Mixing Metaphors with ESB
Dain Hansen's Blog |
February 23, 2007 11:17 PM
|
Comments (1)
I love to hear blog posts that talk about SOA and casually mention the solutions to business integration as silver bullets, holy grails, and nirvana. And the only way I could think to possibly counter such a plethora of blogs was to write the most mixed metaphor catch-phrase ridden blog myself.
I hate to pick on this author but here is an example of this kind of generalization on this Blog
The use of standards, like JBI, simplifies the combining of components but it is the ability to make those high-learning-curve standards accessible to all levels of coders that is the Holy Grail enterprises will be striving to acquire. …
The interesting point about this article is that it highlights a weakness of the JBI standard, which is that it is hard to use, has a high learning curve, and is developer focused. It then goes on to explain that eventual improvements in graphical interfaces will somehow correct this flaw. What is interesting is this reinforces the notion that JBI open source ESBs, are focused on exposing the standards directly to the developer (Java only by the way) and that they have little in the way of integrating design, management, operations. I won’t bring up my the way I really feel about this subject: ok I will, please read here.
This is not to say that we shouldn’t look at standards as ways to expose extensibility for the ESB, and these standards are probably going to have to be geared for the developer audience, but it is ironic that it is setting the clock back on these solutions.
How many cliches have I used so far?
Companies want productivity gains just as much as they want to reduce the vendor lock-in approaches. Developers already have a lot of extensibility options with their ESB already – with Java, J2EE, EJB, POJO, BPEL, SDO, Xquery, WS-Policy, SNMP, JMX, SOAP/WS, Eclipse, UDDI, JMS, JCA, Spring, Hibernate, .NET (have I missed any?).
What we really need to do is look beyond our limited ESB transportation metaphors and go to something more broad, and focused on SOA, We should look at complex SOA architectures and assemblies of services which may be on the Bus, or may even be off the Bus – it shouldn’t matter.
At BEA we recognize that the SOA Holy Grail is not a holy grail at all, but something attainable for our customers; it is not filled with a Java-only spec; it should be filled with a broader more general purpose SOA component architecture standard which really solves how complex composite SOA can be designed, deployed, and managed, that is the SCA Standard.
And one more I had to pick on: “Getting Thrown under the Bus” – and no the ESB will not die like a fruit fly, SOA and standards like SCA will probably be one of the reasons that it won’t.
Thanks for not mixing your metaphors when you talk about ESB.
For more on BEA’s SCA vision you should read Bill’s SCA article
For more on BEA’s own Bus, check out the AquaLogic Service Bus
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
|
