Added Value to XForms by Web Services Supporting XML

Download Report

Transcript Added Value to XForms by Web Services Supporting XML

Added Value to XForms by Web Services
Supporting XML Protocols
Elina Vartiainen
Timo-Pekka Viljamaa
T-111.590 Research Seminar on Digital Media
Autumn 2004: Web Service Technologies
• Introduction
• Background
• XML, XForms, Web services, JMS
• Objective and motivation
• Use cases
• Results
• Implementation and demo
• Comparison to HTTP and possible other implementations
• Conclusions
• 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
• Flexible markup language derived to describe the structure of
• No predefined tag set
• All semantics are defined either by the processing applications
or style sheets
Background (cont.)
• 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 machineto-machine interaction over a network
• XML, WSDL, SOAP and UDDI as key standards for Web
• 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
• 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
• 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.)
Results (cont.)
Comparison to HTTP
• Preceding kind of functionality is
not standardized
• could be implemented with a
database and a dynamic web
• Inefficiency of SOAP
• multiple system calls to send
one logical message
• XML parsing and formatting
• Delay in the request caused by the
interaction between the Nagle
algorithm and TCP delayed ACK
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
• XForms and Web services can overcome the limitations of
• 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