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> wrote:
>
> ---------- Forwarded message ----------
> From: Amelia A Lewis <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>
> Cc: 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> 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
>