본문 바로가기

Dev.../CORBA관련 자료

IOR(Interoperable Object Reference)

1. IOR (Interoperable Object Reference)

 

(1) IOR에 대한 간단한 설명.

 

CORBA 2.0 이전에는 표준 프로토콜 명세가 존재하지 않았다. 따라서, CORBA 2.0 명세 이전의 제품들은 ORB 간의 상호연동이 불가능하였으며, 각 벤더는 자사만의 프로토콜이 존재하였다. Orbix에서는 POOP라 불리는 프로토콜이 있었다.

CORBA 2.0에서는 ORB간의 상호연동을 가능하게 하는 GIOP(General Inter-ORB Protocol)라는 것을 소개하였는데 GIOP는 실제 프로토콜이 아니라 전송 구문(Transfer Syntax)과 몇가지 표준 메시지 포멧을 정의한 추상적인 프로토콜이었다. GIOP는 연결-지향적(connection-Oriented) 프로토콜을 대상으로 하였다.

IIOP(Internet Inter-ORB Protocol)는 GIOP를 TCP/IP 상에서 동작하도록 구현한 것이며, CORBA 2.0 명세를 구현하였다고 하는 ORB는 IIOP를 지원하여야 하며 실제로 대부분의 ORB들이 IIOP를 지원한다.

ORB 상호연동은 또한 표준화된 객체 참조자 포멧을 필요로 하는데 객체 참조자는 클라이언트와 목표 객체가 서로 간의 통신을 위한 연결 설정을 위한 정보들을 포함하고 있다.

표준화된 객체 참조자 포멧은 IOR(Interoperable Object Reference)이라고 불리며 생각할 수 있는 거의 대부분의 Inter-ORB Protocol에 대한 정보를 수용할 만큼 유연하다.

IIOP를 보면 IOR은 호스트명, TCP/IP 포트번호, 객체 키(Object Key)를 가지고 있으며 객체 키는 각 벤더가 임의로 지정할 수 있다.

 

(2) 서버에서 객체 참조자를 알리는 방법은 다음과 같은 것들이 있을 수 있다.

 

1) 네이밍 서비스(Naming Service)나 트래이딩 서비스(Trading Service)를 통해 알린다.

2) 객체 참조자를 스트링으로 변환해서 이를 파일에 저장한다.

3) 객체 참조자를 E-Mail을 통해 전송하거나 Web 페이지에 올린다. (이를테면 CGI를 이용해 파일을 업/다운 로드의 형태가 있을 수 있다.)

 

(3) IOR에 포함되는 정보

Repository ID(표준), Endpoing Info(표준), Object Key(비표준)

 

1) Repository ID(표준)

- 인터페이스에 대한 정보 => Interface type을 식별하기 위한 repository ID

 

2) Endpoint Info(표준)

- 프로토콜, 물리적 주소(IIOP를 사용하는 경우 IP와 TCP 포트번호)

- 이 부분은 서버 객체의 주소를 바로 가질 수 있지만 대부분의 경우 구현 저장소의 주소를 가지고 있다.

- CORBA에서는 하나의 참조자가 하나 이상의 프로토콜을 지원하는 것을 허용한다. (ORB가 적합한 프로토콜을 선택한다.) 이후의 CORBA는 클라이언트가 프로토콜을 선택하는 것을 가능하게 할 것이다. => 클라이언트 측 ORB가 올바른 목표 주소(서버의 주소)를 찾는데 사용

 

3) Object Key(비표준)

- 이 부분이 어떻게 구성되어 있고 어떤 식으로 사용되고 하는 것은 각 벤더에 달려 있다. 그러나, 모든 ORB들이 서버가 어플리케이션에 특정한 객체 Identifier를 가지는 것을 허용하고 있으며 객체 identifier는 서버 측의 ORB와 객체 어댑터에 의해 서버 내에서 목표 객체를 찾기 위해 사용된다.

- 클라이언트 측에서는 ORB가 런타임에 Object Key 부분은 모든 요청에 binary 데이터 형태로 붙여서 보내기 때문에 소스 코드 레벨에서는 전혀 문제가 되지 않는다.

 

=> 서버 측 ORB가 주소 공간내의(서버 프로세스 내의) 특정 객체를 찾는데 사용

 

 

2. IOR 구조

(1) IOP

 

namespace IOP{

typedef CORBA::ULong ProfileId;

 

const ProfileId TAG_INTERNET_IOP = 0U;

const ProfileId TAG_MULTIPLE_COMPONENTS = 1U;

 

// IDL:IOP/TaggedProfile:1.0

struct TaggedProfile {

ProfileId tag;

CORBA::Octet *profile_data;

 

// SORBA define.

int size;

bool operator=(int);

bool operator!=(int);

};

 

class TaggedProfileHelper {

public :     

static void TaggedProfileHelper::read(IOP::TaggedProfile *_one, stream::GIOPInputStream *_in);

};

 

// IDL:IOP/IOR:1.0

struct IOR {

CORBA::String_var type_id;

TaggedProfile *profiles;

};

 

class IORHelper {

public :    

    static IOP::IOR *read(stream::GIOPInputStream *_in);

};

 

// IDL:IOP/ComponentId:1.0

typedef CORBA::ULong ComponentId;

 

struct TaggedComponent {

ComponentId tag;

CORBA::Octet *component_data;

 

bool operator=(int);

bool operator!=(int);

};

 

class TaggedComponentHelper {

public :    

    static IOP::TaggedComponent read(stream::GIOPInputStream *_in);

};

 

} // End of namespace IOP

 

(2) IIOP

 

namespace IIOP{

 

struct Version {

CORBA::Octet major;

CORBA::Octet minor;

};

class VersionHelper {

public :    

    static Version read(stream::GIOPInputStream *in);

};

 

struct ProfileBody_1_0 {

Version iiop_version;

char *host;

CORBA::UShort port;

CORBA::Octet *object_key;

};

 

class ProfileBody_1_0Helper {

public :    

    static ProfileBody_1_0 *read(stream::GIOPInputStream *in);

};

 

struct ProfileBody_1_1 {

Version iiop_version;

char *host;

CORBA::UShort port;

CORBA::Octet *object_key;

IOP::TaggedComponent *components;

};

 

class ProfileBody_1_1Helper {

public :    

    static ProfileBody_1_1 *read(stream::GIOPInputStream *in);

};

 

struct ListenPoint {

char *host;

CORBA::UShort port;

};

 

typedef ListenPoint* ListenPointList;

 

struct BiDirIIOPServiceContext {

ListenPointList listen_points;

};

 

} // End of namespace IIOP

 

3. 발견된 문제점.

 

1) 일관되지 않은 List 자료구조

- ORB를 id 별로 관리할 ORBList (ORB_id와 ORB_ptr의 쌍을 array로 구현했음)

- ORB_init()시 System Property(service list, property list)를 관리할 PropertyList(array로 구현했음).

 

// property들을 저장할 자료구조 PropertyList

struct Property {

char *key;

char *property;

};

class PropertyList

{

private :

int index;

Property list[30];

 

public :

PropertyList(){ index =0; };

Property *read(int _index);

void write(Property *p);

int size() { return index; };

}; // property들을 저장할 자료구조 PropertyList 끝.

 

-> 수정 방향 : 융통성 있고 확장 가능한 자료구조를 구현하여 사용.

 

2) profile들에 부여한 operator overloading = NULL 문제 ( 무조건 JAVA를 따랐기 때문 )

객체 pointer의 length를 구할 경우 End of pointer를 명시하기위해 operator overloading을 사용 -> 컴파일 시 warning message 발생

 

ex:

// TaggedProfile 의 operator overloading    

bool TaggedProfile::operator=(int n)

{

if(n == NULL) {

tag = 444;

profile_data = NULL;

return true;

}

return false;

}

 

3) 구조적 설계 결여 (각 class간의 관계에 대해 고려하지 않았음, 검증 없이 JAVA의 relationship을 그대로 따랐기 때문) -> 통합 컴파일시 수많은 link error.

 

4) 구현 언어에 대한 문법적인 문제, use case에 대한 이해의 결여

 

 

 

 

 

 

 

 

 

* 동봉한 rose file에 Design Model에 있는 Sequence Diagram과 Class Diagram 참조.

 

 

struct MessageHeader_1_0

{

CORBA::Char magic[4];

Version GIOP_version;

CORBA::Boolean byte_order;

CORBA::Octet message_type;

CORBA::ULong message_size;

};

 

 

MessageHeader_1_0

CORBA::Char

magic[4]

Version GIOP_version 

CORBA::Boolean byte_order

CORBA::Octet message_type

CORBA::ULong

message_size

CORBA::Octet Major

CORBA::Octet Minor

 

 

'Dev... > CORBA관련 자료' 카테고리의 다른 글

[CORBA] POA시나리오 Part 1-3  (0) 2008.10.23
[CORBA] POA시나리오 Part 1-2  (0) 2008.10.23
[CORBA] POA시나리오 Part 1-1  (0) 2008.10.23