![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
TMF(TeleManagement Forum)와 같이 CIM 모델을 기반으로 하는 업계에서 오브젝트, 속성 및 관계를 포함한 엔티티의 큰 부분으로 SID(공유 정보 데이터 모델) 목록을 발행하는 동안, IBM에서 발행한 IFW(IBM 금융 서비스업 모델)와 같은 CIM 모델로는 추가적으로 오브젝트 인터페이스를 포함하여 이를 통해 사용자는 서비스 스펙을 생성할 수 있다.
CIM 그 자체는 커다란 부분이며 이전에 언급한 대로 이는 앵커 오브젝트를 결정하는 각 서비스의 "비즈니스 의도"(BI)이다. 앵커 오브젝트는 모든 서비스 운영 요청 또는 응답이 CIM의 기반을 강타하는 CIM 오브젝트이다. 앵커 오브젝트가 한 번 정의되면, 다른 CIM 요소들을 모두 검색할 수 있으며 이는 서비스 내에서 오브젝트의 관계 작동에 엄청난 영향력을 가진다. 예를 들어, 오브젝트 A와 오브젝트 B 사이에 CIM으로 정의된 관계가 있으며, BI는 B에서 A 또는 그 반대로 횡단이 발생해야 하는 방식(이 경우에 서비스 인터페이스에서 B는 A를 포함할 것임)으로 앵커 오브젝트를 결정할 수 있다. 그러면 관계들은 관계 이름을 규모에 동일시하는 것 뿐 아니라 방향성을 소유하는 "벡터" 작동을 취득하려는 경향이 있다.
이 기사에서는 SOA 기반 구현에서 CIM 오브젝트들의 관계의 이러한 특성에 대해 알아보려 한다.
아래 그림 1은 비즈니스 프로세스와 CIM 계층을 보여준다.
그림 1. 비즈니스 프로세스 및 CIM 계층
- 상부 계층은 거품과 같이 프로세스 요소들을 포괄하는 비즈니스 프로세스 계층이며, 이는 결과적으로 서비스로 전환된다. (주: 프로세스 계층은 실제로 다양한 추상화 레벨로 나타날 수 있다. 예: 통신 업계에서 e-TOM(향상된 통신 운영 맵)과 은행 업계에서 APM(분석 프로세스 모델) 재사용에 따라 SOA 아키텍트는 단일 서비스 또는 다중 서비스로 그 기능을 인식하도록 결정할 수 있다.
- 하부 계층은 CIM 오브젝트를 포괄하는 CIM 계층이다. 또한 이름이 지정된 CIM 오브젝트들(ProoductOrder, Resource, TelephoneNumber)은 "벡터 작동"을 이해하기 위한 예제로 논의할 것이다.
"OrderManagement"라는 용어로 주문을 관리하기 위한 서비스를 작성하는 예제를 생각해보자. 다음 단계는 이 서비스의 비즈니스 의도를 분석하는 것이다.
비즈니스 의도는 서비스의 비즈니스 기능일 뿐이다. 간단히 하기 위해서 이 경우에 SOA/통합 아키텍트가 단일 서비스 컴포넌트만을 통해 이 기능을 이행하도록 결정한다고 가정하자. 반면에, 현실에서 기능은 다중 서비스 컴포넌트를 통해 이행될 수 있다. 중요하게 이해할 점은 하나의 추상 서비스에 주어진 기능을 이행하는 서비스의 수가 몇 개이든지 간에, 그 의도는 동일하게 유지된다는 점이다. 이 예제에서는 주문 관리 프로세스가 "AddressManagement", "ProductValidation" 등과 같은 서비스를 통해 내부적으로 인식되어야 한다고 하더라도, 그 의도는 주문만 관리하도록 유지된다. 이 점이 명확히 이해되면 SOA/통합 아키텍트는 앵커 오브젝트를 식별해야 한다.
앵커 오브젝트는 이전에 언급한 대로 서비스 운영이 CIM에 연결되는 CIM 오브젝트이다. 앵커 오브젝트의 선택은 서비스 운영 요청 및 응답과 커플링되는 비즈니스 의도와 완전히 맞추어야 한다.
예를 들어, OrderManagement의 BI가 프론트 엔드 CRM(고객 관계 및 관리) 애플리케이션으로부터 포착된 주문을 이행하도록 수행하는 것이라고 가정하자. 서비스 요청은 아마 완료된 주문 구조를 수신하고 여기에서 생성된 또 다른 OrderId로 다시 응답하도록 예상한다.
이 경우에 그 요청의 앵커 오브젝트는 ProductOrder(CIM으로 TMF SID 사용)이다. 예: 서비스 운영 SubmitOrderRequest는 ProductOrder(CIM)에 커플링되거나 연결될 것이며, 그 다음에 모든 다른 요소들은 이를 사용하여 검색될 것이다. 한편, SubmitOrderResponse라는 용어의 응답은 아마 아래 그림 2와 같이 ProductOrder(CIM)로 다시 연결될 것이다.
그림 2. 앵커로서 ProductOrder
이 경우에 요청과 응답은 둘 다 앵커 오브젝트를 하나만 가지며, 요청과 응답 운영에 대해서도 동일하다.
현실에서는 운영 요청이나 응답의 중요하지 않은 앵커 오브젝트들이 둘 이상 있을 수 있다. 서비스인 "AddressManagement"를 다른 예제로 고려해보자. AddressManagement의 BI는 주소 세부사항을 관리하는 것이다. AddressManagement가 Customer의 AddressReferenceIdentifier 또는 MobileTelephone 숫자 중 하나를 수신하고 주소 구조로 다시 리턴할 수 있는 방식으로 설계되어야 한다면, 아마 그 요청 "RetrieveAddressDetailsRequest"는 Address(CIM) 뿐만 아니라 TelephoneNumber(CIM)에도 연결할 수 있다. 예: "RetrieveAddressDetailsResponse"가 Address(CIM)에만 연결하는 동안 앵커 오브젝트들은 두 개 이상
앵커 오브젝트가 완결되면 다른 오브젝트로의 횡단은 방향에 민감해지고 관계는 차후에 논의되는 벡터와 같이 작동하려는 경향이 있다.
ProductOrder에서부터 TelephoneNumber로의 횡단
첫 번째 예제 OrderManagement 서비스를 살펴보자. 이 경우에 주문이 전화 번호도 포함한다고 가정하자. ProductOrder를 사용하여 "TelephoneNumber"를 앵커 오브젝트로 검색하려면 ProductOrder에서부터 횡단이 수행되어야 한다.
그림 3. ProductOrder에서 TelephoneNumber로
그림 3에서는 ProductOrder에서부터 TelephoneNumber로의 횡단을 보여주며, 이는 관계 이름을 표현하는 a1, b1, c1, d1. a1, b1, c1, d1 경로를 통해 이루어진다. 이렇게 생성된 서비스 인터페이스에서 ProductOrder는 a1, b1, c1, d1을 통해 횡단하는 TelephoneNumber가 들어있다. 예: 횡단은 벡터의 방향과 유사한 방향이 되고 관계 이름이 벡터의 규모에 유사하게 되는 방향에 민감해진다.
TelephoneNumber에서 ProductOrder로의 횡단
또 다른 서비스인 TelephoneNumberManagement에 대해 고려해보자. 이 서비스는 입력이 TelephoneNumber와 ProductIdentifier가 되고 응답이 성공 또는 실패가 되는 요청 운영 ReserveTelephoneNumber가 있다. 이 경우에 BI가 전화 번호를 관리하는 것이기 때문에 요청의 앵커 오브젝트는 TelephoneNumber이다. 이는 ProductIdentifier를 검색하기 위해 횡단이 아래 그림 4와 같이 반대 방향에서 수행되어야 한다는 것을 의미한다. 경로는 다르고 다른 이름을 가져야 한다. 이 경우에는 d2, c2, b2, a2이다. 생성된 서비스 인터페이스에서 TelephoneNumber에는 다른 관계 이름이 있는 ProductOrder가 들어 있을 것이다.
그림 4. 전화 번호 요청 예약
CIM은 대부분의 경우에 UML을 기반으로 한다. 이는 횡단이 오브젝트들 사이에 어느 방향으로나 가능하다는 것을 의미한다. 하지만 SOA를 위해 처리할 때에 BI가 식별되어야 하며, 따라서 방향은 논의한 대로 지정된다. 모든 양방향 관계의 경우(상위 하위 관계 제외) 이론적으로는 다른 이름으로 또 다른 관계를 정의해야 한다. (예: 그 방향을 기반으로 하는 다른 이름) 도구들은 주기적 종속성 문제를 충분히 처리할 수 있는 지능형이어야 한다. IBM RSA(Rational 소프트웨어 아키텍트) 도구는 "벡터 작동"을 충분히 처리할 수 있는 지능형이다. Progress DXSI 데이터 확장 이외에도 써드파티 도구는 이러한 시나리오를 처리할 수 있으며, WID(WebSphere Integration Developer), WPS(WebSphere Process Server)와 같은 IBM 블루 스택 도구들과 통합하는 것으로 입증되었다. 프로젝트 상 필요에 따라 SOA/통합 아키텍트는 적절한 도구를 선택해야 한다.
SOA 환경을 기반으로 하는 CIM에서 오브젝트들 사이에 관계들은 방향에 민감해지는 벡터와 같이 작동한다. 방향은 앵커 오브젝트로 정의되어, 결과적으로 비즈니스 의도로 구동된다. 적절한 도구들은 설계를 처리하기 위해 필요하며, 이는 프로젝트에 대해 신중하게 선택되어야 한다.
- Information Framework(SID)에 대해 더 자세히 읽어보자.
- IBM Redbook 서적 "Implementing
Technology to Support SOA Governance and Management"를 다운로드하자.
- achieve data interoperability with
common-model-based data services inside your service-oriented architecture의 방법에 대해 더 자세히 배워보자.
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그