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 Philip,

Konradi, Philipp wrote:
Hi Scott,

I'm fine with using more than one property to describe the service
location (if it makes sense for certain protocols e.g. JMS).
My main message is that ServicePublication.PROP_KEY_ENDPOINT_LOCATION
property (you called it "endpointID") is the URI describing where to
reach the service or in other words where to connect to and send
invocation messages in order to call the service e.g.
http://myserver.de/myWebService, jms:activemq::B:1099/myServiceTopic or
{tcp://mybroker:1099 + additional property like topicName =
myServiceTopic}. So this property has actually already the meaning of the new introduced "connectTargetID" property.

Only if the provider has defined the String (or opaque URI) to contain the pub-sub group member's address (e.g. jms:activemq::B:1099/myServiceTopic). Some providers won't actually want to do/allow this (expose the endpoint ID of group member) I suspect, so I don't actually think it's a good idea to conflate the two addresses into one endpoint ID (i.e. for the group e.g. jms:activemq:tcp://mybroker:1099/topic and for the B endpoint within that group: jms:activemq:tcp:B:1099/topic).

In any event, I know that the endpointID *can* contain any addressing system desired (since it's ultimately a String/opaque URI), but I believe it's simpler to directly support pub-sub groups with a separation between groupIDs and group member IDs.

To earth my points to concrete class and methods:

a) org.eclipse.ecf.osgi.services.discovery.IServiceEndpointDescription:
the already existing and inherited method URI getLocation(), which
returns the value of ServicePublication.PROP_KEY_ENDPOINT_LOCATION,
is semantic-wise the same as the new getConnectTargetID() method
returning org.eclipse.ecf.core.identity.ID

They aren't semantically identical, because IDs have the notion of a Namespace. URIs do not. The namespace is critical for determining (for example), which distribution providers are 'appropriate' for a given endpointID.

If it's just the more convenient return type which is desirable then we
should have at least similar names: e.g. getLocationAsID();

A reasonable suggestion, but I'm not sure whether 'endpoint' or 'location' is 'better'. The RFC119 spec should have just one of these ...not both...but that's my opinion (and not shared by the spec authors apparently).


b) org.eclipse.ecf.osgi.services.discovery.IServiceEndpointDescription:
the already existing and inherited method String getEndpointID(), which
returns the value of ServicePublication.PROP_KEY_ENDPOINT_ID,
seems to have a different meaning then the new and similar sounding
getECFEndpointID() method returning an ID.
The first one is just a unique id (#123456) identifying the
stub/endpoint exposing a service. That's I think something similar to
ECF's IServiceID which inherits from ID but gives the ID the meaning to
identify a service instance and not a service container or host. If I
understood correctly the other method getECFEndpointID() is returning
the id of the host machine where the service instance is actually
executed.
To prevent confusion here using another name would make sense e.g.
getServiceHostID().

But maybe I've missed something?! Please let me know.

The getECFEndpointID is the ID of the container that is 'responsible' for the published service...not the ID of the service itself.

The IServiceID is the discovery mechanism's identifier for the service. In order to keep a separation between the discovery and distribution mechanism these are not necessarily the same (because the IServiceID contains other information associated with the discovery mechanism only...e.g. scope, discovery protocol, etc).

So the ID returned from getECFEndpointID() is most closely analogous to the String returned from RFC 119's String getEndpointID()...thus the current naming (which I'm open to changing, if there is a more/better/improved idea).

As an aside, I think (as above) that the RFC119 conflation of endpointID and location is confusing. Neither String nor URI are great (IMHO) for describing service addressing...at least partially because there is no way to define new addressing types (i.e. String and URI are both final). String is not very satisfactory because it has no structure at all, and URI has a structure that is just fine for *resource* addressing, but is limiting when it comes to other kinds of addressing (e.g. jms:activemq::B:1099/myServiceTopic or myprotoco:12345678 etc)...as for that, you basically fall back on the URI opaque 'mode' (protocol followed by protocol-specific String).

In any event, I'm open to renaming getECFEndpointID, but am more inclined to keep it <something>EndpointID ...e.g. getAsEndpointID() than to call it <something>AsLocationID...let me know what you think.

Scott


Regards, Philipp



-----Original Message-----
From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Scott Lewis
Sent: Tuesday, April 28, 2009 6:12 PM
To: Eclipse Communication Framework (ECF) developer mailing list.
Subject: Re: [ecf-dev] handling pub-sub providers with RFC 119

Hi Philipp,

Konradi, Philipp wrote:
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.

Yes, I agree this is possible (i.e. an endpoint identifier that
identifies both the pub-sub group *and* the endpoint within that
group).

But I would say it's sort of clumsy...as such an endpointID can become
quite complex...and all this is in an opaque String (or an opaque URI
:).  IMHO the ECF ID notion works rather nicely for this...because

a) IDs can have namespaces...so it's possible to use that namespace to
(e.g.) select a relevant provider (rather than using
jms:activemq:ecf...etc).
b) IDs only need to be parsed once (whereas Strings or even opaque
URIs
potentially many times).
c) Having two IDs...one to identify the pub sub group to connect to,
and
the other to identify the endpoint within the group...seems more
natural
to me than to put them into an opaque and complex ID as above.

But in any event, since we (ECF) now have both, we can now accomodate
providers that such addressing either way.

Scott

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

_______________________________________________
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



Back to the top