Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [ecf-dev] handling pub-sub providers with RFC 119 
Hi Scott,

Great to hear about improving support for JMS.
Comments inline...

Regards, 
Philipp

> -----Original Message-----
> From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Scott Lewis
> Sent: Wednesday, April 22, 2009 7:18 PM
> To: Eclipse Communication Framework (ECF) developer mailing list.
> Subject: [ecf-dev] handling pub-sub providers with RFC 119
> 
> Hi Folks,
> 
> Recently, there was a message thread titled "Remote service with
> ActiveMQ JMS topic using RFC 119 transparent way. " and in this
message
> [0], I described some work I'm doing with the ECF RFC 119 impl to
> easily
> deal with these cases (i.e. option 2 in my message).  
[Konradi, Philipp] I'd prefer option two, since option one doesn't
support the transparency which RFC 119 targeted for OSGi application
(services&clients) bundles.


BTW: in [0]: 
> Consider the following architecture:
> 
> A  <-->  B <--> C
>
> In this architecture, we have two clients 'A' and 'C' and a server
> 'B'...all participating in the same publish and subscribe group.
To verify I've understood it correctly: 'server' is in case of JMS the
JMS broker?


> ...By 'these cases'
> I
> mean publish and subscribe groups that are used for remote services
> between members of those groups (e.g. JMS groups, etc).
> 
> Currently, there's no direct support in RFC119 for remote services
> within pubsub groups... because although RFC119 has the notion of an
> 'endpoint ID', this endpoint ID gives the location of the remote
> service's host...which assumes that the host is a server (i.e. can be
> reached *directly* from a client), rather than indirectly (i.e. via a
> pub/sub group).
[Konradi, Philipp] That's correct, RFC 119 really does not say a word
about pub-sub... though my thinking was always that pub-sub is easily
possible with RFC 119 as well. But let's see, this discussion sounds
interesting... 
I assume by saying 'endpoint ID' you mean RFC 119
ServicePublication.PROP_KEY_ENDPOINT_LOCATION property.
ServicePublication defines also a property called PROP_KEY_ENDPOINT_ID
but this is just some unique service endpoint ID (e.g. an UUID) allowing
to find out whether service metadata discovered via different discovery
providers belongs to the same service instance or not.
My interpretation of RFC 119 PROP_KEY_ENDPOINT_LOCATION property is that
it's the URL under which the advertised service endpoint can be reached.

So in case of an Web service endpoint the url would probably contain
local host and port, in case of JMS (indirect communication) the url
would contain the host name of the JMS broker, port and the queue or
topic name. 

BTW: Would it make sense to add some (configuration) mechanisms to
select whether JMS queues or topics (request-response or pub-sub) should
be used for exposure of a service? 
I could think of using either intents for this or/and additional
configuration data with the service.


> ...I've added some API to our RFC119 implementation in
> org.eclipse.ecf.osgi.services.distribution.  What it does is expose
> both
> the *endpointID* and the *connectTargetID* in the discovery-published
> meta-data (i.e. see this interface [2]).  
[Konradi, Philipp] In my understanding PROP_KEY_ENDPOINT_LOCATION is
what you meant by *connectTargetID*. 


> ... On the client side, this
> information about the remote service (both it's endpointID and
> connectTargetID) can then be used to connect to a pub/sub group at
> remote service discovery time (but only when the connectTargetID is
> non-null...note that this has *no* effect/relevance for client-server
> distribution providers).
> 
> I've implemented the mechanism to do this, and am working on some test
> code using the ActiveMQ (JMS) provider.  If others are interested in
> helping test this, please let me know.
> 
> One more thing...in this previous thread [3] I brought up the issue of
> dealing with the situation where potentially many remote services were
> published/available on a lan (e.g.) and it was unclear (from RFC119)
> how
> this should be handled...e.g. does the announcement of some remote
> service mean that another remote service doesn't get a proxy?  Should
> all remote service discoveries lead to proxy creation?  How can an
> application provide some control/scope to the proxy creation?
> 
> RFC119 doesn't really address this situation yet, but I've added two
> service interface called IProxyContainerFinder, and
> IHostContainerFinder
> [4] that allows other bundles to register themselves as 'container
> finders'...i.e. to decide which (of potentially many) remote services
> providers should handle a discovered service publication.   Note that
> these container finders allow full customization of the remote service
> discovered meta-data (i.e. they can decide to create new IContainers,
> reuse old ones, ignore some, etc).  The way to replace the
> DefaultProxyContainerFinder is to simply register your own
> implementation of IProxyContainerFinder (or IHostContainerFinder) as
an
> OSGi service...e.g:
> 
>
bundleContext.registerService(IProxyContainerFinder.class.getName(),new
> MyProxyContainerFinder(), null);
> 
> And when services are discovered via the discovery impl(s) your
> container finder will be consulted to make the decision about what
> IContainer should/will handle the request.  Note that currently the
> service with the highest service ranking will be selected (if there
are
> many), and the DefaultProxyContainerFinder has the lowest service
> ranking possible (so will only be used if *no* other container finders
> are registered in the service registry).
> 
> Note that there is also a IHostContainerFinder, to allow the same sort
> of customization for selection of the IContainers to handle the host
> service publication (with the default being all existing IContainers).
> 
> Any comments welcomed.  
[Konradi, Philipp] 
Regarding handling of discovered services I was thinking about three
main strategies:
a) create service proxies for each discovered remote services
b) create a service proxy for a discovered remote services only if some
bundles asked or listen for such a service (interface filter)
c) like b) only with additional condition to create a proxy only if
service consumer hasn't any service at all (give the client an
appropriate service proxy but don't waste resources on multiple similar
proxies)

How about having default handlers for these general proxy creation
strategies and allow to configure them on a bundle-basis?!


> ... I'm working on testing/debugging this API right
> now (it already works fine with the r-OSGi and ecf generic providers
> (i.e. in org.eclipse.ecf.tests.osgi.services.distribution), but I want
> to verify the correct behavior for ActiveMQ provider also, as above).
> 
> To summarize, the two API additions are:
> 
> 1) IServiceEndpointDescription including both endpointID and
> connectTargetID
> 2) Adding IProxy/HostContainerFinder API to allow for
> customization/extension of the default container selection mechanism
> for
> both host and proxy handling.
> 
> Thanks,
> 
> Scott
> 
> [0] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02265.html
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=270652
> [2]
>
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osg
> i/services/discovery/IServiceEndpointDescription.html
> [3] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02206.html
> [4]
>
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osg
> i/services/distribution/package-summary.html
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top