Anatomy of service
Components of a service
Diagram below illustrates functional components of a service. At this moment we don’ allocate these functions to the specific components of the integration stack.
The service interface is a collection of message types that the service accepts. These messages are ten tranlated by the broker into finer-grained messages to the adapter (s) (or service(s) that are part of this virtual service). The application adapter(s) tranlate the messages from broker into API calls to the applications.
The functional components of a service include:
- One or more service implementations. These are the to-be-integrated applications, likely implemented using object technology.
- Service abstraction has three tasks:
- Inteface. It acts an interface between the applications and the integration universe. This integration universe may be a bus or a broker.
- Translation. It translates messages from the integration layer into calls to application(s) and translates the outbound application calls into messages to the integration layer.
In general, that’s all you should do: pass messages between the applications/services; ideally, use coarse-grained document-style messages. You should avoid RPC-style connection-oriented interactions, for reasons described here.
- Orchestration. It coordinates multiple API calls or service invocations to yield coarser-grained services.
Service in the Bus integration model
The following figure illustrates an implementation of service in the bus model. For simplicity, lets focus on the service provider side and simplify the service consumer by representing it as a single box.
The service abstraction function may be distributed:
- You can allocate translation task to the adapter, to the broker, or have both share this role.
- Likewise, you can allocated orchestration task to the adapter, to the broker, or to both.
How do you chose to allocate these functions? These common sense guidelines may help you:
- A common school of thought is that translation and orchestration is best done by the broker and that the adapters should remain ‘thin’ (i.e. should be just transport adapters). This is fine thinking unless your broker is counterproductive in which case you should take this opportunity and code your translations / orchestrations for the service layer in your programming language of choice.
- If you coordinate services provided by multiple providers, you are likely to need broker.
- You should try to allocate your orchestrations / translations to the same component, to simplify future changes and refactorings. Again, choose the more productive environment (hopefully the broker) to perform these functions.
- Off-the-sheld adapters come in different flavours, ranging from relatively simple transport adapters to complex adapters that perform business functionality, such as tranlation of the fine-grained application APIs to more coarse grained messages. If you happen to own such a complex adapter, it makes sense to use its orchestration / translation.
Service in the Broker integration model
The following diagram illustrates service composition in the broker model.
Unlike in the bus model, there is no natural demarcation line that would isolate the service requestor from the service. In the bus model, transport (MOM) is such a natural demarcaton line. In the broker model, the service is simply an orchestration that can be invoked by another orchestration (very much like intra-program method call). Therefore, you must pay extra care to clearly isolate services from their consumers.
As in the bus model, you have a choice of distributing the service abstraction functions between adapters and broker. Similar trade-offs apply, however in the broker model, you are less likely to allocate translation or orchestration to the adapters. Having all translations / orchestrations in a single domain, it should be easier to make functional changes / refactor the integration solution, assuming that you have a productive development environment.
Variations on the above options
Of course, multiple variations on the above two options are possible. For example, in the bus model, you may eliminate broker from the service side altogether. Or, you can have broker talk to service providers directly, skipping the common transport. These variations make no substantial difference to the construction of service - that’s all they are, variations.