KR100439761B1 - 코바에서의 그룹 통신 시스템 및 방법 - Google Patents

Abstract

본 발명은 OCI(Open Communications Interface)를 확장한 코바에서의 그룹 통신 시스템 및 방법에 관한 것이다. 본 발명에 있어서 OCI를 이용한 코바에서의 그룹 통신 기법은 OS(Operating System, 운영체제)에 독립적인 것은 물론, ORB(Object Request Broker)와 OCI의 수정없이 기존의 다양한 그룹 통신 프로토콜을 적용할 수 있다. 따라서, 현재 많이 연구되고 있는 고장감내 코바에서도 즉시 활용될 수 있는 효과가 있다.

Description

코바에서의 그룹 통신 시스템 및 방법{SYSTEM AND METHOD FOR GROUP COMMUNICATION IN CORBA}

본 발명은 코바(CORBA)에서의 그룹 통신(group communication) 시스템 및 방법에 관한 것으로, 특히, OCI(Open Communications Interface)를 확장한 코바에서의 그룹 통신 시스템 및 방법에 관한 것이다.

일반적으로, 코바에서의 그룹 통신 시스템에 사용되는 인터페이스(interface)들로, 버퍼(buffer), 억셉터(acceptor), 트랜스포트(transport), 커넥터(connector), 커넥터 팩토리(connector factory), 레지스트리(registries), 정보 객체(information object) 등이 있다. 버퍼는 데이터를 가지고 있으며, 클라이언트(client)와 서버(server) 사이의 통신에 사용하는 위치 카운터를 관리한다. 정보 객체들은 억셉터, 트랜스포트, 커넥터, 및 커넥터 팩토리에 대한 정보들을 가지고 있으며, 각 객체마다 자신의 정보 객체를 가지고 있다.

본 발명에 따른 그룹 통신을 위한 확장에서는 기존의 OCI의 인터페이스들을 모두 사용함과 동시에 "GCIOP(Group Communication Inter-ORB Protocol) ConnectorTransport"에서 "ordering_type"과 GCIOP 억셉터에서 "join, leave, set_state, get_state" 함수를 새로이 추가하였다.

도 2는 확장 OCI를 이용하여 그룹 통신 프로토콜로 통신할 때 사용하는GCIOP의 "Tagged Profile" 형식을 나타낸 개략도로, 코바에서의 실제 통신 프로토콜에 맞도록 구현된다. "Tagged Profile"을 정의해서 사용한다. "Tag"는 고정 값으로서 객체 간의 통신을 위해 사용되는 프로토콜을 나타낸다. '01'은 이미 IIOP(Internet Inter-ORB Protocol)에서 쓰이고 있기 때문에, 그룹 통신을 위해서는 이 외의 다른 값을 사용한다. 그룹 이름(Group Name)은 ORB(Object Request Broker)는 물론, 하부 그룹 통신 프로토콜에서도 그룹 구분자로 사용된다. 호스트 이름(Host Name)은 멤버 자체의 호스트 이름을 나타내며, 객체 키(Object Key)는 특정 객체의 인스턴스(instance)를 나타낸다. 실제로 서버 측의 억셉터는 IOR(Interoperable Object Reference)을 만들기 위한 프로파일 정보를 입력한다. 그룹 IOR의 "ProfileBody"는 IDL로부터 생성된 것이며, "ProfileBody"의 정보는 "add_profile"이라는 함수에 의해 GCIOP의 내용을 바탕으로 채워진다.

도 3은 그룹 통신을 위한 OCI 정보 객체의 IDL 명세서(specification)를 나타낸 도면으로, 그룹 통신 OCI 부분의 모든 구성 요소들인 커넥터, 커넥터 팩토리, 억셉터, 트랜스포트는 각각의 정보 객체를 가지고 있다. 모든 정보 클래스들은 기존 OCI의 정보 클래스로부터 상속을 받아 확장된 것이다.

도 4는 그룹 통신을 위한 함수가 추가된 OCI IDL 명세서를 나타낸 도면으로, 그룹 통신 OCI의 억셉터 인터페이스는 애플리케이션 객체(application object)들만이 이용할 수 있다. 기존 OCI의 모든 인터페이스는 변경없이 그대로 사용되며, 본 발명에는 그룹 멤버쉽과 상태 전송을 위한 "create_group, join, leave, set_state, get_state" 함수들만이 억셉터에 추가되었다.

고장 감내와 고 가용성은 객체 복제 기법을 이용하여 지원될 수 있다. 복제된 객체들은 일반적인 작업에 대해 객체 그룹을 형성하여 협동하여 일을 처리한다. 한편 신뢰적이며 고장 감내를 지원하는 분산 애플리케이션을 만들기 위해서는 객체 그룹 멤버들 사이의 상태 일관성이 유지 되어야 한다. 그룹 통신 서비스(Group Communication Service; GCS)는 모든 멤버 객체들 사이의 일관성을 보장하는 데에 있어 유용한 기술이다. 그룹 통신 서비스는 객체 그룹 내에서 현재 연결되어 있는 멤버의 리스트를 뷰(view)로써 관리하며, 뷰 변경이 있을 때마다 최신의 뷰를 유지한다. 여기서 현재 뷰 내에 있는 멤버들에게는 신뢰적 메시지 전송이 보장된다.

한편 코바는 이종의 분산 환경에서 분산된 객체들 간의 통신을 지원하기 위한 이식성(portability) 및 상호 운용성(interoperability)과 같은 특성들을 지원한다. 이런 측면에서 특정 그룹 통신 프로토콜만이 코바에 적용되는 것은 코바 그룹 애플리케이션들의 모든 요구를 만족시킬 수 없었다. 이를 해결하기 위해서는 표준 코바 인터페이스를 통해 다양한 그룹 통신 프로토콜을 적용할 수 있는 일반적인 그룹 통신 프레임웍이 있어야 한다.

일반적으로 코바에서의 그룹 통신 서비스를 지원하는 방법들로는 통합 방식, 서비스 방식, 가로채기 방식으로 나뉘어 진다. 이 방법들의 대표적인 예로는 통합 방식의 "Electra", 서비스 방식의 OGS(Object Group Service), 가로채기 방식의 "Eternal"을 들 수 있다.

"Electra"는 코바의 BOA(Basic Object Adapter)를 확장함으로써 그룹 통신 서비스를 지원하고자 했다. 그룹 멤버쉽은 하부 그룹 통신 시스템에 의존하며, 객체 그룹 추상화(abstraction)를 위해 특정 그룹 참조(group reference)를 새롭게 디자인했다. 사용자들은 ORB의 "Environment" 클래스를 사용하여 동기 호출(synchronous call), 비동기 호출(asynchronous call), 그리고 지연된 동기 호출(deferred synchronous call)과 같은 호출 방법을 조정할 수 있다. 이 시스템은 ORB와 그룹 통신 시스템 사이에 중계 객체 없이 바로 연결이 되어 있으므로, 구현과 성능 측면에서 효율적이라 할 수 있다.

OGS는 그룹 통신을 위한 새로운 코바 객체 서비스로 디자인 되었다. OGS는 "Groupable, GroupAdminitrator, GroupAccessor"로 구성된다. "Groupable"은 멤버 객체가 사용하는 메시지 수신, 그룹 구성 통보, 상태 전송을 위한 인터페이스를 가지고 있으며, "GroupAdministrator"는 "join_group, leave_group"을 위한 인터페이스를 가지고 있다. "GroupAccessor"는 멀티캐스트를 위한 인터페이스를 가지고 있다. 그룹 뷰는 객체 서비스에서 지원하며, 메시지 멀티캐스트 또한 서비스에서 지원한다. 이 방식은 ORB에 대해 독립적이며, 코바 객체 서비스로서 이식성을 보장한다.

"Eternal"과 "Eternal 인터셉터(interceptor)"는 그룹 통신 시스템의 메시지와 관련된 IIOP 메시지를 가로채서 복제 메니저에게 전송한다. 특히 "join/leave 그룹, send/receive" 함수는 "open/close"와 "write/read" 시스템 콜에 매핑된다. 객체 그룹 식별자(object group identifier)는 각 인터페이스 이름으로 구성되며, 그룹 식별자와 인터페이스 이름을 포함한 매핑 테이블은 복제 메니저에 의해 관리된다. 메시지 멀티캐스트는 하부 그룹 통신 시스템에 의해 지원된다. 이 방식은 인터셉터를 이용하기 때문에 ORB를 수정할 필요가 없다.

코바에 TCP/IP 외에 멀티캐스트 프로토콜을 적용한 연구에서는 OCI를 이용해서 IP 멀티캐스트를 코바에 적용했다. OCI는 코바에서 TCP/IP를 대체할 수 있는 인터페이스를 제공한다. 이 모듈은 클라이언트/서버 모델의 통신에서 연결 초기화 부분과 통신 부분을 나누어 놓은 것이다. 코바는 전송 수준(transport layer)에 대해 연결 지향(connection oriented), 신뢰적 데이터 전송(reliable data transport), 스트림으로 전송되는 데이터(transported data as a stream), 연결 손실에 대한 통지(notification of connection loss)를 만족해야 한다고 정하고 있다. 이에 따라 IP 멀티캐스트를 코바에 적용할 때, 긍정 응답(acknowledgement)과 소실된 패킷에 대한 재전송(retransmission) 기능을 추가하였다. 그리고 IOR에 IP 멀티캐스트 주소(D class)와 시퀀스 번호를 추가하였다.

마지막으로 MGIOP(Multicast Group Internet Inter-ORB Protocol) 엔진에 대한 내용이 MGIOP 명세서에 제안되었다. MGIOP는 그룹 ID와 도메인 ID를 포함하며, 특히 GIOP(General Inter-ORB Protocol) 메시지 자체를 포함하고 있다.

통합 방식에서 그룹 통신 서비스 모듈은 ORB에 통합되기 때문에, 그룹 참조와 그룹 관리(group management)를 지원하기 위해 ORB를 수정해야 한다는 단점이 있다. 서비스 방식은 코바의 점대점 통신인 GIOP(General Inter-ORB Protocol)를 활용하여 ORB 위에서 객체 서비스로써 그룹 통신을 지원하지만, 기존의 그룹 통신 프로토콜을 활용할 수 없으며, 성능 측면에서 비효율적이라는 단점을 가지고 있다. 가로채기 방식은 인터셉터를 이용하여 그룹 통신과 관련된 시스템 콜을 가로 챔으로써 그룹 통신 서비스를 지원하는데, 인터셉터가 시스템 콜의 인터페이스와 그룹 통신 서비스의 인터페이스를 대응시킨다는 점에서 OS(Operating System, 운영체제)에 종속된다는 단점이 있다. 또한 코바와 그룹 통신 서비스를 연결하기 위한 인터셉터가 코바의 일부가 아니기 때문에, 코바 객체가 하부 그룹 통신 서비스를 바로 활용 할 수 없다. 결론적으로 기존의 방식들은 코바에 그룹 통신 프로토콜을 지원하기 위한 인터페이스를 제공하지 않으며, 애플리케이션 프로그래머들은 프로토콜을 바로 활용할 수 없었다.

코바에 TCP/IP 외에 멀티캐스트 프로토콜을 적용한 연구에서는 Java IP 멀티캐스트 API를 그룹 함수로써 직접 이용하기 때문에 동적 그룹 멤버쉽을 지원하지 않으며, 코바에서 다양한 그룹 통신 프로토콜을 적용할 수 없다. MGIOP 엔진은 ORB에 포함되거나 ORB와 연결되어야 하므로, ORB를 수정해야 한다는 단점이 있다.

따라서, 본 발명은 이와 같은 종래 기술의 결점을 해결하기 위하여 안출한 것으로, 상호운용성, 다양한 그룹 통신 프로토콜에 대한 재사용성, ORB와 OS에 대한 독립성을 유지하고, 유연하게 하부 프로토콜을 적용할 수 있는 OCI를 활용하여, 그룹 통신 프로토콜을 적용할 수 있는 프레임웍을 제공하는 코바에서의 그룹 통신 시스템 및 방법을 제공하는 데 그 목적이 있다.

즉, 본 발명에서는 상호운용성, 기존의 다양한 그룹 통신 프로토콜에 대한 재사용성, ORB와 OS에 대한 독립성을 유지하고, 유연하게 하부 프로토콜을 적용할 수 있는 OCI를 활용하여, 기존의 코바를 수정하기 않고 그룹 통신 프로토콜을 적용할 수 있는 프레임웍을 제안한다. 기존의 OCI에 객체 그룹을 관리하고, 그룹으로의 메쏘드 호출(invocation)을 지원하기 위해 새로운 함수들을 추가한다. 이와 함께 GIOP의 그룹 통신 인스턴스인 GCIOP를 정의한다. 구체적으로 그룹 통신 정보 객체를 OCI에 추가하고, 그룹 함수 지원을 위해 OCI의 인터페이스를 확장한다. 기존의 OCI는 커넥터, 커넥터 팩토리, 억셉터, 트랜스포트 모듈로 구성된다. 그룹 통신에서는 기본적으로 그룹 주소(group addressing), 메시지 전송 순서화(message delivery ordering), 상태 전송(state transfer)의 지원이 요구된다. 고장 감내를 제외한 이러한 요구 사항들을 만족시키기 위해, 그룹 이름, 순서화 종류, 상태 정보를 정보 객체에 저장한다. 그리고 순서화 종류를 조정하기 위해 커넥터의 트랜스포트 정보 객체에 순서화 종류를 나타내는 애트리뷰트(attribute)와 억셉터 객체에 그룹 함수 인터페이스를 추가했다. 이러한 과정을 통해 본 발명에서 제안하는 디자인에는 ORB와 OCI의 수정없이 다양한 그룹 통신 프로토콜을 적용될 수 있다.

이와 같은 목적을 달성하기 위한 본 발명은, 네트워크를 통해 연결된 클라이언트 및 다수의 서버를 구비한 코바에서의 그룹 통신 시스템에 있어서, 상기 클라이언트는 제 1 그룹 통신 OCI의 응용을 제어하는 제 1 애플리 케이션 객체; 상기 제 1 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 1 ORB; 및 각각의 정보 객체를 가지고 있는 커넥터 팩토리, 커넥터, 커넥터트랜스포트를 구비하여 상기 제 1 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 1 그룹 통신 OCI를 포함하는 것을 특징으로 한다.

도 1은 본 발명에 따른 코바에서의 그룹 통신 시스템의 일 실시예를 나타낸 블록도,

도 2는 확장 OCI를 이용하여 그룹 통신 프로토콜로 통신할 때 사용하는 GCIOP의 "Tagged Profile" 형식을 나타낸 개략도,

도 3은 그룹 통신을 위한 OCI 정보 객체의 IDL 명세서를 나타낸 도면,

도 4는 그룹 통신을 위한 함수가 추가된 OCI IDL 명세서를 나타낸 도면,

도 5는 도 1에 도시된 시스템의 전체 구조를 도식적으로 세분화하여 나타낸 도면,

도 6은 도 1에서 실제 구현에 사용된 GCIOP 함수들의 인터페이스를 나타낸 도면,

도 7은 도 1에서 그룹 구성을 위해 호출되는 함수들의 상호작용을 나타낸 도면,

도 8은 도 1에서 클라이언트가 그룹에 연결하는 과정을 나타낸 도면,

도 9는 도 1에서 클라이언트가 그룹 객체를 실행하는 과정을 나타낸 도면,

도 10은 도 1에서 클라이언트와 서버 측에서 그룹 통신 OCI를 이용하여 초기화 하는 과정을 나타낸 도면.

이하, 이와 같은 본 발명의 실시 예를 상세히 설명하면 다음과 같다.

본 발명은 전송 수준 프로토콜 교체를 위한 인터페이스로써 포터블 인터셉터의 한 부분인 네트워크 수준 인터셉터(network-level interceptor)를 이용하고자 했다. 그러나, 현재 인터셉터 명세서에서는 네트워크 수준 인터셉터에 대해 아직 명확히 정의하지 않았다. 한편 네트워크 수준 인터셉터 외에 이와 비슷한 기능을 하는 방법으로 OCI와 MGIOP를 들 수 있다. OCI는 IN/CORBA 명세서에서 제안된 것으로 다양한 전송 프로토콜을 투명하게 적용할 수 있는 방법이다. 예를 들어, "Halteren"은 코바에 OCI를 이용하여 IP 멀티캐스트 프로토콜을 적용했다. MGIOP는 GIOP를 멀티캐스트 그룹 통신 프로토콜에 대응시킨 방법으로, MGIOP 엔진은 동시에 여러 개의 그룹 통신 프로토콜을 지원할 수 있다. 그러나 이 엔진이 ORB에 포함되거나 ORB에 연결되어야 하므로, 엔진을 이용하기 위해서는 ORB의 수정이 필요하다는 단점이 있었다. 이에 본 발명에서는 이식성 측면에서 OCI가 MGIOP보다 그룹 통신을 적용하는 데에 더 적합하다고 판단하여 OCI를 이용했다.

그룹 통신을 위한 OCI 확장에 대해 보면 다음과 같다.

먼저, 코바 객체에 그룹 통신 서비스를 적용하기 위해서는 그룹 주소, 그룹 멤버쉽(group membership), 순서화(ordering)의 3가지 측면이 고려되어야 한다. 본 발명에서는 하부 그룹 통신 프로토콜이 메시지에 대해 신뢰성 있는 전송을 보장한다고 가정한다. 그룹 주소는 클라이언트가 그룹을 하나의 객체와 같이 인식하게 하도록 투명성을 보장한다. 여기서 제안하는 OCI 확장은 그룹 통신 프로토콜에서 제공하는 그룹 구별자를 사용하여 그룹 객체 레퍼런스를 만든다. 그룹 객체 레퍼런스는 IOR로써 표현되며 OCI의 트랜스포트에 그룹 구별자를 확장한다. 클라이언트는 IOR에 있는 정보를 참조하여 그룹으로 통신을 위한 연결을 할 수 있다. GIOP가 종단(end-point)의 정보인 그룹 주소를 가지고 있지 않는 추상적인 프로토콜이기 때문에, 통신을 할 때에는 GIOP에 호환되는 프로토콜이 필요하다. 실제로 TCP/IP를 전송 프로토콜로 사용하는 경우에는 IIOP를 구현해서 사용한다. 이에 본 발명에서는 그룹 통신을 지원하기 위해 GIOP에 대한 구현 프로토콜인 GCIOP를 정의했다.

그룹 멤버쉽에서는 그룹 내의 멤버들 사이의 일관성 유지를 위해 멤버 뷰를 관리한다. 이에 확장한 인터페이스에서는 그룹 초기화, 소멸, 가입, 탈퇴 등의 그룹 함수를 제공한다. 실제로 이 함수들은 OCI의 억셉터에 추가된다. 상태 전송 인터페이스는 억셉터를 통해 제공되며, 상태의 정보는 코바 객체 타입으로 억셉터 정보 객체에 저장된다.

순서화는 하나 이상의 클라이언트들이 그룹과 통신할 때 멤버들 사이의 일관성을 유지하기 위해 필요한 요소이다. 클라이언트는 트랜스포트 정보에 있는 순서화 타입의 값을 변경함으로써 순서화 타입을 조정할 수 있다. 여기서 기본 순서화 값은 전 순서화(total ordering)로 한다.

도 1은 본 발명에 따른 코바에서의 그룹 통신 시스템의 일 실시예를 나타낸 블록도로, 코바에서의 하부 그룹 통신 프로토콜과 확장 OCI 구조를 보여준다.

먼저, 그룹 IOR에 대해 설명하면 다음과 같다.

먼저, 기존의 코바에서 서버 객체가 ORB에서 제공하는 IOR에 의해 표현되는것처럼, 코바그룹 통신에서 그룹을 식별하기 위해 그룹 통신 OCI는 그룹 IOR을 제공한다. 서버 측의 객체가 활성화 되었을 때, 코바는 IP 주소와 포트 번호와 같은 전송 정보를 포함한 IOR을 만든다. 이와 같이 그룹 IOR은 그룹 이름과 각 멤버의 호스트 이름을 포함한다. IOR은 서버 측에서 초기 실행 시 만들어 지며, 클라이언트 애플리케이션 객체에 의해 분석된다. IOR은 "Type ID, Profile Count, Tagged Profile"로 구성된다. "Type ID"는 객체의 IDL 기반으로 저장소 ID 형식(repository ID format)에서 IOR의 인터페이스 형식을 제공한다. "Profile Count"는 "Tagged Profile"의 수를 의미한다. "Tagged Profile"은 IOR에 하나 이상 존재할 수 있으며, 통신에 이용되는 프로토콜의 정보를 포함하고 있다.

OCI 정보구조에 대해 설명하면 다음과 같다.

먼저, 그룹 통신 OCI 부분의 모든 구성 요소들인 커넥터, 커넥터 팩토리, 억셉터, 트랜스포트는 각각의 정보 객체를 가지고 있다. 모든 정보 클래스들은 기존 OCI의 정보 클래스로부터 상속을 받아 확장된 것이다. 이것은 OCI에 다양한 프로토콜을 접합 시킬 수 특징에 의한 것이다. 도 4는 그룹 통신을 위한 OCI 정보 클래스의 IDL 명세서이다. ConnectorInfo는 그룹 이름을 저장하고 있으며, 커넥터는 메시지가 그룹에 보낼 때 ConnectorInfo를 사용한다. ConnectorInfo는 클라이언트 측의 OCI로 관리한다.

서버 측의 OCI는 그룹 이름과 호스트 이름을 가지고 있는 AcceptorInfo를 관리한다. 그룹 이름은 서버가 그룹을 만들거나 가입할 때 사용하는 것이며, 호스트 이름은 서버 자체의 호스트 이름을 나타낸다. 그룹 및 호스트 이름은 도 2의 GCIOP프로파일 정보를 만들 때 사용된다. 상태는 그룹 멤버의 상태를 나타내며, 새로운 멤버가 그룹에 가입 했을 때 상태 전송을 위해 사용된다. TransportInfo는 커넥터와 억셉터가 자신의 트랜스포트 객체를 생성 했을 때 클라이언트와 서버 양 쪽에서 사용된다. 커넥터와 억셉터는 TransportInfo에 같은 그룹 이름을 가지고 있다. 클라이언트 객체는 커넥터의 TransportInfo에 있는 ordering_type의 값을 변경함으로써, 메시지 전송에 적용되는 순서화 타입을 변경할 수 있다.

그룹 통신 서비스를 위한 인터페이스에 대해 설명하면 다음과 같다.

먼저, 도 4에서 그룹 통신을 위한 함수가 추가된 OCI의 IDL 명세서를 볼 수 있다. 그룹 통신 OCI의 억셉터 인터페이스는 애플리케이션 객체들만이 이용할 수 있다. 기존 OCI의 모든 인터페이스는 변경없이 그대로 사용된다. 그룹 멤버쉽과 상태 전송을 위한 "create_group, join, leave, set_state, get_state" 함수들만이 억셉터에 추가되었다. 그룹 생성 후, 첫번 째 서버는 프라이머리 멤버로 그룹 주소값을 제공한다. 이에 다른 멤버들은 기존의 그룹에 가입 또는 탈퇴할 수 있으며, 이들이 그룹에 가입했을 때 상태 전송이 실행된다.

본 발명에서 제안하는 시스템은 그룹 통신 프로토콜, ORB, 확장된 OCI로 구성된다. 하부 그룹 통신 프로토콜인 FTGCS(Fault Tolerant Group Communication Service)는 그룹 통신 컴포넌트와 그룹 멤버쉽 관리 컴포넌트를 가지고 있다. 그룹 통신 컴포넌트는 네시지 멀티캐스팅과 신뢰적 전송을 지원하며, 그룹 멤버쉽 관리 컴포넌트는 동적으로 멤버쉽 리스트를 관리하며, 그룹 뷰의 일관성을 보장한다. 확장된 OCI는 그룹 멤버쉽, 상태 전송, 순서화, 그룹 IOR, 그룹 통신 컴포넌트에 대한 인터페이스를 지원한다.

도 5는 제안된 시스템 구조이다. 클라이언트 부분은 메시지 전송에 대한 순서화 타입을 설정할 수 있는 순서화 컴포넌트와 그룹에게 멀티캐스트 통신을 지원하는 통신 컴포넌트로 구성된다. 확장된 OCI에서 순서화 컴포넌트와 통신 컴포넌트는 각각 TransportInfo와 트랜스포트 객체에 포함된다. 서버 부분에서 그룹 멤버쉽은 서버 객체가 억셉터의 함수들을 이용해서 그룹을 구성할 수 있게 한다. 상태 전송 컴포넌트는 상태 전송 메커니즘을 지원하며, 그룹 IOR 컴포넌트는 그룹 주소값으로써 그룹 IOR을 만든다. 트랜스포트 객체의 한 부분으로 통신 컴포넌트는 FTGCS를 사용한다. 그리고 OCI에서의 통신은 트랜스 포트 객체들 사이에서 이루어진다.

그룹 멤버는 억셉터의 "create_group(), join()" 함수에서 초기화 된다. 클라이언트 측의 트랜스포트 객체는 커넥터의 "connect()" 함수에서, 서버 측의 트랜스포트 객체는 억셉터의 "accept()" 함수에서 생성된다. 이 후 그룹 멤버는 트랜스포트 객체에 매핑된다. 즉 그룹 통신이 코바의 애플리케이션 객체들에게 제공되는 것이다.

도 6은 도 1에서 실제 구현에 사용된 GCIOP 함수들의 인터페이스를 나타낸 도면으로, 그룹 멤버 컴포넌트에 대해 설명하면 다음과 같다.

먼저, 동적 그룹 멤버쉽을 지원하기 위한 그룹 관리 함수들은 억셉터 객체에서 제공된다. 한편 그룹 뷰와 그룹 멤버들 사이의 일관성 관리는 FTGCS에 의존한다. 객체 애플리케이션이 억셉터의 함수들에 의해 FTGCS의 그룹 멤버에게 연결되었을 때, 함수들은 객체 애플리케이션과 연결할 그룹의 정보가 필요하다. 이에 억셉터의 로컬 변수로써 그룹 이름, 호스트 이름, 하부 그룹 통신 프로토콜의 그룹 멤버의 주소값을 가지고 있으며, 억셉터의 함수들은 이 변수들을 함수의 매개변수로 이용한다. 애플리케이션 객체들이 인식하는 그룹 이름은 하부 그룹 통신 시스템에서의 그룹 이름과 같으며, 스트링 타입의 "group_name_" 변수에 저장된다. 호스트 이름은 객체 애플리케이션이 존재하는 호스트의 이름으로 프로파일 정보를 만드는데 사용되며, 스트링 타입으로 host_ 변수에 저장된다. 그룹 멤버 gm_은 FTGCS의 그룹 멤버를 가리킨다. 이 값은 함수의 매개변수로써 트랜스포트 객체에 전달되며, 오직 하나의 트랜스포트 객체에 매핑된다.

억셉터의 함수들은 억셉터의 IDL 명세서에 언급되었듯이 그룹 멤버쉽과 상태 전송, 멤버들 사이의 통신을 지원한다. 이 함수들에서는 FTGCS의 해당 함수들을 호출한다. 예를 들어, 그룹 함수에 해당하는 억셉터 함수들은 'gm_.Create_group (group_name_);, 'gm_.Join (group_name_)', 'gm_.Leave ()'를 호출한다. 상태 전송 함수 또한 FTGCS의 해당 함수인 'set_state (org.omg.CORBA.Object state)', 'get_state ()'를 호출한다.

순서화 컴포넌트에 대해 설명하면 다음과 같다.

먼저, ConnectorTransportInfo와 AcceptorTransportInfo의 차이점은 GCIOP TransportInfo 객체에서 순서화 설정 여부이다. ConnectorTransportInfo 객체에서만 애플리케이션 프로그래머는 순서화 타입을 설정할 수 있는 함수를 사용할 수 있다. ConnectorTransportInfo는 인과관계 순서화(causal ordering)와 전 순서화(total ordering)를 표시할 수 있는 OrderingType 변수를 가지고 있다.ordering_type() 함수는 OrderingType를 리턴 값으로 가지고 있으며, 이 함수를 이용하여 순서화 타입을 확인 할 수 있다. ordering_type(OrderingType value) 함수는 value 매개변수 값을 value_ 라는 로컬 변수에 저장한다. 실제로 이 값은 트랜스포트 객체에서 메시지 전송 시 적용된다. 트랜스포트의 센드 함수는 실제 하부 그룹 통신 프로토콜의 함수인 SendMessage(buf.data(), info_.ordering_type(), atomic)을 호출 함으로써 메시지 전송을 한다.

그룹 IOR 컴포넌트에 대해 설명하면 다음과 같다.

먼저, 억셉터는 서버 측에서 IOR을 만들기 위해 프로파일 정보를 채워 넣는다. IDL 컴파일러에 의해 생성된 그룹 IOR의 ProfileBody 클래스의 생성자에서는 변수를 초기화 하고, 억셉터의 add_profile 함수에서 ProfileBody의 정보를 완성한다.

통신 컴포넌트에 대해 설명하면 다음과 같다.

먼저, 통신 컴포넌트의 함수들은 코바의 내부 함수들로써 ORB에 의해 요청된다. 트렌스포트 객체들이 클라이언트와 서버 사이의 연결을 완료한 후, 이 객체들은 버퍼 객체에 교환할 메시지의 내용을 담고 send, receive 함수에서는 버퍼 객체를 주고 받음으로써 메시지를 교환한다. 전송되는 데이터는 바이트 스트림이다. 트랜스포트 객체들 사이의 기본 통신은 IIOP이고, 그룹 통신을 위한 인터페이스 또한 같은 이름의 인터페이스를 사용하기 때문에, 하부 통신 프로토콜로 그룹 통신 프로토콜을 사용하더라도 "send_detect, receive_detect, send_timeout, receive_timeout" 함수와 같은 IIOP 기반의 함수들을 구현해야 한다. 이 함수들의내부에서는 하부 그룹 통신 프로토콜인 FTGCS의 "SendMessage(byte[] data, OrderingType ordering, int atomic), Receive()" 함수를 호출한다. ORB의 초기 환경 설정에 따라 "send, receive"에 해당하는 "public void send(OCI.Buffer buf, boolean block), public boolean receive_detect(OCI.Buffer buf, boolean block)" 함수들이 호출된다.

"public void send(OCI.Buffer buf, boolean block)"에 대해 설명하면 다음과 같다.

먼저, 클라이언트와 그룹 사이의 메시지 교환을 위해 사용되는 버퍼 객체는 매개 객체이다. 블록 옵션은 제안된 방법에서는 고려하지 않는다. 이 함수 내부에서 "SendMessage(buf.data(), info_.ordering_type(), atomic)"가 호출되며, buf.data()는 바이트 배열로써 메시지 자체를 의미한다. "info_.ordering_type()"는 순서화 값이며, "atomic" 옵션은 FTGCS의 기본 값을 따른다.

"public boolean receive_detect(OCI.Buffer buf, boolean block)"에 대해 설명하면 다음과 같다.

먼저, "receive_detect" 함수는 클라이언트로부터 보내진 메시지가 FTGCS의 "receive" 큐에 도착했는지를 확인하기 위해 반복적으로 실행된다. 도착한 메시지가 없다면, 이 함수는 FALSE 값을 리턴한다. 한편 도착한 메시지가 있다면, 이 함수에서는 내부적으로 FTGCS의 gm_.Receive()를 호출하고, "TRUE" 값을 리턴한다. 그리고 받은 메시지는 버퍼 객체로 전달된다.

그룹 객체 키에 대해 설명하면 다음과 같다.

먼저, 코바에서의 객체 호출에 있어서 수신자가 메시지를 받았을 때, 이 메시지로 인해 호출되는 객체의 객체 키(object key)가 요청된다. 한편 그룹 통신이 코바에 적용되었을 경우에도, 그룹을 이루고 있는 멤버들 측에 그룹 IOR을 포함하는 객체 키가 요청된다. 본 발명에서는 기존의 일대일 통신에서 사용하는 객체 키를 재사용했다. 그러나 기존의 BOA와 POA 모델에서는 그룹의 모든 객체 구현들을 하나의 객체 키로 표현할 수 없기 때문에, 각 멤버들의 객체들을 구분하지 못한다. 코바에서 그룹 객체 모델을 지원하기 위해서는 그룹 객체 키를 생성하는 새로운 OA가 디자인 되어야 한다. 본 발명에서 제안하는 시스템은 실제 구현에서 클라이언트의 요청 메시지에 포함된 객체 키를 각 멤버의 객체 키로 교체되도록 했다. 여기서 모든 멤버들은 네이밍 서비스와 같은 추가적인 메커니즘을 이용함으로써 자신이 속한 그룹을 대표하는 객체 키를 알고 있다고 가정한다. 모든 멤버들의 ORB는 자신의 객체 구현에 해당하는 객체 키를 생성하며, 각 멤버들의 GCIOP 트랜스포트는 로컬 변수로써 객체 키를 저장한다. 클라이언트로부터 요청된 메시지가 GCIOP 트랜스포트에 도착했을 때, 멤버들은 도착한 메시지가 현재 가입되어 있는 그룹으로 보내진 것인지를 확인한다. 받은 메시지에 포함되어 있는 객체 키가 대표 객체 키와 같다면, 이는 로컬 객체 키로 교체된다. 이 후 클라이언트에서 요청한 함수가 호출된다.

그룹 멤버쉽 모델은 동적인 그룹 멤버쉽을 제공하고, 그룹 가입/탈퇴 함수, 뷰 변경 메커니즘, 상태 전송 등을 이용하여, 그룹 뷰의 일관성을 보장한다. 그룹 멤버 객체들은 서버 측에서 동작하는데, 서버 측 OCI가 억셉터 객체이므로, 억셉터에서 그룹 구성을 위한 함수들을 제공한다. 이 절에서는 그룹을 만들기 위해 멤버 객체들과 그룹 통신 시스템 사이에 어떤 메시지들이 교환되는지를 살펴본다. 다음으로 새로운 멤버가 가입을 요청했을 때, 상태 전송과 뷰 변경 메커니즘의 과정을 기술한다.

새로운 그룹을 만들고 처음 가입하는 멤버를 프라이머리 멤버라 가정한다. 각각의 멤버들은 뷰 변경 통지 메시지(view-change notification message)를 받았을 때, 자신의 뷰 정보를 프라이머리 멤버에게 보고한다. 이 후 모든 멤버들은 그룹 뷰의 일관성을 담당하는 프라이머리 멤버로부터 뷰 인스톨 메시지(view-install message)를 기다린다. 한편 프라이머리 멤버는 모든 멤버들로부터 동일한 뷰 정보를 받았을 때, 뷰 설치 메시지를 멀티캐스트 한다. 본 발명에서 제안한 메커니즘에서 프라이머리 멤버 객체는 그룹 통신 시스템의 함수와 일치되는 억셉터의 함수들을 사용할 수 있다. 뷰 변경 메커니즘은 뷰 설치 메시지를 받음으로써 완료된다. 이 과정을 통해서 억셉터는 하부 그룹 통신 시스템에 있는 그룹 멤버의 주소값을 가지고 있으며, 서버 객체들은 전송 프로토콜에 연결되어 있다.

도 7은 도 1에서 그룹 구성을 위해 호출되는 함수들의 상호작용을 나타낸 도면이다. 현재 만들고자 하는 그룹은 존재하지 않는다고 가정하자. 프라이머리 멤버 객체는 억셉터의 만들고자하는 그룹 함수 예로, create_group() 함수를 호출한다(1). create_group() 함수는 내부적으로 그룹 통신 시스템의 그룹 생성을 요청하고, 그룹에 가입한다(2). 하부 그룹 통신 시스템이 뷰 인스톨 메시지를 받았을 때, 그룹 멤버의 주소값은 억셉터에게 전달되고(3), 그룹 생성 과정은 끝난다.

새로운 멤버가 그룹에 가입하려 할 때, 상태 전송 메커니즘이 요구된다. 새로운 멤버 객체가 억셉터의 join()을 호출하면(4), 하부 그룹 통신 시스템에도 멤버로써 가입하게 된다(5). 뷰 변경 메시지를 보내기 전에 상태 전송은 실행된다. 여기서 상태 전송은 멤버의 상태가 애플리케이션에 의존적인 데이터이므로 추가적으로 요구된다. 하부 그룹 통신 시스템은 프라이머리 멤버의 억셉터 내 get_state() 함수를 이용하여 현재 멤버의 상태를 받아온 후(6), set_state() 함수를 이용하여 새로운 멤버에게 상태를 전달한다(7). 마지막으로 시스템은 모든 멤버에게 뷰 변경 메시지를 멀티캐스트 한다(8).

본 발명에서 제안하는 시스템의 통신 모델은 일대다(one-to-many) 통신이며, 이에 하나의 클라이언트가 그룹을 형성하고 있는 다수의 서버들에게 메시지를 전송한다. 클라이언트와 그룹 사이의 연결은 클라이언트의 커넥터와 그룹의 억셉터에 의해 이루어진다. 연결이 완료된 후, 하나의 커넥터와 다수의 억셉터는 각각 트랜스포트 객체를 생성하며, 통신은 트랜스포트 객체들 사이에서 멀티캐스트로 이루어진다. 하기에 클라이언트와 그룹 사이의 연결을 위해 전송되는 메시지와 객체 호출(object invocation)을 위해 교환되는 메시지에 대해 기술한다.

도 8은 도 1에서 클라이언트가 그룹에 연결하는 과정을 나타낸 도면이다. 서버 측의 ORB는 억셉터의 accept() 함수를 호출한다(1). 이에 억셉터는 자신이 사용할 수 있는 전송 프로토콜에서 요청 메시지 수신을 위해 대기한다(2). 클라이언트는 IOR에 포함되어 있는 원격 객체 주소값(remote object reference)을 클라이언트 측에 있는 로컬 프락시(local proxy)에 등록하고(3), 클라이언트 측의 ORB는 커넥터의 connect() 함수를 호출한다(4). 커넥터는 그룹 주소값을 이용하여 그룹에 연결을 위해 접촉(contact)한다(5). 이 후 그룹 통신 시스템은 커넥터와 억셉터에게 연결 완료에 해당하는 통지(notification) 메시지를 전달한다(6). 클라이언트와 서버 그룹 측에 있는 커넥터와 억셉터는 각각 트랜스포트 객체를 생성하고, 커넥터와 억셉터가 포함하고 있는 그룹 멤버 주소값들을 트랜스포트에 전달한다(7). 클라이언트와 그룹 사이의 통신은 트랜스포트 객체 사이에서 이루어진다.

클라이언트가 ORB를 통해 원격 객체를 실행시킬 때, 기본적으로 하위 수준 통신은 메시지 전송(message passing) 방식이다. 그룹 통신에서 데이터 전송의 순서화는 실행 때마다 변경할 수 있어야 한다.

도 9는 도 1에서 클라이언트가 그룹 객체를 실행하는 과정을 나타낸 도면이다. 제안된 시스템에서 클라이언트는 TransportInfo 클래스의 ordering_type 함수를 이용해서 순서화 타입을 결정할 수 있다(3). 이 후 클라이언트가 서버 측의 객체 실행을 요청한다면(4), 클라이언트 측의 ORB는 트랜스포트의 send() 함수를 호출하고(5), 메시지는 그룹 통신 시스템의 SendMessage() 함수를 통해 그룹에게 전송된다(6).

서버 측의 ORB는 연속적으로 트랜스포트 객체의 receive_detect() 함수를 이용해서 메시지의 도착을 조사한다(1). receive_detect() 함수는 불린(boolean) 값을 리턴한다. 즉, 리턴 값이 참이면, 서버는 receive_detect() 함수의 매개변수로 버퍼 객체를 사용함으로써 메시지를 받는다. 한편 거짓 값을 받으면, (1), (2), (7), (8) 과정을 반복한다. 결국 ORB는 서버 객체에게 요청을 전달하고, 객체 실행이 완료된다(9).

초기화 과정에서 클라이언트 객체와 서버객체는 그룹 통신 OCI 객체를 ORB에 끼워넣기 위한 초기화 객체를 호출한다. 초기화 객체는 객체 어댑터(object adapter; OA)의 존재 유무에 따라 클라이언트 객체인지 서버 객체인지를 구분하며, 서버 측에서 객체 어댑터 주소값을 매개변수로써 초기화 객체에게 전달한다. 초기화 객체는 기본 ORB 정책(policy)을 그룹 통신 정책으로 설정한다.

서버 측에서 그룹 통신을 위한 새로운 GCIOP 억셉터가 OCI에 추가되어야 한다. OA 관리자는 get_acc_registry 함수를 이용하여 억셉터 레지스트리에 접근할 수 있다. 새로운 억셉터는 생성 후, 억셉터 레지스트리의 add_acceptor 함수로 ORB에 추가된다. 클라이언트 측에서 커넥터 팩토리는 생성 후, ORB에서 제공하는 커넥터 팩토리 레지스트리에 의해 추가된다. 서버는 OA와 억셉터 리지스트리를 통해 기본적인 억셉터의 주소값을 얻을 수 있다. 이에 억셉터 주소값은 IDL 컴파일러로 생성된 함수인 GCIOP.AcceptorHelper의 "narrow" 함수를 이용해 GCIOP 억셉터에 매핑된다. 이 후 GCIOP 억셉터의 create_group 함수가 호출되고, OA는 IOR를 만든다. 여기서 우리는 처음 그룹에 가입하는 멤버가 IOR을 만든다고 가정한다.

OA가 활성화 되고 클라이언트로부터의 접촉 요청을 받으면, 억셉터는 트랜스포트를 만든다. 트랜스포트는 하부 그룹 통신 서비스의 프로세스 그룹 멤버를 초기화한다. 여기서 주 개념은 서버 객체의 트랜스포트를 프로세스 그룹 멤버에게 매핑하는 것이다. 새로운 그룹 멤버가 기존 그룹에 가입할 때에는 기존 멤버의 상태(state)를 새로운 멤버에게 전송한다. 서버는 GCIOP 억셉터의 get_state 함수와 set_state 함수를 이용하여, 상태를 얻거나 설정할 수 있다. 상태 정보는 객체 타입으로 AcceptorInfo에 저장된다.

클라이언트가 초기화 된 후에는 ORB의 커넥터 팩토리 레지스트리가 커넥터 팩토리를 만든다. GCIOP 커넥터 팩토리를 추가하기 위해, 커넥터 팩토리 주소값은 GCIOP 커넥터 팩토리의 주소값에 연결되어져야 한다. 커넥터 팩토리는 IOR의 정보를 통해 커넥터를 생성하고, 커넥터는 트랜스포트를 생성한다. 클라이언트는 GCIOP 커넥터 TransportInfodml OrderingType 변수를 사용하여 순서화 타입을 설정할 수 있다.

도 10은 도 1에서 클라이언트와 서버 측에서 그룹 통신 OCI를 이용하여 초기화 하는 과정을 나타낸 도면이다.

먼저, 클라이언트(1) 측의 초기화 과정을 보면 다음과 같다.

커넥터 팩토리 레지스트리를 얻는다(1). GCIOP 커넥터 팩토리를 생성한다(2). 커넥터 팩토리를 커넥터 팩토리 레지스트리에 추가한다(3). 커넥터 팩토리를 생성한다(4). GCIOP 커넥터를 생성한다(5). GCIOP 트랜스포트와 GCIOP ConnectorTransportInfo를 생성한다(6). 그룹 통신 프로토콜에서 클라이언트를 초기화 한다(7).

다음, 서버(1) 측의 초기화 과정을 보면 다음과 같다.

억셉터 레지스트리를 얻는다(a). GCIOP 억셉터를 생성한다(b). 억셉터를 억셉터 레지스트리에 추가한다(c). 억셉터를 생성한다(d). GCIOP 트랜스포트와 GCIOP AcceptorTransportInfo를 생성한다(e). 그룹 통신 프로토콜에서 그룹 멤버를 초기화 한다(f).

이상에서 설명한 바와 같이 본 발명에 있어서 OCI를 이용한 코바에서의 그룹 통신 기법은 OS에 독립적인 것은 물론, ORB와 OCI의 수정없이 기존의 다양한 그룹 통신 프로토콜을 적용할 수 있다. 따라서, 현재 많이 연구되고 있는 고장감내 코바에서도 즉시 활용될 수 있는 효과가 있다.

Claims (5)

1. 네트워크를 통해 연결된 클라이언트 및 다수의 서버를 구비한 코바에서의 그룹 통신 시스템에 있어서,

   상기 클라이언트는 제 1 그룹 통신 OCI의 응용을 제어하는 제 1 애플리 케이션 객체;

   상기 제 1 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 1 ORB; 및

   각각의 정보 객체를 가지고 있는 커넥터 팩토리, 커넥터, 커넥터트랜스포트를 구비하여 상기 제 1 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 1 그룹 통신 OCI를 포함하는 코바에서의 그룹 통신 시스템.
2. 제 1 항에 있어서,

   상기 각 서버는 제 2 그룹 통신 OCI의 응용을 제어하는 제 2 애플리 케이션 객체;

   상기 제 2 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 2 ORB; 및

   각각의 정보 객체를 가지고 있는 억셉터, 억셉터트랜스포트를 구비하여 상기 제 2 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 2 그룹 통신 OCI를 포함하는 코바에서의 그룹 통신 시스템.
3. 네트워크를 통해 연결된 클라이언트 및 다수의 서버를 구비하되,

   상기 클라이언트는 제 1 그룹 통신 OCI의 응용을 제어하는 제 1 애플리 케이션 객체; 상기 제 1 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 1 ORB; 및 각각의 정보 객체를 가지고 있는 커넥터 팩토리, 커넥터, 커넥터트랜스포트를 구비하여 상기 제 1 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 1 그룹 통신 OCI를 포함하고,

   상기 각 서버는 제 2 그룹 통신 OCI의 응용을 제어하는 제 2 애플리 케이션 객체; 상기 제 2 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 2 ORB; 및 각각의 정보 객체를 가지고 있는 억셉터, 억셉터트랜스포트를 구비하여 상기 제 2 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 2 그룹 통신 OCI를 포함하는 코바에서의 그룹 통신 시스템에서 그룹 통신 방법에 있어서,

   그룹 구성을 위해 호출되는 함수들의 상호작용은, 새로운 그룹을 만들기 위한 억셉터의 그룹 함수를 호출하는 제 31 단계;

   상기 억셉터의 그룹 함수가 내부적으로 그룹 통신 시스템의 그룹 생성을 요청하고, 그룹에 가입하는 제 32 단계;

   하부 그룹 통신 시스템이 뷰 인스톨 메시지를 받았을 때, 그룹 멤버의 주소값은 억셉터에게 전달되고, 그룹이 생성되는 제 33 단계;

   새로운 멤버 객체가 그룹에 가입하기 위한 억셉터의 함수를 호출하는 제 34 단계;

   하부 그룹 통신 시스템에도 멤버로써 가입하게 되는 제 35 단계;

   하부 그룹 통신 시스템은 프라이머리 멤버의 억셉터 내 상태 함수를 이용하여 현재 멤버의 상태를 받아오는 제 36 단계;

   상태 함수를 이용하여 새로운 멤버에게 상태를 전달하는 제 37 단계; 및

   모든 멤버에게 뷰 변경 메시지를 멀티캐스트하는 제 38 단계를 포함하는 코바에서의 그룹 통신 방법.
4. 네트워크를 통해 연결된 클라이언트 및 다수의 서버를 구비하되,

   상기 클라이언트는 제 1 그룹 통신 OCI의 응용을 제어하는 제 1 애플리 케이션 객체; 상기 제 1 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 1 ORB; 및 각각의 정보 객체를 가지고 있는 커넥터 팩토리, 커넥터, 커넥터트랜스포트를 구비하여 상기 제 1 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 1 그룹 통신 OCI를 포함하고,

   상기 각 서버는 제 2 그룹 통신 OCI의 응용을 제어하는 제 2 애플리 케이션 객체; 상기 제 2 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 2 ORB; 및 각각의 정보 객체를 가지고 있는 억셉터, 억셉터트랜스포트를 구비하여 상기 제 2 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 2 그룹 통신 OCI를 포함하는 코바에서의 그룹 통신 시스템에서 그룹 통신 방법에 있어서,

   상기 클라이언트가 그룹에 연결하는 과정은, 서버 측의 ORB가 그룹 연결을 위한 억셉터의 함수를 호출하는 제 41 단계;

   억셉터가 자신이 사용할 수 있는 전송 프로토콜에서 요청 메시지 수신을 위해 대기하는 제 42 단계;

   상기 클라이언트가 IOR에 포함되어 있는 원격 객체 주소값을 클라이언트 측에 있는 로컬 프락시에 등록하는 제 43 단계;

   클라이언트 측의 ORB가 커넥터의 커넥트 함수를 호출하는 제 44 단계;

   커넥터가 그룹 주소값을 이용하여 그룹에 연결을 위해 접촉하는 제 45 단계;

   그룹 통신 시스템은 상기 클라이언트와 서버 그룹 측에 각각 있는 커넥터와 억셉터에게 연결 완료에 해당하는 통지 메시지를 전달하는 제 46 단계; 및

   상기 클라이언트와 서버 그룹 측에 각각 있는 커넥터와 억셉터는 각각 트랜스포트 객체를 생성하고, 각각 포함하고 있는 그룹 멤버 주소값들을 트랜스포트에 전달하는 제 47 단계를 포함하는 코바에서의 그룹 통신 방법.
5. 네트워크를 통해 연결된 클라이언트 및 다수의 서버를 구비하되,

   상기 클라이언트는 제 1 그룹 통신 OCI의 응용을 제어하는 제 1 애플리 케이션 객체; 상기 제 1 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 1 ORB; 및 각각의 정보 객체를 가지고 있는 커넥터 팩토리, 커넥터, 커넥터트랜스포트를 구비하여 상기 제 1 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 1 그룹 통신 OCI를 포함하고,

   상기 각 서버는 제 2 그룹 통신 OCI의 응용을 제어하는 제 2 애플리 케이션 객체; 상기 제 2 애플리 케이션 객체의 그룹 통신을 위한 제어에 따라 코바의 내부 함수인 다수의 통신 컴포넌트의 함수를 선택적으로 요청하는 제 2 ORB; 및 각각의 정보 객체를 가지고 있는 억셉터, 억셉터트랜스포트를 구비하여 상기 제 2 ORB와 상기 네트워크 사이에서 그룹 통신을 위한 다수의 전송 프로토콜을 선택적으로 적용하는 제 2 그룹 통신 OCI를 포함하는 코바에서의 그룹 통신 시스템에서 그룹 통신 방법에 있어서,

   상기 클라이언트가 그룹 객체를 실행하는 과정은, 상기 클라이언트가 전송정보 클래스의 순서화 타입 함수를 이용해서 순서화 타입을 결정하는 제 51 단계;

   상기 클라이언트가 서버 측의 객체 실행을 요청하는 제 52 단계;

   상기 클라이언트 측의 ORB는 트랜스포트의 송신 함수를 호출하는 제 53 단계;

   그룹 통신 시스템의 송신 메시지 함수를 통해 그룹에게 메시지를 전송하는 제 54 단계;

   서버 측의 ORB가 연속적으로 트랜스포트 객체의 수신검출 함수를 이용해서 메시지의 도착을 조사하는 제 55 단계;

   상기 단계 55의 조사 결과, 수신검출 함수에 의해 리턴된 된 불린값이 참이면 수신검출 함수의 매개변수로 버퍼 객체를 사용함으로써 메시지를 받는 제 56 단계; 및

   상기 단계 55의 조사 결과, 수신검출 함수에 의해 리턴된 된 불린값이 거짓이면 ORB가 서버 객체에게 요청을 전달하고, 객체 실행이 완료되는 제 57 단계를 포함하는 코바에서의 그룹 통신 방법.