SOA: Responsibilities of Service Providers (Part 5)

This blog post is one in a series.  An overview and general outline of this series is linked here.

Responsibility 4:  Implement common interface format and semantics applicable to the type of service.


Imagine.  Your trusted business partners come to you with a new problem and clearly a user interface is the vehicle to provide a solution for them.  On the backside of the user interface there are a number of existing services that can be leveraged to perform 75% of the heavy lifting.  Sounds great right?

Stay with me.  Imagine.  The existing services were built independently across multiple development teams.  Some were even built by contractors and consultants during various engagements.  There was little coordination across the organization resulting in each service having its own "look and feel" so to speak.  I view this as an organization that simply has "lots of services" and not a "Service Oriented Architecture" (SOA).

So what's the big deal?  Well, without a level of coordination and standardization for how services should be built, development teams must conform to every difference embodied by each service. Technical differences across multiple services may include:
  • Different authentication and authorization mechanisms (or no security at all)
  • Different protocols (e.g. SOAP/http, REST/http, tcp sockets, Java RMI)
  • Different payload formats (e.g. XML vs ASN.1) and conventions
  • Different versioning strategies (or none at all) /* TODO blog later */
  • Different methods/mechanisms to return error messages (e.g. SOAP Faults, Remote Exceptions, or returned in a response to be interrogated)

With each service having a little different look and feel, constructing the user interface and leveraging the existing services can be tedious.  And if care isn't taken the user interface code can easily become more complicated given these differences.


I've seen a couple examples where a formalized technical "blue-print" for how services should be constructed across the enterprise has yielded significant benefits.  First of all, the service developers are not left to make their own fine-grain decisions for how services should be constructed on a project-by-project basis.  But rather focus can be re-directed towards business logic and the overall solution.  Too many times I've seen developers get wrapped around the axil about things such as "so, how to we implement security for our service".  When these details are landed in a blue-print it provides a platform for the I.T. organization to reach a common understanding and agreement for how services will be built technically. Question marks are minimized for developers and consistency is the net result.

From my experience, it is a best practice when the underlying service blue-print is implemented in a common framework.  This is the technical foundation that all services are built on top of.  At a high level, the key benefits include:
  1. A rich service framework increases the odds that services will be constructed with similar "look and feel".  As a best practice, the items enumerated in the previous section should be isolated from business logic as much as possible by the framework.
  2. Developers leverage a common code library to implement services.  Focus and energy can be redirected to service-specific interface definition, business logic, and configuration.
  3. Hard problems can be solved once and embodied within the framework to be consumed by all.
  4. When a change is needed to the underlying implementation, it can be changed once within the framework.  And incorporated by each development organization.
The goal of a common blue-print and framework for service development is to enable each development team to roll out services across the enterprise with a measure of consistency.  Ultimately, this consistency enables clients/consumers to reap the benefits of reduced effort and complexity when interacting with multiple services across the enterprise.

Now, think about the earlier scenario.  In taking this approach, the development team will invoke the first service as part of building their user interface.  As the team proceeds to invoke their second, third, and fourth service it will be done just like the first.  The team will not have to pause to learn anything new or implement semantics that are unique to each service.

Formalizing a common blue-print to reach agreement across the organization can be challenging.  Allocating time and priority to build out a common framework is well worth the effort.  The rewards can be very tangible and ultimately contribute to achieving a high-value Service Oriented Architecture.