RE: Issue 64, @method

Dave, 

this option was mentioned before (cf. posts by me [1], [2]), and I came
to the conclusion that describing the HTTP interface (CRUD methods) may
be impractical because applications won't be able to restrict it in
order to get strong typing.

IOW, if we define the HTTP interface, who will use it? I expect any
application, even if it uses HTTP as the application protocol, will want
to indicate that it only accepts some representation formats (media
types, schemata) and that it produces others.

OTOH if you present a good usecase for an application described with
WSDL to indicate that it supports the generic HTTP interface, I'll
support the idea that such interface be produced by this WG. In fact if
the interface *is* produced inside the WSD WG, we would likely also
produce the (well-known) HTTP binding instance so that applications
would only have to provide an endpoint and bind it to that binding.

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/


[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0006.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0116.html


On Tue, 2004-04-06 at 01:04, David Orchard wrote:
> Jonathan,
> 
> Are you suggesting that WSDL WG would define that interface?  I think BEA is interested in WSDL providing a standardized interface definition of the HTTP operations.  
> 
> I think we are seeing 2 interesting market forces:
> 1) Customers are interested in deploying apps that have some interfaces that use HTTP as a transfer protocol.  They want to be able to use WSDL to describe both the HTTP as transport and HTTP as transfer styles.  
> 2) We've seen some interesting and obvious Web services protocols make use of HTTP directly.  A good example is Atom [1] which uses HTTP as the application protocol.  They have a binding of these verbs to SOAP.  In this particular case, a WSDL 2.0 definition of the HTTP interface would be usable by Atom.  
> 
> I do realize that Atom could model HTTP as an Atom interface.  However, creating the web service definition for the HTTP interface seems somewhat orthogonal  to what Atom is interested in doing, which is describing the message contents under the constrained interface.  I also think that they are doing some interesting work on mapping the HTTP interface exchanging SOAP content onto HTTP as a transport (ie via POST). [2]
> 
> I think that an application may have either a custom interface or the HTTP interface and there is a binding to the underlying protocols interface, the table of relationships is roughly:
> 
> 1. App protocol (custom) + HTTP as Transport = POST
> 2. App protocol (custom) + HTTP as Transfer = various HTTP methods
> 3. App protocol (HTTP) + HTTP as Transfer = direct mapping to HTTP.  Seems like this could be really straight forward to describe in WSDL.
> 4. App protocol (HTTP) + Some other protocol like IIOP as transport = custom binding to protocol.
> 
> I'd like to state that I think that an important reason for doing this is to enable applications to mix and match their application style to the protocol style with the fidelity they want.
> 
> Right now, WSDL optimizes for case #1, and we'll need to allow for case #2 given the SOAP web method feature.  I think I've argued earlier in this message that cases 3 and 4 are also quite interesting.   I don't think they will take much time to model either.  There might even be some re-use for case #2.  
> 
> FWIW, I would rather actually describe the HTTP interface as a REST or constrained interface because HTTP is simply one realization of a RESTful interaction.  There are many potential applications that may want a constrained interface for doing state transfer that don't always (and maybe even never) use HTTP.  It seems a bit wierd to talk about "the HTTP operation" when it might get bound to IIOP.  But there seems to be a rather strong (cough) reaction to any proposal that has "REST" in it.  I figure that talking about a real world scenario of using HTTP as the interface illustrates the point better than talking about "what-ifs".
> 
> Cheers,
> Dave
> 
> [1] http://bitworking.org/projects/atom/draft-gregorio-09.html
> [2] http://www.intertwingly.net/wiki/pie/PacePutDelete

Received on Tuesday, 6 April 2004 05:36:24 UTC