SOA로 변형하기: Part 3. UML에서 SOA로

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 중급

Dmitry Gorelik, Software Developer, IBM Japan

2008 년 5 월 13 일

본 글은 IBM® Rational® Software Architect 7.0.0.2나 그 이상 버전에 포함된 UML-to-SOA 변환 도구를 사용해 소프트웨어 서비스를 UML 모델에서 서비스 지향 아키텍처(SOA) 모델로 바꾸는 과정을 설명합니다. 이 변환 과정은 특정 소프트웨어 구현을 위해 다르게 확장, 변환되는 것을 보호하는 역할을 합니다. UML-to-SOA 변환은 특히 UML 모델을 소스로 받아들이고 특정 도메인에 한정적인 SOA 구현을 가능하게 합니다. 변환 출력은 전적으로 선택된 변환 확장에 의존합니다. 보통 변환 확장은 도메인에 한정적인 소프트웨어 산출물을 생산하는데, 이는 런타인 머신이나 서버에 배치될 수 있습니다. 이러한 확장은 이후 개발 및 배치에 다른 도구를 입력 장치로 사용할 수 있게 해줍니다.

IBM® Rational® Software Architect의 UML-to-SOA 변환 도구에는 SOA 변환 도구가 포함되어 있다. 이는 SCA(Service Component Architecture)를 기반으로 하는데, SCA는 SCDL(Service Component Definition Language)을 사용해 메타데이터를 표현한다. UML-to-SOA 변환 도구는 향상된 개발, 테스팅, 배치를 위해 IBM® WebSphere® Integration Developer 6.0.2나 그 이상 버전으로 임포트된다. 일반적인 변환 구성 옵션에 더해 UML-to-SOA 변환 도구는 특정 구성 속성을 제공한다.

변환 구조와 확장성

그림 1은 UML-to-SOA 변환 구조를 보여준다.

UML-to-SOA 변환 도구는 SCDL 모듈과 라이브러리 프로젝트를 만드는 역할을 하는 UML-to-SCDL 변환으로 확장된다.

• 모듈 프로젝트에는 모듈, 컴포넌트, 익스포트, 임포트 같은 SCDL 산출물이 포함되어 있다.
• 라이브러리 프로젝트에는 다양한 SCDL 요소로 참조되는 도메인에 한정된 다른 산출물이 들어있다.

Rational Software Architect의 UML-to-SCDL 변환 도구는 두 그룹으로 이뤄진 네 가지 확장을 제공한다.

• 인터페이스 확장은 WSDL 포트 유형과 자바 인터페이스에서 참조되는 UML 인터페이스를 포함하는 소스 모델의 모든 인터페이스를 처리하는 데 사용된다. UML-to-WSDL 변환은 WSDL 인터페이스 확장에 의해 사용돼 SCDL 컴포넌트, 익스포트, 임포트로 참조되는 WSDL 포트 유형을 만든다. 자바(Java™) 인터페이스 확장은 참조된 자바 인터페이스를 가지는 자바 프로젝트를 타깃 프로젝트(target project)에 복사하는 데 쓰인다.

• 컴포넌트 구현 확장은 UML 활동을 처리하고 자바 클래스를 참조하는 데 사용된다. BPEL(Business Process Execution Language) 구현 확장은 UML-to-BPEL 변환을 사용해 SCDL로 참조되는 BPEL 프로세스를 만든다. 자바 구현 확장은 참조된 자바 클래스를 가지는 자바 프로젝트를 타깃 프로젝트에 복사하는 데 사용된다.

UML-to-BPEL 변환 도구는 UML-to-WSDL 변환과 UML-to-XSD 변환을 사용해 WSDL(Web Service Description Language) 포트 유형과 XSD 스키마 데이터 타입을 만든다. 비슷하게 UML-to-WSDL 변환은 UML-to-XSD 변환을 사용해 XSD 스키마 데이터 타입을 만든다.

변환 소스

UML-to-SOA 변환은 소프트웨어 서비스의 UML 모델을 처리하기 위해 만들어졌다.

UML-to-SOA 변환을 위해 의도된 소스는 전체 UML 모델 또는 소프트웨어 서비스를 적용하기 위한 UML 2.0 프로파일이다. 동시에, 변환은 하나 이상의 UML 패키지나 또는 해당 소스로, 서비스 프로바이더를 대표하는 개별 UML 컴포넌트를 받아들일 수 있다. UML 모델이나 패키지가 소스로 선택되면 UML-to-SOA 변환은 선택된 모델이나 패키지를 찾고 각 서비스 프로바이더를 위해 필요한 SCDL 산출물을 만든다. 다중 UML 요소를 변환의 소스로 선택하면 UML-to-SOA 변환으로 지원을 받는다.

그림 2는 UML 모델(왼쪽)의 한 부분으로 CreditManager 서비스 프로바이더를 보여주고 UML 클래스 다이어그램(오른쪽)과 CreditManager 서비스 프로바이더의 외부 뷰를 보여준다.

변환 출력

UML-to-SOA 변환은 앞으로의 개발, 테스팅, 배치를 위해 IBM WebSphere Integration Developer 6.0.2나 그 이상 버전에 임포팅되는 출력을 산출한다. 변환은 하나의 타깃으로서, 작업공간의 어떤 프로젝트도 받아들일 수 있다.

팁:
필요하다면 Transformation Configuration 편집기의 Source and Target 페이지 상의 Create New Target Container를 클릭해 새 타깃 프로젝트를 만들 수 있다.

각 서비스 프로바이더를 위해 변환은 모듈 프로젝트를 만든다. manifest.mf, .project, .classpath, .runtime 같은 전형적인 프로젝트 파일에 더해 변환은 sca.module 파일과 SCDL 모듈의 다양한 요소를 대표하는 컴포넌트, 익스포트, 임포트의 확장 파일을 만든다. 모듈 프로젝트는 하나 이상의 라이브러리 프로젝트(인터페이스와 비즈니스 객체 정의를 포함하는)를 참조한다.

그림 3은 UML-to-SOA 변환 도구로 만들어진 모듈 프로젝트의 전형적 구조를 보여준다. 이는 UML-to-SOA 변환으로 만들어진 com.acme.creditmanagement.CreditManager 모듈 프로젝트를 보여주는 확장된 뷰다.

각 UML 인터페이스에 대해 변환은 나뉜 WSDL 파일을 만든다. UML 초기 유형과 빌트인 XSD 단순 유형을 제외한 각 UML 매개변수 유형(데이터 타입)에 대해 변환은 나뉜 XSD 파일을 만든다. WSDL과 XSD 리소스는 변환 소스의 구조에 따라 단일 라이브러리 프로젝트나 다중 라이브러리 프로젝트에서 만들어진다. 그림 4는 UML-to-SOA 변환으로 만들어진 CreditManagement 라이브러리 프로젝트를 보여준다.

소스에서 출력까지의 매핑

다음 표는 소스와 출력 객체 간의 매핑을 기술한다.

UML 서비스 프로바이더 컴포넌트에서 SCDL 모듈로 변환하기

UML-to-SOA 변환은 특정 소프트웨어 서비스 디자인에 따라 SCDL 모듈의 다른 유형을 산출한다. UML에서 소프트웨어 서비스를 디자인하는 것에 관한 자세한 내용은 이전 글인 SOA 모델링을 읽어보기 바란다.

그림 5는 UML 컴포넌트로 나타나는 Customer Order Handling 서비스 프로바이더와 갖춘 행위(owned behavior)로 사용된 Customer Order Handling UML을 보여준다.

이 서비스 프로바이더 디자인을 위해 변환은 단일 SCDL 컴포넌트와 BPEL 구현을 가진 SCDL 모듈 프로젝트를 만든다(그림 6 참조). UML 행동과 BPEL 프로세스 매핑에 관한 더 자세한 내용은 참고자료에 인용한 SOA 모델링 연재 중 "From UML to BPEL"를 참조하기 바란다.

그림 7은 Customer Order Handling 서비스 프로바이더의 분해를 보여주는 UML 컴포지트 구조 다이어그램을 보여준다.

이 경우 변환은 서비스 프로바이더의 각 UML 부분마다 SCDL 컴포넌트를 만들고 이 컴포넌트들을 서비스 프로바이더를 나타내는 UML 컴포넌트의 내부 구조로 적절히 보낸다(그림 8 참조).

UML 컴포넌트로 UML 포트를 통해 제공되고, 서비스 프로바이더를 나타내는 모든 인터페이스는 SCDL 익스포트가 된다. UML 포트를 통해 노출된 모든 필요한 인터페이스는 SCDL 임포트가 된다. 이 예에서 myRole 포트를 통해 노출되어 제공된 CustomerOrderHandling 인터페이스는 myRoleExport.export 파일을 생성하기 위해 사용됐다. OrderVerification, PaymentHandling, CustomerServiceRepresentative, AccountManager 포트는 각각의 임포트 파일을 만들기 위해 사용됐다.

UML 모델과 레퍼런스를 도메인 한정적인 데이터 타입과 인터페이스로 변환하기

몇몇 데이터 타입 라이브러리는 특정 산업에서 추천 또는 공식 표준이 됐다. 이를테면 HL7(Health Level Seven)은 의료계의 ANSI 공인 표준 개발 조직 중 하나인데 XSD 형식으로 된 임상 및 경영 데이터 표준을 제공한다. 많은 경우에 산업에 특화된 타입과 데이터 세트를 사용하는 것은 소프트웨어의 핵심 요구사항 중 하나다.

기존 XSD 데이터 타입으로 레퍼런스 처리하기

이 요구사항을 만족시키려면 소프트웨어 서비스의 UML 모델은 레퍼런스를 기존 XSD 유형으로 사용해야 한다. 이 경우 UML-to-SCDL 변환은 라이브러리 프로젝트를 만들고 부모 프로젝트에서 참조된 XSD 데이터 타입을 가지는 XSD 리소스를 폴더 스트럭처 및 XSD include 또는 XSD import로 참조되는 모든 XSD 스키마를 포함하는 라이브러리 프로젝트에 복사한다. 만들어진 라이브러리 프로젝트의 이름은 원래 참조된 XSD 스키마를 포함하는 프로젝트의 이름과 같다. 포함되거나 임포트된 XSD 스키마가 다른 프로젝트에 있다면 변환은 관련 라이브러리 프로젝트를 만들고 프로젝트 의존성을 필요한 곳에 추가한다.

기존 WSDL 포트 유형으로 레퍼런스 처리하기

기존 XSD 데이터 유형과 같은 방식으로, 소프트웨어 서비스의 UML 모델도 레퍼런스를 기존 WSDL 포트 유형으로 사용한다. WSDL 포트 유형으로의 레퍼런스는 참조된 XSD 데이터 타입과 같은 방식으로 변환 처리된다. 이렇게 되면 UML 모델에서 참조된 WSDL 포트 유형을 위한 모든 필요한 라이브러리 프로젝트와 XSD include나 XSD import로 참조된 WSDL 임포트와 XSD 스키마를 사용해 참조된 모든 WSDL 파일을 만든다.

참조된 자바 인터페이스와 자바 클래스 처리하기

UML-to-SOA 변환은 소프트웨어 서비스의 UML 모델과 레퍼런스로 기존 자바 인터페이스와 클래스를 소스로 지원한다. 이를 통해 이미 자바 구현을 가진 기존 서비스 집합이나 구성으로 새 서비스를 설계할 수 있고 자바 인터페이스를 통해 노출될 수 있다. 소스 모듈을 파싱하는 동안 자바 인터페이스나 클래스에서 변환이 이뤄질 때 자바 프로젝트를 복사한다. 이 복사에는 자바 소스 코드와 의존하는 모든 자바 프로젝트가 포함되고 변환 타깃 컨테이너로 선택된 프로젝트로 이동된다.

변환 출력을 IBM WebSphere Integration Developer에 임포팅하기

웹 애플리케이션을 만들고 완성하고 테스트하려면 File > Import > Existing Projects into the Workspace를 선택해 변환 출력이 WebSphere Integration Developer로 임포트되어야 한다. 변환으로 만들어진 모든 프로젝트는 각각 WebSphere Integration Developer 작업공간에 임포트되어야 한다. 임포트된 프로젝트는 의존성을 갖는다. 프로젝트가 잘못 임포트되면 빌드는 오류를 가질 것이다. 이 경우 간단히 모든 임포트된 프로젝트를 제거하고 다시 만든다.

그리고 나서 WebSphere Integration Developer에서 다음 작업을 완성한다.

1. 빈 구현(empty implementation)으로 컴포넌트에 구현을 추가한다.
2. 모든 임포트를 보낸다.

요약

SOA 변환에 관한 더 자세한 정보는 본 연재의 마지막 글인 'SOA로 변환: Part 4. UML-to-BPEL'에서 찾을 수 있다. 또한 더 자세한 정보를 위해 참고자료의 인용과 링크를 확인하자.

참고자료

• 본 연재의 Part 1인 SOA로 변환: Part 1. IBM WebSphere Business Modeler와 IBM Rational Software Architect를 사용해 비즈니스 프로세스를 서비스 모델 아키텍처로 변환하기를 보라.
  
  
• 본 연재의 Part 2인 SOA로 변환: Part 2. IBM Rational Software Architect에서 Business Process-to-Service Model을 위한 맞춤 확장 만들기를 보라
  
  

• 추가적인 유용한 정보를 위해 SOA(서비스 지향 아키텍처)를 기반으로 소프트웨어 개발하기에 관한 Jim Amsden의 다섯 가지 연재를 읽자.

  • Modeling SOA: Part 1. Service identification 은 IBM 소프트웨어 서비스 프로파일로 확장된 UML 모델을 사용해 비즈니스 요구사항에 연결되지만 솔루션 구현에 독립적인 SOA 솔루션을 디자인하는 방법을 보여준다. 필자는 비즈니스 달성 및 목표와 이 목표들에 맞도록 구현된 비즈니스 프로세스를 기술하고 프로세스를 사용해 비즈니스와 관련된 필요한 서비스를 식별하고 나타내는 요구사항을 충족하는 방법을 설명한다.
  • Modeling SOA: Part 2. Service specification에서 필자는 각 서비스의 식별을 자세히 모델링함으로써 SOA 솔루션을 계속 정의한다. 이 명세들은 서비스의 소비와 생산 간의 계약을 정의할 것이다. 이 계약들에는 제공되고 요구된 인터페이스, 서비스 명세에서 이 인터페이스들이 작동하는 역할, 이 역할들이 상호 작용하는 방법의 규칙과 프로토콜을 포함한다.
  • Modeling SOA: Part 3. Service realization 기사에서는 SOA 기반 웹 서비스가 실제 구현되는 방법을 설명한다. 서비스 실현은 어떤 컴포넌트가 어떤 서비스를 제공할지 결정하는 것으로 시작한다. 이 결정은 서비스 유용성, 배포, 보안, 트랜잭션 범위, 커플링에 중요한 함의를 갖는다. 이 결정들이 이뤄진 후 각 서비스의 기능이 구현되는 방법과 필요한 서비스가 실제 어떻게 사용되는지 설계할 수 있을 것이다. 그리고 나면 IBM Rational Software Architect에 포함된 UML to SOA 변환 기능을 사용해 IBM WebSphere Integration Developer에서 완벽한 솔루션을 구현, 테스트, 배치하는 데 쓸 수 있는 웹 서비스 구현을 만들 수 있다.
  • Modeling SOA: Part 4. Service composition에서는 Part 3에서 설계한 서비스 프로바이더를 모으고 연결하는 방법과 이들의 인터랙션을 구성해 비즈니스 요구사항에 완벽한 솔루션을 제공하는 방법을 다룬다. 결과 컴포넌트는 Invoicer, Productions, Shipper 컴포넌트로 제공되는 서비스를 구성하는 서비스 참여자가 되어 구매승인서(purchase order)를 처리할 수 있는 서비스를 제공한다. 또한 이 서비스 참여자가 원래 비즈니스 요구사항을 만족시키는 방법을 보여준다.
  • Modeling SOA: Part 5. Service implementation: 이 마지막 글에서 필자는 서비스 모델의 디자인 결정과 아키텍처로 구성된 실제 구현을 만드는 방법을 기술한다. 여기서 모델 위주 개발과 IBM Rational Software Architect UML-to-SOA 변환 기능 모두를 활용해 플랫폼에 한정된 구현을 생성해 SOA 모델에서 웹 서비스를 만들 것이다.
  
  
• 한국 developerWorks의 SOA와 웹 서비스 영역을 찾아 서비스 지향 아키텍처에 관한 기술을 향상시키는 데 도움이 되는 자료를 얻자.
  
  
• IBM.com의 IBM SOA 솔루션 사이트를 방문하자.
  
  
• 한국 developerWorks의 Rational 소프트웨어 사이트를 방문하여 Rational Software Delivery Platform 제품에 관련된 기술 자료와 실용적 업무 처리 자료를 얻자.
  
  
• developerWorks Rational 존 뉴스레터에 등록하자. developerWorks Rational에 관한 최신 자료를 받을 수 있다. 매주 Rational Software Delivery Platform에 대한 최신 기술 정보와 실용적 업무 처리 자료를 업데이트 받을 것이다.
  
  
• 효과적인 소프트웨어 개발의 기본 개념에 관련된 글을 위해 Rational Edge 뉴스레터에 등록하자.
  
  
• 기술 주제에 관련된 책을 찾기 위해 기술 서점을 방문하자.
  
  

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

• developerWorks 블로그를 확인하고 developerWorks 커뮤니티에 참여하자.
  
  
• Rational 포럼: Rational Software Architect에 관련된 질문을 할 수 있다.

필자소개

		Dmitry는 IBM Rational 소프트웨어 도구를 지원하는 소프트웨어 개발자다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로