컴포넌트 지향 로봇 시스템을 구축하기 위해서는 컴포넌트 간 데이터 통신만으로는 충분하지 않고 커멘드 레벨(혹은 함수 레벨) 의 컴포넌트 간 통신이 필요하게 됩니다. 예를들면 로봇 암을 제어 하는 머니퓰레이터 컴포넌트의 경우, 손끝의 위치나 속도 등은 상위의 어플리케이션이나 컴포넌트에서 데이터 포트에 보내져야 하는 데이터입니다.
한편, 로봇 암의 각종 설정, 좌표계의 설정, 제어 파라메터의 설정, 동작 모드의 설정 등을 데이터 포트에서 하는 것은 적절하다고는 할 수 없고, 객체 지향적으로 한다면 머니퓰레이터 오브젝트에 대해 setCoordinationSystem(), setParameter(), setMode() 등의 함수가 준비되어 있고 이 함수들을 필요에 따라 적절한 타이밍에 호출하는 것이 적절하다고 할 수 있습니다.
서비스 포트의 예
서비스 포트는 이러한 커멘드 레벨의 컴포넌트 간의 주고 받음을 하기 위한 구조를 제공합니다.
일반적으로 서비스란, 기능적으로 관련이 있는 한묶음의 커멘드(함수, 메소드, 오퍼레이션 등이라고도 불리는)군으로 OpenRTM-aist에 있어서는 이 기능을 제공하는 측을 서비스 프로바이더(인터페이스), 기능을 이용하는 측을 서비스 컨슈머(인터페이스)라고 부릅니다.
또한, UML등의 규약에 있어서는 서비스 프로바이더를 Privided Interface, 또한 서비스 컨슈머를 Required Interface 등이라고 부르고 각각 아래의 그림 과 같이 기호(롤리팝(lollipop), 소켓(socket))로 나태냅니다. 이것은 일반적인 용어 및 기술법이므로 기억해두는 편이 좋습니다. 호출 혹은 호출되는 방향으로 한다면, 호출되는 쪽이 프로바이더(Provided Interface)이고, 호출하는 쪽이 컨슈머(Required Interface)라고 볼 수 있습니다.
프로바이더와 컨슈머
프로바이더 (Provided Interface): 호출되는 측, 서비스를 제공하는 측
컨슈머 (Required Interface): 호출하는 측, 서비스를 이용하는 측
프로바이더 및 컨슈머를 정리해 인터페이스 또는 서비스 인터페이스라고 부르고, 이런 서비스 인터페이스를 갖는 포트를 서비스 포트라고 부릅니다.
서비스 포트와 인터페이스
서비스 인터페이스와 서비스 포트의 관계에 대해 자세히 설명합니다.
컴포넌트, 포트, 인터페이스
포트란 컴포넌트에 부속되는 컴포넌트 간의 접속의 단점이 되는 부분을 가리킵니다. 컴포넌트 간의 접속은 컴포넌트에 부속되는 포트 사이에서 접속에 관한 조정을 해 어떠한 상호 작용(데이터나 커멘드의 주고 받음)을 실시할 수 있는 상태로 하는 것을 의미합니다.
포트 자체는 데이터나 커멘드의 주고 받음에 대해 어떠한 기능도 제공하지 않습니다. 실제로 커멘드의 주고 받음을 하는 것은 서비스 인터페이스(프로바이더 와 컨슈머)입니다. 일반적으로 포트에는 기능적으로 관련있는 임의의 수의 임의의 방향의 인터페이스를 부가하는 것이 가능합니다. 이것에 의해 커멘드의 주고 받음을 한 방향만이 아닌 쌍방향으로도 가능합니다.
컨슈머와 프로바이더는 포트가 접속되었을 때, 어느 조건에 근거해 접속되어 컨슈머에서 프로바이더의 기능을 호출할 수 있습니다. 컨슈머와 프로바이더를 접속하기 위해서는 양측의 형태가 같거나 호환성이 있어야만 합니다.
같은 형태라는 것은 동일한 인터페이스 정의를 가지는 것이고, 호환성이 있다라는 것은 프로바이더의 인터페이스가 컨슈머 인터페이스의 서브 클래스의 하나(역으로 말하면, 컨슈머의 인터페이스가 프로바이더의 인터페이스의 슈퍼 클래스의 하나)라는 것이 됩니다.
서비스 포트
RT컴포넌트는 데이터 포트와 같이 임의의 수의 서비스 포트를 가질 수 있습니다. 또한, 서비스 포트에는 임의의 종류, 임의의 갯수의 프로바이더 또는 컨슈머를 부가할 수 있습니다.
RTC::ReturnCode_t MyServiceProvider::onInitialize()
{
// Set service provider to Ports
m_MyServicePort.registerProvider("myservice0", "MyService", m_myservice0);
// Set CORBA Service Ports
addPort(m_MyServicePort);
return RTC::RTC_OK;
}
m_MyServicePort.registerProvider()로 프로바이더를 서비스 포트 오브젝트 m_MyServicePort에 등록하고 있습니다. 제3인수가 실체 프로바이더 오브젝트 입니다. 다음으로 컴포넌트의 프레임 워크 클래스인 RTObject 클래스의 addPort()함수로 포트를 컴포넌트에 등록하고 있습니다.
위에서와 같이 샘플 컴포넌트 MyServiceConsumer에서 발췌한 코드를 나타냅니다.
RTC::ReturnCode_t MyServiceConsumer::onInitialize()
{
// Set service consumers to Ports
m_MyServicePort.registerConsumer("myservice0", "MyService", m_myservice0);
// Set CORBA Service Ports
addPort(m_MyServicePort);
return RTC::RTC_OK;
}
프로바이더의 경우와 거의 같이 m_MyServicePort.registerConsumer()함수로 컨슈머를 포트에 등록해 그 포트를 addPort()함수로 컴포넌트에 등록하고 있습니다.
이상 특별히 설명도 없이 각각 m_myservice0라고 하는 오브젝트가 프로바이더 또는 컨슈머라고 하며 코드 예를 나타냈습니다만, 아래에 이러한 인터페이스가 어떻게 정의되고 오브젝트가 어떻게 구현되고 있는지를 설명 하겠습니다.
인터페이스 정의
인터페이스란 무엇입니까? C++라면 순수 가상 클래스를 인터페이스라고 부르고, Java는 언어 레벨에서 interface 키워드가 준비되어 있습니다.
OpenRTM-aist에서는 언어나 OS에 의존하지 않고 네트워크 투과라는 특징이 있습니다만 이것은 CORBA라고 불리우는 분산 오브젝트 미들웨어를 이용하는 것에 의해 실현되고 있습니다. CORBA는 국제 표준화 단체 OMG에서 표준화 되어 있는 분산 오브젝트 미들웨어로 표준에 따라서 많은 회사나 단체, 개인 등이 다양한 실장을 제공하고 있습니다.
OpenRTM-aist에서는 인터페이스는 IDL이라고 부르는 CORBA의 인터페이스 정의 언어에 의해 정의합니다. 이 IDL은 언어에 의존하지 않는 인터페이스 정의 방법을 제공하고, 또한 IDL 컴파일러라고 불리는 스텁이나 스켈레톤을 생성 툴을 이용하는 것으로 각종 언어에 대응한 코드가 자동적으로 생성됩니다. 스 텁이란 원격 오브젝트를 호출하기 위한 프록시 오브젝트를 위한 코드이고 스켈레톤은 프로바이더를 구현하기 위한 베이스가 되는 코드입니다.
이렇게 자동 생성된 코드 덕분에 다른 언어끼리의 호출도 무결절적으로 실시할 수 있습니다. 예를 들면 C++로 작성된 프로바이더를 Python이나 Java등으로 용이하게 호출할 수 있는 것 입니다.
module이란 C++에서 말하는 네임 스페이스와 같은 것으로 이것에 의해 인터페이스 명을 취하여 충돌을 막을 수 있습니다.
C언어 등과 같이 typedef 키워드가 있습니다. 위의 예에서는 sequence라고 불리는 동적 배열형을 정의하고 있습니다. 하나는 string(문자열 형)형의 리스트로서 EchoList형, 또하나는 float형의 리스트로서 ValueList형을 정의하고 있습니다. 특히 sequence형은 typedef하지 않고 정의중에 직접 사용할 수 없기 때문에 이와 같이 미리 typedef해 둘 필요가 있습니다.
다음에 interface로 시작하는 부분이 실제 인터페이스의 정의가 됩니다. MyService 인터페이스에는 5개의 함수(IDL에서는 오퍼레이션이라고 부릅니다.)가 정의되어 있습니다. 대부분은 C언어나 Java 등과 같은 정의입니다만, IDL에서는 인수가 입력인지 출력인지를 명확하게 하기 위해 인수 선언 전에 in, out 또는 inout의 수식자가 붙습니다.
IDL 컴파일
그림에 IDL 정의, IDL 컴파일, 프로바이더의 구현 및 스텁의 이용의 흐름을 나타냅니다.
IDL 컴파일과 스텁, 스켈레톤
정의된 IDL을 IDL 컴파일러로 컴파일하면 일반 스텁과 스켈레톤( 또는 서버와 클라이언트라고 부르는 경우도 있음)을 위한 코드가 생성됩니다.
클라이언트, 즉 서비스를 이용하는 측은 스텁 코드를 인클루드 하는 등 스텁에서 정의되고 있는 프록시(대리) 오브젝트를 이용하여 원격에 있는 서버의 기능에 액세스합니다. 아래에 C++에서의 코드 예를 나타냅니다.
MyService_var mysvobj = <어떤 방법으로 원격 오브젝트의 참조를 취득>
Retval retval = mysvobj->myoperation(argument);
MyService_var라는 것은 프록시 오브젝트를 위한 선언입니다. mysvobj에 원격 오브젝트의 참조를 어떠한 형태로 대입하면, 그 밑에서 행해지고 있는 myoperation()함수의 호출은 실제로는 원격에 존재하는 오브젝트에 대해 행해집니다. 이 MyService_var 클래스가 정의되어 있는 것이 스텁에 해당합니다.
한편, 위의 방법에 의해 실제로 호출된 서버측의 오브젝트는 아래와 같이 스켈레톤 클래스를 물려받아 아래와 같이 구현됩니다.
class MyServiceSVC_impl
: public virtual MyService,
public virtual PortableServer::RefCountServantBase
{
public:
MyServiceSVC_impl() {};
virtual ~MyServiceSVC_impl() {};
Retval myoperation(ArgType argument)
{
return do_ something(argument);
}
};
더욱이 여기서 정의된 하위 클래스를 인스턴스화 하여 CORBA 오브젝트 로서 액티베이트 하는 것으로 원격에서 오퍼레이션을 호출할 수 있습니다.
// CORBA의 ORB 등을 기동하기 위한 여러가지 방법
MyServiceSVC_impl mysvc;
POA->activate_object(id, mysvc);
IDL을 정의해 컴파일하는 것으로 분산 오브젝트를 정의하여 이용할 때 필요한 대부분의 코드가 자동적으로 생성됩니다. 단, 위의 「어떤 방법으로 원격 오브젝트의 참조를 취득」하거나, 「CORBA의 ORB을 기동하기 위한 여러가지 방법」라고 하는 것은 CORBA를 직접 이용하는 경우에는 여전히 코딩할 필요가 있는 부분이고, 이것들은 CORBA를 이용하는데도 이해하기 어렵거나 번잡한 작업이 필요한 부분입니다.
그렇지만 OpenRTM-aist를 이용하면 이러한 CORBA의 여러가지 호출의 대부분은 은폐되어 작성자는 클라이언트의 호출, 하위 클래스의 구현에만 집중할 수 있습니다. 이하에는 하위 클래스를 작성해 프로바이더로서 컴포넌트에 등록하는 방법, 컨슈머로서 프로바이더를 이용하는 방법에 대해 자세히 설명합니다.
구현
서비스 포트의 구현에 있어서는 RTCBuilder를 사용하는 것이 편리합니다. 스스로 서비스 포트, 프로바이더 및 컨슈머를 구현하는 것도 가능하지만, CORBA나 IDL 컴파일러에 정통해야 하고 Makefile과 코드의 여러 부분을 수정해야 하기 때문에 그다지 권해드리지 않습니다.
RTCBuilder의 자세한 사용법은 RTCBuilder의 매뉴얼을 참조해 주십시오.
IDL 정의
서비스 포트를 이용할 때는 이용하는 인터페이스를 미리 IDL로 정의하던지 기존의 IDL 파일을 적당한 디렉토리에 배치할 필요가 있습니다.
IDL의 정의 방법에 대해서는 여기에서는 자세히는 설명하지 않지만 대체로 아래와 같은 포맷으로 정의할 수 있어, C언어나 Java에 익숙한 사용자라면 비교적 용이하게 정의할 수 있습니다.
// 네임 스페이스를 위한 모듈을 정의할 수 있다.
// 모듈 정의는 적극적으로 사용하는 것이 추천 된다.
module <모듈 명>
{
// 구조체를 정의할 수 있다.
struct MyStruct // 구조체 명
{
short x; // int형은 short와 long만 이용 가능
short y;
long a;
long b;
double dval; // 부동 소수점형은 float와 double만 이용 가능
float fval;
string strval; // 문자열을 위해 string가 이용 가능
};
// 동적 배열 sequence 형은 미리 typedef 할 필요가 있다
typedef sequence<double> DvalueList;
typedef sequence<MyStruct> MyStructList; // 임의의 구조체도 sequence형으로 가능
// 인터페이스 정의
interface MyInterface // 인터페이스 명
{
void op1(); // 리턴값 없고, 인수 없을 경우
// NG: 대문자・소문자를 구별하지 않는 언어에서는 이하의 정의가 문제가 되기 때문에 IDL에서는 에러가 된다
// short op2(in MuStruct mystruct);
short op2(in MyStruct mydata); // 인수는 {in, out, inout} 로 방향을 지정
oneway void op3(); // 리턴값 없는 오퍼레이션은 onway 키워드가 이용 가능
void op4(in short inshort, out short outshort, inout short ioshort);
void op5(MyInterface myif); // MyInterface 자신을 인수로 이용하는 것도 가능
};
// 동일한 IDL 파일에 복수의 interface를 지정하는 것도 가능
interface YourInterface
{
void op1();
};
};
RTCBuilder에 의한 설계
위와 같이 IDL에서 정의한 인터페이스를 앞으로 개발하는 RT컴포넌트의 서비스 포트의 프로바이더 혹은 컨슈머로서 사용하기 위해서는 컴포넌트의 코드 제네레이터인 RTCBuilder에서 서비스 포트를 설계해 그 때에 이 IDL정의를 줄 필요가 있습니다.
RTCBuilder의 신규 프로젝트를 작성해 퍼스펙티브를 엽니다. 각종 프로파일(컴포넌트의 이름이나 카테고리 명)등 필요한 설정을 한 후, 서비스 포트 탭을 열면 다음과 같은 화면이 나타납니다.
서비스 포트 설계 탭
우선, Add Port버튼을 눌러 서비스 포트를 하나 추가합니다. 그렇게 하면 sv_name이라는 서비스 포트가 하나 추가되어 아래의 BuildView의 컴포넌트 박스에 작은 정사각형의 포트가 한개 추가됩니다. RTCBuilder의 에디터 왼쪽 포트 리스트의 sv_name을 클릭하면 우측에 RT-Component Service Port Profile가 표시되고 포트명을 적당한 이름(여기에서는 MyServiceProviderPort)으로 변경합니다.
서비스 포트의 추가
에디터 왼쪽의 포트 리스트의 MyServiceProviderPort을 클릭해 Add Interface버튼을 클릭하면 MyServiceProviderPort 에 인터페이스 if_name이 하나 추가되고 방금전과 같이 에디터 왼쪽의 if_name을 클릭해 RT-Component Service Port Interface Profile상에서 if_name을 적당한 이름(여기에서는 MyServiceProvider)로 변경 합니다. 아래의 BuildView에서는 정사각형의 포트에 롤리팝이 추가되어 프로바이더 (Provided Interface)가 포트에 부가되는 것을 시각적으로 확인할 수 있습니다.
서비스 인터페이스(프로바이더)의 추가
에디터 우측의 Interface Profile에서는 인터페이스의 프로파일을 설정합니다. 예를 들면 방향의 드롭 다운 리스트에서는 대상의 인터페이스가 프로바이더(Provided)인지 컨슈머(Required)인지를 지정합니다.
서비스 인터페이스의 「방향」의 설정
여기에서는 프로바이더를 추가하려고 하기 때문에 Provided 대로 합니다. 이 외, 인스턴스명, 변수명 등도 지정할 수 있습니다만, 필수는 아닙니다. 인터페이스명은 접속시에 프로바이더와 컨슈머의 인스턴스명이 같다면 대응 관계를 지정하지 않더라도 포트의 접속을 자동적으로 실시하는 경우에 이용됩니다.
서비스 인터페이스명의 인스턴스명과 자동접속
다만, 인스턴스명이 차이가 나도 접속시에 임의의 인터페이스 끼리를 접속할 수 없기 때문에 입력은 필수는 아닙니다. 또 변수명은 코드를 생성했을 때에 프로바이더 오브젝트를 대입하는 변수명을 지정하기 위한 항목입니다만, 이것도 인터페이스명에서 자동적으로 생성되기 때문에 입력은 임의입니다.
다음에 IDL의 지정과 인터페이스형의 지정을 합니다. 위에서 정의한 것과 같은 IDL을 적당한 디렉토리에 배치하고, IDL파일 지정 박스 옆의 Browse버튼을 눌러 대상이 되는 IDL을 지정합니다. 그러면 지정된 IDL로 정의된 인터페이스가 그 아래의 인터페이스형의 드롭 다운 리스트에 나타납니다. 이 드롭 다운 리스트에서 이 포트에 추가한 인터페이스명을 선택합니다. IDL파일에 문법 에러 등이 있을 경우에는 드롭 다운 리스트에 희망하는 인터페이스가 나타나지 않습니다. 다시 IDL파일의 정의를 클릭해 주십시오.
인터페이스형의 선택
또한, 위 설명의 방향 드롭 다운 리스트에서 Required를 지정하면 이 인터페이스는 컨슈머가 됩니다. 이하는 다른 컴포넌트 MyServiceConsumer의 서비스 포트와 인터페이스 설정 화면의 예입니다.
서비스 인터페이스(컨슈머)의 추가
에디터 아래의 BuildView에 포트에 소켓이 추가되어 컨슈머 (Required interface)가 포트에 부가되는 것을 확인할 수 있습니다.
프로바이더의 구현
프로바이더라는 것은 문자 그대로 서비스를 프로바이드(제공)하기 위한 인터페이스 입니다. 따라서, IDL로 정의된 인터페이스를 갖는 서비스의 내용을 구현할 필요가 있습니다.
프로바이터 인터페이스를 갖는 컴포넌트를 RTCBuilder로 설계한 경우 코드 생성을 하면, 컴포넌트의 소스의 모형과 함께, 예를 들어 C++의 경우는 <서비스 인터페이스명>SVC_impl.cpp과 <서비스 인터페이스명>SVC_impl.h이라는 프로바이더의 구현 코드의 모형도 생성됩니다.
이러한 구현 모형에는 IDL에 정의된 인터페이스에 상당하는 클래스가 미리 정의되어 있습니다.
여기에서는 C++에서의 구현 방법을 예를 들어 IDL로 정의된 오퍼레이션의 몇개인가를 구현해 볼 것입니다.
echo()함수의 작성
먼저, echo() 멤버 함수를 보겠습니다.
/*
* Methods corresponding to IDL attributes and operations
*/
char* MyServiceSVC_impl::echo(const char* msg)
{
// Please insert your code here and remove the following warning pragma
#ifndef WIN32
#warning "Code missing in function <char* MyServiceSVC_impl::echo(const char* msg)>"
#endif
return 0;
}
#warning 프리프로세서 지시문이 있습니다만, 이것은 gcc로 컴파일 할 때에 이 함수가 구현되어 있지 않은 것을 경고하기 위한 것이므로, #ifndef마다 삭제합니다.
그러나 이것은 컴파일시에 에러가 됩니다. const char*을 char*에 건네주고 있기 때문입니다. 또한, CORBA의 오브젝트의 구현 방법으로서도 잘못되어 있습니다. CORBA에서 return으로 반환되는 오브젝트는 ORB(Object Request Broker, 원격 오브젝트의 호울 부분을 맡는 부분, CORBA의 코어)에 의해 해체된다고 하는 룰이 있기 때문입니다. (return시에는 오브젝트의 소유권을 포기한다라고도 말합니다.)
따라서 return에는 별도 영역을 확보해 msg의 내용을 복사한 문자열을 반환할 필요가 있습니다. 이것에 따르면, 이하와 같이 구현한다면 좋을 것입니다.
여기에서는 malloc으로 영역을 확보하고 있습니다만 ORB는 free로 영역을 해체하는지 delete로 해체하는지는 모릅니다. 실제로 CORBA에서는 오브젝트(구조체나 배열 또는 그 복합형 등도 포함)나 문자열을 취급하기 위한 방법이 별도로 정해져 있어, 거기에 따라 함수의 인수를 받거나, 돌려주거나 할 필요가 있습니다.
CORBA에서 정해진 방법에 따르면 echo()함수는 이하와 같이 구현할 필요가 있습니다.
이 String_var형의 변수 msgcopy에 인수의 msg에 저장되어 있는 문자열을 복사하고 있는 것은 CORBA::string_dup()함수입니다. 이 함수에서는 인수로 주어진 문자열을 저장하는데 충분한 메모리 영역을 확보해 그 영역에 인수의 문자열을 복사하고 있습니다.
다음의 행에서는 return으로 호출된 곳으로 msgcopy내의 문자열을 반환하면서 오브젝트의 소유권을 포기, return측에 소유권을 이양하고 있습니다. 아래의 그림에 표시된 것과 같이 ORB에서는 return으로 반환된 문자열을 네트워크상의 원래 호출된 곳으로 송신한 다음, 문자열 오브젝트를 해방합니다.
ORB와 오퍼레이션 호출, 메모리 관리의 관계
이 룰을 잘 이해하면, msgcopy 오브젝트가 echo() 함수내에서 사용되지 않는 것에서 부터, echo()함수의 구현은 최종적으로는 이하와 같이 쓸 수도 있습니다.
CORBA::string_dup() 함수에서 문자열 영역의 확보와 내용의 복사를 한 상태에서, 그 소유권을 직접 호출된 곳으로 주는 것이 됩니다.
이와 같이 서비스 프로바이더는 CORBA의 오브젝트이기 때문에 그 구현 방법은 통상의 C++의 구현과는 조금 다른 방식으로 할 필요가 있습니다. 특히, 함수의 인수 및 리턴값의 주고 받는 규약은 조금 복잡하게 보입니다. 다만, 위와 같이 오브젝트의 소유권이라는 사고를 염두에 두고 생각해보면 인수를 어떻게 주고 받아야 할 것인가 또는 리턴값을 어떻게 리턴해야 할 것인가가 저절로 밝혀집니다. 상세한 것에 대해서는 Appendix나 그 외의 CORBA의 참고서 등을 참고해 주십시오.
set_value(), get_value() 와 get_value_history()
다음은 set_value() 함수, set_value() 함수 및 set_value_list() 함수를 동시에 작성해 보겠습니다. 이러한 함수는 set_value()로 설정된 float형의 값을 저장해 두고 get_value()로 그 값을 리턴한다는 단순한 것입니다. 또한, get_value_history()에서는 지금까지 세트된 값의 이력을 저장해 두어, 이력을 리스트로서 리턴한다는 것입니다.
먼저 값을 저장해 놓을 변수를 준비합니다. 현재의 값은 MyServiceSVC_impl 클래스에 CORBA::Float형의 private 멤버로서 준비합니다. 한편, get_value_history()에서는 리턴값에 SimpleService::ValueList라는 CORBA의 시퀀스형이 사용되고 있기 때문에 이것을 멤버 변수로서 갖도록 합니다. 이러한 변수 선언을 MyServiceSVN_impl.h의 MyServiceSVC_impl 클래스 정의의 마지막에 다음과 같이 추가합니다.
class MyServiceSVC_impl
: public virtual POA_SimpleService::MyService,
public virtual PortableServer::RefCountServantBase
{
: (중략)
private:
CORBA::Float m_value; // 이 행을 추가한다
SimpleService::ValueList m_valueList; // 이 행을 추가한다
};
변수의 초기화도 잊지말고 합니다. MyServiceSVC_impl.cpp의 생성자에서 m_value는 0.0으로, m_valueList는 길이 0으로 초기화 합니다.
다음 set_value()함수를 작성합니다. 인수로 주어진 값을 멤버 변수 m_value에 대입하는 것과 동시에 m_valueList에도 추가합니다. CORBA의 시퀀스형은 동적 배열형으로 []오퍼레이터와 함께 length(), length(CORBA::ULong)의 함수를 이용할 수 있습니다. length()함수는 현재 배열의 길이를 반환해, length(CORBA::ULong)함수는 현재의 배열의 길이를 설정 합니다. 구현은 아래와 같이 됩니다.
void MyServiceSVC_impl::set_value(CORBA::Float value)
throw (CORBA::SystemException)
{
m_value = value; // 현재값
CORBA::ULong len(m_valueList.length()); // 배열의 길이를 취득
m_valueList.length(len + 1); // 배열의 길이를 1개 늘림
m_valueList[len] = value; // 배열의 마지막에 value를 추가
return;
}
echo()함수와는 다르게 CORBA::Long형은 C++의 long int와 등가로, 오브젝트 소유권, 영역 확보나 폐기 등은 생각할 필요가 없습니다. 따라서 위와 같이 단순한 대입으로 상관없습니다. 또, 배열형은 2종류의 length()함수와 [] 오퍼레이터를 사용해 배열의 길이를 1개 증가하고 마지막에 인수 값을 대입하고 있습니다. 또한 OpenRTM-aist에서는 CORBA의 시퀀스형을 STL의 vector에 가까운 형태로 이용하기 때문에 함수 템플렛을 제공하고 있어, 그것을 사용하면
함수내 첫번째 행에서는 시퀀스형 오브젝트를 위한 스마트 포인터인 SimpleService::valueList_var형의 변수명을 선언하고 있습니다. 또한 다음의 행에서는 이 스마트 포인터에 대해 copy 생성자를 호출해 그 포인터를 대입하고 있습니다. 이것에 의해 영역의 확보와 값의 복사가 동시에 행해집니다. 마지막에 vl.retn()으로 vl이 저장하고 있는 시퀀스형의 오브젝트의 소유권을 포기하고 return측에 오브젝트를 건네주고 있습니다.
그리고 vl은 함수내에서 사용되지 않기 때문에 이하와 같이 쓸 수도 있습니다.
SimpleService::ValueList* MyServiceSVC_impl::get_value_history()
throw (CORBA::SystemException)
{
return new SimpleService::ValueList(m_valueList);
}
이상 프로바이더의 작성에 대해 설명하였습니다만, 프로바이더가 이른바 CORBA 오브젝트이므로 사용하는 형, 변수의 주고 받는 구조 등 CORBA의 룰에 따라 작성해야 합니다. 처음에는 번거롭게 느껴지겠지만 프리미티브형에 대해서는 종래대로의 작성, 복잡한 오브젝트에 대해서는 메모리의 확보와 해제가 어디서 행해지는지, 소유권은 어느 쪽에 있는지를 이해하면 어떻게 작성해야 하는 것인가 이해할 수 있다고 생각합니다.
컨슈머의 이용
컨슈머에서는 위에서 작성된 서비스 프로바이터를 호출해 그 기능을 사용하는 것이 됩니다. 컨슈머를 갖는 컴포넌트의 모형 코드를 RTCBuilder로 생성한 경우에는 프로바이더의 경우와는 다르게 특별한 파일이 생성되지 않습니다.
그 대신 컴포넌트의 헤더에 아래와 같은 프로바이더의 플레이스 홀더인 컨슈머 오브젝트가 선언됩니다.
이것은 RTC::CorbaConsumer 클래스 템플릿에 형인수 SimpleService::MyService를 주고 MyService형의 컨슈머를 선언하고 있는 것이 됩니다. 또한 작성 파일 쪽은 onInitialize()함수에서 컨슈머의 포트에 등록과 포트의 컴포넌트에 등록이 행해지고 있는 것을 확인할 수 있습니다.
RTC::ReturnCode_t MyServiceConsumer::onInitialize()
{
: (중략)
// Set service consumers to Ports
m_MyServiceConsumerPortPort.registerConsumer("MyServiceConsumer",
"SimpleService::MyService",
m_MyServiceConsumer);
// Set CORBA Service Ports
addPort(m_MyServiceConsumerPortPort);
// </rtc-template>
return RTC::RTC_OK;
}
헤더에서 선언되고 있는 m_MyServiceConsumer 변수가 registerConsumer() 멤버 변수에 의해 포트에 등록되어 있는 것을 알 수 있습니다. 제1 인수에는 이 컨슈머의 「인스턴스 변수」가, 제2 인수에는 컨슈머의 「인터페이스형」이 그리고 제3 인수에는 컨슈머의 인스턴스인 m_MyServiceConsumer 변수가 각각 주어지고 있습니다. 이것에 의해 컨슈머가 인터페이스명, 형이름 모두 포트에 관련되고 있는 것이 됩니다.
컨슈머 m_MyServiceConsumer는 위에서 설명한 것과 같이 프로바이더의 플레이스 홀더가 되어 있습니다. C++에서는 오브젝트에의 포인터와 같이 취급할 수 있습니다.
MyService 인터페이스에서는 string형(CORBA의 string형) 인수를 하나 취하는 echo() 오퍼레이션이 정의되어 있습니다. 따라서 예를들면 이하와 같이 echo()함수를 호출할 수 있습니다.
m_MyServiceConsumer->echo("Hello World");
C++에서는 위와 같이 포인터, Java나 Python에서는 참조와 같은 오퍼레이션을 호출할 수 있는 것입니다.
그럼 여기에서 눈치가 빠른 사람이라면 포인터 또는 참조가 가르키는 곳은 도대체 어떻게 되어 있는지 생각할 것입니다. C++ 등에서도 예를 들어 아래와 같은 코드는 segmentation fault에러가 발생합니다.
class A {
public:
const char* echo(const char* msg) {
std::cout << msg << std::endl;
return msg;
}
};
int main (void) {
A* a;
a->echo("Hello World!!");
}
a는 null 포인터이기 때문에 아무것도 오브젝트를 가르키지 않습니다. 이것과 같이 위의 m_MyServiceConsumer도 컴포넌트 기동 직후에는 어떠한 오브젝트도 가리키지 않기 때문에 당연히 오퍼레이션을 호출할 수 없습니다. 위의 class A의 경우에서는
int main (void) {
A* a;
a = new A();
a->echo("Hello World!!");
}
오브젝트를 new로 생성해 변수 a에 대입하면 a는 그 시점에서 어느 오브젝트를 가리키는 정당한 포인터이기 때문에, class A의 멤버 함수인 echo()를 호출할 수 있습니다.
그렇지만 컴포넌트 없는 컨슈머가 호출하고 싶은 것은 네트워크상의 어디엔가에 있는 오브젝트의 오퍼레이션입니다. 따라서, m_MyServiceConsumer가 가리키는 것은 원격 오브젝트의 참조(CORBA 오브젝트 참조(레퍼런스))입니다.
실제로 아래의 그림과 같이 컨슈머는 그 포트가 프로바이더를 갖는 포트와 접속될 때, 대응하는 오브젝트 참조를 받습니다. 접속에 의해 컨슈머는 정당한 오브젝트를 가리키는 것이 되고 이렇게 하여 처음으로 오퍼레이션을 호출할 수 있습니다.
서비스 포트의 접속과 오브젝트(참조) 레퍼런스
접속 후는(상대의 포트에 적당한 프로바이더가 존재한다면) 컨슈머의 오퍼레이션을 호출할 수 있습니다만, 접속하고 있지 않은 경우 또는 유호한 참조가 세트되어 있지 않은 경우에는 컨슈머 오브젝트는 예외를 던집니다. 그래서 컨슈머를 이용하는 경우 언제 접속이 되었는지, 또한 언제 접속이 끊어졌는지 모르기 때문에 항상 이 예외를 포착해 적절히 처리할 필요가 있습니다.
이러한 커멘드 중에 인수를 받는 것은 echo와 set value만으로, 한편 이러한 커멘드는 인수를 한개만 받습니다. 받은 문자열을 최초의 공백에서 분할해 argv[0] = 커멘드, argv[1] = 인수로서 string의 vector에 저장합니다. echo, set_value커멘드에서는 argv[1]를 인수로서 이용하여 다른 커멘드에서는 단순히 무시하기로 하겠습니다.
echo 커멘드의 작성입니다. argv[0]가 echo인 경우, argv[1]을 인수로 해 echo()함수를 호출합니다. echo()의 CORBA의 string형의 리턴값을 받기 위한 변수로서, retmsg를 선언하고 있습니다. echo()의 리턴값의 소유권은 이쪽에 있기 때문에, 받은 후에 적절히 영역을 해제할 필요가 있습니다만, String_var형의 스마트 포인터를 이용하면 불필요하게 되는 시점에 적절히 영역을 해제하여 줍니다. 리턴값을 표시하고 return RTC::RTC_OK로 onExecute()함수를 빠져 나옵니다.
get_value 커멘드는 set_value 커멘드에서 설정한 값을 취득합니다. get_value() 오퍼레이션은 리턴값이 CORBA::Float로 값을 건네주기 위해 오브젝트의 소유권등은 특별히 생각하지 않아도 괜찮습니다. 여기에서는 리턴값을 그대로 std::cout으로 콘솔에 표시시키고 있습니다.
if (argv[0] == "get_echo_history")
{
EchoList_var elist = m_myservice0->get_echo_history();
for (CORBA::ULong i(0), len(elist.length(); i <len; ++i)
{
std::cout << elist[i] << std::endl;
}
return RTC::RTC_OK;
}
get_echo_history 커멘드에서는 get_echo_history()의 결과를 받아, 그것까지 echo 커멘드로 인수로 주어진 문자열의 리스트를 돌려주고 있습니다. get_echo_history()함수의 리턴값은 CORBA의 시퀸스형인 EchoList입니다. 시퀸스형에 대해서도 스마트 포인터인 _var형이 정의되어 있기 때문에, 이것을 이용합니다. 배열의 길이를 취득하기 위한 length() 함수를 이용할 수 있기 때문에, 길이를 조사해 for문에서 모든 요소를 표시하고 있습니다. 시퀸스형의 _var형에서는 위와 같이 [] 오퍼레이터를 이용해 C언어의 배열과 같이 각 요소에 액세스할 수 있습니다.
if (argv[0] == "get_value_history")
{
ValueList_var vlist = m_myservice0->get_value_history();
for (CORBA::ULong i(0), len(vlist.length()); i < len; ++i)
{
std::cout << vlist[i] << std::endl;
}
return RTC::RTC_OK;
}
마지막으로 get_value_history 커멘드입니다. get_value_history() 오퍼레이션을 호출하여, 지금까지 설정된 최근 몇개의 리스트를 표시합니다. get_value_history()함수의 리턴값은 CORBA::Float의 시퀸스형인 ValueList입니다. 요소는 CORBA::Float이기 때문에 오브젝트의 소유권등은 고려하지 않아도 되지만, 시퀸스형은 그것 자신이 오브젝트이므로 소유권을 고려해야 하기 때문에 여기에서는 _var형의 변수로 받고 있습니다.
std::cout << "Invalid command or argument(s)." << std::endl;
}
catch (CORBA::SystemException &e)
{
std::cout << "No service connected." << std::endl;
}
return RTC::RTC_OK;
}
마지막으로 위의 어느 것에도 맞지 않았던 커멘드의 경우에, 메세지를 보내고 있습니다. 또, 컨슈머에 참조가 세트되어 있지 않은 경우를 포함한 예외를 포착하기 위한 catch절이 있습니다.
이상으로 컨슈머에 의한 오퍼레이션의 호출법에 대해 간단히 예를 들어 설명하였습니다. 컨슈머를 이용할 때는 반드시 오브젝트 참조가 세트되었다고는 한정할 수 없으므로, 반드시 예외를 포착해 대처하는 것과 각 오퍼레이션의 호출이 CORBA의 룰에 근거하여 행해지는 것을 유의하여 주십시오.
서비스 포트란?
컴포넌트 지향 로봇 시스템을 구축하기 위해서는 컴포넌트 간 데이터 통신만으로는 충분하지 않고 커멘드 레벨(혹은 함수 레벨) 의 컴포넌트 간 통신이 필요하게 됩니다. 예를들면 로봇 암을 제어 하는 머니퓰레이터 컴포넌트의 경우, 손끝의 위치나 속도 등은 상위의 어플리케이션이나 컴포넌트에서 데이터 포트에 보내져야 하는 데이터입니다.
한편, 로봇 암의 각종 설정, 좌표계의 설정, 제어 파라메터의 설정, 동작 모드의 설정 등을 데이터 포트에서 하는 것은 적절하다고는 할 수 없고, 객체 지향적으로 한다면 머니퓰레이터 오브젝트에 대해 setCoordinationSystem(), setParameter(), setMode() 등의 함수가 준비되어 있고 이 함수들을 필요에 따라 적절한 타이밍에 호출하는 것이 적절하다고 할 수 있습니다.
서비스 포트는 이러한 커멘드 레벨의 컴포넌트 간의 주고 받음을 하기 위한 구조를 제공합니다.
일반적으로 서비스란, 기능적으로 관련이 있는 한묶음의 커멘드(함수, 메소드, 오퍼레이션 등이라고도 불리는)군으로 OpenRTM-aist에 있어서는 이 기능을 제공하는 측을 서비스 프로바이더(인터페이스), 기능을 이용하는 측을 서비스 컨슈머(인터페이스)라고 부릅니다.
또한, UML등의 규약에 있어서는 서비스 프로바이더를 Privided Interface, 또한 서비스 컨슈머를 Required Interface 등이라고 부르고 각각 아래의 그림 과 같이 기호(롤리팝(lollipop), 소켓(socket))로 나태냅니다. 이것은 일반적인 용어 및 기술법이므로 기억해두는 편이 좋습니다. 호출 혹은 호출되는 방향으로 한다면, 호출되는 쪽이 프로바이더(Provided Interface)이고, 호출하는 쪽이 컨슈머(Required Interface)라고 볼 수 있습니다.
프로바이더 및 컨슈머를 정리해 인터페이스 또는 서비스 인터페이스라고 부르고, 이런 서비스 인터페이스를 갖는 포트를 서비스 포트라고 부릅니다.
서비스 포트와 인터페이스
서비스 인터페이스와 서비스 포트의 관계에 대해 자세히 설명합니다.
포트란 컴포넌트에 부속되는 컴포넌트 간의 접속의 단점이 되는 부분을 가리킵니다. 컴포넌트 간의 접속은 컴포넌트에 부속되는 포트 사이에서 접속에 관한 조정을 해 어떠한 상호 작용(데이터나 커멘드의 주고 받음)을 실시할 수 있는 상태로 하는 것을 의미합니다.
포트 자체는 데이터나 커멘드의 주고 받음에 대해 어떠한 기능도 제공하지 않습니다. 실제로 커멘드의 주고 받음을 하는 것은 서비스 인터페이스(프로바이더 와 컨슈머)입니다. 일반적으로 포트에는 기능적으로 관련있는 임의의 수의 임의의 방향의 인터페이스를 부가하는 것이 가능합니다. 이것에 의해 커멘드의 주고 받음을 한 방향만이 아닌 쌍방향으로도 가능합니다.
컨슈머와 프로바이더는 포트가 접속되었을 때, 어느 조건에 근거해 접속되어 컨슈머에서 프로바이더의 기능을 호출할 수 있습니다. 컨슈머와 프로바이더를 접속하기 위해서는 양측의 형태가 같거나 호환성이 있어야만 합니다.
같은 형태라는 것은 동일한 인터페이스 정의를 가지는 것이고, 호환성이 있다라는 것은 프로바이더의 인터페이스가 컨슈머 인터페이스의 서브 클래스의 하나(역으로 말하면, 컨슈머의 인터페이스가 프로바이더의 인터페이스의 슈퍼 클래스의 하나)라는 것이 됩니다.
서비스 포트
RT컴포넌트는 데이터 포트와 같이 임의의 수의 서비스 포트를 가질 수 있습니다. 또한, 서비스 포트에는 임의의 종류, 임의의 갯수의 프로바이더 또는 컨슈머를 부가할 수 있습니다.
이하는 OpenRTM-aist의 샘플 컴포넌트 MyServiceProvider에서 발췌한 포트와 프로바이더의 등록을 위한 코드입니다.
RTC::ReturnCode_t MyServiceProvider::onInitialize() { // Set service provider to Ports m_MyServicePort.registerProvider("myservice0", "MyService", m_myservice0); // Set CORBA Service Ports addPort(m_MyServicePort); return RTC::RTC_OK; }m_MyServicePort.registerProvider()로 프로바이더를 서비스 포트 오브젝트 m_MyServicePort에 등록하고 있습니다. 제3인수가 실체 프로바이더 오브젝트 입니다. 다음으로 컴포넌트의 프레임 워크 클래스인 RTObject 클래스의 addPort()함수로 포트를 컴포넌트에 등록하고 있습니다.
위에서와 같이 샘플 컴포넌트 MyServiceConsumer에서 발췌한 코드를 나타냅니다.
RTC::ReturnCode_t MyServiceConsumer::onInitialize() { // Set service consumers to Ports m_MyServicePort.registerConsumer("myservice0", "MyService", m_myservice0); // Set CORBA Service Ports addPort(m_MyServicePort); return RTC::RTC_OK; }프로바이더의 경우와 거의 같이 m_MyServicePort.registerConsumer()함수로 컨슈머를 포트에 등록해 그 포트를 addPort()함수로 컴포넌트에 등록하고 있습니다.
이상 특별히 설명도 없이 각각 m_myservice0라고 하는 오브젝트가 프로바이더 또는 컨슈머라고 하며 코드 예를 나타냈습니다만, 아래에 이러한 인터페이스가 어떻게 정의되고 오브젝트가 어떻게 구현되고 있는지를 설명 하겠습니다.
인터페이스 정의
인터페이스란 무엇입니까? C++라면 순수 가상 클래스를 인터페이스라고 부르고, Java는 언어 레벨에서 interface 키워드가 준비되어 있습니다.
OpenRTM-aist에서는 언어나 OS에 의존하지 않고 네트워크 투과라는 특징이 있습니다만 이것은 CORBA라고 불리우는 분산 오브젝트 미들웨어를 이용하는 것에 의해 실현되고 있습니다. CORBA는 국제 표준화 단체 OMG에서 표준화 되어 있는 분산 오브젝트 미들웨어로 표준에 따라서 많은 회사나 단체, 개인 등이 다양한 실장을 제공하고 있습니다.
OpenRTM-aist에서는 인터페이스는 IDL이라고 부르는 CORBA의 인터페이스 정의 언어에 의해 정의합니다. 이 IDL은 언어에 의존하지 않는 인터페이스 정의 방법을 제공하고, 또한 IDL 컴파일러라고 불리는 스텁이나 스켈레톤을 생성 툴을 이용하는 것으로 각종 언어에 대응한 코드가 자동적으로 생성됩니다. 스 텁이란 원격 오브젝트를 호출하기 위한 프록시 오브젝트를 위한 코드이고 스켈레톤은 프로바이더를 구현하기 위한 베이스가 되는 코드입니다.
이렇게 자동 생성된 코드 덕분에 다른 언어끼리의 호출도 무결절적으로 실시할 수 있습니다. 예를 들면 C++로 작성된 프로바이더를 Python이나 Java등으로 용이하게 호출할 수 있는 것 입니다.
아래는 OpenRTM-aist의 샘플에서 사용되고 있는 IDL 정의입니다.
module SimpleService { typedef sequence<string> EchoList; typedef sequence<float> ValueList; interface MyService { string echo(in string msg); EchoList get_echo_history(); void set_value(in float value); float get_value(); ValueList get_value_history(); }; };module이란 C++에서 말하는 네임 스페이스와 같은 것으로 이것에 의해 인터페이스 명을 취하여 충돌을 막을 수 있습니다.
C언어 등과 같이 typedef 키워드가 있습니다. 위의 예에서는 sequence라고 불리는 동적 배열형을 정의하고 있습니다. 하나는 string(문자열 형)형의 리스트로서 EchoList형, 또하나는 float형의 리스트로서 ValueList형을 정의하고 있습니다. 특히 sequence형은 typedef하지 않고 정의중에 직접 사용할 수 없기 때문에 이와 같이 미리 typedef해 둘 필요가 있습니다.
다음에 interface로 시작하는 부분이 실제 인터페이스의 정의가 됩니다. MyService 인터페이스에는 5개의 함수(IDL에서는 오퍼레이션이라고 부릅니다.)가 정의되어 있습니다. 대부분은 C언어나 Java 등과 같은 정의입니다만, IDL에서는 인수가 입력인지 출력인지를 명확하게 하기 위해 인수 선언 전에 in, out 또는 inout의 수식자가 붙습니다.
IDL 컴파일
그림에 IDL 정의, IDL 컴파일, 프로바이더의 구현 및 스텁의 이용의 흐름을 나타냅니다.
정의된 IDL을 IDL 컴파일러로 컴파일하면 일반 스텁과 스켈레톤( 또는 서버와 클라이언트라고 부르는 경우도 있음)을 위한 코드가 생성됩니다.
클라이언트, 즉 서비스를 이용하는 측은 스텁 코드를 인클루드 하는 등 스텁에서 정의되고 있는 프록시(대리) 오브젝트를 이용하여 원격에 있는 서버의 기능에 액세스합니다. 아래에 C++에서의 코드 예를 나타냅니다.
MyService_var라는 것은 프록시 오브젝트를 위한 선언입니다. mysvobj에 원격 오브젝트의 참조를 어떠한 형태로 대입하면, 그 밑에서 행해지고 있는 myoperation()함수의 호출은 실제로는 원격에 존재하는 오브젝트에 대해 행해집니다. 이 MyService_var 클래스가 정의되어 있는 것이 스텁에 해당합니다.
한편, 위의 방법에 의해 실제로 호출된 서버측의 오브젝트는 아래와 같이 스켈레톤 클래스를 물려받아 아래와 같이 구현됩니다.
class MyServiceSVC_impl : public virtual MyService, public virtual PortableServer::RefCountServantBase { public: MyServiceSVC_impl() {}; virtual ~MyServiceSVC_impl() {}; Retval myoperation(ArgType argument) { return do_ something(argument); } };더욱이 여기서 정의된 하위 클래스를 인스턴스화 하여 CORBA 오브젝트 로서 액티베이트 하는 것으로 원격에서 오퍼레이션을 호출할 수 있습니다.
IDL을 정의해 컴파일하는 것으로 분산 오브젝트를 정의하여 이용할 때 필요한 대부분의 코드가 자동적으로 생성됩니다. 단, 위의 「어떤 방법으로 원격 오브젝트의 참조를 취득」하거나, 「CORBA의 ORB을 기동하기 위한 여러가지 방법」라고 하는 것은 CORBA를 직접 이용하는 경우에는 여전히 코딩할 필요가 있는 부분이고, 이것들은 CORBA를 이용하는데도 이해하기 어렵거나 번잡한 작업이 필요한 부분입니다.
그렇지만 OpenRTM-aist를 이용하면 이러한 CORBA의 여러가지 호출의 대부분은 은폐되어 작성자는 클라이언트의 호출, 하위 클래스의 구현에만 집중할 수 있습니다. 이하에는 하위 클래스를 작성해 프로바이더로서 컴포넌트에 등록하는 방법, 컨슈머로서 프로바이더를 이용하는 방법에 대해 자세히 설명합니다.
구현
서비스 포트의 구현에 있어서는 RTCBuilder를 사용하는 것이 편리합니다. 스스로 서비스 포트, 프로바이더 및 컨슈머를 구현하는 것도 가능하지만, CORBA나 IDL 컴파일러에 정통해야 하고 Makefile과 코드의 여러 부분을 수정해야 하기 때문에 그다지 권해드리지 않습니다.
RTCBuilder의 자세한 사용법은 RTCBuilder의 매뉴얼을 참조해 주십시오.
IDL 정의
서비스 포트를 이용할 때는 이용하는 인터페이스를 미리 IDL로 정의하던지 기존의 IDL 파일을 적당한 디렉토리에 배치할 필요가 있습니다.
IDL의 정의 방법에 대해서는 여기에서는 자세히는 설명하지 않지만 대체로 아래와 같은 포맷으로 정의할 수 있어, C언어나 Java에 익숙한 사용자라면 비교적 용이하게 정의할 수 있습니다.
// 네임 스페이스를 위한 모듈을 정의할 수 있다. // 모듈 정의는 적극적으로 사용하는 것이 추천 된다. module <모듈 명> { // 구조체를 정의할 수 있다. struct MyStruct // 구조체 명 { short x; // int형은 short와 long만 이용 가능 short y; long a; long b; double dval; // 부동 소수점형은 float와 double만 이용 가능 float fval; string strval; // 문자열을 위해 string가 이용 가능 }; // 동적 배열 sequence 형은 미리 typedef 할 필요가 있다 typedef sequence<double> DvalueList; typedef sequence<MyStruct> MyStructList; // 임의의 구조체도 sequence형으로 가능 // 인터페이스 정의 interface MyInterface // 인터페이스 명 { void op1(); // 리턴값 없고, 인수 없을 경우 // NG: 대문자・소문자를 구별하지 않는 언어에서는 이하의 정의가 문제가 되기 때문에 IDL에서는 에러가 된다 // short op2(in MuStruct mystruct); short op2(in MyStruct mydata); // 인수는 {in, out, inout} 로 방향을 지정 oneway void op3(); // 리턴값 없는 오퍼레이션은 onway 키워드가 이용 가능 void op4(in short inshort, out short outshort, inout short ioshort); void op5(MyInterface myif); // MyInterface 자신을 인수로 이용하는 것도 가능 }; // 동일한 IDL 파일에 복수의 interface를 지정하는 것도 가능 interface YourInterface { void op1(); }; };RTCBuilder에 의한 설계
위와 같이 IDL에서 정의한 인터페이스를 앞으로 개발하는 RT컴포넌트의 서비스 포트의 프로바이더 혹은 컨슈머로서 사용하기 위해서는 컴포넌트의 코드 제네레이터인 RTCBuilder에서 서비스 포트를 설계해 그 때에 이 IDL정의를 줄 필요가 있습니다.
RTCBuilder의 신규 프로젝트를 작성해 퍼스펙티브를 엽니다. 각종 프로파일(컴포넌트의 이름이나 카테고리 명)등 필요한 설정을 한 후, 서비스 포트 탭을 열면 다음과 같은 화면이 나타납니다.
우선, Add Port버튼을 눌러 서비스 포트를 하나 추가합니다. 그렇게 하면 sv_name이라는 서비스 포트가 하나 추가되어 아래의 BuildView의 컴포넌트 박스에 작은 정사각형의 포트가 한개 추가됩니다. RTCBuilder의 에디터 왼쪽 포트 리스트의 sv_name을 클릭하면 우측에 RT-Component Service Port Profile가 표시되고 포트명을 적당한 이름(여기에서는 MyServiceProviderPort)으로 변경합니다.
에디터 왼쪽의 포트 리스트의 MyServiceProviderPort을 클릭해 Add Interface버튼을 클릭하면 MyServiceProviderPort 에 인터페이스 if_name이 하나 추가되고 방금전과 같이 에디터 왼쪽의 if_name을 클릭해 RT-Component Service Port Interface Profile상에서 if_name을 적당한 이름(여기에서는 MyServiceProvider)로 변경 합니다. 아래의 BuildView에서는 정사각형의 포트에 롤리팝이 추가되어 프로바이더 (Provided Interface)가 포트에 부가되는 것을 시각적으로 확인할 수 있습니다.
에디터 우측의 Interface Profile에서는 인터페이스의 프로파일을 설정합니다. 예를 들면 방향의 드롭 다운 리스트에서는 대상의 인터페이스가 프로바이더(Provided)인지 컨슈머(Required)인지를 지정합니다.
여기에서는 프로바이더를 추가하려고 하기 때문에 Provided 대로 합니다. 이 외, 인스턴스명, 변수명 등도 지정할 수 있습니다만, 필수는 아닙니다. 인터페이스명은 접속시에 프로바이더와 컨슈머의 인스턴스명이 같다면 대응 관계를 지정하지 않더라도 포트의 접속을 자동적으로 실시하는 경우에 이용됩니다.
다만, 인스턴스명이 차이가 나도 접속시에 임의의 인터페이스 끼리를 접속할 수 없기 때문에 입력은 필수는 아닙니다. 또 변수명은 코드를 생성했을 때에 프로바이더 오브젝트를 대입하는 변수명을 지정하기 위한 항목입니다만, 이것도 인터페이스명에서 자동적으로 생성되기 때문에 입력은 임의입니다.
다음에 IDL의 지정과 인터페이스형의 지정을 합니다. 위에서 정의한 것과 같은 IDL을 적당한 디렉토리에 배치하고, IDL파일 지정 박스 옆의 Browse버튼을 눌러 대상이 되는 IDL을 지정합니다. 그러면 지정된 IDL로 정의된 인터페이스가 그 아래의 인터페이스형의 드롭 다운 리스트에 나타납니다. 이 드롭 다운 리스트에서 이 포트에 추가한 인터페이스명을 선택합니다. IDL파일에 문법 에러 등이 있을 경우에는 드롭 다운 리스트에 희망하는 인터페이스가 나타나지 않습니다. 다시 IDL파일의 정의를 클릭해 주십시오.
또한, 위 설명의 방향 드롭 다운 리스트에서 Required를 지정하면 이 인터페이스는 컨슈머가 됩니다. 이하는 다른 컴포넌트 MyServiceConsumer의 서비스 포트와 인터페이스 설정 화면의 예입니다.
에디터 아래의 BuildView에 포트에 소켓이 추가되어 컨슈머 (Required interface)가 포트에 부가되는 것을 확인할 수 있습니다.
프로바이더의 구현
프로바이더라는 것은 문자 그대로 서비스를 프로바이드(제공)하기 위한 인터페이스 입니다. 따라서, IDL로 정의된 인터페이스를 갖는 서비스의 내용을 구현할 필요가 있습니다.
프로바이터 인터페이스를 갖는 컴포넌트를 RTCBuilder로 설계한 경우 코드 생성을 하면, 컴포넌트의 소스의 모형과 함께, 예를 들어 C++의 경우는 <서비스 인터페이스명>SVC_impl.cpp과 <서비스 인터페이스명>SVC_impl.h이라는 프로바이더의 구현 코드의 모형도 생성됩니다.
아래에 각 언어에서 생성되는 프로바이더의 구현 모형 코드의 파일명을 나타냅니다.
<interface name>SVC_impl.h
이러한 구현 모형에는 IDL에 정의된 인터페이스에 상당하는 클래스가 미리 정의되어 있습니다.
여기에서는 C++에서의 구현 방법을 예를 들어 IDL로 정의된 오퍼레이션의 몇개인가를 구현해 볼 것입니다.
echo()함수의 작성
먼저, echo() 멤버 함수를 보겠습니다.
/* * Methods corresponding to IDL attributes and operations */ char* MyServiceSVC_impl::echo(const char* msg) { // Please insert your code here and remove the following warning pragma #ifndef WIN32 #warning "Code missing in function <char* MyServiceSVC_impl::echo(const char* msg)>" #endif return 0; }#warning 프리프로세서 지시문이 있습니다만, 이것은 gcc로 컴파일 할 때에 이 함수가 구현되어 있지 않은 것을 경고하기 위한 것이므로, #ifndef마다 삭제합니다.
char* MyServiceSVC_impl::echo(const char* msg) { return msg; }또한 이 함수는 echo() 함수의 인수에 주어진 문자열을 단지 호출한 측에 돌려주는 것만의 기능을 제공한다고 합니다. 따라서, 이하와 같이 구현하면 좋을 것입니다.
char* MyServiceSVC_impl::echo(const char* msg) { return msg; }그러나 이것은 컴파일시에 에러가 됩니다. const char*을 char*에 건네주고 있기 때문입니다. 또한, CORBA의 오브젝트의 구현 방법으로서도 잘못되어 있습니다. CORBA에서 return으로 반환되는 오브젝트는 ORB(Object Request Broker, 원격 오브젝트의 호울 부분을 맡는 부분, CORBA의 코어)에 의해 해체된다고 하는 룰이 있기 때문입니다. (return시에는 오브젝트의 소유권을 포기한다라고도 말합니다.)
따라서 return에는 별도 영역을 확보해 msg의 내용을 복사한 문자열을 반환할 필요가 있습니다. 이것에 따르면, 이하와 같이 구현한다면 좋을 것입니다.
char* MyServiceSVC_impl::echo(const char* msg) { char* msgcopy; msgcopy = malloc(strlen(msg)); strncpy(msgcopy, msg, strlen(msg)); return msgcopy; }여기에서는 malloc으로 영역을 확보하고 있습니다만 ORB는 free로 영역을 해체하는지 delete로 해체하는지는 모릅니다. 실제로 CORBA에서는 오브젝트(구조체나 배열 또는 그 복합형 등도 포함)나 문자열을 취급하기 위한 방법이 별도로 정해져 있어, 거기에 따라 함수의 인수를 받거나, 돌려주거나 할 필요가 있습니다.
CORBA에서 정해진 방법에 따르면 echo()함수는 이하와 같이 구현할 필요가 있습니다.
char* MyServiceSVC_impl::echo(const char* msg) { CORBA::String_var msgcopy = CORBA::string_dup(msg); return msgcopy._retn(); }함수내의 첫번째 행은 CORBA의 문자열 클래스 CORBA::String의 스마트 포인터인 CORBA::String_var형을 선언하고 있습니다. String_var형은 이른바 소유권을 관리하기 위한 스마트 포인터로 STL의 auto_ptr과 비슷합니다.
이 String_var형의 변수 msgcopy에 인수의 msg에 저장되어 있는 문자열을 복사하고 있는 것은 CORBA::string_dup()함수입니다. 이 함수에서는 인수로 주어진 문자열을 저장하는데 충분한 메모리 영역을 확보해 그 영역에 인수의 문자열을 복사하고 있습니다.
다음의 행에서는 return으로 호출된 곳으로 msgcopy내의 문자열을 반환하면서 오브젝트의 소유권을 포기, return측에 소유권을 이양하고 있습니다. 아래의 그림에 표시된 것과 같이 ORB에서는 return으로 반환된 문자열을 네트워크상의 원래 호출된 곳으로 송신한 다음, 문자열 오브젝트를 해방합니다.
이 룰을 잘 이해하면, msgcopy 오브젝트가 echo() 함수내에서 사용되지 않는 것에서 부터, echo()함수의 구현은 최종적으로는 이하와 같이 쓸 수도 있습니다.
char* MyServiceSVC_impl::echo(const char* msg) { return CORBA::string_dup(msg); }CORBA::string_dup() 함수에서 문자열 영역의 확보와 내용의 복사를 한 상태에서, 그 소유권을 직접 호출된 곳으로 주는 것이 됩니다.
이와 같이 서비스 프로바이더는 CORBA의 오브젝트이기 때문에 그 구현 방법은 통상의 C++의 구현과는 조금 다른 방식으로 할 필요가 있습니다. 특히, 함수의 인수 및 리턴값의 주고 받는 규약은 조금 복잡하게 보입니다. 다만, 위와 같이 오브젝트의 소유권이라는 사고를 염두에 두고 생각해보면 인수를 어떻게 주고 받아야 할 것인가 또는 리턴값을 어떻게 리턴해야 할 것인가가 저절로 밝혀집니다. 상세한 것에 대해서는 Appendix나 그 외의 CORBA의 참고서 등을 참고해 주십시오.
set_value(), get_value() 와 get_value_history()
다음은 set_value() 함수, set_value() 함수 및 set_value_list() 함수를 동시에 작성해 보겠습니다. 이러한 함수는 set_value()로 설정된 float형의 값을 저장해 두고 get_value()로 그 값을 리턴한다는 단순한 것입니다. 또한, get_value_history()에서는 지금까지 세트된 값의 이력을 저장해 두어, 이력을 리스트로서 리턴한다는 것입니다.
먼저 값을 저장해 놓을 변수를 준비합니다. 현재의 값은 MyServiceSVC_impl 클래스에 CORBA::Float형의 private 멤버로서 준비합니다. 한편, get_value_history()에서는 리턴값에 SimpleService::ValueList라는 CORBA의 시퀀스형이 사용되고 있기 때문에 이것을 멤버 변수로서 갖도록 합니다. 이러한 변수 선언을 MyServiceSVN_impl.h의 MyServiceSVC_impl 클래스 정의의 마지막에 다음과 같이 추가합니다.
class MyServiceSVC_impl : public virtual POA_SimpleService::MyService, public virtual PortableServer::RefCountServantBase { : (중략) private: CORBA::Float m_value; // 이 행을 추가한다 SimpleService::ValueList m_valueList; // 이 행을 추가한다 };변수의 초기화도 잊지말고 합니다. MyServiceSVC_impl.cpp의 생성자에서 m_value는 0.0으로, m_valueList는 길이 0으로 초기화 합니다.
MyServiceSVC_impl::MyServiceSVC_impl() : m_value(0.0), m_valueList(0) { // Please add extra constructor code here. }다음 set_value()함수를 작성합니다. 인수로 주어진 값을 멤버 변수 m_value에 대입하는 것과 동시에 m_valueList에도 추가합니다. CORBA의 시퀀스형은 동적 배열형으로 []오퍼레이터와 함께 length(), length(CORBA::ULong)의 함수를 이용할 수 있습니다. length()함수는 현재 배열의 길이를 반환해, length(CORBA::ULong)함수는 현재의 배열의 길이를 설정 합니다. 구현은 아래와 같이 됩니다.
void MyServiceSVC_impl::set_value(CORBA::Float value) throw (CORBA::SystemException) { m_value = value; // 현재값 CORBA::ULong len(m_valueList.length()); // 배열의 길이를 취득 m_valueList.length(len + 1); // 배열의 길이를 1개 늘림 m_valueList[len] = value; // 배열의 마지막에 value를 추가 return; }echo()함수와는 다르게 CORBA::Long형은 C++의 long int와 등가로, 오브젝트 소유권, 영역 확보나 폐기 등은 생각할 필요가 없습니다. 따라서 위와 같이 단순한 대입으로 상관없습니다. 또, 배열형은 2종류의 length()함수와 [] 오퍼레이터를 사용해 배열의 길이를 1개 증가하고 마지막에 인수 값을 대입하고 있습니다. 또한 OpenRTM-aist에서는 CORBA의 시퀀스형을 STL의 vector에 가까운 형태로 이용하기 때문에 함수 템플렛을 제공하고 있어, 그것을 사용하면
void MyServiceSVC_impl::set_value(CORBA::Float value) throw (CORBA::SystemException) { m_value = value; // 현재값 CORBA_SeqUitl::push_back(m_valueList, value); return; }와 같이 쓰는 것이 가능합니다. CORBA_SeqUtil.h에서는 for_each(), find(), push_back(), insert(), front(), back(), erase(), clear()라는 함수가 정의되어 있습니다.
get_value()는 아래와 같이 됩니다.
CORBA::Float MyServiceSVC_impl::get_value() throw (CORBA::SystemException) { return m_value; }저정된 값을 return으로 호출한 곳으로 리턴할 뿐입니다. 여기에서도 조금 전의 echo()의 예와는 다르게 CORBA::Float이 프리미티브형이기 때문에 소유권 등을 고려할 필요는 없습니다.
마지막으로 set_value_history()의 구현을 보고 갑니다. 값의 이력이 저장된 m_valueList를 리턴한다면 좋을 것 이라고 생각되지만 방금 전 설명한 소유권과 영역의 해방의 문제가 있기 때문에 아래와 같이 구현할 필요가 있습니다.
SimpleService::ValueList* MyServiceSVC_impl::get_value_history() throw (CORBA::SystemException) { SimpleService::ValueList_var vl; vl = new SimpleService::ValueList(m_valueList); return vl._retn(); }함수내 첫번째 행에서는 시퀀스형 오브젝트를 위한 스마트 포인터인 SimpleService::valueList_var형의 변수명을 선언하고 있습니다. 또한 다음의 행에서는 이 스마트 포인터에 대해 copy 생성자를 호출해 그 포인터를 대입하고 있습니다. 이것에 의해 영역의 확보와 값의 복사가 동시에 행해집니다. 마지막에 vl.retn()으로 vl이 저장하고 있는 시퀀스형의 오브젝트의 소유권을 포기하고 return측에 오브젝트를 건네주고 있습니다.
그리고 vl은 함수내에서 사용되지 않기 때문에 이하와 같이 쓸 수도 있습니다.
SimpleService::ValueList* MyServiceSVC_impl::get_value_history() throw (CORBA::SystemException) { return new SimpleService::ValueList(m_valueList); }이상 프로바이더의 작성에 대해 설명하였습니다만, 프로바이더가 이른바 CORBA 오브젝트이므로 사용하는 형, 변수의 주고 받는 구조 등 CORBA의 룰에 따라 작성해야 합니다. 처음에는 번거롭게 느껴지겠지만 프리미티브형에 대해서는 종래대로의 작성, 복잡한 오브젝트에 대해서는 메모리의 확보와 해제가 어디서 행해지는지, 소유권은 어느 쪽에 있는지를 이해하면 어떻게 작성해야 하는 것인가 이해할 수 있다고 생각합니다.
컨슈머의 이용
컨슈머에서는 위에서 작성된 서비스 프로바이터를 호출해 그 기능을 사용하는 것이 됩니다. 컨슈머를 갖는 컴포넌트의 모형 코드를 RTCBuilder로 생성한 경우에는 프로바이더의 경우와는 다르게 특별한 파일이 생성되지 않습니다.
그 대신 컴포넌트의 헤더에 아래와 같은 프로바이더의 플레이스 홀더인 컨슈머 오브젝트가 선언됩니다.
: (중략) // Consumer declaration // <rtc-template block="consumer_declare"> /*! */ RTC::CorbaConsumer<SimpleService::MyService> m_MyServiceConsumer; // </rtc-template> private: : (중략)이것은 RTC::CorbaConsumer 클래스 템플릿에 형인수 SimpleService::MyService를 주고 MyService형의 컨슈머를 선언하고 있는 것이 됩니다. 또한 작성 파일 쪽은 onInitialize()함수에서 컨슈머의 포트에 등록과 포트의 컴포넌트에 등록이 행해지고 있는 것을 확인할 수 있습니다.
RTC::ReturnCode_t MyServiceConsumer::onInitialize() { : (중략) // Set service consumers to Ports m_MyServiceConsumerPortPort.registerConsumer("MyServiceConsumer", "SimpleService::MyService", m_MyServiceConsumer); // Set CORBA Service Ports addPort(m_MyServiceConsumerPortPort); // </rtc-template> return RTC::RTC_OK; }헤더에서 선언되고 있는 m_MyServiceConsumer 변수가 registerConsumer() 멤버 변수에 의해 포트에 등록되어 있는 것을 알 수 있습니다. 제1 인수에는 이 컨슈머의 「인스턴스 변수」가, 제2 인수에는 컨슈머의 「인터페이스형」이 그리고 제3 인수에는 컨슈머의 인스턴스인 m_MyServiceConsumer 변수가 각각 주어지고 있습니다. 이것에 의해 컨슈머가 인터페이스명, 형이름 모두 포트에 관련되고 있는 것이 됩니다.
컨슈머 m_MyServiceConsumer는 위에서 설명한 것과 같이 프로바이더의 플레이스 홀더가 되어 있습니다. C++에서는 오브젝트에의 포인터와 같이 취급할 수 있습니다.
MyService 인터페이스에서는 string형(CORBA의 string형) 인수를 하나 취하는 echo() 오퍼레이션이 정의되어 있습니다. 따라서 예를들면 이하와 같이 echo()함수를 호출할 수 있습니다.
m_MyServiceConsumer->echo("Hello World");C++에서는 위와 같이 포인터, Java나 Python에서는 참조와 같은 오퍼레이션을 호출할 수 있는 것입니다.
그럼 여기에서 눈치가 빠른 사람이라면 포인터 또는 참조가 가르키는 곳은 도대체 어떻게 되어 있는지 생각할 것입니다. C++ 등에서도 예를 들어 아래와 같은 코드는 segmentation fault에러가 발생합니다.
class A { public: const char* echo(const char* msg) { std::cout << msg << std::endl; return msg; } }; int main (void) { A* a; a->echo("Hello World!!"); }a는 null 포인터이기 때문에 아무것도 오브젝트를 가르키지 않습니다. 이것과 같이 위의 m_MyServiceConsumer도 컴포넌트 기동 직후에는 어떠한 오브젝트도 가리키지 않기 때문에 당연히 오퍼레이션을 호출할 수 없습니다. 위의 class A의 경우에서는
int main (void) { A* a; a = new A(); a->echo("Hello World!!"); }오브젝트를 new로 생성해 변수 a에 대입하면 a는 그 시점에서 어느 오브젝트를 가리키는 정당한 포인터이기 때문에, class A의 멤버 함수인 echo()를 호출할 수 있습니다.
그렇지만 컴포넌트 없는 컨슈머가 호출하고 싶은 것은 네트워크상의 어디엔가에 있는 오브젝트의 오퍼레이션입니다. 따라서, m_MyServiceConsumer가 가리키는 것은 원격 오브젝트의 참조(CORBA 오브젝트 참조(레퍼런스))입니다.
실제로 아래의 그림과 같이 컨슈머는 그 포트가 프로바이더를 갖는 포트와 접속될 때, 대응하는 오브젝트 참조를 받습니다. 접속에 의해 컨슈머는 정당한 오브젝트를 가리키는 것이 되고 이렇게 하여 처음으로 오퍼레이션을 호출할 수 있습니다.
접속 후는(상대의 포트에 적당한 프로바이더가 존재한다면) 컨슈머의 오퍼레이션을 호출할 수 있습니다만, 접속하고 있지 않은 경우 또는 유호한 참조가 세트되어 있지 않은 경우에는 컨슈머 오브젝트는 예외를 던집니다. 그래서 컨슈머를 이용하는 경우 언제 접속이 되었는지, 또한 언제 접속이 끊어졌는지 모르기 때문에 항상 이 예외를 포착해 적절히 처리할 필요가 있습니다.
try { m_MyServiceConsumer->echo("Hello World!!"); } catch (CORBA::SystemException &e) { // 예외시의 처리 std::cout << "포트가 접속되어 있지 않습니다."" << std::endl; } catch (...) { // 그외의 예외 }또한, onExecute()멤버 함수내에서 예외가 발생해 함수 내부에서 포착되지 않은 경우, RTC는 에러 상태로 천이합니다.
이상을 근거로 하여 MyserviceConsumer 컴포넌트를 작성합니다. 이 예는 onExecute()에서 유저로 부터 입력을 대기하고, 각 오퍼레이션에 대응한 커멘드를 받아 커멘드에 따라 원격의 프로바이더의 오퍼레이션을 호출하여 결과를 돌려주는 간단한 것입니다.
그럼 먼저 유저에게 사용할 수 있는 커멘드를 게시하는 부분부터 봅시다.
RTC::ReturnCode_t MyServiceConsumer::onExecute(RTC::UniqueId ec_id) {try { std::cout << std::endl; std::cout << "Command list: " << std::endl; std::cout << " echo [msg] : echo message." << std::endl; std::cout << " set_value [value]: set value." << std::endl; std::cout << " get_value : get current value." << std::endl; std::cout << " get_echo_history : get input messsage history." << std::endl; std::cout << " get_value_history: get input value history." << std::endl; std::cout << "> "; std::string args; std::string::size_type pos; std::vector<std::string> argv; std::getline(std::cin, args);먼저 위에서 설명한 대로 컨슈머가 발생하는 예외를 포착하기 위해서는 try절로 둘러쌉니다. 사용가능한 커멘드 리스트를 표시해, 유저의 입력을 getline()함수로 받고 있습니다.
pos = args.find_first_of(" "); if (pos != std::string::npos) { argv.push_back(args.substr(0, pos)); argv.push_back(args.substr(++pos)); } else { argv.push_back(args); }이러한 커멘드 중에 인수를 받는 것은 echo와 set value만으로, 한편 이러한 커멘드는 인수를 한개만 받습니다. 받은 문자열을 최초의 공백에서 분할해 argv[0] = 커멘드, argv[1] = 인수로서 string의 vector에 저장합니다. echo, set_value커멘드에서는 argv[1]를 인수로서 이용하여 다른 커멘드에서는 단순히 무시하기로 하겠습니다.
if (argv[0] == "echo" && argv.size() > 1) { CORBA::String_var retmsg; retmsg = m_myservice0->echo(argv[1].c_str()); std::cout << "echo return: " << retmsg << std::endl; return RTC::RTC_OK; }echo 커멘드의 작성입니다. argv[0]가 echo인 경우, argv[1]을 인수로 해 echo()함수를 호출합니다. echo()의 CORBA의 string형의 리턴값을 받기 위한 변수로서, retmsg를 선언하고 있습니다. echo()의 리턴값의 소유권은 이쪽에 있기 때문에, 받은 후에 적절히 영역을 해제할 필요가 있습니다만, String_var형의 스마트 포인터를 이용하면 불필요하게 되는 시점에 적절히 영역을 해제하여 줍니다. 리턴값을 표시하고 return RTC::RTC_OK로 onExecute()함수를 빠져 나옵니다.
if (argv[0] == "set_value" && argv.size() > 1) { CORBA::Float val(atof(argv[1].c_str())); m_myservice0->set_value(val); std::cout << "Set remote value: " << val << std::endl; return RTC::RTC_OK; }set_value 커멘드의 작성입니다. 인수 argv[1]의 문자열을 CORBA::Float형으로 변환해 set_value() 오퍼레이션의 인수에 주고 있습니다.
if (argv[0] == "get_value") { std::cout << "Current remote value: " << m_myservice0->get_value() << std::endl; return RTC::RTC_OK; }get_value 커멘드는 set_value 커멘드에서 설정한 값을 취득합니다. get_value() 오퍼레이션은 리턴값이 CORBA::Float로 값을 건네주기 위해 오브젝트의 소유권등은 특별히 생각하지 않아도 괜찮습니다. 여기에서는 리턴값을 그대로 std::cout으로 콘솔에 표시시키고 있습니다.
if (argv[0] == "get_echo_history") { EchoList_var elist = m_myservice0->get_echo_history(); for (CORBA::ULong i(0), len(elist.length(); i <len; ++i) { std::cout << elist[i] << std::endl; } return RTC::RTC_OK; }get_echo_history 커멘드에서는 get_echo_history()의 결과를 받아, 그것까지 echo 커멘드로 인수로 주어진 문자열의 리스트를 돌려주고 있습니다. get_echo_history()함수의 리턴값은 CORBA의 시퀸스형인 EchoList입니다. 시퀸스형에 대해서도 스마트 포인터인 _var형이 정의되어 있기 때문에, 이것을 이용합니다. 배열의 길이를 취득하기 위한 length() 함수를 이용할 수 있기 때문에, 길이를 조사해 for문에서 모든 요소를 표시하고 있습니다. 시퀸스형의 _var형에서는 위와 같이 [] 오퍼레이터를 이용해 C언어의 배열과 같이 각 요소에 액세스할 수 있습니다.
if (argv[0] == "get_value_history") { ValueList_var vlist = m_myservice0->get_value_history(); for (CORBA::ULong i(0), len(vlist.length()); i < len; ++i) { std::cout << vlist[i] << std::endl; } return RTC::RTC_OK; }마지막으로 get_value_history 커멘드입니다. get_value_history() 오퍼레이션을 호출하여, 지금까지 설정된 최근 몇개의 리스트를 표시합니다. get_value_history()함수의 리턴값은 CORBA::Float의 시퀸스형인 ValueList입니다. 요소는 CORBA::Float이기 때문에 오브젝트의 소유권등은 고려하지 않아도 되지만, 시퀸스형은 그것 자신이 오브젝트이므로 소유권을 고려해야 하기 때문에 여기에서는 _var형의 변수로 받고 있습니다.
std::cout << "Invalid command or argument(s)." << std::endl; } catch (CORBA::SystemException &e) { std::cout << "No service connected." << std::endl; } return RTC::RTC_OK; }마지막으로 위의 어느 것에도 맞지 않았던 커멘드의 경우에, 메세지를 보내고 있습니다. 또, 컨슈머에 참조가 세트되어 있지 않은 경우를 포함한 예외를 포착하기 위한 catch절이 있습니다.
이상으로 컨슈머에 의한 오퍼레이션의 호출법에 대해 간단히 예를 들어 설명하였습니다. 컨슈머를 이용할 때는 반드시 오브젝트 참조가 세트되었다고는 한정할 수 없으므로, 반드시 예외를 포착해 대처하는 것과 각 오퍼레이션의 호출이 CORBA의 룰에 근거하여 행해지는 것을 유의하여 주십시오.