CORBA소개

예전에 마소에 올렸던 기사내용인데.. 엠파스의 블로그에 제글이 있네요~

야..신기하다~~ ㅎ.ㅎ;

엠파스 기술문서를 뒤지면.. 96년에 크리스탈레포트에 대한 문서들도 있네요~~

ㅋㅋ

 

[프로그램이론] 2004-07-14 01:08:38

// ------------------------- 분산객체 기술의 큰 형님을 자처한다 분산객체 기술에 대해 무엇을 어떻게 설명해야 할까? 분산객체 기술에 대해 모두 설명하려면 많은 분야에 대한 부연 설명이 필요할 것이다. 특집 2부에서는 몇 십 권의 책으로도 부족한 방대한 사양 소개를 간추려 분산 컴퓨팅(distrubuted computing)과 객체지향 기술(object oriented technology)을 대표할 수 있는 CORBA의 탄생 배경을 시작으로 그 실체를 살펴본다. 신현묵 로코즌 객체 기술연구소장 -------------------------------------------------------------------------------- 분산 컴퓨팅 기술의 발전을 살펴보면, 그 역사는 네트워크의 발전과 개인용 컴퓨터의 발전, 그리고 근간에 가장 많은 주목을 받았던 클라이언트/서버 소프트웨어의 발전에 많은 영향을 받았다고 생각할 수 있다. 또 객체지향 기술은 소프트웨어 디자인의 복잡함을 줄이고 소프트웨어를 재사용할 수 있게 많은 도움과 영향을 주었다. 이러한 기술적인 내용과 기능, 연구 결과를 통합하려는 시도에서 분산객체 시스템(Distributed Object Management System)이 연구되고 있었다. CORBA의 탄생 고성능 PC와 충분한 대역폭을 제공하는 네트워크에 의해 분산 컴퓨팅이 가능해짐에 따라 기업 정보 시스템은 다양한 이기종 컴퓨터 환경에서 데이터와 응용 프로그램을 분산 운용하면서 프로그램의 상호 운영성과 사용자에게 분산의 투명성을 제공할 수 있게 됐다. 은행 정보 시스템은 은행의 각 지점별 BP(Branch Processor)가 지점 업무를 처리하고, 이 BP는 중앙 시스템과 필요한 업무를 처리하는 전형적인 분산 시스템의 예라고 할 수 있다. 이러한 분산 시스템은 원격 시스템간 자원 공유, 개방성, 시스템 사이의 병렬성, 확장성, 고장 감내성, 위치 투명성 등을 제공해야 한다. 또한 하드웨어 발달과 소프트웨어 발달의 불균형이 심화되면서 소프트웨어 개발의 새로운 전환이 요구됨에 따라 지난 80년대 객체지향 기술이 대두됐다. 객체지향 기술이 제공하는 추상화, 캡슐화, 상속성, 다형성 등의 성질은 컴포넌트 프로그래밍을 할 수 있게 했으며 소프트웨어 생산성을 보장하는 소프트웨어 개발 방법론으로 성장했다. 또한 객체는 데이터와 그 데이터를 조작할 수 있는 메쏘드(method)로 구성돼 있으며, 프로그램은 메시지에 의한 객체간 상호 작용을 기술함으로써 여러 문제를 해결할 수 있게 됐다. 분산객체 기술은 이러한 두 기술의 장점을 효과적으로 통합하는 기술이며, 개발자에게 애플리케이션 개발의 생산성을 향상시켜주고, 사용자에게 분산 환경에 투명하게 통합된 정보를 제공한다. 이를 위해, OMG(Object Management Group)에서는 분산 컴퓨팅과 객체지향 기술을 하나로 합친 표준 아키텍처를 제안하게 되는데, 그것이 바로 CORBA(Com mon Object Request Broker Architecture)다. 필자는 이 지면을 통해 CORBA가 왜 분산객체 기술의 선도 역할을 하게 될 것인지에 주안점을 두고 설명할 것이다. CORBA는 단순한 규격이 아니다 많은 엔지니어와 프로그래머는 CORBA를 단순한 미들웨어로만 보는 경향이 있다. 물론 이러한 요소도 분명히 CORBA의 일부분이기 때문에 틀렸다라고 말할 수는 없다. CORBA가 객체지향 미들웨어로서 출발한 것이 맞기 때문이다. 그러나 CORBA의 공식 규격에 나오는 엄청난 규모의 인터페이스 규격과 세부 항목, 관련 항목의 내용을 살펴본다면 벌어진 입을 다물지 못할 것이다. 필자도 이러한 인터페이스 규격에 질린 적이 한두 번이 아니다. 실제로 OMG의 CORBA 관련 홈페이지(www.cor ba.org)에 가서 CORBA의 규격을 살펴보면 그 전체적인 내용을 파악할 수 있다. 필자가 일하는 로코즌 객체 기술연구소에서는 COR BA의 전체적인 규격을 모두 인쇄해 놓았는데, 이 분량이 300페이지 책자로 50여권이 넘어가는 방대한 내용이다. 여기에 계속 새롭게 만들어지는 규격과 내용 또한 만만치 않다. 그렇다면 왜 CORBA의 내외부적인 규격의 내용이 이렇게 방대한 것일까? 그 이유는 CORBA가 공개돼 있는 프레임워크이기 때문이다. 즉, CORBA는 단순하게 ORB와 서비스뿐 아니라 활용 측면의 세부적인 내용까지 모두 적용할 수 있기 때문에 이미 만들어진 이러한 프레임워크를 활용, 다양한 분야에 변환해 사용할 수 있도록 한 규격이기 때문이다. 이제 많은 회사와 엔지니어는 CORBA와 OMA(Object Mana gement Architecture) 규격, 그리고 다양한 서비스군, 주변 규격 중에서 각자에게 필요한 규격과 부분만을 참조해 자기가 원하는 제품이나 프로그램을 만들어낼 수 있다. 바로 이러한 오픈돼 있는 규격을 갖고 있는 참으로 도량(?)과 아량이 넓은 CORBA야말로 분산객체 기술의 큰 형님을 자처할 수 있는 것이다. CORBA가 탄생한지도 이제 10년이 가깝게 지났으며, 그 동안 많은 변화가 있었고, 또 경쟁자의 다양한 발전 요소를 받아들였다. CORBA의 탄생에서부터 3.0 규격에 이르기까지의 변화 내용을 그림으로 정리하면 다음 <그림 1>과 같다. 간단하게 정리하면, 1991년 CORBA 스펙 1.0이 발표된 이후 실질적으로 CORBA가 널리 사용된 시기는 지난 95년 2.0 스펙이 발표되면서부터다. 이 때부터 여러 언어에 대한 포팅을 시작했으며 1997년 2.2 규격이 발표되면서 자바와 POA, GIOP 1.1을 지원하게 됐다. 이번 특집에서는 CORBA의 과거보다는, CORBA의 현재와 미래에 대해 한번 고민해보는 좋은 기회가 될 것이다. CORBA 애플리케이션의 개괄 CORBA 애플리케이션의 디자인은 다른 객체지향 애플리케이션과 별반 다를 것이 없지만, 다른 기계에 존재하는 객체와 네트워크에서 통신할 수 있도록 추가 계층(layer)을 포함해야 한다는 점이 다르다. 이런 추가 계층은 스텁(stub)과 스켈레톤(skeleton)이라는 특수한 객체에 의해 조절한다. CORBA 클라이언트에서 스텁은 서버 기계에 실제로 구현한 객체에 대한 프록시(proxy) 역할을 한다. 클라이언트는 인터페이스를 구현한 객체와 직접 상호 작용하듯이 스텁에 접근한다. 어쨌든 인터페이스를 구현한 대부분의 객체와는 달리 스텁은 클라이언트 기계에 설치된 ORB(Object Request Broker) 소프트웨어를 통해 인터페이스를 호출한다. ORB는 여러 형태로 만들 수 있는데, 각각의 ORB를 만드는 벤더에 따라 구조와 동작 방식이 다르다. 대표적인 ORB 벤더인 인프라이즈의 비지브로커는 스마트 에이전트 방식으로 동작하며, 아이오나의 오빅스는 서버 데몬 형식으로 동작한다. CORBA 서버에서 ORB 소프트웨어는 인터페이스 호출을 생성된 스켈레톤에 자동으로 넘겨준다. 스켈레톤은 BOA(Basic Object Adaptor)를 통해 ORB 소프트웨어와 통신한다. 스켈레톤은 BOA를 사용해 객체를 등록하고, 여기에 객체의 범위(원격 기계에서 사용할지의 여부 등)와 객체가 인스턴스화해 클라이언트에 반응할 수 있게 되는 시기 등을 결정한다. CORBA의 서버 프로그램 구조 CORBA 서버 프로그램은 클라이언트 객체에서 서버에게 요구를 할 경우, 이 요구를 받아들여 동작하기 위한 구현부(Implementa tion)를 하나 이상 갖고 있다. 이러한 요구를 클라이언트는 ORB를 통해 하므로, ORB는 BOA를 사용해 필요한 구현 내용을 선택하고 해당 구현 내용을 요구한다. 이때 BOA는 해당 구현부 내부의 메쏘드를 호출하기 위해 서버 스켈레톤(Server Skeleton)을 사용한다. 객체 어댑터(Object Adapter)는 서버의 객체를 관리하는 중요한 도구다. 객체 어댑터의 역할은 구현부를 ORB에서 호출할 수 있도록 만들어 주는 것이다. 일반적으로 이러한 객체 어댑터를 BOA라고 부른다. 그러므로 모든 CORBA의 ORB 제작사는 그들의 시스템 일부분에서 BOA를 지원해야 한다. 그러므로 서버는 이러한 BOA와 객체의 작업에 대한 메쏘드들과의 연결을 제공하며, 각각의 연결에 필요한 정보를 갖고 있는 것이다. CORBA 클라이언트 제작 서버 애플리케이션에서 정의한 객체를 사용하고자 할 때는 객체 인스턴스를 직접 호출하지 않고, 객체에 대한 인터페이스를 얻어 이를 이용해 작업하면 된다. 인터페이스를 얻는 방법에는 크게 정적 바인딩(static, early binding)과 동적 바인딩(dynamic, late binding)이 있다. 정적 바인딩을 이용하려면 스텁-스켈레톤 유닛을 클라이언트 애플리케이션에 추가해야 하는데, 이 유닛은 서버 인터페이스를 저장할 때 자동으로 생성된다. 정적 바인딩이 동적 바인딩에 비해 수행 속도가 빠르며, 컴파일할 때 데이터형을 검사하는 장점이 있다. 그렇지만 어떤 객체나 인터페이스를 사용해야 하는지를 런타임이 될 때까지 모를 경우에는 동적 바인딩을 사용해야 한다. 동적 바인딩은 스텁 유닛을 요구하지 않지만, 사용하는 모든 원격 객체 인터페이스(remote object interface)가 LAN에서 동작하는 인터페이스 저장소에 등록돼 있어야 한다. DII(Dynamic Invocation Interface) 활용 DII는 클라이언트 애플리케이션이 인터페이스 호출을 마샬링하는 스텁 클래스를 사용하지 않고도 서버 객체를 호출할 수 있도록 해준다. DII는 컴파일할 때 인터페이스 호출을 바인딩하지 않기 때문에 스텁 클래스를 사용하는 것보다 조금 느리게 동작한다. DII를 사용하기 전에 서버 인터페이스는 LAN에서 동작하는 인터페이스 저장소에 등록되어 있어야 한다. 클라이언트 애플리케이션에서 DII를 사용하려면 서버 인터페이스를 얻어 이를 Any 데이터형 변수에 대입한다. Any는 CORBA에서 사용하는 특수한 Variant 데이터형이다. 그리고 나서, Any 변수를 인터페이스 인스턴스인 것처럼 사용하여 인터페이스 메쏘드를 호출하면 된다. CORBA의 현재, CORBA 3.0 OMG에서는 현재 CORBA의 3.0 스펙을 제정하기 위한 표준화 작업을 진행중이다. 전체 회원사의 의견을 받아들여 CORBA의 쉬운 사용과 능력에 새로운 중요성을 부여하고, 그러한 내용을 스펙에 추가했다. 지난 99년 8월초에 초안을 제안했으며 그 해 9월 27일에 OMG 미팅에서 최종 제안할 예정이었으나, 많은 이견이 있어 이에 대한 논의가 계속되면서 최종 스펙은 아직도 완성되지 않고 있다. 그렇지만 현재까지 제안된 내용만으로도 가까운 미래의 CORBA의 모습을 어느 정도 예측할 수 있으므로, 여기에 대해 알아보도록 할 것이다. CORBA 3의 특징을 요약한다면 다음과 같다. 인터넷과의 통합 QoS(Quality of Service)의 확보 CCM(CORBA Component Model) 아키텍처 인터넷 통합(Internet Integration) 방화벽 규격(Firewall Specification) CORBA 3의 방화벽 규격은 전송층(transport layer) 방화벽, 애플리케이션층(application layer) 방화벽, 그리고 (아마 가장 흥미로운) 콜백을 위해 유용한 양방향 GIOP 커넥션, 마지막으로 이벤트 통지(event notifica tions) 등을 정의하고 있다. 전송층 방화벽은 TCP 계층에서 작업하며, 잘 알려진 IIOP 프로토콜을 위한 포트로는 683, SSL 위에서 동작하는 IIOP를 위해서는 포트 684를 정의하고 있다. 이 규격을 보면 관리자가 IIOP 프로토콜의 트래픽을 CORBA ORB가 조절하거나, 방화벽의 기본적인 내용을 설정할 수 있다. 콜백을 지원하는 것도 중요한 변화다. 이를 위해 객체는 클라이언트처럼 실행되며, 클라이언트 모듈은 콜백되는 객체를 인스턴스화할 수 있도록 돼 있다. 기존의 표준 CORBA 커넥션에서는 한 방향으로만 이러한 호출이 수행됐는데, 이 때 콜백이 일반적으로 다른 방향으로 트래픽을 조절하기 위해 TCP 커넥션을 하나 더 만들어야 한다. 이렇게 되면 기존에 존재하는 모든 방화벽에 걸리는 문제가 생기기 때문이었다. CORBA 3에서 새롭게 제안된 IIOP 커넥션에서는 커넥션의 양쪽 끝에서 반대 방향으로의 호출을 인정할 수 있는 새로운 보안 모델을 제시하고 있다. 상호 운용할 수 있는 명명 서비스 (Interoperable Name Service) CORBA 객체 레퍼런스는 CORBA 구조의 기반이 되는 내용이다. 그러므로 각각의 컴퓨터가 읽을 수 있고 상호 운용할 수 있는 객체 레퍼런스(Interoperable Object Reference, 이하 IOR)는 해당 인스턴스를 호출할 수 있는 유일한 방법을 제공한다. 다시 말해, 객체 레퍼런스를 얻지 않고 원격 인스턴스에 도달할 방법은 현재로서는 존재하지 않는다. 그런데 만약 객체 인스턴스의 위치와 그것이 현재 실행되는 것을 알았을 때는 명명 서비스(naming service)라는 것을 이용해 쉽게 객체 레퍼런스를 얻을 수 있다. 그런데 이러한 명명 서비스의 객체 레퍼런스를 알 수 없다면 어떻게 할 것인가? 상호 운용할 수 있는 명명 서비스는 URL 형태의 객체 레퍼런스인 iioploc를 정의하고 있다. 이를 통해, 명명 서비스를 포함하고 있는 원격지에 정의된 서비스에 접근하기 위해 프로그램 내에서 이용할 수 있다. 또한, 두 번째 URL 형태로 정의된 iiopname은 실제로 사용자가 URL에 추가한 이름을 사용해 원격 명명 서비스를 호출하는 것을 지원하며, 명명된 객체의 IOR을 가져올 수 있게 한다. 쉽게 예를 들면, iioploc가 ‘iioploc://www.omg.org/NameSer vice’라면 www.omg.org에 부합되는 IP 주소를 가진 기계에서 실행되는 CORBA 명명 서비스를 찾을 수 있다. QoS 제어 비동기 메시징(Asynchronous Messaging)과 QoS CORBA 3의 새로운 메시징 규격에는 다수의 비동기 그리고 시간에 독립적인 호출 모드를 정의하고 있다. 그리고 모든 모드에서 사용할 수 있는 정적, 동적 호출을 모두 사용할 수 있다. 비동기 호출의 결과 값은 실제 호출할 때 클라이언트에서 사용하는 형태로 만들어지는데, 폴링(polling)과 콜백 중 하나의 방법으로 구현할 수 있다. QoS를 위해 정책(Policies)이라는 것을 도입, 이를 통해 객체 호출에 대한 QoS를 확보한다. 여기에서 설정할 수 있는 부분은 해당 호출에 대한 시간과 우선권(priority), 데드라인(dead line) 등이 있으며, 라우팅 정책과 네트워크 라우팅 등도 제어할 수 있도록 규격이 결정됐다. Minimum, 고장 감내성, 리얼타임 CORBA MinimumCORBA는 임베디드 시스템을 고려해 정한 규격이다. 임베디드 시스템을 위한 minimumCORBA 규격에서는 CORBA의 동적인 부분인 Dynamic Invoca tion Interface, Interface Reposi tory 등을 제외했다. 리얼타임 CORBA는 리얼타임 환경을 위해 제시한 규격으로 리얼타임 환경을 위한 예측 가능성을 확보하기 위해 우선권 설정이나 쓰레드 풀의 관리 및 통신 프로토콜의 동적인 이용을 통한 네트워크 리소스 관리 방법 등을 정의하고 있다. Fault-tolerant CORBA에 대해서는 현재 RFP에 의해 상정한 상태지만, 여러 벤더의 이견으로 아직도 제대로 된 합의 사항을 끌어내지 못하고 있는 현실이다. CCM CORBA 2.0에 정의된 IIOP 프로토콜 이후에 OMG에서 제안한 내용 중에서 가장 흥미로운 내용을 꼽으라면 필자는 CCM을 꼽을 수 있을 것 같다. CORBA 컴포넌트의 구현을 위해 프로그래머, 사용자 그리고 컴포넌트 소프트웨어 소비자를 위해 여러 형태로 접근하고 있는데, CORBA 컴포넌트의 주요 부분은 다음과 같다. 트랜잭션, 보안, 영속성 및 인터페이스 제공, 이벤트 처리 패키지 등을 컨테이너 환경에 제공 EJB(Enterprise Java Beans)와의 통합 CORBA 컴포넌트 소프트웨어 시장을 형성할 수 있도록 하기 위한 소프트웨어의 분산 형태 CORBA 컴포넌트의 컨테이너 환경은 기존의 서비스에 비해 더 추상적인 상위 단계에서 패키지화한 뒤에 제공된다. 이렇게 패키지화한 컴포넌트는 기본적으로 트랜잭션과 보안과 관련된 기능을 포함하고 있기 때문에, 이러한 부분에 대해 초보 프로그래머가 큰 고생을 하지 않고 비즈니스 애플리케이션을 제작할 수 있도록 도와주고 있다. 또한 컨테이너들이 각각의 컴포넌트에서 이용하는 각종 이벤트를 지원하기 위해 이벤트 채널을 제공하며, 컴포넌트들이 제공하거나 요청하는 인터페이스를 관리하는 역할도 동시에 담당하고 있다. 또한 CCM에 있어 가장 주목할 만한 내용은 EJB가 이러한 CORBA 컴포넌트와 동일하게 동작하며, CORBA 컴포넌트 컨테이너에 설치할 수 있다는 점이다. 이는 기본적으로 CCM 모델을 EJB 모델을 확장하는 형태로 설계했기 때문인데, CORBA 컴포넌트가 EJB와 다른 점은 여러 언어에서 작성할 수 있으며, 인터페이스도 다중으로 제공할 수 있다는 점이다. 이를 통해, 현재 EJB로 만들어지는 다양한 EJB 컴포넌트를 자유롭게 변환하고 확장할 수 있는 기반을 제공한다. 또한 CORBA 컴포넌트 규격에는 다중 플랫폼 소프트웨어 분산 형태를 정의하고 있다. 이것은 XML 기반의 환경 설정 도구를 포함하고 있으며, 분할된 스크립트 규격에는 여러 가지 스크립트 언어를 구성, 이를 통해 CORBA 컴포넌트를 적절하게 배치할 수 있도록 한다. CORBA 컴포넌트 모델은 아직도 완성되지 않은 규격이지만, CORBA 3에 있어 가장 중요한 부분인 만큼 많은 사람들의 기대와 주목을 받고 있다. CORBA와 프레임워크의 관계 CORBA는 OMG에서 제정한 일종의 프레임워크다. OMG는 다양한 산업 분야에서 소프트웨어를 비롯한 많은 기술적인 요소에 분산객체 기술이 필요할 것으로 보고 여러 업체가 모여 분산객체의 프레임워크에 대한 표준안을 만들었다. 이는 나중에 전체적으로 연결할 때 어느 한 업체의 규격을 따라가기보다는 오픈돼 있는 표준 규격으로 진행하자는 합의에 따라 만들어 놓은 것이 CORBA이기 때문이다. 각각의 소프트웨어·하드웨어 업체들은 OMA 하부 기반의 CORBA의 일부분을 만들든, 아니면 이를 활용하는 부분으로 만들든 크게 상관할 필요 없이 필요한 부분만 합의에 따라 규격을 만들자는 것이 OMG의 목표이기도 하다. 그렇다면 이러한 소프트웨어 프레임워크가 왜 중요한 것일까? 소프트웨어의 개발을 위해서는 다양한 기술적인 요소와 방법이 필요하다. 이러한 요소와 방법을 하나의 철학적인 요소로 연결, 소프트웨어 개발부터 완료까지 많은 방법이 하나의 줄기를 따라 움직인다. 간단하게 설명하면 소프트웨어 프레임워크라고 볼 수 있으며, 실제 만들어진 소프트웨어를 구동하며 관리하는 것도 프레임워크 안에 있다고 볼 수 있다. 많은 소프트웨어 개발자와 엔지니어는 통일된 프레임워크가 있다면, 각각의 노력과 시행 착오를 줄일 수 있으며 이를 통해 많은 이익을 얻을 수 있다는 것을 알게 됐다. OMA와 ORB CORBA에서는 ORB가 가장 중요하다. 그런데 예상과는 다르게 CORBA간의 호환성 문제가 있다. 대표적인 ORB로는 인프라이즈의 비지브로커와 아이오나의 오빅스를 들 수 있으며, 국내에서 개발된 ORB로는 ETRI의 iORB와 로코즌의 SORBA가 있다. 그 밖에도 전세계 여러 회사에서 ORB를 제작하고 있다. OMA는 객체를 작성하는 구조다. OMA는 분산 환경에서 통신을 담당하는 CORBA와 객체를 조작하는 기본 기능을 정의한 COSS(Common Object Service Spe cification), 그리고 기타 기본 기능과 개발자가 작성한 각종 응용 객체로 구성된다. 이 중에서 CORBA 서비스는 객체를 연결하기 위한 기본 기능을 제공한다. 이 기능에는 객체의 생명 주기 서비스(Object Lifecycle Service), 명명 서비스(Naming Service), 디렉토리 서비스(Directory Service) 등이 있고 객체지향의 접근 방법인 온라인 트랜잭션 처리(On-line Transaction Processing)와 트레이더 서비스(Trader Service) 등을 포함하고 있다. 이러한 CORBA 서비스는 객체의 통신과 연결에 필요한 서비스를 제공하고, CORBA 퍼실리티(Facilities)는 필요한 서비스를 제공한다. 대표적인 복합 문서 관리(Compound Document Management) CORBA 퍼실리티는 복합 문서의 컴포넌트를 접근할 때 표준화 방법을 지원한다. 이러한 CORBA 퍼실리티는 크게 두 가지로 구분할 수 있다. 하나는 수평적 퍼실리티(horizintal facilties)로, 복합 문서 서비스가 이에 준하는 것으로 전반적인 영역에서 사용할 수 있는 서비스이고, 또 다른 하나는 수직적 퍼실리티(vertical facilties)로 특정한 산업 영역에서 사용하는 서비스를 말한다. 프레임워크의 적용 사례 현재 국내외 IT 업체와 엔지니어가 가장 많은 관심을 보이고 있는 분야는 아마도 통신과 관련된 부분일 것이다. 그 중에서도 IMT-2000이나 블루투스와 같은 이동통신 네트워크와 하드웨어 등이 그 초점이 될 것이다. 물론, 이러한 환경의 변화를 통해 기본적인 개발 방법이 변한다거나 과거의 방법으로 개발할 수도 있을 것이다. 그렇지만 더욱 다양한 컨텐츠와 서비스를 위해 더욱 많은 업체가 이런 작업을 공동으로 해야할 것이다. 적절한 예가 될지 모르겠지만, 새로운 프레임워크를 만드는 예로 모바일 프로그램을 만들기 위한 전략에 접근해 보자. 차세대 휴대 단말기는 크게 나누어 씬 클라이언트와 무거운(thick) 클라이언트가 있다. 현재의 휴대폰은 씬 클라이언트라고 할 수 있는다. 휴대폰 단말기는 사용자가 정해진 일부의 애플리케이션만을 가끔씩 사용하며, 대용량 저장장치가 필요 없고 간단한 애플리케이션만을 사용할 수 있다. 그에 비해, 무거운 클라이언트는 상당한 크기의 저장장치를 포함하고 있으며, 여러 애플리케이션을 탑재해 실행할 수 있는 형태의 시스템을 의미한다. 또한 기업의 다양한 종류의 엔터프라이즈 애플리케이션과 다양한 형태의 게임과 같은 상당한 수준의 컴퓨팅 환경이 요구되는 경우에 반드시 필요한 클라이언트이다. 현재, 필자는 한 회사의 IMT-2000용 단말기에 이용할 예정인 플랫폼에서 개발을 진행중이다. 이 플랫폼의 환경은 32MB의 메모리, StrongArm600, 640X480의 256 컬러 이상을 지원하는 수준의 고사양을 자랑하고 있다. 이 정도의 클라이언트일 경우에는 기존의 WAP보다 한 단계 높은 수준의 네이티브 애플리케이션이 필요하고, 이들 애플리케이션이 엔터프라이즈 환경과 유기적으로 결합된 새로운 소프트웨어 프레임워크의 필요성이 대두할 수 있다는 것을 짐작할 수 있다. <그림 2>는 필자 회사의 연구소에서 제작하고 있는 차세대 모바일 게임용 프레임워크의 환경이고, <그림 3>은 기존의 온라임 게임 제작 방식이며 <그림 4>는 CORBA를 이용한 온라인 게임 제작 프레임워크에 대한 개념도를 그려본 것이다. 이 게임은 리눅스와 PC, 차세대 단말기용 플랫폼에서 서로 통신하면서 동시에 서로 원활하게 게임을 즐길 수 있도록 기획한 것으로 중심적인 부분에 필자가 소속된 회사의 CORBA-ORB를 사용하며, 전체적인 게임 프레임워크 또한 OMA를 가공한 프레임워크를 사용한다. 얼마전에 필자가 있는 연구소에서는 국내 굴지의 통신회사인 D사에 컨설팅을 나간 적이 있다. 이곳에서 사용하는 ASDL 교환 장비는 루슨트 테크놀로지에서 만든 제품이었다. 이 제품을 구동하는 소프트웨어 모듈은 CORBA IDL로 매핑한 상태로 제품에 포함돼 있었다. 불과 얼마전까지도 이러한 하드웨어를 제어하는 수단은 단순한 칩 레벨에서 RS-232C나 USB 등으로 연결한 뒤, 값을 전달하고 제공되는 API를 활용하는 것이 고작이었던 것을 감안하면 참 좋은 세상이 된 것 같다. 이제는 어떠한 제품을 가져와 네트워크에 연결해도 해당 하드웨어가 자연스러운 하나의 객체로서 ObjectID를 가지고 다른 객체에서 볼 수 있는 시야를 만들어 주는 것이다. 더 이상 소프트웨어 엔지니어가 다른 하드웨어와의 연결 고리나 연결 방법을 어떤 식으로 가져갈지 고민할 필요가 없는 것이다. 이미 네트워크 장비를 비롯한 NMS/TMN시장에서는 CORBA만한 대안이 없다. 이는 이기종의 다양한 장비를 만들어 내는 회사들끼리 서로 표준화할 만한 규격에서 CORBA 이외에는 대안이 없다는 것이다. CORBA의 새로운 모습 그렇다면 이제는 앞에서 이야기한 CORBA의 새로운 규격을 이용한 다양한 형태의 변화에 대해 알아보도록 하자. 이 중에서 주목할 부분은 CORBA 컴포넌트 규격 중에서 XML과의 연계를 위한 새로운 규격이다. 이는 실제 OMG의 전체적인 개념 중에서 객체 미들웨어를 중심으로 메타 데이터를 처리하도록 하는 XML과 연동되는 XMI/MOF와 관련된 내용과, 임베디드/리얼타임 CORBA에 대한 내용이 들어 있다. 이러한 내용을 바탕으로 구상할 수 있는 여러 응용 프로젝트가 있는데, 이에 대해 몇 가지만 소개하고자 한다. CORBA와 XML의 결합, XML 리파지터리 분산객체 기술로서 CORBA가 갖고 있는 장점 중 하나는 OMG 내부에서 객체지향 설계 및 디자인을 담당할 UML(Unified Modeling Language)이라는 표준을 정하고, UML과 객체를 연동할 규격을 내놓았다는 점이다. 이를 바탕으로 필자는 다음과 같은 XML 리파지터리를 구상했는데, 이는 현재의 기업 환경에 필요로 하는 분산 자원의 저장과 관리를 목적으로 하고 있다. XML 리파지터의 역할은 기업 환경에서 존재하는 스키마를 표준적으로 관리하고, 서로 다른 스키마간의 메타 데이터를 교환하며, 분산객체 컴포넌트를 관리하도록 하는 것이다. 전체적인 아키텍처는 다음 <그림 5>와 같다. MOF 리파지터리 MOF는 OMG에서 만든 표준 스키마 정의다. MOF는 CORBA 매핑을 통해 CORBA 클라이언트나 서버에서 런타임에 스키마를 변경할 수 있는 IDL을 표준으로 제공하고 있다. MOF 리파지터리는 MOF에서 정의하고 있는 CORBA IDL을 구현한 MOF 모델을 저장할 수 있는 저장소를 말한다. 이러한 아키텍처의 적용 분야로는 다음과 같은 것들이 있을 수 있다. CORBA의 런타임에서 메타 모델을 관리할 수 있도록 하는 애플리케이션 통합적인 메타 모델 관리 애플리케이션 데이터웨어하우스 등과 같은 메타 데이터 관리 애플리케이션 CORBA 클라이언트와 서버에서 메타 모델에 대한 관리와 적용을 해야 하는 경우에는, 메타 데이터의 통일적 관리가 필요하다. 이때 어떠한 메타 모델이라고 하더라도 한 단계 상위의 MOF 메타 모델의 인스턴스 형식으로 변경할 수 있기 때문에 기업이나 공공기관에서 발생하는 수많은 메타 모델을 통합 관리할 수 있게 된다. 이러한 구조로 설계된 리파지터리는 컴포넌트 모델의 러닝 영역과 작업 영역에서 UML로 만든 설계 자료와 바이너리 모듈인 컴포넌트 형태의 모듈로 전환할 수 있다. 이를 위해 XML을 변환하는 XMI 규격을 통한 일종의 변환 작업이 필요하다. XMI Change Utility XMI는 메타 데이터 교환을 위한 표준을 말한다. XMI를 활용할 경우 각기 다른 메타 데이타를 이해하는 도구간에 손쉽게 통신할 수 있고, 이 교환을 위해 기술되는 언어로 XML을 사용하기 때문에 더욱 범용성을 가질 수 있으며, 어떠한 시스템과 도구라고 하더라도 XMI를 통해 메타 데이타를 교환할 수 있다. XML Change Utility의 가장 큰 장점은 수많은 메타 모델간의 교환을 위한 하나의 표준이기 때문에 전사적 환경에서 그 중요성이 높아가는 메타 데이타의 교환에 가장 폭넓고 풍부하게 사용할 수 있다. 컴포넌트 리파지터리 CORBA 객체와 자바빈, COM/DCOM 컴포넌트와 같은 컴포넌트를 저장하고 관리하는 전사적 자원의 통합 관리를 목표로 하는 리파지터리다. 이러한 컴포넌트를 중앙에 집중 관리하기 때문에 기업 자원을 최대한 활용할 수 있으며 또한 버전의 관리, 소멸 등의 컴포넌트 생명 주기를 관리할 수 있다. 전사적인 자원 환경에서 컴포넌트의 비중과 규모는 나날이 커지고 있다. 통합적이면서 중앙집중적인 컴포넌트 관리를 통해 더욱 효과적인 자원 활용을 기대할 수 있다. 임베디드 리얼타임 CORBA 최근에 가장 각광받고 있는 분야의 기술은 아마도 임베디드와 리얼타임 기술일 것이다. 최근의 IT 산업의 발전과 통신 네트워크의 발달은 이러한 임베디드와 리얼타임 기술의 중요성을 점점 더 높이는 계기가 되고 있다. OMG에서도 CORBA 관련 기술에 대한 규격을 결정하면서, 임베디드/리얼타임 기술의 발전에 보조를 맞추기 위해 많은 노력을 기울이고 있다. 이러한 기술이 접목되면서 엔터프라이즈를 중심으로 객체에 대한 표준을 만들어 오던 OMG에서 2000년 7월 드디어 리얼타임 임베디드 CORBA에 대한 첫 워크샵을 개최한 바 있다. 그리고 이것은 CORBA가 새롭게 나아가고 준비해야 할 사항을 대변해준다. 동작 원리 앞에서도 간단하게 언급한 바 있지만, 임베디드 CORBA와 리얼타임 CORBA를 이해하기 위해서는 기본적인 CORBA 아키텍처의 동작 원리에 대해 다시 한 번 정리할 필요가 있다. CORBA란 분산 환경에서 객체를 사용할 수 있도록 하는 표준 아키텍처를 지칭한다는 것은 이미 다 알고 있을 것이다. 여기에 사용할 객체를 구현객체라 하고 그것을 사용하는 것을 클라이언트라 부른다. 여기에서 구현객체의 메쏘드를 호출하고 ‘이러이러한 값을 처리해줘’하고 값을 던져주면 ‘자 처리한 값이야’하고 값을 넘겨준다. 이 과정을 처리하는 것이 CORBA의 ORB 코어 부분이다. 다음 <그림 6>을 보면 화살표가 통신을 한다는 표시다. 즉, 객체를 통신해주기 위한 구조가 바닥에 깔리는 것이다. 구현객체에 어떤 요청을 하기 위해 ORB 코어 부분에 클라이언트가 작업을 요청한다. 이러한 부분을 동적인 메커니즘을 사용한 DII를 사용하거나 정적 메커니즘을 사용한 OMG-IDL에 의해 컴파일한 스텁을 사용한다. 처리가 끝나면 ORB 코어 쪽에서는 구현객체에 대해 요청을 다시 넘겨줘야 하는데, 이 부분을 동적 메커니즘의 경우에는 DSI, 정적 메커니즘의 경우에는 IDL 스켈레톤을 사용한다. 여기에 여러 기능을 사용하기 위한 ORB의 인터페이스가 있다. 이를 원활하게 동작시키기 위해서는 구현객체를 관리할 필요성이 대두하는데, 이 때문에 객체 어댑터가 필요하다. 이를 순서대로 나열하면, 클라이언트가 DII와 스텁을 사용해 호출하고 그때 ORB 인터페이스를 사용하며, 스켈레톤과 DSI를 사용해 구현객체를 다시 호출한다. 이 때 ORB 인터페이스와 객체 어댑터를 사용하고 스텁과 스켈레톤을 만들기 위한 작업을 할 때 IDL 컴파일러를 사용한다. 그리고 통신 표준 프로토콜로 GIOP와 IIOP를 사용한다. 이것이 바로 CORBA의 아키텍처다. 필자가 있는 연구소에서는 이러한 요소 외에도 다양한 기술적인 지원을 추가한 ORB를 개발했다. 이 ORB는 전문가 에이전트(Expert Agent)를 제공해 공통 객체 서비스(Common Object Service)를 지원하고 IR, IMR을 쉽게 찾을 수 있도록 했다. 작은 Nam ing을 두고 RepositoryID 등으로 객체를 찾을 수 있는 서비스가 가능하고 규칙 기반의 전문가 시스템 쉘인 Jess를 이용한 스크립트 언어를 활용, 스마트한 객체를 지원하고 내부 도메인의 프로토콜에 대한 보안 등을 지원하는 방향으로 개발을 진행하고 있다. 또한, 다음 <그림 7>에서 보는 바와 마찬가지로 In terface Repository와 Implementation Repository를 지원하기 위한 IR Server와 IMR Agent 이외에 각종 모니터링 도구와 관리 도구, 그리고 개발자가 프로그래밍을 쉽게 할 수 있도록 도와주는 위저드를 제공할 예정이다. 임베디드 시스템과 리얼타임 시스템 임베디드 시스템이란 미리 정해진 특정 기능을 수행하기 위해 컴퓨터의 하드웨어와 소프트웨어가 조합된 전자 제어 시스템을 말하는 것으로 필요에 따라 일부 기계가 포함될 수 있다. 즉, 우리 생활에서 쓰이는 각종 전자기기, 가전제품, 제어장치는 단순히 회로로만 구성된 것이 아니라 마이크로프로세서를 내장하고 있으며 또한 마이크로프로세서를 구동, 특정한 기능을 수행하는 프로그램을 내장하고 있다. 그에 비해, 리얼타임 시스템이란 여기에 실시간적인 개념을 추가한 것을 의미한다. 다시 말해, 어떤 작업을 정해진 시간 안에 반드시 할 수 있도록 하는 것이다. 항공기나 핵발전소 등과 같은 곳에서는 정해진 시간 안에 해야할 일을 하지 않으면 어떤 일이 벌어질지 뻔하다. 이러한 리얼타임 시스템에는 정해진 시간 안에 작업을 반드시 완수해야 하는 하드 리얼타임 시스템(Hard Real-Time System)과 다소의 유연성을 가지는 소프트 리얼타임 시스템(Soft Real-Time System)이 있다. 리얼타임 시스템과 임베디드 시스템을 구축할 때, 기존 방식대로 메모리 관리부터 애플리케이션 제작까지 모든 것을 개발자가 알아서 프로그래밍할 수도 있지만, 이는 너무도 개발자에게 가혹한 짐을 지우는 것이라고 할 수 있다. 여기에 만약 멀티태스킹 기능이라도 추가된다면 개발자로서는 당장이라도 도망가고 싶은 마음이 생길 것이다. 예전의 일반적인 하드웨어에서는 순차 프로그램과 인터럽트만으로 충분히 이러한 작업을 할 수 있었지만 현재의 임베디드 시스템 요구 사항에는 네트워크와 멀티미디어가 기본으로 자리잡게 돼 OS의 필요성이 더욱 요구된다. 이렇게 임베디드 시스템에서 사용하는 운영체제를 임베디드 OS라고 하며, 대부분의 임베디드 OS에는 리얼타임 기능을 어느 정도 가지고 있는데, 이를 리얼타임 OS(Real-Time OS, RTOS)라고 한다. RTOS로 대표적인 것에는 WindRiver의 VxWorks, ISI의 pSOS, 마이크로텍의 VRTX, 마이크로웨어의 OS-9 등 상용 RTOS와 uCOS, RT-Linux 등이 있다. 임베디드 리눅스나 윈도우CE(포켓 PC), 임베디드 자바 등은 리얼타임 기능을 충실하게 지원하지는 못하고 있다. 임베디드 CORBA 아키텍처 임베디드 시스템에 이용할 수 있는 CORBA ORB는 다음과 같은 요구 사항을 만족시켜야 한다. 임베디드 시스템은 객체의 위치와 생성, 리소스의 할당을 시스템 디자인시에 요구 경량의 리소스 및 저장공간 사용 지원 서비스의 최소화 임베디드 시스템은 객체의 위치와 생성, 리소스 할당을 시스템을 디자인할 때 요구하는 경향이 있다. 이러한 사실을 바탕으로 mini mumCORBA 규격은 동적인 객체 생성 및 활성화 등의 기능을 제거해 가능한 한 최소 크기의 ORB를 만들 수 있도록 제안했다. 따라서 앞서 설명한 ORB의 구조 중 동적 스켈레톤과 동적 스텁을 지원하지 않을 것이다. 로코즌에서 지난 9월에 출시한 mini SORBA는 CORBA 2.2 규격을 기반으로 기본적인 minimumCORBA 스펙을 만족시키는 ORB다. mini SORBA에는 ORB의 동적 관리와 관련된 부분을 제외했고, 쓰레드 관리와 관련한 루틴과 정책 관리 루틴의 일부를 제외했으며, POA에서도 동적 객체 활성화를 위한 정책 일부와 동적 객체 관리에 대한 루틴을 제거했다. 객체의 is_a, non_existent 등의 객체 확인 여부와 관련된 기능을 제거, 적은 메모리에서도 동작할 수 있는 임베디드 ORB로서의 요구 사항을 만족시키게 됐다. 리얼타임 CORBA 아키텍처 어떤 아키텍처의 경우 일반적인 목적의 문제 해결과 특별한 애플리케이션의 지원이라는, 어떻게 보면 전혀 어울리지 않는 부분을 모두 가진 경우가 있다. 리얼타임 개발자들은 시스템 실행을 예측할 때와 리소스를 할당할 때 매우 세심한 주의를 해야 한다. 특정한 시간 안에 해당 작업을 마무리해야 하고, 제한된 리소스를 효율적으로 사용하려면 이렇게 세심한 주의를 해야 하는 것은 너무나 당연한 일이다. 따라서 리얼타임 시스템은 대부분 태스크에 우선순위(priority)를 부여한 뒤에, 우선순위가 높은 작업부터 할 수 있도록 해 정확한 시간 안에 일을 처리하게 하는 것이 그 핵심적인 내용이다. 이와 같이 리얼타임 애플리케이션을 개발하는 것은 여간 어려운 일이 아니다. 리얼타임 CORBA는 기존 CORBA에 이러한 작업 예측 가능성과 리소스 관리를 개발자에게 지원하기 위해 만들었다. 다시 말해, 리얼타임 시스템 개발을 지원하기 위해 CORBA의 본질인 일반적인 목적을 어느 정도는 희생한 셈이다. 현재 리얼타임 CORBA의 스펙은 CORBA 규격 2.2를 확장한 형태로 1999년에 정의된 바 있으며, 곧 발표 예정인 CORBA 규격 3.0에서는 정식으로 지원할 예정이다. 로코즌 연구소에서도 이에 발맞춰 신속하게 RT-CORBA를 준비하고 있는데, 다음 <그림 9>는 RT-CORBA의 아키텍처를 나타낸 것이다. 이 그림에서 노란 색으로 표시된 부분이 RT-CORBA에서 새로 추가되는 부분이다. 여기서 보면 쓰레드 관리와 우선순위 관리, 그리고 이를 위한 스케줄링 서비스 등이 추가됐음을 알 수 있다. 네트워크 리소스에 대해서는 서로 다른 프로토콜을 언제라도 변경해 사용할 수 있는 PPF(Pluggable Protocol Framework)가 제시된 것이 특징이다. 인디펜던스데이의 미스테리 이상으로 CORBA의 기본 구조와 앞으로의 미래상에 대해 알아보았다. 짧은 글로 CORBA의 전체적인 부분을 모두 알아볼 수는 없지만, 나름대로의 그림은 그려보았으니 CORBA를 이해하는데 조금이라도 도움이 됐으면 하는 바람이다. CORBA가 훌륭한 구조를 가지고 있다는 것은 분명하지만 단점이 전혀 없지는 않다. CORBA에 대한 문제점을 지적하자면 다음과 같다. CORBA의 서비스는 다 있는가? 실제로 CORBA 서비스가 모두 가동되는 상품은 거의 없다. MOM(Message Oriented Middleware)은 실제 동작할 수 있는가? 비동기 메시지를 구현할 수 있는 서비스를 아직 제공하지 못하고 있다. 서버 측의 확장은 어떻게 구현할 수 있는가? 로드 밸런싱(Load Balancing)과 고장 감내 구현이 아직 미미하다. 무엇보다 중요한 것은 CORBA의 디자인 및 제작이 너무 어렵다. 빨리 컴포넌트화할 수 있어야 하는데, 이 과정에 아직도 규격 싸움(?)을 하고 있다. 이러한 단점을 보안하기 위해 많은 개발사가 움직이고 있으며 필자 또한 열심히 작업하고 있다. 마지막으로 CORBA에 대한 내용을 정리하면서 옛날에 히트했던(?) 영화인 인디펜던스데이의 미스테리를 독자 여러분에게 풀어드리고 글을 마치려고 한다. 이 영화에 나오는 외계인 컴퓨터와 지구인의 컴퓨터가 송수신이 가능한 이유는 무엇 때문이었을까(힌트 : 컴퓨터 플랫폼, 애플리케이션 분산 구조, 코딩 언어와 관계없이 동작하는 프레임워크를 선택한다면)? 필자 연락처 : zetlos@naver.com -------------------------------------------------------------------------------- OMG에 대해 OMG는 지난 89년 5월 8개 회사(3Com, 아메리카 온라인, 캐논, 데이터 제너럴, HP, 필립스 텔레커뮤니케이션즈, 썬 마이크로시스템즈, 유니시스)가 주축이 돼 설립했다. 그 해 10월 비영리 집단으로서 독립적인 활동을 시작했다. 기술적으로 훌륭하며 상업적으로 가치가 있고 소프트웨어 산업에서 벤더 독립적인 것을 개발하기 위한 노력으로 현재 OMG의 회원은 800개사를 넘어섰다. OMG에서는 분산객체 관리 시스템의 요구 사항을 충족시키기 위해 CORBA를 제안했다. 이러한 디자인 과정에서 OMG가 무게를 두고 있는 부분은 완전히 개방된 객체 구조를 생성한다는 점이다. 즉, 현재의 소프트웨어는 기본적으로 이식성(portability)과 상호 운용성(interoperability)을 가져야 한다는 요구 조건을 기본으로 하고 있다. OMG가 제안한 표준은 현재 대다수의 컴퓨터 회사나 연구 분야에서 받아들여지고 있는데 그 성공 비결은 다음과 같다. OMG는 프로그램 코드 자체를 제안하는 것이 아니라 인터페이스 명세만 제안한다. 이 인터페이스 명세는 IDL(Interface Definition Language)이라는 특정 프로그래밍 언어에 종속되지 않는 독립적인 언어이며 특정 운영체제 또는 네트워크에 종속되지 않는다. 각 ORB 구현 제품은 CORBA 2.0/2.3/3.0 명세를 따르면 이 제품들 간에 상호 운용할 수 있다. OMG는 세계 표준인 CORBA/IIOP, 객체 서비스, 인터넷 퍼실리티(Internet Facilities), 도메인 인터페이스 규격(Domain Interface Specification)을 통해 ‘세상 어디서나 사용하는 미들웨어’라는 슬로건을 내걸고 발전해 나가고 있다. OMG는 표준화 객체 소프트웨어의 도입을 통해 컴포넌트 기반의 소프트웨어 시장을 형성하는 역할을 했다. 즉, 애플리케이션 개발을 위한 공통적인 프레임워크를 제공하기 위해 세부적인 규격을 제정하고 있는 것이다. OMG에 대한 더 많은 정보는 OMG 홈페이지(www. omg.org)를 참고하기 바란다. CORBA의 각종 서비스 CORBA의 서비스에 대한 일반적인 정의를 내리자면, ORB를 이용해 소프트웨어를 개발할 때 개발된 코드를 재사용하기 위해, 개발 소프트웨어 도메인에 독립적으로 작업할 수 있는 프로그램을 말한다. 이것은 개발에 필요한 중요한 문제를 해결하기 위해 여러 중요한 기능을 한 가지씩 담당할 수 있게 만들어졌고, 이 서비스들을 조합해 당면한 문제들을 해결할 수도 있다. 현재 OMG는 15개의 CORBA 서비스 규격을 발표했다. COSS1에 정의된 CORBA 서비스 명명 서비스(Naming Service) : 객체 정보의 등록 및 검색과 관련된 기능을 제공하는 서비스로 네트워크에 산재돼 있는 구현객체들이 자신의 정보를 등록하고, 클라이언트 프로그램들은 자신이 필요한 구현객체의 정보를 이름으로 검색, 구현객체 정보를 취득한다. 취득한 구현객체의 정보로 구현객체에 접근할 수 있도록 해주는 서비스가 명명 서비스다. POS 서비스 : POS는 CORBA 객체가 종료돼도 객체의 상태를 유지 관리해주는 서비스다. 클라이언트 프로그램은 이 POS를 이용해 객체의 현재 상태를 다른 매체에 저장하고 필요할 때 PID를 이용, 저장된 객체를 복구해 사용할 수 있다. 생명 주기 서비스(Life Cycle Service) : 이 서비스는 객체의 초기 생성부터 소멸되는 시점까지 일련의 객체 생명 주기를 관리하는 서비스로, Naming, Externalization, Relationship 서비스와 연계해 사용한다. 이벤트 서비스(Event Service) : 이벤트 서비스는 객체들간의 이벤 트 메시지를 처리할 수 있는 서비스로, 객체들 간의 콜백 기능을 이벤트 서비스로 대치해 사용할 수 있다. COSS2에 정의된 CORBA 서비스 트랜잭션 서비스(Transaction Service, OTS) : OTS는 객체의 트랜잭션을 관리하는 서비스로 RDB에서 트랜잭션을 관리하듯이, CORBA 객체에 대한 트랜잭션을 처리할 수 있게 지원하는 서비스다. 동시 동작 제어 서비스(Concurrency Control Service) : 객체들의 특정 자원에 대한 동시 접근을 제어하는 서비스다. 예를 들어, 프린팅하는 기능을 갖는 구현객체가 프린터를 사용중일 때 다른 객체가 프린터를 사용하지 못하게 하고, 먼저 프린터를 사용하는 객체가 프린터를 독점하지 못하게 제어하는 기능을 지원하는 서비스다. 관계 서비스(Relationship Service) : 객체 사이의 관계를 관리하는 서비스로 디자인 시에 작성된 관계 외에도 관계가 없는 객체 사이를 런타임에 관계를 설정할 수 있게 지원하는 서비스다. 외부화 서비스(Externalization Service) : 객체 상태의 저장 및 재생을 지원하는 서비스로 POS는 플랫 파일, 관계형 데이터베이스, 객체 데이터베이스 등을 사용해 관리하지만 이 서비스는 객체 상태를 스트림화하기 때문에 다양한 방법으로 저장하고 나중에 재생해 사용할 수 있는 기능을 지원한다. COSS3에 정의된 CORBA 서비스 보안 서비스(Security Service) : CORBA 객체들의 보안을 관리하는 서비스로 네트워크를 기반으로 하는 분산 환경에서 시스템을 공격하고자 하는 사람, 부적절한 방법으로 시스템을 이용하는 사용자에 의해 발견될 수 있는 모든 보안 구멍(security holes)을 막도록 설계했으며 안전한 환경에서 상호 작용하는 객체가 보안 정책이 집행 중이라는 사실을 알 수 없도록 설계돼 있다. 시간 서비스(Time Service) : 분산된 객체간의 시간 동기화를 관리하는 서비스다. 예를 들어, 서울과 미국에서 9시에 어떤 통계 작업을 진행하고자 할 때 서로 시각에 대한 개념이 다르기 때문에 집계가 잘 안 될 수 있다. 이때 이 서비스를 통해 서로의 시간을 동기화할 수 있으면 정확히 9시에 통계 작업이 진행돼 원하는 결과를 얻을 수 있을 것이다. COSS4에 정의된 CORBA 서비스 질의 서비스(Query Service) : 질의문을 사용, 객체를 검색하는 기능을 갖는 서비스로 질의문에서 작성된 기준에 만족하는 어트리뷰트를 갖는 객체를 검색해 낼 수 있다. 이 서비스에서 사용하는 질의문은 SQL이나 OQL 중 하나를 사용할 수 있다. 라이선싱 서비스(Licensing Service) : 사용자가 객체를 사용하기 위한 라이선스를 관리하는 서비스로, ORB 기반의 컴포넌트를 개발하고 서비스를 제공하는 제공업자가 사용자들이 사용한 컴포넌트들에 대한 사용 대가를 회수할 때에 필요한 자료 및 기능을 제공하기 위해, ORB 기반의 컴포넌트 사용에 대한 라이선스를 관리하는 서비스다. 프로퍼티 서비스(Properties Service) : 객체의 동적 프로퍼티를 생성하고, 이를 관리하는 서비스다. 이미 IDL에 정의되어 있는 객체에 프로퍼티를 추가할 경우 보통의 경우 해당 객체의 IDL을 수정, 다시 컴파일해 사용해야 한다. 하지만 이 서비스를 사용하면 런타임에 특정 객체의 프로퍼티를 동적으로 생성해 사용할 수 있는 기능을 지원한다. COSS5에서 정의된 CORBA 서비스 트레이더 서비스(Trader Service) : 객체를 등록하고, 검색할 수 있도록 지원하는 서비스로 Exporter가 트레이더에게 기능 정보를 제공하면, Importer가 필요한 기능을 질의문으로 만들어 객체 정보를 검색하는 서비스다. 이 서비스를 사용하면, Exporter가 제공하는 기능 정보를 Importer가 트레이더를 통해 필요한 기능의 객체를 검색하고, 검색된 객체 정보를 이용해 네트워크에 분산돼 있는 구현객체에 접근, 필요한 기능을 사용할 수 있다. 컬렉션 서비스 (Collection Service) : 이 서비스는 객체들에 대한 리스트 관리를 지원하는 서비스로, 동일한 객체들을 일렬로 묶거나(list), 서로 다른 객체들을 꾸러미(bag)로 만들 필요가 있을 때 사용하는 서비스다. // -------------------------