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.
Welcome to the blog of Greg Pavlik, software technologist and frustrated adventurer. Currently, I am working on technologies related to Cloud Computing and Cloud Platform as a Service capabilities.
Monday, May 21, 2007
Wednesday, May 16, 2007
Monday, May 14, 2007
The Other Dave on SCA
The other Dave Chappell is suggesting that the Java community is fracturing on whether Java is a useful programming model for SCA. Let me give my perspective on this, since I've commented on this extensively in the SCA working group and in other forums.
There is no doubt that adding support for imperative programming models is important for SOA composites. This is where the Java/SCA model makes sense.
But does it matter? My argument all along has been that we should not teach a new model around Java. Everyone is already converging on a common model: the whole Java world is moving toward pojo programming stripped free of the framework cruft. In the first SCA f2f I sat with Rod Johnson and watched him implement some of the annotations in the original SCA JCI spec in a few minutes. SCA frameworks will bootstrap Java code. Write it for Spring and it will be useable in SCA. Or vice versa.
Put it another way: we can bootstrap basic BPEL processes into an SCA environment without changing the BPEL definition because you just use the language. We expect to see the same thing for Java platforms moving forward. If anything, this is the ultimate form of industry convergence.
There is no doubt that adding support for imperative programming models is important for SOA composites. This is where the Java/SCA model makes sense.
But does it matter? My argument all along has been that we should not teach a new model around Java. Everyone is already converging on a common model: the whole Java world is moving toward pojo programming stripped free of the framework cruft. In the first SCA f2f I sat with Rod Johnson and watched him implement some of the annotations in the original SCA JCI spec in a few minutes. SCA frameworks will bootstrap Java code. Write it for Spring and it will be useable in SCA. Or vice versa.
Put it another way: we can bootstrap basic BPEL processes into an SCA environment without changing the BPEL definition because you just use the language. We expect to see the same thing for Java platforms moving forward. If anything, this is the ultimate form of industry convergence.
Dave Chappell joins Oracle SOA team
Great news: Dave Chappell (ex-Sonic) has signed on with Oracle's integration and SOA team. He was already out speaking on our SOA strategy at JavaOne last week on the main SCA panel.
Update: bookmark Dave's blog here: http://blogs.oracle.com/davidchappell
Update: bookmark Dave's blog here: http://blogs.oracle.com/davidchappell
Wednesday, May 02, 2007
Systems Integration 2007 (Prague, Czech Republic)
I will be delivering two keynote talks this year at the Systems Integration conference in Prague. This is a big event for central Europe and I'm excited to get a chance to talk with lots of people that are implementing SOA solutions. I'm also pretty excited about seeing Prague, if only between meetings.
Subscribe to:
Posts (Atom)