Skip to main content
[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 discovered and fix a subtle bug in the JMS abstract channel impl of disconnect(). See bug 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=276769
This bug was preventing the impl of the activemq remote service tests from running properly. Now they are. 

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

Back to the top