2016년 12월 7일 수요일

BPEL

BPEL


Business Process Execution Language(혹은 BPEL)란, 실행 가능한 비즈니스 프로세스 모델링 언어이다.그러나, BPEL은 특정의 세만틱이나 프로세스 구조의 요소를 가지고 있지 않기 때문에, 생각할 수 있는 모든 비즈니스 프로세스를 모델화해 실행하는 것은 불가능하다.이 때문에, BPEL은 예를 들어 Java와 같은 프로그램 언어와 함께 이용되거나 워크플로우 통합 브로커 엔진등의 상업용 제품에 갖춰지고 있는 독자적인 스크립트 언어에 의해서 확장되는 것이 많다.

BPEL의 기원은 WSFL와 XLANG에 거슬러 올라갈 수 있다.BPEL은 XML에 의해서 시리아라이즈 가능하고, 대규모 프로그래밍의 개념을 실현하는 것이다.대규모 프로그래밍과 소규모 프로그래밍의 개념은, 비즈니스 프로세스로 전형적으로 볼 수 있는 장시간 계속하는 비동기의 프로세스를 기술할 때의 두 개의 측면에 의해서 분류할 수 있다.

BPEL이 IBM와 마이크로소프트에 의해서 개발된 것은, BPMI.org (Business Process Management Initiative)가 개발한 초기의 언어 BPML에 대항하기 위해(때문에)에서 만났다.이 배경에 대해서는 몇개의 논의가 있지만, 아마, 다양한 그룹에서 상세한 것에 대하여 합의할 수 없는 성격에 의할 것이라고 생각된다.워크플로우 이론이 선조인 BPEL과는 달라, BPML는 Pi calculus로부터 착상 되었다.이 때문에, BPML는 완전하고 정식화된 문법을 가지게 되어, 시장에는 강력한 BPML의 제품이 등장하게 되었다.이 때문에, 어플리케이션 서버 개발을 통일하는 표준에 대해서 통제력을 가지고 싶다고 생각하고 있던 IBM와 마이크로소프트는 염려를 가졌다.

오늘로는, 과거의 BPEL과 BPML와의 차이는 거의 학술적인 것이 되어 있다.BPEL의 문법이 승리를 거두어 BPML의 의미론이 승리를 거두었다.IBM와 마이크로소프트의 힘에 의해, 오늘 BPEL의 이름이 남아 있다.BPEL은 서서히 BPML로 가까워질 방향으로 진화하고 있다.BPML가 형식상 완전하기 때문에, 이것은 불가피이다.


목차

목적

대규모 프로그래밍은, 추상도의 높은 프로세스여, BPEL으로는 이러한 프로세스를 추상 프로세스라고 부르고 있다.BPEL의 추상 프로세스는, 규격화된 방법으로 표현된 행동을 나타내고 있다.추상 프로세스는, 메시지를 기다린다, 메시지를 송신하는, 실패한 트랜잭션의 보상을 하는 등의 처리가 기술되고 있다.그것과는 대조적으로, 소규모 프로그래밍은, 1개의 트랜잭션으로 끝나는, 생존 기간의 짧은 행동을 취급한다.소규모 프로그래밍과 대규모 프로그래밍으로는 다른 언어가 필요하다라고 말하는 발상으로부터 BPEL은 태어났다.

BPEL의 설계 목표

BPEL에는 원래 10의 설계 목표가 있었다:

  1. 외부의 실체에 대해서 WSDL 1.1을 이용해 정의된 Web 서비스의 조작을 개입시켜 교환해, 자신을 WSDL 1.1을 이용해 정의된 Web 서비스로서 선언하는 비즈니스 프로세스를 정의하는 것.교환은, portType의 정의에 의존해 포토의 정의에는 의존하지 않는다고 하는 의미로"추상적"인 것.
  2. XML에 근거한 언어에 의해 비즈니스 프로세스를 정의하는 것.프로세스의 그래피컬한 표현 방법을 정의하거나 프로세스를 위한 특정의 설계 수법을 제공한 하는 것이 아닌 것.
  3. 비즈니스 프로세스의 외부(추상적) 및 내부(실행 가능) 뷰의 양쪽 모두로 이용하기 위한, Web 서비스를 조직화의 개념을 정의하는 것.그러한 비즈니스 프로세스는, 하나의 자율적인 존재의 행동을 정의해, 기술적으로는 비슷한 상대와 종합 작용을 실시한다.각각의 사용법의 패턴(즉 추상 뷰와 실행 가능 뷰)은 몇개의 전문화된 확장을 필요로 하지만, 이러한 확장은 최소한으로 유지되어 import/export나, 두 개의 사용법의 패턴을 묶는 링크가 사양에 준거하는, 등의 요구에 대해서 테스트되어 있지 않으면 안 된다.
  4. 계층적인, 또 그래프적인 제어의 방식을 제공해, 양쪽 모두의 사용법을 가능한 한 심리스에 융합시키는 것.이것에 의해 프로세스 모델링 공간의 분단을 감소시킨다.
  5. 프로세스의 데이터나 제어 플로우를 정의하기 위해서 필요한, 단순한 데이터 조작의 기능을 서포트한다.
  6. 인스턴스 식별자의 정의를 어플리케이션 레벨의 메시지 레벨로 허가하는 프로세스 인스턴스의 식별 메커니즘을 서포트한다.인스턴스의 식별자 파트너에 의해서 정의되어 변경될 가능성이 있다.
  7. 암묵적인 프로세스 인스턴스의 생성과 소멸을 기본적인 라이프 사이클 기구로서 서포트한다."suspend"나"resume"과 같은 고도의 라이프 사이클 조작은 라이프 사이클 관리를 위한 장래의 릴리스로 추가될 가능성이 있다.
  8. 변제의 액션이나, 장기에 걸쳐 유효한 비즈니스 프로세스의 일부를 위한 에러 회복 기능을 서포트하기 위해(때문에) 문제 판정(scoping)과 같은, 증명된 기술에 근거한, 장기에 걸쳐 유효한 트랜잭션 모델을 정의한다.
  9. Web 서비스를 프로세스의 분해와 결합의 모델로서 이용한다.
  10. Web 서비스의 표준(인증되어 제안된 것) 위에, 가능한 한 조립해 가능한 방법으로 구축된다.

BPEL 언어

BPEL은 오케스트레이션(Orchestration) 언어이며, 코레오그라피(choreography) 언어는 아니다(en:Web Service Choreography 참조).오케스트레이션과 코레오그라피의 주된 차이는 그 범위이다.코레오그라피모델이 어느 참가자로부터의 뷰(예를 들어 피어 투 피어 모델)에 초점을 두고 있지만, 오케스트레이션모델은 모든 관계자와 관련한 교환을 포함해, 시스템의 전체적인 뷰를 준다.오케스트레이션과 코레오그라피의 구별은 다음 같게 비유된다：오케스트레이션이, 오케스트라의 지휘자와 같은 집중관리의 행동을 기술해, 코레 오구라 요금은 안무 된(choreographed) 댄스로, 댄서가 서로의 페어의 행동해 반응하도록(듯이), 각각의 참가자가 외부의 이벤트에 근거한 처리를 실행하는, 분산 제어의 행동을 기술한다.

BPEL의 현대적인 비즈니스 프로세스에 대한 초점, 한층 더 WSFL 및 XLANG의 역사로부터, BPEL은 Web 서비스를 외부의 통신 메커니즘으로서 채용하게 되었다. 그 때문에, BPEL의 메시징 능력은, 입출력되는 메시지를 기술하기 위한 WSDL1. 1의 사용법에 의존한다.

메시지의 송신 수신을 실시할 수 있는 능력을 제공하는 것에 가세하고, BPEL 프로그램 언어는 아래와 같은 항목을 서포트한다：

  • 프롭퍼티에 근거하는 메시지간 관련 기구
  • XML 및 WSDL의 형태에 근거하는 변수
  • 표현이나 문의를 복수의 언어로 쓸 수 있도록(듯이)하기 위한 , 확장 가능한 언어 플러그 인 모델：BPEL은 XPath1. 0을 디폴트로 서포트하고 있다
  • if-then-elseif-else, while, sequence(커멘드를 순서대로 실행한다), flow(커멘드를 병렬에 실행한다)를 포함한 구조화 프로그래밍 요소
  • 로컬 변수, 장해 핸들러, 보상 핸들러, 이벤트 핸들러를 이용한 논리의 캡슐화를 가능하게 하는 스코프 시스템
  • 변수에의 병행적인 액세스를 제한하기 위한 시리아라이즈 된 스코프

WS-BPEL 2.0으로의 변경점

  • 새로운 액티버티의 형태: repeatUntil, validate, forEach(병렬, 직렬), rethrow, extensionActivity, compensateScope
  • 명칭의 변경된 액티버티: switch/case는 if/else에, terminate은 exit에 개명되었다
  • 타미네이션한드라가, 명시적인 종료의 액티버티에 적용하기 위해서 추가되었다
  • 변수의 초기화
  • 변수 변환을 위한 XSLT(새로운 XPath 확장 함수 bpws:doXslTransform)
  • 변수의 데이터에의 XPath 액세스(XPath 변수의 문법$variable[. part]/location)
  • Web 서비스 액티버티에 있어서의 XML schema 변수(WS-I doc/lit 스타일 서비스용)
  • 로컬에 정의된 messageExchange (수신 액티버티와 답신 액티버티의 내부적인 대응)
  • 추상 프로세스의 명문화(문법 및 의미)
  • 각각의 액티버티에 대해 기술 언어의 변경을 가능하게 했다

BPEL에의'소규모 프로그래밍'의 서포트의 추가 편

BPEL의'if-then-elseif-else'나'while'등의 제어 구조나, 변수 조작의 기능은, 논리를 제공하기 위한 '소규모 프로그래밍'언어를 사용하는 것에 의존하고 있다.모든 BPEL 실장은 XPath 1.0을 디폴트의 언어로서 서포트해야 하지만, BPEL의 설계는 시스템 구축자가 다른 언어도 사용할 수 있도록 생각할 필요가 있다. BPELJ는, Java가 BPEL내의'소규모 프로그래밍'로서 기능할 수 있도록하기 위한 JSR 207에 관련한 시도이다.

역사

IBM와 마이크로소프트는, 각각이 정의한 꽤 잘 닮은'대규모 프로그래밍'언어 WSFL와 XLANG을 가지고 있었다.BPML의 평판과 등장, BPMI.org의 성공, Intalio Inc.에 리드된 개방적인 BMPS에의 추진 활동에 의해, IBM와 마이크로소프트는 서로의 언어를 하나의 새로운 언어 BPEL4WS에 통합하는 것을 결정했다. 2003년 4월, BEA 시스템즈, IBM, 마이크로소프트, SAP, Siebel Systems는, Web Services BPEL Technical Committee를 개입시켜 OASIS에 BPEL4WS 1.1을 제출했다. BPEL4WS는 1.0으로 1.1의 양쪽 모두의 버전으로 등장했지만, OASIS WS-BPEL 기술 위원회[1]은 2004년 9월 14일에, 그 사양을 WS-BPEL 2.0이라고 부르는 것을 투표에 의해 결정했다.이 명칭의 변경은, BPEL을, WS-로 시작되는 다른 Web 서비스 표준의 명명 규칙에 맞추어 BPEL4WS 1.1으로 WS-BPEL 2.0과의 사이의 대폭적인 사양의 강화를 나타내기 위해서 행해졌다.다만 특정의 버전에 대해 논의하고 있지 않으면, BPEL만으로 충분하다.

2007년 6월, Active Endpoints, Adobe Systems, BEA 시스템즈, IBM, 오라클, SAP은 BPEL4People 및 WS-HumanTask 사양을 릴리스 했다.이것은, BPEL 프로세스에 대해 인간의 활동을 어떻게 수중에 넣는지 기술하는 것이다.

BPEL의 개발의 방향에 대해서는 서서히 논쟁이 일어나 오고 있다.WS-HumanTask의 형태로 BPEL에 세만틱을 추가하는 등의 요구는, BPEL이 완전한 언어가 아니다고 하는 사실을 강조할 뿐이다.반대로, 실용적인 어플리케이션으로는, 거의 항상, 다른 프로그래밍 툴로 언어를 확장할 필요가 있다.완전한 언어인 BPML로는, BPEL을 확장할 때 필요한 것 같게 XML에 새로운 태그를 추가하는 것이 아니라, 새로운 시멘틱스를 프로세스로서 실현될 수 있다.그 때문에, 이른바 BPEL 준거의 제품을 사용할 때 , 벤더가 주장하는 것이 어느 버전의 BPEL인지에 대단한 주의가 필요하다.BPEL 준거의 제품은, BPEL만으로는, 반드시 하나의 비즈니스 프로세스조차 실현될 수 없다.이것이 의미하는 곳은, 현장에서만 밝혀진다.비록이라고 말한다면, 연산자가 없기 위해(때문에) 완전한 코드를 쓸 수 없는 프로그램 언어를 가지고 있는 것이다.

BPEL의 BPMN과의 관계

OASIS 기술 위원회가 스코프외로 했기 때문에, WS-BPEL을 위한 그래피컬한 기법으로 표준은 없다.몇개의 벤더는 각각의 그래피컬한 기법을 낳고 있다.이러한 기법은 대부분의 BPEL 요소가 블록 구조인(예를 들어 sequence, while, pick, scope등)인 것을 이용하고 있다.이 기능에 의해, BPEL 기술을 옛 Nassi-Shneiderman diagram에 있어서의 structograms를 생각이 미치는 형태로 직접 비주얼에 표현할 수 있다.

완전히 다른 비즈니스 프로세스 모델링 언어, Business Process Modeling Notation (BPMN)를, BPEL 프로세스 기술을 표현하는 그래피컬한 프론트엔드로서 이용하는 것을 제안하고 있는 사람도 있다.이 방법의 실현성을 나타내는 것으로서 BPMN 사양에는 비공식에서 부분적이지만 BPMN으로부터 BPEL 1.1에의 매핑이 포함되어 있다.

BPMN으로부터 BPEL에의 보다 상세한 매핑은, BPMN2BPEL 등 오픈 소스의 것을 포함한 복수의 툴에 의해 실현되고 있다.그러나, 이러한 툴의 개발에 의해 BPMN과 BPEL의 사이의 근본적인 차이가 밝혀져, BPMN 모델로부터 인간이 이해할 수 있는 BPEL 코드를 생성하는 것은 매우 곤란, 경우에 따라서는 완전히 불가능하다라고 하는 것이 안[요점 출전].한층 더 곤란한 것은, BPMN과 BPEL의 사이의 왕복 여행 기술, 즉 한쪽에 가세한 변경이 이제 한쪽에 반영되도록(듯이), BPMN의 그림으로부터 BPEL 코드를 생성해, 오리지날의 BPMN 모델을 유지하면서, 생성된 BPEL 코드를 동기 시키는 것이다.

관련 항목

표준 규격

BPEL 및 비즈니스 프로세스의 사이트

BPEL 관련의 기사

「https://ja.wikipedia.org/w/index.php? title=BPEL&oldid=50409669」로부터 취득

This article is taken from the Japanese Wikipedia BPEL

This article is distributed by cc-by-sa or GFDL license in accordance with the provisions of Wikipedia.

Wikipedia and Tranpedia does not guarantee the accuracy of this document. See our disclaimer for more information.

In addition, Tranpedia is simply not responsible for any show is only by translating the writings of foreign licenses that are compatible with CC-BY-SA license information.

0 개의 댓글:

댓글 쓰기

피드 구독하기: 댓글 (Atom)