(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2006/0075070 A1
`(43) Pub. Date:
`Apr. 6, 2006
`Merissert-Coffinieres et al.
`
`US 2006.0075070A1
`
`(54)
`
`(76)
`
`(21)
`(22)
`
`(63)
`
`DEVELOPMENT AND DEPLOYMENT OF
`MOBILE AND DESKTOP APPLICATIONS
`WITHNA FLEXBLE MARKUP-BASED
`DISTRIBUTED ARCHITECTURE
`
`Publication Classification
`
`(51) Int. Cl.
`G06F 5/16
`
`(2006.01)
`
`Inventors: Patrick Merissert-Coffinieres, Issy Les
`Moulineaux (FR); Alain Dinkespiler,
`Paris (FR); Alejandro Daniel
`Rosenblatt, Toulouse (FR):
`Alexandra-Madalina Stroe, Cupertino,
`CA (US)
`Correspondence Address:
`MORRISON & FOERSTER LLP
`7SS PAGE MILL RD
`PALO ALTO, CA 94304-1018 (US)
`Appl. No.:
`11/295,028
`
`Filed:
`
`Dec. 5, 2005
`
`Related U.S. Application Data
`Continuation of application No. 10/116,310, filed on
`Apr. 2, 2002.
`
`(52) U.S. Cl. .............................................................. 709/218
`
`(57)
`
`ABSTRACT
`
`A computer program product embodied in a computer
`readable medium is configurable to accomplish execution of
`an application that is specified and encoded in a markup
`based descriptor language. The product includes client runt
`ime computer code configured to cause a client computer
`device to process the markup-based descriptor language to
`deploy an application to accomplish execution of the appli
`cation. The client runtime computer code is further config
`ured to process the markup-based descriptor language to
`selectively configure the client computer device to deploy
`the application so as to accomplish execution of the appli
`cation by the client computer device stand-alone or by the
`client computer device in cooperation with a server to which
`the device is connectable via a network connection.
`
`12
`Centruntime
`
`
`
`
`
`
`
`
`
`118
`Data
`
`108
`Application Server
`
`
`
`06
`Server Runtine
`
`
`
`
`
`16
`XML Form
`Specification
`
`Instacart, Ex. 1057
`
`1
`
`

`

`Patent Application Publication
`
`Apr. 6, 2006 Sheet 1 of 10
`
`US 2006/0075070 A1
`
`
`
`2
`
`

`

`Patent Application Publication Apr. 6, 2006 Sheet 2 of 10
`
`US 2006/0075070 A1
`
`
`
`
`
`
`
`
`
`
`
`3
`
`

`

`Patent Application Publication Apr. 6, 2006 Sheet 3 of 10
`
`US 2006/0075070 A1
`
`4
`
`

`

`
`
`yAYN
`
`5
`
`
`
`

`

`
`
`6
`
`

`

` I93yNdl4
`
`7
`
`

`

`Patent Application Publication Apr. 6, 2006 Sheet 7 of 10
`
`US 2006/0075070 Al
`
`Ld
`
`
`
`
`
`
`
`mea
`
`tors
`
`8
`
`

`

`:=gotfeSET=}F
`
`socmolgWH
`
`:&
`
`ay
`
`C3
`
`ei—H\poe"G
`
`ses
`
`oSa.“1Riee=bl
`.4™—Leemm|ii
`
`oze
`
`N
`
`aS&=7
` doReeRlda
`
`apsgWeng&
`
`9
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`
`
`10
`
`

`

`Patent Application Publication
`
`Apr. 6, 2006 Sheet 10 of 10
`
`US 2006/0075070 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`TE?ONY/O
`
`11
`
`

`

`US 2006/0075070 A1
`
`Apr. 6, 2006
`
`DEVELOPMENT AND DEPLOYMENT OF MOBILE
`AND DESKTOP APPLICATIONS WITHNA
`FLEXBLE MARKUP-BASED DISTRIBUTED
`ARCHITECTURE
`
`TECHNICAL FIELD OF THE INVENTION
`0001. The present invention is in the field of developing
`and deploying applications and services for a full range of
`devices, Scaling from mobile phones to computer desktops,
`within a flexible markup based distributed architecture.
`
`BACKGROUND OF THE INVENTION
`0002. As wireless computing devices become more ubiq
`uitous, the demand for value-added mobile applications and
`Solutions to deliver these applications increases. Enterprises
`expect new mobile applications to seamlessly integrate with
`the existing corporate information system, thus granting
`access to existing resources and services to highly mobile
`workers. Examples include accessing legacy applications
`and connecting to enterprise databases through wireless
`devices.
`0003 Mobile applications may have challenges such as:
`0004. Accessing a mobile application from different
`kinds of devices, for example from a PDA or a desktop
`computer, depending on the location of the user. PDAS
`and desktops differ in several ways, including form
`factors, operating systems and connectivity.
`0005 Running a mobile application on a mobile
`device continuing to work offline, in the case of a
`broken connection. An offline behavior utilizes access
`to local resources.
`0006. A mobile application accessing services pub
`lished by some Web Services provider implementing
`Web Services standards, including SOAP, WSDL and
`UDDI.
`0007 Deploying mobile applications in such heteroge
`neous environments greatly increases the complexity of the
`Solutions, and presents many unresolved challenges. These
`challenges in turn affect the development of applications, as
`well as ongoing maintenance. Some issues to address are:
`0008 Open standards compatibility. Proprietary solu
`tions are unlikely to be practical in Such heterogeneous
`environments. The Solution should fit the emerging
`Web Services standards, including SOAP, WSDL and
`UDDI.
`0009 Multi-platform deployment. The same service
`may be accessed from different kinds of devices and
`different communication protocols may be used.
`0010 Ease of modification. Since the markets change
`quickly, especially emerging markets like the wireless
`applications market, it is desirable that Smart applica
`tions are easy and quick to modify.
`0011 Adaptable deployment. No single deployment
`model fits all contexts. The suitable deployment model
`depends on several factors, such as device resources,
`security requirements and application characteristics.
`Deployment models typically range from a thin client
`connected to a server, to a stand-alone running appli
`cation.
`
`0012. Access to local resources. Mobile devices cannot
`rely exclusively upon server side resources, since the
`connection with a server cannot always be guaranteed.
`Furthermore, it can be costly to continually maintain a
`connection to a server when it is only occasionally
`required.
`0013 Enhanced user interface. Required to improve
`the user experience.
`0014 Solutions like HyperText Markup Language
`(HTML) combined with HyperText Transfer Protocol
`(HTTP), Wireless Application Protocol (WAP), pure Java
`programming, Application Servers, and proprietary Soft
`ware Development Kits (SDKs), each address a subset of
`these challenges, but more comprehensive solutions are
`desired.
`0.015 HTML and WAP are open standards and may be
`deployed on multiple platforms. Services developed with
`these standards may be easily modified, since they become
`immediately available to the client devices when deployed
`on the server. Unfortunately, the deployment model of
`HTML and WAP is a rather rigid thin client model and a
`connection to a server must remain typically available
`during the execution of the application. This may be costly
`and even impractical, should the connection to the server be
`interrupted unexpectedly. Another drawback is that these
`Solutions allow little access, if any, to local resources.
`Finally, the user interface is rather modest, at best.
`0016. Another solution mentioned above is pure Java
`programming. Although Java is quite portable, and is con
`sidered to Some extent as an “open standard, there are in
`fact multiple Java standards, including J2ME MIDP, Per
`Sonal Java, and Java 2 Standard Edition. Thus, deploying a
`Java application on different platforms may require rewrit
`ing it several times, which implies involving highly-skilled
`developers. The same problem arises when modifying an
`application. Java provides good means of implementing a
`deployment model targeted to a specific architecture, access
`ing local resources and providing effective User Interfaces.
`Unfortunately, each deployment model generally requires a
`specific Java program, thus making it unfeasible to dynami
`cally adapt a given application to new architectural require
`mentS.
`0017 Proprietary SDKs provided by mobile device
`manufacturers are quite comparable in capabilities and
`drawbacks to the Java programming approach, but have the
`additional drawback of not being open standards. The use of
`Such proprietary solutions entails a commitment to one
`particular (inflexible) solution, which in turn restricts the
`ability to later port an application to other mobile devices.
`Should the chosen Solution at Some point no longer meet the
`requirements of the user, it could be extremely costly to
`implement a completely new solution.
`0018 Application servers, and especially Java applica
`tion servers based on the Java 2 Enterprise Edition (J2EE)
`standard, promote several architecturally significant separa
`tions of concerns. One architectural feature is a variation on
`the HTML approach, namely Java Server Pages (JSP). JSPs
`are targeted to improve the separation between interaction
`logic and business logic on the server side, but have the same
`limitations as traditional HTML architectures on the client
`side. Another architectural feature is the distinction between
`
`12
`
`

`

`US 2006/0075070 A1
`
`Apr. 6, 2006
`
`the development phase and the deployment phase for an
`application, thus allowing some flexibility for adapting to
`the underlying technical architecture. However, the deploy
`ment process is typically only concerned about server-side
`deployment characteristics, including transactions, security
`and database access. The distribution of processing and
`resources between the client and the server are not addressed
`by this solution.
`
`SUMMARY OF THE INVENTION
`0019. A computer program product embodied in a com
`puter-readable medium is configurable to accomplish execu
`tion of an application that is specified and encoded in a
`markup-based descriptor language. The product includes
`client runtime computer code configured to cause a client
`computer device to process the markup-based descriptor
`language to deploy an application to accomplish execution
`of the application. The client runtime computer code is
`further configured to process the markup-based descriptor
`language to selectively configure the client computer device
`to deploy the application so as to accomplish execution of
`the application by the client computer device stand-alone or
`by the client computer device in cooperation with a server to
`which the device is connectable via a network connection.
`
`BRIEF DESCRIPTION OF THE FIGURES
`0020 FIG. 1 illustrates an outline of the runtime archi
`tecture, in accordance with an embodiment of the present
`invention.
`0021
`FIG. 2 illustrates an outline of the development
`and deployment process, in accordance with an embodiment
`of the present invention.
`0022 FIG. 3 illustrates the processing runtime client and
`server stacks, in accordance with an embodiment of the
`present invention.
`0023 FIG. 4 illustrates a description of three major
`deployment profiles supported by preferred embodiments of
`the present invention.
`0024 FIG. 5 illustrates the flow of information within
`the client and server stacks of an embodiment of the present
`invention, for the thin connected profile.
`0025 FIG. 6 illustrates the flow of information within
`the client and server stacks of an embodiment of the present
`invention, for the thick connected profile.
`0026 FIG. 7 illustrates the flow of information within
`the client stack of an embodiment of the present invention,
`for the stand-alone profile.
`0027 FIG. 8 illustrates the flow of information within
`the client and server stacks of an embodiment of the present
`invention, for the applet profile.
`0028 FIG. 9 illustrates an embodiment of a visual design
`module of the present invention
`0029 FIG. 10 illustrates embodiments of the markup
`based descriptors and corresponding screens displayed by
`embodiments of the present invention
`
`DETAILED DESCRIPTION
`0030. A comprehensive flexible solution, based on a
`markup language like XML, for developing Smart mobile
`
`applications and services, and for deploying them in hetero
`geneous environments. Smart mobile applications can be
`used in a connected or disconnected mode and they can
`access and process resources locally or on a server. Accord
`ing to one aspect, a flexible client-server architecture is
`targeted to run Smart mobile applications. The applications
`and the deployment architecture are specified within
`markup-based descriptors. The Supported architecture speci
`fications range from a standalone client running an entire
`unconnected application, to a thin client managing the User
`Interface with the business logic of the application running
`on the server. In between, many combinations of client and
`server side processing may be specified. The characteristics
`of the architecture may be dynamically modified, thus
`leading to increased flexibility in the deployment. Mostly,
`the markup-based descriptors are forms specifying the User
`Interface of the application, the behavior of the application
`in response to the interactive events, the business logic of the
`application, and the location where the resources are to be
`found and processed. The behavior of the application is
`defined in a scripting language, which is given access to the
`resources of the device, including access to methods written
`in a language like Java, either on the client or on the server.
`0031. For example, a client runtime system displays
`interactive screens, or forms, interacting with specific server
`components running within an application server. The client
`runtime retrieves a form specification, either locally or from
`the server. When the form is accessed from the server, it may
`be preprocessed therein. Otherwise, it is preprocessed on the
`client. The preprocessing of a form specification is a con
`struction process, where the actual form to be displayed is
`constructed as specified in the form specification, possibly
`using available resources like databases to populate the
`actual form. The client runtime parses and processes the
`actual form to generate the User Interface on the device, and
`then handles the interactive events. The client runtime is
`typically installed on the computing client device, which
`may be a Smart phone, a PDA, or a desktop computer, but
`it can also be downloaded on demand as an applet into a
`browser. The server software is typically installed on a
`server running a Java application server. The entry point in
`the server Software is a servlet using an XML configuration
`file generated by the Designer. When a client device sends
`a request, the servlet analyzes the request, prepares the XML
`formatted response, and sends it back to the client. The
`preparation process may include preprocessing of a form
`specification, and retrieval of deployed forms and/or data
`from backend systems.
`0032. According to another aspect, a development and a
`deployment process is provided for Smart applications and
`services. For example, the development and deployment
`process may be performed in three steps. The first step is the
`user interface and interaction design step, and produces the
`interactive specification of the forms. Within this step,
`databases and other resources are managed and accessed as
`abstract references, without any indication about their physi
`cal location or other implementation-dependent characteris
`tics. The second step is the deployment definition step, that
`is, defining where and how the form specifications,
`resources and data are to be deployed on the client and the
`servers. The third step corresponds to the actual deployment
`on the target platforms. This separation provides means for
`deploying the same application across multiple kinds of
`distributed environments. The environments may differ by
`
`13
`
`

`

`US 2006/0075070 A1
`
`Apr. 6, 2006
`
`the operating system of the client device, by the resources
`available on the client or on the server, and by the charac
`teristics of the connection. The result of the development
`and the deployment process is a set of markup documents
`describing the architecture and the behavior of the resulting
`application.
`0033. As an example of this development and deploy
`ment process, an easy-to-use Rapid Application Develop
`ment (RAD) designer tool may be provided for application
`developers. The designer tool running on the developer's
`computing device provides the developer with tools for each
`step of the development and deployment process, from the
`visual definition of screens to the testing of full-fledged
`client-server applications. With the designer tool, the devel
`oper can define and edit the screen visually. The designer
`tool creates the XML files required by the client and by the
`SeVe.
`0034. The same application may thus be deployed on
`different deployment models and platforms, providing
`increased flexibility (useful, for example, for wireless imple
`mentations). For example, if the application is designed to
`Support the sale force of a large corporation equipped with
`both wireless PDAs and desktop computers, different types
`of deployments may be required. In the office, the user may
`expect to access the application through a thick connected
`model, using the full processing power of a desktop com
`puter and the high bandwidth of the local network. While
`outside the office, the user may access the application, for
`instance to check the status of an order, from either a PDA
`using a thin connected model or from a browser through the
`Internet by using an applet deployment mode. When a
`connection is not available, the application may operate in a
`stand-alone mode, thus allowing the user to enter an uncom
`mitted order or estimate a total price.
`0035 FIG. 1 illustrates, at a broad level, the runtime
`architecture of one embodiment in accordance with the
`present invention. The runtime architecture is implemented
`on a computing client device 102 and a server 100, con
`nected through a connection link 117. The illustrated
`embodiment corresponds to a “thin client runtime configu
`ration.
`0036) The computing client device 102 may include two
`or more layers. The operating system 110 interfaces to the
`hardware and handles the low level management of the
`resources on the device. Such as memory, storage, and user
`input. A Java Virtual Machine is considered an extension of
`the operating system, abstracting the device's resources into
`the Java standard, and providing a standard programming
`platform across devices. A third layer is the client runtime
`112, providing part of the client side functionality. The
`server 100 may comprise a Java J2EE compatible applica
`tion server 108, which manages the services available on the
`server. The server runtime 106 based on a Java servlet
`provides part of the server side functionality in accordance
`to the present invention. The communication link 117 may
`be an Internet connection based on the HTTP protocol.
`0037. When, through an interaction 101 with the com
`puting client device 102, a user requests access to a form
`from a service located on the server 100, the client runtime
`112 sends a request 107 to the server 100 using the available
`communication link and protocol 117. On the server 100, the
`application server 108 analyzes the request and forwards it
`
`to the server runtime 106. The server runtime processes the
`request, recognizes it as a form request, retrieves the
`requested form specification stored in an XML file 116 and
`additional data from external resources 118 as appropriate,
`and combines them to construct the preprocessed XML form
`120, which is passed back to the client device 102. The client
`runtime 112 then processes the XML form and generates 103
`the corresponding User Interface on the device's display.
`0038. This general architecture described with reference
`to FIG. 1 illustrates a deployment with a thin client profile
`where the construction of the form occurs on the server and
`no local storage is used on the client. However, other
`deployment profiles may be employed. The following
`deployment profiles will be later discussed in more detail:
`0039 Stand-alone: the form specifications are stored,
`and the displayable interactive forms constructed and
`processed on the client, and no connection to a server
`is utilized.
`0040. Thick connected client: the form specifications
`are retrieved from a server, but the displayable inter
`active forms are constructed and processed on the
`client. Local resources. Such as local databases may be
`involved.
`0041. Thin Client: the form specifications are stored on
`the server. The displayable interactive forms are con
`structed on the server and the preprocessed forms are
`then passed to the client. The client handles the pro
`cessing of the events once the form is on the device, and
`no access to client resources is utilized.
`0042 Applet deployment: the runtime is not installed
`on the client; it is downloaded on request from the
`server and runs inside a browser.
`0043. The named deployment profiles are not fixed dur
`ing the execution of a given application. For example, the
`frequently used forms of an application may run in a
`stand-alone mode, and the less frequently used ones may be
`deployed in a thin or thick client mode. Furthermore, the
`present invention provides means for dynamically changing
`the deployment profile during the execution of an applica
`tion, thus leading to highly flexible architectures.
`0044 FIG. 2 illustrates, at a broad level, an embodiment
`of the development and deployment process in accordance
`with the present invention. A Rapid Application Develop
`ment (RAD) designer tool 200 running on the developer's
`computing device is provided. The designer tool 200 com
`prises three modules: the visual design module 226, the
`deployment module 228, and the test module 244. The
`process is carried out in four major steps: the visual design
`step 202, the deployment definition step 206, the export
`deployment step 210, and the test platform step 240.
`0045. The visual design step 202 includes defining the
`abstract form specifications 204 of the application. An
`abstract form specification is stored as an XML document.
`The developer designs the visual aspect of the applications
`forms, by interacting with the visual design module 226,
`typically by positioning visual components on the screen.
`The developer may specify the interactive behavior of each
`visual component through Script code, as required. Capabil
`ity is provided for Script code to access external resources as
`abstract references, delaying the binding to the actual
`
`14
`
`

`

`US 2006/0075070 A1
`
`Apr. 6, 2006
`
`resources until the deployment definition step 206. As a
`result, the visual layout and behavior of the applications are
`specified independently of the target platforms. External
`resources the Script code can manipulate include Java meth
`ods, images and databases. While presenting the visual
`aspect of a form, the designer tool 200 generates an XML
`representation 204 containing the full specification of the
`abstract form, including the interactive behavior of the form.
`The developer may choose to perform part or all of the tasks
`of the visual design step 202 by directly editing this file,
`using the text-editing feature of the visual design module
`226.
`0046. During the deployment definition step 206, the
`developer defines one or more deployment targets 230 for
`the current application using the deployment module 228.
`The characteristics of the deployments for an application are
`stored in an XML document, namely the project file 208.
`Each deployment target 230 corresponds to a specific plat
`form 242, and comprises the description of the client profile
`and the accessed servers. For each abstract resource refer
`enced during the visual design step 202, the developer
`specifies its actual location and settings.
`0047. During the export deployment step 210, the devel
`oper actually deploys the required files on the client device
`238 and the server 236, using the deployment module 228 of
`the designer tool 200. When the developer requests the
`deployment module 228 to export the deployment, the
`designer tool 200 creates all the files required by the
`deployment and copies the files and the resources either to
`the client or to the server according to the deployment
`definition.
`0.048. During the test platform step 240, the developer
`tests the application in the context of each of the platforms
`242 defined during the previous development steps, using
`the test module 244.
`0049 FIG. 3 illustrates the client and server processing
`runtime stacks of various architecture embodiments. The
`processing stack comprises three principal layers: the
`resource manager 320, the processor 306, and the User
`Interface (UI) Manager 300. Two types of stacks are defined:
`the client stack 308, which includes the three layers named
`above, and the server stack 318 which excludes the UI
`Manager 300. By providing similar processing stacks on the
`client device 326 and on the server 328, improved flexibility
`in the deployment of applications, is provided since most of
`the applications' logic may be run uniformly on either the
`client or on the server.
`0050. Within the processor 306, the form builder 314
`handles the transformation of form specifications into dis
`playable interactive forms. The form builder 314 analyzes
`the form specification to check if additional resources are
`required, including data, image or methods. The requests for
`the resources are passed to the resources manager 320, as
`needed. For example, the form specification may specify
`that a visual grid be filled with data extracted from a
`database table. The form builder 314 is in charge of per
`forming this task. The developer may use Script code within
`the form specification to define how the form may be
`constructed, making the construction process more flexible.
`If the form contains script code, the script engine 316
`compiles it.
`0051) The UI Manager 300 interacts with the input and
`output capabilities of the client device 326, such as screen,
`
`keyboard, touch screen, Sound card or mouse. These ele
`ments are specific to the device and are managed by the
`operating system of the device. The display manager 302
`handles the creation of the visual layout of the forms, using
`the visual controls available on the client device, such as
`buttons, text fields or grids, as expressed in the displayable
`interactive form created by the form builder 314. When
`interest for an event has been registered within a form, the
`event manager 304 is in charge of notifying the correspond
`ing component of the form whenever the event occurs, and
`if script code has been associated with the event on the
`component, the Script engine 316 is in charge of running the
`corresponding code.
`0052 The resource manager 320 receives the requests for
`external resources, either from the processor 306 or from the
`event manager 304. The resource manager 320 includes
`connectors 324 to access the different types of resources.
`Available resources include, for example:
`0053 Databases
`0054 Table: a table from a database, such as JDBC
`and XML databases
`0.055
`Query: an SQL query on a JDBC database or
`an XML query to an XML file
`0056 Multimedia
`Image file: a file containing an image
`0057)
`0.058 Multimedia stream: a link to a video or sound
`streaming server or to a file containing video or
`Sound data
`0059 Graphics
`0060 Network Files
`0061 XML file: an XML document stored as a file,
`which is parsed into a Document Object Model
`(DOM) tree
`0062 Methods
`0063 A Java class: a user defined class implement
`ing some complex business logic
`0064 EJB: Entreprise Java Beans
`0065 File System: access to the local storage
`0.066
`Other Device Resources
`0067. Device specific resource (IrDA, bar code)
`0068 Functional Resources
`0069 Payment: secure payment
`0070) Identification: secure identification
`0071 Location service: a service providing the geo
`graphical location of the device
`0072. When the returned resource is an XML document,
`the resource manager 320 parses the XML file and returns
`the DOM representation of the XML document.
`0073. The requester 310 handles the communications
`between the client and the server. The exchange of data is
`structured essentially in the form of XML messages, either
`in a text format or a compiled format. The compiled format
`is managed by the compiled XML module 312, and is more
`
`15
`
`

`

`US 2006/0075070 A1
`
`Apr. 6, 2006
`
`efficient, as the size of the transferred data is reduced.
`Additionally, it saves the trouble of translating objects into
`XML on the server and the reverse on the client.
`0074 FIG. 4 shows a broad description of the three
`primary deployment profiles. Each of these profiles will be
`later described in a more detailed fashion, in FIGS. 5, 6, 7.
`An additional specific profile, namely the applet profile,
`represents an example of a mix of the three primary profiles,
`and is illustrated in FIG. 8:
`0075) Thin Connected Client 404: On the server 408,
`the resource manager retrieves the deployed form from
`the server storage. The processor on the server 408
`retrieves additional resources, if necessary, and pro
`cesses the form. The processor then sends the processed
`form to the UI manager on the client device 406, which
`generates the interface on the device's display.
`0076) Thick connected client 402: On the server 408,
`the resource manager retrieves the form specification
`from the server storage and sends the form specification
`to the processor on the client device 406. On the client
`device 406, the processor retrieves additional resources
`if necessary, processes the form specification and
`passes the processed form to the UI manager, which
`generates the interface on the device's display.
`0.077
`Stand-alone 400: On the client device 406, the
`resource manager retrieves the form specification from
`the local storage resource and passes the form specifi
`cation to the processor. The processor retrieves addi
`tional resources if necessary, processes the form speci
`fication and passes the processed form to the UI
`manager, which generates the interface on the device's
`display.
`0078. In each of these modes, including the stand-alone
`mode, external data can be incorporated through a connector
`to an external resource. For example, the client device 406
`may query a network database or an XML data server on the
`web.
`0079 An additional mode, the applet deployment mode,
`can be thought of as a combination of the thin and the thick
`connected client profiles. However, in this case, the client
`runtime is not an application but an applet running inside a
`web browser supporting Java. With this model, the user can
`access the same application without installing specific runt
`ime software on the client. The use of an applet constrains
`the deployment, because standard restrictions for applets
`apply, Such as restricted access to local resources and to
`SWCS.
`0080. The process of presenting a form on the client
`device is now described within an embodiment of an archi
`tecture. The process will be illustrated for each of the main
`deployment profiles described above in FIG. 4. In the
`following figures, thick arrows represent the flow of infor
`mation between stack layers. Notice that, in some embodi
`ments, the grayed layers in the figures represent layers that
`are actually available on the computing system, although
`they are not used in the represented deployment profile.
`Alternatively, in Some embodiments, the grayed layers may
`be absent.
`0081 FIG. 5 illustrates the flow of information within
`the client and server stacks, for the thin connected profile.
`
`0082 501 The process starts when the user raises an
`event on the device interface 10, associated with an action
`provoking the presentation of a new form.
`0083 502 The event manager 14 intercepts the event and
`sends the request to the requester 21.
`0084 503 The requester 21 transmits the request as an
`XML message to the listener 35 on the server 36.
`0085) 504 The listener 35 analyzes the request and sends
`a command to the resource manager 34 to retrieve the XML
`file 520 containing the form specification. The resource
`manager 34 then parses the XML document into a DOM
`tree.
`0086) 505 The parsed DOM tree of the form specification
`520 is passed to the processor 30. The screen builder 32 uses
`this DOM tree to construct a new DOM tree representing the
`displayable interactive form. During this processes, the
`script engine 33 may be invoked in order to execute the
`construction of Script code if any.
`0087 506 As part of the construction process, the pro
`cessor 30 may invoke the resource manager 34, requesting
`some data from a database 521 to populate the displayable
`interactive form.
`0088 507 The processor integrates the data in the form as
`specifi