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

Subject: RE: [soa-rm] Groups - Rough notes taken during the last ebSOA meeting.(ebSOA-Elements.pdf) uploaded

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
***********

soa-rm message