hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hivemind-...@jakarta.apache.org
Subject [Jakarta HiveMind Wiki] New: ServiceImplementationSwitch
Date Mon, 09 Aug 2004 22:54:02 GMT
   Date: 2004-08-09T15:54:01
   Editor: AchimHuegen <ahuegen@gmx-topmail.de>
   Wiki: Jakarta HiveMind Wiki
   Page: ServiceImplementationSwitch
   URL: http://wiki.apache.org/jakarta-hivemind/ServiceImplementationSwitch

   no comment

New Page:

= Problem Description =

AchimHuegen, August 9 2004

This proposal is about multiple implementations of the same service interface.
The problem has already been described in this proposal: ConditionalContributionsProposal.

I dont't think that the example used there (pick implementation depending on jdk version and
library availability) is a very common use case. For me the most important use cases are:
  * Select most appropriate implementation for your application out of a set of possible candidates
(e.g. security realms: JDBCRealm, JNDIRealm, MemoryRealm)
  * Switch all services of a middleware connector to dummy implementations

= Proposed Solution =

I have one problem with the solution from ConditionalContributionsProposal:
The decision how to switch implementations technically is not made at the application level.
E.g. the first provider of a service implementation decides to use a system property. Now
all applications that use this service must provide this system property. But different providers
means different methods and finally your application has to deal with inconsistent implementation
selection.  

So here is my approach:
Implementations get a name and via a contribution a mapping from service to an implementation
is defined by referencing its name.

{{{
<service-point id="foo.service" interface="foo.MultipleService" />
    
<implementation service-id="foo.service" >
    <create-instance class="foo.serviceImplDefault" />
</implementation>

<implementation service-id="foo.service" >
    <create-instance name="implementation1" class="foo.serviceImpl1" />
</implementation>

<contribution configuration-id="hivemind.ServiceImplementationSwitch" >
    <switch service-id="foo.service" implementation="implementation1" />
</contribution>
}}}

This example shows a service point with two implementations. The first implementation is the
default and has no name. The second one is named "implementation1".
The contribution tells the registry to use the latter one when creating instances of this
service.

== Default implementation ==

If only one implementation exists it is the default. 
If multiple implementations exist and one is unnamed, then its the default. If no mapping
is defined, then the default implementation is used.

== Symbol sources ==

You can use symbols in the configuration immediately. E.g. a system property:
{{{
<contribution configuration-id="hivemind.ServiceImplementationSwitch" >
    <switch service-id="foo.service" implementation="{propertyFooService}" />
</contribution>
}}}

== Extensions ==

=== Wildcards ===
Switch all implementations matching a wildcard. More concrete definitions have higher priority:
{{{
<contribution configuration-id="hivemind.ServiceImplementationSwitch" >
    <switch service-id="foo.*" implementation="dummy" />
    <switch service-id="foo.connectors.*" implementation="local" />
</contribution>
}}}

=== Expression Language ===
The expression language from ConditionalContributionsProposal could be integrated.
{{{
<contribution configuration-id="hivemind.ServiceImplementationSwitch" >
    <switch service-id="foo.service" implementation="{propertyFooService}" 
        condition="jdk(1.4)" />
</contribution>
}}}



---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org


Mime
View raw message