SOA – No New Concepts

SOA is based on sound software development concepts that have been around for years
-Modular programming
-Component based design
-Object oriented
-Aspect oriented
-Separation of concerns
-Interface and implementation
-Loose coupling
-Reuse
-Authoritative source

These concepts have been used in single, ‘monolithic’, software system development for years.  Breaking up a large system into smaller, more manageable sub-systems is well understood in software development.

Separation of Concerns (SoC)
This is the starting point of good web services development.  Simply stated, SoC is the process of taking a large system and breaking it down into smaller, independent sub-systems. (components, modules, aspects, concerns).  This type of architecture design requires a controlling module that is responsible for orchestrating the services.  This module is commonly referred to as a cross-cutting concern/aspect.  This is similar to the main class/function in a C/C++/C#, or Java application.

SOA is based on loosely coupled components, or services.  The only thing new about SOA is that each service is a single system that can be connected by the internet.  These service components are separate software systems that have their own purpose, and identity.
SOA simply leverages the internet to create new software systems from physically separate, disparate systems.  As the internet becomes more and more popular, and connection speeds steadily increase, SOA becomes more of a reality.

Loose Coupling - Interfaced, Not Integrated
What does loose coupling mean? Although not required, each service is usually physically separate.   Each service may run on a different software platform, and use different internal programming languages, data stores, and other platform/OS proprietary features.  Because of this, they cannot be integrated together.  SOA defines how these separate services interact through the use of standardized, well defined, interfaces.

In a single, monolithic application, individual components, or aspects, are interdependent on one another.  This may cut down on initial development time, but makes code reuse, testing, and maintainability very difficult.  By decoupling the different aspects of an application, the code can be organized so it is not repeated in several different places, and can be maintained with less effort.

To understand SOA, a basic understanding of interface and implementation is required.   A classic example of this concept is the analog clock.  A clock is laid out on a round plane, or face, with the numbers 1 through 12 written around the circumference starting with the number 12 at the top and the number 1 to the right, and so on around the face.  There are two or three pointers projecting for the center of the face, one pointer represents the hour, a slightly longer pointer represents the minute, and an optional pointer represents seconds.  We all know what a clock face looks like, and how to tell time.  This is the interface.  The internal workings of the clock is the implementation.  The user does not need to know anything about the internal workings of a clock to tell the time.  Only a clock maker needs to know the internal mechanics of the clock – pendulum/counter weight, spring coil, electric motor, and so on.  The clock maker builds an implementation of the clock that supports the established, well known, clock face interface.  The Interface MUST come first.  If a watch maker figures out a new way to build a clock that is more accurate, or cheaper, or has simpler mechanics, no one would use it if it didn’t implement the standard clock face interface.

For SOA interfaces the same thing hold true.  SOA components must adhere to standard, well defined interfaces that are commonly understood before developing the implementation.  Software system services that allow the implementation to create the interface should be used very skeptically, and cautiously.  With a little extra work, there are usually ways around this.

Orthogonality - Beware Of Side Affects
The result of creating loosely coupled services, that interact via their public interface is called orthogonal design.  Good ortogonal design mitigates adverse side affects between services.  Separate services only interact (intersect) at well defined, deliberate, points (interfaces).
There are always exceptions to these principles, but any exception should be carefully analyzed, and understood as to why it is an exception, and not just something overlooked, or misunderstood. (Or worse yet, bad overall design).

SOAP, WSDL And Other Web Services Standards
SOAP is by far the most used, if not the most loved, SOA / Web Services interface standard.  SOAP is an open, well defined messaging specification.  It builds on existing XML, and XSD technologies that are also standard, open specifications.  WSDL is the public facing document that contains the SOAP message interface for a specific Web Services provider.  SOAP, WSDL, XML, XSD and other Web Services specifications are maintained by W3C, OASIS, and WS-I.  These organizations are all open, committee based, standards governing bodies.

SOA Advantages:
What are the advantages of SOA?This depends on who you ask.  Three of the biggest benefits are:
1.  Separation of concerns.
2.  Ability to maintain an authoritative source.
3.  Reuse of service components.

The first advantage, ‘Separation of concerns’, falls under the above discussion on component based, loosely coupled services with their own purpose, and identity.

The next two, ‘Ability to maintain an authoritative source’, and ‘Reuse of service components’, are really just different sides of the same coin.  As a personal example, I have worked as a US Naval contractor for several years, for, and with, many different naval commands.  Many of the software systems I have worked on in different commands (and sometimes different systems in a single command), have a need for maintaining list of naval ships.  The naval fleet of ships is not static.  Ships are commissioned and decommissioned regularly, and all the different list of ships must be manually updated in each individual system.  Through the use of a Web Service, the list of naval ships could be maintained in one system by one command, and provided as a service to all other commands.  This service would be the authoritative source for the list of ships.  Other commands that need a list of ships would retrieve the list from the authoritative source service.  The other systems may store or cache this list locally for performance reasons, and automatically update their local copy on a time basis, or when the authoritative source list has changed.  This would reduce the amount of duplicative effort, and keep the most current list of ships synchronized across all Navy commands.  This is only a simple example, but demonstrates the potential advantages of using SOA in an enterprise setting.

Having a plan – SOA Governance:
SOA details are still being ironed out.  It’s hard to know what the complete playing field will look like when all the SOA and Web Services issues have been resolved.  Having stated this, it is still good to have some starting guide lines for building an SOA.

1.  Use standard, well defined, and well known interfaces.
2.  Need for the service.  It’s important to determine what systems, or aspects of a system would make a good Web Services candidate.  What components should be shared with other systems?Not every software application needs to be designed around Web Services.  A single, closed software application based on SOA, just to consume its own services, doesn’t make a lot of sense.  This is just an extra, unnecessary layer, that negativity affects performance, and buys nothing for maintainability.  There are plenty of times an SOA makes good sense.  Carefully consider when Web Services would provide the best solution.
3.  InteroperabilityBe extremely careful using .NET Web Services.  For .NET, use the wsdl.exe tool to create C# interface code from a WSDL, and a global.asmx.cs file with the Response.Redirect() method to redirect Web Service consumers away from the automated .NET reflected WSDL to a custom, user controlled WSDL/SOAP interface.  Axis based Web Services should be upgraded to use Axis2.  Use the wsdl2java tool to generate java code from a custom, user controlled WSDL/SOAP interface.   Use the Document/Literal style. Become familiar with the W3C, OASIS, and WS-I specifications.
4.  Simplicity – What good is providing a service if it’s hard to use, or not well understood?Keep the service operations simple.  Provide information that is both useful, and easy to access.  Define all data elements in the WSDL/SOAP interface.  It is common to see a SOAP response message defined as a single string data type element, only to have the response string contain additional xml elements that aren’t defined in the SOAP XSD.  Each SOAP request and response message piece of data should be well typed, and defined in its own element.

Conclusion:
This is just a high level overview of SOA and Web Services Best Practices.  Hopefully this document has been useful.  Best Practices begin with a care and desire to do good work.  There are many other good resources available online and just spending time working with SOA and Web Services will reveal what works and what doesn’t.

References:
“The Mythical Man Month” - F. Brooks (1974)
“The Pragmatic Programmer” – A. Hunt & D. Thomas (2000)
Various writings by A.T. Mannes


Comments and questions can be sent to: