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

Hao He wrote on 06/10/2003 01:32:31 AM:

<snip/>
> 
> 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.

> 
> 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 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.

> 
> 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.

> 
> 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? 

> 

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.

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...

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Received on Tuesday, 10 June 2003 11:15:44 UTC