As Figure 11 demonstrates, the main idea behind adding an Edge Component is separation of concerns. The Edge Component takes care of all the cross-cutting concerns and other concerns that are not in the core business of the service. These concerns can include areas such as load balancing, format transformations, and auditing. The business logic of the service is then handled in another component that focuses solely on the business logic and remains free of the other concerns. This separation allows supporting all the scenarios mentioned earlier since the separation allows each component to evolve at its own pace. For example, to support a new technology (scenario 1) just add an additional edge component, but the business logic doesn't have to change. When you change the behavior of the business logic and add a new usage plan (scenario 2), the Edge component doesn't change.

In a sense the Edge Component Pattern can be used to provide a façade, proxy and AOP patterns for SOA.

We still have to show how the problem in scenario 3 of implementing cross-cutting concerns across services can be taken care of. The best approach for doing that is to take the single responsibility principle further and remember that the Edge Component is, indeed, a component and it doesn't have to map to a single "monolith" class. For example, you can apply a pipes and filters architectural style and chain several classes/components, each dealing with a specific concern, to create incoming or outgoing pipe-lines. For example, Figure 12 shows a sample Edge Component that applies a validation filter to make sure the message is correctly formatted. Then there's a transformation filter to translate an external contract format into an internal one. Last, there's a routing filter to send the message to the correct component within the service. These subcomponents can be reused from service to service as needed as well as change and evolve independently.

While it is tempting to define an inner contract between the Edge Component and the Service at the onset, there is no real reason to do that unless, maybe, you have to support multiple external contracts (be weary of implementing a contract per consumer though - see PTP Integration anti-pattern). When the service evolves and newer versions of the contract are created like in scenario 1, such as adding a new technology, you may have to add inner contract when you still want to support the older versions of the external one.

The edge component is very useful and I've introduced it in most of the SOA projects I architected. Many of the structural patterns mentioned in this book expand and build on the Edge Component Pattern.

Let's take a look at the technological aspects of the Edge Component Pattern.

Technology Mapping
The technology mapping section takes a brief look at what it means to implement the pattern using existing technologies as well as mention places where technologies implement the pattern.

There is no technology that will take care of all the concerns the Edge Component can fulfill automatically. The upside is that no technology that I know of prevents you from implementing the Edge Component Pattern and some technologies will even handle some of the concerns for you.

For example, JAX-WS or Windows Communication Foundation (WCF) basically implement the Edge Component pattern for you, but they only handle lower-level concerns, which they sometimes call bindings. The concerns handled by JAX-WS and WCF are those mentioned in the various WS* standards; for example, WCF can handle MTOM encoding or Security for you. However, as I already mentioned, you still need to code high-level concerns such as routing and contract translations by yourself.

An interesting technology option is a Java engine called Restlet. Restlet has a few built-in classes that sets it as a good example for implementing the Edge Component Pattern.

Edge Component Example - the Restlet Engine
The Restlet engine by Noelios Consulting, which is a Java library for implementing RESTful services, has some built-in classes, such as filter and router, that allow for easily building an Edge Component. Consider the example in Figure 13.

Figure 13 shows a possible Edge configuration on an Orders service whose contract has two operations: getLast, which returns the last order, and getAll, which returns all the orders for a specific customer. However, before the call actually makes it to the business logic we have to log it, handle statuses or problems, then make sure the correct host was used and finally route the call to the appropriate business functionality. Adding an Edge Component lets us achieve all that without affecting the business logic, which just processes the business requests.

Listing 2 provides an excerpt of the above-mentioned configuration in code.

As we've seen, The Edge Component Pattern is supported by all current technologies and even implemented internally by some of them. You can take a look at the Further reading section at the end of the chapter for links to resources that expand on the technologies mentioned in this section.

Quality Attribute Scenarios
The quality attribute scenarios section talks about the architectural benefits of utilizing patterns from the requirements perspective. Most of the architectural requirements are described from the perspective of quality attributes (scalability, flexibility, performance etc.), through the use of scenarios where these attributes are manifested. The scenarios can also be used as a reference for situations where the pattern is applicable.

The Edge Component Pattern can be associated with a lot of quality attributes. Most of these attributes are the result of applying the Edge Component Pattern along with another pattern. There are, however, two quality attributes that are directly related to the Edge Component Pattern. The first is flexibility - making it easy to change and enhance the external properties of the service without affecting the business logic. The second is maintainability - separation of concerns makes it easy to understand what each component is doing. Recall the three sample scenarios - adding a new technology to an existing service, changing business behavior without changing the contract, and solving cross-cutting concerns only once - with the Edge Component in place, we were able to solve the problem without affecting the rest of the solution or at least minimizing it. Table 2 shows a couple of sample scenarios for using the Edge Component.

The Edge Pattern is the last of the basic structural patterns for SOA. To wrap this excerpt up, let's take a look at the patterns that were covered - before we take a look at additional structural pattern for  availability and scalability patterns.

Summary
This excerpt dealt with a few of the basic structuring patterns for building services. The patterns covered were:

• Edge Component: Separate interface (contract) from implementation to enable flexibility and maintainability
• ServiceHost: Make a common wrapper to host service instances and reuse across services
• ActiveService: Have at least one independent thread in the service so it can initiate
• Transactional Service: Handles messages inside a transaction to gracefully recover from crashes
• Workflodize: Add a workflow inside the service for added flexibility

Reference

1. Web service - is a method that is exposed over http. This is an unfortunate term since it overloads the word service for something that can easily be abused to create

•   •   •

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.