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

I believe that I strongly agree with chris on this. I would like to 
give my reasons:

If we take seriously the mandate of supporting specifications that 
support app<->app cooperation (i.e., not just communication but 
effective interworking) for the large scale then we need to ensure that 
we lay down sufficient guidelines to support that world-view.

That may well mean that `your favorite' method of inter-app cooperation 
is NOT supported. The reason being that, in order to support truly 
Internet-scale systems, we need more overhead/infrastructure than might 
be necessary `between consenting applications in private'. Of course, 
part of the success of that is identifying the absolute minimum 
infrastructure needed.

I believe that we have a choice here: we can attempt to bless the 
current chaos, or we can give our professional opinion as to what is 
really needed. I personally favor attempting the latter (since we are 
SUPPOSED to be the people who know).

Having said all that, there is the great American tradition of 
grandfathering existing practice. I have no objection to that; but, I 
repeat, I believe that we do our audience no favors if we fail to grasp 
the larger mandate.

Frank McCabe

On Tuesday, June 10, 2003, at 08:15  AM, Christopher B Ferris wrote:

>
> 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 12:14:59 UTC