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] Groups - Rough notes taken during the last ebSOA meeting. (ebSOA-Elements.pdf) uploaded


Ken - - 

A great point (and I am guilty of the comment you addressed.)  We're
getting down in the weeds before we get oriented to the stars.

How about starting with some OO-ish questions like these:

1.  What is "SOA" a subclass of?  (Or, in English:  what type of thing
is an "SOA").  Obviously, it's an "architecture", but what's it an
architecture of?

2.  To further clarify 1., let's ask:  "What is SOA a sibling of"?
Assuming we agree that SOA is an architecture for X, what other
alternative architectures do we know about for X? If we can name one or
two, then we can use these to compare and contrast SOA.

Martin




-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: Monday, March 28, 2005 1:10 PM
To: Smith, Martin; Duane Nickull
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Groups - Rough notes taken during the last ebSOA
meeting. (ebSOA-Elements.pdf) uploaded

Just catching up on email and hopefully this has not already been
addressed.

I think that before we "define the relevant objects and their
interactions 
or possible states" we need to define what the system does that we
consider 
of sufficient value that we are going through the effort of building the

rm.  Otherwise, we are merely documenting objects that others have
defined 
or will define possibly conflicting objects without a common idea of why
we 
care about an SOA at all.  Given the press is full of such descriptions,

our job would already be done. :-)

Ken

At 05:59 PM 3/22/2005, Smith, Martin wrote:
>Just to check my understanding, is this the same as:
>
>"Goal of the TC is to define the relevant objects and their
interactions 
>or possible states  (i.e., an ontology) necessary and sufficient for 
>modeling a "services oriented" environment for (designing, building and

>operating) distributed computer applications?
>
>(A "services oriented" distributed AD environment would be
distinguished 
>by a set of principles or patterns defining this style.)
>
>Martin
>
>
>
> >>Might it not be good to start by listing the capabilities an SOA
> >>enables?  For example, an SOA enables a set of distributed resources
> >>(both data and processing resources) to be assembled to accomplish a
task
> >>defined independently from the SOA or its implementation.
>.  . .
> >>Let the fun begin!
> >>
> >>Ken
> >>
> >>
> >>At 01:0       1PM3222005,mattm@adobe.zl6wrote

--
 
------------------------------------------------------------------------
---------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-883-7934   |
  |    7515 Colshire Drive                    fax:      703-883-1379   |
   \   McLean VA 22102-7508
/
 
------------------------------------------------------------------------
---------- 





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