Apache Synapse

I'm messing around with Apache Synapse. It's an open source mediation framework from Apache. It seems pretty straight forward to use. I was looking for a light weight mediation server to show capabilities and uses of mediation servers or intermediaries. I'm just starting out with it. I'm also looking at ServiceMix which is much more robust but a bit more complicated. It does mediation but a whole lot more like messaging for persistence which is very important in my mind. It's more of a full featured ESB type platform although it lacks the tooling associated with more expensive commercial products. LogicBlaze is based on ServiceMix which I hope to get too as well sometime in the future. Time is always an issue. My ultimate goal is to compare development efforts with more expensive platforms to that of open source solutions which are cheaper or free but have primitive tooling.

The Power of the Marginal

I've always liked Paul's essays. This one in particular is very good and pushes a lot of buttons. His quote "If most of your ideas aren't stupid, you're probably being too conservative. You're not bracketing the problem.", reminds me of something I tell myself and my daughter often. If you are not making mistakes then you are not in the game. It's easy to be perfect and safe standing on the sideline.

Still waiting for patterns

And now there are anti-patterns (saw this over at Sandy Kemsley's ebiz blog) for SOA. What happen to the patterns? I guess the anti of the anti-pattern is the good pattern. :)

Oracle Unveils Event-Driven Middleware Suite: Next-Generation of SOA @ SOA WEB SERVICES JOURNAL

I don't really care about this product from Oracle. They will probably just abandon it in about a year after they buy someone that does the same thing. But the interesting thing is the "SOA 2.0" mentioned in the article. It will be interesting to see if they can get this new buzzword version to gain traction. How much power does a big vendor like Oracle have? We will have to wait and see. There was a grassroots movement to try and stop this in the form of an online petition. I really think something like SOA .98 would have been more appropriate. ;)

SOA

This is coming to you from the beautiful Kiawah Island, SC. I'm still trying to figure out how to win the lottery so I can sit and stare at the waves all day. Okay back to SOA. Brenda Michelson has a conversation started on preparing the organization for SOA. There have been some discussion points brought up. Check it out and chime in.

Enter The JBoss Matrix

Ah the pace of the software industry. Hope you were not getting to attached to JBossESB. If you were I'm sure that there is grief counseling available from Redhat.

Ozzie takes top Microsoft software job - Yahoo! News

I'll be perfectly honest. I don't care for Microsoft products all that much. But the two men that are discussed in this article are pretty amazing individuals. I use to go to Lotus Notes conferences back in the early nineties and listen to Ozzie speak. It was well worth the trip. Ozzie is a very talented individual and the kind of person Microsoft needs. It is funny though because he use to bash the hell out of Microsoft during those talks.

Bill Gates who was blasted and vilified (remember the pie in the face) as a businessman is doing some pretty amazing things for the world's population. I doubt the vast majority of the folks who did the blasting have ever or will ever contribute to the greater good of the world as Bill Gates is doing. Some may argue that Bill obtained his money through ruthless business tactics but I think few can argue with what he is doing with the money.

How to rebuild an airplane.....

In-flight. That's the trouble I sometimes see with IT architecture. Rarely are we given the luxury of rolling out a new model. Instead we have to rebuild or replace components of complex architecture while it's still in use. I like the analogy of replacing the aircraft engine while the plane is in-flight. A pretty impossible task I would say.

That's why building the architecture on a solid foundation is so important. Of course that is easier said than done in the real world. The real world is full of demanding clients, tight deadlines, tight budgets and applications/infrastructure that have to be up almost all the time. Of course the other big problem is that we are not perfect. Sometimes the right architecture at first is not always the right architecture later on. Ever remodel a house? Sometimes your needs change beyond what the house is capable of providing. Sometimes it's as simple as adding a room while other times it calls for more drastic measures like tearing out foundations, walls and other large things (not to mention the portable toilet that sits out front of your house for months).

The big promise of a SOA style of architecture is the potential to handle change better. If done semi-correctly, large destructive remodeling should not be as frequent or necessary. How to do it semi-correctly? That's the million dollar question. Let's explore that more in future conversations.

ACM Queue: Interview with Amazon's Werner Vogels on Services, SOA, and Business Innovation - Business-Driven Architect - ebizQ

Another good article from Brenda Michelson and a good interview from ACM Queue with Amazon's CTO. It's about Amazon and the possible nirvana of computing.

Wary of Analysts

Most folks who work in an IT shop for a non-technology oriented company know all about the impact IT industry analyst can have. Upper management much to the angst of the architects and senior tech leads, depend on these analysts for advice or opinions. Whole projects can be derailed from a simple comment from an "expert". Entire IT industry movements can be started from these opinions from some of the more powerful analyst.

Technology vendors are not immune to the affect either. Most vendors of size have to spend time and money coaching the analyst on their products, market presence and viability. Do you think the amount of effort the vendor spends with the analyst is linked to the opinion of the analyst? hmm...I often wonder.

My own personal experience is that a lot of analysts don't have the background to render the opinions they are giving. Most have not done any significant work in real IT shops or it is so dated as to be not relevant ( I really don't care that you use to drop your Fortran punch cards). There are exceptions though and it's important I think to understand those. There are some good analysts out there.

When an analyst comes to visit or you are tied into a conference call with one, make sure you get them to explain their own experience with the technology they are rendering an opinion on. In other words if they have never actually implemented an "ESB" (and who has?) at a real company or if they have never actually integrated anything other than maybe some pasta with the sauce then chances are their opinions are entirely academic.

There is nothing wrong with getting those types of opinions as long as everyone understands and they are presented as academic. One final thought, make sure you understand the analyst's opinion on a given subject before they get in front of your management. Otherwise you may find yourself in a less than fun situation.

Distributed in a box (DIB)

Okay so I just made up a new acronym. I am speaking EAI terms today but it also applies to SOA (At least it should or could maybe I don't know). EAI architecture can come in many flavors. Some examples would include fully distributed, hub and spoke, bus, fully centralized or some combination of them all. This mainly has to do with where you place your software components including messaging components, enrichment services, business logic etc. A lot of influence will come from the vendor and how they have architected their platform. Another influence will be the skill set and maturity of the IT organization. Fully distributed is more difficult to manage while fully centralized is easier to manage. Or is it?

One lesson that I have learned the hard way is that a fully centralized architecture can quickly become very difficult to maintain. This is especially true if you experience a lot of early on success and start growing rapidly. What kind of problems you ask? Maintenance including patching, upgrades, code deployments and application co-dependencies where adequate separation of services has not been done (of course distributed can have this problem too).

The concept I'm getting to here is loose coupling. It really becomes very important with large environments with lots of services. This term has been around for a while in the EAI space (and now in the SOA world). It's not only how you distribute your components but how those components relate to and or depend on each other. The more dependency, the more brittle the architecture becomes. Of course in reality this is not always as easy to achieve as folks might think.

There are some contributing factors that can stall a distributed architecture. 1-The cost of the software that you have to deploy. Large environments with lots of endpoints can quickly add up if you are being charge by the processor. 2-The management instrumentation of the software. Was it designed with distributed administration in mind? Do you have to log in to a hundred different endpoints to manage the infrastructure? 3-Ownership of target systems. Yes believe it or not sometimes getting software installed on systems is difficult when you don't own them. Or the software is not considered a core part of the system. 4-And of course your developers ability to architect their solutions in a loosely coupled way. Once again the maturity of your organization can play a big role in that.

There is no clear cut answer to all of this. These decisions will always have to vary by company. I think the more distributed you can become, the more reliable and less brittle you infrastructure will be.

So what is DIB other than something I just made up? It's the concept of distributing your architecture within a centralized server cluster. You get some of the benefits of a centralized architecture while also getting some of the benefits of a distributed architecture. It is by no means a perfect solution but it does help overcome some (but not all) of the inherent problems with a centralized architecture and a fully distributed architecture. And we all know of course that architecture is all about trade offs.

New Links

I've added some new links to the site. Check them out under Enterprise/Integration Architecture on the right. These folks have real experience in this space and have a lot of valuable insight.

How to open source Java? That is THE question. | Between the Lines | ZDNet.com

David Berlind has an excellent post on the Open Sourcing of Java. He touches on a lot of points with Open Source in general as well as the particulars of Java. The particular area that hit home with me is compatibility. He used Linux as an example. The main point there was that there really is not guaranteed compatibility between distributions. And that migrating off one distribution to another has a lot of potential issues which most customers would shy away from. So much for avoiding lock in.

I'm a fan of Open Source software. However achieving vendor independence is not a trivial task. The act of just selecting Open Source software does not provide that independence.