Understanding the Structure of the Service-Oriented Architecture

The high-level depiction of service-oriented architecture contains three components: the service, the directory, and the client. Three collaborations take place between the components: locating services, publishing services, and communicating between services and a client. Some service-oriented architecture descriptions include the act of binding to a service as a fourth operation. Figure 3-1 shows the components and operations.

Figure 3-1: Architectural structure of the service-oriented architecture

Each implementation of service-oriented architecture is responsible for dictating how the three operations take place as well as the design of the components that make up the architecture. Some implementations could stress the dynamic capabilities of the architecture and sacrifice ease of implementation transparency, such as the Jini platform. Other implementations may choose to stress implementation and location transparency and sacrifice unique attributes that a particular programming language may have. This second approach is the one Web Services take; if you are a Java programmer, you will notice many sacrifices that Web Services make to achieve implementation transparency when you relate the feature and functions to native Java capabilities.

Understanding the Components of a Service-Oriented Architecture

The three types of components in the service-oriented architecture divide responsibilities between services and clients to services. The directory facilitates physical separation between the client and the service. The three components are as follows :

Service: Any number of services participate in service-oriented architecture. Each service embodies a particular function that is available to other services and clients. Examples of services are a credit authorization service or a sales order entry service.

Directory: There is typically one directory within service-oriented architecture (unless the application considers fail-over or load-balancing scenarios). The directory retains information about businesses and the services that each business publishes. The directory also contains information about how to communicate with each service in terms of its location, interface, and details about communication protocols.

Client: Clients use the directory to locate services and then use the services themselves to fulfill business needs. A client could be another service, or it could be a full Web-based or fat client. In the former case, an order placed through a sales order entry service may call out to a credit authorization service to validate that the user has enough credit to make the purchase. In the latter case, a Web-based client may use a stock ticker service to display up-to-date information, or a portal may collect information and forward it to a service for processing. Depending on how the service gets used, you could view a service as an extension, albeit a physically separated extension, of a client's business logic tiers. A client could also use an aggregation of services as its only business logic tier and place user interfaces directly on top of the services.

Architecturally, the division between the three components is clean. In reality, different architecture implementations, such as Web Services or the Jini platform, use different techniques to implement the architecture components. For example, Web Services use a two-part service implementation, one half to receive and parse a request, the other to fulfill it in a first-class programming platform such as Java. On the other hand, a Jini platform service directly receives and fulfills a service request using Java's RMI. The "Introducing Web Services, and Implementing the Service-Oriented Architecture" section discusses the Web Service environment and how it builds on top of and extends the base service- oriented architecture.

Understanding the Collaborations in a Service-Oriented Architecture

The collaborations that occur in service-oriented architecture are, frequently, the most important aspect of the architecture. By standardizing how collaborations take place, the architecture bypasses the underlying implementation of the service, client and directory. The collaborations that occur in a service-oriented architecture are as follows:

Publish: A component publishes a service, making it available to others via the publishing interface of the directory. Publishing a service involves placing information about the service's interface and additional service details depending on how much information particular directory implementations require. Once published, other clients and services can locate the service via the directory.

Locate: Potential clients of services locate the services via the directory. Clients can locate specific instances of services or look for a match based on search criteria that a particular directory implementation supports. The directory returns to the client information about how to bind to a service, the service interface, and any other information that the client may have requested .

Communicate: The client makes requests of the service via the network protocol specified in the service's directory information. The service fulfills the request and returns the information to the client.

Like the components that make up Services-Oriented Architecture, there is a lot of room for the implementations to innovate and cater to particular needs for the implementation. The Jini platform uses Java's RMI as the primary mechanism to communicate with a service, and Web Services use XML-based mechanisms for the primary communication method. Each has their advantages ”speed vs. broad support. And each has their setbacks ”closed protocol standard vs. performance overhead.

A client has a simple sequence of operations, from a design perspective, to use the components of the design. The client makes a request of the service directory to look up a particular service. The lookup call typically contains some criteria about the service that the client wants. The service information returned helps the client bind to the service and call an operation against the service.

Figure 3-2 shows a typical sequence, ignoring some intermediate steps that may occur depending on the service-oriented architecture implementation.

Figure 3-2: Collaborations from client to service

Conceptually, service-oriented architectures are simple. As they say, the devil is in the details.