Ulterior Motive Behind BEA and IBM Joint Spec?

Share the article!

BEA and IBM are collaborating together creating joint specifications for building more portable server applications. The two companies announced three specifications: Service Data Objects, WorkManager and Timers. The text of the announcement unsatisfactorily attempts to explains their rationale:

Our rationale for publishing these specifications now is to rapidly facilitate experimentation, implementation, feedback, and early adoption in advance of standardization and ratification within the JCP.

These joint specifications do raise a lot of interesting questions. Why are these capabilities being rushed into early adoption? Doesn’t the current J2EE 1.4 specification adequately address the needs of the enterprise? What are the requirements behind these specs? What’s with the feature creep? Is this something designed in a vacuum?

The answer to these questions are pretty raw and simple. J2EE 1.4 does not adequately support the needs of the enterprise. The primarily need of the enterprise today is to integrate their disparate applications. This requires querying disparate databases and managing business processes. None of this is adequately supported by the J2EE standard. In fact with out the introduction of MDB and JCA it would have been entirely impossible!

Matter of fact, J2EE and the EJB model behind it promotes stove pipe like applications. The enterprise doesn’t need any more of these, what they need is to solve their integration nightmare. This is best solved by employing a loosely coupled architecture. Work Manager and Timer are designed to support the handling of asychronously invoked processes, and SDO is more like a self describing structure.

BEA and IBM have integration servers in the form of Weblogic Integrator and Websphere Business Integrator respectively. Both tools support the graphical development of business processes. Both tools generate java code out of the process descriptions. The unspoken question is, what kind of runtime does the java code run on top of? Is the runtime portable across J2EE servers? Does it support scalable asychronous processes?

The sad state of affairs is that BPM is exactly what the enterprise wants and needs and stove pipe EJB based applications are exactly what an enterprise wants to avoid. Both vendors would like to graft BPM on top of standard J2EE containers. Unfortunately, too much is missing and these capabilities are needed yesterday. So no ulterior motives here folks, just vendors coming to grips with reality, move along now.

Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>