Patent Application
20080065679
With continuing reference to
In operation, the UI server 125 in this embodiment encodes information and rules about GUI functionality into the binary array(s) 126. The UI server 125 embeds the binary array(s) 126 into the source code for the compound document 202 so that, when the document 202 is rendered at the UI client 140, the UI client 140 can efficiently perform checks without having to make frequent requests to the UI server 125 for additional information. More specifically, upon receiving the initial request for a compound document 202, the AJAX server program 120 in this embodiment first communicates with the business application program 122 via an application programming interface to determine which rules are applicable for the nodes 224 in that document 202. After determining which rules are applicable, the AJAX server 120 encodes this information into the binary array(s) 126 and embeds these array(s) 126 into the markup language code for the requested compound document 202. These binary array(s) 126, in turn, contain one or more rule identifiers and an evaluation attribute for each node 224 that is a potential interface target in the compound document 202. In this way, the array(s) 126 contain all of the input that the UI client 140 will need to evaluate whether a particular GUI action is valid. In some embodiments, the present invention may also cache the rule identifiers for certain Java bean-backed elements (e.g., folder elements in a tree) on the UI server 125 to further improve efficiency.
When an end user begins to drag an object 228, the UI client 140 first communicates with the server UI 125 via AJAX to evaluate the self-contained rules for the document (i.e., relatively simple rules that pertain only to the document being dragged, such as whether a document is flagged “steady_state”). The UI server 125 passes the document ID and all applicable rules for the page to an application layer API at the server 125. The application 122 then evaluates the self-contained rules and then returns to the UI server 125 a binary array indicating which rules that the document has met (‘1’) and failed to meet (‘0’). At this point, the UI server 125 sends the binary array 126 back to the UI client 140, which inspects these values and subsequently “turns off” the target elements 224 whose rules have not been met. In this way, when the binary arrays come back from the application layer, the comparisons that occur on the client are very fast and can eliminate many trips to the server for more complete rules checking.
In addition to these checks, the UI client 140 also receives from the UI server 125 when requesting rules, information about whether or not a rule requires further server validation. For those target elements 224 that are still valid after the initial processing, the UI client 140 may also determine if they require additional server-side validation using a flag set in the element's underlying markup code. This flag indicates that bit-checking the rules at runtime succeeded, but that the client UI still needs to go back to the server to evaluate the more complex rules.
Thus, in the example web application 201 shown in
The business application program 122 begins processing the user's request by generating a list of open nodes 224 in the requested document 202. Next, at lines 308-312, the business application program 122 generates a list of rules that apply to those open nodes 224. This may include generating simple rules (e.g., child only rules) at line 310, generating complex rules (e.g., plug-in rules, such as parent child rules) at line 312, or some combination of simple and complex rules. At lines 316-318, the business application program 122 returns the generated rules to the AJAX server 120. In some embodiments, the business application program 122 may further cache the generated rules for future use at line 314.
At lines 320-322, the AJAX server 120 generates a dynamic HTML (“DHTML”) web page responsive to the user's request. This process includes rendering the compound document 202 at line 320, embedding rule identifiers for the target objects 224 in the page 202 at line 322, and creating a binary array 126 containing the returned rules and corresponding rule ID's (described in more detail with reference to
After receiving the generated web page 202 at line 328, the UI client 140 renders the compound document 202 for the user at line 329. The UI client 140 then waits for the user to interact with the web application 200. In response to a simple GUI interaction, such as the user dragging an object to a folder, the UI client 140 makes an AJAX call to the UI server 125 at line 332. That is, the UI client 140 transmits a request to the UI server 125 requesting the identity (“ID”) of the source document (i.e., the one being dragged). In response, the business application 122 evaluates the simple rules with respect to the document ID to determine which rules the document meets and which it does not meet. The web server 120 then generates a new binary array 126 at line 338 containing the results of this rule evaluation and embeds this information in a new DHTML page and binary array 126 at line 336. The UI server 125 then returns the DHTML page and binary array 126 to the UI client 140 at lines 340-342.
The UI client 140 then evaluates the new binary array 126 at lines 342-364. More specifically, the UI client 140 parses the document 202 to get the rule identifier for each potential drop target(s) 224 at line 342. Note that the rule identifier array for each drop target was created when the page was generated, and it describes which rules the drop target requires for a source to be “valid.” The UI client 140 then uses the rule IDs at line 344 to find each element in binary array 126 that corresponds to those element(s) each rule identifier in the array for that drop target. If the binary array 126 contains only a binary-true for each rule in the array for node 224 (e.g., only simple rules), the UI client indicates that the drop target is valid at line 362; otherwise, the UI client determines whether the drop target has an associated server rule at line 346.
If the UI client determines that the drop target has an associated server rule, the UI client generates a request to evaluate the rule. The server 120 receives this request at line 346 and then forwards the request to the appropriate business application 122 at line 348. The business application 122 evaluates the complex server rule and then passes the results back to the web server 120 and UI client 140 at lines 352-354. If the complex rule evaluated true for the target, the UI client 140 indicates that the drop target is valid at line 358.
If the binary array contained a binary-false value for any rule associated with the target (at line 344) or the complex rule evaluated as false (at line 358), the UI client 140 indicates that the node 224 is not a valid drop target at line 364. The UI client 140 then indicates the results of this analysis to the user at line 366.
For purposes of illustration, assume a simple web application 200 is comprised of a single compound document 202 that contains one permitted GUI interaction, drag and drop and one potential drop target 224, a folder called “target_folder”. The target_folder element 224, in turn, is associated with one rule requiring that: “source documents must be in ‘steady_state’ to be placed in this folder.” In this example, the binary rules array 126 would contain the following information:
and the binary document array 126 would contain the following information:
Thus, in this example, when the user drags a document to the “target_folder” element, the UI client 140 first checks the document array to see if there is a “1” in the array index corresponding to the rule ID. If the value is “1” the drop is allowed, otherwise it is not.
For purposes of illustration, assume an example complex web application 200 has two different types of documents (“program_document” and “standard_procedure”), and three potential drop targets (“target_folder1,” “target_folder2,” and “target_folder3”). Each target 224 has a business rule that requires “source documents must be in ‘steady_state’ to be placed in this folder.” “Target_folder2” and “target_folder3” have an additional rule that requires “source documents must be of type ‘standard_procedure’ to be placed in this folder.” “Target_folder3” has still another rule that requires “the source document's ‘project’ attribute must be equal to its parent's ‘project’ attribute.” In this simplified example, the HTML code for the drop targets would look as follows:
The serverRuleIDs attribute in this example indicates that additional server-side checking is required for the complex rule. The rules array 126 would contain the following information:
a document of type “program_document” would contain the following information:
and a document of type “standard_procedure” would contain the following information:
In this example, if the user drags a program_document to the “target_folder1” element, the UI client 140 checks the document array to see if there is a “1” in the array index corresponding to the rule ID. Because the value is “1,” the drop is allowed. Similarly, if a user drags a “standard_procedure” document to “target_folder2,” two indices will checked before a drop is allowed. Because the value of both is “1,” the drop is allowed. If a user drags a “program_document” to “target_folder3” (which contains a complex rule), when rule 0 and 1 are met a drop is still not allowed until further checking is done on the server 125. The UI client 140 facilitates this by communicating with the UI server in the background to evaluate rule 2. If all rules are met, then the drop is allowed.
This computing system 600 embodiment comprises a plurality of central processing units 610a-610d (herein generically referred to as a processor 610 or a CPU 610) connected to a main memory unit 612, a mass storage interface 614, a terminal/display interface 616, a network interface 618, and an input/output (“I/O”) interface 620 by a system bus 622. The mass storage interfaces 614, in turn, connect the system bus 622 to one or more mass storage devices, such as a direct access storage device 640 or a readable/writable optical disk drive 642. The network interfaces 618 allow the computer system 600 to communicate with other computing systems 600 over the communications medium 606. The main memory unit 612 in this embodiment also comprises an operating system 624, a plurality of application programs 626 (such as the AJAX server 120 and the business application program 122), and some program data 628.
The computing system 600 in this embodiment is a general-purpose computing device. Accordingly, the CPU's 610 may be any device capable of executing program instructions stored in the main memory 612 and may themselves be constructed from one or more microprocessors and/or integrated circuits. In this embodiment, the computing system 600 contains multiple processors and/or processing cores, as is typical of larger, more capable computer systems; however, in other embodiments, the computing system 600 may comprise a single processor system and/or a single processor designed to emulate a multiprocessor system.
When the computing system 600 starts up, the associated processor(s) 610 initially execute the program instructions that make up the operating system 624, which manages the physical and logical resources of the computer system 600. These resources include the main memory 612, the mass storage interface 614, the terminal/display interface 616, the network interface 618, and the system bus 622. As with the processor(s) 610, some computer system 600 embodiments may utilize multiple system interfaces 614, 616, 618, 620, and buses 622, which in turn, may each include their own separate, fully programmed microprocessors.
The system bus 622 may be any device that facilitates communication between and among the processors 610; the main memory 612; and the interfaces 614, 616, 618, 620. Moreover, although the system bus 622 in this embodiment is a relatively simple, single bus structure that provides a direct communication path among the system bus 622, other bus structures are within the scope of the present invention, including without limitation, point-to-point links in hierarchical, star or web configurations, multiple hierarchical buses, parallel and redundant paths, etc.
The main memory 612 and the mass storage devices 640 work cooperatively to store the operating system 624, the application programs 626, and the program data 628. In this embodiment, the main memory 612 is a random-access semiconductor device capable of storing data and programs. Although
Although the operating system 624, the application programs 626, and the program data 628 are illustrated as being contained within the main memory 612, some or all of them may be physically located on different computer systems and may be accessed remotely (e.g., via the communication media 108) in some embodiments. Thus, while the operating system 624, the application programs 626, and the program data 628 are illustrated as being contained within the main memory 612, these elements are not necessarily all completely contained in the same physical device 600 at the same time, and may even reside in the virtual memory of other computer systems 600.
The system interface units 614, 616, 618, 620 support communication with a variety of storage and I/O devices. The mass storage interface unit 614 supports the attachment of one or more mass storage devices 640, which are typically rotating magnetic disk drive storage devices, although they could alternatively be other devices, including arrays of disk drives configured to appear as a single large storage device to a host and/or archival storage media, such as hard disk drives, tape (e.g., mini-DV), writable compact disks (e.g., CD-R and CD-RW), digital versatile disks (e.g., DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), holography storage systems, high definition disks, IBM Millipede devices, and the like.
The terminal/display interface 616 is used to directly connect one or more display units 680 to the computer system 600. These display units 680 may be non intelligent (i.e., dumb) terminals, such as a cathode ray tube, or may themselves be fully programmable workstations used to allow IT administrators and users to communicate with the computing system 600. Note, however, that while the interface 616 is provided to support communication with one or more displays 680, the computer systems 600 does not necessarily require a display 680 because all needed interaction with users and other processes may occur via network interface 618.
The computing system 600 in
One exemplary computing system 600, particularly suitable for use as the web server 102, is the System i platform running the i5/OS multitasking operating system and the Websphere web application server program, all of which are produced by International Business Machines Corporation of Armonk, N.Y. Another exemplary computing system 600, particularly suitable use as the client device 104, is a personal computer running one of the Linux or Windows operating systems. However, those skilled in the art will appreciate that the methods, systems, and apparatuses of the present invention apply equally to any computing system 600 and operating system combination, regardless of whether one or both of the computer systems 600 are complicated multi user computing apparatuses, a single workstations, lap-top computers, mobile telephones, personal digital assistants (“PDAs”), video game systems, or the like.
Referring again to
The URL or “Uniform Resource Locater” may be any code or set of parameters capable of locating resources on the network. The current definition for the Internet network is defined in RFC 1945, which is incorporated herein by reference. Under this specification, the URL is typically of the format: http://somehost/somedirectory?parameters . . . “where “somehost” is the hostname position of the URL, “somedirectory” is a directory in which the web page may be found. The usual manner in which a URL is resolved into an actual IP address for a web server is through the use of a nameserver. In an Internet or intranet network, a nameserver maps hostnames in URLs to actual network addresses. An example of a nameserver is the Domain Name Service (DNS) currently implemented in the Internet. The process of having a Web client request a hostname and address from a nameserver is sometimes called resolution. In TCP/IP, the nameserver resolves the hostname into a list of one or more IP addresses which are returned to the Web client in an HTTP request. Each IP address identifies a server which hosts the requested content made by the browser.
The communication media 108 may be any suitable network or combination of networks and may support any appropriate protocol suitable for communication of data and/or code to/from multiple computing systems 600. Accordingly, the network interfaces 618 can be any device that facilitates such communication, regardless of whether the network connection is made using present day analog and/or digital techniques or via some networking mechanism of the future. Suitable communication media 108 include, but are not limited to, networks implemented using one or more of the IEEE (Institute of Electrical and Electronics Engineers) 802.3x “Ethernet” specification; cellular transmission networks; and wireless networks implemented one of the IEEE 802.11x, IEEE 802.16, General Packet Radio Service (“GPRS”), FRS (Family Radio Service), or Bluetooth specifications. Those skilled in the art will appreciate that many different network and transport protocols can be used to implement the communication medium 108. The Transmission Control Protocol/Internet Protocol (“TCP/IP”) suite contains suitable network and transport protocols.
The embodiments in
Although the present invention has been described in detail with reference to certain examples thereof, it may be also embodied in other specific forms without departing from the essential spirit or attributes thereof. For example, those skilled in the art will appreciate that the present invention is capable of being distributed as a program product in a variety of forms, and applies equally regardless of the particular type of tangible, computer-readable signal bearing medium used to actually carry out the distribution. Examples of suitable tangible, computer-readable signal bearing media include, but are not limited to: (i) non-writable storage media (e.g., read only memory devices (“ROM”), CD-ROM disks readable by a CD drive, and Digital Versatile Disks (“DVDs”) readable by a DVD drive); (ii) writable storage media (e.g., floppy disks readable by a diskette drive, CD-R and CD-RW disks readable by a CD drive, random access memory (“RAM”), and hard disk drives); and (iii) communications media (e.g., computer networks, such as those implemented using “Infiniband” or IEEE 802.3x “Ethernet” specifications; telephone networks, including cellular transmission networks; and wireless networks, such as those implemented using the IEEE 802.11x, IEEE 802.16, General Packet Radio Service (“GPRS”), Family Radio Service (“FRS”), and Bluetooth specifications). Those skilled in the art will appreciate that these embodiments specifically include computer software down-loaded over the Internet.
Embodiments of the present invention may also be delivered as part of a service engagement with a client corporation, nonprofit organization, government entity, internal organizational structure, or the like. Aspects of these embodiments may include configuring a computer system to perform, and deploying software, hardware, and web services that implement, some or all of the methods described herein. Aspects of these embodiments may also include analyzing the client's operations, creating recommendations responsive to the analysis, building systems that implement portions of the recommendations, integrating the systems into existing processes and infrastructure, metering use of the systems, allocating expenses to users of the systems, and billing for use of the systems. This service engagement may be directed at providing both the server-side operations and the client-side operations, may be limited to only server-side operations, or some combination thereof. Accordingly, these embodiments may further comprise receiving charges from other entities and associating that charge with specific users of the servers 102 and/or clients 104.
The various software components illustrated in
Those skilled in the art will appreciate that accompanying figures and this description depicted and described embodiments of the present invention, and features and components thereof. Any particular program nomenclature used in this description was merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature. Thus, for example, the routines executed to implement the embodiments of the invention, whether implemented as part of an operating system or a specific application, component, program, module, object, or sequence of instructions could have been referred to as a “program”, “application”, “server”, or other meaningful nomenclature. Indeed, other alternative hardware and/or software environments may be used without departing from the scope of the invention. Therefore, it is desired that the embodiments described herein be considered in all respects as illustrative, not restrictive, and that reference be made to the appended claims for determining the scope of the invention.
