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

달력

8

« 2019/8 »

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