- 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>
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 UTC