A few questions still as I'm trying to get a grasp on the whole JBI / OSGi relationship:
(1) ServiceLink has a great number of different JBI binding components, such as (http://servicemix.apache.org/components-list.html) servicemix-sap, servicemix-hl7, servicemix-sdo, servicemix-file. Looking at documentation on ServiceMix 4 at http://www.slideshare.net/gertv/servicemix-4-integrating-osgi-with-jbi-1439897 for example, the architecture is pictured as (the slides may be old) 1. ServiceMix Kernel 1.1.0 (now Karaf?) at the bottom 2. ServiceMix NMR, Web, ActiveMQ 3. JBI Compatibility layer, CXF NMR and Camel NMR on top of ServiceMix NMR 4. ServiceMix JBI Components (2009.01) (HTTP, JMS, CXF...) on top of JBI layer so, I get the idea that a. If I develop pure OSGi bundles without JBI, I cannot use servicemix-sap JBI BC - true / false? b. If I develop pure OSGi bundles without JBI, I can only do what CXF and Camel can - and am more limited in connectivity to more exotic protocols such as sap, hl7...true / false? c. in the JBI components documentation I find that "The development of JBI components has been discontinued, in favor of Apache Camel which provides a full range of components." - does Camel indeed offer all the same features as the old JBI BC's? (2) When developing pure OSGi solutions, I am going to be grouping a number of OSGi bundles as a feature (like in JBI I would create a Service Assembly). This "feature" is ServiceLink specific concept, is it not? Not something that exists in all OSGi servers? (3) Does choosing JBI or OSGi affect which clustering / failover / High Availability -related features I can use? On Wed, Feb 16, 2011 at 3:25 PM, Guillaume Nodet <[email protected]> wrote: > You can read: > http://gnodet.blogspot.com/2010/12/thoughts-about-servicemix.html > http://www.slideshare.net/gnodet/ijtc-servicemix-4 (that one is from 2007) > > > On Wed, Feb 16, 2011 at 13:42, janne postilista > <[email protected]> wrote: >> Hi, >> >> when you say that JBI container (and packaging) has strong >> limitations, and OSGi is better for building containers, do you mean >> >> - limitations exist for developers who develop the container >> - limitations exist for developers who develop service assemblies and >> just use the container (=me)? > > Limitations for SA developers, as the SA packaging is limited and > isn't really written to handle code deployment really well. > >> I didn't even know I could or had to choose between developing JBI >> -based or developing OSGi -based solution....what are the main >> problems and limitations I would face if I choose the JBI route as >> opposed to OSGi? >> >> Any documentation / articles / links to help with this choice? >> >> >> On Wed, Feb 16, 2011 at 2:25 PM, Guillaume Nodet <[email protected]> wrote: >>> Life isn't as easy as black or white. JBI defines a packaging and a >>> container in addition to the normalized exchanges. >>> Both packaging and container have very strong limitations, though >>> ServiceMix provides some enhancements on top of the JBI spec that >>> fixes some of those problems. >>> However OSGi is a much better choice for building containers. >>> >>> As for portability, the problem is that your assemblies are tied to >>> ServiceMix components, so if you ever want to switch to another JBI >>> container (there aren't that many really), you'd have to make sure the >>> ServiceMix components can be used in that container (which certainly >>> require some work), or rewrite the whole service units. >>> >>> It's a choice for you to make, either stick to the standard, or favor >>> tools which have better productivity and support (Camel has already >>> more tooling than JBI I think). >>> >>> On Wed, Feb 16, 2011 at 13:17, janne postilista >>> <[email protected]> wrote: >>>> Hi, >>>> >>>> why would I prefer OSGi over JBI (and is it a question of choosing >>>> either)? I thought OSGi was more or less just a way of packaging a JBI >>>> service assembly (but maybe its not...)? >>>> >>>> I thought JBI was a good thing (standardized packaging, common >>>> concepts in all supporting ESBs, etc)? Why would I not want to develop >>>> JBI artifacts? Is JBI considered bad for some reasons? If I develop >>>> "simple osgi bundles", am I not tied into servicemix tighter than if I >>>> develop JBI sa's (then I can move them more easily to any JBI >>>> compliant ESB)? >>>> >>>> >>>> On Wed, Feb 16, 2011 at 2:06 PM, Christian Schneider >>>> <[email protected]> wrote: >>>>> Hi Janne, >>>>> >>>>> I think you could use some maven toolings for generating the xmls. The >>>>> bigger question though is: Do you really want to write JBI artifacts now >>>>> that servicemix is based on OSGi. >>>>> So the better way to go may be to write simple osgi bundles. For writing >>>>> OSGi bundles Eclipse with Sonatype m2eclipse plugin is probably all you >>>>> need. >>>>> I have written a small tutorial for developing OSGi bunldes on Karaf: >>>>> http://www.liquid-reality.de/display/liquid/2011/02/15/Karaf+Tutorial+Part+1+-+Installation+and+First+application >>>>> >>>>> My company has just released a distribution of Karaf + Camel + CXF with >>>>> some >>>>> nice examples for integrations. >>>>> See: >>>>> http://www.talend.com/products-application-integration/talend-integration-factory-community-edition.php >>>>> >>>>> It is basically the same as servicemix but without JBI support. This is >>>>> just >>>>> to show that we believe that JBI is not necessary anymore to build an >>>>> integration platform. You can deploy the same >>>>> kind of integration bundles using the normal servicemix distro. >>>>> >>>>> Christian >>>>> >>>>> >>>>> Am 16.02.2011 12:54, schrieb janne postilista: >>>>>> >>>>>> Hi, >>>>>> >>>>>> which IDE is best suited for developing a project to be deployed in >>>>>> ServiceMix 4? Eclipse or Netbeans? >>>>>> >>>>>> What kind of plugins, etc, are there for developing service assemblies >>>>>> (binding components etc)? Do people actually write the required XML, >>>>>> etc, by hand, or what is the common practise? >>>>>> >>>>>> ServiceMix documentation >>>>>> http://servicemix.apache.org/eclipse-plugin.html links to a dead end, >>>>>> also googling for "servicemix eclipse" brings a few dead ends like >>>>>> >>>>>> http://swik.net/ServiceMix/Blog%3A+ServiceMix+%28SM%29/Creating+graphical+JBI+deployments+with+ServiceMix+in+Eclipse+%28created%29/b3zo >>>>>> >>>>>> I know there's some tooling linked to Fuse ESB, but that's either not >>>>>> free (fuse integration developer) or cover only part of the service >>>>>> assembly (Fuse IDE for Camel http://fusesource.com/fuse/camel-beta/ ) >>>>>> >>>>> >>>>> -- >>>>> ---- >>>>> http://www.liquid-reality.de >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
