브런치

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관련 자료' 카테고리의 다른 글

IOR(Interoperable Object Reference)  (0) 2008.10.23
[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
by 꿈꾸는자의 생각의파편들 2008.10.23 20:53
  1. Interface

    CORBA.PortableServer.POA

    CORBA.PortableServer.POAManager

    CORBA.PortableServer.ServantManager

    CORBA.PortableServer.ServantActivator

    CORBA.PortableServer.ServantLocator

    CORBA.PortableServer.AdapterActivator

    CORBA.PortableServer.ThreadPolicy

    CORBA.PortableServer.LifespanPolicy

    CORBA.PortableServer.IdUniquenessPolicy

    CORBA.PortableServer.IdAssignmentPolicy

    CORBA.PortableServer.ImplicitActivationPolicy

    CORBA.PortableServer.ServantRetentionPolicy

    CORBA.PortableServer.RequestProcessingPolicy

    CORBA.PortableServer.Current

    추가적으로 POA는 Servant native type를 정의한다.

     

    3.1 The Servant IDL Type

    Servant는 CORBA Interface를 Language Mapping로 구현한 것이다.

  • 각각의 Language Mapping는 반드시 Servant가 Object Implementation에 Mapping되는지에 대해서 기술해야 한다.
  • Servant Type는 아래와 같은 특징이 있다.
  1. Servant Type의 값은 CORBA Programmer로부터 감춰진다.

    사용자 Program에서 직접적으로 호출할 Operation이 없다.

    ( 특정 POA Operation의 Parameter로 전달 )

  2. Servant는 ORB와 해당 Servant의 Default POA를 얻는데 필요한 Interface를 제공해야 한다. 이 Interface는 암시적 활성화에 사용된다.
  3. Servant는 표준 Object Reference Operation의 기본 구현을 제공한다.

    ( get_interface, is_a, non_existent )

    이 Operation은 추가적인 행위을 정의하기 위해서 override될 수 있다.

  4. Servant는 반드시 유일성에 대해서 테스트 가능해야 한다.

    ( Values of type Servant must be testable for identity. )

  5. Servant는 그것이 생성된 주소공간이나, Context의 Process 바깥에서는 의미가 없다.

 

 

3.2 POAManager Interface

  1. Processing States

    : active, inactive, holding, discarding로 나누어짐.

    POAManager는 holding State로 생성되고, 그러므로 rootPOA는 holding State로 초기화됨.

     

  • Active State
    • POA Manager에 속한 모든 POA들이 Request를 받고 처리한다.

    : Active 상태에 있어도 POA는 Request를 Queue를 해야 할 것이다

    ( ORB 구현 및 리소스 제한으로 )

    Queue를 하다가 Limit에 도달하면 "TRANSIENT"( Client가 Request를 재전송할 것 ) System Exception 발생

     

  • Discarding State
    • POA Manager에 연관된 모든 POA에 도달하는 모든 Request( Process가 시작된 Request는 제외 )가 무시된다.

    : Request가 Discard되면 "TRANSIENT" System Exception 발생

    : Discarding State의 주된 목적은 Flow-control에 있다.

    : Request의 순서가 정의되어 있을 경우에 사용됨.

    : 처리가 끝난후 POA Manager를 Active State로 되돌리는 것이 요구됨.

 

  • holding State

    : Discarding State 무조건 "TRANSIENT" Exception을 발생시키지만, holding State는 일단 Request를 Queuing을 한다. 그러나 Queue의 Limit를 넘어서게 되면, "TRANSIENT" Exception이 발생한다.

     

  • inactive State

  • Inactive 상태로 전이되는 "deactive" Method의 "etherealize _objects"Parameter가

 

True 이면 : POA Manager에 연관된 POA들은 각각의 POA에 있는 Active Object에 "etherealize"Method를 호출한다.( POA가 RETAIN, USE_SERVANT_MANAGER 정책이라면, 현재 진행중이거나 남아 있는 Request를 완전히 처리하도록 한다. )

 

False이면 : True일때의 행위를 하지 않는다.

 

  1. Locality Constraints

    POA Manager는 다른 Process로 Export되어서는 안되며, 외부로 표현되어서도( ORB.object_to_string ) 안된다. -> MARSHAL Exception 발생.

    POA Manager를 DII와 함께 사용하려는 시도가 있을 경우 -> NO_IMPLEMENT Exception 발생

     

  2. Activate

    Method에 대한 설명 : Spec 참조 ( Chapter:11.3.2.3 Page:11-18 )

  3. Hold_requests

    Method에 대한 설명 : Spec 참조 ( Chapter:11.3.2.4 Page:11-18 )

  4. Discard_requests

    Method에 대한 설명 : Spec 참조 ( Chapter:11.3.2.5 Page:11-19 )

  5. Deactivate

    Method에 대한 설명 : Spec 참조 ( Chapter:11.3.2.6 Page:11-19 )

  6. Get_state

    : 현재의 상태 리턴

     

    3.3 AdapterActivator Interface

    AdapterActivator 각각의 특정 POA에 연관되어 있다.

    POA의 요구에 따라서 ChildPOA를 생성할 수 있는 능력을 제공한다.

    Find_POA가 호출될 때 "Activate" Parameter가 TRUE일 때 호출 된다.

  • Application Server가 실행시에 모든 POA를 생성한다면 Adapter Activator가 필요없다. 단지 Request 처리 도중에 POA의 생성이 필요할 때만 사용된다.
  • 새로운 POA가 생성되는 동안 그 POA로 전달된 모든 Request는 Queuing된다. 이것은 AdapterActivator가 POA를 새로 생성하고 초기화 하는 시간을 준다.

 

  1. Locality Constraints

    POA에 등록되어서 사용되어야만 한다.

  2. unknown_adapter

    Boolean unknown_adapter( in POA parent, in String name );

    해당 POA가 존재하지 않는 Request를 ORB가 받았을 때 실행된다.

     

  • 언제 unknown_adapter가 실행되는가?

1)아래의 그림에서 POA A, B, C, D가 있고, Request는 POA D에 있는 Object를 호출하여야 하며, POA A, B만이 활성화 되어 있다고 가정한다.

2)find_POA Operation이 실행될 때 find_POA의 "activate_it" Parameter가 TRUE일때

 

 

3.4 ServantManager Interface

ServantManager 자체는 비어있으며, ServantActivator( RETAIN Policy )과 ServantLocator( NON_RETAIN Policy )로 상속된다.

역할은 필요에 따라서 Object를 활성화 하는 것이다.

ServantManager는 POA에 등록되며, 필요에 따라서 POA에 의해서 호출 된다.

 

 

 

 

신고

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

IOR(Interoperable Object Reference)  (0) 2008.10.23
[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
by 꿈꾸는자의 생각의파편들 2008.10.23 20:49

2. POA 시나리오

    2.1 POA는 Object ID와 Active Servant를 다룬다.

이 방식에는 몇가지 방법이 있다.

POA정책

POA의 Servant 다루는 방식

RETAIN 

Active Objct Map으로 관리

USE_DEFAULT_SERVANT 

사용자가 등록한 Default Servant 사용

USE_SERVANT_MANAGER 

사용자가 등록한 Servnat Manager 사용

 

  1. POA Creation

        ORB는 기본적인 "rootPOA"를 관리하여야하며, POA를 이용한 구현객체를 만들려고 하는 개발자는 이 POA Object를 획득해야만 한다.

    RootPOA는 아래와 같은 정책을 갖게 된다.

Policy 

RootPOA값

Thread Policy 

ORB_CTRL_MODEL 

Lifespan Policy 

TRANSIENT 

ObjectID Uniqueness Policy 

UNIQUE_ID 

ID Assignment Policy 

SYSTEM_ID 

Servant Retention Policy 

RETAIN 

Request Processing

USE_ACTIVE_OBJECT_MAP_ONLY 

Implicit Activation 

IMPLICIT_ACTIVATION 

 

  • 개발자는 새로운 POA를 생성할 수 있다.

    새로 생성한 POA에 새로운 정책을 설정할 수 있다.

    Adapter Activator과 Servvant Manager를 제공할 수 있다.

    Object의 Name 공간을 구분 지을 수 있다.( Object ID가 연관된 POA에 의해서 해석됨. )

    다양한 Object Set의 Request Processing을 독립적으로 할 수 있다.( 개발자가 )

  • POA Object는 지속적이지 않다.

    ORB에 의해서 POA의 상태가 저장되지 않는다. ( Server Application의 책임이다. )

  • Server Application은 다른 Application에 의해서 사용되는 POA Name와 자신의 POA Name사이에 혼동이 없다고 가정한다. ( 이것은 ORB의 책임이다. : 모든 POA는 유일한 이름을 가져야 한다. )

 

 

  1. Reference Creation

    Object Reference는 Server의 위치, POA Key, Object Key로 이루어진다.

    Reference은 아래와 같은 방식으로 만들어 진다.

    1. create_reference create_reference_with_id : 추상 Object를 만들지만 활성화 되지 않는다.
    2. active_object, active_object_with_id : 객체를 활성화 한다. 이후에 Reference획득은 servant_to_reference 또는 id_to_reference로 한다.
    3. POA( IMPLICIT_ACTIVATION ) : 암시적으로 Servant를 활성화 한다. 비활성화된 Object의 Reference를 얻고자 하는 시도가 있을 경우 POA는 생성된 Object_ID를 Servant에 할당하고, 그 결과로 얻어지는 Object를 활성화 한다.

      Reference획득은 POA.servant_to_reference 또는 servant를 Reference Type로 Conversion함으로써( 이것은 전적으로 Language Mapping에 따른다. ) 얻을 수 있다.

       

    ※ Object Reference는 여러 방법으로 Client에 배포 될 수 있다.( Naming, Trade, String..등등 )

 

2.4 Object Activation State

CORBA Object는 어느 때고 Active Servant와 연관될 수도 아닐 수도 있다.

 

※ POA정책에 따른 Object Activation 변화

  1. POA( RETAIN )

    Server Application이 Object를 등록하면, 해당 Object를 POA는 Active Object Map에 유지한다.

  • active_object, active_object_with_id 를 사용하여 등록하면, POA내에서 Object는 바로 활성화가 된다.
  • set_servant_manager로 Servant Manager를 POA에 설정하면, Client의 Request가 도달하면 POA는 우선 Active Object Map를 찾고, 만약 존재하지 않는 다면 Servant Manager를 호출한다. Servant Manager가 Object를 리턴하면, 이것을 Active Object Map에 유지하며, 그렇지 않으면 Error를 Client로 반환한다.
  • 어떤환경( IMPLICIT_ACTIVATION )에서는 Server Application이 활성화 되지 않은 Object의 Reference를 요청할 경우 POA는 암시적으로 Object를 활성화 한다.
  1. POA( USE_DEFAULT_SERVANT )

    Server Application이 set_servant로 Default Servant를 등록한다.

    이 경우 Client로부터 오는 Request의 ObjectID가 무엇이든지 간에 등록된 Default Servant가 Invoke된다.

  2. POA( NON_RETAIN )

    POA는 활성화 되었던 Object를 Active Object Map에 유지 하지 않는다.

    Server Application은 set_servant나 set_servant_manager로 Default Servant나 Servant Manager를 등록하여야한다.

    POA의 관점에서는 이 정책이 쓰일경우 하나의 Request가 끝나는 동안만 Object는 활성화 된다. 즉 하나의 Request가 처리되면 Object는 제거된다.

 

2.5 Request Processing

 

위의 그림 4번 항목( POA가 Request를 받음. )이후의 동작

  1. POA( RETAIN )
    1. Active Object Map에서 해당 Object를 찾고,
    2. 해당 Object에 Invoke 한다.

     

  2. POA( NON_RETAIN ) or ( RETAIN but NOT Found Object )
    1. POA( USE_DEFAULT_SERVANT )
  • Default Servant is Set : Invoke
  • Default Servant is not Set : OBJ_ADAPTER System Exception 발생
  1. POA( USE_SERVANT_MANAGER )
  • Servant Manager is Set :

Servant Manager의 incarnate 호출 ( POA : NON_RETAIN )

Servant Manager의 preinvoke 호출 ( POA : RETAIN )

  • Servant Manager is not Set : OBJ_ADAPTER System Exception 발생
  1. POA( USE_OBJECT_MAP_ONLY )

 

 

 

  1. Implicit Activation

  • Implicit Activation을 지원하는 Operation들
    • POA.servant_to_reference( Servant ) : reference를 리턴
    • POA.servant_to_id( Servant ) : Object ID를 리턴
    • Language Mapping에 의해서 지원되는 Operation

      ( Ex : C++ è _this() : reference를 리턴 )

    • Language Mapping에 의해서 제공되는 Implicit Conversion

      ( Servant çè reference or Object ID )

  • Language Mapping에 의존적인 2가지 Category

    ( Spec Chapter 11.2.7에 ( Page 11-10 )에 있는 내용.. Spec 참조 )

    

 

 

2.7 Multi-threading

( ORB가 아닌 POA 자체에 대한 Thread Model )

  • ORB의 관련 함수들 : work_pending, perform_work, run, shutdown
  • Thread Policy와 연관됨.

 

  1. Single Thread Model

        : Request가 순차적으로 POA에서 실행된다.

 

  1. ORB Controlled Model

        : ORB에서 제공하는 방법으로 Thread를 사용한다.

         이 모델에서 ORB는 하나 또는 여러 개의 POA의 생성, 관리, 파괴에 관한

         책임을 진다.

 

  1. Multi Thread 사용의 제한

        : 어떻게 사용하든지 상관하지 않는다. 단지 멀티 Thread 환경에서의

         Object에 대한 동시접근 문제에 관한 것을 염두해 두어야 한다.

 

 

2.8 Dynamic Skeleton Interface

POA는 Programmer가 Servant에 아래와 같은 방법으로 연결하는 것이 가능하도록 디자인 되었다.

  • Static Skeleton( type-specific skeleton )
  • Dynamic Skeleton

: 어떤 방법을 사용하든지 Client에게는 투명하다.

: 같은 Interface를 제공하는 2개의 Corba Object가 하나는 DSI Servant로 하나는 type-specific servantㄹ 구체화 될 수 있다.

: Corba Object는 일정시간 동안 DSI Servant로 또 다른 시간동안 type-specific Servant로 구체화 될 수 있다.

 

  • DSI Servant Interface는 아래와 같은 것들이 요구됨.
    • POA로부터 CORBA.ServerRequest를 가지고 Request를 실행하는데 필요한 Process를 수행한다.
    • Return the Interface Repository ID identifying the most-drived interface supported by the target CORBA Object in a Request.

      ( Request에 있는 목표 CORBA Object에 의해서 지원되는 최상위(most-drived ) Interface를 구분하기 위한 Interface Repository ID를 리턴한다. )

    • 이후의 내용은 Spec Chapter 11.2.9( Page 11-12 )를 참조할 것. Example제공
    •  

2.9 Location Transparency

POA는 POA를 사용해서 구현된 Object에 대한 위치 투명성( Location Transparency)를 제공한다. ( 이후 내용 Spec 11.2.10( Page 11-13 ) 참조 할 것 )

 

신고

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

IOR(Interoperable Object Reference)  (0) 2008.10.23
[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
by 꿈꾸는자의 생각의파편들 2008.10.23 20:48

1. POA

  1. 개요

    POA는 아래의 목적으로 디자인 되었다. ( 2.3 Spec에 의함. )

  • 프로그래머로 하여금 다른 ORB product사이에 이동이 가능한 객체구현을 가능 하게 한다.
  • 지속적인 구분자를 가지는 객체 지원을 제공한다. 더 정확하게 POA는 프로그래머로 하여금 여러 서버주기를 도는 객체를 위한 일관된 서비스를 제공하는 객체구현을 생성하도록 설계되었다.
  • 객체의 투명한 활성을 지원한다.
  • 하나의 서번트가 여러 개의 객체 구분자( Object ID )를 가질 수 있도록 허용한다.
  • 서버에 존재하는 POA의 구분된 멀티 인스턴스를 허용한다.
  • 최소한의 프로그램 작업의 노력으로 일시적인 객체를 허용한다.
  • POA-allocated객체로 명확하지 않은 서번트의 활성화를 지원한다.
  • 객체구현이 최대한으로 객체행위를 책임지도록 한다. 특히 구현은 객체구별을 정의하는 근거자료를 확정하고, 객체의 identity와 객체의 상태사이의 관계를 정의하고, 객체상태의 복구와 storage를 관리하고, 요청에 응답을 하는 코드를 제공하여, 시간 내 어떤 지점에서 객체의 존재유무를 결정하여 객체행위를 컨트롤 할 수 있다.
  • 각 객체를 설명하는 지속상태(그들의 상태가 어디에 저장되는지, 특정identity값이 앞서 사용되었는지, 객체가 존재를 위해 중지할 것인지 아닌지 등등)를 관리하는 ORB를 요청하지 않는다.
  • POA에 구현된 객체에 대한 정보를 결합하기 위한 확장된 메커니즘을 제공한다.
  • 프로그래머로 하여금 정적 또는 동적 스켈레톤 클래스를 상속한 객체구현을 가능하게 한다.

 

 

  1. 구성

    1.2.1 추상 POA Model

    1.2.2 POA Architecture

    1.2.3 용어

  • Client

    클라이언트는 객체 레퍼런스를 통해 객체에 요청하는 컴퓨터적인 요소이다.

     

  • Server

    서버는 Impl 객체가 존재하는 컴퓨터적인 요소이다. 일반적으로 서버는 프로세스에 대응한다. 클라이언트와 서버가 프로그램이 주어진 객체에 관계된 기능을 하는 역할을 한다. 객체를 위한 클라이언트 프로그램은 다른 것에 대해 서버가 될 수도 있다. 동일한 프로세스는 한 개의 객체를 위한 클라이언트 서버 모두가 될 수 있다.

     

  • Object

    추상적인 관점에서는 CORBA 객체를 나타낸다. Client의 관점에서는 Object는 Object Reference로 캡슐화 된다. 이 문서에서는 POA Interface를 통해서 명확하게 관리되어 지는 객체 구분자에 대한 서버측 관점을 정의한다.

     

  • Servant

    서번트는 프로그래밍 언어 객체 또는 구현이 한 개 또는 여러 개의 객체를 요청하는 요소이다. 서번트는 일반적으로 서버 프로세스의 요소안에 존재한다. 요청은 객체의 레퍼런스가 ORB에 의해 중재 되어지고 특정 서번트에서 분기하도록 변형시킨다. 객체의 생성주기과정은 여러 개의 서번트(즉 레퍼런스에 따른 요청이 목표로 삼는)로 이루어질지도 모른다.

     

  • Object Id

    객체 Id는 특정한 CORBA 객체를 구별하기 위해서 POA나 사용자가 제공한 구현( Implementation )에 의해서 사용되어지는 값이다. 객체 Id의 값은 POA에 의해서 할당되고 관리되어질 수도 있고, 사용자가 제공한 구현에 의해서 할당되고 관리되어질 수도 있다. Object ID는 클라이언트에 감춰지고, Reference로 캡슐화된다. 객체Id는 기본 형태가 없다. 이것은 uninterpreted octet sequence( Byte[]형태 )로 POA에 의해 관리된다.

     

  • Object Reference

    이 모델에서 객체 레퍼런스는 CORBA객체 모델과 동일하다. 이 모델은 레퍼런스가 객체 Id와 POA identity를 특별하게 캡슐화하는 것을 포함한다.

     

     

    특정 ORB 구현에서 구체적인 레퍼런스는 문제시되는 서버와 POA의 위치 같은 더 많은 정보를 포함할 것이다. 예를 들어 POA의 완전한 이름(POA의 이름들은 root에서 시작하고 특정 POA로 끝난다.)을 포함할 지도 모른다. 사실 레퍼런스는 실제적으로 객체Id를 포함할 수 도 있고 그렇지 않을 수도 있지만 더 많은 확실한 값을 포함하는 대신에 객체Id에 매핑될 수 있는 ORB에 의해 관리된다. 이것은 POA에 의해 포함되는 추상 정보 모델의 설명이다. POA 이름과 Object ID를 나타내기 위해서 어떤 Encoding이 사용되어지든지 간에 POA이름에 어떤 합법적인 문자 또는 Object ID의 어떠한 합법적인 Octet를 사용하는 것을 제한해서는 안된다.

     

  • POA

    POA는 서버의 구성중에서 신원을 구별할 수 있는 요소이다.( 각각의 POA는 어떤 특정 Key를 가지고 찾을 수 있다. ) 각 POA는 객체Id를 위한 namespace와 다른 POA(nasted or child)를 위한 namespace를 제공한다. 어떤 POA와 연관된 정책은 그 POA에 구현된 객체의 특성을 서술한다. Nested POA는 Server내에 있는 객체에 대한 계층적인 name space의 형태로 나타난다.

     

  • Policy

    Policy는 POA에서 구현된 객체에 의해 공유되는 특징들을 구체화하기 위해 어플리케이션에 의해 POA로 결합된 객체이다. 이 명세서는 POA의 쓰레딩 모델을 제어하는 policy뿐만 아니라 객체관리에 관계된 다른 옵션의 다양함을 정의한다. 다른 명세서는 다른 policy(ORB프로세스가 POA에서 구현된 객체를 어떻게 요청하는지 영향을 주는)를 정의한다.

     

  • POA Manager

    POA 관리자는 하나 또는 더 이상의 POA의 진행 상태를 캡슐화 하는 객체이다. POA Manager에 있는 Operation을 사용함으로써 POA를 대기시키거나 취소 시킬 수 있다. 개발자는 또한 POA를 비활성화 시키기 위해 POA 관리자를 사용할 수 있다.

     

  • Servant Manager

    서번트 관리자는 어플리케이션 개발자가 POA로 결합시킬 수 있는 객체이다. ORB는 서번트 관리자가 요구대로 서번트를 활성화하거나 비활성화 시키도록 오퍼레이션을 발생시킨다. 서번트 관리자는 특정 서번트로 객체(객체Id값에 의해 특징지어지는)의 결합을 관리하고 객체가 존재하는 지 여부를 결정하는 책임이 있다. ServantActivator과 ServantLocator이라고 불리는 서번트 관리의 두가지 종류가 있다. 특정 상황에 사용되는 형태는 POA의 policy에 따라 다르다.

     

  • Adapter Activator

    어뎁터 활성자는 어플리케이션 개발자가 POA로 결합시킬 수 있는 객체이다. ORB는 요청이 현재 존재하지 않는 자식POA로부터 받을 때 어뎁터 활성자로 오퍼레이션을 생성시킨다. 그리고 나서 어뎁터 활성자는 요구되는 POA를 생성시킨다.

     

    1.2.4 Interface들..( 자세한 역할은 Spec 참조 )

  • POA
  • POAManager
  • ServantManager
  • ServantActivator
  • ServantLocator
  • AdapterActivator
  • ThreadPolicy
  • LifespanPolicy
  • IdUniquenessPolicy
  • IdAssignmentPolicy
  • ImplicitActivationPolicy
  • ServantRetentionPolicy
  • RequestProcessingPolicy
  • Current

 

[figure : POA 관련 Class 관계도]

1.2.5 정책들… ( 자세한 내용은 Spec를 참조할 것 )

  • Thread Policy
  1. ORB_CONTROL_MODEL( default )

ORB가 Client의 Request에 대해서 ORB내에서 제어되고 있는 POA에 할당하는 책임을 가진다.

  1. SINGLE_THREAD_MODEL

Request가 순차적으로 처리된다.

 

  • Lifespan Policy
  1. TRANSIENT

POA내에 있는 한 객체는 POA를 벗어나는 순간 사라진다.

  1. PERSISTENT

객체는 POA와는 상관없이 존재할 수 있다.

 

  • Object_Id Uniqueness Policy
  1. UNIQUE_ID

POA내에 활성화된 서번트는 단지 하나의 ObjectID를 가진다.

  1. MULTIPLE_ID

POA내에 활성화된 서번트는 하나 또는 여러 개의 ObjectID를 가질 수 있다.

 

  • Id Assignment Policy
  1. USER_ID

ObjectID는 단지 Application에 의해서만 할당된다.

  1. SYSTEM_ID

ObjectID는 단지 POA에 의해서만 할당된다.

 

  • Implicit Activation Policy
  1. IMPLICIT_ACTIVATION

POA는 함축적인( Implicit ? 암시적인) 서번트 활성화를 지원한다.

  1. NO_IMPLICIT_ACTIVATION

POA는 함축적인( Implicit ? 암시적인 ) 서번트 활성화를 지원하지 않는다.

 

  • Server Retention Policy
  1. RETAIN

POA가 자신의 Active Object Map상에 활동중인 서번트를 유지한다.

  1. NON_RETAIN

서번트는 POA에 의해서 유지되지 않는다.

 

  • Request Processing Policy
  1. USE_ACTIVE_OBJECT_MAP_ONLY

POA는 해당 ObjectID가 Active Object Map상에 존재하지 않으면 OBJECT_NON_EXIST Exception을 Client로 되돌린다. ( RETAIN Policy 요구 )

  1. USE_DEFAULT_SERVANT

ObjectID가 Active Object Map상에 존재하지 않을 경우 Default_Servent를 찾아서 Client로 되돌린다.

  1. USE_SERVANT_MANAGER

ObjectID가 Active Object Map상에 존재하지 않을 경우 ServantManager에게 돌린다.

 

[figure : POA 관련 정책에 관한 Class 관계도]

신고

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

IOR(Interoperable Object Reference)  (0) 2008.10.23
[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
by 꿈꾸는자의 생각의파편들 2008.10.23 20:47
| 1 |