W3C home > Mailing lists > Public > www-forms@w3.org > June 2004

RE: Article: Use XForms to send and receive Web services messages

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 29 Jun 2004 18:07:40 +0100
To: "'Gary Stewart'" <gary@deltagreen.co.uk>
Cc: <www-forms@w3.org>, "'Gerald Bauer'" <luxorxul@yahoo.ca>
Message-ID: <000501c45dfb$95db53d0$6701a8c0@W100>

Gary,

Gary wrote:
> On Mon, 28 Jun 2004, Gerald Bauer wrote:
> 
> >   IBM DeveloperWorks has published a new XForms
> > article by Nicholas Chase titled "Tip: Use XForms to
> > send and receive Web services messages"
> 
> This article was interesting but raised a few questions in my head. 
> First I notice that IBM use the FormsPlayer's text-xml-post so they 
> can talk to the SOAP server using text/xml. Most XForms applications 
> won't have this obviously.

My guess is that some of our samples on the formsPlayer site still use that
(old) technique. It was implemented in a version of formsPlayer that
followed the XForms CR spec (November 2002), since at that time there was no
way to indicate that you wanted a Content-Type of "text/xml", as opposed to
the default "application/xml". This prevented us from doing simple SOAP 1.1
requests.

Some time later the mediatype attribute was added to XForms to take care of
this, so the correct syntax is now:

  <submision action="http://..." method="post" mediatype="text/xml">

This is supported in XForms 1.0 and should work across implementations. What
happens is that because @method is set to "post" the data is 'serialised'
using the 'application/xml' serialisation (giving you an XML document), and
then when the document is sent down the wire, the HTTP Content-Type header
is set to the value of @mediatype. This latter feature also means you can
use settings like "text/xml; charset=utf-8".

Note that there is still another problem for SOAP; version 1.1 allowed
servers to mandate a SOAPAction header. This has thankfully been dropped in
SOAP 1.2, but it means that it's hit and miss whether the server will accept
a SOAP packet submitted using the technique just described.

This will be addressed in version 1.1 of XForms, but for now formsPlayer
uses the xf:extension element to get the header in. For example:

<xforms:submission
 id="sub"
 ref="/"
 method="post"
 mediatype="text/xml; charset=utf-8"
 replace="instance"  action="http://ejse.com/WeatherService/Service.asmx"
>
  <xforms:extension>
    <config xmlns="">
      <header name="SOAPAction">
        "http://ejse.com/WeatherService/GetExtendedWeatherInfo" 
      </header>
    </config>
  </xforms:extension>
</xforms:submission>

(Note that we have just discovered that although this feature has been
present for over a year, it has not been enabled in recent distributions of
formsPlayer. This means that anyone interested in trying this will have to
wait for a patch that will be out in the next couple of days. This feature
will also allow XForms to be used to talk to WebDAV servers.)


> With SOAP 1.2 the type application/soap+xml is the expected MIME type, 
> does this mean that XForms won't be able to talk to the SOAP server? 
> That would be a shame given how well they could be used together.

You are exactly right that XForms and Web Services go very nicely together!
With SOAP 1.2, all you need to do is this (i.e., no extra headers are
needed):

<xforms:submission
 id="sub"
 ref="/"
 method="post"
 mediatype="application/soap+xml; charset=utf-8"  replace="instance"
action="http://ejse.com/WeatherService/Service.asmx"
/>


Note that many servers also support GET, which in some situations is a more
'correct' way to retrieve data. For example, the weather web service
referred to here is only giving you back the current state of the weather -
you can't change it ;) - so GET is fine for retrieving the SOAP packet. And
the fact that XForms will easily serialise a nested XML document correctly
to name/value pairs - even if the original data is nested - means that you
can actually use the same SOAP packet for both GET and POST requests:

<xforms:instance id="instRQ">
  <soap:Envelope
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:wr="http://ejse.com/WeatherService/"
  >
    <soap:Body>
      <wr:GetNineDayForecastInfo>
        <wr:zipCode>02852</wr:zipCode>
      </wr:GetNineDayForecastInfo>
    </soap:Body>
  </soap:Envelope>
</xforms:instance>

<xforms:submission
 id="sub"
 ref="instance('instRQ')"
 method="get"
 replace="instance"
action="http://ejse.com/WeatherService/Service.asmx/GetExtendedWeatherInfo"
/>

On submission, the resulting URL that the GET is sent to, is this:

 
<http://ejse.com/WeatherService/Service.asmx/GetExtendedWeatherInfo?zipCode=
02852>

i.e., any element with data gets used for a name/value pair, with the
element's local-name() used for the 'name' part.

Finally, the presence of the GET method gives you a way to initialise an
instance to the results of a SOAP request:

<xforms:instance
 id="instRS"
src="http://ejse.com/WeatherService/Service.asmx/GetExtendedWeatherInfo?zipC
ode=02852"
/>

An example of all of this is available here:

  <http://www.formsPlayer.com/demo/web-services/weather.html>

which shows a 9 day forecast for US zip codes. (It should show a default
forecast in most XForms processors, although the images - pretty clouds,
suns, rain and stuff - will not show up in all processors.)

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/
Received on Tuesday, 29 June 2004 13:07:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:58 GMT