[discovery] Design Question: Qualifying service names?

[Richard Sitze <rs...@us.ibm.com>]

To locate a service (based on sun's current mechanism) we can drop a file 
whose name is the service interface and content is the name of the 
implementation:

     META-INF/services/package.ServiceName:
          implPackage.ServiceNameImpl

One 'scheme' for locating a service is have the implementation provide a 
(possibly static) method which can be queried to see if the implementation 
is appropriate, by some criteria:

          boolean 
implPackage.ServiceNameImpl.isEnvironmentallyFriendly(someContext)

The problem with this approach is that (a) if it's not the right service, 
then why load it, and (b) it may not even be loadable if dependent classes 
are not available.  (b) is really a nit, but why load a (possibly) bunch 
of services + dependencies if we don't need them?

So, I'm considering a way to qualify the service in such a way that we can 
pre-determine if it's really what we want.  Here are a few schemes for 
discussion:

1.  The most flexible:  For every impl class, look for a implHelper class 
that we can load & query:
          boolean 
implPackage.ServiceNameImplHelper.isEnvironmentallyFriendly(someContext)

2.  [optionally] qualify the name of the of a service, i.e. one of the 
following:
     META-INF/services/qualifier/package.ServiceName
     META-INF/services/package.ServiceName.qualifier

     META-INF/services/package.ServiceName:
          implPackage.ServiceNameImpl  # qualifierType=qualifier

For example, consider a Socket factory that could be qualified by a 
protocol:
     META-INF/services/http/package.ServiceName
     META-INF/services/https/package.ServiceName

     META-INF/services/package.ServiceName.http
     META-INF/services/package.ServiceName.https

     META-INF/services/package.ServiceName:
          implPackage.ServiceNameImplHttp  # protocol=http
          implPackage.ServiceNameImplHttps  # protocol=https

Thoughts from the community?


*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development

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