[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 ebSOAmeeting.(ebSOA-Elements.pdf) uploaded
Martin: You are correct on the first point - I was assuming a definition of SOA. That assumption is based on all elements common in all things claiming to be SOA. I can assure you however that I do not equate SOA to web services. SOA to me is an architectural paradigm; a way of doing things and can be expressed in some ADL. Web services are simply one of many implementations of SOA (assuming of course a definition of web services that doesn't break this premise) ;-) I would still assert that not all implementations of SOA (assuming the following classify as SOA - Bluetooth, Corba, ebXML, WS-*, the Internet, CBA, IBD...etc) have business process management since not all of these are deployed in a business environment. I guess this all proves the point that we do have to focus on the reference model since without a clear definition of SOA, we are going to have these conversations (as valuable as I think they are right now). I am going to propose an agenda for next weeks call - would like to get comments back on it. Cheers Duane Smith, Martin wrote: >I have to disagree with this: " Simple - BPM is not an element in >all service oriented architectures. Not all implementations of web >services have BPM, nor should they all. The Internet itself is an >example of SOA, yet it is stateless. " > >Duane is assuming a definition of SOA, which is precisely what we're >discussing. > >Also, he seems here to equate "implementations of Web services" with >implementations of SOA, which seems to imply SOA is only about Web >Services (as in WS*). > >Martin > > > > > >-----Original Message----- >From: Duane Nickull [mailto:dnickull@adobe.com] >Sent: Tuesday, March 29, 2005 5:47 PM >To: Chiusano Joseph >Cc: Schuldt, Ron L; Smith, Martin; 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 > >Joseph et al: > >I must remind you all that we have a narrowly defined charter to work >forward from. First and foremost is the deliverance of the Reference >Model for SOA. This will be used to then (alternatively) develop >specialized architecture for various applications. BPM is not part of >all service oriented architecture, therefore will not likely be in the >core reference model. This does not preclude it from being present in >architecture that is based on the reference model. Why do I state this >seemingly controversial statement? Simple - BPM is not an element in >all service oriented architectures. Not all implementations of web >services have BPM, nor should they all. The Internet itself is an >example of SOA, yet it is stateless. The reference model should include > >elements that are common in all instances of SOA. IMO - architecture >may be both SO and process oriented concurrently. > >BPM is, of course, a highly sought after function for any concrete >architecture to embrace. > >I would suggest we concentrate on the reference model first, then look >at how to develop specific architecture using the reference model. It >sounds like an example of one to tackle may be architecture for a >government system for information exchange that uses BPM/orchestration >as a key component. > >Duane > >Chiusano Joseph wrote: > > > >>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 <http://www.boozallen.com/> >> >> >> >> >> >------------------------------------------------------------------------ > > >>From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com] >>Sent: Tue 3/29/2005 3:49 PM >>To: Smith, Martin; 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 >> >>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 >> >> >> > > > -- *********** Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]