Advanced Internet Computing

1

Prof. Dr. Schahram Dustdar Distributed Systems Group

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

Some scientific journals

2

ACM Transactions on Internet Technology (TOIT) is the premier multi-disciplinary scholarly journal on Internet/Web foundational and application technology and on social issues and public policy. Internet/Web technology encompasses many disciplines in computing, including computer software engineering, computer programming languages, middleware, management of unstructured, semi-structured and structured data, security, electronic commerce, knowledge discovery and data mining, multimedia data management, networking and distributed systems, communications, performance and scalability, etc.

3

Complexity, Interaction, Autonomy !  Heterogeneous systems increasingly connected

!  Integration becomes more complex

!  Software – and Hardware-Architects cannot plan for all potential interactions upfront !  Increased interaction dynamics of systems and processes

(people and software services)

!  Autistic software vs. Autonomic software

!  Monitoring and Management of Internet-scale infrastructures becomes paramount -> shift to runtime

!  Autonomic & Services Computing including e.g.,: !  Self-Healing !  Self-Configuring !  Self-Optimizing !  Self-Protecting !  … !  Self-* properties

What‘s wrong with the Internet?

!  It is much too difficult to build, deploy and maintain Internet-based systems

!  In the future, application software will need to address:

!  . . . complexity !  . . . interoperability !  . . . trustworthyness !  . . . robustness !  . . . Ease of use !  . . . Ease of maintainance

4

5

Infrastructure Evolution

!  Today, AC principles applied on systems level

!  Future, AC principles also need to be applied to higher levels of the software stack

6

Software Evolution !  Requirements cannot be fully gathered upfront or be frozen !  Too many stake-holders started arising

!  Requirements intrinsically decentralized, complete control and pre-plan illusory

!  When changed, impact whole product/process/service

!  Evolution is intrinsic to software !  it is NOT a “post-delivery” nuisance

!  There is still one assumption !  We own our modules and our components!

1.  Process-driven and MDD approaches to master complexity and enterprise-scale change: Model/build once -> use many times by many service consumers)

2.  User-driven composition, Mashup approach for small-scale: Build once -> use once)

Open-world assumption

!  Crucial in emerging domains! !  Ambient intelligence, context aware applications, pervasive

computing

!  Services become key actors !  Resources are made available on a network as services

(SaaS) !  Loosely coupled !  Accessed on demand

!  Key aspects: !  Services are owned by other people !  Not under our jurisdiction

8

Production Support

Sales

R & D

Processes Evolution

9

Teamwork Evolution

10

4 Evolutions ‒ Implications

Infrastructure/Software/Processes/Teamwork – Evolutions

!  Dependencies between parts of systems are no longer fixed and predetermined !  Human team activities and team forms !  Software services !  Interactions between teams and services on infrastructures

!  Ability to deal with context changes and unanticipated events and people !  self-* behaviors:

e.g., self-adapting, self-organizing

!  Internet of Things: Support active objects providing service, such as !  taggable objects (e.g., RFID, NFC) !  artifacts !  Sensor composition and sensor networks

eHealth & Smart Health networks

Game Machine

Telephone

PC

DVD

Audio

TV STB DVC

Smart Homes

Smart eGovernments & eAdministrations Smart Energy

Networks

Future Internet - Smart *.*

Smart Transport Networks

Draft Report of the Task Force on Interdisciplinary Research Activities applicable to the Future Internet (Version 4.1 of 13.07.2009) has been published on http://www.future-internet.eu

12

Mastering Complexity in the Future Internet

Top-down approach: Process-driven (incl. service composition) and MDD approaches to master complexity and enterprise-scale change: !  model/build once -> use many times by

many service consumers)

Bottom-up approach: User-driven composition, Mashup approach for small-scale: !  build once -> use once

Infrastructure/Software/Process/Teamwork Evolution

13

Future Internet - Assumptions

!  Context-aware collaboration !  context models describing the activity scopes

!  Connecting widely distributed actors !  Service-oriented Architectures (SOA)

!  Dynamically find and use services !  need for trust in services

!  Dynamically find and collaborate with humans !  need for trust in humans

14

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

20

Enterprise Application Integration (EAI)

–

The beginning of SOA

21

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

22

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 channel

Message channel

23

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

24

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

25

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

26

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.

MOM Integration Broker

27

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.

28

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 Automation Order Management Accounting

Adapter Adapter Adapter

Adapter Adapter Adapter

29

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.

Service-Oriented Computing and Web Services

31

Some good references…

32

Service-oriented Computung (SoC)

33

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

34

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

35

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? !  … 36

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)

37

Software Services…

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

38

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

39

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

40

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.

41

Service Registry/ Broker

Service Provider

Service Requestor

Requirements

Service Specification

Publish

Service-Oriented Architecture

Service Specification

Service

Interaction Model

Query

Request Response

Service Specification

Requirements

42

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

43

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

44

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

Name No. Zip State

OK Cancel

(composition, repackaging, differentiation, added value services)

Application runs here

Application runs here

Application runs partly here

Application runs partly here

45

What problems do we solve?

46

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.

47

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. 48

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).

49

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.

50

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.

51

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 it How to

publish it

How to build it

Client Perspective

Provider Perspective

52

Deployment/Realization

Web-service Implementation

(outsourced)

Web-service orchestration

interface

Imported web-service interfaces

Web-service usage

interface

Web-service client

reuse/buy build/buy

build

Web-service Implementation

(in-house)

Web-service Implementation

(outsourced)

53

SOA Framework

Transport Protocols Transport

Messaging Protocol, Addressing Messaging

Interface + Bindings Policy Description

Discovery, N

egotiation

Transactions

Composition Orchestration

Reliable Messaging

Quality of Service Security

Choreography

54

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

55

Service Characteristics (2)

!  Predictable service-level agreements (SLAs)

!  Dynamic and Discoverable !  Consumable without provider intervention where

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

56

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

57

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

58

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

59

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

60

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

61

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)

62

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 !  …

63

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

64

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

65

Web Services

One possible implementation technology

for SOA

66

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

67

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/)

68

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

69

Reliable Messaging

WS-Reliable Messaging

SOA Framework Core Web Service Standards Web Service Framework

Discovery, N

egotiation

Messaging Protocol, Addressing SOAP

Policy

Transactions

Orchestration

Security

Choreography

SOAP, WS-Addressing

UD

DI

UD

DI, W

S-Addressing,

WS

-MetaD

ataExchange

WS-Policy

WS-Transaction WS-Coordination

BPEL4WS

WS-Security

WS-CDL

Transport Protocols

Interface + Bindings WSDL

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

Messaging

Description

Composition

Quality of Service

70

UDDI Registry

Service Provider

Service Requestor

Requirements

WSDL Specification

Publish

Core Web Service Architecture

WSDL Specification

SOAP

Query

Request Response

WSDL Specification

Web Service Requirements

71

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

72

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

73

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?”)

74

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

75

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)

76

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 using WS-PolicyAttachment

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

77

Extended Specifications (2)

!  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)

78

Extended Specifications (3)

!  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

79

Orchestration OCustomer

OProducer 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.

80

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.

81

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

82

Example

83

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

84

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

85

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

86

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

87

Summary

88

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

89

Summary SOA (2)

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

!  Possible solution: step-by-step adoption

90

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

91

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

92

Thanks for your attention!

Prof. Dr. Schahram Dustdar Distributed Systems Group Institute of Information Systems Vienna University of Technology Austria

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