방명록 에 소감을 남겨주십시 요.
여러분의 의견이 책의 내용을 더욱 풍부하게 만들 것 입니다.

코아 코바의 모든 내용은 본 저자와 영한 출판사 그리도 여러 회사들에 의해서 소유되어 있 읍니다. 본 저자의 허락없이 무단 복사 및 인용을 금합니다. 이 사항을 위반시 모든 법적인 책임을 지셔야 합니다.
[ 다음 | 이전 ]

2막 프레임웍을 근간으로 한 시스템 개발 방법

흔히들 요즘 구축된 시스템들을 말할 때 네트웍 환경 또는 분산 환경이라는 말을 자주한다. 그러나 이 둘 사이에는 분명 차이가 있다. 먼저, 네트웍 환경 은 흔히들 말하는 근거리 통신망(LAN , Local Area Network)이나 원거리 통신망(WAN , Wide Area Network) 또는 인터넷처럼 전화선이나 광섬유 등의 물리적인 매체상에 TCP/IP나 PPP(Point-to-Point Protocol)등의 논리적인 통신 방법인 프로토콜을 사용하여 연결된 환경을 말한다. 요약하자면 네트웍 환경이란 네트웍 그 자체의 연동에 중점을 둔 환경을 의미한다. 이에 반해 분산 환경은 이러한 네트웍 환경을 기반으로 하여 원격지의 시스템간의 협동 작업을 통해 서로의 자원을 공유하거나 필요한 정보를 주고받는 등 일련의 상호작용을 의미한다. 정리해보면 분산 환경은 네트웍 환경을 이용하여 원하는 작업을 달성하는 데 필요한 모든 구성요소들을 의미한다. 여기서 이들 용어를 정의하는 이유는 다음과 같다.

네트웍 환경에서 중요한 것은 네트웍상의 호환과 연동에 있다. 따라서 네트웍 환경에서는 어떤 프로토콜을 사용하고 , 네트웍상의 데이타 교환량은 어느 정도인가 하는 것처럼 네트웍의 연동과 상태를 관리하는 기술 등에 관심을 갖는다. 그러나 분산 환경에 있어 중요한 것은 네트웍 뿐만 아니라 협동 작업을 위해 필요한 모든 요소에 관심을 갖는다. 가령, 우리는 지리적으로 분산된 은행 지점간의 계정 업무를 처리하기 위해 구축된 다양한 네트웍 환경상에 데이타베이스 , 스프레드쉬트 , 윈도우 OLE등 다양한 소프트웨어 기술을 적절히 다루는데 관심을 갖는다. 네트웍은 단지 원하는 컴퓨터간의 물리적인 연결을 위해 필요한 요소일 뿐이다.

결국 우리는 분산 환경에 적합한 응용 프로그램을 개발하기 위해서 필요한 온갖 기술을 익히고 이들을 통합해야만 하는 슈퍼 프로그래머가 돼야 한다. 다음은 분산 환경에서 슈퍼 프로그래머가 책임져야만 하는 짐들이다.

이러한 요구 상황은 유닉스 프로그래머 뿐만 아니라 PC를 기반으로 하는 윈도우 프로그래머들도 마찬가지이다. 많은 윈도우 프로그래머들이 직접 소켓 프로그램을 통해 분산 프로그램을 작성하거나 마이크로소프트에서 제공되는 리모트 오토메이션 기능을 이용하여 분산 프로그램을 작성하고 있다. 그러나 아무리 뛰어난 개발 도구나 라이브러리가 있다곤 하더라도 정확한 배경 지식을 이해하지 못한다면 쉽게 적용할 수 없을 뿐만 아니라 슈퍼 프로그래머도 될 수 없다.

1장 . 프레임웍 기반의 소프트웨어 개발

과거와 달리 현재 개발되는 대부분의 시스템은 사용자로 부터 보다 다양한 기능과 편리한 사용자 화면을 요구받는다. 따라서 이러한 요구사항을 만족시키기 위해서는 많은 양의 코드를 직접 작성해야 한다. 또한 작성된 코드는 안전하게 검증돼야 한다. 과거 이러한 작업을 보다 효율적으로 수행하기 위해 직접 필요한 공통 기능을 모아 놓은 프로그램 덩어리(라이브러리 )를 작성하거나 이를 구입했었다. 그러나 준비된 라이브러리를 사용하기 위해서 프로그래머는 라이브러리의 매뉴얼을 열심히 숙지하고 이들 라이브러리가 제공하는 다양한 함수를 사용해야 만 했다. 윈도우 프로그래밍 경험이 있다면 MFC(Microsoft Foundation Class) 라이브러리를 이용하기 위해 수 십 권의 매뉴얼을 뒤져야만 했던 불편함을 기억할 것이다. 이러한 상황을 라이브러리 기반의 소프트웨어 개발이라 한다.

보다 생산성있는 방법으로 소프트웨어를 개발하는 데 있어 라이브러리 기반의 개발 방법은 몇 가지 문제를 갖고 있다. 먼저, 앞서 언급한 것처럼 라이브러리를 사용하기 위해서 너무 많은 것을 배워야만 한다. 또한 확장이나 재사용이 제한적이다 . 가령, 현재 라이브러리를 확장하거나 재사용하기 위해서는 새롭게 작성된 코드를 직접 컴파일 해야 만 한다. 심지어 객체 지향 개념을 기반으로 작성된 라이브러리들도 이 상황은 마찬가지 이다. 따라서 진정한 재사용의 개념은 지원되지 않는다라고 말할 수 있다. 그러나 기쁜 소식은 컴포넌트 기반의 소프트웨어 개발이라는 새로운 방법이 등장했다는 것이다.

생산성있는 슈퍼 프로그래머가 되기 위해서는 미리 준비된 여러 개의 레고 블럭을 잘 조합하여 원하는 것을 만드는 것처럼 이미 개발되어 있거나 개발하는 응용 프로그램을 잘 맞추기 위한 능력을 길러야 한다. 이 때, 재사용을 목적으로 미리 개발되어 있거나 개발하는 프로그램 조각을 컴포넌트라 한다. 컴포넌트는 기존의 라이브러리와 달리 프로그램 수행중에 원하는 기능을 사용할 수 있다. 컴파일같은 과정은 더 이상 필요없다. 따라서 진정한 의미의 코드 재사용이 이루어진 것이다. 대표적인 컴포넌트로는 마이크로소프트의 OCX나 OLE, 오라클, 애플,IBM같은 회사들의 연합 조직인 CI Lab에서 발표한 OpenDoc가 이에 해당된다. 뒤에서 자세히 언급하겠지만 OCX나 OLE는 DCOM(Distributed Component Object Model)을 그 하부구조로 사용하고 OpenDoc은 CORBA를 하부 구조로 사용한다. 여기서 중요한 점은 이들 컴포넌트들은 DCOM이나 CORBA같은 프레임웍을 하부 구조로 사용한다는 점이다.

잠시, 정리하자는 차원에서 다음 [그림 2-1]을 살펴보자. 먼저 [그 림2-1]은 기업에서 필요로 하는 일반적인 정보 시스템을 표현한 것이다. 먼저 왼쪽의 경우, 라이브러리를 이용한 시스템은 필요에 따라 각자의 하부 시스템에서 다른 시스템을 호출한다. 가령, 회계 시스템은 마케팅 시스템을 , 마케팅 시스템은 인사나 자재 시스템을, 인사 시스템은 자재 시스템을..... 시스템들간에 수 없이 많은 호출과 인터페이스가 필요하다. 이에 반해, 오른쪽의 경우는 컴포넌트를 기반으로 하여 구축된 시스템이다. 각각의 하위 시스템은 컴포넌트이다. 이들 컴포넌트는 공통의 인터페이스를 통해 손쉽게 서로 간의 기능을 이용할 수 있다. 이 때, 공통의 인터페이스는 모든 컴포넌트의 기반이 된다. 따라서 이들 컴포넌트는 마치 가전제품을 콘센트에 꼽아 사용하는 것처럼 공통의 인터페이스를 지원하는 프레임웍에 꼽아 손쉽게 이용할 수 있다. 이것이 바로 컴포넌트를 기반으로 한 시스템 개발의 기본 아이디어이다.


[ 그림2-1 ] 라이브러리 대 컴포넌트 개발 방법

결국, 시스템 디자이너나 개발자는 컴포넌트를 이용함으로서 복잡한 시스템간의 인터페이스를 줄일 수 있을 뿐만 아니라 개발되거나 개발하는 컴포넌트의 재사용성을 높일 수 있다. 이러한 장점들은 전반적으로 시스템의 유지 및 보수, 관리에 드는 비용을 줄일 수 있다. 이제, 컴포넌트를 기반으로 한 시스템 개발은 하나의 큰 줄기가 되었다. 이러한 줄기를 이해하는 데 있어 가장 중요한 점은 바로 컴포넌트들이 사용하는 공통의 인터페이스를 이해하는 것이다. 이 인터페이스는 서로 다른 목적으로 개발된 컴포넌트들이 자신의 사양을 만족시키면 어떤 네트웍 환경에서건 상관없이 서로 간의 서비스를 교환할 수 있게 해 준다. 일반적으로 이렇게 서로 다른 컴포넌트나 프로그램 사이의 인터페이스 역할을 담당하는 소프트웨어들을 미들웨어(Middleware) 또는 프레임웍이라고 한다 ( 실제, 미들웨어에는 주로 우리가 이 책에서 관심을 갖는 객체 지향 미들웨어인 CORBA를 비롯하여 아주 다양한 소프트웨어들이 다수 포함된다. 이들에 관해서는 다음 장에서 자세히 다루도록 한다).

특히, 요즘과 같이 다양한 운영체제나 하드웨어, 데이타베이스 등이 함께 운용되는 상황하에서 공통의 인터페이스를 준수하는 컴포넌트 기반의 소프트웨어는 앞서 살펴본 대로 많은 장점을 제공한다. 우리는 이러한 공통의 인터페이스를 프레임웍이라 부르고 이러한 프레임웍의 가장 진보된 형태로서 객체 지향 프레임웍인 CORBA를 살펴본다.

2장 . 프레임웍 변천사

2.1 분산 시스템의 태동 배경과 모델

초기 대부분의 컴퓨팅 시스템은 중앙에 있는 대형 컴퓨터에 직접 접속하여 모든 작업을 수행하는 호스트 중심의 중앙 집중식 방법이었다. 이 방식은 중앙의 시스템에 모든 작업이 집중되는 문제를 초래했다. 따라서 이 방법을 채택한 곳에서는 중앙 시스템으로 값비싼 IBM 호스트 같은 대형 컴퓨터를 사용해야만 했으며 중앙의 컴퓨터에 모든 작업부하가 걸리는 문제를 초래했다. 이러한 문제들을 해결하고자 제안된 방법이 일정하게 작업을 분배하여 협동하는 시스템 모델인 분산 컴퓨팅 시스템이다. 분산 컴퓨팅 시스템은 대형 컴퓨터를 이용하지 않고 유닉스같이 대형 컴퓨터에 비해 상대적으로 값이 싼 중형 컴퓨터들에게 일을 적절히 분배하여 활용함으로써 많은 효과를 얻었다. 따라서 이러한 분산 컴퓨팅 시스템을 구성하는 대표적인 기술적 방법이 클라이언트 /서 버 기술이다. 이 방법은 [ 그림2-2 ]의 우측처럼 서비스 요청자인 클라이언트는 서비스 제공자인 서버에게 원하는 작업을 요청하고 클라이언트는 서버에서 처리된 작업 결과만을 얻는 기술을 말한다. 따라서 클라이언트에는 서버에게서 전달받은 결과를 가공하여 사용자에게 출력하는 부분이 주로 놓인다. ( 그러나 현재는 클라이언트 컴퓨터의 성능이 향상됨에 따라 1차적 가공은 서버가 하고 2차적 가공을 클라이언트가 하거나 별도의 가공을 클라이언트에게 맡기기도 한다. )

[ 그림2-2 ] 중앙 집중식 방식과 분산 시스템 방식

2.1.1 중 앙 집중식 방식에서 클라이언트/서버 방식으로.

중앙 집중 방식 ------------------------------> 클라이언트/서버 방식

기존의 대형 컴퓨터를 중심으로 한 중앙 집중식 방식에서 중형 컴퓨터를 중심으로 클라이언트/서버 방식으로 전환하는 데에는 크게 다운사이징(Downsizing) , 라이트사이징(Rightsizing), 업사이징(Upsizing) 등 3가지 방법이 있다. 각 방법들은 다음과 같다.

다운사이징은 중.대형 컴퓨터를 PC나 매킨토시,유닉스 워크스테이션등으로 하향 조정하는 경우를 말한다.

업사이징은 개별적으로 존재하던 PC들을 네트웍으로 묶어 상향 조정하는 것을 말한다.

라이트사이징은 중.대형 컴퓨터 등에 구애받지 않고 다양한 플랫폼에 가장 적합한 시스템을 구성하는 것을 말한다. 즉 서버가 위치할 플랫폼이 PC건 대형 컴퓨터건 상관없이 이질적으로 구성된 시스템들을 네트웍으로 연결한 후 이 환경에 가장 적합한 응용 프로그램을 구성하는 것이다. 현재 이 방법이 가장 널리 사용되고 있다.

만약 현재 시스템을 확장하거나 새로운 시스템을 추가할 경우, 과연 어떤 역할을 새로운 시스템에 부여할 것인지 결정하고 위의 방법 중 하나를 사용하여 시스템을 구성한다면 시스템의 확장성을 보장받게 될 것이다.

2.1.2 클 라이언트/서버 시스템의 특징

앞서 잠시 살펴본 것처럼 클라이언트/서버 시스템의 등장 배경과 그 정의와 역할에 대해서 의견을 달리할 사람은 없을 것이다. 그러나 클라이언트/서버 시스템의 특징에 대해서는 여러 의견들이 있는 듯하다. 따라서 본 책에서는 다음과 같이 클라이언트/서버 시스템의 특징들을 정리해 본다.

서버는 다수의 클라이언트에게 해당 서비스를 제공할 뿐만 아니라 각종 서버의 시스템 자원을 공유할 수 있도록 해준다.

클라이언트/서버 시스템에서 클라이언트는 서비스를 요청하는 단위로서 네트웍을 경유하여 하나의 분리된 역할을 지닌다. 또한 서버는 해당 서비스의 제공자로서 역할을 갖는다. 따라서 서버는 항상 서비스의 요청을 기다리고 있어야 하며 클라이언트는 서버에게 서비스를 요청하기 위한 연결요청을 해야 한다.

클라이언트와 서버는 네트웍을 경유하여 서로 다른 컴퓨터상에 위치할 수 있으며 한 컴퓨터상에 동시에 위치할 수도 있다. 뿐만 아니라 클라이언트 프로그램은 서버역할을 동시에 할 수 있으며 서버프로그램 역시 다른 서버의 클라이언트가 될 수 있다.

클라이언트와 서버는 하드웨어 플랫폼에 무관해야 한다. 다시 말해 클라이언트와 다른 서버가 어떤 운영체제나 하드웨어에 위치하건 서버는 클라이언트에게 서비스를 제공해야 한다.

클라이언트/서버 시스템은 클라이언트의 수를 추가하거나 서버의 수를 추가하는 등 그 규모를 줄이거나 늘려도 전체 시스템의 운영에 무관해야 한다. 또한 서버의 기능을 추가한다거나 업그레이드 해도 클라이언트에 영향을 미쳐서는 안된다.

  1. 2단 계 클라이언트/서버 시스템과 다단계 클라이언트/서버 시스템

일반적으로 클라이언트/서버 시스템을 2단계 클라이언트/서버 시스템과 3단계 클라이언트/서버 시스템으로 분류한다. 먼저 2단 계 클라이언트/서버 모델에서 클라이언트는 해당 서버에게 원하는 서비스를 요청한다. 이에 반해 서버는 해당 요청에 대한 서비스를 제공한다. 실제 2단 계 클라이언트 서버 시스템은 원격 데이타베이스 접근 모델과 데이타베이스 서버 모델로 나눌 수 있다.([그림2-3])

원격 데이타베이스 접근 모델은 원격지의 컴퓨터에 위치한 데이타베이스 서버에게 SQL같은 데이타베이스 질의어를 통해 서비스를 요청하고 이에 대한 결과를 제공받는 모델을 말한다. 실제 개발시에는 주로 ESQL(Embedded SQL)방식을 사용하여 C나 C++코드에 SQL을 직접 삽입하여 서비스를 요청하고 이에 대한 결과를 일련의 테이블 형태로 전달받는다.

원격 데이타베이스 접근모델의 단점으로는 클라이언트/서버간 대규모의 데이타 이동이 불가피하다는 점이다. 예를 들어, 하나의 SQL요청에 대한 결과가 100만개라면 이 모든 데이타가 서버에서 클라이언트로 옮겨져야만 한다. 이에 따라 시스템의 성능 저하 및 네트웍 병목현상을 초래했고 응용 프로그램 작성시 프로그램의 로직과 구조가 서버 시스템의 구조에 의존함으로서 시스템의 확장시 많은 문제를 초래했다. 예를 들어 , 서버의 데이타베이스 구조가 바뀌면 모든 클라이언트 프로그램을 재작성 해야 한다. 또한 클라이언트측 사용자수에 따라 서버의 세션을 설정하기 때문에 사용자수가 늘수록 서버의 부하가 걸리는 단점이 있었다.

따라서 이러한 문제점을 다소 해결하고자 출현한 2단계 클라이언트/서버 시스템이 데이타베이스 서버 모델이다. 이 모델은 데이타베이스 시스템의 스토아드 프로시져를 사용함으로서 응용 프로그램의 로직이 바뀌더라도 서버내의 프로시져만 변경하고 이를 클라이언트들이 공유함으로서 다소 응용 프로그램 개발 후 유지.보수가 유리하다. 그러나 이 두 방식 모두 소규모이고 비정형화된 업무에 적합한 방식이다. 따라서 은행업무나 증권전산처럼 대규모의 클라이언트를 요구하는 환경에는 성능 저하 등의 문제를 유발하는 단점이 있다.

[ 그림2-3 ] 2단계 클라이언트/서버 시스템

따라서 이러한 문제점들을 해결하는 방안으로서 대두된 것이 다단계 구조의 클라이언트/서버 시스템이다. 이 다단계 클라이언트/서버 시스템은 데이타베이스가 위치한 서버부분과 최종 사용자들이 사용하는 클라이언트 부분을 완전히 분리하고 이들 사이에 연결기능을 제공하는 중간 소프트웨어(미들웨어)를 위치시킴으로서 좀 더 유연하고 확장가능한 시스템을 구현할 수 있게 해준다. 특히 데이타베이스의 위치나 공급업자에 상관없이 이질적인 DBMS를 계속 연결시켜 확장이 가능하며 서버에 많은 부하가 걸릴 때 이 부하를 균등하게 분배하는 로드발랜싱(Load Balancing) 기능이 가능하다. 그러나 기술적으로 구현이 어렵고 개발시 비용이 상대적으로 많이 발생하며 관리가 어렵다는 단점이 지적되기도 한다. [ 그림2-4 ]는 다단계 클라이언트/서버 모델을 도식화한 것이다. 사실상 시스템 프로그래머들은 클라이언트와 서버를 분리하여 처리하기 위한 응용 프로그램을 작성할 수 있다. 이를 순수한 다단계 모델이라고 한다. 그러나 대규모의 분산 환경에서 다양한 서버들에 접근하기 위해서는 해당 서버의 개수 만큼 응용 프로그램을 작성해야 한다. 가령, [ 그림2-4 ]의 순수한 다단계 모델에서 이용하고자 하는 서버의 수가 3개라면 각각의 서버에 접근하기 위해 3개의 응용 프로그램을 작성해야 한다. 더욱이 각기 다른 3개의 클라이언트가 있을 경우 3*3 , 즉 9개의 응용 프로그램을 작성해야 만 한다. 그러나 [ 그림2-4 ]의 미들웨어를 이용한 다단계 모델처럼 미들웨어가 복수 개의 클라이언트와 서버사이에서 이들의 인터페이스를 담당함으로서 이질적인 대규모의 분산 환경에서 별도의 인터페이스 프로그램없이도 접근할 수 있다. 이러한 이유때문에 분산 환경을 구축하는 데 있어 미들웨어의 도입과 활용은 가장 중요한 결정사항중의 하나라고 할 수 있다. 예를 들어 , ODBC도 아주 기본적인 미들웨어 중의 하나라고 할 수 있다.

[ 그림2-4 ] 다단계 클라이언트/서버 시스템

다음은 2단계 클라이언트/서버 시스템과 3단계 시스템을 비교 구분한 것이다.
구 분 2단계 시스템 3단계 시스템
업 무 규 모 소규모 / 그룹단위 대규모 / 기업단위
성 격 정형화된 업무 비정형화된 업무
내 용 검색, 분석 정산
보 고 기능 강력 보통
확장성 클라이언트 확장 5백대 정도 수 천대
서버 확장 5대정도 1백대 이상
DB 확장 제한 용이
구 축 용이성 쉽다. 어렵다.
비 용 적다. 많다.
네 트웍 구축 간단 복잡
개발 개발자 부담 작다. 크다.
이 용자 교육 용이하다 . 어렵다.
AP AP추가/수정 어렵다. 쉽다.
복 잡한 AP처리 제약 강력하다.
트렌젝션 관리 불가능 가능
응답시간 길다. 짧다.
로 드발랜싱 불가능 지원
DBMS성능 강력 보통
디렉 토리 서비스 불가능 제공
보안/관리 보안성 제약 강력
보안대상 데이타베이스 응용 프로그램
중 앙집중관리 불가 지원

[표2-1] 2단계 시스템과 3단계 시스템의 비교

2.2 다단 계 클라이언트/서버 시스템의 동작 원리

일반적으로 클라이언트/서버 시스템의 논리적인 작동과정을 이해하기는 쉽다. 그러나 막상 실제 물리적으로 서비스의 요청이 전달되고 이에 대한 결과를 받는 과정을 이해하는 사람은 적은 실정이다. 따라서 실제 네트웍을 경유하여 서비스가 유통되는 과정에 대해 자세히 살펴본다.

2.2.1 클 라이언트/서버 시스템의 동작원리

먼저 [ 그림2-5 ] 에서 처럼 클라이언트/서버 시스템은 2가지 동작 경로를 갖는다. 먼저 사용자들에게 보여지는 경로는 논리적인 경로로서 단지 서버에게 서비스를 요청하고 이에 대한 결과를 받는 수평적인 경로이다. 그러나 실제 클라이언트와 서버사이에는 네트웍이라는 물리적인 연결경로가 있기 때문에 이 경로를 통해 서비스의 요청과 이에 대한 결과가 전달된다. 이 경로를 물리적인 경로라 한다 . 물론 클라이언트와 서버가 하나의 컴퓨터상에 존재할 수도 있다. 이 경우 실제 물리적인 네트웍 라인을 이용하지는 않지만 컴퓨터 내부에서는 네트웍 기능을 이용해 별도의 프로그램 영역사이의 통신이 이루어진다. 실제 이 물리적인 경로를 살펴보면 다음과 같다. 참고로 통신 프로토콜은 TCP/IP를 사용한다고 가정한다.

클라이언트 서비스 요청 -> 클라이언트 운영체제 + 통신 프로토콜 -> 네트웍 -> 서버 운영체제 통신 프로토콜 -> 서버에게 서비스 요청 전달

가장 먼저 클라이언트에 의한 서비스 요청이 서버에게 전달되는 경로를 살펴보자. 먼저 클라이언트는 원하는 서버에게 해당 서비스를 요청한다. 이 서비스에는 네트웍상의 서버의 위치 정보가 명기된다. 이 서비스는 네트웍을 경유해 서버에게 전달되는 데 이 과정에서 통신 프로토콜이라는 네트웍 기능을 이용하게 된다. 해당 통신 프로토콜은 클라이언트의 운영체제에 의해서 조정되거나 운영체제의 일부로서 자리잡혀 있다. 예를 들어 , 윈도우3.1의 경우 통신 기능이 포함되어 있지 않으므로 TCP/IP를 지원하는 별도의 통신 프로토콜을 추가해야 한다. 그러나 윈도우95나 윈도우NT의 경우 통신 기능이 포함되어 있기 때문에 별도의 통신 프로토콜을 추가할 필요는 없다. 일단 클라이언트의 운영체제와 통신 프로토콜을 통해 전달된 서비스는 전화선이나 TP 케이블 같은 물리적인 매체를 통해 서버에게 전달된다. 먼저 서버에서는 클라이언트에서 보내온 서비스를 인식하기 위해 클라이언트와 같은 통신 프로토콜을 사용해야만 한다. 왜냐하면 통신 프로토콜이 서로 다르면 서비스를 송.수신 할 수 없기 때문이다. 그러나 똑같은 운영체제를 사용할 필요는 없다. 예를 들어, 서버는 유닉스 운영체제상에서 수행될 수도 있다. 단 유닉스는 TCP프로토콜을 지원해야 클라이언트의 서비스를 수신할 수 있다. 일단 서버의 운영체제를 통해 전달된 서비스는 실제 해당 서버에게 전달된다.

서버 서비스 제공 -> 서버 운영체제 + 통신 프로토콜 -> 네트웍 -> 클라이언트 운영체제 + 통신 프로토콜 -> 클라이언트에게 서비스 결과 전달

일단 클라이언트의 서비스를 전달받은 서버는 해당 서비스의 요청 사항에 적합한 행동을 취한다. 예를 들어, 그 서비스는 데이타베이스에 특정 조건을 만족하는 값들을 읽어오거나 갱신할 수 있다. 일단 해당 서비스의 수행을 마친 후 서버는 그 서비스의 결과를 해당 클라이언트에게 전달하기 위해 서버의 운영체제상의 통신 프로토콜을 이용하여 서비스 결과를 전달한다. 결국 해당 서비스 결과는 다시 물리적인 네트웍 라인을 경유하여 클라이언트상의 통신 프로토콜에 의해 인식된 후 클라이언트에게 전달된다.

[ 그림2-5 ] 클라이언트/서버간의 동작 원리

이들 과정에서 중요한 것은 항상 클라이언트와 서버사이에는 같은 프로토콜을 사용해야 한다는 점이다. 실제 통신 프로토콜의 역할에 대해서는 다음 절에서 자세히 다루도록 한다.

다음 [ 그림2-6 ]는 실제 클라이언트/서버 시스템의 구성 가능한 예를 보여 준다. 이 예를 보면 클라이언트는 윈도우 3.1 에 TCP/IP통신 프로토콜을 추가하여 사용하고 있으며 서버는 각기 윈도우3.1에 TCP/IP 통신 프로토콜 , 통신 프로토콜이 내장된 윈도우95 , 통신 프로토콜이 내장된 유닉스를 이용하고 있음을 알 수 있다. 클라이언트는 [ 그림2-6 ]의 세 서버 중 어느 것에라도 서비스를 요청할 수 있다. 이 서비스는 앞서 살펴본 과정에 의해서 전달된다. 또한 시스템 관리자는 언제라도 클라이언트와 서버를 추가할 수 있다. 이때 클라이언트와 서버 모두 어떠한 운영체제라도 상관없다. 단 같은 통신 프로토콜은 사용해야 한다. ( 참고로, 클라이언트와 서버 프로그램 모두 해당 운영체제상에서 수행돼야 한다. )

[ 그림2-6 ] 클라이언트/ 서버 구성 예

2.2.2 통 신 프로토콜의 역할 이해

앞서 클라이언트/서버 시스템을 이해하려는 많은 사람들 중 가장 난해한 부분 중 하나가 클라이언트/서버 사이의 통신 부분이라고 지적한 바가 있다. 사실 이 부분을 이해하기 위해서는 통신 프로토콜의 기능을 이해해야 한다. 그렇다면 과연 프로토콜이란 무엇인가 ?

실제로 다른 나라에서 그 곳 사람들과 의사 교환을 위해서는 당연히 그 곳 언어를 사용해야 한다. 한국에선 당연히 한국어를 , 인도에서 인도어를 사용하는 것처럼 말이다. 그러나 우리는 영어를 사용하여 세계 어느 곳에서도 대화를 나눌 수 있다 . 왜냐하면 영어는 공용어로 인식되어 세계의 모든 곳에서 사용되고 있기 때문이다 . 물론 영어가 이렇듯 공용어로 자리잡히게 된 데에는 여러 이유가 있겠지만 영어가 세계에서 가장 많이 사용하기 때문에 지속적으로 사용되는 것임에는 분명하다 . 이처럼 프로토콜은 쌍방의 약속된 신호이다. 다시 말해 쌍방이 서로의 의사를 교환하기 위한 약속이라고 이해하면 된다. 따라서 특정 프로토콜을 사용하는 사람들과 대화를 나누기 위해서는 그 프로토콜을 사용해야만 가능해진다. 이런 이유로 인해 클라이언트와 서버는 같은 프로토콜을 사용해야 만 한다.

2.2.2.1 표준 프로토콜 , TCP/IP 이해
통신 시스템은 하드웨어와 소프트웨어들의 복 잡한 결합으로 이루어진다. 따라서 이 복잡한 네트웍 시스템을 쉽게 이 해하고 구성하기 위해 많은 국제기구와 연구기관에서는 네 트웍 시스템을 각기 작은 여러 개의 조각으로 분리한 참 조 모델을 표준으로 제시하였다. 1) 참조 모델 참조 모델은 네트웍 시 스템의 구성 요소들이 서로 결합하는 방법과 이들 구성 요 소들 사이의 인터페이스에 대한 표준 사항을 제시한다. 여기에서 참 조 모델은 크게 TCP/IP(Transmission Control Protocol/Internet Protocol) 와 OSI 참조 모델의 두 가지가 있다. OSI (Open Systems Interconnection) 참조 모델은 국 제 표준 기구인 ISO(Internalization Organization for Standardization)에 의해서 제안되었고 학 술 . 연구 분야에서 연구.인용되고 있다. 그러나 실제 TCP/IP 모델이 더 광범위하게 사용되고 있는 실정이며 인터넷의 공 식 프로토콜로 맹위를 떨치고 있다. 개념상의 복잡성을 줄이기 위 해 참조 모델들은 프로토콜을 여러 개의 계층으로 나눈다. 사실 계 층 구조는 개념적인 것으로 실제로 프로토콜을 구현할 때 반드시 여 러 개의 모듈로 구성될 필요는 없다. [그림2-7]에서 처럼 OSI는 프로토콜을 7개의 계층으로 TCP/IP는 5개의 계층으로 나 누었다. 각 계층은 각기 나름대로 고유한 역할을 수행한다. 물리 계 층은 두 모델 모두에서 필수적인 계층이다. 트위스트 케이블, 동축 케 이블, 광섬유에서 부터 지점과 지점을 연결하는 무선 또 는 위성 연결이 사용될 수 있다. 많은 컴퓨터 시스템들은 컴 퓨터사이의 통신을 관장하는 CSMA/CD, 토큰 링, 토큰 버스 방 식의 기술을 이용한다. 가정에서 모뎀을 통해 인터넷에 접속하기 위 해 사용하는 PPP(Point-to-Point)도 이 계층에 속한다. 한편 CCITT 데이타 링 크 및 네트웍 계층 프로토콜인 X.25도 IP 계층 밑에서 사용될 수 있 다. 원격 로그인에 필요한 호스트간의 연결을 제공하는 공중망 (PDNs ,Public Data Networks)에서는 X.25가 많이 이 용되고 있다. 결국 전화선같은 물리적인 매 체로 연결된 지점 사이에서 원하는 정보를 송.수신하기 위해서는 OSI나 TCP/IP모델처럼 약속된 계층을 양쪽에 설치해야 한 다. 이 약속된 계층을 프로토콜 스택이라고도 한다. 예를 들어 , 인터넷을 사용하기 위해서 우리는 TCP/IP 스택을 설치해야 한다 . 이 스택안에는 5개의 논리적인 계층이 존재한다. [ 그림2-7 ] OSI와 TCP/IP통신 프로토콜 모델 2) TCP/IP 계층 이제 프로토콜에 대한 이 해가 됐다면 좀더 TCP/IP에 대해 자세히 알아보자.인터넷은 다양한 운 영 체제를 사용하는 컴퓨터 시스템의 네트웍이다. 그리고 인터넷에서의 정 보 전송 단위인 패킷(packet)은 출발지의 시스템에서 목적지에 도달하기 까지 여 러 시스템을 거쳐 전송된다. 그래서 여러 시스템이 이해할 수 있는 공 통의 약속 즉, 프로토콜이 필요하다. 그 결과 생긴 통신 프로토콜이 바 로 전송 제어 프로토콜/인터넷 프로토콜 TCP/IP이다. TCP/IP의 각 계층을 실제 클라이언트/서버 시스템을 사용하는 과정을 통 해 살펴보자. 먼저 우리는 클라이언트 컴퓨터상에서 데이타베이스 응용 프로그램을 사 용해 서버에게 해당 데이타베이스 서비스를 요청한다. 이 요청은 데 이타의 안전을 보장하는 전송층으로 전달된다. 전송층에서는 송.수신시 보내지는 정 보의 순서. 내용 등을 정확히 전달시켜야 한다. 일단 전송 계 층을 지나 인터넷 계층에 도착한 패킷 정보는 원하는 주소로 전 달된다. 일단 해당 주소 정보를 확인한 패킷 정보는 네트웍 계 층에서 원하는 목적지로 보내진다. 목적지로의 전송은 물리 계층을 통 해 진행된다. 원하는 목적지에 도착한 패킷 정보는 물리층 -> 네트웍층 -> 인터넷층 -> 전송층을 거치면서 해당 데 이타베이스 서비스를 제공하는 서버에게 전달된다. 해당 서버는 다 시 반대 순서를 경유하여 해당 데이타베이스 질의 결과를 클라이언트에게 제 공한다. 좀더 자세히 TCP/IP의 기 능을 살펴보면 다음과 같다. 먼저 TCP는 자료 전송시 발 생하는 문제를 해결하고 컴퓨터간의 신뢰성 있는 상호연결을 제공한다 . 이를 위해 TCP는 데이타의 전송시 에러가 없어야 하고 데이타를 패 킷으로 나누고 다시 모을 수 있어야 한다. 또한 중복된 패 킷이 없어야 하며 서로 다른 순서로 도착한 패킷을 올바른 순 서로 처리해줘야 한다. 이러한 기능을 TCP에서 제공한다 . TCP와 아울러 IP는 다양한 호스트와 네트웍을 출발지에서 목적지까지 패킷이 전 달되도록 논리적으로 연결해 주는 역할을 한다. 이를 위 해 IP는 인터넷에서 전송의 기본이 되는 패킷과 인터넷 주 소 방식을 정의한다. 또한 프로토콜의 네트웍 계층과 전송층사이의 패 킷 전송을 담당하며 해당 패킷을 원격지의 호스트로 전송한다 . 또한 TCP/IP는 개방형 구 조이기 때문에 유닉스를 비롯하여 윈도우 등 각종 운영체제에서 이 를 지원하고 있으며 각종 네트웍 하드웨어와 독립적이며 통일적인 네 트웍 주소를 사용함으로서 Ethernet , Token ring , Dial-up line, X.25등 각종 전송매체의 종 류와 독립적으로 작동하며 인터넷 등 전세계를 상대로 한 거대한 네 트웍에서도 사용 가능하다. 이러한 이유들로 인해 TCP/IP는 산 업계 표준 프로토콜로 인정받고 있으며 가장 광범위하게 사용되고 있 다. ( 만약 TCP/IP에 대해 보다 많은 정보를 원한다면 Wilensky의 "TCP/IP for Dummies"를 권한다. 이 책은 아 주 쉽게 TCP/IP와 인터넷에 대해 설명해 주고 있다 . )

2.3 미들 웨어 시스템

2.3.1 미 들웨어의 정의

이 시점에서 다단계 클라이언트/서버 시스템을 미들웨어를 활용한 분산 시스템이라고 정리하자. 왜냐하면 다단계 시스템을 효과적으로 활용하고 구성하기 위해서는 각종 중간기능의 소프트웨어인 미들웨어를 필요로 하기 때문이다. (비슷하지만 혹자는 미들웨어를 클라이언트와 서버사이의 상호작용을 위해 필요한 분산된 모든 소프트웨어로 정의하기도 한다.) 이때 중간 기능을 제공하는 미들웨어는 공통의 것이라기 보다는 각기 다른 서비스를 제공하는 중간 소프트웨어를 지칭하는 것이다. 가령, 서로 다른 데이타베이스들 사이의 로드발랜싱이나 트렌젝션처리를 주로 담당하는 OLTP 소프트웨어도 미들웨어라 말할 수 있다. 그러나 미들웨어들이 공통적으로 제공하는 기능은 이질적인 서버들에 일관되게 접근하여 이들 서버의 서비스를 이용하게 해주는 기능이다.

2.3.2 미 들웨어를 이용한 다단계 분산 시스템의 구성과 동작 과정

앞서 클라이언트/서버 시스템의 작동과정을 살펴본 바 있다. 그렇다면 미들웨어를 사용하여 다단계 클라이언트/서버 시스템을 구성하려면 어떤 방법들이 있는 지 알아보자.

먼저 [ 그림2-8 ]에서 처럼 미들웨어를 클라이언트측에 위치시킬 수 있다. 이 경우 클라이언트는 미들웨어에서 제공하는 API를 이용하여 원하는 작업을 수행한다. 나머지 모든 작업은 미들웨어에서 처리된다.

이 구성 방법은 몇가지 문제를 발생시킨다 . 먼저 각각의 클라이언트 컴퓨터마다 미들웨어를 설치해야만 한다. 또한 이런 부담으로 인해 보다 강력한 클라이언트의 컴퓨터 능력을 필요로 한다. 실제 이런 구성은 거의 없다.( 없다라고 생각해도 무방하다. )

[ 그림2-8 ] 미들웨어가 클라이언트측에 위치한 다단계 시스템

미들웨어를 서버측에 위치시키는 것은 현재 가장 일반적으로 사용하는 방법이다. 단지 클라이언트측에는 미들웨어에서 제공하는 DLL(Dynamic Linking Library)나 공유 라이브러리를 제공하여 클라이언트에게는 단지 하나의 인터페이스 만으로 다양한 서버를 이용할 수 있게 해준다. 그리고 실제 미들웨어 서비스를 제공하는 부분은 서버의 컴퓨터에 위치한다. 서버측의 미들웨어는 해당 서버에게 클라이언트측의 서비스를 전달하여 수행시키고 이 결과를 클라이언트에게 전달하는 역할을 한다.

[ 그림 2-9 ] 미들웨어가 서버측에 위치한 다단계 시스템

미들웨어를 클라이언트나 서버측에 두지않고 별도의 전용 컴퓨터에 설치할 수도 있다. 이런 경우는 실제 수많은 클라이언트와 서버를 필요로 하여 미들웨어가 많은 작업을 수행해야 하는 경우 적합한 모델이다. 또한 이질적인 시스템들을 서버로 관리할 경우 가장 적합한 모델이다. 클라이언트측에는 DLL(Dynamic Linking Library)이나 공유 라이브러리를 제공하여 클라이언트에게는 단지 하나의 인터페이스 만으로 다양한 서버를 이용할 수 있게 해준다. 그리고 실제 미들웨어 서비스를 제공하는 부분에는 해당 서버에게 서비스를 요청하기 위해 필요한 서버의 라이브러리가 존재한다. 따라서 클라이언트의 요청은 미들웨어의 API를 통해 전달되고 전달된 클라이언트의 서비스 요청은 서버API를 통해 다른 컴퓨터상에 존재하는 서버에게 전달되며 이에 대한 결과는 다시 미들웨어를 통해 클라이언트에게 전달된다. 이 구성에서 주의해야 할 점은 빠른 전송속도를 보장하는 네트웍 환경을 갖추어야 한다. 왜냐하면 [ 그림2-10 ]에서 보듯이 다른 구성요소에 비해 네트웍을 경유하는 경로가 많기 때문에 많은 데이타들에 의해 전송속도에 문제가 생길 수 있기 때문이다. 이 문제가 해결된다면 대규모의 다단계 시스템은 고려해 볼 만한 시스템이다.

[ 그림2-10 ] 미들웨어가 별도의 호스트에 위치한 다단계 시스템

2.3.3 미 들웨어의 종류

앞서 살펴본 것처럼 미들웨어는 단순히 하나의 소프트웨어를 칭하는 것이 아니다. 미들웨어는 클라이언트와 서버사이에서 그들이 필요로 하는 서비스를 효율적으로 제공하는 소프트웨어를 말한다. 따라서 클라이언트와 서버는 그들의 요구에 따라 데이타베이스 응용 환경에서 필요한 데이타베이스 미들웨어를 필요로 할 수도 있고 빠른 트렌젝션이나 로드밸런싱을 위해 OLTP미들웨어를 요구할 수도 있다. 그렇다면 이러한 광역의 미들웨어에는 어떤 것들이 있을까?

2.3.3.1 통 신 미들웨어

사실 아주 광범위한 의미의 미들웨어는 TCP/IP같은 통신 패키지 , 원격 프로시져 호출(RPC , Remote Procedural Call) , 메세지 규잉 시스템(Message Queuing System)에서 부터 출발한다 . 사실 우리는 OSF의 DCE , 노벨의 Netware , 네임드 파이프(Named Pipe) , TCP/IP , NetBios같은 통신 기능 패키지와 Peerlogic이나 메세지 익스프레스같은 메시지 기능 패키지를 이용하여 단순한 다단계 클라이언트/서버 시스템을 구할 수 있다. 이들을 편의상 통신 미들웨어라고 부른다.

통신 미들웨어중에서 RPC는 가장 광범위하게 사용되었고 지금에도 기타 다른 미들웨어 시스템의 하부구조로 이용되어 지는 시스템이다. RPC는 사용자에게 원격지에 있는 함수를 호출할 수 있는 방법을 제공한다. 다시말해 사용자는 RPC에서 제공하는 IDL(Interface Definition Language)라는 언어를 통해 원하는 함수를 작성한다. 이때 IDL컴파일러는 클라이언트측에서 사용하는 함수와 서버에서 사용하는 함수를 함께 제공한다. 따라서 클라이언트가 자신에게 주어진 함수를 호출하면 이 호출은 자동적으로 RPC런타임 라이브러리를 통해 서버에 위치한 함수가 호출된다. 해당 함수의 수행이 끝난 후 해당 결과는 다시 클라이언트측에서 호출한 함수의 결과값으로서 전달된다. 이러한 RCP를 제공하는 것으로는 Sun/USL ONC(Open Network Computing)에서 제공하는 RPC와 DCE(Distributed Computing Environment)에서 제공하는 RPC가 있다.

통신 미들웨어의 가장 초보적인 것으로는 소켓같이 네트웍 기능을 제공하는 여러가지 패키지를 들수 있다. 초기 클라이언트/서버 시스템을 개발하려는 사람은 이 패키지를 사용하여 일일이 클라이언트 프로그램과 서버 프로그램을 작성해야만 했다. 그러나 근래에 와서는 노벨의 네트웨어나 마이크로소프프의 윈도NT처럼 기존의 운영체제에 네트웍 기능을 대폭 강화하여 프린터나 디렉토리등 각종 자원을 공유할 뿐만 아니라 개발자들에게 이러한 기능을 이용하여 새로운 클라이언트/서버 시스템을 구성할 수 있는 기능을 제공한다.

특히 네트웍 운영체제는 클라이언트/서버 시스템을 구성하는 데 있어 가장 중요한 하부구조를 이루는 요소중 하나이다. 왜냐하면 이 운영체제의 성능과 기능에 따라 실제 적용가능한 영역을 결정할 수 있기 때문이다. 다시 말해 네트웍 운영체제의 종류에 따라 클라이언트와 서버의 규모와 적용시 성능도 결정된다고 할 수 있다. 가령, 근래에 들어 개인용 컴퓨터를 기반으로 하는 클라이언트 운영체제는 기존의 16비트 운영체제를 탈피하고 멀티태스킹을 기본으로 하는 32비트 운영체제가 득세하고 있는 실정이다. 그 대표적인 주자가 마이크로소프트사의 윈도우95와 윈도우NT, IBM의 OS/2등을 들 수 있다. 클라이언트 부분이외에 서버쪽에서도 기존의 유닉스 외에 마이크로소프트의 윈도우NT, 노벨의 네트웨어들이 강세를 보이고 있는 있는 실정이다.

다음 [그림2-11]은 그 적용 규모에 따라 운영체제를 잘 표현하고 있다. 기존의 도스나 윈도우3.1등 단순한 운영체제들에서 네트웍 기능을 포함하고 강력한 하드웨어에 구동이 가능한 네트웍 운영체제쪽으로 발전하고 있음을 알 수 있다.


[ 그림2-11 ] 클라이언트 / 서버 운영체제

2.3.3.2 서 비스 미들웨어

통신 기능을 하부 구조로 활용하면서 특정한 서비스 타입에 적합한 미들웨어들이 있는 데 그 종류는 다음과 같다.

데이타베이스 미들웨어는 클라이언트의 SQL요청에 대한 서버의 서비스와 이에 대한 결과를 네트웍상에서 주고받는 일련의 서비스를 제공한다. 데이타베이스 미들웨어의 예로는 마이크로소프트의 ODBC(Open Database Connectivity) ,볼랜드의 IDAPI , SAG(SQL Access Group)의 CLI(Call Level Interface) , 오라클의 글루(Glue)가 있다.

OLTP 미들웨 어를 이용하는 클라이언트는 네트웍상의 OLTP서버에 트렌젝션 서비스를 요청하고 이에 대한 결과를 돌려받는다. 실예로는 턱시도(Tuxedo)와 엔시나(Encina) , X/Open등이 있다.

객체 지향 미들웨어는 클라이언트 객체가 ORB(Object Request Broker)라는 소프트웨어 버스를 활용하여 원격지의 서버의 메소드를 호출하고 이의 수행결과를 전달받는다. 특히 분산 객체 미들웨어는 사용자들과 프로그래머에게 상속이나 다형성처럼 객체 지향 기술이 제공하는 다양한 장점들을 제공하며 네트웍 프로그램에서 발생하는 수고를 덜어줌으로서 가장 각광받는 시스템이 되고 있다. 또한 분산 객체 미들웨어는 네트웍 투명성 이외에 다양한 플랫폼상에 존재하는 다양한 객체들을 하나로 묶을 수 있는 기능을 제공하기 때문에 이종의 플랫폼과 데이타 모델을 통합하는 시스템으로 자리잡고 있다. 실제 제품으로는 Orbix , ObjectBroker , PowerBroker 등 수십 개에 이른다.

  1. 서비스별 미들웨어의 기능

앞서 미들웨어의 다양한 종류에 대해 알아보았다. 해당 미들웨어에서 제공하는 주요 서비스와 개념에 대해 살펴보도록 하겠다.

2.3.4.1 DCE 통신 미들웨어

DCE는 OSF에서 구성한 이질적인 분산 환경을 위한 복합 소프트웨어 패키지이다. 여기서 "구성"과 "복합" 이란 단어를 사용한 이유는 DCE가 단일 소프트웨어로서 OSF에 의해서 만들어진 것이 것이 아니라 기존의 네트웍 운영체제하에서 사용되던 서비스중에서 우수한 기능만을 모아 분산 환경에서 클라이언트/서버 프로그램을 가능하게 만든 것이기 때문이다. 현재 DCE는 1.1 까지 릴리이즈 됐는데 이 버전에서는 보다 빠르고 관리하기 쉬운 코드와 실행 시간에 함수를 호출할 수 있는 동적 호출(Dynamic Invocation Interface)기능을 추가했다. ( 이 기능은 분산 객체 표준인 CORBA의 기능을 반영한 것이다.) 뿐만 아니라 로드 발랜싱 , 계정 관리 , 감사(Auditing)기능 등을 반영하고 있다고 알려져 있다. 실제 DCE의 구성요소는 [ 그림2-12 ] 에서 처럼 DCE RPC(Remote Procedural Call) , DCE 이름 서비스, DCE 시간 서비스 , DCE 보안 서비스 , DCE 분산 파일 시스템 , DCE 쓰레드 등이다. 이것들은 모두 함께 작업을 수행할 뿐만 아니라 개별적으로도 가능하다. 가령 , DCE RPC만 사용할 수 있지만 RPC에 쓰레드나 보안 기능을 추가할 수도 있다.


[ 그림2-12 ] DCE의 구성요소

각각의 DCE 구성요소를 간략히 살펴보면 다음과 같다.

1) DCE RPC

RPC는 원격지에서 미리 작성된 함수를 호출할 수 있는 기능을 프로그래머에게 제공한다. DCE RPC는 사용자에게 IDL(Interface Definition Language)와 IDL컴파일러를 제공한다. 사용자가 원하는 DCE RPC응용 프로그램을 IDL에 맞게 작성하고 이를 IDL 컴파일러를 사용하여 컴파일을 수행하면 클라이언트용 C코드와 서버용 C코드가 생성된다. 다시 말해 모르는 사이에 분산기능이 스며들어 가는 것이다. ( 이 방법은 분산 객체 시스템의 표준인 CORBA의 것과 유사하다. ) 실제 이 코드를 스터브(Stud)라 부르는 데 스터브는 컴파일시 DCE 실시간 라이브러리와 함께 컴파일되고 링크되어 클라이언트측의 호출 기능을 수행한다. DCE RPC의 가장 강력한 기능은 DCE 보안과 이름 서비스 , 쓰레드를 함께 사용할 수 있다는 점이다. 이 기능은 각각의 호출시 실시간에 서버의 위치를 찾을 수 있을 뿐만 아니라 각각의 함수호출에 대해 권한인정(Authentication)을 할 수 있다는 장점이 있다. 그러나 DCE RPC의 단점으로는 트렌젝션을 제공하지 못한다는 점이다. 이 문제의 해결을 위해X/Open 컨소시엄은 DCE RPC에 트렌젝션을 추가한 TxRPC를 정의하고 있으며 OLTP미들웨어에서도 이와 유사한 작업을 진행하고 있다.

2) DCE 이름 서비스

DCE 이름 서비스는 프로그램 , 파일 , 디스크 같은 모든 자원을 특별한 데이타베이스에 사용자가 원하는 이름 형태로 저장한 후 인식할 수 있는 기능을 제공한다. 이를 위해 DCE는 분산 환경을 셀(Cell)이라 불리는, 관리할 수 있는 단위로 나눈다. 이 셀은 클라이언트와 서버의 조합으로서 셀의 도메인은 사용자에 의해서 정의된다. 실제 셀의 크기에 제약은 없지만 관리하기 쉽게 정의하는 것이 좋고 최소한 하나의 셀 디렉토리 서버와 보안 서버를 포함해야 한다. 또한 DCE는 디렉토리 서비스를 셀 단위의 로컬 이름을 관리하는 셀 디렉토리 서비스와 셀간의 , 즉 전체 디렉토리를 관리하는 전역 디렉토리 서비스로 구성한다. 이들 사이의 정보를 주고 받으면서 전체 이름들이 관리된다.

3) DCE 시간 서비스

DCE 시간 서비스는 네트웍상의 컴퓨터들이 공통의 표준 시간을 인식하여 동기화 할 수 있는 기능을 제공한다. DCE는 적어도 3개의 시간 서버를 요구한다. 시간 서버는 시간에 대한 문의가 들어오면 답변을 해주는 서버를 의미한다. 적어도 하나 또는 그 이상이 전화나 라디오 등을 통해 시간을 받을 수 있는 하드웨어에 연결되어 있어야 한다. 각각의 시간 서버는 서로 문의를 하여 클락을 맞추어야 한다. DCE는 UTC시간 표준을 사용한다.

4) DCE 보안 서비스

DCE 보안 서비스는 MIT의 커버로스 인증 시스템과 HP의 보안 기능을 기반으로 하여 구성되어 크게 시스템 접근 허가를 위한 인증(authentication) , 자원에 접근 허가를 위한 인가(authorization) , 그리고 사용자 계정 관리기능을 제공하고 있다. 이 기능을 위해 각각의 DCE 셀은 보안 서버를 갖추어야 한다.

5) DCE 분산 파일 시스템

DCE 분산 파일 시스템은 분산 환경에서 파일의 위치를 투명하게 해주고 높은 가용성을 제공한다. 특히 DCE 분산 파일 시스템은 로그를 기반으로 한 시스템으로서 유사시 서버에 장애가 발생하더라도 빠르게 재시작하고 회복할 수 있다. 왜냐하면 모든 수행 작업을 로그에 기억하고 있기 때문에 장애시 이를 보고 이전 상태로 쉽게 복귀할 수 있기 때문이다. 또한 파일과 디렉토리를 복수 개의 서버에 중복시켜 가용성을 높이고 있으며 다른 유닉스 네트웍 파일 시스템인 NFS와 함께 사용할 수 있다.

DCE 분산 파일 시스템은 DCE RPC의 보안 기능과 통합되어 있으며 각각의 파일은 유일한 식별자를 지니고 있어 네트웍상에서 위치와 무관하게 유일하다. 사용자에게 제공되는 API도 POSIX 1003.1a, 포터블 OS 인터페이스에 근거하고 있다.

6) DCE 쓰레 드

쓰레드는 일정한 작업을 수행하는 프로그램의 작은 단위이다. 우리는 이 쓰레드들을 복수 개 수행시키는 다중쓰레드를 사용함으로서 프로그램의 성능을 향상시킬 수 있다. DCE 쓰레드 패키지는 POSIX 1003.4a , Pthreads 표준에 근거한 쓰레드 API를 사용자에게 제공한다. 직접 이 API를 이용하여 쓰레드 기능을 이용할 수 있을 뿐만 아니라 앞서 살펴본 다른 DCE 요소들이 사용하고 있다.

2.3.4.2 데 이타베이스 미들웨어

데이타베이스 미들웨어란 분산 환경에서 복수 개의 데이타베이스 서버들을 일관되게 이용하기 위한 환경을 제공해주는 서비스를 말한다. 이 경우 2가지 상황이 발생할 수 있다. 하나는 동일한 공급업자가 제공한 데이타베이스 서버들을 사용할 경우이고 또 하나는 서로 다른 공급업자에 의해 제공된 이질적인 데이타베이스 서버들을 이용할 경우이다. 전자의 경우는 크게 문제될 것이 없다. 왜냐하면 모든 클라이언트가 사용하는 서비스 호출방식도 동일할 뿐만 아니라 이 서비스를 처리하는 서버도 동일하기 때문이다. 그러나 후자의 경우 많은 문제가 발생한다. 가장 중요한 문제로는 원하는 데이타베이스 서버를 호출하는 클라이언트들의 호출 방식과 각 데이타베이스 서버들이 사용하는 SQL문장의 차이이다. 이 차이를 해결하는 가장 원시적인 방법은 N*M개만큼 해당 서버에 대응하는 드라이버를 만드는 것이다. 이 방법은 생각만 해도 끔찍한 방법이 아닐 수 없다. 이 문제를 해결하고자 나온 방법들에 따라 데이타베이스 미들웨어는 다음과 같이 분류할 수 있다.

먼저 이 방법을 사용하는 대표적인 제품으로 SAG(SQL Access Group)의 CLI(Call Level Interface)와 볼랜드의 IDAPI , 마이크로소프트의 ODBC , 오라클의 Glue등을 들 수 있다. 이 방법은 클라이언트들에게 공통의 SQL 호출 인터페이스를 제공하고 이 인터페이스는 실행시간에 해당 서버의 드라이버를 로드하여 수행시킴으로서 앞선 문제를 해결한다. 그러나 실제 이 방법도 과연 어떤 것이 공통의 SQL 호출 인터페이스이고 해당 드라이버의 공통표준은 무엇인가 등 수많은 문제를 내포하고 있다.

이 방법은 앞선 방법처럼 클라이언트에게 공통의 SQL 호출 인터페이스를 제공하고 이를 각각의 서버에게 전달하는 게이트웨이 드라이버를 위치시킨다. 서버측에서는 클라이언트의 게이트웨이 드라이버가 제출한 서비스를 해석하기 위한 게이트웨이 서버가 위치한다. 이 방법을 채택한 대표적인 예로는 ISO/SAG의 RDA(Remote Database Access)와 IBM의 DRDA(Distributed Relational Database Architecture)등을 들 수 있다 .

[ 그림 2-13 ] SQL 인터페이스와 SQL 게이트웨이 미들웨어 방식

2.3.4.3 OLTP 미들웨어

흔히들 TP모니터라고도 불리는 OLTP는 현재 국.내외에서 가장 광범위하고 다양하게 사용되는 미들웨어이다. 왜냐하면 OLTP가 제공하는 기능 중 작업을 균등하게 분배하는 기술은 현재 사용하는 대부분의 데이타베이스 시스템의 성능을 향상시킬 수 있으며 2PC(2 Phase Commit)란 기능은 다른 서버들 상의 데이타 갱신상에서 발생할 수 있는 데이타의 불일치를 보장해 주는 기능이 유용하기 때문이다. 따라서 은행 업무나 항공 예약같은 업무에서 이 기능은 필수적이다. 그러나 대부분의 데이타베이스 시스템은 동종의 시스템 사이에서는 이 기능을 제공하지만 이종의 데이타베이스 시스템에서는 지원하지 못한다. 결국 OLTP 미들웨어는 이질적인 분산 환경에서 트렌젝션을 처리하고 각종 처리절차를 관리하는 기능을 제공한다. 특히 OLTP미들웨어는 대규모이고 빠른 응답시간을 요구하는 분야에 유용하다. 또한 데이타베이스 시스템을 통해 시스템을 구성하려는 곳이 다음의 특징을 갖는다면 OLTP 미들웨어의 도입을 신중이 검토하라 .

가령, 오라는 데이타베이스 시스템과 사라는 데이타베이스 시스템을 동시에 이용하여 시스템을 구성하는 경우 프로그램 작성면에서 프로그래머는 2가지 DBMS의 API를 모두 알아야만 한다. 또한 두개의 데이타베이스를 모두 한꺼번에 조작할 경우 데이타의 무결성과 안정성을 API차원에서 보장하기 힘들다. 이때 OLTP 미들웨어를 도입하면 단지 미들웨어의 API만 알면 모든 것을 해결할 수 있다.

예를 들어 , 오라는 데이타베이스 시스템을 도입하여 클라이언트/서버 시스템을 구성할 경우 일반적으로 클라이언트에는 해당 오라는 DBMS의 클라이언트 패키지와 네트웍 관련 패키지를 구매해야 한다. 이때 가격은 일반적으로 상당히 비싸다. 이런 경우 OLTP미들웨어를 구입하면 상대적으로 저렴한 미들웨어 API만을 구입하여 클라이언트에 설치하고 단지 서버는 미들웨어 하나와 DBMS만 구입하면 된다. 뿐만 아니라 이후 다른 DBMS를 도입하다거나 서버를 늘릴 경우 많은 득을 볼 수 있다.

이러한 상황이외에도 데이타베이스 시스템을 이용하는 곳이라면 OLTP미들웨어를 신중히 고려할 필요는 있다.

[ 그림2-14 ] OLTP 미들웨어의 서비스 모형도

2.3.4.4 객 체 지향 미들웨어

객체 지향 미들웨어는 객체 지향 개념을 기반으로 한 다단계 분산 시스템을 제공한다. 사실 객체 지향 미들웨어의 기술적 배경이자 가장 중요한 요소는 CORBA(Common Object Request Broker)이다.

CORBA는 현재 컴퓨터 사용자들은 개인적으로 생산성있는 응용 프로그램을 원할 뿐만 아니라 파일이나 데이터베이스처럼 다양한 데이타 저장 공간으로 부터 정보를 얻길 원한다. 뿐만 아니라 다른 사용자들과 자료를 공유하고 서로 통신하길 원하고 있다. 이렇듯 다양한 요구 사항을 만족시키는 프로그램을 작성하기 위해서는 서로 다른 운영체제와 네트웍 환경 등 이종의 환경하에서 작동가능한 클라이언트/서버 소프트웨어를 개발해야 할 뿐만 아니라 개발된 소프트웨어는 분산 환경에서 서로 다른 시스템과도 쉽게 통합이 가능해야 한다. 그러나 이러한 요구 사항을 만족시키는 소프트웨어를 작성하는데 있어서 많은 어려움이 존재한다. 먼저 기존의 C와 같이 로직의 흐름에 따라 프로그램을 작성하는 방식으로는 이 같은 요구사항을 만족시키기 어렵다. 또한 이종의 분산환경에서 여러 종류의 응용 프로그램을 통합하기 위해서는 일정한 결합방식이 필요하다.

이러한 문제를 해결하는 방식으로 우리는 기존의 RPC(Remote Procedure Call)방식이나 마이크로 소프트의 OLE(Object Linking and Embedding)같은 방식을 사용해왔다. 그러나 RPC의 경우 복잡한 프로그램을 작성하는 데 있어 많은 한계들을 나타냈으며 OLE의 경우 윈도우 객체들만의 호환을 지원하기 때문에 진정한 분산 시스템 표준이라고 말하기 어렵다.( 물론 최근에 마이크로소프트는 OLE객체를 유닉스상에서 수행하도록 하는 방법을 개발중이다. ) 그러나 이러한 문제를 해결할 수 있는 방식으로 대두된 것이 OMG(Object Managemane Group)에서 제정한 CORBA 표준안이다. CORBA는 이 책에서 다루는 핵심 주제이다. 두번째 마당에서 부터 본격적으로 CORBA에 대해 살펴본다. 여기서는 정리차원에서 호기심이 강한 여러분들을 위해 아주 간략하게 소개하도록 한다.

1989년 4월 현재 존재하는 객체 기술을 바탕으로 응용 프로그램들을 결합하기 위한 객체 지향 표준을 제정하기 위해 OMG라는 비영리 단체가 탄생하였다. 이 단체에는 마이크로소프트를 포함한 수많은 컴퓨터 관련 단체들이 참가하여 객체 지향 기술을 기반으로 하여 이종의 분산된 환경하에서 응용 프로그램들을 서로 통합할 수 있는 표준기술을 탄생시켰다. 바로 이 표준이 CORBA , 아니 좀더 자세히 말하면 OMA(Object Management Architecture)이다 . OMA는 응용 프로그램간의 결합뿐만 아니라 객체의 생성 , 소멸에서 부터 저장 , 트렌젝션 기능에 이르기까지 분산 객체 환경에서 필요한 모든 서비스를 총칭하는 것이다. 이들 기능 중 CORBA는 컴퓨터 내부의 버스처럼 서로 다른 프로그램들 사이의 버스 역할을 하는 모듈로서 OMA의 가장 중요한 요소이다. 결국 CORBA 는 OMA의 한 부분이고 ORB는 CORBA 의 핵심기술을 말하는 것이다. 현재 OMG는 1990년 OMA를 발표한 이래 지금까지 CORBA 2.0 명세를 발표하였으며 자바와의 연동에 중심을 둔 3.0 표준이 진행되고 있다.

1) OMG의 OMA

OMA는 [그 림2-15]에서 보듯이 이종의 분산환경에서 필요한 모든 기능을 정의하기 때문에 상당히 광범위하다. 먼저 OMA를 이해하는 데 있어 가장 기초 사항이 객체 지향 개념의 이해이다. 왜냐하면 OMA가 제공하는 모든 서비스는 객체 개념을 기반으로 하기 때문이다. 따라서 분산 객체 시스템을 고려중인 사람들은 객체 지향 개념과 언어에 익숙해져야 한다.

OMA는 크게 이종의 분산 환경에서 통신을 담당하는 CORBA와 객체를 조작하는 데 필요한 각종 기본 기능들을 정의하고 있는 COSS(Common Object Service Specification) , 그리고 추가적으로 제공되는 지원 서비스가 존재하고 있다. 그리고 마지막으로 이들 기능들을 이용하여 사용자들이 작성한 각종 응용 객체들이 존재한다. 앞서도 언급했듯이 OMA 구조에서 가장 중요한 것이 CORBA이며 현재 수많은 구현 제품이 존재하고 있다. 그러나 실제 CORBA만으로는 복잡한 응용 프로그램을 작성하는 데 있어 충분한 기능을 제공하지는 못한다. 따라서 이들 필요한 기능을 모아서 만든 것이 COSS이다. COSS에서 제공하는 서비스는 [그 림 2-15]에서 나타나는 것처럼 아주 다양하고 광범위하다. 각 서비스에 대한 자세한 기능은 3막 을 참조하기 바란다. 현재 CORBA를 구현한 대부분의 제품은 이들 COSS기능을 제공하기 위해 많은 작업을 수행하고 있다.(참고로 COSS는 CORBA 서비스라는 용어로 사용되기도 한다.)

[ 그림 2-15 ] OMA(Object Management Architecture)

2) CORBA 1.2

분산 객체 시스템을 위한 OMA에서 CORBA는 가장 중추적인 역할을 한다. 다름아니라 CORBA는 분산 환경에서 객체간의 통신을 담당하기 때문이다.

CORBA는 [그 림2-16]과 같은 구조로 구성되어 있다. CORBA를 이해하는 데 있어 중요한 점은 CORBA는 서버라는 용어를 사용하지 않는다는 것이다. 왜냐하면 CORBA는 객체 지향 개념을 바탕으로 하여 원격지의 클라이언트가 원격지에 있는 서버를 호출하는 것이 아니라 객체의 메소드를 호출함으로서 서비스가 이루어 진다. 따라서 CORBA 에서는 서버가 아니라 구현 객체( Object Implementation )라는 용어를 사용한다. 이 때 고려해 볼 사항은 사용자가 클라이언트와 구현 객체사이의 통신부분을 직접 관여해야 하는가에 대한 여부와 구현시 사용하는 프로그래밍 언어에 따라 각기 다르게 작성해야 하는가 하는 문제이다. 만약 그렇다면 사용자에게 너무 많은 짐을 지우는 셈이 된다. 이러한 점을 해결하고자 CORBA에서는 IDL(Interface Definition Language) 이라는 표준 언어를 제공한다 . 3막과 4막에서 자세히 다루겠지만 사용자는 IDL을 사용하여 원하는 프로그램을 작성할 수 있다. 일단 작성된 IDL은 CORBA 에서 제공하는 IDL 컴파일러를 통해 컴파일된다. 이 결과 원하는 프로그램 언어로 작성된 클라이언트 코드와 구현 객체 코드를 얻을 수 있다.( 이 코드는 C나 C++ 또는 자바처럼 사용자가 원하는 형태로 제공된다.) 이 코드들에는 통신을 위해 필요한 모든 기능이 자동적으로 포함된다. 따라서 사용자는 네트웍과 구현 언어에 대해 걱정할 필요가 없다.

일단 CORBA의 클라이언트 객체에는 클라이언트 스터브와 프로그램 수행시 원하는 메소드를 호출하는 동적 호출(Dynamic Invocation)기능을 통해 구현 객체를 호출할 수 있다. 일단 클라이언트 객체의 호출이 발생하면 통신을 담당하는 ORB 기능을 통해 구현 객체에게 전달된다 . 이때 구현 객체쪽의 객체 아답터 (Object Adapter)는 기본적으로 해당 객체를 호출 가능하게 생성하고 원하는 호출에 해당하는 메소드를 실행시킨다. 일단 실행된 메소드에 의해서 처리된 결과는 다시 클라이언트 객체에게 전달된다. 클라이언트 객체에 의해서 요청된 서비스는 CORBA를 통해 원격지의 구현 객체에게 전달되고 구현 객체에 의해서 처리된 결과는 다시 클라이언트 객체에게 반환된다. 호출시 전달되는 정보로는 호출시 대상이 되는 객체와 메소드 , 전달 인자 등이 있다.


[ 그림2-16 ] CORBA 구성도

분산 객체 시스템의 장점으로는 CORBA라는 표준을 기반으로 하고 있는다는 점과 객체 지향 기술에서 제공하는 우수한 기능을 사용할 수 있다는 점을 들 수 있다. 따라서 객체 지향 방법을 사용하여 시스템을 구성하려는 곳에서는 분산 객체 미들웨어의 사용은 필수적이라 할 수 있다.

2.4 미들 웨어 기술의 현재와 미래

지금까지 중앙 집중 방식의 시스템에서부터 2단 계 클라이언트/서버 시스템, 미들웨어를 통한 다단계 시스템에 이르기까지 미들웨어 시스템의 발전사와 더불어 해당 기능을 정리해 보았다. 다음 [그 림2-17]은 미들웨어 기술의 발전방향을 정리한 그림이다.

이 그림에서 보듯이 차세대 미들웨어 기술은 기존의 LAN을 기반으로 하는 환경에서 인터넷을 포함한 WAN환경으로 변했다. 환경뿐만 아니라 기술적 측면에서도 초기 파일서버나 데이타베이스 서버에서 객체 지향 미들웨어로의 기술변환이 주를 이룬다고 말할 수 있다. 그 누구도 이러한 사실에 이견을 달리하지 않고있다. 특히 이후 요구되어지는 컴퓨팅 환경은 보다 복잡하고 다양한 사용자들의 요구사항을 만족하기 위해 보다 다양한 기능을 갖는 시스템을 필요로 한다. 이 시스템은 단지 데이타베이스같은 단일 기능이 아니라 해당 데이타베이스를 통해 얻은 정보를 2차원 , 3 차원으로 가공하거나 이를 다른 곳으로 옮기는 등 보다 강력한 기능을 발휘해야 하며 다른 소프트웨어의 기능을 적절히 이용할 수 있어야 한다. 이러한 연유에서 CORBA라는 표준과 객체 지향 기술을 기반으로 한 분산객체 미들웨어는 계속 확산될 전망이다. 실제로 6막 에서 살펴보는 것처럼 외국의 경우 대규모의 시스템 건설 프로젝트에서 분산객체 미들웨어를 사용하고 있는 실정이며 상당 부분 성공하고 있는 실정이다. 국내의 경우도 새로운 시스템을 구성하는 몇몇 연구기관과 회사에서 분산객체 미들웨어을 통해 시스템을 구성하고 있다. 머지않아 객체 지향 기술의 국내 확산과 더불어 분산객체 미들웨어의 요구사항은 점차 증가하리라 생각한다 . 따라서 장기적인 시스템 구축 계획을 갖고 있는 분들은 이러한 동향도 참고함이 유리할 것이다.

[ 그림2-17 ] 미들웨어 기술의 발전지도

2막을 마치며

우리는 2막을 통해 컴포넌트를 기반으로 한 시스템 개발이 주는 장점들과 이를 위해 필요로 하는 다양한 프레임웍인 미들웨어 시스템을 정리해 보았다. 미들웨어는 다양한 이종의 환경하에 있는 모든 소프트웨어들을 유기적으로 묶어주는 역할을 수행한다. 따라서 미들웨어는 컴포넌트 소프트웨어 개발시 프레임웍을 제공하는 중요한 요소이다. 현재, 이용가능한 미들웨어로는 TCP/IP같은 통신 미들웨어에서 부터 데이타베이스 미들웨어, OLTP미들웨어 등이 있으며 가장 진보된 미들웨어인 객체 지향 미들웨어인 CORBA가 확산되고 있다.



[ 다음 | 이전 ]