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

Greetings,

      Thank you very much for your kind and thoughtful comments on the
recently published WSA Requirements document. We are very grateful for your
analysis and astute feedback.

      At this time, the Working Group has decided to focus our efforts on
the reference architecture itself. Doing this allows us to approach the
problem iteratively, in a manner well aligned with both the current state
of the technology and with our own understanding of the needs for the WSA.
In future possible iterations over the requirements, we will most certainly
make good use of your comments, and hopefully thereby produce a better
document.

      If in the future you conceive of additional comments, please do not
hesitate to send them for the group's consideration. Cheers until then, and
once again, thanks!

Regards,

D-

*************************************************
Dr. Daniel Austin
Sr. Technical Architect / Architecture Team Lead
daniel_austin@notes.grainger.com <----- Note change!
847 793 5044
Visit http://www.grainger.com

"The ideal architect should be a person of letters, a mathematician,
familiar with historical studies, a diligent student of philosophy,
acquainted with music, not ignorant of medicine, learned in the responses
of jurisconsults, familiar with astronomy and astronomical calculations."
Vitruvius, circa 25 BC



                                                                                                                                             
                      "Paul Meurisse"                                                                                                        
                      <paul.meurisse@veritasitmana        To:       www-wsa-comments@w3.org                                                  
                      gement.com>                         cc:       www-ws-arch@w3.org                                                       
                      Sent by:                            Subject:  Comments 13112002 on /TR/ 2002/WD-wsa-reqs-20021011 from Paul            
                      www-ws-arch-request@w3.org           Meurisse,drs.ir.lic, Managing Director Veritas IT Management -                    
                                                           www.veritasitmanagement.com                                                       
                                                                                                                                             
                      11/14/2002 05:02 AM                                                                                                    
                      Please respond to                                                                                                      
                      paul.meurisse                                                                                                          
                                                                                                                                             
                                                                                                                                             






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:36:05 UTC