[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