What is SOA, really?
Posted by Uncle Bob on 04/11/2007
The good news is, you probably already know. The bad news is, you probably know too much. This article describes Service Oriented Architecture in a simple and easy to understand way that is devoid of buzzwords and vendor spin. It’s the introduction to SOA that you haven’t been able to find anywhere else.
There are things in a business that don’t change very often. Gas stations in the U.S., for example, still sell gasoline by the gallon. Restaurants still sell meals from a menu. Dentists still sell cleanings every 6 months. Every business has these aspects that don’t change very frequently. They often represent a huge part of the business. We’ll call these things the _core business functions.
There are other things in a business that change very frequently. Prices, tax rates, catalogs, new products, new marketing campaigns, advertising, new business areas, new customer areas, etc. Indeed, businesses must be able to change, and change quickly, in order to survive. And yet, it is vital that those changes do not adversely affect the core business functions.
Software developers have known for years that software that changes frequently should be decoupled from software that changes infrequently. When applied to individual programs and systems this principle is sometimes called The Common Closure Principle. When it is applied to the information management of an enterprise, it is called SOA.
SOA is the practice of sequestering the core business functions into independent services that don’t change frequently. These services are glorified functions that are called by one or more presentation programs. The presentation programs are volatile bits of software that present data to, and accept data from, various users.
To make this clear, imagine an internet store-front. Customers use a browser to talk to the presentation software that displays the store’s website. The presentation software interprets the gestures of the customer and invokes services that do things like acquiring the data for the current catalog, or registering the customer’s order. Note that the services have no idea they are talking to a website. They could just as well be talking to a thick client, or a 3270 green screen. They simply accept and return data in a standard format that the web system happens to be able to use.
That’s really all there is to it. The rest of SOA is just a matter of details. At the highest level, SOA is nothing more (and nothing less) than separating changeable elements from unchangeable elements. But why is this important?
Consider that internet store-front again. It presents the user with a catalog, allows the user to move items into, and out of a shopping cart, and accepts the eventual order. The presentation of these concepts is very volatile. Marketing people are likely to want to change it frequently. For example, they might want to change from a shopping cart metaphor to scrollable receipt on the sidebar. They may wish to present more or less descriptive data in the product list. They may want to experiment with different colors, font-faces, and layouts. Indeed, it’s feasible that they’ll want to try applets, JStart clients, Ajax, and a myriad of other presentation options. But none of this has anything to do with the core business functions encapsulated by the services. Those services that acquire catalogs and register orders remain unchanged despite all the presentation thrashing. That’s why the separation is important. It protects the information processing assets of the business from the constant jitter and spin of the presentation.
But presentation is not the only thing that jitters and spins. So do the business processes. Again, consider our store-front. Perhaps our business has decided to offer fine wines as one of the products it sells. Selling alcohol requires that the age of the customer be verified. Let us say that we have a service that provides this verification. This service must be called for any order that contains alcohol products. The decision to call this service is neither a presentation decision, nor a service decision. Rather it is part of the business process for a particular kind of order. Business processes are volatile and they breed like rabbits. As businesses evolve they add more and more steps and forks to their business processes. The services being used by those processes don’t change much; but the pathways through the processes do. Therefore we want to separate the business process from the services and from the presentation. Smalltalkers had a name for this separation when it appeared in a single program. They called it Model-View-Controller.
Notice that we have yet to mention even one of the plethora of technologies that are so commonly associated with SOA. That’s because SOA is not about any particular technology. Rather it is a design philosophy that decouples well heeled business functions from volatile processes and presentations. It is the MVC of enterprise software.
In my next blog on this topic, we’ll look at the next level of detail in an attempt to understand HOW services can be constructed, and how the decoupling of presentation, process, and functions can be achieved.
Comments
t_r_siri@yahoo.co.in about 1 hour later:
Actually SOA is Service Oriented Architechture. This kind of architechture is used for prototype model. whatever explained above about SOA. those requirements are continously changing and for the continous changing requirements we are going to use prototype model and for that model architechture may used is SOA.
anonymous@hotmail.com about 3 hours later:
That sentence caused an “out of stack space” error t_r_siri.
orcmid about 4 hours later:
Nice treatment around the connection of SOA and separation of concerns.
The link to the “What is OOD?” material is terrific. I’d not seen that before, and here I’ve been fumbling around doing it on an ad hoc basis. Now I can recalibrate against a disciplined view of it. Great stuff.
lumpy 2 days later:
I’d go even further and say that SOA isn’t just “separating changeable elements from unchangeable elements” but separating as many things that can logically/functionally be separated, regardless of whether they’re changeable or not. Having the different pieces separated allows you to more easily test them, develop them, modify them, run them on different servers, etc.
To use your on line store example, I can think of many parts that can be separated, regardless of whether or not they change: product upload, product management, order downloads, customer management, customer list download, the shopping cart (adding and removing items), product presentation, shipping options management, and so on.
1073X 9 days later:
It is a good idea that “separating as many things that can logically/functionally be separated”. But there would be some problems to make them working together.Give it a rule is helpful.Perhaps, SOA.
Larry Guger 16 days later:
Well done, however I would like to clarify on the early example used such that although the price of gasoline may change frequently the need to retrieve the price of gasoline would be a core business function. The reason I want to make this distinction is to not confuse the benefits of a service to provide consistent, reasonably stable functionality with the inconsistent, unstable information that the service provides.
Quite often a stable service is particularly useful for serving up often changing data to promote consistent data across the enterprise. This moves an enterprise closer to “one version of the truth”.
nqdq@hotmail.com 19 days later:
It occurs to me that the more that is explained about SOA and what it means to the IT Systems Architect, the less I believe that there is anything new about it all.
As I was walking with my girl friend last Friday morning, I reminded her that she is my “Dream Angelâ€. She replied that I should consider raising my “standards a bit higherâ€. Of course, I was confused and I still am. If she really IS my everything, then how can I raise my “standards†any higher? It’s not possible!
SOA is like my dream angel (you are telling me), then why am I as a long time systems architect confused about what is being said here? In my opinion, there is nothing new here, just a redefinition of what we have been doing the last twenty years I’ve spent as an Systems Analyst, implementing routines that are reusable and common in applications.p.s. I am in love with my dream angel.
chuck_forbes@hotmail.com 20 days later:
Perhaps we’re operating on a smaller scale in my state agency, but I haven’t been able to comprehend why I would need to create re-usable components – with Web Services. We build re-usability when we need it, but it’s usually within objects at the database level, and all of our software tools can access the database. Am I planning for the possibility that we may replace the database, so I should be pro-active and replace it with a technology (Web Services) that may also have an uncertain future?
Plus, I’m always wary when I read articles on the miracles of SOA and a large company is mentioned where they’ve implemented “over 70 Web Services”. 70? For a large company? That sounds like it’s either tough to design, implement, or even devise, a Web Service.
-=cf
ramacosta@prodigy.net.mx 3 months later:
Great stuff! Your explanation is by far the simplest I’ve seen about SOA. I partially agree with nqdq@hotmail.com about that there is nothing new about SOA. I think the approach is not new. In fact, I’m sure it is the ever-dream-enviroment for any developer, but the difference is that today is achievable and was not just a few years ago. The real challenge is about taking really the advantage of this era and have the ability of developing really SERVICE ORIENTED products.
mallesha_dh@yahoo.co.in 4 months later:
It seems to more about MVC architecture rather than SOA.
nehmek07@yahoo.c.in 4 months later:
Very simple and Great explanation.
Adding to it, SOA is move towards creating reusable components at enterprise-level, irrespective of applications and different business aspects. Later this can be thought of world-wide components across Industries, business and domains… etc.,
benjose@hotmail.com 5 months later:
A very good blog on SOA, which emphasizes the need to seperate the main business functions from the dynamic fluffs that get added/substracted from time to time. I wonder if the concepts of each function being a service, evolved from earlier concepts like CORBA or COM or DCOM itself. -Ben
jessn 5 months later:
SOA is an abbreviation for “Service Oriented Architechture” (as mentioned in one of the other comments). It is in the matter of fact old wine poured into new bottles. Such an architecture has existed for several years, but it has not been widely accepted among R/D organizations for very long.
Conor Moran 5 months later:
After reading the article, one thing that I think needs clarification is: “SOA is the practice of sequestering the core business functions into independent services that don’t change frequently.”
Why is it important that the services are independant given that the services don’t change frequently? I guess independent means that the services should be “loosely coupled” and I think that most SOA definitions I read require this, but it doesn’t seem very important in your article…
Nags 6 months later:
Learn About All Things SOA:: SOA India 2007:: IISc, Bangalore (Nov 21-23)
Aligning IT systems to business needs and improving service levels within the constraints of tight budgets has for long been the topmost challenge for CIOs and IT decision makers. Service-oriented Architecture (SOA) provides a proven strategy to clearly address both of these objectives. Creating more agile information systems and making better use of existing infrastructure are two leading factors that are boosting SOA adoption across large, medium, and small Indian industries from the BFSI, Retail, Telecom, Manufacturing, Pharma, Energy, Government and Services verticals in India. If you are an IT decision maker belonging to any of these verticals, SOA India 2007 (IISc, Bangalore, Nov 21-23 2007) presents a unique opportunity to gather cutting-edge business and technical insights on SOA and other related areas such as BPM, BPEL, Enterprise 2.0, SaaS, MDM, Open Source, and more.
At SOA India 2007, acclaimed SOA analysts, visionaries, and industry speakers from across the world will show you how to keep pace with change and elevate your IT infrastructure to meet competition and scale effectively. The organisers are giving away 100 FREE tickets worth INR 5000 each to the first 100 qualified delegates belonging to the CxO/IT Decision Maker/Senior IT Management profile, so hurry to grab this opportunity to learn about all things SOA. You can send your complete details, including your designation, e-mail ID, and postal address directly to Anirban Karmakar at anirbank@sda-india.com to enrol in this promotion that is open until 12 October 2007.
SOA India 2007 will also feature two half-day workshops on SOA Governance (by Keith Harrison-Broninski) and SOA Architecture Deep Dive (by Jason Bloomberg). If you are an IT manager, software architect, project leader, network & infrastructure specialist, or a software developer, looking for the latest information, trends, best practices, products and solutions available for building and deploying successful SOA implementations, SOA India 2007’s technical track offers you immense opportunities.
Speakers at SOA India include:
• Jason Bloomberg, Senior Analyst & Managing Partner, ZapThink LLC
• Keith Harrison-Broninski, Independent consultant, writer, researcher, HumanEdJ
• John Crupi, CTO, JackBe Corporation
• Sandy Kemsley, Independent BPM Analyst, column2.com
• Prasanna Krishna, SOA Lab Director, THBS
• Miko Matsumara, VP & Deputy CTO, SoftwareAG
• Atul Patel, Head MDM Business, SAP Asia Pacifc & Japan
• Anil Sharma, Staff Engineer, BEA Systems
• Coach Wei, Chairman & CTO, Nexaweb
• Chaitanya Sharma, Director EDM, Fair Isaac Corporation
A partial list of the sessions at SOA India 2007 include:
• EAI to SOA: Radical Change or Logical Evolution?
• BPEL: Strengths, Limitations & Future!
• MDM: Jumpstart Your SOA Journey
• Governance, Quality, and Management: The Three Pillars of SOA Implementations
• Building the Business Case for SOA
• Avoiding SOA Pitfalls
• SOA Governance and Human Interaction Management
• Business Intelligence, BPM, and SOA Handshake
• Enterprise 2.0: Social Impact of Web 2.0 Inside Organizations
• Web 2.0 and SOA – Friends or Foe?
• Achieving Decision Yield across the SOA-based Enterprise
• Governance from day one
• Demystifying Enterprise Mashups
• Perfecting the Approach to Enterprise SOA
• How to Build Cost Effective SOA. “Made in India†Really Works!
For more information, log on to http://www.soaindia2007.com
Comment1 6 months later:
This article is very well written. the emphasis here seems to be around re-usable code/applications. The main difference is that formerly, applications were all being written purely in OO type languages, but with the advent of Web services, the emphasis is shifting and seems to be more on XML-based applications and EAI which has as basis the SOA architecture and also conforms to Web 2.0
Ramdas 7 months later:
SOA is a good concept like re-usable components which will not change frequently and can be used directly. It will help the business without disturbing core functionalities and easy to rollout any new releases. My view it is to stabilise the some the components which can be used by any other sattelite system or even internal modules as interface.
Gaurav Sharma 7 months later:
It’s a very good and simple article on SOA. If we try to read the way any of the firms have to present SOA, we are basically chasing our tales …
One think I’d like to mention is that in OOP terms its not Model-View-Controler … I think facade would be more close ?? any thoughs ..
Jose cardoso 7 months later:
I am about to have an interview, and the company uses SOA. Your explanation (simple, clear and full with useful illustrations) is the type I just needed to understand what’s SOA is about. I have been using it for years and didn’t know. Thanks
Rick 9 months later:
Thanks for the article, it does help to have this explained without a vendor rant. What this says to me is that SOA is really nothing more than a marketing buzz in terms of what good IT architects have been trying to accomplish for years. I think SOA is now a way to help Exec. Mgmt to understand what good IT folks have been doing for years. Never the less, SOA/MVC is critical for developing large scale transaction-based systems.
The Wiki def. for MVC sums it up in a less marketable fashion.
Model-view-controller (MVC) is an architectural pattern, which at the same time is also a Multitier architecture, used in software engineering. In complex computer applications that present a large amount of data to the user, a developer often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface will not affect data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.
eroch2@yahoo.com 12 months later:
I agree the term SOA is getting abused. Related post (mine).
http://blogs.ittoolbox.com/eai/business/archives/what-is-soa-23569
heeru.janweja@gmail.com about 1 year later:
great write-up. the language used is simple and it did not get too technical like a lot of the other presentations. waiting for the next in line, hope it comes out soon.
BobJax about 1 year later:
How it differs from Any MVC approcach? Is it seperation of services which seperates for unchange service? pls try to clear….
sivaks about 1 year later:
Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application’s business logic or individual functions are modularized and presented as services for consumer/client applications. What’s key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services’ underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.
sivapathiwada about 1 year later:
Service-oriented architectures have the following key characteristics:
SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services. SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise. SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry. Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.
Phafane Aka Kgopa @SITA (RSA) about 1 year later:
You have answered me ….I have been asking myself many questions about this concept,now im clarified, H?ow will this benefit or improve service delivery in govt or should poor country adopt SOA as Analysis Standard how will it assist in making their life worth a while.
james over 3 years later:
Hi BoB,
Could you explain Where we Actually implement soa in 3 tier architechture ,
can we implement soa using webservices in .net,
the above givn abt soa is very good , Thanks,Regards JameS
sohbet over 3 years later:
The web client and the window and the java script causes problem for some. Anyway as everything has some sort of disadvantages this software may also have them but the point we have to note here is that how many people are
Parcel Delivery over 4 years later:
SOA is an abbreviation for Service Oriented Architecture. After reading the article, I think SOA is a good concept like re usable components. A service is a function that is well-defined, self-contained, and does not depend on the context of other services.
Pandora over 4 years later:
However RSpec uses an alternative syntax that reads more like a specification than like a test. Let me show you what I mean.
Criminal Records over 4 years later:
The decision to call this service is neither a presentation decision, nor a service decision. Rather it is part of the business process for a particular kind of order. Business processes are volatile and they breed like rabbits. As businesses evolve they add more and more steps and forks to their business processes.
Tenant Screening over 4 years later:
Application developers or system integrators can build applications by composing one or more services without knowing the services’ underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.
Download Software For over 4 years later:
Thanks i can download it now.
funny pictures over 4 years later:
“Actually SOA is Service Oriented Architechture. This kind of architechture is used for prototype model. whatever explained above about SOA. those requirements are continously changing and for the continous changing requirements we are going to use prototype model and for that model architechture may used is SOA”
Agreed with this statement actually use for prototype model.This model based upon standard and conineous top level model