RE: Counting noses on "is SOAP and/or WSDL intrinsic to the def inition of Web service"

I MOST CERTAINLY agree with "sync and sync interaction should be a good
starting set".

I think that I am seeing this distinction increasingly being made in
published analyses of what is going on in Web services.  I think that we
would be well advised to bake this in at a fairly high level -- because
it is, in practical terms, a REALLY useful and useable distinction.

-----Original Message-----
From: Hao He [mailto:Hao.He@thomson.com.au] 
Sent: Tuesday, June 10, 2003 6:36 PM
To: 'Christopher B Ferris'; 'www-ws-arch@w3.org'
Subject: RE: Counting noses on "is SOAP and/or WSDL intrinsic to the def
inition of Web service"


> What exactly do you want the WSA document to say about "plain XML over

> HTTP"?
> 
> <hh>First, we want the WSA formally recognize "plain XML over HTTP" as
part
> of the architecture. </hh>

While I can certainly appreciate the motivation for this, and am
somewhat sympathetic, I really do think that it is out of scope.

<hh>The primary objective of this group is to produce something that is
simple, useful and can be easily used by most developers. 
If we ignore the large number of cases out there, we will lose them.
This will be a lose-lose-lose situation for users, software vendors, and
this working group. Therefore, I strongly believe this is right in the
scope of this WG.</hh>

> 
> We could (I think) note in the text or an appendix what the WSDL
description
> of that type of service is, making XML over plain HTTP a "minimal web 
> service" in the nomenclature I proposed yesterday (or "basic" or
whatever
> less perjorative term we want to supply). Still, we would have to note
that
> the actual form of the content is completely unconstrained, or rather 
> application-defined. Thus app <-> app communication relies on ad hoc /
out
> of band definition of both the syntax and the semantics.  We would 
> also
have
> 
> <hh>This sounds reasonable. We could define a minimum set of app <-> 
> app communication patterns here. </hh>

And how do we hang anything else on the bare minimum foundation without
having a defined process model? I don't think that it is in scope 

<hh>If you have a layered arch, we can gradually apply additional
constraints. In the simplest case, people can have whatever process
model they like as long as the process model is transparent to the
client, i.e.. HTTP proxies. Then, if the client wants to mandate a
process model, or its most immediate server wants to mandate a process
model, one can add SOAP constraint. This is a technical question and I
believe this group can solve it one way or another. </hh> 


for
us to define such a process model. That is what XMLP has been doing for
the past couple of years. IMO, if you want to pass around XML in HTTP
because you feel that you don't require the other goop, that's perfectly
fine, but it is not IMO part of the architecture we should be defining 
in WSA. As I indicated in my previous post, that is simply effective use
of Web arch and that is the concern of the TAG.

<hh>I believe that the WSA we produce should also be part of the Web
arch. A layered architecture that enables developers to see a natural
transition from non-SOAP XML to SOAP will only benefit all of us. </hh>


> 
> to note that any extensions to provide reliable messaging, security, 
> correlation of multi-part services, etc. (see the Requirements 
> document)
are
> also ad hoc / application-defined.
> 
> <hh>That is ok.</hh>

I disagree, I don't think that it is okay that we have an architecture
that simply says that for this flavor, everything is ad hoc. If indeed
everything is at the application level, then it is not WSA, it is the
application architecture.

<hh>I really should not agree with the word ad hoc.  Even we have a
minimum set of constraints, we can still define it clearly and
precisely. One thing we can define here is a simple app <--> app
communication pattern.  For example, sync and sync interaction should be
a good starting set. </hh>


> 
> I'm happy to say something in the WSA document that genuflects over
"plain
> XML over HTTP" to blesses it as a "web service" design pattern for 
> those
who

I am not.

> have application-defined syntaxes and don't need reliable messaging, 
> correlation, choreography, security, late binding, etc.  But we can't
avoid
> the "but, on the other hand, that doesn't support most of the WSA 
> requirements ... users SHOULD migrate to SOAP when these become
important in
> their application context" or something.
> 
> <hh>That is ok too. As long as we can point the its relationship with
SOAP
> and those features.
> </hh>

What relationship is that? 

<hh>The additional constraints SOAP introduces. </hh>

> 

I will reiterate my position that while I appreciate the desire, I think
that it is outside the scope of the WSA to try to encompass generic 
XML/HTTP
in the WSA. Are we suggesting that WSA define the architecture used by 
XForms?
Technically, XHTML is XML. Do we include that in our architecture... it
is 
starting
to look an awful lot like Web arch and not WSA.

<hh>It is not important what actually is inside the document. WSA is-a
Web arch.  </hh>

I would strongly urge the WG to consider what it is opening itself up to

by expanding
the scope of WSA to generic XML/HTTP as being a Web service. It may have

service
characteristics and it may be on the Web, but...

<hh>Again, the primary goal is to create something useful, if we ignore
users, they will ignore us. If a software vendor ignores its customers,
their customers will ignore the vendor. </hh>

Hao

Received on Tuesday, 10 June 2003 20:01:17 UTC