[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Remote service with ActiveMQ JMS topic using RFC 119 transparent way.
|
Hi Roshan,
A couple of question inline below.
roshan joseph wrote:
Hi,
I am trying to use the ECF remote services with RFC 119 for testing
publish subscribe mechanism using ACtive MQ Topic.
I have a client which creates a ECF client container and publish a
message to the Active MQ Topic and a subscriber service which listens
on this topic to process this message. Both the client and service
have ECF client containers(ecf.jms.activemq.tcp.client).
I start the activeMq JMS server application to act as the ECF server
which connects to the ActiveMQ JMS broker. Though all looks fine from
outside, but I don't see my client publishing the actual message to
the topic.
How are you publishing your message to the topic? ECF's JMS
implementation(s) provides access to messaging via 'shared objects' and
the ECF shared object API. This is an api that allows named objects to
send/receive messages on the JMS topic associated with the container.
The container does multiplexing so there can be 0..many shared
objects...all sharing/using the same underlying topic.
There is example code for shared objects in
path: /cvsroot/rt
module: org.eclipse.ecf/tests/bundles/org.eclipse.ecf.tests.sharedobject
See TestMessagingSharedObject in particular.
Now...one thing you should be aware of...I'm personally working on
adding support for connection-oriented/publish-subscribe containers to
the RFC119 implementation for Galileo...and it's not yet complete. Let
me explain about what this entails.
First, as part of the meta-data about a remote service, RFC119 specifies
an 'endpoint' identifier...which basically specifies the 'host' of a
remote service. 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.
Let's assume that A wants to make available a remote service S, and that
C would like to use this service (S'). In RFC 119, A publishes (via the
discovery mechanism) meta-data about S...including A's endpoint ID. But
if C receives A's endpoint ID, it is only useful for lookup and proxy
creation if *C is already connected to B*. That is, if C is not already
connected to the group, then A's endpoint ID is (probably) not usable
directly by C (i.e. in a JMS topic, for example, the client's endpoint
ID is only usable for clients that are already connected to the group).
So, for C to use A's service, there are two options:
1) Connect C explicitly to B *before* C tries to do lookup of discovered
services (S).
2) Include in the meta-data about S information necessary for C to
connect to *B* prior to doing the lookup of A's services.
To implement option 1, it's necessary to go out of RFC119...as RFC119
doesn't address this architecture as it is now...and explicitly create
an ECF IContainer instance, and connect it to B. This is somewhat
inconvenient, in that the application programmer (you) have to
explicitly create an IContainer instance and call
IContainer.connect(B)...perhaps at application startup time.
I am currently working on adding metadata to ECF's implementation of
RFC119 discovery to support option 2. Then it will be possible to have
ECF's RFC119 implementation create an IContainer instance of the correct
type, and then connect it to B prior to doing the service lookup...and
have this all take place 'automatically' from the point of view of the
client (that is, an S' service would just appear in C's service registry.
I am working on this mechanism (option 2) right now...i.e. this week,
and expect to have it in place and tested by the end of this week. Note
that this mechanism will be general enough to deal properly with *all*
connection-oriented ECF remote services providers...e.g. JMS, XMPP,
Skype. It will be necessary for client to define how they want to
handle such discovered services via an IProxyContainerFinder (see this
interface here):
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osgi/services/distribution/package-frame.html
This will allow clients of RFC119 discovery/distribution (i.e. you) to
control the selection of the ECF remote service container to use for
responding to remote service discovery from the RFC119 discovery mechanism.
Sorry about the long posting, but I'm working/thinking through this use
case (publish and subscribe remote service providers) right now and I
thought I would take an opportunity to record some of my thoughts in
prose (and so that others can/could comment/review/critique, etc).
Scott
