[openrtm-commit:00284] r272 - trunk/OpenRTM-aist-docs/Documents/03_DevelopersGuide/01_Basic_RTC_Programming/03_ServciePort

[openrtm ＠ openrtm.org]

Author: n-ando
Date: 2011-07-31 19:28:09 +0900 (Sun, 31 Jul 2011)
New Revision: 272

Modified:
   trunk/OpenRTM-aist-docs/Documents/03_DevelopersGuide/01_Basic_RTC_Programming/03_ServciePort/03_ServicePort_en.txt
Log:
Service Port implementation tutorial in English has been updated.

Modified: trunk/OpenRTM-aist-docs/Documents/03_DevelopersGuide/01_Basic_RTC_Programming/03_ServciePort/03_ServicePort_en.txt
===================================================================
--- trunk/OpenRTM-aist-docs/Documents/03_DevelopersGuide/01_Basic_RTC_Programming/03_ServciePort/03_ServicePort_en.txt	2011-07-31 10:27:27 UTC (rev 271)
+++ trunk/OpenRTM-aist-docs/Documents/03_DevelopersGuide/01_Basic_RTC_Programming/03_ServciePort/03_ServicePort_en.txt	2011-07-31 10:28:09 UTC (rev 272)
@@ -0,0 +1,1480 @@
+// -*- pukiwiki-edit -*-
+// 
+// @brief How to use Service Port Basic
+// @date $Date$
+// @author Noriaki Ando <n-ando at aist.go.jp>
+// 
+// Copyright (C) 2011
+//     Noriaki Ando
+//     Intelligent Systems Research Institute,
+//     National Institute of
+//         Advanced Industrial Science and Technology (AIST), Japan
+//     All rights reserved.
+// 
+// $Id$
+// 
+//* Service Port (Basic)
+
+#contents
+
+//------------------------------------------------------------
+** What is service port?
+
+// ƒƒ{ƒbƒgƒVƒXƒeƒ€‚ðƒRƒ“ƒ|[ƒlƒ“ƒgŽwŒü‚ō\’z‚·‚邽‚߂ɂ́AƒRƒ“ƒ|[ƒlƒ“ƒg
+// ŠÔ‚̃f[ƒ^’ʐM‚¾‚¯‚ł͏\•ª‚Å‚Í‚È‚­AƒRƒ}ƒ“ƒhƒŒƒxƒ‹(‚ ‚é‚¢‚͊֐”ƒŒƒxƒ‹)
+// ‚̃Rƒ“ƒ|[ƒlƒ“ƒgŠÔ’ʐM‚ª•K—v‚É‚È‚Á‚Ä‚«‚Ü‚·B—Ⴆ‚΁Aƒƒ{ƒbƒgƒA[ƒ€‚ð§
+// Œä‚·‚éƒ}ƒjƒsƒ…ƒŒ[ƒ^ƒRƒ“ƒ|[ƒlƒ“ƒg‚̏ꍇAŽèæ‚̈ʒu‚⑬“x‚Ȃǂ́AãˆÊ
+// ‚̃AƒvƒŠƒP[ƒVƒ‡ƒ“‚âƒRƒ“ƒ|[ƒlƒ“ƒg‚©‚çƒf[ƒ^ƒ|[ƒg‚Å‘—‚ç‚ê‚é‚ׂ«ƒf[ƒ^
+// ‚Å‚·B
+
+When you construct your robot systems according to the component based
+software development, not only data-centric communication but also
+command (or function call) based communication between components is
+necessary.  For example, in case of a manipulator component which
+controls robot arm, position or velocity of end-effector should be
+given through data port from application programs of upper layer.
+
+// ˆê•ûAƒƒ{ƒbƒgƒA[ƒ€‚ÌŠeŽíÝ’èAÀ•WŒn‚̐ݒèA§Œäƒpƒ‰ƒ[ƒ^‚̐ݒèA“®
+// ìƒ‚[ƒh‚̐ݒèA‚È‚Ç‚ðƒf[ƒ^ƒ|[ƒg‚ōs‚¤‚Ì‚Í“KØ‚Æ‚ÍŒ¾‚¦‚¸AƒIƒuƒWƒFƒN
+// ƒgŽwŒü“I‚É‚¢‚¦‚΁Aƒ}ƒjƒsƒ…ƒŒ[ƒ^ƒIƒuƒWƒFƒNƒg‚ɑ΂µ‚āA
+// setCoordinationSystem(), setParameter(), setMode(), ‚Ȃǂ̊֐”‚ª—pˆÓ‚³
+// ‚ê‚Ä‚¢‚āA‚±‚ê‚ç‚̊֐”‚ð•K—v‚ɉž‚¶‚Ä“KØ‚ȃ^ƒCƒ~ƒ“ƒO‚ŌĂԂ̂ªŽ©‘R‚Æ‚¢
+// ‚¦‚Ü‚·B
+
+On the other hand, according to the object oriented principle,
+coordination settings, control parameters settings, operation mode
+settings and other miscellaneous settings for the robot arm should not
+be performed through data ports .  It is natural that these
+functionalities are invoked through certain member functions such as
+setCoordinationSystem(), setParameter() and setMode() of a manipulator
+object as necessary at the right time.
+
+#ref(serviceport_example_en.png,40%,center)
+CENTER: ''An example of service port''
+
+// ƒT[ƒrƒXƒ|[ƒg‚Í‚±‚̂悤‚ȃRƒ}ƒ“ƒhƒŒƒxƒ‹‚̃Rƒ“ƒ|[ƒlƒ“ƒgŠÔ‚Ì‚â‚èŽæ‚è‚ð
+// s‚¤‚½‚ß‚ÌŽd‘g‚Ý‚ð’ñ‹Ÿ‚µ‚Ü‚·B
+
+The service port provides a mechanism for a command based (or service
+based) communication between components.
+
+// ˆê”ʂɃT[ƒrƒX‚Ƃ́A‹@”\“I‚ÉŠÖ˜A‚Ì‚ ‚é‚ЂƂ܂Ƃ܂è‚̃Rƒ}ƒ“ƒh (ŠÖ”Aƒ
+// ƒ\ƒbƒhAƒIƒyƒŒ[ƒVƒ‡ƒ“‚È‚Ç‚Æ‚àŒÄ‚΂ê‚Ü‚·) ŒQ‚Å‚ ‚èAOpenRTM-aist‚É‚¨‚¢
+// ‚ẮA‚±‚Ì‹@”\‚ð’ñ‹Ÿ‚·‚鑤‚ðƒT[ƒrƒXƒvƒƒoƒCƒ_(ƒCƒ“ƒ^[ƒtƒF[ƒX)A‹@”\
+// ‚ð—˜—p‚·‚鑤‚ðƒT[ƒrƒXƒRƒ“ƒVƒ…[ƒ}(ƒCƒ“ƒ^[ƒtƒF[ƒX)‚ƌĂт܂·B
+
+Generally speaking, a service means a set of commands (it is also
+called as functions, methods or operations) which are functionally
+related each other. In the OpenRTM-aist, entities which provide
+functionality are called a service-provider (interface), and entities
+which require and use other service entities are called a service
+consumer (interface).
+
+// ‚È‚¨AUML“™‚Ì‹K–ñ‚É‚¨‚¢‚ẮAƒT[ƒrƒXƒvƒƒoƒCƒ_‚ð Privided Interface,
+// ‚Ü‚½ƒT[ƒrƒXƒRƒ“ƒVƒ…[ƒ}‚ð Required Interface ‚ȂǂƌĂсA‚»‚ꂼ‚ꉺ}
+// ‚̂悤‚È‹L† (ƒƒŠƒ|ƒbƒv (lollipop) Aƒ\ƒPƒbƒg (socket) ) ‚Å•\‚µ‚Ü‚·B
+// ‚±‚ê‚́Aˆê”Ê“I‚È—pŒê‚¨‚æ‚Ñ‹Lq–@‚È‚Ì‚ÅŠo‚¦‚Ä‚¨‚¢‚½•û‚ª‚æ‚¢‚Å‚µ‚傤BŒÄ
+// ‚Ô‚ ‚é‚¢‚͌Ă΂ê‚é•ûŒü‚Å‚¢‚¦‚΁AŒÄ‚΂ê‚é‚à‚Ì‚ªƒvƒƒoƒCƒ_ (Provided
+// Interface) ‚Å‚ ‚èAŒÄ‚Ô‚à‚Ì‚ªƒRƒ“ƒVƒ…[ƒ} (Required Interface) ‚Æ‚¢‚¤Œ©
+// •û‚à‚Å‚«‚Ü‚·B
+
+In the UML specifications and its notation rules as well, the service
+provider is called as ''Provided Interface'' and the service consumer
+is called as ''Required Interface'', and they are designated as the
+following notation.
+
+#ref(provider_and_consumer_en.png,40%,center)
+CENTER: ''Service provider and consumer''
+
+- Provided Interface: An entity that is called from others and provides services
+- Required Interface: An entity that calls and uses other's services 
+
+// ƒvƒƒoƒCƒ_‚¨‚æ‚уRƒ“ƒVƒ…[ƒ}‚ð‚܂Ƃ߂ăCƒ“ƒ^[ƒtƒF[ƒX‚Ü‚½‚́AƒT[ƒrƒX
+// ƒCƒ“ƒ^[ƒtƒF[ƒX‚ƌĂсA‚±‚ê‚çƒT[ƒrƒXƒCƒ“ƒ^[ƒtƒF[ƒX‚ðŽ‚Âƒ|[ƒg‚ðƒT[
+// ƒrƒXƒ|[ƒg‚ƌĂт܂·B
+
+The providers and the consumers are referred to collectively as the
+interfaces or the service interfaces, and the port which has these
+service interfaces is called the service port.
+
+** Service port and interfaces
+
+// ƒT[ƒrƒXƒCƒ“ƒ^[ƒtƒF[ƒX‚ƃT[ƒrƒXƒ|[ƒg‚ÌŠÖŒW‚ɂ‚¢‚ďڂµ‚­à–¾‚µ‚Ü‚·B
+
+This section describes the relation between service interfaces and
+service ports in detail.
+
+#ref(component_port_interface_ja.png,40%,center)
+CENTER: ''The component, the port and the interface''
+
+// ƒ|[ƒg‚Ƃ̓Rƒ“ƒ|[ƒlƒ“ƒg‚É•t‘®‚µAƒRƒ“ƒ|[ƒlƒ“ƒgŠÔ‚̐ڑ±‚Ì’[“_‚Æ‚È‚é•”
+// •ª‚ðŽw‚µ‚Ü‚·BƒRƒ“ƒ|[ƒlƒ“ƒgŠÔ‚̐ڑ±‚Ƃ́AƒRƒ“ƒ|[ƒlƒ“ƒg‚É•t‘®‚·‚éƒ|[
+// ƒgŠÔ‚Őڑ±‚ÉŠÖ‚·‚é’²’₪s‚í‚êA‰½‚ç‚©‚Ì‘ŠŒÝì—p (ƒf[ƒ^‚âƒRƒ}ƒ“ƒh‚Ì‚â
+// ‚èŽæ‚è) ‚ªs‚¦‚éó‘Ô‚É‚·‚邱‚Æ‚ðˆÓ–¡‚µ‚Ü‚·B
+
+The port is an end-point, which belongs to a component, for a
+connection between component.  Connecting two components means that
+negotiation between ports of components is done and a certain
+interaction (data-centric or command based) can be performed by it.
+
+// ƒ|[ƒgŽ©‘̂̓f[ƒ^‚âƒRƒ}ƒ“ƒh‚Ì‚â‚èŽæ‚è‚ɑ΂µ‚āA‰½‚Ì‹@”\‚à’ñ‹Ÿ‚µ‚Ü‚¹‚ñB
+// ŽÀÛ‚ɃRƒ}ƒ“ƒh‚Ì‚â‚èŽæ‚è‚ðs‚¤‚̂̓T[ƒrƒXƒCƒ“ƒ^[ƒtƒF[ƒX (ƒvƒƒoƒCƒ_
+// ‚ƃRƒ“ƒVƒ…[ƒ}) ‚É‚È‚è‚Ü‚·Bˆê”Ê“I‚Ƀ|[ƒg‚É‚Í‹@”\“I‚ÉŠÖ˜A‚Ì‚ ‚é”CˆÓ‚Ì
+// ”‚Ì”CˆÓ‚Ì•ûŒü‚̃Cƒ“ƒ^[ƒtƒF[ƒX‚ð•t‰Á‚·‚邱‚Æ‚ª‚Å‚«‚Ü‚·B‚±‚ê‚É‚æ‚èA
+// ƒRƒ}ƒ“ƒh‚Ì‚â‚èŽæ‚è‚ðˆê•ûŒü‚¾‚¯‚Å‚È‚­‘o•ûŒü‚É‚·‚邱‚Æ‚à‚Å‚«‚Ü‚·B
+
+The port does not provide any functionality for data or command
+communication.  Communication between components is actually performed
+by service interfaces (service providers and consumers.)  Generally a
+port can associate functionally related service interfaces of any
+number and any directions.  This means that not only oneway
+communication but also bidirectional communication can be performed
+through it.
+
+// ƒRƒ“ƒVƒ…[ƒ}‚ƃvƒƒoƒCƒ_‚́Aƒ|[ƒg‚ªÚ‘±‚³‚ꂽ‚Æ‚«‚ɁA‚ ‚éðŒ‚ÉŠî‚¢
+// ‚Đڑ±‚³‚êAƒRƒ“ƒVƒ…[ƒ}‚©‚çƒvƒƒoƒCƒ_‚Ì‹@”\‚ðŒÄ‚яo‚·‚±‚Æ‚ª‰Â”\‚É‚È‚è
+// ‚Ü‚·BƒRƒ“ƒVƒ…[ƒ}‚ƃvƒƒoƒCƒ_‚ðÚ‘±‚·‚邽‚߂ɂ́A—¼ŽÒ‚Ì''Œ^''‚ª“¯‚¶A
+// ‚Ü‚½‚͌݊·«‚ª‚ ‚é•K—v‚ª‚ ‚è‚Ü‚·B
+
+A consumer and a provider are connected based on a certain condition,
+and then a consumer is able to call provider's functions.  In order to
+connect a consumer and a provider, both ''type'' should be same or
+compatible.
+
+// “¯‚¶Œ^‚Å‚ ‚éA‚Æ‚Í“¯ˆê‚̃Cƒ“ƒ^[ƒtƒF[ƒX’è‹`‚ðŽ‚Â‚±‚Æ‚Å‚ ‚èAŒÝŠ·«‚ª
+// ‚ ‚é‚Ƃ́AƒvƒƒoƒCƒ_‚̃Cƒ“ƒ^[ƒtƒF[ƒX‚ªƒRƒ“ƒVƒ…[ƒ}‚̃Cƒ“ƒ^[ƒtƒF[ƒX
+// ‚̃TƒuƒNƒ‰ƒX‚̈ê‚‚ł ‚éA(‹t‚É‚¢‚¦‚΁AƒRƒ“ƒVƒ…[ƒ}‚̃Cƒ“ƒ^[ƒtƒF[ƒX‚ª
+// ƒvƒƒoƒCƒ_‚̃Cƒ“ƒ^[ƒtƒF[ƒX‚̃X[ƒp[ƒNƒ‰ƒX‚̈ê‚‚ł ‚é)‚Æ‚¢‚¤‚±‚Æ‚É‚È
+// ‚è‚Ü‚·B
+
+The same ''type'' means that both interfaces should have same
+definition, and the compatibility means that the provider's interface
+is one of the sub-classes of consumer's interface.  In other words,
+the consumer's interface should be one of the super-classes of the
+provider's interface.
+
+***The service port
+
+// RTƒRƒ“ƒ|[ƒlƒ“ƒg‚̓f[ƒ^ƒ|[ƒg“¯—lA”CˆÓ‚̐”‚̃T[ƒrƒXƒ|[ƒg‚ðŽ‚Â‚±‚Æ
+// ‚ª‚Å‚«‚Ü‚·B‚Ü‚½AƒT[ƒrƒXƒ|[ƒg‚ɂ́A”CˆÓ‚ÌŽí—ށA”‚̃vƒƒoƒCƒ_‚Ü‚½‚Í
+// ƒRƒ“ƒVƒ…[ƒ}‚ð•t‰Á‚·‚邱‚Æ‚ª‚Å‚«‚Ü‚·B
+
+The RT-Component can own any numbers of service ports so that data
+ports are so.  Moreover, a service port can own any kinds of and any
+numbers of providers and consumers.
+
+// ˆÈ‰º‚́AOpenRTM-aist‚̃Tƒ“ƒvƒ‹ƒRƒ“ƒ|[ƒlƒ“ƒg MyServiceProvider ‚©‚甲ˆ
+// ‚µ‚½ƒ|[ƒg‚ƃvƒƒoƒCƒ_‚Ì“o˜^‚Ì‚½‚߂̃R[ƒh‚Å‚·B
+
+The following code that is excerpted from MyServiceProvider sample
+code of OpenRTM-aist shows how to register a port and a provider to
+the component.
+
+ 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() ‚ŃvƒƒoƒCƒ_‚ðƒT[ƒrƒXƒ|[ƒgƒIƒuƒWƒF
+// ƒNƒg m_MyServicePort ‚É“o˜^‚µ‚Ä‚¢‚Ü‚·B‘æ3ˆø”‚ªŽÀ‘Ì‚Å‚ ‚éƒvƒƒoƒCƒ_ƒI
+// ƒuƒWƒFƒNƒg‚Å‚·BŽŸ‚ɁAƒRƒ“ƒ|[ƒlƒ“ƒg‚̃tƒŒ[ƒ€ƒ[ƒNƒNƒ‰ƒX‚Å‚ ‚é
+// RTObjectƒNƒ‰ƒX‚ÌaddPort() ŠÖ”‚ŁAƒ|[ƒg‚ðƒRƒ“ƒ|[ƒlƒ“ƒg‚É“o˜^‚µ‚Ä‚¢‚Ü
+// ‚·B
+
+m_MyServicePort.registerProvider() registers a provider to a service
+port object m_MyServicePort. The third argument is an entity of the
+provider object. And next, it is registered to the component by using
+addPort() function which is RTObject component framework class's
+member function.
+
+// “¯—l‚ɁAƒTƒ“ƒvƒ‹ƒRƒ“ƒ|[ƒlƒ“ƒg MyServiceConsumer ‚©‚甲ˆ‚µ‚½ƒR[ƒh‚ðŽ¦‚µ‚Ü‚·B
+
+Same as above, following shows the excerpted code from
+MyServiceConsumer sample component.
+
+ 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;
+ }
+
+// ƒvƒƒoƒCƒ_‚̏ꍇ‚Æ‚Ù‚Æ‚ñ‚Ç“¯‚¶‚ŁAm_MyServicePort.registerConsumer() ŠÖ
+// ”‚ŃRƒ“ƒVƒ…[ƒ}‚ðƒ|[ƒg‚É“o˜^‚µA‚»‚̃|[ƒg‚ð addPort() ŠÖ”‚ŃRƒ“ƒ|[
+// ƒlƒ“ƒg‚É“o˜^‚µ‚Ä‚¢‚Ü‚·B
+
+Almost same as the provider's case, m_MyServicePort.registerConsumer()
+function registers a consumer to a port, and the port is registered to
+the component by addPort function.
+
+// ˆÈãA“Á‚Éà–¾‚à‚È‚µ‚ɁA‚»‚ꂼ‚ê m_myservice0 ‚Æ‚¢‚¤ƒIƒuƒWƒFƒNƒg‚ªAƒv
+// ƒƒoƒCƒ_A‚Ü‚½‚̓Rƒ“ƒVƒ…[ƒ}‚Å‚ ‚é‚Æ‚µ‚ăR[ƒh—á‚ðŽ¦‚µ‚Ü‚µ‚½‚ªAˆÈ‰ºA
+// ‚±‚ê‚ç‚̃Cƒ“ƒ^[ƒtƒF[ƒX‚ª‚ǂ̂悤‚É’è‹`‚³‚êAƒIƒuƒWƒFƒNƒg‚ª‚ǂ̂悤‚É
+// ŽÀ‘•‚³‚ê‚é‚©‚ðà–¾‚µ‚Ä‚¢‚«‚Ü‚·B
+
+An object m_myservice0 assumed a provider and a consumer without any
+explanation and they are used in the codes shown above.  How to define
+these interfaces and how to implement these objects are shown in the
+following.
+
+***Interface defintion
+
+// ƒCƒ“ƒ^[ƒtƒF[ƒX‚Ƃ͉½‚Å‚µ‚傤‚©HC++‚Å‚ ‚ê‚΁Aƒˆ‰¼‘zƒNƒ‰ƒX‚ðƒCƒ“ƒ^[
+// ƒtƒF[ƒX‚ƌĂñ‚¾‚肵‚Ü‚·‚µAJava‚ÍŒ¾ŒêƒŒƒxƒ‹‚Å interface ƒL[ƒ[ƒh‚ª—p
+// ˆÓ‚³‚ê‚Ä‚¢‚Ü‚·B
+
+What is the interface?  In C++ language, pure virtual classes are
+called interface.  In Java language, ''interface'' keyword is used for
+interface definition.
+
+// OpenRTM-aist‚ɂ́AŒ¾Œê‚âOS‚Ɉˑ¶‚µ‚È‚¢Aƒlƒbƒgƒ[ƒN“§‰ß‚Å‚ ‚é‚Æ‚¢‚Á‚½
+// “Á’¥‚ª‚ ‚è‚Ü‚·‚ªA‚±‚ê‚ÍCORBA‚ƌĂ΂ê‚镪ŽUƒIƒuƒWƒFƒNƒgƒ~ƒhƒ‹ƒEƒGƒA‚ð—˜
+// —p‚·‚邱‚Æ‚É‚æ‚èŽÀŒ»‚³‚ê‚Ä‚¢‚Ü‚·BCORBA‚́A‘Û•W€‰»’c‘ÌOMG‚Å•W€‰»‚³
+// ‚ê‚Ä‚¢‚镪ŽUƒIƒuƒWƒFƒNƒgƒ~ƒhƒ‹ƒEƒGƒA‚ŁA•W€‚ɏ]‚Á‚āA‘½‚­‚̉ïŽÐ‚â’c‘́A
+// ŒÂl‚È‚Ç‚ª‘½—l‚ÈŽÀ‘•‚ð’ñ‹Ÿ‚µ‚Ä‚¢‚Ü‚·B
+
+The main important features of the OpenRTM-aist are language
+independence, OS independence and network transparency, and these
+features are realized by using the distributed object middleware which
+is called the CORBA.  The CORBA is one of the distributed object
+middleware which is standardized in a international standardization
+organization OMG (Object Management Group), and a lot of
+implementations compliant to the standard are provided by various
+companies, organizations and individuals.
+
+// OpenRTM-aist‚ł́AƒCƒ“ƒ^[ƒtƒF[ƒX‚ÍIDL‚ƌĂ΂ê‚éCORBA‚̃Cƒ“ƒ^[ƒtƒF[
+// ƒX’è‹`Œ¾Œê‚É‚æ‚Á‚Ä’è‹`‚µ‚Ü‚·B‚±‚ÌIDL‚ÍŒ¾Œê‚Ɉˑ¶‚µ‚È‚¢ƒCƒ“ƒ^[ƒtƒF[ƒX
+// ’è‹`•û–@‚ð’ñ‹Ÿ‚µA‚Ü‚½IDLƒRƒ“ƒpƒCƒ‰‚ƌĂ΂ê‚éƒXƒ^ƒu‚âƒXƒPƒ‹ƒgƒ“‚𐶐¬ƒc[
+// ƒ‹‚ð—˜—p‚·‚邱‚ƂŁAŠeŽíŒ¾Œê‚ɑΉž‚µ‚½ƒR[ƒh‚ªŽ©“®“I‚ɐ¶¬‚³‚ê‚Ü‚·BƒX
+// ƒ^ƒu‚Ƃ́AƒŠƒ‚[ƒg‚̃IƒuƒWƒFƒNƒg‚ðŒÄ‚яo‚·‚½‚߂̃vƒƒLƒVƒIƒuƒWƒFƒNƒg‚Ì
+// ‚½‚߂̃R[ƒh‚Å‚ ‚èAƒXƒPƒ‹ƒgƒ“‚Ƃ́AƒvƒƒoƒCƒ_‚ðŽÀ‘•‚·‚邽‚߂̃x[ƒX‚Æ
+// ‚È‚éƒR[ƒh‚Å‚·B
+
+In the OpenRTM-aist, interfaces are defined by the IDL (Interface
+Definition Language) that is an interface definition language of
+CORBA.  The IDL provides a definition scheme independent from any
+languages, and by using IDL compiler which generates stubs and
+skeletons, language dependent codes are automatically generated.  The
+stubs include code of proxy objects which call remote objects, and the
+skeletons include base classes to implement providers.
+
+// ‚±‚ê‚玩“®¶¬‚³‚ê‚éƒR[ƒh‚Ì‚¨‚©‚°‚ŁAˆÙ‚Ȃ錾Œê“¯Žm‚̌Ăяo‚µ‚àƒV[ƒ€
+// ƒŒƒX‚ɍs‚¤‚±‚Æ‚ª‚Å‚«‚Ü‚·B—Ⴆ‚΁AC++‚ÅŽÀ‘•‚³‚ꂽƒvƒƒoƒCƒ_‚ðAPython‚â
+// Java“™‚Å—eˆÕ‚ɌĂяo‚·‚±‚Æ‚ª‚Å‚«‚é‚Ì‚Å‚·B
+
+By the automatically generated codes, the invocation between different
+languages can be performed seamlessly.  For example, a provider object
+which is implemented in C++ language can be called from Python and/or
+Java easily.
+
+// ˆÈ‰º‚́AOpenRTM-aist‚̃Tƒ“ƒvƒ‹‚ÅŽg—p‚³‚ê‚Ä‚¢‚éIDL’è‹`‚Å‚·B
+
+An IDL definition used in a OpenRTM-aist's sample is shown in the
+following.
+
+ 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++‚ÅŒ¾‚¤‚Æ‚±‚ë‚Ì–¼‘O‹óŠÔ‚̂悤‚È‚à‚̂ŁA‚±‚ê‚É‚æ‚èƒCƒ“ƒ^[
+// ƒtƒF[ƒX–¼‚ðAE‚µÕ“Ë‚ð–h‚®‚±‚Æ‚ª‚Å‚«‚Ü‚·B
+
+The keyword ''module'' is almost same as namespace in C++ language,
+this qualifies the name of the interface and the collision of name can
+be avoided.
+
+// CŒ¾Œê“™‚Æ“¯—l‚É typedef ƒL[ƒ[ƒh‚ª‚ ‚è‚Ü‚·Bã‚Ì—á‚ł́Asequence ‚ÆŒÄ
+// ‚΂ê‚é“®“I”z—ñŒ^‚ð’è‹`‚µ‚Ä‚¢‚Ü‚·Bˆê‚‚́Astring (•¶Žš—ñŒ^) Œ^‚̃ŠƒXƒg
+// ‚Æ‚µ‚āAEchoList Œ^A‚à‚¤‚Ð‚Æ‚Â‚Í float Œ^‚̃ŠƒXƒg‚Æ‚µ‚Ä ValueList Œ^‚ð
+// ’è‹`‚µ‚Ä‚¢‚Ü‚·B“Á‚É sequence Œ^‚́Atypedef ‚¹‚¸‚ɁA’è‹`’†‚Å’¼ÚŽg‚¤‚±
+// ‚Æ‚ª‚Å‚«‚È‚¢‚̂ŁA‚±‚̂悤‚É—\‚ß typedef ‚µ‚Ä‚¨‚­•K—v‚ª‚ ‚è‚Ü‚·B
+
+You can use ''typedef'' keyword as same as C language.  An array type
+called ''sequence'' is defined in the above example.  A EchoList type
+as string list type and a ValueList type as float list type are
+defined. Especially, since you cannot use sequence types directly,
+the sequence type should be defined by using typedef before it is
+used.
+
+// ŽŸ‚É interface ‚ÅŽn‚Ü‚é•”•ª‚ªŽÀÛ‚̃Cƒ“ƒ^[ƒtƒF[ƒX‚Ì’è‹`‚É‚È‚è‚Ü‚·B
+// MyService ƒCƒ“ƒ^[ƒtƒF[ƒX‚ɂ́A5‚‚̊֐” (IDL‚ł̓IƒyƒŒ[ƒVƒ‡ƒ“‚ƌĂÑ
+// ‚Ü‚·) ‚ª’è‹`‚³‚ê‚Ä‚¢‚Ü‚·B‚Ù‚Æ‚ñ‚ǂ́ACŒ¾Œê‚âJava‚È‚Ç‚Æ“¯‚¶‚悤‚È’è‹`‚Å
+// ‚·‚ªAIDL‚ł͈ø”‚ª“ü—Í‚Å‚ ‚é‚©o—Í‚Å‚ ‚é‚©‚𖾊m‚É‚·‚邽‚߂ɁAˆø”éŒ¾
+// ‚Ì‘O‚ɁA''in'', ''out'' ‚Ü‚½‚Í ''inout'' ‚̏CüŽq‚ª•t‚«‚Ü‚·B
+
+Next, the part which starts with ''interface'' keyword is the actual
+interface definition.  The MyService interface owns five functions (in
+IDL they are called ''operations'') in it.  Syntax is almost same as C
+language and Java language, but one of the specifiers ''in'', ''out''
+or ''inout'' is put before each argument to specify whether the
+argument is used as input, output or both.
+
+***IDL compilation
+
+// }‚ɁAIDL’è‹`‚©‚çIDLƒRƒ“ƒpƒCƒ‹AƒvƒƒoƒCƒ_‚ÌŽÀ‘•‚¨‚æ‚уXƒ^ƒu‚Ì—˜—p‚Ì—¬
+// ‚ê‚ðŽ¦‚µ‚Ü‚·B
+
+The following figure shows the flow of IDL definition, IDL
+compilation, implementation of provider and use of stub.
+
+#ref(idlcompile_stub_skel_ja.png,40%,center)
+CENTER: ''IDL compilation and stub and skeleton''
+
+// ’è‹`‚³‚ꂽIDL‚ðIDLƒRƒ“ƒpƒCƒ‰‚É—^‚¦‚ăRƒ“ƒpƒCƒ‹‚ðs‚¤‚ƁA’ʏíƒXƒ^ƒu‚ƃX
+// ƒPƒ‹ƒgƒ“ (‚Ü‚½‚̓T[ƒo‚ƃNƒ‰ƒCƒAƒ“ƒg‚Æ‚¢‚¤ŒÄ‚Ñ•û‚ð‚·‚éê‡‚à‚ ‚é) ‚Ì‚½
+// ‚߂̃R[ƒh‚ª¶¬‚³‚ê‚Ü‚·B
+
+Giving defined IDL to a IDL compiler and compiling it, stubs and
+skeletons (these are sometimes called servers and clients) are
+generated.
+
+// ƒNƒ‰ƒCƒAƒ“ƒgA‚·‚È‚í‚¿ƒT[ƒrƒX‚ð—˜—p‚·‚鑤‚́AƒXƒ^ƒuƒR[ƒh‚ðƒCƒ“ƒNƒ‹[
+// ƒh‚·‚é‚È‚Ç‚µ‚āAƒXƒ^ƒu‚Æ‚µ‚Ä‚¢’è‹`‚³‚ê‚Ä‚¢‚éƒvƒƒLƒV(‘㗝)ƒIƒuƒWƒFƒNƒg
+// ‚ð—˜—p‚µ‚āAƒŠƒ‚[ƒg‚É‚ ‚éAƒT[ƒo‚Ì‹@”\‚ɃAƒNƒZƒX‚µ‚Ü‚·BˆÈ‰º‚ÉC++‚Å‚Ì
+// ƒR[ƒh—á‚ðŽ¦‚µ‚Ü‚·B
+
+A client, which is using service, accesses to the functions of server
+on a remote node through proxy object defined as stub that is included
+in the stub code.  An example in C++ language is shown in the
+following code.
+
+ MyService_var mysvobj = <something to get remote object reference>
+ Retval retval = mysvobj->myoperation(argument);
+
+// MyService_var ‚Æ‚¢‚¤‚Ì‚ªAƒvƒƒLƒVƒIƒuƒWƒFƒNƒg‚Ì‚½‚߂̐錾‚Å‚·B
+// mysvobj‚ɃŠƒ‚[ƒgƒIƒuƒWƒFƒNƒg‚ÌŽQÆ‚ð‰½‚ç‚©‚ÌŒ`‚Å‘ã“ü‚·‚é‚ƁA‚»‚̉º‚ōs
+// ‚í‚ê‚Ä‚¢‚é myoperation() ŠÖ”‚̌Ăяo‚µ‚́AŽÀÛ‚ɂ̓Šƒ‚[ƒg‚É‘¶Ý‚·‚éƒI
+// ƒuƒWƒFƒNƒg‚É‚¨‚¢‚čs‚í‚ê‚Ü‚·B‚±‚ÌMyService_var ƒNƒ‰ƒX‚ª’è‹`‚³‚ê‚Ä‚¢‚é
+// ‚Ì‚ªƒXƒ^ƒu‚É‚ ‚½‚è‚Ü‚·B
+
+A line starting with MyService_var is declaration for a proxy object.
+After substituting a remote object reference into the ''mysvobj''
+variable, the invocation of myoperation() function performs remote
+object function call actually.  The MyService_var class is the stub
+defined in the stub code.
+
+// ˆê•ûAã‹L‚Ì•û–@‚É‚æ‚Á‚ÄŽÀÛ‚ɌĂ΂ê‚éƒT[ƒo‘¤‚̃IƒuƒWƒFƒNƒg‚́AˆÈ‰º‚Ì
+// ‚悤‚ɃXƒPƒ‹ƒgƒ“ƒNƒ‰ƒX‚ðŒp³‚µ‚Ĉȉº‚̂悤‚ÉŽÀ‘•‚³‚ê‚Ü‚·B
+
+On the other hand, the server side object which is called by the above
+method is implemented by inheriting a skeleton class as follows.
+
+ class MyServiceSVC_impl
+   : public virtual MyService,
+     public virtual PortableServer::RefCountServantBase
+ {
+ public:
+    MyServiceSVC_impl() {};
+    virtual ~MyServiceSVC_impl() {};
+    Retval myoperation(ArgType argument)
+    {
+      return do_ something(argument);
+    }
+ };
+
+// ‚³‚ç‚ɁA‚±‚±‚Å’è‹`‚³‚ꂽƒT[ƒoƒ“ƒgƒNƒ‰ƒX‚ðƒCƒ“ƒXƒ^ƒ“ƒX‰»‚µACORBAƒIƒuƒWƒF
+// ƒNƒg‚Æ‚µ‚ăAƒNƒeƒBƒx[ƒg‚·‚邱‚ƂŁAƒŠƒ‚[ƒg‚©‚çƒIƒyƒŒ[ƒVƒ‡ƒ“‚ðŒÄ‚яo
+// ‚·‚±‚Æ‚ª‚Å‚«‚Ü‚·B
+
+And, instantiating a servant class defined above, and activating it as
+a CORBA object, operations can be called from remote node.
+
+ // some spells to startup ORB of CORBA
+ MyServiceSVC_impl mysvc;
+ POA->activate_object(id, mysvc);
+
+// IDL‚ð’è‹`‚µ‚āAƒRƒ“ƒpƒCƒ‹‚·‚邱‚ƂŁA•ªŽUƒIƒuƒWƒFƒNƒg‚ð’è‹`‚µ—˜—p‚·‚é‚Ì
+// ‚É•K—v‚ȑ唼‚̃R[ƒh‚ªŽ©“®“I‚ɐ¶¬‚³‚ê‚Ü‚·B‚½‚¾‚µAã‹L‚́u‰½‚ç‚©‚Ì•û
+// –@‚ŃŠƒ‚[ƒgƒIƒuƒWƒFƒNƒg‚ÌŽQÆ‚ðŽæ“¾v‚µ‚½‚èAuCORBA‚ÌORB‚ð‹N“®‚·‚邽
+// ‚ß‚Ì‚¢‚ë‚¢‚ë‚È‚¨‚Ü‚¶‚È‚¢v‚Æ‚¢‚Á‚½‚à‚̂́ACORBA‚𒼐ڗ˜—p‚·‚éê‡‚ɂ͈Ë
+// ‘R‚Æ‚µ‚ăR[ƒfƒBƒ“ƒO‚·‚é•K—v‚ª‚ ‚é•”•ª‚Å‚ ‚èA‚±‚ê‚ç‚ÍCORBA‚ð—˜—p‚·‚邤
+// ‚¦‚Å‚à—‰ð‚ª“‚©‚Á‚½‚èA”ÏŽG‚ȍì‹Æ‚ª•K—v‚Æ‚È‚é•”•ª‚Å‚·B
+
+Defining and compiling IDL, most of codes required to define and use
+distributed objects are generated automatically.  However, ''something
+to get remote object reference'' and ''some spells to startup ORB of
+CORBA'' are still required in the actual coding, and these are one of
+difficult and complicated things in use of CORBA.
+
+// ‚µ‚©‚µ‚È‚ª‚çAOpenRTM-aist‚ð—˜—p‚·‚ê‚΁A‚±‚¤‚µ‚½CORBA‚Ì—lX‚ȌĂяo‚µ‚Ì
+// ‘唼‚͉B•Á‚³‚êAŽÀ‘•ŽÒ‚̓Nƒ‰ƒCƒAƒ“ƒg‚̌Ăяo‚µAƒT[ƒoƒ“ƒg‚ÌŽÀ‘•‚É‚Ì‚Ý
+// W’†‚·‚邱‚Æ‚ª‚Å‚«‚Ü‚·BˆÈ‰º‚ł́AƒT[ƒoƒ“ƒg‚ðŽÀ‘•‚µƒvƒƒoƒCƒ_‚Æ‚µ‚ăR
+// ƒ“ƒ|[ƒlƒ“ƒg‚É“o˜^‚·‚é•û–@AƒRƒ“ƒVƒ…[ƒ}‚Æ‚µ‚ăvƒƒoƒCƒ_‚ð—˜—p‚·‚é•û–@
+// ‚ɂ‚¢‚ďڂµ‚­Œ©‚Ä‚¢‚«‚Ü‚·B
+
+Using OpenRTM-aist, however, most of these CORBA's native function
+calls are hidden, and developers can concentrate only to servants'
+implementation, and calling servers from clients.  In the following,
+how to implement servants and register it to the component and how to
+use providers from the consumers are described in details.
+
+** Implementation
+
+// ƒT[ƒrƒXƒ|[ƒg‚ÌŽÀ‘•‚É“–‚½‚Á‚ẮARTCBuilder‚ð—˜—p‚·‚é‚Ì‚ª•Ö—˜‚Å‚·BŽ©
+// •ª‚ŃT[ƒrƒXƒ|[ƒgAƒvƒƒoƒCƒ_‚¨‚æ‚уRƒ“ƒVƒ…[ƒ}‚ðŽÀ‘•‚·‚邱‚Æ‚à‚Å‚«‚Ü
+// ‚·‚ªACORBA‚âIDLƒRƒ“ƒpƒCƒ‰‚ɐ¸’Ê‚µ‚Ä‚¢‚é•K—v‚ª‚ ‚è‚Ü‚·‚µAMakefile‚âƒR[
+// ƒh‚Ì—lX‚È•”•ª‚ð‘‚«Š·‚¦‚é•K—v‚ª‚ ‚è‚Ü‚·‚Ì‚Å‚ ‚܂肨Š©‚ß‚Å‚«‚Ü‚¹‚ñB
+
+It is convenient to use RTCBuilder in implementing a service port.
+You can implement service ports, providers and consumers by yourself.
+But a detailed knowledge of CORBA, IDL compiler is required, and
+Makefile and some parts of source code have to be modified. It is not
+recommended.
+
+// RTCBuilder‚̏ڍׂȎg‚¢•û‚́ARTCBuilder‚̃}ƒjƒ…ƒAƒ‹‚ðŽQÆ‚µ‚Ä‚­‚¾‚³‚¢B
+
+See the manual of RTCBuilder for the detailed usage of RTCBuilder.
+
+*** IDL Definition
+
+// ƒT[ƒrƒXƒ|[ƒg‚ð—˜—p‚·‚é‚ɂ́A—˜—p‚·‚éƒCƒ“ƒ^[ƒtƒF[ƒX‚ð—\‚ßIDL‚Å’è‹`‚·
+// ‚é‚©AŠù‘¶‚ÌIDLƒtƒ@ƒCƒ‹‚ð“K“–‚ȃfƒBƒŒƒNƒgƒŠ‚É”z’u‚µ‚Ä‚¨‚­•K—v‚ª‚ ‚è‚Ü‚·B
+
+In order to use service ports, you have to define interfaces in IDL
+files or use pre-defined IDL files, and have to put them into
+appropriate directory.
+
+// IDL‚Ì’è‹`•û–@‚ɂ‚¢‚ẮA‚±‚±‚ł͏ڍׂ͏q‚ׂ܂¹‚ñ‚ªA‚¨‚¨‚æ‚»ˆÈ‰º‚̂悤
+// ‚ȃtƒH[ƒ}ƒbƒg‚Å’è‹`‚·‚邱‚Æ‚ª‚Å‚«ACŒ¾Œê‚âJava‚ÉŠµ‚ꂽ“ÇŽÒ‚Å‚ ‚ê‚΁A”ä
+// Šr“I—eˆÕ‚É’è‹`‚Å‚«‚é‚Å‚µ‚傤B
+
+Detailed IDL definition rules are not described here, but it can be
+defined roughly as follows.  Developers who are familiar with C or
+Java languages would easily understand it.
+
+ // Module can be defined for namespace.
+ // Using a module definition positively is recommended.
+ module <module name>
+ {
+   // struct could be defined as follows
+   struct MyStruct // structure name
+   {
+     short x; // only short and long integer types are available
+     short y;
+     long  a;
+     long  b;
+     double dval; // only float and double floating point types are available
+     float fval;
+     string strval; // string type is available for character string
+   };
+ 
+   // dynamic sequence type should be typedefed previously
+   typedef sequence<double> DvalueList;
+   typedef sequence<MyStruct> MyStructList; // sequence of any struct allowed
+ 
+   // interface definition
+   interface MyInterface // interface name
+   {
+     void op1(); // no return value, not arguments
+ 
+     // NG: the following definition is error, because uppercase and lowercase are not distinguished
+     // short op2(in MuStruct mystruct);
+     short op2(in MyStruct mydata); // direction is specified {in, out, inout}
+ 
+     oneway void op3(); // oneway keyword can be used for only operations with no return
+ 
+     void op4(in short inshort, out short outshort, inout short ioshort);
+ 
+     void op5(MyInterface myif); // MyInterface itself can be used for arguments
+   };
+ 
+   // one or more interfaces can be defined one IDL file
+   interface YourInterface
+   {
+     void op1();
+   };
+ };
+
+
+*** Designing by using RTCBuilder
+
+// ã‚̂悤‚ÉIDL‚Å’è‹`‚µ‚½ƒCƒ“ƒ^[ƒtƒF[ƒX‚ðA‚±‚ê‚©‚çŠJ”­‚·‚éRTƒRƒ“ƒ|[ƒl
+// ƒ“ƒg‚̃T[ƒrƒXƒ|[ƒg‚̃vƒƒoƒCƒ_A‚à‚µ‚­‚̓Rƒ“ƒVƒ…[ƒ}‚Æ‚µ‚Ä—p‚¢‚邽‚ß
+// ‚ɂ́AƒRƒ“ƒ|[ƒlƒ“ƒg‚̃R[ƒhƒWƒFƒlƒŒ[ƒ^‚Å‚ ‚é RTCBuilder ‚ŃT[ƒrƒXƒ|[
+// ƒg‚ðÝŒv‚µA‚»‚̍ۂɂ±‚ÌIDL’è‹`‚ð—^‚¦‚Ä‚â‚é•K—v‚ª‚ ‚è‚Ü‚·B
+
+In order to use interfaces defined as mentioned above for service
+ports' providers and consumers in your new RT-Component, IDL
+definition should be given to RTCBuilder tool which can be used to
+design RT-Components.
+
+// RTCBuilder ‚̐V‹KƒvƒƒWƒFƒNƒg‚ðì¬‚µAƒp[ƒXƒyƒNƒeƒBƒu‚ðŠJ‚«‚Ü‚·BŠeŽí
+// ƒvƒƒtƒ@ƒCƒ‹(ƒRƒ“ƒ|[ƒlƒ“ƒg‚Ì–¼Ì‚âƒJƒeƒSƒŠ–¼)“™A•K—v‚Ȑݒè‚ðs‚Á‚½ŒãA
+// ƒT[ƒrƒXƒ|[ƒgƒ^ƒu‚ðŠJ‚­‚ƁAŽŸ‚̂悤‚ȉæ–Ê‚ªŒ»‚ê‚Ü‚·B
+
+Create a new project of RTCBuilder and open perspective of RTCBuilder.
+After setting various required profiles including component's name and
+category, open service port's tab, you can see the following editor
+view.
+
+#ref(rtcbuilder_serviceport_tab1_ja.png,40%,center)
+CENTER: ''Service port's design tab.''
+
+// ‚Ü‚¸A''Add Port'' ƒ{ƒ^ƒ“‚ð‰Ÿ‚µƒT[ƒrƒXƒ|[ƒg‚ðˆê‚’ljÁ‚µ‚Ü‚·B‚»‚¤‚·‚é
+// ‚ƁAsv_name ‚Æ‚¢‚¤ƒT[ƒrƒXƒ|[ƒg‚ªˆê‚’ljÁ‚³‚êA‰º‚ÌBuildView‚̃Rƒ“ƒ|[
+// ƒlƒ“ƒg‚Ì” ‚ɁA¬‚³‚Ȑ³•ûŒ`‚̃|[ƒg‚ªˆê‚’ljÁ‚³‚ê‚Ü‚·BRTCBuilder‚̃GƒfƒB
+// ƒ^¶‚̃|[ƒgƒŠƒXƒg‚Ìsv_name‚ðƒNƒŠƒbƒN‚·‚é‚ƁA‰E‘¤‚É''RT-Component
+// Service Port Profile''‚ª•\Ž¦‚³‚ê‚é‚̂ŁAƒ|[ƒg–¼‚ð“K“–‚È–¼‘O (‚±‚±‚Å‚Í
+// ''MyServiceProviderPort'') ‚ɕύX‚µ‚Ü‚·B
+
+At first, click ''Add Port'' button and add a service port to the
+RT-Component.  Then a service port named sv_name is added, and a small
+rectangle signifying a port is added on a component's larger rectangle
+in the build view that is usually located below.  Click sv_name in
+port list in the left side of the editor, then ''RT-Component Service
+Port Profile'' will appear on the right side.  Please modify it to an
+appropriate name (here it is set as ''MyServiceProviderPort'').
+
+#ref(rtcbuilder_serviceport_tab2_ja.png,40%,center)
+CENTER: ''Adding a service port''
+
+// ƒGƒfƒBƒ^¶‚̃|[ƒgƒŠƒXƒg‚Ì MyServiceProviderPort ‚ðƒNƒŠƒbƒN‚µA''Add
+// Interface''ƒ{ƒ^ƒ“‚ðƒNƒŠƒbƒN‚·‚é‚ƁAMyServiceProviderPort ‚ɃCƒ“ƒ^[ƒtƒF[
+// ƒX ''if_name'' ‚ªˆê‚’ljÁ‚³‚ê‚Ü‚·‚̂ŁAæ‚Ù‚Ç‚Æ“¯—l‚ɃGƒfƒBƒ^¶
+// ‚Ì''if_name''‚ðƒNƒŠƒbƒN‚µA''RT-Component Service Port Interface
+// Profile''ã‚Å''if_name''‚ð“K“–‚È–¼‘O (‚±‚±‚Å‚ÍMyServiceProvider) ‚ɕύX
+// ‚µ‚Ü‚·B‰º‚ÌBuildeView‚ł́A³•ûŒ`‚̃|[ƒg‚ɃƒŠƒ|ƒbƒv‚ª’ljÁ‚³‚êAƒvƒ
+// ƒoƒCƒ_ (Provided Interface) ‚ªƒ|[ƒg‚É•t‰Á‚³‚ꂽ‚±‚Æ‚ªŽ‹Šo“I‚É•ª‚©‚è‚Ü
+// ‚·B
+
+Click MyServiceProviderPort in the list at the left side of the editor
+and then click ''Add Interface'' button.  You will find an interface
+''if_name'' is added under the MyServiceProviderPort.  As well as
+former step, click ''if_name'' at the left side of the editor, then
+rename ''if_name'' to an appropriate name (here it is set as
+''Provided Interface'') on the ''RT-Component Service Port Interface
+Profile''.
+
+
+#ref(rtcbuilder_serviceport_tab3_ja.png,40%,center)
+CENTER: ''Adding a service interface (provider)''
+
+// ƒGƒfƒBƒ^‰E‘¤‚Ì Interface Profile ‚ł́AƒCƒ“ƒ^[ƒtƒF[ƒX‚̃vƒƒtƒ@ƒCƒ‹‚ð
+// Ý’肵‚Ü‚·B—Ⴆ‚Î''•ûŒü''‚̃hƒƒbƒvƒ_ƒEƒ“ƒŠƒXƒg‚ł́A‘Ώۂ̃Cƒ“ƒ^[
+// ƒtƒF[ƒX‚ªƒvƒƒoƒCƒ_ (Provided) ‚©ƒRƒ“ƒVƒ…[ƒ} (Required) ‚©‚ðŽw’肵‚Ü
+// ‚·B
+
+You can set interface profile in the Interface Profile pane at the
+right side of the editor. For example, you can specify the target
+interface as a provider (provided interface) or a consumer (required
+interface) in the ''Direction'' drop-down list.
+
+
+#ref(rtcbuilder_direction_ddown_ja.png,100%,center)
+CENTER: ''Setting direction of a service interface''
+
+// ‚±‚±‚ł̓vƒƒoƒCƒ_‚ð’ljÁ‚µ‚悤‚Æ‚µ‚Ä‚¢‚é‚̂ŁAProvided ‚Ì‚Ü‚Ü‚É‚µ‚Ü
+// ‚·B‚±‚Ì‚Ù‚©AƒCƒ“ƒXƒ^ƒ“ƒX–¼A•Ï”–¼‚È‚Ç‚àŽw’è‚Å‚«‚Ü‚·‚ªA•K{‚Å‚Í‚ ‚è
+// ‚Ü‚¹‚ñBƒCƒ“ƒXƒ^ƒ“ƒX–¼‚́AÚ‘±Žž‚ɃvƒƒoƒCƒ_‚ƃRƒ“ƒVƒ…[ƒ}‚̃Cƒ“ƒXƒ^ƒ“
+// ƒX–¼‚ª“¯‚¶‚È‚çA‘ΉžŠÖŒW‚ðŽw’肵‚È‚­‚Ä‚àƒ|[ƒg‚̐ڑ±‚ðŽ©“®“I‚ɍs‚¤ê‡
+// ‚É—˜—p‚³‚ê‚Ü‚·B
+
+Since we are trying to add a provider interface now, keep it
+''Provided.''  Additionally a intance name, a variable name can be
+specified, but thease are not mandatory parameters. The instance name
+is used as a matching key when service ports are connected without
+detailed interface pair settings.
+
+#ref(serviceif_autoconnection_ja.png,40%,center)
+CENTER: ''Instance name of service interface, and automatic pairing.''
+
+// ‚½‚¾‚µAƒCƒ“ƒXƒ^ƒ“ƒX–¼‚ªˆÙ‚È‚Á‚Ä‚¢‚Ä‚àAÚ‘±Žž‚É”CˆÓ‚̃Cƒ“ƒ^[ƒtƒF[ƒX
+// “¯Žm‚ðÚ‘±‚Å‚«‚é‚̂ŁA“ü—Í‚Í•K{‚Å‚Í‚ ‚è‚Ü‚¹‚ñB‚Ü‚½A•Ï”–¼‚̓R[ƒh‚ð
+// ¶¬‚µ‚½Û‚ɃvƒƒoƒCƒ_ƒIƒuƒWƒFƒNƒg‚ð‘ã“ü‚·‚é•Ï”–¼‚ðŽw’è‚·‚邽‚߂̍€–Ú
+// ‚Å‚·‚ªA‚±‚ê‚àƒCƒ“ƒ^[ƒtƒF[ƒX–¼‚©‚玩“®“I‚ɐ¶¬‚³‚ê‚é‚̂ŁA“ü—Í‚Í”CˆÓ
+// ‚Å‚·B
+
+However, the instance name is not a must, because even if instance
+names are different between provider and consumer, you can specify
+interface pairs at connection time.  Although the variable name is
+used to specify the name of variable which is substituted by a
+provider object in the generated source code, it is not mandatory
+since these are also generated automatically from interface name.
+
+// ŽŸ‚ÉIDL‚ÌŽw’è‚ƁAƒCƒ“ƒ^[ƒtƒF[ƒXŒ^‚ÌŽw’è‚ðs‚¢‚Ü‚·Bã‚Å’è‹`‚µ‚½‚悤‚È
+// IDL‚ð“K“–‚ȃfƒBƒŒƒNƒgƒŠ‚É”z’u‚µAIDLƒtƒ@ƒCƒ‹Žw’èƒ{ƒbƒNƒX‰¡‚Ì Browse ƒ{
+// ƒ^ƒ“‚ð‰Ÿ‚µA‘ΏۂƂȂéIDL‚ðŽw’肵‚Ü‚·B‚·‚é‚ƁAŽw’肳‚ꂽIDL‚Å’è‹`‚³‚ê
+// ‚½ƒCƒ“ƒ^[ƒtƒF[ƒX‚ªA‚»‚̉º‚̃Cƒ“ƒ^[ƒtƒF[ƒXŒ^‚̃hƒƒbƒvƒ_ƒEƒ“ƒŠƒXƒg
+// ‚ÉŒ»‚ê‚Ü‚·B‚±‚̃hƒƒbƒvƒ_ƒEƒ“ƒŠƒXƒg‚ŁA‚±‚̃|[ƒg‚É•t‰Á‚µ‚½ƒCƒ“ƒ^[
+// ƒtƒF[ƒX–¼‚ð‘I‘ð‚µ‚Ü‚·BIDLƒtƒ@ƒCƒ‹‚É•¶–@ƒGƒ‰[‚È‚Ç‚ª‚ ‚éê‡‚ɂ́Aƒhƒƒb
+// ƒvƒ_ƒEƒ“ƒŠƒXƒg‚ÉŠó–]‚·‚éƒCƒ“ƒ^[ƒtƒF[ƒX‚ªŒ»‚ê‚Ü‚¹‚ñBÄ“xIDLƒtƒ@ƒCƒ‹‚Ì
+// ’è‹`‚ðƒ`ƒFƒbƒN‚µ‚Ä‚­‚¾‚³‚¢B
+
+Next, specify interface type and its IDL (Interface Definition
+Language) file.  Put IDL files to proper location, and click
+''Browse'' button at the side of IDL file name input form, and specify
+the IDL from the dialogue window.  After that, the interfaces defined
+in the IDL file will appear in the interface type dropdown list.
+Select interface to be owned by the port from the dropdown list.  If
+IDL file includes some errors such as syntax error, expected interface
+names might not appear.  In such case, please check the specified IDL
+file again.
+
+
+
+#ref(rtcbuilder_interfacetype_ddwon_ja.png,100%,center)
+CENTER: ''Selecting interface type''
+
+// ‚È‚¨Aãq‚Ì''•ûŒü''ƒhƒƒbƒvƒ_ƒEƒ“ƒŠƒXƒg‚Å ''Required''‚ðŽw’è‚·‚é‚ƁA‚±
+// ‚̃Cƒ“ƒ^[ƒtƒF[ƒX‚̓Rƒ“ƒVƒ…[ƒ}‚É‚È‚è‚Ü‚·BˆÈ‰º‚͕ʂ̃Rƒ“ƒ|[ƒlƒ“ƒg
+// ''MyServiceConsumer'' ‚̃T[ƒrƒXƒ|[ƒg‚ƃCƒ“ƒ^[ƒtƒF[ƒX‚̐ݒè‰æ–Ê‚Ì—á
+// ‚Å‚·B
+
+Moreover, if the ''Required'' is specified in the ''Direction''
+dropdown list, the interface will be a consumer.  The following figure
+shows a service port and interfaces setting page of another
+''MyServiceConsumer'' component.
+
+
+#ref(rtcbuilder_serviceport_tab4_ja.png,40%,center)
+CENTER: ''Adding service interface (consumer)''
+
+// ƒGƒfƒBƒ^‰º‚Ì BuildView ‚É‚¨‚¢‚ă|[ƒg‚Ƀ\ƒPƒbƒg‚ª’ljÁ‚³‚ê‚āAƒRƒ“ƒVƒ…[
+// ƒ} (Required interface) ‚ªƒ|[ƒg‚É•t‰Á‚³‚ꂽ‚±‚Æ‚ªŽ‹Šo“I‚É•ª‚©‚è‚Ü‚·B
+
+Finally you will find visually that consumer (Required interface) is
+added to the port in the BuildView pane under the editor.
+
+// *** ƒvƒƒoƒCƒ_‚ÌŽÀ‘•
+*** Implementing Provider
+
+// ƒvƒƒoƒCƒ_‚Æ‚¢‚¤‚Ì‚Í•¶Žš’Ê‚èAƒT[ƒrƒX‚ðƒvƒƒoƒCƒh(’ñ‹Ÿ)‚·‚邽‚߂̃Cƒ“
+// ƒ^[ƒtƒF[ƒX‚Å‚·B‚µ‚½‚ª‚Á‚āAIDL‚Å’è‹`‚µ‚½ƒCƒ“ƒ^[ƒtƒF[ƒX‚ðŽ‚ÂƒT[
+// ƒrƒX‚Ì’†g‚ðŽÀ‘•‚·‚é•K—v‚ª‚ ‚è‚Ü‚·B
+
+The Provider is literally a interface to provide some service.
+Therefore, the service that is the actual functionality of the
+provider interface has to be implemented.
+
+// ƒvƒƒoƒCƒ_ƒCƒ“ƒ^[ƒtƒF[ƒX‚ðŽ‚ÂƒRƒ“ƒ|[ƒlƒ“ƒg‚ðRTCBuilder‚Ő݌v‚µ‚½ê
+// ‡AƒR[ƒh¶¬‚ðs‚¤‚ƁAƒRƒ“ƒ|[ƒlƒ“ƒg‚̃\[ƒX‚̂ЂȌ`‚Æ‚Æ‚à‚ɁA—Ⴆ‚Î
+// C++‚̏ꍇ‚ɂ́A<ƒT[ƒrƒXƒCƒ“ƒ^[ƒtƒF[ƒX–¼>SVC_impl.cpp ‚Æ <ƒT[ƒrƒXƒC
+// ƒ“ƒ^[ƒtƒF[ƒX–¼>SVC_impl.h ‚Æ‚¢‚¤AƒvƒƒoƒCƒ_‚ÌŽÀ‘•ƒR[ƒh‚̂ЂȌ`‚à¶
+// ¬‚³‚ê‚Ü‚·B
+
+In case of designing a component with service provider interfaces by
+RTCBuilder, for example in C++ language, additional provider's
+implementation source code such as <service interface
+name>SVC_impl.cpp and <service interface name>SVC_impl.h will be
+generated with other component template source code.
+
+#ref(rtcbuilder_svcimpl_cxxsrc_ja.png,100%,center)
+CENTER: ''Service provider implementation files (C++,Python,Java)''
+
+ˆÈ‰º‚ɁAŠeŒ¾Œê‚Ő¶¬‚³‚ê‚éƒvƒƒoƒCƒ_‚ÌŽÀ‘•‚̂ЂȌ`ƒR[ƒh‚̃tƒ@ƒCƒ‹–¼‚ð
+Ž¦‚µ‚Ü‚·B
+
+Provider's implementation template code file names for each language are shown in the following.
+
+|>|CENTER: ''Generated template code files'' |
+| ''C++''    | <interface name>SVC_impl.cpp &br; <interface name>SVC_impl.h |
+| ''Python'' | <interface name>_idl_example.py |
+| ''Java''   | <interface name>SVC_impl.java |
+
+
+#ref(rtcbuilder_svcimpl_pysrc_ja.png,100%,center)
+CENTER: ''Implementation file for service provider (Python)''
+
+#ref(rtcbuilder_svcimpl_javasrc_ja.png,100%,center)
+CENTER: ''Implementation file for service provider (Java)''
+
+// ‚±‚ê‚ç‚ÌŽÀ‘•‚̂ЂȌ`‚ɂ́AIDL‚Å’è‹`‚³‚ꂽƒCƒ“ƒ^[ƒtƒF[ƒX‚É‘Š“–‚·‚éƒNƒ‰
+// ƒX‚ª‚ ‚ç‚©‚¶‚ß’è‹`‚³‚ê‚Ä‚¢‚Ü‚·B
+
+A class associated to the interface defined in IDL is already declared
+in these implementation templates.
+
+// ‚±‚±‚ł́AC++‚Å‚ÌŽÀ‘••û–@‚ð—á‚É‚Æ‚èAIDL‚Å’è‹`‚³‚ꂽƒIƒyƒŒ[ƒVƒ‡ƒ“‚Ì‚¢
+// ‚­‚‚©‚ðŽÀ‘•‚µ‚Ä‚¢‚«‚Ü‚·B
+
+Here, as an example, some operations defined in IDL will be
+implemented in C++ language.
+
+
+// ****echo()ŠÖ”‚ÌŽÀ‘•
+****echo() operation implementation
+
+// ‚Í‚¶‚߂ɁAecho() ƒƒ“ƒoŠÖ”‚ðŒ©‚Ä‚Ý‚Ü‚·B
+
+Let's see echo() member function at first.
+
+ /*
+  * 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 ƒvƒŠƒvƒƒZƒbƒTƒfƒBƒŒƒNƒeƒBƒu‚ª‚ ‚è‚Ü‚·‚ªA‚±‚ê‚Ígcc‚ŃRƒ“ƒpƒC
+// ƒ‹‚µ‚½Û‚É‚±‚̊֐”‚ªŽÀ‘•‚³‚ê‚Ä‚¢‚È‚¢‚±‚Æ‚ðŒx‚·‚邽‚ß‚Ì‚à‚Ì‚Å‚·‚̂ŁA
+// #ifndef‚²‚ƍ폜‚µ‚Ü‚·B
+
+You can find the #warning preprocessor directive.  Since an error
+arises at the compile time if this function is not implemented, delete
+them including #ifndef directive.
+
+ char* MyServiceSVC_impl::echo(const char* msg)
+ {
+   return msg;
+ }
+
+// ‚Ü‚½A‚±‚̊֐”‚́Aecho() ŠÖ”‚̈ø”‚É—^‚¦‚ç‚ꂽ•¶Žš—ñ‚ðA’P‚ɌĂяo‚µ‘¤
+// ‚É•Ô‚·‚¾‚¯‚Ì‹@”\‚ð’ñ‹Ÿ‚·‚é‚Æ‚µ‚Ü‚·B‚µ‚½‚ª‚Á‚āAˆÈ‰º‚̂悤‚ÉŽÀ‘•‚·‚ê‚Î
+// ‚æ‚¢‚悤‚ÉŽv‚¦‚Ü‚·B
+
+Now we assume that this function echo() just return given string in
+argument to the caller. Therefore, the following implementation seems
+apparently normal.
+
+ char* MyServiceSVC_impl::echo(const char* msg)
+ {
+   return msg;
+ }
+
+// ‚µ‚©‚µA‚±‚ê‚̓Rƒ“ƒpƒCƒ‹Žž‚ɃGƒ‰[‚É‚È‚è‚Ü‚·Bconst char* ‚ð char* ‚É“n
+// ‚µ‚Ä‚¢‚邽‚ß‚Å‚·B‚Ü‚½ACORBA ‚̃IƒuƒWƒFƒNƒg‚ÌŽÀ‘••û–@‚Æ‚µ‚Ä‚àŠÔˆá‚Á‚Ä
+// ‚¢‚Ü‚·BCORBA‚ł́Areturn ‚Å•Ô‚³‚ê‚éƒIƒuƒWƒFƒNƒg‚́AORB (Object
+// Request Broker, ƒŠƒ‚[ƒgƒIƒuƒWƒFƒNƒg‚̌Ăяo‚µ•”•ª‚ðŽi‚é•”•ªACORBA‚̃R
+// ƒA) ‚É‚æ‚Á‚ĉð‘Ì‚³‚ê‚é‚Æ‚¢‚¤ƒ‹[ƒ‹‚ª‚ ‚邽‚ß‚Å‚·B(returnŽž‚ɂ̓IƒuƒWƒF
+// ƒNƒg‚̏Š—LŒ ‚ð•úŠü‚·‚éA‚Æ‚àŒ¾‚¢‚Ü‚·B)
+
+However, this will be error when it is compiled. Because the const
+char* variable is returned to char* type.  Addingly it is also
+incorrect in the CORBA implementation rules.  Because CORBA has a rule
+that the ownership of the returned object has to be released and ORB
+destructs after that.
+
+// ‚µ‚½‚ª‚Á‚āAreturn ‚ɂ́A•Ê“r—̈æ‚ðŠm•Û‚µAmsg ‚Ì“à—e‚ðƒRƒs[‚µ‚½•¶Žš—ñ
+// ‚ð•Ô‚·•K—v‚ª‚ ‚è‚Ü‚·B‚±‚ê‚ɏ]‚¦‚΁AˆÈ‰º‚̂悤‚ÉŽÀ‘•‚·‚ê‚΂悢‚悤‚ÉŽv
+// ‚¤‚©‚à‚µ‚ê‚Ü‚¹‚ñB
+
+Therefore, in order to return objects, you have to allocate memory and
+copy the contents of msg and return it. According to this rule, the
+following implementation seems correct.
+
+ char* MyServiceSVC_impl::echo(const char* msg)
+ {
+   char* msgcopy;
+   msgcopy = malloc(strlen(msg));
+   strncpy(msgcopy, msg, strlen(msg));
+   return msgcopy;
+ }
+
+// ‚±‚±‚ł́Amalloc‚ŗ̈æ‚ðŠm•Û‚µ‚Ä‚¢‚Ü‚·‚ªAORB‚Ífree‚ŗ̈æ‚ð‰ð‘Ì‚·‚é‚Ì‚©A
+// delete‚ʼnð‘Ì‚·‚é‚Ì‚©‚Í‚í‚©‚è‚Ü‚¹‚ñBŽÀ‚́ACORBA‚ł̓IƒuƒWƒFƒNƒg(\‘¢‘Ì
+// ‚â”z—ñA‚Ü‚½‚»‚Ì•¡‡Œ^“™‚àŠÜ‚Þ)‚╶Žš—ñ‚ðˆµ‚¤‚½‚ß‚Ì•û–@‚ª•Ê“r’è‚ß‚ç‚ê‚Ä
+// ‚¢‚āA‚»‚ê‚ɏ]‚Á‚Ċ֐”‚̈ø”‚ðŽó‚¯Žæ‚Á‚½‚èA•Ô‚µ‚½‚è‚·‚é•K—v‚ª‚ ‚é‚Ì‚Å
+// ‚·B
+
+Here, although memory is allocated by using malloc, it is uncertain
+whether the area would be released by free() or delete().  Actually
+CORBA provides methods to allocate and/or destruct objects (including
+structure, array and complex types), and developers have to receive
+argument and return value according to the rules.
+
+// CORBA‚Å’è‚ß‚ç‚ꂽ•û–@‚ɏ]‚¤‚ƁAecho()ŠÖ”‚͈ȉº‚̂悤‚ÉŽÀ‘•‚·‚é•K—v
+// ‚ª‚ ‚è‚Ü‚·B
+
+According to the CORBA rule, the echo() function should be implemented
+as follows.
+
+ char* MyServiceSVC_impl::echo(const char* msg)
+ {
+   CORBA::String_var msgcopy = CORBA::string_dup(msg);
+   return msgcopy._retn();
+ }
+
+// ŠÖ”“à‚Ì1s–ڂł́ACORBA‚Ì•¶Žš—ñƒNƒ‰ƒXCORBA::String ‚̃Xƒ}[ƒgƒ|ƒCƒ“ƒ^
+// ‚Å‚ ‚é CORBA::String_var Œ^‚ðéŒ¾‚µ‚Ä‚¢‚Ü‚·BString_var Œ^‚Í‚¢‚í‚ä‚鏊
+// —LŒ ‚ðŠÇ—‚·‚邽‚߂̃Xƒ}[ƒgƒ|ƒCƒ“ƒ^‚ÅSTL‚Ìauto_ptr‚ÉŽ—‚Ä‚¢‚Ü‚·B
+
+In the first line of the function, CORBA::String_var which is a kind
+of smart pointer for CORBA's string class CORBA::String is declared.
+String_var, which is similar to auto_ptr of STL, is a smart pointer to
+manage ownership of objects.
+
+ CORBA::String_var msgcopy = CORBA::string_dup(msg);
+
+// ‚±‚Ì String_var Œ^‚̕ϐ” msgcopy ‚Ɉø”‚Ì msg ‚ÉŠi”[‚³‚ê‚Ä‚¢‚镶Žš—ñ‚ð
+// ƒRƒs[‚µ‚Ä‚¢‚é‚Ì‚ª CORBA::string_dup() ŠÖ”‚Å‚·B‚±‚̊֐”‚ł͈ø”‚É—^‚¦
+// ‚ç‚ꂽ•¶Žš—ñ‚ðŠi”[‚·‚é‚̂ɏ\•ª‚ȃƒ‚ƒŠ—̈æ‚ðŠm•Û‚µA‚»‚̗̈æ‚Ɉø”‚Ì•¶
+// Žš—ñ‚ðƒRƒs[‚µ‚Ä‚¢‚Ü‚·B
+
+This CORBA::string_dup() function copies the character string stored
+in msg variable to the variable msgcopy which is a String_var type
+variable.  In this function, sufficient memory space for given
+characters are allocated and these are copied to the area.
+
+// ŽŸ‚̍s‚ł́Areturn ‚ŌĂяo‚µŒ³‚É msgcopy “à‚Ì•¶Žš—ñ‚ð•Ô‚µ‚‚AƒIƒuƒWƒF
+// ƒNƒg‚̏Š—LŒ ‚ð•úŠüAreturn ‘¤‚ɏŠ—LŒ ‚ðˆÚ÷‚µ‚Ä‚¢‚Ü‚·B‰º}‚ÉŽ¦‚·‚悤‚É
+// ORB ‚ł́Areturn ‚Å•Ô‚³‚ꂽ•¶Žš—ñ‚ðAƒlƒbƒgƒ[ƒNã‚̌Ăяo‚µŒ³‚É‘—M‚µ
+// ‚Ä‚©‚çA•¶Žš—ñƒIƒuƒWƒFƒNƒg‚ð‰ð•ú‚µ‚Ü‚·B
+
+At the next line, character string in msgcopy is returned to caller
+and its ownership is released and is transferred to caller.  As shown
+in the following figure, ORB destructs string object after it is
+transferred to the caller on the network.
+
+
+#ref(serviceport_orb_and_provider_ja.png,50%,center)
+CENTER: ''Relation among ORB, operation call and memory management.''
+
+// ‚±‚̃‹[ƒ‹‚ð‚æ‚­—‰ð‚·‚é‚ƁAmsgcopy ƒIƒuƒWƒFƒNƒg‚ª echo() ŠÖ”“à‚ÅŽg—p
+// ‚³‚ê‚Ä‚¢‚È‚¢‚±‚Æ‚©‚çAecho() ŠÖ”‚ÌŽÀ‘•‚͍ŏI“I‚ɂ͈ȉº‚̂悤‚É‚à‘‚­‚±
+// ‚Æ‚à‚Å‚«‚Ü‚·B
+
+According to this rule, since msgcopy object is used only for return
+value in the function, the implementation of the echo() function can
+be written as follows.
+
+ char* MyServiceSVC_impl::echo(const char* msg)
+ {
+   return CORBA::string_dup(msg);
+ }
+
+// CORBA::string_dup() ŠÖ”‚Å•¶Žš—ñ—̈æ‚ÌŠm•Û‚Æ“à—e‚̃Rƒs[‚ðs‚Á‚½‚¤‚¦‚ŁA
+// ‚»‚̏Š—LŒ ‚𒼂ɌĂяo‚µŒ³‚É—^‚¦‚Ä‚¢‚邱‚Æ‚É‚È‚è‚Ü‚·B
+
+This means that CORBA::string_dup() function allocates memory for
+string characters, copies it to there and transfers its ownership to
+caller.
+
+// ‚±‚̂悤‚ɁAƒT[ƒrƒXƒvƒƒoƒCƒ_‚Í CORBA ‚̃IƒuƒWƒFƒNƒg‚Å‚·‚̂ŁA‚»‚ÌŽÀ‘•
+// •û–@‚͒ʏí‚Ì C++ ‚ÌŽÀ‘•‚Ƃ͏­‚µˆá‚Á‚½‚â‚è•û‚ōs‚¤•K—v‚ª‚ ‚è‚Ü‚·B“Á‚ɁAŠÖ
+// ”‚̈ø”‚¨‚æ‚Ñ•Ô‚è’l‚̎󂯓n‚µ‹K‘¥‚́A­‚µ•¡ŽG‚Ȃ悤‚ÉŒ©‚¦‚Ü‚·B‚½‚¾‚µA
+// ã‹L‚̂悤‚ɁAƒIƒuƒWƒFƒNƒg‚̏Š—LŒ ‚Æ‚¢‚¤l‚¦•û‚ð”O“ª‚É‚¨‚¢‚čl‚¦‚é‚ƁA
+// ˆø”‚ð‚ǂ̂悤‚Ɏ󂯎æ‚é‚ׂ«‚È‚Ì‚©A‚ ‚é‚¢‚Í•Ô‚è’l‚ð‚ǂ̂悤‚É•Ô‚·‚ׂ«
+// ‚È‚Ì‚©‚ªŽ©‚¸‚Æ–¾‚ç‚©‚É‚È‚è‚Ü‚·BÚ×‚ɂ‚¢‚ẮAAppendix‚⑼‚ÌCORBA‚ÌŽQ
+// l‘“™‚ðŽQl‚É‚µ‚Ä‚­‚¾‚³‚¢B
+
+In this manner, since a service provider is a CORBA object, its
+implementation have to be performed as a little different way from the
+normal C++ style programming.  Especially the rule for argument and
+return value for operations seems difficult to understand.  However,
+as mentioned above, if you are keeping the ownership handling of
+objects in your mind, you can easily understand how to receive
+arguments and how to return object.  For details, please refer to the
+reference book of Appendix or other CORBA etc.
+
+// ****set_value(), get_value() ‚Æ get_value_history()
+****set_value(), get_value() and get_value_history()
+
+// ŽŸ‚́Aset_value() ŠÖ”, get_value() ŠÖ”‚¨‚æ‚Ñ get_value_list() ŠÖ”‚ð
+// “¯Žž‚ÉŽÀ‘•‚µ‚Ä‚¢‚«‚Ü‚·B‚±‚ê‚ç‚̊֐”‚́Aset_value() ‚Őݒ肳‚ꂽfloatŒ^
+// ‚Ì’l‚ð•Û‘¶‚µ‚Ä‚¨‚«Aget_value()‚Å‚»‚Ì’l‚ð•Ô‚·‚Æ‚¢‚¤’Pƒ‚È‚à‚Ì‚Å‚·B‚Ü‚½A
+// get_value_history() ‚ł́A¡‚܂łɃZƒbƒg‚³‚ꂽ’l‚Ì—š—ð‚ð•Û‘¶‚µ‚Ä‚¨‚«A
+// —š—ð‚ðƒŠƒXƒg‚Æ‚µ‚Ä•Ô‚·‚Æ‚¢‚¤‚à‚Ì‚Å‚·B
+
+Next, set_value(), get_value() and get_value_list() functions will be
+implemented simultaneously.  These functions work as follows.
+set_value() sets a float type value and stores a variable, get_value()
+returns the stored value, and get_value_history() returns history list
+which is recorded past set values.
+
+// ]‚Ü‚¸A’l‚ð•Û‘¶‚µ‚Ä‚¨‚­•Ï”‚ð—pˆÓ‚µ‚Ü‚·BŒ»Ý‚Ì’l‚ÍMyServiceSVC_implƒNƒ‰
+// ]ƒX‚ÉCORBA::FloatŒ^‚Ìprivateƒƒ“ƒo[‚Æ‚µ‚Ä—pˆÓ‚µ‚Ü‚·Bˆê•ûA
+// ]get_value_history() ‚ł́A–ß‚è’l‚ÉSimpleService::ValueList ‚Æ‚¢‚¤CORBA
+// ]‚̃V[ƒPƒ“ƒXŒ^‚ªŽg‚í‚ê‚Ä‚¢‚é‚̂ŁA‚±‚ê‚ðƒƒ“ƒo[•Ï”‚Æ‚µ‚ÄŽ‚‚悤‚É‚µ
+// ]‚Ü‚·B‚±‚ê‚ç‚̕ϐ”éŒ¾‚ð MyServiceSVC_impl.h ‚Ì MyServiceSVC_impl ƒNƒ‰
+// ]ƒX’è‹`‚̍Ōã‚Ì•û‚Ɉȉº‚̂悤‚ɒljÁ‚µ‚Ü‚·B
+
+At first, a variable to store current value is needed.  The current
+value is declared as a CORBA::Float type private member of
+MyServiceSVC_impl class.  On the other hand, in the
+get_value_history() function, since a CORBA sequence type
+SimpleService::ValueList is used for return value, same type variable
+should be owned as a member variable.  These variable declarations are
+added to the end of MyServiceSVC_impl class definition in
+MyServiceSVC_impl.h.
+
+ class MyServiceSVC_impl
+   : public virtual POA_SimpleService::MyService,
+    public virtual PortableServer::RefCountServantBase
+ {
+   : (*snip*)
+ private:
+   CORBA::Float m_value; // add this line
+   SimpleService::ValueList m_valueList; // add this line
+   };
+
+// •Ï”‚̏‰Šú‰»‚à–Y‚ꂸ‚ɍs‚¢‚Ü‚·BMyServiceSVC_impl.cpp ‚̃Rƒ“ƒXƒgƒ‰ƒNƒ^
+// ‚ŁAm_value ‚Í 0.0‚ɁAm_valueList ‚Í’·‚³0‚ɏ‰Šú‰»‚µ‚Ä‚¨‚«‚Ü‚·B
+
+Remember to initialize variable. In the constructor in
+MyServiceSVC_impl.cpp, m_value is set to 0.0 and the length of
+m_valueList is set to 0.
+
+ MyServiceSVC_impl::MyServiceSVC_impl()
+ : m_value(0.0), m_valueList(0)
+ {
+   // Please add extra constructor code here.
+ }
+
+// ŽŸ‚ɁAset_value() ŠÖ”‚ðŽÀ‘•‚µ‚Ü‚·Bˆø”‚É—^‚¦‚ç‚ꂽ”’l‚ðƒƒ“ƒo•Ï”
+// m_value ‚É‘ã“ü‚·‚é‚Æ‚Æ‚à‚ɁAm_valueList‚É‚à’ljÁ‚µ‚Ü‚·BCORBA‚̃V[ƒPƒ“
+// ƒXŒ^‚́A“®“I”z—ñŒ^‚ŁA[]ƒIƒyƒŒ[ƒ^‚Æ‚Æ‚à‚ɁAlength(),
+// length(CORBA::ULong) ‚̊֐”‚ð—˜—p‚·‚邱‚Æ‚ª‚Å‚«‚Ü‚·Blength() ŠÖ”‚́AŒ»
+// Ý‚Ì”z—ñ‚Ì’·‚³‚ð•Ô‚µAlength(CORBA::ULong) ŠÖ”‚ÍŒ»Ý‚Ì”z—ñ‚Ì’·‚³‚ðÝ’è
+// ‚µ‚Ü‚·BŽÀ‘•‚͈ȉº‚̂悤‚É‚È‚è‚Ü‚·B
+
+Next, set_value() function is implemented. Set a value from the
+argument to a member variable m_value, and add it also to m_valueList.
+CORBA's sequence type is a kind of dynamic array type, and [] (array)
+operator, length() and length(CORBA::ULong) operators are
+available. length() returns current length of the array, and
+lenght(CORBA::ULong) set length of the array.  The function can be
+implemented as follows.
+
+ void MyServiceSVC_impl::set_value(CORBA::Float value)
+   throw (CORBA::SystemException)
+ {
+   m_value = value; // Œ»Ý’l
+ 
+   CORBA::ULong len(m_valueList.length()); // Getting length of the array
+   m_valueList.length(len + 1); // Increment length of the array
+   m_valueList[len] = value; // Adding a value to the end of the array
+ 
+   return;
+ }
+
+// echo() ŠÖ”‚Ƃ͈قȂèACORBA::Long Œ^‚ÍC++‚Ìlong int‚Æ“™‰¿‚ŁAƒIƒuƒWƒF
+// ƒNƒg‚̏Š—LŒ A—̈æŠm•Û‚â”pŠü“™‚͍l‚¦‚é•K—v‚Í‚ ‚è‚Ü‚¹‚ñB‚µ‚½‚ª‚Á‚āAã
+// ‚̂悤‚É’Pƒ‚È‘ã“ü‚ō\‚¢‚Ü‚¹‚ñB‚Ü‚½A”z—ñŒ^‚́A2Ží—Þ‚Ì length() ŠÖ”‚Æ
+// []ƒIƒyƒŒ[ƒ^‚ð—˜—p‚µ‚āA”z—ñ‚Ì’·‚³‚ð1‚‘‚₵‚čŌã”ö‚Ɉø”‚Ì’l‚ð‘ã“ü‚µ
+// ‚Ä‚¢‚Ü‚·B‚È‚¨AOpenRTM-aist‚ł́ACORBA‚̃V[ƒPƒ“ƒXŒ^‚ðSTL‚Ìvector‚É‹ß
+// ‚¢Œ`‚Å—˜—p‚·‚邽‚߂̊֐”ƒeƒ“ƒvƒŒ[ƒg‚ð’ñ‹Ÿ‚µ‚Ä‚¨‚èA‚»‚ê‚ðŽg‚¤‚ƁA
+
+Differing from the argument of the echo() function, since CORBA::Long
+type is equivalent of long int type, you do not need to consider
+ownership, allocation and destruction of objects.  Therefore, simple
+assignment above is allowed.  By using two types of length() function
+and [] array operator of the sequence type variable, length of the
+variable is incremented and a value is added to the tail of the array.
+OpenRTM-aist provides some function templates which enables CORBA
+sequence type to be used like STL vector container, and the above code
+can be implemented as follows.
+
+ void MyServiceSVC_impl::set_value(CORBA::Float value)
+   throw (CORBA::SystemException)
+ {
+   m_value = value; // Current value
+   CORBA_SeqUitl::push_back(m_valueList, value);
+ 
+   return;
+ }
+
+// ‚̂悤‚ɏ‘‚­‚±‚Æ‚ª‚Å‚«‚Ü‚·BCORBA_SeqUtil.h ‚ł́A for_each(), find(),
+// push_back(), insert(), front(), back(), erase(), clear() ‚Æ‚¢‚Á‚½ŠÖ”‚ª
+// ’è‹`‚³‚ê‚Ä‚¢‚Ü‚·B
+
+In the CORBA_SeqUtil.h, for_each(), find(), push_back(), insert(), front(), back(), erase() and clear() functions are defined.
+
+// get_value() ‚͈ȉº‚̂悤‚É‚È‚è‚Ü‚·B
+
+get_value() can be implemented as follows.
+
+ CORBA::Float MyServiceSVC_impl::get_value()
+   throw (CORBA::SystemException)
+ {
+   return m_value;
+ }
+
+// •Û‘¶‚³‚ꂽ’l‚ð return ‚ŌĂяo‚µŒ³‚É•Ô‚·‚¾‚¯‚Å‚·B‚±‚±‚Å‚àAæ‚Ù‚Ç‚Ì
+// echo() ‚Ì—á‚Ƃ͈قȂèACORBA::Float ‚ªƒvƒŠƒ~ƒeƒBƒuŒ^‚Ȃ̂ŏŠ—LŒ “™‚ðl
+// —¶‚·‚é•K—v‚Í‚ ‚è‚Ü‚¹‚ñB
+
+This function only returns the stored value.  Differing from echo()
+function, since CORBA::Float is primitive type, you do not need to
+consider ownership, and so on.
+
+// ÅŒã‚ɁAget_value_history() ‚ÌŽÀ‘•‚ðŒ©‚Ä‚¢‚«‚Ü‚·B’l‚Ì—š—ð‚ªŠi”[‚³‚ꂽ
+// m_valueList‚ð•Ô‚¹‚΂¢‚¢‚¾‚¯‚̂悤‚ÉŽv‚¦‚Ü‚·‚ªAæ‚قǂ̏q‚ׂ½Š—LŒ ‚Æ—Ì
+// ˆæ‚̉ð•ú‚Ì–â‘肪‚ ‚邽‚߁AˆÈ‰º‚̂悤‚ÉŽÀ‘•‚·‚é•K—v‚ª‚ ‚è‚Ü‚·B
+
+Finally, let's see an implementation of the get_value_history()
+function.  Although it seems simply returning m_valueList is enough,
+ownership, because of the problems about allocation and destruction,
+the implementation should be as follows.
+
+ SimpleService::ValueList* MyServiceSVC_impl::get_value_history()
+   throw (CORBA::SystemException)
+ {
+   SimpleService::ValueList_var vl;
+   vl = new SimpleService::ValueList(m_valueList);
+   return vl._retn();
+ }
+
+// ŠÖ”“à1s–ڂł́AƒV[ƒPƒ“ƒXŒ^ƒIƒuƒWƒFƒNƒg‚Ì‚½‚߂̃Xƒ}[ƒgƒ|ƒCƒ“ƒ^‚Å‚ ‚éA
+// SimpleService::valueList_var Œ^‚̕ϐ”‚ðéŒ¾‚µ‚Ä‚¢‚Ü‚·B‚³‚ç‚ÉŽŸ‚̍s‚ŁA
+// ‚±‚̃Xƒ}[ƒgƒ|ƒCƒ“ƒ^‚ɑ΂µ‚āAƒRƒs[ƒRƒ“ƒXƒgƒ‰ƒNƒ^‚ðŒÄ‚яo‚µ‚Ä‚»‚̃|ƒC
+// ƒ“ƒ^‚ð‘ã“ü‚µ‚Ä‚¢‚Ü‚·B‚±‚ê‚É‚æ‚èA—̈æ‚ÌŠm•Û‚ƁA’l‚̃Rƒs[‚ª“¯Žž‚ɍs‚í
+// ‚ê‚Ü‚·BÅŒã‚ɁAvl._retn() ‚ŁAvl ‚ª•ÛŽ‚µ‚Ä‚¢‚éƒV[ƒPƒ“ƒXŒ^‚̃IƒuƒWƒF
+// ƒNƒg‚̏Š—LŒ ‚ð•úŠü‚µ‚āAreturn‘¤‚ɃIƒuƒWƒFƒNƒg‚ð“n‚µ‚Ä‚¢‚Ü‚·B
+
+At the first line of the function, SimpleService::ValeList_var type
+which is a smart pointer type of sequence object is declared.  At the
+next line, calling the copy-constructor, its pointer is assigned to
+the declared smart pointer.  It performs allocation of memory and copy
+of the value simultaneously.  Finally, vl._retn() releases the
+ownership of the sequence type object owned by vl variable, and object
+is passed as return variable.
+
+// ‚»‚µ‚āAvl ‚͊֐”“à‚ÅŽg—p‚³‚ê‚Ä‚¢‚È‚¢‚̂ŁAˆÈ‰º‚̂悤‚ɏ‘‚­‚±‚Æ‚à‚Å‚«‚Ü‚·B
+
+And, since the variable vl is not used in the function, it can be
+coded as follows.
+
+ SimpleService::ValueList* MyServiceSVC_impl::get_value_history()
+   throw (CORBA::SystemException)
+ {
+   return new SimpleService::ValueList(m_valueList);
+ }
+
+
+// ˆÈãAƒvƒƒoƒCƒ_‚ÌŽÀ‘•‚ɂ‚¢‚Ä‚Ý‚Ä‚«‚Ü‚µ‚½‚ªAƒvƒƒoƒCƒ_‚ª‚¢‚í‚ä‚é
+// CORBAƒIƒuƒWƒFƒNƒg‚Å‚ ‚é‚̂ŁAŽg—p‚·‚éŒ^A•Ï”‚̎󂯓n‚µ‚ÌŽd•û‚ȂǁA
+// CORBA‚̃‹[ƒ‹‚ɏ]‚Á‚ÄŽÀ‘•‚µ‚È‚¯‚ê‚΂Ȃè‚Ü‚¹‚ñB‚Í‚¶‚߂͔ς킵‚­Š´‚¶‚é‚©
+// ‚à‚µ‚ê‚Ü‚¹‚ñ‚ªAƒvƒŠƒ~ƒeƒBƒuŒ^‚ɂ‚¢‚Ă͏]—ˆ’Ê‚è‚ÌŽÀ‘•A•¡ŽG‚ȃIƒuƒWƒF
+// ƒNƒg‚ɂ‚¢‚Ă̓ƒ‚ƒŠ‚ÌŠm•Û‚Ɖð•ú‚ª‚Ç‚±‚ōs‚í‚ê‚é‚©AŠ—LŒ ‚Í‚Ç‚¿‚ç‚É‚ 
+// ‚é‚©‚ð—‰ð‚·‚é‚ƁA‚ǂ̂悤‚ÉŽÀ‘•‚·‚é‚ׂ«‚È‚Ì‚©—‰ð‚Å‚«‚é‚ÆŽv‚¢‚Ü‚·B
+
+What you just read is the outline of implementation of service ports.
+Since a provider is a kind of CORBA object, they should be implemented
+according to the CORBA way such as types to be used, the way of
+argument passing.  Although you might feel it a little troublesome at
+first, you can use primitive types as conventionally, and you can
+easily understand how to use other complex types if you understand
+ownership of variables and memory allocation and destruction.
+
+***Using Consumers
+
+// ƒRƒ“ƒVƒ…[ƒ}‚ł́Aã‚ÅŽÀ‘•‚µ‚½ƒT[ƒrƒXƒvƒƒoƒCƒ_‚ðŒÄ‚яo‚µA‚»‚Ì‹@”\‚ð
+// —˜—p‚·‚邱‚Æ‚É‚È‚è‚Ü‚·BƒRƒ“ƒVƒ…[ƒ}‚ðŽ‚ÂƒRƒ“ƒ|[ƒlƒ“ƒg‚̂ЂȌ`ƒR[ƒh
+// ‚ðRTCBuilder‚Ő¶¬‚µ‚½ê‡‚ɂ́AƒvƒƒoƒCƒ_‚̏ꍇ‚Ƃ͈قȂè“Á•Ê‚ȃtƒ@ƒCƒ‹‚͐¶
+// ¬‚³‚ê‚Ü‚¹‚ñB
+
+Consumers call service providers which are implemented as presented
+above and use their functionality.  When RTCBuilder generates template
+source code of component which has consumers, other special files are
+not created, unlike component which has providers.
+
+// ‚»‚Ì‘ã‚í‚èAƒRƒ“ƒ|[ƒlƒ“ƒg‚̃wƒbƒ_‚Ɉȉº‚̂悤‚ȃvƒƒoƒCƒ_‚̃vƒŒ[ƒXƒz
+// ƒ‹ƒ_‚Å‚ ‚éƒRƒ“ƒVƒ…[ƒ}ƒIƒuƒWƒFƒNƒg‚ªéŒ¾‚³‚ê‚Ü‚·B
+
+In stead of generating files, the following consumer object as a place holder will be declared in the header of component source code.
+
+
+      : (*snip*)
+   // Consumer declaration
+   // <rtc-template block="consumer_declare">
+   /*!
+    */
+   RTC::CorbaConsumer<SimpleService::MyService> m_MyServiceConsumer;
+ 
+   // </rtc-template>
+ 
+  private:
+      : (*snip*)
+
+// ‚±‚ê‚́ARTC::CorbaConsumer ƒNƒ‰ƒXƒeƒ“ƒvƒŒ[ƒg‚ÉŒ^ˆø”
+// SimpleService::MyService ‚ð—^‚¦‚āAMyService Œ^‚̃Rƒ“ƒVƒ…[ƒ}‚ðéŒ¾‚µ‚Ä
+// ‚¢‚邱‚Æ‚É‚È‚è‚Ü‚·B‚Ü‚½AŽÀ‘•ƒtƒ@ƒCƒ‹‚Ì•û‚ł́AonInitialize() ŠÖ”‚É‚¨
+// ‚¢‚āAƒRƒ“ƒVƒ…[ƒ}‚̃|[ƒg‚Ö‚Ì“o˜^‚ƁAƒ|[ƒg‚̃Rƒ“ƒ|[ƒlƒ“ƒg‚Ö‚Ì“o˜^‚ª
+// s‚í‚ê‚Ä‚¢‚邱‚Æ‚ªŠm”F‚Å‚«‚Ü‚·B
+
+This means that type argument SimpleService::MyService is given to the
+class template of RTC::CorbaConsumer, and MyService type consumer is
+declared.  You can find that they are registered to a port in the
+onInitialize() function and the port is also registered to the
+component in the implementation file.
+
+ RTC::ReturnCode_t MyServiceConsumer::onInitialize()
+ {
+   : (*snip*)   
+  // 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;
+ }
+ 
+
+// ƒwƒbƒ_‚Ő錾‚³‚ê‚Ä‚¢‚½ m_MyServiceConsumer •Ï”‚ªAregisterConsumer()
+// ƒƒ“ƒoŠÖ”‚É‚æ‚Á‚ă|[ƒg‚É“o˜^‚³‚ê‚Ä‚¢‚邱‚Æ‚ª•ª‚©‚è‚Ü‚·B‘æ1ˆø”‚ł́A
+// ‚±‚̃Rƒ“ƒVƒ…[ƒ}‚́uƒCƒ“ƒXƒ^ƒ“ƒX•Ï”v‚ªA‘æ2ˆø”‚ł̓Rƒ“ƒVƒ…[ƒ}‚́uƒC
+// ƒ“ƒ^[ƒtƒF[ƒXŒ^v‚ªA‚»‚µ‚Ä‘æ3ˆø”‚ł̓Rƒ“ƒVƒ…[ƒ}‚̃Cƒ“ƒXƒ^ƒ“ƒX‚Å‚ ‚é
+// m_MyServiceConsumer •Ï”‚ª‚»‚ꂼ‚ê—^‚¦‚ç‚ê‚Ä‚¢‚Ü‚·B‚±‚ê‚É‚æ‚Á‚āAƒRƒ“
+// ƒVƒ…[ƒ}‚ªƒCƒ“ƒXƒ^ƒ“ƒX–¼AŒ^–¼‚Æ‚à‚Ƀ|[ƒg‚ÉŠÖ˜A•t‚¯‚ç‚ê‚Ä‚¢‚邱‚Æ‚É‚È
+// ‚è‚Ü‚·B
+
+You can see that a variable m_MyServiceConsumer which is declared in
+the header is registered to a port by the registerConsumer() member
+function.  An instance variable of the consumer as the first argument,
+an interface type of the consumer as the second argument, and
+m_MyServiceConsumer variable of a instance of the consumer as the
+third argument are given to the function respectively.  According to
+this function call, the service consumer is associated with a port
+with instance name and type name.
+
+// ƒRƒ“ƒVƒ…[ƒ} m_MyServiceConsumer ‚͏ã‚Å‚àq‚ׂ½‚悤‚ɁAƒvƒƒoƒCƒ_‚̃vƒŒ[
+// ƒXƒzƒ‹ƒ_‚É‚È‚Á‚Ä‚¢‚Ü‚·BC++‚ł́AƒIƒuƒWƒFƒNƒg‚ւ̃|ƒCƒ“ƒ^‚̂悤‚Ɉµ‚¤‚±
+// ‚Æ‚ª‚Å‚«‚Ü‚·B
+
+As above mentioned, the consumer m_MyServiceConsumer is a place holder
+of a provider object. In C++ language it can be handled as a pointer.
+
+MyService ƒCƒ“ƒ^[ƒtƒF[ƒX‚ł́Astring Œ^ (CORBA‚ÌstringŒ^) ˆø”‚ðˆê‚Â
+Žæ‚é echo() ƒIƒyƒŒ[ƒVƒ‡ƒ“‚ª’è‹`‚³‚ê‚Ä‚¢‚Ü‚µ‚½B‚µ‚½‚ª‚Á‚āA—Ⴆ‚Έȉº
+‚̂悤‚É echo() ŠÖ”‚ðŒÄ‚яo‚·‚±‚Æ‚ª‚Å‚«‚Ü‚·B
+
+ m_MyServiceConsumer->echo("Hello World");
+
+// C++‚ł͏ã‚̂悤‚Ƀ|ƒCƒ“ƒ^AJava‚âPython‚Å‚ÍŽQÆ‚̂悤‚ɁAƒIƒyƒŒ[ƒVƒ‡ƒ“
+// ‚ðŒÄ‚яo‚·‚±‚Æ‚ª‚Å‚«‚é‚Ì‚Å‚·B
+
+Operations can be called by it like a pointer in C++ language, and a
+reference in Java and Python languages.
+
+// ‚³‚āA‚±‚±‚ÅŠ¨‚Ì—Ç‚¢•û‚́Aƒ|ƒCƒ“ƒ^‚Ü‚½‚ÍŽQÆ‚ÌŽw‚·æ‚͈ê‘Ì‚Ç‚¤‚È‚Á‚Ä‚¢
+// ‚é‚ñ‚¾‚Æ‚¨Žv‚¢‚Å‚µ‚傤BC++“™‚Å‚àA—Ⴆ‚Έȉº‚̂悤‚ȃR[ƒh‚Í
+// segmentation fault ‚Å‘¦À‚É—Ž‚¿‚Ü‚·B
+
+And now, readers who have enough experience in C++ language might be
+wondering what is the entity of the pointer and the reference.  In C++
+language, the following code is aborted immediately by 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ƒ|ƒCƒ“ƒ^‚Å‚·‚̂ŁA‰½‚àƒIƒuƒWƒFƒNƒg‚ðŽw‚µ‚Ä‚¢‚Ü‚¹‚ñB‚±‚ê‚Æ“¯—l
+// ‚ɁAã‚Ì m_MyServiceConsumer ‚àAƒRƒ“ƒ|[ƒlƒ“ƒg‚Ì‹N“®’¼Œã‚ɂ́A‚¢‚©‚È‚é
+// ƒIƒuƒWƒFƒNƒg‚àŽw‚µ‚Ä‚¢‚Ü‚¹‚ñ‚̂ŁA“–‘RƒIƒyƒŒ[ƒVƒ‡ƒ“‚ðŒÄ‚яo‚·‚±‚Æ‚ª‚Å
+// ‚«‚Ü‚¹‚ñBã‚Ì class A ‚̏ꍇ‚ł́A
+
+The "a" is a null-pointer, and it points nothing.  In the same way,
+since m_MyServiceConsumer can be state that does not point any object,
+it cannot call any operations.  In the above example, variable "a" can
+be a valid pointer if a new object is created and is assigned to the
+pointer as the following.
+
+ int main (void) {
+   A* a;
+   a = new A();
+   a->echo("Hello World!!");
+ }
+
+// ƒIƒuƒWƒFƒNƒg‚ðnew‚Ő¶¬‚µ‚āA•Ï” a ‚É‘ã“ü‚µ‚Ä‚ ‚°‚ê‚Î a ‚Í‚»‚ÌŽž“_‚Å‚ 
+// ‚éƒIƒuƒWƒFƒNƒg‚ðŽw‚µŽ¦‚·³“–‚ȃ|ƒCƒ“ƒ^‚Å‚·‚̂ŁAclass A‚̃ƒ“ƒoŠÖ”‚Å‚ 
+// ‚é echo() ‚ðŒÄ‚Ô‚±‚Æ‚ª‚Å‚«‚Ü‚·B
+
+Therefore, now variable "a" can call the "echo()" function which is a
+member of class A.
+
+// ‚µ‚©‚µ‚È‚ª‚çAƒRƒ“ƒ|[ƒlƒ“ƒg‚È‚¢‚̃Rƒ“ƒVƒ…[ƒ}‚ªŒÄ‚яo‚µ‚½‚¢‚̂́Aƒlƒb
+// ƒgƒ[ƒNã‚Ì‚Ç‚±‚©‚É‚ ‚éƒIƒuƒWƒFƒNƒg‚̃IƒyƒŒ[ƒVƒ‡ƒ“‚Å‚·B‚µ‚½‚ª‚Á‚āA
+// m_MyServiceConsumer ‚ªŽw‚µŽ¦‚·‚̂̓Šƒ‚[ƒgƒIƒuƒWƒFƒNƒg‚ÌŽQÆ (CORBAƒIƒu
+// ƒWƒFƒNƒgŽQÆ(ƒŠƒtƒ@ƒŒƒ“ƒX)) ‚Å‚·B
+
+However, consumer in the component would call a operation of the
+remote object which is located somewhere on the network.  In other
+words, m_MyServiceConsumer points a reference (CORBA's object
+reference) to a remote object.
+
+// ŽÀ‚͉º}‚ÉŽ¦‚·‚悤‚ɁAƒRƒ“ƒVƒ…[ƒ}‚Í‚»‚̃|[ƒg‚ªƒvƒƒoƒCƒ_‚ðŽ‚Âƒ|[ƒg
+// ‚Ɛڑ±‚³‚ê‚é‚Æ‚«‚ɁA‘Ήž‚·‚éƒIƒuƒWƒFƒNƒgŽQÆ‚ðŽó‚¯Žæ‚è‚Ü‚·BÚ‘±‚É‚æ‚è
+// ƒRƒ“ƒVƒ…[ƒ}‚͐³“–‚ȃIƒuƒWƒFƒNƒg‚ðŽw‚·‚±‚Æ‚É‚È‚èA‚±‚¤‚µ‚߂ăIƒyƒŒ[
+// ƒVƒ‡ƒ“‚ðŒÄ‚яo‚·‚±‚Æ‚ª‚Å‚«‚é‚Ì‚Å‚·B
+
+As shown in the following figure, a consumer receives an object
+reference when it is connected to the other port which has provider.
+After the connection established, since the consumer has a valid
+object reference, it can call operations in the remote object.
+
+#ref(serviceport_connection_and_reference_ja.png,40%,center)
+CENTER: ''Connecting service ports and object reference''
+
+// Ú‘±Œã‚Í(‘ŠŽè‚̃|[ƒg‚É“K“–‚ȃvƒƒoƒCƒ_‚ª‘¶Ý‚·‚ê‚Î)ƒRƒ“ƒVƒ…[ƒ}‚̃Iƒy
+// ƒŒ[ƒVƒ‡ƒ“‚ðŒÄ‚яo‚·‚±‚Æ‚ª‚Å‚«‚Ü‚·‚ªAÚ‘±‚µ‚Ä‚¢‚È‚¢ê‡A‚Ü‚½‚Í—LŒø‚È
+// ŽQÆ‚ªƒZƒbƒg‚³‚ê‚Ä‚¢‚È‚¢ê‡‚́AƒRƒ“ƒVƒ…[ƒ}ƒIƒuƒWƒFƒNƒg‚Í—áŠO‚ð“Š‚°‚Ü
+// ‚·B‚»‚µ‚āAƒRƒ“ƒVƒ…[ƒ}‚ð—˜—p‚·‚éê‡A‚¢‚ڑ±‚ªs‚í‚ê‚é‚©A‚Ü‚½‚¢‚Â
+// Ú‘±‚ªØ’f‚³‚ê‚é‚©‚Í•ª‚©‚è‚Ü‚¹‚ñ‚̂ŁAí‚É‚±‚Ì—áŠO‚ð•ß‘¨‚µ‚Ä“KØ‚ɏˆ—
+// ‚·‚é•K—v‚ª‚ ‚è‚Ü‚·B
+
+After connection established, the consumer can call operations if an
+appropriate provider exists in the other port.  The consumer will
+throw exceptions if the connection is not established or valid object
+reference is not set.  Since you cannot know when connection is
+established or is destructed, always you have to catch exceptions from
+consumers and handle them adequately.
+
+ try
+ {
+   m_MyServiceConsumer->echo("Hello World!!");
+ }
+ catch (CORBA::SystemException &e)
+ {
+   // some logic when exception is caught
+      std::cout << "Port is not connected" << std::endl;
+ }
+ catch (...)
+ {
+   // Other exceptions
+ }
+
+// ‚È‚¨AonExecute() ƒƒ“ƒoŠÖ”“à‚Å—áŠO‚ª”­¶‚µAŠÖ”“à•”‚Å•ß‘¨‚³‚ê‚È‚©‚Á
+// ‚½ê‡ARTC‚̓Gƒ‰[ó‘Ô‚Ö‘JˆÚ‚µ‚Ü‚·B
+
+If an exception is thrown from the onExecute() member function, and
+the exception is not caught, RTC will go to error state.
+
+// ˆÈã‚𓥂܂¦‚āAMyServiceConsumer ƒRƒ“ƒ|[ƒlƒ“ƒgŽÀ‘•‚µ‚Ü‚·B‚±‚Ì—á‚ł́A
+// onExecute() ‚ц[ƒU‚©‚ç‚Ì“ü—Í‘Ò‚¿‚ðs‚¢AŠeƒIƒyƒŒ[ƒVƒ‡ƒ“‚ɑΉž‚µ‚½ƒR
+// ƒ}ƒ“ƒh‚ðŽó‚¯Žæ‚èAƒRƒ}ƒ“ƒh‚ɉž‚¶‚ăŠƒ‚[ƒg‚̃vƒƒoƒCƒ_‚̃IƒyƒŒ[ƒVƒ‡ƒ“
+// ‚ðŒÄ‚яo‚µŒ‹‰Ê‚ð•Ô‚·‚Æ‚¢‚Á‚½ŠÈ’P‚È‚à‚Ì‚Å‚·B
+
+Based on the above, let's implement a MyServiceConsumer component.  In
+this example, the component receives commands assigned to each
+operation defined in the interface in the onExecute() function, and
+call actual operation in the remote object according to the received
+command and return results.
+
+// ‚ł́A‚Ü‚¸ƒ†[ƒU‚É—˜—p‚Å‚«‚éƒRƒ}ƒ“ƒh‚ð’ñŽ¦‚·‚é•”•ª‚©‚ç‚Ý‚Ä‚¢‚«‚Ü‚·B
+
+So, let's see a part that shows available command to users.
+
+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);
+
+// ‚Ü‚¸Aã‚ŏq‚ׂ½‚悤‚ɃRƒ“ƒVƒ…[ƒ}‚ª”­‚·‚é—áŠO‚ð•ß‘¨‚·‚邽‚ß‚Étryß‚ňÍ
+// ‚Ý‚Ü‚·B—˜—p‰Â”\‚ȃRƒ}ƒ“ƒhƒŠƒXƒg‚ð•\Ž¦‚µ‚āAƒ†[ƒU‚Ì“ü—Í‚ðgetline()ŠÖ”
+// ‚Ŏ󂯎æ‚Á‚Ä‚¢‚Ü‚·B
+
+As mentioned above, in order to catch exceptions from consumer please
+put the code into a "try" block.  This code is showing available
+command list and getting input from user by getline() function.
+
+      
+      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);
+        }
+
+// ‚±‚ê‚ç‚̃Rƒ}ƒ“ƒh‚Ì‚¤‚¿Aˆø”‚ðŽæ‚é‚à‚Ì‚Í echo ‚Æ set_value ‚¾‚¯‚ŁA‚©‚Â
+// ‚±‚ê‚ç‚̃Rƒ}ƒ“ƒh‚͈ø”‚ðˆê‚‚¾‚¯‚Æ‚è‚Ü‚·BŽó‚¯Žæ‚Á‚½•¶Žš—ñ‚ðÅ‰‚Ì‹ó”’
+// ‚Å•ªŠ„‚µAargv[0] = ƒRƒ}ƒ“ƒhAargv[1] = ˆø”‚Æ‚µ‚Ä string ‚Ì vector ‚É
+// Ši”[‚µ‚Ü‚·Becho, set_value ƒRƒ}ƒ“ƒh‚Å‚Í argv[1] ‚ðˆø”‚Æ‚µ‚Ä—˜—p‚µA‘¼
+// ‚̃Rƒ}ƒ“ƒh‚Å‚Í’Pƒ‚É–³Ž‹‚·‚邱‚Æ‚É‚µ‚Ü‚·B
+
+Only "echo" and "set_value" commands receives argument in the command
+set, and these commands have only one argument.  Separating received
+character string by blank character, two strings are stored as argv[0]
+= command and argv[1] = argument.  argv[1] is used as argument in the
+echo and set_value command, and for other command argv[1] is just
+ignored.
+
+        
+      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 ƒRƒ}ƒ“ƒh‚ÌŽÀ‘•‚Å‚·Bargv[0] ‚ª ''echo'' ‚̏ꍇAargv[1] ‚ðˆø”‚É‚µ
+// ‚Ä echo() ŠÖ”‚ðŒÄ‚яo‚µ‚Ü‚·Becho() ‚ÌCORBA‚ÌstringŒ^‚Ì–ß‚è’l‚ðŽó‚¯Žæ
+// ‚邽‚߂̕ϐ”‚Æ‚µ‚āAretmsg ‚ðéŒ¾‚µ‚Ä‚¢‚Ü‚·Becho() ‚Ì–ß‚è’l‚̏Š—LŒ ‚Í
+// ‚±‚¿‚瑤‚É‚ ‚é‚̂ŁAŽó‚¯Žæ‚Á‚½Œã‚É“KØ‚ɗ̈æ‚ð‰ð•ú‚·‚é•K—v‚ª‚ ‚é‚Ì‚Å‚·
+// ‚ªAString_var Œ^‚̃Xƒ}[ƒgƒ|ƒCƒ“ƒ^‚ð—˜—p‚·‚é‚ƁA•s—v‚É‚È‚Á‚½Žž“_‚Å“KØ
+// ‚ɗ̈æ‰ð•ú‚ðs‚Á‚Ä‚­‚ê‚Ü‚·B–ß‚è’l‚ð•\Ž¦‚µ‚āAreturn RTC::RTC_OK ‚Æ‚µ‚Ä
+// onExecute() ŠÖ”‚𔲂¯‚Ä‚¢‚Ü‚·B
+
+This is an implementation of echo command.  In case that argv[0] is
+"echo", echo() function is called with argument from argv[1].  In this
+function, CORBA's string type variable "retmsg" is declared to receive
+return value from echo() function.  Since the ownership of the return
+value from echo() function is here, you have to release memory
+properly after used.  However, if String_var type smart pointer is
+used in this context, memory will be released automatically when it is
+not used any more.  So this code just prints returned value and end
+the onExecute() function with return RTC::RTC_OK.
+
+      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 ƒRƒ}ƒ“ƒh‚ÌŽÀ‘•‚Å‚·Bˆø” argv[1] ‚Ì•¶Žš—ñ‚ðCORBA::Float Œ^‚É
+// •ÏŠ·‚µ‚āAset_value() ƒIƒyƒŒ[ƒVƒ‡ƒ“‚̈ø”‚É—^‚¦‚Ä‚¢‚Ü‚·B
+
+This is "set_value" command implementation. After converting argument
+argv[1] to CORBA::Float, it is given to set_value() operation as an
+argument.
+
+        
+      if (argv[0] == "get_value")
+        {
+          std::cout << "Current remote value: "
+                    << m_myservice0->get_value() << std::endl;
+          return RTC::RTC_OK;
+        }
+
+// get_value ƒRƒ}ƒ“ƒh‚Í set_value ƒRƒ}ƒ“ƒh‚Őݒ肵‚½’l‚ðŽæ“¾‚µ‚Ü‚·B
+// get_value() ƒIƒyƒŒ[ƒVƒ‡ƒ“‚́A–ß‚è’l‚ª CORBA::Float ‚Å’l“n‚µ‚Ì‚½‚߃Iƒu
+// ƒWƒFƒNƒg‚̏Š—LŒ ‚È‚Ç‚Í“Á‚ɍl‚¦‚È‚­‚Æ‚à\‚¢‚Ü‚¹‚ñB‚±‚±‚ł́A–ß‚è’l‚ð‚»
+// ‚Ì‚Ü‚Ü std::cout ‚ŃRƒ“ƒ\[ƒ‹‚É•\Ž¦‚³‚¹‚Ä‚¢‚Ü‚·B
+
+"get_value" command gets a value that is set by "set_value" command.
+get_value() operation has a CORBA::Float return value, and because it
+is passed by value, concerning about ownership of object is not
+necessary.  Here, returned value is directly printed out to the
+console by 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 ƒRƒ}ƒ“ƒh‚ł́Aget_echo_history() ‚ÌŒ‹‰Ê‚ðŽó‚¯Žæ‚èA‚»
+// ‚ê‚Ü‚Å echo ƒRƒ}ƒ“ƒh‚ňø”‚É—^‚¦‚ç‚ꂽ•¶Žš—ñ‚̃ŠƒXƒg‚ð•Ô‚µ‚Ä‚¢‚Ü‚·B
+// get_echo_history() ŠÖ”‚Ì–ß‚è’l‚Í CORBA ‚̃V[ƒPƒ“ƒXŒ^‚Å‚ ‚é EchoList
+// ‚Å‚·BƒV[ƒPƒ“ƒXŒ^‚ɂ‚¢‚Ä‚àƒXƒ}[ƒgƒ|ƒCƒ“ƒ^‚Å‚ ‚é _var Œ^‚ª’è‹`‚³‚ê‚Ä
+// ‚¢‚Ü‚·‚̂ŁA‚±‚ê‚ð—˜—p‚µ‚Ü‚·B”z—ñ‚Ì’·‚³‚ðŽæ“¾‚·‚邽‚ß‚Ì length() ŠÖ”
+// ‚ª—˜—p‚Å‚«‚é‚̂ŁA’·‚³‚ð’²‚×‚Ä for •¶‚Å‚·‚ׂĂ̗v‘f‚ð•\Ž¦‚µ‚Ä‚¢‚Ü‚·BƒV[
+// ƒPƒ“ƒXŒ^‚Ì_varŒ^‚ł́Aã‚̂悤‚É[]ƒIƒyƒŒ[ƒ^‚ð—˜—p‚µ‚ÄCŒ¾Œê‚Ì”z—ñ‚̂悤
+// ‚ÉŠe—v‘f‚ɃAƒNƒZƒX‚Å‚«‚Ü‚·B
+
+get_echo_history command receives a result from get_echo_history()
+operation, and print a list of strings that were given to echo-command
+before.  The return value of get_echo_history() operation is EchoList
+CORBA sequence type.  Since the _var smart pointer type is also
+defined for sequence type, it is used there.  A "length()" function
+which returns current length of the array is available, and getting
+the length of the array by it all the values are printed out by "FOR"
+sentence.  In the _var object of sequence type, "[]" operator is
+available as shown in above example, and each element can be accessed
+like in C language.
+
+      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;
+        }
+
+// ÅŒã‚ɁAget_value_history ƒRƒ}ƒ“ƒh‚Å‚·Bget_value_history() ƒIƒyƒŒ[ƒVƒ‡
+// ƒ“‚ðŒÄ‚яo‚µA‚±‚ê‚܂Őݒ肳‚ꂽ‚ ‚½‚è‚̃ŠƒXƒg‚ð•\Ž¦‚µ‚Ü‚·B
+// get_value_hitory() ŠÖ”‚Ì–ß‚è’l‚Í CORBA::Float ‚̃V[ƒPƒ“ƒXŒ^‚Ì
+// ValueList ‚Å‚·B—v‘f‚Í CORBA::Float ‚Ì‚½‚߃IƒuƒWƒFƒNƒg‚̏Š—LŒ “™‚Æ‚¢‚Á
+// ‚½‚±‚Ƃ͍l‚¦‚È‚­‚Ä‚à‚æ‚¢‚Ì‚Å‚·‚ªAƒV[ƒPƒ“ƒXŒ^‚Í‚»‚ꎩgƒIƒuƒWƒFƒNƒg‚Å
+// ‚·‚̂ŁAŠ—LŒ ‚ðl—¶‚µ‚È‚¯‚ê‚΂Ȃç‚È‚¢‚Ì‚Å‚±‚±‚Å‚Í _var Œ^‚̕ϐ”‚ÅŽó‚¯
+// Žæ‚Á‚Ä‚¢‚Ü‚·B
+
+Let's see get_value_history command implementation.  Calling
+get_value_history() operation, it prints out a list of values which
+were set before.  The return value of the get_value_history()
+operation is ValueList, which is sequence type of CORBA::Float.  Since
+each element is CORBA::Float, you don't need to consider the ownership
+of objects.  However, since sequence type variable is an object to be
+considered its ownership, it is assigned to _var type variable.
+
+ std::cout << "Invalid command or argument(s)." << std::endl;
+     }
+   catch (CORBA::SystemException &e)
+     {
+       std::cout << "No service connected." << std::endl;
+     }
+   return RTC::RTC_OK;
+ }
+
+// ÅŒã‚ɁAã‚Ì‚Ç‚ê‚É‚à“–‚Ä‚Í‚Ü‚ç‚È‚©‚Á‚½ƒRƒ}ƒ“ƒh‚̏ꍇ‚ɁAƒƒbƒZ[ƒW‚ðo
+// ‚µ‚Ä‚¢‚Ü‚·B‚Ü‚½AƒRƒ“ƒVƒ…[ƒ}‚ÉŽQÆ‚ªƒZƒbƒg‚³‚ê‚Ä‚¢‚È‚¢ê‡‚Ì—áŠO‚ðŠÜ
+// ‚ß‚Ä•ß‘¨‚·‚邽‚ß‚Ì catch ß‚ª‚ ‚è‚Ü‚·B
+
+At the end, a message is printed out for unknown or invalid command
+case.  And you can see "catch" block to catch exception from the
+consumer including reference not assigned exception.
+
+// ˆÈãAƒRƒ“ƒVƒ…[ƒ}‚É‚æ‚éƒIƒyƒŒ[ƒVƒ‡ƒ“‚̌Ăѕû‚ɂ‚¢‚ÄŠÈ’P‚È—á‚ðŒð‚¦‚Ä
+// à–¾‚µ‚Ü‚µ‚½BƒRƒ“ƒVƒ…[ƒ}‚ð—˜—p‚·‚éÛ‚ɂ́A•K‚¸‚µ‚àƒIƒuƒWƒFƒNƒgŽQÆ‚ª
+// ƒZƒbƒg‚³‚ê‚Ä‚¢‚é‚Æ‚ÍŒÀ‚ç‚È‚¢‚̂ŁA•K‚¸—áŠO‚ð•ß‘¨‚µ‘Ώˆ‚·‚邱‚ƂƁAŠeƒI
+// ƒyƒŒ[ƒVƒ‡ƒ“‚̌Ăяo‚µ‚ªACORBA‚̃‹[ƒ‹‚ÉŠî‚¢‚čs‚í‚ê‚邱‚Æ‚É—¯ˆÓ‚µ‚Ä
+// ‚­‚¾‚³‚¢B
+
+How to call operations from consumer was explained sprinkled with some
+simple example in above.  In case of using consumers, it must be noted
+that exception from consumers should always be caught and should be
+handled them since object reference is not always set to it.  And note
+that every operation call would be done by CORBA's rule.