You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Ge@@ru" <ge...@gmail.com> on 2011/11/28 15:44:26 UTC
[PROPOSAL] OSGI Exchange
Hi at all,
I write this email to ask on ml if my idea could be valid to the future
of smx/camel.
JBI will be soon deprecated like NMR, so why doesn't use OSGI directly
to communicate between bundles and components with a common API?
In my head i think to a framework like MessageExchange or Camel Exchange
where:
- there is an interface OsgiExchange with classic methods: getProperty,
setProperty, getIn/getOut (return OsgiMessage interface)
- a common communication interface OsgiExchangeService that expone a
method:
public OsgiExchange callService (String serviceName,
OsgiExchange exchange,
boolean useCopy)
throws Exception;
Every bundles that expose a osgi service use this interface and set osgi
properties to discriminate osgi service between different bundles.
Obviously, client of the osgi service use reference with "filter"
argument to call a particular service.
On first step this solution can be use directly on camel (without have a
from("osgi:/xxx) ) with a simple object that implement
OsgiExchangeService, convert OsgiMessage to Exchange and send exchange
to a predefined route through a simple ProducerTemplate class.
Same solution can be used with cxf to call osgi service like for
MessageExchange through callService method and OsgiExchange.
What do people think about this?
Regards,
Geaaru
Re: [PROPOSAL] OSGI Exchange
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
Cellar trunk already provide a DOSGi implementation.
It works exactly as other DOSGi solutions (just adding a property on the
service).
Regards
JB
On 11/29/2011 02:06 AM, Johan Edstrom wrote:
> Fuse fabric already does this, I think cellar will/does as well or cxf dosgi will.
> Other than that implementing it yourself would be really simple.
>
> /je
>
> On Nov 28, 2011, at 7:44 AM, Ge@@ru wrote:
>
>> Hi at all,
>>
>> I write this email to ask on ml if my idea could be valid to the future
>> of smx/camel.
>>
>> JBI will be soon deprecated like NMR, so why doesn't use OSGI directly
>> to communicate between bundles and components with a common API?
>>
>> In my head i think to a framework like MessageExchange or Camel Exchange
>> where:
>> - there is an interface OsgiExchange with classic methods: getProperty,
>> setProperty, getIn/getOut (return OsgiMessage interface)
>> - a common communication interface OsgiExchangeService that expone a
>> method:
>>
>> public OsgiExchange callService (String serviceName,
>> OsgiExchange exchange,
>> boolean useCopy)
>> throws Exception;
>>
>> Every bundles that expose a osgi service use this interface and set osgi
>> properties to discriminate osgi service between different bundles.
>> Obviously, client of the osgi service use reference with "filter"
>> argument to call a particular service.
>>
>> On first step this solution can be use directly on camel (without have a
>> from("osgi:/xxx) ) with a simple object that implement
>> OsgiExchangeService, convert OsgiMessage to Exchange and send exchange
>> to a predefined route through a simple ProducerTemplate class.
>>
>> Same solution can be used with cxf to call osgi service like for
>> MessageExchange through callService method and OsgiExchange.
>>
>> What do people think about this?
>>
>> Regards,
>>
>> Geaaru
>>
>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] OSGI Exchange
Posted by Johan Edstrom <se...@gmail.com>.
Fuse fabric already does this, I think cellar will/does as well or cxf dosgi will.
Other than that implementing it yourself would be really simple.
/je
On Nov 28, 2011, at 7:44 AM, Ge@@ru wrote:
> Hi at all,
>
> I write this email to ask on ml if my idea could be valid to the future
> of smx/camel.
>
> JBI will be soon deprecated like NMR, so why doesn't use OSGI directly
> to communicate between bundles and components with a common API?
>
> In my head i think to a framework like MessageExchange or Camel Exchange
> where:
> - there is an interface OsgiExchange with classic methods: getProperty,
> setProperty, getIn/getOut (return OsgiMessage interface)
> - a common communication interface OsgiExchangeService that expone a
> method:
>
> public OsgiExchange callService (String serviceName,
> OsgiExchange exchange,
> boolean useCopy)
> throws Exception;
>
> Every bundles that expose a osgi service use this interface and set osgi
> properties to discriminate osgi service between different bundles.
> Obviously, client of the osgi service use reference with "filter"
> argument to call a particular service.
>
> On first step this solution can be use directly on camel (without have a
> from("osgi:/xxx) ) with a simple object that implement
> OsgiExchangeService, convert OsgiMessage to Exchange and send exchange
> to a predefined route through a simple ProducerTemplate class.
>
> Same solution can be used with cxf to call osgi service like for
> MessageExchange through callService method and OsgiExchange.
>
> What do people think about this?
>
> Regards,
>
> Geaaru
>
>
>