답변:
(XML, SOAP, WSDL)과 같은 기본 기술은 서비스를 자체적으로 엔티티로 설명하고 찾고 호출하는 수단을 제공합니다. 그러나 이러한 기술은보다 복잡한 협업에서 서비스의 역할에 대한 자세한 동작 정보를 제공하지 않습니다. 이 협업에는 일련의 활동과 활동 사이의 관계가 포함되어있어 비즈니스 프로세스를 구축합니다. 이 프로세스를 구축하는 두 가지 방법이 있습니다 : 서비스 조정 및 서비스 안무.
서비스 오케스트레이션은 서로 다른 서비스 간의 상호 작용을 조정하는 단일 중앙 집중식 실행 가능 비즈니스 프로세스 (오케 스트레이터)를 나타냅니다. 오케 스트레이터는 서비스 호출 및 결합을 담당합니다.
참여하는 모든 서비스 간의 관계는 단일 엔드 포인트 (즉, 복합 서비스)로 설명됩니다. 오케스트레이션에는 개별 서비스 간의 트랜잭션 관리가 포함됩니다. 오케스트레이션은 서비스 구성을위한 중앙 집중식 접근 방식을 사용합니다.
서비스 안무는 메시지 교환, 상호 작용 규칙 및 둘 이상의 엔드 포인트 간 계약에 의해 정의되는 참여 서비스에 대한 전체 설명입니다. 안무는 서비스 구성을 위해 분산 된 접근 방식을 사용합니다.
안무는 여러 서비스 간의 상호 작용을 설명하며 오케스트레이션은 당사자의 관점에서 제어를 나타냅니다. 즉, 안무가 관련 서비스 간의 상호 작용을 제어하는 논리가 있어야하는 위치와 관련 하여 오케스트레이션 과 다릅니다 .
서비스 오케스트레이션 : 고정 된 로직으로 여러 서비스를 구성합니다. 이 논리는 한 곳에서 설명됩니다. 관리자가 미세 관리를하는 사람들로 구성된 팀을 상상할 수 있습니다. 관리자는 무엇을 언제 어떻게해야하는지 정확하게 알려줍니다. 팀 구성원은 작업의 전체 목표를 신경 쓰지 않고 관리자는 결과를 단일 결과물로 결합합니다. 실제 예는 BPEL 프로세스입니다. BPEL 프로세스에는 로직이 포함되어 있으며 여러 서비스를 호출하고 해당 응답을 단일 서비스 응답으로 결합 할 수 있습니다.
서비스 안무 : 의사 결정 논리가 중앙 집중식으로 배포되지 않습니다. 모든 사람이 공동의 이익을 목표로하고 소규모 관리없이 적극적으로 일하는 가정을 상상할 수 있습니다. 또는 다른 회원들이 상호 의존적이며 공동의 목표를 위해 노력하는 인체를 상상할 수 있습니다. 실제 예는 이벤트 중심 처리이며, 여기서 에이전트는 이벤트에 의해 활성화되고 작업을 수행합니다. 모든 에이전트는 시스템을 함께 만듭니다. 중앙 집중식 논리가 없습니다. 안무 가능성은 오케스트레이션을 넘어서 현실 세계와 더 잘 맞을 수 있습니다.
내 의견은 우리가 비즈니스 로직에 집중해야하므로,이 둘 사이에 많은 구별 할 필요가 없다는 것입니다. 단일 논리 지점이 작업을 수행하는 경우 오케스트레이션을 수행합니다. 중앙 집중식 논리로 문제를 해결할 수없는 경우 어쨌든 안무를해야합니다. 그렇기 때문에 우리는 종종 IT 분야에서 오케스트레이션을하는 반면, 안무는 학문적 개념이자 연구의 주제로 남아 있습니다. 그리고 현실 세계 에서처럼 실제로 그것을 모르고 안무를하는 경우가 종종 있습니다.
서비스는 원자 서비스와 다른 서비스로 구성된 서비스를 구별 할 수 있습니다. 이러한 구성을 "오케스트레이션"이라고합니다. 때로는 워크 플로, 때로는 비즈니스 프로세스. 예를 들어 BPEL은 오케스트레이션 언어이지만 "비즈니스 프로세스 실행 언어"라고합니다.
서비스를 계층 적으로 구성 할 필요는 없습니다. 즉, 두 서비스가 서로 통신 할 수 있습니다. 그들 사이에서 실행되는 프로토콜을 "안무"라고합니다. 두 가지 서비스 일 수 있지만 일반적으로 두 가지 이상의 서비스가 관련됩니다. 안무의 각 서비스는 파트너 서비스의 조정자로 볼 수 있습니다. 안무에 참여하는 각각의 서비스는 오케스트레이션 / 워크 플로우 / 프로세스로 실현 될 수있다.
오케스트레이션은 각 서비스의 전체 동작을 보여 주며 안무는 각 서비스의 인터페이스 동작 설명을 결합합니다.
안무, 인터페이스 행동, 제공자 행동 및 오케스트레이션을 구별하는 훌륭한 과학 논문은 다음과 같습니다 : Dijkman, R. & Dumas, M. 서비스 지향 디자인 : 다중 관점 접근법 337-368
실이 오래되었지만 여전히이 질문을 찾아 여기에서 넘어 질 사람들을 위해 쓰지 않았습니다. 이것은 SOA ( Service-Oriented Architecture) 에서 매우 논쟁의 여지가있는 질문으로 초보자에게는보다 명확한 설명이 필요합니다.
오케스트레이션 : 실행 가능한 프로세스
안무 : 다자간 협업
반대로 안무는 중앙 코디네이터에 의존하지 않습니다. 오히려 안무에 관련된 각 웹 서비스는 언제 언제 작업을 수행하고 누구와 상호 작용해야하는지 알고 있습니다. 안무는 공공 비즈니스 프로세스에서 메시지 교환에 중점을 둔 공동 노력입니다.
안무의 모든 참가자는 비즈니스 프로세스, 실행할 작업, 교환 할 메시지 및 메시지 교환시기를 알고 있어야합니다.
안무와 오케스트레이션
웹 서비스를 작성하여 비즈니스 프로세스를 실행한다는 관점에서 오케스트레이션은보다 유연한 패러다임이며 안무에 비해 다음과 같은 장점이 있습니다.
구성 요소 프로세스의 조정은 알려진 조정자가 중앙에서 관리합니다.
웹 서비스는 더 큰 비즈니스 프로세스에 참여하고 있다는 사실을 모르고 통합 될 수 있습니다.
Andrei와 다른 사람들은 오케스트레이션과 안무가 무엇인지 잘 설명했습니다. 소프트웨어 설계자가이 두 가지 대안 중 하나를 선택하려면 서로 다른 품질과 비교하여 비교해야합니다.
오케스트레이션은 안무보다 더해집니다
안무는 오케스트레이션을 능가합니다
성능 : 오케스트레이션은 워크 플로 스크립트 해석 및 오케스트레이션 플랫폼 자체의 추가 계층으로 인해 성능 오버 헤드가 발생합니다.
비용 : 안무는 학습 곡선과 거버넌스 부담과 관련된 추가 미들웨어 나 언어가 필요하지 않습니다.
오케 스트레이터 요소가 고 가용성을위한 메커니즘을 사용하지 않는 경우 오케스트레이션 솔루션에 SPOF가 도입 될 수 있습니다. 의견에서 이것을 지적하는 @Deepak por에게 감사드립니다.
안무가 고도로 분산 된 조직에 내부적으로 적합하다고 말하고 싶습니다. 중앙 비즈니스 프로세스 실행자가 필요하지 않습니다. 이는 각 조직 하위 단위에 의한 독립적 인 성장과 발전을 촉진합니다.
(나는 오케스트레이션 대 안무 질문에 대한이 해석에 가입합니다 : http://geekexplains.blogspot.com/2008/07/ways-of-combining-web-services.html )
오케스트레이션 은 프로세스의 모든 액터를 제어 할 수있는 경우 (모두 하나의 제어 도메인에 있고 활동의 흐름을 지시 할 수있는 경우)에 유용합니다. 이것은 물론 통제하는 한 조직 내에서 시행 될 비즈니스 프로세스를 지정할 때 가장 자주 발생합니다.
안무 는 둘 이상의 당사자가 다른 당사자의 프로세스 또는 해당 프로세스의 가시성을 제어 할 수없는 둘 이상의 당사자가 정보와 가치를 공유하기 위해 활동과 프로세스를 조정할 수있는 방법을 지정하는 방법입니다. 제어 / 가시성 영역에서 조정이 필요한 경우 안무를 사용하십시오. 간단한 시나리오에서 네트워크 프로토콜과 같은 안무를 생각할 수 있습니다. 그것은 수용 가능한 요청과 당사자 간의 응답 패턴을 지시합니다.
오케스트레이션에는 지휘자가 있으며 악기 연주자가 있습니다. 플레이어는 지휘자가 행동하는 방식에 따라 연주합니다. 컨덕터를 교체하면 고조파 표현이 달라집니다. 즉, 여전히 동일한 플레이 (서비스)이지만 다른 결과가 나타납니다. 예를 들어, 재정 준비 제안을 제공하기 위해 오케스트레이션 서비스는 지휘자 템플릿 (비즈니스)에 따라 각 플레이어 (엔터티 또는 유틸리티 서비스, 예를 들어 신용 확인)를 재생 (결과 반환 또는 재생 조정 / 업데이트)하도록 요청하여 수행합니다. 규칙). 안무에는 안무가가 있으며 무용수 그룹이 있습니다. 안무는 방향이지만, 각 댄서 그룹은 그 방향을 실현하는 방법에 자율적입니다.