service -oriented computing: concepts, characteristics and directions · · 2014-11-07service...

Service -Oriented Computing: Concepts, Characteristics and Directions

Mike P. PapazoglouTilburg University

INFOLAB,Dept. of Information Systems and Management,PO Box 90153, Tilburg 500 LE, The Nethrlands

[email protected]

Abstract

Service-Oriented Computing (SOC) is the computingparadigm that utilizes services as fundamental elementsfor developing applications/solutions. To build the ser-vice model, SOC relies on the Service Oriented Architecture(SOA), which is a way of reorganizing software applicationsand infrastructure into a set of interacting services. How-ever, the basic SOA does not address overarching concernssuch as management, service orchestration, service trans-action management and coordination, security, and otherconcerns that apply to all components in a services archi-tecture.

In this paper we introduce an Extended Service OrientedArchitecture that provides separate tiers for composing andcoordinating services and for managing services in an openmarketplace by employing grid services.

1 Introduction

Service-Oriented Computing (SOC) is the computingparadigm that utilizes services as fundamental elementsfor developing applications/solutions. Services are self-describing, platform-agnostic computational elements thatsupport rapid, low-cost composition of distributed applica-tions. Services perform functions, which can be anythingfrom simple requests to complicated business processes.Services allow organizations to expose their core compe-tencies programmatically over the Internet (or intra-net) us-ing standard (XML-based) languages and protocols, and beimplemented via a self-describing interface based on openstandards.

Because services provide a uniform and ubiquitous in-formation distributor for wide range of computing devices(such as handheld computers, PDAs, cellular telephones,or appliances) and software platforms (e.g., UNIX or Win-

dows), they constitute the next major step in distributedcomputing.

Services are offered by service providers - organizationsthat procure the service implementations, supply their ser-vice descriptions, and provide related technical and busi-ness support. Since services may be offered by differententerprises and communicate over the Internet, they pro-vide a distributed computing infrastructure for both intra-and cross-enterprise application integration and collabora-tion. Clients of services can be other solutions or applica-tions within an enterprise or clients outside the enterprise,whether these are external applications, processes or cus-tomers/users. Consequently, to satisfy these requirementsservices should be:

• Technology neutral: they must be invocable throughstandardized lowest common denominator technolo-gies that are available to almost all IT environments.This implies that the invocation mechanisms (proto-cols, descriptions and discovery mechanisms) shouldcomply with widely accepted standards.

• Loosely coupled: they must not require knowledge orany internal structures or conventions (context) at theclient or service side.

• Support location transparency: services should havetheir definitions and location information stored in arepository such as UDDI and be accessible by a vari-ety of clients that can locate and invoke the servicesirrespective of their location.

Services come in two flavors: simple and compositeservices. The unit of reuse with services is functional-ity that is in place and readily available and deployableas services that are capable of being managed to achievethe required level of service quality. Composite servicesinvolve assembling existing services that access and com-bine information and functions from possibly multiple ser-

Proceedings of the Fourth International Conference on Web Information Systems Engineering (WISE’03)

0-7695-1999-7/03 $17.00 © 2003 IEEE

vice providers. For example, consider a collection of sim-ple services that accomplish a specific business task, suchas order tracking, order billing, and customer relationshipsmanagement. A enterprise may offer a composite web ser-vice that composes these services together to create a dis-tributed e-business application that provides customized or-dering, customer support, and billing for a specialized prod-uct line (e.g., telecommunication equipment, medical insur-ance, etc). Accordingly, services help integrate applicationsthat were not written with the intent to be easily integratedwith other distributed applications and define architecturesand techniques to build new functionality while integratingexisting application functionality.

Service-based applications are developed as indepen-dent sets of interacting services offering well-defined in-terfaces to their potential users. This is achieved with-out the necessity for tight coupling of distributed applica-tions between transacting partners, nor does it require pre-determined agreements to be put into place before the useof an offered service is allowed.

While the services encapsulate the business functional-ity, some form of inter-service infrastructure is required tofacilitate service interactions and communication. Differ-ent forms of this infrastructure are possible because servicesmay be implemented on a single machine, distributed acrossa set of computers on a local area network, or distributedmore widely across several wide area networks. A particu-larly interesting case is when the services use the Internet asthe communication medium and open Internet-based stan-dards. A web service is a specific kind of service that isidentified by a URI and exhibits the following characteris-tics:

• It exposes its features programmatically over the In-ternet using standard Internet languages and protocols,and

• It can be implemented via a self-describing interfacebased on open Internet standards (e.g., XML interfaceswhich are published in a network-based repositories).

Interactions of web-services occur as SOAP calls carry-ing XML data content and the service descriptions of theweb-services are expressed using WSDL [15] as the com-mon (XML-based) standard. WSDL is used to publish aweb service in terms of its ports (addresses implementingthis service), port types (the abstract definition of operationsand exchanges of messages), and bindings (the concretedefinition of which packaging and transportation protocolssuch as SOAP are used to inter-connect two conversing endpoints). The UDDI [14] standard is a directory servicethat contains service publications and enables web-serviceclients to locate candidate services and discover their de-tails.

Web services share the characteristics of more generalservices, but they require special consideration as a result ofusing a public, insecure, low-fidelity mechanism for inter-service interactions.

This paper is organized as follows. In section 2 we intro-duce the concept of software as a service, while in section3 we describe the basic service oriented architecture. Sec-tion 4 describes an extended service architecture material-ized by grid services and section 5 introduces the concept ofservice bus for open service marketplaces. Finally, section6 presents our conclusions.

2 A view of software as a service

The concept of software-as-a-service espoused by SOCis revolutionary and appeared first with the ASP (Applica-tions Service Provider) software model. An ASP is a thirdparty entity that deploys, hosts and manages access to apackaged application and delivers software-based servicesand solutions to customers across a wide area network froma central data center. Applications are delivered over net-works on a subscription or rental basis. In essence, ASPswere a way for companies to outsource some or even allaspects of their information technology needs.

By providing a centrally hosted Intent application, theASP takes primary responsibility for managing the soft-ware application on its infrastructure, using the Internet asthe conduit between each customer and the primary soft-ware application. What this means for an enterprise is thatthe ASP maintains the application, the associated infrastruc-ture, and the customer’s data and ensures that the systemsand data are available whenever needed.

Although the ASP model introduced the concept ofsoftware-as-a-service first, it suffered from several inherentlimitations such as the inability to develop highly interac-tive applications, inability to provide complete customiz-able applications [7]. This resulted in monolithic architec-tures, highly fragile, customer-specific, non-reusable inte-gration of applications based on tight coupling principles.Today we are in the midst of another significant develop-ment in the evolution of software-as-a-service architectedfor loosely-coupled asynchronous interactions on the basisof XML-based standards with intention to make access toand communications of applications over the Internet eas-ier.

The SOC paradigm allows the software-as-a-serviceconcept to expand to include the delivery of complex busi-ness processes and transactions as a service, while permit-ting applications be constructed on the fly and services to bereused everywhere and by anybody. Perceiving the relativebenefits of (web) services technology many ASPs are mod-ifying their technical infrastructures and business models tobe more akin to those of web service providers.


0-7695-1999-7/03 $17.00 © 2003 IEEE

3 The basic service oriented architecture

To build integration-ready applications the service modelrelies on the service-oriented architecture (SOA). SOA is away of reorganizing a portfolio of previously siloed soft-ware applications and support infrastructure into an inter-connected set of services, each accessible through standardinterfaces and messaging protocols. Once all the elementsof an enterprise architecture are in place, existing and futureapplications can access these services as necessary withoutthe need of convoluted point-to-point solutions based on in-scrutable proprietary protocols. This architectural approachis particularly applicable when multiple applications run-ning on varied technologies and platforms need to commu-nicate with each other. In this way, enterprises can mix andmatch services to perform business transactions with mini-mal programming effort.

Publish

ServiceProvider

ServiceRegist ry

ServiceClientFind

Bind

Figure 1. The basic Service Oriented Archi-tecture.

SOA is a logical way of designing a software system toprovide services to either end-user applications or other ser-vices distributed in a network through published and dis-coverable interfaces. The basic SOA defines an interac-tion between software agents as an exchange of messagesbetween service requesters (clients) and service providers.Clients are software agents that request the execution of aservice. Providers are software agents that provide the ser-vice. Agents can be simultaneously both service clients andproviders. Providers are responsible for publishing a de-

scription of the service(s) they provide. Clients must ableto find the description(s) of the services they require andmust be able to bind to them.

The basic SOA is not an architecture only about services,it is a relationship of three kinds of participants: the serviceprovider, the service discovery agency, and the service re-questor (client). The interactions involve the publish, findand bind operations [4], see Figure-1. These roles and op-erations act upon the service artifacts: the service descrip-tion and the service implementation. In a typical service-based scenario a service provider hosts a network accessi-ble software module (a implementation of a given service).The service provider defines a service description of the ser-vice and publishes it to a client or service discovery agencythrough which a service description is published and madediscoverable. The service requestor uses a find operation toretrieve the service description typically from a the discov-ery agency, i.e., a registry or repository like UDDI, and usesthe service description to bind with the service provider andinvoke the service or interact with service implementation.Service provider and service requestor roles are logical con-structs and a service may exhibit characteristics of both.

The fundamental logical view of a service in the basicSOA is that it is a service interface and implementation.A service is usually a business function implemented insoftware, wrapped with a formal documented interface thatis well known and known where to be found not only byagents who designed the service but also by agents who donot know about how the service has been designed and yetwant to access and use it. Black box encapsulation inher-its this feature from the principles of modularity in softwareengineering, e.g., modules, objects and components. Ser-vices are different from all of these forms of modularity inthat they represent complete business functions, they are in-tend to be reused and engaged in new transactions not at thelevel of an individual program or even application but at thelevel of the enterprise or even across enterprises. They areintended to represent meaningful business functionality thatcan be assembled into a larger and new configurations de-pending on the need of particular kinds of users particularclient channels.

The interface simply provides the mechanism by whichservices communicate with applications and other services.Technically, the service interface is the description of thesignatures of a set of operations that are available to the ser-vice client for invocation. The service specification mustexplicitly describe all the interfaces that a client of thisservice expects as well as the service interfaces that mustbe provided by the environment into which the service isassembled/composed. As service interfaces of composedservices are provided by other (possibly singular) services,the service specification serves as a means to define howa composite service interface can be related to the inter-


0-7695-1999-7/03 $17.00 © 2003 IEEE

faces of the imported services and how it can be imple-mented out of imported service interfaces. This is shownin Figure 2. In this sense the service specification has amission identical to a composition meta-model that pro-vides a description of how the web-service interfaces in-teract with each other and how to define a new web-serviceinterface (<PrortType>) as a collection (assembly) of ex-isting ones (imported <PrortType>s), see Figure-2. A ser-vice specification, thus, defines the encapsulation boundaryof a service, and consequently determines the granularity ofreplaceability of web-service interface compositions. Thisis the only way to design services reliably using importedservices without knowledge of their implementations. Asservice development requires that we deal with multiple im-ported service interfaces it is useful to introduce this stagethe concept of a service usage interface. A service usageinterface is simply the interface that the service exposes toits clients [10] . This means that the service usage inter-face is not different from the imported service interfaces inFigure-2, it is, however, the only interface viewed by a clientapplication.

Figure-2 distinguishes between two broad aspects of ser-vices: service deployment, which we examined already, ver-sus service realization. The service realization strategy in-volves choosing from an increasing diversity of differentoptions for services, which may be mixed in various com-binations including:

• In house service design and implementation. Once aservice is specified, the design of its interfaces or setsof interfaces and the coding of its actual implementa-tion happens in-house.

• Purchasing/leasing/paying for services. Complex web-services that are used to develop trading applicationsare commercialisable software commodities that maybe acquired from a service provider, rather than im-plemented internally. These types of services are verydifferent from the selling of shrink-wrapped softwarecomponents, in that payment should be on an execu-tion basis for the delivery of the service, rather than ona one-off payment for an implementation of the soft-ware. For complex trading web-services, the serviceprovider may have different charging policies such aspayment per usage, payment on a subscription basis,lifetime services and so on.

• Outsourcing service design and implementation. Oncea service is specified, the design of its interfaces or setsof interfaces and the coding of its actual implementa-tion may be outsourced. Software outsourcings are ad-vantageous in the case of organizations that have be-come frustrated with the shortcomings of their internalIT departments.

• Using wrappers and/or adapters. Non-component im-plementations for services may include database func-tionality or legacy software accessed by means ofadapters or wrappers. Wrappers reuse legacy code byconverting the legacy functionality and encapsulatingit inside components. Adapters use legacy code incombination with newly developed code. This newlydeveloped code may contain new business logic andrules that supplement the converted legacy functional-ity.

Service descriptions are used to advertise the service ca-pabilities, interface, behavior, and quality. Publication ofsuch information about available services (on a service reg-istry) provides the necessary means for discovery, selec-tion, binding, and composition of services. In particular,the service interface description publishes the service signa-ture while the service capability description states the con-ceptual purpose and expected results of the service. The(expected) behavior of a service during its execution is de-scribed by its service behavior description (e.g., as a work-flow process). Finally, the Quality of Service (QoS) de-scription publishes important functional and non-functionalservice quality attributes, such as service metering and cost,performance metrics (response time, for instance), secu-rity attributes, (transactional) integrity, reliability, scalabil-ity, and availability.

Service implementation can also be very involved be-cause in many occasions many organizations rely on sin-gle monolithic programs to represent the single service orservice method implementation. But very often in order tofulfil the functions of a service multiple programs are in-volved, e.g., programs that belong to multiple applicationsof new programs that belong to multiple applications. Ap-plication composition and integration very often is involvedin fulfilling the service. At the logical level of the servicewe do not pay any attention to this. All we need to knowis that there is a business function implemented in softwaresomehow and this is the interface to it. At development timewe care, however, how the service is implemented. morespecifically, what are the methods and the internal construc-tion of the implementation.

The service in the basic SOA is designed in such a waythat it can be invoked by various service clients and is log-ically decoupled from any service caller (loose coupling).Services can be reused and one does not have to look insidethe service to understand what it does. There are no assump-tions of any kind in the service as to what kind of serviceconsumer is using and for what purpose and in what context.In SOA the service is not coupled with its callers, in fact itknows nothing about them. However, the service callers arevery much coupled with the service as they know what theservices are what they call and what they can accomplish. In summary, in SOA service consumers make targeted


0-7695-1999-7/03 $17.00 © 2003 IEEE

Service-realization

Web-serviceImplementation

(outsourced)

Web-servicespecification

Importedweb-service

interfaces

Web-serviceusage

interface

Web-serviceclient

reuse/buybuild/buy

build


(in-house)


(outsourced)

Service-deployment

Service-realization


(outsourced)

Web-servicespecification

Importedweb-service

interfaces

Web-serviceusage

interface

Web-serviceclient

reuse/buybuild/buy

build


(in-house)


(outsourced)

Service-deployment

Figure 2. Service interfaces and implementation.

named calls, they target specific services through specificinterfaces that are exposed by the services and thereforethey are very much dependent on availability and the ver-sion of the service that they are calling.

4 Grid services and the extended service ori-ented architecture

The basic SOA does not address overarching concernssuch as management, service orchestration, service transac-tion management and coordination, security, and other con-cerns that apply to all components in a services architecture.Such concerns are addressed by the extended SOA (ESOA)[11] that is depicted in Figure-3. This layered architectureutilizes the basic SOA constructs as its bottom layer.

The service composition layer in the ESOA encompassesnecessary roles and functionality for the consolidation ofmultiple services into a single composite service. Resultingcomposite services may be used by service aggregators ascomponents (i.e., basic services) in further service composi-tions or may be utilized as applications/solutions by serviceclients. Service aggregators thus become service providersby publishing the service descriptions of the composite ser-vice they create. A service aggregator is a service provider

that consolidates services that are provided by other serviceproviders into a distinct value added service. Service ag-gregators develop specifications and/or code that permit thecomposite service to perform functions that include the fol-lowing:

• Coordination: controls the execution of the componentservices, and manages dataflow among them and to theoutput of the component service (e.g., by specifyingworkflow processes and using a workflow engine forrun-time control of service execution).

• Monitoring: allows subscribing to events or informa-tion produced by the component services, and publishhigher-level composite events (e.g., by filtering, sum-marizing, and correlating component events).

• Conformance: ensures the integrity of the compositeservice by matching its parameter types with those ofits components, imposes constraints on the componentservices (e.g., to ensure enforcement of business rules),and performs data fusion activities.

• QoS composition: leverages, aggregates, and bundlesthe component’s QoS to derive the composite QoS,including the composite service’s overall cost, per-


0-7695-1999-7/03 $17.00 © 2003 IEEE

Composition

Description & Basic Operations

Mana-gement

•Capability•Interface•Behavior•QoS

•Coordination•Conformance•Monitoring•QoS

•Publication•Discovery•Selection•Binding

Service provider

Service client

Service aggregator

performs

publishes

uses

Role actions

becomes

Operations•Assurance•Support

Market•Certification•Rating•SLAs

Service operator

Market maker

Managed services

Composite services

Basic services

Figure 3. The Extended Service Oriented Architecture.

formance, security, authentication, privacy, (transac-tional) integrity, reliability, scalability, and availability.

The recently proposed standard Business Process Exe-cution Language for web services (BPEL) [5] is an XML-based effort to addresses the definition of a new web ser-vice in terms of compositions of existing services. A BPELprocess is defined ”in the abstract” by referencing and inter-linking portTypes specified in the WSDL definitions of theweb services involved in a process.

Managing e-business critical applications requires in-depth administration capabilities and integration across adiverse, distributed environment. Any downtime of keye-business systems has a negative impact on business tothe extent of throwing you out of the market. To countersuch a situation, enterprises need to constantly monitor thehealth of their applications. The performance should bein tune, at all times and under all load conditions. Ap-plication management is thus an indispensable element ofthe ESOA that includes performance management and busi-ness/application specific management.

To manage critical applications/solutions and specificmarkets, ESOA provides managed services in the servicemanagement layer depicted at the top of the ESOA pyra-mid. In particular, ESOA’s operations management func-

tionality is aimed at supporting critical applications that re-quire enterprises to manage the service platform, the de-ployment of services and the applications. Operations man-agement functionality may provide detailed application per-formance statistics that support assessment of the applica-tion effectiveness, permit complete visibility into individualbusiness transactions, and deliver application status notifi-cations when a particular activity is completed or when a de-cision condition is reached. We refer to the organization re-sponsible for performing such operation management func-tions as the service operator. Depending on the applicationrequirements a service operator may be a service client oraggregator.

Operations management is a critical function that can beused to monitor the correctness and overall functionality ofaggregated/orchestrated services thus avoiding a severe riskof service errors. In this way one can avoid typical errorsthat may occur when individual service-level agreements(SLAs) are not properly matched. This fact was illustratedby the failure of the rail network operator in the UK, appar-ently triggered in part by a complete mismatch between theSLAs imposed on the track repair subcontractors and theSLAs and legitimate safety expectations of the train com-panies [3]. Proper management and monitoring provides a


0-7695-1999-7/03 $17.00 © 2003 IEEE

strong mitigation of this type of risk, since the operationsmanagement level allows business managers to check thecorrectness, consistency and adequacy of the mappings be-tween the input and output service operations and aggregateservices in a service composition.

Another aim of ESOA’s service management layer is toprovide support for open service marketplaces. Currently,there exist several vertical industry marketplaces, such asthose for the semiconductor, automotive, travel, and finan-cial services industries. Open service marketplaces oper-ate much in the same way like vertical marketplaces, how-ever, they are open. Their purpose is to create opportunitiesfor buyers and sellers to meet and conduct business elec-tronically, or aggregate service supply/demand by offeringadded value services and grouping buying power (just likea co-op). The scope of such a service marketplace would belimited only by the ability of enterprises to make their offer-ings visible to other enterprises and establish industry spe-cific protocols by which to conduct business. Open servicemarketplaces typically support supply chain managementby providing to their members a unified view of productsand services, standard business terminology, and detailedbusiness process descriptions. In addition, service market-places must offer a comprehensive range of services sup-porting industry-trade, including services that provide busi-ness transaction negotiation and facilitation, financial set-tlement, service certification and quality assurance, ratingservices, service metrics such as number of current servicerequesters, average turn around time, and manage the nego-tiation and enforcement of SLAs. ESOA’s service manage-ment layer includes market management functionality (asillustrated in Figure-3) that is aimed to support these mar-ketplace functions. The marketplace is created and main-tained by a market maker (a consortium of organizations)that brings the suppliers and vendors together. The marketmaker assumes the responsibility of marketplace adminis-tration and performs maintenance tasks to ensure the ad-ministration is open for business and, in general, providesfacilities for the design and delivery of an integrated servicethat meets specific business needs and conforms to industrystandards.

The ESOA service management functions can rely ongrid computing as it targets manageability. One of the aimsof grid computing is the ability to manage ever-growingand ever more complex networks without overheads. Thegrid service domain architecture is a high level abstractionmodel that describes the common behaviors, attributes, andoperations and interfaces to allow a collection of services tofunction as an integral unit and collaborate with others in afully distributed, heterogeneous, grid-enabled environment.Service grids constitute a key component of the distributedservices management as the scope of services expands be-yond the boundaries of a single enterprise to encompass a

broad range of business partners, as is the case in open mar-ketplaces. For this purpose grid services can be used to pro-vide the functionality of the ESOA’s service managementlayer [6], [13].

The principal strengths of web and grid services are com-plementary, with web services focusing on platform-neutraldescription, discovery and invocation, and grid services fo-cusing on the dynamic discovery and efficient use of dis-tributed computational resources. This complementarity ofWeb and Grid Services has given rise to the proposed OpenGrid Services Architecture (OGSA) [6] [13], which makesthe functionality of grid services available through web ser-vice interfaces. Grid services are stateful services that pro-vide a set of well-defined interfaces and follow specific con-ventions to facilitate coordinating and managing collectionsof web service providers/aggregators. The grid service in-dicates how a client can interact with it and is defined inWSDL. The state of the service is exposed to its clientsas a standard interface that addresses web service filtering,discovery, routing, aggregation, selection, data and contextsharing, notification and life-time management.

5 The service grid bus

Grid services used in the ESOA’s service managementlayer to provide an enabling infrastructure for systems andapplications that require the integration and managementof services with the context of dynamic virtual market-places. Grid services provide the possibility to achieve end-to-end qualities of service and address critical applicationand system management concerns. To this end grid ser-vices provide the grid infrastructure over which services in-teract, aggregate, and coordinate through a distinct archi-tectural tier. This infrastructure is called the service gridbus. The service grid bus (SGB) provides a high-level ab-straction architecture and management facilities to allowservices (within an open service marketplace) to functionas an integral unit and collaborate with other services. TheSGB architecture provides facilities for registration, discov-ery, selection/routing, business rules, filtering, routing, ag-gregation, fail-over, and topological mapping of service in-stances. The business rules govern the SGB’s automaticprocessing for incoming service requests over aggregatedservice instances.

The service bus is a logical construct that cares very littlewhere or on what platform a service provider runs. A userinterface, designed to exactly match the business require-ments may consume the services provided by the servicebus, leaving the enterprise a free hand to choose the mostefficient service provider.

An SGB is designed to provide a single service connec-tivity and a management tier that addresses the followingconcerns:


0-7695-1999-7/03 $17.00 © 2003 IEEE

Service

RegistryServiceentry

Serviceentry

Servicedispatching

Servicedispatching

service orchestration engineservice orchestration engine

Management & PolicyManagement & Policy

Service Port TypesService Port Typesgrid services &service implementations

service provisioning, policy-QoS,selection/routing,event monitoring,workflow/transactions

SLAs,security,recovery,business rules, service mapping,discovery,Selection,……..

incoming service request

response

Figure 4. The service grid bus.

• Reach and robustness: The SGB allows to locate ser-vices anywhere in an open service marketplace and in-sulate them from connection failures, errors, and barri-ers such as firewalls, proxies, and caches. It guaranteesthat each service always sees an errorfree connectionto any other service. The application as a whole shouldbe robust under transient or long-term failure of one ormore service components.

• Policy and security management: Services need to de-scribe their capabilities and requirements to their en-vironment and potential users. A collection of ca-pabilities and requirements is referred to as a policy[8]. A policy may express such diverse characteristicsas service transactional capabilities, security, responsetime, pricing, etc. For example, a policy of a servicemay specify that all interactions must be invoked undertransaction protection, that incoming messages have tobe encrypted, that outgoing messages will be signed,that responses may only be accepted within a specifictime interval, etc. Finally, services must be restrictedto authorized producers and consumers. The SGB en-forces the security policy uniformly and universallyacross the entire marketplace.

• Development time and cost: The SGB provides the fa-

cilities that allow services to be easily aggregated intocomposite, higher-level services that match the factor-ing of an application. New services and clients will beadded throughout the lifetime of the application. Thatprocess must be managed quickly, efficiently and costeffectively.

• Scalability and performance: The SGB must be able toperform well despite slow components and long, un-predictable network latencies.

The SGB lets service components interact over any net-work connection, handling all network errors, barriers, andtransient or extended off-line conditions. It provides sup-port for a business transaction model and support mech-anisms for advanced transactional behavior of complexservice-oriented business processes that span organizations[12]. The transaction model allows expressing unconven-tional atomicity criteria, e.g., payment atomicity, conversa-tion atomicity, contract atomicity, and possesses the abilityto express collaborative agreements and business conversa-tion sequences that rely on transactional support. The modelrelies on a phased approach to business transactions so thatall exchange of information between partners on the termsthey could commit to, e.g., to fix price and quantity, arekept outside the ”pure” transaction protocol. This results


0-7695-1999-7/03 $17.00 © 2003 IEEE

in enhancing flexibility and reducing latency and expensivetransaction compensations and rollbacks in business inter-actions. The SGB’s asynchronous communications makesthe application robust under transient service node failures,and allows transparent rerouting in the event of prolongedfailure.

The SGB provides standard, high-level services for se-curity, management, service interaction, and aggregation,greatly accelerating application development and deploy-ment. The SGB should also be consistent with emergingWeb services workflow and transaction standards such asWeb Services Transactions [1], Web Services Coordination[2] and the Business Transaction Protocol (BTP) [9]. Fi-nally, the SGB supports linear scalability and high perfor-mance by offering native support for asynchronous interac-tion, and allowing service endpoints to be managed for loadbalancing, workload distribution, and fail-over. The SGB it-self must be scalable and capable of supporting peak loads.

Figure-4 describes a service sharing and aggregationSGB model for open service marketplaces. The SGB modelallows services and the resources they use to be more eas-ily shared by different constituencies within an open servicemarketplace. With its service grid foundation an open ser-vice marketplace provides the notion of a business servicegrid that automatically dispatches the best service availablefrom a pool of dynamically assembled service providers inorder to meet the user’s need. Selection of a service is notjust based on availability, but can also be based on QoScharacteristics, as specified in SLAs and business arrange-ments. Selection of a service is performed automaticallybased on service policy, and the features provided by theSGB enable service providers to conceal the implementa-tion complexity required to handle multiple client requestsover heterogenous environments.

The SGB invokes a service aggregation module to main-tain its policy and states while serving external service re-quests. This module also performs selection and dispatch-ing to find a service instance to execute a service request.The service aggregation module is also decomposed intomodular functional units so that it is customizable to meetthe special needs of diverse platforms, operations logic andso on.

One of the major benefits of introducing a distinct inte-gration tier in the form of the SGB to implement the ESOA’sservice management layer is the ability to couple in value-added services that provide packaged solutions for commondevelopment needs. The SGB provides an asynchronous in-teraction model that lets users and applications initiate andmonitor multiple tasks and data feeds simultaneously, andimmediately alerts them when a transaction completes ora critical event occurs. In this regard, the SGB allows dy-namic data feeds and transaction events to be delivered tothe users or applications immediately when they occur. The

SGB delivers to users applications that let them view mul-tiple key performance indicators in real-time, collaboratewith other users, and take action when critical events takeplace.

6 Conclusions

In this paper we introduced the concepts behind ServiceOriented Computing and explained how the basic ServiceOriented Architecture helps deliver service-based applica-tions. We argued that in order to provide the advanced func-tionality needed to deliver sophisticated e-business applica-tions an Extended Service Oriented Architecture is neces-sary. This architecture includes a service composition tier tooffer necessary roles and functionality for the consolidationof multiple services into a single composite service. It alsoprovides a tier for service operations management that canbe used to monitor the correctness and overall functional-ity of aggregated/orchesteated services and support for openservice marketplaces. Finally, we explained how grid ser-vices can be used to implement the service management tierof the Extended Service Oriented Architecture by means ofthe service grid bus.

References

[1] F. Cabrera et al, ”Web Services Coordi-nation (WS-Coordination)”, August 2002,http://www.ibm.com/developerworks/library/ws-coor/.

[2] F. Cabrera et al, Web Services Trans-action (WS-Transaction), August 2002,http://www.ibm.com/developerworks/library/ws-transpec/.

[3] CBDI Journal Modeling for SOAwww.cbdiforum.com/, Feb. 2002.

[4] M. Champion, C. Ferris, E. Newcomer, and D. Or-chard Web Services Architecture W3C WorkingDraft, www.w3.org/TR/ws-arch/, Nov. 2002.

[5] F. Curbera, Y. Goland, J. Klein, F. Leyman,D. Roller, S. Thatte, and S. WeerawaranaBusiness Process Execution Language forWeb Services(BPEL4WS) 1.0,” August 2002,http://www.ibm.com/developerworks/library/ws-bpel.

[6] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke.Grid Services for Distributed System Integration.IEEE Computer, 35(6), 2002.

[7] J. Goepfert, M. Whalen An Evolutionary Viewof Software as a Service. IDC White paper,www.idc.com, 2002.

[8] F. Leymann Web Services: Distributed Applicationswithout Limits - An Outline Procs. Of Database Sys-tems for Business, Technology and Web, 2003.


0-7695-1999-7/03 $17.00 © 2003 IEEE

[9] OASIS Committee Specification Business Transac-tion Protocol, version 1.0, May 2002.

[10] M. P. Papazoglou, J. Yang Design Methodology forWeb Services and Business Processes Procs. of the3rd VLDB-TES Workshop, Hong-Kong, 2002.

[11] M. P. Papazoglou, D. Georgakopoulos Service Ori-ented Computing Communications of the ACM, Oc-tober 2003.

[12] M. P. Papazoglou Web Services and Business Trans-actions World Wide Web Journal, vol. 6, March 2003.

[13] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Gra-ham, and C. Kesselman Grid Service Specification.Technical report, Open Grid Service InfrastructureWG, Global Grid Forum, 2002. Draft 5, November 5,2002.

[14] UDDI.org UDDI Technical White paper,http : //www.uddi.org/, 2001

[15] Web Service Definition Language.http://www.w3.org/TR/wsdl.


0-7695-1999-7/03 $17.00 © 2003 IEEE

service -oriented computing: concepts, characteristics and directions · · 2014-11-07service...

Documents