Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Business Module Packaging
A business module is implemented to provide specific functionality. The interface to the module is published for clients to interact with it. For in-process communication with direct invocation capability, it could make a direct call to the API. For remote access, the interaction would be through a distributed technology mechanism. In either case, the decision to expose the business logic remotely through web services or direct invocation has no relevance in defining the business module interface. The interface definition is the responsibility of the business module owner, and it should be defined independently of how it gets exposed for remote access.
This is the gist of this article. Web services have been determined to be a preferred way to expose a business module. However, the decision to use web services (or any other technology) is independent of the definition of the business module interface or its development. With this approach, the business module can be developed in isolation, and the decision to use a suitable distributed technology can be determined after the fact. If necessary, we could choose multiple technologies to expose the business module remotely and widen its accessibility. The architecture of such a proposed integration is detailed in Figure 1.
Figure
1 Web services architecture.
Web services act as a packaging layer to the business module. Separating the business module from the web services layer, as shown in the figure, helps in clearly defining the roles and responsibilities for software development within an enterprise.
Web services have WSDL as a means to define the interface, but using WSDL to define the business module interface defeats the purpose of choosing web services, because it ties you to using only the web services technology stack. It's in the interest of the business module owner to have the flexibility to seamlessly change the infrastructure and the distributed technology it uses to communicate with other applications or services. Also, multiple infrastructures could be deployed simultaneously to provide distributed access to the same business module. This is a very common mistake, causing non-portable business modules that cannot switch the distributed layer seamlessly. Many projects start by writing WSDL for their service/business module interface. But WSDL is a web services technology and shouldn't be used to define the core business interface. If you use WSDL to define your interface, and web services are eventually replaced by a newer technology, your business module interface would have to be redefined again in the newer technology.
The interface is the key-binding contract between the consumers and producers; having to change the interface purely due to adoption of a new technology is highly undesirable. Even worse, the interface definition change most likely would break existing clients, because it wouldn't be compatible with the old technology specification. All of this, even while the real interface to the business module is unchanged. This change in interface due to a technology change may be considered poor design.
In the next article, we'll take a closer look at best practices to define the interfaces for your business logic module in greater detail. Subsequent articles in this series will exploit this architecture further and evolve a framework to automate packaging of any business module as a web service.