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

["Peter F Brown" <peter@justbrown.net>]

+1 that it is "the essence" that there are indeed multiple services in any
given SOA, but cardinality of services is not an axiom of the RM itself
-Peter

-----Original Message-----
From: Michael Stiefel [mailto:development@reliablesoftware.com] 
Sent: 18 May 2005 21:02
To: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram

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
>