Re: OpenORB Avalon intergation.

[Stephen McConnell <mc...@apache.org>]

Hi Garry:

So for the delay in responding to your email - but I've made up
for that with a detailed reply :-)

Gary Shea wrote:

>
> I'm trying to see how the Avalon model meshes with the relationship
> between an ORB and the components that can be fit into it, like the TNS.
> At one level, there is already a model in place, the POA (and the PI?),
> that mandates how components fit into the ORB.  Ideally, there should be
> a way that manipulations of components in the Avalon model should
> correspond directly and cleanly to the actions taken to attach/detach
> services to/from the ORB.  Unfortunately, I'm totally out of my depth
> here...

About a year ago my initial approach was to define the application
components and plug these together using component composition.  This
worked fine in the beginning, however, as you get into multi-ORB
scenarios you really need to look more closely as the management model
of the ORB, the Avalon component model, and the means through which
you can achieve more transparent integration.

First of all - the ORB delivers two distinct computational roles:

  a) the static ORB and related ORB.init function which serves
     as an ORB factory

  b) the runtime ORB that serves as

     - a distributed computing platform
     - a manager of pluggable services
     - a minimal service directory

If we take a look at the factory what we have on the ORB is a relatively
primitive but "standard" factory operation that takes properties as
arguments. ORB implementations on the other-hand supplement this
with more comprehensive configuration models - however, a static
configuration description can only describe (a) system wide defaults,
and possibly (b) a set of predefined profiles of default values.  I've
done something similar with the org.apache.orb.ORBFactoryService
implementation.

http://home.osm.net/doc/orb/org/apache/orb/ORBFactoryService.html

The ORBFactoryService provides a number of operations supporting the
creation
of an ORB. The service is itself designed to be run as a "Block" within the
Phoenix application server (but can be executed independent of the Phoenix
environment).  Once installed in the app-server, the user can
wire together a new service and declare a dependency on the ORB factory.
ORBFactoryService is provided with a configuration and context on start-up.
The configuration holds the default property definitions to be applied to a
new ORB on creation.

A configuration looks something like:

    <orb-factory>

        <!--
        The following properties constitute default properties that
        will be added to the Properties instance supplied as an
        argument to the ORB init function.
        -->

        <property name="openorb.ORBLoader"
          value="org.apache.orb.CORBA.kernel.DefaultLoader" />
        <property name="openorb.debug" value="1" />
        <property name="openorb.debug.ShowStackTrace" value="true"/>

        <!--
        The following initializer elements define interceptors and
        features to be installed into an ORB.
        -->

        <initializer
          class="org.openorb.iiop.IIOPProtocolInitializer"
          name="iiop"/>

        <initializer
          class="org.openorb.adapter.poa.POAInitializer"
          name="poa"/>

    </orb-factory>

Using the above, you can invoke the operation createORB on the factory
and pass in either a supplementary Properties value and/or a
supplementary Configuration.  The factory implementation understands
cascading configurations, that is, a configuration backed by a parent
configuration.  This means that the configuration you want for a
particular ORB instance need only contain property and initalizer
declarations that override or supplement the default values.

http://home.osm.net/doc/orb/org/apache/orb/CascadingConfiguration.html

For examples, I have a server that provides a set of business components
and the server configuration contains a ORB configuration block.

    <gateway profile="osm.planet" policy="planet.xml">

        <orb>

            <property name="openorb.home" file="." />
            <property name="openorb.config" file="conf/orb.xml" />
            <property name="openorb.profile" value="gateway" />
            <property name="iiop.port" value="2509" />
            <property name="iiop.alternateAddr" value="home.osm.net:2509"/>

            <initializer class="org.apache.pss.Initializer" name="pss" />

        </orb>

        ...

     </gateway>

The above "orb" element is used by the gateway implementation as
an argument to the ORB factory.  In this case it includes a few extra
properties and the PSS initializer.  I should point out that the
current implementation is dependent on the supply of a OpenORB.config
file which drives the loading of the initializers - however - this will
disappear soon and the actual loading of initalizers will be driven by
the configuration file.  All loading takes place using the class
org.apache.orb.CORBA.kernel.DefaultLoader.

http://home.osm.net/doc/orb/org/apache/orb/CORBA/kernel/DefaultLoader.html

The loader is supplied with a special Properties argument (the
ORBInitContext class) prepared by the factory implementation.  The
context holds a logging channel, application context and the cascading
ORB configuration.  The loader uses this information to assign a logging
channel to the ORB under creation, and creates and supplies child
loggers to the components it creates (e.g. a PSS interceptor gets
assigned a logging channel that is a child of the ORB logging channel).
In addition, each interceptor is configured and contextualized by the
the loader.  This approach means that we will be able to migrate
away from the "properties" model towards hierarchical structures that
are passed to respective sub-systems.  For examples, the Apache PSS
implementation does not use properties - instead information is
supplied in the form of configuration instances.  After completing the
process of initialization of the new ORB instance, a new ORB, pre
configuration and contextualized relative the runtime context is
returned to the calling application.

http://home.osm.net/doc/orb/org/apache/orb/ORB.html

As shown in the above javadoc for org.apache.orb.ORB, the ORB instance
includes supplementary operations derived from the Avalon framework.
In particular, the Startable interface introduces the start and stop
operations.  An application simply needs to invoke start and everything
is taken care of by the implementation.  When the application completes,
the manager that is running the ORB will invoke stop(), followed by
dispose() from the Disposable interface.  Disposal basically releases
resources and this operation can be propagated down to ORB subsystems
(such as the PSS interceptor).  This ensures we have a clean service
deployment and disposal strategy.

> What I want to do is rewrite (again, arggh!) the TNS stuff so that it
> doesn't create its own ORB.

I think the right thing is for the Transient Name Service (TNS) to be
treated as an Initializer, preferably implementing the LogEnabled and
Composable interface.  This will ensure that the Initializer is properly
set up with a logging channel and configured with static information,
etc.  Take at look at the PSS interceptor as an example.

http://home.osm.net/doc/pss/org/apache/pss/Initializer.html

Basically you can get initial references inside the orb_init operation
(so you access the RootPOA for example) use this to create an object
reference for the TNS, publish it an initial reference then on post_init
go ahead and instantiate the TNS server.

The alternative - a TNS based on a supplied ORB is also possible - your
basically taking the supplied ORB, creating a POA and returning an
object reference.  To do this so your really leveraging the "Avalon"
model your implementation would be LogEnabled, Configurable,
Contextualizable and Composable. The Composable interface defines the
mechanisms though which your are supplied with the services you need to
create your TNS POA, namely the ORB.  You will run into some
restrictions concerning the use of Composable - namely the fact that
the ComponentManager passed to your implementation class can only pass
object derived from Component - there are two solutions (a) the managing
class put the ORB reference into a ORBContext (a convenience holder).

http://home.osm.net/doc/orb/org/apache/orb/ORBContext.html

The alternative is to use the Serviceable and ServiceManager interfaces
(not an official part of the Avalon framework and under current
discussion on the Avalon Dev list). These interfaces and implementations
enable you to manage CORBA Objects as first class components.

http://home.osm.net/doc/avalon/org/apache/avalon/framework/service/package-s
ummary.html

> I could include a pre-configured ORB in the
> Context, but would prefer that the ORB have a more formal Avalon role
> like Component.  Perhaps what Steve is working on will turn out to be
> exactly "ORB as Component".  Then the question is, is it 'right' to pass
> a Component to a Component as Context?  Doesn't sound exactly like
> 'composition'...

The org.apache.orb.ORB implementation is a full component and is available
for immediate use.  There is more work needed on packaging, documentation
and
detailing how the factory and ORB leverage the Avalon component model and
Phoenix app-server environment.  This also is somewhat dependent on the
Avalon-dev group coming to a resolution concerning management of objects
outside of the strict Avalon world.  In terms of future development, there
is still a lot to do in terms of enhancing internals of OpenORB to fully
support properly managed logging (e.g. assigning child loggers to POAs,
eliminating dependence of the Configarator class inside DefaultLoader,
etc.).  But its a good start.

In the meantime, its all available on-line under the Apache license.

http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-cornerstone/apps/enterprise
/orb/
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-cornerstone/apps/enterprise
/pss/

> I hope someone can see what I'm stuck on and make some useful
> observations!

I hope this helps.  Don't hesitate to post questions about Avalon to
the Avalon dev list.  Questions concerning the org.apache.orb/pss, etc.
should be posted to the Avalon Apps Dev list.

mailto:avalon-dev@jakarta.apache.org  // Avalon Dev
mailto:avalon-apps-dev@jakarta.apache.org // Avalon Apps Dev

In the meantime, we really need to put in place a demonstration
HelloWorld server using the full framework.  That will make things
much easier to understand and a lot easier deploy.

Please note that the Apache ORB and PSS implementation are based on the
current OpenORB CVS version.  Neither will work with the binary downloads
(due to changes to logging framework and some enhancements of the IDL
compiler to better support several improvements to the PSDL compiler).

Cheers, Steve.

> Regards,
>
>         Gary
>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>