The Role of Metadata in the Orchestration of Web Services

Table of Contents

II. List of Tables

III. List of Figures

IV. List of Code-Listings

1 Preface
1.1. Chapter Overview

2 Process Management and Web Services
2.1. Enterprise Application Integration
2.1.1. Message-broker-based EAI
2.2. Workflow Management Systems
2.3. From EAI and WfMS to Web Services

3 Introduction to XML-Technologies
3.1. Extensible Markup Language
3.1.1. Well-formed vs. valid
3.1.2. XML Namespaces
3.2. Document Type Definition
3.3. XML Schema Definition
3.4. The Extensible Stylesheet Language
3.5. XML Path Language
3.6. XML Query Language

4 Introduction to Web Services
4.1. Service Oriented Architecture
4.2. Web Service
4.3. Basic Web Service Technologies
4.3.1. SOAP
4.3.2. Web Service Description Language
4.3.3. Universal Description, Discovery, and Integration
4.3.3.1. Public and Private Registries
4.3.3.2. Representing Information within UDDI
4.3.3.3. Representing Businesses and Providers
4.3.3.4. Representing Services
4.3.3.5. Representing Web Services
4.3.3.6. Technical Models

5 Web Services in a Business World
5.1. Web Service Orchestration
5.1.1. Orchestration Requirements
5.1.2. Orchestration Standards
5.2. Business Process Executing Language for Web Services
5.2.1. Document Structure
5.2.2. Variables Variables in BPEL
5.2.3. Service Selection
5.2.4. Activities
5.2.4.1. Implementing Structured Activities
5.2.5. Exceptions and Transactions
5.2.6. Instance Routing

6 Realization
6.1. Scenario Overview
6.2. System Environment
6.2.1. J2EE for Web Service Implementation
6.2.1.1. JAX-WS
6.2.2. The Oracle BPEL Process Manager for WS Orchestration
6.3. Implementation
6.3.1. Database Structure
6.3.1.1. Connecting to the MySQL Database
6.3.3. Building a JAX-WS Web service
6.3.3. Developing the BPEL Process
6.3.3.1. Dynamic Binding with WS-Addressing
6.3.3.2. Dynamic Procurement Process Steps

7 Conclusion and Future of Work
7.1. Conclusion
7.2. Future of Work

V. Appendices
A. web.xml for WSSupp1
B. Suppliers’ Web Service Implementation
C. Rating Service Implementation
D. Static Process Implementation
E. Dynamic Process Implementation

VI. List of Abbreviations

VII. Bibliography

II. List of Tables

Table 1: Primitive Activities

Table 2: Structured activities

Table 3: System Environment

Table 4: Implemented Web Services

Table 5: Service Binding Elements

III. List of Figures

Figure 1: XML-Validation

Figure 2: XML-Technologies presented within this thesis

Figure 3: XSL-Transformation

Figure 4: Presentation of Listing 1 (suppliers.xml) as a webpage

Figure 5: SOA stack with current standards and emerging Web services specifications

Figure 6: The SOA Find-Bind-Execute paradigm

Figure 7: UDDI schema

Figure 8: Orchestration with BPEL

Figure 9: Simple Procurement Example

Figure 10: Synchronization

Figure 11: Entity Relationship Diagram (ERD)

Figure 12: Deployment Process of the WSSupp1 Web service

Figure 13: Dynamic Binding Process

Figure 14: Process Communication Overview

IV. List of Code-Listings

Listing 1: Well-formed XML-Document

Listing 2: DTD for the XML document from Listing 1

Listing 3: XML Schema for the XML Document from Listing 1

Listing 4: XML document from Listing 1 formatted in HTML with XSL

Listing 5: XPath Expressions

Listing 6: XQuery statement

Listing 7: Sample SOAP envelope

Listing 8: BPEL document elements

Listing 9: BPEL Variable Declaration

Listing 10: BPEL Partner Declaration - Purchasing Agent View

Listing 11: Partner Link Type Definition

Listing 12: Port Type Definition

Listing 13: Sequential execution

Listing 14: Conditional behavior

Listing 15: Synchronization with <flow> and <sequence>

Listing 16: Fault Handling

Listing 17: MySQL Database connection with Java

Listing 18: Service Endpoint for Supplier1 Service

Listing 19: Configuring the build.xml target

Listing 20: JAX-WS annotations

Listing 21: Endpoint Reference

Listing 22: Port Binding

Chapter 1 Preface

“Orchestration is the study and practice of arranging music for an orchestra or musical ensemble. In practical terms it consists of deciding which instruments should play which notes in a piece of music.” [Wiki] In musical terms, the orchestra would be made up of Web services, BPEL would be the sheet music and the business process manager (BPM) would be the composer that selects the necessary Web services and decides how they should interact with each other.

Organizations use Web services in two broad categories, Enterprise Application Integration (EAI) and Business-to-Business (B2B) e-commerce as well as less complex scenarios such as technical functions and information services (common services¹ ). This thesis provides an insight on how the Web service standards resolve the limitations of conventional middleware and extend the benefits of process management to a wider scope of business problems.

Web service standards like SOAP, XML, WSDL, and BPEL enable customers to solve integration problems easily by providing interoperability within a company or across multiple companies and improve B2B eCommerce and supply chain management by shifting to a service-oriented paradigm in application development. Web service orchestration provides an open, standards-base approach to create high-level business processes, such as workflows.

This thesis will focus on BPEL for describing the business logic, although competing standards are still in use. The steps for the workflow implementation will be explained on the basis of a sample procurement scenario.

1.1. Chapter Overview

The second chapter “Process Management and Web Services” gives an insight into Enterprise Application Integration (EAI) and Workflow Management Systems (WfMS) and how Web services resolve the limitations of these middleware technologies.

Web service technologies are based on the use of several XML dialects to exchange data between applications. Chapter 3 “Introduction to XML-Technologies” describes the basics of the markup language and its technologies. Because XML is a huge topic the focus of this chapter lies primarily on what is needed to understand Web services technologies.

Chapter 4 “Introduction to Web Service” introduces the SOA conceptual framework, describes what a Web service is and how Web services standards such as SOAP, WSDL and UDDI fit together.

Chapter 5 “Web Services in a Business World” digs deeper into the Web service topic and shows how Web service orchestration provides an open, standards-based approach to create high-level business processes, such as workflows. This chapter focuses on BPEL (Business Process Executing Language for Web Services) as the orchestration language and describes its features.

Chapter 6 “Realization” describes a sample scenario for orchestrating Web services to an automated business process and explains the steps that have to be taken in order to implement the process. This chapter also introduces technologies such as JAX-WS, and WS-Addressing.

Chapter 2 Process Management and Web Services

2.1. Enterprise Application Integration

Before a company is able to effectively communicate with other enterprises and move in the direction of collaborative business-to-business (B2B) e-commerce, internal systems, applications, and processes have to be considered. The need for IT Systems to communicate within an organization led to the evolution of Enterprise Application Integration (EAI). Behind any system integration effort is the need to automate and streamline procedures, if possible with only little/no human intervention or media break. The challenge within EAI is to integrate disparate systems, applications, and data sources (data exchange between ERP², CRM³, databases, data warehouses). [WSA1]

The middleware layer between client and server opened a way for this higher form of distributed information systems. Middleware provides programming abstractions - communication models, transactions, queues - for designing distributed applications. Well-known middleware technologies are Remote Procedure Calls (RPC)⁴, TP Monitors, Object Monitors, Object Brokers⁵ (CORBA), message-oriented middleware (MOM) and message brokers. MOM is based around a message queue system enabling the storage, routing or transforming of the message as it is being delivered. It is a category of inter-application communication software that relies on asynchronous message passing as opposed to a request/response metaphor. But the problem of MOM is its lack of standards. All the major vendors have their own implementations, each with its own API and management tools.

Traditional RPC-based and MOM systems create point-to-point links between applications and are therefore static and inflexible. [CAA] Middleware technologies such as message-broker-based EAI platforms and Workflow Management Systems (WfMS) facilitate the integration of coarse-grained, heterogeneous components shifting towards asynchronous interactions.

2.1.1. Message-broker-based EAI

Message brokers extended MOM with the capability of attaching logic to messages and processing messages directly at the middleware level. They are typically used in N-tier architectures when complex distribution strategies have to be implemented. Message brokers avoid overly tight integration between multiple tiers. And they are most useful if the communication pattern is not of the request/response type - when messages need to be stored until they are retrieved, e.g. event notification, information dissemination, or publish/subscribe system.

The task of MOM is to move messages from one point to another with certain guarantees whereas the message is always consumed by a single receiver. A Message broker can be considered as a neutral hub for message processing (hub- and-spoke architecture⁶ ). It reduces the transformation complexity by establishing a neutral message format. Message brokers transport, route, filter, and process messages and provide adapters. Adapters mask the heterogeneity and make it possible to access all systems with the same programming model and data exchange format. This implies that there is no need to change applications if they need to interoperate with new systems. Message brokers support a variety of different message-based interaction models, e.g. the publish/describe model to link applications together. [CAA] Messages are published to the middleware system and interested applications subscribe (static or dynamic) to the messages by registering its interest. The message broker delivers copies of the messages to all interested subscribers.

In spite of the lower development and opportunity costs as well less maintenance effort, usually only large companies are able to implement message-broker-based EAI because software licenses are extremely expensive, IT personnel have to be trained, and resources necessary for installation and operation have to be acquired.

2.2. Workflow Management Systems

Workflow Management Systems (WfMS) address the other side of the application integration problem. WfMS extends already existing middleware with the possibility of using processes as a way of describing the integration logic. They help organizations to specify, execute, monitor, and coordinate the flow of work cases within a distributed environment. Users are notified of pending work, and managers can quickly observe status and route approvals through the system. Workflow management means programming in the large. Functionalities that go well beyond what can be typically found in programming languages have to be implemented - large software modules, complex N-tier systems, and entire applications. Also workflows are usually long-lasting and therefore need a sophisticated failure handling, e.g. rollback and recovery. Leading commercial workflow systems are e.g. IBM WebSphere MQ Workflow by IBM, BEA WebLogic Integration, and BizTalk Orchestration.

illustration not visible in this excerpt

Just like the message-broker-based EAI, WfMS software licenses are very expensive and installation, operation, and maintenance of such systems are very complex. Furthermore the development cycles to actually automate real business processes are quite long. A complete middleware platform has to be implemented to provide the necessary runtime environment. Also, workflow management systems are only useful with repetitive and well-defined processes that, for example, do not require heterogeneous applications.

2.3. From EAI and WfMS to Web Services

EAI solutions focus on sharing business data and business processes across an enterprise to realize workflows by linking disparate systems, applications, and data sources. While internal workflows such as a supply chain scenario only involve processes within a company, B2B scenarios exchange information across enterprise boundaries via an extranet or the Internet to make already existing internal data and functions available for business partners (retailers, banks) and industrial consumers, e.g. when a company needs to order goods from another company (procurement scenario). In this scenario the automation of this whole process would be very beneficial to both sides. But cross-company interactions not only require integration across a Wide Area Network, they also last longer and go across trusted domains. Consequently, those interactions require authentication and encryption of messages.

Message-broker-based EAI and its complementary technology WfMS are limited, mainly because they support no integration across a Wide Area Network. The only successful B2B integration is UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce, and Transport) which is widely used in the high tech, civil aviation and tourism industries. However it is very complex and often unnecessarily complicated, and also lacks standardization at the system and communication protocol level.

Web services resolve the limitations of conventional middleware by three main aspects: service-oriented architectures, re-design of middleware protocols, and standardization. Web services technologies are based on the use of several XML dialects to exchange data between applications. Therefore, the basics of this markup language and its technologies will be discussed in the next chapter.

Chapter 3 Introduction to XML-Technologies

3.1. Extensible Markup Language

The wide spread of the Web made it very difficult to standardize all forms of Internet exchanges. But XML is a commonly accepted standard and flexible enough to enable the definition of description languages and protocols necessary to describe the different aspects of a service.

A brief history

In the mid-70s the Standard Generalized Markup Language (SGML) was introduced by Charles F. Goldfarb. SGML soon established an international standard for data representation and evolved a universal format for information exchange. Over a decade later the World Wide Web Consortium (W3C) was founded by Tim Berners-Lee, the inventor of the World Wide Web, to ensure compatibility and agreement among industry members in the adoption of new standards. One of their first initiatives was to create the Hypertext Markup Language (HTML), a text-based, platform-independent language based on SGML. HTML provides the syntax to display documents in a browser but it does not present any information about the nature of the data being displayed which became important in the 90s when e-business needed a standard data representation format. Therefore the W3C created the Extensible Markup Language (XML), a meta-language derived from SGML. XML combines HTML’s presentation feature with the ability to add meta-information and describe other languages. W3C has published the XML Version 1.1 Recommendation in 2004. [W3CXML]

With XML many different kinds of data can easily be described, displayed, organized, managed and exchanged across different systems. XML can be transformed to various presentation formats using the Extensible Stylesheet Language Transformations [XLST, Section 3.4], e.g. to display XML as HTML content. It is a protocol for Remote Procedure Calls (RPC) to allow distributed computing (XML-RPC), and it is the perfect fit for exchanging data within businessto-business (B2B) or business-to-consumer (B2C) architectures.

Furthermore, vocabularies, a set of related XML tags, defined formally using a schema definition language, can be created to describe particular industry or business functions. Common XML vocabularies are e.g. Math XML for describing mathematical notation or Address XML for the interchange of address data.

3.1.1. Well-formed vs. valid

An XML document has to be well-formed, otherwise it is not considered to be XML and XML parsers will refuse to process it. It is well-formed if it generally complies with the XML syntax expressed in the XML Standard, e.g. there can be only one root element and every start-tag must have a matching end-tag. XML is case-sensitive and element names must obey XML naming conventions. If an XML document follows all of the rules in the XML Recommendation [W3CXML2] it is well-formed and can be read by any available XML parser.

Listing 1: Well-formed XML-Document (suppliers.xml)

illustration not visible in this excerpt

An XML document not only has to be well-formed, it also needs to be valid, especially when implementing Web services where organizations have to interoperate. Therefore a method for checking validity is included in XML. For an XML document to be valid the content must comply with a definition of allowed elements, attributes, and other document pieces in order to get the expected data. This set of rules can be defined in a Document Type Definition [DTD, Section 3.2] or an XML Schema Definition [XSD, Section 3.3].

illustration not visible in this excerpt

Figure 1: XML-Validation

3.1.2. XML Namespaces

When creating complex applications, and teams and organizations work together, XML documents will most commonly contain elements with the same name but for another purpose with different meaning and semantics. To combine them into other documents or process multiple documents simultaneously, XML supports namespaces to provide uniquely named elements in an XML instance. Thereby elements are giving qualified names (often referred to as QNames).

An XML-namespace is declared with the reserved XML attribute xmlns and identified by an URI (Unified Resource Identifier)⁷, a globally unique identifier. XML also supports default namespaces. A default namespace applies to the element where it is declared, and to all elements with no prefix within the content of that element.

Many XML standards⁸ have evolved but only a few can be addressed within this thesis. An overview of XML standards relevant to this thesis will be reviewed in the following section is shown in Figure 2.

illustration not visible in this excerpt

Figure 2: XML-Technologies presented within this thesis

3.2. Document Type Definition

As mentioned above, a well-formed XML document conforms to the XML specification. But for an XML document to be valid the content must comply with constraints expressed through a given grammar that represents a definition of allowed elements, attributes, and other document pieces. This set of rules can be defined in a Document Type Definition (DTD).

A DTD is a formal set of grammar rules in order to define the structure of SGML and XML documents. Within a DTD, element types and attributes can be declared, simple data types and validation rules can be assigned, and parent-child relationships between element types can be established. A validating XML processor can validate an XML document against a DTD and pass the XML document structure and the payload to the application.

The Document Type Definition is based on SGML; therefore the syntax is quite different from the rules of basic XML documents. A DTD starts with an optional header consisting of the XML declaration to avoid XML version conflicts. And it is followed by a document type declaration to inform the parser that there is a DTD associated with the XML document. The body of a DTD declares elements, attributes, entities, and notations.

Listing 2: DTD for the XML document from Listing 1 (suppliers.dtd)

illustration not visible in this excerpt

For more detailed information on how to create a DTD see [W3SDTD]

DTD’s are suggested to define simple schemas for XML-documents. Due to the poor support of XML namespaces, limited content model descriptions and poor data typing, they are insufficient when it comes to creating schemas for more complex document structures, e.g. data in enterprise application environments. This is when the XML Schema Definition Language (XSD) comes into play.

3.3. XML Schema Definition

Unlike DTD’s, XML Schemas are created using XML. XSD has received the broadest industry support across contemporary XML and Web services technologies because it offers more variations and options for easily creating complex and re- usable content models. A wide range of data types can be defined and new data types can be derived from existing ones. Many XML and Web services specifications natively incorporate XSD schema features. Utilizing XSD, it's possible to assign to an XML document a separate schema document that describes XML structure, atomic data type, constraints and restrictions, descriptive bindings and alternative sub-schemas [XSch].

For more information on XML Schema see [W3CSch].

Listing 3: XML Schema for the XML Document from Listing 1 (suppliers.xsd)

illustration not visible in this excerpt

3.4. The Extensible Stylesheet Language

The Extensible Stylesheet Language (XSL), a language for expressing style sheets, is a key integration technology and is utilized by many Enterprise Application Integration (EAI) products. ([XML], p. 38) XSL is divided into two primary sections, the Extensible Stylesheet Language Transformation (XSLT) and the Extensible Stylesheet Language Formation Objects (XSL-FO).

As demonstrated in Figure 3, “…XSLT can be used to convert one XML document type into another based on a different XML language, such as WML (Wireless Markup Language)” [SOA,p.34] or HTML. Alternatively, an XSLT style sheet can be used to transform an XML document into an XSL-FO rendition making it suitable for published output, such as a PDF (Portable Document Format)⁹ or a PostScript¹⁰ document. [SOA, p.34]

Figure 3: XSL-Transformation

illustration not visible in this excerpt

The following listing [Listing 4] demonstrates how to generate an HTML site [Figure 4] from the XML information of [Listing 1] and display it in a simple table using XSL.

For more information on XSLT see [W3CXSLT].

Listing 4: XML document from Listing 1 formatted in HTML with XSL

illustration not visible in this excerpt

Figure 4: Presentation of Listing 1 (suppliers.xml) as a webpage

illustration not visible in this excerpt

3.5. XML Path Language

XPath¹¹ is a notation for retrieving information from a document and provides a common syntax for features shared by XSLT [Section 3.4] and XML Query Language [Section 3.6]. XQuery builds on XPath and is a language for extracting information from XML documents.

XPath provides a common non-XML syntax and semantics for functionality shared between XSL Transformation and XML Pointer Language [W3CXPo]. Combined with XSLT, XPath can be used to implement various operations for extracting and transforming XML data.

XPath models an XML document, which must conform to the XML Namespaces Recommendation [W3CNS], as a tree of nodes. This tree contains seven types of nodes; root nodes, element nodes, attribute nodes, text nodes, namespace nodes, processing instruction nodes and comment nodes. XPath expressions, the primary syntactic construct, navigate step-by-step through the hierarchical structure of an XML document, where each step is separated by a ‘/’ character. To get the exact piece of information needed, documents are addressed by specifying a location path. XPath expressions can also represent and manipulate numbers, strings and Booleans.

XPath is concise, simple, and powerful by providing a single syntax for queries, addressing, and patterns.

Listing 5: XPath Expressions

illustration not visible in this excerpt

For more information on XPath see [W3CXPa].

3.6. XML Query Language

The XML Query Language (XQuery), an extension of XPath 2.0 [W3CXPa], was fundamentally derived from the language Quilt [Quilt] as a query language for XML sources, such as databases, and relational databases as well as Web messages and documents. XQuery was influenced by languages such as SQL (Structured Query Language)¹², Lorel¹³, and XML-QL¹⁴ and “… provides a full-featured language for creating complex queries across multiple XML data sources.” [SOA, p.42]

XQuery 1.0 [W3CXQu] operates on the abstract, logical structure of an XML document. It uses XPath 2.0 for navigation within XML documents respectively addressing parts of XML documents and XML Schema to integrate user-defined data types into XQuery expressions. The language provides several kinds of expressions which may be constructed from keywords, symbols, and operands and it allows expressions to be nested with full generality. Every XQuery expression has to return a value. XQuery language elements are e.g. constructors for generating syntax tree nodes, various arithmetic and comparison operations, logical expressions and node sequence operators.

Version 1.0 of XQuery is “read-only”, but insert, update or delete operations are currently planned for version 1.1. For more information on XQuery 1.0 see [W3CQu].

Listing 6: XQuery statement

illustration not visible in this excerpt

Chapter 4 Introduction to Web Services

“… Web services are being used as sophisticated wrappers over conventional middleware platforms …” and can be described as “… an additional tier that allows middleware services to be invoked as Web services.” [CAA, p.149] Consequently, they can be characterized by an internal and an external architecture. The internal architecture is supported by internal middleware and defines the connection of a Web service with the local information systems. The external architecture, supported by external middleware, defines how Web services discover and interact with each other requiring cross-organizational interactions. [CAA, p. 149] It relies upon standards that will be discussed in [Section 4.3].

4.1. Service Oriented Architecture

Service-oriented architecture (SOA) is a simple framework that helps structure the application of Web services technologies. It can be defined as the strategy to how services can understand each other and how they interact. SOA services are functional units implemented by a service provider to achieve desired end results for a service consumer. A SOA service can be a simple object, a complex object, a collection of objects, a process containing other processes or a whole collection of applications outputting a single result. [NtSaWS]

The SOA concept is not new. It is an alternative to traditionally models, such as the Common Object Request Broker Architecture (CORBA). While CORBA is object- oriented and tightly coupled, the overall design of SOA is object-based and achieves loose coupling among interacting software agents by defining platform and language independent interfaces that are not strongly tied to a particular implementation. Loosely-coupled systems became important when business applications needed to be more agile to the changes in business such as changing policies, partners, business strengths and business focus, the so called on demand business. SOA achieves loose coupling by two architectural constraints - a small set of simple interfaces universally available for all providers and consumers as well as descriptive rather than instructive messages constrained by an extensible schema delivered through the interface. To make interfaces more dynamic and flexible, SOA describes the interfaces in the XML based language Web Service Description Language (WSDL) instead of using the object-oriented Interface Definition Language (IDL), as CORBA does. SOA is not language-specific, as long as the language can generate and interact with WSDL. ([NtSaWS], [WiSOA])

The lifecycle for SOA projects includes four stages - modeling, assembling, deploying and managing. In the modeling phase business requirements are gathered and business processes are designed and optimized. During the assembling phase services are created out of existing assets that are currently used to run the business. The services are then orchestrated to implement the business process. The next step is to deploy the business process into a robust, scaleable, and secure services environment. The managing phase involves establishing and maintaining the service availability and response times and managing underlying service assets, as well as gathering information for continuous process improvement. The critical factor to the success of any SOA project is to provide guidance and oversight.

4.2. Web Service

A Web service can be referred to the tactical implementation of a SOA model in software-form giving specific guidelines on how messaging needs to interact. Web services can be pictured as self-contained applications that can be deployed by using application server¹⁵ software, described using a service description language, published to a registry of services, located through a standard mechanism, invoked through a declared Application Programming Interface (API) and orchestrated with other services.

Requirements for Web Services are to communicate via internet protocols, most commonly SOAP¹⁶ [Section 4.3.1] over HTTP (Hypertext Transfer Protocol)¹⁷, and to send and receive data formatted as XML documents. Due to the ability of Web services to establish direct interactions with other software agents, each service can play the role of client (consumer) invoking the service or server (provider) implementing the service. This implies that Web services do not fit into the classic client-server model.

A Web service refers to a set of interoperability standards to simplify the integration with heterogeneous systems. Therefore applications written in various programming languages and running on various platforms can use Web services to exchange data over computer networks, generally over the World Wide Web.

The Organization for the Advancement of Structured Information Standards (OASIS) and the World Wide Web Consortium (W3C) are the primary committees responsible for the architecture and standardization of Web services. Vendors such as Microsoft, IBM and Sun have released development tools that simplify the process of building Web service clients and servers.

As already mentioned, Web services provide a very loose coupling between an application that uses a Web service and the Web service itself. This allows either piece to change without negatively affecting the other, as long as the interface remains unchanged. By utilizing HTTP, Web services tunnel everything through Port 80, which is always open for HTTP-traffic in Web browsers, and therefore do not need a change to firewall or browser configurations in order to operate, though it may be unwelcome by administrators because it bypasses certain aspects of network security.

Due to text-based protocols and data formats Web services make it easy for developers to comprehend; though the use of these text-based protocols may result in a loss of performance compared to other distributed computing approaches such as RMI (Remote Method Invocation) or CORBA. This is mainly due to the requirement to parse and transport XML. XML documents are inherently more voluminous, more data has to be exchange, and more control packages are required. [WJC] “The additional communications and processing costs are frequently perceived as a potential barrier to the use of Web services technologies.” ([WJC], p.2) But “improvements in implementations of SOAP communications have significantly reduced the performance failings…While a Web service solution will still be slower, consume more memory, more network bandwidth, and more CPU cycles than an alternative solution, the differences are less marked in realistic applications …” ([WJC], p.11)

4.3. Basic Web Service Technologies

As previously mentioned, the XML-based protocol SOAP [Section 4.3.1] is the protocol for exchanging XML-based messages, normally using HTTP. It enables the communication between Web services independent of programming language, operating system, or platform. “Although transport protocols are fundamental to Web services and clearly are a defining factor in the scope of interoperability, the details are generally hidden from the design of Web services.” [SPA]

The interface of a Web service is described in a machine processible format such as the Web Services Description Language [Section 4.3.2], which is an XML-based service description on how to communicate using the Web service by defining the protocol and the message characteristics of end points.

Furthermore, ”Quality of services is an important requirement of business-to- business transactions and thus a necessary element in Web services. The various Quality of Service properties such as availability, accessibility, integrity, performance, reliability, regulatory, and security, need to be addressed in the implementation of Web service applications. The properties become even more complex when you add the need for transactional features to Web services.“ [QoS] The security layer ensures that the exchanged information is not modified or forged. The guaranteed delivery of the information exchanged between participants is provided by the reliable messaging layer. And the transaction layer “…defines interoperable mechanisms for propagating context of long-lived business transactions and enables participants to meet correctness requirements by following a global agreement protocol.” [WS-CDL]

The protocol UDDI (Universal Description, Discovery, and Integration, [Section 4.3.3]), accessed using SOAP, is a standard for publishing Web services. It provides access to WSDL documents so that applications can determine whether to use a certain Web service. [Figure 6] UDDI also provides features ”… to agree on a mode of interaction between a requestor and a service.” [SPA]

“Together, these specifications allow applications to find each other and interact following a loosely coupled, platform-independent model.” ([BPEL1.1], p.8)

High-level languages such as the Business Process Execution Language [BPEL, Section 5.2] take the service concept one step further by providing a method of defining and supporting workflows and business processes. Assembling, integrating and coordinating individual Web services into a manageable business application is called orchestration [Section 5.1].

The following figure, adapted from [SPA, Figure 1-7. The SOA stack: High-level architecture of the bus., and Figure 3-1. Web services architecture], gives an overview of the SOA stack and its just mentioned Web Service Technologies.

illustration not visible in this excerpt

Figure 5: SOA stack with current standards and emerging Web services specifications

illustration not visible in this excerpt

Figure 6: The SOA Find-Bind-Execute paradigm [KES]

4.3.1. SOAP

SOAP is a lightweight protocol of the XML specification for exchanging structured and typed data¹⁸ between applications. It is platform-, language-, and vendor- independent, not object-oriented, easy to implement, and firewall safe and it has evolved into the most widely supported messaging format and protocol for use with XML Web services.

SOAP relies on XML schema [Section 3.3] and XML namespaces [Section 3.1.2] for its definition and function. It enables communication between service requestor, service provider and discovery agencies [Figure 6] whereby SOAP acts like an envelope that carries its contents. SOAP does not enforce specific communication patterns, SOAP messages can be embedded into various transport protocols. Because HTTP is the protocol most commonly used, specific rules on how the RPC should be sent are included in the specification for HTTP. SOAP defines a framework for message structure and a message processing model allowing rich message patterns such as traditional request-response, broadcasting and sophisticated message correlations.

SOAP specification

The SOAP specification Version 1.2 consists of a primer (Part 0, [W3CSO0]), messaging framework (Part 1, [W3CSO1]), and adjuncts (Part 2, [W3CSO2]).

The first part (Part 1) defines the extensible SOAP messaging framework. This framework consists of the SOAP processing model defining the rules for processing a SOAP message, the SOAP extensibility model defining the concepts of SOAP features and SOAP modules, the SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes as well as the SOAP message construct defining the structure of SOAP messages. [W3CSO1]

The second part (Part 2) defines a set of adjuncts that may be used with the SOAP messaging framework, e.g. how to use the SOAP Data Model for representing RPC calls and responses, and rules for encoding instances of data. [W3CSO2]

The primer (Part 0) “… is a non-normative document intended to provide an easily understandable tutorial on the features of the SOAP version 1.2 specifications.” [W3CSO0]

As mentioned above, any information exchanged over SOAP is contained within an

envelope that represents the overall structure of the XML that is sent. This way a SOAP server¹⁹ is able to understand the data. The rules on how the data is represented are specified in a set of encoding rules. This allows complex data types and objects to be serialized as XML in order to be sent in SOAP messages. SOAP also defines a convention for making remote procedure calls.

The <envelope> element provides the root element for the XML document. It includes any namespace declarations and also consists of the <body> element, which represents the content of the message. The actual RPC calls are made using direct children of this <body> element, called body entries. Body entries must reside in a namespace other than the SOAP namespace. The SOAP server will use these to uniquely identify a certain procedure. When the procedure is done running a SOAP message is then sent back with the results via the HTTP response. [XML]

SOAP establishes two communication styles, SOAP-RPC and document-centric, as wells as two serialization formats, encoded and literal. Encoded signifies that the RPC/document message is encoded whereas literal implies that the RPC/document message is not encoded.

With SOAP, in RPC mode, applications can activate methods without knowing anything about the actual implementation of the method. The SOAP runtime enforces a specific structure for RPC style messages and their responses. This implies that client and server are subjected to certain constraints. The SOAP body contains an element for each method/procedure and its parameters, and it is tightly coupled with the service interface. If the interface changes, the message structure has to be adjusted. SOAP-RPC describes application semantics as well as system behaviors and it is instructive rather than descriptive. Expressing a remote procedure call in the body element of a SOAP message is a useful mechanism for tunneling RPCs between systems. Web services created with SOAP-RPC are not interoperable by nature. Although, interoperability can still be achieved by using the serialization format encoded.

[...]

---

¹ Common services are e.g. portal services, access management services, resource and systems management, information retrieval, XML document exchange, and file transfer. Other examples for Web Service scenarios are EDI replacement, mobile device to enterprise application communication, peer-to-peer, grid computing and the outsourcing of non-core processes (orchestration-oriented business model).

² Enterprise Resource Planning

³ Customer Relationship Management

⁴ foundation for almost all other forms of middleware, including Web Service middleware (SOAP)

⁵ CORBA (Common Object Request Broker Architecture) is the most well-known object broker architecture

⁶ applications only communicate with the message broker, instead of directly with each other

⁷ An URI should not be mistaken for an URL, it does look like an URL but it does not typically link to a website.

⁸ An overview of existing XML standards can be found at [Std].

⁹ device and resolution independent file format developed by Adobe Systems

¹⁰ page description language primarily used in the electronic and desktop publishing areas

¹¹ XPath 1.0 was published as a W3C Recommendation in 1999. W3C is currently working on XPath 2.0. A candidate recommendation of XPath 2.0 has been released Nov 2005.

¹² computer language for creating, modifying and retrieving data from relational databases

¹³ query language for semi structured data

¹⁴ declarative query language to extract data from XML documents and construct new XML documents (W3C Standard)

¹⁵ application servers: Apache Axis and the Apache Jakarta Tomcat Server, Oracle Application Server IBM WebSphere, Macromedia ColdFusion, etc.

¹⁶ originally an acronym for “Simple Object Access Protocol”, but full name was dropped with SOAP 1.2 specification maintained by the W3C

¹⁷ other communication protocols: FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), XMPP (Extensible Messaging and Presence Protocol)

¹⁸ Data is typed when it takes on additional abstract meaning than what its character usually represents. Examples for typed data are integers, dates, Booleans, and strings

¹⁹ server that hosts Web services, acts as the provider of services, and is the primary participant in a service network (e.g. Apache Axis)