오케스트레이션 대 안무


답변:


334

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

서비스 오케스트레이션

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

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

관현악법

서비스 안무

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

안무

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


7
환상적인 이미지가 둘을 보여줍니다! 어디서 구했습니까?
David Mann

6
@DavidMann 귀하의 의견에 감사드립니다. 유용하다고 생각되면 투표하십시오. 이 다이어그램을 Visio에서 만들었으며 영감을 얻어 서비스 구성에 일부 문헌을 사용했습니다. 그러나 나는이 구성이 2 년 전에 서비스 구성에 대해 읽기 시작했을 때 깨달았다는 것을 깨달았습니다. 이 답변을 참조로 업데이트하고 두 가지의 재산권을 확장 할 것입니다.
Andrei

@Andrei : 이것보다 더 간단하지 못했습니다.
Anshul Nigam

오케스트레이션과 안무를 혼합하는 것이 합리적입니까? 예를 들어 핵심 동기 워크 플로에 대한 오케스트레이션이 있지만 일부 안무가 비동기 이벤트를 소스 기능 (마이크로 서비스)으로 다시 스트리밍합니다. 내 시나리오 에서이 접근법은 사가 / 상태 머신 및 보상 로직을 수행하지 않아도됩니다.
Ryan.Bartsch

1
일부 독자는 오케스트레이션 다이어그램에서 오케스트레이션이 제어 서비스에서 서비스 제공에 대한 동기 호출을 의미한다고 추측 할 수 있습니다. Invoke-Reply 통신은 비동기 메소드를 사용하여 수행 할 수 있음을 분명히하고 싶습니다. 메시지 브로커를 통해.
Christoph

34

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

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

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


21

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

서비스를 계층 적으로 구성 할 필요는 없습니다. 즉, 두 서비스가 서로 통신 할 수 있습니다. 그들 사이에서 실행되는 프로토콜을 "안무"라고합니다. 두 가지 서비스 일 수 있지만 일반적으로 두 가지 이상의 서비스가 관련됩니다. 안무의 각 서비스는 파트너 서비스의 조정자로 볼 수 있습니다. 안무에 참여하는 각각의 서비스는 오케스트레이션 / 워크 플로우 / 프로세스로 실현 될 수있다.

오케스트레이션은 각 서비스의 전체 동작을 보여 주며 안무는 각 서비스의 인터페이스 동작 설명을 결합합니다.

안무, 인터페이스 행동, 제공자 행동 및 오케스트레이션을 구별하는 훌륭한 과학 논문은 다음과 같습니다 : Dijkman, R. & Dumas, M. 서비스 지향 디자인 : 다중 관점 접근법 337-368


19

실이 오래되었지만 여전히이 질문을 찾아 여기에서 넘어 질 사람들을 위해 쓰지 않았습니다. 이것은 SOA ( Service-Oriented Architecture) 에서 매우 논쟁의 여지가있는 질문으로 초보자에게는보다 명확한 설명이 필요합니다.

오케스트레이션 : 실행 가능한 프로세스

  • 개인 비즈니스 프로세스에 사용
  • 중앙 프로세스 (다른 웹 서비스 일 수 있음)는 관련 웹 서비스를 제어하고 해당 작업과 관련된 웹 서비스에서 서로 다른 작업의 실행을 조정합니다.
  • 관련 웹 서비스는 컴포지션 프로세스와 관련이 있으며 상위 비즈니스 프로세스에 참여하고 있음을 "알지"않아도됩니다.
  • 오케스트레이션의 중앙 코디네이터 만이이 목표를 인식하므로 오케스트레이션은 조작의 명시 적 정의 및 웹 서비스 호출 순서로 중앙 집중화됩니다.

여기에 이미지 설명을 입력하십시오

안무 : 다자간 협업

  • 반대로 안무는 중앙 코디네이터에 의존하지 않습니다. 오히려 안무에 관련된 각 웹 서비스는 언제 언제 작업을 수행하고 누구와 상호 작용해야하는지 알고 있습니다. 안무는 공공 비즈니스 프로세스에서 메시지 교환에 중점을 둔 공동 노력입니다.

  • 안무의 모든 참가자는 비즈니스 프로세스, 실행할 작업, 교환 할 메시지 및 메시지 교환시기를 알고 있어야합니다.

여기에 이미지 설명을 입력하십시오

안무와 오케스트레이션

  • 웹 서비스를 작성하여 비즈니스 프로세스를 실행한다는 관점에서 오케스트레이션은보다 유연한 패러다임이며 안무에 비해 다음과 같은 장점이 있습니다.

  • 구성 요소 프로세스의 조정은 알려진 조정자가 중앙에서 관리합니다.

  • 웹 서비스는 더 큰 비즈니스 프로세스에 참여하고 있다는 사실을 모르고 통합 될 수 있습니다.

  • 결함이 발생할 경우 대체 시나리오를 적용 할 수 있습니다.

1
실제로, 안무는 일반적으로 중앙 조정자에 의존하며 일반적으로 조정자는 일종의 분산 메시지 브로커입니다. 메시지 브로커와 같은 것을 사용하지 않으면 매우 유연하지 않은 방식으로 서비스를 묶어 취성 및 재사용 성이 떨어집니다.
Rodney P. Barbati

8

Andrei와 다른 사람들은 오케스트레이션과 안무가 무엇인지 잘 설명했습니다. 소프트웨어 설계자가이 두 가지 대안 중 하나를 선택하려면 서로 다른 품질과 비교하여 비교해야합니다.

오케스트레이션은 안무보다 더해집니다

  • 안정성 : 오케스트레이션 플랫폼은 오류 처리 및 트랜잭션 관리 (보상 트랜잭션)를 기본적으로 지원합니다. 안무에서 사용자 정의 개발 워크 플로 및 오류 처리는 오류가 발생하기 쉬운 경향이 있습니다.
  • 수정 가능성 : 오케스트레이션 플랫폼에있는 시각적 BPM 도구에서 프로세스 워크 플로 및 복잡한 서비스 구성을 만들고 변경하는 것이 더 쉽습니다.

안무는 오케스트레이션을 능가합니다

  • 성능 : 오케스트레이션은 워크 플로 스크립트 해석 및 오케스트레이션 플랫폼 자체의 추가 계층으로 인해 성능 오버 헤드가 발생합니다.

  • 비용 : 안무는 학습 곡선과 거버넌스 부담과 관련된 추가 미들웨어 나 언어가 필요하지 않습니다.

편집하다

오케 스트레이터 요소가 고 가용성을위한 메커니즘을 사용하지 않는 경우 오케스트레이션 솔루션에 SPOF가 도입 될 수 있습니다. 의견에서 이것을 지적하는 @Deepak por에게 감사드립니다.


3
안무를 제외하고는 추가 미들웨어가 필요합니다. 요구 사항 (작업)은 다른 노드와 일치해야합니다. 그 후 안무가 전개, 제정, 모니터링 및 조정됩니다. 이 모든 관리에는 일반적으로 미들웨어가 제공하는 도구가 필요합니다.
Andrei

1
오케스트레이션은 안무에서는 그렇지 않은 단일 실패 지점의 단점을 가져 오지 않습니까?
Deepak


6

오케스트레이션 은 프로세스의 모든 액터를 제어 할 수있는 경우 (모두 하나의 제어 도메인에 있고 활동의 흐름을 지시 할 수있는 경우)에 유용합니다. 이것은 물론 통제하는 한 조직 내에서 시행 될 비즈니스 프로세스를 지정할 때 가장 자주 발생합니다.

안무 는 둘 이상의 당사자가 다른 당사자의 프로세스 또는 해당 프로세스의 가시성을 제어 할 수없는 둘 이상의 당사자가 정보와 가치를 공유하기 위해 활동과 프로세스를 조정할 수있는 방법을 지정하는 방법입니다. 제어 / 가시성 영역에서 조정이 필요한 경우 안무를 사용하십시오. 간단한 시나리오에서 네트워크 프로토콜과 같은 안무를 생각할 수 있습니다. 그것은 수용 가능한 요청과 당사자 간의 응답 패턴을 지시합니다.


5

Service Orchestration vs. Choreography를 보는 다른 방법 :

-서비스 오케스트레이션 : 비즈니스 영역 주변.
-서비스 안무 : 여러 비즈니스 도메인 중.


1

오케스트레이션에는 지휘자가 있으며 악기 연주자가 있습니다. 플레이어는 지휘자가 행동하는 방식에 따라 연주합니다. 컨덕터를 교체하면 고조파 표현이 달라집니다. 즉, 여전히 동일한 플레이 (서비스)이지만 다른 결과가 나타납니다. 예를 들어, 재정 준비 제안을 제공하기 위해 오케스트레이션 서비스는 지휘자 ​​템플릿 (비즈니스)에 따라 각 플레이어 (엔터티 또는 유틸리티 서비스, 예를 들어 신용 확인)를 재생 (결과 반환 또는 재생 조정 / 업데이트)하도록 요청하여 수행합니다. 규칙). 안무에는 안무가가 있으며 무용수 그룹이 있습니다. 안무는 방향이지만, 각 댄서 그룹은 그 방향을 실현하는 방법에 자율적입니다.


-1

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

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.