[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Re: ecf-dev Digest, Vol 45, Issue 35
|
Hi Roshan,
I've created a new test case:
org.eclipse.ecf.tests.provider.jms.activemq/org.eclipse.ecf.tests.provider.jms.activemq.remoteservice.ActiveMQServiceRegisterTest
That exercises the ActiveMQ pub-sub remote services through RFC 119.
With some bug fixes discovered and fixed along the way, the tests in
this test class now all pass/work.
Note that someone/one of us should put together some instructions for
a) Setting up ActiveMQ broker so that it can be used with this test case
(i.e. add broker topic called 'exampleTopic').
b) How to run this test case and others
I will do this asap. If you are willing/able to do this as well it
would be appreciated.
BTW, I found a bug in activemq in the process...during the running of
these tests ActiveMQ gives a spurious warning with exception trace (a
NumberFormatException). I've created the following bug on the activemq
bug tracking system for this:
https://issues.apache.org/activemq/browse/AMQ-2256
When I run the tests with activemq 5.2 I get a number of exception and
stack traces as described in
https://issues.apache.org/activemq/browse/AMQ-2256. These do not
prevent the tests from succeeding, but the console is filled up with
spurious warnings/stack traces.
Scott
roshan joseph wrote:
Hi Scott,
Could you please point me to the test case you have created to test
the pub/sub for RFC 119 using the Activemq jms provider?
I am in the process of creating a sample proto type using ActiveMQ JMS
topic for my publish/subscribe of remote services through RFC 119
transparent way, hence this would be of great help.
I did look at the http://ecf1.osuosl.org/ site but did not find any
recent changes under the activemq packages. If you are still in the
process of testing this, can you give me some direction on how to
achieve pub-sub of remote services in a group through activemq and ECF
Thank you in advance...
Regards
Roshan
Date: Wed, 22 Apr 2009 10:18:25 -0700
From: Scott Lewis <slewis@xxxxxxxxxxxxxxxxx
<http://us.mc395.mail.yahoo.com/mc/compose?to=slewis@xxxxxxxxxxxxxxxxx>>
Subject: [ecf-dev] handling pub-sub providers with RFC 119
To: "Eclipse Communication Framework (ECF) developer mailing list."
<ecf-dev@xxxxxxxxxxx
<http://us.mc395.mail.yahoo.com/mc/compose?to=ecf-dev@xxxxxxxxxxx>>
Message-ID: <49EF5161.2020405@xxxxxxxxxxxxxxxxx
<http://us.mc395.mail.yahoo.com/mc/compose?to=49EF5161.2020405@xxxxxxxxxxxxxxxxx>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Folks,
Recently, there was a message thread titled "Remote service with
ActiveMQ JMS topic using RFC 119 transparent way. " and in this
message
[0], I described some work I'm doing with the ECF RFC 119 impl to
easily
deal with these cases (i.e. option 2 in my message). 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).
ECF's IContainer can represent communication with either an endpoint
(server) *or* a pubsub group and this makes it possible to use this
capability to support peer-to-peer remote services within a pub-sub
group (e.g. a jms topic).
In order to make this capability accessible via the ECF RFC119 impl
(please add to your thoughts about giving a name to ECF's impl
here [1])
, I've added some API to our RFC119 implementation in
org.eclipse.ecf.osgi.services.distribution. What it does is
expose both
the *endpointID* and the *connectTargetID* in the discovery-published
meta-data (i.e. see this interface [2]). On the client side, this
information about the remote service (both it's endpointID and
connectTargetID) can then be used to connect to a pub/sub group at
remote service discovery time (but only when the connectTargetID is
non-null...note that this has *no* effect/relevance for client-server
distribution providers).
I've implemented the mechanism to do this, and am working on some
test
code using the ActiveMQ (JMS) provider. If others are interested in
helping test this, please let me know.
One more thing...in this previous thread [3] I brought up the
issue of
dealing with the situation where potentially many remote services
were
published/available on a lan (e.g.) and it was unclear (from
RFC119) how
this should be handled...e.g. does the announcement of some remote
service mean that another remote service doesn't get a proxy? Should
all remote service discoveries lead to proxy creation? How can an
application provide some control/scope to the proxy creation?
RFC119 doesn't really address this situation yet, but I've added two
service interface called IProxyContainerFinder, and
IHostContainerFinder
[4] that allows other bundles to register themselves as 'container
finders'...i.e. to decide which (of potentially many) remote services
providers should handle a discovered service publication. Note that
these container finders allow full customization of the remote
service
discovered meta-data (i.e. they can decide to create new IContainers,
reuse old ones, ignore some, etc). The way to replace the
DefaultProxyContainerFinder is to simply register your own
implementation of IProxyContainerFinder (or IHostContainerFinder)
as an
OSGi service...e.g:
bundleContext.registerService(IProxyContainerFinder.class.getName(),new
MyProxyContainerFinder(), null);
And when services are discovered via the discovery impl(s) your
container finder will be consulted to make the decision about what
IContainer should/will handle the request. Note that currently the
service with the highest service ranking will be selected (if
there are
many), and the DefaultProxyContainerFinder has the lowest service
ranking possible (so will only be used if *no* other container
finders
are registered in the service registry).
Note that there is also a IHostContainerFinder, to allow the same
sort
of customization for selection of the IContainers to handle the host
service publication (with the default being all existing IContainers).
Any comments welcomed. I'm working on testing/debugging this API
right
now (it already works fine with the r-OSGi and ecf generic providers
(i.e. in org.eclipse.ecf.tests.osgi.services.distribution), but I
want
to verify the correct behavior for ActiveMQ provider also, as above).
To summarize, the two API additions are:
1) IServiceEndpointDescription including both endpointID and
connectTargetID
2) Adding IProxy/HostContainerFinder API to allow for
customization/extension of the default container selection
mechanism for
both host and proxy handling.
Thanks,
Scott
[0] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02265.html
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=270652
[2]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osgi/services/discovery/IServiceEndpointDescription.html
[3] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02206.html
[4]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osgi/services/distribution/package-summary.html
------------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev