오케스트레이션 대 안무

오케스트레이션 대 안무

---

조직 내 관점에서 서비스 오케스트레이션과 서비스 안무의 차이점은 무엇입니까?

---

(XML, SOAP, WSDL)과 같은 기본 기술은 서비스를 자체적으로 엔티티로 설명하고 찾고 호출하는 수단을 제공합니다. 그러나 이러한 기술은보다 복잡한 협업에서 서비스의 역할에 대한 자세한 동작 정보를 제공하지 않습니다. 이 협업에는 일련의 활동과 활동 사이의 관계가 포함되어있어 비즈니스 프로세스를 구축합니다. 이 프로세스를 구축하는 두 가지 방법이 있습니다 : 서비스 조정 및 서비스 안무.

서비스 오케스트레이션

서비스 오케스트레이션은 여러 서비스 간의 상호 작용을 조정하는 단일 중앙 집중식 실행 가능 비즈니스 프로세스 (오케 스트레이터)를 나타냅니다. 오케 스트레이터는 서비스 호출 및 결합을 담당합니다.

참여하는 모든 서비스 간의 관계는 단일 엔드 포인트 (즉, 복합 서비스)로 설명됩니다. 오케스트레이션에는 개별 서비스 간의 트랜잭션 관리가 포함됩니다. 오케스트레이션은 서비스 구성을위한 중앙 집중식 접근 방식을 사용합니다.

서비스 안무

서비스 안무는 메시지 교환, 상호 작용 규칙 및 둘 이상의 엔드 포인트 간 계약에 의해 정의되는 참여 서비스에 대한 전체 설명입니다. 안무는 서비스 구성을 위해 분산 된 접근 방식을 사용합니다.

안무는 여러 서비스 간의 상호 작용을 설명하며 오케스트레이션은 당사자의 관점에서 제어를 나타냅니다. 즉, 안무가 관련 서비스 간의 상호 작용을 제어하는 ​​논리가 있어야하는 위치와 관련 하여 오케스트레이션 과 다릅니다 .

---

서비스 오케스트레이션 : 고정 된 로직으로 여러 서비스를 구성합니다. 이 논리는 한 곳에서 설명됩니다. 관리자가 미세 관리를하는 사람들로 구성된 팀을 상상할 수 있습니다. 관리자는 무엇을 언제 어떻게해야하는지 정확하게 알려줍니다. 팀 구성원은 작업의 전체 목표를 신경 쓰지 않고 관리자는 결과를 단일 결과물로 결합합니다. 실제 예는 BPEL 프로세스입니다. BPEL 프로세스에는 로직이 포함되어 있으며 여러 서비스를 호출하고 해당 응답을 단일 서비스 응답으로 결합 할 수 있습니다.

서비스 안무 : 의사 결정 논리가 중앙 집중식으로 배포되지 않습니다. 모든 사람이 공동의 이익을 목표로하고 소규모 관리없이 적극적으로 일하는 가정을 상상할 수 있습니다. 또는 다른 회원들이 상호 의존적이며 공동의 목표를 위해 노력하는 인체를 상상할 수 있습니다. 실제 예는 이벤트 중심 처리이며, 여기서 에이전트는 이벤트에 의해 활성화되고 작업을 수행합니다. 모든 에이전트는 시스템을 함께 만듭니다. 중앙 집중식 논리가 없습니다. 안무 가능성은 오케스트레이션을 넘어서 현실 세계와 더 잘 맞을 수 있습니다.

내 의견은 우리가 비즈니스 로직에 집중해야하므로,이 둘 사이에 많은 구별 할 필요가 없다는 것입니다. 단일 논리 지점이 작업을 수행하는 경우 오케스트레이션을 수행합니다. 중앙 집중식 논리로 문제를 해결할 수없는 경우 어쨌든 안무를해야합니다. 그렇기 때문에 우리는 종종 IT 분야에서 오케스트레이션을하는 반면, 안무는 학문적 개념이자 연구의 주제로 남아 있습니다. 그리고 현실 세계 에서처럼 실제로 그것을 모르고 안무를하는 경우가 종종 있습니다.

---

서비스는 원자 서비스와 다른 서비스로 구성된 서비스를 구별 할 수 있습니다. 이러한 구성을 "오케스트레이션"이라고합니다. 때로는 워크 플로, 때로는 비즈니스 프로세스. 예를 들어 BPEL은 오케스트레이션 언어이지만 "비즈니스 프로세스 실행 언어"라고합니다.

There is no requirement that services need to be hierarchically composed. That means, two services may talk to each other. The protocol running between them is called "choreography". It may be two services, but usually, there are more than two services involved. Each service in a choreography may be seen as orchestrator of the partner services. Each service taking part in a choreography may be realized as orchestration/workflow/process.

An orchestration shows the complete behavior of each service whereas the choreography combines the interface behavior descriptions of each service.

A good scientific article distinguishing choreography, interface behavior, provider behavior, and orchestration is the following one: Dijkman, R. & Dumas, M. Service-oriented Design: A Multi-viewpoint Approach International Journal of Cooperative Information Systems, 2004, 13, 337-368

---

Since the thread is old but still writing to it for those who will stumbled here in search of this question as I did. This is much debated question in Service-oriented architecture (SOA) which needs much cleaner explanation for beginners.

Orchestration: Executable Process

• Used in private business processes
• A central process (which can be another Web service) takes control of the involved Web services and 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: Multi-party Collaboration

• Choreography, in contrast, does not rely on a central coordinator. Rather, each Web service involved in the choreography knows exactly when to execute its operations and with whom to interact. Choreography is a collaborative effort focusing on the exchange of messages in public business processes.

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

Choreography vs. Orchestration

• From the perspective of composing Web services to execute business processes, orchestration is a more flexible paradigm and has the following advantages over choreography:

• The coordination of component processes is centrally managed by a known coordinator.

• Web services can be incorporated without their being aware that they are taking part in a larger business process.

• Alternative scenarios can be put in place in case faults occur.

---

Andrei and others did a good job explaining what is orchestration and what is choreography. For the software architect choosing between these two alternatives, it is also important to compare them with respect to different qualities.

Orchestration pluses over choreography

• Reliability: Orchestration platforms have built-in support for error handling and transaction management (compensating transactions). In choreography, custom-developed workflow and error handling tends to be more error-prone.
• Modifiability: Creating and changing process workflows and complex service compositions is easier in the visual BPM tools found in orchestration platforms.

Choreography pluses over orchestration

• Performance: Orchestration incurs a performance overhead due to workflow script interpretation and the additional layer of the orchestration platform itself.

• Cost: Choreography does not require additional middleware or language, which have associated learning curves and governance burden.

---

Orchestration is useful when you have control over all the actors in a process - when they're all in one domain of control and you can dictate the flow of activities. This is of course most often when you're specifying a business process that will be enacted inside one organisation that you have control over.

Choreography is a way of specifying how two or more parties - none of which has any control over the other parties' processes, or perhaps any visibility of those processes - can coordinate their activities and processes to share information and value. Use choreography when coordination across domains of control/visibility is required. You can think of choreography, in a simple scenario, as like a network protocol. It dictates acceptable patterns of requests and responses between parties.

---

I'd say choreography is well suited internally for highly decentralized organizations. You won't need a central business process executor. This facilitates independent growth and development by each of organization sub-units.

(I subscribe to this interpretation of orchestration vs. choreography question: http://geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html)

---

Another way to look at Service Orchestration vs. Choreography:

- Service Orchestration: Around a Business Domain.
- Service Choreography: Among multiple Business Domains.

---

In orchestration, there is a conductor and there are instrument players. Players play according to how conductor conducts. If conductor is replaced, the harmonic expression will be different i.e. it is still the same play (service) but with a different outcome. For example, to provide a financial arrangement proposal, the orchestration service will conduct by asking (invoking) each player (entity or utility service, e.g. credit check) to play (return results or adjust/update its playing) according to conductor's template (business rules). In choreography, there is a choreographer and there are groups of dancers. Choreography is a direction, but each group of dancers is autonomous in how to realize that direction.

---

오케스트레이션은 일반적으로 낮은 수준의 서비스를 연결합니다. 중재자 와 같습니다 . 안무는 커플 링을 더욱 줄입니다. 나는 이것에 대해 더 자세히 설명 했다 .

참고 URL : https://stackoverflow.com/questions/4127241/orchestration-vs-choreography