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 <dwhyt...@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
>>> <sergey_zhemzhit...@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
>>
>>
>
