Applied SOA: Part 2 – SOA BasicsSolution ·
SoThis is part of a series of blog post about Applied SOA. The past blog entries are:
In this article, I’ll cover the basics of SOA.
The hardest question for an Architect to answer briefly is ‘what is architecture’. Probably the second hardest question is ‘what is SOA’? In both cases, if you receive a quick answer you are getting short changed because you’re being served one definition that is used by a minority of people (obviously including the person you’re talking to). Let me try to have a go at it and keep in mind that I’ll likely exclude topics that others would consider core to SOA while including topics that others would consider non-SOA. The world is a big place with a lot of people.
If you have a Microsoft background, SOA probably resonate with the SOA four tenets:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Service compatibility is determined based on policy
Sounds easy enough and familiar? If you dig a little you’ll find that those ‘SOA tenets’ were introduced by Don Box in a 2004 MSDN article about Indigo, the project name of a technology that became WCF. Box defined them as SOA fundamentals, but really it had a strong inclination towards the solution, i.e. Web Services using WCF. Reading them today they sound more like a departure from CORBA, DCOM, .NET Remoting and distributed objects in general. That definition is good for the solution, i.e. it emphasis characteristics of the solutions. It doesn’t addressed why you would use services in a solution though. There is no mention of business processes, for instance.
Another popular definition of SOA is the SOA Manifesto. It is a longer and complete definition, is vendor neutral and is signed by 700 practitioner. It actually has tenets too:
- Business value over technical strategy
- Strategic goals over project-specific benefits
- Intrinsic interoperability over custom integration
- Shared services over specific-purpose implementations
- Flexibility over optimization
- Evolutionary refinement over pursuit of initial perfection
Another definition, found in an article by Philip Wik in SOA Magazine, summarizes a school of thoughts centering SOA around business processes:
The essence of SOA is to decompose business processes into discrete functional units or services and group existing or new business functions into business services.
That definition has the merit of being brief, but it does exclude quite a lot of efforts undertaken in the industry. For instance, if you expose your employee information into a consolidated service, you’re not inside any business processes, so you’re not doing SOA? Primarily, you’re doing EAI in order to bridge your corporate AD, PeopleSoft, that Access DB your HR people are using despite your recommendation and what not. But the final result, the service, isn’t that a SOA artefact?
Ok, enough criticizing every definitions, let me pollute the air with my own tentative definition:
- SOA is an architecture style (as defined in TOGAF)
- In a Service Oriented Architecture (SOA), services are first class citizen
Is that abstract enough? Ok, let me explain.
There are usually few architecture that purely follow one style. You might have multi-tier applications involved in some SOA but also involved into Web Architecture, distributed, etc. . The dominance of a style determines the style of a given architecture: if you have three servers talking to each other, 3-tier isn’t necessarily the corner stone of your architecture.
Now what does it mean to have services as first class citizen? It means that your architecture revolves around them. If you have web services in a system, it doesn’t mean you have SOA.
SOA is quite broad and these days it comes with a fair bit of ceremony. In order to broaden the reach of this blog series, I’ll address SOA concerns in general and how they can be applied in non-pure SOA. Hence the title: Applied SOA!
There are different type of ‘Services’ with very different concerns out there. For instance:
High-Volume / Highly Isolated Services:
|Business Process Driven|| |
System Integration Services
Enterprise Data Service
|Service Tier in an n-tier application|| |
To me, all those examples share some form of SOA and have SOA issues to address.
A final note on SOA basics. Typically a full-blown SOA Project have the following stakeholders, looking over different activities of the project:
- Data & Service Governance
- Enterprise Architecture
- Roadmaps (rarely done in one big bang project)
- SLA, etc.
I often give the following fictitious SOA project as an example to explain all those activities. I work for a big consulting company. Imagine my company wants to create an Employee Service. Simple enough? One service! The reason is simple: there are lots of systems containing information about employees, some syncs between them directly, some syncs transitively (via another system that in turn syncs with another one), some do not, etc. . The executives are sick about hearing about nightly job that didn’t work and affect the payroll or that a business unit is unable to search for skilled workers in another business unit because we use different systems.
|Enterprise Architecture|| |
So guess what? Those projects are expensive. It is often hard to justify the long-term benefit. Therefore? They involve a lot of politics!
A good predictor for a Service Oriented Architecture could be:
- It has several concerns described above
- It involves a lot of politics