Brian Schaffner (ZDNet Korea)
이전 글에서 각 비즈니스 프로세스에 적합한 서비스 지향 아키텍처(SOA)를 구축하는 방법에 대해 논의한 바 있다. 이번 글에서는 SOA 아키텍처를 보다 세심하게 살펴보고 컴포넌트를 실행하는 방법에 대해 알아보자.
아울러 웹서비스 기술을 이용해 서비스 에이전시, 서비스 제공자, 그리고 서비스 요청자 등을 실행하기 위한 설계를 구축하는 방법 등에 대해 설명하도록 하겠다.
웹 기술로 서비스 실행하기
웹 기술은 상당히 풍부한 수준으로 서비스 실행 도구를 제공할 만큼 성숙해 왔다. 웹서비스 기술은 대체로 다른 기술을 기반으로 구축되며 특히 XML과 HTTP에 근거를 두고 있다.
각 서비스들은 흔히 현존하는 애플리케이션을 포장한 형태로 제공되고 있다. 그림 A는 다양한 웹서비스 컴포넌트와 이들이 하나의 서비스 아키텍처를 수행하기 위해 어떻게 공조를 이루는지 그 연관 관계에 대해 설명하고 있다.
 |
| 그림 A : SOA의 웹서비스 구현 |
위 그림에서 UDDI가 서비스 발견 에이전시를 제공하며 웹·애플리케이션 서버는 서비스 제공자를 전달하고 애플리케이션은 서비스 제공자의 역할을 하는 것을 발견할 수 있다. 이런 모습이 바로 SOA 모델의 충족 요건이 된다.
서비스 제공자에서 애플리케이션 기능성 요약하기
웹 서비스는 하나 또는 그 이상의 애플리케이션 전반에 걸쳐 실행된다는 기능성을 갖춘 서비스의 ‘포장’을 반드시 제공해야 한다. 일부 웹서비스는 아마 다른 웹서비스들이 다중 애플리케이션에 대한 통합 인터페이스를 제공하는 반면에 단일 애플리케이션을 대상으로 한 기능성을 제공하고 있는지도 모른다.
애플리케이션을 서비스 측면에서 면밀히 계획해 보면 애플리케이션과 기술이 비즈니스 프로세스에 적합한지 살펴볼 수 있다. 그림 B는 애플리케이션의 기능성이 서비스 실행으로 면밀하게 계획되는 방법에 대한 사례를 보여준다.
 |
| 그림 B : 애플리케이션 기능성이 서비스에 매핑되는 예 |
EJB와 같은 컴포넌트 아키텍처는 애플리케이션 서버 환경에서 수행될 수 있는 서비스를 요약해 보여준다.
웹 서버는 서비스 접근에 대해 HTTP 네트워크 전송 방법을 제시하며 애플리케이션 서버는 SOAP 인터페이스와 서비스를 구성하는 객체 컴포넌트를 주관한다. 객체 컴포넌트는 애플리케이션들에 대해 비즈니스 서비스 계층을 제공한다.
결과적으로 웹서비스는 기초적인 애플리케이션들에서 풍부하게 정의된 서비스들을 이끌어 낸다. 이러한 서비스는 이후 개념 정의가 잘 된 비즈니스 프로세스로 연결된다.
애플리케이션 전반에 걸친 개념적 계층을 구성하면 각 애플리케이션의 기능성을 비즈니스 서비스로 정의된, 보다 의미 있는 방법으로 전달할 수 있다.
WDSL 환경의 서비스 규약 정의
서비스 제공자는 WSDL 문서 형태로 해당 인터페이스 규약을 출판한다. WSDL 문서는 서비스 위치 지정, 그리고 해당 서비스에 대한 접근 방법까지 포함하는 서비스의 특징을 정의한다. 개발적 관점에서 볼 때 WSDL은 서비스 요청자와 서비스 공급자가 모두 동의하는 규약을 제공한다.
일단 비즈니스 프로세스를 정의하고 해당 프로세스를 실행할 서비스를 조직하고 나면 그 다음 단계는 서비스와 서비스 내부의 특정 방법론을 결정하는 것이다.
WSDL은 세부 서비스의 XML 포맷이다. WSDL 문서 내에서 서비스 접근법, 가능한 방법에 대한 판단, 방법에 대한 접근, 방법까지 나아가는 동안 거쳐야 하는 매개변수, 기타 여러 요소에 대한 세부 작업을 수행할 수 있다.
서비스 요청자들은 서비스 레지스트리를 이용해 서비스를 위치시킨다. 웹서비스의 실행에서 서비스 레지스트리는 UDDI를 이용해 실행된다. UDDI 서버는 서비스 내역에 대한 데이터베이스를 갖고 있으며 이들을 서비스 요청 애플리케이션에 제공한다.
서비스 요청자는 웹서비스와의 인터페이스 규약을 납득하기 위해 WSDL 문서를 활용한다.
일반적으로 WSDL 문서는 물리적으로 UDDI 서버에 저장되는 것은 아니다. 오히려 UDDI 서버는 서비스 요청자에게 WSDL 문서를 어디서 발견할 수 있는지 위치를 확인할 수 있는 URL들을 제공한다.
프로그래머의 측면에서 WSDL 문서는 서비스에 접속하기 위해 사용하는 개념 인터페이스를 정의한다. 설계 측면에서 WSDL은 서비스 요청자와 제공자 사이의 규약을 규정하기 때문에 반드시 이 2가지 앞에 위치해야 한다.
일단 WSDL이 설계돼 합의되면 서비스 제공자의 개발자와 서비스 요청자의 개발자는 다소 평행적으로 작업하게 된다.
서비스 발견
서비스는 UDDI 서버에 질의하고 관련된 WSDL 문서에 접근함으로써 발견된다. 중심 레지스트리를 사용함으로써 클라이언트 애플리케이션은 역동적으로 서비스를 발견하고 이에 결합될 수 있다.
UDDI 서버 및 프로토콜은 상당히 포괄적이다. 하나의 서비스 아키텍처로서 UDDI 컴포넌트는 자신의 도메인 내에 위치한 모든 서비스에 대해 잘 알고 있는 중앙 에이전시 역할을 수행한다. 언제든 서비스 요청자가 서비스에 접근하거나 서비스를 위치시켜야 할 때마다 UDDI 서버는 정보 요청을 받는다.
UDDI는 레지스트리를 검색하는데 있어 다양한 방법을 제공한다. 일단 하나의 조직과 서비스가 위치되고 나면 서비스 요청자는 WSDL 위치를 요약한다.
WSDL 은 대개 서비스 그 자체와 함께 위치한다. 그 다음 서비스 요청자는 서비스의 세부 사항을 알기 위해 WSDL 문서에 접근한다. WSDL 문서 내의 정보를 활용해 서비스 요청자는 서비스에 접근하는 방법, 그리고 어떤 방법론이 있는지, 어떤 매개변수가 보내져야만 하는지 등을 다른 것보다 먼저 이해하게 된다.
그림 C는 이러한 프로세스가 작동하는 것을 묘사한 것이다.
 |
| 그림 C : 서비스 요청자로부터 WSDL에 접근하기 |
향후 과제
SOA를 구현하는 것은 정말 하나의 도전과도 같다. 구현을 통해 SOA를 구성하는 컴포넌트와 웹서비스 이면의 기술들을 이해함으로써 풍부한 전략적 솔루션을 제공함과 동시에 각 비즈니스의 필요 부분과 도전과제 등을 충족시키는 실속있는 아키텍처를 만들어 낼 수 있을 것이다.
