Applied SOA: Part 2 – SOA Basics

SoThis is part of a series of blog post about Applied SOA. The past blog entries are:

• Introduction

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.

(emphasis mine)

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:

Examples	Characteristics
High-Volume / Highly Isolated Services: Search Engine Live ID Messenger	Data Isolation is a given Data will be replicated on multitude of servers Multitude front-end servers to satisfy demand Simple protocol (often HTTP-REST)
Business Process Driven	Surfaces data from multiple system Data isn’t isolated but spread in different systems The process determines the breakdown of services and service into operations not the complexity of implementing each operations Often involves WS-* protocols (to support transactions for instance)
System Integration Services	Services breakdown by system Services expose data from a given system No business process involved
Enterprise Data Service	Autonomous service (e.g. own Database) Expose a specific set of enterprise data Other systems use its capabilities Sort of the reverse of a System Integration Service, in this case the service is build first and applications are build after leveraging it
Service Tier in an n-tier application	Typically services are consumed by only one consumer:  the application’s front end Strong coupling with the consumer in terms of platform protocol (e.g. SOAP over TCP using .NET binary formatting), data representation (data is ready to display on screen as opposed to be closer to an Enterprise Data Model)

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:

• Business
  • Data & Service Governance
  • Enterprise Architecture
  • Roadmaps (rarely done in one big bang project)
• IT
  • Operations
  • Monitoring
  • 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.

Activity	Example
Governance	What is an employee?  Actually, more basic, what is an employee ID?  Is it the email, the employee number, the Active Directory Account name? Is a past employee an employee or is it a separate concept? Is a contractor an employee? Is a prospect an employee?  If so, what’s his ID?  Is not, how does recruiting work with the future service? Who can view and modify what attributes? What are the fundamental operations to perform on an employee? How do we version the data & operations along time?
Enterprise Architecture	What will v1 include?  E.g. a restful GET on the intranet What’s the roadmap for future versions, what systems will integrate along the way? How to open part of the service to partners at some point in time? How to make some operations accessible to different departments?
Operations	What’s the helpdesk strategy? How do we monitor that service? What is the promised SLA? Work around if the service fails for a longer period?

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