Gregor on SOA

I attended Gregor Hophes session on SOA in Las Vegas I little over a year ago and liked it. I wanted to drop into his session in Barcelona to see if the presentation has been updated.

Gregor now works for Google, let us see if that has changed his attitude and presentation form.

Gregor gives the following definition of a service:

• Self contained
• Independent of consumer context (makes few assumptions on use)
• universally accessible

Seems as if Gregor is pretty much doing the same presentation as he did at TSSJS in Vegas 2005, he is even cracking the same jokes. If he had put up the warning sign, I could be listening to Ross Mason talking about using Mule as an ESB instead.


Achitectural intent. Gregor talks about architectural styles and what architectural artifacts and specifics that defines SOA as a concept and architectural style. To define SOA he claims that it is just as important to state what SOA is not in order to give a proper definition of SOA.

Gregor uses Starbucks as an example of his discussions in the SOA space. At Starbucks (at least in the U.S) the staff performs a highly specialized task, one that collects the order, one that makes the coffee and one that processes the payment. This is throughput optimization, but requires a lot of staff, at least three people in this case. If thoughput it not the case, you might me just as well of having one effective employee that does a good job, it is simpler, more general purpose and less expensive. The point is, maybe you can stick with simpler. Is loose coupling and high co hesion allays for the best, even if you can implement the everything in one small class instead of three? I think that the problem with metaphors like the one with Starbucks is that I find it rare that people actually ask questions about what is the reason for having this design, and why not make it simpler. Developers tend to embrace new technology and paradigms regardless of their appliance. This may be good or bad. Bad in the sense that we may choose the wrong technology for a specific task. Good in the sense that we build knowledge on what works and what doesn't.

For written definitions of what SOA is that you can memorize before you attend JavaZone2006 and want to ask questions, Gregor recommends Orchestrationpatterns.

Q & A
The difference between REST and SOAP is brifly discussed. Gregor points out that the important part of SOA is really the architectural style not implementation specific issues.