On Sun, Jun 8, 2008 at 6:29 AM, Graham Leggett <[EMAIL PROTECTED]> wrote: > Guillaume Nodet wrote: > >> ServiceMix is fully jbi compliant. You can limit yourself to the JBI >> specification, but ServiceMix can go a bit further. > > And by going further, you achieve vendor lockin, and in the process the > whole point behind JBI is lost.
As with many specs, the JBI spec has many areas left to the implementation. This is no different than any of the Java EE related specs and is evidenced by each Java EE container has its own set of tools and nuances. Taking a look at Geronimo, JBoss, Weblogic and Websphere, there are plenty of differences in tools and implementation. > Coming as an outsider looking critically at ServiceMix (and other > containers), all I am seeing is a return to the mess that was EJB2: Xml > Hell, combined with vendor specific config. If JBossESB (for example) > doesn't perform as well as ServiceMix, I want the power to swap them out. Portability is far easier amongst ESBs supporting JBI than amongst ESBs that don't support JBI. We've proven this already by running ServiceMix JBI components in Sun's OpenESB. Unfortunately, however, because not all ESBs support a standard, you are correct, the portability amongst them all is non-existent. >> As for the tutorial, it produces JBI compliant artifacts, but that's >> true we use a maven plugin to ease the work of the user: feel free to >> not use it if you prefer, but it' s just a tool used to create the jbi >> descriptors and package the SUs and SAs as required by the JBI >> specification. For the deployment method, you can also use the >> standard JBI depoyment method which use ant tasks, but again, we offer >> a simplier way to deploy JBI artifacts either using the maven plugin >> or by copying the artifact in the hotdeploy folder. > > Using the maven plugin isn't the problem (in fact if it didn't have a maven > plugin I wouldn't use it), it is the fact that the archetypes has > "servicemix" in the title. > > This tells me that the resulting projects will be vendor locked to > servicemix, or is this not correct? The Maven projects that are created are specific to the ServiceMix JBI components. However, ServiceMix provides the shared-compat library that allows the ServiceMix components to run in any JBI compliant container. > Something I am missing is a clear description of the kinds of artifacts that > are produced in the JBI process. Does it produce jars? ears? something else? > And are these defined by the JBI specification, or do containers make up > their own rules? Have you read the What is JBI? page here: http://servicemix.apache.org/what-is-jbi.html This page and the linked pages describe all of this and will answer these questions for you. In short, the artifacts produced are JBI spec compliant service assembly zip files that contain JBI spec compliant service unit zip files. Each zip file contains a jbi.xml metadata file describing the contents of each zip file. >> And AFAIK, JbossESB does not support JBI .... > > According to the wikipedia entry at > http://en.wikipedia.org/wiki/Java_Business_Integration, JBossESB is listed > as a JBI implementation. I have no idea why it is listed as a JBI implementation because, to my knowledge, JBoss ESB is not JBI compliant, though that may have changed. > The reason for the questions is that I am trying to evaluate whether JBI is > worth using, as opposed to something like a system based on ordinary queues. > If it ends up becoming a loose standard that everybody ignores, or an > incomplete standard that needs to be "embraced and extended" before it > becomes useful, then JBI simply becomes an exercise in obfuscation, taking a > potentially simple problem and turning it into a complicated (and therefore > expensive) one. I can tell you that I've been involved in implementing ServiceMix in many companies all over the world, both large and small. These companies come from a wide range of industries including banking, financial, telecommunications, IT, retail, aerospace, manufacturing, gaming, travel, e-commerce, government agencies, etc. These implementations run the gamut of use cases and in many cases are replacing or have been chosen over commercial solutions. Some include an incredible amount of transactions per day while others don't do a tremendous number of transactions but the value of each transaction is much higher. There are even multiple use cases where vendors are using ServiceMix as the base for their own product (in a sort of OEM style of use). There are a wide range of ServiceMix implementations out there already and the growth continues to increase steadily. Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' Apache ActiveMQ - http://activemq.org/ Apache Camel - http://activemq.org/camel/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Blog: http://bruceblog.org/
