 | |
|
난이도 : 고급 Natalia Balaba-Liaskovski, Software Engineer,
IBM
2008 년 2 월 26 일 전형적인 개발 사이클에는 Business Analysis 모델을 생성하여 비즈니스 목표를 분석 및 포착한 다음, 이것을 소프트웨어 아키텍처용 모델로 변형하는 것이 포함되어 있습니다. IBM® Rational® Software Architect의 Business Process-Service Model SOA 변형 기능으로 모델을 생성할 수 있습니다. Part 2에서는(Part 1은 참고자료 참조) 비즈니스 프로세스를 서비스 모델로 변형하기 위해 커스텀 프로세스를 분해하는(decomposition) 방법을 설명합니다.
비즈니스 프로세스(Business Process)-서비스 모델(Service Model) 변형 기능 개요
IBM Rational Software Architect의 비즈니스 프로세스-서비스 모델 변형 기능은 주 변형과 세 개의 기본 확장으로 구성되어 있다.
주 변형은 서비스 공급자를 기술하는 Unified Modeling Language (UML) Component를 생성한다. 이 변형은 또한 컴포넌트를 포트로 채우는데, 각각 서비스에 의해 제공되거나 요청된 인터페이스를 나타낸다. 마지막으로 CollaborationUse 엘리먼트는 아키텍처 모델에 있는 서비스의 컴포넌트 표현을 Business Analysis Model의 Collaboration으로 연결시키기 위해 생성된다. 컴포넌트에 있는 각각의 포트에는 적절한 역할이 주어진다. CollaborationUse 엘리먼트는 포트와 역할 바인딩과 함께 콘트랙트 확인 조각을 나타낸다. 콘트랙트 확인은 Business Analysis로의 트레이스백을 허용하여, 컴포넌트가 비즈니스 분석 모델에 지정된 대로 프로세스를 실현하는지를 확인한다.
그림 1. 포트, 콘트랙트 확인 조각, CollaborationUse 엘리먼트, 역할 바인딩을 포함하고 있는 변형 툴의 주 아웃풋
주 변형으로는 생성된 컴포넌트를 내부에서 분해하지 않는다. 구현과 전개 영역의 결정과 제약에 따라 달라지기 때문이다.
내부 분해를 수행하는 태스크는 주 변형에 대한 확장에 주어진다. 각 확장은 비즈니스 프로세스를 분해하고, 이것의 내부 작동을 기술한다. 이와 같은 확장이 변형에도 제공되지만, 특수한 필요에 적합한 커스텀 확장을 생성 및 등록함으로써 다른 서비스 분해를 수행할 수 있다.
커스텀 확장 시나리오
이 예제에서는 새로운 서비스에 대한 Business Analysis 모델을 만들고, 레거시 서비스와 솔루션의 통합을 모델링 하는 것으로 간주한다. 이 모델은 Medical Marketplace를 생성하기 위해 실행되는 서비스의 클러스터를 나타낸다. Medical Marketplace는 다양한 의료 서비스를 제공하며, 모두 한 지붕 아래에 있다. 각각의 클라이언트 요청이 처리되고, 적절한 서비스가 선택 및 클라이언트에게 제공된다. 서비스가 수행되면, 지불이 수행되고 고객 피드백이 마켓플레이스 데이터베이스로 제출된다. (그림 2)
그림 2. Medical Marketplace 비즈니스 프로세스를 갖춘 Business Analysis Model
의료 서비스가 제공된 후에 청구 및 금액을 수령하는 Payment Collector 서비스에 집중해 보자. 트랜잭션에 대한 기록을 관리하기 위해 이종의 부기가 필요하다. 이러한 프로세스에 Logger 서비스를 사용한다. 이 서비스는 기존의 자바™ 코드를 활용하려는 의도이다.
자바 라이브러리로서 구현된 레거시 Billing 및 Logging 서비스들이 있다고 해보자. Billing 서비스는 Billing 이라고 하는 자바 인터페이스를 의미한다. com.acme.billing.MedicalBilling 자바 클래스에 의한 구체적인 Billing 구현이 있다. MedicalBilling은 또 다른 레거시 라이브러리 com.acme.logging (그림 3)에 의해 정의된 Logging 서비스를 사용한다.
그림 3. Billing과 Logging 서비스의 자바 구현을 포함하고 있는 자바 레거시 라이브러리
전체 SOA 솔루션은 Services Component Definition Language (SCDL)로 전개된다. 커스텀 확장의 목적은 자바 기반 레거시 라이브러리로 연결될 준비가 된 SCDL 모델을 만들기 위함이다.
비즈니스 프로세스를 서비스 모델로 확장하는데 필요한 단계
- Eclipse 플러그인 프로젝트를 만든다.
- 변형 클래스를 생성한다. (Listing 1)
Listing 1. 변형 클래스 생성 코드
package com.ibm.xtools.transform.cfm.example.transform;
import com.ibm.xtools.transform.cfm.example.rules.MyPopulateComponentRule;
import com.ibm.xtools.transform.core.Transform;
public class MyTransform
extends Transform {
//id of the transformation
public static final String TRANSFORM_ID =
"com.ibm.xtools.transform.cfm.example.transform.MyTransformId";
public MyTransform() {
super(TRANSFORM_ID); // instantiate transformation using id
add(new MyPopulateComponentRule());//program transformation with this rule
}
}
|
주:
확장 ID를 생성할 때, 고유한 것에 순응하도록 한다. 변형 설정이 하나의 프로세스가 확장 ID를 사용하여 변형되어야 한다는 것을 명시하면, 그 ID를 가진 확장이 선택되고 사용되어 이 프로세스를 변형한다.
- 이 기능을
MyPopulateComponentRule 코드에 구현한다. Listing 2의 코드는 이러한 규칙의 중심 기능을 강조한 것이다.
Listing 2.
MyPopulateComponentRule 코드
public class MyPopulateComponentRule extends ModelRule {
/*
* canAccept method asserts wither or not the extension is applicable
*/
public boolean canAccept(ITransformContext context) {
// the rule will be invoked if the current node on the source side is
// an instance of UML Collaboration and the node on the target side
// is instance of UML Component
return context.getSource() instanceof Collaboration
&& context.getTarget() instanceof Component;
}
/*
* createTarget method will perform additional (to main) transformation of the
Collaboration(service) in the source
* model to the elements in the target model
*/
protected Object createTarget(ITransformContext context) throws Exception {
Component collaborationComponent = (Component) context.getTarget();
Component java_adapter = createJavaConverter(collaborationComponent);
assert (java_adapter != null);
Property attribute = collaborationComponent.createOwnedAttribute(
"java_adapter", java_adapter);
for (Iterator e = collaborationComponent.getOwnedPorts().iterator(); e.hasNext();) {
Port port = (Port) e.next();
// there will only one port that provides interface to the outside.
if (!port.getProvideds().isEmpty()) {
Port in_port = java_adapter.createOwnedPort("in_" + port.getName(), null);
Interface anInterface = (Interface) port.getProvideds().get(0);
addProvidedInterface(anInterface, in_port);
createConnector(collaborationComponent, port, in_port, null, attribute,
ConnectorKind.DELEGATION_LITERAL);
} else if (!port.getRequireds().isEmpty()) {
Interface anInterface = (Interface) port.getRequireds().get(0);
Type type = createUsage(java_adapter, anInterface);
Port out_port = java_adapter.createOwnedPort("out_" + port.getName(), type);
createConnector(collaborationComponent, out_port, port, attribute, null,
ConnectorKind.DELEGATION_LITERAL);
}
}
return collaborationComponent;
}
/*
* auxiliary method – creates java adapter component for the role,
which represents Collaboration (service) itself
*/
private Component createJavaAdapter(Component collaborationComponent) {
for (Iterator e = collaborationComponent.getOwnedPorts().iterator(); ehasNext();) {
Port port = (Port) e.next();
if (!port.getProvideds().isEmpty()) {
return (Component) collaborationComponent..createPackagedElement(port.getName() +
"Adapter",UMLPackage.Literals.COMPONENT);
}
}
return null;
}
…
}
Create the extension condition class:
/**
* com.ibm.xtools.transform.cfm.example.condition.MyExtensionCondition
*/
public class MyExtensionCondition
extends TransformCondition {
public MyExtensionCondition() {
super();
}
protected boolean isContextSatisfied(ITransformContext context) {
return (context.getSource() instanceof Collaboration)
&& CommonConfigUtil.getExtensionIdFor(
(Collaboration) context.getSource(), context).equals(
MyTransform.TRANSFORM_ID);
}
}
|
런타임 시 조건이 사용되어 비즈니스 프로세스가 커스텀 변형을 사용하여 변형되도록 설정되었는지 여부를 선언한다.
- XML 플러그인 파일에 확장을 등록한다. Listing 3은 커스텀 확장을 선언하는 예제이다.
Listing 3.
커스텀 확장을 선언하는 XML 플러그인 파일용 코드 예제
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.2"?>
<plugin>
<extension
point="com.ibm.xtools.transform.core.transformationExtensions">
<TransformationExtension
author="you"
description="my custom extension"
document="optional"
enabled="true"
id="com.ibm.xtools.transform.cfm.example.transform.MyTransformId"
name="My custom extension"
targetTransformation="com.ibm.xtools.transform.cfm.wbm.transforms.MainTransform"
version="1.0.0">
<TransformDefinition
acceptCondition="com.ibm.xtools.transform.cfm.example.condition.MyExtensionCondition"
class="com.ibm.xtools.transform.cfm.example.transform.MyTransform"
id="com.ibm.xtools.transform.cfm.example.transform.MyTransformId"/>
<ExtendTransform
targetTransform="com.ibm.xtools.transform.cfm.wbm.transforms.OwnedBehaviorTransform">
<AddTransform id="com.ibm.xtools.transform.cfm.example.transform.MyTransformId"/>
</ExtendTransform>
</TransformationExtension>
</extension>
</plugin>
|
다음의 샘플 커스텀 확장은 비즈니스 프로세스-서비스 모델 주 변형을 타겟으로 한다:
com.ibm.xtools.transform.cfm.wbm.transforms.MainTransform
또한 확장 적용성을 결정하는데 어떤 확장 조건이 사용되어야 하는지도 지정한다:
com.ibm.xtools.transform.cfm.example.condition.MyExtensionCondition
마지막으로, 변형의 브랜치를 지정하는데, 이는 다음과 같은 확장에 의해 확장된다:
com.ibm.xtools.transform.cfm.wbm.transforms.OwnedBehaviorTransform
커스텀 확장 전개하기
- 변형을 설정한다.
- 이전 단계를 마친 후에, 플러그인을 플러그인 plug-ins 디렉토리로 보내고, Rational Software Architect를 재시작 한다.
커스텀 확장은 Configuration UI(사용자 인터페이스)에서 선택할 수 있다. (그림 4)
그림 4. 커스텀 확장으로 변형 설정하기
- 커스텀 확장을 사용하는 프로세스들 중 하나를 설정한다.
- 설정을 저장하고, 변형을 실행한다.
- 아웃풋으로 작업하고, 계속 모델링 하여, 레거시 코드로 위임한다. (그림 5)
그림 5. 커스텀 확장 분해를 사용하여 변형된 Payment Collector
커스텀 확장을 위한 분해는 그림 5에 묘사되어 있다. 이제 다음 단계를 수행할 차례가 되었다.
서비스 호출을 자바 라이브러리에 위임하기
자바 어댑터의 역할은 서비스 호출을 자바 라이브러리로 위임하는 것이다. 다음은 모델링 단계이다:
-
BillingComponent를 입력하여 Payment Collector를 위한 두 번째 프로퍼티(파트)를 만들고, 두 개의 포트를 추가한다:
- 첫 번째 포트를 myRoleAdapter에 추가하고, 필수 인터페이스를
com.acme.billing.Billing으로 설정한다.
- 두 번째 포트를 Billing component에 추가하고, 유형을
com.acme.billing.MedicalBilling (그림 6)으로 설정한다.
- 두 개의 포트를 연결한다.
그림 6. 확장을 레거시 코드에 맞게 바꾸기
주:
Billing 서비스는 Logger라고 하는 또 다른 서비스를 필요로 한다. Logger 서비스의 구현이 Billing과 같다면, Billing에서 했던 것과 같은 방법으로 Logger 서비스를 모델링 할 수 있다. 그렇지 않다면, myRoleAdapter 컴포넌트의 기능 일부로서 모델링 될 수 있다.
이 모델은 SOA Transformation에 의해 사용되어 전개 생성물들을 만든다. SOA Transformation은 Payment Collector 컴포넌트를 IBM®WebSphere® Integration Developer 비즈니스 통합 모듈 프로젝트로 변형한다. 자바 어댑터용 파트와 Medical Billing은 그 모듈 내 Service Component Architecture (SCA) 컴포넌트로 변환된다. MedicalBilling을 위해 생성된 SCA 컴포넌트는 자바 레거시 라이브러리에 대한 컴포넌트 구현 레퍼런스를 나타낸다.
요약과 Part 3 예고
비즈니스 프로세스-서비스 모델 변형 기능은 WebSphere Business Modeler의 비즈니스 분석 모델링과 UML의 디자인 모델링 간 다리 역할을 한다. 특정 전개 영역과 구현 영역 요구 사항을 가진 비즈니스는 이러한 변형을 자신들의 필요에 맞게 바꿀 수 있다. 변형에 의한 생성물들은 Rational Software Architect에서 추가 모델링을 거친다. 또한 Rational Software Architect에 제공된 SOA Transformation 툴을 사용하여 WebSphere Integration Developer 프로젝트로 변형될 수 있다.
다음 글인, SOA로 변형하기: Part 3. UML-SOA 에서는 SOA 변형에 대해 자세히 설명할 것이다. Part 3에서는 Rational Architect Version 7.0.0.2 또는 이후 버전에 포함된 UML-SOA 변형 툴을 사용하여 소프트웨어 서비스의 UML 모델을 특정 영역의 SOA 구현으로 바꾸는 방법을 상세하게 설명한다. 이 툴은 특정 소프트웨어 구현과 런타임을 위한 다른 변형 확장에 대한 우산의 역할을 한다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | | | Natalia는 IBM Rational 소프트웨어 툴을 지원하는 소프트웨어 엔지니어이다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| |
