Added Value to XForms by Web Services Supporting XML by vev19514

VIEWS: 7 PAGES: 16

									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
                          9.12.2004
                         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.)
                          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

								
To top