HHFR A new architecture for Mobile Web Services Principles

Document Sample
HHFR A new architecture for Mobile Web Services Principles Powered By Docstoc
					                 HHFR: A new architecture for Mobile Web Services
                         Principles and Implementations

                              Sangyoon Oh and Geoffrey C. Fox
                                 Community Grids Laboratory
                       501 N Morton St. 222, Bloomington, IN, 47408, USA
                                 {ohsangy, gcf}@indiana.edu

                   Abstract                          importance in the pervasive computing, it is a no-
                                                     big surprise that there are so many recent
   By combining mobile computing and Web             researches of adopting mobile computing as one
Services technologies, pervasive computing           of flexible platform of Web Service technology.
expects    more    portability    and     location      Even a half a decade ago, there is just handful
transparency for accessing information in            of people who access remote information from
anytime from anywhere. Though, a direct              their mobile device. The information access from
integration of two technologies imposes              mobile devices, however, has became easier than
performance limitations because of XML’s             ever recently with the help from advanced mobile
verbose nature and physical limitations of mobile    devices and widespread availability of packet-
computing. We present our new architecture           switched, always-on cellular phone networks.
design and implementations, Handheld Flexible        There are many projects that try to adopt smart-
Representation (HHFR) in this paper. The             phones and cellular phone with data connections
architecture provides alternative representations    as major elements in Web Services, since huge
other than XML-based SOAP and fast                   synergy effect of interoperability and removing
communication      transport     options.     The    physical-location constraints are expected.
negotiation between two end-points using SOAP           However, the verbose nature of current XML-
message sets up characteristics of following         based SOAP [1] approach imposes performance
stream of messages. The benchmark results show       limitations in integrating mobile computing
the performance advantage of using the               applications and conventional Web Services
architecture when a session composes a sequence      directly. SOAP achieves ubiquity by using highly
of messages.                                         universal XML as a form of data exchanging
                                                     between disparate and distributed computing
KEYWORDS                                             resources. Though, XML-based SOAP possesses
Mobile Computing, Web Service, Stream of             three major characteristics that may affect SOAP
Message, Binary Representation                       performance. First, the in-memory data model
                                                     must be converted to textual format to build a
1. Introduction                                      SOAP message object and to extract information
                                                     from it. Secondly, because of inevitable mobile
   Mobile computing gives a pervasive computing      computing characteristics – high latency, narrow
the way to access information any-time and any-      bandwidth, limited computation, and small
where by its portability and remote connectivity.    memory space, SOAP message processing
And Web Service technology gives a pervasive         consumes valuable resources [2]. Finally, mobile
computing the way to interoperate remote             communications suffer from a larger data size by
resources and diverse services. Because of their     XML’s descriptive tags and structure. It is usually
not a problem on the powerful wired networks,         limited computing environment characteristics.
although the bandwidth is pricey in mobile            Both need to overcome performance limitations
networks.                                             of SOAP.
   High performance SOAP encoding is an open             The report of the W3C Workshop [6] on
research area [3], [4], and [5]. Web Services in      Binary Interchange of XML Information Item
mobile environment is a benefited of the              Sets (Infoset) [7] is the result of the increasing
researches, since it also need to overcome the        demand of binary form of XML-based
performance limitations because of its                communication. The report includes conclusion
characteristics above. Even the small size, regular   of workshop meeting on September 2003 as well
frequency message exchanges could cause               as several dozens of position papers from various
performance overheads in such an environment.         institutes [5], [8], and [9]. The purpose of the
   In this paper, we present our new architecture     workshop is to study methods to compress XML
design to achieve an optimized communication          documents and transmit pre-parsed and schema
using binary message stream and a SOAP                specific object. It identified the requirement of
negotiation as well as the prototype                  binary XML Infoset, for example 1) maintaining
implementation of the architecture and the            universal interoperability, 2) a generalized
performance benchmarks.                               solution that is not limited to a specific
   We organize this paper as follows: we describe     application domain, 3) reducing process time
an overview of Handheld Flexible Representation       including a data binding time, and 4) negotiation -
architecture design in section 3. And we illustrate   fall back to XML/SOAP text format if receiver
detail implementations of the prototype in section    can’t understand binary. The discussion leads
4. Section 5 presents a performance benchmark         W3C form XML Binary Characterization
results. Conclusion is described in section 6.        Working Group for further researches. Sun's Fast
                                                      Web Services [5] and Fast Infoset project [10]
2. Background                                         specifies a representation of an instance of SOAP
                                                      Infoset using binary encoding. They use Abstract
   We see several notable projects from industry      Syntax Notation (ASN). 1. [11] to abstract
and academia that try to overcome performance         encoded messages that may be encoded using it.
limitations of current Web Services approach.         The higher level protocols (WSDL [12] for
Extreme! Lab researched the limits of SOAP            contract definition of service etc.) remain
performance for scientific computing where large      unchanged, thus you could use standard SOAP-
data sets including arrays are common and the         XML for development, and have a switch that
design of a SOAP implementation suitable for          turns on the binary protocol for production
systems with small memory and bandwidth [3],          deployment.
[4]. Throughout the experiments, the result of           W3C XML Protocol Working Group released
research shows the major improvements from            the draft of Message Transmission Optimization
using schema-specific parser mechanism for            Mechanism (MTOM) [13] and XML-binary
arrays, persistent connection, and streaming of       Optimized Packaging (XOP) [14]. Combined
messages to prevent full serializing objects to       together, the specifications are targeted to two
determine the length. It also shows that the most     data type - multimedia data that already have
serious overhead is conversion to textual form        standardized formats, such as JPEG, GIF, and
from in-memory float numbers. To resolve the          MP3 and data that includes digital signature. The
limitations, they recommend using multiple            XML encoding would damage the data integrity.
communication protocol incorporating with a           XOP is an alternate serialization that looks like a
binary representation and fast protocols other        MIME package. It avoids data binding overhead,
than SOAP. The condition they are facing with         though still preserves XML structure – tags.
the conventional Web Services is similar to the       Thus, XOP and MTOM, which describes how
constraint of mobile computing because of its         XOP is layered into SOAP HTTP transport, still
 possess a parsing issue inherited from
 SOAP/XML.                                                  In this section we present new software
    Cross Format Schema Protocol (XFSP) [9] is          architecture,     the      Handheld        Flexible
 another project that serializes XML document           Representation (HHFR) that is designed for an
 based on schema. Initially it is motivated by the      optimized and expandable communication in
 flexible definition of network protocols. It is        mobile web services. HHFR separates message
 written in Java and uses DOM4J model to parse          contents from a SOAP message in Angle-Bracket
 the schema. With XML Schema-based                      syntax format, and service end-points in HHFR
 Compression (XSBC) [15], XFSP provides binary          exchange separated-message contents in an
 serialization and parsing framework. Naval             optimized fashion.      An overview of HHFR
 Postgraduate School provides lots of research on       architecture design is depicted in Figure 1.
 Streaming X3D documents in the XFSP
 framework.                                             3.1. Design Overview
    Data Format Description Language (DFDL)                  Major aspects of the architecture design are:
 [16] is a descriptive language that is proposed to
 describe a file or a stream in a binary format for     Optimized binary representation against
 Grid computing.        Like Extensible Scientific      verbose XML syntax: HHFR provides a
 Interchange Language (XSIL) [17], it is XML-           communication options to exchange SOAP
 based and comes with an extensible Java Data           messages in a binary representation format by
 model. DFDL define the structure of data. For          separating XML syntax of SOAP messages and
 example, it defines a number format of data            SOAP message contents. Structured and typed
 whether it is a big-endian or little-endian and a      conventional     SOAP       causes  performance
 complex data format such as an array. Also             bottlenecks that are magnified in mobile
 DFDL is designed to be processable through             environments. Separated data structure and types
 DFDL parser and data model. We designed the            of SOAP body (payload) is negotiated in the
 message format description of our Flexible             beginning of a stream. XML Schema is used to
 Representation based on DFDL. In our Handheld          characterize the syntax of SOAP Body.
 Flexible Representation architecture, we define
 simple XML-schema based descriptive language           Targeting a stream of messages: HHFR works
 and develop a language parser using XML Pull           best for the Web Services where two end-points
 Parser (XPP) [18]. Our prototype implementation        exchange a stream of messages. Messages in a
 will not be in-depth like DFDL, though it will be      stream share the structure and type information of
 enough to show advantages of our approach.             SOAP Body and the most of headers of messages
                                                        are not changing in a stream session. Therefore,
 3. Architecture Overview                               the structure and type as a form of XML Schema
                                                        and headers can be transmitted only once and rest
                                                        of the messages in the stream have only payloads.
                      WS-MFR Scheme
                                                        The ‘streaming’ of message is possible by
                      Stream Info.
                                                        introducing         non-blocking          message
                      Over SOAP
                                                        Context-store as a repository: In the HHFR
 WS-MFR                                     WS-MFR
 End-Point                                  End-Point
                                                        architecture, a context-store module keeps static
                                                        data from a message stream including
                  2.Stream of Message
              in Preferred Representation
                                                        unchanging-SOAP headers, XML Schema as a
                                                        data representation, and stream characteristics
Figure. 1. Illustrated overview of HHFR architecture
                                                        that is captured in a negotiation stage. By saving
                                                        SOAP headers and data representation to the
context-store and having optimized binary format      XML/SOAP syntax and SOAP message content
messages, the architecture slims down a size of       without losing any message contents.
                                                      3.2.2. Binary Representations of SOAP
Interoperable Web Service architecture:               Message. From the separation of representation,
Distinct from other ad-hoc solutions to the SOAP      the architecture provides options to choose
performance problem, the architecture doesn’t         appropriate message representations such as
change overall interoperability of existing Web       binary and conventional SOAP representation for
Service standard. Our approach provides seamless      optimized      Web      Service    communication
integration of current Web Service applications       environment.
by using conventional SOAP messages to setup               The binary representation is a critical option
an optimized representation and transport. When       to improve overall performance of HHFR
the other end-point claims it is not compatible,      architecture in several reasons. First, it reduces
HHFR architecture fall back to the conventional       the size of exchanging message by removing
SOAP communication.                                   verbose SOAP syntax – Angle-Brackets. The
                                                      saving is maximized as a factor of 10s when a
3.2. Separation of Representation                     document structure is inevitably redundant –
     The essential idea of HHFR architecture is an    Array. A very simple message with a single text
optimized representation and communication for        element can be reduced in its size in half. Hence
two Web Service end-points while not sacrificing      it is always good to have reduced size document
SOAP compatibility. We design HHFR                    to exchange, even in a conventional computing
architecture to provide an optimized data             environment, however mobile computing really
representation       according    to      present     need it because of its narrow bandwidth
communication environment. Options include            connection.
binary and conventional SOAP representations.              Also, by using binary format message, HHFR
                                                      is able to avoid textual conversions. The
3.2.1. XML and SOAP Infoset. The first thing          architecture          removes        conventional
to describe SOAP Infoset in our architecture is       encoding/decoding stage where the in-memory
looking into what is XML Infoset, since SOAP is       format is converted into a text format and vice
XML Based language and latest specification 1.2       versa. It is an expensive process especially for
is defined using the XML Infoset.                     relatively low-powered mobile devices to convert
    XML Infoset specification is released to help     non-textual data into and from textual data, which
to define other languages that are based on the       is required in SOAP syntax. Among non-textual
XML data model, yet an instant help from the          data, floating point number conversion is the most
specification goes to the application designing       costly one [3].
and developments, which manipulate data model              Finally, another benefit to have a binary
with XML APIs. The model defined by XML               representation of SOAP message in the
Infoset is not tied up with any specific XML API,     architecture is leaving out parsing for each
such as Document Object Model (DOM), Simple           message. Since SOAP syntax requires a
API for XML (SAX), and XML Pull Parser                structured data model that satisfies Extended
(XPP). Thus, the application development sets to      Backus-Naur Form (EBNF), a parsing process is
free as far as it follows XML Infoset                 needed to get information from the given
Specification. One of the possibilities that XML      documents. The binary representation – byte
Infoset Specification opened is to have a parser      array format of SOAP message contents is chunks
that supports the binary form of XML.                 of continuous information that is defined by
    In our architecture, we defined the data model    SOAP Infoset, which doesn’t need to be parsed in
based on SOAP Infoset. Consequently, the HHFR         conventional way. Rather, architecture provides
architecture is able to separate a representation –   another kind of information retrieval scheme,
stream reader and writer. It is done by                messages in the stream.          As well as the
established internal Data Structure model and          representation, the headers of SOAP messages are
packet reader and writer that reads and writes         not changing mostly. Needless to say, there are
data to byte stream according to the Data              headers that apply to the individual message, such
Structure.                                             as reliability related headers. Such headers are
     For the replacement of XML Syntax that we         processed at the corresponding handlers. Except
separate, the architecture utilizes XML Schema         those, rests of headers that are the majority in
Definition (XSD). It is a recommendation of the        many cases can be transmitted only once and used
World Wide Web Consortium (W3C) about how              by during the stream. Both the representation and
to describe the elements in an XML Documents           headers are archived in the context-tore.
formally. Originally it is for checking the validity       Since we preserve the message contents in
of XML Documents; however it is also an                SOAP Infoset data model, HHFR is able to apply
abstract representation of an XML Document’s           various representations other than binary that
relationship – the structure and characteristics       defined in XML Schema; it is able to
including elements and data type. Nevertheless,        send/receive messages in binary format as well as
there is an issue to be considered to use the XML      traditional SOAP message in formal SOAP
Schema approach to define the syntax of SOAP           syntax.
for message stream. XML Schema doesn’t
guarantee to capture a static view of XML              3.3.2. Negotiating Characteristics of Stream.
Document, such as an order of elements or              A connection of mobile device has narrow
attributes. For that reason, HHFR expects the          bandwidth and high latency. Because of it, chunk
initial sender end-point sends the fixed order data    overlaying and pipelined-send over HTTP 1.1 is
model that is expected on an ultimate receiver         studied to improve its performance [3].
side. However, this is less concerned when the         ‘Persistent connection’ or ‘Keep-Alive’ features
service is defined in RPC style because the            that are required for it, however, is not available
operation, which is the service, has a function        for network protocol implementation on some
signature of the ordered parameters. Except the        mobile devices and some cellular network.
ordering issue, XML Schema nicely replaces the             Because of above reasons, the HHFR
XML syntax in data interchanges.                       architecture provides fast communication options
                                                       as well as default HTTP transport, such as TCP
3.3. Negotiation of Characteristics                    and UDP where message contents in a binary
     A few design issues motivates an introduction     representation is transmitted over in a stream
of a negotiation stage: 1) to have alternative         fashion. Options provide asynchronous (also
representation of SOAP messages, the                   called non-blocking instead of HTTP callback
representation of message and leaving out-SOAP         mechanism) messaging scheme, so that the
Headers should be transmitted at the beginning of      architecture can stream messages. The fast
the stream 2) to setup the fast and reliable way of    communication option looks similar to previous
communication, the architecture should negotiate       ad-hoc solutions to the Web Service Performance
characteristics of stream.                             issue. Though, our architecture puts the fast
                                                       transport implementation behind the SOAP
3.3.1. Supporting Alternative Representation           communication transparently so that services in
of SOAP Message. A stream of messages shares           HHFR       use    conventional      Web     Service
the same representation, which means that              specifications seamlessly and loosely-coupled
messages share the structure and types of SOAP         way without additional ad-hoc scheme.
Body parts. Schemas which represents the                   The reliability is negotiated in the negotiation
separated structure and types of both request and      stage as well. For example, UDP transport is a
response message should be conveyed initially to       simple high-performance datagram Internet
tell the representation of following binary format     Protocol, although UDP doesn’t provide
                      Endpoint A                             Endpoint B
                                                                                          receives a negotiation SOAP message and it
                                          StartSes sio
                                                      n                                   prepares a response SOAP message for negotiated
                                 ID = some UR

                              ID = some URI
                                              I, Seq = 0                                  items. A successful end of negotiation stage is
                                            , Seq = 1
                                                                                          lead to the message streaming stage, where
                                  ID = some URI
                                                , Seq = 2
                                                                                          streams reader and writer are set up for incoming
                                            me URI, Seq
                                                        = 0,2                             and outgoing messages.
                              ACK , ID = so
                                                                                              The negotiation stage is the only notable
                                  ID = some URI
                                                , Seq = 1                                 overhead we have in our architecture and it
                                                      = 0..2
                                                                                          prevents us to use the architecture scheme in
                                           e URI, Seq
                             ACK , ID = som
                                                                                          short-lived sessions, which have few messages
                                           End Session                                    exchanged.

                                                                                          3.4. Message Handling
                   Figure. 2. Possible message exchange                                        The SOAP message has an outer-most
                      between two WS-RM end-points
                                                                                          element, SOAP envelope in its XML document,
                                                                                          which is composed optional headers and a body –
    reliability and ordering guarantee that TCP does.                                     payload which contains a program instruction or
    Datagram may be missing or arrived in out-of-                                         data. The headers contain additional information
    order. Thus, the architecture design implements                                       for SOAP message, such as parsing instructions,
    Web Service Reliable Messaging [20] (WS-RM)                                           security information, and routing/reliability
    specification on UDP transport. Figure 2 depicts a                                    information. The architecture handles static
    possible message exchanges between WS-RM                                              information of messages in the stream (un-
    end-points over UDP or TCP transport.                                                 changed headers) and dynamic information
         The     detail   implementation     of   fast                                    (payload and headers for individual messages)
    communication transport and reliability are                                           differently.
    presented in section 4.
                                                                                          3.4.1. Handler for SOAP Header Processing.
    3.3.3. Negotiation Stage. The issues discussed                                        As discussed, the static/unchanged headers of
    above are negotiated in an initial Negotiation                                        SOAP message in the session (the stream) are
    Stage where a typical HHFR session starts with.                                       archived in negotiation stages. Those headers
    The negotiation uses a conventional SOAP                                              applied to individual message are processed by
    message, which makes the negotiation stage                                            appropriate handlers, which are transmitted as a
    compatible with existing Web Service                                                  part of optimized representation of SOAP
    framework. The architecture design defines each                                       message. The intension of using this possible
    item from the issues as an incremental element in                                     additional information in the stream is negotiated
    a Negotiation Schema. Thus, negotiation handler                                       as a part of the schema that represents a data
                                                                                          structure of exchanging message format in the
                   Optimized Communication
                                                                                          stream. When message in given representation
                                                                                          enters or leaves HHFR architecture, the handlers
      for                                                         Context-Store           process headers. The popular example can be a
                                                          WS-MFR Scheme (URI-S)
                                                                                          WS-RM header of SOAP message that marks
                        Context Mapping                                                   sequence numbers or ACKs.
                                                          Schema Representation (URI-R)
                                                          Stream Info. (URI-T)
                                                          SOAP Headers
                                                                                          3.4.2. Conversion process. Comparing to the
                                                                                          individual message conversion approach where
                     Preferred View of Data
                     on Mobile Application                                                the each converted into another self-contained
           Figure. 3. Relationship of different forms                                     binary format message, the message stream
        of SOAP messages and their defining context                                       approach requires an internal Data Structure
                                                          AXIS WS-Container                         Mobile Device (J2ME)
Object that holds the representation of messages                                       SOAP
                                                                      HHFR                          HHFR
in the session. The architecture builds a data          DSParser
                                                                      Service                       Thread

structure object by processing a captured XML
Schema from the negotiation message. Figure 3          Negotiation
                                                                     Streamer                       Streamer
                                                        Handler                                                  Handler
shows abstract process of message conversion
                                                                                  TCP/UDP Stream
     In a session that uses a binary representation
as an optimized communication data format,
                                                                                   Request Schema
stream reader and writer in the architecture                                      Response Schema
read/write in-memory format data. A reader does                                    Context-Store
a sequence of typed reading of each SOAP                                      (Ad-hoc implementation)

Infoset instances from the network stream
                                                             Figure. 4. Simple Overview of Prototype
according to the internal data structure, while a                         Implementation
writer does a sequence of typed writing.
     Originally,    Data     Format     Description   4. Implementation
Language (DFDL) was included in the
architecture design to define a binary format and         To demonstrate the effectiveness of the
its library is planned to be utilized to read/write   HHFR architecture, we have implemented a
binary format data. However, the schedule of its      prototype Mobile Web Service framework based
library implementation is not matched ours.           on the HHFR architecture. By implementing the
Instead of it, we define a simple schema              prototype, the HHFR design becomes concrete. It
specification for a prototype implementation,         provides separation of message contents and
which is modified a little from W3C’s                 representation, fast communication transport
recommendation.       One     of    examples     of   options, and negotiation scheme. In this section,
modification we’ve made is adding an array            we detail the implementation of prototype.
element data type, such as <element name=
"MyArray"                        type="array"         4.1. Overview
primitives="float" value="90">.                            The HHFR architecture design prototype,
                                                      Handheld Flexible Representation (HHFR) is
3.5. Context Store                                    written in pure Java-based system. It implements
     One of essential components of the               major design points of the architecture to provide
architecture that enables a stream of message         optimized communication for mobile web
approach is a context-store. In previous sections,    services without compensating interoperability.
we define static/unchanged information in             The prototype architecture overview is depicted
conventional SOAP messages – such as                  in Figure 4. Since the architecture design doesn’t
information in headers. The context-store makes       include WS container functions, it needs to use an
it possible to look-up the context information        existing WS Container, such as AXIS of Apache
from a negotiation SOAP message – unchanged           Software Foundation (ASF).
SOAP headers, separated representation, and
characteristics of the stream. The HHFR scheme        4.2. Requirements of mobile Programming
itself is also kept in the context-store as well.     Environment
     In the HHFR architecture design, we define           We present programming requirements,
information in context-store with Universal           especially on mobile side, here.
Resource Identifier (URI). We notate the HHFR
scheme itself as ‘URI-S’. The current                 4.2.1. Limited Programming Library. Because
representation of the stream is ‘URI-R’ and the       of limitations that mobile devices impose, its
choice of transport protocol is ‘URI-T’.              programming environment is not as much
                                                      prosperous as typical wired computing
environments. J2ME has limited package                  HttpTransport.call(). And a receiver side-
supports than J2SE because of code size issues          negotiation is implemented as a receptor of the
and limited instructions supported by a processor.      SOAP request message and loads a SOAP
Also, we have limited choice of XML and SOAP            response back to the initiator with negotiated
library. kSOAP and kXML [21] support rich               stream characteristics information. The initiator –
APIs with tiny memory footprints; however they          SOAP Request sender gets Boolean value as a
provide far less functionalities than conventional      return of negotiation(). The true value leads the
Web Service container, such as AXIS 1.x and 2,          streaming fashion communication. Initiator keeps
and .NET.                                               using the conventional SOAP communication
                                                        method, if the return value is false.
4.2.2. Wireless Network Connection. The
connections of mobile devices have a narrow             4.3.2. Fast       Communication        Transport
bandwidth and high latency, comparing to the            Option. As discussed earlier, a fast
conventional wired connection. European and             communication transport option in the
Asian countries had launched the third generation       architecture design provides an alternative
cellular service (3G), such as UMTS [22] and W-         communication method in an asynchronous
CDMA [23], which is expected to have a                  optimized fashion, other than the default HTTP.
connection      speed    of    300~500kbps for          The TCP and UDP transports are provided as a
downloading and 56~90kbps uploading speed.              transport client and a transport server on sender
The improvement of the connection speed is big,         and receiver side, respectively. TCP transport
if we compare it to 2.5G – GPRS [24] or 2.75G –         classes provide a message streaming through a
EDGE [25] services of up to 56kbps connection.          connection-oriented socket connection. For the
Yet, the 3G installation in USA is the initial          service provider, StreamConnectionFactory class
stage. It is serviced only in major Metropolitan        waits for the incoming socket connection on a
areas and we need to wait few more years to use         server socket and creates a StreamConnector that
the same service that Europe and Asia use.              holds all streaming related classes, such as data
                                                        stream reader and writer, and streamer. UDP
4.3. Implementation Details                             transport implementation has a similar class
     The prototype implementation of mobile             structure,    except    it   doesn’t     have   a
devices depends on kSOAP/kXML for                       ConnectionFactory design pattern because
SOAP/XML parsing and SOAP request/response              of its connectionless character. It just opens up
call. And a mobile-side implementation is a             the UDP port and receives datagram packets.
service user only, while a service provider is
implemented on conventional desktop machine             4.3.3. Queue on Sending/Receiving Thread.
using AXIS container.                                   Other details on communication implementations
                                                        are to place send method and receive method in
4.3.1 Negotiation Scheme. As designed, the              different threads and introduction of queue on
role of negotiation stage is essential to conclude      sender. The idea is used by communication
the characteristics of following stream. The            implementations in many projects nowadays,
negotiation stage is an implemented method,             because of its benefits with little complexity. To
negotiation()      in     HHFR       service    class   put send() and write() methods to a socket steam
HHFRHandler. Since the negotiation stage is             in a single thread makes one operation block the
implemented over SOAP protocol, the negotiation         other and causes performance degradation. Even
is acting different as a caller and a callee on each    though Java 2 Standard Edition provides Non-
side. That is, the negotiation() method on a            Blocking I/O interfaces as a standard from
initiating side – a caller is a simple SOAP request     version 1.4, mobile computing doesn’t get
message creation with desired characteristics of a      benefits: the functionality is not provided for
following stream and it waits a return of kSOAP’s       J2ME yet. Again, the high-latency of current
cellular connections makes it essential to separate
sender thread with writer thread to be able to        1. A service user (client) prepares a message
operate them concurrently.                               with a given array size.
     Queue in the write thread adds more              2. Send it to a service provider (in AXIS)
asynchronicity      to    the     communication       3. Web Service (the service provider) processes
implementation. It decouples the message packet          the message and returns a result message to
process performance from the performance of              the service user.
write communication thread. Write thread              4. Repeat step 1 – 3 for the number of messages
receives message packets and puts them to the
queue. It de-queues a next message packet and         5.1. Benchmark Configuration
tries to write to the socket whenever it is              We configure a benchmark environment as
available. The idea works well specially for          follows: for service providers, AXIS Web Service
narrow bandwidth mobile connection where one          container runs on Sony VAIO notebook with
big message packet can clog the whole                 mobile Intel Pentium 4M CPU 2GHz and 768MB
transmission.                                         DDR RAM, where Windows XP professional
                                                      with Service Pack 2 operates. And mobile
4.3.4. Streamer and Data Structure. The unit          applications (service users) run on Treo 600 with
of message in the prototype implementation is a       ARM processor and 32MB RAM, where Palm OS
various length byte array, which we call a            5.3 operates on as well as MIDP 2.0 and CDLC
‘message packet’ as well. The separation of           1.1.
representation and message contents make the             The time stamps are measured on mobile side
architecture have a scheme to extract/build           (a          session          initiator)     using
information in a non-self contained way.              System.currentTimeMillis() of MIDP
    The streamer is an information extractor and      2.0 - CLDC 1.1 that returns 10 milliseconds
builder with a sequence of switch statement for       precision time stamps.
reading and writing byte format information              Both applications use TCP transport as a
which contains SOAP message contents –                choice of fast transport for the benchmark.
message packet in the order of internal
DataStructure object, which is produced by a          5.2. String Array Concatenation
negotiationHandler. It parses through the                The first benchmark application is a string
received data representation (a schema of the         array concatenation service that produces a
other end point) with DSParser and returns the        single concatenated string of all string in a
DataStructure.                                        message. We measure a Round Trip Time (RTT)
                                                      of a session: if there is a five message in the
5. Evaluation of Prototype Implementation             session, we measure entire five concatenation
                                                      processing time as a RTT. It includes a
   This     section     summaries     performance     communication set-up latency, transmission
benchmark       results     of    the    prototype    overheads, and concatenation operation time.
implementation of HHFR architecture design. We        Additionally, the benchmark of the HHFR
develop two applications for the benchmark: a         prototype implementation contains negotiation
string concatenation service for benchmarking the     overheads.
pure text data and a float number addition service       The benchmark focuses on the performance
for text conversion required data domain. For         effect on runtime system by changing a number of
comparisons, we develop conventional SOAP             messages in a session and a size of array in a
applications using AXIS and kSOAP toolkit for         message, and comparing them with SOAP’s.
each test.
   A simple test session is summarized as
                                                                                                                                                                                    x 10
                                         12000                                                                                                                                5.5

                                         11000                                                                                                                                 5

                                                                                                                                                                                                                                      HHFR: 2 messages
                                                                                                                                                                               4                                                      SOAP: 2 messages
                                          9000                                                                                                                                                                                        HHFR: 4 messages

                                                                                                                                                    Round trip time (msec)
Round trip time (msec)

                                                                                                         HHFR: Single message                                                                                                         SOAP: 4 messages
                                                                                                         SOAP: Single message                                                 3.5                                                     HHFR: 8 messages
                                          8000                                                                                                                                                                                        SOAP: 8 messages





                                          4000                                                                                                                                 1

                                          3000                                                                                                                                0.5
                                                 0            10           20        30          40          50          60     70                                                  0            10           20         30            40           50             60        70

                                                                     Size of string array per message (message size)                                                                                   Size of string array per message (message size)

                                         Figure. 5. String concatenation round trip time                                                                                     Figure. 6. String concatenation round trip time
                                         measurements of a single message in a session with                                                                                  measurements with various array sizes (message
                                         various array sizes (message size). With a single                                                                                   size). This shows different number of message in a
                                         message, a conventional SOAP out-performs HHFR –                                                                                    session graphs in one. With multiple messages in a
                                         prototype implementation.                                                                                                           session, HHFR needs less time to perform in every

                                                x 10
                                          3.5                                                                                                                                9000

                                                           HHFR: 2 array size                                                                                                                                                               HHFR: Single message
                                                           SOAP: 2 array size                                                                                                                                                               SOAP: Single message
                                           3               HHFR: 4 array size
                                                           SOAP: 4 array size                                                                                                8000
                                                           HHFR: 8 array size
                                                           SOAP: 8 array size
                Round trip time (msec)

                                                                                                                                     Round trip time (msec.)






                                           0                                                                                                                                 3000
                                                1             2            3          4           5           6           7      8                                                  0       10        20           30   40       50         60       70       80        90        100

                                                                           Number of messages per session                                                                                                  Size of float array per message (message size)

                                         Figure. 7. String concatenation round trip time                                                                                     Figure. 8. Float number addition round trip time
                                         measurements with various numbers of messages.                                                                                      measurements of a single message with various array
                                         This shows different message size graphs in one.                                                                                    sizes (message size). A break-even-point is located
                                         HHFR out-performs, except a session that consists of                                                                                between 50~60.
                                         a single message.
                                                                                     x 10

5.3. Floating Number Array Addition                                                           HHFR: 5 array size

   The second application we benchmark is a                                    3.5            HHFR: 10 array size
                                                                                              HHFR: 15 array size
                                                                                              Conv. SOAP: 5 array size
float number addition service that returns a                                    3
                                                                                              Conv. SOAP: 10 array size
                                                                                              Conv. SOAP: 15 array size
summation of all float numbers of an array in a

                                                     Round trip time (msec)
message. The benchmark scenario is similar to                                  2.5

the string concatenation service. Though, RTT of
the SOAP application contains an OS level float-
to-text conversion overhead, while HHFR                                        1.5

doesn’t. Like string concatenation service
benchmark, we change a size of array and a                                      1

number of messages in a session to observe a                                   0.5
performance state change in the system, while
comparing it with SOAP’s.                                                       0
                                                                                     0       10       20       30         40   50    60      70      80   90    100

   Figure 8 shows a linear increase of RTT on                                                                   Number of messages per session

both, HHFR and SOAP. Assume the formulas for
HHFR and SOAP curve as y = p1*x¹ + p2                                         Figure. 9. Float number addition round trip time
and y = p3*x¹ + p4 respectively. We see                                       measurements with number of messages. This shows
p1 < p3 and p2 > p4 as well as a break-                                       different message size graphs in one.
even point is located between 50 and 60 of array
size (x) with given input parameters.                needs the                                         additional              memory             space   for
5.4. Observations
   From the figures, we observe a bigger             6. Conclusion
performance advantages from a sequence of
messages in a single session. Figure 7 of the           In this paper, we present new mobile web
string concatenation benchmark and figure 9 of       service architecture, HHFR as well as detailing
the float addition benchmark show that HHFR          the prototype implementation. Also, we evaluate
streaming communication always out-performs a        the performance of the prototype while
conventional SOAP and the gap is fast-increasing     comparing conventional SOAP applications by
as the number of messages in a session grows.        measuring round trip times of given service
These performance gaps are mainly caused by a        sessions: the string concatenation service and the
high network latency of cellular networks.           float number addition service. The evaluation
Different from a default HTTP, TCP enable the        result shows that our run time system out-
system avoid network setup overheads during the      performs a conventional SOAP system when the
session. As discussed in section 3, HTTP 1.1         number of message in a session is multiple or the
persistence connection or HTTP 1.0 keep-alive        given message size is large. Our architecture
option is out-of-considering of our benchmark,       helps session oriented web service applications
since its uncertain availability in a cellular       that communicate in a stream of messages, such
network: proxy support for such a function is        as multimedia or collaboration application.
optional to the cellular service provider.
   The second observation we did is an efficient     7. References
memory space usage of the prototype
implementation by avoiding a text conversion for     [1] World Wide Web Consortium, “Simple Object
building text-based SOAP messages in the float           Access Protocol (SOAP) 1.1”, 2003,
number adding service. During the benchmark,             http://www.w3.org/TR/soap/
the runtime system of the prototype processes
                                                     [2] J. Kobielus, “Wrestling XML Down To Size:
larger size array in a message. As equipped with a       Reducing The Burden On Networks And Servers”,
smaller memory space, OS on a mobile device
    Business Communications Review, Dec. 2003,                 (MTOM)”, Nov. 2004,
    pp. 35-38.                                                 http://www.w3.org/TR/2005/REC-soap12-mtom-
[3] K. Chiu, M. Govindaraju, and R. Bramley,
    “Investigating the Limits of SOAP Performance          [14] World Wide Web Consortium, “XML-binary
    for Scientific Computing”, Proc. of 11th IEEE Int.          Optimized Packaging (XOP)”, Aug. 2004,
    Symposium on High Performance Distributed                   http://www.w3.org/TR/2005/REC-xop10-
    Computing HPDC-11 2002, July 2002, pp. 256.                 20050125/

[4] M. Govindaraju, A. Slominski, V. Choppella, R.         [15] E. Serin and D. Brutzman, “XML Schema-Based
    Bramley, D. Gannon, “Requirements for and                   Compression (XSBC)”,
    Evaluation of RMI Protocols for Scientific                  http://www.movesinstitute.org/xmsf/projects/XSB
    Computing”, Proc. of SC2000, Nov. 2000.                     C/03Mar_Serin.pdf

[5] P. Sandoz, S. Pericas-Geertsen, K. Kawaguchi, M.       [16] M. Beckerle, and M. Westhead, “GGF DFDL
    Hadley, and E Pelegri-Llopart, “Fast Web                    Primer”,
    Services”, Aug. 2003,                                       http://www.gridforum.org/Meetings/GGF11/Docu
    http://java.sun.com/developer/technicalArticles/W           ments/DFDL_Primer_v2.pdf
                                                           [17] R. Williams, “XSIL: Java/XML for Scientific
[6] World Wide Web Consortium, “Report from the                 Data”, Jun. 2000,
    W3C Workshop on Binary Interchange of XML                   http://www.cacr.caltech.edu/projects/xsil/xsil_spec
    Information Item Sets”, Sep. 2003,                          .pdf
    workshop/                                              [18] A. Slominski, “XML Pull Parser (XPP)”,
                                                                Extreame! Computing Lab,
[7] World Wide Web Consortium, “XML Information                 http://www.extreme.indiana.edu/xgws/xsoap/xpp/
    Set”, http://www.w3.org/TR/xml-infoset/
                                                           [19] World Wide Web Consortium, “XML Schema
[8] J. H. Gailey, “Sending Files, Attachments, and              Definition (XSD)”, Oct. 2004,
    SOAP Messages Via Direct Internet Message                   http://www.w3.org/XML/Schema
    Encapsulation”, Dec. 2002,
    http://msdn.microsoft.com/msdnmag/issues/02/12/        [20] IBM, BEA, Microsoft, and TIBCO Software,
    DIME/default.aspx                                           “Web Services Reliable Messaging Protocol”,
                                                                Mar.             2004,             http://www-
[9] D. Brutzman, and A. D. Hudson, “Cross-Format                128.ibm.com/developerworks/webservices/library/
    Schema Protocol (XFSP)”, Sep. 2003                          ws-rmdev/

[10] P. Sandoz, S. Pericas-Geertsen, K. Kawaguchi, M.      [21] kSOAP and kXML, http://www.ksoap.org/
     Hadley, and E Pelegri-Llopart, “Fast Infoset”, Jun.
     2004.                                                 [22] Universal Mobile Telecommunications System
                                                                (UMTS), http://www.iec.org/online/tutorials/umts/
[11] International Telecommunication Union, “Abstract
     Syntax       Notation   One      (ASN       1)”,      [23] Wideband Code Division Multiple Access (W–
     http://asn1.elibel.tm                                      CDMA)

[12] World Wide Web Consortium, Web Services               [24] General Packet Radio Service (GPRS)
     Description Language (WSDL) 1.1, Mar. 2001,
     http://www.w3.org/TR/wsdl                             [25] Enhanced Data Rates for GSM Evolution (EDGE),
[13] World Wide Web Consortium, “SOAP Message                   df/edge_wp_technical.pdf
     Transmission Optimization Mechanism