Plus, (4) If I choose to implement JBI-based solution, am I stuck with the JBI BC components which "have been discontinued"?
What does it mean that they are discontinued, are they not developed / bug fixed anymore? Are the current BC's stable and reliable now? Do I have an option of either using, for example to integrate to a FTP server - servicemix-ftp JBI BC - servicemix-camel JBI BC + Camel FTP integration and which would be better? On Mon, Feb 21, 2011 at 5:20 PM, janne postilista <[email protected]> wrote: > 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 >> >
