꿈꾸는자의 생각의 파편들... :: [CORBA] POA시나리오 Part 1-2

달력

6

« 2019/6 »

  •  
  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  
  •  
  •  
  •  
  •  

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
TAG ,
Posted by 꿈꾸는자의 생각의파편들