Patent Application
20090327292
The present invention is related generally to distributed computing environments and, more particularly, to ensuring data consistency in such environments.
Computer applications are becoming ever more complex and dependent upon communications with other applications. (In this context, the word “application” is meant broadly to include user applications, operating systems, and utilities.) Often, communications among applications are coordinated by sharing data values. All of the participating applications know the data values, and, if any participating application changes a data value, then all of the other applications are made aware of the change.
Protocols exist for ensuring the consistency of data values shared by, and possibly changed by, numerous participating applications. Sometimes, a central data repository “owns” the data, and any interested application must ask the central repository for the current value. Changes to the data values are coordinated by messages sent to and from the central repository. These protocols ensure “hard” consistency of the data, but they can involve a huge amount of messaging to coordinate the participating applications. This coordination traffic can sometimes be a processing and memory-bandwidth burden when the participating applications are all running on a single computing device, and the potential problems only grow when the participating applications are running on a distributed set of computing devices.
Locally connected devices (e.g., computing devices on a wired LAN) can often handle the required messaging traffic, but such traffic can overwhelm small, portable devices by using up too processing power, too much data bandwidth, and thus too much battery power.
The above considerations, and others, are addressed by the present invention, which can be understood by referring to the specification, drawings, and claims. According to aspects of the present invention, a “light weight” protocol is used to coordinate shared copies of a data element. A central repository holds a master copy of the data element. Applications (either on the same computing device as the central repository or on other devices) “subscribe” to the data element (or to an aspect of it) by sending a message to the central repository. Whenever the data element (or data aspect) is changed, applications that have subscribed to the data element (or data aspect) are notified of the change. Because an application may choose to subscribe to only an aspect of the data element rather than to the full data element, the application is spared from receiving update notifications when other (non-subscribed to) aspects of the data element change.
When an application subscribes to an aspect of a data element, the application receives from the central repository the current value of that aspect. When an application wishes to change the value of a subscribed aspect, it sends an update request to the central repository. The central repository accepts the request, changes the master copy of the data aspect to the requested value, and then informs all subscribed applications of the new data value. If two applications both wish to change the value of the same data aspect, they send their update requests, and the central repository accepts both requests, processing them in the order in which they are received. Thus, conflicts are resolved by a straightforward “last updater wins” method that requires no elaborate coordination mechanism. This extremely powerful technique significantly reduces data traffic when compared with previous methods that require a great deal of data-coordination messaging.
In some embodiments, the central repository, upon receiving two nearly simultaneous update requests, only responds to the second one. The result is the same as in the simpler method described above (“last updater wins”), but this refinement can reduce message traffic.
To help applications coordinate their changes, a timestamp can be attached to each notification message stating when the aspect of the data element was changed. However, the protocol does not require any coordination of timers among the applications. The notification message may also state which application requested the most recent change.
In some embodiments, the central repository sends out values for the entire data element to all subscribers whenever any aspect of the data element is changed. This is useful when the data element is relatively small. In some embodiments, all subscribing applications receive notifications with a timestamp whenever any aspect, even an unsubscribed aspect, of a subscribed data element changes.
In some situations, an application may need to “LOCK” a data aspect for a time so that the data aspect cannot be changed by any other application. The above method can be used without change for this. A LOCK field is associated with the data aspect. To lock the aspect, a first application waits until the value of the LOCK field is UNLOCKED. Then the first application requests that the value of the LOCK field be changed to LOCKED. If the update notification indicates that the new value of the LOCK field is LOCKED, and if the update notification states that the first application requested this change, then the first application has locked the data aspect and may proceed. If, on the other hand, the field was locked by another application, then the first application waits until the other application releases it (by requesting that the value be changed to UNLOCKED). This extremely powerful lock/unlock protocol requires no special refereeing by the central repository.
In some embodiments, the central repository tracks the subscriptions to a data element. For some data elements, when the number of subscriptions drops to zero, the central repository deletes the data element.
While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
a and 2b together form a flowchart of an exemplary method on a client for updating a data aspect;
a and 3b together form a flowchart of an exemplary method on a central repository for updating a data aspect; and
a and 4b together form a flowchart of an exemplary method on a client for locking a data aspect.
Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable environment. The following description is based on embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein.
The central repository 102 hosts a master copy of a data element 106. The phrase “data element” is used to convey in the most general way any data structure or combination of data structures. A data element can be a single bit value, a list of values, a spreadsheet, a data object, an elaborate database with millions of entries of different types and values, or a combination of these data structures along with any associations among them. The data element 106 need not be physically stored on the host of the central repository 102 itself (though that is the typical scenario) as long as the central repository 102 has some measure of access to, and control of, the data element 106.
The exemplary data element 106 of
The applications 104a and 104b have each subscribed to the data aspect 108. Upon subscription, they each received from the central repository 102 a copy (108a and 108b, respectively) of the data aspect 108. The application 104c has subscribed to the entire data element 106, and its local copy 106c includes, of course, a copy (not shown) of the data aspect 108. Any of the three applications 104a, 104b, and 104c can update the data aspect 108, and whenever the data aspect 108 is updated, all three applications 104a, 104b, and 104c receive notifications of that fact.
An exemplary method for updating a subscribed data aspect is shown in
In step 200 of
Assuming that the subscription request is in order (e.g., the requested data aspect 108 is known to the central repository 102, the requesting application 104a has sufficient privileges to subscribe to this data aspect 108), the central repository 102 accesses its master copy of the data element 106, retrieves a copy of the requested data aspect 108, and sends that copy to the requesting application 104a in step 302 of
Strictly speaking, step 304 of
Before considering the procedure used by the application 104a to change the value of the data aspect 108, consider what the application 104a does when the other applications 104b and 104c subscribing to the data aspect 108 change its value. Whenever the value is changed, all subscribing applications (including the application requesting the change) receive a notification of the new value in step 204.
As with the response to the original subscription request, the notification in step 204 may include the value of an entire data element even though only a portion of it has changed. Thus in some embodiments, the application 104a receives a new copy of the entire data element 106 even though the subscribed data aspect 108 has not been changed because, for example, the data aspect 110 was changed by the application 104c.
Step 206 of
Step 208 of
When the application 104a wishes to change the value of the data aspect 108, it sends a request with the desired new value to the central repository 102 (step 210 of
Note what the central repository 102 does not do: It does not consider whether or not to apply the requested change. All change requests that are in order (as described above for the subscription requests) are accepted and applied. When two applications make nearly simultaneous changes, there is no special processing to handle this “race” condition: The changes are simply accepted and processed in the order in which they are received by the central repository 102. Thus, this simple protocol supports a “last updater wins” protocol. Because of this, whenever the application 104a requests a change, it should consult the update messages (received in step 204 of
Some embodiments of the central repository 102 refine the processing of step 306 slightly. If two change requests for the same data aspect are received nearly simultaneously, the central repository 102 may choose to simply discard the first one and apply the second. The end result is the same (“last updater wins”), and this refinement saves the cost of sending out the first update notification (which would be almost immediately overridden by the second one anyway).
When the application 104a is finished using the subscribed data aspect 108, it may inform the central repository 102 of that fact by unsubscribing in step 212 of
There are some situations for which the simple “last updater wins” protocol is inadequate. For example, consider the situation where the subscribed data aspect 108 is a counter that should be incremented whenever one of subscribing applications 104a, 104b, and 104c does “something relevant.” Assume that the current value of the data aspect 108 is 3. If both applications 104a and 104b do “something relevant” nearly simultaneously, they will each see the current value of 3 and send an update request to change that value to 4. The central repository 102 accepts both requests, applies them, and changes the value to 4. This is, of course, incorrect, as the value should now be 5.
One solution to this problem is to increase the complexity of the protocol described in relation to
A simpler solution is preferred. A LOCK protocol, based entirely on the “last updater wins” protocol, is provided that allows the subscribing application 104a to modify the value of the data aspect 108 without interference from the other subscribing applications 104b and 104c. That is, the application 104a ensures that its change “sticks.” The application-side of the LOCK protocol is illustrated in
Just as in the protocol illustrated in
The data application 104a also receives notifications whenever the associated LOCK field 110 changes (step 406). In
When the application 104a needs to lock the data aspect 108, it waits until the associated LOCK field 110 has the value UNLOCKED (step 408). When the LOCK field 110 has the value UNLOCKED, the application 104a requests that the LOCK field 110 be changed to LOCKED (step 410 of
Step 414 is the key to the LOCK protocol. Only if the received value of the LOCK field 110 is LOCKED and if the application 104a is indicated as the application that requested that change, then the application 104a has successfully locked the data aspect 108 for its own use. If either test fails, then the application 104a returns to step 408 of
Step 414 is key because the central repository 102 does not referee the LOCK protocol of
If both tests in step 414 succeed, then the application 104a has control of the data aspect 108 and may use it as necessary in step 416 without interference from the other subscribing applications 104b and 104c. When it is finished, the application 104a unlocks the data aspect 108 by requesting that the LOCK field 110 be set to UNLOCKED (step 418).
The above discussion illustrates the concepts of the present invention without a clutter of implementation details. Having only the above discussion, one of ordinary skill in the art could implement aspects of the present invention in any of a number of embodiments. However, it may be useful to consider in detail one embodiment of an implementation protocol. The following discussion presents such an embodiment called the “Remote AppBus Protocol.” The following discussion is not meant to limit the scope of the claims in any manner.
The Remote AppBus Protocol consists of a collection of disjoint request-response messages that can be broadly grouped into Framework and DataObject (“DO”) categories. The Framework requests support connection setup (with user authentication for session), callback registration/removal (for data insertion events), queries (using predicates), data object creation (and insertion) and data cache maintenance (used by Remote AppBus enablers, not by applications). The DataObject requests primarily support accessor and modifier methods related to the attributes, associations, and payload for each object, as well as callback registration/removal for data modification events.
To stay lightweight and to reduce chatter, Remote AppBus enforces a one-response-per-request rule. The response messages themselves are quite straightforward. Most requests receive positive/negative acknowledgments. A small subset however return richer “results” data. For example:
In addition, Remote AppBus supports a limited set of error messages that cover the most frequent exceptions.
While requests are initiated by the remote endpoint (e.g., an application), there also exist asynchronous notification messages initiated by the core AppBus for delivery to the remote endpoint. These respond to previous Framework or DataObject event subscription requests from that remote endpoint. Such subscriptions can be initiated by an application (explicit) but may also be initiated by the remote infrastructure (implicit) as a way of performing proactive synchronization of data items that are in its cache. For the latter, some notifications (e.g., timestamp updates for associated data objects) are targeted for implicit consumption only (to maintain data consistency) and are not delivered to explicit subscribers. To reduce chatter, notifications do not trigger acknowledgements.
While the protocol elements described so far are pretty straightforward, a novelty of the present approach is the use of an on-demand caching strategy at the remote end which provides the desired illusion of consistency but without the huge messaging overheads associated with strict RPC or data mirroring solutions that demand strong data consistency. The present approach involves a multi-faceted, write-through coherent caching system that prioritizes consistency only of relevant data required for immediate access on the remote endpoint. Thus, only those DataObject instances that are “referenced” (either in a query result or in an event notification) are cached by the infrastructure on the remote side. More importantly, only significant parts of the data are cached, where significance is related to the aspects of the data that were requested when that instance was referenced. Each part of a DO instance can be transferred and cached on-demand as follows:
Reference Only: A “stub” DataObject can be created on the remote endpoint and populated only with a DataObject identifier and a current DateStamp. References are created in response to receiving a query result (a list of DO references), as a part of the association list within a more complete DO in the cache, or as a DO reference in an event notification. If the application never queries a DO reference further, then that data object is never fully populated, and no extra bandwidth is consumed in keeping those “unknown” details consistent.
Attributes: DO attributes are represented by name-value pairs. If an application attempts to view or to update attributes for a DO, then all attributes for that DO are instantly fetched to update the cached item. The tradeoff is between the initial delay in populating DO attributes vs. less cost in subsequent accesses. This supports the observation that an application that expresses an interest in a DO (by viewing one attribute) will likely turn around and interact with more attributes. The populating of all DO attributes is triggered by a single response to the first view/update attribute request.
Payload: The DO payload is simply a “blob” (byte-array) with mandatory attributes indicating size and content type (currently defined by a MIME-type). Payload blobs can be arbitrarily large and are potentially useless to applications that do not understand, or have an interest in, that content type. Thus, payloads are not automatically populated in cached DataObjects unless explicitly requested by the application.
Association List: This is a list of “child DO” references maintained by a data object when applications associate it with another data item in a parent-child relationship. The present approach supports a flat hierarchy (a DO can be a parent or a child, but not both), though multiple associations can exist (parents can have many children, and a child can have many parents). Because lists can be large, DO “references” are maintained only if an association list is requested.
Finally, once any part of a DO is cached, it is then kept in synchrony with its DO counterpart on the core AppBus by using the event notification mechanism. For every DO reference dispatched to a remote endpoint, the local endpoint registers itself for DO modification events and dispatches these to the remote DO as they occur. The remote endpoint then uses these notifications to keep the partially cached DO consistent. Note that by exploiting notifications, the present approach essentially ensures that the core AppBus is unaware of the remote mirroring of the selected DO.
A more complex aspect of Remote AppBus involves the simultaneous garbage collection of data on local and remote endpoints. If a DO is referenced and in use on the remote side, then the local side must “pin” that DO reference in the core AppBus to ensure that it is not inadvertently garbage collected. This holds for every DO reference sent to the remote side (in queries, notifications, or association lists). However, many of these DO references will eventually be unused on the remote side and will be de-referenced there. Because “pinned” DOs impact the memory usage on the core AppBus (e.g., on a mobile device), it is critical that the remote endpoint promptly notify the core of “unused” references so they can be unpinned on the local side. This is achieved using a timer on the remote endpoint which periodically triggers a cache evaluation that prunes any unused references and posts that list back to the core AppBus.
The two entities that take part in a Remote AppBus (“RAP”) connection are the Remote AppBus Client (“RC”) and the Remote AppBus Adapter (“RA”) that acts as a client proxy. The RA resides on the same device as the AppBus framework, and the RC resides on the other side of the RAP connection. The RC can make queries for AppBus data and events, create new AppBus data, and modify existing AppBus data. These activity requests are transmitted across the Remote AppBus connection to the RA. The RA then handles the AppBus framework interactions on behalf of the RC and transmits the results across the link.
Remote AppBus enables remote access to the AppBus framework from two kinds of remote clients: remote processes running on the same device but in a separate address space and remote processes running on a different device that can communicate with the AppBus framework over some wired or wireless link (e.g., Bluetooth). In the latter case, RAP relies on Bluetooth Serial Port Profile connections to carry messages. These connections are established by the RAP Client and are maintained as long as the client maintains connection to the AppBus framework.
There are two security modes for a normal, local AppBus client to connect to the AppBus framework, and this applies to remote clients as well. These modes are secure and public.
Boolean data are encoded as a single byte having either a 0x00 (false) or 0x01 (true) value. Integer data are encoded in big-endian variable length fields, depending on the maximum range of values allowed for the field in question. Integer field lengths are 1, 2, 4, or 8 bytes long. Integers are unsigned unless otherwise indicated. String data are encoded using a 2-byte (big-endian) length prefix followed by the specified number of bytes of UTF8-encoded character data. (Note: The length prefix specifies the number of bytes of character data, not the number of characters in the string.) The longest string that may be transferred using this encoding is 65535 characters, assuming that none of the characters requires more than one byte. Note that this encoding scheme is based on IETF standard network byte ordering and is compatible with the commonly used java.io.DataInputStream and java.io.DataOutputStream classes.
Each message is framed using a length-prefix scheme. The 8 bytes of message framing fields are not included in the message size, allowing a maximum enclosed message size of 65535 bytes. High-level messages may be fragmented into multiple low-level frames, allowing arbitrarily large high-level messages. The final fragment of a high-level message should have the FLAG_FINAL field set to true (0x01), other fragments should have the FLAG_FINAL field set to false (0x00). All fragments of a high-level message MUST have the same MSG_SEQ value. For each high-level MSG, there must be one high-level RPY (which may be similarly fragmented into multiple low-level frames). The MSG_SEQ field of the RPY must match the MSG_SEQ of the corresponding MSG. LRDMP Clients and Servers generate MSG sequence numbers independently of each other.
There may be a single-frame error message that indicates an error in processing the original message. When an error message is sent, there will be no reply message.
Messages are processed in order by each peer.
The format of the enclosed messages (MSG, RPY, or ERR) is message-type specific.
In the following message descriptions, all lengths are in bytes unless otherwise indicated.
Framing Header:
Currently, attributes may have the data types String, Date, and Integer. Regardless of type, however, they are transmitted across the Remote AppBus Protocol as String data. Therefore, standards for acceptable data representation in the String format should be established. For Integer data, numerical digits (0-9) may be used. A leading + or − may be included to indicate positive and negative values respectively. The leading + is assumed if no sign indicator is included. For Date data, the format supported is YYYYMMDD HH:MI:SS:MS.
MSG: All message exchanges begin with an MSG message. All MSG messages begin with a 1-byte message header that indicates the type of message. The rest of the message is formatted according to the message type.
MSG Header:
RPY: All successful message exchanges terminate with an RPY message. All RPY messages begin with a 1-byte message header that indicates the type of the message. The rest of the message is formatted according to the reply type.
RPY Header:
ERR: All unsuccessful message exchanges terminate with an ERR message. All ERR messages include a 1-byte error code followed by an error message (which may be blank).
ERR Header:
Error Codes:
MSG_AB_CONNECT: This message is sent by the Client to establish application level connection and request authentication. This message is sent by the Client to the Server to establish an application session before any other messages are sent.
MSG_AB_DISCONNECT: This message is sent by the Client to remove an application-level connection between the AppBus server and one application on the Client device.
MSG_AB_SUBSCRIBE: This message is sent when a Client application wishes to subscribe to AppBus Data Object insertion events. A subscribed application receives a MSG_AB_NOTIFY message each time a Data Object is added to the AppBus repository.
If the application has validated for secure access, it may indicate its desire to only see Data Object insertion events that occur in the secure portion of the AppBus with the SECURE_ACC indicator. A remote application may want to change the security level of its insertion event notifications during the course of a connected session. If this is the case, the application may change its subscription from secure section events only to secure section events and public section events (or vice versa) by unsubscribing (MSG_AB_UNSUBSCRIBE) and subscribing again with the new parameters.
MSG_AB_UNSUBSCRIBE: This message is sent when a Client application wishes to unsubscribe to Data Object insertion events.
MSG_AB_NOTIFY: This message is sent from the Server to subscribed Client applications to inform the applications of Data Object insertions into the AppBus repository. This message and the other notification messages are the only messages initiated by the server.
This message should have a complete list of the attribute names and corresponding values for the Data Object identified by the DO_ID.
MSG_AB_QUERY: This message is sent by the Client to perform a general query for Data Objects that correspond to the match conditions presented in the query message. Queries are defined using supported predicates including both comparison (less than, greater than, equals to, etc.) and logical (and, or, not) operators. Queries can be performed selectively on the public section, on the secure section, or on both together.
The query message uses a defined serialization format (see below) to pack predicates into byte-buffers for transmission.
Serialization format is specified for different kinds of predicates. When predicates are nested (e.g., in logical predicate operators), the inner predicates are expanded and packed in a defined order {lhs, rhs}.
For binary comparison predicates (EQUALS, LESS_THAN, LESS_THAN_EQUALS, GREATER_THAN, GREATER_THAN_EQUALS):
Integer PredicateCode (1 byte)
String AttributeName
Integer AttributeTypeCode (1 byte)
String AttributeValue
For unary comparison predicates (ATTRIBUTE_HAS_VALUE):
Integer PredicateCode (1 byte)
String AttributeName
For binary logical predicates (AND, OR):
Integer PredicateCode (1 byte)
Predicate LHS
Predicate RHS
For unary logical predicates (NOT):
Integer PredicateCode (1 byte)
Predicate LHS
AttributeTypeCodes are specified as follows:
0x01 ATTRIBUTE_STRING_VALUE
0x02 ATTRIBUTE_INTEGER_VALUE
0x03 ATTRIBUTE_TIME_VALUE
PredicateCodes are specified as follows:
0x00 PRED_EQUALS
0x01 PRED_LESS_THAN
0x02 PRED_LESS_THAN_EQUALS
0x03 PRED_GREATER_THAN
0x04 PRED_GREATER_THAN_EQUALS
0x05 PRED_ATTRIBUTE_HAS_VALUE
0x06 PRED_AND
0x07 PRED_OR
0x08 PRED_NOT
MSG_AB_CREATE_DO: This message is sent by the Client to create a new Data Object with a valid identifier. (This process does not add the object to the AppBus.)
MSG_AB_ADD_DO: This message is sent by the Client to add a Data Object to the AppBus.
MSG_AB_REMOVE_REFS: This message is typically sent by the Remote Side Connection or Remote Side Session and not by the application itself. This message is to allow for server-side processes to remove references to unneeded Data Objects.
MSG_DO_SUBSCRIBE: This message is sent when the Client wishes to subscribe to data change events from a specific Data Object. A subscribed application will receive a MSG_DO_NOTIFY message each time that the observed Data Object is modified in some way.
MSG_DO_UNSUBSCRIBE: This message is sent when a Client application wishes to no longer receive notifications with respect to updates from a particular Data Object.
MSG_DO_NOTIFY_UPD_ATT: This message is sent from the Server to the Client to inform of changes to an attribute in a particular Data Object. This message and the other notification messages are the only messages initiated by the Server. (See MSG_DO_NOTIFY_UPD_TSTAMP for a related notification message.)
The MOD_APP_ID indicates which application performed the Data Object mutation.
MSG_DO_NOTIFY_UPD_PAY: This message is sent from the Server to the Client to inform of changes to the payload of a particular Data Object.
MSG_DO_NOTIFY_UPD_TSTAMP: This message is sent from the server to the client to notify it of timestamp updates to one or more data objects. The message is used in two cases.
MSG_DO_NOTIFY_ADD_CHILD: This message is sent from the server to the client to inform of changes to the children of a particular Data Object.
MSG_DO_NOTIFY_ADD_PARENT: This message is sent from the server to the client to inform of changes to the parents of a particular Data Object.
MSG_DO_NOTIFY_REM_ATT: This message is sent from the Server to the Client to inform of removal of an attribute in a particular Data Object.
MSG_DO_NOTIFY_REM_PAY: This message is sent from the Server to the Client to inform of removal of the payload of a particular Data Object.
MSG_DO_NOTIFY_REM_CHILD: This message is sent from the server to the client to inform of changes to the children of a particular Data Object.
MSG_DO NOTIFY_REM_PARENT: This message is sent from the server to the client to inform of changes to the parents of a particular Data Object.
MSG_DO_NOTIFY_ATTACHED: This message is sent from the server to the client to inform of changes to the status of Framework attachment of a particular Data Object.
MSG_DO_REQ_ATTRIBUTES: This message is sent by the Client to request the values of specific attributes contained in a particular Data Object. A value of zero for NUM_ATT indicates that no specific attribute names will be listed in the message and that the request is for all of the attributes in the specified Data Object.
MSG_DO_REQ_PAYLOAD: This message is sent by the Client to request the value of the payload contained in a particular Data Object.
If the application has validated for secure access, it may indicate its desire to only see matches with Data Objects that reside in the secure portion of the AppBus. This is accomplished by setting the SECURE_ACC indicator to TRUE.
MSG_DO_REQ_GET_PARENTS: This message is sent by the Client to perform a specialized query on the specified data object. By passing a template Data Object ID, the Client will receive back a list of Data Object IDs that are direct parents of the specified data object. By default, these will be objects that reside in the same section (secure or public) of the AppBus as the specified data object.
If the application has validated for secure access, it may indicate its desire to only see matches with Data Objects that reside in the secure portion of the AppBus. This is accomplished by setting the SECURE_ACC indicator to TRUE.
MSG_DO_REQ_GET_CHILDREN: This message is sent by the Client to perform a specialized query on the specified data object. By passing a template Data Object ID, the Client will receive back a list of Data Object IDs that are direct children of the specified data object. By default, these will be objects that reside in the same section (secure or public) of the AppBus as the specified data object.
If the application has validated for secure access, it may indicate its desire to only see matches with Data Objects that reside in the secure portion of the AppBus. This is accomplished by setting the SECURE_ACC indicator to TRUE.
MSG_DO_UPDATE_ATTRIBUTES: This message is sent by a Client application to modify an attribute of a Data Object that exists on the Server.
MSG_DO_UPDATE_PAYLOAD: This message is sent by a Client application to modify the payload of a Data Object that exists on the Server.
MSG_DO_UPDATE_TIMESTAMP: This message is sent by a Client application to modify the timestamp of a Data Object that exists on the Server.
MSG_DO_ADD_CHILD: This message is sent by the Client to request that a parent-child association be established between the two data objects specified.
MSG_DO_REMOVE_ATTRIBUTES: This message is sent by a Client application to remove an attribute from a Data Object that exists on the Server. This message is sent by a Client application to remove with a single message multiple attributes from a Data Object that exists on the Server.
MSG_DO_REMOVE_PAYLOAD: This message is sent by a Client application to remove the payload from a Data Object that exists on the Server.
MSG_DO_REMOVE_CHILDREN: This message is sent by a Client application to disassociate selected children from a parent Data Object.
MSG_DO_REMOVE ALL_CHILDREN: This message is sent by a Client application to disassociate all children from a parent Data Object.
RPY_POSITIVE_ACK: This reply is sent by the Server side or the Client side to indicate a positive acknowledgement of an action message that does not involve returning any data.
RPY_NEGATIVE_ACK: This reply is sent by the Server side or the Client side to indicate a negative outcome in an action message that returns a true/false result. A “true” result is indicated by sending a RPY_POSITIVE_ACK, while, “false” is indicated by sending RPY_NEGATIVE_ACK. (Note that this response does NOT indicate error: Any explicit errors will trigger their own ERR messages. Thus, the client can expect to receive either RPY or ERR, not both.)
RPY_APP_CONNECTION_CRED: This reply is sent by the Server to the Client in response to a MSG_AB_CONNECT message. This response is how the Client side establishes the Application Context ID for a particular Client side application.
RPY_DO_ID_LIST: This reply is sent in response to several messages, both queries and actions, where the client receives back information about which Data Objects were affected.
If this reply is sent in response to MSG_AB_ADD_DO, then NUM_ID should equal 1. RPY_DO_ATTRIBUTES: This reply is sent from the Server to the Client in response to a MSG_DO_REQ_ATTRIBUTES and provides a list of attribute names and their corresponding values.
RPY_DO_PAYLOAD: This reply is sent from the Server to the Client in response to a MSG_DO_REQ_PAYLOAD and provides the value of the payload for a given Data Object.
RPY_DO_PARENTS: This reply is sent in response to a query to determine parents for the specified data object.
RPY_DO_CHILDREN: This reply is sent in response to a query to determine children for the specified data object.
RPY_DO_TIMESTAMP: This reply is sent in response to a query to determine a timestamp for the specified data object.
The following is a list of valid Message/Reply combinations. Various Error responses, such as INVALID_MESSAGE and UNKNOWN are applicable to nearly all messages and therefore are not enumerated here. As such any message initiator should be ready to receive these error responses at any time. More specific error messages that apply in certain circumstances are listed where they apply. Note that an incorrectly formulated query will also result in the receipt of an INVALID_MESSAGE.
Data Object Reference Flushing: Due to the fact that the server side (Remote Sessions Handler) is required to retain references to Data Objects accessed by the Remote Sessions, the client side is required to notify the server side when these references are no longer required in order that the server side may clean up unneeded references and allow for garbage collection by the VM.
Data Object Payload Caching: To reduce over-the-air bandwidth usage, the Client and Server sides may agree to do deferred fulfillment of Data Object payload data when the payload would normally be updated by a MSG_DO_NOTIFY_PAYLOAD. If deferment has been agreed to, the INVAL_ONLY may be set in the message indicating an invalidation of the payload value but not providing the new one. The new value would then be requested by the Client as needed using a MSG_DO_REQ_PAYLOAD. Note that the Server is not obligated to do this and may in fact include the payload value in the MSG_DO_NOTIFY_PAYLOAD message. Therefore, the client should be ready to handle this at any time.
Data Object Reference Management: One suggested method for determining when client-side references are no longer needed is Weak References. When the reference is garbage collected on the client side, the Weak Reference goes to null, and a message is sent across the Remote link to allow the server to remove its held reference to the corresponding Data Object
Data Object Reference Holding: The AppBus is a dynamic data buffering system. Its very nature (access to most recently used data and events) means that Data Objects will be available on the bus for an indeterminate amount of time. Additionally, once these Data Objects are no longer referenced by the AppBus framework nor by any applications, they may be garbage collected by the VM. Consequently, in order to emulate the kind of data availability and retention that a local application might have, the Remote Sessions Handler needs to retain references to accessed Data Objects until the Remote Session has indicated that they are no longer needed. (A local application would receive a list of Data Object references in a AppBus query, and as long as it retained the references, the objects would be guaranteed not to be garbage collected, but not guaranteed to remain indexed by the AppBus.) Consequently, the Remote Session has the responsibility of notifying the Remote Sessions Handler of unneeded references.
Event Subscription: Since standard method/object callback mechanisms do not function across the remote access link, a translation system is necessary to handle event subscription notifications. When a remote application chooses to receive Data Object update notifications, it creates and transmits a MSG_AB_SUBSCRIBE message for all Data Object insertion notifications or a MSG_DO_SUBSCRIBE message for individual Data Object notifications. The Remote Proxy/AppBus Session objects are responsible for AppBus event callback registration on behalf of the remote application, keeping a record of the remote application interested in the callback and transmitting the callback events to the remote application using a MSG_AB_NOTIFY message or a MSG_DO_NOTIFY message.
Event Subscription Architectures: Since the Remote Sessions Handler is responsible for event registration and transmission, an indexing/translation structure may be required. Different types of architectures may be used for this. Two possibilities are as follows:
In view of the many possible embodiments to which the principles of the present invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
| Number | Date | Country | |
|---|---|---|---|
| 61076296 | Jun 2008 | US |
