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] [issue:structure] draft 07, sect 2, line 201, Figure 2-1


 Well said

-----Original Message-----
From: Metz Rebekah [mailto:metz_rebekah@bah.com] 
Sent: Tuesday, May 24, 2005 5:41 PM
To: SOA-RM
Subject: RE: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure
2-1

All - 

A picture is worth 1000s of words (sometimes).  After reading through
(most of) the discussion today on the graphic, I created visual
representation of my comments.  That is attached to this message. 

Starting from the top of my pictorial comment:  As I thought about the
versions of this graphic, I am beginning to believe that "service
invocation" and "service information request" are both pertinent to the
RM.  With their inclusion, we can infer the existence of a service
consumer without calling it out as direct component of the model.  The
essence of the service consumer role is to invoke the service or to find
out something about the service - so I think calling those out has
merit.  

One of the concepts that I haven't reached a firm position on is the
role of a resource in service oriented architecture.  Does *every*
resource need to be understood and treated as service for an
architecture to truly be service oriented?  Does a SOA dismiss the
existence of resources that are not services?  I go back to what
actually distinguishes service oriented architectures from other
distributed computing architectures.  I realize that there has been
plenty of debate on the list over the past few weeks on this subject,
but I am still of the mind that we need to identify what makes SOA,
well, SOA and not just another description of distributed computing.  
Differences:
1)  A standardized and ubiquitous communication
infrastructure/backplane/etc
2)  Discoverability, presence and availability - which are necessary
precursors to orchestration and composition.
3)  A way to describe the functional, content and operational interfaces
that are exposed, independently of any resource that backs those
interfaces, and coming together as part of the service description that
may exist independently of an actual service it describes.
4)  An understanding of the operational aspects of a service, within the
description.  This goes towards addressing the "structural integrity of
a house" analogies that were whizzing around earlier today.  We may be
able to witness some larger group behavior when we put a whole bunch of
services together (a swarm of bees), but the operational interface is
focused more on the individuals within that larger group dynamic (one
lowly worker bee).  It also seems that this is a pre-requisite for the
"higher layer" orchestration and composition that is touted as the
nirvana of SOA.


Rebekah

Rebekah Metz
Associate
Booz Allen Hamilton
Voice:  (703) 377-1471
Fax:     (703) 902-3457


> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Tuesday, May 24, 2005 4:54 PM
> Cc: 'SOA-RM'
> Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201,
Figure
> 2-1
> 
> We need to summarize this thread to get prepared to bring the core RM
> out of the sink hole.
> 
> Let's chose one graphic, then enter comments against it.  I have
> uploaded CoreRM8.png as a member submission. If there are specific
> comments to go against this one that are related to what will go in
the
> RM itself, please respond to this thread.
> 
> Duane
> 






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