RE: Comments 13112002 on /TR/ 2002/WD-wsa-reqs-20021011 from Paul Meurisse,drs.ir.lic, Managing Director Veritas IT Management - www.veritasitmanagement.com

It seems to me that these suggestions would be more usefully addressed
to the evolving architecture document itself as opposed to the
requirements document.  You seem to be making a case that this approach
helps to satisfy the requirements as they stand, so why bother to mess
with the requirements?  I'm not sure if I'm putting that clearly.  Let
me try another way.  It seems to me that putting this stuff into the
requirements document does not materially add to an understanding of the
requirements themselves as much as it injects a proposed solution.  It
seems to me that the these suggestions have merit as architectural
components.  Let us consider them as that, which is what I think the
real intent is.  I may be missing something, but it does not seem to me
that the existing requirements document in any way precludes
consideration of these ideas.

Besides, to take a more pragmatic point of view, there is a certain
sense that this working group needs to operate on something resembling a
schedule.  I think no one on the team would consider the requirements
doc to be perfect or perhaps even optimal, but it does have the virtue
of -- at last -- being agreed upon as something we can all live with.  I
think that there would be very strong resistance to re-opening debate on
that document except for the most pressing of reasons.

-----Original Message-----
From: Paul Meurisse [mailto:paul.meurisse@veritasitmanagement.com] 
Sent: Thursday, November 14, 2002 5:02 AM
To: www-wsa-comments@w3.org
Cc: www-ws-arch@w3.org
Subject: Comments 13112002 on /TR/ 2002/WD-wsa-reqs-20021011 from Paul
Meurisse,drs.ir.lic, Managing Director Veritas IT Management -
www.veritasitmanagement.com




Web Services Architecture Requirements - W3C Working Draft 11 October
2002


          Comments from Paul Meurisse,drs.ir.lic, Managing Director.
          Veritas I.T. Management (www.veritasitmanagement.com)

I. Context :

In order to be complete while at the same time avoiding contradictions,
ambiguity and non interoperability, the WSA CSF (critical success
factor) hierarchies as defined in above mentioned document
http://www.w3.org/TR/2002/WD-wsa-reqs-20021011
should be amended in several places. The terminology should also be
extended with :
- Context,
- choreography of messages = ordered sequence of messages with
propagation of context (see above),
- business process = choreography of  web services using a choreography
of messages (see above) to communicate between those web services within
and across trust boundaries.

II. My comments (proposed amendments) :

Comment 1 (amendment) : The WSA CSF hierarchies in the above
requirements document should describe the lifecycle of a the web service
which includes its persistence and re-activation.

Comment 2 (amendment) : The WSA CSF hierarchies in the above
requirements document should describe how a web service context can be
created, initialised and propagated.

Comment 3 (amendment) : The WSA CSF hierarchies in the above
requirements document should describe the nesting (and dynamic
iteration) of web services with initialisation of a context at the
highest level and then the propagation of context downwards and
propagation of error conditions upwards the nesting hierarchy.

Comment 4 (amendment) : The WSA CSF hierarchies in the above
requirements document should contain CSF hierarchies for the business
processes as an orchestration of web services (using also an
orchestration of messages). Indeed, business processes are web services
on their own and can be used in higher business processes which are
again web services. See also nesting above.

Comment 5 (amendment) : WSA CSF hierarchies in the above requirements
document should contain CSF hierarchies for long lived web service
transactions and long lived business processes (as defined as an
orchestration of web services using a choreography of messages)
transactions.

III. Motivations for the above comments based upon the goals and CSF
hierarchies of the WSA requirements document itself. As such it
contributes to the overall conceptual integrity of the requirements
document (AC002.1).

III.1. Motivation1 :

AC017 mentions that the WSA must support (in order to allow the EDI
users to evolve towards web services) interactions which are :
- long running
- stateful
- choreographed

within and across trust boundaries.

But once a web service has a state (because it is a stateful interaction
as mentioned in AC017 or because it is long running interaction as
mentioned in AC017 with persistence of the state in order to guarantee
consistency) it has to create a context to describe the state. This
context can thus be used for security and transactions too. Also this
context must be propagated within nested web services and communicated
to other peer web services using part of the message with inter
operability in mind. It also means that the WSA must define how a
context is created, initialised, persisted but also what can be put in
this context (structure of the context with extensibility in mind).

The XML schema of this new artifact = context could have elements for :

- state of the web service itself,
- nesting degree
- state of the higher level business process of which it is part,
- security,
- local and extended transactional behaviour

The - context - should be propagated in the header of the SOAP header,
all this defined in such a way that there is interoperability.

Also when web services are choreographed we need an overall context for
this choreography and this can be seen as the business process context
where the business process is defined as a choreography of web services.

When we talk about a choreography of web services and a choreography of
messages, we have both the private view of this message choreography and
the public view of it. Both need to match (means have to be defined in
order to guarantee this match) because there private and public view are
complementary views of the same message choreography and the business
process (= web service
choreography) context must be propagated by the message choreography.

III.2. Motivation 2 :

AC002.1 provides conceptual integrity, i.e. a unified theme rather than
a set of disjoint ideas, which generally characterizes designs that are
easy to understand and implement.

AC002.1.1 reduces complexity by decomposition of the component's
functionality and its position within the architecture

AC002.1.2 eases development and maintenance of implementations of the
architecture by defining architectural components that are logical,
consistent, and thus easy to understand.

Conform AC002.1, AC002.1.1 and AC002.1.2 it seems an absolute must to
define, in addition of the - context- as mentioned in motivation 1, the
orchestration of web services as a business process. I propose not only
to add the necessary CSF hierarchy but also to add the new term -
business process - to the general terminology and to define it as an
orchestration of web services where the web services interact through a
sequenced choreography of messages which are propagating the business
process context.

III.3. Motivation 3 :

AC024 must enable peer to peer interacting web services. For me this is
a simple use case for web service orchestration.

III.4. Motivation 4 :

AC002 provides for modular web services architecture components, with
each at a level of granularity appropriate (for me granularity includes
nesting of web services and business processes - defined as an
orchestration of web services - which are web service again ) to meet
the other goals.

III.5. Motivation 5 :

AC003 : is sufficiently extensible to allow for future evolution of
technology and of business goals. For me this means that - context- must
be defined in a formal and extensible way with interoperability in mind
while being propagated through a message choreography.

III.6. Motivation 6 :

AR003.3 technologies following this architecture should not impede the
development of complex interaction scenarios. For me complex interaction
scenarios can be defined as a choreography of web services using a
choreography of messages.


III.7. Motivation 7 :

AR003.5 systems must not be precluded from quoting, either unmodified or
modified, messages within other messages, to an arbitrary depth. This
should be combined with the nesting of web services and the choreography
of web services.

Received on Thursday, 14 November 2002 16:05:00 UTC