“If you aren’t technical, [SOA is] one of those terms that flies right over your head.”, explains Don Fornes, Founder & CEO at Software Advice; not to mention the added complexity of a slew of related acronyms such as “SOAP, XML, CORBA, DCOM, .NET, J2EE, REST, BPEL and WS-CDL”. In his article he tries to demystify the concepts around SOA.
In an effort to present SOA in simple English he proposes a colloquial definition of SOA:
A new and better way to get a bunch of different software programs to work together so people can do things that require information from each of those systems.
Don describes SOA as an information technology (IT) equivalent to managing a large, diverse workforce. He says
To get stuff done in a big organization, you need to:
- carefully define your goals and what constitutes success;
- draw on the unique talents and knowledge of each individual;
- get people to speak the same language and work together as a team; and,
- measure where things stand and whether success is achieved.
All of which he says are characteristics of an SOA to deliver a successful IT solutions.
It catalogs what systems are in place and what they can do (e.g. what data they own). It specifies a common language that they can all use to communicate, even if this common language is not each system’s “native tongue.” With those components in place, the organization can build new applications or processes that make use of the multi-system integration. Finally, a SOA coordinates and monitors the processes that span these systems.
He acknowledges that SOA is nothing more than an integration of disparate systems but goes on to list the benefits that differentiate an SOA from traditional/point-to-point integration.
- It’s now much easier to integrate systems.
- It […] manages and monitors complex processes that require multiple systems to work together in real-time
- It […] defines standards for writing the next generation of systems so that the SOA vision is easier to achieve as the IT landscape evolves.
He goes on to expand on the metaphor of managing a large and diverse workforce. He outlines key concepts in SOA and their significance and how they relate to the workforce metaphor. Below are a few of the concepts with their description and respective equivalents.
Loosely coupled
Loosely coupled refers to the idea that services within an SOA can provide that service to multiple applications, not just one specific application. This is similar to a workforce where employees work with different teams or departments, depending on what needs to get done. They are not restricted to working for one boss or one department.WSDL
Web Services Description Layer (WSDL) is an emerging metadata standard for describing what each service does. Think of it as a language for describing all of the roles and responsibilities within an organization. While we can use English to describe employee roles in the workplace, computer systems require their own language to describe each service's role.Reusability
One of the goals of SOA is to make application development easier and easier over time. Toward that end, you want each service - new or existing - to be reusable in the future. It is similar to seeking to retain your best employees to leverage their skills over and over again on many different projects throughout their careers.Compositability
Compositability means that services can be joined together to create bigger services that perform more sophisticated applications. That combination can then serve as a service itself. This is similar to building a great team of employees where the whole is greater than the sum of the parts. You would be inclined to put that team on new projects again and again.Autonomy
Autonomy means that each service does what it does best in the manner it sees fit. You want to take advantage of the service's output, not dig into how the service accomplished what it did. If you do dig into how each service does what it does, you lose the SOA ideal of simplicity. It's a lot like letting your best employees do what they do best rather than micromanaging them.
Don warns that though all the concepts seem good in theory, the real crux of effective SOA is in the execution. He asserts that SOA is still in its early stages and comes with challenges surrounding latency of services, nascent standards and getting autonomous systems to speak a canonical ‘language’.
There is certainly reason to consider all of these issues. However, SOA is supported by a huge industry filled with developers that want to see its vision realized. Even if SOA is not a magic bullet, there is tremendous value to working toward the SOA vision and achieving just some of its ideals. The model holds great promise and provides a roadmap for moving beyond historical IT integration and development challenges.
More of the excerpted post can be read at the Don’s website.
Community comments
Oh how soon they forget...
by John Reynolds,
Sounds good on paper
by Umesh Rajbhandari,
Re: Sounds good on paper
by James Watson,
Re: Sounds good on paper
by Umesh Rajbhandari,
Re: Sounds good on paper
by James Watson,
WSDL is emerging?
by James Watson,
Oh how soon they forget...
by John Reynolds,
Your message is awaiting moderation. Thank you for participating in the discussion.
SOA Elevator Speech: January, 2005:
weblogs.java.net/blog/2005/01/06/soa-elevator-s...
Sounds good on paper
by Umesh Rajbhandari,
Your message is awaiting moderation. Thank you for participating in the discussion.
Disadvantages of SOA:
1. Creating and maintaining a service that satisfies the requirements of multiple applications is extremely difficult. It is much simpler (and recommended) to code of each application. Besides faster coding (because of simplicity) there is no risk of side effect as the service does not need to be modified for another application.
2. Increases development time as the design is overly complicated as we need to satisfy the requirements of multiple applications. Consequence of this is the time to market is increased and opportunity cost is incurred.
3. Response time is slow. Usually web services use WSDL and involved transformation of data from program objects to xml then back to program objects (which is resource intensive and slow). On top of that some organisations use ESB which just increases one hop in the process and makes the response time even worse.
WSDL is emerging?
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
WSDL has been around for nearly 10 years. If it hasn't emerged yet, it ain't gonna.
I cringe every time I see one of these "SOA in straight-shooter talk" posts and WSDL is mentioned. WSDL is not part of the definition of SOA! It's a technology that a lot of people use to implement SOA (mostly unsuccessfully.) You can use WSDL and not do SOA and vice-versa.
The fact of the matter is that WSDL has a lot of problems and in my opinion creates more issues that it solves. But the really big problem is that by focusing on this poorly designed specification you cloud the message of the point of SOA.
Re: Sounds good on paper
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
While what you are referring to is real, you miss the point of SOA. SOA is not about satisfying the needs of different applications. It's about representing what a business does as services. A big misconception of SOA is that it's primarily about reuse. Reuse is of very low importance. It's not a core goal. Reuse is a happy (and largely unpredictable) side-effect of a well implemented service oriented architecture.
True to some extent but if well designed services are in place, they can speed time to market.
WSDL is (should not) be used in runtime calls to web services. As I said above WSDL is a blight on SOA but what you say here doesn't make much sense to me. For the rest of it, I've never seen any of these be the primary cause of slow services. Usually, the slowness is caused by bad design e.g. messages are too large, excessive memory allocation, lack of streaming of data, bad joins, etc. The things you point too are usually just the excuses given by developers who don't understand why their code is slow. For example, I recently was involved in a project that moved a hibernate/jax-ws service to an ESB and the average response time was improved by more than 20% on the same hardware.
Re: Sounds good on paper
by Umesh Rajbhandari,
Your message is awaiting moderation. Thank you for participating in the discussion.
Different people have different opinions about what is SOA, therefore there are more disagreements than agreements. If you look at the 'loosely coupled' section of this article it mentions about re-using services from multiple applications. It is fine if the services are very generic but would introduce more complexity than it solves if the requirements for each application varies from others.
While I agree that applications should be well designed, I do not agree with the notion that applications can be faster by introducing ESBs. Usually ESBs are installed and maintained separate from the applications. Let's say you want to make a call from your application to the mainframe, would it be faster calling the mainframe directly from your application or using an ESB? If you use the ESB, your application calls ESB then ESB calls the mainframe. The response also comes via the ESB. ESB introduces one extra hop where marshalling and unmarshalling cost (in most of the cases expensive cost) is incurred.
Re: Sounds good on paper
by James Watson,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree there are many different ideas about what SOA is and that's the biggest problem with SOA. Given that there is a body of work that describes what is and isn't SOA in exacting detail (see Thomas Erl) there should be no reason for this situation to exist. A term with no clear definition is not very useful for communication. For this reason, I refuse to accept any explanation of SOA that deviates from the standard definition. It's fine to talk about other ideas, we just don't call them SOA.
And putting in a call to a logger will make a method slightly slower. It almost never matters, however.
I'm not suggesting that an ESB makes things faster in a single execution. What I am saying is that the overhead is generally not significant. Our ESB adds less than 100 milliseconds to a transaction (on average.) If this extra 100 milliseconds can't be tolerated, then it's not likely that services are going to work at all. A well-designed message-based ESB can also better utilize resources for improved scaling.
What I am saying is that all the performance problems I've ever solved were fixed by correcting design issues. There are times when a specific architecture is not appropriate but this is not one of those cases. In the specific case I referred to above, the extra overhead of the ESB was far less than what was saved by eliminating memory hogs such as JAXB and hibernate.