Applied SOA: Part 9–Service Versioning

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

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy
• Interoperability
• Service Composition
• System Consistency
• Security

In this article, I’ll cover Service Versioning.

In SOA a Service usually has many consumers & it should be able to evolve independently of its consumers.  By that I mean that when a Service evolves, consumers shouldn’t break.  Otherwise we would have a hard time to evolve services.

We can do quite a bit of changes to a Service without breaking existing consumers logic. For instance:

• Changing Service implementation details, i.e. not its behaviour, e.g. tap to another Database, add logging, route information to different systems, etc.
• Adding a new Service Operation to a Service
• Adding optional data-items in message payload

What needs to remain stable for consumers to continue to operate normally is called the Service contract:  Service behaviours and information exchange patterns, i.e. schemas & bindings.  This definition of Service contract is broader than WCF Service Contracts.

Service Contract can be backward compatible, i.e. a new Service Contract can support the same consumer base (for instance when we add a Service Operation without altering existing ones).

We need to version Service Contracts in order to accommodate for breaking changes.  When an evolution of a Service requires to introduce breaking change in its Contract, we need to support the current version until all consumers can be moved to the new version.

We want to keep track of two types of Service Versions:  breaking ones and non-breaking changes.  Breaking change versions require multiple versions to co-exist in order to support different consumers while non-breaking change versions are useful to determine the capacity of a Service.

A typical versioning scheme is to track breaking change versions with major version number while non-breaking versions are tracked with minor version number.  This is the scheme used by Windows Azure REST services for instance.

Concurrent Service Versions

Maintaining more than one Service Contract version at the same time is notoriously hard.  Typically you introduce breaking changes because either a business process or a back-end system imposes that change on you.  Those changes are often hard to burry under a legacy Service Contract version.

That problem isn’t unlike its equivalent in the component world.  How do you evolve a component?  You version its interface and try to keep old interface backward compatible as long as you can before deprecating them.

Service Behaviours

Just a word about Service Behaviours:  those are encapsulated in Service Contract along operation signatures.  Behaviours are any logic surfaced to the consumer, as opposed to implementation details which aren’t surfaced.

For example, if a Service encapsulates access to a Database, a consumer won’t know which Database the Service read / writes from.  The exact Database is therefore an implementation detail.

On the other hand, if a Service operation takes an integer in input and validates the input as being greater than zero by raising a fault if that pre-condition isn’t met, that becomes a behaviour.  A consumer depends on that validation:  if a change requires the input to be greater than 5, consumer sending values between 1 and 5 will break.

Service Behaviours are hard to document with tools.  For instance, WCF Service Contracts do not capture pre & post conditions.  This typically require documentation on the side.

Applied SOA: Part 8–Security

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

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy
• Interoperability
• Service Composition
• System Consistency

In this article, I’ll cover security.  Security is a very broad topic and by no mean unique to SOA.  I’ll focus on what is specific about service security.

I once had a colleague whose mantra around security was the triple ‘A’:

• Authentication
• Authorization
• Audit

I actually find that triple ‘A’ a very good summary of security concerns in most systems:  who are you, what can you do with the system and keeping traces of what you did.

Authentication

When a service is invoked, it is done by something (e.g. a browser, another service, etc.) on behalf of somebody (e.g. an end user, a system user, an anonymous agent).

Some concerns jump in:

• How do we identify users in your system, i.e. what is the identity model in your system?  Is the identity a username?  A SID?  A set of claims?
• What is the authentication process, what are the credentials involved?  User name / password?  Certificate?
• Where and when is the authentication done?  Once and a proof of that authentication (e.g. token, cookie) is transported thereafter or is it done at each tier boundary?  Service boundary?
• How does it flow through service composition?  Does the end user identity flows all the way or does the identity of services take over somewhere in the pipeline?  How do you address the case where a service composition is done through asynchronous means, i.e. can the invoker identity be stored with the asynchronous message?

In the Microsoft realm of technology, some classical approach exist.  Using Windows Authentication is often used within a corporate network as a secure way to authenticate user with little friction (user is already logged in on his / her workstation).  Identity can flow via impersonnification or caller context.  The database is often considered a trusted subsystem, i.e. that it doesn’t require the end-user identity, trusting the calling services.  In some cases, you might want to flow the identity right through the database though, in order to strictly enforce security policy.

Outside corporate firewalls identity is often managed using custom means, i.e. username / password and a combination of cookie & custom token.  Claims based security model is rising and becoming more common but is still a young technology.  Interoperability is a challenge with Claims based as very little products support it hence you would have problem to flow the identity everywhere.  This is often managed by having a security policy of controlling the user identity at the Enterprise boundary and then flowing the service identity.

Authorization

Now that you know the identity of the agent invoking your service, how do you control access?  Many models are possible given the following variables:

• Are you going to be context insensitive (e.g. this operation requires role X to execute) or context sensitive (e.g. this operation requires role X and role Y.<the name of the department you are trying to access> to execute)?
• Are you going to control the access at the operation border only?  If so, a user can either invoke your service operation or not.  You might also need to control what the user can see and perform security trimming even once the user has been given access to the service operation.
• Are you going to grant access based on role (RBAC), to a set of claims or to a set of permissions, itself determined from role, claims and other data about the user identity?
• Where are you going to control access?  Everywhere?  At an entry point only?

Typically, you’ll have a mix of those variables in your system.  Just being aware of them and which compromise you are making in your architecture will go a great way of ensuring the clarity of the security model, how well it will be understood by different stakeholder and hence the strength of its eventual implementation.

Audit

Often forgotten in security is the audit.  Indeed, we can secure a system with access control (authorization), but another big requirements for a secure system is to be able to trace back what a given user did or who did what in a system.

Audit is the ability of tracing back actions.  This is typically enabled by logging actions to a store.

Now the first question you need to ask yourself is if you’ll need to audit easily, i.e. via some UI with search facilities, etc. in which case you want the logging information to be easily mined or is audit going to come as a consequence of some rare legal problems, in which case you just want the information to be available so that some professional could go and mine the information on a need-to base.

Logging can be done at different level:

• At the service boundary you can log information about an operation, payload in / out, time of request, identity of the user, etc.  .  In an SOA architecture, this should be sufficient to reconstruct user actions.
• You can continue to log within a service, at different layer, even going as far as logging DB access.  This is useful if your service implementation changes often or if their logic is strongly influenced by some configurable sources (e.g. business rule engine in BizTalk, custom application configuration, etc.) in which case service operation treatment might vary over time and it could be hard to reconstruct actions just by looking at service log.

You can log actions within your system, e.g. by stamping changes with a user name, by keeping all changes, etc.  .  This is done by systems such as TFS which never forget anything.  It is easier to do in such systems because they have generic entity management system.  On system managing many type of entities (e.g. many tables in a DB), it can become difficult to keep all changes in the system without cluttering information schema.  In those cases, you might want to perform logging on the side, e.g. in log files.

Regardless of where you log, it might be challenging to reconstruct user actions from log.  So it’s better to think in advance at what type of reconstruction you would need to do to make sure it will be feasible.  Often the reconstruction scenarios are simple, e.g. who changed the salary of X?  But sometimes, it can be harder, for instance, if you need to reconstruct a long running business process where different people can have played a different role.

Again, you’ll often end up with a mix of the options presented here, i.e. logging on the side + keeping last changes in store which you can then expose at the application level.

Golden rule

Architect with security in mind day 1!

We repeat that everywhere all the time but more often than not, security comes second.  This is actually quite natural since as an architect you typically sit down with business people to specs out an application.  Those stakeholders often have very remote concerns about security.  A good way to get around this tendency is to involve security-aware people (e.g. legal, your Enterprise Security guru) early in the process.

Applied SOA: Part 7–System Consistency

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

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy
• Interoperability
• Service Composition

In this article, I’ll cover system consistency.  In every distributed solution, a major concern should be consistency.  How to you ensure that different moving parts in your solution create a consistent state?

Many patterns and solutions exist to address that problem.  We’ll look at a few and see how it impacts other attributes of a SOA solution.

Distributed ACID Transaction

First solution that pops to mind is ACID transactions.  ACID transaction is a very elegant and very mature technology allowing distributed parts of a system to remain consistent.  I won’t go into details here and just assume you know the basics of ACID transactions.

ACID transactions can actually solve the consistency problem in a SOA solution as well.  We would need to use distributed transactions (through WS-Atomic protocol for instance) where transaction would span through the calling tree of a service.  This way, everything in the calling tree would be part of the same transaction and would either commit or rollback as a whole.  It would conflict with solution attributes of SOA though.

The main attribute it would conflict with is service autonomy / isolation.  A distributed transaction implies that a calling service holds lock in a composed service for a certain duration.  This means the composed service can’t guarantee to other callers it can process their requests.  That control has been partially externalized by the transaction.  It breaks the trust boundaries between services:  a service now needs to trust services invoking those services will hold locks on its resources.  Locks also limit scalability of services.

ACID transactions are excellent at ensuring data consistency but they come at a high cost.  This cost is deemed unacceptable in Cloud Computing because of scalability.  The same goes for services invoked across trust boundaries (e.g. B2B services).

Compensation

The typical fall-back pattern when transactions aren’t appropriate is Workflow + Compensation.  With this pattern, each service expose a rollback, or compensation, logic so that a calling service can call an operation and later on call another operation in order to rollback the effect of the previous transaction.  This typically assume that some sort of workflow engine is at the root of all those calls, orchestrating the service call chain.

This patterns also work and solve the consistency problem.  It introduces different compromises.  For instance, services must trust the workflow engine to take care of the consistency.  Mostly, it is a more complicated solution.  Instead of relying on a system (the transaction coordinator) to take care of compensation, you basically must implement it yourself.

Above the technical difficulty, it might be difficult to compensate after a certain lapse of time.  This would be a business problem.  A typical example is A puts $100 in B’s account, B pays a $90 bill, A wants to rollback its original transaction, but the money is already spent, what can we do?  This is where the orchestrating workflow will get more and more complicated.

Conclusion

We’ve seen the two basic patterns for consistency.  Typically we mix them together.  For instance, a service implementation will use ACID transaction internally to ensure consistency internally.  For read-only operations, composition without distributed transaction can be ok in many system where changes aren’t happening too quickly.  This typically leaves you with only a small set of services requiring state-altering composition.  Those often are business processes and are best handled in a Workflow engine.

Applied SOA: Part 6–Service Composition

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

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy
• Interoperability

In this article, I’ll quickly cover service composition.

Service Composition is often stated as a goal of SOA.  I think it’s rather a consequence of a Service Oriented Architecture.  You first deploy building block-type of services.  Once those are running, you can start deploying higher order services reusing those building blocks.

As we’ve seen in the Service Taxonomy blog entry, a good service taxonomy helps you to structure service composition.  The one I presented, from soapatterns.org, has composition built-in.  Typically, a business processes compose many services.  An activity within a process might also compose a few more agnostic services.

Composition is good, it’s incarnated reuse, so we should want it everywhere, shouldn’t we?  Well, like with everything sweet, there’s a tension related to its usage.  In the case of composition, this tension is with isolation.  As we’ve seen in different SOA definitions, isolation is important.  Composition compromises isolation in many ways:

• It couples SLA:  the composing service is just as strong as its weakest link at any moment in time.
• It couples services time-wise:  composition increases latency but also require the composed service to be up-and-running.
• It also often couples service contracts if the composing service expose data from the composed services.  One way or the other, changes in the composed service will affect the composing service.

This tension is the reason why you won’t want to layer your services in many layers.  Doing so would result in weak SLA, long response time and high-maintenance.  If you do not layer at all, you’ll end up with duplicated logic.  As usual, patterns and judgement should help you balance your solution!

Integration in the Cloud

I ran across a series of good blog posts I wanted to share with you, dear readers.

From Richard Seroter, the series is about integration patterns in the cloud, looking at cloud-to-cloud & cloud-to-on-premise scenarios.

Richard looks at three main patterns:

• Shared Database
• Remote Procedure Invocation
• Asynchronous Messaging

For each pattern, Richard describe the pattern, the general challenges, the challenges specifically related to the cloud and finally he demonstrates the pattern using different cloud provider (e.g. Google, Amazon, Azure).

His text is very thorough yet straight to the point.  He puts his fingers on the right issues.  Great work Richard!

Applied SOA: Part 5 – Interoperability

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

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy

In this article, I’ll cover the Interoperability.  SOA aims is to expose capabilities through services in order to let different agents leverage those capabilities.  A common theme is therefore interoperability.  Given the universal reach of services (as opposed to objects or components for instance), the interoperability bar tends to be quite high.

Technical Interoperability

Now the first thing that pops into technologists’ mind when interoperability is mentioned is technical interoperability:  the ability for two systems to communicate with each other despite their underlying technological stack differences.  This is no small challenges.

Indeed, we would think that with SOAP & WS-*, all those interoperability problems are behind us, all taken care of by standardisation bodies, right?  Well, not quite.  Although those standards enable basic interoperability in an unprecedented way, they still do not guarantee it.  The center of the problem is the way SOAP specs can be interpreted and how differently it was interpreted by different vendors.

As a result, it isn’t trivial to achieve interoperability between heterogeneous systems.  For instance, Microsoft published four months ago a package of bindings to use with different vendors.

Two opposing forces are at play when we consider technical interoperability:

• The richness of the protocol used in the services
• How interoperable we want it to be

For instance, consider the following list of Services protocol:

• WS-* (e.g. WS-Atomic, WS-Security, etc.)
• WS-I Basic Profile
• REST / OData
• SQL Views
• File share

As we go down the list, protocols get simpler and simpler.  The first ones allow rich scenarios (e.g. distributing a transaction, sharing a claims based security context, etc.) while the later ones do not.  The amount of potential clients grow as we go down though:  who  can’t drop a file on a file share?

Now once you’ve decided on how much interoperability you can afford given the protocol your solution needs, you have many tactics to make it happen.  For web services, this typically involves getting closer protocol standards and not letting your development platform do as much as it otherwise would.

Indeed, many web services platform offer a great story to quickly author web services by eliminating a lot of the gory details of SOAP.  Different development platform (e.g. .NET vs Java) takes different decisions on those details which make them incompatible though.  Pesky details such as field ordering, native types to SOAP types mapping, how list of objects are mapped to XML schema, etc. can all bring incompatibilities between a service and its consumers if written in different platforms.

All that being said, those problems are known and great guidelines exist.  For the .NET platform, an excellent tool for authoring interoperable web services is WSCF (Web Service Contract First) by thinktecture.  Those tools accelerate protocol-centric development instead of marking details.

The key here is to test with the different target platforms.  Quite similar to multi-web browser development really.

Business Interoperability

Another aspect of interoperability is business interoperability.  Let’s say we solved the technical interoperability problem and we have a great recipe to build web services interoperable with our target consumers but that we do not speak the same business language, how really interoperable are we?

An example I like to give concerns two hypothetical services within a consulting company (yeah, I love consulting company examples!).  The first service returns a list of employees who didn’t fill up their weekly timesheets while a second service sends email to an employee.  We could easily combine those two services in order to warn offenders they haven’t filled their timesheet yet, couldn’t we?  What if the first service signature looks something like this:

EmployeeData[] GetOffenders()

where the EmployeeData data contract has the following shape:

EmployeeData :
{
  EmployeeNumber : integer,
  FirstName : string,
  LastName : string
}

and the second service looks like this:

SendEmail(emailAddress : string, mailBody : string)

Well…  we got ourselves a typical data mismatch problem.  The first service identify employees by employee number while the second one expect their email address.

A simplistic example, but quite common one in large enterprises, especially ones where acquisitions created a patchwork of different semantics (e.g. here a project is something with a billing code and people staffed on it, there it’s an aggregation of teams with no budget semantics).

Again, this is a problem with solid existing solutions, but it is still something to be mindful of when elaborating a Service Oriented Architecture.  Two typical solutions to this problem are:

• Schema rationalisation (or Canonical Data Model, CDM) where services expose a canonical model where different entities only have one meaning and representation.
• Entity Aggregation (e.g. Master Data Management) where different semantics and representations are allowed to exist but a central authority performs reconciliation.

In conclusion, it is important to define what type of interoperability (both technical & business) we target and to take the necessary steps to achieve it given the challenges of the solution’s context.

Applied SOA: Part 4 – Service Taxonomy

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

• Introduction
• SOA Basics
• Service Discovery Process

In this article, I’ll cover the Service Taxonomy.  On an SOA project, we’re going to have services.  How should we classify them?

First why would we want to categorise them?

First, to give a structure to the solution.  Without structure, it’s hard to govern an important number of elements, especially if those elements are services.

Second, at the architecture level, we can give rules for categories as opposed to individual services.  Again, this is structure, we can manage fewer pieces.

Third, at the design level the taxonomy will help us clarifying the boundaries of a service.  At the end of the day, there are two extremes:  either you have one service with all the operation of your company in it or a lot of services with one operation each.  A service is just a container and unless you have some clear taxonomy, which operation belongs to which service can be a matter of taste and individual preferences, which seldom yields strong design decisions.

Finally, it gives us the ability to reason about the structure at a higher level without getting cut in the intricacy of specific services.

There are many ways to categorise services.  A popular one was defined by Tomas Erl in his book SOA Design Patterns.  That taxonomy is based on a few patterns exposed in that book.  Each pattern invokes separation of concerns in order to define a service layer.  Two axis are used for the separation of concern:

• Agnosticism to business context
• Business Logic

A component is said to be agnostic to the business context if it can be invoked from any business process and behave identically.  A component is said to be business logic specific if it contains business logic.

Nevertheless, this taxonomy is useful.  It defines three layers:

• Utility Layer, agnostic of both business context and business logic.  On this layer exist services manipulating information without applying business logic on it or varying depending on the business context.  Typically those services offer communication capability:  emails, pub-sub, mapping, etc.  .
• Entity Layer, agnostic of the business context but implementing business logic.  Services in this layer are typically data centric.
• Task Layer, business context sensitive and implementing business logic.  Services at this layer typically participate in the activities of a specific business process.

Reusability is maximal at the Utility Layer and minimal at the Task Layer.  At the Task Layer, a service is specific to a business process (context) and can’t be reused elsewhere.

Business Logic increases as we go to the Task Layer.

Composition is done for the Task Layer to the Entity and to the Utility layer.  By composition I mean that a service from one layer can call a service from another one.  This is probably the strongest property of this taxonomy:  the composition rule is deduced from the definition of the taxonomy as opposed to imposed as another principle.

For example, a service at the Entity Layer, by definition, can be called from any business process.  It cannot, therefore, call a service at the Task Layer, being specific to only one business process.

I’ve used this taxonomy in the architecture of a sizable SOA project.  It worked well in terms of given structure and was quite resilient to changes along the project (e.g. security requirements, multiple consumers, etc.).

Something we did to enrich the taxonomy was to further subdivide each layer per domain.  A domain being an information / process breakdown.  Given those subdivisions, each service could only be within one layer and serving one domain within that layer.  That gave a very strong & clear service boundary definition.

Now the weakness of the taxonomy, we’ve found, is the vagueness of the definition of agnosticism to business context & business logic.  It sounds great on paper, but my service designer team, composed of brilliant and seasoned designers, spent the project having philosophical discussions about what is and what isn’t business context agnostic.  It boiled down to the fact that an operation being or not aware of the business context isn’t always clear.

On smaller project I’ve seen a taxonomy based only on data domains, hence having only an entity layer.  This simplifies the clustering of services as data domains are typically quite clear.  It does mix the concerns of process centric & data centric capabilities though.

Applied SOA: Part 3 – Service Discovery Process

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

• Introduction
• SOA Basics

In this article, I’ll cover the Service Discovery Process.  You’re working on an SOA project.  There’s going to be services.  What are those services?

That sounds like a trivial questions but it’s actually quite fundamental.  There are two extreme approaches I know about.

The first approach, also called “bottom-up”, basically consists at looking at what applications needs and trying to generalize it to the Enterprise level.  This approach is actually quite popular because most SOA efforts start with one project, a new application, and therefore it is quite natural to look at that application to decide what you want to expose in your Enterprise at large.

Now that approach is application centric by nature.  Your viewpoint is the tree (the application) not the forest (the entire Enterprise).  So yes, you can guess from this new HR system you’re deploying that having an employee service is a good idea, but what type of employee schema makes sense at the Enterprise level (cross applications) and which operations would make sense to be exposed at the Enterprise level?  The application won’t tell you that.  You can speculate, everyone around the table will have a different idea.

That approach is quite good at picking reusable ‘utility’ services, e.g. Enterprise Login, Pub / Sub, Transformation Service, Communication, etc.  .  You can often pick some data services that would make sense at the Enterprise level too.  It is wise to go easy on those one and deploy a minimalist version 1 so that you have elbow room to take more decisions by the time you connect other applications on it.

It is quite rare that you raise to Business Processes using this approach and if you do you’ll have the application’s view of a Business Process.

Now let’s look at what some SOA gurus think of this approach.  Philip Wik, in an SOA Magazine article mentions:

But, as a question of architecture and strategy, a populist approach is like building a new house around its appliances. A bottom-up approach introduces needless complexities into already complex systems that are at cross purposes with the company’s umbrella strategy.

(emphasis mine)

Thomas Erl, in one of his books (SOA Concepts, Technology, and Design, 2005), says:

The bottom-up strategy is really not a strategy at all nor is it a valid approach in achieving contemporary SOA. [...] Although the bottom-up design allows for the efficient creation of Web services as required by applications, implementing a proper SOA at a later point can result in a great deal of retro-fitting or even the introduction of new standardized service layers positioned over the top of the non-standardized services produced by this approach.

(emphasis mine)

Not such a popular approach in the SOA circle as we can see.  Why is it so popular then?  Well, let’s look at the other extreme approach, also called the “Top Down” approach.  This approach starts with the Enterprise business process and identifies each activity that should be implemented by a service.

For instance, let’s take my company (fictitious, I made it up) on boarding process.  This process is represented using Business Process Notation (BPMN). It represents the process and is entirely agnostic of the systems & technologies.

Each task (square) in this diagram becomes a potential service operation.  This approach is of course task-centric and doesn’t give a very good view on the data.

Why approach is better?  Well, guess what, it depends!

The first approach is easy but doesn’t capture Enterprise needs.  The second approach is less trivial (you’ll need to speak to a lot of departments to get your head around a process sometimes) but captures the Enterprise needs with no noise about the technology.

Typically, the two approaches should be used together and meet in the middle.  On one hand you analyse the Enterprise Business Process, on the other hand, you analyse services from different systems.  When you identify services with both approaches, you probably have a good candidate for promotion to Enterprise Service while improving your chances of reuse.  You can still piggy back your first big project involving services which tends to happen anyway.

What I often see is a bottom-up approach with some Enterprise inputs, such as an Enterprise Data Model and some Enterprise business rules.  This typically leads to Data Services centered around key Enterprise concepts exposing Enterprise Data.  It’s not the full-blown SOA promise, but it’s a good foundation for future SOA projects:  you need to start knocking down data silos before orchestrating cross-business-units process.

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

WCF Express Interop Bindings

Something that might come as a surprise for somebody who worked with WCF (even for years) but never had to interoperate with another platform than .NET is how much WCF isn’t interoperable out-of-the-box.

It isn’t WCF fault really.  It’s SOAP’s fault and its lousy specs.  Well…  not so much lousy as big, complicated and extremely flexible.  The result is that each vendor implements a subset of those or at least expose a subset as the default configuration for web service.  So although you’re using a platform that is interoperable, the web services you are exposing are not.

Of course, if you’re exposing your web service using basic http binding with no security, no reliability, no session and plain old XML (even for big binary payload), you are probably interoperable (and pretty unsecure).  If you use a fancier bindings, chances are you won’t be able to interoperate with another platform.

But rest assure, instead of mocking around binding configuration until you can talk to this Java server over there, Microsoft gives us the WCF Express Interop Bindings on CodePlex.  Take a look at this picture (from the site) and reflect on how “Universal” SOAP is when you have platform technology names on both side of the diagram!