In the first installment of this two-part series, we detailed the XML Forms Generator’s ability to generate standards-compliant forms, using XML instance documents as a starting point. We showed you how automating form generation accelerates the development of forms and how Model Driven Development techniques assist in that automation.
Aside from XML instance data, another common description mechanism for data that must be gathered is WSDL. By leveraging EMF models of WSDL and XML Schema, you can also generate forms -- and even meaningful form-submission response pages -- directly from WSDL documents.
The XML Forms Generator does just that, automatically generating XHTML/XForms documents from source WSDL documents. The XML Forms Generator distribution also includes tooling for the generation and testing of JavaServer Pages (JSP) Web service response templates.
The generated forms adhere to the XHTML and XForms 1.0 standards, and can be viewed in popular XHTML/XForms renderers.
The tools described in this article are seamlessly integrated into the open source Eclipse tools platform, and are freely available on IBM alphaWorks as the XML Forms Generator.
As it does with XML instance documents (see Part 1), the XML Forms Generator takes a model-driven approach when generating forms from WSDL documents. The Generator reads a WSDL document’s properties (operations, message parts, type definitions, and so on) into run-time Java™ structures determined by an EMF model of WSDL and XML Schema. As a result, the structure facilitates analysis of the WSDL document, allowing for the creation of a prototypical XML instance document that in turn (under the covers) drives the generation of a functioning form that is ready for deployment.
The resulting form may be submitted directly to a Web service endpoint. Note, however, that nothing in the XForms 1.0 Recommendation specifically requires the success of such an invocation, so you may need to include a middleware intermediary. The XML Forms Generator distribution comes with a Java 2 Platform, Enterprise Edition (J2EE) Web application that includes a pair of servlets that provide simple demonstrations of such a middle-tier solution (see Resources).
Also, because a WSDL document encodes the structure of the data to be sent in response to a service invocation, it is possible to generate a template for displaying a response to the invocation of a WSDL-defined Web service operation. There are several possible approaches to generating response templates, including XSLT and even XForms itself with the use of its switch/case mechanism. To demonstrate interactions in a J2EE environment, the XML Forms Generator's current release instead generates response templates as JSP files.
To avoid the complexity of multiple-submit forms, the XML Forms Generator requires that the user select a single operation for which a form will be generated. It does so by reading the WSDL to determine the available operations and presenting a wizard page that includes a list of these operations, from which one must be chosen (see Figure 1).
Figure 1. Selecting an operation defined in a WSDL document
The XML Forms Generator does further analysis, which results in the selection of a default submission target for the form that is the actual service endpoint URL.
Figure 2. The form's default submission target overridden to match the service address
In Listing 1, the endpoint is discovered through an examination of the service element declared in the WSDL document:
Listing 1. WSDL code with service element
<service name="GoogleSearchService">
<port name="GoogleSearchPort" binding="typens:GoogleSearchBinding">
<soap:address location="http://api.google.com/search/beta2"/>
</port>
</service>
|
The input message parts of the selected operation, as well as the types defined in XML Schema within the WSDL's types section, are examined to produce a prototypical XML instance document that carries all the data that could be submitted in the request message. Listing 2 shows a simple WSDL portType declaration with a single operation, and its input message definition:
Listing 2. WSDL portType declaration
<portType name="GoogleSearchPort">
<operation name="doSpellingSuggestion">
<input message="typens:doSpellingSuggestion"/>
<output message="typens:doSpellingSuggestionResponse"/>
</operation>
</portType>
<message name="doSpellingSuggestion">
<part name="key" type="xsd:string"/>
<part name="phrase" type="xsd:string"/>
</message>
|
From this input message declaration, the XML Forms Generator generates an XML instance document (see Listing 3), from which it then creates a functioning XHTML/XForms document. The instance document is itself a SOAP envelope, which allows direct invocation to a Web service without the need for any special manipulation of the instance prior to submission of the form.
Listing 3. XML instance document
<?xml version="1.0" encoding="ASCII"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
encodingStyle="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<typens:doSpellingSuggestion xmlns:typens="urn:GoogleSearch"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<typens:key xsi:type="xsd:string"/>
<typens:phrase xsi:type="xsd:string"/>
</typens:doSpellingSuggestion>
</soap:Body>
</soap:Envelope>
|
The XML Forms Generator can also understand more complex type definitions, and can successfully generate forms from both RPC literal-style and document literal-style service definitions.
Figure 3 is the form that results from the example shown in Listing 3, rendered in the formsPlayer plug-in for Internet Explorer (see Resources):
Figure 3. A form generated for a WSDL operation
Intermediaries for service invocation
When a form is submitted directly from a browser to a Web service, the response the browser receives will itself be a SOAP envelope. It is reasonable to expect that the envelope will not be renderable as anything other than raw XML markup.
Figure 4. The raw XML of a SOAP response to a form submission
The simplest approach to creating a renderable version of the response is to interject an intermediary that actually makes the call and then converts the SOAP envelope into XHTML markup that can be rendered.
Figure 5. A servlet intermediary to the service invocation
The XML Forms Generator distribution includes a Web application containing a servlet that does just this, in order to demonstrate the pros and cons of the approach. The servlet examines the Web service response envelope, extracts the data, and wraps that data in XHTML markup that is renderable:
Figure 6. The rendered response delivered by the servlet
While the response data is now consumable by an end user (as seen in Figure 6), the presentation mechanism is hopelessly intertwined with the invocation mechanism. To enable a more flexible architecture that provides the sort of model-view-controller separation encouraged by the J2EE "model 2" architectural pattern, you need a separate template that provides a view of the response.
As mentioned previously, the XML Forms Generator allows you to use a WSDL document to create a JSP that serves as a response template. Java Standard Tag Library (JSTL) elements interrogate the XML of the response envelope. Listing 4 is a representative snippet of generated JSP markup:
Listing 4. Generated JSP markup
<?xml version="1.0" encoding="ASCII"?>
<jsp:root xmlns:jsp=http://java.sun.com/JSP/Page
xmlns:x="http://java.sun.com/jsp/jstl/xml" version="2.0">
...
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>
WSDL Response Template: doSpellingSuggestion Response
</title>
<link href="gen_default.css" rel="stylesheet"/>
</head>
<body>
<h1>doSpellingSuggestion Response</h1>
<p><b>Return</b></p>
<p><x:out select="$myDOM//return"/></p>
</body>
</html>
</jsp:root>
|
While the initial visual presentation is not markedly different from that generated by the prior servlet-only approach, the response page is ready for any modifications a developer or designer might apply. The XML Forms Generator has already done the work of constructing the fundamental form elements and matching them to the data with XPath expressions.
Figure 7. The more model-2-architecture flow enabled by the JSP response template
As an Eclipse plug-in, the XML Forms Generator provides tight integration with Eclipse and Eclipse-based products, with convenient user interface elements including context menus, wizards, and preference pages.
A variety of options provide control over the generated form's title and heading text, stylesheet, submission target, repeat depth, textarea generation, and more.
The XML Forms Generator also permits quick rendering of generated forms in a variety of renderers, using the same mechanism shown in Part 1 of this series, on the Compound XML Document Editor.
In many cases, you can generate a working form with just a few mouse clicks. In fact, the XML Forms Generator provides a single "Generate All" option for WSDL documents, which permits generation of the XML instance document, the form, and the response JSP template, all with one action.
Figure 8. Generation options for WSDL documents
The XML Forms Generator utilizes Model Driven Development concepts with EMF to permit generation of forms from WSDL descriptions of Web services. Although XForms 1.0 does not require Web service invocation support (that support is forthcoming in XForms 1.1), you still have quite a few options for using XForms against Web services, as we have demonstrated. The form generated from the example in this article can be successfully invoked against the service endpoint today.
As a standards-based, model-driven tool, the XML Forms Generator enables the immediate generation of working forms for Web services, providing a head start in forms development within any Service-Oriented Architecture (SOA).
Acknowledgements: Thanks to Kelvin Lawrence and Henry Tran of IBM.
Learn
- Review the first installment of this two part series on model-driven XML forms generation (developerWorks, August 2005).
- Learn more about Eclipse and the Eclipse Modeling Framework at eclipse.org.
- Read "Model-driven compound document development" (developerWorks, July 2005) by Kevin Kelly, Jan Kratky, and Keith Wells to find out how to build compound XML documents in Eclipse.
- Visit the W3C to learn more about the XForms 1.0, XHTML 1.0, and XML Events Recommendations, as well as the XForms 1.1 Working Draft and the Web Services Description Language (WSDL) 1.1 Note.
- Get more information on the HR-XML consortium, including the HR-XML schemas used as examples in this document.
- Some examples in this article were generated from U.S. Centers for Disease Control and Prevention schemas.
- Get to know IBM's Rational solutions at the developerWorks New to Rational page.
- Nicholas Chase has written a series of XForms-related technology tips for developerWorks, including "Use XForms to send and receive Web services messages" (June 2004).
Get products and technologies
- Visit IBM alphaWorks to find out more about the following technologies mentioned in this article:
- Check out X-Smiles, a Java language-based XML browser.
- Download the Novell XForms Explorer beta, a plug-in for Microsoft Internet Explorer 6.0 and above.
- Download formsPlayer, a set of libraries that allow you to build XForms processors, editors, and debuggers.
- Develop your own Web applications using Google Web APIs.
Jan Joseph Kratky is the lead developer for the Compound XML Document Editor and XML Forms Generator. Currently a software engineer with IBM Emerging Software Standards in Research Triangle Park, North Carolina, he holds a B.A. from Cornell University and an M.S. from Rensselaer Polytechnic Institute. A Sun Certified Java Programmer and Sun Certified Web Component Developer, Jan has worked with Java technologies since 1997, and with Eclipse technologies since 2001.
Kevin E. Kelly is a Senior Software Engineer with the IBM Corporation working on Software Standards. Kevin is a member of the W3C XForms Working Group as well as the W3C Compound Document Format Working Group. His focus is on the client technology and evolving open standards-based technologies for faster, more efficient standards adoption through XML-based and model-driven approaches. Before joining IBM, Kevin spent eight years at Rational Software working on UML modeling and Java technologies. Kevin holds a B.S. from Mercer University, and a M.S. from the University of Montana.
Steve Speicher is a Senior Software Engineer with IBM working on Software Standards. Steve's current focus is leveraging tools and model-driven development to improve the process of creating standards. Steve has previously worked on software development tools in the Rational division and IBM internal tools. Steve holds a B.S. in Computer Science and Applied Mathematics, both from Kent State University. Contact Steve at sspeiche@us.ibm.com.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
