UNIT II-WEB SERVICES (WS) AND PRIMITIVE

Web services — Service descriptions — Messaging with SOAP —Message Exchange Patterns — Service activity—Coordination —Atomic Transactions — Business activities — Orchestration — Choreography

1. Kongunadu College of Engineering and Technology Department of Computer Science and Engineering 20IT703PE-SERVICE ORIENTED ARCHITECTURE By, Mrs.Vahidhabanu Y, ASP / CSE

2. UNIT II WEB SERVICES (WS) AND PRIMITIVE SOA

3. Web services Service descriptions Messaging with SOAP Message Exchange Patterns Service activity Coordination Atomic Transactions Business activities Orchestration Choreography

4. Web services Web services is software systems designed to support interoperable machine-to machine interaction over a network. Interoperability is gained through a set of XML-based open standards, such as WSDL,SOAP, and UDDI. A web service is used to implement architecture according to service-oriented architecture(SOA) concepts. The basic unit of communication is a message.

5. A Web Service is can be defined by following ways: It is a client-server application or application component for communication. The method of communication between two devices over the network. It is a software system for the interoperable machine to machine communication. It is a collection of standards or protocols for exchanging information between two devices or application.

6. Web service framework what is a web service framework? It's an ensemble of tools and libraries used to deploy a web service. As a web service developer, a framework is like a tons of features already developed/thought-out that you can use in your own way to deliver your web service faster. Examples of features handled by frameworks: client-server messaging, authentication and sessions management, files operations, etc.

7. Service Descriptions Description documents are required To accompany any service wanting to act as ultimate receiver Primary service description document is the WSDL definition WSDL – Web Service Description Language WSDLs enable loose coupling between services

8. WSDL definitions enable loose coupling between services

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

10. Each service requestor is using the WSDL of a service provider to ensure that messages sent will be understood and accepted.

11. Abstract description Concrete description Metadata and service contracts Semantic descriptions Service description advertisement and discovery

12. Service endpoints and service descriptions 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.

13. A WSDL service description Also known as WSDL service definition (or) WSDL definition WSDL definition contains two categories Abstract description Concrete description Fig 16: WSDL document consisting of abstract and concrete parts that collectively describe a service endpoint.

14. 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.   Three main parts: portType – high-level view of service interface . Sorts messages into groups of functions called Operations Operation – a specific action performed by the service . (Think public method for components in traditional distributed applications) Message – parameters are represented as messages . An operation consists of a set of input and output messages

15. WSDL Concrete Description Abstract interface definition Must be connected to a real, implemented technology This connection is defined in concrete description portion of WSDL file, This portion consists of three related parts : Binding The requirements to establish physical connection with the service (SOAP,…) Port The physical address for the service Service The service represents a group of related endpoints

16. Metadata and Service Contracts WSDL definitions rely on XSD schemas To formalize the structure of messages Policies are supplementary information in a WSDL Policies provide Rules, Preferences, and Processing details beyond what is expressed in the WSDL and schema

17. Fig 17 : A service contract comprised of a collection of service descriptions and possibly additional documents

18.  Semantic descriptions Most of the metadata currently provided by services focuses on expressing technical information related to data representation and processing requirements.  Examples of service semantics include: how a service behaves under certain conditions how a service will respond to a specific condition what specific tasks the service is most suited for

19. Service Description Advertisement & Discovery As the number of services within and without organizations increases, Advertising mechanisms may be needed UDDI formed the first generation of Web service standards . (Not commonly implemented) Central directories and registries allow humans and service requestors to : Locate the latest versions of known service descriptions Discover new Web services

20. Registries Public Accept registrations from organizations with or without Web services They act as service provider entities Private Can be implemented within an organization To provide a central repository for descriptions of services

21. Fig 18 : Service description locations centralized in a registry

22. Business entities and business services UDDI Components Business entities and business services Binding Templates and tModels 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). This record includes one or more business service areas , Each of them provides a description of the services offered by the business entity .

23. Messaging with SOAP

24. What is SOAP ? SOAP is an XML-based protocol for accessing web services over HTTP. It has some specification which could be used across all applications. SOAP is known as the Simple Object Access Protocol, but in later times was just shortened to SOAP v1.2. SOAP is a protocol or in other words is a definition of how web services talk to each other or talk to client applications that invoke them. SOAP was developed as an intermediate language so that applications built on various programming languages could talk easily to each other and avoid the extreme development effort.

25. Why SOAP Exchanging data between applications is crucial in today’s networked world. But data exchange between these heterogeneous applications would be complex. One of the methods used to combat this complexity is to use XML (Extensible Markup Language) as the intermediate language for exchanging data between applications . But there are no standard specifications on use of XML across all programming languages for data exchange. That is where SOAP software comes in. SOAP was designed to work with XML over HTTP and have some sort of specification which could be used across all applications.

26. SOAP Building Blocks The SOAP specification defines something known as a “ SOAP message ” which is what is sent to the web service and the client application.

27. An Envelope element that identifies the XML document as a SOAP message – This is the containing part of the SOAP message and is used to encapsulate all the details in the SOAP message. This is the root element in the SOAP message. A Header element that contains header information – The header element can contain information such as authentication credentials which can be used by the calling application. It can also contain the definition of complex types which could be used in the SOAP message. By default, the SOAP message can contain parameters which could be of simple types such as strings and numbers, but can also be a complex object type.

28. A simple SOAP service example of a complex type we wanted to send a structured data type which had a combination of a “Tutorial Name” and a “Tutorial Description,” then we would define the complex type as shown below. The complex type is defined by the element tag < xsd:complexType >. All of the required elements of the structure along with their respective data types are then defined in the complex type collection.

29. A Body element that contains call and response information – This element is what contains the actual data which needs to be sent between the web service and the calling application. Below is an SOAP web service example of the SOAP body which actually works on the complex type defined in the header section. Here is the response of the Tutorial Name and Tutorial Description that is sent to the calling application which calls this web service.

30. SOAP Message Structure The Envelope element The header element and The body element The Fault element (Optional)

31. As seen from the above SOAP message, the first part of the SOAP message is the envelope element which is used to encapsulate the entire SOAP message. The next element is the SOAP body which contains the details of the actual message. Our message contains a web service which has the name of “Guru99WebService”. The “Guru99Webservice” accepts a parameter of the type ‘ int ’ and has the name of TutorialID .

32. SOAP Envelope Element The first bit of the building block is the SOAP Envelope. The SOAP Envelope is used to encapsulate all of the necessary details of the SOAP messages, which are exchanged between the web service and the client application. The SOAP envelope element is used to indicate the beginning and end of a SOAP message. This enables the client application which calls the web service to know when the SOAP message ends.

33. The Fault message When a request is made to a SOAP web service, the response returned can be of either 2 forms which are a successful response or an error response. When a success is generated, the response from the server will always be a SOAP message. But if SOAP faults are generated, they are returned as “HTTP 500” errors.

34. < faultCode > – This is the code that designates the code of the error. The fault code can be either of any below values SOAP- ENV:VersionMismatch – This is when an invalid namespace for the SOAP Envelope element is encountered. SOAP- ENV:MustUnderstand – An immediate child element of the Header element, with the mustUnderstand attribute set to “1”, was not understood. SOAP- ENV:Client – The message was incorrectly formed or contained incorrect information. SOAP- ENV:Server – There was a problem with the server, so the message could not proceed.

35. < faultString >  – This is the text message which gives a detailed description of the error. < faultActor > (Optional) – This is a text string which indicates who caused the fault. <detail>(Optional)  – This is the element for application-specific error messages. So the application could have a specific error message for different business logic scenarios.

36. Practical SOAP Example

37. Message styles/Communication model The SOAP communication model explains the client-server communication protocol for accessing remote objects. Remote Procedure Call (RPC) Document (Message)-style SOAP Services

38. Remote Procedure Call (RPC) A remote procedure call (RPC) type web service appears as a remote control object to a client application. Interactions between a client and an RPC-style Web services center around a service-specific interface. Clients declare their request as a method call with a set of arguments, Returns a response containing a return value.

39. Document (Message)-style SOAP Services In the messaging document style, SOAP contains <Body> XML document part. The <Body> element does not reflect any explicit XML structure. The SOAP runtime environment accepts the SOAP <Body> element as is and passes it to the designated application.Invariably There may or may not be a response associated with this the message.

40. Case Study Submitting an invoice b/w RailCo and its customer includes: Generation and mailing of invoice Generation and mailing of account statement for currently outstanding amounts Generation and mailing of discount reminder to explain RailCo’s pricing and to show the customer how close they are to a discount All 3 of these documents needed to be included in same SOAP message

41. RailCo Invoice Submission Service packaging the contents of 3 documents into one SOAP message .

42. Nodes Programs that services use to transmit and send SOAP messages are SOAP nodes SOAP nodes must conform to SOAP specification , As a result SOAP messages are vendor-neutral A SOAP node transmitting a SOAP message received by the service logic

43. Node Types

44. Node Types SOAP sender A SOAP node that transmits a message SOAP receiver A SOAP node that receives a message SOAP intermediary A SOAP node that receives and transmits a message with optional processing Initial SOAP sender The first SOAP node to transmit the message Ultimate SOAP receiver The last SOAP node to receive a message

45. Different types of SOAP nodes involved with processing a message

46. Positioning of SOAP nodes within a message transmission between RailCo and TLS. In RailCo Invoice Submission Service, the underlying SOAP server s/w (represent the initial SOAP sender node) executes the transmission of SOAP message via HTTP

47. SOAP intermediaries SOAP intermediary Responsible for relaying the contents of a message to a subsequent SOAP node . A forwarding SOAP intermediary Process & alter header block information relating to the forwarding logic . Ex: It will remove a header block it has processed, as well as any header blocks that cannot be relayed any further. An active SOAP intermediary Not required to limit its processing logic to the rules & instructions provided in header blocks of a message it receives. Can alter existing header blocks, insert new ones, & execute a variety of supporting actions

48. Message Paths A message path Route taken from being sent to ultimate arrival Message path modeling is becoming increasingly important for large SOA Use of header blocks can alter the path dynamically

49. A message path consisting of three Web services

50. Message Exchange Patterns

51. Introduction All business task require the transmission of multiple messages . Challenge lies in coordinating these messages in a particular sequence S o that the individual actions performed by the message are Executed properly and in alignment with the overall business task Not all message exchanges require both requests and responses

52. MEPs MEPs represent a set of templates That provide a group of already mapped out sequences For the exchange of messages . Most common example is a request and response pattern . It states that Upon successful delivery of a message from one service to another, R eceiving service responds with a message back to the initial requestor.

53. Primitive MEPs Before the arrival of contemporary SOA , Messaging frameworks were used by messaging-oriented middleware products . As a result, a common set of primitive MEPs has been in existence for some time. Request-Response Fire-and-Forget Complex MEPs

54. Request-response MEP Most popular MEP in use among distributed application environments This pattern defines synchronous communication This pattern establishes a simple exchange A message is first transmitted from a source (service requestor) to a destination (service provider). Upon receiving the message, destination (service provider) then responds with a message back to the source (service requestor).

55. Case Study TLS Accounts Payable Service U pon receiving an invoice submission from a vendor , Enlists the TLS Vendor Profile Service to validate the invoice header information A sample request-response exchange b/w the TLS Accounts Payable and Vendor Profile Services

56. Fire-and-Forget MEP This simple asynchronous pattern is based on unidirectional transmission of messages from a source to one or more destinations Several variations: Single-destination pattern : a source sends a message to one destination only Multi-cast pattern : a source sends messages to a predefined set of destinations Broadcast pattern : similar to multi-cast, except that message is sent to a broader range of recipient destinations A response to a transmitted message is not expected

57. Case Study TLS Accounts Payable Service contains a rule W hen an invoice header fails validation, an e-mail notification is generated . To execute this step, Accounts Payable Service sends a message to Notification Service TLS Accounts Payable Service sending off a one-way notification message

58. Complex MEPs Primitive MEPs can be assembled in various configurations To create different types of messaging models , called as complex MEPs A classic example is the publish-and-subscribe model Services involved with this model have new roles – Publishers and Subscribers Two Steps involved Subscriber sends a message to notify the publisher that it wants to receive messages on a particular topic. Upon the availability of the requested information, the publisher broadcasts messages on the particular topic to all of that topic's subscribers .

59. Publish-and-subscribe messaging model is a composite of two primitive MEPs

60. Case Study Notification Service periodically generates and distributes notification messages for a number of different topics Some pass the notification on as an e-mail to select accounting personnel. TLS Notification Service notifying subscribers about a problem condition via a notification broadcast.

61. MEPs and SOAP SOAP standard provides its own messaging framework To support single-direction message transfer Extensible nature of SOAP Allows many messaging characteristics and behaviors to be implemented via SOAP header blocks SOAP also provides an optional parameter That can be set to identify the MEP associated with a message

62. MEPs and WSDL WSDL operations support Different configurations of incoming, outgoing, and fault messages Within WSDL specification , they’re often simply referred to as patterns

63. Four MEPs applied to service operations Release 1.1 of WSDL specification provides support for 4 MEPs These MEPs are applied to service operations , represented as follows 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 Service expects a single message and is not obligated to respond. Notification operation Service sends a message and expects no response

64. Four MEPs applied to service operations

65. Eight MEPs applied to service operations Release 2.0 of WSDL specification extends MEP support to 8 patterns in-out pattern out-in pattern in-only pattern out-only pattern robust in-only pattern robust out-only pattern in-optional-out pattern out-optional-in pattern

66. Service activity

67. Introduction Completion of business tasks is a major function of any automated solution Tasks are comprised of processing logic that executes To fulfill a number of business requirements. In service-oriented solutions, Each task can involve any number of services . Interaction of a group of services working together to complete a task can be referred to as a service activity Note : “Activity” is a generic term that is most frequently associated with a logical unit of work completed by a collection of services. Fig . In an activity, multiple Web services collaborate to do a specific piece of work.

68. Primitive service activities Scope of an activity can drastically (hugely) vary. A simple or primitive activity Typified (Demonstrated) by synchronous communication Therefore often consists of 2 services exchanging information using a standard request-response MEP (Figure ). Primitive activities are almost always short-lived ; E xecution of a single MEP generally constitutes the lifespan of a primitive activity Fig 11. A primitive service activity consisting of a simple MEP

69. Primitive service activities A business task automated by A series of custom-developed services and without the use of a composition extension Can easily be classified a complex activity.

70. Complex service activities Complex activities can involve many services (and MEPs) That collaborate to complete multiple processing steps over a long period of time These more elaborate types of activities are Generally structured around extension-driven and composition-oriented concepts , Such as choreography and orchestration . Fig 6.12. A complex activity involving four services

71. Case Study Message path traveled by a RailCo invoice submission is a great example of a complex activity. Recap Initial sender, RailCo's Invoice Submission Service , transmits the invoice message . Message is first received by a passive intermediary , TLS's Load Balancing Service , which routes the message according to environmental conditions . The message subsequently arrives at TLS's Accounts Payable Service . Accounts Payable Service acts as a controller and initiates a service composition to begin processing the message contents . It begins by interacting with the Vendor Profile Service to validate invoice header data and attaches the invoice document to the vendor account . Accounts Payable Service then extracts taxes, shipping fees, and the invoice total . It passes these values to the Ledger Service , which updates various ledger accounts, including the General Ledger. Finally the activity ends, as the Accounts Payable Service completes its processing cycle by sending a response message back to RailCo .

72. Case Study These processing steps constitute a complex activity involving five services Fig 6.13. A sample complex activity spanning RailCo and TLS boundaries

73. Service activities and SOA In SOAs, Activities represent any service interaction required to complete business tasks. Scope of a service activity is Primarily concerned with the processing and communication b/w services only. Underlying application logic of each Web service is Generally not mapped as part of a service activity. Complex activities are commonplace in larger service-oriented solutions And can involve numerous participating services.

74. Coordination -

75. Coordination A framework is required To provide a means for context information in complex activities To be managed, preserved and/or updated, and distributed to activity participants. Coordination establishes such a framework Fig 6.14. Coordination provides services that introduce controlled structure into activities

76. Coordinator composition The coordinator composition consists of the following services: Activation service Creates a new context and associates this context to a particular activity . Registration service Allows participating services to use context information (received from the activation service) to register for a supported context protocol . Protocol-specific services Represent the protocols supported by the coordinator's coordination type . Coordinator Controller service of this composition , also known as the coordination service

77. Coordinator composition WS-Coordination establishes a framework That introduces a generic service based on the coordinator service model (Figure 6.15). This service controls a composition of three other services That each play a specific part in the management of context data . Fig 6.15. The coordinator service composition

78. Coordination types and protocols Each coordinator is based on a coordination type , Coordination type specifies the nature and underlying logic of an activity For which context information is being managed. Coordination types are specified in separate specifications . WS-Coordination framework is extensible It can be utilized by different coordination types, including custom variations. But the 2 coordination types are commonly associated with WS-Coordination : WS- AtomicTransaction and WS- BusinessActivity .

79. Coordination types and protocols Coordination type extensions provide a set of coordination protocols The coordination protocols R epresent unique variations of coordination types , and Consist of a collection of specific behaviors and rules . A protocol is best viewed as a set of rules That are imposed on activities A nd which all registered participants must follow

80. Coordination contexts & coordination participants A context created by activation service is referred as a coordination context . A coordination context contains A collection of information that represents the activity and various supplementary data. Examples of type of data held within a coordination context include: A unique identifier that represents the activity An expiration value Coordination type information

81. Coordination contexts & coordination participants A service that wants to take part in an activity managed by WS-Coordination Must request the coordination context (from the activation service) . The service then can use this context information To register for one or more coordination protocols . A service that has received a context and has completed registration is considered a participant in the coordinated activity .

82. The activation and registration process Coordination service composition is instantiated (initiated) When an application service contacts the activation service (Figure 6.16). Via a CreateCoordinationContext request message , It asks the activation service to generate a set of new context data. Fig 6.16 The WS-Coordination registration process

83. The activation and registration process Once passed back with the ReturnContext message , Application service now can invite other services to participate in the coordination This invitation consists of the context information The application service originally received from the activation service. Any Web service in possession of this context information May issue a registration request to the registration service . This allows the service to enlist in a coordination based on a specific protocol. Upon a successful registration, a service is officially a participant. Registration service passes the location of the coordinator service to participant service, With which all participants are required to interact. At this time, the coordination service is also sent the address of the new participant.

84. The completion process Application service can request that a coordination be completed By issuing a completion request message to the coordination service. Coordinator , in turn, then issues its own completion request messages to all coordination participants . Each participant service responds with a completion acknowledgement message Fig 6.17. The WS-Coordination completion process .

85. Coordination and SOA A coordinator-based context management framework (provided by WS-Coordination and its supporting coordination types), introduces a layer of composition control to SOAs (Figure 6.18). It standardizes the Management and interchange of context information within a variety of key business protocols Fig 6.18. Coordination as it relates to other parts of SOA

86. Coordination and SOA Coordination also alleviate (lightens) the need for services to retain state . Statelessness is a key service-orientation principle Applied to services for use within SOAs . Coordination reinforces this quality By assuming responsibility for the management of context information .

87. Case Study In the previous case study example, An individual process steps that comprised a complex activity . Once the processing of this activity enters the TLS environment, TLS employs a context management system to coordinate the flow of message through its internal services Fig 6.19. TLS Accounts Payable, Vendor Profile, and Ledger Services being managed by a coordination

88. Case Study Coordination is applied to the following steps: 3. Accounts Payable Service uses the Vendor Profile Service To validate the invoice header data. If the data is valid, the invoice document is attached to the vendor account . 4. Accounts Payable Service extracts taxes & shipping fees from the invoice document. Tax & shipping fees values, along with the invoice total, are submitted to Ledger Service . Ledger Service is responsible for updating the General Ledger & numerous sub-ledgers, such as the Accounts Payable Ledger. Atomic transaction coordination type is used to coordinate these processing steps

89. Atomic transactions -

90. MEPs and WSDL Transactions have been around as long as automated computer solutions have existed. Atomic transactions implement the familiar commit and rollback features To enable cross-service transaction support Figure 6.20. Atomic transactions apply an all-or-nothing requirement to work performed as part of an activity.

91. ACID Transactions The protocols provided by the WS-AtomicTransaction specification enable cross-service transaction functionality comparable to the ACID-compliant transaction features found in most distributed application platforms Four required characteristics of a traditional transaction Note: Concepts discussed in this section were derived from the WS-AtomicTransaction specification, which defines protocols for use with WS-Coordination

92. Business activities

93. Business activities govern long-running, complex service activities. Hours, days, or even weeks can pass before a business activity is able to complete. During this period, the activity can perform numerous tasks that involve many participants. For instance, business activity protocols do not offer rollback capabilities. Given the potential for business activities to be long-running, it would not be realistic to expect ACID-type transaction functionality. Instead, business activities provide an optional compensation process that, much like a "plan B," can be invoked when exception conditions are encountered 

94. Orchestration -

95. Introduction Orchestration is a centrally controlled set of workflow logic That facilitates interoperability b/w 2 or more different applications. A common implementation is the hub-and-spoke model It allows multiple external participants to interface with a central orchestration engine An orchestration controls almost every facet of a complex activity

96. What Orchestration Does? With orchestration, Different processes can be connected without having to redevelop the solutions that originally automated the processes individually Orchestration bridges this gap By introducing new workflow logic By reducing the complexity of solution environments. Workflow logic is more easily maintained than when embedded within individual solution components.

97. Business protocols and process definition 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 A business protocol defines How participants can interoperate to achieve the completion of a business task. Details of workflow logic are encapsulated and expressed by an orchestration They are contained within a process definition.

98. Process services and partner services Process itself is represented as a service , resulting in a process service A process service coordinating and exposing functionality from three partner services Other services allowed to interact with the process service are identified as partner services or partner links.

99. Invoke of Process Service Depending on the workflow logic, Process service can be invoked by an external partner service , (or) Process service can invoke other partner services The process service, after first being invoked by a partner service, then invokes another partner service

100. Basic activities and structured activities An activity is a generic term that can be applied to any logical unit of work Completed by a service-oriented solution . Basic activities (receive, invoke, reply, throw, wait) Represent fundamental workflow actions Basic activities can be assembled Using the logic supplied by structured activities (sequence, switch, while, flow, pick). Basic and structured activities can be organized So that the order in which they execute is predefined .

101. Sequences and Flows 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, There is no requirement for one set of activities to wait before another finishes.

102. Links Links are used to establish dependencies b/w activities that are part of flows . Before any linked activity can begin , Requirements contained within any incoming links first must be satisfied . Before an activity can complete , I t must ensure that any requirements established in outgoing links first are met . Rules provided by links are also referred to as synchronization dependencies .

103. Orchestration and SOA Business process logic is at the root of automation solutions , Orchestration provides an automation model where process logic is centralized. Orchestrations establish a common point of integration for other applications These lead to increased organizational agility because: Workflow logic encapsulated by an orchestration can be modified or extended in a central location Positioning an orchestration centrally can ease the merging of business processes By establishing potentially large-scale service-oriented integration architectures , orchestration can support the evolution of a diversely federated enterprise

104. Orchestration relating to other parts of SOA

105. Case Study Extended TLS Purchase Order Submission Process managed by an orchestration and involving numerous potential partner organizations Orchestration establishes process logic that includes the business activity and extends it further to govern additional interaction scenarios with multiple vendor services. Ex : 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. Finally, the system simply assesses the best deal on the table

106. Choreography -

107. Introduction Choreographies are intended for public message exchanges Goal is to establish a kind of organized collaboration b/w services representing different service entities No one entity (organization) controls the collaboration logic

108. A choreography enables collaboration between its participants . WS-CDL is the specification Chosen to represent the concept of choreography

109. Need for Interoperation Requirement for organizations to interoperate via services is needed. During collaboration, interoperation requirement is more important Here, multiple services from different organizations need to work together to achieve a common goal. Web Services Choreography Description Language (WS-CDL) It is a specification that attempts to organize information exchange b/w multiple organizations (or even multiple applications within organizations), with an emphasis on public collaboration

110. Components of choreographies Roles and Participants Within a choreography, a web service assumes one of a umber of predefined roles . Relationships and channels Every action within a choreography is broken down into a series of message exchanged b/w two services. Each potential exchange is defined as a relationship . Interactions and work units Actual logic behind a message exchange is encapsulated with an interaction , which is the fundamental building block of choreographies .

111. Reusability, composability, and modularity Each choreography can be designed in a reusable manner , Allowing it to be applied to different business tasks comprised of same fundamental actions Using an import facility , A choreography can be assembled from independent modules . These modules can represent distinct sub-tasks They can be reused by numerous different parent choreographies

112. A choreography composed of two smaller choreographies. A choreography composes a set of non-specific services to accomplish a task, Choreographies themselves can be assembled into larger compositions.

113. Orchestrations and choreographies Orchestration expresses organization-specific workflow . This means that an organization owns and controls the logic behind an orchestration , even if that logic involves interaction with external business partners Choreography is not necessarily owned by a single entity It acts as a community interchange pattern An orchestration can be view as a business-specific set of a choreography

114. A choreography enabling collaboration b/w 2 different orchestrations

115. Choreography and SOA Concept of exposing business logic through autonomous services can be applied to any implementation scope . 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 Support SOA implementations.

116. Choreography relating to other parts of SOA. Choreography assist in understanding of SOA across organization boundaries.

117. Choreography and SOA Choreography S upports composability , reusability, and extensibility, Increase organizational agility and discovery. Organizations are able to join into multiple online collaborations, which can dynamically extend or even alter related business processes that integrate with the choreographies. By being able to pass around channel information, Participating services can make third-party organizations aware of other organizations with which they already have had contact.

118. A choreography enabling collaboration b/w 2 different orchestrations