JBI or OSGI packaging

["Mathew, Reju" <Re...@state.ma.us>]

Hi,
 
I am a newbe to the ServiceMix. When developing new applications (using
servicemix - camel) deployed in ServiceMIX 4, which is the preferred way
of packaging - JBI or OSGI ? Do not envisage registering at / using
(OSGI) Service Registry and either way packaged seems deployable into
the osgi container of servicemix (using osgi install) in the same way.
So then which way is recommended / forward looking approach ?
 
thanks,
Reju
 

Re: JBI or OSGI packaging

[Vincent GIRARDREYDET <vi...@thalesgroup.com>]

I'de also add that we the set of tooling available for SMX4 (especially 
the EndpointExporter bean, but also Spring DM's tools), it's really easy 
to integrate with OSGi and you almost don't even need to learn OSGi not JBI.

Guillaume Nodet a écrit :
> Right.
>
> Just want to add that if you use the JBI packaging, you can't access OSGi at
> all, so any interaction with the anything outside of the SU is way more
> difficult to achieve (such as accessing a shared JDBC DataSource for
> example).
> In addition the OSGi packaging is usually easier to use, though you need to
> learn OSGi a bit.  But if you're a newbie, you'd have to learn the JBI
> packaging too ...
>
> On Fri, Sep 4, 2009 at 09:26, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>   
>> Hi Reju,
>>
>> I would like to say that this question is a "classical" one for all new
>> SMX4 users.
>>
>> If you begin your developments on ServiceMix4, I think it's better to begin
>> with OSGi service bundles. This approach is interesting especially if your
>> underground application is already OSGi based. The disadvantage of this is
>> if you want to migrate your services on another JBI compliant ESB (like
>> OpenESB), you can't.
>>
>> On the other hand, using JBI packaging (which works without problem on
>> SMX4/NMR), your services can work on any JBI compliant ESB (like SMX3 or
>> OpenESB). For example, in my case, I have "old" JBI services running in
>> production on SMX3. Before migrating these services into OSGi packaging, I
>> have directly deploy it in SMX4 (no change at all has been made).
>>
>> I hope it's clear :)
>>
>> Regards
>> JB
>>
>>
>> Mathew, Reju wrote:
>>
>>     
>>> Hi,
>>>  I am a newbe to the ServiceMix. When developing new applications (using
>>> servicemix - camel) deployed in ServiceMIX 4, which is the preferred way
>>> of packaging - JBI or OSGI ? Do not envisage registering at / using
>>> (OSGI) Service Registry and either way packaged seems deployable into
>>> the osgi container of servicemix (using osgi install) in the same way.
>>> So then which way is recommended / forward looking approach ?
>>>  thanks,
>>> Reju
>>>
>>>
>>>       
>
>
>   

Re: JBI or OSGI packaging

[Guillaume Nodet <gn...@gmail.com>]

Right.

Just want to add that if you use the JBI packaging, you can't access OSGi at
all, so any interaction with the anything outside of the SU is way more
difficult to achieve (such as accessing a shared JDBC DataSource for
example).
In addition the OSGi packaging is usually easier to use, though you need to
learn OSGi a bit.  But if you're a newbie, you'd have to learn the JBI
packaging too ...

On Fri, Sep 4, 2009 at 09:26, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Hi Reju,
>
> I would like to say that this question is a "classical" one for all new
> SMX4 users.
>
> If you begin your developments on ServiceMix4, I think it's better to begin
> with OSGi service bundles. This approach is interesting especially if your
> underground application is already OSGi based. The disadvantage of this is
> if you want to migrate your services on another JBI compliant ESB (like
> OpenESB), you can't.
>
> On the other hand, using JBI packaging (which works without problem on
> SMX4/NMR), your services can work on any JBI compliant ESB (like SMX3 or
> OpenESB). For example, in my case, I have "old" JBI services running in
> production on SMX3. Before migrating these services into OSGi packaging, I
> have directly deploy it in SMX4 (no change at all has been made).
>
> I hope it's clear :)
>
> Regards
> JB
>
>
> Mathew, Reju wrote:
>
>> Hi,
>>  I am a newbe to the ServiceMix. When developing new applications (using
>> servicemix - camel) deployed in ServiceMIX 4, which is the preferred way
>> of packaging - JBI or OSGI ? Do not envisage registering at / using
>> (OSGI) Service Registry and either way packaged seems deployable into
>> the osgi container of servicemix (using osgi install) in the same way.
>> So then which way is recommended / forward looking approach ?
>>  thanks,
>> Reju
>>
>>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Re: JBI or OSGI packaging

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Reju,

I would like to say that this question is a "classical" one for all new 
SMX4 users.

If you begin your developments on ServiceMix4, I think it's better to 
begin with OSGi service bundles. This approach is interesting especially 
if your underground application is already OSGi based. The disadvantage 
of this is if you want to migrate your services on another JBI compliant 
ESB (like OpenESB), you can't.

On the other hand, using JBI packaging (which works without problem on 
SMX4/NMR), your services can work on any JBI compliant ESB (like SMX3 or 
OpenESB). For example, in my case, I have "old" JBI services running in 
production on SMX3. Before migrating these services into OSGi packaging, 
I have directly deploy it in SMX4 (no change at all has been made).

I hope it's clear :)

Regards
JB

Mathew, Reju wrote:
> Hi,
>  
> I am a newbe to the ServiceMix. When developing new applications (using
> servicemix - camel) deployed in ServiceMIX 4, which is the preferred way
> of packaging - JBI or OSGI ? Do not envisage registering at / using
> (OSGI) Service Registry and either way packaged seems deployable into
> the osgi container of servicemix (using osgi install) in the same way.
> So then which way is recommended / forward looking approach ?
>  
> thanks,
> Reju
>  
>