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

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

The current definition of a service in the glossary is:
"A behavior or set of behaviors offered by one entity for use by another
according to a policy and in line with a service description"

Given that any/every entity is implicitly or explicitly the bearer of a (set
of) behaviour(s), any entity is implicitly a service provider (particularly
if we accept that "service" includes the use by one entity of any resource
managed by another): it is the conception of "actions/events that cross a
boundary" (to paraphrase Frank's comment) between entities that defines our
service-oriented model...

-Peter

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: 18 May 2005 20:32
To: Duane Nickull
Cc: SOA-RM
Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram

Well, I think the issue here is what modeling concepts are required in order
to model multiple services. The OSI stack does not need to mention the
multiple parties because modeling communication does not require the
modeling of the parties; it effectively only models the medium of
communication.

For us, the issue will only arise if we need to model the relationships
between services. For a straw man example, if sequence or other dependency
was part of being a service then we would need to model services as
resources.

I guess, my intuition is that service qua service is very much akin to
communication as medium. Hence my phrase that service was an action
boundary.

We spent many months in the W3C trying determine what a service really was;
and although we did not use the phrase action boundary; we would have had we
thought of it!

Frank


On May 18, 2005, at 11:06 AM, 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
>
>
>>
>