papazogloump-2006-97

8/6/2019 papazogloump-2006-97

1/42

ForP

eerR

eview

Web Services Technologies and Standards

Journal: Computing Surveys

Manuscript ID: draft

Paper: Information Systems

Date Submitted by theAuthor:

n/a

Complete List of Authors: Papazoglou, Michael; Tilburg Univ., Information Systems

Computing ClassificationSystems:

H3 Information Storage & Retrieval, H3.5 Online InformationServices, Web-based services, Service oriented computing

Computing Surveys


2/42

ForPeer

Review

Copyright Michael P. Papazoglou

1 8 April 2006

Web Services Technologies and Standards

Michael P. Papazoglou

INFOLAB, Tilburg University, PO Box 90153,

Tilburg 5000 LE, The [email protected]

Abstract

Web services are self-contained, Internet-enabled applications capable not only of

performing business activities on their own, but also possessing the ability to engage other

Web services in order to complete higher-order business transactions. The act of building

applications and processes as sets of interoperating services is enabled by means of unifiedservice-oriented architecture (SOA). SOA introduces a new philosophy for building

distributed applications where elementary services can be published, discovered and boundtogether to create more complex valued-added services. This article aims at providing a

comprehensive survey of Web service technologies, examining it usage, its relation with

other technologies, the newest developments in the field, architectural models andstandards. The article presents a Web services functionality stack on the basis of whose

functional layers it taxonomizes service standards and current research activities.

Categories and subject descriptors: H [Information Systems]: H3 [Information Storage

& Retrieval]: H3.5 [Online Information Services]: Web-based servicesGeneral terms: Design, Languages, Standards, Management.

Additional keywords and phrases: Service Oriented Computing, Web services, process

modeling and management, workflow systems, application integration, coordination andcollaboration.

1 IntroductionService-Oriented Computing (SOC) utilizes services as the constructs to support thedevelopment of rapid, low-cost and easy composition of distributed applications. Services

are autonomous, platform-independent computational entities that can be used in a

platform independent way. Services can be described, published, discovered, anddynamically assembled for developing massively distributed, interoperable, evolvable

systems. Services perform functions that can range from answering simple requests to

executing sophisticated business processes requiring peer-to-peer relationships betweenpossibly multiple layers of service consumers and providers. Any piece of code and any

application component deployed on a system can be reused and transformed into a

network-available service. Services reflect a "service-oriented" approach to programming,based on the idea of composing applications by discovering and invoking network-available

services rather than building new applications or by invoking available applications to

accomplish some task [Papazoglou 2003].

This "service-oriented" approach is independent of specific programming languages oroperating systems. Services are most often built in a way that is independent of the context

in which they are used, i.e. service provider and consumers are loosely coupled. At the

middleware level, loose coupling requires that the "service-oriented" approach beindependent of specific technologies or operating systems. In particular, services and

service composition does not rely on existing programming languages. It allows

organizations to expose their core competencies programmatically over the Internet or a

age 1 of 41 Computing Surveys

0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


3/42

ForPeer

Review


2 8 April 2006

variety of networks, e.g., cable, UMTS, XDSL, Bluetooth, etc., using standard (XML-based)

languages and protocols, and implementing a self-describing interface.

The premise of SOCs foundation is that an application can no longer be thought of as a

single process running within a single organization. The value of an application is actually nolonger measured by its functionality but by its ability to integrate with its surrounding

environment. For instance, services can help integrate applications that were not writtenwith the intent to be easily integrated with other applications and define architectures and

techniques to build new functionality leveraging existing application functionality. A new

type of applications can be based solely on sets of interacting services offering well-definedinterfaces to their potential users. These applications are often referred as: composite

applications. In the business-to-business (e-Business) world, service orientation enables

loosely coupled relationships between applications of transacting partners, the model doesnot even mandate any kind of pre-determined agreements before the use of an offered

service is allowed [Papazoglou 2006a]. The service model allows for a clear distinction to be

made between service providers (organizations that provide the service implementations,supply their service descriptions, and provide related technical and business support);

service clients (end-user organizations that use some service); and service aggregators

(organizations that consolidate multiple services into a new, single service offering).

Services are offered by service providers which are organizations that procure the serviceimplementations, supply their service descriptions, and provide related technical and

business support. Clients of services can be other solutions or applications within an

enterprise or clients outside the enterprise, whether these are external applications,processes or customers/users. This distinction between service providers and consumers is

independent of the relationship between consumer and provider which can be either client /

server or peer to peer. For the service-oriented paradigm to exist, services need to be:technology neutral (their invocation mechanisms, e.g., protocols, descriptions and discovery

mechanisms, should comply with widely accepted standards), loosely coupled (they must

not require knowledge or any internal structures or conventions, e.g., context at the client

or service side), and they must support location transparency (they can have theirdefinitions and location information stored in a repository and be accessible by a variety ofclients that can locate and invoke the services irrespective of their location).

Web Services are the current most promising technology based on the concept of ServiceOriented Computing [Weerawarana 2005]. A Web service is a service available via a

network such as the Internet that completes tasks, solves problems or conducts

transactions. Web services provide the basis for the development and execution of businessprocesses that are distributed over the network and available via standard interfaces and

protocols. The eventual goal of Web services technology is to enable distributed applications

that can be dynamically assembled according to changing business needs, and customizedbased on device and user access while enabling wide utilization of any given piece of

business logic wherever it is needed.

Web services form the building blocks for creating distributed applications. They rely on a

set of open Internet standards, such as the Simple Object Access Protocol (SOAP) astransmission medium, the Web Services Description Language (WSDL) for service definition

and the Business Process Execution Language (BPEL) [Andrews 2003] for orchestrating

services. These standards allow developers to implement distributed applications usingdifferent tools provided by many different vendors to create corporate applications that

join together software modules from systems in diverse organizational departments or from

different enterprises. For example, an application that tracks the inventory level of partswithin an enterprise can provide a useful Web service that performs simple requests, e.g.,

credit checking and authorization, or inventory status checking. But more importantly, Webservices can also be combined and/or configured, behind the scenes and even on the fly, to

perform virtually any kind of (business-related) task or transaction. In this way they canperform complete business applications that access and combine information from multiple

Page 2 of 41Computing Surveys

0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


4/42

ForPeer

Review


3 8 April 2006

sources, such as an insurance brokering system, a travel planner, an insurance liability

computation or a package tracking system. Enterprises can thus use a single Web service toaccomplish a specific business task, such as billing or inventory control or they may

compose several Web services together to create a distributed e-Business application such

as customized ordering, customer support, procurement, and logistical support.

Figure 1 A purchase order application involving interacting Web services.

Figure 1 shows how a purchase order process can be developed in terms of interacting Webservices involving purchase orders, credit checks, automated billing, stock updates and

shipping originating from various service providers who can gradually package their

offerings to create turnkey products. This purchase order involves a purchasing protocol

wherein a buying organization initially creates a purchase order and sends a request fororder fulfillment to a seller; the seller then after it receives a purchase order responds witheither acceptance or rejection based on a number of criteria, including availability of the

goods and the credit of the buyer. Submitting a purchase order using the Web can be

represented as a complex set of interacting Web services. The product order example hereinhas been adapted from a similar example used for orchestrating Web services [Andrews

2003]. On receiving the purchase order from a buyer, the purchase order process initiates

five tasks concurrently: checking the credit worthiness of the user, determining whether ornot an ordered part is available in the product inventory, calculating the final price for the

order and billing the customer, selecting a shipper, and scheduling the production and

shipment for the order. While some of the processing can proceed concurrently, there arecontrol and data dependencies between these tasks. For instance, the customers

creditworthiness must be ascertained before accepting the order, the shipping price isrequired to finalize the price calculation, and the shipping date is required for the complete

fulfilment schedule. When these tasks are completed successfully, invoice processing can

proceed and the invoice is sent to the customer.

Tracking and adjusting purchase orders due to unexpected events such as the buyer

initiating a purchase order change or cancellation involves a lot of coordination work. Thiscalls for the use of reactive services. For instance, if a single event in the purchase order

needs to change or is cancelled, the entire process can unravel instantly. Employing a

collection of Web services that work together to adjust purchase orders for such situationscreates an automated solution to this problem. In the case of a purchase order cancellation

the purchase service can automatically reserve a suitable replacement product and notify

the billing and inventory services of the changes. When all of these Web service interactionshave been completed and the new adjusted schedule is available, the purchase order Web

service notifies the customer sending her an updated invoice.

Creditche

ck

Creditres

ponse

PO submission

Invoice

Reserve inventory

Inventory response

BillingnotificationBillingstatementBuyer

Purchase Order

CreditService

InventoryService

BillingService

ShipmentService

Shippingnotification

Shipmentacknowledgement

Creditche

ck

Creditres

ponse

PO submission

Invoice

PO submission

Invoice

Reserve inventory

Inventory response

BillingnotificationBillingstatementBuyerBuyer

Purchase OrderPurchase Order

CreditService

InventoryService

BillingService

ShipmentService

CreditService

InventoryService

BillingService

ShipmentService

Shippingnotification

Shipmentacknowledgement


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


5/42

ForPeer

Review


4 8 April 2006

Aim of this paper is to introduce concepts and technologies underlying the domain of Webservices and to taxonomize Web services related standards and research activities in terms

of their functional characteristics. For this purpose three interrelated functional layers are

introduced in a conceptual architectural scheme: service foundations, service composition,and service management and monitoring. The paper is organized as follows. Section-1

introduces Web services, compares them with the concept of software-asaservice anddiscusses their types and broad characteristics. Section 3 introduces the concept of Service

Oriented Architecture, while section-4 presents the layering of Web services technologies

and standards in terms of a Web services functional stack that is founded on the layers ofservice foundations, service composition, and service management and monitoring. Sections

5, 6, and 7 present these layers in detail, standards that underlie them and characteristic

research activities. Finally section-8 presents a summary of this paper.

2 Web Services OverviewAs terminology is often used very loosely it is easy to confuse someone by describing a

service as a Web service when it is in fact not. Consequently, it is useful to examine firstthe concept of software as-a-service on which Web services technology builds upon before

we deconstruct its meaning.

2.1 Software-as-a-serviceThe concept of software-as-a-service appeared first with the ASP (Applications Service

Provider) software model. Application Service Providers are companies that packagesoftware and infrastructure elements together with business and professional services to

create a complete solution that they present to the end customer as a service on a

subscription basis. An ASP is a third party entity that deploys, hosts and manages access toa packaged application and delivers software-based services and solutions across a network

to multiple customers across a wide area network. Applications are delivered over networkson a subscription or rental basis.

The basic idea behind an ASP is to rent applications to subscribers. The whole application

is developed in terms of the user interface, workflow, business and data components thatare all bound together to provide a working solution. An ASP hosts the entire application

and the customer has little opportunity to customize it beyond set up tables, or perhaps thefinal appearance of the user interface (such as, for example, adding company logos). Access

to the application for the customer is provided simply via browsing and manually initiated

purchases and transactions occur by downloading reports. This activity can take place bymeans of a browser. This is not a very flexible solution but offers considerable benefits in

terms of deployment providing the customer is willing to accept it as is.

Although the ASP model introduced the concept of software-as-a-service first, it suffered

from several inherent limitations such as the inability to develop highly interactive

applications, inability to provide complete customizable applications and inability tointegrate applications [Goepfert 2002]. This resulted in monolithic architectures, highly

fragile, customer-specific, non-reusable integration of applications based on tight couplingprinciples.

The Web services paradigm allows the software-as-a-service concept to expand to includethe delivery of complex business processes and transactions as a service, while permitting

that applications are constructed on the fly and services to be reused everywhere and by

any kind of client application. The use of Web services provides a more flexible solution. Thecore of the application the business and data components remain on the ASPs machines,

but are now accessed programmatically via Web service interfaces. The customers cantherefore build their own custom business processes and user interfaces, and are also free


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


6/42

ForPeer

Review


5 8 April 2006

to select from a variety of Web services that are available over the network and satisfy their

needs.

2.2 Definition of Web ServicesAt this stage a more complete definition of a Web service can be given. A Web service is aplatform-independent, loosely coupled, self-contained programmable Web-enabled

application that can be described, published, discovered, coordinated and configured using

XML artefacts for the purpose of developing distributed interoperable applications. Webservices possess the ability to engage other services in a common computation in order to:

complete a task, conduct a business transaction, or solve a complex problem,and expose their features programmatically over the Internet (or intra-net) using

standard Internet languages and protocols like XML, and

can be implemented via a self-describing interface based on open Internetstandards.

Two important characteristics of Web services merit further discussion. These are loosecoupling and the semantic encapsulation of discrete functionality.

Web services interact with one another dynamically and use Internet standard technologies,making it possible to build bridges between systems that otherwise would require extensive

development efforts. Traditional application design depends upon a tight interconnection ofall subsidiary elements, often running in the same process. The complexity of these

connections requires that developers thoroughly understand and have control over both

ends of the connection; moreover, once established, it is exceedingly difficult to extract oneelement and replace it with another. As opposed to tight coupling principles that require

agreement and shared context between communicating systems as well as sensitivity to

change, loose coupling requires a much simpler level of coordination and allow for moreflexible reconfiguration.

A Web service is a self-contained software module that performs a single task. The moduledescribes its own interface characteristics, i.e., the operations available, the parameters,

data-typing and the access protocols, in a way that other software modules can determinewhat it does, how to invoke its functionality, and what result to expect in return. In this

regard, Web services are contracted software modules as they provide publicly available

descriptions of the interface characteristics used to access the service so that potentialclients can bind to it. The service client uses a Web services interface description to bind to

the service provider and invoke its services.

Services are described in terms of a description language, e.g., WSDL, that providesfunctional as well as non-functional characteristics (see section-5.2). Functional

characteristics include operational characteristics that define the overall behavior of theservice while non-functional characteristics include service availability, reliability, scalability,

security, authorization, authentication, (transactional) integrity, performancecharacteristics, e.g., speed or accuracy, timeliness information as well as payment schemes

on a Finance it, Lease it, Pay for it or Pay per use basis.

2.3 Types of Web servicesServices can vary in function from simple requests (for example, currency conversion, credit

checking and authorization, inventory status checking, or a weather report) to complex

systems that access and combine information from multiple sources, such as an insurancebrokering system, a travel planner, an insurance liability computation, or a package tracking


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


7/42

ForPeer

Review


6 8 April 2006

system. Topologically, Web services can come in two flavors: simple informational services

and complex services. Informational, or type I, Web services support only inboundoperations. As such they always wait for a request, process it and respond. This type is very

common and is generally stateless. Complex, or type II Web services implement some form

of coordination between inbound and outbound operations and are almost always statefull,see Figure 2.

Figure 2 High-level view of informational and complex services.

Informational services are services of relatively simple nature, they either involve simple

request/response sequences between interacting services thus providing access to content(content services) or they expose back-end business applications to other applications

located outside the firewall (business process services). They can also provide a seamlessaggregation of information across disparate systems and information sources, including

back-end systems, giving programmatic access to a business service so that the requester

can make the best decisions. Such service requests may have complicated realizations.Consider for example, pure business services, such as logistic services, where automated

services are the actual front-ends to fairly complex physical organizational business

processes. Generally, these services are offered by a third-party and run the whole rangefrom commerce-enabling services, such as logistics, payment, fulfillment, and tracking

services, to other value-added commerce services, such as rating services. The exposed

programmatic services are discrete in nature, exhibit normally a request/reply mode ofoperation and are of fine granularity, i.e., they can be viewed as atomic (or singular)

operations. The clients of these services can assemble them to build new applications.

Informational services are singular in that they perform a complete unit of work that leaves

its underlying data stores in a consistent state. However, they are not transactional in

nature (although their back-end realizations may be). An informational service does notkeep any memory of what happens to it between requests. In that respect this type of

service is known as a stateless Web service.

Informational and simple trading services require support by the three evolving standards:

(i) Service description (WSDL), (ii) Service Publication and Discovery (UDDI) and (iii)Communication Protocol (SOAP), all described in section-5. The key limitations of

informational services (including simple trading services) are that they do not define any

standards for business collaboration, process definition or security over the Web.

Enterprises can use a singular (discrete) service to accomplish a specific business task, suchas billing or inventory control or they may compose several services together to create a

complex service (typically a business process) such as customized ordering, customersupport, procurement, and logistical support. Complex services are collaborative in natureand some of them may require transactional functionality. Consider for instance a secure


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


8/42

ForPeer

Review


7 8 April 2006

supply-chain marketplace application where buyers and suppliers collaborate and compete

for orders and the fulfillment of those orders. Numerous document exchanges will occur inthis process including requests for quotes, returned quotes, purchase order requests,

purchase order confirmations, delivery information and so on. Long running transactions

and asynchronous messaging will occur, and business conversation and even negotiationsmay occur before the final agreements are reached.

Complex services exhibit coarse-grained functionality and are stateful. A stateful Web

service maintains some state between different operation invocations issued by the same or

different Web service clients. Typically, business processes specify stateful interactionsinvolving the exchange of messages between partners, where the state of a business

process includes the messages that are exchanged as well as intermediate data used in

business logic and in composing messages sent to partners.

Complex Web services, just like informational services, require the support of standards

such as SOAP, WSDL and UDDI, however, they also require emergent standards forspecifying business processes and associated XML messages and content and a standard

business terminology. The complex Web services standards are still evolving and are

converging on SOAP, WSDL, UDDI, WS-MetaDataExchange (flexible interface to allowservice endpoints to provide meta-data information to requesters and support the

boostraping of Web service interactions) for and the Web Services Business ProcessExecution Language (BPEL), see section-5.

Both simple and complex Web services can also be categorized according to the way theyare programmed in applications. Some Web services exhibit programmatic behavior

whereas others exhibit mainly interactive behavior where input has to be supplied by the

user. This makes it natural to distinguish between the following two types of Web services:

1. Programmatic Web services: Programmatic Web services encapsulate a programmaticbusiness processes and expose the business logic functionality of the applications and

components that underlie them. Programmatic business services expose function calls,typically written in programming languages such as Java/EJB, Visual Basic or C++.Applications access these function calls by executing a Web service through standard

WSDL programmatic interface. The exposed programmatic services perform a request-

response type of business task and return a concrete result, in this sense they can beviewed as atomic operations. An example typical of programmatic behavior could be

an inventory checking function of an inventory management system, which is exposed

as a Web service accessible to applications via the Internet. The inventory checking

Web service can then be invoked by a create order service that also uses a create

purchase order Web service from an order entry system to create orders, if the

inventory is available.

2. Interactive Web services: these expose the functionality of a Web applicationspresentation (browser) layer. They expose a multi-step Web application behavior thatcombines a Web server, an application server and underlying database systems and

typically deliver the application directly to a browser. Clients of these Web services can

incorporate interactive business processes into their Web applications, presentingintegrated (aggregated) applications from external service providers.

Obviously these two types of Web services can be combined delivering, thus, businessprocesses that combine typical business logic functionality with Web browser interactivity.

We may distinguish between two programming styles for services: synchronous or remoteprocedure call (RPC)-style versus asynchronous or message (document)-style.

Synchronous services: Clients of synchronous services express their request as a method

call with a set of arguments, which returns a response containing a return value. This


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


9/42

ForPeer

Review


8 8 April 2006

implies that when a client sends a request message, it expects a response message before

continuing with its computation. Because of this type of bilateral communication betweenthe client and service, RPC-style services require a tightly coupled model of communication

between the client and service provider. RPC-style Web services are normally used when an

application exhibits the following characteristics:

The client invoking the service requires an immediate response. The client and service work in a back-and-forth conversational way. The service is typically data-oriented.

Examples of typical simple information services with an RPC-style include returning the

current price for a given stock; providing the current weather conditions in a particular

location; or checking the credit rating of a potential trading partner prior to the completionof a business transaction.

Asynchronous services: Asynchronous services are document-style or message drivenservices. When a client invokes a message-style service, the client typically sends it an

entire document, such as a purchase order, rather than a discrete set of parameters. The

service accepts the entire document it processes it and may or may not return a resultmessage. A client that invokes an asynchronous service does not need to wait for a

response before it continues with the remainder of its application. The response from theservice, if any, may arrive any time later. Asynchronous services promote a looser coupling

between the client and service provider, as there is no requirement for a tightly coupled

request-response model between the client and the Web service. Document-style Webservices are normally used when an application exhibits the following characteristics:

The client does not require (or expect) an immediate response. The service is process-oriented.

Examples of document-style Web services include processing a purchase order; responding

to a request for quote order from a customer; or responding to an order placement by aparticular customer. In all these cases, the client sends an entire document, such as apurchase order, to the Web service and assumes that the Web service is processing it in

some way, but the client does not require an immediate answer.

2.4 Quality of ServiceFor a Web service to function properly it must include a description of both its operational

characteristics, which determine its overall behavior, as well as well as a description of itsnon-functional characteristics. Non-functional characteristics of a service concentrate

predominantly on describing the environment hosting the Web service. Each service hosting

environment may offer various choices of qualities of service based on technical

requirements regarding demands for around-the-clock levels of service availability,performance and scalability, security and privacy policies and so on, all of which must be

described. It is thus obvious that the quality of service offered by a Web service is becomingthe utmost priority for service providers and their customers. Improvements in network

infrastructure and support, coupled with increasing internal performance expectations, havepushed organizations to more stringently tie financial benefit to the quality of service (QoS)

delivered.

In the Web services context, QoS can be viewed as providing assurance on a set of

quantitative characteristics. These can defined on the basis of important functional and non-

functional service quality properties that include implementation and deployment issues aswell as other important service characteristics such as service metering and cost,

performance metrics (e.g., response time), security requirements, (transactional) integrity,reliability, scalability, and availability. These characteristics are necessary requirements


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


10/42

ForPeer

Review


9 8 April 2006

understand the overall behavior of a service so that other applications and services can bind

to it and execute it as part of a business process.

The key elements for supporting QoS in a Web services environment are partly based on

[Mani 2002] and include availability (absence of service downtimes), accessibility (thedegree with which a Web service request is served) conformance to standards, integrity

(the degree with which a Web service performs its tasks according to its WSDL descriptionas well as conformance with service-level agreement), performance (measured in terms of

two factors: throughput and latency), reliability (expressed in terms of number of

transactional failures per month or year), scalability, and security (authentication,authorisation, message integrity and confidentiality).

There are several cases where Web services require transactional behavior and contextpropagation. The fact that a particular Web service requires transactional behavior is

described in its accompanying Service Level Agreement, and service providers must

maintain this property.

As organizations depend on business units, partners, and external service providers, to

furnish them with services, they rely on the use a service level agreements to ensure thatthe chosen service provider delivers a guaranteed level of service quality. A Service Level

Agreement is a formal agreement (contract) between a provider and client, formalizing thedetails of a Web service (contents, price, delivery process, acceptance and quality criteria,

penalties and so on, usually in measurable terms) in a way that meets the mutual

understandings and expectations of both the service provider and the service requester.Both service providers and clients alike need to utilise SLAs in order to work well together.

Thus, an SLA is an important and widely used instrument in the maintenance of service

provision relationships.

The metrics imposed by SLAs should correlate with the overall objectives of the services

being provided. Thus an important function that an SLA accomplishes is addressing QoS at

the source. This refers to the level of service that a particular service provides [Mani 2002].To address such concerns, the evolving Web services suite of standards supports a standardpolicy framework that makes it possible for developers to express the policies of services

and for Web services to understand policies and enforce them at runtime. The Web Services

Framework (WS-Policy) [WS-Policy 2003] assists this undertaking by providing buildingblocks that may be used in conjunction with other Web service and application-specific

protocols to assist in expressing, exchanging and processing the policies governing the

interactions between Web services endpoints (see section-6.5).

2.5 Service Interfaces and Component ImplementationsServices are intended to represent meaningful business functionality that can be assembled

into a larger and new configurations depending on the need of particular kinds of usersparticular client channels. A business process can be composed of finer-grained services

that need to be supported by infrastructure services and management services such asthose providing technical utility such as logging, security, or authentication, and those that

manage resources. To a service client is irrelevant whether the services are provided by afine-grained suite of components, or a single monolithic ERP. However, it is important that

the developer who implements the service still thinks about granularity so they can change

parts of the implementation with the minimum of disruption to other components,applications and services. The granularity of components should be the prime concern of the

developer responsible for providing component implementations for services, whereas

service designers should be more interested in the process operations and assemblypotential of the provided services. Service design and development is about identifying the

right services, organizing them in a manageable hierarchy of composite services (smallergrained often supported larger grained), choreographing them together for supporting abusiness process.


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


11/42

ForPeer

Review


10 8 April 2006

Classifying business processes into logical service domains reduces the number of businessprocesses and services that need to be addressed. This gives raise to the concept of a

service domain, also referred to as business domain, which is a functional domain

comprising a set of current and future business processes that share common capabilitiesand functionality and can collaborate with each other to accomplish a higher-level business

objective, e.g., loans, insurance, banking, finance, manufacturing, human resources, etc. Inthis way a business can be partitioned into a set of disjoint domains. Such domains can be

leveraged from multiple architectural reasons such as load balancing, access control, and

vertical or horizontal partitioning of business logic.

Figure-3, shows that a service domain such as distribution is subdivided into higher-level

business processes (service aggregations) such as purchasing, order management andinventory. In this figure, an order management business process, which we shall use as a

running example throughout the paper, performs order volume analysis, margin analysis,

sales forecasting and demand forecasting across any region, product or period. It can alsoprovide summary and transaction detail data on order fulfillment and shipment according to

item, sales representative, customer, warehouse, order type, payment term, and period.

Furthermore, it can track order quantities, payments, margins on past and upcomingshipments, and cancellations for each order. The order management process in Figure-3 is

shown to provide business services (singular, i.e., discrete services) for creating, modifying,suspending, canceling, querying orders, and scheduling order activities. Business services

can also create, modify, and delete bulk orders and order activities, while customers be

informed of the progress of an order and its order activities. Business services in the ordermanagement process are used to create and track orders for a product, a service or a

resource, and is used to capture the customer-selected service details. Information that is

captured as part of an order may include customer account information, product offeringand quality of service details, SLA details, access information, scheduling information, and

so forth.

Business services and business processes distinguish between an interface andimplementation part. The interface part defines the visible service functionality, i.e., theoperations available, the parameters, data-typing and the access protocols, in a way that

other software modules can determine what the service does, how to invoke its

functionality, and what result to expect in return. The implementation realizes the interfacetypically using component-based development. Service realization may be provided by a

software package, e.g, an ERP package, a special purpose built component, a commercial

off the shelf application (COTS), or a legacy application. The implementation details arehidden from the users of the service. Different service providers using any programming

language of their choice may implement the same interface. One service implementation

might provide the functionality itself directly, while another service implementation mightuse a combination of other services to provide the same functionality.

Business services are supported by infrastructure, management and monitoring services.

These services provide the infrastructure enabling the integration of services through the

introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation,and other transformation mechanisms, often considered as part of the Enterprise Service

Bus [Chappell 2004], [Papazoglou 2006b], see section-5.6. This layer also provides the

capabilities required for enabling the development, delivery, maintenance and provisioningof services as well as capabilities that monitor, manage, and maintain QoS such as security,

performance, and availability. It also provides services that monitor the health of SOA

applications, giving insights into the health of systems and networks, and into the statusand behavior patterns of applications making them thus more suitable for mission-critical

computing environments. Monitoring services implement all important standardsimplementations of WS-Management (see section-7) and other relevant protocols and

standards such as WS-Policy (see section-6.5).


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


12/42

ForPeer

Review


11 8 April 2006

Figure 3 Processes, service interfaces and componentg realizations.

All service domains, business processes and services are automatically populated withfinancial and operational functions and data available from resources such as Enterprise

Resource Planning systems, databases, Customer Resource Management and other

enterprise systems, which lie at the bottom of the service lifecycle development hierarchyand which implement the business services.

We may collectively think of the service domain, business processes and business servicessections as comprising the logical part of the Web services development life cycle, while we

may think of the infrastructure services, the component-based realizations, and theoperational systems sections as comprising the physical part of the Web services

development life cycle [Papazoglou 2006c]. The physical part involves a realization strategy

that needs to choose from an increasing diversity of different options for implementingservices, which may be mixed in various combinations including [Papazoglou 2006c]: in

house service design and implementation, purchasing/leasing/paying for services,

outsourcing service design and implementation, using wrappers and/or adapters to accessnon-component implementations for services, which may include database functionality or

legacy software accessed.

3 The Service-Oriented ArchitectureKey to the concept of using Web services as the constructs to support the development ofrapid, low-cost and easy composition of distributed applications is the Service-Oriented

Architecture (SOA). SOA is a logical way of designing a software system to provide services

to either end-user applications or other services distributed in a network through publishedand discoverable interfaces. An SOA builds on the Web services baseline specifications of


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


13/42

ForPeer

Review


12 8 April 2006

SOAP, WSDL, and UDDI that are examined in section-5. The main building blocks of the

Web services architecture are determined on the basis of the roles of service providers,service registries and the service requesters (or clients).

The basic SOA defines an interaction between software agents as an exchange of messagesbetween service requesters (clients) and service providers. Clients as usual request the

execution of a service while providers are software agents that provide the service and areresponsible for publishing a description of the service(s) they provide. From an architectural

perspective the provider is the platform that hosts and controls access to the service. The

Web services provider is responsible for publishing the Web services it provides in a serviceregistry hosted by a service broker. This involves describing the business, service and

technical information of the Web service and registering that information with the Web

service registry in the format prescribed by the discovery agency. The Web servicerequester searches the service registry for the desired Web services. This effectively means

discovering the Web service description in a registry provided by a discovery agency and

using the information in the description to bind to the service. Agents can be simultaneouslyboth service clients and providers. This approach is particularly applicable when multiple

applications running on varied technologies and platforms need to communicate with each

other. In this way, enterprises can mix and match services to perform business transactionswith minimal programming effort.

Figure 4 Web service roles and operations.

Discovering Web services involves querying the registry of the discovery agency for Webservices matching the needs of a Web service requester. A query consists of search criteria

such as type of service, preferred price range, what products are associated with this

service, with which categories in company and product taxonomies is this Web serviceassociated as well as other technical characteristics and is executed against the Web service

information in the registry entered by the Web service provider. The find operation can beinvolved in two different instances by the requester. Statically at design time to retrieve aservices interface description for program development. Dynamically (at run-time) to

retrieve a services binding and location description for invocation.

For an application to take advantage of the Web service interactions between the three roles

in the SOA three primary operations must take place. These are publication of the servicedescriptions, finding the service descriptions and binding or invocation of services based on

their service description. These three basic operations can occur singly or iteratively and

are shown in Figure 4, which represents logical view of the service-oriented architecture.This figure illustrates the relationship between the three roles and the three operations.

First, the Web service provider publishes its Web service(s) with the discovery agency.

Next, the Web service requester searches for desired Web services using the registry of thediscovery agency. Finally, the Web service requester, using the information obtained from


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


14/42

ForPeer

Review


13 8 April 2006

the discovery agency, invokes (binds to) the Web service provided by the Web service

provider [Boubez 2000].

The final operation in the Web service architecture is the actual invocation of the Web

service. During the binding operation the service requester invokes or initiates aninteraction at run-time using the binding details in the service description to locate and

contract to the service. The technical information entered in the registry by the Web serviceprovider is used here.

4 Web Services Technology StackThe minimum infrastructure required by the Web services paradigm is purposefully low to

help ensure that Web services can be implemented on and accessed from any platformusing any technology and programming language. By intent, Web services are not

implemented in a monolithic manner, but rather represent a collection of several related

technologies.

Web services lean on a functionality stack containing technologies and standards that canbe layered in accordance with the planes of the extended Service Oriented Architecture

(xSOA) [Papazoglou 2003], [Papazoglou 2005a]). Objective of these functional layers is to

provide facilities for ensuring consistency across the organization, high availability ofservices, security of non-public services and information, orchestration of multiple services

as part of mission-critical composite applications all essential requirements for business-

quality services.

Figure 5 The Web services functionality stack.

The architectural layers in the Web services functionality stack, depicted in Figure 5,

describe a logical separation of functionality in such a way that each layer defines its own aset of constructs, roles and responsibilities and leans on the constructs of its preceding layer

to accomplish its mission. The logical separation of functionality is based on the need to

separate basic service capabilities provided by a services middleware infrastructure and SOAfrom more advanced service functionality needed for dynamically composing (integrating)


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


15/42

ForPeer

Review


14 8 April 2006

services and the need to distinguish between the functionality for composing services from

that of the management of services and their underlying infrastructure.

As shown in Figure 5, the Web services functionality stack has three planes the

foundational, the composition and the management and monitoring layer. The foundationallayer defines basic Web services communication and utilizes the basic service middleware

and architectural constructs and functionality for describing, publishing discovering services,which are widely accepted and are implemented quite uniformly. Higher-level layers are

layered on top of the foundational layer and define strategic aspects of business processes

and the management and monitoring of Web services based processes and applications. Theperpendicular axis in Figure-5 designates service characteristics that cut across all three

planes. These include semantics, non-functional service properties and QoS. The Web

services functionality stack is shown to define several roles. In addition to the classical rolesof service client and provider it also defines the roles of service aggregator and service

operator, which will be explained later in this paper.

In the remainder of this paper we shall introduced each plane from a technology, state of

the art and scientific challenges standpoint. From the technology standpoint a

comprehensive review of state of the art, standards, and current research activities in eachkey area will be provided.

5 Web Services Foundation LayerThe service foundations plane provides a service oriented middleware backbone that

realizes the runtime SOA infrastructure that connects heterogeneous components and

systems, and provides multiple-channel access to services, e.g., via mobile devices, palmtops, hand held devices, over variety of networks including the Internet, cable, UMTS,

XDSL, Bluetooth, and so on. This runtime infrastructure allows to define the classical SOA

functions involving communication, the description, publishing, finding and binding of

services. Four sets of standards implement the basic service functions. These are SOAP,WSDL, UDDI and WS-MetaDataExchange. We shall first examine the basic serviceinteractions followed by the Enterprise Service Bus, a services backbone that realizes the

services runtime environment and infrastructure.

5.1 Web Services CommunicationTo address the problem of overcoming proprietary systems running on heterogeneous

infrastructures, Web services rely on SOAP, an XML-based communication protocol forexchanging information between computers regardless of their operating systems,

programming environment, or object model framework. SOAP is defined as lightweightprotocol for exchange of structured and typed information between computers and systems

in decentralized and distributed environment such as the Internet or even a LAN [Cauldwell

2001].

SOAP provides a wire protocol that specifies how service-related messages are structured

when exchanged across the Internet. SOAP is a lightweight protocol that allows applicationsto pass messages and data back and forth between disparate systems in a distributed

environment enabling remote method invocation. By lightweight we mean that the SOAP

protocol possesses only two fundamental properties: sending and receiving HTTP (or other)transport protocol packets, and processing XML messages.

Although SOAP may use different protocols such as HTTP, FTP or RMI to transport messages

and locate the remote system and initiate communications, its natural transport protocol is

HTTP. Layering SOAP over HTTP means that a SOAP message is sent as part of an HTTPrequest or response, which makes it easy to communicate over any network that permits


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


16/42

ForPeer

Review


15 8 April 2006

HTTP traffic. SOAP uses the HTTP protocol to transport XML-encoded serialized method

argument data from system to system. Serialization is the process of converting applicationdata to XML. XML is then a serialized representation of the application data. The process of

generating application data from XML is called deserialization. SOAPs serialization

mechanism converts method calls to a form suitable for transportation over the network,using special XML tags and semantics. The serialized argument data is used on the remote

end to execute the clients method call on that systems, rather than on the clients localsystem.

The basic requirement for an Internet node to play the role of requester or provider in XMLmassaging-based distributed computing is the ability to construct and parse a SOAP

message and the ability to communicate over the network by sending and receiving

messages. Any SOAP runtime system executing in a Web application server performs thesefunctions.

The current SOAP specification describes how the data types defined in associated XMLschemas are serialized over HTTP or other transport protocols. Both the provider and

requester of SOAP messages must have access to the same XML schemas in order to

exchange information correctly. The schemas are normally posted on the Internet, and maybe downloaded by any party in an exchange of messages. A SOAP message contains a

payload, the application specific information it delivers. Every SOAP message is essentiallyan XML document. SOAP messages consist of three basic parts: an envelope that defines a

structure for describing the content and processing of a message; a header, which allows

defining a set of encoding rules for expressing instances of application-defined data types;and a body, which is a structure for representing remote procedure calls and responces.

The SOAP envelope serves to wrap any XML document interchange and provide amechanism to augment the payload with additional information that is required to route it to

its ultimate destination. The SOAP envelope contains a header and a body. The header

contains processing or control information on how a message recipient should process the

message. In this way an XML document can express meaningful information about aservice, such as authentication or transaction control-related information, as well as qualityof service, billing or accounting information regarding an application. The SOAP body is the

area of the SOAP message where the application specific XML data (payload) being

exchanged in the message is placed. The SOAP is where the method call information and its related arguments are encoded. It is where the response to a method call

is placed, and where error information can be stored.

The Web services communication model describes how to invoke Web services and relies on

SOAP. SOAP supports two possible communication styles: remote procedure call (RPC) and

document (or message), described in section 2.4.

5.2 Web Services DescriptionA SOAP service would require some documentation explaining the operations exposed along

with their parameters in a machine-understandable standard format. In the Web services

context, this is provided by employing a document expressed in Web Services DescriptionLanguage (WSDL). WSDL is the service representation language used to describe the details

of the complete interfaces exposed by Web services and thus is the means to accessing a

Web service. It is through this service description that the service provider cancommunicate all the specifications for invoking a particular Web service to the service

requester.

WSDL provides a mechanism by which service providers can describe the basic format of

Web requests over different protocols (e.g., SOAP) or encoding (e.g., Multipurpose InternetMessaging Extensions or MIME). WSDL is an XML based specification schema for describing


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


17/42

ForPeer

Review


16 8 April 2006

the public interface of a Web service. This public interface can include operational

information relating to a Web service such as all publicly available operations, the XMLmessage protocols supported by the Web service, data type information for messages,

binding information about the specific transport protocol to be used, and address

information for locating the Web service. WSDL allows the specification of services in termsof XML documents for transmission under SOAP.

A WSDL document describes how to invoke a service and provides information on the data

being exchanged, the sequence of messages for an operation, protocol bindings, and the

location of the service. WSDL represents a contract between the service requester and theservice provider. The WSDL specification can be conveniently divided into two parts: the

service interface definition (abstract interface) and the service implementation (concrete

endpoint):

The service-interface definition describes the general Web service interface structure.This contains all the operations supported by the service, the operation parametersand abstract data types.

The service implementation part binds the abstract interface to a concrete networkaddress, to a specific protocol and to concrete data structures. A Web service clientmay bind to such an implementation and invoke the service in question.

This distinction enables each part to be defined separately and independently, and reused

by other parts.

The Web service interface definition describes messages and operations in a platform and

language independent manner. It describes exactly what types of messages need to be sent

and how the various Internet standard messaging protocols and encoding schemes can beemployed in order to format the message in a manner compatible with the service

providers specifications. A service interface definition is an abstract service description that

can be instantiated and referenced by multiple concrete service implementations. The

service interface contains the WSDL elements that comprise the reusable portion of theservice description, these include: the , , ,

and elements. These are briefly summarized below.

Any complex data type that the service uses must be defined in an optional sectionimmediately before the section. The section describes the data types

for exchange between the client and the service. Messages in WSDL are abstract collections

of typed information cast upon one or more logical units, used to communicate informationbetween systems. A element corresponds to a single piece of information

moving between the invoker and the service. A regular round trip method call is modeled as

two messages, one for the request and one for the response. A message can consist of oneor more elements with each part representing an instance of a particular type

(typed parameter). When WSDL describes a software module, each part maps to anargument of a method call.

The WSDL element describes the interface of a Web service. It is simply alogical grouping of operations. The is used to bind the collection of logical

operations to an actual transport protocol such as SOAP, providing thus the linkage between

the abstract and concrete portions of a WSDL document. In WDL s contain, which represent the various methods being exposed by the service. An

operation defines a method on a Web service, including the name of the method and the

input and output parameters. A typical operation defines the input and output parametersor exceptions (faults) of an operation.

Figure 6 shows an excerpt of a WSDL interface definition describing a purchase orderservice. This service takes a purchase order number, a date and customer details as input

and returns an associated invoice. The WSDL example in Figure 6 defines a Web service


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


18/42

ForPeer

Review


17 8 April 2006

that contains a named PurchaseOrderPortType that supports a single

, which is called SendPurchase. The example assumes that the service is

deployed using the SOAP 1.1 protocol as its encoding style, and is bound to HTTP.

Figure 6 Simple WSDL interface definition.

The element SendPurchase in the listing above will be called using the

message POMessage and will return its results using the message Inv(oice)Message.

Operations can be used in a Web service in four fundamentals patterns: request/response,

solicit/response, one-way and notification. The operation SendPurchase is a typical example

of a request/response style of operation as it contains an input and an output message.

The service implementation part of WSDL contains the elements (although

sometimes this element is considered as part of the service definition) and and describes how a particular service interface is implemented by a given

service provider. The service implementation describes where the service is located, or

more precisely, to which network address the message must be sent in order to invoke the

Web service. In WSDL a element contains information of how the elements in

an abstract service interface ( element) are converted into concrete network

protocol such as SOAP or HTTP. The WSDL element defines how a given

operation is formatted and bound to a specific protocol. If there are many operations then

they will be multiple bindings. A specifies the address for a binding, thus defining

the location of a service, or service endpoint. If there are multiple bindings, there will be

multiple endpoints. A element contains a collection of WSDL elements.

Simple services with only one operation, will have only one endpoint. Each

element is named, and each name must be unique among all services in a WSDL document.


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


19/42

ForPeer

Review


18 8 April 2006

5.3 UDDI: Universal Description, Discovery, and I ntegrationThe Universal Description, Discovery and Integration (UDDI) specification was created to

identify potential trading partners and cataloguing their business functions andcharacteristics. UDDI offers a standard infrastructure to classify, catalogue and manage

Web services to enable Web services discovery and consumption. UDDI is designed for useby developer tools and applications that use Web services standards such as SOAP/XML andWSDL.

Through UDDI, enterprises can publish and discover information about other businesses andthe services they provide. This information can be classified using standard taxonomies so

that information can be discovered on the basis of categorization. UDDI contains also

information about the technical interfaces of an enterprises services.

The UDDI XML schema defines five core types of information that provide thewhite/yellow/green page functionality. The UDDI data model hierarchy and the key XML

element names that are used to describe and discover information about Web services are

shown in Figure 7. The entity types in the UDDI data model are as follows:

businessEntity: describes a business or any other organization that provides Web services.

The construct is a top-level structure that corresponds to white pagedescription of a company.

businessService: describes a collection of related Web services offered by an organizationdescribed by a construct. The structure is used to

group a series of related Web services related to either a business process or category of

services. The kind of information contained in a element maps to theyellow pages information about a company.

bindingTemplate: The access information required to actually invoke a service is described

in the information element named which exposes a service endpointaddress required for accessing a service from a technical point of view. Technicaldescriptions of Web services the green pages data -- reside within sub-structures of the

element.

tModel: Each data type contains a special data structure

that provides information about a Web service interface specification. The data

structure describes a technology model representing a reusable concept, such as a Webservice type, a protocol used by Web services, or a category system.

publisherAssertion: defines relationships between pairs of structures.

Two (or more) related enterprises may use the structure to publish

assertions of business relationships.

The UDDI, just like WSDL, draws a sharp distinction between abstraction andimplementation. In fact, the primary role that a plays is to represent technical

information about an abstract interface specification. Due to the fact that both the UDDI andWSDL schema have been architected to delineate clearly between interface and

implementation, these two constructs are quite complementary work together naturally. The

WSDL-to-UDDI mapping model is designed to help users find services that implementstandard definitions. The WSDL-to-UDDI mapping model describes how WSDL

and element specifications can become s; how the s of WSDL

become UDDI s; and how each WSDL service is registered as a [Manes 2003].


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


20/42

ForPeer

Review


19 8 April 2006

UDDI uses SOAP as its transport layer, thus enterprises can interact with UDDI registries

through SOAP-based XML API calls in order to discover technical data about an enterprisesservices. In this way enterprises can link up with service providers and invoke and use their

services. The UDDI specifications allow enquiries and publishing APIs to interact with UDDI

registered sites. Enquiries enable parties to find business businesses, services, or bindings(technical characteristics) meeting certain criteria. UDDI sites use publishing functions to

manage the information provided to requestors. The publishing API essentially allowsapplications to save and delete the five data structures supported by UDDI and described

earlier. These calls are used by service providers and enterprises to publish and un-publish

information about themselves in the UDDI registry.

Figure 7 Overview of UDDI data structures.

5.4 Web Services Meta-data and SemanticsFor Web services to interact properly with each other as part of composite applications that

perform more complex functions by orchestrating numerous services and pieces ofinformation, the requester and provider entities must agree both on the service description

(WSDL definition) and semantics that will govern the interaction between them. To

surmount semantic interoperability problems Web services make use of resource-basedmetadata to describe what service endpoints need to know to interact with each other. This

kind of metadata is used to associate specific properties and their values with whatever the

metadata is about. For example, a meta-data record for a manufactured product, giving itsname, serial number, weight, production date and so on.

Metadata describing a service typically contain descriptions of the interfaces of a service -

the kinds of data entities expected and the names of the operations supported - such items

as vendor identifier, narrative description of the service, Internet address for messages,

format of request and response messages, and may also contain choreographic descriptionsof the order of interactions. Metadata for a service should also include QoS as well as policy

descriptions. Service policy metadata describe the assertions that govern the intent on thepart of a participant when a service is invoked. Policies apply to many aspects of services:

to security, to privacy, manageability, QoS and so forth. Such descriptions may range from

simple identifiers implying a mutually understood protocol to a complete description of thevocabularies, expected behaviors and so on. Such meta-data gives high-level semantic

details regarding the structure and contents of the messages received and sent by Webservices, message operations, concrete network protocols, and endpoint addresses used by

Web services. It also describes abstractly the capabilities, requirements, and general

characteristics of Web services and how they can interoperate with other services.

Web services use the Resource Description Framework (RDF) as an infrastructure thatenables the encoding, exchange, and reuse of structured metadata. This infrastructure has

businessEntity: Information about theparty who publishes information about afamily of services.


businessService : Descriptiveinformation about a particularservice.


bindingTemplate : Technicalinformation about a service entry

point and constructionspecifications.



tModel: Descriptions of specificationsfor services or taxonomies. Basis fortechnical fingerprints.


bindingTemplatedata containsreferences to tModels. These

references designate the interface

specifications for a service.

PublisherInsertion : Informationabout a relationship between twoparties, asserted by one or both.
















bindingTemplatedata containsreferences to tModels. These

references designate the interface

specifications for a service.




0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


21/42

ForPeer

Review


20 8 April 2006

been advanced as the primary enabling infrastructure of the Semantic Web activity in the

W3C and enables metadata interoperability through the design of mechanisms that supportcommon conventions of semantics, syntax, and structure. RDF uses XML as a common

syntax for the exchange and processing of metadata. RDF [Klyne 2004] has provided the

basis for a common approach to declaring schemas in use.

RDF provides a model for describing resources on the Web. The basic RDF data modelconsists of three fundamental concepts: resource, properties and statements. Resources are

the central concept of RDF and are used to describe individual objects of any kind, for

example an entire Web service, a part of a Web service, or a whole collection of Webservices. A resource may also be an object that is not directly accessible via the Web, for

example, a printed book or a travel brochure. RDF defines a resource as any object that is

uniquely identifiable by a Uniform Resource Identifier [Klyne 2004], [Manola 2004], whichcan be a Web address or some other kind of unique identifier. Resources map conceptually

to entities or parts of entities.

RDF Schema is used to declare vocabularies, the sets of semantics property-types defined

by a particular community. RDF Schema defines the valid properties in a given RDF

description, as well as any characteristics or restrictions of the property-type valuesthemselves. The XML namespace mechanism serves to identify RDF Schemas. To

understand a particular RDF schema is to understand the semantics of each of theproperties in that description. RDF schemas are structured based on the RDF data model.

RDF Schema refers to the metadata entities it describes as classes. A class in RDF Schemacorresponds to the generic concept of a type or category, somewhat like the notion of a

class in object-oriented programming languages such as Java [Manola 2004]. Figure 8

depicts such a class hierarchy for publications. This figure illustrates that there are severalother classes such as ex:Article, ex:WhitePaper, ex:NewsItem which are all specializations

of class ex:Publication. To indicate that these classes are also specialized classes of the

class ex:Publication, the predefined property is used to associate the

specialized classes with ex:Publication. This is denoted by dotted lines in Figure 8. Note thatthe resource itself has an of . Moreover, RDFmakes use of multiple inheritance to allow a resource to be an instance of more than one

class, e.g., the class NewsArticle in Figure 8.

The expressivity of RDF and RDF Schema is deliberately restricted. RDF is limited to binary

ground predicates, and RDF Schema is limited to a subclass hierarchy and a property

hierarchy, with domain and range definitions of these properties. The Web OntologyWorking Group (http://www.w3.org/2001/sw/WebOnt) identified a number of characteristic

use-cases for the Semantic Web, which would require much more expressiveness than RDF

and RDF Schema. Some of the richer schema capabilities that have been identified as useful(but that are not provided by RDF Schema) include [Manola 2004]: specifying cardinality

constraints on properties, specifying that a given property (such as ex:hasAncestor) istransitive, specifying that a given property is a unique identifier (or key) for instances of a

particular class, specifying that two different classes (having different URIrefs) actually

represent the same class, specifying that two different instances (having different URIrefs)actually represent the same individual. Moreover, specifying cardinality restrictions of a

property that depend on the class of resource to which a property is applied, and the ability

to describe new classes in terms of combinations (e.g., unions and intersections) of otherclasses, or to say that two classes are disjoint (i.e., that no resource is an instance of both

classes). These capabilities, in addition to other semantic constructs, are the targets of

ontology languages such as the Ontology Working Language (OWL) [Antoniou 2004],[McGuiness 2004] and the Darpa Agent Markup Language (DAML) [DAML].


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0


22/42

ForPeer

Review


21 8 April 2006

Figure 8 Sample RDF schema for a hierarchy of publications.

The OWL ontology language is based on RDF and RDF Schema and provides all the

additional capabilities mentioned above. The intent of languages such as OWL is to provideadditional machine-processable semantics for resources, to provide semantic foundations

for situations involving dynamic discovery of businesses and services by relying onknowledge representation and reasoning techniques to represent business concepts,

relationships between them and a set of rules, that is, to make representations of resources

more closely mirror the semantics of their intended real world counterparts. While suchcapabilities are not necessarily needed to build useful applications using RDF, the

development of such languages is a very active subject of work as part of the development

of the Semantic Web [Manola 2004].

5.5 Web Services Meta-data ExchangeNormally, Web services are invoked by the service endpoint information that is provided byWSDL. For instance, a WSDL service port has a location address, which identifies the

endpoint. This information is suitable in most cases, with the exception of stateful Web

services and cases that add more dynamic information to the address (instance information,policy, complex binding, and so on) [Joseph 2004]. This requires a client or runtime system

to uniquely identify a service at runtime, based on this runtime information. This binding-specific information could include a unique identifier. Currently, there is no standard way by

which this information can be exchanged and then mapped to the runtime engine while the

service is accessed. The Web Services Addressing (WS-Addressing) specification tackles thisproblem by providing a lightweight mechanism for identifying and describing the endpoint

information and mapping that information into the SOAP message headers.

WS-Addressing provides transport-neutral mechanisms to address Web services and

messages. WS-Addressing was introduced in order to standardize the notion of a pointer to

a Web service [Graham 2004a]. It defines how message headers direct messages to aservice, provides an XML format for exchanging endpoint references, and defines

mechanisms to direct replies or faults to a specific location. WS-Addressing enables

messaging systems to support message transmission through networks that includeprocessing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral

manner.

Web services use metadata to describe what other endpoints need to know to interact withthem. More specifically, WS-Policy describes the capabilities, requirements, and general


0

2

3

4

5

6

7

8

9

0

23

4

5

6

7

8

9

0

2

3

4

5

6

7

8

9

0

2

papazogloump-2006-97

Documents