Title of Invention | OCCASIONALLY-CONNECTED APPLICATION SERVER |
---|---|
Abstract | Abstract Providing a framework for developing, deploying and managing sophisticated mobile solutions, with a simple Web-like programming model that integrates with existing enterprise components. Mobile applications may consist of a data model definition, user interface templates, a client side controller, which includes scripts that define actions, and, on the server side, a collection of conduits, which describe how to mediate between the data model and the enterprise. In one embodiment, the occasionally-connected application server assumes that data used by mobile applications is persistently stored and managed by external systems. The occasionally-connected data model can be a metadata description of the mobile application's anticipated usage of this data, and be optimized to enable the efficient traversal and synchronization of this data between occasionally connected devices and external systems. |
Full Text | OCCASIONALLY-CONNECTED APPLICATION SERVER COPYRIGHT NOTICE A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. CLAIMS OF PRIORITY U.S. Provisional Application No. 60/573,077 entitled "MOBILE APPLICATION SERVER" by Bosworth et al, filed May 20, 2004. [Attorney's Docket No. BEAS-01537US0]; and U.S. Patent Application No. 11/122,294 entitled "OCCASIONALLY-CONNECTED APPLICATION SERVER" by Bosworth et al, filed May 4, 2005. [Attorney's Docket No. BEAS-01537US1]. FIELD OF THE INVENTION The current invention relates generally to mobile application architectures, and more particularly to mobile application architectures for developing, deploying and managing applications for occasionally connected mobile devices. BACKGROUND OF THE INVENTION Computers and computing devices have become smaller, faster and more efficient. As a result, their functionality has evolved and they are able to store and process more information. However, there is a still a limit to what a device can store and process locally. Lately, the development of mobile connected systems have enabled even more functionality for portable devices. These devices, including laptop computers, PDAs, cell phones, notebook computers, blackberry-type devices, and other mobile devices can be connected to the internet wherever a strong connection exists. Though applications for these devices come in several forms, users historically prefer a web base model because of the ease of application deployment and subsequent changes. Additionally, web based pages are very simple and intuitive for users to use. There are several problems with the latest developments of mobile devices web browsing. It is not easy to get connections wherever a user is. The connection is typically through a standard phone connection, which depends on cellular phone signal strength. There are currently many dead zones in cellular phone networks, which can cause downtime for connections between a mobile device and a web server. This is even more troublesome when considering the interaction necessary to provide web page content through a typical browser. When a user interacts with a web browser, the browser will request more information from a server based on user input. This requires an active connection between the browser and a web server in order to retrieve new information to present to a user. Thus, when a user is interacting with a web browser on a mobile device and enters an area with weak signal strength or a dead zone, the weak connection (or lack thereof) will likely provide errors in the content received by the mobile device. Thus, the user is often unable to interact with the web page in this manner. What is needed is a mobile application architecture framework that provides an intuitive user interface and a more reliable mechanism for providing content to a user on a mobile device. The framework should also provide for developing, deploying and managing sophisticated mobile solutions while enabling a simple Web-like programming model that integrates with existing enterprise components. SUMMARY OF THE INVENTION In one embodiment, the occasionally-connected application server platform provides a framework for developing, deploying and managing sophisticated mobile solutions, with a simple Web-like programming model that integrates with existing enterprise components. Occasionally-connected applications may consist of a data model definition, user interface templates, a client side controller, which includes scripts that define actions, and, on the server side, a collection of conduits, which can describe how to mediate between the data model and the enteiprise. In one embodiment, the occasionally-connected application server assumes that all data used by occasionally-connected applications is persistently stored and managed by external systems such as web services. The data model can be a meta data description of the connected-connected application's anticipated usage of this data, and can be optimized to enable the efficient traversal and synchronization of this data between occasionally connected devices and external systems. The occasionally-connected data model can describe the structure (and other properties) of persistent application data. The occasionally-connected data model itself can be synchronized with a browser so that the client is able to intelligently to traverse data and synchronize data with the server. BRIEF DESCRIPTION OF THE DRAWINGS FIGURES 1A-B are illustrations of an architectural overview in accordance with one embodiment of the present invention. FIGURE 2 is an illustration of an asynchronous interaction diagram in accordance with one embodiment of the present invention. FIGURE 3 is an illustration of a programming model for a MAS application in accordance with one embodiment of the present invention. FIGURE 4 is an illustration of an entity relationship diagram in accordance with one embodiment of the present invention. FIGURE 5 is an illustration of an UML Entity Relationship Diagram in accordance with one embodiment of the present invention. FIGURE 6 is an illustration of a node instance diagram in accordance with one embodiment of the present invention. FIGURE 7 is an illustration of select operations in accordance with one embodiment of the present invention. FIGURE 8 is an illustration of an input output matrix in accordance with one embodiment of the present invention. FIGURE 9 is a CRM schema type diagram in accordance with one embodiment of the present invention. FIGURE 10 is an illustration of a page flow for part of a CRM application in accordance with one embodiment of the present invention. FIGURES 11A-B are illustrations of synchronization method of one embodiment of the present invention. FIGURES 12A-D illustrate exemplary keyref definitions of one embodiment of the present invention. DETAILED DESCRIPTION In one embodiment, the occasionally-connected application server platform provides a framework for developing, deploying and managing sophisticated mobile solutions, with a simple Web-like programming model that integrates with existing enterprise components. Connected-connected applications may consist of a data model definition, user interface templates, a client side controller, which includes scripts that define actions, and, on the server side, a collection of conduits, which describe how to mediate between the data model and the enterprise. In one embodiment, the occasionally-connected application server assumes that all data used by mobile applications is persistently stored and managed by external systems. The data model can be a meta data description of the mobile application's anticipated usage of this data, and can be optimized to enable the efficient traversal and synchronization of this data between occasionally connected devices and external systems. The occasionally-connected data model can describe the structure (and other properties) of all persistent application data. The model itself can be synchronized with the mobile browser so that the client is able intelligently to traverse data and synchronize data with the server. The occasionally-connected data model can describe the data that will be cached and synchronized on the client and, optionally, cached on the server. Much of the programming model is described by meta data, which affords administrators and end users a high level of control over deployed applications. > In one embodiment, the programming model can be folly supported within WebLogic Workshop of BEA Systems, San Jose, California — using Workshop's visual design tools and roundtrip development model, and enabling developers to leverage other WebLogic Platform components such as LiquidData, and Integration. Building mobilized solutions can as straight-forward as building Workshop Web applications and not require a specialist mobile team. The goal is a great mobile experience with great total cost of ownership from development, deployment, maintenance, to daily use. Figures 1A-B illustrates an overall system architecture 100 of one embodiment, which comprises a mobile browser 110, occasionally-connected application server 120 and external Web services 140. The occasionally-connected application server 120 (OCAS), such as a Mobile Application Server (MAS), can mediate exchanges of data between client applications running on the mobile browser and external systems accessed through Web services. This mechanism can have two stages: first, the OCAS 120 can coordinates the translation of data between external systems and the occasionally-connected data model; second, the OCAS 120 can coordinate synchronization between the client cache and the external Web services. One embodiment of the present invention is an occasionally-connected application server 120 for mobile clients 111. The occasionally-connected application server 120 can comprise memory to store a occasionally-connected data model 127, such as a mobile data mobile; and a cache 128 to store data nodes as defined by the occasionally-connected data model 127. The occasionally-connected application server 120 can cache data nodes in the cache 128 as indicated by metadata in the occasionally-connected data model. The occasionally-connected application server 120 can be software run on one or more machines. The occasionally-connected application server 120 can ran on top of or be a part of an application server. The occasionally-connected client 111 can be a personal digital assistant (PDA), phone, notebook computer or other mobile computing device. The clients can also include stationary computers especially those with intermittent contact with a server. The occasionally-connected application server 120 can translate data between external systems, such as web services 140, and data nodes defined by the occasionally-connected data model 127. One embodiment of the present invention is a system including an occasionally-connected application server 120. The occasionally-connected application server 120 can be configured to provide an application to a client. The application can allow a client to read and update application data without requiring current access to the occasionally-connected application server. The occasionally-connected application server 120 can be adapted to obtain application data from an external system to send to the client. The occasionally-connected application server can be adapted to translate data from the external system into data nodes. The external system can be a service bus, a web service or some other system. The occasionally-connected data model 127 can indicate the mobile client's anticipated usage of external data and obtain external data before it is requested by the mobile client 111. The data nodes can be independent chunks of data, such as XML data. The model data model 127 can include an XML definition, such as an XML schema or XML DTD, for the data nodes. One embodiment of the present invention is a system including an occasionally-connected application server 120. The occasionally-connected application server 120 can be configured to provide an application to a client. The application can allow a client to read and update application data without requiring current access to the occasionally-connected application server. The occasionally-connected application server 120 can be adapted to obtain application data from an external system to send to the client. The occasionally-connected application server can be adapted to translate data from the external system into data nodes. The external system can be a service bus, a web service or some other system. The mobile client 111 can transfer the data nodes and the occasionally-connected data model 115 to produce a display at the mobile client 111. An adaptive user interface server 126 can construct HTML pages from the data nodes in the cache 128 and the occasionally-connected data model 127 for clients 130. Clients 130 can include traditional web browsers that have consistent access to the server 120. The Adaptive UI Server 126 can provide a mechanism for running client applications on the server, enabling access from thin clients (e.g., ordinary Web browsers, SMS phones, etc.). The mobile client 111 can run an application using the data nodes and the occasionally-connected data model 115 without being in contact with the occasionally-connected application server 120. The data nodes in the cache 113 and occasionally-connected data model 115 can be used by a sync client 112 at mobile browser 110 to produce a display such as the HTML view 119. In one embodiment, templates can be used to produce the display at the mobile browser 110. The data nodes and occasionally-connected data model can be synchronized between the occasionally-connected application server 120 and the mobile client 111. This synchronization can be done in the background as a connection between the mobile client 111 and the occasionally-connected application server 120 is available. One embodiment of the present invention is an occasionally-connected application server 120 comprising a synchronization unit 131, such as a sync engine, to synchronize data nodes, such as data nodes in cache 128, with a client 111 for an application defined by the occasionally-connected data model; and a conduit manager 124 to translate between data from external systems and the data nodes defined by the occasionally-connected data model 127. One embodiment of the present invention is method comprising, at an occasionally-connected application server 120, storing an occasionally-connected data model 127 defining nodes and relations between nodes; and, at the occasionally-connected application server 120, caching data nodes as defined by the occasionally-connected data model 127. The occasionally-connected application server 120 can cache data nodes as indicated by metadata in the occasionally-connected data model 127. One embodiment of the present invention is an occasionally-connected application server 120 comprising a memory to store an occasionally-connected data model 127 and a cache 128 to store data nodes as defined by occasionally-connected data model 127. The data node including a primary key and a synchronization state. The primary key identifies the data mode. The data node can also include at least one secondary key. The synchronization state can be used to synchronize the data node with a mobile client. The occasionally-connected data model 127 can include an XML schema for the date node. One embodiment of the present invention is an occasionally-connected application server 120. The occasionally-connected application server 120 can include a memory to store an occasionally-connected data model 127, the occasionally-connected data model 127 can define nodes and relations between nodes, and a conduit manager 124 to translate between data from external systems and data nodes defined by the occasionally-connected data model 127. The conduit manager 124 can use conduits 137 which define transforms between data nodes defined by occasionally-connected data model 127 and data for requests and responses for a specific web service 140. The transforms can be contained as meta data. A request transform can include an XQuery function that creates outgoing message body. A response transform include an XQuery function that processes incoming response and creates data nodes defined by the occasionally-connected data model 127. One embodiment of the present invention is an occasionally-connected application server 120 for mobile clients 111 comprising a conduit manager 124 which evokes external web service 140 operations. The conduit manager 124 can uses conduits 137. The conduits can define transforms between data defined by an occasionally-connected data model and requests and responses for a specific web service 140. One embodiment of the present invention is a method comprising at an occasionally-connected application server 120, using conduits 137 to transform between data nodes in an occasionally-connected data model 127 and requests and responses for web services 140, the data nodes being XML data; and at the occasionally-connected application server 120, using the data nodes to provide data to a mobile client 111 for a mobile browser display. The data nodes can be transferred to the mobile client 111 for the display. One embodiment of the present invention is a mobile client 111 comprising data nodes, which can be stored in cache 113. The data nodes can be in the XML format. The data nodes at the mobile client can have an associated synchronization state. The synchronization state can indicate whether the data node has been synchronized with a server 120. The data nodes can be synchronized in the background as access to the server is made available and a display at the mobile client 111 is made using the data modes at the mobile client 111 without requiring current access to the server 120. The synchronization states can include an indications that the data node was locally created or modified; an indication that the data node was locally created or modified and ready for synchronization with server; and an indication that that the data node has a server synchronization is pending; an indication that the data node was synchronized with the server; and, an indication that that synchronization was rejected by the server; an indication that there was a conflict between a local modification and a server update. These and other synchronization states can be used to update data nodes at the client 111. The mobile client 111 can be transferred the data nodes and the occasionally-connected data model from the server 120 to produce a display at the mobile client. The mobile client 111 can run an application using the data nodes and the occasionally-connected data model 115 without being in current contact with a server. The synchronization of the data nodes between the server 120 and the mobile client 111 can be done in the background. One embodiment of the present invention is an occasionally-connected application server 120 comprising an occasionally-connected data model 115 defining node types and the relations between nodes; and data nodes. The data nodes can be in the XML format. The occasionally-connected application server 120 can pass synchronization states for the data nodes back and forth with the mobile client 111 to synchronize the data node. The data nodes can be synchronized in the background as access to the server is made available and a display at the mobile client 111 is made using data modes at the mobile client 111 without requiring current access to the server 120. One embodiment of the present invention is a method for synchronizing a mobile application on a mobile device. The method comprises displaying a first user interface on the mobile device, the first user interface derived from a template stored on the mobile device; receiving a first input from a user on the mobile device; updating a synchronization parameter in the mobile device; displaying a second user interface on the mobile device, the second user interface derived from a second template stored on the mobile device and selected based on the user input; and retrieving data from an application server, the data including one or more templates selected based on the synchronization parameter. One embodiment of the present invention is a mobile unit 111 comprising a local cache 113 of data nodes in the XML format, and an occasionally-connected data model 115 defining node types and the relations between nodes, wherein the mobile unit 111 uses the data nodes and the occasionally-connected data model to produce an application which is displayed at the mobile unit. A template 135 can be used for producing a interface for the data nodes at the mobile unit. One embodiment of the present invention is a mobile unit 110 comprising a local cache 128 of data nodes in the XML format; an occasionally-connected data model 115 defining node types and the relations between nodes; and actions that allow the modification of the data nodes. One embodiment of the present invention is a mobile unit 110 comprising a memory storing an occasionally-connected data model 115 and a local cache 113 of data modes as defined by the occasionally-connected data model 115. The data nodes including primary keys and synchronization states. In one embodiment at least one of the data modes includes a least one secondary key. The synchronization state can be used to synchronize the mode data with an occasionally-connected application server. The occasionally-connected data model 115 can include at least one XML schema for the data node. One embodiment of the present invention is an occasionally-connected application server 120 for mobile clients comprising a conduit manager to translate between external systems, such as web services 140, and an occasionally-connected data model 127. A cache 128 can be used to store data nodes as defined by the occasionally-connected data model 127; and adaptive user interface server 126. Some mobile clients 111 are transferred the data nodes and the occasionally-connected data model to produce a display at the mobile client 111 and other clients receive HTML pages from the occasionally-connected application server 120 which are constructed by the adaptive user interface server 126 using the data nodes and occasionally-connected data model. Clients 130 served by the adaptive user interface server 124 can have a traditional browser. Mobile clients 111 can have a special browser 110 that uses data nodes and the occasionally-connected data model to produce a display. One embodiment of the present invention is a method comprising at a server 120, storing data nodes as defined by an occasionally-connected data model 127 and the occasionally-connected data model 127; and transferring to some clients 111 the data nodes and the occasionally-connected data model so that the client can produce a display; and transferring to other clients 130 HTML pages constructed at the server from the data nodes and the occasionally-connected data model. One embodiment of the present invention is an occasionally-connected data model comprising nodetypes describing the structure of nodes. The nodes cazi be logically independent units of data; and keyref declarations that describe the relations between nodes. The nodes can include a root node. A variable can point to the root node. A mobile browser 110 can use data nodes and the occasionally-connected data model 115 to produce a display at a mobile unit 111. The occasionally-connected data model 115 can include a node graph. The node graph can indicate which data modes to cache. The nodetypes can include a XML definition, such as an XML schema, that is a complex type definition. The keyref declaration can define a key and key ref. The key can be a primary key. The keyref can be a foreign key definition referencing a primary key. The keyref definition can define legal traversals between nodes in a data graph. One embodiment of the present invention is an occasionally-connected data model comprising nodetypes which are an XML definition of nodes structure; and meta data, such as a keyref definition, that describes the relations between nodes. The nodes can be logically independent units of data. One embodiment of the present invention is a method for implementing a proxy, comprising mapping a web service operation to data within a programming model, such as an occasionally-connected data model, receiving a request regarding associated with the data; and initiating a invoke to a corresponding web service operation. One embodiment of the present invention is a mobile unit 111 comprising a local cache 113 of application data nodes, the data nodes being in the XML format, an occasionally-connected data model 115 defining node types and the relations between nodes; and a template 135 for producing an interface for the data nodes. The template 135 can be an XHTML template. The template 135 can use Spath expressions. The template 135 can access a current position in the occasionally-connected data model 115. A current variable can indicate the current position. In one embodiment, the template 135 does not modify the occasionally-connected data model. In one embodiment, the template 135 can invoke actions. Actions can modify data nodes. The actions can allow the modification of the data nodes without a connection to the server 120. The template 135 can be usable for multiple applications, each application having its own occasionally-connected data model and data node. The template 135 can be validated by a browser 11Q. Figures 11A-B are illustrations of a synchronization method of one embodiment of the present invention. In the example of Figure 11 A, the client 1102 includes a client version of "data node A" 1104. The client version of "data node A" 1104 has the sync state "ready for sync". The client version of "data node A" 1104 can include data constructed or modified at the client 1102. In the example of figure 11 A, there is no active connection between the client 1102 and the server 1108. The client version of "data node A" 1104 can be used by an application at the client without waiting for synchronization. The changes to "data node A" can be included in a message in message queue 1106 to be sent when a connection is available. The server 1108 has a server version of "data node B" 1110 which has not been sent to the client 1102. The server version of "data node B" 1110 can be constructed from data obtained from the "web service B" 1116. The conduit manager can use "conduit B" 1114 to translate response data from the "web service B" 1116 into the server version of "data node B" 1110. The "data node B" can be included in a message in message queue 1118 to be sent when a connection is available. Figure 11B show the situation when a connection is made available. The client version of "data node A" 1104 can be sent to the server 1108; and the client version of "data node A" 1104 can have its sync state set to "awaiting sync". The server 1108 can cache a server version of "data node A" 1111. The conduit manager 1112 can use "conduit A" 1115 to construct request data to send to "web service A" 1117. The client 1102 can store a client version of "data node B" 1105 obtained from the server 1108. The use of data nodes that are synchronized in the background with a server allow clients with intermittent connectivity to the server to run applications with the local version of the data nodes, and be updated as conductivity is made available. The following description gives one non-limiting implementation of one embodiment The discussion below gives one embodiment, but those skilled in the art will understand that other implementations of the above-described concepts can be done. Any potentially limiting language given below is to be interpreted in the context of the specific non-limiting implementation and is not meant to limit the general concepts. One embodiment of the present invention is a system for providing an occasionally connected access mechanism, comprising a browser 110. The browser 110 can be configured to be implemented on a mobile device 111 and provide a user interface to a user. The user interface can be derived from a template 135. An application server 120, the application server 120 configured to provide a persistent data store and receive and transmit information with the browser. In one embodiment, the Occasionally-connected application server 120 (MAS) runs on top or is a part of an application server, such as BEA Systems' WebLogic server. Occasionally-connected application server 120 contains a persistent data store to store application meta data, and a data cache 128 to optimize client requests. The Occasionally-connected application server 120 can be accessible to the mobile browser via a collection of Web based synchronization services, which can extend the SyncML standard. This enables different types of clients to leverage the MAS data model and synchronization capabilities. The Occasionally-connected application server 120 need not keep the full state of the client. Instead, the Occasionally-connected application server 120 can intelligently cache data based on meta data in the occasionally-connected data model 127. Additionally, the Occasionally-connected application server 120 can incorporates a dynamic content adaptation mechanism, known as the Adaptive Ul Server 126, that is capable of delivering mobile application functionality to thin clients (e.g., HTML Web site, WAP, SMS). hi one embodiment, the occasionally-connected data model can be a meta data description of the mobile application's anticipated usage of external data, and be optimized to enable the efficient traversal and synchronization of this data between occasionally connected devices and external systems. The occasionally-connected data model can be a relational model that describes nodes of data (or entities) associated with external services, and traversals (or relations) between them. For example, given a Web service that provides access to a Customer Relationship Management (CRM) application, the data model might have nodes for Accounts, Contacts, and Purchase Orders, etc., with traversals that let the application "navigate" from a given node (e.g., an Account) to all related nodes (e.g., Contacts and Purchase Orders). The occasionally-connected data model can be surfaced to the developer as a virtual XML document with a manifest variable, $root which points to the root node in the data model. Navigation to related nodes can be defined within the virtual XML document via keyref declarations. This enables a simple traversal syntax using a subset of XPath notation used hi ECMAScript for XML and known in this document as SPath. In addition, the mobile browser can always have as context, a current position within the data model (for example a particular customer or set of orders). The template and script can access this current position through another manifest variable $current. In one embodiment, the mobile browser 110 is, or includes, an extension of a Web browser that enables occasionally connected laptops and other devices to run applications regardless of whether they happen to be connected or offline. The browser can incorporates the same HTML renderer as current Web browsers, but also a user interface template and page flow mechanism, a data cache with intelligent synchronization capabilities, and an extended scripting language that provides access to the data cache. The mobile browser's user interface can consist of page templates. Templates can be XHTML pages with embedded bindings to cached data using SPath expressions. In one embodiment, Templates have no server side dependencies, so they can be rendered regardless of the status of the browser's network connection (i.e., online or offline). Templates can generate user interface events, which can be captured by a controller; the controller can call action scripts, which are able to modify the data in the client cache and determine page flow. The chont synchronization unit can automatically synchronize data accesses and changes with the Occasionally-connected application server 120. Applications can be provisioned to the mobile browser 110 by pointing to a URL, which references an XML application package implementing the client user interface and occasionally-connected data model for the application. The application can then be synchronized to the sync client 112. Furthermore, once an application has been deployed, application updates can be automatic and seamless. In one embodiment, the Adaptive UI Server 124 can be a proxy that runs the client application (templates, page flow, actions, etc.) for each active user. It can generate HTML pages (or SMS, etc.), which are sent to the browser 130, and the HTML pages can contain suitable hyperlinks that generate HTTP requests, which the adaptive server interprets into corresponding action calls. The adaptive server 126 can use the same synchronization mechanism as the mobile browser 110. Client applications can communicate with the server via synchronization. The synchronization process can trigger conduit requests to fetch new or more recent data, or to request client changes to be posted back to the external Web services 140. Conduits 137 can'contain meta-data that describes how to package the Web service requests and how to interpret their responses in the context of the data model. For example, supposing a client application modifies the rating code for a particular Account node (record) that is cached on the client; the synchronization mechanism can generate an update command that is sent to the server. If the client application then retrieves Contacts associated with the Account, and then adds a new Contact, then the synchronization mechanism can generate commands to fetch and add the corresponding data nodes. Conduits can describe how to invoke the various Web service operations required to implement each of these operations. The system can use standard Web services to exchange information with external data resources and business processes. The conduit mechanism can enable the Occasionally-connected application server 120 to call these operations to update the mobile data cache 128. Operations can act as getters and setters for a particular data type; a collection of operations can be managed by a conduit, which can act as an adapter. The conduit manager can coordinate synchronization requests from the OCAS's data cache, and conduit operations. Conduits can be the meta data used to associate Web services with three types of requested actions related to the data model: ? Navigating to related data; e.g. getting Contacts associated with an Account; ? CRUD operations; i.e., requests to create, read, update, and delete data; for example, creating a Contact related to an Account, updating the Contact details, or even requesting that the Contact be deleted; ? Custom operations, which are actions that need to take place in the enterprise related to some data, but are opaque to the data model; for example, requesting that a task be closed. The Conduit meta data can map the OCAS data model and synchronization commands to and from SOAP messages associated with the corresponding Web service operations. Conduit meta data can be defined using XML Query or XScript. A principal disadvantage of the current Web browser architecture with respect to mobility is the synchronous (blocking) request-response messaging protocol (i.e., HTTP). In the OCAS, messaging may be asynchronous. That is, user interface activity (e.g., browsing pages and modifying data) can run asynchronously with respect to the network connectivity and synchronization requests may run asynchronously with respect to the browser. FIG. 2 illustrates an exemplary asynchronous interaction between mobile browser 210, OCAS 220, and external Web services 230. The system implements reliable, ordered, message queues between the browser and the OCAS, and may use durable JMS queues between the OCAS and Web services (for asynchronous operation calls). If the browser is online, then sync messages can be enqueued and later sent to the OCAS. Otherwise, the synchronization unit can keep track of these events and generates sync messages whenever a connection is established. On the server, if the OCAS has cached data related to the client's synchronization request, then it can respond immediately. If the cache does not hold the appropriate data (or the data is stale) then the synchronization unit can call the conduit manager. The synchronization unit can then deliver the updated data to the browser. Since there may have been multiple conduits invoked for a particular sync request, the OCAS may deliver multiple sync messages to the browser. When a sync message is received by the browser, the local cache can be updated and an event sent to the controller. If data that is currently being displayed has been modified (i.e., data bound to the current template) then controller can cause the current page to be refreshed. That is, the page data bindings can be recomputed and the page incrementally redisplayed in the browser, without flickering or losing current user input, caret, or focus. OCAS applications can consist of client and server components. FIG. 3 illustrates the programming model 300 for an exemplary OCAS application. Programming model 300 includes mobile client 310, OCAS 320 and external system 330. In one embodiment, all communication to external systems (i.e., the enterprise) can be achieved via Web services (i.e., SOAP messages). The server programming model can comprise of a data model definition 3223 for each application, and a set of conduit definitions 324 that describe Web service operations. The data model consists of a set of XML Schema definitions that describe data types and relations. Conduit definitions contain XScript and XML Query (XQuery) functions that map incoming and outgoing SOAP messages onto the data model. The client programming model can comprise of the data model 311 (which is a copy of the model defined on the server), a set of XHTML templates 312, and a controller definition 313, which includes an XPF page flow definition and XScript actions and functions. The contents of the entire application can be described by a single XML file, which is used by the framework automatically to provision application components to the client In one embodiment, each OCAS application may have its own occasionally-connected data model. The occasionally-connected data model can describe the logical structure (and other properties) of the application data, as exposed by the back-end applications via Web services. The occasionally-connected data model can consists of nodetypes, which describe the nodes (or entities) in the data model, and keyrefs, which define the relationships between the nodetypes. The occasionally-connected data model can act as the lingua franca used by the other OCAS components to process data or to exchange data with each other. The actual design of an application's data model (which is done by the application designer) can take into account the anticipated usage of the data, so as to optimize both data access by the client applications and data synchronization between the server and occasionally connected devices. Additional meta-data can also be specified to make it easier for applications to display data-driven (i.e., automatic) user interfaces. In one embodiment, the occasionally-connected data model only describes the data; the OCAS assumes that all operational data is stored and managed (owned) by the external systems i.e., no operational data permanently resides in the OCAS. The occasionally-connected data model can be used to describe the data that may be cached both on the client and on the server and can be essentially a virtual cached view on top of data in the enterprise fetched through Web services. In one embodiment, within the occasionally-connected data model, there is a magic starting node, known as mas:root (referenced by $root in the programming model) from whence everything flows. From any node can be possible to access related nodes via traversals. Nodes can conform to XML Schema definitions (/schema/* .xsd). Traversals can also be defined by schema definitions, using keyref declarations. An automatic synchronization mechanism can coordinate changes between client and server data. Data can be retrieved and exchanged with external system via a mechanism known as conduits. Conduits can be configured by a set of conduit files (/conduit/* .jsx) that define conduit operations—XScript and XQuery functions that invoke and process the results from external Web service operations. Conduit operations can consist of a pair of XML Query functions associated with a given keyref; one function can format the outbound request to the appropriate Web service operation, the other can process the inbound response. Conduit operations can also define procedural logic in the associated XScript function. The occasionally-connected data model can represented as a data graph consisting of nodes and fraversals—analogous to entities (i.e., table rows) and relations (i.e., primary/foreign key fields) in a relational database. A node is a logically independent unit of data (or entity—for example, a customer, purchase order, or contact record) and can be represented as an XML data object, which is defined by an XML schema. Inside the data cache, each node can include a primary key, synchronization state (e.g., including a sequence number), and possibly, multiple foreign keys that reference other nodes. A nodetype can describe the information about a particular type of node; this can include an XML Schema definition, which describes the structure of the data nodes. A traversal can be a directional relationship between two nodes. Traversals can be primarily a mechanism for navigating from one node to a set of related nodes. For example, an Account may be associated with a set of Contacts and a set of Tasks, each of which may also be associated with a Contact. Relations between nodes can be defined by a keyref declaration. It can define both source and target nodetypes, and can include meta data to determine cardinality or the nodeset (e.g., exactly 1, 0 or more, 1 or more, etc.) The conduit manager's meta data can be associated with the keyref and determines whether or not nodes can be created, updated, linked, or removed. For example, the conduit's meta data determines whether or not there is a known Web service operation for inserting a Note about an Account or for updating an Account. A specific collection of nodes defined by a keyref can be called a nodeset. Data Nodes Data Nodes can contain structured data (i.e., an XML document), but can be atomic with respect to traversals; i.e. In one embodiment, a traversal represents a specific relationship between two nodes, but cannot reference data inside a particular node; nor can data inside a node reference another node. Often a single enterprise document may be made up of multiple nodetypes. For example, a purchase order may contain a sequence of line items (each with product references), and a customer reference. In this case, purchase order, line item, product and customer may all be represented as different nodetypes. la the case of these "composite" nodes, keyrefs within the data model can define cardinality; for example, a line item is associated with exactly one product. Conversely, depending on the needs of the application, a single purchase order nodetype might be defined to contain all of the above information in a single schema. The decision lies with the application designer—based on the need to independently link different nodes based on different traversals, collections and template requirements. For example, if line items are never linked or displayed outside of the purchase order then it might make sense to define a composite purchase order-line item nodetype. Relational Model The occasionally-connected data model can consist of schema and keyref declarations that are analogous to the relational entity and relation (primary/foreign key) constructs. Primary and Foreign Keys An example CRM system (referenced throughout this document for purposes of illustration) is implemented using a relational database. The Entity Relationship Diagram (ERD) 400 illustrated in FIG. 4 represents the account, contact, event, and user entities. The account, contact and user entities are defined by the following SQL. CREATE TABLE account ( pkey INT NOT NULL PRIMARY KEY, parentPkey INT FOREIGN KEY REFERENCES account(pkey), ownerPkey INT FOREIGN KEY REFERENCES user(pkey), name VARCHAR, type CHAR ) CREATE TABLE contact ( pkey INT NOT NULL PRIMARY KEY, accountPkey INT NOT NULL FOREIGN KEY REFERENCES account (pkey) , ownerPkey INT FOREIGN KEY REFERENCES user (pkey) , first VARCHAR, last VARCHAR, email VARCHAR ) CREATE TABLE user ( pkey INT NOT NULL PRIMARY KEY, login VARCHAR ) Both account and contact entities contain a foreign key reference to a user (owner); each contact entity defines a foreign key reference to an account. Also, each account has an optional foreign key referencing a parent account (i.e., accounts have sub accounts). Sample Queries Given the primary key of an account, pa, the following SQL selects all contacts: SELECT * FROM contact WHERE accountPkey = pa Given the primary key of a contact, pc, the following SQL selects the account: SELECT account.* FROM account, contact WHERE account, pkey = contact .accountPkey AND contact.pkey = pc However, given a full contact record, c, this simple SELECT query selects the corresponding account: SELECT * FROM account WHERE account.pkey * c.accountPkey Join Tables Suppose that events can belong to multiple accounts and contacts (e.g., a sales meeting with two accounts present). This would be modeled using a join table, for example: CREATE TABLE event ( pkey INT NOT NULL PRIMARY KEY, title VARCHAR, details VARCHAR ) CREATE TABLE event_account ( eventPkey INT FOREIGN KEY REFERENCES EVENT(pkey), accountPkey INT FOREIGN KEY REFERENCES ACCOUNT(pkey) ) Here, the many-to-many relationship is modeled by the event_account join table. Given the primary key of an account, pa, the following SQL G°in) selects all related events: SELECT event.* FROM event, event_account WHERE event_account.accountPkey = pa AND event.pkey = event_account.eventPkey Similarly, given the primary key of an event, pe, the following SQL selects all related accounts: SELECT account.* FROM account, event_account WHERE event_account .eventPkey ~ pe AND account.pkey = event_account.accountPkey XML Schemas XML Schemas can define the nodetypes in the data model used by the application. The schemas subdirectory may contain multiple .xsd files—all of which are loaded by the framework on start-up. Schema type definitions can consist of two parts: a complexType definition, which describes the type's structure and a meta data definition (using the mas namespace), which for example, defines how to construct a label for a particular type. For example, the following schema fragment defines the contact type. xmlns:xsd="http://www.w3 .org/2001/XMLSch.ema" xmlns :mas=" run :bea. com" xmlns="http://example.c6m/"> The following XML represents a contact element. KeyRef Basics The occasionally-connected data model can consist of standard XML Schema definitions for all application types. The schemas can define nodes that contain XML elements and attributes that are references to other XML nodes. The definition of these references can be made using key ref declarations. A keyref definition can consist of two parts: key and keyref. The key definitions can define the places in the document that contain primary keys. For example, the following key says that an accountKey occurs in each In one embodiment, a key may uniquely identify a single node. Keys may not be used to identify repeating elements within a node (e.g., if line items are defined within the schema for purchase order, then key definitions may not be used to define individual line items). The keyref definitions can define the places in the document that contain foreign keys; the refer attribute refers to an associated key definition. For example, the following keyref says that each contact contains an account attribute, which is a foreign key referencing the accountKey definition (above). There can be many keyref (foreign key) definitions referencing the same (primary) key definition. Type and Instance Diagrams UML is used to illustrate nodetype and keyref diagrams. FIG. 5 illustrates the UML Entity Relationship Diagram (ERD) 500 for the sample CRM application. In this diagram, each entity represents an application nodetype (i.e., schema). Note, the root entity is a system nodetypes The arcs represent relations (i.e., keyref definitions), where the black diamond represents the target nodetype of the source nodetype's foreign key. The star annotation represents a many-to-one relation. Each arc is labeled with the corresponding keyref s alias name. FIG. 6 illustrates a node instance diagram for the CRM use case. Namespaces An exemplary name space embodiment is given below. The server programming model can use namespaces to distinguish between framework and application XML elements. Namespace definitions can be included as attributes within the top-level element of an XML source file. Elements prefixed with the mas namespace represent system elements. xmlns :Tnas="urn:bea.*mas" By convention, elements prefixed with the app namespace prefix represent the application. xmlns:app="http://example.com/" Also, by convention (in this document), the ws namespace prefix is used to indicate elements defined by an example Web service definition (i.e., WDSL file); the sf dc prefix is used to indicate the SalesForce Web service. xmlns:ws="http: //www.openuri.org/" xmlns:sfdc="urn:partner.soap.sforce.com" Example The following label definition constructs a string from the contact's first and last name. The contact type already defines a primary key: The following key definition defines that the email element within the contact node may also be used as a key. The following keyref definitions define the two foreign key elements within the message node. 3 . .C! _1 J J-1- MM/ Note, the messageFromRef keyref could also be written as follows (although, the framework always uses the form above; note, the messageToRef must be written in the form above since there may be multiple The following key declaration defines the primary key for the purchase order nodetype. The following keyref declaration identifies the elements within the purchase order that are foreign keys referencing products. This relationship can be illustrated by figure 12A. For example, the following XScript expression retrieves the product referenced by the first line item of the purchase order. var product *= purchaseOrder.©©products.*; Many-to-Many Many-to-many relations are implemented as pairs of one-to-many relations. An example is given in figure 12B. I.e., account and event declare the following schemas: ocsd:attribute name="id" type="xsd:string" use="required" mas:type="pkey"/> And declare the following keyref definitions: In one embodiment, many-to-many keyrefs cannot declare inverse keyrefs since, in general, the framework would not have enough information to maintain consistency. One-to-One In one embodiment, one-to-one relations are implemented as paired many-to-one relations. Example Supposing each user of the system also has a contact record as shown in figure 12C. I.e., contact and user define the following keyrefs: One-to-one keyrefs should always declare an inverse keyref. var contact = user.©©contact; contact.©©user == user; System Data Types Node Schema Definition The following XML schema defines the structure of a'node. In one embodiment, for each application there is a special root node, which has the nodetype mas: root; this node does not contain application data and may not be modified. The framework automatically creates an instance of the root node, which is referenced via the $root variable. Keyrefs may reference mas: root as their source type, for example: In one embodiment, nodes may either be instantiated by a client programming or by server conduits. Nodeset Schema Definition Apart from the root node, all nodes belong to a nodeset, which corresponds to a keyref. A nodeset is defined by the following XML Schema: xmlns:xsd="http://www.w3.org/200l/XMLSchema" xmlns=:" run; bea. com" > otsd: element name="nodeSet"> he Synchronization States In one embodiment, client applications do not directly call Web service operations—instead the conduit mechanism maps the semantics of individual (constrained) Web service operations onto the programming model against the client's virtual XML document (e.g., CRUD semantics (create, read, update, delete), navigating, custom operations, etc.) Client data model changes are synchronized to the server, which then triggers the conduit manager to invoke the external Web service operations. In one embodiment, conduits define a coordinated set of Web service operations for a particular keyref. Each keyref can be associated with exactly one conduit. Web services may be interfaces to existing systems such as databases, LDAP directories, ERP applications, and Web sites. They may also be wrappers that abstract complex long running asynchronous processes (workflows) coordinated by procedural logic (e.g., WLIJPD). In one embodiment, although Web services used by the system may have certain requirements (e.g., each record must include a unique primary key, and ideally a sequence number or timestamp), there are no occasionally-connected data model specific requirements placed on them. Therefore, the MAS may be one of many consumers of these resources. In one embodiment, conduits do not assume that the Web sendee was written with the data model in mind; that is, the types passed into the request may not be isomorphic to the nodetypes in the data model, and the responses may also be different. Therefore, the schema used by the Web service request and response do not need to be the same as the schema for any of the nodes in the data model. Conduits can contain metadata to map from the data model into the request document for the Web service operation invocation, and to map from the Web service response back into the data model. These nieta data are known as transforms, and can be expressed in the XML Query language. Indeed, the transform model is general enough that a Web service may return a response document that maps to several different related nodes in the data model and still successfully map back into the data model. Meta data that is crucial to the MAS cache (i.e., the record type's primary key and sequence number/timestamp) can also mapped using transforms. Conduit File Overview The conduits subdirectory may contain multiple . j sx files—all of which are loaded by the framework on start-up; these files contain conduit definitions. Conduit files can consist of XScript and XQuery functions that implement conduit operations; these files can also contain meta data defined in comment blocks. The annotations model enables the developer to use both visual tools and script editors to build conduit files. Each conduit file can contain a header comment that may declare the The conduit file also contains (possibly multiple) object declarations that represent Web service controls. Control definitions appear in the header block immediately before the corresponding variable declaration. Example mas:transform Declares associates request and response transforms. mas:namespace Declares the default namespace for the function, mas:field Declares custom source fields that are required to 1 call the function, mas:operation The mas: operation tag has the following attributes: Attribute Description type Operation type (e.g., "select", "insert", "update", etc. ) keyref Keyref name that defines select relation. inverse If true, then implements the inverse keyref definition- node | Nodetype for insert/update/delete operations. Operations can reference either a keyref or schema (node) definition. ©mas : opex~ation type=" operationType" keyref ~" keyref Name" @mas:operation type="operationType" node="nodeType" The inverse attribute indicates that the operation is called on the inverse keyref. ®mas:operation type="operationType" keyref *="keyrefName" inverse="true" For example, given the following keyref and key definitions: The conduit can implement the following select operations: /** ©mas:operation type="select" keyref="app:contactAccountRef" */ function selectAccount($msg, $source) { return ws.invoke($msg); } /** ©mas:operation type="select" keyref=uapp:contactAccountRef" inverse="true" V funciton selectContacts($msg, $source) { return ws.invoke($msg) ; } The traversal contact. ©©account would call selectAccount (), while account .©©contacts . * would call selectContacts (). mas:transform The mas: transform tag has the following attributes: For an insert, update, and delete operations, the default body can be as follows: I'** * @mas:operation type="insert |update (delete" keyref ~"keyrefNajneu */ - function operatioi2TypeSourceType{$msg, $node) { return ws.invoke($msg); } The $node variable contains the node to be inserted/updated/deleted. For a custom operation, the body can be as follows: /** * @mas;operation type="custom" node="node.Wajne" name="qperationName" */ function opera tionT}speSourceType{$msg, $ source, $node) { return ws. invoke ($msg) ,-} Here, the $node variable contains the query object created by the client calling the custom operation. Transforms Operations may optionally define request and response transform functions using the mas: transform annotations. For example, the following operation implements the select operation that retrieves contacts given an account identifiers (i.e., the inverse keyref defined by contactAccountRef): /** * select contacts for an account: $account.©©contacts.* * @mas:operation type="select" keyref="app:contactAccountRefn inverse="true" * ©mas:transform type="reguest" function«MselectContacts_request" * @mas:transform type="response" function="selectContacts__responseu */ function selectContacts ($msg, $source) { return ws.invoke{$msg); } The request transform can be called before the conduit operation is invoked; it returns the XML body of the outbound message, which is inserted into the message object, $msg, passed to the conduit operation. /** * ©mas:namespace target="sfdc" * ©language:body type="xguery" */ function selectContacts_request($source) { SELECT * FROM Contact WHERE Accountld * "{string($source/@id)}" } The response transform can be called after the conduit operation returns (unless the operation returns an transform returns a list of application nodes to the conduit manager. /** * ©mas:namespace fcarget="app" * ©language:body type^'xguery" */ function selectContacts__response ($respQnse) { for $i in $response/sfdc:queryResponse/sfdc:result/sfdc: records return ) Note, the conduit operation is able to manipulate the header and body of the service response message before the body is processed by the response transform. Conduit Operations Conduit operations can map Web service operations onto framework operations that are exposed to the application programming model. Each operation can defines a pair of queries that map the corresponding incoming and outgoing XML messages received from and sent to the associated Web service operation. These transforms consist (typically) of XQuery expressions that translate data from the external system data format, to the MAS application data format defined by the schemas. Operation Types In the client programming model, operations can be invoked either on nodes (including $root), or on keyrefs. For example: $root.create{xml}; // create node node.@@Jceyref .create (xml); // create and link node node.@@keyref.*; // implicit select node.QQkeyref .select (spath); II deep select node.update () ; // update node $root. foo(jonl) ; // custom operation Depending on the operation type, different input parameters are required to be passed to the conduit operation. Except for update and delete, all other operations are passed (part of) the node that represents the context (or source) of the operation (the mas:field declaration determines how much of the source node is transferred to the server). This is referenced by the conduit functions using the $ source variable. In the case of update operations (i.e., insert, update, and custom operations), the data node used to invoke the conduit operation is referenced in the XQuery transform using the $node variable. In addition, all operations have implicit access to the $user system variable, which contains information about the current user. [0100] Each conduit operation may define a pair of queries (transforms) that create and process XML objects corresponding to incoming and outgoing XML messages received from and sent to the associated Web service operation. Transform functions can be declared using the mas: transform annotation on the corresponding conduit function. By convention transform function names can use the same name as the conduit function with the _request and _response suffixes. However, in some cases, response transforms may be reused by multiple conduit operations. Transforms can be implemented as XQuery (XML Query) functions. Example The following operation implements the select operation that retrieves contacts given an account identifier (i.e., the inverse keyref defined by contactAccountRef): /** * select contacts for an account: $account .©©contacts. * * ®mas:operation type="select" keyref="app:contactAccountRef" inverse-"true" * ©mas:transform type="request" function="selectContacts_request" * ©mas:transform type="response" function="selectContacts_response" */ function selectContacts($msg, $source) { return ws.invoke($msg); } * ©mas:namespace target="s£dc" * ©language:body type="xquery" */ function selectContacts_reguest($source) { SELECT * FROM Contact WHERE Accountld - "{string($source/@id)}" } /** * ©mas•.namespace target="app" * ©language:body type="xquery" */ function selectContacts_response($response) { for $i in $response/sfdc:queryResponse/sfdc:result/sfdc:records return The request transform can construct the body of the SOAP message that invokes the query Web service operation. The response transform processes the body of the Web service operation's response SOAP message and constructs a set of Request Transforms The request transform can create the outgoing Web service message from framework and data model elements. Depending on the operation type (see operations table above) the transform can reference the following syst&m service operation, which expects a SOAP message with a body that conforms to the following XML Schema definition. ^element name="query"> The following transform references the $source system variable to specify the Accountid foreign key required for the query. /** * @mas:namespace target="sfdc" * ©language;body type=nxquery" * @mas:namespace target=Hsfdc" */ function selectContacts_request{$source) { SELECT * FROM Contact WHERE Accountid « "{string($source/@id))" For example, this might generate the following outgoing SOAP message body; For example, an incoming SOAP message body might be in the following form: The $response system variable points to the top-level $response/sf dc: crueryftesponse/sf dc: result/sf dc: records The following transform processes the incoming SOAP message and creates a list of * @mas:namespace target="app" * ©language:body type="xquery" */ function selectContacts_response(^response) { for $i in $response/sfdc:queryResponse/sfdc: result/sf dc: records return All request transforms generate nodes, which may be cached by the server, and synchronized with the client's data model. Permissions The operations defined by a conduit determine the operations that may be invoked on corresponding nodesets on the client. For example, if the conduit does not define an insert operation, then the client cannot attempt to create and insert a node for the corresponding nodeset—if it attempts to do so (e.g., in a custom action) this will trigger a runtime error. The client side programming model will enforce these constraints. For example, suppose account is pointing to a particular account node, and that account nodes are associated with the orders keyref. In this case, unless there is a defined conduit insert operation associated with the orders keyref, then the following code would case an error. account.©quotes.create{ ) ; Similarly, unless the update operation is defined for the contact nodetype, then the following code would also cause a error. contact.address.zip = "11201"; In one embodiment, the implementation of client operations (e.g., the createO function) are matched with conduit operations (e.g., insert). For example, the conduit operation, insert, both inserts a node and traversals it to another node using a keyref relationship; therefore the creation of a node on the client must be atomically paired with a traversal operation to a corresponding nodeset. The meta data describing implemented conduit operations is accessible to the user programming model (via the associated keyref). The automatic user interface is able to use this information to generate basic menus (insert, update. etc.) Error Handling The conduit mechanism distinguishes between two kinds of errors: system errors (e.g., protocol and transport errors), and application errors (e.g., invalid data). Furthermore, application errors can be raised in two different ways: as a SOAP fault (i.e., protocol level error), and as part of the SOAP (or plain XML) response message. there is an error in the processing of a message; this can be either due to an infrastructural failure (e.g., transport failure), a protocol failure (e.g., badly formed message), or an application state error (e.g., update failed). System errors arise if there is an error creating or processing the outgoing or incoming SOAP message (e.g., XQuery transform error). Application errors arise if the external application rejects an operation request based on the values that are passed as part of the message body (e.g., update failed). SOAP faults are raised by the SOAP stack during the invocation of the invoke () function on the Web service control Normally the body of the XML object returned by the conduit operation is processed by the response transform. However, if the operation returns a system The I.e., the error-code error-code Each error object may contain the primary key of the node affected by the error. For select operations, this will be the source node's primary key; for update and delete operations this will reference the updated node. System errors can be logged by the server. All other error values can be returned to the client and passed to the corresponding callback function. An error object is returned to the application's callback function; this object has properties corresponding to the schema above. Examples The following operation returns a system error if the invoke () function invocation returns an error. /** * @mas:operation type="select" keyref= n keyref Name" */ function operationTypeSourceType($msg, $source) { var response = control.invoke{$msg); if (response.error) { return } return response; } Where appropriate, it can be the responsibility of the conduit operation to retry failed invoke () invocations. In this case, the conduit has to ensure that the Web service operation either is idempotent, or that some form of reliable messaging is employed. The following operation returns a system error after retrying the invoke {) function on failure. /** * ®mas:operation type="select" keyref= n keyref Name" */ function operationTypeSourceType ($msg, $ source) { for (i=0; i var response = control.invoke($rasg); if (!response.error) { return response; //OK } . . .. } return } The following operation first checks for a system error if the invoke 0 function returns an error, otherwise it returns a general application error. If invoke () succeeds, but the Web service response includes application errors, then it calls a utility function to parse the error message and returns a compound * @mas: operation type-^'create" keyref=r,,./ceyre.f.NaJne,, */ function operationTypeSourcerj'pe($msg, $source) { var response = control.invoke($msg); if (response.error) { if (response.error.code == 101) { return } else { return } } // check for application errors if (response.body.createResponse.result.errors) { return process_error(response.body.createResponse.result.errors); ) return response; //OK ) // utility function to process field errors function process_error(errors) { var fields; for (i=0; i {$i/statusCode} } return CRUD Operations CRUD (Create Read Update Delete) operations represent the four basic relational data operations. These operations can map directly onto the MAS data model and client programming model. Note, the Web service's contact schema has a different shape from the application's contact schema defined above. The select operation examples below illustrates how this mapping is achieved. Select The select operation can enable the framework to retrieve nodes defined by a keyref for a particular source node. Typically, all conduits define a select operation since this is the basic mechanism used to retrieve nodes by the client application. Subsequent select operations (for different keyrefs) can be invoked to construct the data graph. For example, navigating from an account node to the purchase orders keyref invokes the getPurchaseOrders operation of the AccountManager Web service; then, navigating from a purchase order node to the line items keyref will call the getLineitems operation of the orderManager Web service. Select operations have the following form: /** * ®mas -. operation type= "select" keyref="keyrefName" [inverse^"true" 3 * ©mas: transform type="request" function-" furic tionName_request" * @mas:transform .type^'response" function="func,tionName_respo.nse" */ function functionWame($msg/ $source) { return ws.invoke($msg); } Select operations are used to retrieve nodes corresponding to the keyrefName defined for a particular source nodetype; e.g., selecting the account referenced by ihe foreign key for a particular contact node. The inverse attribute defines that the operation implements the reverse relation; e.g., selecting all contacts that reference a particular account by via a foreign key. Keyref definitions can have the following form: In relational terms, the select operation corresponds to the following SQL expression: SELECT * FROM keyref.targetType WHERE primaryjcey = $source/foreign_key An operation implementing the inverse keyref corresponds to the following SQL expression: SELECT * FROM keyref. sourceType WHERE foreignJeey = $source/primary_key ©language:body type^'xquery" * ©mas:namespace target="sfdc" * ©raas:field xpath="©accountId" */ functipn..fieJLectAccoiintByContact_request ($source) { SELECT * FROM Account WHERE Id = {string($source/©accountId) ) } /** * ©language:body type="xguery" * ©mas:namespace target="app" */ function selectAccountByContact_response ($response) { let $i := $response/sfdc:queryResponse/sfdc:result/sfdc:records return * ©mas : transform tvne=MreRnr>nsA" fimrsi- i OTI—« ggO g»r'i-&r'l-»viTii-pyp^ritac* response " */ function selectAccountByContact($msg, $source) { return ws.invoke($msg); } Request Transform The request transform can reference the $ source variable that represents the account node. The function annotations can declare the language (XQuery) and target namespace of the outgoing message document (referencing a namespace prefix declared in the conduit file's header annotation). The function can also declares a field annotation indicating that the ©accountid attribute of the contact node is required by the function; this declaration can ensure that the foreign key value is sent from the invoking client to the server as part of the synchronization request. /** * ©language:body type="xquery" * (annas : namespace target="sfdc" * ©mas:field xpath="©accountId" */ function selectAccountByContact_request($source) { SELECT * FROM Account WHERE Id = {string{$source/@accountId)) ) Response Transform The response transform can reference the $ response variable that represents the XML body of the message returned from the Web service. The function annotations can also declare the language (XQuery) and the target namespace of the XML object returned to the conduit manager. The function can assume that a single record is returned by the Web service number). /** * ©language:body type="xquery" * ®mas:namespace target="app,t */ function selectOwnerByAccount_response($response) { let $i := $response/sfdc:gueryResponse/sfdc:result/sfdc:records return This time, however, the mas:inverseAiias attribute of the keyref definition is used to traverse the keyref in the reverse direction: var contacts = account.©©contacts.* ; The following conduit operation implements this inverse keyref relation: /** * ©mas:operation type="select" keyref="contactAccountRef" inverse="true" * @mas:transform type="request" function="selectCqntactsByAccount_request" * ©mas:transform type="response" functions"selectContactsByAccount_response" */ function selectContactsByAccount{$msg, $source) { return ws.invoke($msg); } /** * ©language:body type="xquery" * ®mas:namespace target="sfdc" * ©mas:field xpath="@id" */ function selectContactsByAccount_request($source) { SELECT * FROM Contact WHERE accountld = {string($source/@id)} } /** * ©language:body type="xquery" * ©mas:namespace target="app" */ function selectContactsByAccount_response ($response) ( for $i := $response/sfdc:queryResponse/sfdc:result/sfdc:records return The conduit operation function can be auto generated by the platform; it references the accountownerRef keyref definition and has declarations (generated by tools) to the request and response transform functions. The operation also declares that it represents the inverse keyref relationship. /** * ©mas:operation type="selectH keyref="contactAccountRef" inverse^"true" * ©mas:transform type="request" function="selectContactsByAccount_requestn * ©mas :transf orm type="response" function=,,selectCon.tactsByAccount_response" */ function selectContactsByAccount($msg, $source) { return ws.invoke($msg}; ) Request Transform The request transform can reference the $ source variable that represents the contact node. The function annotations declare the language (XQuery) and target namespace of the outgoing message document (referencing a namespace prefix declared in the conduit file's header annotation). The function can also declare a field annotation indicating that the ©id attribute of the account node is required by the function; this declaration can ensure that the foreign key value is sent from the invoking client to the server as part of the synchronization request. /** * ©language:body type="xquery" * ©mas:namespace target="sfdc" * @mas:field xpath="@id" */ function selectContactsByAccount_reguest($source) { SELECT * FROM Contact WHERE accountld = {string($source/@id)} } Response Transform The response transform can reference the $ response variable that represents the XML body of the message returned from the Web service. The function annotations can also declare the language (XQuery) and the target namespace of the XML object returned to the conduit manager. The function can assume that multiple records are returned by the Web sendee * ©language:body type="xquery" * ©mas:namespace target="app" */ function selectContactsByAccount_response($response) { for $i := $response/sfdc:queryResponse/sfdc:result/sfdc: records return ^contact id="{string{$i/sfdc:Id) }" accountId="{string($i/sfdc:Accountld)}"> The Non-Relational (Context Free) Selects It is possible to define relations between nodes that do not depend on foreign key values. For example, a set of nodes may be defined by a query that uses the current user's information, or other external information (e.g., time of day, real time data, external system state). In these cases, the nodeset may be attached to arbitrary nodetypes within the data model. Typically, however, these nodesets are attached to the root node. Conduit select operations can reference a keyref definition; since context-free selects, by definition, do not require the context of the source node, in one embodiment, they are always implemented on inverse keyrefs. The following example illustrates how, in the CRM demo, the set of accounts for the current users is retrieved by a conduit select operation. The account nodetype has the following key definition. The mas:alias attribute indicates that the nodeset of accounts is traversable from the root node; i.e., var accounts = $root.©©accounts.*; The conduit can be implemented in the same way as the inverse keyref select operation (above). /** * @mas:operation type="select" key^'accountKey" inverse="true" * ®mas:transform type="request" function="selectAccounts_request" * @mas: transform type="response" functions"selectAccounts_response" "/ function selectAccounts($msg, $source) { return ws.invoke($msg); } * ©language:body type="xquery" * ©mas:namespace target="sfdc" V function selectAccounts_request{$source) { SELECT *.Account FROM Account, User WHERE User.Alias = {string($user/useraame)} AND User.Id = Account.OwnerId } /** * ©language :body type="xquery,l * ©mas:namespace target="appw */ function selectAccounts_response($response) { for $i := $response/sfdc:queryResponse/sfdc:result/sfdc:records return Request Transform The request transform can reference the $user system variable, which is used to construct the request query sent to the Web service. * ©language:body type="xquery" * @mas:namespace target="sfdc" */ function selectAccounts_request($source) { SELECT *.Account FROM Account, User WHERE User.Alias = {string($user/username)) AND User.Id = Account.Ownerld } In this case, the service can implement a join query that selects all accounts that are owned by the current user (i.e., have an ownerid foreign key that matches the ID of the current user). Note, the transform does not reference the $ source variable. Response Transform The response transform can process the set of accounts returned by the Web service operation in the same way as the response transforms defined in previous sections. * ©language:body type="xguery" * ®mas:name space t arget ="app" */ function selectAccounts_response($response) { for $i := $response/sfdc:gueryResponse/sfdc:result/sfdc:records return Note, the ©mas: root id attribute can be automatically computed by the conduit manager when the set of Insert Insert operations can be called by the conduit manager when a client application synchronizes newly created nodes to the server. On the client, nodes can be created in one of two ways; i.e., the create () function can either be called on a keyref or on the root node: var node = source. ®@keyref. create ( var node = $root.create( hi both cases, just the node's XML object can be transferred to the server (i.e., not the source node). This is because in the case of a contextual create operation, the node must contain a foreign key value that references the source node; this value is set automatically by the framework based on the keyref definition. Insert operations have the following form: /** * @mas:operation type="insert" node="i2odeName" * ©mas: transform type="request" function="functionName_reguest" * @mas:transform types="response" function^"functionName_responsen */ function functionName($msg, $source) { return ws.invoke($msg); } Insert operations can be used to create nodes corresponding to the schema referenced by the nodeName declaration. The insert operation's request transform creates the message body for the Web service operation; it can reference the following system variables, which The node's primary key (and, optionally, sequence number) can be returned to the conduit manager, which synchronizes this information back to the client. Nodes are initially created on the client with a temporary primary key; this value must be replaced by the external system's primary key. Nodes typically include foreign key values that reference other nodes. If multiple nodes are created on the client that reference each other, then the system has to ensure that the insert conduit operations are called in the appropriate dependency order, and that primary key values returned from the Web service are used to replace temporary foreign key values for pending nodes. Non-Relational Inserts In one embodiment, non-relational insert operations do not have foreign keys that reference other nodetypes within the data mode. For example, the user nodetype can be defined by the following schema: Suppose an administration application was able to create new users for the system; the client code to do this might be as follows: $root . create ( In one embodiment, this would require the following insert conduit operation: * @mas:operation type="insert" node="app:user" * ®mas:transform type="request" function="insertUser_request" * ®mas:transform type="response" function="insertUser_response" */ function insertUser($msg, $node) { return ws.invoke($msg); } /** * ©language:body type="xquery" * ©mas:namespace target=,rsfdc" */ function insertUser_reguest($node) { } /** * ©language:body type=nxquery" * ©tnas: namespace targets"app" */ function insertUser_response($response) { Request Transform The request transform can reference the $node variable that represents the user node created by the application. The function annotations canf declare the language (XQuery) and target namespace of the outgoing message document (referencing a namespace prefix declared in the conduit file's header annotation). /** * ©language:body type="xquery" * ©mas:namespace target^'sfdc" */ function insertUser_request ($node) { The transform can create a partially constructed the primary key attribute (id) defined by the application's schema. /** * ©language:body type="xguery" * @mas:namespace target="app" */ function insertUser_response($reaponse) { } This primary key value can be processed by the conduit manager and synchronized with the client application. Relational Inserts Relational inserts can involve nodes that contain foreign key values that reference other nodes within the cache. For example, the contact schema, below, defines foreign keys for an owner node (©ownend) and account node (@accountid). Initially, the contact XML object may be constructed by an XScript assignment: var contact = Nodes that contain foreign keys may be created in a number of ways. Given the contact XML object above, and variables representing owner and contact nodes, the following function creates a contact node by calling the create () function on the root node. Note, foreign keys must be set before create () is called. function createContactl(account, owner, contact) { contact.©©account = account; contact.©©owner = owner; return $root.create(contact); } However, the following functions achieve the same goal: function createContact2(account, owner, contact) { contact.©©owner = owner; return account.©©contacts.create(contact) } function createContact3(account, owner, contact) ( contact.©©account = account; return owner.©©contact = contact; } Note in both of these cases, the missing foreign key value is supplied by the framework before the node is synchronized to the server. Therefore, regardless of how the node is created by the application, the conduit operation need only be bound to the nodetype. The conduit operation can be implemented in the same way as the operation defined in the previous section: /** * @mas:operation type="insert" node="app:contact" * ®mas:transform type="requestM function="insertContact—request" A ©mas:transform type="response" function*"insertContact_response" */ function insertContact($msg, $node) { return ws.invoke($msg); ) * ©mas:namespace target="sfdc" * ©language:body type="xquery" */ function insertContact_request($node) { ) /** * ©mas:namespace target="app" * ©language:body type="xcfuery" */ function insertContact_response($response) { This primary key value returned by the response transform can be processed by the conduit manager and synchronized with the client application. This value replaces the temporary primary key assigned by the application when the node was first created. However, in one embodiment, if multiple nodes that reference each other are created by the application, then primary key values returned by the server must also be used to update foreign key values of nodes that reference newly inserted nodes. For example, the following function first creates an owner node, then creates a contact node that references it. function createContact4(account) { var owner ~ $root.create( var contact = contact.©©owner = owner; return account.create(contact); } The conduit insert operation for the user node is called before the conduit insert operation for the contact node, and that the contact node's ownerid attribute contains the appropriate foreign key value returned from the first conduit operation. Sequence Numbers In some cases the Web service method that is called to create a node may not return a sequence number. The conduit is able to make multiple Web service calls within a single conduit operation to retrieve this information. For example, the conduit operation defined in the previous section is extended below: * @mas:operation type="insert" node="app:contact" * ®mas:transform type="request" function*"insertContact_request" * ©mas:transform type="response" function="insertContact_response" */ function insertContact($msg, $source) { var response = ws.invoke($msg); var id = response.sfdc:createResponse.sfdc:result.sfdc:id; // retrieve sequence number var msg2 = createMessage(requestTimestamp(id)); var response2 = ws* invoke(msg2) ; // return both responses response.body += response2 .body .sfdc:query-Response; return response; } /** * ©language:body type=nxquery" * ®mas:namespace target="sfdc" */ function requestTimestamp($id) { SELECT Id, SystemModstamp FROM Contact WHERE Id * "($id)" } /** * ©language:body type="xquery" * ©mas:namespace target="sfdc" */ function insertContact_request($node) { } /** * ©language:body type^xquery" * ©mas:namespace target="app" */ function insertContact_response ($response) { {string ($response/sfdc -.queryResponse/sfdc:records/sfdc: SystemModstamp) } } Request Transform The request transform can create the same Web service message as defined in the previous section: * ©language:body type="xguery" * ©mas-.namespace target=nsfdc" */ function insertContact_request($node) { } Conduit Function However, in this case, the conduit's auto generated XScript function can be modified to invoke two Web service calls. First, the message returned from the request transform can be used to insert the node and to retrieve the inserted node's primary key. /** * @mas:operation type="insert" node="app:contact" * ©mas:transform type»Mrequest" function="insertContact_requestH * ©mas .-transform type=?" response" function="insertContact_response" */ function insertContact($msg, $source) { var response » ws.invoke($msg); var id = response . sfddcreateResponse . sfdc : result. sfdc: id; Next, a new message object is created by passing the inserted node's primary key, id, into a helper XQuery function, requestTimestamp (), defined in the conduit. // retrieve sequence number var msg2 = createMessage(requestTimestamp(id)); var response2 = ws.invoke(msg2); Helper functions declare the same language and namespace annotations as transforms, however they are not referenced by the conduit operation's annotation. The function constructs the appropriate message to invoke a conduit operation to return the sequence number for the newly created node: * ©language:body type="xquery" * ®mas:namespace target="sfdc" */ function requestTimestamp($id) { SELECT Id, SystemModstamp FROM Contact WHERE Id = »{$id}" } Finally, the results of both Web service operations can be combined by creating a single XML object composed of both message bodies: // return both responses response.body += response2.body.sfdc:queryResponse; return response; } Response Transform The response transform can processe the XML object created by the conduit function and returns a single node containing both the primary key and the sequence number of the node. * ©language:body type="xgueryr * ®mas:namespace target="app" */ function insertContact_response($response) { {string($response/sfdc:queryResponse/sfdc:records/sfdc:SystemModstamp)} } Update Update operations can be called by the conduit manager when a client application modified a node. When the enterprise is requested to update data, it is possible that it will refuse—either because there is a policy/process that denies it or because someone else changed the data first. The first problem is unavoidable and requires that the update operation, like all others, can handle failures. The framework can implement an optimistic concurrency model for the second case. When an update request is sent to a Web service operation it can include not only the changed values, but a sequence number that can be used to determine whether the record was up-to-date when it was modified. (The conduit manager cab compute an MD5 hash based on the nodes values if the Web service on the select operation doesn't return its own sequence number.) On the client, nodes can be modified by script expressions, however, updates are not synchronized to the server until the update () function is called on a particular node; for example: function modify(contact, address) { contact .email *= address; contact.update() ; } In one embodiment, neither client applications nor update operations may modify key values (i.e., any field described by key definitions). ©language:body type="xguery" * ©mas: namespace target="sfdc" V function updateContact_request($node) { */ function updateContact_response($response) { let $i := $response/sfdc:queryResponse/sfdc:result/sfdc:r-ecords return } Request Transform The request transform can create the Web service message used to invoke the update operation: /** * ©language:body type="xquery" * ®mas:namespace target="sfdc" */ function updateContact_reguest($node) { } The request transform can be passed in the node's primary key and an element, LastModif iedDate, that represents the timestamp when the record was retrieved from the service. This enables the Web service operation to implement optimistic concurrency; i.e., if the timestamp value sent to the operation does not match the current system timestamp value, then the operation fails. Conduit Function As with the insert operation, the conduit's auto generated XScript function can be modified to invoke two Web service calls. First, the message returned from the request transform is used to update the node. /** * ®mas:operation type="update" node="app:contact" * ©mas:transform type="request" function="updateContact_request" * ©mas:transform type="response" function="updateContact_response" */ function updateContact {$msg, $source) { ws.invoke($msg); Next, a new message object can be created by passing the updated node's primary key, id, into a helper XQuery function, re quest Time stamp (), defined in the conduit (this is the same function defined for the insert operation above). // retrieve sequence number var msg2 = createMessage(reguestTimestamp(id)) ; var response2 = ws.invoke(msg2); Finally, the result of the second Web sendee operation can be returned to be processed by the response transform. return response2; } Response Transform The response transform can process the XML object created by the conduit function and returns a single and the sequence number of the node. /** * ©language:body type="xquery" * @mas:namespace target="app" */ function updateContact_response($response) { let $i := $response/sfdc:queryResponse/sfdc:result/sfdc:records return Conflict Management Node conflicts can occur when a client tries to modify and synchronize a "stale" node that has already been updated (either by another client or other exogenous change process) in the external system. A stale node is one that has a different sequence number than the current sequence number held by the server. If the MAS has cached a more recent version of the node than the one the client is trying to update, then it may respond directly with the updated node (i.e., without invoking the conduit operation), setting the mas: state attribute to "conflict". If the conduit operation rejects the update because the node is stale, then can return an up-to-date node with the appropriate mas: state attribute; this may involve another round-trip to select the up-to-date node. Example The following update operation function checks for an error value returned by the Web service. The request transform is the same as is defined above. /** * ©mas:operation type="update" node="app:contact" * ®mas:transform type="request" functions"updateContact_request" * ©mas:transform type=Hresponse" function="updateContact_responseu */ function updateContact($msg, $source) { var response = ws.invoke($msg); // check for error if (I response-body.sfdc:updateResponse.sfdc:result.sfdc:success) { // retrieve server's record msg = createMessage(selectContact_reguest ($source/@id)); response = ws. invoke (msg) ; // set state expando var node = response.body .sfdc: query-Response, sfdc: result. sfdc: records ; node.@state="conflict"; } else ( // retrieve sequence number msg * createMessage (requestTimestamp($source/@id)) ; response = ws. invoke (msg) ; } return response; } /** * ©language:body ltype=,lxquery" * ©mas:namespace targets"appM */ function updateContact_response ($responseJ { let $i := $response/sfdc:queryResponse/sfdc:result/sfdc:records if ($i.@l= null) then Conduit Function The conduit function can first check for an error value returned by the Web service. function updateContact{$msg, $source) { var response = ws.invoke($msg) ; // check for error if (! response, body. sfdc:updateResponse.sfdc : result .sfdc : success) { If an error is returned, then the function can send a request query to the Web sendee for the entire node; here, the operation reuses the context free select operation's request transform: // retrieve server's record msg = createMessage (selectContact_request ($source/@id)) ; response = ws.invoke (msg) ; The operation then created an expando state attribute so that the response transform can detect that the conflict record has been retrieved from the server. // set state expando var node ^ response.body. sfdc :query-Response . sfdc-.result. sfdc :records; node.@state="conflict" ; If the original Web service method succeed then the function just requests just the updated sequence number (as above). // retrieve sequence number msg = createMessage(requestTimestamp($source/@id)); response = ws . invoke (msg) ; Regardless of whether the update succeeded either response is processed by the response transform. return response; } Response Transform The response transform can first check to see if the state expando attribute was created by the conduit operation. If it was, then the transform can construct a complete node element; otherwise it can return just the primary key and sequence number as above. function updateContact_response ($response) { let $i := $response/sfdc:queryResponse/sfdc:result/sfdc:records if ($i.©state ! = null) then The following function would generate a runtime error, since an attempt is made to modify a node's key value. function foobar(contact) { contact.first = $context.first; contact.last = $context.last; contact. email = $context.email; // runtime error } However, the following function successfully changes the account attribute, which changes the foreign key value, which references the account node. function foo(contact, account) { contact.rirst = ^context.first; contact.last = $context.last; contact.©©accountld = account; // changes account foreign key contact.update(); } Here, the foreign key is defined by the following keyref declaration: Similarly, the function below uses the += operator (a.k.a. link () function) to add a contact node to the set of contacts for the account: function bar(account, contact) { account.©©contacts += contact; } This one-to-many relation is defined by the following keyref declaration, which includes an inverse relation: cxsd: keyref name=,,contactAccountRef" refer="accountKey" mas:alias=,1accouIlt1, mas rinverseAliass11 contacts"> function foo(contact) { contact.first « ^context.first; contact.last = $context.last; contact .©©accountld = null; update(contact) ; } Custom Queries Data can be retrieved by implementing select conduit operations that relate to a defined keyref relationship between two nodetypes; i.e., a foreign key value contained within one node identifies the primary key of a related node. The output of these select operations can be nodes that are folded into the local cache by the framework. Custom queries can be conduit queries (or other procedural logic) that are opaque to the client programming model; i.e., do not explicitly select (or modify) data based exclusively on primary and foreign key relationships. For example, a search operation may return a set of XML objects that match a natural language expression. The different kinds of operations are characterized by the matrix 800 of FIG. 8. Operations have inputs and output that is classified as either temporary data or permanent data. In one embodiment, temporary data is not part of the application's node graph; i.e., it is not defined by schema, key or keyref declarations, and is not automatically folded by the framework into the local cache. Temporary data is not assumed to be persistent, although it may be referenced by system $context or $session variables* which have life cycles determined by the client application framework. Permanent data can consist entirely of application data nodes defined by schema. hi one embodiment, there are two mechanisms for implementing custom queries: 1. Custom Operations can allow the client to pass an opaque, temporary XML object (document) to a specific conduit operation. The operation can asynchronously return a temporary XML document to a client callback. For example, the following custom operation, myQuery, takes an XML object myCallbackO function: $root.myQuery( tnyCallback) ; function myCallbacJc{myOutput) { } 2. Custom Objects can involve the creation of a non-persistent node (defined by schema), which becomes part of the graph. The operation can be invoked when the client "traverses through" a corresponding keyref, in which case, the custom object is passed as the Ssource node into the corresponding select conduit operation. For example, the following custom object conduit operation defined for the keyref that relates task nodes to taskQuery nodes: var query = $root.©otaskQueries- create( Custom Operations Custom operations can be a mechanism for calling custom conduit operations (functions). Both the function inputs and outputs can be XML document literals (not defined by schema). In one embodiment, the framework does not fold results directly into the local cache. For example, suppose we wanted to retrieve a set of email addresses for contacts (for a particular account) who have not opted out of receiving email. The following code client code calls a custom operation, getList, that is passed an XML object, function bar() { account .getList ( * ©language:body type^xquery" */ function foo_reguest ($source, $query) { SELECT Id, Email FROM Contact WHERE Accountld = "{string($source/@id)}" AND HasOptedOutOfEmail = {boolean{$query/@optedOut)} The response from the Web service can be processed by the following function. Note, the results are returned to the client callback as a single XML document—i.e., this is not interpreted as nodes that are folded into the local cache. /** * ©mas:namespace target«napp" * ©language:body type="xquery" */ function foo__response ($response) { for $i in $response/sfdc:queryResponse/sfdc:result/sfdc:records return ^contact id="{string($i/sfdc:Id)}"> the context for the operation. /** * custom operatoin on contact: account.getList( * @mas:operation type="custom" node="app:account" name="getList" * @raas:transform type= "request" function="foo_recruest" * ©mas:transform type="response" function="foo_reBponseH */ function foo{$msg, $source, $query) { $msg.header += createHeader{); return ws.invoke($msg); } Custom Objects Custom objects can involve the creation of a non-persistent node (defined by schema), which becomes part of the graph. The operation can be invoked when the client "traverses through" a corresponding keyref, in which case, the custom object can be passed as the $ source node into the corresponding select conduit operation. In effect, the custom object can contain the input data for a conduit operation that will return nodes bound to the custom object. This cam enable the results to become part of the client cache—and for these nodes to be referenced by subsequent client templates and actions, and for the operation to be rerun to keep these results up to date. For example, the following schema declaration can define a custom object, taskQuery, which is used to select a subset of task nodes based on the value of the priority attribute. The following key definition ensures that each taskQuery object is unique: The following keyref definition is used to bind taskQuery nodes to the root node; it declares a dummy foreign key attribute mas: root that references the root node; the inverseAlias attribute declares a traversal from the root node to the set of taskQuery nodes; i.e., $root. @@taskQueries . *. The following keyref defines the relationship between taskQuery nodes and the task nodes that are returns by the conduit query operation. Each task node declares a dummy taskQuery foreign key attribute that identifies the corresponding query that selected it; the inverseAiias attributed declares a traversal from the taskQuery node to the set of task nodes; i.e., query.©©tasks.*. These keyref definitions define the following relationships between the root node and taskQuery and task nodes as shown in figure 12D. The taskQuery nodes may be created by client script using the standard create () function. function init() { var f = $root.©©taskQueries.create{ In one embodiment, there is no conduit insert operation defined for the taskQueryRootRef keyref, so this client script does not trigger any server activity. The following template traverses the inverse taskTaskQueryRef keyref definition. {$s} This causes an implicit select on the associated conduit operation; the repeater's source attribute references the taskNode created above, and this is used as the source context for the traversal; i.e., the node, The corresponding conduit select operation is defined by the following functions: /** * ®mas:operation type="select" keyref="app:taskTaskQueryRef" inverse='*true" * ©mas-.transform type="request" function^selectTasks_reguest" * ©mas:transform type="response" function="selectTasks_response" */ function selectTasks ($0139, $source) { return ws. invoke ($msg) ; ) /** * ©mas:namespace target="sfdc" * ®mas:field xpath=n©priority" * ©language:body type="xquery" */ function selectTasks_request($source) { SELECT Id, Priority, Subject FROM Task WHERE Priority = "(string($source/@priority})" } /** * ©mas:namespace target="app" * ©language:body type=,,xguery" */ function selectTasks_response($response) { for $i in $response/sfdc:queryResponse/sfdc:result/sfdc:records return } Applications can also define conduit select operations to "seed" the custom objects that represent "pre-canned" queries. For example, the following operation implements a select operation that returns a (constant) set oftaskQuery objects when the client traverses $root .@@taskQueries. *. * ©mas:operation type="select" keyref="app:taskQueryRootRef" inverse="true11 */ function selectTasks ($tnsg, $source) { return ) This queries could, for example, be referenced by the following template:
|
{s2} The first repeater, si, displays the set of taskQuery objects; the second repeater, s2, displays the resulting tasks retrieved from the taskQuery selected by the first repeater. • Priority 2 • Sales Meeting 1 • Annual report Of course, it is also possible to define conduit operations that insert, update, and delete custom objects by implementing a Web service that persists these query objects—in effect, treating them as ordinary nodes within the data model. When a custom object node is modified—either directly by the client application, or indirectly by a sync select operation—all corresponding related nodes can be automatically unlinked from the custom object; i.e., nodes that reference the object via foreign key values, have this foreign key set to null. This ensures that nodes traversed to via a custom object accurately reflect the state of the custom object. Advanced Select Operations The select operation can enable the framework to retrieve nodes for a particular keyref. Conduits can define a select operation since this is the basic mechanism used to retrieve nodes by the client application. Normal select operations can trigger automatically by client applications as they navigate the data model. For example, the following client SPath expression causes the accounts keyref s select operation to be invoked. $account. @@contacts. * The conduit select operation can be passed the primary key of the corresponding account obj ect. This section details other forms of select operations. Caching and Optimizations Both the client and MAS can cache the data that are returned by the conduit manager. Therefore, not every data graph traversal need not generate a select request. Both client and server caches can maintain meta data for each node and nodeset that determines how long the corresponding set of data can be relied upon to be up-to-date, before a new select request is generated. Often, the amount of data that needs to be transferred following a select operation is quite large. Therefore, given the availability of suitable Web service operations, certain optimizations can be implemented by the framework. The seiect_pkey operation is invoked in exactly the same manner as the select operation, however, it returns only sets of primary key values. For example, the select_pkey operation for the corresponding select operation on the contacts keyref above would implement the following response transform. /** * ©language.-body type="xquery" * ®mas:namespace target="appH */ function selectContactsByAccount_response($response) { for $i := $response/sfdc:queryResponse/sfdc:result/sfdc;records return */ function selectContacts_request($keyset) { SELECT * FROM Contact WHERE Id IN ( ( for $x in $keyset return } ) The response transform can be the same as for the normal select operation. Selecting Complex Schemas Select operations may return nodes that are defined as complex documents that contain repeated elements. There is no restriction placed on the complexity of a nodetype's schema definition. However, there may be practical limits to the size of a node record. The next section details the case when a complex document may be split into multiple nodes. Example The schema below illustrates a purchaseorder nodetype that contains multiple lineitem elements. For example, the following XML document illustrates the purchase order schema. * • * The following conduit function contains a nested loop that generate a set of purchase orders, each with a nested set of line items. /** * ©mas:operation type="select" keyref="purchaseOrderAccountRef" inverse="true" * @mas:transform type="request" function="selectPurchaseOrders_request" * @mas:transform type="response" function="selectPurchaseOrders_response" */ function selectPurchaseOrders($msg, $source) { var response = ws.invoke($msg); var pos = response.sfdc:query-Response, sfdc:result .sfdc:records; // retrieve line items for each purchase order for fi = 0; i var msg2 = createMessage{requestLineltems(pos[i].sfdc:Id)); var response2 = ws. invoke (msg2) ; pos [i] += response2 . body. sfdc: queryResponse . sfdc : result. sfdc: records; } return response; } /** * ©language:body type="xquery" * ©mas.-namespace target="sfdc" * iSmas: field xpath="@id" */ function selectPurchaseOrders_reguest($source) { SELECT * FROM PurchaseOrder WHERE PurchaseOrder.Accountld = {string($source/@id)} } * ©language:body type="xguery" * @mas:namespace target="s£dc" */ function selectLineltems($id) { SELECT * FROM Lineltem WHERE Lineltem.PurchaseOrderld = $id } * ©language:body type=="xguery" * ©mas:namespace target«"appn */ function selectPurchaseOrders_response($response) { for $po := $response/sfdc:queryResponse/sfdc:result/sfdc:records return { for $li in $po/ws:records f^tv.m } } Selecting Node Trees Select operations may return nodes that are defined as complex documents that contain repeated elements. There is no restriction placed on the complexity of a nodetype's schema definition. In some cases, it is desirable to split parts of a complex document into independent nodes, bound by keyref relationships. These nodes form a tree, which is synchronized back to the client and incorporated into the cached data graph. The advantage of splitting compound documents into multiple nodes is improved performance by retrieving multiple levels of keyrefs in a single operation (e.g., select all contacts for a particular account, and all associated tasks). Example In the following schema definitions, both the purchaseOrderType and lineitemType have been declared as nodetypes with the following schema definitions. The schema also declares the following key and keyref definitions: The Figure 12D represents the corresponding keyrefs. Whenever compound documents are broken into individual nodes, the framework can ensure that client operations on the constituent nodes (e.g., line items) are supported by the conduit. For example, the client application can be prevented from creating new line item objects unless there is a corresponding insert operation for the lineitems keyref. The conduit definition below is a modified version of the example above. Here, the inner loop creates node elements within a nodeset element. Note, the inner objects must also each define a primary key. * ®mas:operation type="select" keyref=MpurchaseOrderAccountRef" inverse="true" * @mas:transform type="request" function="selectPurchaseOrders_request" * ©mas:transform type="response" function="selectPurchaseOrders_respon.se" */ function selectPurchaseOrders ($11139, $source) { var response = ws. invoke ($msg); var pos = response.sfdc:queryResponse.sfdc:result .sfdc:records; // retrieve line items for each purchase order for (i = 0; i var msg2 = createMessage(requestLineItems(pos[i] .sfdc:Id) }; var response2 = ws.invoke(msg2); pos [i] += response2 .body.sfdc:gueryRespon.se. sfdc:result .sfdc:records; } return response; } /** * ©language:body types"xquery" * @mas:namespace target="sfdc" * @mas:field xpath="@id" */ function selectPurchaseOrders_reguest($source) { SELECT * FROM PurchaseOrder WHERE PurchaseOrder.AccountId = {string($source/@id) } } /** * ©language:body type="xquery" * ®mas:namespace target="app" */ fonc'ciuii aeiei_:LPurchaseurders_response ($response) { for $po := $response/sfdc:gueryResponse/sfdc:result/sfdc: records return { for $li in $po/ws:records return Session Management Session state can be managed by the conduit's custom procedural code. The conduit can define a variable to store a session identifier. This may be created by the conduit, or returned by the Web service—as in this case: // session object returned from Web service var sessionld = null; The conduit can define a function that creates and sends a message to initiate the session; the function can then processes the response to extract any session related information returned by the service. The function below sends the // create and send login message and process results function login() { var body = // set session id sessionld = string (response.body, sfdc: result .sfdc:sessionId) ; // set "URL for subsequent calls (from this conduit) ws.endPoint = string (response, body. sfdc:result. sfdc-.serverUrl) ; ) The $user XML variable contains information about the current user; it is a system variable accessible to all functions. Each conversational method can specify a header containing the session identifier, the following (ordinary) conduit function first checks if a conversation has been started (caiiing login if it hasn7t) then returns the appropriate header XML fragment. // create conversational header function createHeader () { if (sessionld =s= null) { login () ; ) return For example, the following XScript function implements custom session management required by the Web service: /** * ®mas:operation types"select" keyref= "app: contact AcoountRef" inverse="truew * ©mas: transform type="reguest" function=:"selectContacts_rec[uest" * ©raas:transform type«"response" function«"selectContacts_response" */ function selectContacts ($tnsg, $source) { $msg.header += createHeader(); return ws.invoke($msg); } The function is passed in a message object, $msg, that contains a body created by the request transformation. Next, the function calls createHeaderO function to obtain an XML object that contains the necessary header information. This function triggers the login () function (above) if a session has not currently been started The header object is then added to the message. The invoke () function then sends the message (including the header) to the Web service; this uses the transport provided by the specified control. User Information The $user variable contains data about the user on whose behalf the Client Programming Model A user can access an application by referencing its URL on the MAS. The first time a user does that from a client machine, all the components of an application can be automatically "downloaded" from the server. If the application developer has only specified a data model for the application, the meta data for the data model can be downloaded. The meta data can contain enough information for the mobile browser to provide a minimal user interface for the application. Using the meta data, the mobile browser can initially display the root node and its keyrefs. The user can navigate through the application data by clicking on these keyrefs. As the user selects a keyref, the data sync engine asynchronously fetches the nodes for that keyref and automatically displays the data when available. For example, the user could traverse the Accounts link to cause the Account nodes to be fetched; and then traverse an Account's Contacts keyref to view its Contacts for the Account. This model is functional, but not particularly pleasant—the UI is stark and the experience "jerky" since no data is pre-fetched. This section describes how the application programmer can customize the user interface. There are two basic artifacts that the programmer uses to customize a client application. The first is "templates" which can be used to present a custom user interface for a set of data. The programmer can attach customized ways to render nodes and nodesets using "templates" which can be XHTML templates with embedded SPath expressions to access data from the data model and embedded elements to repeat over nodesets. The occasionally-connected data model itself is presented as a big virtual XML document rooted in a magic variable, $root. In One embodiment, there is a "current" position within the data model (for example an Account or a Contacts for an Account) and this is available to the template through another magic variable, Scurrent. URL's can express both branching to another template or new "current" data within the template (e.g. going to an Account to its Contacts). While templates can be expressed in XHTML, they can contain an important extension to t he XHTML model itself, "selection" which is explained below. It enables to enable a richer more interactive UI than HTML normally provides but which is possible when the client is also the controller. The second artifact lets programmers attach offline behavior to buttons and URL's in the page. Every URL can reference "actions" written in ECMAScript for XML (a.k.a. JavaScript) in a page flow file (controller.xpf) which is also placed in the client directory. This file contains a set of script "actions". Actions have full access to the data model so that they can compute values, modify data on the client thus triggering deferred synchronization, explicitly trigger synchronization and deep selects, invoke custom operations, or cause navigation to set currency to another part of the data model. Each "action" in the controller can return both the new currency within the data model (or CONTINUE if the action doesn't actually change "currency" within the data model) and usually the specific template to use in the context of that currency. For example, an action in a page listing Contacts to see related Contacts might simply be a one liner to set the currency to the related Contacts and use the Contact list templates to display them which would be something like: function showContactsForAccount($account) { $context.account » $account; return [$account.©©contacts.*, "ContactsTemplate.tmpl"]; ) Model View Controller MAS client applications can consist of a page flow file (controller .xpf), which may contain XScript actions and functions, and a set of page templates (.tmpi). The client can maintain a local cache of the application data. This data is described by the occasionally-connected data model and is referenced and manipulated using SPath. Templates are XHTML pages which contain embedded SPath expressions. These expressions can reference any data in the cache and systems variables and functions Since templates can only reference local data, they can be rendered independent of the machine's network connection state (i.e., enabling users to run the application offline). The system variable, $current, can act a cursor into the data; $current references either a single node or a node list. The value of $ current can be changed by actions and anchors that invoke system functions; this is known as navigation. The system variable, $context, can provide a mechanism for actions and templates to exchange temporary variables. For example, a template may bind input fields to either context variables or node elements within the cache. Templates may also contain repeaters, which iterate over a specified part of the data or data mode. Repeaters enable the template to automatically build up complex lists and tables, and enable the user to select individual records and to invoke actions on them. The page flow mechanism invokes actions in response to user interface and external events. User interface events can be triggered by anchors within templates; external events can be triggered by external sync updates to the data. When the application first starts, it can call the begin () action within the page flow, which determines the first template to be displayed. Actions can be XScript functions that are invoked by templates and external events. Actions may modify the data, and $current and $context variables that are accessible to the templates. The system variable $page references the currently visible page document; this enables actions to access page controls properties. Navigation can occur when either the $page or $ current system variables are changed by an action. The client cab maintain a history stack of variables. This enables the user to navigate backwards and forwards through the history and for the template to maintain their context (and, for example, the bound values of input elements). XScript SPath Expressions The client programming model can use ECMAScript for XML (E4X, XScript), which is essentially JavaScript with native support for XML; SPath is an XPath-like language, which enables applications to query the XML data graph. It uses the "dot" operator to "traverse" elements within the graph. Elements may be either regular XML elements or data nodes. XML Operations System variables can be prefixed with the '$' symbol and are untyped. The use of other variables is defined by the XScript spec. The following declarations create variables f oo and bar. foo = 100; var bai- = "Alnhfttnv" • The var keyword places the variable within the local scope of the current function; variables that do not declare var are placed in the global scope. The following declaration set the value of foo to the newly created XML object.: var foo =s Compound XML objects can also be created and referenced as follows: var foo = bar == "Alchemy" XML object may also declare attributes, which are referenced using the *@* operator, for example: var foo « Attributes can be added implicitly (i.e., expando): foo.©ping = "200"; The data contained within a node element can be referenced and modified using regular SPath expressions. The following example changes the text value of an element within the $contact node. account.name = "Acme Ltd"; New XML elements may also be created within a node by assignment, for example: account .address = Data Operations Relations between nodetypes can be defined by keyref definitions in the occasionally-connected data model. For example, the following declaration specifies that the accounts keyref originates from the root node, and contains nodes of type account (which is defined by a schema). In the client programming model, keyrefs can be traversed using the @@ operator. For example: $root.©©accounts The keyref() function can also be used to reference named keyrefs. The following example is equivalent to the example above: $ root. keyref (" account- R " ) The keyref can be thought of as referencing the keyref for the specified parent nodes. The following examples references all account nodes of the accounts keyref of the $root node. $root.©©accounts.* $root.keyref("accounts").* This expression returns a nodeset where each node will be of the type account, for example: The [] operator can be used to access a particular node within a nodeset. The following expression returns the first node in the accounts nodeset: $root.©©accounts.*[0] The length () function can be used to return the number of nodes in a nodeset. $root.©©accounts.*.length() Note, this is quite different from the following expression, which returns the value 1 (one). $root.©©accounts.length() Le., $root.@@accounts returns a single element, The data graph can be filtered using the where () function, which takes an SPafh expression as an argument. For example, the following statement matches all contact nodes in the accounts keyref with specified last name and returns a node list $ root.©©accounts.*.where(.name == "Acme"); Note, this is equivalent to the following expression. $root.©©accounts.*.(thisXML.name == "Acme"); Where clauses can evaluate to node lists, and may be followed by a subsequent SPath expressions. For example, the following expression returns a node list of contacts for all accounts named "Acme". $root.©©accounts.*.where(.name == "Acme").©©contacts.*; Labels Each nodetype declaration may define a label, which is an SPath expression that references the node. The label {) function returns the computed string. {$context.account.label()} Keyrefs may also define labels that are returned by the label () function. {$root.©©accounts.label()} The label for a node is obtained by the label() function. For example: When a node or keyref is referenced by itself, coercion automatically invokes the label () function. The following examples are equivalent to the examples above. {$context.account} {$ root. @@account s} You have {$session.count} messages. Click $current The $ current variable represents a node (or node list) and is typically used by a template with relative SPath expression to bind UI elements to data. $user The The $root.@@accounts.*; The occasionally-connected data model can defines the application nodetypes; these can be constructed from the application schema and keyref definitions. For example, the following sample details the account nodetype; this contains the schema elements (name and type), and the keyref definitions (owner, subAccounts, contacts, notes, events, tasks, and quotes). The account node definition defines the elements (and possible attributes) described by the corresponding schema defined on the server. As above, the keyref definition determine the traversals possible from an account node. For example: var user = account.©©owner; var contacts = $root.©©accounts.*.©©contacts.*; Similarly, the following sample defines the contact nodetype. The following XML illustrates a client model for how the user accesses this data although, at no time is there ever an actual XML file that looks like this. Overview In one embodiment, there are two ways for the client to modify the data graph. First, input elements in templates can be bound directly to data nodes; this mechanism enables the user to modify XML elements belonging to existing nodes and requires no code. Second, (and typically) the template invokes an action, which modifies the data. In one embodiment, these changes to the data are not synchronously sent to the server. Instead, a background process synchronizes updates to and from the server. In fact, since the entire page flow mechanism can run independently of network (server) connection, there will typically be multiple offline changes to the data, which will by synchronized and reconciled with the server once a connection is established. The programming model can also implement a mechanism to defer the synchronization of updated or inserted records. For example, a node could be created that represents a purchase order, but the user may not want to synchronize this until all of the line items have been added and then clicked a "submit" button. The server may reject synchronization requests due to optimistic concurrency conflicts with other users, or due to external application errors. Each node has synchronization state which is managed by the framework. This can enable the application to display flags that indicate which records are pending synchronization, up-to-date, or rejected by the server. Schema Validation When the create() and update() functions are invoked the framework does the following: A) validates the object against the application schema, and validates all required foreign keys; B) ensures that the cache is consistent for relations that may be traversed in the reverse direction (i.e., inverse relations). If either condition is not met, a runtime error is generated. Also, key/keyref consistency is enfoi'ced when the linkO or unlink() functions (also +=/-= operators) are invoked. Creating Nodes The following action can create a node using the create () function. var po = po.lineltems += po = ^account. @@purchaseOrders. create (po) ; The node, po, can be constructed by the XML assignment expression (first line). The second and third expressions modify the XML node. However, the node need not be validated until the create () function is called. Updating Nodes Similarly, the application can modify existing nodes by directly accessing the node's data. For example, the following code retrieve a particular purchase order, and then changes the status and adds a new line item: po = $account.@®purchaseOrders. where(.date == "03/12/05") .*[0]; po. status = "getQuote"; po.lineltems += $po.upaate(); Again, the update () function is called to validate the node. Creating Nodes For example, the following XScript constructs a new contact node within the contacts keyref for the specified $account object. var contact = <:email>sydney@james .com node - account,@@contacts.create(contact) ; Nodes are typically created in three stages: first an action creates a context variable, and then causes a template to be displayed. function init() { $context.contact = return ["editContact.tmpl«] / } Next, the template binds input controls to individual context elements. Next, the template invokes a second action; the framework automatically transfers HTML input values back into the context variable before calling the action. The action then creates the new node. function create () { $context.contact = $account.©©contacts.create($context.contact); return ["showContact.tmpl"]; ) In the example above, the action replaces the current context variable ($context.contact) with the node constructed by the create() function; this enables the next template (showcontact.tmpi) to reference to created node. Note, before the create () function is called $context. contact j ust contains a well formed XML element; afterwards it points to a validated node (e.g., that supports the various node function. In one embodiment keyrefs that define an insert conduit operation allow nodes to be created and attempting to create a node on an invalid nodeset will cause a runtime error. Callbacks The create () function may also specify a callback function, which is invoked when the sync mechanism receives an acknowledgement from the server that the node has been created (i.e., the associated conduit operation succeeded in returning the new primary key). For example: function foo(account, quote) { node = account.©©requests.create(quote, bar); } function bar(request) { $context.lastRequest = request; } The callback function can be passed the created node as a parameter. Updating Nodes The update () function can be used to synchronize nodes modified on the client. node.update([callback, id]); The function is called on a keyref that supports the update conduit operation. nodes, synchronization runs as a background process. However, a modified node is not marked for synchronization unless the update () function is called. The update!) function can set the syncstate attribute of the associated node to MODIFIED. This mechanism can enable multiple edits to be made to a single node before the node is synchronized. Example In the following code, the first two expressions can set the syncstate of the $contact node to DSYNC; and the last expression set the syncstate to MODIFIED. contact-first = "Bob"; contact .address = $contact.update(); Callbacks The update () function may also specify a callback function, which is invoked when the sync mechanism receives an acknowledgement from the server that the node has been updated (i.e., the associated conduit operation succeeded). For example: function foo(account, quote) { quote.update(bar); ' ) function bar(request) { $context.lastRequest = request; } The callback function can be passed the created node as a parameter. Conflict Management In one embodiment, node conflicts occur when a client tries to modify and synchronize a "stale" node that has already been updated (either by another client or other exogenous change process) hi the external system. A stale node is one that has a different sequence number than the current sequence number held by the server. If the server rejects the update because the node is stale, then it returns an up-to-date node with the synchronization state attribute set to "conflictn. Update operations may set a callback, which is invoked when the node is returned from the server (whether or not there is a conflict). If a callback is not set, then the client framework automatically replaces the client's stale node with the up-to-date node returned by the server. The callback function should first test for the conflict state using the syncstate 0 system function. It must then set a global variable (i.e., $session) for the application; e.g., function updateCallback(node) { if (node.syncState() == CONFLICT) { $session.message = "edit conflicts"; $session.conflict = node; } } In order to notify the user that a conflict has occurred, each template might include a status area that contains references this global variable; e.g., {$session.message} Here, the global variable contains an HTML anchor that enables the user to navigate to an action that will display the conflict editor page: function showConflict() { $context.node * $session.conflict; return ["showConflict.tmpl"]; } The showConflict template below displays the values of the stale node and the up-to-date node side-by-side. The Spath expression calls the conflict () function which is defined for data nodes; this returns the up-to-date node. Note, although the conflict node may contain foreign key values, the @@ operator cannot traverse from a conflict node. Contact record conflicted with server. |
---|
1997-chenp-2006 correspondence others.pdf
1997-chenp-2006 correspondence po.pdf
1997-chenp-2006 description (complete) 05-12-2008.pdf
1997-chenp-2006 description (complete).pdf
1997-chenp-2006 form-13 03-11-2008.pdf
1997-chenp-2006 form-5 05-12-2008.pdf
1997-chenp-2006-assignement.pdf
1997-chenp-2006-correspondnece-others.pdf
Patent Number | 252360 | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indian Patent Application Number | 1997/CHENP/2006 | |||||||||||||||||||||||||||
PG Journal Number | 19/2012 | |||||||||||||||||||||||||||
Publication Date | 11-May-2012 | |||||||||||||||||||||||||||
Grant Date | 10-May-2012 | |||||||||||||||||||||||||||
Date of Filing | 06-Jun-2006 | |||||||||||||||||||||||||||
Name of Patentee | BEA SYSTEMS, INC. | |||||||||||||||||||||||||||
Applicant Address | 2315 North First Street, San Jose, California 95131 | |||||||||||||||||||||||||||
Inventors:
|
||||||||||||||||||||||||||||
PCT International Classification Number | G06F17/30 | |||||||||||||||||||||||||||
PCT International Application Number | PCT/US2005/017822 | |||||||||||||||||||||||||||
PCT International Filing date | 2005-05-20 | |||||||||||||||||||||||||||
PCT Conventions:
|