Patent Application
20070300237
In the figures which illustrate an example embodiment of the invention,
In one aspect of the below-described embodiment, there is provided a method comprising: based at least in part on a first markup language document describing routines for accessing remote application data, generating a second markup language document describing: an invocation of one of the routines; data to be passed as a parameter to the one of the routines; and circumstances in which the invocation is to occur.
In another aspect of the below-described embodiment, there is provided a machine-readable medium storing code for execution at a computing device, comprising: machine-executable code for generating, based at least in part on a first markup language document describing routines for accessing remote application data, a second markup language document describing: an invocation of one of the routines; data to be passed as a parameter to the one of the routines; and circumstances in which the invocation is to occur.
In yet another aspect of the below-described embodiment, there is provided a machine-readable medium storing code for execution at a computing device, comprising: machine-executable code for instantiating an instance of an object-oriented class, the instantiating being based on at least one markup language element of a markup language document describing an invocation of a routine for accessing remote application data, data to be passed as a parameter to the routine, and circumstances in which the invocation is to occur; and machine-executable code for customizing, based on attributes of the at least one markup language element, the instance for performing the invocation.
Communications between a wireless communication device and an application on an application server may pass through a transaction server. In United States Patent Application 2003/0060896 to Hulai et al. published Mar. 27, 2003, the contents of which are incorporated by reference herein, an approach is described whereby a definition file for each available application is created and stored on the transaction server (referred to as a “middleware server” in Hulai et al.). This so-called “application definition file” may be written in a markup language such as Extensible Markup Language (XML). The XML elements and attributes in the definition file may dictate the user interface at the wireless communication device, the format of messages exchanged with the transaction server and server-side application, and a format for storing application-related data at the device. The XML element and attributes in the application definition file may be as described in Appendix “A” of the above-noted publication, for example.
Hulai et al. contemplate intercommunication between the application and multiple wireless computing devices of various types executing distinct operating systems such as the RIM operating system, Windows CE, or the Palm OS.
Each wireless communication device in communication with the transaction server is provided with virtual machine (“VM”) software to interpret and “execute” the definition files. The VM software varies depending upon the operating system of the wireless communication device. When a wireless communication device wishes to use an application for the first time, it downloads the application definition file for the application from the transaction server. The application definition file controls the screen display at the wireless communication device, including the display of application data at the device, and the nature of possible user inputs, such as through displayed entry fields. When a wireless communication device user inputs information, a package (message) containing this information in a format that accords with a format defined in the definition file may be created and sent to the transaction server. The transaction server passes such packages to the application server. This approach has the advantage that information is received by the application in a consistent format from various wireless computing devices, regardless of the operating system of the device.
To facilitate construction of the definition files, a rapid application development (RAD) tool may be employed. A RAD tool may be programmed computer providing an intuitive graphical user interface (GUI) that facilitates “drag and drop” application development, so that even those who lack depth of expertise in software development or markup languages may create definition files. Using the RAD tool, an integrator may create a hierarchy of graphical icons from a predetermined set of available icons. Icons generally correspond to XML elements representative of various wireless communication device application programming constructs, such as tables for storing data, messages to be sent to the transaction server, user interface screens, user interface screen components (e.g. widgets), actions to be performed upon the occurrence of specified events, and so forth. Each type of icon may have properties, corresponding to attributes of the corresponding XML element, that may be viewed and set by a user through the GUI. The structure of a created hierarchy of graphical icons, in terms of which icons are contained by (or are “children of”) which other icons, may be limited by the permissible containment (i.e. parent-child) relationships between the various represented XML elements, as dictated by an applicable XML schema. As a developer develops the wireless communication device application, the tool 116 automatically generates the corresponding XML. Use of the RAD tool in this fashion may prevent the integrator from having to manually develop definition files, which, although possible, would burden the integrator with learning the details of the applicable XML schema and with generating a valid and well-formed markup language document. The RAD tool may be implemented within a generic integrated design environment (IDE) framework such as the Eclipse framework.
The subject embodiment utilises aspects of this approach to handling communications with wireless communication devices in a new approach, effected largely at the transaction server, for handling wireless computing device communications with the application on the application server.
In overview, with reference to
As shown, in
Library 48 is a set of one or more electronic files containing precompiled routines 49 for accessing the application 14. The routines effectively define a new API, intended for use at the transaction server 20, that becomes the “face” of application 14 from the perspective of other, calling code at the transaction server-specifically, virtual machine software 60 (described below). Routines 49 are written so as to provide useful or convenient mechanisms for “mobilizing the application”, i.e. for causing the application to become accessible by wireless communication device 30. In the present embodiment, the routines 49 take the form of methods defined within object-oriented classes. Specifically, the library 48 is a .NET assembly file (having the extension “.dll”) comprising byte code that was generated by compiling source code written in an object-oriented programming language such as C# or Java for example. The routines 49 include calls to the legacy API of the application 14 and may include logic which “massages” returned data from the application into a form that is useful for “mobilizing” the application. The legacy API calls may employ such technologies as the Simple Object Access Protocol (SOAP) or Distributed Common Object Model (DCOM) for example, which are known in the art.
As noted, routines 49 are written in contemplation of, and in support of, application mobilization. This may be contrasted against the application's legacy API, which may not contemplate presentation of the application at a wireless communication device at all. Thus, if the application 14 were an email application, a library routine may invoke a legacy API function which returns all email messages of a user's inbox, and may then provide a subset of those messages, say, fifteen email messages at a time upon each subsequent invocation. This may be useful for mobilizing an email application given that a typical wireless communication device display may only be able to list about fifteen messages at once, due to size constraints. As another example, if a wireless communication device application is to present two categories of data on its screens (e.g. user surname and financial information) a library method could, when invoked, call a first legacy API function with certain parameters (e.g. an account number) and receive a return result falling within the first category (account holder surname), use the return result to invoke a second legacy API function and receive a return result in the second category (financial information), and further use both return results in formulating a customized return result (surname with financial information) that is convenient for presentation at the wireless communication device.
As should be apparent from the above, the library routines 49 effectively shield an integrator who is tasked with mobilizing an application from the legacy API, which may be confusing or ill-suited for use in accessing application data for presentation at a wireless communication device, and provides in its place a new API, to be invoked at run-time, which is better suited to application mobilization. The integrator need only invoke the methods of the new, better-suited API in order to gain access to the application 14. The integrator need not understand how the library routines 49 achieve their result.
The second component of connector 42 is a markup language document 50, referred to as a “connector descriptor” document, which describes the new API, i.e. describes the routines 49 in the library that are available for invocation at the transaction server 20. The connector descriptor document 50 may also describe other aspects of the library 48 (e.g. system variables). The connector descriptor document 50 is written in a markup language, such as Extensible Markup Language (XML), to facilitate its parsing and usage at run type by the virtual machine software 60. The information in the connector descriptor document 50 facilitates the invocation of library methods 49 by the virtual machine software 60.
The relationship between a connector 42 and an application 14 is typically (but not necessarily) one-to-one. Thus if access to two applications was desired, two connectors may be used. The present embodiment seeks access to only one application 14, thus only one connector 42 is provided. The connector 42 may also be referred to as a data source or a “plug-in”. The latter term is based on the fact that the connector descriptor document 50 portion of the connector 42 can also be “plugged into” the RAD tool 40 to configure the tool 40 for generation of a master definition file 44, as will be described.
The master definition file 44 is a hierarchy of XML elements which effectively “encode” the manner in which the virtual machine software 60 at the transaction server 20 should: parse incoming XML packages from the wireless communication device 30; invoke library routines 49 to pass parsed message data to the application 14; and send response messages (also XML packages) back the wireless communication device 30. The XML elements of the master definition file can be used to define “business logic” for execution at the transaction server 20, in support of mobilizing the application. For example, certain XML elements can be used to define if-then-else logic which results in the run-time invocation of two different library methods 49 (in the alternative) based on an ascertained value of a field in an XML package. The virtual machine software 60 interprets these XML elements and generates a like hierarchy of object instances 70 at run time in the memory of the transaction server 20. The relationship between an XML element and an object instance is generally one-to-one. The object instances 70 are instantiated from a set of object classes 62 stored in memory 26. Each object 70 has data members that are populated with the values of the XML attributes associated with the corresponding XML element in order to “customize” the object for effecting the desired operation. The master definition file 44 is generated by the integrator, with knowledge of: (1) the format of wireless communication device packages expected to be received at transaction server 20; and (2) the new application API (i.e. exposted library methods 49) as described by the connector descriptor document 50. When the master definition file 44 is deployed to the transaction server 20 along with the connector 42, and the virtual machine software 60 is invoked, the desired operation will be initiated. The XML may be in accordance with the XML 1.1 W3C Recommendation, 4 Feb. 2004, François Yergeau et al. (edited in place 15 Apr. 2004), provided at www.w3.org/TR/2004/REC-xml11-20040204/, the contents of which are hereby incorporated by reference hereinto.
To facilitate creation of connector 42, the author of the virtual machine software 60 may publish interfaces (e.g. C# or Java interfaces) indicating types of objects (classes) and methods that need to be implemented within the library 48 in order for the virtual machine software 60 to be able to use the library 48 to access the application 14. For example, there may be an interface for a connector object, a looping object, and a system variable object, each of which is described below.
The connector object (not to be confused with connector 42) may contain properties representing information necessary to connect to a back-end application (e.g. username, password, and path member fields) and may require implementation of a “connect” method for establishing a connection to the application. The connector object may implement the following exemplary interface (shown in the C# programming language):
The looping object represents an array or set of objects returned by the application 14 and may require implementation of methods to facilitate processing these objects one by one, such as: a method to indicate the first object in the array or set (“beginning of the file”); a method to indicate the last object in the array or set (“end of the file”); a method to move to the next object; a method to move to the previous object; a method to move to the first object; and a method to move to the last object. A looping object may also expose ad-hoc functions such as a function that returns a scratchpad Value or a function that returns looping object. The looping object may implement the following exemplary interface:
A system variable object would allow the integrator to define a system variable (i.e. a variable defined within library 48) that could be accessed or set from the virtual machine software 60 at run time. System variables could represent a username, password, and operating system path to the application at the application server, or other variables that may be useful in connection to application 14. The system variable object may implement the following exemplary interface.
Implementations of each of these types of objects may of course define methods not required by the interface.
To facilitate creation of a master definition file 44, the afore-referenced RAD tool 40 could be used. RAD tool 40 may be a computer having a processor 41 connected to memory 43 (
Execution of the RAD software 52 causes, RAD tool 40 to present a GUI which allows a user (the integrator) to enter user inputs 46 for defining a hierarchy of icons representing operation at the transaction server 20. The hierarchy governs the run-time operation of virtual machine software 60 in parsing XML packages from device 30, invoking methods 49, and sending return results in other XML packages to device 30. RAD software 52 is pre-programmed (e.g. as loaded from optical disk 54) to make available within the RAD tool GUI certain “default” icons that may be used (added to a hierarchy of icons) regardless of the nature of the connector(s) to be employed to access the application 14. Such icons may for example represent such program constructs as table definitions defining local tables for storing application-related data or package definitions defining messages to be received from and sent to wireless communication device 30 or ACTION constructs as described in Appendix “A”.
Beyond being pre-programmed to provide default icons the RAD tool 40 is further configured with the connector descriptor document 50 “plug-in” to make the tool 40 aware of the objects (and invokable methods thereof) of connector 42. The plug-in causes new selectable options to appear within the GUI of RAD tool 40 that are specific to the connector 42. For example, an ACTION icon may have a new type representing the invocation of a specific method 49 of a particular class defined in library 48. When this action type is selected, a list (e.g. in the form of a pull-down menu) may initially be presented which enumerates available objects (classes) defined in library 48. When an object is selected from the list, another list (e.g. another pull-down menu) may thereafter be displaying the methods 49 defined within the selected object that are capable of invocation from virtual machine software 60, as specified in the connector descriptor document 50. When one of the method names is selected from that list, the RAD tool GUI may further enumerate the parameters for that method in a further properties window pane, with an edit box next to each parameter for entry by the integrator of the parameter values. By selecting the method name and specifying which data (e.g. which field of which XML package from the wireless communications device 30) should be used as its parameters, the RAD tool user may cause XML elements and attributes for effecting an invocation of that method to become encoded in the resultant master definition file 44 that will ultimately be generated by the RAD tool 40. If the RAD tool 40 were configured with one (or more) different connector descriptor documents, different options (e.g. different objects, methods and parameters) may become available in the RAD tool GUI.
It will be appreciated that the RAD tool 40 does not use the library portion 48 of connector 42. Accordingly, this portion 48 need not actually be resident in memory 43 of RAD tool 40. To reflect this fact, the library 48 is indicated in memory 43 with a dashed border in
The master definition file 44 and connector 42 are downloaded to the transaction server 20 prior to run time. At run time, the virtual machine software 60 at the transaction server 20 instantiates objects 70 based on the master definition file 44 and triggers execution of certain methods of the objects 70. The objects 70 essentially await the arrival of XML packages from the wireless communication device 30 and, upon their arrival (which is signaled by operating system callbacks into methods of certain objects 70), the objects 70 make appropriate calls to the methods 49. The objects 70 may dynamically link to the library 48 to make these calls possible. Instances of the classes defined in library 48 may be instantiated through use of an execution environment, such as a .NET framework (not shown), in conjunction with information from the connector description document 50, such as qualified name information for classes of the .NET assembly .dll file. In particular, by using reflection, the qualified name information may be used to create instances of the classes (objects) of the .NET assembly. The handles to these objects permit object methods 49 to be invoked. Thus, when an XML package arrives at the transaction server 20 from the wireless communication device 30, the instantiated objects 70 effectively parse the package into pieces, which are supplied to the application 14 via the instantiated library objects which effect the “new API” defined by connector 42. Similarly, any return result from the application 14 may trigger generation of a return XML package by objects 70, which package is sent to the device 30 to complete the transaction.
A simple example will help illustrate the foregoing. In the example, it is assumed that the application 14 on the application server 12 is an SQL database.
Turning to
Lines 6 and 7 identify the objects Username and Password as system variables. This indicates that the library 48 declares variables named Username and Password which can be set and read by objects 70 at run time.
Lines 8 to 20 declare an object named “ADOConnection” which implements the interface “Connector”, as indicated by the type attribute. This declaration indicates that the library 48 defines a class named “ADOConnection” which implements the interface “Connector”. The qualified name of the class, namely “mycompany.ado.ADOConnection”, is indicated by the qualifiedname attribute. This attribute is used by a .NET framework at transaction server 20 (not illustrated) for purposes of identifying the correct class of the adoimpl.dll file at run time, via reflection, for purposes of dynamically invoking the methods described below.
Lines 12 to 14 expose a method “Connect” of the ADOconnection object which has a string parameter “adostring”. The method returns a scratchpad value (i.e., a value that is cached at the transaction server 20) indicative of whether the connection was successfully established (TRUE for success or FALSE for failure).
Lines 17 to 19 expose a method “Execute” of the ADO connection object which takes an SQL string as an input (representing a statement used to query the database 14) and returns a set of matching records as a looping object “RecordSet”.
Lines 23 to 32 define the RecordSet object as an implementation of the looping object interface and indicates the qualifiedname of the relevant class within the DLL (“mycompany.ado.RecordSet”).
Lines 27 to 29 expose the method “FieldByName” of the RecordSet object which returns a value of a field in the current record of the set of matching records. The field name is specified by the fieldname parameter. This method extends the basic looping object interface described above.
Line 31 exposes the method “GetCurrentRow” of the RecordSet object which returns the current row (record) as a looping object “RecordSetRow”. This method also extends the basic looping object interface.
Lines 33-42 of
Lines 37 to 39 expose the method “ColumnValue” of the RecordSetRow object which returns the value of the column (field) for the current row indicated by an input “index” parameter.
Line 41 exposes the method “ColumnCount” of the RecordSetRow object which returns the number of columns for the current row.
The window illustrated in
Other portions of the RAD tool GUI (not shown) may include a main design area and a toolbar. The main design area may display the properties of currently-selected application component (icon) of the hierarchy 100. The properties are XML attributes associated with the XML element that is represented by the icon. The user of the RAD tool 40 may be able to enter text in editable fields near each property name to set the XML attribute values.
The toolbar may facilitate various development activities which occur during the creation of the hierarchy 100. The toolbar may for example include a menu list and icons for compiling or publishing the current project. Compiling refers to checking of various aspects of the defined program structure for errors or possible deviations from good programming practices (e.g. for an if-then-else ACTION icon, a hint message may advise the user that no actions have been defined in the “else” logic branch). Publishing refers to generating the master definition file 44 from the hierarchy 100. Publishing may entail serialization of a Document Object Model (DOM) tree representation of the master definition file 44 that is automatically generated within the memory 43 of RAD tool 40 as the user creates icons and assigns properties to them. DOM is described in detail in the W3C Recommendation entitled Document Object Model (DOM) Level 3 Core Specification, Version 1.0, 07 Apr. 2004, provided at www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/, which is hereby incorporated by reference hereinto.
The hierarchy 100 includes three main branches represented by icons 102, 104 and 106.
The first two branches, namely the device independent branch 102 and operating system branch 104, correspond to a portion of master definition file 44 which defines a wireless communication device application for downloading to, interpretation by and execution at the wireless communication device 30. Device independent branch 102 pertains to aspects of the wireless communication device application which are consistent between wireless communication device operating systems, such as the definition of application events (occurrences which trigger processing at wireless communication device application regardless of the application's status), database tables (tables for storing application-related data at device 30) and data rules (rules which dictate how incoming or outgoing XML packages affect data stored in database tables at device 30). The operating system branch 104, on the other hand, is for the definition of operation system-specific GUI screens that are displayed at the device 30. The definition of icons in these two branches 102 and 104 may result in the generation of XML elements and attributes as described in Appendix “A” of U.S. patent application Ser. No. 10/537,621, referenced above. These two branches do not pertain directly to transaction server operation and are thus not a focus of the present description. The branches are shown in collapsed form in
The third branch, server branch 106, corresponds to a portion of master definition file 44 which defines transaction server operation for parsing incoming messages from the wireless communication device 30, passing message data to the application 14, and returning any results from the application 14 to the device 30. Server branch 106 is shown in expanded form (i.e. with subordinate branches/icons visible) in
Each server branch contains a data source branch and a rules branch.
The data sources branch 108 below server branch 106 identifies the connectors that the integrator has opted to use at transaction server 20 for connecting to application 14. In the illustrated embodiment, the integrator has opted to use only connector 42 to access the application 14. Accordingly, only one connector icon 110 appears in the data sources branch 108. The data source branch 108 corresponds to lines 2-9 of
The user interaction with the RAD tool GUI for defining the connector icon 110 in the project explorer window may be as follows. The data sources icon 108 may initially be selected with a mouse (or similar user input mechanism) of the RAD tool 40. A right click (or similar user action) may cause a pop-up menu to be displayed. The pop-up menu may present a list of permissible actions that may be taken in the context of the data sources branch 108, including which icons can be created in that branch. An Add Connector option may permit the user to create an icon representing a connector to be used to access application 14 at run time. Selection of that menu item may cause the icon 110 to be created below icon 108, as shown in
The definition of connector properties in the connector properties window is illustrated in inset 120 of
Below the connector icon 110, a “read-only” portion A of the hierarchy 100 shows, at a first level, all of the classes defined in the library 48 (ADOConnection, RecordSet and RecordSetRow) and, at a second level, each method defined within each class. A third level (not illustrated) may show each parameter for each method and the type of each parameter. The information presented in read only portion A is obtained from the connector descriptor document 50 and is presented to communicate information about the features of connector 42 to the integrator. The connector document 50 may be parsed and converted to a DOM tree representation to facilitate dynamic access to the XML elements and attributes of document 50 and their values to make presentation of portion A possible.
For clarity, the reason that the connector object (defined at lines 8-20,
Referring to
The user interaction with the RAD tool GUI for defining the rule icon 152 in the project explorer window may be similar to the above-described procedure for creating a connector icon 110. The Rules icon 150 may initially be right-clicked to cause a pop-up menu to be displayed with a list of permissible actions. An Add Rule option may permit the user to create the icon 152 below icon 150 and a rule properties window to be displayed in a main design area of the RAD tool GUI.
The definition of rule properties in the rule properties window is illustrated in inset 160. A name field 162 allows the user to enter a name (“DoLogin”) that will be displayed as part of the icon 152. An “associated package” field 164 provides a drop-down list which lists, by name, each package that can be received at transaction server 20 as defined under the device independent branch 102 (
The rule 152 is represented in master definition file 44 by the AXRULE element which is opened at line 11 of
The actions icon 170 of
Immediately below the Actions icon 170, a total of six action icons 172, 174, 176, 178, 180 and 182 are defined. Each of these action icons may be defined by initially right-clicking actions icon 170, selecting an Add Action pop-up menu option, and specifying a type for the action. Permissible action types are defined in section 6 of Appendix “A” of U.S. patent application Ser. No. 10/537,621. New action types DATASOURCEMETHOD, DATASOURCEVARIABLE, DATAOBJECTMETHOD and EXCEPTION, not described in the above noted publication, may also be defined. These action types are described below. At run time, the actions 172, 174, 176, 178, 180 and 182 are performed in the order in which their icons appear in
Action icon 172 represents a SAVEITEM action whereby the value of the attribute “username” in the LOGIN XML package shown in
Similarly, action icon 174 represents a SAVEITEM action whereby the value of the attribute “password” in the LOGIN XML package is saved to a scratchpad memory variable “LoginPassword”. Icon 176 corresponds to the ACTION XML element at line 14 of
Action icon 176 represent an action of type DATASOURCE-VARIABLE which causes a system variable defined within the library 48 to be set to a value specified by the integrator. When action icon 176 is created, action properties may be defined in the main design area as shown at inset 190. A name field 192 allows the user to enter a name (“SetSystemVarUsername”) that will be displayed as part of the icon 176. A “systemvar” field 194 provides a drop-down list which lists, by name, each system variable defined within connector descriptor document 50. In
Action icon 180 is analogous to icon 176, and represents an action which causes system variable Password to be set to the value MasterPassword. Icon 180 corresponds to the ACTION element at lines 17-18 of
Action icon 178 represent an action of type DATASOURCE-METHOD which causes one of the methods 49 of library 48 to be invoked at run time. When action icon 178 is created, action properties may be defined in the main design area as shown at insets 200, 210 and 220 of
Referring back to
Within IF branch 230 of
Action icon 242 of
Within the subordinate THEN branch 250, which is executed if the return result is not end-of-file (indicating that the SQL database 14 had at least one entry for the input username and password), action icon 252 of type DATAOBJECTMETHOD results in the run time invocation of the FieldByName method of the RSlookup object in the scratchpad, with the value “USERID” being passed for parameter fieldname, and with the result being stored in another scratchpad variable UserID (see lines 35-38 of
Finally, within ELSE branch 232 of
In operation, transaction server 20 (
In the exemplary header above, the values of the APPNAME and VERSION attributes are the name and version of the application registered on the transaction server 20. This information is used by the server 20 to uniquely identify master definition file 44 (the “application”) corresponding to the message.
The virtual machine software 60 then instantiates objects 70 described in master definition file 44 within memory 26. The virtual machine software 60 then uses the PKG TYPE value of the LOGIN XML package to identify a rule object 70 corresponding to the received message. In the present embodiment, only one rule, defining operation when a package of type LOGIN is received (which rule is represented by the AXRULE element at lines 11 to 64 of
For certain “built-in” types of actions, such as actions of type SAVEITEM or IF actions for example, the logic that is executed when the action is performed is fully contained within the action object 70 and is merely “customized” by the setting of data members of that action object based on corresponding ACTION element attribute values.
For other types of actions that are not built-in, such as actions of type DATASOURCEMETHOD for invoking a method 49 defined within library 48, the action object 70 invokes one of the methods 49 (as provided by the connector provider—shown in
The virtual machine software 60 (
Once found, an instance of the ADOConnection object is created. The virtual machine 60 then executes the Connect method through .NET reflection method invocation, passing the supplied connection string parameter as defined at line 21 of
The Connect method (
As will be appreciated by those skilled in the art, modifications to the above-described embodiment can be made without departing from the essence of the invention. For example, in some embodiments, such as those in which the application 14 is not a database application, library routines 49 may not invoke legacy API functions. Rather, the routines 49 may access a database at application server 12 in which the application 14 stores application data. The routines 49 may access and/or modify the application data in this database directly (i.e. without using the legacy API). In this case, the routines 49 may incorporate logic which emulates logic existing within the application 12 for causing any change to a database table or record to properly update any other database values which are tied or related to the changed value. For example, if a new customer record is added to one database table, the logic may need to increment a customer count value in another database table. This logic may be necessary to avoid corrupting a database that is normally accessed by the application 14. When the author of the connector 42, who has a good understanding of application 14, emulates this logic within the routines 49 of library 48, the integrator who simply uses the connector 42 to invoke routines 49 by way of calls encoded within the master definition file 44 is freed from the burden of understanding and implementing that logic.
In another alternative, the interfaces provided by the author of the virtual machine software may define a “designer” object for facilitating the design of a particular connector in the RAD tool GUI. For example, if it is desired to provide a custom Query Designer for creating SQL queries in the RAD tool GUI in the case where the application is an SQL database, the author could design a custom interactive designer which conforms to a designer interface. The designer would “plug into” the RAD tool to provide a customized look and feel for creating SQL queries which goes beyond the conventional RAD tool GUI.
Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.
ARML is an XML markup language used by the AIRIX platform. It performs three tasks;
The diagram below illustrates how ARML is used.
The key to ARML usage is the application definition file held on the AIRIX server. This file defines the AIRIX tables for the application, the allowed message set and the user interface definitions for the application on a given device.
The scratchpad is used as a temporary storage area where a global value or a value associated to a screen can be saved for future use. The syntax for a scratchpad value is as follows:
There are several variables that are available that will retrieve application and system values to be used throughout the application. The syntax for these variables is as follows:
[TIME]—returns the current system time, formatted as hh:mm:ss am/pm.
[SYS.FUNC.DATEADD([SYS.VAR.DATE],+−x)]—The Date Arithmetic tag is used to add or subtract days from the current date. In the tag, x represents the number of days added or subtracted. Developers can also choose to substitute a hard-coded date value in the Date Arithmetic tag, in the place of the [SYS.VAR.DATE] tag.
[SYS.FUNC.DATETOSTR([SYS.VAR.DATE],d mmm yyyy h:nn:ss tz)]—The Date To String tag is used to convert date data to a string value.
[SYS.FUNC.STRTODATE([SYS.VAR.DATE],d mmm yyyy h:nn:ss tz)]—The String to Date tag is used to convert string data to a date value, in the RFC 1123 format.
The single-field lookup will run a simple SELECT query with one where-clause to retrieve specific data. The syntax is as follows:
These tags (<AXSCHDEF> . . . </AXSCHDEF>) mark the start and end of the application definition. THE AXSCHDEF tag has two attributes;
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <AXTDEFS> . . . </AXTDEFS> pair marks the start and end of the table definitions section. It has no attributes.
The <DPACKETS> . . . </DPACKETS> pair marks the start and end of the data package definitions section. It has no attributes.
The <DEVICES> . . . </DEVICES> pair marks the start and end of the device interface definitions section. It has no attributes.
Each table definition is enclosed within the <TDEF> . . . </TDEF> pair. The TDEF tag has the following attributes;
The <FIELDS> . . . </FIELDS> tag pair marks where the fields in a given table are defined. The FIELDS tag has a no attributes.
The <FLD> . . . </FLD> tag pair defines a single field in a table. Enclosed between the tags is the field name. The <FLD> tag has the following structure;
An email application would use 2 tables for storing sent emails.
This translates into the following ARML fragment;
The <AXDATAPACKET> . . . </AXDATAPACKET> pair delimits a package definition. The tag has the following attributes;
The <TABLEUPDATES> . . . </TABLEUPDATES> pair marks the start and end of the table definitions section. It has no attributes.
Each table update is enclosed within the <TUPDATE> . . . </TUPDATE> pair. The TUPDATE tag has the following attributes;
The <PKGFIELDS> . . . </PKGFIELDS> tag pair marks where the fields in a given data package are defined. The PKGFIELDS tag has no attributes.
The <PKGFLD> . . . </PKGFLD> tag pair defines a single parameter in a given data package. Enclosed between the <PKGFLD> . . . </PKGFLD> tags is the field name. The <PKGFLD> tag has the following attributes;
Using the table definitions example in section 3.2.4, when the user sends an email, a data package to transport the data would update the ‘SENTITEMS’ table and the ‘RECIPIENTS’ table. The following ARML fragment defines such a data package;
The <DEV> . . . </DEV> pair delimits an interface definition for a specific device. The tag has the following attributes;
The <SCREENS> . . . </SCREENS> pair delimits the screens definition for a specific device. The tag has one attribute;
The following example shows the screen definitions section for an application that allows a user to view their inbox and the mails in it.
section describes the format of application defined packages.
This section describes the general structure of an application-specific data package. As described in section;
The <PKG> . . . </PKG> tags delimit the package data. The PKG tag has the following attributes;
A sample data package following the rules in section 3.3.4 would have a body section like this;
We will use this sample package to illustrate how packages are derived from the package definition file. The first tag in the package is the BODY tag. This tag defines which type of
The ‘MAIL’ section updates the ‘SENTITEMS’ table in the database. It does not update multiple rows. The ‘RECIPS’ section updates the ‘RECIPIENTS’ table in the database; it does update multiple rows, and each row is contained within a pair of <RCP> tags.
The <SCREEN> . . . </SCREEN> pair marks the start and end of the screen definitions section. It has attribute—
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
The <QUERIES> . . . </QUERIES> pair marks the start and end of the queries definitions section. It has no attributes.
The <MENUS> . . . <AMENUS> pair marks the start and end of the menu definition section. It has no attributes.
The <BUTTONS> . . . </BUTTONS> pair marks the start and end of the button definitions section. It has no attributes.
The <TEXTITEMS> . . . </TEXTITEMS> pair marks the start and end of the text items section. It has no attributes.
The <EDITBOXES> . . . </EDITBOXES> pair marks the start and end of the editboxes section. It has no attributes.
The <CHOICEITEMS> . . . </CHOICEITEMS> pair marks the start and end of the choiceitems section. It has no attributes.
The <IMAGES> . . . </IMAGES> pair marks the start and end of the images section. It has no attributes.
The <CHECKBOXES> . . . </CHECKBOXES> pair marks the start and end of the checkboxes section. It has no attributes.
The <LISTBOXES> . . . </LISTBOXES> pair marks the start and end of the listboxes section. It has no attributes.
The <GRIDS> . . . </GRIDS> pair marks the start and end of the grids section. It has no attributes.
The <QUERIES> . . . </QUERIES> pair marks the start and end of query definition section. It has no attributes.
The <QUERY> . . . </QUERY> pair marks the start and end of a given query. It has the following attributes;
The <W> . . . </W> pair marks the start and end of a given where-clause. The value of the parameter is contained within the <W> . . . </W> tags. This value can be a specific value or a reference to a user interface field in the format “[SP.screen.savename] or [QU.query.field]”. It has the following attributes;
The <MENUS> . . . </MENUS> pair marks the start and end of menu definition section. It has no attributes.
The <MENU> . . . </MENU> pair marks the start and end of a menu definition. It has the following attributes.
The <MENUITEM> . . . </MENUITEM> pair marks the start and end of a menuitem definition. It has the following tags;
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
The <BTN> . . . </BTN> pair marks the start and end of a button definition. It has one attribute—
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
The <TI> . . . </TI> pair marks the start and end of the screen definitions section. It has attribute—
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EB> . . . </EB> pair marks an edit box definition. It has the following attributes —
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
The choice item definitions section describes the choice items that exist on a given screen. A choice item is an interface item that requires the user to make a selection from a list of options. It can be represented in different ways on different devices; on a RIM pager, it is a choice box, while on a WinCE device, it is a drop-down list.
The <CHOICE> . . . </CHOICE> pair marks the start and end of a choice item definition. It has these attributes—
The <ITEMS> . . . </ITEMS> pair marks the start and end of a list of items to be included in the in the choice item. If a datasrc is specified, the <ITEMS> section is ignored.
The <I> . . . </I> pair marks the start and end of an individual item in the choice items list. It has the following attributes:
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ITEMS> . . . </ITEMS> pair marks the start and end of a list of items to be included in the in the list box. If a datasrc is specified, the <ITEMS> section is ignored.
The <I> . . . </I> pair marks the start and end of an individual item in the list box items list. It has the following attributes:
The value between the pair is the text value that is to be displayed in the list box. Can be a scratchpad or query value of the form [SP.screen.savename] or [QU.query.field].
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <EVENT> . . . </EVENT> pair marks the start and end of a user-interface level event definition. See section 6 for a detailed discussion of the Smart Client event model.
The <ACTION> . . . </ACTION> pair marks the start and end of an action definition. See section 6 for a detailed discussion of the Smart Client event model.
Grids allow data to be displayed in row-column format. Grids can display data from a data source (query) or they can contain hard coded values. Each column in a grid can be visible or hidden. Hidden values are maintained, but not visible to the user.
<COLS> . . . </COLS> This tag contains no attributes. But instead contains all the columns that are associated with the grid in the order in which they appear from left to right.
<COL> . . . </COL> This tag will determine the column specification for the grid. The attributes for this item are the following:
<ROWS> . . . </ROWS> This will Indicate any hard coded rows that would be created in the design studio. It does not contain any attributes but instead contains all the row definitions.
<R> . . . </R> This is the row declaration that contains all the values for the row that has been hard coded. It has no attributes itself, but contains the value definitions for the row.
An example of a grid declaration is as follows:
The Smart Client has a set of actions that it ties to events. Events can occur at the application level, the screen level or the user interface item level; an application level event is listened for throughout the operation of the application, a screen level event is listened for while the screen is displayed, and so on. If an action for an event is defined at multiple levels, the lowest level has precedence; i.e., user interface actions override screen level actions, which override application level actions. An attempt to list an event multiple times at the same level (application, screen, item) is invalid and will generate an error message.
The <EVENTS> . . . </EVENTS> pair marks the start and end of the events section. It has no attributes.
The <EVENT> . . . </EVENT> pair marks the start and end of an event definition. It has the following attributes;
The button click event occurs when the user selects a button. It has no attributes.
The menu items selected event occurs when the user selects a menu item. It has no attributes.
The data event occurs when ARML data is received from the wireless interface. It has the following attributes;
The <ACTION> . . . </ACTION> pair marks the start and end of an event definition. It has one fixed attribute, and a number of attributes that may or may not appear depending on the type of action required. The fixed attribute is;
The open action tells the Smart Client to open a new screen. It adds one extra attribute to the ACTION tag;
The arml action tells the Smart Client to compose and send an arml package. It does not add any attributes to the ACTION tag, but has the following subtag;
The save action tells the Smart Client to save all fields marked as persistent (i.e., they are defined with SAVE=“Yes”) to be saved to the scratchpad area. It has no attributes.
The purge action tells the Smart Client to clear all fields that have been saved to the scratchpad. It has no attributes.
The notify action tells the Smart Client to activate the configured notification on a device. For devices where this has no meaning, it will cause a beep to be played. It has no attributes.
The close action tells the Smart Client to close the application. It has no attributes.
The integration action tells the Smart Client to pass data to an interface exposed on a device. For example a COM interface on Pocket PC. This action will allow the developer to pass a parameter into an exposed method and then also save the result of that method in a global scratchpad value. The contents of the integration action's element are the input values to be passed to the interface. It has the following attributes;
The close screen action tells the Smart Client to close all open instances of the screen specified by name in the NAME attribute. This action has the following attributes:
The refresh action tells the Smart Client to re-run any queries and re-initialize all UI elements on the screen with the name specified by the NAME attribute. If there are multiple open instances of the screen, all open instances will be refreshed. The refresh action has the following attributes:
The saveitem action tells the Smart Client to create a new scratchpad item or to edit an existing scratchpad item. The value of the scratchpad item is defined within the <ACTION> . . . </ACTION> tags. The saveitem action has the following attributes:
This action will contain two lists of actions. One a list of actions to perform if the condition evaluates to TRUE (IFLIST), and another list of actions to perform if the condition evaluates to FALSE (ELSEIFLIST).
The structure of the action is as follows:
Conditions are used in conjunction with the IF Action. Conditions are specified as follows:
The following is a description of each of the supported conditions:
The following example serves to illustrate how a screen is used to compose a data package to be sent back to the AIRIX server. The example used is a screen giving the bare functionality for composing a basic email message—to simplify the example, the user cannot cancel the action, and multiple recipients are not allowed.
{data}
The package header is delimited by the <HEAD> . . . </HEAD> tags. Contained in text between the two tags is the id of the destination mobile. The HEAD tag has the following attributes;
The <SYS> . . . </SYS> pair contains the actual system package. The tag does not have any attributes.
The <REG> . . . </REG> pair delimit the registration request. The tag has no attributes.
The <USERNAME> . . . </USERNAME> pair contain the user name. The tag does not have any attributes.
The <PASSWORD> . . . </PASSWORD> pair contain the password. The tag does not have any attributes.
The <REGCONFIRM> . . . </REGCONFIRM> pair delimit the confirmation. The tag has no attributes.
The <VALUE> . . . <NVALUE> pair contains the status of the registration request. The following text strings are allowable;
The <APP> . . . </APP> pair contains an application header. It has the following attributes;
The <FINDAPPS> . . . </FINDAPPS> pair delimit the application registration request. It has no attributes.
The <FINDAPPSCONFIRM> . . . </FINDAPPSCONFIRM> pair delimit the confirmation. The tag has no attributes.
The <APP> . . . </APP> pair contains an application header. It has the following attributes;
The <APPREG> . . . </APPREG> pair delimit the application registration request. The tag has the following attributes;
The <APPREGCONFIRM> . . . </APPREGCONFIRM> pair delimit the confirmation. The tag has the following attributes;
The <INTERFACE> . . . </INTERFACE> pair delimit the interface definition. The tag has the no attributes, and contains an interface definition as laid out in section 3. Note that instead of the <DEVICES> . . . </DEVICES> tags in section 3.1.3.6, it will be replaced by
The ‘set active device’ package is shown by the <SA> . . . </SA> tags. The tag has no attributes; the tag pair contains the user's username
The <SACONFIRM> . . . </SACONFIRM> pair delimit the confirmation. The tag does not have any attributes.
The <VALUE> . . . <NVALUE> pair contains the status of the registration request. The following text strings are allowable;
The <NOAPP> . . . </NOAPP> pair delimit the confirmation. The tag has no attributes.
The <VALUE> . . . <VALUE> pair delimit the return code. It can only be NOAPPLICATION—Application not found.
