RE: Magic - It's not magic.

Yes, I think that this is an issue with WSDL.  However, I do think that it
is important to be able to describe existing web resources for
interoperation.

-bryan 

-----Original Message-----
From: Anne Thomas Manes
To: Thompson, Bryan B.; 'Jim Webber '; ''Walden Mathews' '; ''Mark Baker' ';
www-ws-arch@w3.org
Cc: Bebee, Bradley R.
Sent: 5/18/2003 9:49 AM
Subject: RE: Magic - It's not magic.

I think we would need to make major changes to WSDL to make it
adequately
support REST. The central artifact in WSDL is the <portType> (now
<interface>). In a RESTful world, the central artifact would be a
<resource>.

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Thompson, Bryan B.
> Sent: Sunday, May 18, 2003 2:35 AM
> To: 'Jim Webber '; ''Walden Mathews' '; ''Mark Baker' ';
> 'www-ws-arch@w3.org '
> Cc: Bebee, Bradley R.
> Subject: RE: Magic - It's not magic.
>
>
>
> I was suggesting that we might begin by offering REST-ful examples for
the
> existing use case scenarios corresponding to the current set of SOAP
> examples for those use case scenarios.  I think that this is a very
> practical small step.  While it would not set down a normative model
for
> how a REST-ful web service must implement those various use cases, it
> would set down an example of how a REST-ful web service could
implement
> those various use case scenarios.
>
> With respect to examples, Amazon has deployed both SOAP and REST-ful
> web service interfaces.  There was an article a while back in which
> they indicated that 80% of the use was the REST-ful interface -
> it was more
> useful, hence more valuable, for their business.  (Maybe someone
> can locate
> the link w/ Google - I'm in Hungary for W3C, and Google is
> coming back all in Hungarian;)
>
> The thing to remember about REST is that it describes the existing
> web, including its uses for commerical sites such as Google, Amazon,
> etc.  When approaching recommendations for web services architecture,
> a REST-ful take would add constraints such as, for example:
>
>  - Create a resource using HTTP POST by sending an XML
> representation of the
> new resource.  A status code of "Created" indicates success and
> the Location
> header holds the URI of the new resource.  (This is an additional
> constraint
> on the semantics of HTTP POST corresponding to a specific use case
> secenario.)
>
>  - Send an event using POST.  The XML representation of the event is
the
> entity body of the POST.  The status code should be "Accepted" to
indicate
> that the event has been received and that asychronous processing will
> continue.  (This is a, different, additional constraint on the
> semantics of
> HTTP POST corresponding to a different specific use case scenario.)
>
> Similar use case scenarios can be defined for other primitive
operations.
> However, there is probably NOT a REST-ful use case scenario for
> RPC, but you
> get RPC with SOAP so you have a complete solution space.
>
> I don't think that we need to hold up SOAP until we have standardized
> REST-ful web services.  Certainly there is work to be done here on
> standardization of REST-ful web service semantics and service
> discovery.  At
> the same time, I do not believe that we should accept a definition of
web
> services architecture that leaves out a REST-ful approach.  If we do
both,
> then we failing to enable both architectural styles.
>
> REST-ful web services are very practical, as shown by existing
> services such
> as Amazon.  However REST promotes a stronger separation of concerns
among
> the deployed components which tends to promote better reuse --
> poor reuse is
> a major source of costs in business systems.
>
> For example, if you design a web application such that the backend
data
> store using XML resource representations that are created by POST,
updated
> by PUT, read by GET, and destroyed by DELETE then you have a strong
> separation of concerns between your web application controller
> and your data
> persistence.  Further, you can directly reuse the data persistence for
> workflow or exposing web services.  (PUT and DELETE have a bad name on
the
> web.  However, when deployed in conjunction with security
> services, such as
> SAML or Liberty Alliance, there operations can be well described and
well
> governed by security policies.)
>
> I think that REST-ful web services offer an opportunity for federating
> multiple web services into new applications.  An example would combine
> semantic markup with news content with process (workflow state)
> representations and processing components, e.g., for content
> classification,
> to deliver a specific news aggregation service out of mostly
pre-existing
> components using business specific workflow models.  This sort of
approach
> makes strong use of URIs to express links among resource
> representations as
> a means of federating heterogeneous services.  This is an example
> of a very
> "web" approach to developing business solutions that is enabled by a
> REST-ful approach, but not by a SOAP approach.
>
> REST-ful web services and SOAP can be an either-or choice for a
specific
> application, but not for all applications.  They support
> different kinds of
> SOA solutions.  I think that we need them both.
>
> One thing that I think is lacking is the ability to describe existing
web
> services using WSDL.  I think that this unduly limits the utility
> of SOAP by
> making it impossible to directly describe and integrate traditional
web
> resources within a SOAP web services architecture.
>
> -bryan
>
> -----Original Message-----
> From: Jim Webber
> To: 'Walden Mathews'; 'Mark Baker'; www-ws-arch@w3.org
> Sent: 5/17/2003 3:38 PM
> Subject: RE: Magic
>
>
> > To understand it (even a little) is to build something.  Go
> > for it, everybody.
>
> I suspect this is not feasible for everyone to do. However, if the
REST
> contingent would perhaps post a simple application somewhere we could
> download, install, and marvel at it perhaps some of these issues would
> go
> away. Or at least the non-REST crowd could argue on a more informed
> basis.
>
> So how about it? If someone in the REST camp writes a simple
application
> for
> (say) Tomcat or IIS and makes it available to the group? If REST truly
> is as
> powerful as its strongest advocates suggest then this will surely come
> over
> in the example.
>
> To be honest the notion of epiphany appeals to me (I had one of those
> once
> and it was just fab), and so I wouldn't mind having one again.
>
> So, I guess in response to this thread I would have to say, "put up or
> shut
> up."*
>
> Jim
>
> * Appologies if that doesn't translate well from British.
>

Received on Sunday, 18 May 2003 10:20:33 UTC