You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Donald Whytock <dw...@gmail.com> on 2011/06/22 17:23:16 UTC
Re: Is it possible to export camel endpoint as OSGi service?
Hi Sergey,
I tried doing this, encapsulating and exposing what functionality I
wanted, so that my client bundles wouldn't need to be camel-aware.
Yes, it can be done, as long as you're willing to create front-ends
for whatever you want to do.
I ended up thinking it was more trouble than it was worth, especially
when I needed to deal with the actual exchange. At that point it just
seemed easier to let the bundles be camel-aware.
Don
On Wed, Jun 22, 2011 at 11:11 AM, Zhemzhitsky Sergey
<Se...@troika.ru> wrote:
> Hi there,
>
> I'm using the latest version of camel and I'm wondering whether it is possible to export a camel endpoint as OSGi service, so any non-camel-aware code can transparently use camel functionality in OSGi environment. And in that case from the OSGi service consumer's point of view, camel context is a simple OSGi service.
>
> Best Regards,
> Sergey Zhemzhitsky
>
>
> _______________________________________________________
>
> The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
> If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>
>
RE: Is it possible to export camel endpoint as OSGi service?
Posted by Zhemzhitsky Sergey <Se...@troika.ru>.
I like the idea with small messaging core, but I think such a functionality is not very necessary.
It seems that additional level of abstraction with my own interfaces is more preferred for now.
Best Regards,
Sergey Zhemzhitsky
-----Original Message-----
From: Christian Schneider [mailto:chris@die-schneider.net]
Sent: Wednesday, June 22, 2011 7:33 PM
To: users@camel.apache.org
Subject: Re: Is it possible to export camel endpoint as OSGi service?
Hi Sergey, Don,
I just wanted to write a similar mail like Don. Reading his comments I think what we could improve is to offer a small messaging core for camel. For example containing Exchange, Message and ProducerTemplate.
That would
allow to make this "camel awareness really small". What do you think?
Christian
Am 22.06.2011 17:23, schrieb Donald Whytock:
> Hi Sergey,
>
> I tried doing this, encapsulating and exposing what functionality I
> wanted, so that my client bundles wouldn't need to be camel-aware.
> Yes, it can be done, as long as you're willing to create front-ends
> for whatever you want to do.
>
> I ended up thinking it was more trouble than it was worth, especially
> when I needed to deal with the actual exchange. At that point it just
> seemed easier to let the bundles be camel-aware.
>
> Don
>
> On Wed, Jun 22, 2011 at 11:11 AM, Zhemzhitsky Sergey
> <Se...@troika.ru> wrote:
>> Hi there,
>>
>> I'm using the latest version of camel and I'm wondering whether it is possible to export a camel endpoint as OSGi service, so any non-camel-aware code can transparently use camel functionality in OSGi environment. And in that case from the OSGi service consumer's point of view, camel context is a simple OSGi service.
>>
>> Best Regards,
>> Sergey Zhemzhitsky
>>
>>
>> _______________________________________________________
>>
>> The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
>> If you need assistance please contact our Contact Center (+7495) 258
>> 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>>
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________________
The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
Re: Is it possible to export camel endpoint as OSGi service?
Posted by Donald Whytock <dw...@gmail.com>.
How about something like this?
package org.apache.camel.facade;
public class Facade
{
public Services getServices(String endpoint);
}
public interface Services
{
public BlockingQueue<Message> getReader();
public Writer getWriter();
public void addListener(Processor processor);
public void removeListener(Processor processor);
}
public interface Message
{
public Properties getProperties();
public Properties getHeaders();
public Properties setProperties(Properties properties);
public void setHeaders(Properties headers);
public String getText();
public void setText(String text);
}
public interface Writer
{
public void send(Message message);
public void send(String text);
}
public interface Processor
{
public void process(Message message);
}
I'm aiming here for something that can be contained in a single .jar
and work as either a bundle or not. A standalone user would
instantiate Facade, which would fetch a CamelContext; an OSGi user
would get the Facade service, which would use a singleton
OsgiDefaultCamelContext.
The localized Message would contain both the Exchange properties and
the Message headers. Both of those could be ignored if the user is
simply reading text from or writing text to a queue.
The only reason I'm including a Processor interface is for
self-containment. But perhaps this is going too far, since camel-core
would necessarily be present?
Don
On Wed, Jun 22, 2011 at 11:58 AM, Donald Whytock <dw...@gmail.com> wrote:
> Maybe a service object that contains a BlockingQueue to read from
> and/or a method to write with. Creating it could be done by passing a
> URL to a service, or set up URLs and keys in the configuration so that
> client bundles track the service by key.
>
> Alternately, rather than a BlockingQueue, a service that accepted
> event listeners (read: Processes) which would be called for each
> incoming message.
>
> This can be used to make the application non-camel-aware, but it would
> then still need to be camel-facade-aware. Should the facade therefore
> be part of Camel, or a sort of subproject?
>
> My chatterbot project sort of tries to do this. One writes "parsers"
> for it that can respond to incoming messages without necessarily
> knowing where the message is coming from. It's probably more complex
> than what we're talking about, though; it's made for a multiuser
> environment, and uses internal user IDs.
>
> Don
>
> On Wed, Jun 22, 2011 at 11:32 AM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> Hi Sergey, Don,
>>
>> I just wanted to write a similar mail like Don. Reading his comments I think
>> what we could improve is to offer a small messaging core for camel. For
>> example containing Exchange, Message and ProducerTemplate. That would
>> allow to make this "camel awareness really small". What do you think?
>>
>> Christian
>>
>>
>> Am 22.06.2011 17:23, schrieb Donald Whytock:
>>>
>>> Hi Sergey,
>>>
>>> I tried doing this, encapsulating and exposing what functionality I
>>> wanted, so that my client bundles wouldn't need to be camel-aware.
>>> Yes, it can be done, as long as you're willing to create front-ends
>>> for whatever you want to do.
>>>
>>> I ended up thinking it was more trouble than it was worth, especially
>>> when I needed to deal with the actual exchange. At that point it just
>>> seemed easier to let the bundles be camel-aware.
>>>
>>> Don
>>>
>>> On Wed, Jun 22, 2011 at 11:11 AM, Zhemzhitsky Sergey
>>> <Se...@troika.ru> wrote:
>>>>
>>>> Hi there,
>>>>
>>>> I'm using the latest version of camel and I'm wondering whether it is
>>>> possible to export a camel endpoint as OSGi service, so any non-camel-aware
>>>> code can transparently use camel functionality in OSGi environment. And in
>>>> that case from the OSGi service consumer's point of view, camel context is a
>>>> simple OSGi service.
>>>>
>>>> Best Regards,
>>>> Sergey Zhemzhitsky
>>>>
>>>>
>>>> _______________________________________________________
>>>>
>>>> The information contained in this message may be privileged and conf
>>>> idential and protected from disclosure. If you are not the original intended
>>>> recipient, you are hereby notified that any review, retransmission,
>>>> dissemination, or other use of, or taking of any action in reliance upon,
>>>> this information is prohibited. If you have received this communication in
>>>> error, please notify the sender immediately by replying to this message and
>>>> delete it from your computer. Thank you for your cooperation. Troika Dialog,
>>>> Russia.
>>>> If you need assistance please contact our Contact Center (+7495) 258
>>>> 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>>>>
>>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
Re: Is it possible to export camel endpoint as OSGi service?
Posted by Donald Whytock <dw...@gmail.com>.
Maybe a service object that contains a BlockingQueue to read from
and/or a method to write with. Creating it could be done by passing a
URL to a service, or set up URLs and keys in the configuration so that
client bundles track the service by key.
Alternately, rather than a BlockingQueue, a service that accepted
event listeners (read: Processes) which would be called for each
incoming message.
This can be used to make the application non-camel-aware, but it would
then still need to be camel-facade-aware. Should the facade therefore
be part of Camel, or a sort of subproject?
My chatterbot project sort of tries to do this. One writes "parsers"
for it that can respond to incoming messages without necessarily
knowing where the message is coming from. It's probably more complex
than what we're talking about, though; it's made for a multiuser
environment, and uses internal user IDs.
Don
On Wed, Jun 22, 2011 at 11:32 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Hi Sergey, Don,
>
> I just wanted to write a similar mail like Don. Reading his comments I think
> what we could improve is to offer a small messaging core for camel. For
> example containing Exchange, Message and ProducerTemplate. That would
> allow to make this "camel awareness really small". What do you think?
>
> Christian
>
>
> Am 22.06.2011 17:23, schrieb Donald Whytock:
>>
>> Hi Sergey,
>>
>> I tried doing this, encapsulating and exposing what functionality I
>> wanted, so that my client bundles wouldn't need to be camel-aware.
>> Yes, it can be done, as long as you're willing to create front-ends
>> for whatever you want to do.
>>
>> I ended up thinking it was more trouble than it was worth, especially
>> when I needed to deal with the actual exchange. At that point it just
>> seemed easier to let the bundles be camel-aware.
>>
>> Don
>>
>> On Wed, Jun 22, 2011 at 11:11 AM, Zhemzhitsky Sergey
>> <Se...@troika.ru> wrote:
>>>
>>> Hi there,
>>>
>>> I'm using the latest version of camel and I'm wondering whether it is
>>> possible to export a camel endpoint as OSGi service, so any non-camel-aware
>>> code can transparently use camel functionality in OSGi environment. And in
>>> that case from the OSGi service consumer's point of view, camel context is a
>>> simple OSGi service.
>>>
>>> Best Regards,
>>> Sergey Zhemzhitsky
>>>
>>>
>>> _______________________________________________________
>>>
>>> The information contained in this message may be privileged and conf
>>> idential and protected from disclosure. If you are not the original intended
>>> recipient, you are hereby notified that any review, retransmission,
>>> dissemination, or other use of, or taking of any action in reliance upon,
>>> this information is prohibited. If you have received this communication in
>>> error, please notify the sender immediately by replying to this message and
>>> delete it from your computer. Thank you for your cooperation. Troika Dialog,
>>> Russia.
>>> If you need assistance please contact our Contact Center (+7495) 258
>>> 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>>>
>>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Is it possible to export camel endpoint as OSGi service?
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Sergey, Don,
I just wanted to write a similar mail like Don. Reading his comments I
think what we could improve is to offer a small messaging core for
camel. For example containing Exchange, Message and ProducerTemplate.
That would
allow to make this "camel awareness really small". What do you think?
Christian
Am 22.06.2011 17:23, schrieb Donald Whytock:
> Hi Sergey,
>
> I tried doing this, encapsulating and exposing what functionality I
> wanted, so that my client bundles wouldn't need to be camel-aware.
> Yes, it can be done, as long as you're willing to create front-ends
> for whatever you want to do.
>
> I ended up thinking it was more trouble than it was worth, especially
> when I needed to deal with the actual exchange. At that point it just
> seemed easier to let the bundles be camel-aware.
>
> Don
>
> On Wed, Jun 22, 2011 at 11:11 AM, Zhemzhitsky Sergey
> <Se...@troika.ru> wrote:
>> Hi there,
>>
>> I'm using the latest version of camel and I'm wondering whether it is possible to export a camel endpoint as OSGi service, so any non-camel-aware code can transparently use camel functionality in OSGi environment. And in that case from the OSGi service consumer's point of view, camel context is a simple OSGi service.
>>
>> Best Regards,
>> Sergey Zhemzhitsky
>>
>>
>> _______________________________________________________
>>
>> The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia.
>> If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp
>>
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com