마이크로소프트 트랜잭션 서버(Microsoft Transaction Server, MTS)는 viper(독사, 살무사)라고 불린다. MTS가 개발된 뒤로 독사라는 호칭으로 프로그래머들 사이에 퍼졌다. 이렇듯 이 프로그램은 인터넷뿐만 아니라 네트워크 서버와 이를 사용하는 클라이언트 애플리케이션, 심지어 데이터베이스까지도 모두 실행할 수 있는 강력함을 지니고 있다. 마이크로소프트 트랜잭션 서버는 클라이언트 컴퓨터상의 사용자에게 익숙하지 못한 데이터베이스의 요청과 처리를 즉각적으로 스크린상으로 보여주는 장점이 있다. 보안을 담당하고, 다른 서버로의 연결도 가능하게 해주며, 트랜잭션 통합성의 기능도 가지고 있다. MTS는 오토메이션 COM 서버로 하여금 네트워크상에 중앙 집중 형태로 관리해 주는 서비스이다. 뿐만 아니라 보안, 트랜잭션, 데이터베이스 풀링같은 서비스를 제공해 준다. 마이크로소프트 트랜잭션 서버는 분산 애플리케이션과 네트워크의 데이터를 상대적으로 쉽게 만들어 주고 연결해 준다. 흔히 잘 알려진 미들웨어라고도 볼 수 있으며, 미들-티어라고 보아도 무방하다. IBM은 전통적으로 CICS라는 것을 사용했으며, 이것이 트랜잭션 운영을 하는 비슷한 제품으로 볼 수 있다.
마이크로소프트는 트랜잭션 서버를 오브젝트 지향의 프로그래밍 전략의 일환으로 확장시켰다. 트랜잭션 서버를 사용하게 되면 싱글 유저가 드래그 앤 드롭만으로도 트랜잭션 모델을 만들 수 있고, 다중 유저에게는 그 모델을 운영 가능하도록 해주며, 태스크 쓰레드와 프로세스의 생성과 운영을 모두 담당할 수 있다.
MTS는 트랜잭션 애플리케이션 개발자에게 골치 아픈 몇 가지 문제점들을 해결해 주기 위해 개발되었다. 그 문제들 중 몇 가지는 이미 해결되었을 수도 있고, 해결되지 못한 것들도 있을 것이다. 그러나 분산 오브젝트를 심각하게 고려하고 있다면 MTS는 이러한 고려 사항들을 쉽게 해결해 줄 수 있는 기술이 될 수 있다.
MTS에 대하여 또 다른 도큐먼테이션이나 화이트 페이퍼를 원한다면 http://www.microsoft.com/transaction을 참고하기 바란다. 이 홈페이지에는 트랜잭션 서버에 대해 자세한 설명이 나와 있다. MTS 1.0이 Visual Studio에 포함되어 있으며, 최근에는 Option Pack으로 MTS 2.0이 인터넷상에 올라와 있다. NT 옵션팩의 트랜잭션 서비스 페이지로부터 링크 페이지를 발견할 수 있으며, MTS를 무료로 다운로드받을 수 있다. Windows 95나 Windows 98을 사용한다면 MTS 아이템들을 다운로드받을 수는 있지만, 완전한 효과를 기대하기란 힘들다. NT는 MTS의 몇 가지 구성 요소를 구현하기 위해 반드시 필요한 환경이다. MTS는 Windows NT 서버 4.0에서 실행한다. 엔진 자체는 운영체제인 NT와 데이터베이스, 데스크탑에 포함된다.
2. MTS 작동
MTS를 살펴보면서 첫 번째로 궁금한 점은 아마도 MTS를 왜 사용해야만 하는가 일 것이다. 이것에 대한 대답을 알아보기 위해서 일반적인 분산 오브젝트의 구조를 살펴보자. 물론, 분산 오브젝트에 대하여 MIDAS에서 자세하게 살펴보겠지만, 다른 시각으로 간단하게 다시 언급하고 넘어가 보자.
이전 프로그래밍 시대로 되돌아 가보면(최소한, 오늘날 운영체제 및 응용 어플리케이션에서 가장 흔하게 사용되고, 기본적으로 사용한다는 판단을 근거로 시대를 구분함) 마이크로소프트는 컴포넌트 오브젝트 모델(Component Object Model, COM)이라고 알려진 오브젝트 모델을 처음 선보였다. 이 기술은 클라이언트 프로그램에 컴포넌트 오브젝트 모델 자체를 그다지 많이 알고 있지 못하더라도 서버 프로그램으로부터 오브젝트를 사용할 수 있게 해준다. COM은 분산 COM(Distributed COM, DCOM)으로 확장되었다. 이 오브젝트는 네트웍상에 존재하는 어떤 서버 프로그램도 실행할 수 있게 해준다. 뿐만 아니라 클라이언트에 투명성도 보장해 줄 수 있게 되었다.
그 당시 DCOM은 분산 오브젝트를 가지고 게임 프로그램을 만들려는 개발자들에게는 가장 큰 솔루션이 되었다. 마이크로소프트의 윈도우 운영체제를 기반으로 COM/DCOM을 확장해 가고 있는 반면에, 비록 OMG가 CORBA 스펙을 제정하였다 할지라도 그 스펙에 대한 구현은 마이크로소프트를 제외한 거의 대부분의 벤더 사들이 CORBA 표준에 근거하여 각기 다른 차원의 CORBA 분산 오브젝트를 구현하는 단계로 돌입하고 있었다.
COM을 사용하는 분산 오브젝트는 오브젝트를 먼저 발견해야 하고, 오브젝트 서버에 대한 위치 투명성을 제공하였다. 그러나 이러한 COM 오브젝트에 대해 문제가 계속해서 발생된 것은 각 오브젝트 구현에 있어 마샬링이 이루어져야 하고, Windows에 등록되어야 하는 문제점이 발생하였다. 예를 들면, 데이터베이스를 연결할 때 한 오브젝트가 상당히 많은 각기 다른 클라이언트에 데이터베이스 정보를 제공할 때 문제가 되었다. 유지되어야만 하는 다양한 서비스 쓰레드에서 다양한 연결을 제공해 주어야 했다. 이것의 결과로 오브젝트를 유지시키기 위한 동시 접속은 하드웨어에 의존적인 프로그래머들은 풀링(Pooling)이라는 미들웨어 연결 형태와 다중 클라이언트 사이에 다수의 데이터베이스 연결의 재사용을 발견하게 되었다.
트랜잭션 처리(Transactional Processing)는 클라이언트쪽에서 트랜잭션 코드를 작성할 때 문제가 발생할 수 있다. 트랜잭션 안에서 실행될 오브젝트가 필요하다면 왜 오브젝트 그 자체가 트랜잭션을 시작할 수 없는 것일까? 하지만, 이럴 경우 클라이언트는 트랜잭션 실패를 반드시 인지하고 있어야 한다. 그리고 클라이언트가 실패의 경우를 인지해야 하는 것은 코드가 클라이언트에서 항상 활성화되어 있어야 한다는 것을 의미한다.
뿐만 아니라, 서버 오브젝트는 꽤 비용이 들어가는 작업이라는 것을 프로그래머들이 점차 깨닫게 되었다. 서버에서 일단 작업 디렉토리가 한 번 초기화된 다음, 서버의 서비스를 요청하는 다양한 클라이언트에게 제공된다. 가장 큰 문제점은 보안성 문제인데, COM은 오브젝트를 사용하는 유저가 누구인지 모른다. 어떤 유저가 오브젝트를 사용하는지 알기 위해서는 전적으로 프로그래머의 코딩 기술에 의존한다. 보안이란 클라이언트 프로그램이 오브젝트를 사용하려 할 때 오브젝트를 액세스할 수 있는 권리를 허락하거나 거절해 줄 수 있도록 해주는 방법이다. 이러한 코딩 작업은 의외로 꽤 복잡하고, 누가 무엇을 사용하고, 누가 무엇을 접근하는지 끊임없이 물어보고, 그 정보를 기록해야 하는 알고리즘이 필요하다. 뿐만 아니라, 만약 이렇게 자주 물어보고 정보가 자주 교환된다면 네트웍 정체는 자연스럽게 증가할 것이다.
MTS의 단계로 들어오면서 MDI 형태 내에서 각각의 클라이언트를 관찰할 수 있게 되었다. MTS는 네트웍 기반의 보안, 데이터베이스 연결 풀링, 트랜잭션 처리와 오브젝트 풀링을 구현해 주는 서비스이다. 그리고 MTS는 분산 오브젝트를 더 쉽게 구현해 주는 트랜잭션 정적 모니터와 같은 툴을 제공해 준다.
이러한 문제점들을 해결해 주는 MTS의 경우, 서버 프로세스인 mtx.exe는 네트워크 어딘에선가 반드시 실행되고 있어야 한다. mtx.exe는 Microsoft Windows NT 버전 4(서비스 팩 3 또는 그 이상)나 Windows 95/98이 설치되어 있어야 한다. NT가 아닌 다른 운영체제에서 mtx.exe가 실행되면 서버를 원격적으로 조정할 수 없고, 보안도 담당할 수 없다.
서버는 일반적으로 in-process(즉, 동적-링크 라이브러리)로 작성된다. 만약 서버가 실행 파일(exe) 형태로 된다면 MTS 환경하에서는 동작되지 않을 것이다. COM 서버는 겳읖訝事抉? 서버처럼 IDispatch 인터페이스를 구현한다. 오토메이션 서버가 되기 위해서는 다양한 범위의 클라이언트에 액세스될 수 있다. C++ 프로그램으로부터 Visual Basic 프로그램까지 다양한 언어로 모두 구현할 수 있지만, 등록 프로세스는조금 다르다.
COM 서버의 경우, 클라이언트 소프트웨어를 실행시키는 웍스테이션은 서버에서 등록된 GUID(globally unique identifier)를 가지고 있다. 때문에 운영체제는 어떤 실행 파일 이미지가 오브젝트를 구동시키기 위해 실행되어야만 하는지 알고 있다. 오토메이션 서버가 MTS하에서 실행될 때, 서버는 MTS를 통해 등록된다. 이것은 mtx.exe를 가진 오토메이션 서버의 GUID와 관련있다. MTS는 오토메이션 서버에 호출들을 전달할 것이지만, 서버는 미들웨어 컴포넌트로서 공급해 준다. MDICLIENT 윈도우 클래스는 똑같은 방식으로 자식 생성, 파괴, 캐스케이딩, 타일링 등과 같은 것들을 제어해 주는 MDI 애플리케이션 안에서 미들 컴포넌트로서 제공된다.
트랜잭션을 지원하기 위해 MTS는 모든 ODBC 호출을 가로챈다. 그리고 MTS가 듣고 있다가 서버 오브젝트가 데이터베이스 트랜잭션에서 실행되어야만 한다. MTS는 서버 오브젝트가 생성될 때 자동적으로 트랜잭션이 시작된다. 서버 오브젝트는 트랜잭션을 커밋하거나 취소 시킬 수 있다. 만약 처리 과정이 올바르게 종료된 것을 이 오브젝트가 MTS에 리포트하면 MTS는 데이터베이스에 보내지게 된 커밋을 발생시킬 것이다. 그 처리 과정이 비정상적으로 종료되는 것을 오브젝트가 리포트한다면(어떠한 이유에서건 오브젝트를 구현하기 위해 코드를 작성하는 것은 전적으로 프로그래머에 달려 있다.) MTS는 트랜잭션을 롤백해 줄 것이다.
클라이언트 코드는 그 자체로는 어떠한 트랜잭션 처리를 할 필요는 없다. 사실, 클라이언트 코드는 데이터베이스에 연결할 필요도 없다. 이처럼 MTS는 그것들을 모두 관리해 주는 역할을 수행한다. 그리고 재미있는 그 외의 장점은 서버 오브젝트가 생성하고, 다른 서버 오브젝트를 사용할 경우 보조 오브젝트 중 어느 하나가 실패하면 오브젝트는 MTS에게 트랜잭션 을 롤백하도록 알려준다. 최고 단계의 오브젝트는 보조 오브젝트들의 완료 상태에 대해 주의를 기울일 필요는 없다. 이 오브젝트는 커밋하도록 MTS에게 요청할 수 있지만, MTS는 무슨 오브젝트의 호출 연결이 잘못되어 어디서 다운되었는지 안다. 그래서 전체 트랜잭션은 롤백될 수 있는 것이다. MTS는 비록 최고 단계의 오브젝트 처리가 성공되었음을 역으로 리포트할지라도 트랜잭션이 실패되었음을 클라이언트에 반대로 리포트해 줄 것이다. 그리고 오브젝트 프로그래머나 클라이언트 프로그래머 양쪽 모두 이러한 일을 수행하기 위해 어떤 특별한 일을 처리해 줄 필요가 없다
MTS가 데이터베이스 연결을 정해주므로 일련의 공동 연결(풀링)의 상당수를 유지해 줄 수 있도록 설정이 맞추어질 수 있다. 이러한 것들은 그 컨트롤하에 상당수의 오브젝트들에 의해 사용될 수 있다. 풀링은 데이터베이스상의 체증을 감소시켜 준다. 오브젝트가 통신하는 잠재적인 수천의 오브젝트 각각의 연결을 조절해 줄 필요가 없다. 첫 번째 연결이 이루어진 후에는 데이터베이스 연결하는 시간 과정 소모율이 감소되기 때문에 처리 속도를 향상시켜 줄 수 있다.
MTS는 오브젝트상의 연산과 NT 유저 데이터베이스 사이에서 관계 설정을 허락해 주는 코드가 내부에 있다. NT 유저 이름이나 그룹, 둘 중에 하나를 사용하여 다양한 오브젝트에 대한 다양한 권한을 설정함으로써(파일 서버상에서 서브디렉토리에 대한 권한을 설정하는 것과 비슷함) 관리자는 오브젝트나 오브젝트 그룹에 대해 다양한 단계의 권한을 부여해 줄 수 있다. 때문에 MTS는 서버 실행 이미지에 대한 프락시로서 동작한다. 오토메이션 서버 프로그래머는 서버에 꽤 복잡한 코드를 추가하는 것에 대해 더이상 걱정할 필요는 없다. 유틸리티 프로그램은 오브젝트에 대한 보안을 설정하기 위해 관리자에게 이러한 권한을 부여해 준다