Proposed resolution of issue #521

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

The issue reads

<issue>
Line 456, The statement that service orchestration is not "strictly  
part of SOA" as a reason for not addressing orchectration is not a  
strong reason; having the extent of the process model not fully  
defined as stated earlier in the paragraph is OK.

Do not weaken that argument.

Furthermore, ISO 19119, Clause 7.3.5 provides good input for the  
process model by addressing three general types of service  
architecture patterns for orchestration or chaining.

I recommend that this reference be considered during completion of  
the OASIS SOA RM process model.

First, a user-defined chain in which the human manages the workflow  
is called transparent.
Second, worklfow-managed chaining in which the human requests a WF  
manager package (or service) to control the chain, but also provide  
awareness of progress is called translucent.
Third, chaining in which the user invokes a service with no awareness  
of progress is called opaque and offers the same limited knowledge of  
the service chain that the OASIS RM line 273 defines for a service.

Tying ISO 19119 and other standards to the process model will promote  
chaining and has the possibility of greater savings for industry and  
government contemplating SOA.   "
</issue>


The intent of the statement was to note that orchestration is *not*  
an inherent part of the SOA RM. The reason for this is that the focus  
is on what the key relationships involving service are, we are not  
concerned with organizing multiple services. For similar reasons, we  
do not make the service provider and consumer a formal part of the RM  
itself (although they are mentioned liberally in the text) -- i.e.,  
the agents that represent service consumers and providers are not a  
formal part of the RM.

It is not possible to directly quote an ISO specification in an OASIS  
specification; due to potential and actual IPR conflicts.

The point above could be made with more force, and so, a potential  
proposed change could be:

After line 459:

The reason that orchestration (and choreography) are not part of the  
SOA RM is that the focus of the RM is on modeling what service is and  
what key relationships are involved in modeling service. We do not  
model the relationships between services in this RM.