Re: [ecf-dev]Customize selection of RemoteServices Providers to expose/

[Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>]

Hi Phillip,

Konradi, Philipp wrote:
> <stuff deleted>
> So in case a new provider is installed into a container, how is an
> IHostContainerFinder implementation supposed to know about the
> capabilities of this new provider?
>   

Well, at service registration time, the DefaultHostContainerFinder looks 
through all the containers that currently exist/are known to the 
IContainerManager.  It selects one or several based upon whether they 
have IRemoteServiceContainerAdapter as an adapter.  If they *do* have 
that adapter...it's included in the found distribution containers.  This 
is just the default strategy...with no other knowledge about the 
candidate containers than that they already exist/are known to 
IContainerManager (they've been previously created), and that they 
implement IRemoteServiceContainerAdapter.  There's also an optional 
service property where a specific provider can be specified...but if 
this isn't specified then all IRemoteServiceContainerAdapters will be 
'found'.

Presumably, if someone/some app registers themselves as a 
IHostContainerFinder, with a priority higher than the 
DefaultHostContainerFinder, then they would have some knowledge of the 
characteristics of this new provider.   Of course, if they wish, their 
IHostContainerFinder can be based upon the DefaultHostContainerFinder 
(i.e. fall back on or extend it as desired).

Scott


> Philipp
>
>   
> > -----Original Message-----
> > From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Scott Lewis
> > Sent: Wednesday, April 29, 2009 6:11 PM
> > To: Eclipse Communication Framework (ECF) developer mailing list.
> > Subject: Re: [ecf-dev]Customize selection of RemoteServices Providers
> > to expose/ consume a service
> >
> > Hi Philip,
> >
> > Konradi, Philipp wrote:
> >     
> > > Hi all,
> > >
> > > in _http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02281.html_ as
> > > well as in today's conf call Scott described and asked for comments
> > > about the newest additions to RFC 119 / Distributed OSGi support:
> > >       
> the
>   
> > > IProxyContainerFinder / IHostContainerFinder interfaces as a way to
> > > customize the selection of ECF Remote Services Providers to expose /
> > > consume a service.
> > >
> > > I think that this extensions are important means for application
> > > developers / ECF extenders and starting here a new thread to discuss
> > > them and try to uncover missing point if there are some.
> > >
> > > When looking closely at the IHostContainerFinder interface:
> > >
> > > *public** interface* IHostContainerFinder {
> > >
> > > * public* IRemoteServiceContainer[] findHostContainers(
> > >
> > > ServiceReference serviceReference, String[] remoteInterfaces,
> > >
> > > String[] remoteConfigurationType, String[] remoteRequiresIntents);
> > >
> > > I've got the impression that a it fulfills two tasks:
> > >
> > > 1. Check which provider is capable to expose the service (based on
> > > interface, intents, configuration, ...)
> > >
> > > 2. Select from multiple suitable providers the ones which should
> > > actually take care of service exposure
> > >
> > > Is my understanding correct?
> > >
> > >       
> > Yes.
> >
> >     
> > > If yes: Task 1. requires very good knowledge of each available
> > > provider... is the implementer of IHostContainerFinder extension
> > >       
> point
>   
> > > supposed to have it?
> > >
> > >       
> > Yes...but just to be clear the IHostContainerFinder is not an
> >     
> extension
>   
> > point (yet), it's just a service interface.
> >     
> [Konradi, Philipp] 
> So in case a new provider is installed into a container, how is an
> IHostContainerFinder implementation supposed to know about the
> capabilities of this new provider?
>
>   
> > > This capability check is also required at the client/proxy side, to
> > >       
> > be
> >     
> > > taken care by IProxyContainerFinder?
> > >
> > >       
> > Yes.
> >
> >     
> > > Regards,
> > >
> > > Philipp
> > >
> > > P.S.: just a minor remark: Given that this extension point selects
> > >       
> > the
> >     
> > > providers from the available ones and not really "finds" them, maybe
> > > we should rename it to something like xxxContainerSelector?
> > >
> > >       
> > Calling it Selector would be reasonable if people prefer it...although
> > a
> > 'finder' is able to select from available ones *and/or* create new
> > ones.
> >
> > Again if people think Selector would be better (given that it can
> > indeed
> > create or select) I'm open to it...but we would have to come to
> > consensus to make the name change quickly.
> >
> > Thanks for questions and comments.
> >
> > Scott
> >
> >     
> ---------------------------------------------------------------------
>   
> > ---
> >     
> > > _______________________________________________
> > > ecf-dev mailing list
> > > ecf-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/ecf-dev
> > >
> > >       
> > _______________________________________________
> > ecf-dev mailing list
> > ecf-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ecf-dev
> >     
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
>