Articles Forum Examples Download
Oct 17, 2007
Copyright(c) 2007 by Pocomatic Software. All Rights Reserved.
A typical CORBA application development cycle consists of the following three phases:
Design: Design and define object interfaces using OMG IDL
Implementation: Implement object servants' business logic.
Deployment: Provisioning the object server by enlisting servant implementations as a service endpoint.
This article demonstrates a full development cycle of a simple CORBA client-server application. The full source code of these examples are available in examples/corba/hello and examples/corba/hello-tie directories of the PocoCapsule installation. Other additional PocoCapsule/CORBA examples including POA server, OMG-Event/Notification, OMG-DDS, OMG-RTC, and JTRS-SCA are also available from the installation.
In OMG CORBA object model, interfaces of objects are defined using the programming language neutral interface define language (IDL). For instance, the object interface of this example is defined in the Greeting.idl as follows
|
The IDL interface definition above is intuitive for average C++ and/or Java application developers. Conceptually, it could be understood as merely a language independent expression of the following C++ pure virtual class definition:
|
In fact, IDL to C++ mapping utilities/tools indeed generate the client-side stub class sample::Greeting more or less similar to this conceptual mapping.
The second development phase is to implement the business logic of this Greeting service object. There are two portable implementation styles standardized by OMG, namely the “servant inheritance” and the “TIE delegation”, and are referred to as “servant” and “native” respectively in PocoCapsule/CORBA.
In the “servant” style, the object’s server implementation (known as the servant) C++ class should support all operations defined in the IDL interface and should have the so-called POA server skeleton as its direct or indirect parent class. This POA server skeleton is generated from the user defined object IDL using the tool that comes with the underlying ORB (such as the idl2cpp of VisiBroker/C++ or tao_idl of TAO). In this example, the generated POA server skeleton C++ class is the POA_sample::Greeting. The “servant” implementation class MyGreetingServantImpl is therefore prototyped/implemented, for instance, in the GreetingImpl.h/GreetingImpl.C as follows:
|
In the “native” style, the object’s server implementation C++ class should support all operations defined in the IDL interface as in the case of “servant” style, however, not necessary to have the so-called POA server skeleton in the parent class hierarchy. In this example, a “native” implementation class MyGreetingNativeImpl is simply prototyped/implemented in the GreetingImpl.h/GreetingImpl.C as follows:
|
The compiled binary object file(s) of the implementation above, either the servant or the native class, can be directly linked into the server application main executable later on, or can be linked into a standalone shared or dynamic loadable library and then linked or loaded by the main server executable.
Notably, the object interface and its implementations in either the servant or the native form are designed, implemented, and built as ordinary CORBA 2.x application components. Developers do not need to have knowledge or concern about PocoCapsule/CORBA and can assume the resulting component binary (shared/dll library or object file) is going to be used within a plain old CORBA 2.x runtime environment.
The third development phase is deployment, namely to enlist instances of server object implementation classes to the ORB and retrieve the object references or URLs for clients. In PocoCapsule/CORBA, this is done by writing a deployment descriptor that describes the desired deployment setup.
A PocoCapsule/CORBA deployment descriptor describes the structure or arrangement of a given CORBA application in a declarative style, to be distinct from the traditional imperative programming style. A declarative program describes “what” are the intended structures and dependencies without specifying procedures to construct them. An imperative program instructs “how” to proceed step by step in performing given operations.
Imperative programming style is familiar to most OO professionals and is widely used in component implementations and traditional manual application assembly and deployment. However, it is not the most expressive way to describe high level service or system level deployment compositions. Such compositions are best to be comprehended and expressed by their deployed structures rather than by their deployment procedures.
For the servant style implementation, the declarative deployment descriptor (examples/corba/hello/setup.xml) looks like the following:
|
Similarly, for the native (namely, the TIE delegation) style implementation, the deployment descriptor (examples/corba/hello-tie/setup.xml) looks like the following:
|
The deployment descriptor, either the first (for servant implementation) or the second (for native implementation), describes the following server components and setup:
A server object implementation is declared as a singleton <bean> instance of the class MyGreetingServantImpl or MyGreetingNativeImpl. By this declaration, this instance will be instantiated on demand using its constructor with no parameter, and can be referred within the application context via its id “my-impl”.
An ORB instance, with id of “my-orb”. By this declaration, this ORB instance will immediately be initiated as a singleton.
Explicitly under this ORB, a CORBA object is declared (enlisted) uses the declared “my-impl” servant or native instance above as its implementation. The uri attribute of this object equals to “my-server” which will be used as the URI of its corbaloc URL. By this declaration, this CORBA object will immediately be activated as a singleton.
When deploying the native style implementation, the impl-type attribute of <object> element should be specified as “native” (the default value of this attribute is “servant”).
When deploying the native style implementation, the interface attribute of <object> element should be specified as the full scope name of the server IDL interface, namely the “sample::Greeting” in this example.
The PocoCapsule/C++ core framework and the server component implementations above in form of plain old C++ object (POCO) classes are developed independently without knowing each other. However, when deploying these implementations, the core framework has to invoke operations defined on these POCO classes, such as its constructor. This is achieved in PocoCapsule/C++ IoC framework through dynamic invocation proxies.
A unique technique of PocoCapsule/C++ IoC framework is to generate dynamic invocation proxies from deployment descriptors. This scenario is opposite to “reflection” and therefore is referred to as “projection”. Unlike CASE tools or MDA code generators, PocoCapsule/C++ only generates the invocation proxies implied by metadata of deployment descriptors rather than the procedure code with actual invocation parameters to be performed by these descriptors. Hence, the proxy code does not need to be regenerated under method argument value changes of the deployment descriptor.
The utility tool in PocoCapsule/C++ for this “projection” code generation is pxgenproxy. In this example, the proxy code is generated from the descriptor file setup.xml as follows:
|
The generated source code of proxies will be written to a file (happens to be setup_reflx.cc in this example). More detailed description on pxgenproxy utility can be found in PoocCapsule/C++ IoC & DSM Framework Developer Guide.
Unlike CASE, MDA, and IDL that either require application developers to manually insert application code into the generated code, or require application code to extend and implement or invoke generated interfaces/stubs, the PocoCapsule/C++ generated code are completely unknown to applications and largely transparent to application developers.
Application developers only need to look into the generated proxy code if an operation invocation signature mismatch error was reported during its compilation, which is most likely caused by bugs inside the user supplied deployment descriptor. However, the PocoCapsule/CORBA framework’s high level domain specific declarative schema is able to catch most of such low-level errors by the schema validation. Therefore, with PocoCapsule/CORBA, application developers rarely need to look into generated code and can simply compile and build it into a shared/dynamic library or directly link it with the application main executable. In this example, the shared library approach is used and the library is named as reflx.so (or reflx.dll on windows).
The Greeting object server object implementation should be deployed, with the deployment descriptor, to a runtime environment, also known as a container. In PocoCapsule and most other IoC containers, the term “container” merely refers to a application context factory object, which can be embedded in any C++ or Java applications. In this example with PocoCapsule/C++ IoC, this factory is embedded in a tiny C++ main() function (examples/corba/hello/server.C) as follows:
|
This mini container is application independent. Therefore, it is used by many other examples in the PocoCapsule/C++ installation, and can be used by real production applications as well. The POCO_AppContext class in the code is described in the PocoCapsule/C++ IoC & DSM framework developer guide. In a brief description, the code above in this main executable does:
The initDefaultAppEnv() passes the command line arguments to an underlying POCO_AppEnv singleton instance. These argument will then be passed to the PocoCapsule/C++ engine as well as ORB_init().
An application context representation is created from the given assembly/ deployment descriptor (happens to be named as setup.xml in this example).
Establish the server structure from the context by instantiating all eager singleton components (see PocoCapsule/C++ IoC & DSM). This includes declared ORB instance(s) and all declared CORBA objects.
Then, to start the ORB request dispatch loop and print out all published corbaloc URLs, the server retrieves the reference of a lazy instantiation bean of id equals to “pocomatic.dispatcher:user-declared-orb-id” (in this example, the user declared orb id is “my-orb”) from the context. This effectively invokes a function implicitly declared as this bean’s factory. As to be described in more detail, URLs are automatically published by PocoCapsule/CORBA if an <object> element is declared with a specified uri attribute. The value of this uri attribute will be used as the URI of the published URL.
The first thing to do in playing this example is to start the server. As said above, the server will print out the URL of the server object with the URI (i.e. “my-server”) specified in deployment descriptor setup.xml:
|
To see what objects and methods are inversely called back by the container behind the scene, one can restart the server with the “-Dpococapsule.trace.enable=true” command line option. This command line argument will then be passed to the PocoCapsule/C++ engine through the application context to turn on the tracing option. The trace messages are printed on the stderr, as highlighted in the following result: