SOA is a networked subroutine.

That is so wrong.

You might consider a Service a networked subroutine, but then you'd be limiting yourself to software services.

Don't forget the A in SOA - it refers to a collection of services that has a structure, purpose, and coordination.

We do need simplicity, but picking one small piece of the definition to represent the whole doesn't cut it.

This piece is off target. In addition to missing the architectural concept of SOA, it misses the notions that services are discoverable, can be chained together dynamically and orchestrated, have specified interfaces, and more... To think of SOA as simply networked subroutines is way too limiting.

I strongly disagree with the author's naive statements about what constitutes SOA:

- SOA is __NOT__ equivalent to just a networked subroutine.

- A networked subroutine does not encompass the intermediation layer that should be available in a SOA architecture - which can handle the loose-coupling of message transformations.

- A networked subroutine does not provide the ability for orchestration of services - external to the calling application and the service provider.

- A networked subroutine does not include the infrastructure to define policies for messages - which are managed externally from the calling application and the service provider.

- A networked subroutine does not provide the infrastructure for Governance (Business Activity Monitoring, Run-Time, Design-Time)

- A networked subroutine does not provide the infrastructure for service definition/discovery (Registry/Repository)

- A networked subroutine does not address the normalization of data-types that may differ between the calling application and the service provider.

And. . .SOA means added costs, too, For governance, security among systems, and on and on. It is not a networked subroutine, it's a way of doing IT business. A very immature article.

"Average programmers now have enough experience under their belts to be able to understand SOA and code it".

If you are talking about just a bunch of web services, I agree.

Otherwise, I believe you are overly optimistic.

"SOA is a networked subroutine."

While I appreciate the desire to simplify the definition, you may have gone a bridge or two too far.

In other words, it seems equivalent to "Cape Cod architecture is a 2x4."

@Kelvin Meeks:

Good list of stuff. But IMO, none of it is required for an effective SO architecture definition. One may typically find the elements you listed, particularly in larger environments but they are not required.

An intermediary is not a requirement. Consumers and producers interacting directly is perfectly acceptable. Most experienced architects will put an intermediary in place, but that's not an SO concern. Indeed, an intermediary can muddy the SO waters if you're not careful.

Orchestration is not an SO concern. That services might be used in an orchestrated manner is a Good Thing, but IMO that's an application concern (orchestration can be viewed as though it were an app).

Policy driven message handling is most definitely not an SO concern. SO principles don't give a rip about how providers and consumers interact--only that it be through a loosely-coupled, defined, discoverable interface. The details are implementation choices, not architectural issues.

Infrastructure is not required for governance. We do governance for other reasons, not because of SO principles. Would we stop governing if we stopped chasing service orientation? Of course not.

Service definition/discovery does not have to be automated nor have an infrastructure. It could be as simple as "view the list on the bulletin board." (An extreme example to illustrate the point.) Not practical in the large, certainly, but SOA isn't only about large enterprises.

SO principles do not address the normalization of data-types that may differ between the calling application and the service provider. They only say that consumer and provider must agree on the information exchanged via an interface. How the consumer gets to the agreed data types and format is not an SO concern.

These items are great to address within an architecture definition (which should follow more than just SO principles). But with the exception of the repository/registry, none of them are related to SO principles.

I bring these opinions up because this touches a bit on what Petreley was trying to address--too many things attributed/tied to SOA. SO principles are few, fundamentally simple and straight-forward. Practical, real-world architecture definitions are not.

In trying to define complex architectures, we keep trying to lump all concerns under the SOA umbrella. That's where the confusion and disconnects arise. Not all architecture concerns are SO concerns.

It seems almost a waste of time to give this piece additional energy given how misguided the author is. However, for the sake of those that don't know what SOA is or those trying to figure it out ... this article will not provide any useful information for you.

A service is not an architecture. The author's definition is too simplistic. See here for some alternate recommendations on what SOA is: http://blogs.msdn.com/jevdemon/archive/2004/12/17/323889.aspx

Adding to the disagreements. There is a definition from OASIS which vendors don't like because it makes clear that technology is secondary.

Networked sub-routine assumes that it has to involve a network traversal, which it doesn't, there is no reason why a service to service call couldn't occur within a given processor and memory space. This means the generalised definition comes down to

"Sub-routine" at which stage we might as well go the whole hog and say its just a JUMP or GOTO statement in assembler.

I had thought that definitions of SOA couldn't get worse, at least today you have taught me to never again underestimate the level of error to which people can stoop.