SOA what!

[More of my first "No Fluff, Just Stuff" experience]

My last day at the Raleigh "No Fluff, Just Stuff" symposium began with a session called Implementing SOA. This was another session with Neal Ford who seemed to be in competition with Venkat Subramaniam to see who could speak at the most diverse set of sessions.

The session started off with Neal's opinion that a Service Oriented Architecture is not possible without agile best practices. He supports this by saying that such an architecture must be able to adapt to change gracefully. This seems intuitively correct to me because of the fine-grained nature of services and the complexity of the overall architecture. Without the small stuff being correct and stable, the big stuff won't matter.

What is SOA?

Here is how Neal defines SOA

• Enterprise-wide architecture that breaks monolithic applications into a set of finer grain services
• Services are available enterprise-wide through standard protocols
• New applications are assembled from existing services rather than built from scratch
• Services are registered in a central registry
• Services can be discovered and interfaces can be 'negotiated'
• Common services such as security can be shared by all applications or application services

That seems straightforward enough, but something tells me that even these clear guidelines can be stretched to include architectures that don't embody the spirit of SOA. Because what exactly is a "service" anyway? Hmm. Let's see if we can't flush that out as we evolve to an SOA.

Stages of an SOA

Stage 0, as Neal called it, of an SOA is a set of siloed applications that have no integration. This is the typical scenario of many IT organizations - disparate applications that could share common libraries (e.g., security, logging, etc.), but don't talk to one another and could possibly duplicate information.

In Stage 1 we start to see applications exposing functions as Web Services, but there is no integration or management of these services. This is relatively easy to accomplish, and as a best practice should be done via Web Service facades.

Stage 2 starts the process of centrally managing the exposed services from Stage 1. This is where a centralized service, like a Security Service, can start to be used and is, in fact, a good "case study" for the larger SOA.

Stage 3 is the "paradigm shift" - applications are dissolved into coarse-grained business services and business processes are managed across those services. The business functionality in those siloed applications (Stage 0) start to get cleaved away into standalone services that can be orchestrated or choreographed into business processes. This is where I see the agile/iterative process being a key to success.

Service Versioning

Once you have your services up and running what do you do when you need to version a service? The answer depends on whether your services are strongly typed or loosely typed. Strongly type services look something like this

public int AddOrder( Order toAdd, LineItems[] lineItems )

This is the typical way in which we define a method in Java, but you can see the problems if the interface needs to change.

A better way is to loosely type your services. This is done by having your services pass around a canonically defined document. Endpoints end up looking like this

public void service( Document doc )

What changes in this version is not the service, but the document. The service can then use a factory to retrieve the proper logic for handling the given document version (Strategy Pattern).

With loosely coupled services, we can now create a bus architecture that is document-centric and more resilient to change. Defining a robust meta-model for your document structure, however, is paramount to making this architecture a success.

What's also important (maybe most important) to remember here is that your services must have the correct granularity. Too granular and you get latency issues. Too coarse means there is not enough separation of business behavior. "Business function should drive service granularity."

Other things of interest that Neal mentioned included using XSL/XSLT to transform documents before putting them onto or getting them off of the bus. What I found most amusing are Neal's feelings on BPEL. He calls it “doodle-ware” and thinks it's a bad idea - "keep behavior in code," he says.

Conclusion

This session was jam packed with information, most of which was really useful. With my company starting to implement an SOA I will frequently be returning to my notes on this session.

Next up: The Java Memory Model