The notion of service-oriented design goes back to the early 1990s. Service orientation has driven the 'intelligent network services' of the telecommunications domain. Telecommunications services such as free-phone (e.g., 800 services) and credit-card billing are built on top of complex distributed systems and require the cooperation of large numbers of computers, databases, peripherals, and networks (Margaria and Steffen, 2006).

In some sense, services are just like components: a system is made up of a collection of communicating services. Most of the important characteristics of services as listed in Table 19.1 resemble well-known characteristics of 'ordinary' components. If well-designed, ordinary components are also loosely coupled (this is one of the design criteria discussed in Chapter 12), adhere to a contract (often phrased in terms of pre- and post-conditions), hide their logic (information hiding), and so on. Yet, the characteristics of services differ subtly from those of software components, as discussed below.

Services can be discovered Services are discovered dynamically. This characteristic has repercussions for many of the other characteristics and makes services distinctly different from the components in a component-based system.

Service discovery means that, given a description of what the service is supposed to do (the contract), a dynamic search is done for candidate services that are capable of fulfilling that contract. This process is depicted in Figure 19.1. One service, the service requestor, sends a lookup request for another service to a service registry. If a suitable candidate service is found, its details are returned to the service requestor, which can then be bound to that candidate service, the service provider. Of course, the candidate service first has to register itself by publishing information in the registry. The registry thus acts like a phone directory.

Figure 19.1. Service discovery and communication

Consider for example our library system. At the highest level, we might distinguish services that deal with membership administration, catalog administration, and a news service. The latter is intended to provide a window on the surrounding world to the community of library users. It may link to relevant government regulations, healthcare institutes, and so on. The news service may consist of a number of smaller, more specialized services, the invocation of which depends on the user query. It may invoke a service provided by the local hospital if the query concerns healthcare, a service provided by local government if the query concerns government regulations, or a Google-like service.

The suitability of a service for a given service consumer request depends on the contract it offers. The service consumer may also take other considerations into account when choosing a particular service. For instance, depending on demand load, complexity of the question, and other parameters, a service at a particular location may be selected. The dynamism of service orientation thus offers a way of optimizing use of computer resources.

Dynamic discovery can also be used to increase the robustness and fault tolerance of applications. In our news service example, the quality of answers to news requests may not be known in advance. So a query to one news service provider may yield an answer which is not considered adequate by the service requestor. The latter may then dynamically try another provider. The same can be done if a given news service provider fails to return an answer within a certain time frame. The result is a more robust, more fault-tolerant, service assembly.

Services can be composed to form larger services In our library system, services invoke other services to deal with part of their service offering. Viewed the other way round, these smaller services are composed to form larger services. Conceptually, this is not different from the way small components are building blocks for larger components in CBSE.

Services adhere to a contract If the query concerns healthcare, we may have other options besides the local hospital, such as health insurance companies and local drugstores. The services of insurance companies may require membership. The healthcare service may be slow and the information returned very reliable. The drugstore service may be fast but the information returned somewhat less reliable. Figure 19.2 shows schematically how a healthcare query might be handled. Four candidate services have registered themselves in the registry: Hospital, InsuranceA, InsuranceB and Drugstore, together with their characteristics with respect to cost, speed, and reliability of information. If the healthcare inquiry service asks for a service which is both free and reliable, Hospital is selected, the link is made, and the query is executed.^[34]

Figure 19.2. Example service discovery and communication

The input of the request to the registry should contain everything that is needed to do the search and return a satisfactory answer. In an ordinary component-based system, the invocation of a component contains all the information the called component needs to do its job but there is often a lot of tacit information shared between components. This tacit information is known to the designer, but is not explicitly encoded. It is shared knowledge between the components, but nowhere stated explicitly. Typically, this involves things such as:

This information is not tacitly shared in a service-oriented system. Platform characteristics need not be the same for all components in a service-oriented setting. Web services (see Section 19.3) and the associated open standards allow for a smooth bridging of platform differences. Other types of information have to be made explicit, though. Both components and services work according to a contract. In the case of components, this contract lists functional obligations. For services, the contract lists both functional and quality obligations.

If it is required that a service has certain performance characteristics, this has to be specified in the service request. And, conversely, candidate services have to publish their performance characteristics. During the search, performance requirements can then be compared against the performance offerings of candidate services and a suitable candidate can be chosen.

Not all quality information, however, is easy to specify. How for instance should the information reliability of the news services in our library example be specified? Is a choice between two options (reliable and notsoreliable) sufficient? And what do these qualifications mean?

For all types of quality information, the question remains how the service requestor should assure itself of the promised characteristics. A health insurance company may desire to present itself as a reliable source of information. But how can the news service know or ascertain that the promised information reliability level will indeed be reached? We may want to have stronger evidence than the mere promise of the service provider.

One possible way to handle this is to have an independent, trusted intermediary that collects evidence of the quality characteristics of a service. For example, if some party has been using the service and experienced certain quality levels, these can be reported to the trusted intermediary and can be used to update the available quality information of that service. This process is not that different from similar processes that have been proposed for collecting and disseminating quality information for commercial off-the-shelf (COTS) components. In the case of services, we need to explicitly model this information in such a way that it can be dynamically used by other services.

Collectively, the set of quality characteristics promised or required by a service is termed Quality of Service (QoS). This term is used in contexts such as telephony, networking, and streaming media to denote performance requirements one party asks for and another party has to comply with. A related term is Service Level Agreement (SLA). This notion also has been around for many years, most notably in deployment contexts, where the SLA describes certain levels of availability, throughput, and so on, that parties agree on. Both terms are used in the context of services to denote the quality part of a service contract.

A service may offer more than one QoS level. For instance, a voice-recognition service may offer a fast but somewhat noisy result, or a much better result at a slower speed. It is then up to the service consumer to choose between these QoS levels.

Services are loosely coupled Because of the dynamic discoverability, we cannot tacitly assume anything from a service found. Everything two interacting services need to know from each other has to be passed explicitly. A natural consequence then is that we aim for a situation in which they need as little information as possible. So we want services to be loosely coupled. This is a well-known decomposition criterion in every software design method. But in the realm of services, loose coupling also means loose coupling at the business level. A healthcare inquiry from the news service of the library system may be answered by a service provider hitherto completely unknown.

Services are stateless Since the selection of a service is done dynamically, potentially at least a different candidate may be selected each time a certain service is needed. At some point in time, service InsuranceA from health insurance company CompA might be selected, while next time service Hospital from the City Hospital might be the preferred option. The coupling between the library on one side and CompA and City Hospital on the other side is thus very loose. A consequence of this type of loose coupling is that services have to be stateless.

Services are autonomous; services hide their logic A service cannot retain information that is saved for a future invocation. The next invocation may well be to another service with the same functionality, but from a different provider.

In our library example, the news service has its own rules which determine how its process is structured. Its logic does not depend on other services of the library, such as those that have to do with membership administration or the catalog administration. This works two ways: the news service is autonomous and its internal logic is hidden.

Services are reusable A service models a business process. As such, a service is usually not very fine-grained. In our library example, one business process may have to do with the handling of fines, while another has to do with the complete administration of library items. Borrowing a book is not a business process and is not modeled as such in a separate service. Deciding on the proper granularity of services often raises much debate in service-oriented development. An important criterion is that services should be reusable.

Services use open standards In order that different companies can produce and use a variety of services, they communicate through open standards. When two applications cooperate through a proprietary standard, it may not be all that easy to change to another provider for either of them. If the provider of those applications does not disclose the way these applications interface, one is forced to change both. If the provider does disclose the interface, there might well not be a ready solution available, and a solution has to be developed that matches the particular interface. So the user organization in many cases is confronted with a package deal. This is known as vendor lock-in. Vendor lock-in does not occur if open standards are used. Any provider can decide to abide by those open standards, and thus enter the market. There are open standards for how services are described, how they communicate, how data is transferred between services, and so on. Some of the main open standards in use for service-oriented systems are discussed in Section 19.3.

Services facilitate interoperability A consequence of the use of open standards and the loose coupling between services is that interoperability is eased. In more classical approaches, the integration of, say, the news services provided by insurance companies and hospitals on the one hand, and a library information system on the other, poses challenges because of proprietary and incompatible data formats, platform differences, and so on. With services, these incompatibilities are partly hidden inside individual services, and partly subsumed by the open standards. Interoperability, within and across organizational boundaries, is thus made a lot easier.

The characteristics of services do not come about automatically. They have to be designed in. The service-oriented architecture (SOA), discussed in Section 19.2, promotes realization of those characteristics. Section 19.4 gives further guidelines for the design of services.

A system that is composed of a collection of services that send and receive messages has an architecture, like any other system. If no structure is imposed on the way the services are connected through message sending, a bowl of spaghetti results: a spaghetti-oriented architecture. But this is not what we usually mean by the acronym SOA.

In the world of services, the term SOA is often used to denote any system built out of services or one utilizing Web services. We, however, confine the term to standing for a specific architectural style that has become widely used (see Figure 19.3). It has two layers of services, called the business service layer and infrastructure service layer. The services in these layers communicate through a service bus. Finally, the coordination of services is done in the coordination layer.

In this architectural style, services do not send each other messages directly, which would result in the spaghetti style mentioned above. Rather, they do so via a service bus, an event-based messaging engine. This bus acts as an intermediary between services. Services send their messages to the bus, which in turn redirects them to the appropriate receiver of the message.

Figure 19.3. SOA architectural style

The service bus solves major complexity problems that often face application integration projects. This is also the area from which the service bus concept comes. A rather straightforward application integration effort consists of just putting a wrapper around existing legacy applications. These wrappers hide data formats and internal details and provide an XML-based Web interface instead. This is not a viable solution in the long run, though, because of platform differences between applications. To solve this type of integration problem, the notion of an enterprise service bus (ESB) was developed.

A similar type of bus is used in a service-oriented architecture . As well as routing messages, the service bus usually also takes care of a number of other issues that services have to deal with, such as:

Conceptually, we have depicted the service bus as a centralized entity. It may be implemented as such, in a broker or hub style. It may also be implemented in a decentralized way, in smart endpoints of message exchanges.

The business service layer contains services that represent distinct pieces of business logic. The infrastructure service layer contains services that represent supporting activities, such as the storing and shipping of data.

Finally, the interaction between services has to be coordinated. For example, a sequence of services may have to be invoked in a certain order. Or, if a sequence of services is to be invoked to form one coherent transaction, we may want to ensure that the whole chain of services has been executed. If a failure is discovered somewhere in the chain, services that have already been executed have to be undone. To model service interaction, special languages have been developed that express these types of coordination issues. These coordination languages generally grew out of languages for workflow management.

Coordination languages for services come in two flavors: orchestration and choreography. In orchestration, there is a central place where coordination takes place. In choreography, there is no such central place: coordination is distributed. This resembles an orchestra with its conductor and a ballet performance, respectively. In practice, orchestration languages are used more often than choreography languages.

Logically, the coordination layer addresses services in the business and infrastructure service layer. Physically, this linkage is via the services bus, since all message exchanges go via this mediation component.

Web services are an implementation way of realizing services. Web services use a standardized way to integrate services across the Internet. The main open standards used to realize Web services are:

In the context of Web services, XML is used to structure messages. In particular, SOAP messages, WSDL documents, and UDDI descriptions are all encoded as XML documents.

These open standards achieve interoperability between two services. What they do not achieve is integration of a collection of services. If a collection of services is to be integrated into a service-oriented system, there are certain global rules or constraints that such a conglomerate has to obey. For instance, if a complex insurance service consists of several smaller services, we may require that a transaction is completed entirely. If this cannot be achieved, parts that have been realized have to be undone. Also, we may wish to be able to roll back to earlier points in the process. This requires a language to express the flow of process steps. One such language is the Business Process Execution Language for Web Services (BPEL4WS). This type of language is used at the coordination layer of the SOA (Figure 19.3).

Figure 19.4 gives an example of how we may combine WSDL and BPEL4WS in a typical application. WSDL is used to describe individual services. These services are implemented in some language, say Java. The flow of process steps is 'programmed' in BPEL4WS. Each individual process step refers to a service in WSDL. This can be applied recursively. So the complete composition as given in Figure 19.4 may be referred to as a service in some other WSDL description, and used as a single entity in another composition.

When two components (services, applications, and so on) communicate over a network, they do so via a protocol, such as FTP for file transfer and SMTP for mail transfer. These protocols provide containers of information, such as 'file' and 'mailbox', as well as operations to put information into those containers and get information out of them. In a similar way, Web services realize connectivity between network nodes. A SOAP message definition also provides for a container, and ways for the message sender to put the message into the container and for the message receiver to get the message out of the container. However, the SOAP user defines his own message format in each SOAP definition. In that sense, SOAP is not a protocol, but a language to define new protocols. The same holds for WSDL and other Web services standards.

Figure 19.4. Coordination of Web services

The Web services open standards form a stack, known as the Web services stack; see Figure 19.5. At the lowest level of this stack, we encounter the familiar network protocols. At the next level, SOAP deals with the interaction between services. WSDL and UDDI reside at the next higher level. They concern the description and discovery of services. At the highest level, BPEL4WS is concerned with the composition of services. At all levels above the network layer, XML is used as the document-representation language.

There are many other, more specialized open standards related to Web services. WS-Security for example deals with the integrity and confidentiality of messages. It describes how to make SOAP messages secure. WS-ReliableMessaging deals with the reliable delivery of messages. WS-Policy allows for the description of policies of service providers and consumers, with respect to QoS, for example. Further information on these open standards can be found at the websites of OASIS and W3C, the two main consortia in the area of Web services.

Figure 19.5. The Web services stack

The most popular underlying technology platforms to realize Web services are J2EE and .NET. J2EE provides different types of component, such as Enterprise JavaBeans (EJBs) and servlets, to realize Web services. The main API for processing messages is JAX-RPC (Java API for XML-based RPC). In the .NET environment, Web services are represented by units of programming logic called Assemblies. An Assembly consists of one or more classes. The .NET class library provides classes for processing SOAP messages, WSDL definitions, and so on.

Extensible Markup Language (XML)

XML grew out of HTML, the language used to describe the format and layout of Web pages. HTML has a fixed set of elements that are used to describe Web pages. In XML, elements are not predefined. The user of XML can define his own vocabulary in an XML schema. The vocabulary defines the language used in a specific set of documents. Documents can be encoded in XML conforming to the schema.

For instance, in our library system, we may have a schema called library that defines the syntax of documents that describe library items. All items in the library can be encoded using this schema. A small example is given in Figure 19.6.

Figure 19.6. XML example

The first lines in the example tell us that XML version 1.0 is used, and the XML schema used is called library. The next lines have the familiar syntax of HTML, but the keywords used are different. These keywords are defined in the schema, in this case a Document Type Definition called library.dtd. The example describes one library item in the category Novel, and lists the title, author, and year of publication of that novel.

An XML schema defines one or more trees, nested categorizations of constructs. In the example of Figure 19.6, it is a very simple tree in which a libitem has three child nodes. XML provides a way to structure this type of hierarchical information. It is only about syntax. An XML document carries no semantics, though. Any XML document having a structure that conforms to the libitem schema will be accepted as a valid library item.

XML has evolved into more powerful languages that do allow for the inclusion of semantic information in documents. The main exponent of this is the Ontology Web Language (OWL). The semantic information included can be used in service discovery and mapping processes. Where XML is the basis for first-generation, syntax-based Web services, OWL is the basis for second-generation, semantics-based Web services.

XML is used to represent all kinds of data in Web services. Web services communicate by sending each other data formatted as XML documents. SOAP messages are XML documents, the entries in a UDDI are XML documents, and the service descriptions of WSDL are XML documents. XML documents are omnipresent in Web services. The flexibility of XML and its wide support in industry are a major factor in the success of Web services.

Often, items from different XML schema have to be combined in one document. Since names in a single XML document have to be unique, each vocabulary is given its own namespace, and names are then prefixed with a reference to the namespace where that name is defined. For example, soap:binding refers to binding as defined in the WSDL namespace for SOAP bindings (see Figure 19.7). It is customary to use the prefix ths: to refer to the current document ('this namespace').

Business Process Execution Language for Web Services (BPEL4WS)

BPEL4WS is a language for programming-in-the-large. It has variables, if-then-else statements, while statements, and so on. But the elementary objects are not numbers and strings, but process steps. A BPEL4WS 'program' describes the workflow of a business process.

The three main parts of a BPEL4WS process definition are (see also Figure 19.8):

• partnerLinks, which define dependencies between services

• variables, which store information to be kept between service invocations

• a workflow model, which expresses the sequence of process steps to be executed.

A process has a number of partner services that participate in the process. For the news services, possible partner services are HealthcareInformationService (see Figure 19.7) and HospitalInformationService. For each such partner service, the BPEL4WS process definition provides a partnerLinkType element that identifies the corresponding portType elements from the WSDL definition.

Figure 19.8. BPEL4WS skeleton process definition

Figure 19.9. BPEL4WS partnerLinks

Figure 19.9 gives an example that defines two partnerlinkTypes: RequestLT and HospitalRequestLT. Two roles are distinguished for these links: myRole and partnerRole. myRole is used when the service is invoked by a client service, i.e. the service acts as a provider. partnerRole is used when the service invokes another service. The partnerRole then identifies the partner service that is invoked. A service can both be invoked and invoke other services in the same partnerLink. In that case, both roles occur in the same partnerLink.

Information on partner links is also embedded in the WSDL definition of services. It resembles the information given in Figure 19.9.

The variables part of a BPEL4WS process definition is used to store state information related to the workflow. For example, the news service may store the healthcare information received from, say, the drugstore service, examine its contents and invoke the hospital service if the information received is of low quality. Each variable has a type, which has to be given upon definition of that variable.

In a real news service interaction, there will be many requests for information, and many receipts, that co-exist, i.e. there will be many instances of the news service. Within a specific interaction, there thus has to be a way of connecting the right reply to a given request. This is similar to ordinary business transactions, where many orders may be 'alive' concurrently. It is customary to identify particular orders by a specific token, say a purchase order number, which is used during the whole workflow. It is used when the order is shipped, when it is being paid, when enquiries are made, and so on. In service interactions, similar tokens are used as part of the messages being exchanged. Messages are correlated to relate operations within a service instance, for example to connect a news reply to the corresponding request.

Finally, the sequence part of a BPEL4WS process definition gives the sequential order in which process steps are to be executed. BPEL4WS offers a number of constructs to express workflow logic in the process definition. Figure 19.10 gives a short example. The workflow starts with a receive construct, which means that the process waits for a matching message to arrive. Then, the DrugstoreHealthcareInformation service is invoked. This delivers an OutputRequest which is inspected in a BPEL4WS if statement. If the Quality element of the result is large enough, we're done. Otherwise, the HospitalHealthcareInformation service is invoked. Finally, the reply construct sends a result message as an answer to the receive construct. This pair constitutes the request–response operation that was mentioned in the WSDL portType of the healthcare information service.

BPEL4WS is an orchestration language. There is central control (just as the conductor of an orchestra is in control). In a choreography language, such as the Web Services Choreography Description Language (WS-CDL), no such central control exists. In a WS-CDL, each participant remains autonomous. A WS-CDL description defines a number of interactions (message exchanges) together with their ordering constraints. In particular, WS-CDL has no notion of global variables. Variables may be shared between participants in an interaction, so that state information can still be retained. Many other aspects of BPEL4WS show up in WS-CDL too, though sometimes under a different name. WS-CDL is not executable, while BPEL4WS is.

Figure 19.10. Outline BPEL4WS workflow

Services, and compositions of services, need to be engineered too. This process is known as service-oriented engineering (SOE) or service-oriented software engineering (SOSE). At a global level, the SOSE life cycle is not different from the ordinary software life cycle, and consists of phases such as analysis, architecture, design, testing, construction. Each of the SOSE phases however is subtly different from its non-service-oriented counterpart. Below, we discuss the analysis, architecture, and design phases, since this is where the service-specific elements are most visible. An overview of these SOSE phases is given in Table 19.2. The process, of course, is not linear but iterative, both across and within phases.

Sometimes, a distinction is made between organizations that develop individual services and organizations that develop applications built out of a collection of available services. This is similar to software product-line development organizations, where a distinction is made between the component development organization and the application development organization. The latter develops the overall architecture and builds products using components developed by the component organization.

A service, be it simple or composite, models a business process. The first step in the analysis phase scopes the service: which business process will be handled by the service, what is its start and end, who are the participants, what is the input and output of the process? This first step determines the boundaries for the steps to follow.

Especially for larger business processes, there will be existing applications that automate part of the process. These may be (legacy) applications from within the organization, or components and services that may be acquired from elsewhere. The gap analysis step determines which existing elements can be reused in the realization of this service. The gap analysis is similar to a COTS selection process as discussed in Section 9.1.5.

The architecture phase starts with a decomposition of the process into its constituent process steps and their interactions. Workflow modeling notations and languages can be used for this purpose. These resemble the process modeling notations discussed in Section 3.7. Usage scenarios are devised and used to manually test the process flow developed and identify any missing steps. These usage scenarios are also used to group services into composite ones.

Next, a particular instance of the SOA, as discussed in Section 19.2, is chosen. The service layers are determined, the Web services standards to be used are determined, as well as rules for how they are applied (such as which namespaces are used and where they are positioned).

Finally, the design phase concerns the design of individual services and their interfaces, as well as the detailed design of the service-oriented business process. In terms of the SOA architectural style, this concerns the detailed design of the service layers and the coordination layer, respectively. At the level of Web services, the former concerns the SOAP/WSDL level, while the latter concerns the BPEL4WS level.

Though SOSE and the more familiar software engineering approaches look similar, there are important differences for which no adequate SOSE solution has been found yet (see (Papazoglou et al., 2006) and (Tsai et al., 2007)):

Services have a long history in the world of telephony. Many of the achievements made there are currently being reinvented and translated to the general world of software engineering.

The most important characteristic that distinguishes services from ordinary software components is that services can be dynamically discovered, based on a description of what the service is supposed to accomplish. This description contains both functional and quality information. Service providers publish their service descriptions in a registry, after which service requestors can search the registry for candidate services.

The efforts to realize service orientation so far have been largely directed at the syntax level: how to program services, how to hook them together, and so on. The semantic level of domain-specific libraries of services has hardly been touched yet. This is similar to what happened in the area of reuse and components. Efforts to add a level of semantics are underway. (Berners-Lee et al., 2001) describe an extension of the current Web in which information has a meaning. In this semantic Web, services also carry semantics. These semantics can be used in service discovery, composition, and so on. New standards are being developed in which this semantic information is embedded. XML is the basis for the first generation of Web services open standards. The Ontology Web Language (OWL) is the basis for the second, semantics-oriented, generation of standards.

The widely used service-oriented architecture (SOA) consists of a number of business and infrastructure services that communicate via a message engine, the service bus, and a coordination layer that handles the workflow of and interaction between the services.

The realization of services calls for specific software engineering techniques, service-oriented software engineering (SOSE). The main phases of the life cycle for developing services are the same as those for developing components. There are specific elements though, especially in the analysis and design phases, where the alignment between business aspects and technical solutions is stressed. There are also many open issues where it comes to the engineering of services.

(Erl, 2005) is a good textbook on service orientation. It makes a clear distinction between the conceptual issues and implementation issues incurred by Web services. (Papazoglou, 2008) is a very comprehensive textbook on Web services. (Turner et al., 2003) describe the software-as-a-service (SaaS) concept. (CACM, 2003) and (CACM, 2006) are special journal issues that deal with service orientation. There is an annual International Conference on Service-Oriented Computing (ICSOC), in which research on service orientation is reported. One of the striking characteristics of the research reported there is that it seems disconnected from much of mainstream software engineering research.

Two important consortia in the area of open standards are the Organization for the Advancement of Structured Information Standards (OASIS) and the World Wide Web Consortium (W3C). Each has technical committees that endorse standards. W3C is known for its work on XML, SOAP, WSDL, and many other Web-related languages.

More information about XML can be found at www.w3.org/TR/XML. For OWL, see www.w3.org/2004/OWL. For SOAP 1.1, see www.w3.org/TR/soap. We used WSDL version 1.1 in the example in Section 19.3.3; see the W3C report at www.w3.org/TR/wsdl. More information about UDDI can be found at http://uddi.xml.org, hosted by OASIS. We used BPEL4WS version 1.1 in Section 19.3.5; see www-128.ibm.com/developerworks/library/specification/ws-bpel. BPEL4WS is developed by a consortium consisting of BEA Systems, IBM, and Microsoft, among others. It is being standardized as Web Services Business Process Execution Language (WSBPEL) by OASIS, see www.oasis-open.org. The Web Services Choreography Language (WS-CDL) is being developed by W3C; see www.w3.org/TR/ws-cdl-10. Peltz (2003) discusses the difference between orchestration and choreography. (Curbera et al., 2002) provide an introduction to SOAP, WSDL, and UDDI. The research origins of middleware, including Web service middleware such as SOAP and WSDL, is discussed in (Emmerich et al., 2007).

The platform technologies underlying Web services change quickly. Good starting points are http://java.sun.com/Webservices for Java developments and http://msdn2.microsoft.com/en-us/Webservices for .NET developments.

The SOSE life cycle discussed in Section 19.4 is loosely based on (Erl, 2005) and (Papazoglou and van den Heuvel, 2006). SOSE challenges are discussed in (Papazoglou et al., 2006) and (Tsai et al., 2007).