RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better

I think we need to add some words to the RM to capture this
discussion.  We cover part of this in the beginning of Section 3.2.1
but need to be more specific that:

- a service consumer can be a human or a software agent;

- a service consumer can invoke any number of services (including a
single service in isolation) and can chain the output of some services to
act as the input of others;

- from the perspective of a given service, the occurrence of such
chaining would not be visible;

- the service consumer can be implementing a business process;

- the specific of a business process do not change the basic SOA concepts
as described in the RM; however, the specific architecture that one
designs and implements will reflect the business process and make use of
specific service instances that corresponds to the real world effects
that the business process hopes to realize.

Now that said, and in full appreciation that we agreed earlier that
mechanisms which combine services (e.g. choreography, orchestration) are
out of scope, is it sufficient for words, such as those suggested above,
to be included somewhere within the current discussion or do we need to
pull it out into a subsection on its own?  As an example of the
former, we tried to deal with loose-coupling and coarse-grained with
words at the end of Section 2.1.

Ken

At 12:23 PM 12/6/2005, Duane Nickull wrote:

Goran:

 

I slightly disagree with your assertions, probably based on
semantics.  For a service to “participate” in a process, it would
have to be aware of the process (which many will not be).  A better
way to depict this may be to state “services may be aggregated and used
by processes” and “processes may be represented/exposed as
services”.  There are really no limits to the number of layers that
can be present.  Attached is a UML CVD depicting such.

 

A key rationale of why process is not part of SOA is that services cannot
see process.  They are not aware of whether they are being called as
part of a process vs. as an individual service.  If the “s” part of
SOA cannot see or touch that, it cannot be part of the RM.

 

The chicken and egg discussion you bring forward is a requirement for
those building services to strongly consider the business process when
designing their service infrastructure.  Accordingly, it is not
really part of the RM for SOA yet I agree that it is a very important
consideration.

 

For your messages to get to the list, you must join as a “applicant”
rather than an “observer” as per OASIS process.

 

Duane

 

*******************************

Adobe Systems, Inc. -
http://www.adobe.com

Vice Chair - UN/CEFACT 

http://www.uncefact.org/

Chair - OASIS SOA Reference Model Technical Committee

Personal Blog -

http://technoracle.blogspot.com/

******************************* 

 

From: Goran Zugic
[
mailto:] 

Sent: Monday, December 05, 2005 8:47 PM

To: Duane Nickull; Matt MacKenzie; MATHEWS, Tim; Sally St. Amand;


Cc: 

Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
Better 

 

Duane,

 

Thanks for the response. Yes I would like to see the
PPT. I hope you do not mind if I add few more thoughts related to
services and business processes:

 

Services participate in a business process to add
some value to it. They can be governed and evaluated using business
process metrics. One service can participate in many business processes
and provide value to each of them according to the context within that
process. As far as SOA is concerned it is as important to know what the
service does, how it can be discovered, contacted, invoked, executed,
etc. as it is to be able to use it within the process context, measure it
and assess its value from the business process requirements point of
view. SOA needs to avoid typical new technology chicken and egg syndrome,
e.g. companies not producing services because there are no service
friendly process definitions to use them and not having SOA friendly
process definitions because there are no services to use. Services do not
have to know if they will be involved in the process upfront, they will
be contacted on demand according to the process script that is in effect,
and they will be contacted, checked if available, passed the arguments,
collected the response and according to their procedure left alone to
wait for another call. The process execution engine however needs to
invoke the service according to both service specific information and the
process specific information.

 

Having just the service specific information in a
model covers only one part of the picture and I think it is fine as long
as that model is a pure service model. However I find it difficult to
understand that the SOA RM TC model is a SOA reference model when it does
not include other concepts of SOA. Unfortunately it seems that we cannot
get to the point where we could agree on a minimal set of supported SOA
concepts by a model to be the SOA RM.  We do not have to and I do
not want to argue with you or anybody else in SOA RM TC. I am just trying
to see how our works can fit together in a most efficient way. We
obviously need more time to better understand each others thoughts and
ideas and I strongly believe that a constructive respectable discussion
is helpful for everybody. 

 

By the way, do you know what I am supposed to do to
get my messages to the SOA RM list. In spite of that I am the SOA RM TC
observer I get a faliure notice whenever I send a note to the SOA
RM.  

 

Goran

 

----- Original Message ----- 

From: Duane Nickull 

To: Matt MacKenzie ;

; MATHEWS, Tim ;
Sally St. Amand ;

 

Cc:

 

Sent: Monday, December 05, 2005 5:02 PM

Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft
for Better 

 

Goran:

 

The service layer enables the process layer over top of it, however
during runtime, services do not know if they are part of a process or
being called individually (it would generally be a bad idea to try to
maintain the overall state of a process within each service, although it
could be done).  For maximum repurposing of services, it would be
better to have the service as a simple slave to the processes that may
use it.  

 

Accordingly, we made a decision that BPM, Orchestration, choreography
is not a core part of the RM for SOA.  We generally seem to agree
that many SOA implementations will include a layer of BPM over top. 
We are only addressing the SOA model, not the model for the underlying or
overarching layers.

 

I have a PPT that explains this in more detail if you are
interested.

 

Duane

 

*******************************

Adobe Systems, Inc. -
http://www.adobe.com

Vice Chair - UN/CEFACT 

http://www.uncefact.org/

Chair - OASIS SOA Reference Model Technical Committee

Personal Blog -

http://technoracle.blogspot.com/

******************************* 

 

From: Matt MacKenzie
[
mailto:] 

Sent: Monday, December 05, 2005 12:51 PM

To: ; MATHEWS, Tim; Sally St. Amand;


Cc: 

Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft
for Better 

 

Process orientation is only one of
multiple potential integration with service oriented architecture. 
SOA-RM is laying the foundation for durable architecture based on the
core concept of service orientation.  We recognize that process
oriented architecture is a natural fit with service orientation…but so
are things like event orientation.

 

-matt

 

From: 
[
mailto:] 

Sent: Monday, December 05, 2005 3:36 PM

To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand;


Cc: 

Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft
for Better 

 

I think that SOA RM has
done good job documenting well-known service related concepts and
defining some new ones. 

 

I do not see other
details besides service and service-related concept definitions in the
current SOA RM committee draft right now. I look forward to seeing the
completion of the model you are working on with the bottom-up approach.

  

Business, business processes and collaboration aspects of business
are important to address in the model what is not the case with the
current content of the SOA RM committee draft. By a business process I
mean a generic business process entity which has common components
(activities, decisions, etc) and relationships between them that can be
used to model a business process in any environment regardless of what
business we support and technology we use. I agree with Sally that a link
between business processes and services should be one of key requirements
any SOA reference model should try to meet.

 

I am not sure what SOA
with services brings to business when the link between the business
processes and services and overall business process semantics in the SOA
context are not considered to be important aspects in a SOA-based
reference model.

 

Goran

-----Original Message-----

From: MATHEWS, Tim
[
mailto:]

Sent: Monday, December 5, 2005 12:34 PM

To: 'Matt MacKenzie', 'Sally St. Amand',


Cc: 

Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft
for Better "Componentization"

Matt - I am not sure what point you are
trying to make by this?  I agree with your premise of a bottom up
effort, as this was one of the operating assumptions that was made from
the beginning.

 

But, I am confident it is the business
environment that is independent from the reference model.

 

TM

 

From: Matt MacKenzie
[
mailto:] 

Sent: Monday, December 05, 2005 11:58 AM

To: Sally St. Amand; 

Cc: 

Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft
for Better "Componentization"

Sally,

 

A reference model actually needs to be a
bottom up effort.  We leave the ever so popular ?top-down? approach
to folks like ebSOA
J

 

We?re creating a vocabulary and general
understanding of what I hope we can call a discipline of computer science
in the future.  This means, we need a durable reference model that
is not dependent on the current business environment.

 

-matt

 

From: Sally St. Amand
[
mailto:] 

Sent: Monday, December 05, 2005 10:19 AM

To: 

Cc: 

Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft
for Better "Componentization"

 

Frank

 

This is in response to your request on last week?s conference call,
if anyone has comments speak now. I also think that the recent comments
on clarifying sections are a reflection of my issues with the
specification.

 

I agree with the majority of points made/described in ver 10. My
issues are with what is not in this draft. Based on Fig 1 the Refe! rence
Model is guided by Reference Architectures, Concrete Architectures,
Profile & Related Models. They in turn account for requirements,
motivation & goals. This is creating a Reference Model from the
bottom up. I believe a Reference Model should reflect a top down
approach.

 

The Reference Model needs to reflect the environment, the strategy
and the priorities of the business/mission/collaboration.  This will
impact the construction of services. A service is a business task or
activity that is realized through technology. The draft does a good job
of describing how that realization happens. But it doesn?t provide a
sufficient link between processes and services. The draft makes the point
that the central focus of! SOA is the task of business function?getting
something done. A business process is made up of tasks and activities
to achieve a goal (getting something done). The concept of creating
the service from the tasks and activities in a process is important. For
example, where on the continuum of fine grained to coarse grained should
a particular service be; this will affect interaction, reusability. The
relationship between processes and services needs to be in the Reference
Model.

 

While I saw that there is a note saying the glossary is still in
flux, since one of the objective of the Reference Model is a vocabulary,
having less in the glossary might be a better option. Is semantic
integration a guiding principle of SOA? 

 

With respect to conformance there needs to be business results. That
is an SOA should provide demonstrable mission accomplishments, e.g. ROI,
match a competitors distribution channel. SOA is not a technology.
Conformance should provide operational accomplishments, these should be
measurable.

 

Sally

 

 

! 

 

 

 

--

    
---------------------------------------------------------------------------------

  /   Ken
Laskey                                                               
\

 |    MITRE Corporation, M/S H305   
phone:  703-983-7934   |

 |    7515 Colshire
Drive                   
fax:      703-983-1379   |

  \   McLean VA
22102-7508                                             
/

   
----------------------------------------------------------------------------------