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
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 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 II
Enterprise Application Integration (EAI) – The beginning of SOA 8
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 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 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 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 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 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. , 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 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 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
Some good references… 19
Service-oriented Computung (So. C) 20
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 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 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 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 Published Found Bound Invoked Composed 25
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 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: § 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 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 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 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 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 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 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 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 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 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 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 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 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 Messaging Protocol, Addressing Transport Protocols 41 Composition Quality of Service Description Messaging Transport
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 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 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 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 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 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 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 § 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 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 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 (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
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 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 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, 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 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 § 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 § § § 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 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 § 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: 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 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 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 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. (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 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 § 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 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 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 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 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 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 § Possible solution: step-by-step adoption 77
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 § 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 Systems Vienna University of Technology Austria http: //www. infosys. tuwien. ac. at/Staff/sd/ 80
Скачать презентацию Service-oriented Computing Prof Dr Schahram Dustdar Distributed Systems
e85a7b953c3ebc99de38facfecb83abe.ppt