OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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


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]