Added Value to XForms by Web Services Supporting XML Protocols Elina Vartiainen Timo-Pekka Viljamaa T Research Seminar on Digital Media Autumn 2004: Web Service Technologies

Agenda Introduction Background XML, XForms, Web services, JMS Objective and motivation Use cases Results Implementation and demo Comparison to HTTP and possible other implementations Conclusions

Introduction XForms is developed by W3C to overcome the limitations of HTML forms and is based on XML Web services are a technology that provides interoperability between different platforms XForms can be configured to submit any XML data XForms can be connected to Web services by defining the submission data to be a SOAP message

Introduction (cont.) Today, the main transfer protocol of XForms and Web services is HTTP. Both are designed to allow other future transmission methods, for example, non-HTTP transfer protocols The goal of the paper is to examine, if Web services could bring added value to the XForms

Background XML: Flexible markup language derived to describe the structure of documents No predefined tag set All semantics are defined either by the processing applications or style sheets

Background (cont.) XForms: XML application that represents the next generation of forms for the World Wide Web Separates the purpose from the presentation Enables the developer to design different user interfaces, without having to change the actual data May be integrated into any suitable markup language

Background (cont.) Web services: Software systems designed to support interoperable machine- to-machine interaction over a network XML, WSDL, SOAP and UDDI as key standards for Web services Web services describe themselves with WSDL SOAP defines a common format for XML messages UDDI is the group of registries that expose information about a business and its technical interfaces

Background (cont.) Java Messaging Service (JMS): Allows applications to create, send, receive, and read messages Loosely coupled messaging Also provides asynchrony and reliability

Objective and motivation Limitations of HTTP: No support for asynchrony No selectable routing No sufficient reliability or security Statelessness Objective: If the limitations of HTTP are solvable If potential new features and functionalities exist Motivation: Explore relatively familiar technology: XForms Connect it to Web services and XML protocols

Use cases Finding and using a Web service Giving an order Multi-phased ordering Payment of an order Administration of distributed systems Cache Chat application

Results Implementation of use case, in which a customer locates the web service (calculator) from an UDDI repository Java and Apache SOAP running on Apache Jakarta Tomcat application server UDDI repository used was provided by IBM

Results (cont.)

Comparison to HTTP Preceding kind of functionality is not standardized could be implemented with a database and a dynamic web page Inefficiency of SOAP multiple system calls to send one logical message XML parsing and formatting time Delay in the request caused by the interaction between the Nagle algorithm and TCP delayed ACK algorithm

Results (cont.) Implementation of use case for asynchronous messaging was specified using XForms, Java Messaging System (JMS), and Apache Axis

Results (cont.) Comparison to HTTP and other possible implementations Asynchronous messaging using only HTTP creates a lot of overhead (288kB/24h with 1kb/10min) in the network Messaging is client initiatiated Specification is done using current technologies Not the most optimal one in the future SOAP 1.2 specification allows to replace HTTP with any protocol, also with asynchronous messaging protocols, as long as the protocol binding conforms to SOAP’s binding framework

Conclusions XForms and Web services can overcome the limitations of HTTP Exists many use cases for the integration of XForms and Web services that bring added value to the user Integration is implementable and useful in practice Proved by our implementation