Patent Application
20100131585
The present invention relates to displaying information, and more specifically to a client/server framework for displaying information on the client.
Portals are often used by corporations or organizations to provide a single point of access to a collection of services or programs. Portals may construct a view that amalgamates the different services or programs and displays them to a user. Portal pages are often accessed through a web browser running on an end user's computer. The end user points the web browser to a Universal Resource Locator (URL) of the portal to view the user interface (UI) provided by the portal.
The portal may construct the UI as an Hypertext Markup Language (HTML) file that displays information from the services or programs. The HTML of the UI may include links that the end user can click on, causing requests to be sent to the portal. The portal may receive the requests and direct them to the appropriate service or program for processing. The processing of the requests may result in new information being generated for display at the client. The portal may construct a UI page to display the new information and send the page to the client for display.
It can require a substantial amount of programming to create a portal that can generate UIs for information received from different sources, such as the services or programs. One attempt to address the problem of developing UIs to display information in portals has used standards to provide a frame work for requesting and receiving UI elements, which can be embedded in the portal UI. The UI elements typically include fragments of HTML code that can be inserted into an HTML document to provide the UI to the client of the end user. The first of the two standards are Web Services for Remote Portlets (WSRP) which describes how to request and transmit parts of HTML in Simple Object Access Protocol (SOAP) messages. The second standard is JSR-168 which is a standard that describes a portlet interface. Both WSRP and JSR-168 are incorporated herein by reference in their entireties. The portlets are run in a portal framework and can provide the UI elements as parts of HTML that can be transmitted using WSRP. The use of WSRP/JSR-168 can be used to provide a portal that includes a plurality of portlets providing UI elements for inclusion in a UI that is sent to the client.
Although the use of WSRP/JSR-168 aids in simplifying UI development for portals, its use can be cumbersome as a result of the web service interface of WSRP Furthermore, much of the processing of the UI is performed on the server, which can result in problems with the scalability of solutions built on WSRP/JSR-168 technology.
According to one embodiment of the present invention, there is provided a client/server system for displaying information. The system comprises a server having a processor for executing instructions stored in a computer readable memory coupled to said processor resulting in processor executed instructions, said processor executed instructions providing in said computer readable memory and a client having a client processor for executing instructions stored in a computer readable memory coupled to said client processor resulting in client processor executed instructions, said client processor executed instructions. The processor executed instructions of the server provides in said computer readable memory a fragment server for providing a plurality of fragment objects to one or more clients, each fragment object including a markup component and a management component. The client processor executed executed instructions on the client provides in said computer readable memory of the client a display for displaying a plurality of views, each view described by a markup component of a fragment object, and a fragment controller associated with said display for managing said plurality of fragment objects, said fragment controller receiving fragment objects from said server and updating a view of the plurality of views based on a markup component of the received fragment and updating one or more management components of the fragment objects based on the management component of the received fragment object.
According to another embodiment of the present invention, there is provided a method for streaming an XML document. The method includes creating an output steam writer for streaming the output of the XML document, creating an output buffer associated with the output stream writer for holding the information to write to the output stream writer, creating a default stream writer for writing available XML elements to the output buffer, determining an absence of an XML element required in the XML document and creating a marker for the XML element, replacing the marker in the output buffer when the XML element becomes available, determining that there is no more XML elements to write to the output stream, and closing the output stream writer.
a depicts in a schematic, a network environment in which the embodiments of the present disclosure described herein can be practised;
b depicts in a block diagram, hardware components that may be used for the clients 106 and the server 104;
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
As will be appreciated by one skilled in the art, the present invention may be embodied as a system, method or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.
Any combination of one or more computer usable or computer readable medium(s) may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CDROM), an optical storage device, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, or store, the program for use by or in connection with the instruction execution system, apparatus, or device.
Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
a depicts in a schematic, a network environment in which the inventions described herein can be practised. The environment 100 includes a plurality of clients 106. The clients 106 are coupled with a server 104 through a network 102 such as the Internet. Although the network is shown as the Internet, one of ordinary skill in the art will appreciate that other communication networks are possible, such as companies' local intranet. The clients 106 display information to an end user (not shown). End users can interact with the clients to control the information that is displayed. The clients 106 may receive the information to be display from the server 104. The client may communicate the end user's interactions to the server 104. The server 104 generates the information to be displayed by the different client 106. Although a single server is shown in
The clients 106 may use a browser to display the information of the server 104. The server 104 may act as a portal that provides the browser of the client 104 with a single point of access for services and programs accessible to the server 104.
b depicts in a block diagram, hardware components that may be used for the clients 106 and the server 104. The hardware 110 comprises a processor 112 that is capable of executing instructions. The processor 112 is operatively coupled to computer readable memory 116. The computer readable memory may store both data information as well as instructions that are executed by the processor 112. The processor 112 and memory 116 may be operatively coupled through a bus 114. A network interface 118 may also be operatively coupled to the processor through the bus 114. The network interface 118 couples the hardware 110 to the network 102. An input/output (I/O) interface 120 is also operatively coupled to the bus 114. The (I/O) interface 120 may connect to input and output devices such as a keyboard, video, mouse (KVM) 122. One of ordinary skill in the art will appreciate that a KVM 122 may not be required, or may be replaced with different means for inputting and outputting information.
As described further herein, a view is described by a markup component of a fragment object. The browser on the client may include a fragment controller that manages the views displayed in the pagelet. The client side fragment controller allows individual views to be updated without requiring the entire pagelet to be updated or reloaded. In addition to the markup component, the fragment object includes management components that may be used by the client-side fragment controller for managing the fragment objects that are associated with the pagelet being displayed.
In addition to the rendering component 312 and the DOM 314, the browser 302 includes fragment objects 308a, 308b, 308c (collectively referred to as fragment objects 308) that have been loaded into memory. The fragment objects 308 reference the markup describing the views 306 which is stored in the DOM. The browser 302 further includes a fragment controller 310 for managing the views 206 of the pagelet 204. The fragment controller 310 also manages the fragment objects 308 as described further herein. The fragment controller 310 may manage the views by interacting with the DOM to modify nodes of the DOM that include the views currently displayed. The application programming interface (API) for manipulating a browser's DOM is well known in the art.
An end user may direct the browser 302 to a portal running on a server. The portal provides the pagelet 204 to the browser 302. The initial pagelet 204 includes references to fragment objects 308 in a layout. The layout may be, for example an HTML table with <div> tags, where each <div> tag references a fragment object 308. The pagelet may also include the code for the fragment controller 310. When the browser 302 receives the pagelet, it loads the fragment controller 310. With the fragment controller 310 loaded in the browser 302, the fragment objects 308 referenced in the pagelet 204 are retrieved from the server. The fragment controller 310 processes the received fragments and manipulates the browser's DOM 314 to display the views 206 in the layout of the pagelet 204. Alternatively, as an optimization to reduce the amount of calls between the fragment controller and the server, the initial view of each fragment may be retrieved by the fragment server. Subsequent interactions with the views and fragment objects may be performed by the fragment controller.
The fragment 400 is an extensible markup language (XML) document that is used by the fragment controller 310 to load a corresponding fragment object 308. A fragment 400 corresponds to a fragment object 308. As depicted in
The markup component 402 includes tags describing the markup of the view associated with the fragment. The markup of the view may include HTML code, and JavaScript code. The markup may include cascading style sheet (CSS) information for formatting the HTML code. The view information is stored in an XML element, for example a <markupstring>. The following is a schema for a markup component of a fragment 400.
Elements of the markup component 402 of the fragment may include:
In addition to the markup component element, a fragment 400 may include a state element 406 that includes information regarding the current state of the view of the fragment. The state should include all of the information necessary for the fragment producer to recreate the current view. In an exemplary embodiment of a fragment the state information is stored as a Base 64 blob. It is possible that the state element store the state information in a different form.
The fragment 400 may also include a custom property element 408. Custom properties of a fragment may provide control for the customization of the fragment 400. The fragment 400 declares custom properties using meta/customProperties elements, which contain information for enumerating, editing and validating the properties and their values. The actual customization of the properties is held in a fragment/custom element which may have one parameter element per custom property. Custom properties may be overridden by a fragment reference or a page/fragmentInstance. Custom properties are encoded as query-values in the base URI request for a fragment. In a secure environment, customizations, which may be encoded in the base URI, are encrypted to prevent tampering. The following listing is a schema highlighting the custom properties elements of a fragment.
In addition to the custom properties, a fragment 400 may also include a transient properties component 410. The transient properties are a form of scoped shared state that can be shared between fragment objects 308. The scope of transient properties may be either page or application. The page scope distributes transient property updates to the siblings and descendents of the fragment. Since fragments may include other fragments as subfragment, the distribution of updates to siblings and descendants allow the fragment to control how the sub-fragment will behave in the page. The following listing is schema highlighting a transient property elements of a fragment.
Transient properties 410 allow for inter fragment co-ordination. If more information is required to be exchanged between fragments, it can be done through an event frame work. Fragments 400 may include an event component 412. The event component 412 may register an event listener of the fragment object with the fragment controller 310. When the corresponding event is raised a message is passed to the registered event listener of the fragment object. In addition to registering event listeners with the fragment controller 310, the event component 412 may also describe the events that the fragment (or more particularly, the fragment object) can raise. When a fragment object raises an event, an associated payload is passed to the appropriate event listeners of other fragment objects 308. One skilled in the art will appreciate that the message may be passed to the appropriate event listeners in various ways, for example, as described above a fragment may define an event listener or handler for a specific event that is called when the specific event is raised. Alternatively, the fragment controller 310 may pass the raised event to the fragment objects 308 which determine whether to process the event or not. A schema of the event component is shown in the following listing.
where:
The fragment controller 310 manages the states of all of the fragment objects 308. The state of a fragment object may change based on end user interactions with the view of the fragment object 308. The state may also be changed when the fragment object is updated with a new fragment or markup component. Additionally the state may be changed as a result of transient properties and events of other fragments as well as the end users interactions with them. The fragment controller 310 includes a state manager 504 for managing the state of all of the fragment objects 308. The fragment controller 310 also includes a transient manager 508 for managing the transient properties of all of the fragment objects 308. The transient manager 508 passes updated transient properties to any fragment objects 308 that have transient properties with the same name. The fragment controller 310 further includes an event manager 510 for managing the event of all of the fragment objects 308. Fragment objects 308 can raise events using the event manager 510, which then distributes the event to the appropriate fragment objects 308.
The server may further include a plurality of fragment producers 610 that produce the fragment documents. The fragment producers 610 may construct the fragment documents based on information received from the fragment controller 310 which may be encoded into the request URI.
The use of fragments to provide embeddable UI elements to the client allows fragments to be included within fragments as subfragments. The fragment server may be required to combine the subfragment into the parent fragment prior to returning the whole fragment to the client. The fragment server can process the fragments and subfragments as XML documents and merge multiple XML documents into a single XML document, which is returned as the fragment to the client.
The fragment server may need to merge multiple XML documents into a single document. In order to reduce the overhead necessary to complete the processing it is desirable to use an XML stream. However, it is difficult to use an XML stream to combine separate XML elements or sections together into an output stream in an order that differs from the order in which they are available.
If all of the XML portions are available at the time the output stream is being written, all of the XML elements can be written to the output stream in the order required by the merged XML document. It is more complex to create the merged XML document using an output writing stream when not all of the XML elements 902, 904, 906 are available at the time of writing to the output steam.
The XML processing engine may incorporate the above method for streaming a well formed XML document from different XML elements that may not all be available at the beginning of the output streaming. The streamer may include an external facing XMLStreamWriter (W) object that outputs the final XML document. When a new marker is created, a new XMLStreamWriter (Wn+1) and a new internal, or marker, buffer (Bn+1) is also created. Any existing namespace context is assigned to this new writer (Wn+1). Switching from one marker to another selects the right XMLStreamWriter and makes it the active one for writing to the output buffer associated with the external facing stream writer (W), or the output stream writer). New markers can be created anywhere at any time, whenever they are needed; however once a marker is created, it is not possible to write XML to the previous buffer. This ensures that the output XML document will be well formed. If needed, or desirable, the final output streaming may start as soon as contiguous buffers are known to be finished. These buffers can then be discarded afterward.
When merging XML components to form the output XML document, as described above, it may be required, or desirable to merge XML from various sources with a master XML document based on conditions that dictate whether the XML source must be included in the final result or not. The source that is to be excluded from the result should not be generated when possible for performance reasons. The conditions for merging sources may need to be validated against the current state of the merged document. As a result, the condition validation should take into account sources that have already been merged.
In order to provide a simple rules based method for generating the merged XML document, an XML source may be used. The XML source can be read using an XML reader, for example as provided by StAX, to read the XML document. The XML source streams the XML document as the XML reader is reading it. As such it is possible to generate the XML document as it is being read. The XML source may include rules for merging the XML pieces together. The following is a pseudo code listing of a sample program for providing an XML reader for reading an XML document.
As can be seen from the above pseudo code listing a new XML reader is created for the merged document. With the merge reader created, the master document that the XML sources are to be merged with is assigned to the reader. The sources are then merged into the document by setting the rules under which the XML documents will be added. As a result, if a source does not meet the rule it is not included in the merged document, saving overhead and increasing performance. For example, source4 will be merged into the XML document, under <source3>, if <text3> does not exist. Assuming that <text3> does exist in the merged document, source4 will not be added. Since the rule is used, the XML processing engine does not need to read or process source4.
The XML processing engine may include modules for providing a rules-based XML merge reader as described above. The XML processing engine may also include a module to provide streaming re-ordering of XML elements. The rules-based XML merge reader may use streaming re-ordering to provide the merged XML document.
In addition to merging XML documents and re-ordering XML elements as described above, the XML processing engine can provide transactional writing of XML documents to an output stream. The transactional processing allows parts of an XML document to be placed in an output stream, and later removed from the output stream if necessary (rollback) or left (commit).
In the context of XML output streaming, the “transaction” starts when the output stream writer is positioned after a start element location. All subsequent API calls are considered as part of that unit. That unit of instructions can be either committed or rolled back. It is also possible to start a new transaction inside an existing unit of transaction. However, the committed inner unit is subject to the outer committed or rolled back transaction.
The transactional APIs may be added to the StAX APIs. The transactional StAX APIs include:
The begin( ) must be called before commit( ) or rollback( ), and when the position in the output stream is after an opened start element. A begin( ) call can be invoked inside another started transaction; multi-levels of nested transactions. Each begin( ) call must eventually be balanced with either a commit( ) or rollback( ) call. Any number of nested transactions can be performed, however the memory consumption will increase as the number of nested transactions increases. After a commit( ) or a rollback( ) call, the XML is considered well-formed, and final output streaming can start as soon as level 1 transactions are committed, that is transactions that are not nested.
