[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]