IT 종합뉴스서비스

[지디넷코리아]이제 소프트웨어 아키텍처를 선택할 때 C 언어와 같은 초기 단계 프로그래밍부터 C++/자바와 같은 객체 지향 프로그래밍, J2EE 플랫폼의 컴포넌트 지향 프로그래밍, 그리고 서비스 지향 프로그래밍까지 이 모든 방법론 중 어느 것에도 기초를 둘 수 있게 됐다. 물론 각 개발 단계로 나아갈수록 시스템 개발, 통합의 복합성 수준은 점차 증대되며 시스템 설계자는 각 프로젝트에 아키텍처를 정착시키는 작업을 필수적으로 수행해야 한다.

이 중에서 서비스 지향 아키텍처(SOA) 프로그래밍 패러다임은 모든 내/외부 프로젝트에 대해 SOA와 관련해 시스템을 통합해야 하는 서비스와 기업에 기반을 두고 있다. 그리고 SOA에서 ‘서비스’란 용어는 각 기기를 네트워크 환경에서 플러그앤플레이(plug and play) 동작을 가능하게 하는데 대한 참고 사항으로 가장 많이 사용되고 있다.

현재 참조할 수 있는 SOA 실행 사례는 지니(JINI), 코바(CORBA), 자바 RMI 기법, ebXML, 그리고 가장 최신 솔루션인 웹서비스 등으로 이뤄져 있다.

SOA 웹서비스의 실행
웹서비스는 XML로 정의되는 단일 자원 식별기(URI)와 서비스 협약에 의해서만 식별되며 서비스 협약은 공적 인터페이스와 서비스 결합체 등으로 구성된다. 웹서비스의 사용처는 소프트웨어 시스템으로 SOAP 메시지로 규격화된 XML 기반 메시지를 사용해 의사소통을 하게 된다.

일반적으로 클라이언트는 필요 사항을 가장 적합하게 구현한 웹서비스를 필요로 한다. 이런 클라이언트는 서비스 레지스트리와 같은 공적/사적 서비스 디렉토리를 검색함으로써 이와 같은 탐색 작업을 수행한다.

그림 A는 지금까지 설명한 상호작용의 다이어그램을 보여주고 있다. 각 단계는 아래에 목록으로 정리돼 있다.

그림 A : SOA 환경의 상호작용

서비스 공급자는 서비스 디렉토리에 서비스를 등록한다.
서비스 디렉토리는 서비스 협약의 위치를 파악한다.
클라이언트 또는 서비스 사용자는 서비스 디렉토리를 질의함으로써 자신에게 필요한 서비스를 위치시킨다.
서비스 디렉토리 컴포넌트는 서비스를 어떻게 결합할 것인가, 서비스 협약, 그리고 클라이언트에 의해 요청받은 서비스에 관해 보다 자세한 사항과 같은 정보를 알려준다.
클라이언트는 서비스 제공자와 결합해 요구 사항들을 차례로 만족시켜 나간다.

자바 웹서비스에서 서비스 디렉토리 패턴에 대한 면밀한 검토
서비스 디렉토리는 SOA의 필수불가결한 요소 중 하나다. 위의 그림 A는 서비스 사용자와 서비스 제공자가 모두 서비스 디렉토리에 접근할 필요가 있음을 잘 보여주고 있다.

서비스 제공자는 서비스를 서비스 디렉토리에 출판하는 반면 사용자는 런타임의 특정 요소에 기인한 특정 서비스를 배치할 수도 있다. 이러한 런타임 작업을 통해 서비스 디렉토리를 보다 강력한 SOA 요소로 만들 수 있다.

서비스 사용자는 레지스트리에 서비스를 배치하기 전까지는 그 서비스의 위치를 알 수 없다. 서비스 사용자들이 런타임에서 서비스를 발견하고 연결하기 때문에, 서비스 그 자체는 클라이언트가 알아차리지 못하는 순간에 이곳에서 저곳으로 옮겨질 수도 있다.

바로 자바 웹서비스가 고전적인 SOA 실행 사례다. 웹서비스는 서비스 디렉토리를 실행하기 위해 UDDI 규격을 사용한다.

서비스 디렉토리 패턴의 특징
서비스 디렉토리 패턴은 SOA의 고유 특징 중 하나인 ‘투명한 기억 위치 선정’이라는 관점을 존중하고 있다. 패턴은 사용할 수 있는 서비스의 연감이라고 할 수 있는 메인 컴포넌트 주변을 선회하고 있다.

비록 서비스 디렉토리가 SOA 시스템에서 다양한 방법으로 실행되긴 하지만, 서비스 디렉토리를 웹서비스 그 자체로 실행하는 방법은 많은 공감을 얻어낼 수 있다.

서비스 디렉토리 패턴은 인터페이스에서 실행을 분리한다는, 객체 지향 체계의 설계 원칙을 기반으로 작성된다.

그림 B를 통해 서비스 디렉토리 패턴과, 패턴의 각기 다른 부분들의 조합에 관해 이해할 수 있을 것이다.

그림 B : 각기 다른 서비스 디렉토리 패턴 사이의 조합

그림 B는 서비스 제공자가 서비스의 이용 가능성을 등재하거나, 이용할 수 있는 서비스 목록을 활용해 이미 등록된 서비스를 업데이트하거나 삭제할 수 있다는 것을 잘 보여주고 있다.

클라이언트는 특정 서비스를 위치시키거나 또는 미래에 활용할 수 있도록 등록할 수도 있다. 이러한 주요 컴포넌트와 어댑터(어댑터 설계 패턴)는 서비스 디렉토리 내에 존재한다.

UDDI의 구조
UDDI는 공인된 사용자를 대상으로 한 사적 UDDI 레지스트리나 모든 인터넷상의 접속에 대한 공적인 UDDI 레지스트리 형태로 존재할 수 있다.

UDDI는 4개의 데이터 구조로 이뤄진다.

비즈니스 구조 - 이 부분은 비즈니스 옐로우 페이지 정보를 다룬다. 서비스 제공자에 대한 묘사가 이뤄진다.
비즈니스 서비스 구조 - 이 부분은 비즈니스 구조 부분에서 서비스 제공자가 출판하는 서비스를 표현한다.
결합 템플릿 구조 - 이 부분은 특정 서비스 측면을 묘사하는 결합 템플릿이다. 전체적으로 볼 때 특정 서비스의 모든
t모델 구조 - 기술적 모델인 ‘t모델’은 서비스 정의에 활용된다.

일반 회사들은 아파치 액시즈와 같은, 소프트웨어 업체들의 패키지를 활용해 자체 개발인력들이 만들어낸 독자적인 UDDI 레지스트리를 설정하거나 운영할 수 있다. 공적 UDDI 레지스트리는 IBM, MS, 시스티넷(Systinet), x메쏘드즈(xMethods)와 같은 소프트웨어 회사들이 제공하고 있다.

디렉토리 액세스의 핵심 - 웹서비스에서의 UDDI
웹서비스는 B2B 시스템, 포탈, 엔터프라이즈 애플리케이션, BPM 시스템, 워크플로 프로세스, 그리고 기타 BI 시스템 등을 통합할 수 있다.

클라이언트 접근의 핵심 포인트는 UDDI와 같은 특정 실행 도구를 통해야 한다는 것이다. UDDI는 비록 SOA에서 선택사항이긴 하지만 웹서비스에서 채택할 수 있는 가장 보편적인 디렉토리 방법론이다.

서비스 디렉토리 패턴 및 이들의 UDDI에 대한 관계를 철저히 이해하는 것은 웹서비스의 적절한 실행에 꼭 필요한 작업이다. @