Service-oriented Computing 1 Prof. Dr. Schahram Dustdar Distributed Systems Group Institute of Information Systems

Service-oriented Computing

1

Prof. Dr. Schahram DustdarDistributed Systems Group

Institute of Information Systemshttp://www.infosys.tuwien.ac.at/Staff/sd

http://www.infosys.tuwien.ac.at/Staff/sd

2

Some Service-oriented Approaches

Jini

Jini is a technology for building service oriented architectures Apache River

Key features Written in Java Uses RMI and Java Object Serialization Offers network plug and play of services (java

objects) Differences with respect to RMI

Provides Discovery of Jini Services A federating technology for services

OSGi

A Java framework for developing (remotely) deployed service applications Portable byte code (independent of OS or CPU

architecture) Security integrated in the language

Created through a collaboration of industry leaders IBM, Ericsson, Nokia, Sony, Samsung, Oracle, and

many more Excellent model for the myriad of customizations

and variations that are required for today’s devices

UPNP

UPNP supports Devices and Control Points A device may have multiple Services

Sample Device A TV registers itself as a Device The TV exports a ControlService for volume, power,

channel It exports a Picture service for color, contrast and

brightness

Web services vs. CORBA I

Web services vs. CORBA II

8

Enterprise Application Integration (EAI)

–

The beginning of SOA

9

Enterprise Application Integration

One of the main challenges in IT Applications shall be integrated to work together First step: application bridge

Hooks into source application Transforms data Invokes target application

Problems: Heterogeneity Distributed systems Quality of service Target Application

Bridge

Source Application

10

Asynchronous request/reply messaging

Most asynchronous messaging mechanisms follow the “fire-and-forget” messaging principle where the sending application can conduct its work as usual once a message was asynchronously sent. The sending application assumes that the message will arrive safely

at its destination at some point in time. This mode of messaging does not preclude the necessity to perform

request/reply operations.

Message channelmessagemessage messagemessage

Message channelmessagemessage messagemessageRequesterRequester ReplierReplier

requestrequestrequestrequest

replyreplyreplyreply

11

Target Environment

Adapters/Message Queuing

Solution: split bridge into two adapters

Source adapter Hooks into source application Puts data in message queue of target

adapter Target adapter

Transforms message into data for target application

Invokes target application Message queuing middleware

QoS Scaling

Target Application

Message Queuing

Source Environment

Target Adapter

Source Application

Source Adapter

12

Neutral Message Format

Each target application needs separate target adapters to process the different source message formats

Adapters for each application pair Complexity n*n

First improvement: neutral message format Adapters transform data to/from

neutral format Complexity n+n

13

Message Broker

Further improvement: message broker middleware On top of message queuing Identifies and transforms messages Routes to target Simplifies adapter creation

Provides additional benefits: Transformations can reflect corporate policies Publish/subscribe dynamic environments

However: Complex to implement and maintain Expensive software licenses

14

Message-oriented Middleware

MOM is an infrastructure that involves the passing of data between applications using a common communication channel that carries self-contained messages.

Messages are sent and received asynchronously. The messaging system (integration broker) is responsible for

managing the connection points between clients & for managing multiple channels of communication between the connection points.

ClientClient ServerServerClientClient

MOMMOM MOMMOM MOMMOM

Application logicApplication logic MessageMessagenotificationnotification

MessageMessagepublicationpublication

MOM Integration BrokerMOM Integration Broker

15

Message-oriented Middleware (cntd)

MOM provides the following functions: event-driven processing, i.e., the publish/subscribe model. reliability and serialization of messages. subject-based (textual) names and attributes to abstract from physical

names and addresses. multiple communications protocols, e.g., store & forward, request/reply,

publish/subscribe. An integration broker is an application-to-application

middleware service capable of one-to-many, many-to-one & many-to-many message distribution. It records & manages the contracts between publishers & subscribers of

messages. An integration brokers provides the following functions:

message transformation, business rules processing, routing services, naming services, adapter services, repository services, events & alerts.

16

EAI and MoM (cntd)

EAI uses a fast, robust communications backbone with integration broker technology, business process workflow, facilities & tools.

Integration brokers are used for message process flow & are responsible for brokering messages exchanged between two or more applications.

They provide the ability to transform, store & route messages apply business rules & respond to events.

CRM ERP Logistics

Sales AutomationOrderManagement

Accounting

MOM & Integration BrokerMOM & Integration Broker

AdapterAdapter AdapterAdapterAdapterAdapter

AdapterAdapter AdapterAdapterAdapterAdapter

17

Publish/Subscribe Messaging

The application that produces information publishes it and all other applications that need this type of information, subscribe to it. Messages containing the new information are placed in a queue for each subscriber by the publishing application.

Each application may have a dual role: it may act as a publisher or subscriber of different types of information.

PublisherPublisherMessaging ClientMessaging Client








Mes

sage

ser

vice

bac

kbon

eM

essa

ge s

ervi

ce b

ackb

one

Mes

sage

ser

vice

bac

kbon

eM

essa

ge s

ervi

ce b

ackb

one

TopiTopi

ToTopipi

TopicTopic

TopiTopi

ToTopipi

TopicTopic

TopiTopi

ToTopipi

TopicTopic

TopiTopi

ToTopipi

TopicTopic

SubscriberSubscriberMessaging ClientMessaging Client
























Message serverMessage server

Service-Oriented Computing and Web Services

19

Some good references…

20

Service-oriented Computung (SoC)

21

Vision and Principles Programmatic interactions between autonomous systems

(e.g., EAI, B2B Interactions, Access to Internet Resources and applications)

Web services: self-contained Software Entities which are published, discovered, and invoked on the Internet. XML-based languages are used -> loose coupling of systems

Virtualization of Resources, Utilization and consolidation of Internet-based infrastructure

Agile Development of integrated systems through service composition

Services can be provided and consumed everywhere, from servers to mobile devices

22

What is a Service?

Standardized interface

Self-contained with no dependencies to other services

available

Little integration need

Coarse-grained

Context-independent Services themselves have context

Allows for Service Composition

Quality of Service (QoS) Attributes which can be measured

23

Service-oriented System…one example

Today: Amazon or Google Web service

Future?

Which credit is the right one for me?

Credit-Management is part of an overall larger system, i.e., what about Insurance options protecting me? Repayment modalities combined with saving modalities? …

The system is open and dynamic: Interest rate changes My status changes (e.g., illness, debt, etc.) With each change the process starts all over again; how often? …

24

Software Services

Equivalent to real-world services Software services should align with business

functions/real-world services Service properties apply to software services too Implementation of services does not matter Complex applications are built by combining

services (Service Composition)

25

Software Services…

…are self-contained, modular applications that can be Described Published Found Bound Invoked Composed

26

Context and State

Services are context independent Do not depend on the context in which they are used E.g. it does not matter to a taxi driver why the

passenger wants to get to the destination

Not necessarily stateless Loosely coupled

Services can be reused in new contexts Customers are not restricted to one predetermined

supplier

27

What is SOA?

Architectural style of software design Guides all aspects of creating and using

services Also: a way to design an IT infrastructure Main paradigms: loose coupling, dynamic

binding, high interoperability Basic Architecture: publish/find/bind

28

Roles

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 (requestors) (end-user organizations that use some service);

service registry a searchable directory where service descriptions can be published and searched. Service requestors find service descriptions in the registry and

obtain binding information for services. This information is sufficient for the service requestor to

contact, or bind to, the service provider and thus make use of the services it provides.

29

ServiceRegistry/Broker

ServiceRegistry/Broker

ServiceProvider

ServiceProvider

ServiceRequest

or

ServiceRequest

orRequirements

ServiceSpecification

Publish

Service-Oriented Architecture


Service

InteractionModel

Query

Request Response


Requirements

30

Application Service Providers The concept of software-as-a-service is evolutionary & appeared

first with the ASP (Application Service Provider) software model:

an ASP “rents” applications to subscribers.

The whole application is developed in terms of the user interface, workflow, business and data components that are all bound together by the ASP provider to provide a working solution.

An ASP hosts the entire application & the customer has little opportunity to customize it beyond the appearance of the user interface, e.g., adding company logos.

An alternative of this is where the ASP is providing a software module that is downloaded to the customer’s site on demand

31

ASP vs. Web Services

Although the ASP model introduced the concept of software as-a-service first, it suffered from several inherent limitations such as:

inability to develop highly interactive applications, inability to provide complete customisable applications & inability to integrate applications

Today we are in the midst of another significant development in the evolution of software-as-a-service. The new architecture allows for:

loosely-coupled asynchronous interactions on the basis of eXtensible Markup Language (XML) standards with the intention of making access to, and communications

between, applications over the Internet easier, by means of appropriate standards

32

Are ASP, Software as a Service, & Web Service the same?

Access Service

View in Browser

Download on Demand

Typical ASP

Name

No.

Zip

State

OK Cancel

Name

No.

Zip

State

OK Cancel

Software as a Service

Web Services

Adapted from: CBDi forum

Name

No.

Zip

State

OK Cancel

Name

No.

Zip

State

OK Cancel

App. solution providerApp. solution provider

Name

No.

Zip

State

OK Cancel

CustomerCustomer

(composition, repackaging, differentiation,

added value services)

Application runs here

Application runs here

Application runs partly here

Application runs partly here

33

Describe Describe ServicesServices

Discover Discover ServicesServices

IntegrateIntegrateServicesServicesTogetherTogether

A mid-sized manufacturer A mid-sized manufacturer needs to create online needs to create online relationships with customers, relationships with customers, each with their own set of each with their own set of standards and protocolsstandards and protocols

BroaderBroaderB2BB2B

A high-tech manufacturer A high-tech manufacturer needs toneeds to easily integrate and easily integrate and synchronize third-party synchronize third-party providers with itsproviders with itsmanufacturing and manufacturing and distribution requirementsdistribution requirements..

Easier Easier AggregationAggregation

SearchSearchCapabilitiesCapabilities

To To meet its on-time delivery meet its on-time delivery commitmentscommitments a high-tech a high-tech manufacturers needs to place manufacturers needs to place orders with the most orders with the most advantageous parts advantageous parts manufacturer or assemblermanufacturer or assembler

What problems do we solve?

34

Types of Web Services

Informational services are services of relatively simple nature. They either provide access to content interacting with an end-user by means of simple request/response sequences, or expose back-end business applications to other applications. Examples include:

Content services such as weather report info., simple financial info., stock quote info., news items Simple trading services that can provide a seamless aggregation of information across disparate systems & data sources.

Complex services that involve the assembly & invocation of many pre-existing services possibly found in diverse enterprises to complete a multi-step business interaction:

a supply-chain application involving order taking, stocking orders, sourcing, inventory control,

financials and logistics.

35

Service Properties & State

Functional & non-functional properties: The functional service description details the operational characteristics

that define the overall behavior of the service, The non-functional description targets service quality attributes, e.g.,

service metering and cost, performance metrics (response time or accuracy), security, authorization, authentication, scalability, & availability, etc.

Stateless or stateful services: Services that can be invoked repeatedly without having to maintain

context or state are called stateless. Simple informational services are stateless.

Services that require their context to be preserved from one invocation to the next are called stateful.

Complex services (business processes) typically involve stateful interactions.

36

Loose Coupling & Granularity

Loose Coupling: Coupling indicates the degree of dependency any two systems

have on each other. Web services are loosely coupled: they connect and interact more

freely (across the Internet). They need not know how their partner applications behave or are implemented.

Service granularity: Simple services are discrete in nature, exhibit normally a

request/reply mode of operation & are of fine granularity, i.e., they are atomic in nature.

Complex services are coarse-grained, e.g., a SubmitPurchaseOrder process. These involve interactions with other services and possibly end-users in a single or multiple sessions.

Coarse-grained communication implies larger and richer data structures, (viz. those supported by XML).

37

Synchronicity & Well-definedness

Sychronicity: there are two programming styles for services: synchronous or remote procedure call (RPC)-style: Clients of

synchronous services express their request as a method call with a set of arguments, which returns a response containing a return value.

Simple informational services, e.g., 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.

asynchronous or message (document)-style: When a client invokes a message-style service, it typically sends an entire document, e.g., a purchase order, rather than a discrete set of parameters.

Business processes, e.g., a purchase order; responding to a request for quote order from a customer; or responding to an order placement by a particular customer.

Well-definedness: The service interaction must be well-defined. The Web Services

Description Language allows applications to describe to other applications the rules for interfacing and interacting.

38

Service Interface & Implementation

The service interface defines service functionality visible to the external world and provides the means to access this functionality. The service describes 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 determine what it does, how to invoke its functionality, & what result to expect in return.

The service implementation realizes a specific service interface whose implementation details are hidden from its users. Different service providers using any programming

language of their choice may implement the same interface.

39

Perspectives

Interface

Implementation

What does it

do?

How to represent it (business requs)

How do I use it?

Where can I find

it?

Where to host itHow to

publish it

How to build it

Client Perspective

Provider Perspective

40

Deployment/Realization

Service-realizationService-realization

Web-serviceImplementation

(outsourced)

Web-serviceorchestration

interface

Imported web-service

interfaces

Web-service usage

interface

Web-serviceclient

reuse/buybuild/buy

build


(in-house)


(outsourced)

Service-deploymentService-deployment

41

SOA Framework

Transport Protocols Transport

Messaging Protocol, Addressing Messaging

Interface + Bindings Policy Description

Discovery, N

egotiation

Transactions

CompositionOrchestration

Reliable Messaging

Quality of Service

Security

Choreography

42

Service Characteristics (1)

Loosely coupled Interface coupling (implementation details hidden) Technology coupling (platform independent) Process coupling (reusable in different business

processes) Well-defined service contracts Meaningful level of abstraction Based on standards

Interface Data model Process model

43

Service Characteristics (2)

Predictable service-level agreements (SLAs)

Dynamic and Discoverable Consumable without provider intervention where

possible Minimal intervention when needed (e.g. subscription)

44

Service Level Agreements (SLAs)

An SLA is a formal agreement (contract) between a provider and client, formalizing the details of use of a Web service (contents, price, delivery process, acceptance and quality criteria, penalties, etc in measurable terms) in a way that meets the mutual understandings and expectations of both providers & clients.

An SLA may contain the following parts: purpose parties validity period scope restrictions service-level objectives penalties exclusion terms administration authority

45

Quality of Service (QoS)

QoS refers to the ability of a Web service to respond to expected invocations & perform them at the level commensurate to the mutual expectations of both its provider & its customers.

The key QoS attributes in a Web services environment are: availability accessibility conformance to standards integrity performance reliability scalability security transactionality

46

Components vs. Services

Components

Tight coupling Client requires library

Client / Server Extendable Stateless

Fast Small to medium

granularity

Services

Loose coupling Message exchanges Policy

Peer-to-peer Composable Context independent

Some overhead Medium to coarse

granularity

47

Technical Benefits

Efficient development Promotes modularity (loose coupling) Easy to divide and assign to different developers Requestor implementation does not need internal information

More reuse Loose coupling Standards-based

Simplified maintenance Interface is independent of implementation

Incremental adoption Relatively easy to implement incrementally Can co-exist with legacy software (and still provide benefits) Allows step-by-step migration

48

Business Benefits (1)

Increased business agility Finding the right service Changing service providers Quick assembling of services into application Supporting new service requestors and delivery channels Dynamically adjusting capacity Using existing services to support new requirements

Better business alignment Service usage and utilization metrics Service-level agreements

Customer satisfaction Consistent experience across interfaces

49

Business Benefits (2)

Reduced integration costs Application integration main area of application Loose coupling Platform independence

Reduced dependency on technology and vendors Application platform (e.g. J2EE, .NET) Packaged applications (e.g. SAP) Middleware technology (e.g. CORBA) Product features (e.g. Stored Procedures)

50

Challenges

Staff training Maintain discipline

Services must be developed for long-term benefit, not only immediate benefit

Definition of reusable services is non-trivial Relatively high short-term costs

Define business processes Create specifications Develop code Management

Need to modify some legacy applications No callable interfaces Only accessible via file transfer …

51

Possible Solution

Step-by-step migration to SOA Find and implement specific instances where services

provide immediate benefits Lay foundation for service-oriented architecture in

department or enterprise Add to SOA as expedient

Caveat: maintaining discipline becomes even harder

52

SOA Technologies

SOA can be built using: Distributed object middleware (e.g. CORBA, J2EE,

COM/DCOM) Message-oriented middleware (e.g. IBM WebSphere MQ) TP monitors (e.g. CICS) Custom middleware B2B platforms (e.g. ebXML, RosettaNet) Web services

Most of these are not ideal for SOA Only few installations of conventional middleware

actually implement a service-oriented architecture

53

Web Services

One possible implementation technology

for SOA

54

What are Web Services?

SOA: abstract architectural concept (!= Web services)

Web services: one approach to realizing SOA Not a “replacement” technology (at least today):

Not a new programming language Not a new middleware system Not directly “executable” (needs execution

environment)

XML-based interface technology

55

Web Service - Definition

“A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL).

Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”

- W3C (http://www.w3.org/TR/ws-gloss/)

56

Well suited for SOA

Based on Web standards XML and XML Schema for data representation HTTP as transport protocol

Relatively simple Platform independent Pervasive Standardized (W3C, OASIS, …) Embraced by the IT industry

57

Reliable Messaging

WS-Reliable Messaging

SOA FrameworkCore Web Service StandardsWeb Service Framework

Discovery, N

egotiation

Messaging Protocol, AddressingSOAP

Policy

Transactions

Orchestration

Security

Choreography

SOAP, WS-Addressing

UD

DI

UD

DI, W

S-A

ddressing,W

S-M

etaDataE

xchange

WS-Policy

WS-TransactionWS-Coordination

BPEL4WS

WS-Security

WS-CDL

Transport Protocols

Interface + BindingsWSDL

TCP/IP, HTTP, SMTP, FTP, … Transport

Messaging

Description

Composition

Quality of Service

58

UDDI Registry

UDDI Registry

ServiceProvider

ServiceProvider

ServiceRequest

or

ServiceRequest

orRequirements

WSDL Specification

Publish

Core Web Service Architecture

WSDLSpecification

SOAP

Query

Request Response

WSDLSpecification

Web ServiceRequirements

59

Standards

Core standards (SOAP, WSDL, UDDI) describe basic parts of Web service platform

Designed with extensibility in mind Extended specifications provide additional

features, for example: Flexible addressing Non-functional descriptions Quality of Service (reliable messaging, security,

coordination, transactions) Choreography Orchestration

60

SOAP

Originally: Simple Object Access Protocol XML-based messaging protocol Defines

Simple enveloping mechanism Processing model for messages Extensibility scheme Binding mechanism for transport protocols Attachment of non-XML encoded information

61

WSDL

Web Services Description Language XML vocabulary to describe Web services Highly extensible and adaptable Two parts:

Abstract: operations behavior (“what?”) Concrete: binding, service (“how?”, “where?”)

62

UDDI

Universal Description, Discovery and Integration Flexible directory/registry service for Web

services Services described using WSDL and accessed

using SOAP Original vision: public directory

Companies register provided Web services Other companies dynamically discover and use these

Not (yet) fully realized Meanwhile: intra-enterprise directories

63

Web Services…

…are self-contained, modular applications that can be Described: WSDL Published: to UDDI Found: in UDDI Bound: using SOAP Invoked: using SOAP Composed: Orchestration (e.g. BPEL)

64

Extended Specifications (1)

WS-Addressing Interoperable, transport-independent way of

identifying message senders and receivers WS-Policy

Define constraints, conditions, service-level assurances and requirements

Attach these policies to Web services usingWS-PolicyAttachment

WS-MetaDataExchange Dynamic exchange of WS-Policy and other metadata Between endpoints, no registry involved

65


Quality of Service Specifications WS-Security

Security Framework using existing security models(e.g. Kerberos, X.509)

WS-ReliableMessaging In-order delivery At least once delivery At most once delivery

WS-Coordination General mechanism for coordinating multiparty, multi-message Web

service tasks WS-Transaction

WS-AtomicTransaction: short duration (2-phase commit) WS-BusinessActivity: longer duration activities (requires

compensation techniques)

66


WS-CDL (Web Services Choreography Description Language) Describes how services work together

BPEL (Business Process Execution Language for Web Services) Provides orchestration for Web services Definition and execution of business processes Allows the recursive creation of larger Web services

from smaller ones

67

Orchestration

OCustomerOProducer OSupplier1 OSupplier2

Chebbi, I., Dustdar, S., Tata, S. (2005). The view-based approach to dynamic inter-organizational workflow cooperation. Data and Knowledge Engineering, Elsevier, Vol. 56,(2), pp. 139-173, 2006.

http://www.infosys.tuwien.ac.at/Staff/sd/papers/TheView-basedApproachToDynamicInter-organizationalWorkflowCooperation_DKE.pdf


68

Choreography Chebbi, I., Dustdar, S., Tata, S. (2005). The view-based approach to dynamic inter-organizational workflow cooperation. Data and Knowledge Engineering, Elsevier, Vol. 56,(2), pp. 139-173, 2006.



69

Adoption

Designed for step-by-step adoption Core standards usable without extended

specifications Extended specifications provide additional features

SOAP, WSDL and (partially) UDDI already in widespread use

State of extended specifications varies Broad vendor support, including industry

heavyweights IBM and Microsoft

70

Example

71

Example Overview

Example company: travel agency “Service-Oriented Travel” (SOT)

Services provided to customers: Organization of trips (holiday, business, …) Handling of all relevant aspects (flight, hotel, rented car, …)

Suppliers: Airlines Hotels Car rental services …

Objective: Implement SOA with Web services internally Connect to suppliers using Web services

72

Benefits to Customers

Quicker response time Many steps automated No waiting for slow employees of SOT itself or

suppliers to get tasks done

Greater accuracy Employee in the office, at the telephone, and online

service use same software service to get information No more cases of uninformed employees

73

Benefits to Travel Agency

Faster reaction to changes in supply market Loose coupling Standards-based

Improved customer satisfaction Cost savings

No employees needed to manage hotel reservations, booking of flights, car rental

Quicker response time (suppliers) Greater accuracy (suppliers) Benefits to suppliers are much the same

74

Benefits of SOA

Benefits only fully realized once company itself and all suppliers have implemented SOA (or at least external Web services)

However: Number of short-term benefits Step-by-step introduction reduces negative impact Longer-term benefits increase with time

75

Summary

76

Summary SOA (1)

Software services similar to real-world services SOA: abstract architectural concept Architecture: publish/find/bind Technical benefits:

Efficiency Reuse Maintenance Incremental adoption

Business benefits: Agility Alignment Customer satisfaction Integration costs Dependence

77

Summary SOA (2)

Challenges: Training/Skills Discipline Short-term costs Legacy applications

Possible solution: step-by-step adoption

78

Summary Web Services (1)

One approach for SOA XML-based interface technology Properties:

Based on Web standards Relatively simple Platform independent Pervasive Standardized (W3C, OASIS, …) Embraced by the IT industry

79

Summary Web Services (2)

Core standards: SOAP WSDL UDDI

Extensibility Extended specifications:

WS-Adressing WS-Policy WS-MetaDataExchange QoS: WS-Security, WS-ReliableMessaging, WS-Coordination,

WS-Transaction WS-CDL BPEL4WS

Adoption: step-by-step, core standards widely used

80

Thanks for your attention!

Prof. Dr. Schahram DustdarDistributed Systems GroupInstitute of Information SystemsVienna University of TechnologyAustria

http://www.infosys.tuwien.ac.at/Staff/sd/

http://www.infosys.tuwien.ac.at/Staff/sd/

Documents

Service-oriented Computing 1 Prof. Dr. Schahram Dustdar Distributed Systems Group Institute of Information Systems