JBI has always interested me for two reasons: 1) I was surprised to see a model pushed for describing how application servers should be built, rather than used. This was tried with JSR 111 and it failed pretty spectacularly: and this was after J2EE was already defined and agreed on as the standard model for integration servers. 2) It was originally proposed as some of the oddest combinations of technologies: WSDL 2.0 and very old school approach to solving the same problem solved by every dependency injection framework.
OK, now some years have passed: JBI hasn't taken off and now a few vendors are back at the table trying to decide what to do next. Since it's unclear what direction folks will try to take this, I thought I'd poney up a few suggestions on what could make the spec relevant and useful. Basically, get rid of a lot of cruft.
First thing to tackle: the "J2EE for integration servers" looks like it will clearly be SCA. So check SCA support as the standard model for service development. (This seems to be in line with where things are going, or so I thought: Out of the blue, my old friend Mark Little suggests that maybe they will support JBI without SCA. What? Invent a closed, Java specific model for composite services? Enter the matrix indeed!)
Once you build one of these things, it's pretty clear that most of JBI 1.0 can go away. Using SCA and OSGI, you really don't need to do much other than have an interface that passes normalized messages to service engines or binding components. In fact, OSGI provides most of the packaging and injection heavy lifting for building plugins to an SCA/JBI runtime model.
Once you boil down to a few interfaces, then the group could focus on simplifying those interfaces further. Add some management hooks and this is something that could really take off. I suspect this is really what the folks in the Eclipse SRP are really after. All of this suggests that the group could do something genuinely useful: explicitly focusing the JSR as the OSGI based plugin model for Java-SCA platforms.
In sum, narrow the scope, align with industry direction and build some real value additions.
4 comments:
Greg, I think you misinterpreted my post. It wasn't suggesting that JBI 2.0 won't support SCA. That's definitely on the cards. What I was suggesting was that users can develop using JBI and don't need to bother about SCA. Likewise, you could develop on SCA and not even consider JBI. However, the two do work together as well. It's not an either/or situation.
How would you propose that JBI 2.0 define a composite service? What does the developer experience without the assembly model from SCA?
I can see SCA without JBI, as defining the innards of an application server has yet to be successful. But defining the innards without the programming model?
Believe it or not, but there are deployments out there today using JBI 1.0 that don't need SCA. They are only interested in pure Java endpoints (so no language neutrality issues) and they have their own way of assembling components and services from things like EJB3s, POJOS etc. Plus, there are more ESBs out there than JBI and SCA implementations combined. So whereas I see benefits to embracing both (and IMO JBI should definitely embrace the SCA assembly model), the "customer is always right" ;-) and we shouldn't force users down own route or another. Gentle encouragement works beter than dogmatic enforcement.
In 1997, there were many proprietary Web application server models. Sapphire/Web, Silverstream, etc. all offered non-standard ways to build Java Web applications. Customers migrated to J2EE-based application servers because they benefit from broadly supported standards. I believe that sticking with proprietary ESB models will harm users in the long run. Maintaining a separate, JCP standard for ESB "programming" is silly.
I'm not suggesting we force anyone to do anything. The JBI expert group has to decide what they will do. I'm just hoping the group will 1) make sure not to turn this into a research project and 2) put politics aside in order to do the sensible thing for customers.
Post a Comment