Embedded Files
Posted by Uncle Bob on 10/21/2007
Many companies are thinking about adopting SOA as a way to reduce the cost of enterprise development. The thought of diverse and reusable services, effortlessly communicating through an intelligent Enterprise Service Bus is a powerful siren song for executives who see their development and maintenance budgets spiraling upwards. What’s more, vendors are displaying savory looking wares that promise to ease the transition.
Caveat Emptor!
The reality is that cramming an old and rickety enterprise system into services that communicate over a complex buss, is not an easy job. The long and short of the problem can be seen in the following catch-22:
The benefit of SOA comes from the decoupled nature of the services. But in order to create an SOA you have to decouple your services.
Decoupling your services is the issue. Once you have decoupled them, then all the wonderful tools might be useful in facilitating an SOA. On the other hand, if you have decoupled your services, you probably don’t need all those wonderful tools.
I have a client that has implemented SOA to good effect. They avoided the vast majority of the tools. For example, they are not using a big expensive buss. They aren’t using a BPEL engine, or message translators, or routing services. About the only thing they have decided to use is SOAP.
They are creating their services from scratch, and wiring the system together manually. Each service knows where each of it’s client services is. There is no registry service, no common dictionary, no fancy routing.
The system is simple, elegant, and it works. It was designed to work from the start. It is not an old crufty system crammed under a soap layer and called a service provider. Rather it is a nicely arrayed suite of services that were designed to work together from the get-go.
And that’s really the moral of the story. If you want an SOA, you are going to have to design that SOA. It is not very likely that you will be able to cram you old, tightly-coupled code below SOAP interfaces and hope to gain the benefits of services. What you’ll more than likely end up with is just a bigger mess.
Comments
[email protected] 10 days later:
Any thoughts on what approach you might take should you need to incorporate COTS packages into an SOA? Does the fact that you would be forced to cram someone elses app under a soap layer cause you to abandon that approach or are there lessons learnt that can apply to that approach all the same?
Daniel Parker 20 days later:
Bob,
I thought I’d check this site out to see if there was any evidence of your continued existence, given the little vacuum that was created when you left comp.object!
Anyway, on the subject at hand. There are two sides to SOA. On the one hand, it’s about marketing and sucking as much money as possible out of big corporations. And on the other hand, some of it actually makes sense.
Big corporations have a large number of dispersed IT assets. Efforts to centralize, rationalize or rewrite these assets often end up as very expensive failures, it’s just too hard a problem, there’s just too much stuff out there, the track record is not good. The alternative strategy of identifying existing assets and wrapping them in a web services layer, opening them up across the enterprise, has a lot to recommend it. Focusing on providing interfaces to existing IT assets delivers benefits to business users much faster than focusing on building replacement IT assets.
—Daniel
GerardV 2 months later:
I would like to know 2 things…
1st, why does it always seem like the head of a company who has to be a pretty smart business person are constantly being duped into these IT scams when if it were anything else they’d see right through it!?? I mean, take your first paragraph for example:
“Many companies are thinking about adopting SOA as a way to reduce the cost of enterprise development. The thought of diverse and reusable services, effortlessly communicating through an intelligent Enterprise Service Bus is a powerful siren song for executives who see their development and maintenance budgets spiraling upwards. What’s more, vendors are displaying savory looking wares that promise to ease the transition”
They are giving away untold amounts of money to someone or some company just for the idea of saving money in the future! They lose all sense of common sense when it comes to something they probably don’t know anything about, and then if it actually gets implemented on time and on budget, don’t they know that they’re still going to have to pay their IT staff to maintain and most likely customize it after it’s done? Which leads me to my 2nd question…
Who is this client of yours that did the whole the right way and are they hiring? Sounds like a great company to work for in IT! :)
Alistair Cockburn 3 months later:
Hi, Bob – Nice set of blog/article postings!
I was asked whether or not I agree on the SOA posts (which I do, very much), and from there I started poking around and got lost reading for a long while. Enjoyed (and agree with) the Active Records v. Objects post (http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects) ...
Just a month ago, my friend and I just started creating a new personal site content system. Along the way I created somewhat off the cuff a particular DB design to handle a particular subclass. Some time later we were talking about porting the system from .NET to RoR, and his first comment was that our mapping wouldn’t work with Active Record. When I look at the two choices, I’m much more sold on our custom mapping, and happy we’re not using Active Record.
Yes, Active Record would indeed work, and Yes, all DB-OO is safely encapsulated in its own layer so it doesn’t leak, but still, using Active Record across subclass hierarchies does give me a bit of the creeps.
...Always recalling, of course, that the whole point of RoR with its Active Record implementation is to allow programmers to put up Stuff, Fast!
As one programmer put it to me way back in the mid ‘90s – “You are painting a Persian miniature with a single-haired brush – My job is to throw paint on the wall as fast as I can!”
In all cases, lovely site, nice writing!
Alistair
logo designs over 3 years later:
Reflecting on what you can do if you need to incorporate the packages available in a SOA? The fact that you'd have to squeeze someone else application under a layer of soap you waive this approach or are there lessons that can be used to meet all the same?
cheap vps over 3 years later:
I thought I’d check this site out to see if there was any evidence of your continued existence, given the little vacuum that was created when you left comp.object!
Anyway, on the subject at hand. There are two sides to SOA. On the one hand, it’s about marketing and sucking as much money as possible out of big corporations. And on the other hand, some of it actually makes sense.
Big corporations have a large number of dispersed IT assets. Efforts to centralize, rationalize or rewrite these assets often end up as very expensive failures, it’s just too hard a problem, there’s just too much stuff out there, the track record is not good. The alternative strategy of identifying existing assets and wrapping them in a web services layer, opening them up across the enterprise, has a lot to recommend it. Focusing on providing interfaces to existing IT assets delivers benefits to business users much faster than focusing on building replacement IT assets.cheap VPS
craigslist reviews over 3 years later:
Great blog.thanks for sharing valuable information.The concept of SOA is that many companies are thinking about adopting SOA as a way to reduce the cost of enterprise development. The thought of diverse and reusable services, effortlessly communicating through an intelligent Enterprise Service Bus is a powerful siren song for executives who see their development and maintenance budgets spiraling upward.You are doing great work.keep it up!
Alina's List over 3 years later:
Its really awesome post about SOA.But one thing that an important challenge for adopting SOA, is the message exchange. Depending on the design, a single application may generate too much messages,In fact millions of messages.On this stage information management or service management may become complex
Page updated
Google Sites
Report abuse