Скачать презентацию Service-oriented Computing Prof Dr Schahram Dustdar Distributed Systems Скачать презентацию Service-oriented Computing Prof Dr Schahram Dustdar Distributed Systems

e85a7b953c3ebc99de38facfecb83abe.ppt

  • Количество слайдов: 80

Service-oriented Computing Prof. Dr. Schahram Dustdar Distributed Systems Group Institute of Information Systems http: Service-oriented Computing Prof. Dr. Schahram Dustdar Distributed Systems Group Institute of Information Systems http: //www. infosys. tuwien. ac. at/Staff/sd 1

Some Service-oriented Approaches 2 Some Service-oriented Approaches 2

Jini § Jini is a technology for building service oriented architectures § Apache River 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 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 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 Control. Service for volume, power, channel § It exports a Picture service for color, contrast and brightness

Web services vs. CORBA I Web services vs. CORBA I

Web services vs. CORBA II Web services vs. CORBA II

Enterprise Application Integration (EAI) – The beginning of SOA 8 Enterprise Application Integration (EAI) – The beginning of SOA 8

Enterprise Application Integration § One of the main challenges in IT § Applications shall 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: Source Application Bridge § Heterogeneity § Distributed systems § Quality of service Target Application 9

Asynchronous request/reply messaging § Most asynchronous messaging mechanisms follow the “fire-andforget” messaging principle where Asynchronous request/reply messaging § Most asynchronous messaging mechanisms follow the “fire-andforget” 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. request message request Message channel reply Requester message reply Message channel 10 message Replier

Adapters/Message Queuing § Solution: split bridge into two adapters § Source adapter § Hooks Adapters/Message Queuing § Solution: split bridge into two adapters § Source adapter § Hooks into source application § Puts data in message queue of target adapter § Transforms message into data for target application § Invokes target application § Message queuing middleware § Qo. S § Scaling Source Environment Source Application Source Adapter Message Queuing Target Adapter Target Application Target Environment 11

Neutral Message Format § Each target application needs separate target adapters to process the 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 12

Message Broker § Further improvement: message broker middleware § § On top of message 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 13

Message-oriented Middleware § MOM is an infrastructure that involves the passing of data between 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. Application logic MOM Server Client Message publication Message notification MOM Integration Broker 14 MOM

Message-oriented Middleware (cntd) § MOM provides the following functions: § event-driven processing, i. e. 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. 15

EAI and Mo. M (cntd) § EAI uses a fast, robust communications backbone with EAI and Mo. M (cntd) § EAI uses a fast, robust communications backbone with integration broker technology, business process workflow, facilities & tools. Order Management § Integration brokers are used for message process flow & are responsible for brokering messages exchanged between two or more applications. Adapter transform, store & route messages apply business rules & respond to events. Adapter Sales Automation Adapter MOM & Integration Broker § They provide the ability to § § Accounting Adapter CRM 16 Adapter ERP Adapter Logistics

Publish/Subscribe Messaging § The application that produces information publishes it and all other applications Publish/Subscribe Messaging § The application that produces information publishes it and all other applications that need this type of information, subscribe to it. Message server Message service backbone Publisher Messaging Client § Each application may have a dual role: it may act as a publisher or Publisher subscriber of Messaging Client different types of information. Subscriber Messaging Client Subscriber Messaging Client Topic To pi Topi 17 Message service backbone Topic To pi Topi § Messages containing Publisher Messaging Client the new information are placed in a queue for each subscriber by the Publisher publishing application. Messaging Client Subscriber Messaging Client Subscriber Messaging Client

Service-Oriented Computing and Web Services Service-Oriented Computing and Web Services

Some good references… 19 Some good references… 19

Service-oriented Computung (So. C) 20 Service-oriented Computung (So. C) 20

Vision and Principles § Programmatic interactions between autonomous systems (e. g. , EAI, B Vision and Principles § Programmatic interactions between autonomous systems (e. g. , EAI, B 2 B Interactions, Access to Internet Resources and applications) § Web services: self-contained Software Entities which are published, discovered, and invoked on the Internet. XMLbased 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 21

What is a Service? § Standardized interface § Self-contained with no dependencies to other 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 (Qo. S) Attributes which can be 22 measured

Service-oriented System …one example § Today: Amazon or Google Web service Future? § Which 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? § … 23

Software Services § Equivalent to real-world services § Software services should align with business 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) 24

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

Context and State § Services are context independent § Do not depend on the 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 26

What is SOA? § § Architectural style of software design Guides all aspects of 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 27

Roles § The service model allows for a clear distinction to be made between: 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. 28

Service-Oriented Architecture Service Specificatio n Service Registry/ Broker Query Requireme nts Publish Service Specificatio Service-Oriented Architecture Service Specificatio n Service Registry/ Broker Query Requireme nts Publish Service Specificatio Interaction Service n Model Servic Request Provider e Request Response or 29

Application Service Providers § The concept of software-as-a-service is evolutionary & appeared first with 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 30

ASP vs. Web Services § Although the ASP model introduced the concept of software ASP vs. Web Services § Although the ASP model introduced the concept of software as-aservice 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 e. Xtensible Markup Language (XML) standards § with the intention of making access to, and communications between, applications over the Internet easier, by means of appropriate standards 31

Are ASP, Software as a Service, & Web Service the same? App. solution provider Are ASP, Software as a Service, & Web Service the same? App. solution provider Customer Name No. Name Zip State OK View in Browser Cancel No. Zip State OK Typical ASP Cancel Application runs here Name No. Zip State OK Cancel Application runs here Download on Demand Name No. Zip State OK Cancel Software as a Service Name No. Zip State OK Access Service Cancel Web Services Application runs partly here (composition, repackaging, differentiation, added value services) Adapted from: CBDi forum 32 Application runs partly here

What problems do we solve? Broader B 2 B Search Capabilities Easier Aggregation A What problems do we solve? Broader B 2 B Search Capabilities Easier Aggregation A mid-sized manufacturer needs to create online relationships with customers, each with their own set of standards and protocols Describe Services To meet its on-time delivery commitments a high-tech manufacturers needs to place orders with the most advantageous parts manufacturer or assembler Discover Services A high-tech manufacturer needs to easily integrate and synchronize third-party providers with its manufacturing and distribution requirements. Integrate Services Together 33

Types of Web Services § Informational services are services of relatively simple nature. They 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. 34

Service Properties & State § Functional & non-functional properties: § The functional service description 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. 35

Loose Coupling & Granularity § Loose Coupling: § Coupling indicates the degree of dependency 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 Submit. Purchase. Order 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). 36

Synchronicity & Welldefinedness § Sychronicity: there are two programming styles for services: § synchronous Synchronicity & Welldefinedness § 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. 37

Service Interface & Implementation § The service interface defines service functionality visible to the 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. 38

Perspectives What does it do? How to represent it (business requs) How to build Perspectives What does it do? How to represent it (business requs) How to build it Interface How do I use it? Where can I find it? Client Perspective Implementation How to publish it 39 Where to host it Provider Perspective

Deployment/Realization Imported web-service interfaces Web-service orchestration interface Web-service usage interface Web-service client Service-deployment build/buy Deployment/Realization Imported web-service interfaces Web-service orchestration interface Web-service usage interface Web-service client Service-deployment build/buy Service-realization reuse/buy build Web-service Implementation (in-house) Web-service Implementation (outsourced) 40

SOA Framework Orchestration Discovery, Negotiation Reliable Messaging Choreography Security Interface + Bindings Transactions Policy SOA Framework Orchestration Discovery, Negotiation Reliable Messaging Choreography Security Interface + Bindings Transactions Policy Messaging Protocol, Addressing Transport Protocols 41 Composition Quality of Service Description Messaging Transport

Service Characteristics (1) § Loosely coupled § Interface coupling (implementation details hidden) § Technology 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 42

Service Characteristics (2) § Predictable service-level agreements (SLAs) § Dynamic and Discoverable § Consumable Service Characteristics (2) § Predictable service-level agreements (SLAs) § Dynamic and Discoverable § Consumable without provider intervention where possible § Minimal intervention when needed (e. g. subscription) 43

Service Level Agreements (SLAs) § An SLA is a formal agreement (contract) between a 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 44

Quality of Service (Qo. S) § Qo. S refers to the ability of a Quality of Service (Qo. S) § Qo. S 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 Qo. S attributes in a Web services environment are: § § § § § availability accessibility conformance to standards integrity performance reliability scalability security transactionality 45

Components vs. Services Components Services § Tight coupling § Loose coupling § Client requires Components vs. Services Components Services § Tight coupling § Loose coupling § Client requires library § Message exchanges § Policy § Client / Server § Extendable § Stateless § Peer-to-peer § Composable § Context independent § Fast § Small to medium granularity § Some overhead § Medium to coarse granularity 46

Technical Benefits § Efficient development § Promotes modularity (loose coupling) § Easy to divide 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 47

Business Benefits (1) § Increased business agility § § § Finding the right service 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 48

Business Benefits (2) § Reduced integration costs § Application integration main area of application 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. J 2 EE, . NET) Packaged applications (e. g. SAP) Middleware technology (e. g. CORBA) Product features (e. g. Stored Procedures) 49

Challenges § Staff training § Maintain discipline § Services must be developed for long-term 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 § … 50

Possible Solution § Step-by-step migration to SOA § Find and implement specific instances where 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 51

SOA Technologies § SOA can be built using: § § § Distributed object middleware SOA Technologies § SOA can be built using: § § § Distributed object middleware (e. g. CORBA, J 2 EE, COM/DCOM) Message-oriented middleware (e. g. IBM Web. Sphere MQ) TP monitors (e. g. CICS) Custom middleware B 2 B platforms (e. g. eb. XML, Rosetta. Net) Web services § Most of these are not ideal for SOA § Only few installations of conventional middleware actually implement a service-oriented architecture 52

Web Services One possible implementation technology for SOA 53 Web Services One possible implementation technology for SOA 53

What are Web Services? § SOA: abstract architectural concept (!= Web services) § Web 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 54

Web Service - Definition “A Web service is a software system designed to support 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 machineprocessable 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. ” - W 3 C (http: //www. w 3. org/TR/ws-gloss/) 55

Well suited for SOA § Based on Web standards § XML and XML Schema 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 (W 3 C, OASIS, …) Embraced by the IT industry 56

Web Service Core Framework Standards SOA Service Framework Orchestration BPEL 4 WS UDDI, WS-Addressing, Web Service Core Framework Standards SOA Service Framework Orchestration BPEL 4 WS UDDI, WS-Addressing, Discovery, Negotiation UDDI WS-Meta. Data. Exchange WS-Reliable Messaging Choreography WS-CDL WS-Security Interface + Bindings WSDL WS-Transactions WS-Coordination WS-Policy Messaging Protocol, Addressing SOAP, WS-Addressing SOAP TCP/IP, HTTP, SMTP, FTP, … Transport Protocols 57 Composition Quality of Service Description Messaging Transport

Core Web Service Architecture WSDL Specificatio n UDDI Registry Query Requireme nts Publish WSDL Core Web Service Architecture WSDL Specificatio n UDDI Registry Query Requireme nts Publish WSDL Specificatio SOAP Service n Web Request Provider Service Request Response or 58

Standards § Core standards (SOAP, WSDL, UDDI) describe basic parts of Web service platform 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 59

SOAP § Originally: Simple Object Access Protocol § XML-based messaging protocol § Defines § 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 60

WSDL § § Web Services Description Language XML vocabulary to describe Web services Highly 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? ”) 61

UDDI § Universal Description, Discovery and Integration § Flexible directory/registry service for Web services 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 62

Web Services… § …are self-contained, modular applications that can be § § § Described: 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) 63

Extended Specifications (1) § WS-Addressing § Interoperable, transport-independent way of identifying message senders and 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-Policy. Attachment § WS-Meta. Data. Exchange § Dynamic exchange of WS-Policy and other metadata § Between endpoints, no registry involved 64

Extended Specifications (2) § Quality of Service Specifications § WS-Security § Security Framework using Extended Specifications (2) § Quality of Service Specifications § WS-Security § Security Framework using existing security models (e. g. Kerberos, X. 509) § WS-Reliable. Messaging § 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-Atomic. Transaction: short duration (2 -phase commit) § WS-Business. Activity: longer duration activities (requires compensation techniques) 65

Extended Specifications (3) § WS-CDL (Web Services Choreography Description Language) § Describes how services 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 66

Orchestration OCustomer OProducer OSupplier 1 67 Chebbi, I. , Dustdar, S. , Tata, S. Orchestration OCustomer OProducer OSupplier 1 67 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. OSupplier 2

Choreography 68 Chebbi, I. , Dustdar, S. , Tata, S. (2005). The view-based approach Choreography 68 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.

Adoption § Designed for step-by-step adoption § Core standards usable without extended specifications § 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 69

Example 70 Example 70

Example Overview § Example company: travel agency “Service-Oriented Travel” (SOT) § Services provided to 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 71

Benefits to Customers § Quicker response time § Many steps automated § No waiting 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 72

Benefits to Travel Agency § Faster reaction to changes in supply market § Loose 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 73

Benefits of SOA § Benefits only fully realized once company itself and all suppliers 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 74

Summary 75 Summary 75

Summary SOA (1) § § Software services similar to real-world services SOA: abstract architectural 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 76

Summary SOA (2) § Challenges: § § Training/Skills Discipline Short-term costs Legacy applications § Summary SOA (2) § Challenges: § § Training/Skills Discipline Short-term costs Legacy applications § Possible solution: step-by-step adoption 77

Summary Web Services (1) § One approach for SOA § XML-based interface technology § Summary Web Services (1) § One approach for SOA § XML-based interface technology § Properties: § § § Based on Web standards Relatively simple Platform independent Pervasive Standardized (W 3 C, OASIS, …) Embraced by the IT industry 78

Summary Web Services (2) § Core standards: § SOAP § WSDL § UDDI § Summary Web Services (2) § Core standards: § SOAP § WSDL § UDDI § Extensibility § Extended specifications: § § WS-Adressing WS-Policy WS-Meta. Data. Exchange Qo. S: WS-Security, WS-Reliable. Messaging, WS-Coordination, WS-Transaction § WS-CDL § BPEL 4 WS § Adoption: step-by-step, core standards widely used 79

Thanks for your attention! Prof. Dr. Schahram Dustdar Distributed Systems Group Institute of Information 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/ 80