Bruce Snyder wrote:
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.
Exactly, this is the very definition of a failed standard. If the different implementations don't interoperate (as was the case with EJB2), then the standard is pointless.
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.
This is good news.
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.
I did read "what is JBI", and have gone through a number of articles, but I have yet to find one that gives a summary of what constitutes a compliant JBI implementation.
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.
The idea of an ESB is a sound one, I have no doubt of that, the question I have yet to answer is "which one"?
If you had bet the farm on WebSphere back when you were implementing EJB2, instead of JBoss, you would have found yourself waiting a long time before EJB3 was available to you.
With a standards compliant server, I would be empowered to swap out WebSphere for JBoss if I so wanted to use EJB3. In practice, this wasn't straightforward, as many implementations are tied to WebSphere or JBoss, and in the process they are stuck unable to use modern feature releases.
I don't want to choose a container, only to find that I am stuck with that container in 2 years, and a better one is on the horizon.
I want what JBI advertises: write your business logic once against the standard, and then see it run for 5, 10 (15, 20...) years, without being forced to rewrite the system from scratch (or at the very least: rewriting as little as possible).
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
