camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Zhemzhitsky <szh.s...@gmail.com>
Subject Re: Camel OSGi services component
Date Sun, 24 Jun 2012 12:14:29 GMT
Hi guys,

I like the idea with URIs like that "direct-vm:/endpoint/topicName/subTopicName/subSubTopicName?params".
So as Guillaume said the recipient list can be retrieved using something like xpath or even
ant-style expressions

recipientList(directVm("/endpoint/*/subTopicName/subSubTopicName")) - topic can be anything,
but subtopics should match
recipientList(directVm("/endpoint/**")) - topic and subtopics can be anything
recipientList(directVm("/endpoint/topicName/**")) - topic should match, but subtopics should
not
recipientList(directVm("/endpoint/topicName/*/subSubTopicName")) - the second subtopic should
match, the first one - should not.

I also suppose that this approach is less error prone when multiple direct-vm consumers are
involved.

Regards,
Sergey

> Yes, or something even more flexible such as
>   to("direct-vm:/parent/child")

> and for the expression, a simple xpath like:
>   from("foo:bar").recipientList(directVm("/parent/*"))
> or
>   /parent//*

> Just a thought though, not sure if that's really needed.

> On Sat, Jun 23, 2012 at 9:18 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky <szh.subs@gmail.com> wrote:
>>> Hello Guillaume,
>>>
>>> I suppose static method to retrieve consumers that can be filtered by a custom
>>> expression will be quite enough.
>>>
>>
>> Yeah that may be a good idea and fairly easy to implement.
>>
>> The regular direct component could in theory also support this, but I
>> guess direct-vm makes the most sense only, as its cross CamelContext
>> communication.
>>
>> The filter expression could also be defined in the uri, if we want to
>> consider that, though the foo name would then become a dummy? Or would
>> it be to confusing if the name is a filter itself
>>
>> .to("direct-vm:dummy?filter=someFilterStuffHere")
>>
>> .to("direct-vm:someFilterStuffHere")
>>
>>
>>
>>
>>> Regards,
>>> Sergey
>>>
>>>
>>>> On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky <szh.subs@gmail.com>
wrote:
>>>>> Hello, guys,
>>>>>
>>>>> I agree that if the camel-core could be enhanced to achieve easy cross-context
>>>>> communication in the single JVM it would be fine.
>>>
>>>> Claus committed the direct-vm component recently which is part of 2.10:
>>>>    http://camel.apache.org/direct-vm.html
>>>
>>>>> In that case I would not tire the core to OSGi anyhow to be really environment-independent.
>>>>> I suppose that camel context could be published into the JNDI to be retrieved
at some time
>>>>> lately to discover consuming endpoints. Thus we can achieve the similar
behavior in different
>>>>> environments and
>>>>>
>>>>> from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>>>>
>>>>> would become
>>>>>
>>>>> from("foo:bar").recipientList(vm("myfilter"))
>>>>>
>>>
>>>> Atm, the direct-vm queues are not really accessible afaik, so we may
>>>> need to enhance the direct-vm slightly to allow retrieving the set of
>>>> registered consumers (adding a static getRegisteredConsumers on the
>>>> component should be sufficient).  Those are mapped by the path
>>>> component of the consumer uris, so it already provides some kinda of
>>>> tree based structure.  If that's sufficient, we would just need a
>>>> simple expression that would filter them based on some regular
>>>> expression maybe.
>>>
>>>>>
>>>>> Regards,
>>>>> Sergey
>>>>>
>>>>>
>>>>>
>>>>>> Agree, I think that enhancing the existing could achieve this.
>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>
>>>>>> On 06/21/2012 08:51 AM, Guillaume Nodet wrote:
>>>>>>> That's really my main goal.  If we fit into what already exists
more,
>>>>>>> we'll be able to better leverage everything.
>>>>>>>
>>>>>>> On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider
>>>>>>> <chris@die-schneider.net>  wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>> I like that aproach. It would make the OSGi services component
a lot
>>>>>>>> simpler.
>>>>>>>>
>>>>>>>>
>>>>>>>> from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>>>>>>>
>>>>>>>> I guess we can use a similar aproach to achieve load balancing.
Not sure if
>>>>>>>> the example below already would work but I am sure we could
make it work
>>>>>>>> this way or similar:
>>>>>>>>
>>>>>>>> from("foo:bar").loadbalance().roundRobin().recepientList(osgiServices("myldapfilter"))
>>>>>>>>
>>>>>>>>
>>>>>>>> Christian
>>>>>>>>
>>>>>>>> Am 21.06.2012 08:27, schrieb Guillaume Nodet:
>>>>>>>>
>>>>>>>>> Yeah, and I agree leveraging OSGi services for that is
a good idea.
>>>>>>>>> That's not really what I'm concerned about.
>>>>>>>>>
>>>>>>>>> The goal is to have a way to multicast a message to a
set of endpoint
>>>>>>>>> which will be discovered at runtime, and that's not really
OSGi
>>>>>>>>> specific (though the fact that OSGi has a service registry
make that
>>>>>>>>> use case very relevant).
>>>>>>>>> I'd like to reuse what camel-core provides for that instead
of going
>>>>>>>>> around and implementing a brand new component.
>>>>>>>>> The dynamic recipient list works with an Expression which
returns a
>>>>>>>>> list of endpoints (either Endpoint or string uris), so
why not writing
>>>>>>>>> such an expression ?  This expression could easily use
a
>>>>>>>>> ServiceTracker internally to track changes on services
and the
>>>>>>>>> expression itself could be an osgi filter...
>>>>>>>>>
>>>>>>>>>    from("foo:bar").recipientList(osgiServices("myldapfilter"))
>>>>>>>>>
>>>>>>>>> We could even maybe make use of the CamelContext internal
registry
>>>>>>>>> which can do some type of discovery (though the osgi
implementation is
>>>>>>>>> lacking a lot of stuff).
>>>>>>>>> A simple one would at least be some kind of regular expression
that
>>>>>>>>> would match some endpoints.  We may need something slightly
more
>>>>>>>>> specific for vm:// and direct-vm:// which can be used
for
>>>>>>>>> cross-camelContext exchanges.
>>>>>>>>>
>>>>>>>>> And sorry if I seem a bit reluctant, I'm just trying
to make things
>>>>>>>>> fit more cleanly in camel, and improve camel core where
it needs
>>>>>>>>> rather than implementing a new component.  It just seems
that your
>>>>>>>>> requirements are not really osgi specific and could be
made slightly
>>>>>>>>> mode generic.
>>>>>>>>>
>>>>>>>>> On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitsky<szh.subs@gmail.com>
>>>>>>>>>   wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Guillaume,
>>>>>>>>>>
>>>>>>>>>> Of course if there is more convenient way to communicate
between
>>>>>>>>>> bundles there is no need in the component. On the
moment of development
>>>>>>>>>> of this component there were multiple ways to do
that, for instance:
>>>>>>>>>>
>>>>>>>>>> 1. jms component which is rather heavyweight to do
inter-bundle
>>>>>>>>>> communication in the same jvm.
>>>>>>>>>> 2. vm component which is asynchronous and does not
support transactions
>>>>>>>>>> 3. nmr component which can be used in synchronous
mode, but does not
>>>>>>>>>> support pub-sub, although it
>>>>>>>>>>    does not prevent user from registering multiple
consuming endpoints
>>>>>>>>>> with the same name, so the
>>>>>>>>>>    messages are sent only to the first registered
nmr-consumer.
>>>>>>>>>>
>>>>>>>>>> The new direct-vm component solves the issue with
transactions (like
>>>>>>>>>> synchronous nmr does) but it does not
>>>>>>>>>> support pub-sub too.
>>>>>>>>>>
>>>>>>>>>> To use a dynamic recipient list it's necessary to
have some kind of
>>>>>>>>>> custom code that will resolve
>>>>>>>>>> addresses of recipients at runtime. In such a case
syncronous nmr can be
>>>>>>>>>> used as well. The benefit of
>>>>>>>>>> OSGi services is that this is a standard functionality
of OSGi runtime
>>>>>>>>>> and even OSGi api predisposed
>>>>>>>>>> to work with an array of them. Furthermore you will
get all the benefits
>>>>>>>>>> of OSGi services, i.e.
>>>>>>>>>> dynamism, priorities, etc.
>>>>>>>>>>
>>>>>>>>>> It would be nice if direct-vm allowed to configure
pub-sub with all the
>>>>>>>>>> options of multicast processor.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Sergey
>>>>>>>>>>
>>>>>>>>>>> I'm a bit skeptic about this component.
>>>>>>>>>>> It seems at first glance that if conflates a
few things like osgi
>>>>>>>>>>> service access, multicast, etc...
>>>>>>>>>>> If the goal is to do inter-bundle communication,
the new component
>>>>>>>>>>> coming from CAMEL-5370 should already do that
and I don't really see
>>>>>>>>>>> the need for the component.
>>>>>>>>>>> For the multicast, using a dynamic recipient
list coupled with
>>>>>>>>>>> direct-vm should work.
>>>>>>>>>>> On Tue, May 22, 2012 at 7:57 PM,<szh.subs@gmail.com>
   wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi gurus,
>>>>>>>>>>>>
>>>>>>>>>>>> Recently  I've  published  camel  component
that uses OSGi services to
>>>>>>>>>>>> communicate between endpoints in different
bundles.
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the link: https://github.com/szhem/camel-osgi
>>>>>>>>>>>> I've already raised JIRA issue -
>>>>>>>>>>>> https://issues.apache.org/jira/browse/CAMEL-5292
>>>>>>>>>>>>
>>>>>>>>>>>> So I'd like to have some feedback if it seems
to be useful.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Sergey
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Christian Schneider
>>>>>>>> http://www.liquid-reality.de
>>>>>>>>
>>>>>>>> Open Source Architect
>>>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen


Mime
View raw message