RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting. (

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:[email protected]]
Sent: Tuesday, March 29, 2005 1:00 PM
To: Schuldt, Ron L; Don Flinn; [email protected]
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:[email protected]]
Sent: Tuesday, March 29, 2005 2:45 PM
To: Don Flinn; [email protected]
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
[email protected]

-----Original Message-----
From: Don Flinn [mailto:[email protected]]
Sent: Tuesday, March 29, 2005 12:37 PM
To: [email protected]
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: [email protected]
http://flintsecurity.com

soa-rm message