Re: [soa-rm] RE: Definition of Reference Model (Was RE: [soa-rm]Definition of "Service Consumer")

[Duane Nickull <dnickull@adobe.com>]

Martin:

To discuss this issue, I would first like to refer to BPM as just 
"process management" since we are not scoping it to "business" 
environments only.

Once again, I will assert the following:

=> There is no need to make architectural distinctions between a service 
that is consumed as part of a process vs. one that is not.

One of the core principles in the W3C Web Services Architecture, 
Microsoft's Web Services architecture and ebXML is the concept that 
services are autonomous and granular. Accordingly, they themselves have 
no notion of state other than their policies and contracts for 
invocation. One service does not care that it is step 3 of 5 in a 
process. It is true that at some higher level, some functionality may be 
layered on top of an SOA infrastructure to coordinate a process 
executing or failing and rolling back to an agreed upon state. I would 
state that this layer is probably what the analysts refer to as "POA". 
This does not preclude a service from being aggregated as part of a 
composite application.

The existence of "service" in the reference model does not limit it to 
only one service in a concrete implementation. Examine other Reference 
Models like the OSI stack. It is a communication stack reference model 
yet it does not have a process or more than one instance of the stack. 
That is because it is abstract.

The concept of process orientation is best left to a POA reference 
model, which in itself may rely on SOA. Much like the characterization 
of web services relationship to SOA, I would state the following axioms 
and ask the editors to capture these.

=>
"The principles of SOA can be used to implement a process oriented 
system, but process orientation does not necessitate the use of SOA, nor 
does the use of service orientation ensure that the overall system 
design is process oriented."

=>
"Architecture may concurrently be both service and process oriented"

I have no doubt that many SOA implementations in the future will have 
some form of process management. It makes a lot of sense in many 
applications.

Duane



Smith, Martin wrote:

> Joe - -
>
> I agree that all implementations shouldn’t have to include all 
> elements, or, in other words, the RM should not be limited to elements 
> that are included in all implementations.
>
> I still think that both services composition (orchestration, workflow, 
> program logic, BPM . . . ) should be an element of the RM. It’s not 
> going to be a very useful or interesting environment that is limited 
> to interactions with one service.
>
> I also think security should be a core element: it may not be 
> necessary to have security on trivial, free services, but all the 
> interesting cases will have it, and the RM should inform how that 
> element will interact with others.
>
> Also, I saw someone refer to our task as defining a RM for 
> “distributed systems” (or a particular style.) I think that is why we 
> are all here, and using that as the “it” we are trying to describe 
> would bring some focus, IMHO.
>
> Regards,
>
> Martin
>

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