What The Heck Is SOA Anyway?
SOA stands for Service Oriented Architecture. SOA (or any distributed architecture for
that matter) is just a tool with proper usages and popular misuses. In the words of Pat
Helland, Microsoft Architect, “SOA is about HST (Hooking Stuff Together)”.
There have been many stabs at this kind of technology and the related technology of
distributed architectures, CORBA being the prime example. However because of the
relative complexity and lack of computing power (in addition to some serious basic
architectural flaws), CORBA was abandoned before it was ever really used. Other
example of SOA concepts can be found all over in modern computing implementations;
HTTP is a service, DLLs provide “services”, even a Stored Procedure can be considered
as a computer language neutral service.
How Are SOA and ESB Related?
To answer to this question, a relationship familiar from standardized tests will be used –
Enterprise Service Bus is to Service Oriented Architectures as Java is to computer
languages. ESB is an implementation of an SOA in the same way that Java is an
implementation of a computer language. It is also commonly said that Java is a
computer language; which means that it is proper to say that an ESB is a SOA. Whether
it is the best SOA is similar to the argument about whether Java is the best
programming language. Java is really good for some stuff, but not as good for other
stuff (Windows GUI development being an example that readily comes to mind).
An Important Point
No matter how well designed a system may be, at some time it will become so brittle
that major effort should probably be placed into re-architecting the whole system. Ten
years of enhancements and bug fixes are enough to make the basic architecture of most
software systems obsolete. When you add to this the major changes that occur in the
Software Engineering field every three to five years, you can easily see why a product
needs major rework after some time of just existing.
I am not advocating that any working system should be completely rewritten from
scratch. In many cases it is wiser to take a more evolutionary approach of creating a
new architecture and then re-engineering various parts of the system using a stepwise
approach. This allows for building upon success, learning from mistakes and exposing a
deliverable system to a lot less risk.
The important thing to realize in all of the hype surrounding SOA (and WOA, which is
Web Oriented Architecture) is that they are not magic bullets; SOA cannot save the
failings of a product that badly needs re-architecture.
In regards to proper use of SOA, as pointed out by Joshua P., if an entire product were
written in a single programming language, the need for an SOA would be largely
eliminated. HST is about hooking different stuff together, not stuff that can talk to each
other using other, more native, means.
SOA Comes With a Price
SOA comes with a price; the cost is increased complexity and decreased performance.
SOA may give you loose coupling by design, but this can also be achieved (maybe even
more easily), by proper application of software engineering techniques.
An example of where SOA really gives power is in the idea of reusable “services” (think
of services as functions if you are more comfortable with that idea). Reusable services
would be expected to be reused across multiple implementations. An example would be
a lookup service that could be used by a GUI program, a web page and an EDI process.
If the service is never intended to be used by multiple consumers (think of this as calling
programs if you are more comfortable with that idea) the service would be better
written in the native language of the consumer.
SOA Does Not Replace (or Create) Good Architecture
This does not mean that if a service is not used by multiple consumers that it should just
be embedded into the consumer code. This is pretty well accepted as being bad design.
When you stick SQL code into GUI code, you are mixing in a lot of stuff that will
probably end up all working pretty badly in a very short time. Separation of interests,
loose coupling and encapsulation are all ideas with which everyone should be familiar.
These are not marketing buzzwords; they are concrete concepts that work really well
when properly applied.
Also, keeping the big (or bigger!) picture in mind, it may be possible that a set of
functions created for a high volume data-entry system may also be very useful in some
future web based application created for a casual data-entry solution. That is the point
of the concepts mentioned above; done properly they enable maximum reuse and
I cannot speak for what I have not personally experienced, but I have worked on
various projects over a period of ten years that have been based on those concepts and
were able to be maintained and extended without making the code brittle. This in itself
makes a believer out of me, especially since I have worked on other projects where the
code became brittle before it was even first released. You as the reader may need
convincing; unfortunately I cannot supply that for you – probably only personal
experience with successful projects and projects that have failed can do this.