[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
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
Perhaps an even better name would be a Technical Interface
Specification
to not confuse the readers with another Architecture. The
Technical
Interface Specification would detail orchestration, protocols,
security,
semantics, and other technical
requirements.
Ron
-----Original Message-----
From: Smith,
Martin [mailto:Martin.Smith@DHS.GOV]
Sent:
Tuesday, March 29, 2005 1:00 PM
To: Schuldt, Ron L; Don Flinn;
soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Groups - Rough notes taken
during the last ebSOA
meeting. (ebSOA-Elements.pdf)
uploaded
Hmm. I would hope that we define SOA as an
architecture for distributed
applications, because that's what I think I
need. That would certainly
include BPM/orchestration, for
example.
Martin
-----Original Message-----
From:
Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
Sent:
Tuesday, March 29, 2005 2:45 PM
To: Don Flinn;
soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Groups - Rough notes taken
during the last ebSOA
meeting. (ebSOA-Elements.pdf) uploaded
I think
Don has a good idea with the notion of an "Interaction
Architecture" but
perhaps it could be named an "Interface Architecture"
that would specify all
necessary constraints between the service
provider and the service
consumer.
My 2 cents.
Ron Schuldt
Senior Staff Systems
Architect
Lockheed Martin Enterprise Information Systems
11757 W. Ken
Caryl Ave.
#F521 Mail Point DC5694
Littleton, CO
80127
303-977-1414
ron.l.schuldt@lmco.com
-----Original
Message-----
From: Don Flinn [mailto:flinn@alum.mit.edu]
Sent:
Tuesday, March 29, 2005 12:37 PM
To: soa-rm@lists.oasis-open.org
Subject:
Re: [soa-rm] Groups - Rough notes taken during the last ebSOA
meeting.
(ebSOA-Elements.pdf) uploaded
IMO a Service Oriented Architecture is
more then *just* a service
architecture. For example looking at a
complex architecture where a
provider has out-sourced their credit check
functionality to another
company, their shipping to a third company and their
billing to a fourth
company; the architecture of the interactions between all
five companies
are a legitimate concern of the reference model. These
interactions may
include such things as policy negotiation, etc. I
agree that the
structure and transport of the request/response should not be
part of
the reference model as this is an implementation issue.
However, there
are architectural features of the "message" interaction that
should be
included, as suggested above. Perhaps the term "message"
should not be
used in this instance as it has the connotation of a
request/reply
structure and transport. May I suggest Interaction
Architecture.
Don
--
Don Flinn
President, Flint Security
LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail:
flinn@alum.mit.edu
http://flintsecurity.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]