IBM has announced that they have an ESB - and will be shipping it within the month.
Yesterday was a busy day talking with IBM personnel about the ESB and their new WebSphere Process Server. Naturally, I voiced a few concerns about calling it an ESB but if anyone can create a category, it is IBM.
What I heard was a couple interesting comments:
- Don't concern yourself with SOAP over MQ
- We agree, it isn't about JMS
- Don't worry about the protocols, we'll add'em in later
Hmm. If a WS-startup were to have told me this I would have gone off - however, this wasn't - it was IBM. Big blue customers will buy this. They will build on endpoints and mediate in the middle.
I remain disappointed in the lack of clarity around the ESB but am happy to see IBM put some new weight behind their SOA marketing. Congratulations to the IBM teams for getting these products out the door on schedule.
Our customers have been asking us for an ESB evaluators offering which is now available. Send an email to webservices@momentumsi.com. In addition, we'll be putting the IBM ESB into the MomentumSI SOA lab as soon as we can. We remain committed to pushing vendors towards the next generation of standards and pointing out those that are stuck in the J2EE world.
Pop Quiz: WebSphere was the IBM J2EE/Component brand; What is the IBM SOA brand?
Tuesday, September 13, 2005
Sunday, September 11, 2005
It is time for WSEE
When I looked at open sourcing my stuff as part of an ESB - I quickly determined that the ESB had so many definitions (many of which didn't contain orchestration) - that the ESB had already crashed.
Modern software infrastructure is based on standards. Standards are grouped into profiles. Profiles are implemented and become products. I don't always like it - but that's the way it works. The ESB 'pick your standard' circus has demonstrated that our customers need more than marketing umbrellas.
We need architectural profiles.
The successor to the ESB MUST be profile based. Think RFC 2119.
Modern software infrastructure is based on standards. Standards are grouped into profiles. Profiles are implemented and become products. I don't always like it - but that's the way it works. The ESB 'pick your standard' circus has demonstrated that our customers need more than marketing umbrellas.
We need architectural profiles.
The successor to the ESB MUST be profile based. Think RFC 2119.
What is an ESB?
MomentumSI's Definition of the ESB:
"An ESB is a collection of platform specific (Java) API's front-ending a vast subset of the Web service protocols, formats and identifiers."
I almost forgot - I've been meaning to congratulate Sonic on inventing 'SOAP over JMS', also known as the ESB. Unofficially, MomentumSI has been predicting that the bus would crash since October of 2003.
Here is the really sad news: ESB isn't dead as a category. It won't die until a replacement category is created. In my humble opinion, the ESB 2.0 won't work. What is the replacement: The Enterprise Service Network? Application Oriented Networking? I don't know. What I do know is that in an unprecedented display of incompetence Gartner & Sonic took a shotgun to the ESB category and blew it away.
Annrai, Frank, Dan, Roman - uhh... what the hell are you guys waiting for??? I'm going to start referring to you guys as the "Ball-less-four".
"An ESB is a collection of platform specific (Java) API's front-ending a vast subset of the Web service protocols, formats and identifiers."
I almost forgot - I've been meaning to congratulate Sonic on inventing 'SOAP over JMS', also known as the ESB. Unofficially, MomentumSI has been predicting that the bus would crash since October of 2003.
Here is the really sad news: ESB isn't dead as a category. It won't die until a replacement category is created. In my humble opinion, the ESB 2.0 won't work. What is the replacement: The Enterprise Service Network? Application Oriented Networking? I don't know. What I do know is that in an unprecedented display of incompetence Gartner & Sonic took a shotgun to the ESB category and blew it away.
Annrai, Frank, Dan, Roman - uhh... what the hell are you guys waiting for??? I'm going to start referring to you guys as the "Ball-less-four".
Saturday, August 20, 2005
Open Source ESB - Apache Synapse
It appears as though the Apache ESB project, Synapse, is moving forward. According to InternetNews, Blue Titan, Infravio, WSO2, Sonic and Iona are all supporting it.
For those of you who aren't familiar with ESB's, Microsoft does a pretty good job of describing one in their position paper. They basically say that an ESB consists of:
- Orchestration & Transformation
- Intelligent Routing and Mediation
The heart of the current code base was donated by Infravio. However, it was quickly noted:
So, if I understand Dave correctly - Synapse has the routing and mediation but not the orchestration and transformation. Sounds like a problem! Perhaps I can help?
As of today - I am open sourcing our Orchestration IDE, BPEL engine and Transformation system.
But what good is an open source ESB if you can't get decent support? None! Sounds like a job for MomentumSI.
Done. Stay tuned. More to come.
For those of you who aren't familiar with ESB's, Microsoft does a pretty good job of describing one in their position paper. They basically say that an ESB consists of:
- Orchestration & Transformation
- Intelligent Routing and Mediation
The heart of the current code base was donated by Infravio. However, it was quickly noted:
Sonic Software itself an ESB vendor (as well as an initial committer to the Synapse project) said that Synapse wasn't a full blown ESB. "This project is related to ESB , but it is not in itself an ESB," Dave Chappell, Sonic Software's VP and Chief Technology Evangelist told internetnews.com,. "What Synapse bring to the table is a mediation framework that allows users to get in the middle between service requesters and providers and perform various tasks – including transformation and routing and that helps to promote loose coupling between services "
So, if I understand Dave correctly - Synapse has the routing and mediation but not the orchestration and transformation. Sounds like a problem! Perhaps I can help?
As of today - I am open sourcing our Orchestration IDE, BPEL engine and Transformation system.
But what good is an open source ESB if you can't get decent support? None! Sounds like a job for MomentumSI.
Done. Stay tuned. More to come.
Mark Baker Hates Architecting First?
Mark, "I won't rest until you REST", Baker kicks a bit of sand on architecture first.
Oh stop it Mark - you architect first, too.
MomentumSI recently finished a large transactional web system for a customer. The customer was a startup - and had NOTHING. Guess what - before writing a bunch of code, we gave them a "Web Architecture"; we talked to them about the ilities (scalability, integrity, availability, maintainability, etc.) We recommended the infrastructure: firewalls, routers, load balancers, operating systems, web servers, web analytic engines, etc. We also recommended some design patterns and some platform choices (J2EE, IoC/PoJo, SOA-IoC/PoJo, .Net, etc.) Then we talked to them about implementations. My point is that these are things that the company didn't have - and needed before a SINGLE LINE OF CODE WAS WRITTEN.
If you're an organization that is going to do SOA - you should go through a very similar exercise. If you haven't answered the SOA infrastructure questions - or architectural configuration questions and you just start building services you'll end up in a mess. It isn't: "you may end up in a mess" or "you might end up in a mess" - it is "you WILL end up in a mess". Closing your eyes to up-front architecture is a bad idea in web systems, SOA systems or just about any system you can think of.
So, in summary:
YES - "Projects and enterprises should define their Service Architecture FIRST". If you're going to do service based systems - do it within a basic architecture. This doesn't mean go off and architect until you're blue in the face. It means lay down the basic architecture - we did it for web systems - we'll do it for SOA systems.
Oh stop it Mark - you architect first, too.
MomentumSI recently finished a large transactional web system for a customer. The customer was a startup - and had NOTHING. Guess what - before writing a bunch of code, we gave them a "Web Architecture"; we talked to them about the ilities (scalability, integrity, availability, maintainability, etc.) We recommended the infrastructure: firewalls, routers, load balancers, operating systems, web servers, web analytic engines, etc. We also recommended some design patterns and some platform choices (J2EE, IoC/PoJo, SOA-IoC/PoJo, .Net, etc.) Then we talked to them about implementations. My point is that these are things that the company didn't have - and needed before a SINGLE LINE OF CODE WAS WRITTEN.
If you're an organization that is going to do SOA - you should go through a very similar exercise. If you haven't answered the SOA infrastructure questions - or architectural configuration questions and you just start building services you'll end up in a mess. It isn't: "you may end up in a mess" or "you might end up in a mess" - it is "you WILL end up in a mess". Closing your eyes to up-front architecture is a bad idea in web systems, SOA systems or just about any system you can think of.
So, in summary:
YES - "Projects and enterprises should define their Service Architecture FIRST". If you're going to do service based systems - do it within a basic architecture. This doesn't mean go off and architect until you're blue in the face. It means lay down the basic architecture - we did it for web systems - we'll do it for SOA systems.
Monday, August 15, 2005
Tim Bray Supports WS-*
Via Nick Gall.
Tim Bray did an interview and has asked his readers to draw their own conclusion, which I have: Sun customers have had to invent their own distributed computing solutions - on their own dime - and have created proprietary solutions. AToM tried to tell them for years but had little luck.
Questions and Answers with RouteOne
Q: How did you do Routing / Addressing?
A: We went proprietary - because we had to.
Q: How did you do Reliability?
A: We went proprietary - because we had to.
Q: How did you do Orchestration?
A: We went proprietary - we can't wait to get off of it.
Q: Do you put anything standard in the header???
A: Yes, WS-Security
Q: How do you do messaging?
A: Vendor specific; ubiquity via platform API - not protocol
--------------------------------------------
Now it is possible that I misunderstood the point that Tim was trying to make... but if I read it correctly, he has a customer that wants protocol ubiquity. The customer has real problems (transactions, correlated messages, reliability concerns, security concerns, performance concerns). He had to roll his own protocols (boo) and stated that he could have gone faster if he didn't.
I'm so happy that Tim found an enterprise customer that had real issues. Perhaps with the acquisition of SeeBeyond Sun will become a WS-Shop ;-) Gee - having a few protocols implemented sure can change your tune!!!
The funny thing is that my friends at IBM and Microsoft NEVER talk about SOA specs anymore. That's so 2003. Perhaps we should debate JBI (or not).
Tim Bray did an interview and has asked his readers to draw their own conclusion, which I have: Sun customers have had to invent their own distributed computing solutions - on their own dime - and have created proprietary solutions. AToM tried to tell them for years but had little luck.
Questions and Answers with RouteOne
Q: How did you do Routing / Addressing?
A: We went proprietary - because we had to.
Q: How did you do Reliability?
A: We went proprietary - because we had to.
Q: How did you do Orchestration?
A: We went proprietary - we can't wait to get off of it.
Q: Do you put anything standard in the header???
A: Yes, WS-Security
Q: How do you do messaging?
A: Vendor specific; ubiquity via platform API - not protocol
--------------------------------------------
Now it is possible that I misunderstood the point that Tim was trying to make... but if I read it correctly, he has a customer that wants protocol ubiquity. The customer has real problems (transactions, correlated messages, reliability concerns, security concerns, performance concerns). He had to roll his own protocols (boo) and stated that he could have gone faster if he didn't.
I'm so happy that Tim found an enterprise customer that had real issues. Perhaps with the acquisition of SeeBeyond Sun will become a WS-Shop ;-) Gee - having a few protocols implemented sure can change your tune!!!
The funny thing is that my friends at IBM and Microsoft NEVER talk about SOA specs anymore. That's so 2003. Perhaps we should debate JBI (or not).
Subscribe to:
Posts (Atom)
Posts
