Engineering for Information Technology: Business Process, Automation, Architecture, and Integration
Back to our Home Page

Service Oriented Architecture (SOA)

SOA Principles

Business Process Architecture1. Service communication

Service communication follows best practice:

All APIs are well documented and follow a consistent pattern of implementation across all services and components. All complex messages should adhere to known (document) enterprise information schema (e.g. XSD). Binary payloads (e.g. images) must transmit over well known and understood HTTP(S), JMS, EJB, or Java file streaming technologies.

2. Avoid Synchronous Inter-process Communication

Developers should avoid synchronous inter-process communication unless specifically requested in design requirements.

3. Avoid Non-portable Languages & Technologies

All service logic is coded within either your Business Process Management environment (TeamWorks, Savvion, SearchLight, etc.) or system development language such as Java or .Net .

Business Process ArchitectureFor example:

4. Services Are Fully Encapsulated and Capable Of Independent Invocation and Execution

This principle insures that we avoid tight integration between the various services. Goal is to avoid, at all costs, associated “spaghetti code” typically resultant from tight, un-managed integration.

We know that we’re getting this right if our application is fully capable of being driven by our BPM/workflow system. For example, the workflow may send a work-request via e-mail to a workflow user. The workflow user can then click-to-invoke, via workflow, your application’s service via its service interface.

This point includes the avoidance of excessive pre and post execution dependencies.

Here is a good example of meeting this key principle:

An example of not following this principle (e.g. don't do this at home):

5. Services are Portable and “Plug-able”

Services can be de-coupled from their service framework infrastructure and ported out to external frameworks. This principle insures that each sub-component of your web-service system is a complete, functional, well documented entity. This also provides a good path towards sharing components and services across the organization.

Another important point here is to avoid excessive dependency on host application container and infrastructure support systems.

6. Services are Independently Tested

This principle DOES NOT mean that we skip our integration testing. What this does mean is that each component is provided with a document history of testing on the following points:

7. Services are both Event and Process Driven

Services are invoked and respond to events. A “chain” of services may also be strung together and invoked in sequence within a business process. Service “chains” should be managed within a BPM (or suitable process choreography technology) system.

It’s preferable to use BPM technology for process management and choreography:

Copyright ©2007 Gary Samuelson, All Rights Reserved.