This chapter introduces the concept of Services and the associated architectural paradigm, Service-Oriented Architecture (SOA). SOA has emerged as a direct consequence of specific business and technology drivers that have materialized over the past decade. From the business side, major trends such as the outsourcing of noncore operations and the importance of business process reengineering have been key influences driving the surfacing of SOA as an important architectural approach to business information technology (IT) today. From the technology side, the past 15 years have resulted in a realization of the importance of middleware standards and architectures, learning in particular from the successes and failures of distributed object systems and message-oriented middleware.
As an architectural concept, SOA permits multiple approaches for the realization and deployment of an IT system that has been designed and built around its principles. This book focuses on a specific technology that, arguably, has the most significant commercial visibility and traction, and that is Web services. Web services technology is a standards-based, XML-centric realization of an SOA. This chapter examines the motivation behind Web services and some of the main architectural concepts of SOA. Chapter 3, “Web Services,” presents an overview of a Web services platform that provides the foundation to accomplish an SOA stack. Chapter 2, “Background,” offers some required background so that you can understand the rest of this book.
Most companies produce and sell products to their customers to achieve defined business goals, such as specific financial targets. Their business processes prescribe how products are designed, manufactured, marketed, distributed, and sold. From a certain level of abstraction, a company’s business processes are a direct reflection of the products it offers. Therefore, the speed of changing the existing infrastructure or creating new business processes corresponds to the speed of changing or creating products.
To survive in highly dynamic markets and constantly changing environments, companies must be flexible. Flexibility here means the ability to react quickly (preferably faster than the competition) to new customer requirements, new product offerings by existing and new competitors, technology advances, and so on. The flexibility of an enterprise is a refection of its ability to adapt its business processes quickly.
The constituents of the definition of a business process (see [Ley 2000]) translate directly into actions that are necessary to alter business processes: changing the flow of activities of a business process, changing the actors who are performing these activities, changing the tools that support these activities, and so on. These might result in moving the execution of (a subset of) the activities of the business processes to partners. The result could be multiple business partners having to cooperate to perform the business processes of a given company. The company in fact becomes a virtual company (or virtual enterprise). This term indicates that externally, the company looks like a real company—performing all of its business processes itself—but in practice, that is not what is actually happening. Others are partially running the company’s business processes, making the company virtual in this sense.
The model of a business process prescribes the order in which a business must execute the activities that constitute it and under which conditions it must perform each of the activities. Collectively, this kind of prescription is called control flow. The control flow massively influences business-relevant properties of a business process—such as its total cost and its overall duration—and thus the competitiveness of a company:
The execution of each step or activity within a business process is associated with certain costs, such as people costs that are associated with the activity if human intervention is required, or the cost of computer resources that are required to execute activities within the IT environment. Based on this information, a company can derive the overall cost for performing a business process. For example, if policy associated with a credit allocation process determines that someone must check credits with an amount greater than $1,000, and more customers are asking for credits above this limit, a business could change the policy to set manual intervention at a higher value to reduce the overall costs for running the process.
Activities have temporal characteristics, such as the average duration for executing an activity or the average time elapsed until an activity is picked up and performed. Based on this information, you can derive the average interval for executing a business process. For example, when you are booking a business trip, you can reserve hotel and flight reservations in parallel, resulting in a shorter execution time for the overall business process relative to its sequential execution.
There are other business-relevant properties of business processes and the activities they encompass. Changing the control flow of a business process might alter the corresponding properties of the business process in an unexpected manner. For example, introducing parallelism between activities might result in a longer duration of the overall process in those cases in which the parallel activities compete for the same resources (such as staff members who have rare skills).
Therefore, modeling a business process is a non-trivial endeavor, supported by specialized design and analysis tools. After having modeled and optimized a business process, it must be executed in exactly the way it was specified to ensure the business properties that the process is optimized for. Special middleware is available that enforces the correct and model-compliant execution—so-called workflow systems [Ley 2000]. Workflow systems allow monitoring of the business properties of individual business processes or aggregations of business processes at runtime. They also support the analysis of corresponding execution histories. Based on monitoring and analysis of results, you can change the model of a business process, if required, to further optimize it, especially when benchmarking shows that the execution of a business process is not competitive in terms of its key business parameters, such as cost or duration.
Sometimes, modifying the control flow of a business process is insufficient to hit the target values for certain business properties. For example, the cost structure within a company or wages for certain required staff might be too high to meet business expense targets. In such situations, a company’s business process cannot gain competitiveness without significant re-engineering. The company (or a certain branch or location within a company) should probably determine its core competencies, focus on executing only the activities that correspond to these core competencies, and outsource the noncore competencies. Of course, the constraint is that outsourcing must result in hitting the target objectives of the subject business properties. SOA and Web service technology facilitates this kind of outsourcing in a secure, reliable manner.
Figure 1-1 demonstrates an original process (denoted by “P”) that a company runs. The company determines that it is no longer competitive in performing activities A, B, and E. It finds two partners that can run these activities and meet the business goals. Partner 1 runs activities A and B, and Partner 2 runs activity E. The company re-engineered the original process into a new process (P’). In the new process, activity AB kicks off the execution at the first partner (Partner 1), and E’ starts the execution at the second partner (Partner 2). The company now has a new process P’, which results in increased competitiveness.
In general, a company can work in several ways with partners that run the outsourced activities. One way is for a business to acquire a partner that can effectively run some of the activities that it could not run in a competitive manner before. A company might take this approach if the activities that it has trouble performing competitively are core to its business. A company might also choose this acquisition if it is cheaper to acquire the partner than pay the partner to perform the activities. A company might also choose to merge with a partner, essentially combining its own business with that of the partner in a peer manner. This could exploit synergies between the two companies, further reducing costs and enhancing the competitiveness of the aggregate. Usually, mergers and acquisitions result in business processes that are run in a distributed manner, across partners or virtual enterprise as described here.
Mergers or acquisitions can have a deep impact on companies, and they, thus, generally take a less radical approach. They determine appropriate partners and negotiate long-term contracts for performing specific activities on behalf of the outsourcing company. These contracts especially include service level-agreements, which are specifications of service objectives such as availability of the outsourced activities, penalties applied when objectives are not met, bonuses paid if the objectives are overachieved, and so on [Dan 2004]. The result is a network of collaborating partners.
Situations might be highly dynamic. Multiple partners might provide the same services, and a company should choose on a case-by-case basis one of these to perform specific activities. For example, the cost of performing activities on behalf of a company might change depending on the actual load at each partner side. The company can then determine the partner on a best-price basis.
Collaboration might not only result from process optimization endeavors, but from supply chains that are typical within an industry. In this situation, a company and its partners are not distinguished. All partners are peers, collaborating to realize an overall business process that is spread over the partners. Some industries even have standards to define the various kinds of partners, the activities each of them runs, and how they relate. For example, RosettaNet [RN] defines such a standard and is currently moving toward Web service technology [RNWS].
In addition to business process optimization, businesses outsource activities or complete business processes for total cost of ownership considerations. Perhaps a business process is competitive overall, but the overall cost for running parts of it on IT equipment that the company owns is too high. In this situation, a company looks for a partner to run the corresponding activities or the whole business process on behalf of the company. This partner, also called application service provider (ASP), not only runs parts of the business process on its IT equipment, but it also runs the corresponding software, covering the whole spectrum from managing prerequisite software to monitoring the software and performing periodic backups.
Web service technology, technology from the area of Grid computing that is based on Web services, and autonomic computing facilitate the ASP model and extend it toward a model called utility computing (see [Ley 2004], [Rappa 2004]). Within this utility computing model, computer resources and other IT related resources are offered in a similar manner to traditional utilities such as electricity or telephone. The usage of the utility IT resources to run parts of a business process is metered and charged on this basis. You will read more about this topic later.
Enabling communication with services, possibly dynamically discovered, requires loose coupling between a requester and the service to be used. The notion of loose coupling precludes any knowledge or assumptions about the specific platforms that the requester or the service provider run on, specifics about the implementation that either of the partners uses, or the formats and protocols used to interoperate between them. Making such assumptions significantly limits the usefulness of a service or the choice of services that might be available. The notion of loose coupling is a fundamental underpinning of SOA. The following section sheds more light on it.
Distributed system technology that has been developed in the past allows building applications, the elements of which can run on different machines in a network. However, dealing with the business scenarios outlined earlier has some other issues.
Typically, current distributed system technology is centered on object technology. In this case, a service is offered as a method of a class implemented by an object. A requester who wants to use a service must tie the whole object into his application. In other words, a person who needs a single function has to use the whole class or—even worse—the whole class hierarchy within his program. When the class used or the class above it in the class hierarchy changes, he must also change the application that uses that class. The requester and the service are tightly coupled, which means that the requester’s application is fragile because of its association with and dependence on this detail.
Today, different distributed system technologies such as Common Object Request Broker Architecture (CORBA), Java 2 Platform, Enterprise Edition (J2EE), and Component Object Model (COM) are based on quite different and incompatible object models [Emm 2000]. As a result, interoperability between these platforms is difficult. Communication between a requester on one platform and a service on another is at best cumbersome, if it’s possible at all. Not only are the object models different, but higher-level frameworks (middleware) that support them (such as transactions, security, management, and messaging) are also incompatible. This significantly compounds the interoperability problem because you have to deal with quality of service differences. These differences can include running a transaction with participants on different platforms that operate incompatible transaction services, which is not an easy task!
A significant consequence of these interoperability problems is that islands of middleware and corresponding applications that are based on this middleware have been created. In parallel, the ability to easily integrate applications, especially from different islands, has become a strong requirement (Enterprise Application Integration – EAI). In tandem, products that provide special integration middleware have been created. A key aspect of such integration middleware is message orientation.
Message orientation refers to messages being exchanged between the applications that are to be integrated. For this purpose, adapters wrap existing applications that need to be integrated. One kind of adapter signals the occurrence of an event that needs to be passed to other applications (source adapter), and another kind of adapter receives such events and passes them to the application that they are wrapping (target adapter). Events are represented by messages that are transported via a so-called “channel” from the source adapter to a target adapter. The channel ensures a certain quality of services, such as “exactly once delivery”. Also, the channel can have other side effects, such as transforming the message into a format that the recipient understands. Figure 1-2 shows a source adapter A that wraps application A. Adapter A passes a message of format M to the channel, which transforms the message into format M’ and delivers it reliably to target adapter B. Adapter B in turn understands how to pass the data from M’ to B. See [Hohpe 2004] for additional perspectives in this space.
Based on this message-based architecture, applications A and B are loosely coupled. For example, the owner of application A can change the format of message M, generally without affecting his ability to integrate application B. The message M that A produces can be appropriately transformed by the channel into the format M’ that B expects. A message-based approach like this fosters loose coupling.
Often, interaction and communication styles, other than the synchronous request/response approach that is predominant in distributed object systems, are necessary for loosely coupled interactions. For example, the asynchronous send and receive pattern that was mentioned in the previous section can increase a requester’s perspective of the overall availability of the requested service. Operating in a “send-and-forget” mode, the requester doesn’t have to synchronously wait for a response from the service. The requester doesn’t have to deal with potential connection problems between the requester’s side and the service’s side because the channel can operate in a store-and-forward manner, finally delivering the message to the target destination.
Other patterns are also desirable. For example, a message might be delivered to multiple recipients, only a subset of which responds to the originator of the message. This pattern is useful in auction-type scenarios in which a request for bids is sent and bids are returned. This also contributes to loose coupling because the requester is unaware of who the recipients are. The underlying integration middleware deals with these aspects. To overcome rigidity in distributed object systems, you must support the ability to define message exchange patterns (MEP), which provide advanced interaction patterns. MEP is discussed in Chapter 6 in more details.
Web service technology is built on the concept of messaging. As a result, requesters and services can run on different platforms with channels connecting them. Wrappers hide the implementation specifics of the wrapped application function. In other words, requesters and services that are built according to different programming models can interact with each other. Protocols that are underlying a channel are hidden from the communication partners, and different formats can be transformed within a channel. The messaging architecture underlying Web services—SOAP—also foresees exchange of information required by higher-level functionality, such as transaction context or security context. Therefore, a messaging-based approach supports many of the requisite features at the beginning of this section.
The concept of a wrapper allows switching implementations of application functions without impact to the other communication partner. This in turn facilitates loose coupling between a requester and a service (their corresponding wrappers). That is fine, but a universally agreed or standard approach to specifying the wrappers is required to describe, in a machine-readable way, the interface that a service provides to its potential users. The Web Services Description Language (WSDL) provides precisely this capability.
WSDL provides a standard way of describing the interfaces of the wrappers that hide the specific implementation details of a service. Such an interface describes, in abstract terms, the functions that services provide. A requester can use any service that implements a particular interface to satisfy his requirement. This contributes to loose coupling between a requester and the service and provides some element of future-proofing. It gives the requester the freedom to select a different service implementation of the same interface at any time. In particular, the requester can benefit from any future advancements in implementation technology for services by being based on WSDL interfaces.
Services are described not only by their WSDL interfaces, but also in terms of the quality of service they provide. For example, a service might assert that it can participate in a transaction, thereby ensuring overall integrity of a series of service invocations. It might also assert that it can cope with encrypted messages, ensuring that in the course of an interaction between a requester and the service, no confidential data will be revealed to unauthorized parties. The ability to annotate quality of service descriptions is important, and incorporated into Web service technology by means of the Web service policy specifications discussed later in this book (Chapter 7, “Web Services Policy”).
Also, you can associate services with business-relevant data. The directory features of the Universal Description, Discovery, and Integration (UDDI) technology (discussed later) offer and support such a capability and allow information about the company that is providing the service, including contact information, additional documentation, and geographic details. This allows discovery of suitable services based on detailed business criteria. For example, as a requester, a restaurant might want an online service that supplies ordering, settlement, and delivery of vegetables, meat, and so on within a distance of less than 50 miles.
As a consequence, the boundary for describing and discovering services is moved from specialized IT personnel toward business professionals. Again, this contributes to loose coupling by supporting discovery of providers that offer identical services and allowing switching between them dynamically with little or no change to the application.
In everyday life, you can point to many metaphors with which you can associate the concept of a service. These might include utilities such as water, gas, telephone, or electric, in addition to credit card services, transportation, travel agents, instant messaging, Internet service providers, search engines on the Web, and so on. These services represent some sort of publicized package of functionality. They are composeable. For example, a travel agent makes use of transportation (airline and rental car) and credit card services. Services are discoverable based on their descriptions, terms and conditions for use, and so on, based on metadata that fully describes the service. Actual use of a service is often based on an agreed-upon contract with the provider, including what in detail is provided and what the associated quality of services are, such as availability, cost, and other specified conditions that govern its use. Generally speaking, the user of the service requires little or no knowledge as to the specifics of how the service is implemented or how it is provided. The following sections relate these characteristics and apply them to software services.
The idea of packaging software into artifacts that have a wider context, use, and applicability than a single application has been given a lot of attention since the early days of computing. This objective also relates to more flexible units of deployable software. Additional benefits are derived through separation of concerns, which leads to a significantly better understanding of the overall anatomy of complex software systems. This in turn enables improved software development methodologies necessary for tackling today’s complex problems, in addition to improvements in software maintainability. Over the past decades, the ideas that have been applied to this problem have evolved quite significantly.
One of the first attempts to decompose software was centered on functional decomposition that resulted in functions or subroutines as individual software units. Such a unit offers coherent functionality that you can easily understand and build. This decomposition into functions enables modularization of software systems. However, this approach frequently brings about partial simplification that can only address simple problems. Added value comes with aggregations of related functions that help solve more complex tasks that are associated with a particular problem domain. Such approaches have, for example, been pioneered by Ada in the form of packages.
A package is a mere syntactic unit. To improve on and extend this concept further, the notion of a class evolved. A class describes the behavior of objects from a problem domain; therefore, it carries certain semantics in addition to being a syntactic unit combining functions and data. Classes, together with the concept of polymorphism and inheritance, have turned out to be a powerful concept for building software. Polymorphism allows the resulting software to become more flexible, whereas through inheritance, class lattices can be built that stimulate reuse and ease communication among developers within a given community.
Although classes represent objects and carry some semantics, a class lattice mostly captures syntax—namely, the signature of the functions aggregated. The semantics that a class lattice captures are typically understood only within a limited community, such as a development team. Few class lattices are known, the semantics of which are shared across larger communities.
In contrast to this, services are described not only via their interfaces, but also via business terms. Thus, the semantics that a service description provides go beyond that of a class and a class lattice. As such, services support comprehension by much broader communities.
Besides being coarser than objects and classes, components go further by dealing with deployment. Addressing the issue of deployment allows a component provider to focus specifically on application logic, while qualities of services are folded in by the runtime environment that is hosting the component. For that purpose, quality of service requirements are factored and parameterized by deployment descriptors [J2EE]. By setting appropriate values in the deployment descriptors, you specify the behavior of a component with respect to such things as transactions, security checking, state management, and so on. In addition, you can resolve dependencies on other components and resources (such as databases and queues) via deployment descriptors. Finally, you can set up values governing application-specific context (such as local tax rates) via deployment descriptors.
Dealing with these aspects of deployment eases customization. You can tailor a piece of application logic to a company’s specific use by setting values in deployment descriptors accordingly. The container that is hosting the application logic interprets the deployment descriptors and ensures the specified behavior. For a customized context that the application logic requires, the deployment descriptor provides the standardized contract. Deployment descriptors enable components to become tradeable artifacts.
Services represent another step forward in the evolution of software packages. Services can provide an abstraction of specific component models, allowing users of these components to think only in terms of Web services and ignore specific details of the component model and how it its implemented. For example, services can hide the details about whether the component is a J2EE-based component or a .NET based component. This provides significantly enhanced interoperability between computing platforms that have programming models based on these differing component models, such as WebSphere and .NET.
A service is available at a particular endpoint in the network, and it receives and sends messages and exhibits behavior according to its specification. The service has specific functionality and is deployed with appropriate quality of service at the endpoint. (For example, the service is set up with certain transactional or security or reliable messaging behavior.) The functional aspects of a service are specified using WSDL, and the constraints and conditions that are associated with the use of the service are specified via policies that you can attach to various parts of the WSDL (see chapter 7). Interfaces and policies describe the terms and conditions that govern the use of the service. These are published so that potential users of the service can discover and be given all the information they need to bind (perhaps dynamically) to that service.
The information that is published about a service provides details of what the service is and does (its semantics). It further provides all the information that allows the environment hosting a potential user to access the service and successfully interact with it. This can include information about the transport protocols that can be supported and used to send a messages to the service, the wire format of this message expected by the service, whether and how the message has to be encrypted or signed.
Although the environment that is hosting needs this information, the requester doesn’t need this kind of access information, and it certainly doesn’t need to understand details about the implementation of the service. You can implement this service as an EJB, a database stored procedure, or a CICS or IMS transaction made available via a wrapper. The environment that is hosting the service and receiving the request message, often referred to as a container, must deal with that detail necessary to interact with a particular implementation. The requester can think in terms of using a Web service. In that sense, Web service technology is virtualization technology for making use of services, but an implementer of a service can use the technology he is acquainted with to build the service implementation.
One valuable aspect of the services model is that you can create new services from existing ones without leaving the service paradigm. A technology called choreography facilitates the composition and orchestration of the execution of existing services to create more powerful ones (see Chapter 14, “Modeling Business Processes: BPEL”). Choreographies support the idea of programming in the large (see [Ley 2004], [Ley 1997], [Wied 1992]), which fosters the creation of new functionality, in particular by non-IT personnel.
Using the terminology introduced earlier, a business process corresponds to the choreography of services designed to address a high-level business problem. The choreography specifies which services to use, in which order, and under which conditions. Services within the choreography correspond to an activity, some kind of well-identified step in the process. You can define the choreography as a service and incorporate it as an activity within another choreography, again, providing functions from the business domain of a company. Because the collection of services and the choreography that uses them solve a business problem, this collection is sometimes called a solution [BaS04]. Without examining the detail, note that a solution typically contains additional artifacts, such as user interfaces or more complex rules that the choreography uses (see Figure 1-3).
Choreographies use services and render the results as services again. Therefore, one choreography can serve as a base for other choreographies, together with services that have been implemented based on other technologies. Thus, choreography provides a powerful technology for recursive composition of services.
SOA is a specific architectural style that is concerned with loose coupling and dynamic binding between services. Some critically important factors at the heart of SOA are necessary to make it work effectively.
The basic principles that underpin SOA are illustrated in Figure 1-4. First, it is necessary to provide an abstract definition of the service, including the details that allow anyone who wants to use the service to bind to it in the appropriate way. Second, those people who are the providers of services need to publish details of their services so that those who want to use them can understand more precisely what they do and can obtain the information necessary to connect to use them. Third, those who require services need to have some way to find what services are available that meet their needs. Also, to make this bind/publish/find approach work well, standards must be defined to govern what and how to publish, how to find information, and the specific details about how to bind to the service. Web services technology is at the heart of addressing these questions and is the subject of this book. It also forms a basis for the notion of a service bus (infrastructure) that supports SOA.
The provider of a service describes its semantics, that is, the functions it supports in addition to its operational characteristics and required details about how to access the service. This descriptive information (or metadata) about the service is published to a directory or registry. A requester uses a discovery facility that is associated with the registry to find services that he is interested in and selects the one that is required. Based on the access information published about the service, the requester can bind to the selected service.
Descriptive information about a service, as indicated earlier and described in detail later, is based on WSDL and policy. At one end of the spectrum of service publishing and discovery is a separate registry or directory, such as UDDI, which holds WSDL and policy information about registered service and additional information such as business data about the service provider. This information is queried for services that match the requester’s criteria. At the other end of the spectrum, more rudimentary mechanisms can provide access to and retrieval of metadata about a service, the existence of which is known to the requester perhaps by private means. However, after a service has been chosen, the information regarding how to access the service is used next to actually bind to it and send requests to it.
Figure 1-5 illustrates the various steps and artifacts that dynamically discover and bind a service. First, the requester describes the service needed via functions required and nonfunctional properties. Based on this input, the discovery facility produces a list of candidate services that satisfy those needs. From this candidate list, the requester chooses a service. The selection facility shown for that purpose can be as simple as performing a random selection or as sophisticated as considering additional criteria such as cost of use. After the requester has chosen the service, he determines its address and binding details, such as which protocol to use and which message format is required. This information is either already returned within the candidate list details or is retrieved in a separate step.
This processing looks cumbersome. However, middleware called a service bus (see [Voll 2004], for example) can simplify the process and make it more transparent. As illustrated in Figure 1-6, the requester simply passes to the service bus the description of the service and the data that the request message expects to be sent. Next, the requester gets the response to his declarative request. Based on this request, all services that qualify under the service description are undistinguishable for the requester, and the bus can unilaterally select from all candidates. The bus virtualizes these candidate services from the requester’s perspective. For this purpose, the bus implements the shaded area in Figure 1-6. In other words, the bus takes the service description and uses a discovery facility to find the list of qualifying services, selects one of them, retrieves the necessary binding information, binds the service accordingly, transforms the input data from the requester properly, sends the corresponding request message to the service, receives the response, and passes this response in the proper format to the requester. A service bus provides a significantly improved ease-of-use experience for a Web service–based implementation of SOA.
The functionality that a service bus provides goes beyond virtualizing application functionality. Not only can application functions be described via WSDL, but also the usage of resources such as processing power (CPUs) or storage (disks) can be considered as services thus being described via WSDL. Thus, a requester might describe his need for processing power and storage to the bus, and the bus will make this available. Of course, this requires much more sophistication, including scheduling features and extensions of the Web service model. Nevertheless, the service bus is a major enabling technology for a distributed computing environment called Grid (see [Fost 2004], [Czaj 2004]). You can think of it as service-oriented middleware.
Note that CORBA already had some aspects of the SOA in it based on its Trader services. However, from an overall SOA perspective, these trader services were incomplete. Often, they were not implemented, and they certainly weren’t universal in the sense of being platform neutral.
Web service technology is a base for implementing SOA, and the service bus is the centerpiece of this implementation. Thus, we want to sketch the high-level architecture of a service bus.
Figure 1-7 depicts the high-level architecture of the service bus as a stack of SOA capabilities. The bottom layer presents its capabilities to cope with various transport protocols to communicate between a service and a requester. The messaging layer on top of the transport layer enables the bus to deal with messages, both XML and non-XML. The latter is important, for example, if a requester and the service needed reside in the same J2EE application server and the bus can simply transport the data in its Java rendering, avoiding unnecessary transformations. The next layer of the bus facilitates and deals with the description of services in terms of functions supported, quality of services of these functions, and supported binding mechanisms. The actual quality of services that the bus enforces based on appropriate parameterization via polices resides in the layer that follows. This layer copes with security aspects such as message integrity, confidentiality, and nonrepudiation, but also with reliable transport of messages and various kinds of transactions. The top layer represents the various kinds of virtual components that Web services represent. This layer has atomic services that are not composed as far as a requester’s experience with the service is concerned. Composed services that the service bus inherently supports are choreographies and societies of services that cooperate following an agreement protocol to decide on the success of the cooperation at the end of the cooperation. Finally, another layer provides features for discovery of services and their descriptions and to agree on a mode of interaction between a requester and a service.
Chapter 3 revisits this topic and describes how various specifications fit into this SOA stack, with special focus on Web service specifications.
This chapter covered two major drivers that foster SOAs: an ever-increasing number of collaborations between enterprises that result from focusing on core competencies and enhancing agility, and the pressing need to solve the integration problem by loosening the coupling between functional components. This chapter explored the concept of a service as an evolution of software component technology and discussed the impact of services on application structures. It also presented the principles of SOA and introduced a framework of an environment that supports SOA applications.