SWE601-SOA.pdf

Service-Oriented Engineering Service Oriented Computing Slide 1 Outlines  Introduction to Web Service & SOA  The Business Case for SOA  Web service basic: SOAP, WSDL, UDDI  Web service advance: Composition  Service-Oriented Architecture Service Oriented Computing Slide 2 What is SOA?  Simply, a collection of services which can communicate with each other  Services  What you connect together  By default: web services  Communication  Interface agreements  Internet protocols  Conceptually, SOA is NOT a new idea  RPC (Remote Procedure Call) to invoke a procedure anywhere as if on the same machine RMI(Remote Method Invocation) CORBA (Common Object Request Broker Architecture) DCOM (Distributed-Component Object Model) Service Oriented Computing Slide 3 Formally, SOA is:  An architectural style whose goal is to achieve “loose coupling” among interacting and contracted services via communication protocols  An Internet-native distributed computing model  The term service-oriented means to support service’s dynamic description, publication, discovery, and usage Service Oriented Computing Slide 4 Trinity of SOA Service Oriented Computing Slide 5 Web service  A briefer definition  Web services are loosely coupled, contracted components that communicate via XML-based interfaces using Internet protocols  A closer look…  Loosely coupled: Web Services and programs that invoke them can be changed independently  Contracted: a Web Service's behaviour, its input/output parameters and how to bind to it are publicly available  Component: encapsulated code whose internal implementation is hidden  XML: human-readable, text-based format that is firewall friendly and self-describing Service Oriented Computing Slide 6 Key web service technology  SOAP (Simple Object Access Protocol)  Simple messaging framework for transferring information between peers over web in a decentralized and distributed environment using XML  WSDL (Web Service Description Language)  An XML-based means for describing a web service and expressing the interface to a given Web service  UDDI (Universal Description Discovery and Integration)  A repository for WSDL docs Service Oriented Computing Slide 7 Web service & SOA Often, there is a confusion of web service = SOA? Service Oriented Computing Slide 8 Why SOA? – business point of view  Business motivation  Broad intra and inter interoperability  Future e-business: interoperability via internet  However, they lead to high IT complexity and costs demand for quick response  Benefits of SOA  Reduce costs by leveraging existing legacy services  Increase revenue by assembling of existing services  Integrate value chains for e-business collaborations  Create highly dynamic and distributed applications  Achieve ‘just-in-time’ integration ... Service Oriented Computing Slide 9 Why SOA? – technical point of view  Technical motivation  Software reuse & integration  However, the old problems of RPC such as RMI, CORBA and DCOM remain: Single-vendor, non-interoperable solutions Binary protocols, not readable Tightly coupled systems only  Benefits of SOA  Aiming to solve all of the above problems Service Oriented Computing Slide 10 The key - Interoperability  Web Services Interoperability (WSI) Organisation  Goal of WSI:  Ensure web services interoperate across platforms, applications and languages by setting standards for web service  Accelerate web services deployment guidance, tool, sample, and practices forum discussion and meeting Service Oriented Computing Slide 11 E-business  The marriage of traditional supply chain management with internet E-commerce (B2C, C2C) Direct transactions; Point-of-sale E-procurement (B2B) Processes by which a manufacturer obtains products from suppliers For aggregations of buyers/sellers Enormous in volume, quantity, and value E-collaboration (B2B) Information sharing among participants Collaborative planning to decision-making How about Business to Team (B2T)? Service Oriented Computing Slide 12 Business goals  Low cost  Streamlined and efficient process  Monitor and track process execution  Detect and manage exception  In-time response, etc Solution: IT Service Oriented Computing Slide 13 Business trends  Scale dimension  Time dimension Intra-enterprise Manual Inter-enterprise Electronic Global interaction Web Service Oriented Computing Slide 14 IT trends Mainframe Set of servers Set of services Service Oriented Computing Slide 15 Problems  Different parties may have different Operating system, interface, data format, infrastructure, interaction protocols, language, etc  Automating supply chain implies bringing all of them together Solution: Integration Service Oriented Computing Slide 16 Integration types  EAI  B2B  B2C  EDI Service Oriented Computing Slide 17 EAI  Enterprise application integration (EAI) technology is the means of integrating existing software systems or applications within enterprises with each other in order to execute business processes involving many software systems User Interface Integration Data Integration Method or Function Integration Business Process Integration Service Oriented Computing Slide 18 EAI - an overview Adapter EAI technology Adapter Adapter Business process step Data transformation Service Oriented Computing Slide 19 B2B integration  Business-to-business (B2B) integration technology is the means to integrate the electronic data transmission between enterprises over: public or private secured or unsecured transactional or unreliable networks Service Oriented Computing Slide 20 B2B – an overview Network Enterprise 1 Enterprise 2 Data transformation Conversation Security and non-repudiation Contract Service Oriented Computing Slide 21 B2C integration  Business-to-Consumer (B2C) integration is the means to have human users connect to businesses in order to purchase or to sell goods or services  And example is Amazon.com where customers can buy from a variety of goods, including kitchenware, electronics, and, of course, books Service Oriented Computing Slide 22 EDI  Electronic data interchange (EDI) is used for inter-industry electronic interchange of business transactions  Accredited Standards Committee (ASC) develops, maintains, interprets, publishes and promotes the proper use of EDI Standards, charted by American National Standards Institute in 1979  It defines business document formats - transaction sets, does not define collaborations Service Oriented Computing Slide 23 Business logic  Business logic (or business process) is the sequence of business functions that are necessary to achieve a value-added business goal  Each of these functions can be business logic itself if it constitutes a complete set of business functionality Service Oriented Computing Slide 24 Business logic – an example  Purchasing of goods A good to be purchased is determined A quotation request is conducted The goods are purchased Upon delivery, the goods are paid  It can be subdivided into phases Good selection Request for quotation Purchasing Payment Service Oriented Computing Slide 25 Business logic composition  Business logic composition is the integration of smaller business processes into more complex ones  This involves Definition of control flow between the parts Definition of data flow between the parts Definition of compensation to account for errors and cancellations Service Oriented Computing Slide 26 Workflow management  Workflow management is a technology for the organisation of composition Between human office workers Between legacy application systems  Typically, work is organized in steps whereby each step contributes toward the overall results  An example – insurance agent Check life insurance application form Assess risk Optionally demand health check Issue insurance policy Set up payment arrangement with customer Service Oriented Computing Slide 27 Centralized vs. P2P  Workflow management system (WfMS) views itself as the work process organizer and views humans as well as legacy applications as helpers for the work process  Workflow management is centralized  However, conversations in e-Business between communication partners follow the model of peer-to- peer (P2P) Service Oriented Computing Slide 28 A workflow with work node, routing node, and start/completion node variables: check if QuoteReferenceNumber: offered product Offered=false int Customer: String check if Offered=true worth proceeding Item: String else GoAhead=true Quantity: int get quote from RequestedDeliveryDate: quotation system ContractExists=false Date get quote ContractExists=true DeliveryAddress: String from supplier GoAhead: Bool update quotation system ContractExists: Bool Offered: Bool send quote enter quote to customer in forecasting system Service Oriented Computing Slide 29 But how exactly to do integration? - Middleware  Middleware is just a level of indirection between clients and other layers of the system  It introduces an additional layer of business logic encompassing all underlying systems  By doing this, a middleware system simplifies the interface design provides transparent access acts as the platform for inter-system functionality takes care of locating/accessing resources Service Oriented Computing Slide 30 Centralized middleware third party WfMS a “global” workflow is executed here WfMS adapter the combination of message broker and adapters enables interoperability message broker supplier customer’s supplier’s adapters adapters warehouse internal procurement requests warehouse’s internal infrastructure adapters internal infrastructure internal infrastructure Service Oriented Computing Slide 31 P2P middleware customer supplier message broker message broker XYZ XYZ customer’s supplier’s adapters adapters internal infrastructure internal infrastructure Service Oriented Computing Slide 32 P2P – multi-middleware supplier customer middleware for supplier- middleware for integrating the customer interaction middleware for supplier- middleware warehouse interaction warehouse middleware for supplier-XYZ interaction middleware for supplier-ABC another party (XYZ) interaction supplier’s supplier’s supplier’s adapters adapters adapters yet another party (ABC) internal infrastructure Service Oriented Computing Slide 33 Limitations of conventional middleware  In cross organizational interaction, there are no obvious places to put middleware Centralized need a central middleware and global workflow Lack of trust, autonomy and security P2P Too many partners require too many middleware platforms Lack of standardization across middleware platforms makes costly in practice Service Oriented Computing Slide 34 Web service  The natural evolution of middleware and EAI platforms as they try to leverage: the Web the Internet The globalization of society, particularly in its economic aspects  No difference from middleware except: being invoked via Internet  A standardized means of dealing with integration, where traditional methods are vendors/application/language specific Service Oriented Computing Slide 35 Web service blur  New proposals appear every month, many of them never to be heard of again  The nature of Web services and the motivation to use them are often blurred by hype as well as many contradictory and overlapping proposals and specifications  The most popular version of Web services (SOAP, UDDI, and WSDL) is a very poor and limiting view on what true Web services should be  After all, what can be done with web services today? Service Oriented Computing Slide 36 B2B with Web service languages and protocols standardized, eliminating need for many different middleware infrastructures customer (need only the Web services middleware) Web service supplier Web service internal procurement requests internal infrastructure internal infrastructure interactions based on protocols redesigned for peer to peer and B2B settings Web service internal functionality made available as a internal infrastructure service warehouse Service Oriented Computing Slide 37 Web services also provide entry points for accessing local services Web service wide area network (Internet) client Web service Web service middleware middleware internal service internal service internal service internal service Company A (provider) Company B (client) Service Oriented Computing Slide 38 Web service – an enterprise example integrating application (contains the composition logic) Web service-enabled broker sendmail application SmartQuotation DBMS SmartForecasting applications Benefit: heterogeneity reduction and P2P interaction Service Oriented Computing 39 Slide 39 Web service vs. OO  Are they similar? Modularization ? Reusability? Encapsulation?  What are the differences? Web Service – Separate data and process (1 CD for different players) OO- Bind data and process (1 CD for its own player) Service Oriented Computing Slide 40 SOA  An architectural style whose goal is to achieve “loose coupling” among interacting and contracted services via communication protocol  Often seen as built upon, and evolving from older concepts of distributed computing and modular programming Service Oriented Computing Slide 41 More on SOA  Architecture is not tied to a specific technology  SOA is commonly built using Web services standards  It can also be implemented using any service-based technology at a higher cost  The model and the notation followed in this architecture mimics what has been done in traditional RPC technologies  First implementations are just extensions of existing platforms to accept invocations through web service interfaces Service Oriented Computing Slide 42 SOA goal  Just-in-time integration of applications by discovering and orchestrating network- available services Service Oriented Computing Slide 43 Web service composition supplier receive orderGoods orderGoods confirmOrder invoke checkLocalStock customer cancelOrder inStock=false local service offered checkLocalStock by the supplier invoke checkShipAvailable inStock=true shippingAvail=false warehouse checkShipAvailable shippingAvail=true send cancelOrder send confirmOrder Service Oriented Computing Slide 44 A real example Service Oriented Computing Slide 45 SOA challenges  Trust Data from a large number of services from different partners  Test All services work as designed?  Security Is the level of security is adequate?  Continuous updating, refinement and expansion Service Oriented Computing Slide 46 4 Phases to Deploy Web Services  Service Implementation  Service publication  Service Discovery  Service Invocation Service Oriented Computing Slide 47 Phase 1: Service Implementation  For providing new services Write code (in any language you want), define interface (in WSDL), publish the interface (in UDDI) and deploy the service as a Web Service  For providing alternative services when there is an existing service interface Find an existing service by using the Web Services Registry, generate a service as above but to comply with the existing interface  For integration of legacy systems Develop a new service interface for an existing application Service Oriented Computing Slide 48 Phase 2: Publication  Author the Web Service description document Describe in WSDL what the service will do, where it can be found, and how to invoke it  Publish the existence of your doc in a UDDI registry Can be global, closed groups or intranet  Publish the description doc on a Web server so your desired audience can access it Host the service Service Oriented Computing Slide 49 Phase 3 & 4: Discovery and Invocation  Discovery Any application can discover your service and locate the Web Services description doc you published UDDI supports pattern queries for automatic lookups and return the location of the WSDL file for the desired service using URI  Invocation Find the service on the server Request the WSDL file based on URI Invoke Web Service dynamically at run time Service Oriented Computing Slide 50 Underlying technologies Directory: Publish & Find Services: UDDI Inspection: Find Services on server: DISCO Description: Formal Service Descriptions: WSDL Wire Format: Service Interactions: SOAP Universal Data Format: XML Ubiquitous Communications: Internet Simple, Open, Broad Industry Support Service Oriented Computing Slide 51 Key technologies SOAP WSDL UDDI Service Oriented Computing Slide 52 SOAP overview  Guiding principle: “Invent no new technology”  Builds on key Internet standards SOAP ≈ HTTP + XML  The SOAP specification defines: The SOAP message format How to send messages How to receive responses Data encoding Service Oriented Computing Slide 53 SOAP  What is SOAP (Simple Object Access Protocol) Simple messaging framework for transferring information between peers over Web in a distributed environment using XML A messaging framework Envelop contains Header (optional) and Body (mandatory) An encoding format (how to encode, serialise and decode objects) An RPC mechanism to call remote objects  SOAP messages are text–based XML documents  SOAP is implemented over HTTP Non-proprietary standard (unlike RMI and DCOM) Text based (unlike CORBA/IIOP) Has the advantages of HTTP (efficiency and security) Service Oriented Computing Slide 54 SOAP Message Structure SOAP Message SOAP Envelope  Envelope: This is top level root SOAP Header element of a SOAP Message, which contains the Header and Header Block#1 Body element Header Block#N  Header: A collection of zero or more SOAP header blocks each of which might be targeted at any SOAP Body SOAP receiver within the SOAP Body Block #1 message path Body Block #N  Body: A collection of zero or more element information items SOAP Fault targeted at an ultimate SOAP Code [Value,SubCode[*]] receiver in the SOAP message Reason path Node Role Detail Service Oriented Computing Slide 55 SOAP Message Structure SOAP Message SOAP Message SOAP Envelope SOAP Header Header Block#1 … Header Block#N SOAP Body Body Block #1 Body Block #N SOAP Fault … Code [Value,SubCode[*]] Reason Node Role Detail Service Oriented Computing Slide 56 How SOAP Works 128 MB DRAM SOAP Server request envelope SOAP getQuote Client translator service 1.67 USD SOAP response envelope Service Oriented Computing Slide 57 SOAP Messages  SOAP request message The envelope defines various namespaces used The header (optional) can carry authentication, payment, etc The body carries the payload of the message For RPC, it contains procedure/methods name and the arguments  SOAP response message Just like a request but the body carries the results Service Oriented Computing Slide 58 Calling SOAP Methods  A client that knows the format of a SOAP request and response can just make an HTTP request  Pseudo code Read the SOAP request from a file Open HTTP connection to web services POST request to service Write response to stdout Service Oriented Computing Slide 59 SOAP Implementation  Microsoft (http://msdn.microsoft.com/soap) Languages: VB, C#  Apache (http://xml.apache.org/soap) Language: Java Software required: Java 1.1 and above Tomcat 3.2.1 or later Apache Xerxes XML parser 1.2.3  SOAP::Lite (http://soaplite.com) Language: Perl Service Oriented Computing Slide 60 WSDL  An XML-based means for expressing the interface to a given Web service Service functionality Binding to a physical protocol http://www.w3c.org/TR/wsdl.html  A WSDL is a contract between a client and a server Using XML to describe Web Services as collections of communication endpoints that can exchange messages with each other Service Oriented Computing Slide 61 WSDL features  XML schema for describing Web Services Service interface definition – Abstract semantics for Web Service – Service implementation definition – Concrete end points and network addresses where Web Service can be invoked  Clear delineation between abstract and concrete messages Service Oriented Computing Slide 62 WSDL features  WSDL provides a means of specifying Data types used Messages Endpoints of a Web Service  Endpoints are defined by a set of Input messages Output messages Fault messages  These end points are then bound to a messaging framework such as SOAP The messaging framework is finally bound to a concrete instance of the service by specifying the addressing and the transport protocols, e.g., HTTP based URIs Service Oriented Computing Slide 63 WSDL Document Structure Definitions: Associate the web service with its WSDL Document namespaces Documentation: human readable Definitions Types: A container for data type definitions PortType Documentation Message: An abstract, typed definition of the Operation data contained in the message Types Input PortType: The set of operations XML Schema Output Operation: An abstraction description of the web service Message Fault Binding: A spec of the protocol and data format Part for a particular portType Port: An endpoint, defined in terms of binding Binding and URL Operation Service: A collection of related endpoints Input Output Service Fault Port Service Oriented Computing Slide 64 WSDL Concepts  Message and types: data communicated to a service is typed  Operation: an action provided by a web service, described by input and output messages  Port, portType and binding: how dialog occurs between caller and service A binding is how to access an operation using a particular protocol (SOAP or HTTP) A port is a named association of a network address with a binding The caller sees only the port and its binding when making a request of a service  Service: a combination of related ports, specifies details about the implementation Service Oriented Computing Slide 65 Clear delineation WSDL specification abstract part types messages operations port types concrete part bindings services and ports Service Oriented Computing Slide 66 Service Oriented Computing Slide 67 WSDL Implementations  Some popular WSDL implementations Microsoft SOAP toolkit Sun’s JAX-RPC IBM Web Services Toolkit (WSTK)  No ONE writes anything in WSDL Service Oriented Computing Slide 68 UDDI  “Ultimate directory for online business” A repository for WSDL docs Not tied to WSDL It’s supported by an XML schema Standard Querying API and publishing API (www.uddi.org)  A business can register itself with a UDDI registry giving info such as Business information: about your company (name, descriptions, URL, contacts…) Service information: about your services (high level) Binding information: about how to invoke your services (technical) Specification of services information: further technical information about the services Service Oriented Computing Slide 69 UDDI – Information model Provider: Information about the entity who offers a service tModel: Descriptions of specifications for services. Service: Descriptive information about a particular family of technical offerings Bindings contain references to tModels. These references designate the Binding: Technical information interface specifications for a about a service entry point and service. construction specs Service Oriented Computing Slide 70 A closer look businessEntity tModel tModel key tModel name key namekey contacts name name description description description description overviewDoc identifiers overviewDoc overviewDoc identifiers categories identifiers identifiers categories categories categories businessService service key name description categories tModel tModel key key bindingTemplate name binding key name description description Specs stored description overviewDoc at the address overviewDoc identifiers identifiers provider’s site detailed info categories references to tModels categories Stored in Oriented Service the UDDI registry Computing Slide 71 How UDDI work - tModel  tModel = Technology Model  Generic meta-data structure to uniquely represent any concept or construct  Also includes interface protocol definitions  Powerful abstraction modeling system Service Oriented Computing Slide 72 UDDI Features  Neutral in terms of protocols – as a registry, it can contain pointers to anything  Can search by business, service, Web Service (tModel), binding  Usage of Globally Unique Identifiers (GUIDs)  Specification allows public and private nodes  Delineation between interface and implementation Service Oriented Computing Slide 76 Public/Private Registries  IBM, Microsoft, SAP … run public registries uddi.ibm.com, uddi.microsoft.com  They are synchronised so all UDDI registries contain the same info A distributed database  Private registries can be run within LANs or closed groups IBM and Sun provide tools to build  Service Oriented Computing Slide 77 WS Composition  Motivations  Concepts  Design Principles  Composition Models Orchestration Choreography  A travel example Service Oriented Computing Slide 78 Motivations  Integration of intra-enterprise services  Alliances with other enterprises Offering value-added integrated services by combining existing web services  Re-use and extension of existing services  Increasing number of on-line services  Just-in-time integration of existing services via internet  Support for planning, definition and implementation of composite e-services Service Oriented Computing Slide 79 WS Composition  The ability of one business to provide value-added services through composition of basic Web Services, possibly offered by different companies  A way to master complexity, via sequential, parallel, iterative and recursive manners Service Oriented Computing Slide 80 80 WS Composition Middleware  Consists of abstraction and tools that facilitate the definition and execution of a composite service  Allows developers to focus on the business logic rather than on low-level details  Includes A composition model and language What services and how they are invocated via composition schema which defines the business logic A development environment Generally a graphical interface A run-time environment Composition engine that executes the business logic by invoking services defined in schema Service Oriented Computing Slide 81 WS Composition Middleware The run-time environment executes the Service composition model and language Web Service business logic by invoking (usually characterized by a graphical and a other services (through SOAP and HTTP textual representation) modules) House hunting service Flight reservation Packaging service Web Service composition middleware service Phone line Shipment service installation service Internet DSL line installation service Schema Development Run-time environment designer environment (composition engine) Services offered by other providers Schema Composite service definitions execution data Supplier Other Web Services middleware (e.g., SOAP engine and Warehouse conversation controller) a service provider Accounting Service Oriented Computing Slide 82 WS Composition without Middleware Company B Company A Web Service Web (Composite) Web service Service Company C Web services middleware Web Service Web Internal service interface Service Implementation of the composition logic Company D Web Service Conventional middleware The internal application implements the composition logic, by invoking Web services as needed. No support is provided by the Web services middleware in this case Service Oriented Computing Slide 83 WS Composition with Middleware Company B Company A Web Service Web (Composite) Web service Service Company C Web services middleware Service composition support Web (modeling and execution) Service Web Service Other tiers Company D Web Service The composite service is directly implemented at the middleware level, by the composition engine. Service Oriented Computing Slide 84 Limitations of Conventional Composition  Flexible and generic, but Application-specific adapters Ad hoc development Price in complexity and cost Lack of a standard composition model Many of them, but never consolidate A components in one system cannot be reused in others E.g., WfMC, only a handful of vendors implemented, and standards are too generic Service Oriented Computing Slide 85 Opportunities of WS composition  Adequate components Well-defined interface, well-described behaviours  Standardized Described by WSDL, invoked by SOAP  Lightweight, easy to use, rapid design and development “Dream” of workflow management Service Oriented Computing Slide 86 Design Principles of WS Composition  Asynchronous service invocation You do not want to hold everything up if you think the call to the method may take time  Transactional integrity Traditional ACID (atomicity, consistency, isolation and durability) are not sufficient for long-lived transactions  Dynamic, flexible and adaptable to meet changing business needs A clear separation between the process logic and Web services promotes flexibility  Persistence and correlation Maintain states for cross Web Services requests  Exception handling Service Oriented Computing Slide 87 WS Composition Models Orchestration Choreography Refers to an executable  Refers to an abstract business process that can Process interact with both internal and  Tracks the sequence of external Web Services messages that may involve Represents control from one multiple parties including party’s perspective customers, suppliers and The interactions partners  Occur at the message level  Shows the public message  Include business logic and task exchanges that occur execution order between Web Services –  Can span applications and rather than a specific organizations to define a long- business process that a lived, transactional, multi-step single party executes process model Service Oriented Computing Slide 88 Orchestration vs. Choreography web service web service collaboration web process flow web web web service service service service Service Oriented Computing Slide 89 Orchestration Models  Categorized by business logic Activity Diagram State Chart Petri Net Activity Hierarchy … Service Oriented Computing Slide 90 Activity Diagram supplier receive orderGoods orderGoods invoke confirmOrder customer checkLocalStock cancelOrder inStock=false local service offered by the checkLocalStock invoke supplier checkShipAvailable inStock=true shippingAvail=false warehouse checkShipAvailable shippingAvail=true send cancelOrder send confirmOrder Service Oriented Computing Slide 91 State Chart start on new order request started /start “invoke checkLocalStock” searching for products locally local search complete(inStock) [inStock=false]/start “invoke local search complete(inStock) checkShipAvailable” [inStock=true]/start “send confirmOrder” searching for products at other supplier external search complete(shippingAvail) [shippingAvail =false]/start “send external search caneclOrder” complete(shippingAvail) [shippingAvail =true]/start order canceled “send confirmOrder” order completed Service Oriented Computing Slide 92 Petri Net START (upon invocation of orderGoods operation) invoke checkLocalStock LOCAL SYSTEM invoke checkShipAvailable ACCESSED inStock=false Do nothing inStock=true EXTERNAL SUPPLIER ACCESSED send cancelOrder Do nothing shippingAvail=false shippingAvail=true COMPLETE (CANCEL) READY TO SEND CONFIRMATION send confirmOrder COMPLETE (CONFIRM) Service Oriented Computing Slide 93 Activity Hierarchy process order sequence discriminate based on local receive orderGoods invoke checkLocalStock search choice inStock=false inStock=true search external supplier send confirmOrder sequence discriminate based on invoke checkShipAvailable external search choice shippingAvail=true shippingAvail=false send confirmOrder send cancelOrder Service Oriented Computing Slide 94 Orchestration (Activity diagram): A travel agent example Receive  From the perspective of Itinerary Airline a travel agent (Web service) Customer Reserve  Business logic  Task execution order Reserve Hotel Hotels (Web service) Itinerary Notify confirmed Customer outcome Itinerary rejected Service Oriented Computing Slide 95 and  and activities receive messages Receive from and give feedback to Itinerary Airline customers respectively (Web service) Customer Reserve  The travel agent could deal concurrently, so correlation Reserve Hotel identifiers are needed for Hotels (Web service) different instances of a business process Itinerary Notify confirmed Customer outcome Itinerary rejected Service Oriented Computing Slide 96  activities are used to trigger internal Receive and/or external web Itinerary services, so that the Airline (Web service) flexibility for adapting the Reserve rapid business changes  Thanks to a clear Reserve Hotel Hotels (Web service) separation between the process logic and Web services Itinerary Notify confirmed Customer outcome Itinerary rejected Service Oriented Computing Slide 97 &  activity allows tasks to be Receive executed concurrently Itinerary Airline  activity allows (Web service) Customer Reserve conditional behaviours Reserve Hotel Hotels (Web service) Itinerary Notify Customer confirmed outcome Itinerary rejected Service Oriented Computing Slide 98 Choreography: The travel agent example TRAVEL AGENT (Web Services) 1) Traveller, Trip Receive Trip Order 2) Proposed Itinerary 3) Itinerary ID Receive Trip Confirmation 4) Booking ID, Status Send Statement CUSTOMER 5) Booking ID, Statement 99 Service Oriented Computing Slide 99 The Choreography example The example should concern the following:  Choreography The sequence of the public message exchanges is regulated in Web Choreography while there are no restrictions on the order of triggering the operations of Web Services  Transaction A traveller will be informed that a trip request would be logically rolled back in case of any error happening during the process  Possible Choices The travel agent may be able to send either a Bill or a Notification that the trip cannot be confirmed based on the availability of the trip as communicated from the Airline Reservation system Service Oriented Computing Slide 100 Workflow vs. WS Composition Fabio Casati, Mehmet Sayal, Ming-Chien Shan. “Developing E-Services for Composing E- Services”, CAiSE 2001 Service Oriented Computing Slide 101 SOA Development  SOA Concepts Development of SOA Industrial standards Service Oriented Computing Slide 102 Concepts  Service-oriented architecture An architectural style whose goal is to achieve “loose coupling” among interacting and contracted services via communication protocols  Architecture A software architecture is a structure or abstraction of a software system, including: Software components Externally visible properties of those components Relationships among them Constraints on their use Service Oriented Computing Slide 103 Traditional Architecture combines everything into a single program http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsent/html/FoodMovers3.asp Service Oriented Computing Slide 104 Its Problems  The application's functions cannot be re-used, e.g., the business functions are written for this particular application/platform only  It is difficult to debug the program as it grows, and maintain it as it is deployed. A change to one part of the code could affect other code  Security is another problem because the user interface cannot be isolated from the rest of the program  Scalability is almost impossible because it is difficult to spread any part of the application Service Oriented Computing Slide 105 Component-Based Application Architecture First addressed the problem of integrated code by defining layers of functionality Service Oriented Computing Slide 106 Problems Tight Coupling Service Oriented Computing Slide 107 Its Problem  A tightly coupled solution, in which two applications that are being integrated are aware of each others' implementation details, requires custom code that or a human, who reads the output from one application and keys it into another application Allows the components to be re-used on the same platform and usually the same programming language  What if...? we need to share the business functions throughout heterogeneous platforms? we want to share information with our external partners? Service Oriented Computing Slide 108 Service-Oriented Architecture Service Oriented Computing Slide 109 SOA Integration Service Oriented Computing Slide 110 A Service:  Has a clearly defined interface, which is exposed through some kind of standard contract  Is usually discoverable, but not always  Can correspond to real-life business activities  Interacts with other services and components using loosely- coupled, message-based architecture  Uses standards for communication for interoperability  Is up and running all the time, unlike components that must be instantiated before use Service Oriented Computing Slide 111 SOA Enables:  Reusability  Legacy leverage  Agility  Loose coupling  Interoperation Service Oriented Computing Slide 112 Reusability Service Oriented Computing Slide 113 Legacy Leverage Service Oriented Computing Slide 114 Agility Service Oriented Computing Slide 115 Loose Coupling Service Oriented Computing Slide 116 Interoperation Service Oriented Computing Slide 117 Components of SOA  Service in SOA is an exposed piece of functionality with 3 properties: Platform-independent Dynamically located and invoked Self-contained Service Oriented Computing Slide 118 Replaceable Components  Often need to represent several different implementations of a particular component, where you need to isolate requestors from change in the implementation provide access to many different "flavors" of that component, either at once or over time  For example – Insurance Broker site You're building a web site that will provide customers with Insurance quotes. To do so you have an agreement with several different Insurance companies to provide you with quotes. But you have a problem; each of the Insurance companies has a different mechanism for accepting quote requests and providing quotes to you Service Oriented Computing Slide 119 Composable Components  Do you need to take parts of your system and then compose them into a larger system in a configurable way?  Invoking WS’s in a specified order – some services may be skipped (or rerun) depending on results of previous WS  For example, the Business Process Execution Language for Web Services (BPEL4WS) specification describes how to compose Web Services into workflows Service Oriented Computing Slide 120 Integration with SOA  Internal Integration Only worthwhile if the system is already functional and robust Can be done with custom interfaces (e.g. screen scraping) or Using loosely coupled architectures and message-based protocols – internal WS  External Integration Companies communicate with messages such as contracts purchase orders Invoices monetary transactions insurance claims, and many more … Service Oriented Computing Slide 121 Orchestration vs. Choreography  Includes execution order of  Tracks the sequence of web services interactions messages involving multiple  Describes process flow parties and sources  Can include both internal and  Associated with public external web services, but message exchanges, not process is always controlled executable processes by one party  More collaborative in nature web web service service collaboration web web web process flow web service service service service Service Oriented Computing Slide 122 SOA Development  Service-oriented Analysis  Service-oriented Design  Implementation Service Oriented Computing Slide 123 Service-Oriented Analysis  Step 1: define analysis scope Identify system specifications  Step 2: define affected systems Identity affected legacy systems and reusable services  Step 3: perform service modelling Identify services considering Service Reusability Service Autonomy Service Discoverability Service Oriented Computing Slide 124 Service Modelling  Entity Services  Task Services  Utility Services Service Oriented Computing Slide 125 Entity Services  Defines the organization’s relevant business entities E.g., customer, employee, invoice, and claim  Represents a business-centric service that bases its functional boundary and context on one or more related business entities  Considered a highly reusable service  Known as entity-centric business services or business entity services Service Oriented Computing Slide 126 Task Services  A business service with a functional context and scope E.g., add, search, submit and cancel  Tends to have less reuse potential and is generally positioned as the controller of a composition responsible for composing other services  Task services are also known as task-centric business services or business process services Service Oriented Computing Slide 127 Utility Services  Dedicated to providing reusable, cross-cutting utility functionality E.g., event logging, notification, and exception handling  Utility services are also known as application services, infrastructure services, or technology services Service Oriented Computing Slide 128 Delivery Processes  Top Down Tactically focused on that it makes the fulfilment of immediate business requirements a priority and the prime objective of the project Avoids the extra cost, effort, and time Imposes increased governance burden as bottom-up delivered services tend to have shorter lifespans and require more frequent maintenance, refactoring, and versioning Service Oriented Computing Slide 129 Delivery Processes  Bottom Up Advocates the completion of an inventory analysis prior to the physical design, development, and delivery of services Demands more of an initial investment because it introduces an up-front analysis stage focused on the creation of the service inventory blueprint Individually defined as part of this blueprint so as to ensure that subsequent service designs will be highly normalized and standardized Service Oriented Computing Slide 130 Service-Oriented Design  Orchestrate the business logic, based on entity, utility, and task services Different methods can be used, e.g., activity diagram (using task services) Complex systems often mix all types  Service analysis results in a collection of services that establish the starting point for service design Service Oriented Computing Slide 131 Implementation  Choosing the development environment platform, language, technologies etc.  Coding & documentation  Testing  Running  … Service Oriented Computing Slide 132 General Guiding Principles  For development, maintenance, and usage of the SOA Reuse, granularity, modularity, composability, and interoperability Compliance to standards (both common and industry-specific) Services identification and categorization, provisioning and delivery, and monitoring and tracking Service Oriented Computing Slide 133 Specific Architectural Principles  For design and service definition focusing on specific themes that influence the intrinsic behaviour of a system and the design style Encapsulation: hide implementation Loose coupling: minimizes dependencies Contract: communications agreement Abstraction: hide logic from the outside world Reusability: logic is divided into services for reuse Composability: services can be assembled Autonomy: services have control over the logic Optimization: high-quality services are preferred Discoverability: services are descriptive Service Oriented Computing Slide 134 Industrial Standards  Orchestration standards can simplify the creation of business processes involving web services  Many “standards” No clear winner. It is unclear where the industry is going with the various standards  Many proposals of “standards“ – every player tries to get the biggest piece of cake BPEL4WS (IBM, Microsoft,BEA) – merging of XLANG (Microsoft) and WSFL (IBM) WSCI + BPML (Sun, SAP, Intalio and BEA!!!) – as W3C Technical report  Limited number of supporting products (Collaxa, IBM BPWS4J) From: Chris Paletz “Web Services Orchestration. A review of emerging technologies, tools and standards”, Hewllett Packard Co, January 2003 Service Oriented Computing Slide 135 Popular Standards  WSCI/BPML has much richer choreography BPEL4WS Collaborative support and backing by Protocols Abstract WSCI Processes W3C working group  BPEL4WS has major supporters behind it, with developer tools and Executable BPEL4WS documentation already Business Executable BPML available Processes Processes BPEL4WS WSCI/BPML (IBM, Microsoft, BEA) (Sun, Intalio, SAP) Service Oriented Computing Slide 136 BPML  Business Process Modeling Language developed by BPMI.org (Intalio, Sterling, Sun, CSC) meta-language for describing business processes language executed by a BPMS system  Key features basic activities for sending, receiving, and invoking services handles conditional, sequential, and parallel activities persistence, correlation, and composition support supports short and long-running transactions robust exception handling mechanisms  Incorporated WSCI for web services choreography Service Oriented Computing Slide 137 WSCI  Web Services Choreography Interface  Specification from Sun, SAP, W SCI Intalio, and BEA WW eb eb  Defines an XML language for Service Service web services collaboration  Describes the overall W SCI W SCI choreography, or observable WW eb eb Collaboration WW eb eb behavior, between services Service Service Service Service Does not define W SCI executable processes WW eb Each partner exposes their eb Service Service WSCI interface  Layered on top of WSDL Service Oriented Computing Slide 138 WSCI Features  Support for basic activities: each activity specifies the WSDL operation involved use to define a basic request/response message use to invoke external services  Support for structured activities: sequential, parallel, and conditional looping use to specify an unordered actions to perform  Support for business transactions and exceptions: transactional contexts can be defined in WSCI any failure in a context will result in all transactions in context being rolled back Service Oriented Computing Slide 139 BPEL4WS  Business Process Execution Language for Web Services specification from IBM, Microsoft, and BEA XML grammar describing the logic required to coordinate web services in a process flow interpreted and executed by an orchestration engine  Layered on top of WSDL every process is exposed as a web service using WSDL WSDL types are used to describe persistent information WSDL references specify calls to external services  Orchestration features: executable processes model an executable private workflow abstract processes specify a public message exchange Service Oriented Computing Slide 140 BPEL4WS  A layer on top of WSDL  Models the behaviour of web services in a business process interaction  Control logic required to coordinate web services  In current implementations interpreted and executed by an orchestration engine (centralized!)  Support for long transactions (compensations)  Combine activity diagram and activity hierarchy Service Oriented Computing Slide 141 BPEL4WS Process Flow Service Oriented Computing Slide 142 Summary Business concepts Supply chain, EAI, B2B, B2C, EDI, business logic, workflow management Integration Middleware&Web service Web Service Composition Motivations&Concepts Design Principles Composition Models  Orchestration  Choreography A travel example SOA: Concepts Development of SOA Industrial standards Service Oriented Computing Slide 143

Document Details

Related

Full Transcript

Upgrade to continue