SOA Patterns: Basic Structural Patterns - Part 1
Solving some of the more common issues related to services
Oct. 2, 2008 05:00 PM
A more plausible option is to create a library of common tasks and have each service work with the library's API. This helps a bit, but you are still left with coding the wiring that is needed to utilize all of the library's functionality.
Another option is using inheritance to create a superclass that implements the common functionality and have each service inherit from that class. Using inheritance is also problematic since the service functionality usually won't fit within a single class, due to the granularity of what a service is. In addition, different services handle completely different business areas - otherwise they would be the same service, so it usually doesn't make sense to make them a single class hierarchy.
Using inheritance almost solves our problem as we write the code once and the customization only occurs where the services differ - if we want to get the same behavior without using inheritance we need to use a framework.
The ServiceHost acts as a mini-framework that can have several responsibilities. The first responsibility is to instantiate the right components or classes that the service consists of. The ServiceHost is also responsible for reading configuration information, for instance, the ServiceHost can read the port that consumers can use to contact the service. Another responsibility is to set up the service's environment, for example, setting up listeners on the endpoint. Last, the ServiceHost can be responsible for wiring the components - binding a protocol to the listener to an endpoint or setting up a connection to the database. The common denominator of these responsibilities is that they are all related to instantiating and initializing services and, as we've seen in the problem introduction, you are likely to encounter them in more than one service. As mentioned earlier, the ServiceHost is a framework, which is a little different from the library concept mentioned in option two. Basically it's a collection of utility classes/methods your code can call on to get some functionality. Frameworks, on the other hand, contain some functionality or flow and call your code to extend or make the flow a specific one. The principle of frameworks calling your code is known as "Inversion of Control." It is in wide use in object-oriented frameworks such as Spring or Spring.NET, picocontainers, and the like.
The ServiceHost pattern has several benefits compared with the other options. One benefit was already mentioned - as a framework the ServiceHost performs the work and only calls your code to fine-tune the behavior rather than leaving this orchestration to you. Another benefit is that it better addresses the Open Closed Principle (OCP). OCP states that a class should be open to extension but closed for modification, which is exactly what we get when we use the framework concept.
A ServiceHost may host more than one service - though this is probably not very common. There was one system I built where we had to scale a solution down to run on a single computer and this was handy. The more likely situation is that a service would span more than one computer and then you would have several ServiceHost instances, each hosting parts of the service rather than the complete service
The ServiceHost pattern is commonly used by technology vendors - we can see that in the technology mapping section.
The ServiceHost is a fundamental SOA structural pattern and as such it is supported by most available technologies. Both JAX-WS and Windows Communication Foundation let you configure your services in markup (XML) and have the web server, i.e., the servlet engine or IIS, do most of the wiring for you.
Windows Communication Foundation also has a class called ServiceHost. Microsoft's documentation describes the ServiceHost as follows: "Use the ServiceHost class to configure and expose a service for use by client applications when you are not using Internet Information Services (IIS) or Windows Activation Services (WAS) to expose a service. Both IIS and WAS interact with a ServiceHost object on your behalf." Basically the built-in WCF implementation of a ServiceHost is very much in line with the pattern described here.
If you are implementing the ServiceHost pattern by yourself, perhaps on top of the technology one, you can take a look at a lightweight container like Sprint (or Spring.NET), picocontainers, etc., to help you out with wiring and instantiation. There aren't many other technological implications as the ServiceHost pattern is a relatively simple pattern.
Lightweight Containers and Dependency Injection
As we've seen, the ServiceHost Pattern is simple but effective and is widely used. You can take a look at the Further Reading section at the end for links to resources that expand on the technologies mentioned in this section.
Quality Attribute Scenarios
The main reason to use the ServiceHost pattern is reusability. Reusability is increased by the fact that common tasks that are needed by many services are written only once. A nice side-effect of reusability is also increased reliability as you also only need to debug once. The other quality attribute the ServiceHost Pattern provides is portability. Portability is enhanced by the separation of concern effect of the pattern, as was demonstrated in the scale-down example I mentioned earlier. Another facet of portability comes from the ability to configure the service context in markup.
• • •
This article is based on the book SOA Patterns (http://www.manning.com/rotem) scheduled to print February 2009. This article is courtesy of Manning Publications (http://www.manning.com). The ebook is available and sold exclusively through Manning Publications.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week