You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by melu <ml...@gmail.com> on 2009/02/04 14:46:19 UTC

Re: SMX4 - JBI / OSGi

So what happend with SU and SA (packaging)? In SMX4 I found only simple
examples "camel-osgi" and "cxf-osgi", but studying these examples I cannot
understand if SA is still needed in SMX4? Is it in that way that all
services (except BC) are SU and they are deployed on SMX4 and SA is not
needed (no jbi.xml file???)? In my opinion more complicated example would be
that what is needed.

Thanks for answering... of course in advance :) 



gnodet wrote:
> 
> ServiceMix 4 implements the JBI specification.  This specification
> defines several things, one being the Normalized Exchanges and how
> components interact together, the other being how to package your JBI
> application.  Consider it the same difference as between servlets and
> wars: you could write servlets and use an embedded http server without
> using a war packaging.
> It's the same with ServiceMix 4.  You can write integration
> applications using the NMR and not use the JBI packaging as defined in
> the specs.  The OSGi packaging offers more features (access to the
> OSGi registry and services, much more powerful classloading mechanism,
> etc...).
> 
> As for clustering, I'm currently working on a replacement for the JMS
> flow on Smx4, so you will be able to have transparent clustering on
> ServiceMix 4 too.
> 
> On Mon, Jan 26, 2009 at 10:42, melu <ml...@gmail.com> wrote:
>>
>> Thanks for very quick reply :)
>>
>> I am sorry but I don't understand it entirely. I am trying to understand
>> SMX4 architecture and I am a little confused because... If I would write
>> my
>> services as OSGi bundles where is there JBI, NMR and the whole enterprise
>> service bus stuff? Maybe I don't fully understand ESB features but I
>> thought
>> that it gives one to loosely couple services also between computers (I
>> read
>> that you work on clustering :)) and gives "abstraction" of transport
>> protocols. I used ServiceMix 3 and I was very exited to see that one
>> service
>> got automatically knowledge that on another computer some service was
>> deployed and now this first service can transfer to the second. And it
>> was
>> transparent to us... We didn't have to construct explicit flows... But I
>> agree that building explicit flows give developer more power on
>> configuration them. But please explain me what remains from what I
>> thought
>> is ESB - only "transport abstraction"? Please don't be angry for such
>> even
>> less than beginner questions... I am trying to understand what SMX4 will
>> give us and what will be architecture of it... I am very interested in it
>> so
>> I ask even questions like this... even "maybe stupid" at first sight.
>>
>>
>>
>> gnodet wrote:
>>>
>>> OSGi and JBI packaging are both supported, but you don't need to use
>>> both.
>>> If you have an existing application running on Smx3, I would advise to
>>> use the JBI packaging to ease the migration.
>>> If you develop a new application, I would advise to use the OSGi
>>> packaging which brings more flexibility and more features.
>>>
>>> ServiceMix JBI components are packaged in both ways so that the same
>>> components can be used in ServiceMix 3 and 4.
>>> For examples on how to develop JBI components, I would advise you to
>>> look at the servicemix components.  For developing applications, there
>>> are a few examples in the ServiceMix 4 distribution that you can look
>>> at.
>>>
>>> On Mon, Jan 26, 2009 at 09:49, melu <ml...@gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could someone explain in more detail architecutre in ServiceMix 4? Does
>>>> all
>>>> components needs to be both JBI and OSGi? What maven plugin should I
>>>> use
>>>> -
>>>> jbi-maven-plugin or osgi-bundle-plugin or both? Could one give an
>>>> example
>>>> of
>>>> doing such things? How to do something to be both JBI and OSGi
>>>> packaged?
>>>>
>>>> Thanks
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662106.html
>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662698.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
> 
> 

-- 
View this message in context: http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21830763.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.


Re: SMX4 - JBI / OSGi

Posted by Freeman Fang <fr...@gmail.com>.
melu wrote:
> Hi,
>
> Maybe I wrongly explained my thoughts. I still cannot understand how OSGi
> packaging fits to JBI. I was thinking about example where there is more than
> one service and where we want to use OSGi packaging. Normally we would
> create two SU and one SA to package them - as in JBI packaging. But what
> about OSGi packaging? Should this services be packaged as two OSGi bundles
> and... what next? No SA? Does it mean that we should have (in this case) two
> bundles packaged with bundle-maven-plugin and that's it?
>
>   
Yes, no SA needed if you use OSGI packaging, you can use 
bundle-maven-plugin to help the OSGI package, that's it.
Freeman
> Thanks
>
>
>
> Freeman Fang wrote:
>   
>> Hi,
>> Actually we also have examples with jbi packaging SA(with jbi.xml 
>> descriptor), take a look at camel and cxf-wsdl-first examples in the kit.
>> Freeman
>>
>> melu wrote:
>>     
>>> So what happend with SU and SA (packaging)? In SMX4 I found only simple
>>> examples "camel-osgi" and "cxf-osgi", but studying these examples I
>>> cannot
>>> understand if SA is still needed in SMX4? Is it in that way that all
>>> services (except BC) are SU and they are deployed on SMX4 and SA is not
>>> needed (no jbi.xml file???)? In my opinion more complicated example would
>>> be
>>> that what is needed.
>>>
>>> Thanks for answering... of course in advance :) 
>>>
>>>
>>>
>>> gnodet wrote:
>>>   
>>>       
>>>> ServiceMix 4 implements the JBI specification.  This specification
>>>> defines several things, one being the Normalized Exchanges and how
>>>> components interact together, the other being how to package your JBI
>>>> application.  Consider it the same difference as between servlets and
>>>> wars: you could write servlets and use an embedded http server without
>>>> using a war packaging.
>>>> It's the same with ServiceMix 4.  You can write integration
>>>> applications using the NMR and not use the JBI packaging as defined in
>>>> the specs.  The OSGi packaging offers more features (access to the
>>>> OSGi registry and services, much more powerful classloading mechanism,
>>>> etc...).
>>>>
>>>> As for clustering, I'm currently working on a replacement for the JMS
>>>> flow on Smx4, so you will be able to have transparent clustering on
>>>> ServiceMix 4 too.
>>>>
>>>> On Mon, Jan 26, 2009 at 10:42, melu <ml...@gmail.com> wrote:
>>>>     
>>>>         
>>>>> Thanks for very quick reply :)
>>>>>
>>>>> I am sorry but I don't understand it entirely. I am trying to
>>>>> understand
>>>>> SMX4 architecture and I am a little confused because... If I would
>>>>> write
>>>>> my
>>>>> services as OSGi bundles where is there JBI, NMR and the whole
>>>>> enterprise
>>>>> service bus stuff? Maybe I don't fully understand ESB features but I
>>>>> thought
>>>>> that it gives one to loosely couple services also between computers (I
>>>>> read
>>>>> that you work on clustering :)) and gives "abstraction" of transport
>>>>> protocols. I used ServiceMix 3 and I was very exited to see that one
>>>>> service
>>>>> got automatically knowledge that on another computer some service was
>>>>> deployed and now this first service can transfer to the second. And it
>>>>> was
>>>>> transparent to us... We didn't have to construct explicit flows... But
>>>>> I
>>>>> agree that building explicit flows give developer more power on
>>>>> configuration them. But please explain me what remains from what I
>>>>> thought
>>>>> is ESB - only "transport abstraction"? Please don't be angry for such
>>>>> even
>>>>> less than beginner questions... I am trying to understand what SMX4
>>>>> will
>>>>> give us and what will be architecture of it... I am very interested in
>>>>> it
>>>>> so
>>>>> I ask even questions like this... even "maybe stupid" at first sight.
>>>>>
>>>>>
>>>>>
>>>>> gnodet wrote:
>>>>>       
>>>>>           
>>>>>> OSGi and JBI packaging are both supported, but you don't need to use
>>>>>> both.
>>>>>> If you have an existing application running on Smx3, I would advise to
>>>>>> use the JBI packaging to ease the migration.
>>>>>> If you develop a new application, I would advise to use the OSGi
>>>>>> packaging which brings more flexibility and more features.
>>>>>>
>>>>>> ServiceMix JBI components are packaged in both ways so that the same
>>>>>> components can be used in ServiceMix 3 and 4.
>>>>>> For examples on how to develop JBI components, I would advise you to
>>>>>> look at the servicemix components.  For developing applications, there
>>>>>> are a few examples in the ServiceMix 4 distribution that you can look
>>>>>> at.
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 09:49, melu <ml...@gmail.com> wrote:
>>>>>>         
>>>>>>             
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could someone explain in more detail architecutre in ServiceMix 4?
>>>>>>> Does
>>>>>>> all
>>>>>>> components needs to be both JBI and OSGi? What maven plugin should I
>>>>>>> use
>>>>>>> -
>>>>>>> jbi-maven-plugin or osgi-bundle-plugin or both? Could one give an
>>>>>>> example
>>>>>>> of
>>>>>>> doing such things? How to do something to be both JBI and OSGi
>>>>>>> packaged?
>>>>>>>
>>>>>>> Thanks
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662106.html
>>>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>>         
>>>>>>             
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662698.html
>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>       
>>>>>           
>>>> -- 
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>
>>     
>
>   


Re: SMX4 - JBI / OSGi

Posted by Guillaume Nodet <gn...@gmail.com>.
JBI packaging and OSGi packaging are exclusive.  You use either the
first one or the second one.
In the OSGi packaging, you write a spring xml configuration file which
contains the JBI endpoints definition.
Instead of creating a SU for each endpoint and a SA to wrap them, you
can put all those in the same spring app.
You simply need to add the mandatory bean to expose those endpoints in
the OSGi registry as shown in the examples and wrap it in a bundle.

On Thu, Feb 5, 2009 at 09:14, melu <me...@gmail.com> wrote:
>
> Hi,
>
> Maybe I wrongly explained my thoughts. I still cannot understand how OSGi
> packaging fits to JBI. I was thinking about example where there is more than
> one service and where we want to use OSGi packaging. Normally we would
> create two SU and one SA to package them - as in JBI packaging. But what
> about OSGi packaging? Should this services be packaged as two OSGi bundles
> and... what next? No SA? Does it mean that we should have (in this case) two
> bundles packaged with bundle-maven-plugin and that's it?
>
> Thanks
>
>
>
> Freeman Fang wrote:
>>
>> Hi,
>> Actually we also have examples with jbi packaging SA(with jbi.xml
>> descriptor), take a look at camel and cxf-wsdl-first examples in the kit.
>> Freeman
>>
>> melu wrote:
>>> So what happend with SU and SA (packaging)? In SMX4 I found only simple
>>> examples "camel-osgi" and "cxf-osgi", but studying these examples I
>>> cannot
>>> understand if SA is still needed in SMX4? Is it in that way that all
>>> services (except BC) are SU and they are deployed on SMX4 and SA is not
>>> needed (no jbi.xml file???)? In my opinion more complicated example would
>>> be
>>> that what is needed.
>>>
>>> Thanks for answering... of course in advance :)
>>>
>>>
>>>
>>> gnodet wrote:
>>>
>>>> ServiceMix 4 implements the JBI specification.  This specification
>>>> defines several things, one being the Normalized Exchanges and how
>>>> components interact together, the other being how to package your JBI
>>>> application.  Consider it the same difference as between servlets and
>>>> wars: you could write servlets and use an embedded http server without
>>>> using a war packaging.
>>>> It's the same with ServiceMix 4.  You can write integration
>>>> applications using the NMR and not use the JBI packaging as defined in
>>>> the specs.  The OSGi packaging offers more features (access to the
>>>> OSGi registry and services, much more powerful classloading mechanism,
>>>> etc...).
>>>>
>>>> As for clustering, I'm currently working on a replacement for the JMS
>>>> flow on Smx4, so you will be able to have transparent clustering on
>>>> ServiceMix 4 too.
>>>>
>>>> On Mon, Jan 26, 2009 at 10:42, melu <ml...@gmail.com> wrote:
>>>>
>>>>> Thanks for very quick reply :)
>>>>>
>>>>> I am sorry but I don't understand it entirely. I am trying to
>>>>> understand
>>>>> SMX4 architecture and I am a little confused because... If I would
>>>>> write
>>>>> my
>>>>> services as OSGi bundles where is there JBI, NMR and the whole
>>>>> enterprise
>>>>> service bus stuff? Maybe I don't fully understand ESB features but I
>>>>> thought
>>>>> that it gives one to loosely couple services also between computers (I
>>>>> read
>>>>> that you work on clustering :)) and gives "abstraction" of transport
>>>>> protocols. I used ServiceMix 3 and I was very exited to see that one
>>>>> service
>>>>> got automatically knowledge that on another computer some service was
>>>>> deployed and now this first service can transfer to the second. And it
>>>>> was
>>>>> transparent to us... We didn't have to construct explicit flows... But
>>>>> I
>>>>> agree that building explicit flows give developer more power on
>>>>> configuration them. But please explain me what remains from what I
>>>>> thought
>>>>> is ESB - only "transport abstraction"? Please don't be angry for such
>>>>> even
>>>>> less than beginner questions... I am trying to understand what SMX4
>>>>> will
>>>>> give us and what will be architecture of it... I am very interested in
>>>>> it
>>>>> so
>>>>> I ask even questions like this... even "maybe stupid" at first sight.
>>>>>
>>>>>
>>>>>
>>>>> gnodet wrote:
>>>>>
>>>>>> OSGi and JBI packaging are both supported, but you don't need to use
>>>>>> both.
>>>>>> If you have an existing application running on Smx3, I would advise to
>>>>>> use the JBI packaging to ease the migration.
>>>>>> If you develop a new application, I would advise to use the OSGi
>>>>>> packaging which brings more flexibility and more features.
>>>>>>
>>>>>> ServiceMix JBI components are packaged in both ways so that the same
>>>>>> components can be used in ServiceMix 3 and 4.
>>>>>> For examples on how to develop JBI components, I would advise you to
>>>>>> look at the servicemix components.  For developing applications, there
>>>>>> are a few examples in the ServiceMix 4 distribution that you can look
>>>>>> at.
>>>>>>
>>>>>> On Mon, Jan 26, 2009 at 09:49, melu <ml...@gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could someone explain in more detail architecutre in ServiceMix 4?
>>>>>>> Does
>>>>>>> all
>>>>>>> components needs to be both JBI and OSGi? What maven plugin should I
>>>>>>> use
>>>>>>> -
>>>>>>> jbi-maven-plugin or osgi-bundle-plugin or both? Could one give an
>>>>>>> example
>>>>>>> of
>>>>>>> doing such things? How to do something to be both JBI and OSGi
>>>>>>> packaged?
>>>>>>>
>>>>>>> Thanks
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662106.html
>>>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662698.html
>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21846991.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>



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

Re: SMX4 - JBI / OSGi

Posted by melu <me...@gmail.com>.
Hi,

Maybe I wrongly explained my thoughts. I still cannot understand how OSGi
packaging fits to JBI. I was thinking about example where there is more than
one service and where we want to use OSGi packaging. Normally we would
create two SU and one SA to package them - as in JBI packaging. But what
about OSGi packaging? Should this services be packaged as two OSGi bundles
and... what next? No SA? Does it mean that we should have (in this case) two
bundles packaged with bundle-maven-plugin and that's it?

Thanks



Freeman Fang wrote:
> 
> Hi,
> Actually we also have examples with jbi packaging SA(with jbi.xml 
> descriptor), take a look at camel and cxf-wsdl-first examples in the kit.
> Freeman
> 
> melu wrote:
>> So what happend with SU and SA (packaging)? In SMX4 I found only simple
>> examples "camel-osgi" and "cxf-osgi", but studying these examples I
>> cannot
>> understand if SA is still needed in SMX4? Is it in that way that all
>> services (except BC) are SU and they are deployed on SMX4 and SA is not
>> needed (no jbi.xml file???)? In my opinion more complicated example would
>> be
>> that what is needed.
>>
>> Thanks for answering... of course in advance :) 
>>
>>
>>
>> gnodet wrote:
>>   
>>> ServiceMix 4 implements the JBI specification.  This specification
>>> defines several things, one being the Normalized Exchanges and how
>>> components interact together, the other being how to package your JBI
>>> application.  Consider it the same difference as between servlets and
>>> wars: you could write servlets and use an embedded http server without
>>> using a war packaging.
>>> It's the same with ServiceMix 4.  You can write integration
>>> applications using the NMR and not use the JBI packaging as defined in
>>> the specs.  The OSGi packaging offers more features (access to the
>>> OSGi registry and services, much more powerful classloading mechanism,
>>> etc...).
>>>
>>> As for clustering, I'm currently working on a replacement for the JMS
>>> flow on Smx4, so you will be able to have transparent clustering on
>>> ServiceMix 4 too.
>>>
>>> On Mon, Jan 26, 2009 at 10:42, melu <ml...@gmail.com> wrote:
>>>     
>>>> Thanks for very quick reply :)
>>>>
>>>> I am sorry but I don't understand it entirely. I am trying to
>>>> understand
>>>> SMX4 architecture and I am a little confused because... If I would
>>>> write
>>>> my
>>>> services as OSGi bundles where is there JBI, NMR and the whole
>>>> enterprise
>>>> service bus stuff? Maybe I don't fully understand ESB features but I
>>>> thought
>>>> that it gives one to loosely couple services also between computers (I
>>>> read
>>>> that you work on clustering :)) and gives "abstraction" of transport
>>>> protocols. I used ServiceMix 3 and I was very exited to see that one
>>>> service
>>>> got automatically knowledge that on another computer some service was
>>>> deployed and now this first service can transfer to the second. And it
>>>> was
>>>> transparent to us... We didn't have to construct explicit flows... But
>>>> I
>>>> agree that building explicit flows give developer more power on
>>>> configuration them. But please explain me what remains from what I
>>>> thought
>>>> is ESB - only "transport abstraction"? Please don't be angry for such
>>>> even
>>>> less than beginner questions... I am trying to understand what SMX4
>>>> will
>>>> give us and what will be architecture of it... I am very interested in
>>>> it
>>>> so
>>>> I ask even questions like this... even "maybe stupid" at first sight.
>>>>
>>>>
>>>>
>>>> gnodet wrote:
>>>>       
>>>>> OSGi and JBI packaging are both supported, but you don't need to use
>>>>> both.
>>>>> If you have an existing application running on Smx3, I would advise to
>>>>> use the JBI packaging to ease the migration.
>>>>> If you develop a new application, I would advise to use the OSGi
>>>>> packaging which brings more flexibility and more features.
>>>>>
>>>>> ServiceMix JBI components are packaged in both ways so that the same
>>>>> components can be used in ServiceMix 3 and 4.
>>>>> For examples on how to develop JBI components, I would advise you to
>>>>> look at the servicemix components.  For developing applications, there
>>>>> are a few examples in the ServiceMix 4 distribution that you can look
>>>>> at.
>>>>>
>>>>> On Mon, Jan 26, 2009 at 09:49, melu <ml...@gmail.com> wrote:
>>>>>         
>>>>>> Hello,
>>>>>>
>>>>>> Could someone explain in more detail architecutre in ServiceMix 4?
>>>>>> Does
>>>>>> all
>>>>>> components needs to be both JBI and OSGi? What maven plugin should I
>>>>>> use
>>>>>> -
>>>>>> jbi-maven-plugin or osgi-bundle-plugin or both? Could one give an
>>>>>> example
>>>>>> of
>>>>>> doing such things? How to do something to be both JBI and OSGi
>>>>>> packaged?
>>>>>>
>>>>>> Thanks
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662106.html
>>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>           
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>>         
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662698.html
>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>>       
>>>
>>> -- 
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>>     
>>
>>   
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21846991.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.


Re: SMX4 - JBI / OSGi

Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Actually we also have examples with jbi packaging SA(with jbi.xml 
descriptor), take a look at camel and cxf-wsdl-first examples in the kit.
Freeman

melu wrote:
> So what happend with SU and SA (packaging)? In SMX4 I found only simple
> examples "camel-osgi" and "cxf-osgi", but studying these examples I cannot
> understand if SA is still needed in SMX4? Is it in that way that all
> services (except BC) are SU and they are deployed on SMX4 and SA is not
> needed (no jbi.xml file???)? In my opinion more complicated example would be
> that what is needed.
>
> Thanks for answering... of course in advance :) 
>
>
>
> gnodet wrote:
>   
>> ServiceMix 4 implements the JBI specification.  This specification
>> defines several things, one being the Normalized Exchanges and how
>> components interact together, the other being how to package your JBI
>> application.  Consider it the same difference as between servlets and
>> wars: you could write servlets and use an embedded http server without
>> using a war packaging.
>> It's the same with ServiceMix 4.  You can write integration
>> applications using the NMR and not use the JBI packaging as defined in
>> the specs.  The OSGi packaging offers more features (access to the
>> OSGi registry and services, much more powerful classloading mechanism,
>> etc...).
>>
>> As for clustering, I'm currently working on a replacement for the JMS
>> flow on Smx4, so you will be able to have transparent clustering on
>> ServiceMix 4 too.
>>
>> On Mon, Jan 26, 2009 at 10:42, melu <ml...@gmail.com> wrote:
>>     
>>> Thanks for very quick reply :)
>>>
>>> I am sorry but I don't understand it entirely. I am trying to understand
>>> SMX4 architecture and I am a little confused because... If I would write
>>> my
>>> services as OSGi bundles where is there JBI, NMR and the whole enterprise
>>> service bus stuff? Maybe I don't fully understand ESB features but I
>>> thought
>>> that it gives one to loosely couple services also between computers (I
>>> read
>>> that you work on clustering :)) and gives "abstraction" of transport
>>> protocols. I used ServiceMix 3 and I was very exited to see that one
>>> service
>>> got automatically knowledge that on another computer some service was
>>> deployed and now this first service can transfer to the second. And it
>>> was
>>> transparent to us... We didn't have to construct explicit flows... But I
>>> agree that building explicit flows give developer more power on
>>> configuration them. But please explain me what remains from what I
>>> thought
>>> is ESB - only "transport abstraction"? Please don't be angry for such
>>> even
>>> less than beginner questions... I am trying to understand what SMX4 will
>>> give us and what will be architecture of it... I am very interested in it
>>> so
>>> I ask even questions like this... even "maybe stupid" at first sight.
>>>
>>>
>>>
>>> gnodet wrote:
>>>       
>>>> OSGi and JBI packaging are both supported, but you don't need to use
>>>> both.
>>>> If you have an existing application running on Smx3, I would advise to
>>>> use the JBI packaging to ease the migration.
>>>> If you develop a new application, I would advise to use the OSGi
>>>> packaging which brings more flexibility and more features.
>>>>
>>>> ServiceMix JBI components are packaged in both ways so that the same
>>>> components can be used in ServiceMix 3 and 4.
>>>> For examples on how to develop JBI components, I would advise you to
>>>> look at the servicemix components.  For developing applications, there
>>>> are a few examples in the ServiceMix 4 distribution that you can look
>>>> at.
>>>>
>>>> On Mon, Jan 26, 2009 at 09:49, melu <ml...@gmail.com> wrote:
>>>>         
>>>>> Hello,
>>>>>
>>>>> Could someone explain in more detail architecutre in ServiceMix 4? Does
>>>>> all
>>>>> components needs to be both JBI and OSGi? What maven plugin should I
>>>>> use
>>>>> -
>>>>> jbi-maven-plugin or osgi-bundle-plugin or both? Could one give an
>>>>> example
>>>>> of
>>>>> doing such things? How to do something to be both JBI and OSGi
>>>>> packaged?
>>>>>
>>>>> Thanks
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662106.html
>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>           
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>>         
>>> --
>>> View this message in context:
>>> http://www.nabble.com/SMX4---JBI---OSGi-tp21662106p21662698.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>>       
>>
>> -- 
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>>     
>
>