[CORBA] POA시나리오 Part 1-1

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 관계도]