[지디넷코리아]고객들의 닷넷 플랫폼 기반의 새로운 시스템 아키텍처를 볼 때마다, 필자는 그들 대부분이 전통적인 2티어, 혹은 3티어 방식에 따라 애플리케이션을 개발해 왔음을 알 수 있었다.

하지만 정작 이들 중 어떤 시스템 요소들이 향후 그들이 착수하게 될 미래의 프로젝트에 재활용되는 것은 얼마나 될까? 아마도 몇 개 데이터 테이블이나 저장된 절차 정도일 것이다. 개발한 컴포넌트 인터페이스의 대부분이 특정 시스템의 사업적인 요구사항에 종속적이기 때문이다. 개발자들은 해당 솔루션의 성능을 크게 손상하지 않고도 충분히 이런 필요사항을 충족시킬 수 있는 방법에 있음을 모르고 있었다.

그러나 서비스에 필요한 컴포넌트 대신 애플리케이션이 제공하는 서비스 측면에서 애플리케이션을 새롭게 바라보면, 서비스 지향 아키텍처(SOA)의 장점이 분명해 진다.

SOA를 이용하면 아키텍트는 단일 엔티티 안에 특정 업무를 묶어서 제공하는 캡슐화가 가능하다. 이를 통해 서비스 요청을 수락하고, 요청에 따른 결과나 잘못된 시도에 따른 오류 등을 산출한다. 이처럼 서비스의 조합과, 각 서비스들을 어떻게 결합해 애플리케이션을 구성할 것인가에 대한 고민의 결과물이 바로 SOA다.

SOA 아키텍처와 컴포넌트 기반 아키텍처 사이의 차이가 무엇인지 알기 위해서는 실제 사례를 살펴보는 방법이 가장 효과적이다. 컴포넌트 기반의 아키텍처에서는, 각 컴포넌트들이 특정 영역이나 아키텍처 위에서 동작하는 비즈니스 규칙들을 담고 있다.

SOA는 무엇인가
예를 들어 컴포넌트 아키텍처 기반의 송장(Invoice) 시스템은 고객 컴포넌트, 송장 컴포넌트, 그리고 제품 컴포넌트 등으로 구성된다. 개발자는 이러한 컴포넌트들을 고객, 송장, 그리고 제품 등의 주요 영역에 맞춰 프로그래밍하며, 각 영역에서 바람직한 동작이 어떤 것인지 기술한다. 이 때 'AddCustomer(…)' 구문은 고객 한 명을 추가하도록 허용하며, 'InvoiceTotal(1001)' 구문은 '인보이스 1001'에 대한 총계를 나타낸다.

개별 컴포넌트의 임플리멘테이션(implementation)은 특정 기능의 수행 방법을 감추기 때문에, 예를 들어 송장 컴포넌트 사용자는 InvoiceHeader 테이블에 TotalInvoice 행이 있는지 여부와, 송장 컴포넌트가 InvoiceLineItems 테이블에서 인보이스 총계를 산출하기 위해 개별 영역을 계속 반복해야 하는지 등의 여부를 알지 못한다.

또한 컴포넌트 기반 시스템에선 특정 종류의 비즈니스 엔티티를 이용해 시스템 전반에 걸쳐 데이터를 교류하거나 각 컴포넌트를 상호 요청하는 다중 컴포넌트 레이어가 존재한다. 컴포넌트 기반 시스템은 독점적으로 관리될 수 있는 백엔드 소스로부터 공유 데이터에 접근한다.

반면 SOA에선 이러한 기능들이 영역이나 컴포넌트 레이어 단위로 분할되지 않는다. 따라서 우리는 각 영역 전반에 걸쳐 작업 관리에 필요한 모든 종류의 서비스를 실행하기 위해 필수적인 요소들을 규명하는 것에 초점을 맞춘다.

예를 들어 고객 서비스 분야는 고객 정보를 검토하거나 조작해야 할 모든 시스템의 요청에 응답할 수 있어야 한다. 고객 서비스는 고객을 추가하거나 고객 신용 정보의 검토, 고객이 지불하지 않은 송장 등을 가려내는 작업을 처리한다. 통합 고객서비스를 제공하기 위해 자신이 관리하는 고객에 직접 관련된 모든 종류의 데이터를 보관하고 요청 집단의 측면에서 기타 서비스 문의들을 작성한다.

사용자 인터페이스 프로그램은 아직 지불되지 않은 송장 중에서 주요한 것들을 가려내 고객 서비스 부분에 이에 대한 서비스 요청을 보내는 역할을 담당하며, 송장 서비스를 통해 지불되지 않은 송장 정보를 획득한다. 그러나 사용자가 직접 송장 서비스를 요청할 필요는 없다. 왜냐하면 인증된 사용자의 요청이 송장 서비스 부분에 자동 연결돼, 사용자가 원하는 정보를 얻을 수 있기 때문이다.

닷넷을 이용한 SOA 적용방법
초기 SOA 아키텍처 실행안 중 거의 대부분은 이전 컴포넌트 기반 대체물과 큰 차이가 없다. 많은 개발자들은 신용 검증이나 문서 팩스 서비스 등의 특수 서비스를 분리하는 것이 얼마나 유용한지를 잘 알고 있다.

이러한 특수 서비스의 실행은 기본적으로 UI가 없는 애플리케이션이다. 예를 들어 팩스 서비스는 단지 문서와 수신자 리스트만 필요할 뿐이다. 요청 프로그램 입장에서 보면 이 솔루션이 비즈니스 룰을 기반으로 어떻게 메시지를 전달하고 송신을 확인하며 데이터를 저장하는 지는 그리 중요한 사항이 아니다. 단지 수신자 리스트에 있는 모든 팩스 메시지가 제대로 전달됐는지를 검증하기 위한 방법만 필요할 뿐이다.

하지만 이런 간단한 서비스도 결합도가 매우 높다. 이 서비스를 이용하려면 문서 및 수신자 리스트가 서비스에 적합한 양식으로 정리돼야 하며, 요청 프로그램에선 메시지 확인 정보가 상태 변수를 통해 회신돼야 한다.

따라서 SOA의 이용 효과를 극대화하기 위해서는 결속도가 느슨한 메시지 기반 아키텍처를 활용해 서비스가 실행돼야 한다. 예를 들어 문서 및 수신자 리스트는 요청 수준 인터페이스를 통해 애플리케이션에 바로 전달되는 것이 아니다. 대신 XML 도식과 이에 상응하는 XML 도큐멘트를 통해 정의되며, 외부 송신 팩스 메시지의 대기열에 위치한다.

이후 메시지는 싱글 팩스 송신 윈도우 서비스가 담당한다. 이 워크플로 서비스는 대기열의 메시지를 분석해 일련의 웹 서비스 영역으로 전달하고, 다시 여기서 전달, 송신, 검증 등과 같은 필수적인 작업들을 수행된다. 이 모든 작업이 완료되면 워크플로 서비스에 다시 응답과정을 거치게 된다.

그리고 이 모든 절차가 완성되면 팩스 전달 서비스 솔루션은 해당 메시지를 완성/ 미완성 대기열에 위치시켜 요청 상태를 표시한다. 요청 프로그램이나 이에 상응하는 대체 솔루션들은 작업을 마치는데 필요한 동작을 위해 대기열을 검증한다.

이러한 실행 과정을 잘 살펴보면, 일반 시스템의 고객 요청 처리와 비슷한 부분이 있다. 이러한 유형의 실행 방안이 매력적인 이유는 현존 인터페이스의 실행에 아무런 변화를 주지 않고도 새로운 메시지를 신속하게 추가할 수 있다는 점이다.

이러한 아키텍처는 이미 이 종류의 서비스를 제공하는 현존 시스템의 처리 능력을 상승시키는 방법으로 재활용하거나, 대기열에 특정 메시지가 나타날 때 이를 처리할 수 있는 시스템을 추가하는 방법으로 응용이 가능하므로 작업 범위가 매우 탄력적이라 할 수 있다.

또한 메시지 대기 인터페이스를 웹 서비스 아키텍처에 위치시키면, 시스템이나 작업 과정의 종류를 막론하고 어디에서든지 서비스 아키텍처에 대한 호출, 메시지의 제출 및 재생이 가능하다. 전통적인 컴포넌트 아키텍처의 등록, 재편집, 그리고 인터페이스 내의 제한 사항 중 상당수를 감소시키는 부가적인 레이어도 제공한다.

SOA의 개념과 메시지 기반 아키텍처 실행 방안 등은 향후 몇 년 동안 지속적으로 성장하고 개발될, 상대적으로 새로운 분야다. 새로운 시스템 모두에 이러한 아키텍처를 적용할 기업이 많지는 않을 것이다. 하지만 현재의 특정 서비스들이나 영역 기반 서비스 분야에서의 초기 작업들에 있어서 이 아키텍처를 사용하는 것이 매우 중요한 혜택들을 가져다 줄 것이다. @