모호한 영역: 객체, 컴포넌트 그리고 웹 서비스

최근 Object와 Component와 Web Service와의 명확한 차이에 대한 궁금증이 생겼습니다. 이에 관한 자료를 찾다가 Fuzzy Boundaries: Objects, Components, and Web Services 라는 글을 찾았습니다.

제법 명확하게 정리한것 같아서 같이 공유하고자 글을 올립니다. 혹시 번역상의 문제점 등이 있다면 언제든지 알려주시길 부탁드립니다.


모호한 영역: 객체, 컴포넌트 그리고 웹 서비스
Fuzzy Boundaries: Objects, Components, and Web Services
by Roger Sessions, Objectwatch

컴포넌트들과 웹 서비스들안에서 객체를 변형시키기는 쉽지만 어떻게 올바르게 할 것인가?

말하는 강아지들

만약 당신이 객제지향프로그래머라면 당신은 친숙한 프로그래밍 언어(C#과 같은, 중요한 문제가 아님)가 아닐지라도 <그림 1>의 코드 부분을 이해할 것이다. 콘솔에 "woof"라고 프린트하는 이 프로그램을 배우는것은 당신에게 더 이상 놀라운 일이 아니다.

<그림 1>

지금 당신은 강아지들이 "woof"라고 울부짖는 것에 관심이 있거나 관심이 없을 것이다. 그러나 강아지기 짖게 만드는 것과 같은 원리가 세상에 있는 정교한 은행 시스템의 동작원리와 같다.

왜 강아지인가?

강아지는 2가지 사랑스러운 점이 있기때문에 은행시스템 보다 배우기에 더 좋다.
첫번째는 강아지는 은행원보다 귀엽다.
둘째는 강자지의 구현은 간단하고 이런 점들로 인하여 이 글의 내용을 쉽게 설명할 수 있다.

자 다시 강아지 이야기로 돌아가 보자.
간단한 그림 1의 코드를 변경하고 한두개의 컴파일러를 거치면 여러분들은 이 Dog 클래스와 분산된 Dog 컴포넌트를 가질 수 있다. 몇개의 다른 작업들로 같은 Dog 클래스와 같은 인터넷에서 사용잉 가능한 Dog 웹서비스를 생성할 수 있다. 컴파일러 벤더들은 객체를 쉽게 만들고 다른 컴포넌트들이나 웹 서비스들로 변환하는 쉬운 방법을 가지고 있다.

좋지 않은가?

불행하게도 컴파일러 벤더들이 너무도 잘해서 문제다. 객체를 다른 컴포넌트들이나 웹 서비스로 변경할 수 있는 능력은 너무도 강력하다. 아마도 매우 강력할 것이다.

Shakespeare는 "힘은 가지고 있으나 무었이 장점인지 무었이 본질인지에 대한 지시를 받지 못했다."(Measure for Measure, Act 1, Scene 1)라고 이야기하였다.

다시말하면 이것이 객체와 컴포넌트와 웹서비스의 딜레마이다.

컴파일러 벤더들은 강력한 변환의 힘을 우리에게 주었지만 우리가 이러한 힘을 언제 어떻게 사용하여야 하는지에 대한 지시는 없다. 이는 무었이 객체이어야만하며 무었이 컴포넌트이어야만 하며 무었이 웹 서비스이여야하는지에 대한 경계가 매우 모호하다는것이다.

우리는 무질서한 객체의 컴포넌트나 웹 서비스로의 변환을 왜 하여야 하는가 혹은 하지 말아야 하는가에 대한 해답을 찾기 전에 무었이 객체나 컴포넌트 및 웹 서비스를 의미하는지 조금 더 자세하고 정확하게 이해할 필요가 있다.


위치와 환경
객체, 컴포넌트 그리고 웹서비스는 많은 공통점을 가지고 있다.

• 모두 동작하기 위하여 코드로 구성되어있다.
• 모두 자신이 무었을 할 수 있지는 기술하는 인터페이스를 가지고 있다.
• 모두 프로세스안에서 살아있다.
• 모두 클라이언트에 의한 호출 시 살아있다.
• 모두 "메소드의 호출(invoking a method)"에 의하여 클라이언트가 만들어내는 요청들을 지원하는 개념을 가지고 있다. (역자 주: 클라이언트가 요청할 경우 결국 메소드를 호출하여야 하는데 이렇게 메소드를 호출할 수 있도록 지원한다는 의미이다.)
  
• 모두 <그림 2>에 의하여 설명된다.
  

<그림 2>

객체, 컴포넌트 그리고 웹서비스의 차이점은 근본적으로 위치와 환경이란 2개의 사실로 정리된다.
위치는 객체와 컴포넌트와 웹서비스들과 클라이언트 또는 다른 특별한 것들과의 상대적인 위치를 참조하며, 객체, 컴포넌트 그리고 웹서비스와 클라이언트가 살아있는 곳 안에서 프로세스의 상대적인 위치이다.
환경은 런타임시의 객체, 컴포넌트 그리고 웹서비스 호스팅되는 환경과 IBM's WebSphere 또는 Microsoft의 .NET와 같은 고객의 환경을 참조한다.

객체, 컴포넌트 그리고 웹서비스는 각기 차이점(예상할 수 없을정도로)을 가지고 있지만 주로 각기 다른 위치와 환경의 차이가 크다.

자 이러한 위치와 환경에 대한 논의를 시작해보자.

엔티티(여기서의 엔티티는 객체, 컴포넌트 그리고 웹서비스 중 하나를 의미한다.)와 클라이언트 둘다 같은 프로세스에 위치한다고 할때 관계(relationship)는 객체 관계라는 특성을 나타낸다. 환경은 엔티티와 클라이언트 둘다 반드시 같다. 왜냐하면 단일 프로세스(single process)는 하나 이상의 환경에서 존재할 수 없다. 객체지향기술인 Java 또는 C# 둘다 객체의 관계를 구현할 수 있다.

엔티티와 클라이언트가 다른 프로세스 상에 존재할때 환경의 특성을 정의하여야 한다. 엔티티나 클라이언트가 동일한 환경에 있을때 컴포넌트 관계라는 특성을 나타낸다. WebSphere’s EJB (Enterprise Java Beans) 환경 또는 Microsoft’s .NET으로 관리되는 컴포넌트 환경 둘다 컴포넌트를 지원하는 인기있는 기술로서 컴포넌트 관계를 구현할 수 있다.

클라이언트와 엔티티가 서로 다른 환경에서 존재할때 웹 서비스 관계라는 특성을 나타낸다. 웹 서비스 기술은 SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), UDDI (Universal Description, Discovery, and Integration)과 다른 기술들을 포함한다. <그림 3>은 객체, 컴포넌트 그리고 웹서비스가 위치와 환경에 따라 어떻게 다른지를 나타내 준다.

<그림 3>

왜 우리가 객체 또는 컴포넌트들을 가지고 있는지 궁금할 것이다. 객체 관계나 컴포넌트 관계 모두 웹 서비스 기술을 이용하여 구현될 수 있기 때문이다.

이러한 궁금증의 해답는 여전히 객체와 컴포넌트가 효과적이기 때문이다. 우리가 반드시 해야할 일에 주어진 제약사항을 가능한한 효과적으로 해결할 수 있다. 우리에게 다양한 환경이 필요없는 제약사항이 존재한다면 웹 서비스 보다는 컴포넌트가 조금더 효과적이다. 우리가 다중 프로세스 처리가 필요없다면 컴포넌트보다는 객체가 조금 더 효과적이다.  우리가 객체 또는 컴포넌트중 하나를 이용하는 것을 금지하는 제약사항 아래서 일하지 않으면 웹 서비스는 이러한 시스템에서 최소한의 효과를 나타낸다.


해결책

효과(efficiency)

왜 객체는 컴포넌트보다 효과적이고, 컴포넌트는 웹 서비스보다 조금 더 효과적인지 확인해보자.

클라이언트들의 같은 프로세스안에서 객체가 존재한 이래로 이러한 메소드 실행(실제 코드에 메소드 매핑)은 프로세스 범위를 확장하지 않는 것이었다. 메소드 리졸루션(method resolution, 역자 주: 메소드를 객체내에서 찾는 방법)은 더욱이 <그림 4>와 같이 보여지는 테이블 조회 시스템에 최적화된 형태로 사용되어왔다.

<그림 4>

컴포넌트는 클라이언트들의 다른 프로세스에서 존재한다. 컴포넌트는 일반적으로 투영성(고객에게는 보여지지 않는)을 사용하여 네이티브 오브젝트 메소드 해결책(native object method resolution)의 위에 인터프로세스(inter-process) 메커니즘으로 계층화 된다.
일반적으로 이러한 메커니즘은 메소드 요청을 받아들이는 클라이언트 프로세스 안에 대리자로 포함된며, 패키지들은 인터프로세스 커뮤니케이션 패키지안에 있으며, 컴포넌트 프로세스 안에 존재하는 프록시에게 전달된다. 프록시는 패키지를 받고, 요청되어졌던 메소드를 찾으며, 네이티브 객체 메소드 리졸루션(method resolution)을 통한 요청을 생성한다.

컴포넌트들은 객체보다 느린데 인트라프로세스 커뮤니케이션보다 인터프로세스 커뮤니케이션보다 느리다. 컴포넌트들은 최적화를 위한 기회를 가진다. 컴포넌트 프로세스를 위한 클라이언트의 요청들을 전달하기 위하여 .NET과 같은 네이티브 커뮤니케이션 프로토콜들로 전달한다. <그림 5>와 같다.

<그림 5>

웹 서비스들은 클라이언트로부터 프로세스 영역에서 벗어나 있거나 같은 환경안에 있다. 이러한 이유는 최적화된 네이티브 인터프로세스 전달 프로토콜보다 반드시 표준화된 웹 서비스 프로토콜(SOAP over HTTP와 같은)들을 이용해야 하기 때문이다. 웹서비스 전달 프로토콜은 모든 환경을 지원하는 벤더들에게 표현될 수 있으며  최소공통분모를 가지는 효과적인 프로토콜이다.
이러한 프로토콜들은 성능을 많이 소비하지만 환경적인 상호운용성이라는 중요한 목적을 달성할 수 있다.
웹 서비스의 메소드 리졸루션(method resolution)은 <그림 6>과 같다.

요약하면 객체의 메소드 리졸루션(method resolution)은 가장 빠르다. 왜냐하면 모든 커뮤니케이션이 단일 프로세스 안에서 발생되기 때문이다. 컴포넌트 메소드 리졸루션(method resolution)은 느리다. 왜냐하면 비록인터프로세스 커뮤니케이션을 최적화하여도 인터프로세스 커뮤니케이션을 요구하기 때문이다. 웹서비스의 메소드 리졸루션(method resolution)은 가장 느리다. 왜냐하면 인터프로세스 커뮤니케이션만 요구하는 것이 아니기 때문이며 커뮤니케이션을 하려면 최소공통분모를 가지는 프로토콜을 추가로 사용하여야 한다.

어떻게 선택할 것인가?

명백하게 여러분들이 직면하고 있는 제약사항이 빠른 커뮤니케이션을 원한다고 가정하다. 판매시점관리(point-of-sale; POS) 시스템을 구축한다고 할때 POS 시스템은 인벤토리 시스템과의 상호작용을 원한다고 하자. 말하자면 누군가 에스프레소 기계를 막 구매하였다면 지금 에스프레소 기계의 인벤토리에서 빠른 시간안에 판매한 에스프레소만큼 재고정보를 감소시켜야 한다.

이러한 인벤토리 시스템은 세상에 많다. POS 시스템을 구축하려고 할때 여러분은 추후에 연결할(상호작용할) 인벤토리 시스템에 대하여 모를 것이다. 마찬가지로 인벤토리 시스템을 구축하려고 할때 아마도 어떠한 POS 시스템이 연결될 것인지 알수 없다.

POS와 인벤토리 시스템이 독립적으로 개발된다면 아마도 서로 다른 환경에서 작동되어야 할 것이다. POS의 경우 WebSphere 시스템과 .NET 시스템과 같은 환경을 것이다.

중략

POS 아키텍트를 위하여 객체나 컴포넌트 그리고 웹 서비스는 선택의 대상이 아니다. 이것은 단지 어떠한 방식으로 커뮤니케이션을 할 것인가에 대한 선택의 문제이다.

좋은 시스템 아키텍쳐들은 객체나 컴포넌트 그리고 웹 서비스와 같은 상호 배타적인 선택을 하지 않는다. 대신 각기 다른 목적을 위한 유용한 블록을 조립하여 나간다.

웹 서비스는 알수 없는 시스템들과 함께 연동하는 데 유용하며, 컴포넌트는 시스템내부의 분산된 프로세스를 협력적으로 처리하는데 유용하며, 객에는 프로세스 내부의 코드를 조직화하는데 유용하다.

정리

일반적인 시스템은 POS와 인벤토리 시스템간의 연결과 같이 몇개의 시스템간에 연결지점을 가지고 있다. 이러한 시스템은 전체적으로 많은 분산 포인트를 가지고 있으며 아마도 어떠한 하나의 프로세스를 처리하기 위하여 많은 코드를 사용하여야 할 것이다.

더우기 여러분은 피라미드와 같이 계층적으로 사용되는 것을 보기 원할 것이다. <그림 7>은 객체와 연관된 몇몇 컴포넌트와 웹서비스와의 게층을 나타내준다. 이것은 웹 서비스에 대한 심판은 아니며 단지 자율적인 시스템안에서 일반적으로 확인되는 연결 포인트의 수를 관찰한 것이다.

<그림 7>

<그림 7>의 가장 높은 영역이 웹서비스로 패키지된 부분이다. 웹 서비스와 함께 컴포넌트들은 구현되어 사용되며, 객체들은 코드를 조직화한다.

<테이블 1>은 객체와 컴포넌트 및 웹 서비스를 기초로 현재의 내용을 정리한 것이다.

<그림 7>은 <테이블 1> 다양한 요소들을 요약한 것이다. <그림 8>은 POS와 인벤토리 시스템이 서로간에 연관되어 있는 엔티티끼리 어떻게 연동하는지를 나타내준다.


<그림 8>

<그림 8>은 다른 기능을 가진 객체와 컴포넌트들과 웹서비스들이 각각의 목표에 맞게 유기적으로 연결되어 있음을 나타내 준다. 웹 서비스들은 외부의 조직에서 업무 요청을 받는다. 컴포넌트들은 중요한 비즈니스 기능 단위를 수행하며 객체는 코드를 조직화한다.

이는 기능을 구성시 웹 서비스안에 컴포넌트들이 카테고리로 구성되어 있음을 나타낸다.
주목하여야 할 점은 <그림 8>에서 각기 다른 컴포넌트들은 각기 다른 모자로 구분되어 있어서 각자의 역활이 3가주 중요한 기능적은 분류로 구분되어 있다는 것이다.

• Point-of-entry 컴포넌트: 빨간색 모자를 쓴 컴포넌트들로 웹 서비스로부터 받은 요청을 전달해 준다.
• 어플리케이션 컴포넌트: 은색 컴포넌트들로 실제 웹 서비스의 비즈니스 기능을 형성하는 컴포넌트로서 POS 시스템의 판매 처리와 같다.
• Point-of-exit 컴포넌트: 녹색 모자를 쓴 컴포넌트로서 다른 웹서비스를 위한 요청 작업을 준비하기 위한 작업을 한다.

이러한 분류는 아키텍처적인 엄격한 원칙을 바탕으로 객체의 카테고리와 3가지 유형의 컴포넌트 및 웹 서비스들로 구성된다. 이러한 원칙들을 구성할때 Software Fortress Model (SFM)에 따라 조정될 수 있다. SFM에 대한 구가적인 자료는 Sessions, R. 2003. Software Fortresses: Modeling Enterprise Architectures. Addison Wesley를 참조하기 바란다.

SFM에 따르면 point-of-entry 컴포넌트는 가드로 부ㅡ며, 어플리케이션 컴포넌트는 워커, point-of-exit 컴포넌트는 엔보이라고 부른다. SFM을 사용할때 <그림 8>을 <그림 9>와 같이 다시 그려야 한다.


<그림 9>

SFM과 같은 모델의 사용하였을 때에 정의된 원칙을 가지고 명확하게 시스템을 조사할 수 있어 명확성을 가질 수 있다. 명확성의 경우 만은 요소들을 포함하는데 보안, 에러처리, 성능, 확장성 그리고 신뢰성이다.

대부분의 사람들은 시스템을 구축할때 큰 규모의 소프트웨어에서만 객체와 컴포넌트 및 웹 서비스의 상세를 명확헤게 구현하여야 한다로 잘못된 생각을 한다. 사실상 명확성은 3가지 엔티니들의 차이점을 이해함으로써 알 수 있다.

<테이블 1>을 살펴봄으로써 이러한 점에 대한 이해를 할 수 있다.

<테이블 1>

경계 정의하기

언어와 툴을 제공하는 벤더들은 쉽게 컴포넌트나 웹 서비스를 객체로부터 생성할 수 있는 방법에 대한 좋은
방안을 제공한다.

지금부터 객체와 컴포넌트와 웹 서비스에 대한 기초적인 차이점들을 명확하게 이해하여 어떻게 각 엔티티간 경계를 정의할 수 있을지 이해하여야 한다.
로버트 프로스트는 그의 파손된 벽안에 있는 괴팍한 이웃을 보며 "좋은 담장이 좋은 이웃을 만든다"라고이야기하였다. 이를 엔터프라이즈 소프트웨어 시스템 디자인관점에서 보면 각 엔티티를 이해하는 좋은 기준이 된다.



역자의 말: 좋은 글을 이애하시는데 조금이나마 도움이 되었을지 모르겠습니다. 위치와 환경의 차이를 이해하고 이를 바탕으로 경계를 설정하는 원칙을 가지는 것이 매우 중요할 것 같습니다. 번역상의 오류가 있다면 저에게 말씀해주시면 감사하겠습니다. 아울러 부분 부분 의역을 하였으며, 사족을 빼기도 하였습니다.
감사합니다.