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