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 10:32:36 UTC