Chapter 7. Service integration patterns
The previous chapter looked at how service consumers integrate with services to achieve their goals. This chapter takes a look at the higher-level integration of services to achieve goals that are beyond those of a single service, such as several services collaborating to create a complete business process or a report based on information from multiple services. As illustrated in figure 7.1, integration patterns involve all of SOA’s components.
Figure 7.1. This chapter’s focus is on service integration—connecting and making services work together to achieve business goals.
The following patterns are discussed in this chapter:
- Service Bus—Make services interact in a decoupled manner over different protocols, dynamic configurations, and routing
- Orchestration—Make business processes agile and adaptable while using services based on the Request/Reply or Request/reaction interaction patterns
- Aggregated Reporting—Get efficient business intelligence and summary reports spanning the business when the data is scattered and isolated in autonomous services
The first pattern we’ll look at is the Service Bus pattern, which is a communication building block that helps services integrate and collaborate with each other.
Having multiple interfaces or endpoints for each service, as mentioned previously, can be a good option if you want to make sure your service is usable from other services, but it isn’t a good path to choose for integration. You can’t control all the services; if you could, you’d be unlikely to have a problem getting them all to speak the same protocol. In the best case scenario, multiple interfaces will only solve half of the problem—other services could communicate with your services, but you’d still need to figure out and write integration code for services you’d want to consume, and you’d have to do that for each service. That’s precisely the point-to-point integration problem SOA is supposed to avoid.
Enterprise Service Buses (ESBs) are products that cover a lot of service infrastructure aspects in addition to implementing the Service Bus pattern. In addition to service mediation and routing, ESBs will usually add capabilities like orchestration (see the Orchestration pattern in section 7.2), provide management capabilities (see the Service Monitor pattern in chapter 4), help deliver some reliability features (such as the Virtual Endpoint pattern in chapter 3), and so on. Additionally, ESBs usually come with a lot of connectors for easy integration with third-party systems and protocols.
We’ve already covered a pattern for long-running processes—the Saga pattern (chapter 5). In a sense, the Orchestration pattern is a particular implementation of the Saga pattern where the coordinator is external to all the participants. The Saga pattern is more generic, as it can also be implemented without a central component that knows what steps need be done and when to complete the business process. This has the advantage of keeping services more autonomous, with emergent and flexible processes, but the cost is a lack of clarity as to what constitutes a business process and resulting difficulties in monitoring and understanding the current state of those business processes.
Used properly, the Orchestration pattern can add a lot of flexibility to SOA as well as keep you from losing sight of the forest for the trees—the many services you may have in your system. The main risk you run when using the Orchestration pattern is to overuse it, which can result in SOA antipatterns like Nanoservices (discussed in chapter 8). To help avoid this problem, you can partition the workflows between the external flow (Orchestration) and internal flows (the Workflodize pattern in chapter 2).
The service component is the SOA endpoint of the Aggregated Reporting pattern, and by “SOA,” I mean it utilizes standard SOA technologies like web services or messaging. The service exposes two types of endpoints:
The main active functionality of the data back end component is the Transformation service (which you can think of as an implementation of the Active Service pattern discussed in chapter 2). The Transformation service’s responsibility is to rearrange all the incoming data in a way that’s useful for reporting. An Aggregated Reporting implementation will have extensive transformation components that will sift through the raw data, clean it, aggregate it, and build useful representations of it.
This chapter’s goal was to highlight the main integration patterns that enable services to work together and become a system, rather than a bunch of services or an unmaintainable knot (see the Knot antipattern in the next chapter).
That’s the end of part 1 of this book. The next part takes a look at some aspects of implementing SOA in the real world. The next chapter will take a look at some of the common pitfalls, or antipatterns, that can ruin a fledging SOA implementation at the start.
Arnon Rotem-Gal-Oz, “SOA—Contracts, Events and Ownership”, Cirrus Minor (blog), http://arnon.me/2010/09/soa-contracts-events-ownership/. This article discusses which party, the service consumer or the service, should own the messages and event contracts.
Martin Fowler, “CQRS” (Command Query Responsibility Segregation), http://martinfowler.com/bliki/CQRS.html. Martin Fowler’s site provides a good explanation of the CQRS concept. CQRS is a complimentary approach for aggregated reporting, which, as its name implies, suggests that data for commands (such as updates) is sent to one source, whereas the data for queries arrives from a different source. Usually the context for CQRS should be within services, but if you implement the Aggregated Reporting pattern, you can use it as the source for queries in a CQRS system and even provide wider reporting capabilities (with data originating from multiple services.