Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Re: pub-sub ActiveMQ remote services through RFC 119

Hi Roshan,

roshan joseph wrote:
Hi Scott,
Thank you for the detail response and it was very helpful. I still have some questions on the test case. I was thinking that, to test the activemq pub-sub remote services through RFC 119 you need to have 4 processes, they being 1. The activemq broker which creates the topic for pub-sub (for e.g: tcp://localhost:61616/exampleTopic)

2. An ActiveMQJMSServerContainer (ActiveMQ Manager) which has the id ‘ecf.jms.activemq.tcp.manager’ and manages the pub-sub group.

3. An ActiveMQJMSClientContainer (ActiveMQ Client) which has the id ‘ecf.jms.activemq.tcp.client’ that acts as the publisher of remote services

4. Another ActiveMQJMSClientContainer (ActiveMQ Client) which also has the container id like 3 above but who is the consumer of this service. Is my thinking wrong here, or can this steps 2,3 and 4 executed in a single process?


Yes, that's true. I haven't yet been able to create a new test case with the above scenario. Since you have it clearly in mind, perhaps you could create such a test case? If you would like/able to do this, please open a bug describing this scenario and we'll coordinate on the bug.


I was able to execute the test case under org.eclipse.ecf.tests.remoteservice.AbstractConcatHostApplication and the AbstractConcatConsumerTestCase both the r-osgi and the generic container tests. For the pub-sub using activemq provider won't the case be a bit different, as here both the publisher and consumer are clients itself of Activemq manager.


Yes the scenario is a little bit different. I just haven't been able to get to creating this new test case yet (as you probably have noticed, working on documentation, examples, testing, and support via the mailing list and newsgroups...as well as giving the OSGi/RFC119 folks a hard time for changing the spec on us...have all been on my mind recently :).


I will be more than happy to contribute from my side any tests with the respect to this topic. If you feel I am way off mark with regard to how pub-sub mechanism works in ecf, pls do correct me


No afaict you are correct. If you can/could help out with test cases for this exact scenario it would be most appreciated. If not I will get to it, but it won't/can't be immediately.

Scott

Regards
Roshan
--- On *Mon, 5/18/09, ecf-dev-request@xxxxxxxxxxx /<ecf-dev-request@xxxxxxxxxxx>/* wrote:


    Date: Mon, 18 May 2009 10:47:57 -0700
    From: Scott Lewis <slewis@xxxxxxxxxxxxxxxxx
    <http://us.mc395.mail.yahoo.com/mc/compose?to=slewis@xxxxxxxxxxxxxxxxx>>
    Subject: Re: [ecf-dev] Re: ecf-dev Digest, Vol 45, Issue 35
    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: <4A119F4D.7040107@xxxxxxxxxxxxxxxxx
    <http://us.mc395.mail.yahoo.com/mc/compose?to=4A119F4D.7040107@xxxxxxxxxxxxxxxxx>>
    Content-Type: text/plain; charset=ISO-8859-1; format=flowed

    Hi Roshan,

    I have not yet completed the test case for activemq, as I have been
    modifying the existing test cases (in
    org.eclipse.ecf.remoteservices) so
    that provider-specific testing of remoteservices will be easier (both
    for activemq provider and for other current/future providers).  One
    complicating factor is that testing using normal junit testing
    (i.e. all
    tests in a single process) doesn't really test thing with remoting
    properly...and so I've been modifying the tests to have an abstract
    service host application (separate process)...i.e. via these classes:

    org.eclipse.ecf.tests.remoteservice.AbstractConcatHostApplication

    And a tests with an abstract service consumer:

    org.eclipse.ecf.tests.remoteservice.AbstractConcatConsumerTestCase

    There are also tests for the RFC 119 impl that are in
    org.eclipse.ecf.tests.osgi.services.distribution.  In particular,
    this
    abstract test class

    org.eclipse.ecf.tests.osgi.services.distribution.AbstractServiceRegisterTest

    My intention is to create activemq-specific test cases, based upon
    these
    abstract tests...both for ECF remote services API and for the RFC119
    impl (which is based upon the ECF remote services API).

    So, in any case, I will do what I can to get these activemq
    provider-based tests in place this week.  If you (Roshan) are
    able/willing to help with this, please open a bug/enhancement request
    and consider attaching code/code fragments of tests that you are
    able/willing to contribute.

    Note the mechanism here (for pub-sub containers) that remains to be
    tested is implemented in

    org.eclipse.ecf.osgi.services.distribution.DefaultProxyContainerFinder

    This is a default proxy container finder...which currently has
    logic to
    *connect* a container (to the pubsub group) if the
    endpointDescription.getConnectTargetID() returns a non-null value
    (see
    line 85 in DefaultProxyContainerFinder).  For pubsub containers (e.g.
    activemq) this getConnectTargetID() should/will be non-null and so
    consumers will be connected to the identified pub/sub group before
    proxy
    lookup occurs.

    Note also that if you wish, you may define your own logic for
    IProxyContainerFinder (and IHostContainerFinder) and implement as
    desired (i.e. you don't have to use the DefaultProxyContainerFinder's
    logic at all).

    So, in any event...I'll be working on test code for this in the very
    near future.

    Thanks,

    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>
> <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>
> <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>
> <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
    <http://us.mc395.mail.yahoo.com/mc/compose?to=ecf-dev@xxxxxxxxxxx>
    > https://dev.eclipse.org/mailman/listinfo/ecf-dev
>


    ------------------------------

    _______________________________________________
    ecf-dev mailing list
    ecf-dev@xxxxxxxxxxx
    <http://us.mc395.mail.yahoo.com/mc/compose?to=ecf-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/ecf-dev


    End of ecf-dev Digest, Vol 46, Issue 15
    ***************************************


------------------------------------------------------------------------

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev



Back to the top