The Old Joel on Software Forum: Part 4 (of 5) - Service oriented architecture

Service oriented architecture

Forgive me if this has been discussed before. People in my place of work are talking a great deal about a "service oriented architecture" (SOA). I have read presentations on it and it sounds like a new name for some existing ways of doing distributed applications. My initial impression is that this is a buzzword hoping for a market. I am planning to ignore and/or nod my head for the time being

Does anyone have an alternative explanation?

name withheld out of cowardice
Friday, March 5, 2004

I think Powersoft used that phrase (or something similar) with respect to their PFC (Powersoft Foundation Classes) framework some years back.

So yeah, it's nothing new under the sun.

Bill Gate$
Friday, March 5, 2004

It's nothing new really. But it is slightly different to how most people do distributed systems.

Basically, you focus on having the different tiers exporting 'services' instead of bits of functionality. i.e. Create Payment & Authorise Payment instead of Create & authorise the payment from form 11.0

Koz
Friday, March 5, 2004

Koz-

I don't see how that is any different from a current distributed system. The only difference I see in what you say is that you are call them "services" instead of (I can't be sure which you mean) Objects or methods.

name withheld out of cowardice
Friday, March 5, 2004

The differences are there if you squint hard enough. Mainly, as far as I've seen:

- Language and platform agnostic
- A Web Service is (or should be) a self-contained, independent unit of functionality. Most previous distributed systems rely on a set of cooperating distributed services.
- Transport neutral. A SOA should be accessible over a variety of transports.

Should be working
Friday, March 5, 2004

Whatever "Service Oriented Architecture is, this cool software will help you do it:

http://www.remobjects.com

Herbert Sitz
Friday, March 5, 2004

Remote objects is exactly what web services are not.

http://seanmcgrath.blogspot.com/2004_02_15_seanmcgrath_archive.html#107739235774357824

http://seanmcgrath.blogspot.com/2004_02_15_seanmcgrath_archive.html#107727890368144486

fool for python
Saturday, March 6, 2004

Fool, did you actually look at RemObjects? Or are you just going off the name and saying that "Remote Objects" aren't services?

I confess I looked at your links and I can't find anything that would indicate RemObjects is doing things in a way that the guy wouldn't call services. Then again, I'm not the biggest genius in this area.

In any case, RemObjects is totally organized around interfaces, and their framework seems to me to fit perfectly with this quote from your link:

"A service is strictly not a unit of code; it is rather a boundary definition that might be valid for several different concrete implementations."

Can you explain what I'm not understanding here?

Herbert Sitz
Saturday, March 6, 2004

Herbert, my post was not in response to yours but rather a response to the messaging/documents vs objects/apis views of web services. By remote objects, I was not reffering to RemObjects as I have not *yet* looked at your offering.

I gether from your response that it is not CORBA.next as Don Box calls Sun's view of web sevices.

fool for pyton
Saturday, March 6, 2004

http://dotnetguru.org/us/articles/SOA-Softly/SOA-Softly.html

http://udidahan.weblogs.us/ (various posts)

Dave Hallett
Sunday, March 7, 2004

From the "A comparison between RemObjects and .Net Remoting" page it sounds to me that RemObjects is very true to its name. Its conceptual base is remoting "objects", which you instantiate and call. SOA tries to shift the focus from this tighty coupled bound view to a more relaxed autonomous message passing framework. The idea behind this thinking is that by loosening the coupling the systems can be more scalable, both in development terms and in deployment/operations.
Obviously the tradeoff here is scale vs. efficiency. If you are going to do a small inhouse system where you have full control over all the participants and performance is an issue, SOA might not be the ideal thing to look at.
And yes, marketing has gotten their hands on SOA, so you see the hype flying like there is no tomorrow, but that does not mean the underlying concepts are wrong.
I have done CORBA based archiectural work in the past, and while it was great on paper, I do recognize the realworld problems that SOA tries to be an answer to.

Just me (Sir to you)
Tuesday, March 9, 2004