Service Oriented Architecture (SOA)

SOA Principles

1. Service communication

Service communication follows best practice:

• Consistent
• Secure
• Traceable
• Transacted

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.

• A good example of a synchronous request is the basic SQL query into an Oracle DB.
• A bad example of a synchronous request is a payments component blocking on a direct request into PeopleSoft (ledger).

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 .

For example:

• When using Java, service logic should be implemented as “Plain Old Java Objects” (POJOs). Implementation details, such as EJB or WebServices, then provide connectivity into this java object. This approach provides better portability between hosting solutions.

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:

• A web-service is able to invoke a specific Enterprise Content Management service (ECM : Alfresco, Documentum, etc.) independently of that application’s internal, proprietary framework and protocol/state management requirements.
• All pre and post condition requirements are met via web-service API calls into this ECM component.
• All pre and post condition requirements, being that they are fulfilled via web-service API calls, are fully document and available for integrators.

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

• An external requester (Web-service client) is unable to invoke the Enterprise Content Management service (ECM) independently of your ECM framework because this service is unable to function without direct support of its own internal, tightly integrated, proprietary workflow GUI and sub-system (this situation could have been avoided by providing alternate ECM support options for independent invocation). Situation typically results in user receiving a workflow request something to effect of "swivel-chair" integration: "enter XYZ direction into your ECM fat-client GUI.

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:

• Capability (per business requirements)
• Performance
• Reliability and Robustness (includes negative or “dirty” testing)
• Recoverability
• Security
• Scalability

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.

• A good reason for invoking a chain of service requests from within a Java class is for unavoidable performance requirements. Though the initial service request may be invoked by a Java GUI, subsequent requests should be invoked by the BPM system in response to the initiated chain of events associated to the invoked process.

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

• Metrics are automatically captured and, therefore, readily available on management reporting dashboards
• Better support for long running transactions
• Better support for recovery, logging, and security
• Supports just-in-time runtime configuration and “code-free” process re-configuration and management.

Copyright ©2007 Gary Samuelson, All Rights Reserved.