In service orientation, a system is made up of services that are discovered dynamically. The use of services gives rise to a typical architecture: the Service-Oriented Architecture (SOA). The usual imlplementation of a service-oriented system is via Web services that make heavy use of open standards. Service orientation marks a shift from producing software to using software.

Services are composed of 3 basic ingredients:

Services which often consist of additional services.

Service Descriptions which give the details of the services.

Service Communication Communications which are needed to execute proper functioning of the services.

Service orientation grew out of Component-Based Software Engineering (CBSE), and heavily uses the Web. A service resembles a component in Component Based Software Engineering, resembles a CORBA or .NET description of a component, and service communication resembles Remote Procedure Call. Though Services, Service Descriptions, and Service Communication resemble well-know concepts, they differ slightly from these concepts. When these minor differences are taken together we end up with Service-Orientation being markedly different from the Component-Based approach.

If one component makes use of another component in a component-based system, the selection of that component is made at design time. The caller knows all the details of the callee that it needs to know: name, parameters and quaility. The composition can be tested before it is put into operation. There often are a lot of tacit dependencies between the two components that must be satisfied if the components are to work together. An example of a desktop application would be the requirement that both components run on the same platform.

This is not true if services are used. In a service-oriented system, one service may request the use of another service, but the selection is made dynamically. In a voice-recognition application, for example, we may need a service to remove noise from a recorded message. There may be several candidate services that promise to deliver the required functionality. Differences between the service candidates might include noise removal quality, time required to perform the indicated function, and so on. The services themselves, are likely to have been written in different languages (C & Java for example), The services could even be on different platforms. An Internet File Transfer program written in Microsoft Visual C++ might request services provided by a Linux server, for example. When the voice recognition program requests the services of a noise reduction application, the selection is performed dynamically, and potentially different noise reduction applications could be chosen at different times. This last situation underscores the major difference between service-oriented and component-based technologies.

The use of services gives rise to a Service Oriented Architecture (SOA) in which services interact through a messaging engine, the Service Bus. The coordination of services is handled in the Dedicated Coordination Layer.

The usual implementation of a service-oriented system is via Web services. Often, Web services and service orientation are viewed as synonyms. However, Web services are an Implemenation which means that it utilizes Service-Oriented systems. Web services make use of a number of open standards, such as XML, SOAP, and others. These standards describe only the syntax level. For example, SOAP is used to describe how services exchange messages. But it only describes the syntax of the messages, not the semantics. In order to deal with this situation, the second-generation Web, the Semantic Web is currently under development. In the Semantic Web, the services will also carry semantics. This means information will also carry a meaning. Second-generation Web services will exploit these semantics.

Service orientation is more than just a technology. Traditional software engineering approaches are geared towards the production of software. Organizations using these traditional approaches build complete software solutions or individual components. Their customers buy these solutions and then, usually own them. They have to install the software on their machines, and receive regular patches, or buy the next version or release.

This is not the case in a service-oriented approach. Service orientation marks a shift from producing software to using software. In service orientation, an organization need not host the software, need not keep track of versions and releases, need not ensure that the software evolves with the wishes and requests of its users, and so on. The software is Somewhere and is deployed on an as needed basis. To emphasize this shift in perspective, service-orientation is sometimes referred to as Software as a Service (SaaS).

Service Descriptions And Service Communication

The concept of service-oriented design originated in the early 1990s. Service orientation has driven the Intelligent Network Services of the telecommunications domain. Telecommunications services such as free-phone and credit card billings are built on top of complex distributed systems and require the cooperation of large numbers of computers, databases, peripherals, and networks.

In one sense, services are just like components: a service is made up of a collection of communication services. Most of the important characteristics are listed below:

Figure SD-1: Main Service Characteritics

Many of these characteristics resemble well-known characteristics of ordinary components. A well-designed, ordinary component will be loosely coupled, adhere to a contract, hide their logic, etc. Likewise the characteristics of services only differ slightly from those of ordinary components.

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 component based system.

Service discovery means that, given a description of what the system is supposed to do by the Contract, a dynamic search is done for candidates that are capable of fulfilling the contract. This process is depicted in Figure SD-2 below:

Figure SD-2: Service Discovery And Communication

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 be bound to the Service Provider. Of course, the candidate service first has to register itself by publishing information in the Service Registry. The registry is analogous to a phone directory.

Consider, for example, a library system. At the highest level, services deal with membership administration, catalog administration, and a news service. The latter is intended to provide a window of the surrounding world to the community of library users. The library system might link to government agencies, healthcare institutions, and so on. The news service could in turn consist of a number of smaller, more specialized services. In order to access these services, all that is required is a user inquiry. If the query regards healthcare, the healthcare service could be instantiated, if the query involves government regulations, the government service could be initiated.

The suitability of a service for a given 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 several factors, such as demand load, complexity of the question, and other parameters, a service at a particular location may be selected. The dynamic character of service orientation thus offers a way of optimizing the use of computer resources.

Dynamic discovery can also be used to increase the robustness of fault tolerance of applications. In the news service example above, for 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 service requestor 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 system.

Services can be composed to form larger services. In the library system described above, services invoke other services to deal with part of their service offering. From another perspective, it appears as though the smaller services are composed to form larger services. Conceptually, then, this is not far different from the way small components are building blocks for larger components in Component Based Software Engineering.

Services adhere to a contract. If the query concerns healthcare, there may be other options besides the hospital, such as health insurance companies or a drugstore chain. The services of the insurance companies may require a membership. The healthcare service might be slow, but the information is very reliable. On the other hand, the drugstore returns information very quickly, but the information returned could be a little more suspect. The following diagram illustrates this scenario:

Figure SD-3: Example of Service Discovery and Communication

Four candidate services have registered themselves in the registry: Hospital, Insurance Company A, Insurance Company B,, and the Drugstore Chain. Their corresponding characteristics have also been registered in the registry. If a request is made that is both free & reliable, the Hospital is selected, the link is made, the query is given and the response is returned to the requestor.

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 also may be tacit information shared by the components. This tacit information is known to the designer, but is not explicitly encoded. It is shared between the components, but nowhere is it stated expliciltly. Typically, tacit information may consist of:

Platform Characteristics: Items such as Operating Systems, Database Version Number, and Network Protocols

Quality Information: Charactersistics such as performance, reliability and availability.

Design Decisions: General knowledge of the domain may leave some items undefined, i.e. tax filing deadlines, membership renewal dates, etc.)

This information is not tacitly shared in a service-oriented system. Platform characteristics need not all be the same for all components in a service-oriented setting. Web services and the associated open standards allow for a smooth bridging of platform differences. However, other types of information needs to be made explicit. 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.

However, not all quality information is easy to specify. For all types of quality information, the question remains how the service requestor should assure itself of the promised characteristics. One way to handle the reliability of promised characteristics is to employ an independent, trusted intermediary that collects evidence of the quality characteristics of a service. For example, if some party has been using a service and has experience certain quality levels, these can be reported to the trusted intermediary, so the quality information about the service can be updated. This process is not entirely different from similar processes that collect and disseminate Commercial-Off-The-Shelf component quality information. In the case of services, this process needs to explicitly model the 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 attributes requested by one service or delivered by another. A related term is Service Level Agreement (SLA). This concept has been around for many years, most notably in deploment contexts, where the Service Level Agreement describes certain levels of availability, throughput, and so on, agreed by all involved parties. 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 level of Quality of Service. For example, a voice recognition service may offer a fast but somewhat noisy result, or a much better result, but at a slower speed. It is then up to the consumer to choose between these QoS levels.

Services are Loosely Coupled because of the dynamic discoverability. We cannot tacitly assume anything from a found service. Everything two interacting services need to know must be passed explicitly. A natural consequence then is that we aim for a situation in which the services need as little information as possible. This makes loosely coupled services desirable. This is a well-known decomposition criterion in every software method. In the realm of services, loose coupling also means loose coupling at the business level. A healthcare inquiry from a news service may be answered by a service provider, previously unknown to the requestor.

Services are stateless: Since the selection of a service is done dynamically, potentially a different candidate may be selected each time a service is requested. In order for this to occur, services must be loosely coupled. A consequence of this loose coupling is that services are stateless.

Services are autonomous: A service cannot retain information that will be saved for a future invocation. The next invocation may well be to another service with the same functionality, but from a different provider.

Services hide their logic: A service has its own rules which determine how its process is structured. Its logic does not depend on the functioning of other services.

Services are reusable: Services may be used many times by the same provider or by many different providers.

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 probably isn't very easy for either of them to choose a different provider. If the provider does not disclose the way applications interface, a ready solution to meet the application's interface likely does not exist, and will have to be developed. This is known as Vendor-Lock-In. Vendor-Lock-In does not occur in the case of open standards. Any provider can abide by these open standards, and thus enter the market. There are open standards for how services are described, how they communicate, and how data is transferred between services.

Services facilitate interoperability: A consequence of the use of open and the loose coupling between services is that interoperability is eased. In more classical approaches, the integration of proprietary or incompatible data formats or platforms, proved to be a significant challenge. With services, however, most of these incompatibilities are hidden inside the individual services and significantly moderated due to the use open standards. Interoperability, within and across organizational boundaries, is thus made much easier.

The characteristics of services do not come about automatically. They must be designed in. The Service Oriented Architecture (SOA) promotes realization of those characteristics.

The Service Oriented Architecture

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, an incomprehensible quagmire can occur. In the world of services, the term Service Oriented Architecture is often used to denote any system built out of services or one utilizing Web services. Typically, a Service Oriented Architecture will be composed with two layers of services. The two layers of services are the Business Service Layer and the Infrastructure Service Layer. The services in these layers communicate through a Service Bus. Finally, the coordination of services in done in the Coordination Layer.

In this architectural style, services do not send each other messages directly, which would result in the quagmire mentioned above. Rather, they communicate with each other through the Service Bus, which is an event-based messaging engine. The 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.

The service bus also solves major complexity problems that often face application integration projects. This is also the area from which the concept of the service bus was first conceived. 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. Unfortunately, this is not a viable solution in the long run, beause of platform differences between applications. To solve this type of problem the 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 also usually takes care of a number of other issues that services have to deal with:

Mediation: Protocol translation, data transformations, dealing with platform differences, adaptations for services that use different protocols.

Quality of Service: Issues that have to do with security, data integrity and message reliability.

Management: Monitoring and logging service usage and gathering audit information.

Conceptually, the service bus is depicted 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: with 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 needs to be invoked to form one coherent transaction, it may be necessary to make sure 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 to express these types of coordination issues. These coordination languages 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 - the coordination is distributed. In practice, orchestration languages are used more often than choreography languages.

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

Web Services

Web Services are the culmination of effort in realizing networked services. Web services use a standardized way to integrate services across the Internet. The main open standards used to realize Web services are:

Extensible Markup Languages (XML): which has the primary goal of sharing data between applications.

Simple Object Access Protocol (SOAP): used to transfer messages between services.

Web Services Description Language (WSDL): used to describe available services.

Universal Description, Discovery, and Integration (UDDI): used to list the available services.

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 the 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. One possibility would be the requirement that if a sequence of services is unable to complete, then all realized services must be undone, as in the case of a financial transfer. More specifically would be the ability to roll back to an earlier point in the process. This requires a language that can 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 Service Oriented Architecture.

When two components (services, applications, and so on) communicate over a network, they do so via a protocol such as FTP, SMTP or HTTP. These protocols provide containers for information as well as operations to put information into and retrieve information from these containers. In a similar way, Web services realize connectivity between network nodes. A SOAP message definition also provides for a container, and ways for the sender to put messages into the container, and ways for the receiver to retrieve messages 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 rather a language to define protocols. The same holds for WSDL and other Web service standards.

The Web Services Open Standard form a Stack, known as the Web Services Stack, as illustrated in the diagram below:

Figure SA-1: Services Architecture / Web Service Stack

At the lowest level of this stack we encounter the familiar network protocols. At the next level up, SOAP (Simple Object Access Protocol) deals with the interaction between services. WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration) at the next higher level concern the description and discovery of services. At the highest level BPEL4WS (Business Process Execution Execution Language for Web Services) deals 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. WS-Security describes how to make SOAP messages secure. WS-ReliableMessaging deals with the delivery of reliable messages. WS-Policy allows for the description of policies of service providers and consumers, with respect to Quality of Service (QoS).

The most popular underlying technology platforms to realize Web Services are J2EE and .NET. J2EE provides different types of components such as Enterprise Java Beans and servlets to realize Web Services. The main API for processing messages is JAX-RPC (Java API for XML-based RPC). In the .NET programing 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 the processing of SOAP messages, WSDL, HTTP and FTP.

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.

Using the previous library description as an example, we could start by creating a schema called Library that defines the syntax of documents that describe library items. All items in the library can be encoded using the Library Schema. The following diagram illustrates an excerpt from the Schema:

<?xml version="1.0"?>
<!DOCTYPE Library SYSTEM "Library.dtd">

<Libitem Category="Novel">
	<Title>Using NetBeans for PHP Development</Title>
	<Author>Michel Catudel</Author>
	<Year>2012</Year>
</Libitem>

Figure XML-1: Some XML Sample Code

The first line notifies the processor that XML version 1.0 is used. The second line denotes this Schema is called Library. The next lines are similar to the format used in a standard HTML document, though the Keywords used are different. The keywords will be defined in 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 Figure XML-1 a very simple tree called Libitem has 3 child nodes. XML provides a way to structure this type of hierarchial information. It is only about Syntax. An XML documents carries no semantics. 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 allow the inclusion of semantic information in documents. The main exponent of this is 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 Web Services, Ontology Web Language is the basis for second generation, semantic driven 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, and the service descriptions of WSDL are also XML documents. XML documents are integral components of 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 into one document. Since names in single XML documents have to be unique, each vocabulary is given its own namespace, and the names are 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. Note, it is customary to use the prefix ths: when referring to the current document.

Simple Object Access Protocol (SOAP)

The Simple Object Access Protocol is the format for exchanging messages between Web Services. A SOAP message is sent from a SOAP Sender of one service to the SOAP Receiver of another service, possibly in conjuction with SOAP intermediaries of SOAP services. The message is contained in a SOAP Envelope. The envelope will have an optional header and mandatory body. The header contains information that identifies intermediaries and meta information about the SOAP message contained in the body. The body is the container for the message being transmitted.

A SOAP message is unidirectional. It defines a message from one service to another, not a Conversation between two services. If conversations issues such as Session State needs to be transferred, this will have to be done at the higher levels using WSDL and Business Process Execution Language for Web Services.

Web Services Description Language (WSDL)

Web Services Description Language is used to define individual Web Services. A short example of a Web Services Description Language is illustrated in the diagram below:

<definitions name="XNAGameTutorial"
  targetNamespace="http://Centurion2.com/XNA/XNA1/xna1.php">

  <message name="GetXNAGameInputDeviceInformation">
    <part name="body" element="xsd: InputDeviceInformationRequest"/>
  <message name="GetXNAGameOutputDeviceInformation">
    <part name="body" element="xsd: OutputDeviceInformationRequest"/>

  <portType name="XNAGameInformationPortType">
    <operation name="GetXNAGameInformation">
      <input message="ths:GetXNAGameInputDeviceInformation"/>
      <output message="ths:GetXNAGameOutputDeviceInformation"/>
    </operation>
  </portType>

  <binding name="XNAGameInformationSOAPBinding"
    type=ths:XNAGameInformationPortType">
    <soap:binding style="document" transport="ServicesURI"/>
    <operation name="GetXNAGameInformation">
      <input>
        <soap:body use = "literal"/>
      </input>
      <output>
        <soap:body use = "literal"/>
	</output>
    </operation>
  </binding>

  <service name="XNAGameInformationService">
    <port name="XNAGameInformationPort" 
      binding="ths:XNAGameInformationSoapBinding">
      <soap:address location="http://centurion2.com/XNA/XNA1/xna1.php">
    </port>
  </service>
</definitions>

Figure WSDL-1: WSDL Example Code

This example shows the 4 main parts of a Web Service definition:

Web Services Interface labeled portType. This is similar to a component interface as used in component-based software engineering.

A Service Interface has a name and a series of operations

Messages labeled message. When an operation is executed, messages can be executed.

Bindings define transport and format details for the operations and interface messasges.

A portType interface can have multiple bindings.

Services which describe the collection of endpoints for accessing a service.

An endpoint, or port, is a combination of a binding and a network address.

A service can have several ports of the same portType, but with different bindings.

The ports can have similar semantics but may have different physical properties.

The portTypes and Messages describe the abstract interface description, while Bindings and Services describe the concrete implementation part of the service description.

This example, of course, only scratches the surface of WSDL. WSDL has many other features necessary to decompose large service descriptions into smaller ones. WSDL also has the ability to describe faults and fault handlers. Also, WSDL builds on and uses additional open standards, such as those for building namespaces.

Universal Description, Discovery and Integration (UDDI)

The Universal Description, Discovery and Integration is a registry of service descriptions. A Universal Description, Discovery and Integration registry allows the publishing and search for services. The Universal Description, Discovery and Integration registry can be either public or private. The original vision behind the Universal Description, Discovery and Integration Registry was to have a huge public registry, similar to a telephone directory, in which every organization would publish its services. Reality is quite different. Many organizations do not want their services available outside the organization. Other organizations only want to make services available to partner organizations. The current version allows different levels of visibility for service descriptions.

Entries in a Universal Description, Discovery and Integration Registry have 3 parts:

Business Entity: Information about the organization that offers the services: name, description and a unique identifier.

BusinessServices: This section describes the actual services provided by the organization.

Must contain a unique identifier for each service.

BindingTemplates: Technical information on how to link services to obtain information.

Binding Templates may point to a website or the technical interface requirements.

Entries are stored in XML format. These entries are quite complex, and not easily readable. Some keys used to identify organizations are comprehensible, but mostly interpretation must be performed by SOAP messages.

Having different registries rather than one global registry poses some interesting challenges, similar to the challenges of distributed databases. For instance, keys and other information may have to be mapped between registries. The interaction between a collection of registries has to obey the rules of the organizations that manage the registries. The interface to such a set of UDDI registries is through inquiry systems obtaining the policies of the particular UDDI registry. Unfortunately, there is no standard as to how to encode information into a UDDI registry.

Business Process Execution Language for Web Services (BPEL4WS)

Business Process Execution Language for Web Services is a programming language for implementing services at an abstract level. It has variables, if-then-else constructs, while loops, and so on. But the elementary objects are not numbers and strings, but rather process steps. A Business Process Execution Language for Web Services program describes the workflow of a business process. The 3 main parts of a Business Process Execution Language for Web Services process definiton are:

Partner Links: define dependencies between services.

Variables: store information to be kept between service invocations.

Workflow Model: Expresses the sequence of process steps to be executed.

A process has a number of partner services that participate in the process. For each such partner service, the Business Process Execution Language for Web Services process definition provides a partnerLinkType element that identifies the corresponding portType elements from the WSDL definition. The following example shows an example Business Process Execution Language for Web Services referring to diagram SD-3 above:

<process name="NewsServiceProcess">
  <partnerLinks>
    <partnerLink name="HealthCareRequestLT"
      partnerLinkType="HealthCareInformationServicePortType"
      myRole="HealthcareInformationServiceProvider"/>
    <partnerLink name="HospitalRequestLT"
      partnerLinkType="HospitalInformationServicePortType"
      partnerRole="HospitalInformationServiceProvider"/>
  </partnerLinks>

  <variables>
      ...
  </variables>

  <sequence>
      ...
  </sequence>
</process>

Figure BPEL4WS-1: BPEL4WS Sample Process Definition

Figure BPEL4WS-1 gives an example that defines 2 partnerLink types: HealthCareRequestLT and HospitalRequestLT. 2 Roles are distinguished for these links: myRole and partnerRole is invoked when the service uses 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.

The variables part of a Business Process Execution Language for Web Services process definition is used to store state information related to the workflow. Each variable has a type, which has to be given at the time the variable is defined.

The sequence part of a Business Process Execution Language for Web Services process gives the sequential order in which process steps are to be executed. Business Process Execution Language for Web Services offers a number of constructs to express workflow logic in the process definition as depicted in the diagram below:

<sequence>
  <receive name="InformationRequest"
      ...
  </receive>

  <invoke name="DrugstoreHealthCareInformation"
      ...
  </invoke>

  <switch>
    <case condition="GetVariableProperty('OutputRequest', 'Quality') '>' "threshold">
    </case>
    
    <otherwise>
      <invoke name="HospitalHealthCareInformation"/>
    </otherwise>
  </switch>
  
  <reply variable="InformationResponse"/>
<sequence>

Figure BPEL4WS-2: BPEL4WS Sequence Workflow

In a typical service interaction, there will both be many requests for information, and many responses to those requests. Therefore, there needs to be a way of connecting the correct response to any given request. In service interactions tokens are used as part of the messages being exchanged. Messages are correlated to relate operations within a service instance.

Service Oriented Software Engineering

Services, and compositions of services need to be engineered too. This process is known as Service Oriented Software Engineering (SOSE). At the global level, the Service Oriented Software Engineering Life Cycle is not much different than the classical software life cycle. The Service Oriented Software Engineering Life Cycle consists of phases such as analysis, architecture, design and construction. Each of the Service Oriented Software Engineering phases is, however, slightly different from its non-service oriented counterpart.

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.

There are 3 main steps to the Service Oriented Software Engineering process, ad indicated in the table below:

SOSE Phase	Detailed Steps
Analysis	Determine Scope Gap Analysis
Architecture	Decompose Process Compose Specific Service Oriented Architecture (SOA)
Design	Design Services and Their Interfaces Design Business Process
Figure SOSE-1: Main Phases of Service Oriented Software Engineering

A service, whether it is simple or a large 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 the start and end. Who are the participants, what is the input and output of the process. The first step determines the boundaries for the steps to follow.

Especially for larger business processes, there are applications that will automate part of the process. These can be legacy applications from within the organization, or components and services that may be acquired elsewhere. The gap analysis step determines which existing elements can be reused in the realization of this service.

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. Usage scenarios are devised and used to manually test the process flow developed and identify any missing steps. These usage scenarios then help to decide which services can be grouped into a composite service.

The next step is to Compose a specific Service Oriented Architecture. The service layers are determined, the Web services standards to be used are determined, as well as rules for how the Web Services are to be applied.

The last SOSE phase is the Design phase. The design phase is subdivided into two activities. The first activity is to Design Services and Their Interfaces. In terms of the Service Oriented Architectural style, this concerns the detailed design of the service layers and the coordination layer.

Summary

Services have a long history in the area of telephone service. Many of the achievements made in telephony are currently being rediscovered and translated into the world of Software Engineering.

The most important characteristic that distinguishes services from classical software components is that services are discovered dynamically. Based on a description of what the service is supposed to accomplish, the most applicable service is selected and chosen at the time of the request. 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.

Most efforts at developing service orientation has been the mechanical assembly of service components: how to configure the service, and how to connect the different services together to form the composite service. The semantic level of service development has only begun to be exploited. Efforts are currently underway to describe a Semantic Web which will consist of a Web that carries semantic information in addition to current Web Services. XML is the basis for the first generation web. The Ontology Web Language is the basis for the second, semantics oriented Web Services.

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

The full realization of services will require Software Engineering techniques in the field of Service Oriented Software Engineering. The main phases of devloping services are the same phases used for developing components. Though there are unique elements that need to be considered during the analysis and design phases. There are still many open issues when it comes to the Engineering of Services.