SOA
With all of the hoopla over SOA's, you would think we would be replacing app. servers. Not so says Marc Fleury, and wherever his opinion counts, you would think others would listen. For he does own the most lucrative software franchise on the planet today. Sure he'll get commoditized, but won't they all? Standards add value not diminish value, though BEAS has tried to prove otherwise. Once the standard-bearer their pre-emptive (of SUNW) move to create JWS backfired as a perfect storm hit them, and removed their potential for greatness. Now they are another Siebel waiting to be bought. What's more valuable today WebLogic or JBoss skills? As we digress...SOA's are another word for JAX, and even though JBI would like to extend the integration capabilities of app. servers to include JMS and JCA, what's the point - - you have baked in J2EE 1.4 capabilities, just teach the legions how to do remote calls to EJBs and voila, you have web services. Ok, ok, I see that in the world of proprietary structures such simlicity is not going to sell well in to corporate IT, they need solutions, they need "engines" that can handle the traffic, and perform well under volume, and manage remote data services, and on and on...What is needed, therefore, is a reference architecture from the customer point of view, not the vendor point of view, that says what they would like to accomplish via an SOA. This would be incredibly more complicated and more revealing, and may just push the vendors to think more simply. Doesn't baking in JCA extensions seem like a tight net that will be hard to extract from in the future - - we would see that from Ford's supply chain point of view. Or Boeing. Or Steelcase. The point being that the real complexity with J2EE is not in the specification for development, but in the implementation of integration. Maybe JBI solves this, maybe it just adds another layer, I trust Mr. Bauhaus on this matter, but wonder if all avenues are being explored. Such as JAX. As for the other end of the SOA curve, there is the front-end MSFT developers, who may turn out to have a natural advantage if MSFT has the resources to build literally everything. That includes the rules engines, the vertical solutions, the pre-built components, and on and on. That is why Java has such an advantage, because when you don't have to count on vendors to supply everything, you have an incentivized business model on what to build and for what purposes. With MSFT, you may have some logic to build, but beware that it may be something supplied by central command. Never forget Hailstorm. My good friend is a MSFT developer and has created logic that would make any Java developer proud, if they would move beyond their VB prejudice, and accept the interoperable story of web services. (Damn, I sound like McNealy.) As we look around the world at integration, is it not the manufacturers who have the greatest need with the most complex supply chain, and what other services are needed beyond integration - - how about risk analysis. Seems like once you can solve for risk, you can solve a lot more problems. In the universe of SOA's anything is relevant, and that makes everything necessarily compatible. Is JBI an extension of a standard platform built around Java-interoperability. Or is JAX a solution for .Net integration. Or are they both useful. Lets have some debate for the benefit of both kinds of customers.
posted by douglas dooley @ 8:16 AM
0 Comments:
Post a Comment
<< Home