Title: RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting. (ebSOA-Elements.pdf) uploaded
Perhaps we are defining
an "Interface and Interaction" architecture?
That would accomodate
both key requirements that I see below: (1) Specify all necessary constraints between the service provider and the
service consumer (according to a contract), and (2) including interaction
capabilities along the lines of BPM/Orchestration, and (I will
add) Choreography.
Yes, for those who may
recall my expression on the ebSOA list about 1 year ago that BPM and "above" is
not part of SOA, I have since seen the light.:)
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
From: Schuldt, Ron L
[mailto:]
Sent: Tue 3/29/2005 3:49
PM
To: Smith, Martin; Don Flinn;
Subject: RE: [soa-rm] Groups - Rough notes
taken during the last ebSOA meeting. (ebSOA-Elements.pdf)
uploaded
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:]
Sent:
Tuesday, March 29, 2005 1:00 PM
To: Schuldt, Ron L; Don Flinn;
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:]
Sent:
Tuesday, March 29, 2005 2:45 PM
To: Don Flinn;
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
-----Original
Message-----
From: Don Flinn [mailto:]
Sent:
Tuesday, March 29, 2005 12:37 PM
To:
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:
http://flintsecurity.com
