Bill Gibson, 프로그램 관리자
Microsoft Corporation

적용 대상 :
  Microsoft Visual Studio 2005 Team System

서비스 지향 아키텍처 (SOA)란, 느슨한 분산 시스템을 개발하기 위한 아키텍처 모델로 최근 화제에 오르는 것이 많아졌습니다. SOA의 정확한 정의에 대해는 현재에도 논의 되었지만, 기본적으로는 메시지를 사용하고 통신을 실시하는 상호 운용 가능한 서비스에 근거하는 아키텍처 패턴이 일반적인 해석입니다. 그럼, 서비스와는 구체적으로는 무엇일까요. SOA의 다음 4 가지 기본 원리가 큰 화제가 되었는데, 이 기본 원리에서 서비스의 특성이 정의됩니다.

1. 경계가 명확하다.

2. 자율적이다.

3. 클래스 대신, 스키마와 계약을 공유한다.

4. 호환성이 정책에 근거한다.

이것들은 바람직한 특성이지만, 단지 HTTP/SOAP 를 사용을 선택하거나 ASMX 프로그래밍모델을 사용하여  응용 프로그램을 구현하는 것 만으로는 이러한 특성은 구현 할 수 없습니다. 서비스 지향과는  한개의 "아키텍처 패턴" 으로 서비스는 그 패턴에 포함되는 1 개의 "추상개념" 입니다. 서비스는 신중하게 디자인해야 합니다. 여기에서는 "서비스" 라는 용어를 기본적으로는 이 아키텍처 패턴이나 구현을 말하기 위해서 사용합니다.

이 백서의 목적은 4 개의 기본 원리에 대해의 견해를 보여주는 것이 아닙니다. 여기에서는 서비스가 시스템 정의 모델 (SDM)에서 정의되는 특수한 (응용 프로그램 ) 시스템인 것을 보여줍니다. 또, 시스템 디자이너를 사용하여  서비스를 디자인 및 구성하여, 대규모로 서비스 지향 시스템을 작성하는 방법을 보여줍니다. 시스템을 사용하여  서비스를 표현하여 서비스의 경계를 분명히 할 수 있는 것을 보여줍니다. 그 결과, 서비스와 다른 서비스와의 의존관계(dependencies)가 명확하게 되어, 디자인에서 구현 되는 자율성의 정도를 계측 및 조정할 수 있습니다.

여기서 말하는 제안은 4 개의 기본 원리라는 측면에서도 생각할 수 있습니다.

경계가 명확하다

4 개의 기본 원리의 첫번째로서 서비스의 경계를 넘어 행해지는 통신을 명확하게 특정해야 합니다. 서비스의 공개 영역은 명시적인 계약에 의해서 충분히 인식 및 정의해야 합니다. 계약의 디자인에서는 계약을 적절한 요소로 분해하여, 서비스 소비자를 서비스 구현의 상세에서 분리하도록, 세심의 주위를 기울여야 합니다.. 다만, 명확한 경계를 정의할 때는 서비스의 내부에 포함하는 내용과 외부에 두는 내용을 고려하는 것도 중요합니다. 서비스의 상호작용이나, 서비스의 리소스에의 액세스에 어떠한 백 도어도 이용할 수 없는 것이 이상입니다.

대부분의 웹 서비스 프로그래밍모델에는 웹 서비스 관련의 특성으로 주석을 붙일 수 있었던 클래스 등, 명시적인 서비스의 구현의 구축이 있습니다. 그러나, 서비스의 것보다 추상적인 개념을 생각할 수 있는 복수의 서비스클래스 구성으로서 논리적으로 판단하는 방법 또는 서비스에 꼭 필요한 다른 구현의 요소나 리소스를 고려하는 방법은 준비되어 있지 않습니다. 프로그래밍모델에서는 사실상, 경계의 단편을 정의할 수 있습니다. 그러나, 이러한 단편을 완전한 서비스정의에 조립하는 작업은 사용자 자신이 실시하게 됩니다.

여기서, SDM  시스템의 개념을 생각하고 도움이 될지를 보고 가기로 합시다. 시스템이란, 복수의 리소스에서 "구성" 되는 것입니다. 또, 시스템은 시스템의 멤버의 동작을 끝점(endpoint) 경유로 다른 시스템에 개별적으로 공개할 수 있습니다. 시스템을 사용하고 서비스를 나타내면, 시스템의 경계가 서비스의 경계가 되기 위해, 경계내에 배포되는 응용 프로그램이나 하부구조를 명시적으로 포함할 수 있습니다. 시스템, 즉 서비스에 의해서 공개되는 끝점(endpoint)를 정확하게 지정할 수도 있습니다. 시스템을 사용하면 서비스를 보다 추상적으로 생각하기 쉬워지므로 서비스를 구현 하는 하위수준프로그래밍 구조에 의해서, 아키텍처 엔터티의 혼란을 막을 수 있습니다. 시스템을 사용하면, 시간의 경과와 함께 새로운 멤버를 시스템에 추가하고, 새로운 끝점(endpoint)를 공개하여 서비스 정의를 간단하게 확장할 수 있습니다. 예를 들어, asmx 기술을 사용하여 최초의 버전의 서비스를 배포한 후Windows Communication Platform (WCF) 를 사용하여, 그 서비스를 확장할 수 있습니다.

시스템 디자이너를 사용하고, 아키텍처 전체를 시스템이나 클라이언트 응용 프로그램에서 조립하여 디자인하는 경우, 시스템에 의해서 제공되는 캡슐화가 적용됩니다. 시스템 디자이너와 SDM 모델에서는 시스템 사이의 모든 통신이 공개된 끝점(endpoint)만을 사용하여  정의해야 합니다.

또한 시스템 디자이너에서는 서비스를 상향식방식 뿐만이 아니고 탑다운 방식에서도 디자인할 수 있습니다. 탑다운 방식으로 디자인하는 경우, 구현 디자인의 구체적인 부분에 임하기 전에 서비스에서 공개하는 동작을 생각할 수 있습니다.

자율적이다

두 번째의 기본 원리는 서비스는 개별적으로 배포 및 관리해야 한다고 말하는 전제에 근거합니다. 일단 서비스를 배포하면, 이러한 서비스를 사용하는 사용자를 가정 할 수 없기 때문에 장기에 걸쳐 사용된다고 가정하여 디자인하여, 환경의 변화에 곧바로 대응할 수 있도록 해야 합니다. 즉, 서비스의 구현은 시간 경과와 함께 변화할 가능성이 있기때문에, 다른 서비스의 구현의 상세에 의존해선 안 되는 것을 의미합니다.

시스템을 사용하여  서비스를 디자인하여, 서비스가 제공하는 응용 프로그램을 다른 서로 의존하는 응용 프로그램이나 시스템과 함께 구성하여, 자율성을 최대한으로 높일 수 있습니다. 또, 이러한 디자인에 의해, 다른 서비스와의 의존관계(dependencies)가 밝혀져, 서비스의 명시적인 소비자 끝점(endpoint)로서 나타납니다.. 각각의 의존관계(dependencies)를 조사해 적절하면, 참조할 응용 프로그램이나 시스템을 서비스의 경계내에 포함할 수 있습니다.