 |
이 타스크에서는 종합적인 메시지 디자인 모델(카탈로그)을 개발하는 데 필요한 조치를 설명합니다. 또한 도메인 모델과 메시지 모델의 관계 및 메시지 교환 패턴을 설명합니다. 메시지 세분성 및 메시지 성능에 대한 디자인 고려사항도 간단히 설명합니다. |
원칙: 분석 및 디자인 |
|
관계
역할 | 기본 수행자:
| 추가 수행자:
|
입력 | 필수:
| 선택사항:
|
출력 |
|
프로세스 사용법 |
|
기본 설명
통신 서비스와 컴포넌트 간의 메시지는 SOA의 중요한 부분입니다. 이 메시지에는 기존 서비스 호출의 입출력 메시지 뿐 아니라 엔터프라이즈에 사용할 내부 메시지 형식이 포함되며 정보 플로우는 응용프로그램 아키텍처의 계층을
통해 전달됩니다. 많은 경우에, 공통 메시지 형식이 권장됩니다.
서비스에는 입출력 메시지가 포함되므로 이 타스크는 다음과 같은 내용에 초점을 맞춥니다.
-
서비스에 대한 입출력 메시지의 형식 및 컨텐츠 식별 및 스펙
-
기본적인 데이터 모델과의 관계
-
내부 공통 메시지 형식 및 고려사항
-
각 메시지를 다른 메시지에 맵핑하는 방법 결정
서비스 모델의 메시지 스펙에서는 엔터프라이즈 아키텍처/응용프로그램 아키텍처, 데이터 아키텍처 및 통합 아키텍처의 Perspective를 고려해야 합니다. 이는 다음과 같습니다.
-
엔터프라이즈 또는 응용프로그램 레벨에서 정의된 메시지 표준
-
데이터 아키텍처의 파트인 해당 메타 또는 데이터 모델
-
통합 아키텍처의 일부인 메시지 변환 표준
스펙에서는 아키텍처의 세 영역 각각의 조직 표준을 이해해야 합니다. 메시지 스펙 및 데이터 모델은 밀접하게 연결되어 있습니다. 데이터 모델은 기본적인 엔티티 및 해당 관계 즉, 출력 메시지의 일부로 송신되고
들어오는 입력 메시지에서 수신되는 서브세트로 구성되어 있습니다. 따라서 메시지 형식과 기본적인 데이터 모델 또는 데이터 아키텍처 간의 맵핑은 아키텍처의 핵심 고려사항입니다. 경우에 따라 패턴 및 해당 구현(예:
엔터프라이즈 서비스 버스)으로 메시지의 변환(및 라우팅)을 처리할 수 있습니다. 많은 경우에, 데이터 모델에 대한 입출력 메시지를 변환하려면 명시적 핸들러가 필요합니다.
대부분의 객체 지향 프로그래밍 언어에서 동작 호출은 메소드 호출 또는 메시지 전달 패러다임을 기반으로 합니다. 예를 들어, C++의 경우 함수 포인터 테이블을 사용하여 올바른 메소드를 호출합니다. 반면에
Smalltalk의 경우 실행 시간에 수신측을 평가하는 메시지를 전달합니다. 서비스 지향 솔루션은 기본적으로 메시지를 기반으로 하며 프로그래밍 언어에 대한 바인딩이 클라이언트에 대한 메소드 기반 인터페이스를 나타낼
수 있지만 서비스 간 또는 서비스와의 통신에는 해당되지 않습니다. 서비스 메시지 전달의 또 다른 측면은 메소드 호출의 근본적인 동기 특성과 달리 비동기 인터페이스로 개발되는 서비스가 많아지고 있다는 것입니다.
엔터프라이즈 통합 분야에서는 메시지 지향 미들웨어(MOM)라는 단일 기술 클래스를 사용하여 수년 간의 성공을 이루어왔습니다. 이 기술 세트는 대기열 관리자 및 메시지 브로커와 같은 제품에서 잘 나타납니다. MOM은
IT 조직에 응용프로그램을 느슨하게 연결하기 위한 유연하고 확장 가능하며 견고한 메소드를 제공해왔습니다.
서비스 지향 아키텍처(SOA)는 컴포넌트 기반 개발의 발전으로 인식되어 왔습니다. 이러한 발전과 관련하여 일정 측면에서는 MOM의 성공에서 얻은 많은 교훈을 고려합니다(예를 들어, 시스템을 느슨하면서도 효과적으로
결합하는 방법). MOM 하부 구조는 통신 시스템의 독립적인 발전을 허용하는 다음과 같은 특성을 제공합니다.
-
메시지 대기열 지정 - 네트워크 또는 시스템 장애에도 신뢰할 수 있는 메시지 전달
-
메시지 라우팅 - 성능 및 신뢰성을 위한 네트워크 라우팅 및 메시지 컨텐츠를 기반으로 한 고급 라우팅의 두 가지 관점
-
메시지 변환 - 수신 서비스가 "항목"에 대한 요청을 허용할 수 있을 때 호출 서비스가 "제품"에 대한 요청 전송 가능
-
메시지 어댑터 - 원래 MOM 인터페이스로 개발되지 않은 시스템을 MOM 인식 서비스로 지원 가능
|
단계
메시지 표준 사용
식별된 서비스의 메시지 스펙 정의 시 엔터프라이즈 메시지 표준(존재하는 경우)을 고려해야 합니다. 메시지 표준을 정의하지 않은 경우, 이를
개발하는 것이 좋습니다. 산업 메시지 스키마가 있는 경우에는 이를 사용합니다. 예를 들어, XML 메시지 전달 스펙은 금융, 정부,
여행(OTA XML [Open Travel Alliance, http://www.opentravel.org/online_schema.cfm]) 및 통신 산업용으로 정의되었습니다.
또한 OAGIS [Open Applications Group, http://www.openapplications.org/index.htm]에서 사용 가능한 비산업용 특정 스키마가 있습니다.
공통
메시지 형식
공통 메시지는 n 층의 아키텍처 층을 통해 전송되는 메시지를 나타냅니다. 일반적으로 사용자 인터페이스 정보는 제어기 층을 통해서
캡처하고 송신하며 비즈니스 또는 응용프로그램 계층에서 프로세스한 다음 지속성 계층 또는 백엔드 레거시 시스템에 전달합니다. 이러한
전송 중에 메시지는 서로 다른 형식을 갖는 층 간에 교환됩니다. 엔터프라이즈 서비스 버스(ESB)를 사용하지 않거나 형식 변환이란
점에서 ESB 사용이 고비용이라고 간주되는 경우, 모든 형식 변환 오버헤드를 해결하려면 엔터프라이즈에 있는 공통 메시지 형식의 표준과 일치해야 합니다. ESB를 사용하여 이러한 중개, 변환 및 라우팅을 수행할 수 있습니다. ESB는 SOA 계층 모델에서 설명된대로 통합 계층입니다.
경우에 따라 출력 및 입력 메시지 형식과 일치하면 됩니다. 공통 메시지 형식에 대한 문제는 아키텍처의 핵심 결정입니다. 즉, 여기에
지정된 "맞춤식"을 선택하거나 산업 모델(예: 여행 산업의 OTA XML) 또는 비산업용 특정 모델(OAGIS에서 정의)을 채택할 수 있습니다. 경우에 따라 결정은 메시지에서 필드를 갱신하는 공통 엔터프라이즈 메시지를 사용하고 계속 처리하기 위해 다음 층으로 전달하는 것입니다. 정치적 요소 때문에 이와 같은 공통 구성을 완성할 수 없는 경우, 메시지를 내부 공통 메시지 형식으로 변환하는 어댑터를 디자인할 수 있습니다.
또한 어댑터는 ESB의 파트로 사용할 수 있습니다.
ISV
고려사항 :
ISV 패키지에서 실현된 서비스를 호출하는 메시지는 ISV 패키지 데이터 모델의 제한조건을 충족시키는 데이터 속성으로 증가되어야 합니다. 이와 같은 데이터 요소는 ISV 패키지 컴포넌트 내에서 실현된 서비스의 분석을 통해 식별되거나 ISV 패키지 상향식 서비스 분석을 통해서도
식별될 수 있습니다. 서비스를 실현할 때까지 이 속성은 식별될 수 없기 때문에 속성이 식별되면 공통 메시지로 갱신되어야
합니다.
공통 메시지 형식 및 데이터 아키텍처
일반적으로 서비스에서는 기본적인 데이터 모델에 대한 정보를 표시하지 않습니다. 오히려 이 서비스는 기본적인 데이터 모델을 캡슐화하는 데 사용되어야 하며 이 데이터 모델의 데이터 스토어는 서비스를 실현하는 서비스 컴포넌트에서
사용됩니다. 따라서, 보기, 편집, 삭제, 추가 검색 및 데이터베이스에 대한 기타 오퍼레이션이라는 서비스는 서비스의 후보로 적합하지
않지만 오늘날 사용되는 만큼 기본적인 컴포넌트 오퍼레이션으로는 사용될 수 있습니다.
개념적, 논리적 또는 실제 데이터 모델을 정의하는 기존 데이터
아키텍처는 공통 메시지 형식을 정의하는 데 필요한 소스입니다. 공통 메시지 형식의 정의는 데이터 아키텍처의 노력 및 데이터 모델과
동등해야 합니다. 이 분석에서는 새 서비스를 실현할 서비스 컴포넌트에 필요한 올바른 데이터 스토어 및 스키마의 가용성을 확인합니다.
새 데이터가 기본 시스템에 추가되어야 하는 경우, 기존 데이터 아키텍처가 향상되어 새 서비스를 포함합니다.
많은 엔터프라이즈에서는 기존 시스템이 종종 일괄처리를 통해 협업하는
사일로 및 데이터 아일랜드의 존재를 반영합니다. 서비스라는 수단을 통해 독립된 데이터 스토어에서 이주할 수 있습니다. 서비스 제공자의 데이터 소스 식별은 서비스 실현(realization) 중에 달성됩니다.
ISV 고려사항: 논리 데이터 모델은 사전 정의되고, ISV 패키지에 표현된 암시적인 데이터 모델을 수용해야 합니다. 따라서 패키지된 응용프로그램과 기존 데이터 모델 사이에 메시지 전송이 발생해야 합니다. 이러한 일은 ISV에서 제공된 API를 통해 이루어집니다.
SOA에서, 특히 ISV가 서비스를 통해 기본 데이터 및 기능성을 공개하지 않는 경우, 이 ISV 데이터 모델에 대한 어댑터가 중요합니다.
ISV 데이터 모델이 액세스 가능한 경우, 모델을 사용자 정의하여
식별된 서비스를 지원하는 데 필요한 메시지를 사용할 수 있습니다. 반대로 데이터 모델이 액세스 불가능한 경우, ISV에 포함된 데이터
모델에서 서비스 메시지 전달을 제한할 수 있습니다. 또한 문제점을 줄이기 위해 중개 메커니즘을 사용할 수도 있습니다. 이 컨텍스트에서 ESB에서 제공된 중개를 사용하여 ISV 패키지와 인터페이스로 접속할 수 있도록 지원할 수 있습니다. ISV 데이터 모델은 서비스를 구현하기 위해 위에서 필요한 추가 속성과 추가 속성 그 이상도 나타낼 수 있습니다.
모든 관련 서비스가 있는 공통 메시지 형식
공통
메시지 형식은 개별 서비스의 입력/출력 메시지로 조정해야 하므로 필요한 경우 해당 서비스가 이 형식을 사용 및 갱신할 수 있도록 지정됩니다. 서비스는 공통 엔터프라이즈 메시지 형식에서 정보를 추출하거나 결과를 예상해야 합니다. 이 형식은 서비스 공통 메시지 형식 템플리트에서 문서화됩니다.
|
도메인 모델 재사용
개념: 도메인 디자인 개념에서는 도메인 모델링의 개념에 대해 간단히 설명합니다. 도메인 모델링은 기술에 관계 없이 비즈니스 도메인의 핵심 개념을
나타내는 데 있어 분석 모델 또는 비즈니스 분석 모델 개념과 유사합니다. 도메인 데이터를 저장하는 데 사용되는 데이터베이스 스키마가 서비스 특정 기술인 것처럼, 서비스에서 사용하는 메시지는 기술과 관련이
있습니다(그렇지 않은 경우 웹 서비스에 사용되는 XML 스키마의 경우 기술 특정). 실제로 다음과 같은 관계를 고려할 수 있습니다.
이 다이어그램은 핵심 도메인 요소 발견에 사용되는 도메인 모델과 메시지 모델 간의 관계를 도메인 모델의 실현(realization)으로 나타냅니다. 이 때 한 세트의 요소가 서비스로 전달되고 서비스에서 리턴됩니다.
다음은 상태 변수 값을 가져오고 설정하기 위해 클래스 및 "액세서" 함수 포함과 인터페이스가 분리되는 일반 Java/컴포넌트 모델입니다. 이 모델은 매우 일반적인 접근 방식이지만, 이용자와 컴포넌트가 다른 주소
공간 또는 다른 시스템에 있는 경우 특정 컴포넌트의 전체 상태에 액세스하기 위한 각 호출의 통신 비용이 높다는 단점을 갖고 있습니다.
또 다른 문제는 컴포넌트 간 관계입니다. 하나의 계정이 한 세트의 고객을 갖는다는 개념은 이 스타일로 개발하기 어려우며 일반적으로 개별 오브젝트를 검색하는 데 사용되는 ID 목록을 관리하는 데서 끝납니다.
서비스 모델을 개발하는 경우, AccountMgr 서비스 및 MeetingMgr 서비스 스펙으로 연결되는 데이터 구동 서비스 식별 접근 방식을 사용할 수 있습니다. 첫 번째 서비스 스펙은 모든 계정 및 담당자를 관리하는 중앙 위치입니다.
실제로, 고객 관계 관리(CRM) 솔루션의 핵심 데이터 모델은 이 서비스와 다른 서비스를 사용하여 빌드되었습니다. 두 번째 서비스는 CRM 솔루션 및 다른 솔루션에서 회의를 예약하는 데 사용할 수 있어 분리되었으며
엔터프라이즈 그룹웨어 응용프로그램과 인터페이스합니다.
다음은 모델 샘플로서, 서비스 스펙을 보여줍니다. 해당 메시지는 위의 도메인 모델에서 가정할 수 있습니다.
|
메시지 교환 패턴 이해
메시지를 생각할 때 일반적으로 단순히 오퍼레이션 매개변수로 간주하는 경향이 있습니다. 이는 특히 서비스의 UML 표시가 매개변수와 오퍼레이션을 함께 사용하고 WSDL(Web Services Description
Language) 1.1이 유사한 접근 방식을 사용하기 때문입니다. 그러나 서비스 및 서비스 스펙의 관점에서 생각할 때, 메시지를 서비스 오퍼레이션이 사용/이용하거나 생성하는 재사용 가능한 요소로
인식하는 것이 보다 도움이 됩니다. 동일한 입력 및 출력 메시지를 사용할 수 있는 다른 교환과 구분되는 서비스에 대한 이름 지정된 교환이지만, 서비스 용어에서는 오퍼레이션이 단순한 메시지 교환을
의미합니다.
메시지 교환 패턴의 개념은 해당 스펙을 지원하는 표준을 개발하기 위한 서비스 사용 분석의 일부로서 웹 서비스 표준 분야의 관심 개념입니다. 메시지 교환 패턴에는 두 서비스 간(또는 서비스와 이용자
간)에 생성, 사용 또는 이용되는 메시지의 특정 조합 이름을 지정하며, 서비스 디자이너가 서비스 스펙에 대한 오퍼레이션을 설명하기 위한 공통 용어를 제공합니다.
다음 목록은 서비스 스펙 정의에서 사용할 수 있는 공통 교환 패턴의 목록입니다. 이러한 패턴은 일반적으로 서비스 협업 모델링에서 사용됩니다.
동기 요청/응답: 서비스 이용자가 서비스로 메시지를 송신한 후 서비스로부터 응답을 받을 때까지 대기를 차단하는 전통적인 메소드 호출에서 효과적입니다.
단방향 메시지: 이 경우, 이용자는 응답을 대기 또는 예상하지 않고 서비스로 메시지를 송신합니다. 이 패턴은 응답 유형이 없는 비동기 메소드 호출로 간주할 수 있습니다. 즉, 서비스 이용자가 서비스의
메시지 처리를 대기하지 않고, 메시지 송신 후 계속 실행합니다.
알림: 이 경우, 서비스는 이용자(일반적으로 다른 서비스)에게 다시 메시지를 송신해야 합니다. 이를 수행하려면 서비스가 알림 메시지를 송신할 대상을 알 수 있도록 이용자가 서비스에 등록해야 합니다.
비동기 요청/응답: 단방향 메시지 및 알림의 조합입니다. 서비스 이용자는 반송 주소를 포함하여 메시지를 송신합니다. 서비스 처리가 완료되면 다시 제안자를 호출합니다. 서비스 이용자가 첫 번째 메시지를
비동기식으로 송신하는 경우 송신된 모든 요청을 추적해야 서비스에서 수신된 응답을 원래 요청과 상관시킬 수 있습니다.
공개/등록: 이 역시 조합입니다. 서비스 이용자가 "주제"의 관심사항을 공개 서비스에 등록합니다. 다른 서비스 또는 서비스 이용자는 메시지와 연관된 주제를 식별하여 공개 서비스에 메시지를 공개하고
메시지를 송신합니다. 주제가 이전에 등록된 이용자와 일치하는 경우, 해당 이용자에게 새 메시지를 알립니다. 이러한 경우 참여하는 서비스를 매우 느슨하게 결합할 수 있습니다. 이용자 또는 공개자는 공개 서비스의
위치만 알면 되며 별다른 노력 없이 솔루션에 새 이용자를 추가할 수 있습니다.
|
메시지 세분성 관리
서비스는 세분화되지 않은 오퍼레이션을 제공합니다. 따라서 해당 오퍼레이션 간에 이동하는 메시지 또한 세분화되지 않습니다. 이 관심사항은 원래 HTTP를 전송 수단으로 사용하고 SOAP를 프로토콜로 사용하며 XML을
연결 형식으로 사용하여 상대적으로 느린 응답과 높은 대역폭 요구사항이 적용되는 웹 서비스 솔루션 배치 초기에서 강조되었습니다. 예를 들어, 서비스로부터의 주식 시세 요청을 고려합니다. 초기 웹 서비스에서는 간단한
주식 시세를 자주 시연했습니다. 주권 기호(ticker symbol)는 네 자리 문자이며 응답은 10진수입니다. RPC 스타일의 2진 프로토콜의 경우, 메시지 ID로 오버헤드가 추가될 수 있습니다. 예를 들어
8바이트인 경우에는 요청과 응답에 각각 8+4, 8+8(고정밀도 10진수)의 영역을 예상할 수 있습니다. HTTP/SOAP의 경우 다음과 같은 양식을 예상할 수 있습니다.
요청
|
응답
|
SOAPAction: "http://www.webservicex.net/Quote"
User-Agent: MyAgent 1.0
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://www.webservicex.net/">
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<tns:Quote>
<tns:Symbol>IBM</tns:Symbol>
</tns:Quote>
</soap:Body>
</soap:Envelope>
|
HTTP/1.1 200 OK
X-Powered-By: ASP.NET
Connection: close
Content-Length: 522
X-AspNet-Version: 1.1.4322
Date: Mon, 21 Mar 2005 00:34:21 GMT
Content-Type : text/xml; charset=utf-8
Server : Microsoft-IIS/6.0Cache-Control: private, max-age=0
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<QuoteResponse xmlns="http://www.webservicex.net/">
<Quote><Last>89.28</Last>
</Quote>
</QuoteResponse>
</soap:Body>
</soap:Envelope>
|
웹 서비스 기술의 얼리어댑터(early adopter)는 두 가지 결론을 얻었습니다. 먼저, 전통적인 컴포넌트 모델의 복잡한 스타일보다는 문서와 같은 데이터를 제공하는 소수 오퍼레이션에 맞게 서비스가
최적화되었습니다. 이는 실제 데이터 부하가 큰 경우 프로토콜 오버헤드를 분산시키는 이점이 있습니다. 또한 엔터프라이즈 서비스 간(최소한 동일한 솔루션의 서비스 간)에 보다 단순한 소규모 프로토콜 바인딩을
선택했으며, 예를 들어, 엔터프라이즈 외부 서비스에 대한 인터페이스와 같이 필요한 경우에 대비하여 HTTP/SOAP가 예약되었습니다.
이 개념은 전혀 새로운 개념은 아닙니다. 컴포넌트 환경에서도 가치 오브젝트 패턴 또는 J2EE Service Facade 모두 클라이언트와 서버 간 통신 라운드 트립 수를 줄일 수 있는 접근 방식입니다. 두 가지
방식 모두 전통적인 액세서 함수를 사용하지 않고 컴포넌트 상태의 전체 사본을 클라이언트로 송신하는 개념을 사용합니다. 서비스의 경우, 비즈니스 모델, 특히 비즈니스 프로세스 모델에 보다 적합한 서비스를 개발하는
것으로 고려합니다. 이처럼, 전자 데이터 교환(EDI) 트랜잭션 세트가 주문, 송장, 출하 지시서 등과 같은 비즈니스 문서를 나타내는 방식과 동일한 방식으로 메시지에 공통 비즈니스 문서가 반영됩니다.
|
메시지 교환 성능 관리
일반적으로 긴 메시지는 통신 성능을 극복하는 데 유용하지만 경우에 따라 긴 데이터 메시지가 문제점이 될 수도 있습니다. 예를 들어 위의 SOAP 메시지의 경우, HTTP, SOAP 및 XML을 사용하여 메시지
크기가 데이터 크기를 현저히 증가시켰습니다. 이는 웹 서비스 기술을 사용하여 빌드된 초기 시스템의 불만사항이기도 합니다. 반대로, 이러한 문제를 통해 성능을 코드 성능, 메시지 디자인 및 프로토콜 선택사항의
관점에서 초기 디자인 활동으로 고려하는 등 흥미로운 교훈을 얻을 수 있었습니다.
한 가지 고려해야 할 중요 측면은 서비스에서 이용자로 또는 서비스에서 서비스로 대용량 상태를 이동하는 경우 이러한 메시지가 실제로 서비스 상태의 변경사항이 반영되지 않은 스냅샷을 나타낸다는 점입니다. 따라서
데이터를 신뢰할 수 있는 시간을 식별하여 이 "실효성(staleness)"을 명시적으로 관리하거나 일정 시간이 지난 후 만기되도록 이용자에게 "임대차"하는 방법을 고려할 수 있습니다. 자세한 정보는 백서,
서비스 지향 아키텍처(SOA) 및 컴포넌트 기반 개발을 사용하여 웹 서비스 응용프로그램 빌드를 참조하십시오.
고려해야 할 또 다른 주제는 컨텐츠 캐싱입니다. 캐싱은 일반적으로 응용프로그램의 성능 최적화와 관련된 문제이지만, 서비스 지향 솔루션의 경우 분산 특성 및 메시지 기반 통신으로 인해 이용자와 서비스 간에 캐시를
삽입해야 합니다. 이러한 캐시는 조회 최적화를 위해 사용되는 일반 데이터베이스 캐시는 아니며 웹 서비스 및 웹 프록시에서 사용되는 캐시와 유사합니다. 실제로, HTTP 및 SOAP를 사용하는 웹 서비스의 경우,
이러한 프록시를 캐시로 사용하여 특정 상황에서 서비스 응답을 지원할 수 있습니다.
그러나 캐시 사용과 관련된 실제 문제는 캐시가 캐시 컨텐츠를 지원하는 데 사용되는 정책을 이해하는 방식과 서비스로 캐시를 무효화할 수 있는 방법입니다. 배치된 서비스를 호스팅하고 관리하는 데 사용되는 기술 하부
구조는 캐싱 기능을 제공해야 합니다. 향후 기대할 수 있는 서비스 정책의 한 영역은 캐시 관리 정보의 제공입니다.
|
|
자세한 정보
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|