John Reynolds's Blog

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.

Comments

• Hmm... what a service does is a verb, yet a service itself is a noun. Additionally, an object can have methods, and those would be verbs. For programmers, the problem with SOA is that it has no intrinsic meaning; any attempt to define it ultimately unravels.

  For managers however, that is precisely what makes SOA great. They all can claim to use it, and it is impossible to disprove. For them it is a really cool buzzword technology that they can instantly adopt, without having to change anything.

  My suggestion: Commerce Oriented Architecture. I think it is superior because then everybody knows what it means, but still nobody has to change anything.

  Heck, if I didn't enjoy being productive so much, I could make a great technology consultant! ;-)

  Posted by: cajo on May 25, 2006 at 10:23 AM

• John (cajo),I have to disagree with your cynicism about SOA.Object Oriented Programming had no intrinsic meaning to programmers back in... oh say 1990. It was a paradigm shift, and it took awhile for the difference to sink in. Witness all the C++ programmers who did not really "get it".I think we are at the same point with SOA. If you work on a few "real" SOA projects, you will begin to "get it" and it will have intrinsic meaning from that point on.Of course, the best thing about this discussion is that it will propel both of us into the ranks of the highly paid, highly hyped technology consultants. ;-)

  -JohnR

  Posted by: johnreynolds on May 25, 2006 at 11:04 AM

• I thought we had a term for the "verb" paradigm: procedural programming. Say, isn't that what everyone was doing before OO? :)

  Posted by: richunger on May 25, 2006 at 12:02 PM

• Rich,You've got a good point. Procedural programming always did have it's place, but the solutions generally weren't loosely coupled... That made reusing code and modifying procedures problematic.Perhaps that's what SOA adds to the game.-JohnR

  Posted by: johnreynolds on May 25, 2006 at 12:12 PM

• >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.
  But only if those "distinct services" are at the correct granularity, right? Isn't that the toughest part of this challenge?

  Posted by: gsporar on May 25, 2006 at 03:33 PM

• Right Greg,Designing services with the right granularity (from the perspective of what is likely to change in a business process) is a real skill, and I think that's what makes SOA a paradigm shift.-JohnR

  Posted by: johnreynolds on May 25, 2006 at 03:38 PM

• So, let me take a stab at the right verbs:

  GET, PUT, POST, DELETE

  see The Restfulness of Speech Acts

  See, like nouns having a hierarchical relationship in OOP, verbs also have a hierarchical relationship.

  Then the more you thinkg about it, there's only a few verbs on the top of the the hierarchy.

  The problem with SOA and WS-* as it stands is that it fails to recognize a hierarchy and treats everything as flat. This then leads to infinite an infinite interoperability space, rather than one that is small and incremental.

  Carlos

  
  

  Posted by: ceperez on May 26, 2006 at 08:11 AM

• Carlos,
  As a programmer, I can certainly buy the argument that most services derive or are composed from GET, PUT, POST, and DELETE in one way or another... The link that you provided certainly puts it much more eloquently than I can.

  But I have to say that if I tried to have a conversation with a business owner using only these terms to describe their processes, their eyes would probably glaze over ;-)

  -JohnR
  

  Posted by: johnreynolds on May 26, 2006 at 08:51 AM

• John,

  I think you miss the point of SOA. That is, you want your services to be easily composable. Never has it been to make it easily understandable to business owners (that's what business rules are supposedly for).

  My point is that increase interoperability and therefoe make easier composability, one needs to structure verbs in a hierarchy, and when one does that one ultimately achieves what the web (i.e. REST) has achieved. Fix the verbs and you achieve interoperability.

  Carlos

  Posted by: ceperez on May 26, 2006 at 09:32 AM

• Carlos,Perhaps we'll have to agree to disagree on "the point" of SOA... your position just doesn't match up with what I have experienced in my work with IT groups.

  For me, the whole point of SOA has been to create business applications that are easier to maintain and modify, and composing the application in a way that business understands is a key part of that.
  From my perspective, the composition of complex processes from distinct services is of primary importance, and each of those services generally has a meaning to my business owners.
  Note that BPEL is generally included in any "SOA" solution stacks, and one of BPELs goals is to foster communication between the business people and the IT staff (particularly through the use of graphical notations such as BPMN).

  
  -JohnR

  Posted by: johnreynolds on May 26, 2006 at 10:14 AM

• I'll buy your "Services are verbs" definition. By logic, they should then probably be created in some "verb" programming language. I can't resist pointing out that "verb" is a noun, though :-)

  Posted by: tobega on May 26, 2006 at 02:19 PM

• Tobega,
  I clearly should have run this blog by my wife, the elementary school teacher, before postin ;-)

  -JohnR

  Posted by: johnreynolds on May 26, 2006 at 02:49 PM

• 
  Is "binary XML" a conjugate or oxymoron? :)

  But speaking of fast web services - I'd love to see a writeup from you or any of the other webloggers about fast web services that are interoperable with .NET.
  

  Posted by: phlogistic on May 30, 2006 at 07:00 PM

• Credits to John Bobowicz for the labelling of an oxymoron...

  Posted by: phlogistic on May 30, 2006 at 08:10 PM

This work is licensed under a Creative Commons License.