[no subject]

- Agency Tier: Service Consumer "candidates" (may consume services
offered by one or both of the other tiers)=20
- Enterprise-Wide Tier: Service Provider and Consumer "candidates" (may
offer services to Agency Tier, may consume services from External Tier)=20
- External Tier: Service Producer "candidates" (may offer services to
one or both of the other tiers. May also consume services outside the
bounds of the EA)

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
=20

> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]=20
> Sent: Monday, March 28, 2005 2:37 PM
> To: Smith, Martin; Ken Laskey; Duane Nickull
> Cc: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Groups - Rough notes taken during the=20
> last ebSOA meeting. (ebSOA-Elements.pdf) uploaded
>=20
> Hi Folks,
>=20
> For my $.02 FWIW SOA is a subgroup of Enterprise Architecture=20
> and I don't see it being a sibling of any other major=20
> classification of IT Architectures, but it is certainly the=20
> parent for the far-reaching subclasses of SOA components,=20
> subsystems which can be called services and in which those=20
> services are intentionally, or retroactively, purposed or=20
> repurposed as reusable. Reusability, in this context needs=20
> some work because it is a particular kind of systematic=20
> reusability. One, but not the only, kind of reuse is the=20
> example I offer where the same service that accesses an=20
> employee performance evaluation report for a line manager who=20
> wants to examine ways in which that line's production output=20
> can be improved can also be used by upper management for=20
> reviewing HR policies, for instance. The accessing service in=20
> this case is the SOA component.
>=20
> The difference between Enterprise Architecture and SOA lies=20
> mostly in the fact that EA is specific to an enterprise,=20
> while SOA can be abstracted out of a given Enterprise, and=20
> collected along with other SOA components so abstracted to=20
> form a registry of available services across, for example,=20
> the Federal Government. Likewise, I'm sure some enterprising=20
> sort will see the obvious opportunity for providing such a=20
> registry of SOA components for a small fee, or not so small=20
> depending...
>=20
> Ciao,
> Rex
>=20
> At 2:10 PM -0500 3/28/05, Smith, Martin wrote:
> >Ken - -
> >
> >A great point (and I am guilty of the comment you addressed.)  We're=20
> >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=20
> type of thing=20
> >is an "SOA").  Obviously, it's an "architecture", but what's it an=20
> >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=20
> >alternative architectures do we know about for X? If we can=20
> name one or=20
> >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=20
> last ebSOA=20
> >meeting. (ebSOA-Elements.pdf) uploaded
> >
> >Just catching up on email and hopefully this has not already been=20
> >addressed.
> >
> >I think that before we "define the relevant objects and their=20
> >interactions or possible states" we need to define what the=20
> system does=20
> >that we consider of sufficient value that we are going through the=20
> >effort of building the
> >
> >rm.  Otherwise, we are merely documenting objects that others have=20
> >defined or will define possibly conflicting objects without a common=20
> >idea of why we care about an SOA at all.  Given the press is full of=20
> >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=20
> sufficient for=20
> >>modeling a "services oriented" environment for (designing, building=20
> >>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=20
> capabilities an SOA =20
> >> >>enables?  For example, an SOA enables a set of distributed=20
> >> resources  >>(both data and processing resources) to be=20
> assembled to=20
> >> 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                                                      =20
>          \
> >   |    MITRE Corporation, M/S H305    phone:  703-883-7934   |
> >   |    7515 Colshire Drive                    fax:     =20
> 703-883-1379   |
> >    \   McLean VA 22102-7508
> >/
> >
> >-------------------------------------------------------------
> ----------
> >-
> >----------
>=20
>=20
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
>=20