[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
Maybe part of what we should do is create an ongoing list of hard questions, such as those in this thread. When we've created the framework for answering the questions, we have our RM. Ken On Mar 29, 2005, at 6:05 PM, Duane Nickull wrote: > 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 > *********** > > ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-883-7934 7515 Colshire Drive fax: 703-883-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]