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:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
