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

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

I agree with Martin on both 
points. To the first point, I believe that this aspect ("where is the service 
line drawn?") is something that the TC needs to further discuss, and - if needed 
- potentially vote on at some point (sorry for so many uses of the word 
point).

 

Kind Regards,

Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com

From: Smith, Martin 
[mailto:]
Sent: Tue 3/29/2005 5:50 
PM
To: Duane Nickull; Chiusano Joseph
Cc: Schuldt, Ron L; 
Don Flinn; 
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:]
Sent: 
Tuesday, March 29, 2005 5:47 PM
To: Chiusano Joseph
Cc: Schuldt, Ron L; 
Smith, Martin; Don Flinn;

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:]
> 
Sent: Tue 3/29/2005 3:49 PM
> To: Smith, Martin; Don Flinn; 

> 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:]
> 
Sent: Tuesday, March 29, 2005 1:00 PM
> To: Schuldt, Ron L; Don Flinn; 

> 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:]
> 
Sent: Tuesday, March 29, 2005 2:45 PM
> To: Don Flinn; 

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

>
>
> -----Original 
Message-----
> From: Don Flinn [mailto:]
> Sent: 
Tuesday, March 29, 2005 12:37 PM
> To: 
> 
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: 

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