Re: [soa-rm] FYI: BEA SOA Reference Diagram

[Michael Stiefel <development@reliablesoftware.com>]

I agree that " The essence of a SOA is multiple services coming together to 
satisfy a set of needs."

I believe that to be useful to our audience we need to discuss how multiple 
services work together. Even if there is just one service, that service has 
to be designed in a certain way if it is to potentially participate in a 
SOA.  Another way of looking at it is that one service is just the 
degenerate case.

It seems to me what we are working on right now is a Service Orientation 
Reference Model which is the necessary first step. You can call the next 
step a SOA Reference Model, or a SOA Reference Architecture, but without 
that next step I do not think we will produce something that will be of 
lasting value to the larger community.

I do not see how discussing how services can be connected together is any 
more concrete that discussing the nature of a single service. Abstraction 
is always relative to the level of discourse.

Take  the ISO stack as an example, the idea of connection is implicit in 
the abstraction. The whole point is to describe how two layers in the stack 
in different processes in different systems can communicate without having 
to understand the lower level protocols. The reason the communication is 
not shown (although I have seen pictures of it with the communications 
shown as in Tannenbaum's Computer Networks) is because the abstraction 
being shown is how the protocols are organized in one of the processes. If 
that is the level of discourse, there is no need to show a connection.

Incidentally,  I too do not like the use of the word architecture in the 
term SOA. Maybe we should propose what the SOAP 1.2 specification did and 
make the acronym the name.

Michael


At 02:06 PM 5/18/2005, Duane Nickull wrote:


>Ken Laskey wrote:
>
>>The essence of a SOA is multiple services coming together to satisfy a 
>>set of needs.
>
>This is the core point we have not reached consensus on yet.  This is a 
>well worded as can be so I would like to use this assertion as a basis for 
>the discussion.
>
>Thoughts:
>
>I would agree that "The essence of a SOA infrastructure is multiple 
>services coming together to satisfy a set of needs.  I do have 
>reservations about the concept of multiplicity of services being used as a 
>key metric to define SOA.
>
>Questions:
>1. Is it necessary that there be more than one service in order that SOA 
>be SOA? 2. If yes to #1, is it necessary to call services only in sequence?
>
>My gut feeling is that having multiple services is probably a given for 
>any specific implementation of SOA, however it is not a requirements for 
>something to be service oriented.  If I architect one application and 
>build it with a single service, service description, policy set, (+ 
>whateverElseGetsInTheReferenceModel), is that service oriented 
>architecture?  I think yes.
>
>I would fully support a reference architecture depicting multiple 
>services  being used either sequentially or in parallel, however think 
>that is a sub project best left for a dedicated sub committee.
>
>Duane
>