OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


In today's meeting, I agreed with several other voices that I am not 
sure there is an architecture per se in SOA, but rather that most of 
what are called SOAs are, in fact, service-components of an 
Enterprise Architecture, which is, IMO, where the actual Architecture 
is realized.

However, it is too late to bother arguing that, so we will have to be 
careful in describing what we mean by an SOA per se. So I have to 
agree with 1) and I think a service and some other infrastructure 
entity, be it a remote system or another node in the same system are 
required to constitute an architecture. I'm not sure about whether we 
should stipulate satisfaction of needs. It makes good common sense, 
though. But, I think that in essence there has to be a service and a 
service consumer for an SOA to exist.

Regards,
Rex

At 2:44 PM -0400 5/18/05, Christopher Bashioum wrote:
>Two points:
>
>1) in our document, we make the assertion that a service is the fundamental
>building block of an SOA.  If that is correct (and I believe it is), then
>you cannot have an SOA with only 1 building block.  The concept of a service
>being the fundamental building block of an SOA implies rather strongly that
>the relationship among multiple services (and the possible specialization of
>services) is part and parcel of an SOA.  In other words, there is something
>important to how these building blocks get put together that is inherent in
>SOA.  Not sure what that is just yet, and maybe we can show that in a single
>stack.
>
>2) I am not sure about the sufficiency of Ken's statement.  I think there is
>something about the orientation applied when building a service description
>that gets to the re-purposing.  I.e., building a service with the stated
>requirement of re-purposing of that service.
>
>Having said #2, I am not sure if that is really an essential property of
>SOA, or if it is a quality of a "good" SOA.
>
>
>
>-----Original Message-----
>From: Duane Nickull [mailto:dnickull@adobe.com]
>Sent: Wednesday, May 18, 2005 2:06 PM
>Cc: SOA-RM
>Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram
>
>
>
>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
>
>>


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]