avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: thinking Merlin/Pheoix stuff ...
Date Sun, 02 Jun 2002 14:54:00 GMT


Peter Donald wrote:

>On Fri, 31 May 2002 17:59, Stephen McConnell wrote:
>
>>Looking at a real example - the assembly of an ORB - the information
>>supplied to an ORB to assemble itself is specific to an ORB component.
>> As shown in the above example, its a bunch of interceptor declarations.
>>
>
>The problem is that there is no way that I can think of of passing in 
>configuration without restricting yourself to a particular implementation. 
>For instance most roles/interfaces can have multiple implementations. 
>
>One implementation may require configuration, one may not require 
>configuration (it may be fixed at compile time), one configuration schema may 
>be different from another. One implementation may have similar contained 
>components but represented completely and utterly differently or whatever. ie 
>Are interceptors specific to OpenORB implementation? or are they generic 
>across all Corba ORBs? 
>

An interceptor is a standard ORB extension mechanisms.  In fact you can 
look at an ORB as a ServiceManager - interceptors represent service 
available via the ORB.  In the classic ORB specificiation these are 
accessed via orb.resolve_initial_references( "myService" ).  The 
org.apache.orb.ORB implementation actually implements the ServiceManager 
interface which simply delegates actions to the standard 
resolve_initial_references operation.  

Using the example we discussed before of a component that has a 
dependecy on an ORB from which it can locate a time service ... if we 
translate this into Avalon terminaology, it could be described as a 
component that has a dependecy on a service (which is a ServiceManager) 
that exposes sub-services.  If the dependency declaration were extended 
to support nested dependencies, we could potentially see something like 
the following:

  <dependencies>
      <dependency>

          <!-- declaration of a classic dependency -->

          <role>orb</role>
          <service name="org.apache.orb.ORB" version="2.4">

              <!-- declaration of the nested dependecies that this
                   component has on the supplied ORB -->

              <dependency>
                  <role name="time">
                  <service name="org.omg.CosTime.TimeService" version="1.0">
              </dependecy>

          </service>

      </dependency>
  </dependencies>

When handling the establishment of the component, a container can spot 
the nested dependecies and recognize that this menas that the primary 
dependecy is a service manager that has to be populated relative to the 
sub-dependencies.  This would get out out of the "configuration" issue 
and focussed on the question of nested dependecy declarations.

The actual component could then do something like:

    public void service( ServiceManager manager )
    {
        m_orb = (ORB) manager.lookup( "orb" );
        m_time = (TimeService) manager.lookup( "orb/time" );
    }

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message