Sure, 99.9999% of the world believes that BPM stands for Business Process Management, but to SUN it stands for Business Process Machines - good going. Alright, it is no secret that I think that Sun has screwed up their chance to dominate enterprise computing architectures in the coming years. By fighting the web services trend and running after Java-only platforms and CBD style programming, they gave IBM and Microsoft the keys to the kingdom.
In an attempt to get back in the game, Sun is pursuing a strategy called JBI or Java Business Integration. This venture acknowledges that Java needs more than API's for calling web services, thus the JAX solutions are merely bridges between old and new environments (Java CBD and SOA). JBI, however, is a restating of the problem. It acknolwedges that first order concerns in architectural design are interoperability and integrate-ability.
In their words,
JBI is intended to support the full range of integration solutions,including simple,synchronous point-to-point EAI or more complex B2B business process automation incorporating long-running transactions and complex workflows. However, it is especially well suited for business process automation problems, with the goal of enabling much simpler development of solutions that today are complex and time consuming to implement. Examples of the solutions JBI will facilitate include:
•Self-service customer portals
•Enterprise employee portals
•Customer relationship management (CRM)integration
•Supply chain integration
•EDI replacement
And what will the approach look like?
JBI will support an RPC-oriented Web services programming model as well as a message-oriented Web services programming model,in particular,the constructs of:
•Components as services with interfaces that are publicly and explicitly described by standard metadata,for example,the Web Services Description Language (WSDL)
•Document-centric processing where component services act on standard,structured XML documents that contain both business data and metadata,which provides context for service execution
•Asynchronous communication between components with support for long-running transactions
And the scope is?
The current scope of the JBI architecture standard, as described in the approved JSR 208 proposal, is not to specify how components are themselves implemented. Instead, it only specifies the interfaces they must support for plugging into the JBI environment to use its services and interact with one another to request and deliver services. Thus,JBI is at least initially about system programming interfaces (SPIs)and not about application programming interfaces (APIs), and therefore pertains more directly to those who build integration servers and tools than to those who build solutions with them.
You know, I really like this idea. However, I have this bad feeling that Sun will screw it up. They will likely continue to treat their language (Java) and platform (J2EE) as their primary concerns and treat JBI as an add-on (rather than the other way around). Sun will have to throw away their notion that everything is either an API or is Java P-code and move towards protocols and language neutral interfaces. Lastly, they will have to quit fighting IBM on EVERYTHING. If IBM & Microsoft agree on a new specification, just go along - and win with the implementation. They must stop trying to win the ego battle. Perhaps a tough job for a company run by McNealy.
For more on JBI, see: http://www.webservices.org/papers/JBIwp70903.fm.pdf
No comments:
Post a Comment