This chapter is from the book
This chapter is from the book
This chapter is from the book
Service-Oriented Development
Software vendors have widely adopted the paradigm of service-oriented development based on Web services. Service-oriented development is complementary to the object-oriented, procedure-oriented, message-oriented, and database-oriented development approaches that preceded it.
Service-oriented development provides the following benefits:
Reuse—The ability to create services that are reusable in multiple applications.
Efficiency—The ability to quickly and easily create new services and new applications using a combination of new and old services, along with the ability to focus on the data to be shared rather than the implementation underneath.
Loose technology coupling—The ability to model services independently of their execution environment and create messages that can be sent to any service.
Division of responsibility—The ability to more easily allow business people to concentrate on business issues, technical people to concentrate on technology issues, and for both groups to collaborate using the service contract.
Developing a service is different from developing an object because a service is defined by the messages it exchanges with other services, rather than a method signature. A service must be defined at a higher level of abstraction (some might say at the lowest common denominator) than an object because it's possible to map a service definition to a procedure-oriented language such as COBOL or PL/I, or to a message queuing system such as JMS or MSMQ, as well as to an object-oriented system such as J2EE or the .NET Framework.
It's also important to understand the granularity at which the service is to be defined. A service normally defines a coarse-grained interface that accepts more data in a single invocation than an object and consumes more computing resources than an object because of the need to map to an execution environment, process the XML, and often access it remotely. Of course, object interfaces can be very coarse-grained. The point is that services are designed to solve interoperability problems between applications and for use in composing new applications or application systems, but not to create the detailed business logic for the applications.
It's possible to create an aggregation of Web services such that the published Web service encapsulates multiple other Web services. This allows a coarse-grained interface to be decomposed into a number of finer-grained services (or multiple finer-grained services to be composed into a coarse-grained interface). The coarse-grained service may make more sense to publish, while the finer-grained services may make more sense as "private" Web services that can be invoked only by the coarse-grained Web service.
Services are executed by exchanging messages according to one or more supported message exchange patterns (MEPs), such as request/response, one-way asynchronous, or publish/subscribe.
At a project level, an architect typically oversees the development of reusable services and identifies a means to store, manage, and retrieve service descriptions when and where they are needed. The reusable services layer insulates business operations such as "get customer" or "place an order" from variations in the underlying software platform implementations, just as Web servers and browsers insulate the World Wide Web from variations in operating systems and programming languages. The ability of reusable services to be composed into larger services quickly and easily is what provides the organization the benefits of process automation and the agility to respond to changing conditions.
How XML Helps Simplify Systems Development and Integration
The use of XML in Web services provides a clear separation between the definition of a service and its execution. This separation in the standards is intentional so that Web services can work with any software system. The XML representation, provided through an XML Schema, of the data types and structures of a service allows the developer to think about the data being passed among services without necessarily having to consider the details of a given service implementation. This represents a change in the nature of the integration problem from having to figure out the implementation of the service in order to talk to it. Whether the service's execution environment is an object, message queue, or stored procedure doesn't matter. The data is seen through the filter of a Web service, which includes a layer that maps the Web service to whatever execution environment is implementing the service.
One way to help accomplish this significant turnaround in the way we think about how to design, develop, and deploy applications using services may be to divide the responsibility within IT departments between those who:
Create the services—Dealing with the complexity of the underlying technology on which the service is being deployed and ensuring that the XML/Web services descriptions are what the service consumer needs and that they share the right data.
Consume the services—Assembling new composite applications and business process flows, ensuring that the shared data and process flows accurately reflect operational and strategic business requirements.
This potential division of responsibility more cleanly separates the technical issues from the business issues.
Organizational Implications of SOA
Previously, the same individuals in the IT department were responsible for understanding both business and technical functions—and this remains a classic problem for IT, that is, getting the same person or persons to bridge business and technology domains. To gain the full benefit of Web services, SOA, and BPM technologies, IT departments should consider the best organization and skill set mix. It's important when adopting a new architecture and a new technology to identify new roles and responsibilities. Among the important considerations is that technical staff must be able to reorient themselves from thinking about doing the entire job to doing a piece of the job that will be completed by someone else. A service needs to be developed within a larger context than an object or a procedure because it is more likely to be reused. In fact, defining services for reuse is probably the most important part of service orientation. To obtain their highest value, services must be developed in the context of other services and used in combination with them to build applications. This change in thinking is likely to require someone in a departmental or corporate leadership position to help review designs and ensure that they are in line with these new IT goals.
Service Abstraction
A service is a location on the network that has a machine-readable description of the messages it receives and optionally returns. A service is therefore defined in terms of the message exchange patterns it supports. A schema for the data contained in the message is used as the main part of the contract (i.e., description) established between a service requester and a service provider. Other items of metadata describe the network address for the service, the operations it supports, and its requirements for reliability, security, and transactionality.
Figure 1-2 illustrates the relationship among the parts of a service, including the description, the implementation, and the mapping layer between the two. The service implementation can be any execution environment for which Web services support is available. The service implementation is also called the executable agent. The executable agent is responsible for implementing the Web services processing model as defined in the various Web services specifications. The executable agent runs within the execution environment, which is typically a software system or programming language.
)
Figure
1-2 Breakdown of service components.
An important part of the definition of a service is that its description is separated from its executable agent. One description might have multiple different executable agents associated with it. Similarly, one agent might support multiple descriptions. The description is separated from the execution environment using a mapping layer (sometimes also called a transformation layer). The mapping layer is often implemented using proxies and stubs. The mapping layer is responsible for accepting the message, transforming the XML data to the native format, and dispatching the data to the executable agent.
Web services roles include requester and provider. The service requester initiates the execution of a service by sending a message to a service provider. The service provider executes the service upon receipt of a message and returns the results, if any are specified, to the requester. A requester can be a provider, and vice versa, meaning an execution agent can play either or both roles.
As shown in Figure 1-3, one of the greatest benefits of service abstraction is its ability to easily access a variety of service types, including newly developed services, wrapped legacy applications, and applications composed of other services (both new and legacy).
){kind=small}
Figure
1-3 Requesting different types of services.
Separating the Service from the Product
Some software vendors still don't separate the idea of a service from the idea of an execution environment, and they continue to sell Web services implementations only as part of another, typically pre-existing product. This practice can make it more difficult to obtain the benefits of services because the products have features that may not be required to execute Web services and that may create incompatibilities if the products make the services dependent upon them.