Some of these questions are a prelude to a larger issue - what is the
relationship of WSRequest and WSDL? My working model (now ;-) is that
WSRequest represents a message exchange, described by the XML Schema types
for the input and output message, the message exchange pattern (is more than
in-only supported?), the endpoint address, the basic binding method (SOAP
1.1, SOAP 1.2, HTTP) and a few options (HTTP method, WSA engaged, action).
That leaves a lot of things from WSDL that don't have a direct
correspondence - the abstraction of "operations", more details of the
binding method, binding parameters (i.e. options).
The abstract parts such as operations live at a higher level, and can be
provided through wrappers such as my stub generators. But at the binding
level there is a closer correspondence between what may appear in a WSDL and
what the WSRequest can accommodate.
The disconnect between the binding behavior encapsulated in WSRequest and
the binding description from WSDL 2.0 is the message framing algorithms of
the WSDL 2.0 HTTP Binding. Depending upon the media type, the XML is
serialized as the message body, or deconstructed into the URL, or a mixture
of the two. I don't think the WSRequest object does more than simply omit
the SOAP envelope (though I'm still trying to get it working enough to tell
for sure.)
We can approach support for the HTTP Binding, and thus for REST services, in
two ways:
1) Use the WSRequest object as an "open socket" and have the stub do the
heavy lifting of generating "raw" content (payload) and headers (options).
2) Encapsulate the behavior of the HTTP binding (and other bindings!) within
the WSRequest object. By copying a set of options that correspond fairly
directly to the attributes in the HTTP binding, the WSRequest can formulate
the message accordingly.
An example of (1) might look something like this (where getURLfromPayload()
and trimPayload() are two gnarly JS functions in the stub that implement
most of the HTTP Binding smarts):
var wsr = new WSRequest(); //environment specific
var payload = <wrapper><param1>a</param1><param2>b</param2></wrapper>;
var options = new Array();
options.useSOAP = false;
options.HTTPmethod = "GET";
options.HTTPversion = "1.1";
var url = getURLfromPayload(/*address*/
'http://www.wso2.org/services/example/rest';
/*location*/ 'method1?format=rest';
/*inputSerialization*/
"application/x-www-form-urlencoded",
/*queryParameterSeparator*/ '&',
/*ignoreUncited*/ false,
payload);
wsr.open(options, url, false);
wsr.send(trimPayload(/*address*/
'http://www.wso2.org/services/example/rest';
/*location*/ 'method1?format=rest';
/*inputSerialization*/
"application/x-www-form-urlencoded",
/*queryParameterSeparator*/ '&',
/*ignoreUncited*/ false,
payload));
var result = wsr.responseText;
An example of (2) simply sets options corresponding to the WSDL and the
WSRequest object takes care of forumlating the messages.
var wsr = new WSRequest(); //environment specific
var payload = <wrapper><param1>a</param1><param2>b</param2></wrapper>;
var options = new Array();
options.useSOAP = false;
options.HTTPmethod = "GET";
options.HTTPversion = "1.1";
options.inputSerialization = "application/x-www-form-urlencoded";
options.queryParameterSeparator = '&';
options.ignoreUncited = false;
options.location = ''method1?format=rest';
wsr.open(options, 'http://www.wso2.org/services/example/rest', false);
wsr.send(payload);
var result = wsr.responseText;
That's not really a fair comparison of ease of code - clearly hiding the
code within the WSRequest object makes the JS simpler. But this code will
often be hidden within a stub so that's not a definitive differentiator.
I prefer the second alternative for several reasons:
1) The binding code is done in a real programming language, not in
Javascript. A complex binding algorithm might be better suited to a static
language.
2) The binding code becomes more of a strategic asset of the Mashup Server,
and not simply some JS code that can be cloned and used easily in other
places.
3) It makes WSRequest easier to use without stubs (which I think is till an
interesting alternative in many cases).
4) I still expect people to take the stubs we generate, and customize them.
Simplifying the stubs is good for this.
5) It bases the behavior of WSRequest on a clear and detailed specification
(WSDL 2.0), which also has the benefit of being an open standard (soon).
This will moderate the potential for confusing the users with too many ways
to formulate messages.
7) We should already have code in Axis2 to frame these messages - broadens
the reuse of that code.
6) Consistency of message framing behavior with other WSDL 2.0-compatible
toolkits. Less customer education required.
So my proposal would be to add options to the WSRequest object that
correspond to the options available in the WSDL 2.0 bindings (all three of
them), and make the message framing behavior of WSRequest conform to that
spec. If we like this direction I can produce a spec for the necessary
additional options.
I have not thought much about how to handle WSDL extensions in this way.
WS-Addressing is straightforward, WS-Security might not be so (have to look
at the PHP solutions). But a straitforward extrapolation would augment the
options to include extension specs.
Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
-----Original Message-----
Sent: Monday, April 23, 2007 7:09 PM
Subject: Re: [Wsf-general] WSRequest.options.useSOAP
+1 to switching to WSRequest.options.binding={soap11,soap12,http}.
Sanjiva.
Post by Jonathan MarshThe useSOAP option has a value which is either 1.1, 1.2, true, or
false. This is a bit messy (already two of the values are
synonymous),
Post by Jonathan Marshand doesn't scale beyond SOAP and bare HTTP. For instance, how would
this option accommodate a JSON or XMPP binding? In the long run a
clear
Post by Jonathan Marshcorrespondence between the WSRequest options (and values) and WSDL
bindings would be an advantage. WSDL binding types are currently
identified by a URI, but a synonymous enumeration containing
"soap11",
Post by Jonathan Marsh"soap12", and "http" would suffice.
*Jonathan Marsh* - http://www.wso2.com -
http://auburnmarshes.spaces.live.com
---------------------------------------------------------------------
---
Post by Jonathan Marsh_______________________________________________
Wsf-general mailing list
http://wso2.org/cgi-bin/mailman/listinfo/wsf-general
--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
"Oxygenating the Web Service Platform."
_______________________________________________
Wsf-general mailing list
http://wso2.org/cgi-bin/mailman/listinfo/wsf-general