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.
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.
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?
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?
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.
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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
