John Reynolds's Blog

Community: Jini Archives

Objects are Nouns... Services are Verbs... SOA hinges on designing the right Verbs

I still find postings that express confusion about the relationship between object-oriented architectures and service-oriented architectures... so I would again like to offer my own $0.02 worth of insight...

Objects are Nouns; Services are Verbs

An Object is primarily a Thing that is manipulated (and is generally stateful), a Service is primarily an Action that is performed (and is generally stateless).

In an object-oriented architecture, the software components are primarily organized as entities (things) that are to be manipulated. These entities generally have relationships to other entities, and that leads to the emphasis on design artifacts such as UML class diagrams.

In a service-oriented architecture, the software components are primarily organized as tasks (actions) that are to be performed. These tasks are generally designed to function as steps in more complex processes, and that leads to the emphasis on design artifacts such as BPMN diagrams.

Businesses use software to automate business processes. Business processes do involve Nouns (Objects), but they are generally more concerned with Verbs (Services).

Let me explain: Most businesses process forms of one sort or another. In general, manipulation of the form (an object) is not the primary concern of the business; the primary concern of the business is to perform a set of tasks (services) based on the contents of the form.

If the software components are packaged as distinct services, the mapping between the business requirement to "process the form" and the software implementation of the process is relatively straight forward. This clean mapping between requirements and implementation results in solutions that can better respond to changing requirements over time (Trust me, all business requirements change over time).

Sun's Tim Bray has recently expressed his opinion that the term "SOA" is meaningless, and that he prefers the term "Web-style". With respect to Tim, I disagree with his opinion.

I do not agree with Tim that "Web-style" is a better term than "SOA".

I agree with Tim that the term SOA has:"become damaged, weakened by over hype, over use, over promise (and) under deliver", but unlike Tim, I think that I can "explain what the difference is between SOA and Web services". Web services are a protocol specific form of service. To implement an SOA you must eventually pick a protocol, but it needed be a Web oriented protocol.

Tim asks for "an explanation that's meaningful in terms a programmer can understand, so a programmer can go and build one of these things". Perhaps it is my own arrogance or naivete, but I think my explanation is a darn good start.

In my experiences with many developers, I have found that explaining how to design and build SOA solutions is not any more difficult or "verbose" than it was to explain how to design and build Object-Oriented solutions. I confess that I do resort to "paragraphs and paragraphs (of) prose", but everyone who knows me understands that I always resort to paragraphs and paragraphs of prose ;-)

But if Tim is right, and the term SOA has become a dead alabatross, then I'd like to offer an alternative to "Web-style": How about Process Oriented Architecture? Kind of has a nice ring to it; Don't you think?

Regardless of the acronym or term that we use to describe it, the point remains the same: If your primary task is to automate a business process, then you should package (most of) your software components as verbs... er, I mean services.

SOA/ESB Level Set

	This figure shows the basis of an application developed using SOA principles and an ESB. Specific services are plugged into the bus, making them available to any application.
The service bus is responsible for routing messages to and from each service, eliminating the problems associated with "point-to-point" programming. Many ESBs are built on top of reliable messaging technologies. Messages are often XML based, but some ESBs allow for multiple protocols and formats. Applications are composed by developing driver programs that orchestrate the available services. Languages such as BPEL are tailored for writing these "driver" programs. Any number of "driver" programs can be written to utilize the services on the bus.
	If the application requires a user interface it is generally bolted on to the driver program.
Any user interface technology can be used; Rich Interfaces using Swing, Browser Interfaces using JSF and/or AJAX.
	If the application requires an external interface to the world beyond the service bus, those interfaces are also generally bolted on to the driver program.
Although it is certainly possible to expose all of the services to the outside world, that is usually not desirable. Generally only "composite services" that represent a service offered to a business partner will be exposed. Before exposing any service to the outside world, security issues must be addressed.
	Legacy programs are added to the mix by creating custom “service adaptors” between the legacy code and the service bus.
The success of integrating any legacy asset into the mix is related to the difficulty of crafting an adaptor (a.k.a. connector) for that asset. If the adaptor is fairly straight-forward, successful integration is more likely. If the adaptor is convoluted, only minimal success is likely. Although reuse of legacy assets is touted as a major SOA selling point, in reality many legacy assets will require refactoring to be of much use. The real payoff is adopting a style of programming that will make new services much easier to reuse later.
	The services that are plugged into the bus should be loosely coupled. Invoking one service should ideally have no side effect on other services. Care must be taken if the services directly access a shared database.
If services share records in a common database, they are coupled in a manor that may not be obvious to the author of the driver program. "Hidden" coupling in an underlying database can be a real problem. When possible, services should be stateless and operate only on the documents that are passed to them.
	To avoid hidden database coupling, some vendors recommend plugging a data service into the service bus.
The primary concern with the data access service approach is the performance issue associated with accessing all data through the bus. The use of data access services has let to several related ideas, such as using Service Data Objects to pass working data between services.

Please let me know what else you think I should add...

Big dreams on the longest night of the year...

The past year has seen a lot of progress in enterprise computing. At the beginning of this year I was writing an "elevator speech" on Service Oriented Architecture to introduce the concepts to my IT colleagues:

"This talk will be far more evangelical than technical, and I hope that it will de-mystify SOA for some. I'm sure many of you will say "Duh!" when you read some of the points, but you'd be surprised how many folks just don't get it (yet). "

The other big story of 2005 has to be AJAX (Adaptive Javascript and XML). I first blogged about AJAX in March after witnessing an amazing demo by Dion and Ben. I was wowed by the possibilities, but haunted by:

"memories of pre-custom tag JSP pages... a little puddle of HTML markup embedded in an ocean of Java code (only this time it's JavaScript)"

AJAX and Service Oriented Architectures are fond remembrances of the recent past... What about dreams for the future?

David Gelernter said the following during an interview for the Sun Developer Network:

"Huge numbers of "non-technical" people rely on computers not because they want to but because they have to. The great author and culture-critic George Orwell noted 60-odd years ago (and I noted in Mirror Worlds) that some people like playing with machines; some people don't. People who don't are just barely hanging on today. They need something far simpler, far more powerful than they've got today"

I think that SOA and AJAX are catalysts for the "far simpler future" that most people need. At first glance, you may not see the linkage, but take another look.

Web Services are what makes AJAX sexy. AJAX is what makes Web Services accessible to the masses.

As the SOA mindset takes hold, we should see an explosion of web services. As the AJAX toolsets mature, it should become incredibly simple for "power users" to craft tailored solutions from the new bounty of web services. Throw in improvements in service orchestration and choreography (BPEL for People anyone?), and I think we'll see a new generation of Renaissance Artist/Programmers.

In a recent interview, Bill Buxton offered the following scenario:

"The interesting thing is if you can throw a cell phone on a passenger seat, the phone rings, and the phone says to the stereo, "There's a call coming in. Can you turn the music down and can I borrow the speakers? And by the way, can I use the microphone embedded in the steering column?" Now you can just talk hands-free."

In Bill's example, the stereo provides an "audio output" service, the the microphone provide a "voice input" service, and the phone provides several communication and choreography services. The key is to help the "Renaissance power user" discover these services and then to help wire the services together on-the-fly. The pieces of the puzzle exist, the challenge is to make it easier to put them together.

The languages, tools, and devices that deliver this kind of power to the new Renaissance men and women are what I plan to dream of tonight...

Pleasant dreams indeed ;-)

This work is licensed under a Creative Commons License.