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