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:

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.

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).

Service Network Newsletter

The August edition of the Service Network Newsletter is available.


Enjoy.

SOA Boot Camp

After months of work, we're finally kicking off our SOA Boot Camp. MomentumSI consultants will be immersed in 17 days and nights of non-stop SOA education!

You name it - it made it: registries, repositories, governance, mediation, orchestration, composite applications, SO security, SO-BAM, legacy enablement, WS-I & WS-*, Indigo, Axis, SOBA, ESB, SOA reference architectures, SOA reference models, SOA process / methodology, SOA best practices, service analysis & design, XML message design, reuse metrics and more.

We have also signed up many of the leading SOA companies to provide vendor specific training on their best-of-breed products by their local gurus. After we run it internally a couple times we will be taking SOA Boot Camp to our customers.

SOA is a fundamentally different computing model - we've realized that the 2 and 3 day training just doesn't cut it. Let's hope that 17 gets the job done.