RE: Proposal for WS-Types :: Web Services Description Specification

>From the process perspective, this work does not appear to be within the bounds of the current charter for this Working Group, so if you're asking for more than feedback from any WG members who might be interested in providing it, you might want to pursue another process such as W3C Member Submission [1].  Member Submission raises the profile of a spec, allows you to answer IPR statements about the technology within it, and make a request about what you think the W3C should do with the spec (e.g. start a Working Group to refine and standardize it).

[1] http://www.w3.org/2003/06/Process-20030618/submission.html

________________________________
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of Ruwan Wijesinghe
Sent: Tuesday, September 26, 2006 8:42 PM
To: www-ws-desc@w3.org
Subject: Re: Proposal for WS-Types :: Web Services Description Specification


Hi,

Thank you for the quick reply. These are our answers to the issues raised by you.

WS-Types is Not a proposal to go back to RPC style (even though the sample code attached seems like that, sorry for that code. We have chosen that code to make it simple). WS-Types type can contain any complex XML document just as any return message of normal web service. The only difference is that these document elements contain methods in addition to attributes (like HTML DOM). (Note that even the current Web Services can be used in RPC style)

It is true that WS-Types hides the presence of the network from client application developer. However this is not a problem as long as he is aware about that. Good example is that many service like Microsoft Sharepoint Server, Microsoft Team Foundation Server are managed using Web Services. However in order to provide easy access, Microsoft Provides a .Net class library with simple set of classes to administrate these services. These classes in turn call the web services for the real operation. WS-Types eliminate the need for creating this client components by the web service authors. The client stub generator can create this client class libraries by looking at the meta data available in WSTD file.

WSTD is by no means a replacement to WSDL. Rather, this is a supplement to WSDL. WSTD just provides an OOP based layer on top of WSDL. WSTD always referes to WSDL for its bindings and message formats. Since the bindings are defiend in WSDL as compliant with WS-*, and WSTD just refer them, These WS-Types stub classes with perfectly compliant with WS-*. Note that exsiting web services can convert to WS-Types compliant just by providing a WSTD document in a web share. This does not affect the style of web service messaging at all. Also note that any WS-Types compliant web service can be used by none WS-Types compliant web service client as usual.

Please note that we do not suggest to maintain pointers for web service objects in server side. Please look at the sample WSTD. It just maps the properties of the client object to existing messages passed to web service operation.

The expire attribute in SOAP header does not means any kind of Garbage Collection. That simply says that the commitment of the server to the data available in the return message is expired at the given time (this is an existing SOA pattern). The version number is used for the same purpose (to keep multiple versions of the data).

Please note that this is just an initial proposal and anything can be changed.

Thank you,

Ruwan





On 9/27/06, Tyrell Perera <tyrell.perera@gmail.com<mailto:tyrell.perera@gmail.com>> wrote:
---------- Forwarded message ----------
From: Amelia A Lewis <alewis@tibco.com <mailto:alewis@tibco.com> >
Date: Sep 26, 2006 8:39 PM
Subject: Re: Proposal for WS-Types :: Web Services Description Specification
To: Tyrell Perera <tyrell.perera@gmail.com<mailto:tyrell.perera@gmail.com>>
Cc: www-ws-desc@w3.org<mailto:www-ws-desc@w3.org>


Well, hmmm.

Disclaimer: I do not speak for the working group (although I am a
participant, representing my firm).  The following is not, however, an
official position of my firm; it's just my opinion, based on
experience.

RPC is not revolutionary.  Or new.  Object remoting is RPC in drag.
RPC is broken, in my opinion and experience; closing your eyes tightly
and repeating "there is no network" does not lead to robust and
reliable communications over the network.

There's a network there.  The network is not a computer.
Computer-internal addressing formats are not appropriate across a
network, and the temptation to build in "pointers" inevitably leads
these APIs into darkness and chaos.  There is no stack; there is no
return value to pop off the missing stack.

"SOAP" is no longer an acronym, but when it was, it was the "Simple
Object Access Protocol."  Yup, it was a revolutionary object-oriented
protocol (with looser coupling than RMI or Corba or DCOM).  It is
worth noting that the trend in web services has been notably *away*
from "rpc style" to "document style"--toward messaging, toward looser
coupling, toward asynchronicity.

I note that the last paragraph of page 3 of this proposal acknowledges
that there is a problem: the proposed WS-Types-generated services are
incompletely compatible with existing services.  That "object
expiration" is tied to this raises awkward questions about distributed
garbage collection.  That there is no mention of WS-Addressing in the
discussion of addressing syntax is also noteworthy.  What about
security?  Setting policies?  Is anything other than request/response
in client/server mode supported?  For that matter--where's the schema,
DTD, RNG schema, or pseudo-schema for the two XML dialects which are
demonstrated here solely by example?

I'd certainly oppose any adoption by the WSD WG; I think that our
group needs to finish getting the basic description of sending web
service messages over a network done.  Past CR, into PR and then Rec,
and we can all have a final blowout at the Last WSD Face-to-Face ever
and generate embarrassing stories to tell about one another.

I would also recommend that the authors of this spec investigate
WS-Addressing (for dynamic addressing of services), the WS-Resource
framework (at OASIS) for something rather object-like that is more
nearly native to the network, and build anything on top of other
specifications that can handle some of the hard issues (where "hard"
means "unsolvable in the general case").  For that matter,
investigating WSDL's extension mechanisms and something like
WS-Policy, to provide annotations to WSDL rather than a completely new
XML dialect for description of messages (oh, all right, then,
"messages masquerading as objects") over a network.  Doing so would
lower the barrier to entry (if it looked interesting, the people who
still think that RPC is a good idea would prolly give it a whirl,
after all ... but not if they have to give up existing stuff and
compatibility with WS-*).

Uh.  I'd call that my two cents, but I s'pose it's a either a nickel
(measured by size) or nothing (measured by encouraging statements).
Oh, well.

Amy!
On Tue, 26 Sep 2006 15:58:25 +0530
"Tyrell Perera" <tyrell.perera@gmail.com<mailto:tyrell.perera@gmail.com>> wrote:

>Hi,
>
>We have been working on a Object Oriented Web Services Description
>Specification.
>
>"Here we suggest a new revolutionary web service specification that
>will totally change how people use web services or how people develop
>web service client applications. Currently web services do not support
>OOP style programming. Today, the objects returned from the web
>services only have properties. They do not have any methods.
>
>This new technology will enable web services to return objects with
>both properties and methods. When these methods are called they will
>call some other web services. Since the service URL of the web
>services can be assigned dynamically, we can use them to develop
>service brokers that work seamlessly."
>
>We are attaching a preliminary draft proposal to this mail. Please let
>us know your thoughts on this and necessary steps to follow, in order
>to bring this to community evaluation.
>
>Thnaks and Regards,
>
>Tyrell Perera and Ruwan Wijesinghe
>


--
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com <mailto:alewis@tibco.com>