Korea [국가변경]

관련 시리즈 자세히 보기: SOA로 변형하기

이 기사 내에서 :
	BPEL 개요
	UML을 사용하는 이유
	웹 서비스를 위해 BPEL 매핑하기
	UML-to-BPEL 변형에 의한 UML 요소 해석
	더 배울 점
	참고자료
	필자소개
	기사에 대한 평가

관련 링크:
	Rational 기술자료
	SOA와 웹서비스 기술자료
	The Rational Edge

한국 developerWorks > Rational | SOA와 웹서비스 >

SOA로 변형하기: Part 4. IBM Rational Software Architect에서 웹 서비스가 UML에서 BPEL로 변환하는 프로세스

Purchase Order Process 모델의 예

문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

영어원문

제안 및 의견

피드백

난이도 : 중급

Murali Pattathe, Advisory Software Developer, IBM Canada

2008 년 6 월 17 일

본 글은 UML(Unified Modeling Language)에서 BPEL 프로세스 구현의 세부사항을 어떻게 설계하는지 설명합니다. UML은 유스케이스, 협업, 데이터, 인터페이스, 클래스, 컴포넌트, 인터랙션, 상태, 액티비티(activity) 모델링을 더 편리하고, 이해하기 쉬우면서도 일반적으로 잘 실행되도록 지원합니다. 그러므로 UML을 활용해 다양한 플랫폼 아키텍처로 변환할 수 있는 애플리케이션 모델을 얻을 수 있습니다. 이 글에서는 UML 산출물을 BPEL 산출물로 변환하는 과정을 보여줍니다.

BPEL4WS(Business Process Execution Language for Web Services, 또는 BPEL)는 XML 기반 표준으로, 웹 서비스에 기반을 둔 비즈니스 프로세스 동작을 지정한다. 이는 WSDL(Web Services Definition Language)과 XSD(XML Schema Definition) 상에서 만들어졌다. UML-to-BPEL 변형은 IBM Rational Software Architect나 Rational Software Modeler처럼 UML 도구에서 개발된 프로세스의 모델이고 프로세스를 구현하는 데 필요한 올바른 BPEL, XSD, WSDL 파일로 이 모델들을 전환한다.

현재 IBM® Rational® Software Architect(7.0.0.5)에서 실행될 수 있는 UML-to-BPEL 변형은 독립적이지 않으므로 변형만을 행하지 않는다. 대신 필요하다면 UML-to-SOA(service-oriented architecture) 변형으로 호출된다. Rational Software Architect는 소프트웨어 아키텍트가 시스템을 디자인하는 데 도움이 되는 유용한 도구를 많이 제공한다. UML-to-XSD나 UML-to-WSDL 같은 UML 변형은 Rational Software Architect에서만 가능하고 UML-to-BPEL 변형은 이를 사용해 XSD와 WSDL 산출물을 생성한다.

BPEL 개요

BPEL은 웹 서비스를 기반으로 비즈니스 프로세스 동작을 지정하는 XML 개념과 관계형 시맨틱을 제공한다. BPEL4WS 프로세스는 파트너와의 인터랙션에 의해 정의된다. 파트너는 프로세스에 서비스를 제공하거나 프로세스에서 서비스를 필요로 하거나 프로세스로 두 방향 인터랙션에 참여한다. 그러므로 BPEL은 서비스 수집을 호출하는 데 영향을 주고 각 서비스의 파트너에게 책임을 부여하는 명령을 지정함으로써 웹 서비스 통합을 조정한다. 이를 사용해 파트너의 공개 인터페이스와 실행 가능한 프로세스의 설명 모두를 지정할 수 있다.

UML을 사용하는 이유

UML은 복잡한 시스템을 디자인하고 이해하는 데 도움이 되는 시각적 모델링 개념을 제공하는 OMG(Object Management Group)의 표준이다. 몇 가지 일반적인 이점이 있다.

가장 널리 알려진 객체 지향 모델링 개념이다.
쉽게 이해할 수 있는 그림 형태의 표기법을 사용한다.
객제 지향 시스템의 주 기능을 알 수 있는 풍부한 의미 집합을 제공한다.

UML은 객체 지향 소프트웨어를 개발하는 데 널리 사용된다. 또한 커스터마이제이션과 함께 컴포넌트 기반 소프트웨어, 비즈니스 프로세스 모델링, 서비스 모델링, 시스템 디자인에 쓰여 왔다. 그러므로 UML의 주 경험을 적용해 웹 서비스 기술을 성장시킬 수 있었다.

웹 서비스를 위해 BPEL 매핑하기

UML-to-BPEL 변형은 다음과 같은 접근을 사용해 BPEL 파일을 생성한다.

BPEL 프로세스는 UML 컴포넌트를 기반으로 생성된다.
BPEL 범위는 UML 컴포넌트의 각각의 UML Activities에 대해 BPEL 프로세스 안에서 생성된다.
BPEL 파트너 링크는 UML 컴포넌트가 가지는 포트의 세부사항을 기반으로 생성된다.

UML-to-BPEL 변형 요구사항은 UML Activity 설계 프로세스를 고려해야 한다.

여기서 핵심은 UML-to-BPEL 변형이 현재 Rational Software Architect V.7.0.0.4와 BPEL 산출물을 생성하는 데 필요한 UML 모델링의 주요 요구사항에서 지원하는 방법이다. 본 글은 Activity 다이어그램을 설계할 때 Purchase Order Process라는 샘플 모델을 사용해 몇 가지 UML-to-BPEL 변형 요구사항을 설명한다.

현재 UML-to-BPEL 변형 프로세스는 UML을 확장하거나 커스터마이즈할 필요가 없지만 Activity 다이어그램을 설계할 때 몇 가지 세부사항을 가지고 있어야 한다.

Purchase Order Process 모델의 세부사항

샘플 프로세스를 자세히 살펴보자. UML OrderProcessor Component는 네 가지 포트를 가지고 있다.

Purchasing이라는 제공된 인터페이스를 포함하는 Purchasing 포트
InvoiceProcessing이라 부르는 제공된 인터페이스와 Inovoicing이라는 필수 인터페이스를 포함하는 Invocing 포트
Scheduling이라 부르는 필수 인터페이스를 가지는 Scheduling 포트
ScheduleProcessing이라는 제공된 인터페이스와 Shipping이라 부르는 필수 인터페이스를 포함하는 Shipping 포트

UML processPurchaseOrder Activity는 컴포넌트를 위해 필요한 모든 구현 세부사항을 제공하는 OrderProcessor Component가 소유한 동작이다.

그림 1은 OrderProcessor(UML Component) 소유의 동작인 UML Activity를 보여준다. OrderProcessor 컴포넌트는 그림 2에서 보여준다.

그림 1. UML Activity인 processPurchaseOrder

그림 2. UML Component인 OrderProcessor

이는 스펙에 대한 적절한 값을 설정하는 것이다.

Purchasing::processPurchaseOrder(customerInfo:Customer, 
purchaseOrder:PurchaseOrder):Invoice

Activity는 Activity 스펙 연산의 매개변수와 일치하는 Activity 매개변수를 가지고 있어야 한다. 앞의 그림 1에서 본 Activity는 customerInfo를 나타내는 세 가지 Activity 매개변수 노드를 가지고 있다.

Customer
purchaseOrder: PurchaseOrder
invoice: Invoice

주의:
Activity 매개변수는 연산 매개변수 서명과 반드시 일치해야 한다.

UML-to-BPEL 변형은 Listing 1에서 설명하는 코드인 두 개의 출력 매개변수와 BPEL Receive 액티비티를 생성한다.

Listing 1. processPurchaseOrder 프로세스에서의 BPEL Receive 액티비티

                
<bpws:receive createInstance="yes" name="processPurchaseOrder" 
operation="processPurchaseOrder" partnerLink="purchasingPurchasing" 
portType="ns2:Purchasing">
      <wpc:output>
        <wpc:parameter name="customerInfo" variable="processpurchaseorder_customerInfo"/>
        <wpc:parameter name="purchaseOrder" variable=
"processpurchaseorder_purchaseOrder"/>
      </wpc:output>
</bpws:receive>

컴포넌트의 각 포트를 나타내는 Receive 액티비티에는 세 가지 파티션(Invoicing, Shipping, Scheduling)이 있다. 이들은 컴포넌트의 포트와 일치하는 각 파티션의 속성을 나타낸다. 컨트롤 흐름은 Receive 액티비티의 initialNode에서 시작하고 forkNode에 연결된다. 세 가지 controlFlows는 forkNode에서 시작하고 각각은 다른 Action에 연결된다. 이는 컨트롤이 forkNode에 다다를 때 액션의 다중 시퀀스가 작동한다는 것을 의미한다. UML-to-BPEL 변형은 흐름에서 BPEL Flow 액티비티와 세 가지 BPEL 시퀀스를 생성한다.

컨트롤 흐름이 initialNode에서 시작하면 이것은 forkNode에 연결된다. 세 가지 controlFlows가 forkNode에서 시작하고 각각은 하나의 Action에 연결된다. 이는 컨트롤이 forkNode에 다다를 때 액션의 다중 시퀀스가 동시에 실행될 수 있다는 것을 의미한다. UML-to-BPEL 변형은 흐름에서 BPEL 흐름 액티비티와 세 가지 BPEL 시퀀스를 생성한다.

forkNode에서 나오는 첫 번째 컨트롤 흐름을 살펴보자. 흐름은 initiatePriceCalculation라는 Action(Call Operation action)에 연결되고 액션의 UML 오퍼레이션은 이것으로 설정된다.

PurchaseOrderProcess::com::acme::credit:
:Invoicing::initiatePriceCalculationOperation(customerInfo
        : Customer, purchaseOrder : PurchaseOrder)

그러므로 Action은 세 가지 inputPins를 가진다. 가장 오른쪽의 inputPin이 targetInputPin(핀 이름은 액션이 액티비티 파티션의 한 부분이기 때문에 비었다)이다. 첫 번째와 두 번째 inputPins는 액션과 관련된 오퍼레이션을 위해 두 가지 입력 매개변수가 있음을 나타낸다. 핀 이름은 데이터 객체를 나타내야 한다. 그 객체 이름은 UML Activity나 UML 컴포넌트에 존재해야 하는 UML 변수나 UML 속성이나 UML 매개변수의 이름일 수 있다. 이 모델에서 customerInfo와 purchaseOrder는 Activity의 매개변수다. UML-to-BPEL 변형은 Listing 2에서 볼 수 있는 것처럼 BPEL Invoke 액티비티와 두 개의 입력 매개변수를 생성한다.

Listing 2. initiatePriceCalculation 프로세스에서의 BPEL Invoke 액티비티

                
<bpws:invoke name="initiatePriceCalculation" operation="initiatePriceCalculation" 
partnerLink="invoicingInvoicingPartner" portType="ns3:Invoicing">
            <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
            </wpc:input>
</bpws:invoke>

initiatePriceCalculation 액션에서 나오는 컨트롤 흐름은 completePriceCalculation 액션(Call Operation 액션)과 Action의 UML 오퍼레이션 설정에 연결된다.

PurchaseOrderProcess::com::acme::credit::Invoicing::completePriceCalculation
        (shippingInfo : Manifest)

액션에는 두 가지 inputPins(가장 오른쪽의 inputPins는 targetInputPin이지만 액션이 Activity 파티션의 부분이므로 이름이 없다)가 있다. 단일 inputPin은 액션과 관련된 오퍼레이션에 한 개의 입력 매개변수가 있음을 의미한다. 핀 이름은 UML Activity나 UML 컴포넌트에 존재해야 하는 UML 변수나 UML 속성이나 UML 매개변수의 이름이 될 수 있는 데이터 객체를 나타내야 한다. 이 모델에서 shippingInfo는 컴포넌트의 UML 속성이다. 여기에 requestShipping 액션에서 들어오는 또 다른 컨트롤(requestShipping이라는 액션을 완성하기 전에 completePriceCalculation 액션이 호출되야 한다)이 있음을 알 수 있다.

UML-to-BPEL 변형은 BPEL Invoke 액티비티와 입력 매개변수, requestShipping 액션의 타깃 BPEL 링크, requestShipping 액션을 위한 Invoke 액티비티의 소스 BPEL 링크로 설정될 링크를 생성한다.

Listing 3. completePriceCalculation 프로세스에서의 BPEL Invoke 액티비티

                
<bpws:invoke name="completePriceCalculation" 
operation="completePriceCalculation" partnerLink="invoicingInvoicingPartner" 
portType="ns3:Invoicing">
            <wpc:input>
              <wpc:parameter name="shippingInfo" variable="shippingInfo"/>
            </wpc:input>
            <bpws:targets>
              <bpws:target linkName="processPurchaseOrderLink1"/>
            </bpws:targets>
</bpws:invoke>

completePriceCalculation 액션에서 나오는 컨트롤 흐름은 processInvoice 액션(Accept Call 액션)과 연결된다. 이 액션에서 나오는 트리거는 하나의 CallEvent와 이와 관련된 오퍼레이션을 설정한다.

PurchaseOrderProcess::org::ordermanagement::InvoiceProcessing::processInvoice
        (invoice : Invoice)

액션에는 두 가지 outputPins(가장 오른쪽의 outputPins는 액션의 returnInforation 속성을 나타낸다)가 있다. 단일 outputPin은 액션과 관련된 오퍼레이션에 하나의 입력 매개변수가 있음을 의미한다. 핀 이름은 UML Activity나 UML 컴포넌트에 존재해야 하는 UML 변수나 UML 속성이나 UML 매개변수의 이름이 될 수 있는 데이터 객체를 나타내야 한다. 이 예에서 Invoice는 액티비티에서의 매개변수다. UML-to-BPEL 변형은 BPEL Receive 액티비티와 하나의 출력 매개변수를 생성한다.

forkNode에서의 두 가지 다른 컨트롤 흐름 시퀀스도 비슷하게 처리된다. 마지막에 BPEL Reply 액티비티가 생성되는데 Activity::specification 오퍼레이션이 반환 매개변수를 가지기 때문이다(이 예에서 Activity 스펙 연산은 PurchaseOrderProcess::org::ordermanagement::Purchasing::processPurchaseOrder다). 이는 Listing 4에서 볼 수 있다.

Listing 4. processPurchaseOrder 프로세스에서의 BPEL Reply 액티비티

                
<bpws:reply name="processPurchaseOrder" operation=
"processPurchaseOrder" partnerLink="purchasingPurchasing" portType=
"ns2:Purchasing">
      <wpc:input>
        <wpc:parameter name="result" 
variable="processpurchaseorder_result"/>
      </wpc:input>
</bpws:reply>

Listing 5는 orderProcessor 컴포넌트를 위한 UML-to-BPEL 변형에 의해 생성되는 완전한 BPEL을 보여준다.

Listing 5. 생성된 BPEL 프로세스의 완전한 목록

                
<?xml version="1.0" encoding="UTF-8"?>
<bpws:process xmlns:bpws="
http://schemas.xmlsoap.org/ws/2004/03/business-process/" 
xmlns:ns="http://org/ordermanagement/OrderProcessorArtifacts/" 
xmlns:ns0="http://org/crm/" 
xmlns:ns1="http://org/crm/domain/" 
xmlns:ns2="http://org/ordermanagement/Purchasing/" 
xmlns:ns3="http://com/acme/credit/Invoicing/" 
xmlns:ns4="http://org/ordermanagement/InvoiceProcessing/" 
xmlns:ns5="http://com/acme/shipping/Shipping/" 
xmlns:ns6="http://org/ordermanagement/ScheduleProcessing/" 
xmlns:ns7="http://com/acme/productions/Scheduling/" 
xmlns:wpc="http://www.ibm.com/xmlns/prod/websphere/business-process/6.0.0/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" expressionLanguage="
http://www.ibm.com/xmlns/prod/websphere/business-process/expression-lang/java/6.0.0/" 
name="OrderProcessor" suppressJoinFailure="yes" targetNamespace="
http://org/ordermanagement/OrderProcessor/">  <bpws:import importType="
http://schemas.xmlsoap.org/wsdl/" 
location="OrderProcessorArtifacts.wsdl" namespace="
http://org/ordermanagement/OrderProcessorArtifacts/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/PurchaseOrder.xsd" 
namespace="http://org/crm/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/Invoice.xsd" 
namespace="http://org/crm/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/Manifest.xsd" 
namespace="http://org/crm/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" location="
../../../PurchaseOrderProcess/org/crm/domain/Customer.xsd" 
namespace="http://org/crm/domain/"/>
  <bpws:import importType="
http://www.w3.org/2001/XMLSchema" 
location="../../../PurchaseOrderProcess/org/crm/Schedule.xsd" 
namespace="http://org/crm/"/>  <bpws:partnerLinks>
    <bpws:partnerLink myRole="PurchasingRole" 
name="purchasingPurchasing" 
partnerLinkType="ns:PurchasingPLT"/>
    <bpws:partnerLink name="
invoicingInvoicingPartner" 
partnerLinkType="ns:InvoicingPLT" 
partnerRole="InvoicingRole"/>
    <bpws:partnerLink myRole="InvoiceProcessingRole" 
name="invoicingInvoiceProcessing" 
partnerLinkType="ns:InvoiceProcessingPLT"/>
    <bpws:partnerLink name="schedulingSchedulingPartner" 
partnerLinkType="ns:SchedulingPLT" 
partnerRole="SchedulingRole"/>
    <bpws:partnerLink name="shippingShippingPartner" 
partnerLinkType="ns:ShippingPLT" 
partnerRole="ShippingRole"/>
    <bpws:partnerLink myRole="ScheduleProcessingRole" 
name="shippingScheduleProcessing" 
partnerLinkType="ns:ScheduleProcessingPLT"/>
  </bpws:partnerLinks>  <bpws:variables>
    <bpws:variable name="id" 
type="xsd:string"/>
    <bpws:variable name="shippingInfo" 
type="ns0:Manifest"/>
    <bpws:variable name="schedule" 
type="ns0:Schedule"/>
    <bpws:variable name="
processpurchaseorder_customerInfo" 
type="ns1:Customer"/>
    <bpws:variable name="
processpurchaseorder_purchaseOrder" 
type="ns0:PurchaseOrder"/>
    <bpws:variable name="
processpurchaseorder_result" 
type="ns0:Invoice"/>  </bpws:variables>
  <bpws:sequence name="Sequence">
    <bpws:receive createInstance="yes" 
name="processPurchaseOrder" 
operation="processPurchaseOrder" 
partnerLink="purchasingPurchasing" 
portType="ns2:Purchasing"> <wpc:output>
        <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
        <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
      </wpc:output> </bpws:receive>
    <bpws:scope name="
processPurchaseOrder">
      <bpws:flow name="
processPurchaseOrderFlow"> <bpws:links>
          <bpws:link name="
processPurchaseOrderLink1"/> <bpws:link name="
processPurchaseOrderLink2"/> </bpws:links>
        <bpws:sequence name="Sequence3">
          <bpws:invoke name="
initiatePriceCalculation" operation="
initiatePriceCalculation" partnerLink="
invoicingInvoicingPartner" 
portType="ns3:Invoicing"> <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
            </wpc:input> </bpws:invoke>
          <bpws:invoke name="completePriceCalculation" 
operation="completePriceCalculation" 
partnerLink="invoicingInvoicingPartner" 
portType="ns3:Invoicing"> <wpc:input>
              <wpc:parameter name="shippingInfo" 
variable="shippingInfo"/>
            </wpc:input> <bpws:targets>
              <bpws:target linkName="
processPurchaseOrderLink1"/>
            </bpws:targets> </bpws:invoke>
          <bpws:receive name="processInvoice" 
operation="processInvoice" 
partnerLink="invoicingInvoiceProcessing" 
portType="ns4:InvoiceProcessing"> 
<wpc:output> 
         <wpc:parameter name="invoice" 
variable="processpurchaseorder_result"/>
            </wpc:output> </bpws:receive>
        </bpws:sequence> <bpws:sequence name="Sequence4">
          <bpws:assign name="Assign1">
            <bpws:copy> <bpws:from 
variable="processpurchaseorder_purchaseOrder">
                <bpws:query queryLanguage="
http://www.w3.org/TR/1999/REC-xpath-19991116"><!
[CDATA[/oid]]></bpws:query>
              </bpws:from> <bpws:to variable="
processpurchaseorder_customerInfo">
                <bpws:query queryLanguage="
http://www.w3.org/TR/1999/REC-xpath-19991116"><!
[CDATA[/firstname]]></bpws:query>
              </bpws:to></bpws:copy>
          </bpws:assign><bpws:invoke name="requestShipping" 
operation="requestShipping" 
partnerLink="shippingShippingPartner" 
portType="ns5:Shipping">
            <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="shippingInfo" 
variable="shippingInfo"/>
            </wpc:input><bpws:sources>
              <bpws:source linkName="processPurchaseOrderLink1"/>
            </bpws:sources> </bpws:invoke>
          <bpws:receive name="processSchedule" 
operation="processSchedule" 
partnerLink="shippingScheduleProcessing" 
portType="ns6:ScheduleProcessing">
            <wpc:output>
              <wpc:parameter name="schedule" 
variable="schedule"/>
            </wpc:output> <bpws:sources>
              <bpws:source linkName="
processPurchaseOrderLink2"/>
            </bpws:sources> </bpws:receive>
        </bpws:sequence> <bpws:sequence name="Sequence5">
          <bpws:invoke name="
requestProductionScheduling" operation="
requestProductionScheduling" partnerLink="
schedulingSchedulingPartner" 
portType="ns7:Scheduling"> <wpc:input>
              <wpc:parameter name="customerInfo" 
variable="processpurchaseorder_customerInfo"/>
              <wpc:parameter name="purchaseOrder" 
variable="processpurchaseorder_purchaseOrder"/>
            </wpc:input> </bpws:invoke>
          <bpws:invoke name="sendShippingSchedule" 
operation="sendShippingSchedule" 
partnerLink="schedulingSchedulingPartner" 
portType="ns7:Scheduling"> <wpc:input>
              <wpc:parameter name="schedule" 
variable="schedule"/>
            </wpc:input> <bpws:targets>
              <bpws:target linkName="
processPurchaseOrderLink2"/>
            </bpws:targets>
          </bpws:invoke>
        </bpws:sequence>
      </bpws:flow>
    </bpws:scope>
    <bpws:reply name="processPurchaseOrder" 
operation="processPurchaseOrder" 
partnerLink="purchasingPurchasing" 
portType="ns2:Purchasing">
      <wpc:input>
        <wpc:parameter name="result" 
variable="processpurchaseorder_result"/>
      </wpc:input>
    </bpws:reply>
  </bpws:sequence>
</bpws:process>

위로

UML-to-BPEL 변형에 의한 UML 요소 해석

UML-to-BPEL 변형은 UML 모델의 특정 정보를 사용해 BPEL 산출물을 생성한다. 부정확하거나 불완전한 모델은 오류나 부정확한 BPEL 산출물을, 또는 둘 모두를 생성할 수 있다. 물론 이런 오류를 피하고 싶을 것이다. 다음 표는 다양한 변형에서 추론할 예상된 결과를 이해하는 데 도움이 될 것이다.

UML 요소의 변형

표 1은 변형을 지원하는 UML 요소와 이와 일치하는 BPEL 구성이나 변형이 만드는 액티비티를 나열한다.

표 1. UML 요소와 BPEL 결과

UML 요소	변형 결과
Component	변형은 BPEL 프로세스와 컴포넌트가 하나 이상의 액티비티를 가지면 컴포넌트와 같은 이름을 만든다. 컴포넌트는 일치하는 BPEL 프로세스에서 소유한 모든 동작과 변수를 위한 컨텍스트를 제공한다. 컨포넌트가 빈(empty) 액티비티를 가지면 변형은 제공된 인터페이스에서 각 연산에 대해 빈 BPEL Scope 액티비티를 만든다. BPEL 프로세스의 이름공간과 관련 WSDL 산출물 파일은 컴포넌트의 요소와 그 안의 패키지를 포함한다.
Component::ownedAttribute	소유한 속성의 Type 속성에서 지정되는 유형이 포트를 가지지 않는 컴포넌트라면 변형은 일치하는 BPEL 프로세스에서 BPEL 변수를 만든다.
AcceptCallAction	BPEL Receive 액티비티가 생성된다. 변형은 액션과 관련된 트리거 목록을 검사해 어떤 연산이 CallEvent 유형과 관련이 있는지와 어떤 연산이 BPEL 연산과 매핑되는지 결정한다. 핀 이름이 비지 않고 포트 이름과 매치돼야 한다면 변형은 액션의 ReturnInformation 속성과 관련된 출력핀 이름을 사용해 파트너를 생성한다. 그렇지 않다면 변형은 ActivityPartition::represents 속성 값이 포트이거나 포트 유형인 곳에서 ActivityPartition::represents 속성을 사용한다. 오퍼레이션 컨테이너는 호출을 받는 동안 포트 중 하나의 인터페이스를 제공해야 한다. 액션의 출력핀 숫자는 연산 매개변수 수와 같아야 한다. 액션은 또한 액션의 Return Information 속성을 나타내는 추가 출력핀을 가진다.
들어오는 엣지 없는 AcceptEventAction 하나 이상의 들어오는 엣지가 있는 AcceptEventAction 이벤트가 SignalEvent인 트리거와 AcceptEventAction	BPEL 흐름은 AcceptEventAction::triggers에 하나 이상의 SignalEvents가 있을 때 생성된다. BPEL은 다중으로 들어오는 ControlFlows와 객체 흐름을 액션의 같은 InputPin으로 지원하지 않는다. BPEL Receive 액티비티가 생성된다. 연산은 시그널을 받을 수 있음을 알리는 리셉션에서 추론된다. 주의: AcceptEventAction은 이벤트를 받는 내내 포트나 포트 유형을 나타내는 ActivityPartition이어야 한다. 포트에 제공되는 인터페이스는 각 시그널에 리셉션을 가져야 한다. AcceptEventAction은 AcceptEventAction::triggers의 SignalEvents와 관련된 각 시그널에 OutputPin을 가져야 한다. 핀 유형과 시그널 유형은 맞아야 한다.
AcceptEventAction과 이벤트가 TimeEvent여야 하는 트리거 Time 표현(expression)은 TimeEvent::when 속성과 관련된다.	BPEL 대기(wait) 액티비티가 생성된다. BPEL 대기 액티비티의 For 속성이나 Until 속성은 time 표현에 기반을 두고 설정된다. Until 속성을 위해 값을 지정하려면 표현은 년, 달, 날, 시간, 분, 초 같은 포맷이어야 한다 For 속성을 위해 값을 지정하려면 표현은 년, 달, 날, 시간, 분, 초의 수 같은 포맷이어야 한다. 주의: 다중 time 이벤트를 지정할 수 없다.
컴포넌트 소유의 동작이자 컴포넌트가 제공하는 오퍼레이션의 메서드인 Activity	변형은 컴포넌트를 위해 BPEL 프로세스의 톱 레벨 흐름에서 BPEL Scope 액티비티를 만든다.
Activity::Specification	컴포넌트가 하나의 액티비티만을 가진다면 변형은 스펙과 관련된 오퍼레이션의 톱 레벨 BPEL Receive 액티비티를 만든다. 컴포넌트가 다중 액티비티를 갖는다면 변형은 BPEL Pick 액티비티와 각 Activity::Specification과 관련된 각 연산에 대해 onMessage 이벤트 유형을 만든다. 스펙 연산이 Out이나 Return 매개변수를 갖는다면 변형은 BPEL Reply 액티비티를 만든다.
Activity::ownedParameter:Parameter	변형은 컴포넌트와 일치하는 BPEL 프로세스에서 BPEL 프로세스 변수를 만든다. 변수 이름은 액티비티 이름에 맞춰 컴포넌트의 다른 액티비티 매개변수에 충돌이 없음을 확인해야 한다. Activity 스펙과 관련된 매개변수 이름과 연산 유형은 이름과 유형이 맞는 액티비티 매개변수를 가져야 한다.
Activity::ownedAttribute:Property	변형은 프로세스의 액티비티에 대해 톱 레벨 Scope 요소에서 BPEL 변수를 만든다.
Activity::variable:Variable	변형은 프로세스의 액티비티에 대해 톱 레벨 스코프(scope)의 BPEL 변수를 만든다.
ActivityFinalNode	변형은 BPEL Terminate 액티비티를 만든다.
ActivityPartition::represents	Represents 속성 값은 포트나 포트 유형이어야 한다. 변형은 포트에서 각각의 제공된 또는 필수 인터페이스를 위한 BPEL 파트너 링크를 생성한다. 이를 통해 변형은 파티션 액션과 관련된 오퍼레이션을 위한 올바른 BPEL 파트너를 인식할 수 있다.
CallOperationAction	BPEL Invoke 액티비티가 생성된다. 핀 이름이 비지 않고 포트 이름과 매치돼야 할 때 변형은 타깃 입력핀 이름을 사용해 파트너를 생성한다. 그렇지 않다면 변형은 ActivityPartition::represents 속성을 사용하고 ActivityPartition::represents 속성 값은 포트나 포트 유형 중 하나가 돼야 한다. 연산 컨테이너는 연산을 호출하는 과정을 통해 포트 중 하나에서 필수 인터페이스여야 한다. 액션의 입력핀 수는 연산의 매개변수 수와 같아야 한다. 액션은 또한 액션의 타깃 입력핀을 나타내는 추가 입력핀을 가져야 한다. 액션에서 출력핀 수는 연산의 매개변수 수와 같아야 한다.
InitialNode	변환은 이 요소를 사용해 BPEL 액티비티의 시작을 나타낸다. 이 노드의 다른 BPEL 산출물은 만들지 않는다.
OpaqueAction	변형은 lvalue가 BPEL을 변형으로 설정하고 rvalue를 변형에서의 BPEL로 설정한 곳에서 연산 수가 lvalue:= rvalue 같은 식을 사용할 때 BPEL assign 액티비티를 만든다. 다중 부여에 있어 (;)을 분리기로 사용할 수 있다: aVar:=bVar ; cVar:=dVar. 변형은 액션의 언어 속성이 Java™로 설정되고 body 속성의 값이 스니펫에 지정된 액션과 관련이 있을 때 BPEL Java 스니펫을 만든다. 변형은 액션의 언어 속성이 HTML이나 JSP로 설정될 때 빈 BPEL 인간 태스크를 만든다.
SendSignalAction	BPEL Invoke 액티비티가 생성된다. BPEL invoke의 오퍼레이션은 SendSignalAction::signal 속성의 수신과 같다. 핀 이름이 있을 때 타깃 입력핀 이름을 사용해 파트너가 생성된다. 그렇지 않다면 변형은 ActivityPartition::represents 속성을 사용한다. 연산 컨테이너는 이벤트를 보내는 포트 중 하나에서 필수 인터페이스여야 한다. 타깃 핀 이름은 핀 이름이 있을 때 포트 이름과 같아야 한다. 또는 ActivityPartition::represents 속성 값이 포트나 포트 유형이어야 한다.

UML Activity 엣지의 변형

표 2는 변형이 지원하는 Activity 엣지 유형과 그에 따라 생성되는 BPEL 시퀀스와 링크를 나열한다.

표 2. UML Activity 엣지 유형과 그에 따르는 BPEL 시퀀스와 링크

UML 액티비티 엣지	변형 출력
ControlFlow	변형은 공동 컨트롤을 위해 BPEL 시퀀스와 링크를 만든다.
ObjectFlow	변형은 공동 컨트롤을 위해 BPEL 시퀀스와 링크를 만든다. 필요하다면 변형은 객체 흐름 이름에 기반을 두고 변수를 생성한다. 생성된 이름은 객체 흐름 이름이 비었을 때 적용된다.

컨트롤 또는 결정 노드의 변형

표 3은 변형이 지원하는 컨트롤 및 결정 노드와 변형이 만드는 그에 따르는 BPEL 출력을 나열한다.

표 3. UML 컨트롤 및 결정 노드와 BPEL 출력

컨트롤 및 결정 노드	변형 출력
DecisionNode	변형은 이 노드에서 나오는 각 흐름에 대해 BPEL Switch 액티비티와 BPEL Case 브랜치를 만든다. BPEL 시퀀스는 각 BPEL Case 브랜치에서 만들어져 나가는 각 흐름의 타깃에서 생성된 BPEL 액티비티를 적응시킨다. 각각에서 나오는 흐름의 각 가드는 BPEL Case 브랜치에 대해 BPEL 컨디션을 설정한다. 변형은 가드 값이 Else와 같고 language 속성이 비었을 때 나오는 흐름에 대해 BPEL Otherwise 브랜치를 만든다.
ForkNode	변형은 BPEL 흐름 액티비티의 시작인 <flow name="ForkNode.name">을 지정하는 코드를 생성한다. <flow> 액티비티에서 변형은 fork 노드를 떠나는 각 흐름에 대해 중첩된 BPEL Sequence 액티비티를 만든다.
JoinNode	변형은 BPEL 흐름 액티비티의 끝인 </flow>를 지정하는 코드를 생성한다.
MergeNode	변형은 각각의 들어오는 흐름의 소스 노드 사이의 BPEL 링크를 병합 노드와 여기서 나오는 흐름의 타깃 노드로 만든다.

객체 노드의 변형

표 4는 변형이 지원하는 객체 노드와 변형이 생성하는 그에 따르는 BPEL 액티비티를 나열한다.

표 4. UML 객체 노드와 그에 따르는 BPEL 액티비티

컨트롤 또는 객체 노드	변형 출력
ActivityParameterNode	변형은 그에 따르는 BPEL 산출물을 만들지 않는다. 변형은 ActivityParameterNode 객체 노드를 조사해 객체 흐름이 ActivityParameterNode 객체 노드와 연결될 때만 시퀀스 순서를 결정한다. ActivityParameterNode 객체 노드는 이와 일치하는 액티비티 매개변수를 가져야 한다.
LoopNode	변형은 UML 컴포넌트가 소유한 동작인 UML 액티비티에서 각 LoopNode의 BPEL While 액티비티를 만든다.
LoopNode::decider	변형은 출력핀과 관련된 BPEL 변수를 사용해 BPEL while 액티비티의 BPEL 컨디션을 만든다. 관련된 출력핀은 UMLPrimitiveTypes::Boolean 유형이어야 한다.
LoopNode 내의 UML 요소	BPEL while 액티비티에서 변형은 UML-to-BPEL 변형이 지원하는 UML 요소에 대해 적절한 BPEL 액티비티를 만든다.
InputPin	변형은 입력핀의 소유자가 AcceptCallAction, CallOperationAction, 또는 OpaqueAction 액션의 인스턴스일 때 InputPin 요소를 검사한다. 입력핀 수는 입력핀을 소유한 액션과 관련된 연산의 매개변수와 같아야 한다. 추가 입력핀은 액션이 CallOperationAction의 인스턴스일 때만 <<target>> 입력핀을 나타내야 한다. 입력핀이 객체 흐름 엣지에 의해 액티비티에 연결되지 않는다면 핀의 이름은 액티비티를 소유하는 액티비티나 컴포넌트에서 액티비티의 매개변수, 변수, 또는 속성과 같아야 한다.
OutputPin	변형은 출력핀의 소유자가 AcceptCallAction, CallOperationAction, 또는 OpaqueAction action의 인스턴스일 때 OutputPin 요소를 검사한다. 액션이 CallOperationAction이나 CallOperationAction의 인스턴스일 때 핀 수는 출력핀을 소유한 액션과 관련된 연산의 매개변수와 같아야 한다. 액션이 AcceptCallAction의 인스턴스일 때 추가 출력핀은 핀을 소유한 액션의 Return Information 속성을 나타내야 한다. 출력핀이 객체 흐름 엣지에 의해 액티비티에 연결되지 않으면 핀은 액티비티를 소유한 액티비티나 컴포넌트에서 액티비티 매개변수, 변수, 또는 속성과 일치하는 유효한 이름을 가져야 한다. 출력핀이 들어오거나 나가는 객체 흐름 엣지를 가지고 있지 않다면 변형은 일치하는 BPEL 변수를 사용해 핀을 소유한 액션에 관련된 일치하는 연산의 BPEL 출력 매개변수를 만든다.

Loop 노드의 변형

표 5. UML loop 노드 요소와 생성된 BPEL 액티비티

Loop 노드 또는 loop 노드 요소	변형 결과
LoopNode	변형은 UML 컴포넌트가 소유한 동작인 UML 액티비티에서 각 LoopNode의 BPEL while 액티비티를 만든다.
LoopNode::decider	변형은 출력핀과 관련된 BPEL 변수를 사용해 BPEL While 액티비티의 BPEL 컨디션을 만든다. 관련 출력핀은 UMLPrimitiveTypes::Boolean 유형이어야 한다.
LoopNode 내의 UML 요소	BPEL While 액티비티에서 변형은 UML-to-BPEL 변형이 지원하는 UML 요소에 적절한 BPEL 액티비티를 만든다.

더 배울 점

지금까지 UML-to-BPEL 변형의 기초와 UML에서 BPEL Process 구현을 어떻게 설계하는지에 대해 자세한 내용을 배웠다. 이제 참고자료의 자료들을 읽고 유스케이스 시나리오를 찾아보자.

참고자료

교육

SOA로 변형하기: Part 1. IBM WebSphere Business Modeler와 IBM Rational Software Architect를 사용하여 비즈니스 프로세스를 서비스 모델 아키텍처로를 읽자.
SOA로 변형하기: Part 2. IBM Rational Software Architect에 Business Process-to-Service Model 변형 기능을 위한 커스텀 확장 생성하기
SOA로 변형하기: Part 3. UML에서 SOA로
추가적인 유용한 정보를 위해 SOA(서비스 지향 아키텍처)를 기반으로 소프트웨어 개발하기에 관한 Jim Amsden의 다섯 편의 연재를 읽자.
- Modeling SOA: Part 1. Service identification은 IBM Software Profile로 확장된 UML 모델을 사용해 비즈니스 요구사항에 연결되지만 솔루션 구현에 독립된 SOA 솔루션을 디자인하는 방법을 설명한다. 필자는 비즈니스 목표와 그 목표를 맞추기 위해 구현된 비즈니스 프로세스를 설명하고 프로세스를 사용해 요구사항을 수행하는 데 필요한 비즈니스 관련 서비스를 구분하는 방법을 설명한다.
- Modeling SOA: Part 2. Service specification: 각 서비스 스펙을 자세히 모델링함으로써 SOA 솔루션을 정의한다. 이 스펙들은 서비스 소비자와 공급자 간의 계약을 정의한다. 이 계약들에는 제공된 필수 인터페이스, 서비스 스펙에서 인터페이스의 역할, 이 역할들이 상호 작용하는 규칙과 프로토콜을 포함한다.
- Modeling SOA: Part 3. Service realization: 여기서는 SOA 기반 웹 서비스가 실제 구현되는 방법을 설명한다. 서비스 구현은 어떤 컴포넌트가 어떤 서비스를 제공할지 결정하는 것으로 시작한다. 이 결정은 서비스 가용성, 배포, 보안, 트랜잭션 범위, 커플링 등이 포함된다. 결정 후 각 서비스의 기능이 구현되는 방법과 요청된 서비스가 실제 어떻게 사용되는지 모델링할 수 있을 것이다. 그리고 나면 IBM Rational Software Architect에 포함된 UML에서 SOA 변환 기능을 사용해 IBM WebSphere Integration Developer에 쓸 수 있는 웹 서비스 구현을 생성해 완벽한 솔루션을 구현, 테스트, 전개한다.
- Modeling SOA: Part 4. Service composition: "Part 3. Service realization"에서 모델링한 서비스 공급자를 조합, 연결하고 인터랙션을 구성해 비즈니스 요구사항에 완벽한 솔루션을 제공하는 방법을 다룬다. 결과 컴포넌트는 구매 주문을 처리하는 서비스를 제공하는 Invoicer, Productions, Shipper 컴포넌트에 의해 제공되는 서비스를 합성하는 서비스 참여자가 될 것이다. 또한 서비스 참여자들이 원래 비즈니스 요구사항을 어떻게 수행하는지도 설명한다.
- Modeling SOA: Part 5. Service implementation: 이 마지막 글에서 필자는 서비스 모델의 디자인 결정과 아키텍처로 구성된 실제 구현을 만드는 방법을 설명한다. 모델 위주의 개발과 IBM Rational Software Architect UML-to-SOA 변형 기능을 통해 SOA 모델에서 웹 서비스를 만든다.
Business Process Execution Language for Web Services version 1.1(IBM® developerWorks®, 2007년 12월)을 읽자.
UML에서 BPEL까지(IBM® developerWorks®, 2003년 9월)를 읽자.
한국 developerWorks의 Rational 영역을 방문하여 Rational 소프트웨어 딜리버리 플랫폼 제품에 관련된 기술 자료와 실용적 업무 처리 자료를 얻자.
Rational 컴퓨터 기반, 웹 기반, 강사 주도 온라인 교육을 찾아보자. 초급에서 고급에 이르는 교육 과정을 통해 기술을 익히고 Rational 도구에 대해 더 알아보자. 카탈로그에서 제공하는 이 과정 중 컴퓨터 기반 교육이나 웹 기반 교육을 구매할 수 있다. 또한 "시작하기" 과정은 무료로 들을 수 있다.
developerWorks의 SOA와 웹 서비스 영역을 찾아 서비스 지향 아키텍처에 관한 기술을 향상시키는 데 도움이 되는 자료를 얻자.
IBM.com에서 IBM SOA 솔루션 사이트를 방문하자.
효과적인 소프트웨어 개발의 기본 개념에 관련된 글을 위해 Rational 엣지 뉴스레터에 등록하자.
IBM developerWorks 뉴스레터에 등록해 매주 최고의 developerWorks 튜토리얼, 글, 다운로드, 커뮤니티 활동, 웹 캐스트, 행사에 대해 업데이트받자.
기술 주제에 관련된 책을 찾기 위해 온라인 서점을 방문하자.

제품 및 기술 얻기

IBM Rational Software Architect V 7 시험판을 다운로드하자.
IBM Rational 소프트웨어의 시험판을 다운로드하자.
IBM 제품 평가판을 다운로드해 애플리케이션 개발 도구와 DB2®, Lotus®, Rational®, Tivoli®, WebSphere®의 미들웨어 제품에 익숙해지자.

토론

developerWorks 블로그를 확인하고 developerWorks 커뮤니티에 참여하자.

필자소개


		Murali Pattathe는 캐나다 온타리오 주의 IBM 오타와 랩에서 IBM Rational 고문 소프트웨어 개발자로 근무하고 있다. 지난 15년 동안 소프트웨어 개발 업계에서 애플리케이션 및 도구 디자인과 개발 경험이 있으며 많은 다른 변형과 변형 프레임워크 개발에 참여했다

이 문서 북마킹 하기

IBM 소개