Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] Re: Remote service with ActiveMQ JMS topic using RFC 119
Hi Scott,
 Thank you for responding to my mail and I am really sorry for a late response.
Regarding your question on how am I publishing the message, this is the code I use to make a connection from the publisher
 
//JMS specific connectivity for ActiveMQ using ECF
 private static final String CLIENT_CONTAINER_NAME = "ecf.jms.activemq.tcp.client";
 private static final String TARGET_NAME = "tcp://localhost:61616/exampleTopic";
 container = getContainerFactory().createContainer(CLIENT_CONTAINER_NAME);
 
 // Create target ID JMS ActiveMQ call
 String target = TARGET_NAME;
  
 ID targetID = createTargetID(container,target);
 
 container.connect(targetID, null);
 Thread.sleep(3000);
 
I did not use the shared object api like you mentioned, but want to try out the RFC 119 way. I tried a remote service call with R-osgi and found it working and hence want to try the publish subscribe using JMS. I was not sure whether this is the right approach.
 
From your mail what I could gather is, I need to make a connection to the ActiveMQ server than directly to the JMS broker. Please do correct me if I am wrong.
 
If you have already included in ECF implementation, the RFC 119 discovery to support the option 2, like you mentioned in your mail, I would be very much interested to try it out.
 
Thank you once again for the detail explanation, I really appreciate your help and support.
 
Regards
Roshan


--- On Tue, 4/21/09, ecf-dev-request@xxxxxxxxxxx <ecf-dev-request@xxxxxxxxxxx> wrote:

Date: Tue, 21 Apr 2009 09:35:51 -0700
From: Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>
Subject: Re: [ecf-dev] Remote service with ActiveMQ JMS topic using
    RFC 119    transparent way.
To: "Eclipse Communication Framework (ECF) developer mailing list."
    <ecf-dev@xxxxxxxxxxx>
Message-ID: <49EDF5E7.3090205@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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




Back to the top