Industry Commentary

Services-oriented architecture (SOA) is quickly emerging as a strong technical foundation for enterprise applications. My company, involved in the development of application architecture solutions, has seen a growing emphasis on SOA to meet the integration, process-level reuse, and flexibility requirements of the dynamic enterprise environment. While simple Web services have educated the market on services, SOA is the implementation that most enterprises are adopting to achieve their goals.

The W3C has a Web Services Architecture group that is working in this area. While the group is called Web Services Architecture, that term is used interchangeably with services-oriented architecture. The emergence of the W3C as a standards body working to bring some cohesiveness to this space can only be a good thing for the enterprise. By bringing clarity to the issues and requirements involved and then working to define standards, this will result in common interoperable foundations. This interoperability is key if the enterprise is to realize the long-term advantage of turning a heterogeneous IT environment into a corporate asset.

Four Key Decisions
With that backdrop, let's look at the four key architecture decisions that will lay the groundwork for the successful adoption of SOA. These key decisions are:

• Service Transport
• Service Protocol
• Service Interface
• Service Interaction Pattern

Those of you who are familiar with the OSI (Open Systems Interconnection) Reference Model will probably recognize the benefit of establishing common vernacular and standards for these decisions. Since history is a valuable tool for education, let's take a quick look at the OSI. Work on the OSI started in the 1970s with the goal of standardizing the way computers communicate so that they could communicate ubiquitously. Everyone seems to have heard at some point (usually from their college days) about the seven layers of the OSI model: physical, data link, network, transport, session, presentation, and application. These layers cover everything from the lowest level, how bits go over the actual network hardware, to how the application interfaces with the communication mechanism. Standardizing these layers is what allows hardware vendors to build Ethernet cards that interoperate and, somewhat more prominently, what allowed the Internet to become such a widespread success through the use of TCP/IP and http, which fits into the OSI model.

If services-oriented architecture is to share that same success, common answers must be made, or at the minimum it should be realized when answers conflict so that some interoperability can be established where necessary. Recognize also that these decisions build on each other, similar to the OSI layers. The transport is the lowest layer and the interaction pattern the highest layer.

Service Transport
The service transport is the mechanism by which the services will communicate with each other. The two choices that are most evident are direct communication using HTTP, or messaging-based communication using any of the available message-oriented middleware (MOM) vendors. In talking with companies that are currently adopting SOA, it is evident that the messaging transport provides the desired loose coupling of services with the robustness required of 24x7 enterprise applications. The HTTP transport is being used mainly for communication within the extended enterprise.

Service Protocol
The service protocol is the language the services will use when communicating with each other. SOAP is a standard that is emerging at the lowest level. But that is not sufficient for defining the services protocol - it is akin to two people who know only eighth-grade English attempting to discuss physics. Enterprises have the option of adopting higher-level standards from sources such as ebXML or RosettaNet, or creating their own service protocol. The best path to take depends on the integration touch points, where standards may be more beneficial, and the internal needs of the enterprise, which may best be met with a custom protocol.

Service Interface
The service interface defines what the service looks like to those who want to use it. The desired service granularity defines the typical service interface, which is then customized for particular services. A rule to follow is that an API-based interface forces early binding while a document-based interface allows late binding. The document-based interface provides the desired flexibility and loose coupling of services. One pitfall to watch out for is fine-grained interfaces that lead toward too much interservice communication. This introduces unnecessary overhead that will impact performance and scalability and also leads to tight coupling of services.

The service interface should also be definable outside of the implementation. Supporting service definitions is important for separating the implementation of a service (called a service provider) from the user of the service (called a service consumer). This service definition is often called a service contract. The service definition is a very important contributor to the workings of the service interaction.

Service Interaction Pattern
The service interaction pattern defines the landscape for how the services work together. The interaction pattern determines the controller of the service interaction and how much the services know about each other. Central-dispatcher and service-to-service workflow are two of the leading options for controlling service interaction. The service definition that was mentioned earlier plays an important role in determining the interaction by allowing a service seeker to find a service provider. Since the service provider may change, the service definition is the stable point for linking a service consumer and provider.

Another powerful concept employed in service interactions is service leasing. Service leasing refers to the concept of providing the service consumer with a handle to a service provider, with the caveat that the service provider handle is only good for some period of time (or possibly until some external event or condition takes place), after which the service provider handle expires. Once the service provider handle expires, the service consumer would once again have to find a service provider. A useful analogy is DHCP (Dynamic Host Configuration Protocol), which is used for controlling IP address allocation (along with other networking configuration). In the old days of networking, every computer had its own IP address, which had to be allocated and tracked manually by the IT staff. As computers were added and removed, the IP address tracking could become quite an administrative task. Enter DHCP, which allows a central server to allocate IP addresses to client computers using a leasing mechanism. As computers join a network, they receive an IP address that is good for some amount of time. Once it expires, the DHCP server gets the address back and can reallocate it. There are no wasted IP addresses given to machines that have been removed from the network and if there are network changes that need to be made, the server will propagate them when the clients release their IP address.

Answering these four critical questions will form the services-oriented architecture environment. These architecture decisions must be made in a consolidated effort in order to realize the full benefits of the SOA. Because of their interdependency and impact on each other, they cannot be made independently. While this will form the enterprise standard for typical services, it should not be constraining. Some services may deviate because of their unique requirements but those situations should be closely examined and noted. Referring to the adoption of the OSI Model, it can be seen that the more layers that have common answers (i.e., using TCP/IP vs Novell's IPX), the more interoperation will be possible, with the nice side effect of lower maintenance and administration costs.

Conclusion
While these four decisions lay the groundwork for an SOA, as its adoption in the enterprise expands and becomes more advanced there will be application-level requirements that need to be addressed. The solutions to the application requirements will be built on the SOA layers we just discussed. Some requirements that are likely to be encountered are session management, context sharing, security, and transactions. Session management is important if a service gets many invocations from the same consumer; how can the service become part of that session of communications without the consumer having to repeatedly send the same information. Context sharing streamlines the support for many services to work together to fulfill a business function. Because the behavior of the services may vary based on certain environment conditions (such as user, request, or session variables), these services need access to that information. In lieu of the service consumer proactively sending all possible environment variables, it would be nice if the service provider could access it if needed. Security and transactions are more straightforward because they are traditional application concerns: how do you secure services so that you have control over who can access them and how do you maintain data integrity when many services may be involved in processing business functionality? SOA is evolving to address these requirements.

While it may seem that there is a lot to grapple with when adopting an SOA, don't be intimidated. Education is the first step - understand what the factors are for laying a successful SOA foundation. If the decision is made to adopt an SOA approach for constructing your business assets, you will encounter many build versus buy decisions.

Remember to trust your experience and intuitions. SOA is a big step in the evolution of distributed computing but it is not a brand new invention or a silver bullet.