Drexel University Date: 11/07/05


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Drexel University Date: 11/07/05

  1. 1. Drexel University Date: 11/07/05 CS 575 Dr. Mitchell Position Paper Project Team: Max Lincoln e-mail: mel34@drexel.edu Slava Sadkhin e -mail: vgs22@drexel.edu *** team contact Yaqi Zhang e-mail: yz63@drexel.edu Kathy Yang e-mail: kjy24@drexel.edu Topics in SOA: Orchestration versus Choreography Extended Abstract: Orchestration vs. Choreography in Single Organizational SOAs Services utilized within a Service Oriented Architecture (SOA) may be provided by different organizations. Often, a service provided by one organization may be the constructed by aggregating services provided by other organizations. This is especially common in Business-to-Business (B2B) transactions performed through the SOA. SOAs are useful in single organizational environments as well, however. In a Business to Consumer (B2C) service over an SOA, a service may be an aggregation of services provided by a single organization. Two distinct styles of composing a single service from multiple services exist. Services based on the orchestration model have a central control point, which may invoke both internal and external services. Choreographed services do not have a central control point, requiring each service to know how it interacts with other services. Choreographed services have the advantage in B2B transactions that a central party does not have to be defined to control the service, but it also means that services require more knowledge of each other to interact. This paper considers usage models for Choreography and Orchestration within a single- organization, B2C application. It argues that the centralized control provided by Orchestrated services offers many benefits to application development and maintenance, and simplifies the high-level picture of the SOA so it can more easily be understood and implemented. Web Services Web services are business processes that run over a network using standards such as XML-RPC or, most commonly, SOAP. SOAP stands for the Simple Object Access Protocol but this is generally considered a misnomer, and there is a movement in a software engineering community to redefine SOAP acronym to better reflect direction in Service Oriented Architecture. This architecture is principally an XML messaging standard, where XML documents are sent to and optionally returned from URLs, referred to as service endpoints. Web Services can be viewed as an extension of component models, such as Sun's Enterprise JavaBeans (EJB) and Microsoft's Component Object Model (COM). With the introduction of web services, “web services composition” is used to describe the composition of web services into a process. We can derive two ways to design a service composition: choreography or orchestration. Martin Chapman, co-chair of the WS-
  2. 2. Choreography working group and a member of Oracle's Web-services strategy team emphasizes the importance of careful defining the differing process composition terminology used in the industry, such as orchestration, collaboration, coordination, conversations: "By orchestration you mean there is a central controller and the business process is run by that controller, and by choreography you mean there is no controller and the business process is run in a distributed way by each of the participants..." Choreography Choreography is defined as “collaboration between some enterprise services to achieve a common goal”. It doesn’t focus on one service, but its control logic is visible when services interact with each other. The relationship between the distributed services can be tracked by the sequence of messages that may involve, for instance, multiple parties and multiple sources, including customers and suppliers. Choreography is typically associated with the public message exchanges that occur between multiple web services, rather than a specific business process that is executed by a single party. One of characteristics of Choreography an organization needs to consider are simple consumer oriented interactions. Processes are short-lived and don’t require business collaboration. Companies should not make their emphasis on security and reliability. There is no one centralized repository, and processes require synchronization with much maintenance costs involved over the long run. In choreography, services must perform transformations themselves, or call a service to perform the transformation. Steps in choreography are performed to following a predefined scheme, maintaining its overall global perspective. So, Choreography is more collaborative, and each party involved in a process has a specific part of interaction. It implies that there is no centralized control, and actual control is shared among module domains. For example, large ERP systems consist of functional modules. Each independent module maintains its integrity and consistency through the use of synchronizing interfaces. Each interface behaves to a predefined collaboration scheme, where all exceptions are managed based on system’s state. If a purchase order is received and distributed, then the related transaction information needs to be updated on accounts payable side. This is done through an interface where each required field has to be filled in and validated. Orchestration On another hand, Orchestration implies a centralized control mechanism. It describes a behavior that “a service provider implements to realize a service”. Orchestration describes how web services can interact with each other at the message level, including the business logic and execution order of the interactions. A step process model is introduced to deal with these interactions. An orchestration processes are run by orchestration engines, which act as the central control point. Since orchestration uses a centralized control point, this central point may be used to handle problems that all services may face. For example, an orchestration process engine could act as a primary transaction, security and reliability manager. Orchestration can also help 2
  3. 3. reduce coupling between services, since they do not communicate directly, and the input/output of each service may be transformed by the orchestration engine to “fit” services together. Orchestration-oriented languages such as BPML and BPEL support these capabilities. An advantage that we are looking for in an orchestrated approach is that web services are controlled to be dynamic, adaptable and flexible to changing business needs. If the web services utilized are granular enough, business processes may be changed by changing the way the services interact or the set of services used, rather than by changing the underlying service implementations. The largest advantage of an orchestrated service may lie at the conceptual level. Orchestrated systems are easy to understand, implement, and maintain, since the interaction between services happens in a consistent way. Unlike most choreography-based approaches, services do not need to consider and synchronize state, which results in less design and implementation time, and less lines of code. Combining Orchestration and Choreography Orchestration and choreography are mutually exclusive high-level process management patterns, but it is important to note that a real-life system may use a combination of the two. Although they are mutually exclusive, it is possible to layer the technologies. For example, it is not uncommon for choreographed services to consist of orchestrated participants. In this case, the global business process is defined by the choreographed interaction, but each participant may be defining an internal business process through orchestration. In this scenario, the choreographed process would likely be multi-organizational, while the orchestrated process would be within an organization. A simple example of this type of combination is shown in Figure 1. The opposite scenario is also possible, orchestrated services may utilize a choreographed process. This is illustrated in Figure 2. This scenario seems to negate many of the benefits of both choreography and orchestration. For example, it has added a central control point to an otherwise choreographed system, and it has coupled the services so that the process can’t be redefined using only changes at the orchestration engine level. (Peltz, IEEE). 3
  4. 4. (Shin, Sun Microsystems) Conclusion Web services standards for process execution and modeling based on the concept of aggregating services into a process are still developing. There are many options available to organizations, which makes the choice of a standard a difficult one that should be thoroughly investigated. However, several architectural styles have emerged to classify the different standards, and organizations may use characteristics of these styles to guide their investigations. In this paper, we found that the orchestration style, characterized principally by a central control point, offers advantages to business processes that do not cross-organizational boundaries. Coordination was found to have some benefits for cross-organizational processes. Therefore, projects that are proposed within the scope of a single organization should seriously consider using an orchestration-based approach to their SOA. Since choreographed services often utilize orchestrated participants, this approach does not prevent systems from becoming part of cross-organizational processes later. 4
  5. 5. References: Chris Peltz, “Web services orchestration and choreography”, Computer, Volume 36, Issue 10, Oct. 2003 Page(s):46 - 52, IEEE. R. Shapiro "A Comparison of XPDL, BPML, and BPEL4WS," draft document, Cape Visions, May 2002; http://xml.coverpages.org/Shapiro-XPDL.pdf. S. Kumaran and P. Nandi "Conversational Support for Web Services: The Next Stage of Web Services Abstraction," research report, IBM developerWorks, Sept. 2002; http://www-128.ibm.com/developerworks/webservices/library/ws-conver/. BPMI, "The BPML Specification", http://www.bpmi.org/bpml-spec.htm BEA Systems, IBM Corporation, Microsoft Corporation, SAP AG, Siebel Systems, “Business Process Execution Language for Web Services, Version 1.1”, May 5, 2003; http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/. 5