Blogs

Service Oriented Architecture (SOA) is a term you don’t hear very much anymore.  It was all the rage when I was doing hands-on consulting many years ago so, I’m quite familiar with the goals and challenges of developing a SOA.  Wikipedia defines SOA as “a flexible set of design principles used during the phases of systems development and integration in computing… [which] provide a loosely-coupled suite of services that can be used within multiple separate systems from several business domains”. 

What this means is that rather than develop software as a monolithic, inseparable, intertwined, chunk of code, we strive to design a system that is comprised of autonomous “services” each providing some discrete function and/or access to data.  These services are usually implemented in the form of Web Services, which come in many flavors including SOAP, REST, XML over HTTP, etc.  Windows Services and Components (COM, .NET Assemblies, etc.) can be used as well however, these tend to require local installation and create dependencies.  Therefore, they are not completely autonomous, nor are they easy to implement when applications cross organizational boundaries (i.e., because the service or component from one company has to be installed at the other company).

One implementation of a SOA that I was a part of building was for the mortgage banking industry, specifically for loan origination.  The autonomous services that we built included (among others):

• Credit Reporting – Name and SSN in, XML based Report Out
• Products & Pricing -– Loan & Borrower Data in, Products and Pricing Information Out
• Property Valuation – Address in, XML based Report Out
• Data Abstraction Layer – Loan & Borrower Data in, Unique Identifier out and vice versa
• Underwriting - Loan & Borrower Data in, Result Out

You get the idea.  These services could be used from any application in the organization and, in some cases outside the organization.  For example, approved mortgage brokers or “partners” could call the underwriting service remotely and incorporate it into their own applications, website, etc. The beauty was/is that the input to and output from the service remains consistent over time despite changes that may be made to the underlying implementation (e.g., going against a different set of underwriting rules). 

SOA benefits include:

• Reuse – once the service is written it can be plugged in wherever needed versus writing the same application over and over again every time/place you need it
• Consistency – the service executes the same way every time so, for example, calculations such as APR (a tricky calculation for mortgages and one that has to be correct per compliance guidelines) and underwriting decisions are consistent across applications that consume the service
• Scalability & Reliability - because the services run in a web server environment they can take advantage of load balancing and fault tolerance technologies to provide scalability and reliability
• Rapid development – several services can be combined very rapidly to create robust applications without having to write anything but the code necessary to glue them together
• Integration – access to line of business systems’ data and functionality becomes trivial if these systems are fronted by services

The major difficulties of implementing a SOA were/are:

• Cooperation and consensus between service providers (departments within an organization or separate organizations) on what the service should and should not do, as well as support, Service Level Agreements and security concerns
• Performance - services tend to carry some overhead versus direct and local function calls
• Versioning – results returned from a particular service may differ over time as changes are made to the underlying implementation.  Web services need to be versioned so that clients can choose which version will be executed at any given time
• Complexity – SOAs are more complex and require more design and planning than that required for a one-off application
• Vision and sponsorship – a lot of developers just don’t see the big picture and often when they do, they don’t have management’s backing to design and build an SOA platform

So, what’s all of this got to do with SharePoint?  While it’s not a pure SOA implementation, it has many of the attributes of a SOA particularly as SharePoint itself becomes ever more ubiquitous.   SharePoint provides a suite of services, components and frameworks, some of which are abstract in nature (e.g., workflow) and some that perform well-defined, discrete functions as follows:

* Links to details for most of these services can be found on the Microsoft SharePoint Site.

To make it even more interesting, you can write your own Service Applications that live within SharePoint 2010.  Doing so automatically gives your Service Application scalability through load balancing, as well as access to other services and data in SharePoint.  This frees you up to focus on the specific business application required by your organization (e.g., credit reporting) without having to write all of the other parts of the application that are innately handled by SharePoint 2010 or other custom Service Applications.  Writing custom SharePoint Service Applications requires cutting edge development skills and an advanced knowledge of SharePoint 2010.  The upside however is that you get a good Service Oriented Architecture platform with a rich set of services out of the box!