[
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,
> Perhaps, but this isn't necessary the endpoint for all clients
> participating in the group. That is, what if A (above) publishes a
> service? What would its endpoint be in the service publication?
If A would publish a service, then I could think of its service endpoint
location in the service publication to look like:
jms:activemq::B:1099/myServiceTopic
B being the hostname of the broker, myServiceTopic being the name of the
JMS topic on which the ECF JMS provider is listening and the service
instance can be invoked.
The given URL is probably not 100% correct but hopefully provides an
idea of how it might look.
Regards,
Philipp
> -----Original Message-----
> From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Scott Lewis
> Sent: Thursday, April 23, 2009 5:09 PM
> To: Eclipse Communication Framework (ECF) developer mailing list.
> Subject: Re: [ecf-dev] handling pub-sub providers with RFC 119
>
> Hi Phillip,
>
>
> Konradi, Philipp wrote:
> > Hi Scott,
> >
> > <stuff deleted>
> > [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.
> >
>
> Agreed, option 1 doesn't support the intended usage of RFC119
> (transparent remoting)...but in fact as I understand it RFC 119 in
it's
> current form doesn't actually support this model (pub/sub) of
> remoting/remote services (because there is only the notion of
> 'endpoint'...and no notion of pubsub group).
>
> So we (ECF) will/are introducing the API described below to make it
> possible to use RFC 119 publication and proxy creation within pubsub
> groups (e.g. JMS). It is, of course, also possible for people to use
> the ECF remote services API to explicitly access proxies and the other
> forms of remote communication on IRemoteService as well.
>
> >
> > 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?
> >
>
> Sort of :). In ECF's JMS provider implementation (with TCP anyway)
the
> situation looks like this:
>
> A <--> (JMS Broker) <--> C
> |
> B
>
> The JMS Broker can be (and usually will be) run on the same
> process/host
> as B (the ECF 'group manager'). But this isn't required,
actually...as
> the JMS Broker and B can/could be run on a process separate from B.
> You
> might ask...why have B at all? Well, the answer is that B manages the
> group membership for the entire group, so that reliable group
> membership
> changes can be communicated to the others (A and C). It also can/does
> manage any authentication that occurs for access to the group.
>
> >
> >
> >> ...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.
> >
>
> Right this is my understanding.
>
> > 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.
> >
>
> Perhaps, but this isn't necessary the endpoint for all clients
> participating in the group. That is, what if A (above) publishes a
> service? What would its endpoint be in the service publication?
>
> > 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.
> >
>
> Effectively, ECF already now already has this with the
> IHostContainerFinder. It would allow the usage of intents (or any
> other
> service properties) to determine how/what container (and what it's
> configuration might be) is made available for usage as the
distribution
> provider ...and for JMS can/could determine what JMS queues/topics are
> used to expose the service (e.g. by creating JMS IContainer instances
> of
> appropriate type).
>
> A custom IHostContainerFinder can replaced/substituted by creating an
> implementation of IHostContainerFinder and registering it as a service
> (whiteboard pattern) via the service registry with a service.ranking
> that is higher than the default one (which is Integer.MIN_VALUE).
>
> Thanks,
>
> Scott
>
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
