Unit iii soa
- 1. UNIT III By Dr.Smitha.P.S Associate Professor Velammal Engineering College
- 2. UNIT III WEB SERVICES (WS) AND STANDARDS Web Services Platform – Service descriptions – WSDL – Messaging with SOAP – Service discovery – UDDI – Service-Level Interaction Patterns – Orchestration and Choreography
- 3. 3.1 SERVICE DESCRIPTIONS (WITH WSDL) • This part of SOA provides the key ingredient to establishing a consistently loosely coupled form of communication between services implemented as Web services. • For this purpose, description documents are required to accompany any service wanting to act as an ultimate receiver. The primary service description document is the WSDL definition (Figure 1).
- 4. SERVICE DESCRIPTIONS (WITH WSDL) • Figure 1. WSDL definitions enable loose coupling between services.
- 5. CASE STUDY • For RailCo to design its B2B Web services in full compliance with the TLS services, RailCo acquires the WSDL service description published by TLS for their Accounts Payable Service. This definition file then is used by developers to build the Invoice Submission Service so that it can process SOAP messages in accordance with the service interface requirements defined in the TLS service descriptions. • Further, RailCo provides TLS with a copy of the WSDL definition for the RailCo Order Fulfillment Service. TLS registers this service description and adds it to the list of vendor endpoints that will receive electronic purchase orders. (Figure 2 illustrates both scenarios.)
- 6. CASE STUDY • Figure 2. Each service requestor is using the WSDL of a service provider to ensure that messages sent will be understood and accepted.
- 7. Service endpoints and service descriptions • A WSDL describes the point of contact for a service provider, also known as the service endpoint or just endpoint. It provides a formal definition of the endpoint interface (so that requestors wishing to communicate with the service provider know exactly how to structure request messages) and also establishes the physical location (address) of the service. • A WSDL service description (also known as WSDL service definition or just WSDL definition) can be separated into two categories: – abstract description – concrete description
- 8. WSDL(Web Services Description Language) Figure 3. WSDL document consisting of abstract and concrete parts that collectively describe a service endpoint.
- 9. WSDL-Abstract description Abstract description • An abstract description establishes the interface characteristics of the Web service without any reference to the technology used to host or enable a Web service to transmit messages PortType, operation, and message • The parent portType section of an abstract description provides a high- level view of the service interface by sorting the messages a service can process into groups of functions known as operations. • Each operation represents a specific action performed by the service. A service operation is comparable to a public method used by components in traditional distributed applications. Much like component methods, operations also have input and output parameters. • Because Web services rely exclusively on messaging-based communication, parameters are represented as messages. Therefore, an operation consists of a set of input and output messages. • The transmission sequence of these messages can be governed by a predetermined message exchange pattern that also is associated with the operation
- 10. WSDL-Concrete description • For a Web service to be able to execute any of its logic, it needs for its abstract interface definition to be connected to some real, implemented technology. This connection is defined in the concrete description portion of the WSDL file, which consists of three related parts: • binding, port, and service • A WSDL description's binding describes the requirements for a service to establish physical connections or for connections to be established with the service. SOAP is the most common form of binding. • Related to the binding is the port, which represents the physical address at which a service can be accessed with a specific protocol. • Within the WSDL language, the term service is used to refer to a group of related endpoints. Note • The term "port" is being renamed "endpoint" in version 2.0 of the WSDL specification
- 11. Case Study • The TLS Accounts Payable Service was created to receive invoices submitted by numerous vendors. Its associated service description therefore has a simple abstract description consisting of one interface definition that contains a single operation called SubmitInvoice. • Specified within the operation is one input and one output message. The input message is responsible for accepting the invoice document from a vendor service requestor (such as the RailCo Invoice Submission Service). The output message is used by the Accounts Payable Service to send a message of acknowledgement indicating that the submitted invoice document has been successfully received and that its contents are valid. • The concrete part of this service description simply binds the operation to the SOAP protocol and provides a location address for the Accounts Payable Service.
- 12. Metadata and service contracts • Three separate documents that each describe an aspect of a service: – WSDL definition – XSD schema – Policy • WSDL definitions frequently rely on XSD schemas to formalize the structure of incoming and outgoing messages • Another common supplemental service description document is a policy. • Policies can provide rules, preferences, and processing details above and beyond what is expressed through the WSDL and XSD schema documents. • Each of these three service description documents can be classified as service metadata, as each provides information about the service. • Service description documents can be collectively viewed as establishing a service contract a set of conditions that must be met and accepted by a potential service requestor to enable successful communication.
- 13. Service Contract Figure 4. A service contract comprised of a collection of service descriptions and possibly additional documents.
- 14. 3.2 SERVICE DISCOVERY-UDDI • UDDI is an XML-based standard for describing, publishing, and finding web services. UDDI stands for Universal Description, Discovery, and Integration. UDDI is a specification for a distributed registry of web services. UDDI is a platform-independent, open framework. • The sole requirement for one service to contact another is access to the other service's description. As the amount of services increases within and outside of organizations, mechanisms for advertising and discovering service descriptions may become necessary. • For example, central directories and registries become an option to keep track of the many service descriptions that become available. These repositories allow humans (and even service requestors) to: – locate the latest versions of known service descriptions – discover new Web services that meet certain criteria – When the initial set of Web services standards emerged, this eventuality was taken into account. This is why UDDI formed part of the first generation of Web services standards. Though not yet commonly implemented, UDDI provides us with a registry model worth describing.
- 15. Private and public registries • UDDI specifies a relatively accepted standard for structuring registries that keep track of service descriptions (Figure 5). These registries can be searched manually and accessed programmatically via a standardized API. Figure 5. Service description locations centralized in a registry.
- 16. UDDI • Public registries accept registrations from any organizations, regardless of whether they have Web services to offer. Once signed up, organizations acting as service provider entities can register their services. • Private registries can be implemented within organization boundaries to provide a central repository for descriptions of all services the organization develops, leases, or purchases. • Following are descriptions of the primary parts that comprise UDDI registry records. – Business entities and business services – Binding templates and tModels
- 17. UDDI Business entities and business services • Each public registry record consists of a business entity containing basic profile information about the organization (or service provider entity). Binding templates and tModels • Registry records follow the same logic in that they store binding information in a separate area, called the binding template. • Each business service can reference one or more binding templates. The information contained in a binding template may or may not relate to an actual service. • For example, a binding template may simply point to the address of a Web site. However, if a Web service is being represented, then the binding template references a tModel. The tModel section of a UDDI record provides pointers to actual service descriptions (Figure 6).
- 18. UDDI Figure 6. The basic structure of a UDDI business entity record.
- 19. CASE STUDY • At any given time there are several concurrent development and integration projects underway at TLS. Almost every project results in the creation of new services. Some are developed as part of service-oriented solutions, while others originate from legacy adapters and ancillary services appended to older distributed systems. The net result is a constantly growing pool of unmanaged services. • After a year-end review of past development initiatives, it was discovered that several project teams had inadvertently built Web services with very similar functionality. To avoid a recurrence of redundant effort, a private registry was created (Figure 7). Project teams responsible for any currently active service descriptions were required to register their services in the registry (and this registration process became part of the standard development lifecycle from there on).
- 20. CASE STUDY Figure 7. The TLS service registry containing pointers to current TLS WSDL definitions
- 21. 3.3 MESSAGING (WITH SOAP) • Because all communication between services is message- based, the messaging framework chosen must be standardized so that all services, regardless of origin, use the same format and transport protocol. • The SOAP specification has been universally accepted as the standard transport protocol for messages processed by Web services. Since its initial release, SOAP has been further revised to accommodate more sophisticated message structures in support of enterprise distributed applications and enterprise SOAs. • Even though it was originally named the Simple Object Access Protocol, the SOAP specification's main purpose is to define a standard message format.
- 22. An Analogy • Now that we've completed the required application form, we need to figure out how to get this information to the agency. Because Bob only knew the name of the company, we need to look up its mailing address in the phone book. We add the mailing address to an envelope, place the application form inside, and throw it in a mailbox. • A phone book is commonly compared to a service registry, and a mailing address is the equivalent of a WSDL endpoint (or port). An envelope represents a standardized medium for transporting mailmuch like SOAP represents a standardized format for transporting messages. • When we are ready to let our letter go, we place it in a mailbox, the same way service requestors hand over SOAP messages to SOAP nodes to perform the actual transmission. • Finally, the route traveled by the letter from us to the Reconnect agency is much like the message path a SOAP message follows from service requestor to service provider.
- 23. Messages Envelope, header, and body Every SOAP message is packaged into a container known as an envelope.The envelope is responsible for housing all parts of the message (Figure 1). Figure 1. The basic structure of a SOAP message.
- 24. Header blocks • A primary characteristic of the SOAP communications framework used by SOAs is an emphasis on creating messages that are as intelligence-heavy and self-sufficient as possible. • Header blocks outfit a message with all of the information required for any services with which the message comes in contact to process and route the message in accordance with its accompanying rules, instructions, and properties.
- 25. Header blocks • The use of header blocks has elevated the Web services framework to an extensible and composable enterprise-level computing platform. Practically all WS-* extensions are implemented using header blocks • Examples of the types of features a message can be outfitted with using header blocks include: – processing instructions that may be executed by service intermediaries or the ultimate receiver – routing or workflow information associated with the message – security measures implemented in the message – reliability rules related to the delivery of the message – context and transaction management information – correlation information (typically an identifier used to associate a request message with a response message)
- 26. Message styles • The SOAP specification was originally designed to replace proprietary RPC protocols by allowing calls between distributed components to be serialized into XML documents, transported, and then deserialized into the native component format upon arrival • SOA relies on document-style messages to enable larger payloads, coarser interface operations, and reduced message transmission volumes between services.
- 27. Case Study Traditionally, the submission of an invoice involved a number of interactions between RailCo and its customer, including: • The generation and mailing of the invoice document. • The generation and mailing of an account statement, showing all currently outstanding amounts owed by the customer. • The generation and mailing of a quantity discount reminder, explaining RailCo's volume pricing policy, and showing how close the customer is to reaching a quantity discount based on parts ordered to date. • When forced to submit invoices electronically to TLS via the Invoice Submission Service, all three of these documents needed to be included in the same message. As a result, a single document-style message used by RailCo is capable of providing an invoice, an account statement, and volume discount pricing formulas (Figure 2).
- 28. Case Study Figure 2. The RailCo Invoice Submission Service packaging the contents of three documents into one SOAP message.
- 29. SOAP Attachments SOAP attachments are commonly employed to transport binary files, such as images. Faults Finally, SOAP messages offer the ability to add exception handling logic by providing an optional fault section that can reside within the body area. The typical use for this section is to store a simple message used to deliver error condition information when an exception occurs.
- 30. SOAP nodes Nodes The programs that services use to transmit and receive SOAP messages are referred to as SOAP nodes (Figure 3). Figure 3. A SOAP node transmitting a SOAP message received by the service logic.
- 31. SOAP nodes Node types • As with the services that use them, the underlying SOAP nodes are given labels that identify their type, depending on what form of processing they are involved with in a given message processing scenario. – SOAP sendera SOAP node that transmits a message – SOAP receivera SOAP node that receives a message – SOAP intermediarya SOAP node that receives and transmits a message, and optionally processes the message prior to transmission – initial SOAP senderthe first SOAP node to transmit a message – ultimate SOAP receiver the last SOAP node to receive a message
- 32. Case Study • When the RailCo Invoice Submission Service sends a SOAP message containing an invoice, the underlying SOAP server software (representing the initial SOAP sender node) executes the transmission of the SOAP message via HTTP. • Prior to the TLS Accounts Payable Service actually receiving the invoice message, the TLS SOAP server or listener (representing the ultimate SOAP receiver node) receives the message first (Figure 4).
- 33. CASE STUDY Figure 4. The positioning of SOAP nodes within a message transmission between RailCo and TLS.
- 34. SOAP intermediaries • Service intermediaries transition through service provider and service requestor roles, SOAP intermediary nodes move through SOAP receiver and SOAP sender types when processing a message (Figure 5). Figure 5.Different types of SOAP nodes involved with processing a message. SOAP nodes acting as intermediaries can be classified as forwarding or active
- 35. SOAP Intermediate nodes • SOAP nodes acting as intermediaries can be classified as forwarding or active. When a SOAP node acts as a forwarding intermediary, it is responsible for relaying the contents of a message to a subsequent SOAP node. In doing so, the intermediary will often process and alter header block information relating to the forwarding logic it is executing. For example, it will remove a header block it has processed, as well as any header blocks that cannot be relayed any further. • Active intermediary nodes are distinguished by the type of processing they perform above and beyond forwarding-related functions. An active intermediary is not required to limit its processing logic to the rules and instructions provided in the header blocks of a message it receives. It can alter existing header blocks, insert new ones, and execute a variety of supporting actions.
- 36. SOAP Message paths • A message path refers to the route taken by a message from when it is first sent until it arrives at its ultimate destination. Therefore, a message path consists of at least one initial sender, one ultimate receiver, and zero or more intermediaries (Figure 6). Figure 6. A message path consisting of three Web services.
- 37. SOAP Message paths • Note also that a message path is sometimes not predetermined. The use of header blocks processed by intermediaries can dynamically determine the path of a message. This may be the result of routing logic, workflow logic, or environmental conditions (Figure 7). • Figure 7. A message path determined at runtime.
- 38. 3.4 MESSAGE EXCHANGE PATTERNS- service level interaction pattern • Message exchange patterns (MEPs) represent a set of templates that provide a group of already mapped out sequences for the exchange of messages. The most common example is a request and response pattern. Here the MEP states that upon successful delivery of a message from one service to another, the receiving service responds with a message back to the initial requestor.
- 39. Primitive MEPs Request-response • This is the most popular MEP in use among distributed application environments and the one pattern that defines synchronous communication • The request-response MEP (Figure 2) establishes a simple exchange in which a message is first transmitted from a source (service requestor) to a destination (service provider). Upon receiving the message, the destination (service provider) then responds with a message back to the source (service requestor). Figure 2. The request-response MEP.
- 40. CASE STUDY • In the Service compositions section of Chapter 5, we provided an example where the TLS Accounts Payable Service, upon receiving an invoice submission from a vendor, enlists the TLS Vendor Profile Service to validate the invoice header information. • The MEP used in this situation is the standard request-response pattern, where a response from the Vendor Profile Service is expected once it receives and processes the original request. The Accounts Payable Service requires a response to ensure that the header details provided in the invoice submission are valid and current (Figure 3). Failure to validate this information terminates the Invoice Submission Process and results in the Accounts Payable Service responding to the vendor with a rejection message. Figure 3. A sample request-response exchange between the TLS Accounts Payable and Vendor Profile Services.
- 41. Primitive MEPs Fire-and-forget • This simple asynchronous pattern is based on the unidirectional transmission of messages from a source to one or more destinations (Figure 4). Figure 4. The fire-and-forget MEP.
- 42. Primitive MEP-Fire and Forget A number of variations of the fire-and-forget MEP exist, including: • The single-destination pattern, where a source sends a message to one destination only. • The multi-cast pattern, where a source sends messages to a predefined set of destinations. • The broadcast pattern, which is similar to the multi- cast pattern, except that the message is sent out to a broader range of recipient destinations. The fundamental characteristic of the fire-and-forget pattern is that a response to a transmitted message is not expected.
- 43. Complex MEPs • Primitive MEPs can be assembled in various configurations to create different types of messaging models, sometimes called complex MEPs. • A classic example is the publish-and-subscribe model. The steps involved are generally similar to the following: Step 1. • The subscriber sends a message to notify the publisher that it wants to receive messages on a particular topic. Step 2. • Upon the availability of the requested information, the publisher broadcasts messages on the particular topic to all of that topic's subscribers.
- 44. Complex MEPs Figure 6. The publish-and-subscribe messaging model is a composite of two primitive MEPs. This pattern is a great example of how to aggregate primitive MEPs, as shown in Figure 6 and explained here: Step 1 in the publish-and-subscribe MEP could be implemented by a request-response MEP, where the subscriber's request message, indicating that it wants to subscribe to a topic, is responded to by a message from the publisher, confirming that the subscription succeeded or failed. Step 2 then could be supported by one of the fire-and-forget patterns, allowing the publisher to broadcast a series of unidirectional messages to subscribers.
- 45. MEPs and WSDL • Request-response operation Upon receiving a message, the service must respond with a standard message or a fault message. • Solicit-response operation Upon submitting a message to a service requestor, the service expects a standard response message or a fault message. • One-way operation The service expects a single message and is not obligated to respond. • Notification operation The service sends a message and expects no response. Figure 8. The four basic patterns supported by WSDL 1.1.
- 46. 3.5 ORCHESTRATION One of the driving requirements behind the creation of these solutions was to accommodate the merging of large business processes. With orchestration, different processes can be connected without having to redevelop the solutions that originally automated the processes individually.
- 47. ORCHESTRATION Business protocols and process definition • The workflow logic that comprises an orchestration can consist of numerous business rules, conditions, and events. • Collectively, these parts of an orchestration establish a business protocol that defines how participants can interoperate to achieve the completion of a business task. • The details of the workflow logic encapsulated and expressed by an orchestration are contained within a process definition.
- 48. ORCHESTRATION Process services and partner services • Identified and described within a process definition are the allowable process participants. First, the process itself is represented as a service, resulting in a process Figure 2. A process service coordinating and exposing functionality from three partner services
- 49. ORCHESTRATION • Other services allowed to interact with the process service are identified as partner services or partner links. Depending on the workflow logic, the process service can be invoked by an external partner service, or it can invoke other partner services (Figure 3). • Figure 3. The process service, after first being invoked by a partner service, then invokes another partner service.
- 50. ORCHESTRATION Basic activities and structured activities • WS-BPEL(Web services Business Process Execution Language) breaks down workflow logic into a series of predefined primitive activities. Basic activities (receive, invoke, reply, throw, wait) represent fundamental workflow actions which can be assembled using the logic supplied by structured activities (sequence, switch, while, flow, pick).
- 51. ORCHESTRATION Sequences, flows, and links • Basic and structured activities can be organized so that the order in which they execute is predefined. A sequence aligns groups of related activities into a list that determines a sequential execution order. Sequences are especially useful when one piece of application logic is dependent on the outcome of another. • Flows also contain groups of related activities, but they introduce different execution requirements. Pieces of application logic can execute concurrently within a flow, meaning that there is not necessarily a requirement for one set of activities to wait before another finishes. However, the flow itself does not finish until all encapsulated activities have completed processing. This ensures a form of synchronization among application logic residing in individual flows. • Links are used to establish formal dependencies between activities that are part of flows. Before an activity fully can complete, it must ensure that any requirements established in outgoing links first are met. Similarly, before any linked activity can begin, requirements contained within any incoming links first must be satisfied. Rules provided by links are also referred to as synchronization dependencies.
- 53. Case Study • TLS employs a WS-BPEL orchestration (Figure 5). Figure 5. The extended TLS Purchase Order Submission Process managed by an orchestration and involving numerous potential partner organizations.
- 54. CASE STUDY • The orchestration establishes comprehensive process logic that encompasses the business activity and extends it even further to govern additional interaction scenarios with multiple vendor services. For example, when one vendor cannot fulfill an order, the next vendor in line is sent the same purchase order. This cycle is repeated until either one vendor can complete the order in its entirety (within certain price limitations) or until all vendors have been queried. In the latter situation, the system simply assesses the best deal on the table by applying a formula that takes into account the price, percentage of order to be filled, and backorder terms. • The orchestration logic manages all aspects of the process, including the involvement of multiple vendor partner services, as well as the business activity that kicks in when a PO is processed.
- 55. 3.6 CHOREOGRAPHY • The Web Services Choreography Description Language (WS-CDL) is one of several specifications that attempts to organize information exchange between multiple organizations (or even multiple applications within organizations), with an emphasis on public collaboration (Figure 1). Figure 1. A choreography enables collaboration between its participants.
- 56. CHOREOGRAPHY Roles and participants • Within any given choreography, a Web service assumes one of a number of predefined roles. This establishes what the service does and what the service can do within the context of a particular business task. • Roles can be bound to WSDL definitions, and those related are grouped accordingly, categorized as participants (services). Relationships and channels • Each potential exchange between two roles in a choreography is therefore defined individually as a relationship • we require a means of establishing the nature of the conversation. Channels do exactly that by defining the characteristics of the message exchange between two specific roles. Interactions and work units • Interactions are the fundamental building blocks of choreographies because the completion of an interaction represents actual progress within a choreography. • Related to interactions are work units. These impose rules and constraints that must be adhered to for an interaction to successfully complete.
- 57. Finally, even though a choreography in effect composes a set of non-specific services to accomplish a task, choreographies themselves can be assembled into larger compositions. Figure 2. A choreography composed of two smaller choreographies.
- 58. Orchestrations and choreographies • An orchestration expresses organization-specific business workflow. This means that an organization owns and controls the logic behind an orchestration, even if that logic involves interaction with external business partners. • A choreography, on the other hand, is not necessarily owned by a single entity. It acts as a community interchange pattern used for collaborative purposes by services from different provider entities (Figure 3).
- 59. Orchestrations and choreographies Figure 3. A choreography enabling collaboration between two different orchestrations.
- 60. Orchestrations and choreographies ORCHESTRATION • Usually used in private business processes.A central process (which can be another Web service) takes control of the involved Web services. • Coordinates the execution of different operations on the web services involved in the operation. • The involved Web services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process. • Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of Web services. Choreography • Does not rely on a central coordinator. • Each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact. • Each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact. • All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges.
- 61. Choreography and SOA • Two services within a single organization, each exposing a simple function, can interact via a basic MEP to complete a simple task. Two services belonging to different organizations, each exposing functionality from entire enterprise business solutions, can interact via a basic choreography to complete a more complex task. Both scenarios involve two services, and both scenarios support SOA implementations. Choreography therefore can assist in the realization of SOA across organization boundaries (Figure 4).