U.S. patent application number 11/261016 was filed with the patent office on 2007-05-03 for system and method for dynamically updating web pages using messaging-oriented middleware.
This patent application is currently assigned to International Business Machines Corporation. Invention is credited to Gerard John Buttner, Chitra Dorai, Ahmad-Sameh Afif Fakhouri, Daniel A. Gisolfi, Jianren Li.
Application Number | 20070100844 11/261016 |
Document ID | / |
Family ID | 37997799 |
Filed Date | 2007-05-03 |
United States Patent
Application |
20070100844 |
Kind Code |
A1 |
Buttner; Gerard John ; et
al. |
May 3, 2007 |
System and method for dynamically updating web pages using
messaging-oriented middleware
Abstract
System, computer implemented method and computer program product
for dynamically updating a Web page using browser-based messaging.
A system for dynamically updating a Web page using browser-based
messaging includes a Web page that includes a plurality of Web
messaging tags, and a selected data model that can be bound to the
Web messaging tags, and at least one messaging client for accepting
at least one message from a message server and for processing the
accepted at least one message into the selected data model.
Inventors: |
Buttner; Gerard John; (Stony
Point, NY) ; Dorai; Chitra; (Chappaqua, NY) ;
Fakhouri; Ahmad-Sameh Afif; (New Rochelle, NY) ;
Gisolfi; Daniel A.; (Hopewell, NY) ; Li; Jianren;
(Valhalla, NY) |
Correspondence
Address: |
DUKE. W. YEE
YEE & ASSOCIATES, P.C.
P.O. BOX 802333
DALLAS
TX
75380
US
|
Assignee: |
International Business Machines
Corporation
Armonk
NY
|
Family ID: |
37997799 |
Appl. No.: |
11/261016 |
Filed: |
October 28, 2005 |
Current U.S.
Class: |
1/1 ; 707/999.1;
707/E17.119 |
Current CPC
Class: |
G06F 16/957
20190101 |
Class at
Publication: |
707/100 |
International
Class: |
G06F 7/00 20060101
G06F007/00 |
Claims
1. A system for dynamically updating a Web page using browser-based
messaging, comprising: a Web page that includes a plurality of Web
messaging tags, and a selected data model that can be bound to the
Web messaging tags; and at least one messaging client for accepting
at least one message from a message server and for processing the
accepted at least one message into the data model.
2. The system according to claim 1, wherein the plurality of Web
messaging tags comprises a plurality of Web message tags in at
least one of Java.TM. Server Page and Hyper Text Markup
Language.
3. The system according to claim 1, wherein the plurality of Web
messaging tags comprises Web messaging tags for configuring a port
number of the messaging server, for selecting a messaging client
type, for binding messaging topic and property to the data model on
the Web page, and for generating JavaScript.TM. code.
4. The system according to claim 1, wherein the selected data model
comprises an On Demand Client Browser Framework data model.
5. The system according to claim 1, wherein the at least one
messaging client comprises one of a JavaScript.TM. messaging client
type and a Java.TM. Applet messaging client type for accepting the
at least one message from the messaging server, for processing the
accepted at least one message, and for updating the accepted at
least one message into the selected data model.
6. The system according to claim 5, wherein the messaging client
comprises the Java.TM. Applet type, and wherein the system further
comprises JavaScript.TM. and Java.TM. libraries for accepting the
at least one message from the messaging server, for processing the
accepted at least one message, and for updating the accepted at
least one message into the selected data model.
7. The system according to claim 5, and further comprising a
server-side library for handling communication with the at least
one messaging client.
8. The system according to claim 2, wherein a plurality of Web
messaging attributes comprises a plurality of Web messaging
attributes in Hyper Text Markup Language for dynamically updating
data directly into a Document Object Model on the Web page.
9. A computer implemented method for dynamically updating a Web
page using browser-based messaging, comprising: providing a Web
page that includes a plurality of Web messaging tags, and a
selected data model that can be bound to the Web messaging tags;
establishing a connection to a messaging server; subscribing to at
least one topic from the messaging server; receiving at least one
message relating to the at least one subscribed topic from the
message server; and updating the received at least one message into
the data model to update the at least one Web page.
10. The computer implemented method according to claim 9, wherein
providing a Web page that includes a plurality of Web Messaging
tags and a selected data model that can be bound to the Web
messaging tags, comprises: providing a plurality of Web messaging
tags in at least one of Java.TM. Server Page and Hyper Text Markup
Language.
11. The computer implemented method according to claim 9, wherein
providing a Web page that includes a plurality of Web Messaging
tags and a selected data model that can be bound to the Web
messaging tags, comprises: providing a plurality of Web messaging
tags for configuring a port number of the messaging server, for
selecting a messaging client type, for binding messaging topic and
property to the data model on the Web page, and for generating
JavaScript.TM. code.
12. The computer implemented method according to claim 9, wherein
the selected data model comprises an On Demand Client Browser
Framework data model.
13. The computer implemented method according to claim 9, and
further comprising: selecting a messaging client of one of a
JavaScript.TM. messaging client type and a Java.TM. Applet
messaging client type for accepting the at least one message from
the messaging server, for processing the accepted at least one
message, and for updating the accepted at least one message into
the selected data model.
14. The computer implemented method according to claim 13, wherein
selecting a messaging client of one of a JavaScript.TM. messaging
client type and a Java.TM. Applet messaging client type comprises
selecting a messaging client of a Java.TM. Applet messaging client
type, and wherein the method further comprises: providing
JavaScript.TM. and Java.TM. libraries for accepting the at least
one message from the messaging server, for processing the accepted
at least one message, and for updating the accepted at least one
message into the selected data model.
15. The computer implemented method according to claim 9, and
further comprising: providing a server-side library for handling
communication with the at least one messaging client.
16. A computer program product, comprising: a computer usable
medium having computer usable program code for dynamically updating
a Web page using browser-based messaging, the computer program
product comprising: computer usable program code configured for
providing a Web page that includes a plurality of Web messaging
tags, and a selected data model that can be bound to the Web
messaging tags; computer usable program code configured for
establishing a connection to a messaging server; computer usable
program code configured for subscribing to at least one topic from
the messaging server; computer usable program code configured for
receiving at least one message relating to the at least one
subscribed topic from the message server; and computer usable
program code configured for updating the received at least one
message into the data model to update the Web page.
17. The computer program product according to claim 16, wherein the
computer usable program code configured for providing a Web page
that includes a plurality of Web messaging tags, and a selected
data model that can be bound to the Web messaging tags, comprises:
computer usable program code configured for providing the plurality
of Web messaging tags in one of Java.TM. Server Page or Hyper Text
Markup Language.
18. The computer program product according to claim 16, wherein the
computer usable program code configured for providing a Web page
that includes a plurality of Web Messaging tags, and a selected
data model that can be bound to the Web messaging tags, comprises:
computer usable program code configured for providing a plurality
of Web messaging tags for configuring a port number of the
messaging server, for selecting a messaging client type, for
binding messaging topic and property to the data model on the Web
page and for generating JavaScript.TM. code.
19. The computer program product according to claim 16, and further
comprising: computer usable program code configured for selecting a
messaging client type of one of JavaScript.TM. and Java.TM. Applet
for accepting the at least one message from the messaging server,
for processing the accepted at least one message, and for updating
the accepted at least one message into the selected data model.
20. A computer implemented method for dynamically updating a Web
page, comprising: providing a computer infrastructure operable to:
serve a Web page that includes a plurality of Web messaging tags,
and an On Demand Client Browser Framework model which can be bound
to the plurality of Web messaging tags; and publishing at least one
message for broadcast to at least one Web messaging client that has
subscribed to at least one message topic.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates generally to the data
processing field, and more particularly, to a system, computer
implemented method and computer program product for dynamically
updating a Web page using browser-based messaging.
[0003] 2. Description of the Related Art
[0004] The Web has created an incredible growth environment by
making business applications easy to deploy, manage and access. As
a result, the Web has replaced the client-server model fairly
quickly. Based on open standards such as Java.TM., J2EE.TM.
(Java.TM. 2 Platform Enterprise Edition), HTTP (Hyper Text Transfer
Protocol), HTML (Hyper Text Markup Language) and JavaScript.TM.,
and the ubiquitous browser; enterprises are able to open up their
"backends" and create an environment where employees and customers
can readily access a variety of applications from any location at
any time.
[0005] On the other hand, however, the Web has created a user
experience that is considered to be a step backward from what
existed in the client-server world. There, clients enjoyed
arbitrary richness as provided by the hosting GUI (Graphical User
Interface)-based operating system such as Microsoft.RTM.
Windows.RTM.. Although Web interfaces can be made very graphical,
the actual interactivity model is very restrictive. The perceptible
performance gap and full screen refreshes between most interactions
with the user, for instance, remain an important issue. ActiveX.TM.
controls and the like attempt to remedy this in various ways but
have failed to gain ubiquitous usage because of issues relating to
the development model, security, performance and compatibility.
Only Web pages with HTML, DHTML (Dynamic HTML), CSS (Cascading
Style Sheets) and JavaScript.TM. have remained ubiquitous and
widely used. Java.TM. applets to some extent can perform many tasks
on browsers despite the difficulty of accommodating the variety of
browsers with different JVMs (Java.TM. Virtual Machines) in use on
the Internet as well as security restrictions.
[0006] The On-Demand Client Browser Framework (OBF) is a software
framework which implements browser-based Service Data Objects
(SDO), a Java.TM. standard model using JavaScript.TM., and includes
a set of JavaScript.TM. UI widgets as well as a small server-side
Java.TM. library for streaming data. The OBF tries to address many
of the interactivity issues raised by the Web, but remains rooted
in the traditional Web page architecture.
[0007] Based on an advanced usage of JavaScript in modern browsers
such as IE 5.5 and above, Netscape.RTM. 6 and above, and
Mozilla.TM. 1.x, the OBF seeks to create "Web pages that last
longer". Composed with a dynamic model that packs more data, OBF
enabled Web pages are able to sustain longer interactions with an
end user without requiring roundtrips back to the server. By
creating what effectively is an MVC (Model View Controller) model
inside the page, a developer is able to define a working data set
and a set of controls that dynamically bind to that data. Thus, the
same data object can be shared among different widgets on the same
page.
[0008] Consider, for example, a Web application for managing a
user's stock portfolio. In this example, stock prices as well as
asset allocation (percentage of the value of a particular stock in
the total portfolio, i.e., price*shares/total value) needs to be
displayed for users. A scrollable table display of data (sometimes
referred to as a DataGrid) can be used to display asset allocation
(stock issue, volume) for example, and the current price for a
particular stock; and a pie chart can also be used to display the
same information to a user. This data can be shared by the DataGrid
and the pie chart at the same time. When any data object in the
model is updated, the binding component in the OBF will notify the
user interface objects, which are bound to the data object, to
refresh themselves to reflect the latest changes. The user can then
interact with the working data set, using the set of controls, and
until a roundtrip back to the server is really necessary (e.g., to
submit data, complete a transaction, etc.), the user benefits from
response times and a freedom to interact with the page that is
uncommon in regular Web pages.
[0009] While the OBF is able to cache a certain amount of data
inside its data model on the Web page at the time of initial page
loading, and can greatly improve the usability (interactivity and
responsiveness) of Web pages, the data set that can be cached is
still limited due to client computer memory constraints and
incurred initial network delay from downloading a large data set.
In addition, OBF-enabled Web pages lack an intrinsic facility for
keeping the Data Objects current while they are on the user's
screen. The above-described Web application of a stock portfolio is
a good example of this. In this case, stock prices are changing
with time and the Web pages have to be updated to keep up with the
changes. In a standard Web application, data on a Web page can only
be updated if the entire page is re-retrieved from the server. This
is inefficient in that it requires a round trip of a
request-response pair for each data refresh, and also loses any
updates the user may have made on a different part of the same
page.
[0010] In the OBF, one way of updating data in the model is made
possible by using a browser-based WebService control. However, a
user has to initiate a WebService call to update a data page by
clicking a button or hyperlink on a Web page. It essentially is a
pull-based model which requires user actively seeking the data and
refreshing the Web page often.
[0011] A competitor of the OBF is AJAX. AJAX stands for
Asynchronous JavaScript.TM. and XML (Extensible Markup Language), a
term describing a Web development approach to creating interactive
Web applications using a combination of technologies: [0012] HTML,
or XHTML (Extensible HTML), and CSS for information presentation
[0013] The Document Object Model manipulated through JavaScript.TM.
to dynamically display and interact with the information presented
[0014] The XMLHttpRequest object to retrieve data asynchronously
from the Web server on the background.
[0015] The technologies used by AJAX have been available since
1997, however, several recent high-profile offerings from
Google.TM. are AJAX applications, including Gmail.TM., Google.TM.
Maps, Google.TM. Groups, etc. This has helped raise the profile of
the technique and has made AJAX more popular among Internet
developers.
[0016] Related to AJAX, a known solution of browser-based messaging
is provided by ActiveMQ.TM. through its REST API (Application
Program Interface). ActiveMQ.TM. is an open source JMS 1.1 provider
and messaging middleware. AJAX support in ActiveMQ.TM. builds on
top of the REST connector for ActiveMQ.TM., which allows Web
capable devices to send or receive messages over JMS (Java.TM.
Message Service).
[0017] Although OBF and AJAX share the same goals towards improving
the usability of Web applications and use many of the same
technologies (such as JavaScript.TM., HTML DOM (Document Object
Model), CSS, etc.), there are considerable differences between
them. OBF is well-architected using an MVC model on Web pages, as
described above, with the model bound to widgets, thus allowing
data sharing among widgets. By doing so, there is a clean
separation between the data model and widgets. Any data update from
the Web server is always made against the model. The model can be
bound to any widget. With tooling help, Web page development using
OBF can be made very flexible and easy to drag and drop. In
contrast, there is no formal MVC model in AJAX, which uses XML as
its data storage. The Web messaging of ActiveMQ.TM. uses
XmlHttpRequest to make calls on the REST API to send and receive
messages, and then an AJAX JavaScript.TM. library will manipulate
the messages for presentation without involving a data model.
[0018] There is, accordingly, a need for a system and computer
implemented method for dynamically updating a Web page using
browser-based messaging to improve the usability and interactivity
of Web applications.
SUMMARY OF THE INVENTION
[0019] The present invention provides a system, computer
implemented method and computer program product for dynamically
updating a Web page using browser-based messaging. A system for
dynamically updating a Web page using browser-based messaging
comprises a Web page that includes a plurality of Web messaging
tags, and a selected data model that can be bound to the Web
messaging tags, and at least one messaging client for accepting at
least one message from a message server and for processing the
accepted at least one message into the selected data model.
BRIEF DESCRIPTION OF THE DRAWINGS
[0020] The novel features believed characteristic of the invention
are set forth in the appended claims. The invention itself,
however, as well as a preferred mode of use, further objectives and
advantages thereof, will best be understood by reference to the
following detailed description of an illustrative embodiment when
read in conjunction with the accompanying drawings, wherein:
[0021] FIG. 1 depicts a pictorial representation of a network of
data processing systems in which aspects of the present invention
may be implemented;
[0022] FIG. 2 depicts a block diagram of a data processing system
in which aspects of the present invention may be implemented;
[0023] FIG. 3 is a block diagram that schematically illustrates a
Web Messaging architecture according to an exemplary embodiment of
the present invention;
[0024] FIG. 4 is a block diagram that schematically illustrates a
JavaScript.TM. Web Messaging implementation of the Web Messaging
architecture illustrated in FIG. 3 according to an exemplary
embodiment of the present invention;
[0025] FIG. 5 is a block diagram that schematically illustrates a
Java.TM. Applet Web Messaging implementation of the Web Messaging
architecture illustrated in FIG. 3 according to an exemplary
embodiment of the present invention;
[0026] FIG. 6 is a diagram that schematically illustrates
interaction between various components and layers of a Web
Messaging control according to an exemplary embodiment of the
present invention; and
[0027] FIG. 7 is a flowchart that illustrates a method for
dynamically updating a Web page according to an exemplary
embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0028] FIGS. 1-2 are provided as exemplary diagrams of data
processing environments in which embodiments of the present
invention may be implemented. It should be appreciated that FIGS.
1-2 are only exemplary and are not intended to assert or imply any
limitation with regard to the environments in which aspects or
embodiments of the present invention may be implemented. Many
modifications to the depicted environments may be made without
departing from the spirit and scope of the present invention.
[0029] With reference now to the figures, FIG. 1 depicts a
pictorial representation of a network of data processing systems in
which aspects of the present invention may be implemented. Network
data processing system 100 is a network of computers in which
embodiments of the present invention may be implemented. Network
data processing system 100 contains network 102, which is the
medium used to provide communications links between various devices
and computers connected together within network data processing
system 100. Network 102 may include connections, such as wire,
wireless communication links, or fiber optic cables.
[0030] In the depicted example, server 104 and server 106 connect
to network 102 along with storage unit 108. In addition, clients
110, 112, and 114 connect to network 102. These clients 110, 112,
and 114 may be, for example, personal computers or network
computers. In the depicted example, server 104 provides data, such
as boot files, operating system images, and applications to clients
110, 112, and 114. Clients 110, 112, and 114 are clients to server
104 in this example. Network data processing system 100 may include
additional servers, clients, and other devices not shown.
Specifically, clients may connect to any member of a network of
servers which provide equivalent content.
[0031] In the depicted example, network data processing system 100
is the Internet with network 102 representing a worldwide
collection of networks and gateways that use the Transmission
Control Protocol/Internet Protocol (TCP/IP) suite of protocols to
communicate with one another. At the heart of the Internet is a
backbone of high-speed data communication lines between major nodes
or host computers, consisting of thousands of commercial,
government, educational and other computer systems that route data
and messages. Of course, network data processing system 100 also
may be implemented as a number of different types of networks, such
as for example, an intranet, a local area network (LAN), or a wide
area network (WAN). FIG. 1 is intended as an example, and not as an
architectural limitation for different embodiments of the present
invention.
[0032] With reference now to FIG. 2, a block diagram of a data
processing system is shown in which aspects of the present
invention may be implemented. Data processing system 200 is an
example of a computer, such as server 104 or client 110 in FIG. 1,
in which computer usable code or instructions implementing the
processes for embodiments of the present invention may be
located.
[0033] In the depicted example, data processing system 200 employs
a hub architecture including north bridge and memory controller hub
(MCH) 202 and south bridge and input/output (I/O) controller hub
(ICH) 204. Processing unit 206, main memory 208, and graphics
processor 210 are connected to north bridge and memory controller
hub 202. Graphics processor 210 may be connected to north bridge
and memory controller hub 202 through an accelerated graphics port
(AGP).
[0034] In the depicted example, local area network (LAN) adapter
212 connects to south bridge and I/O controller hub 204. Audio
adapter 216, keyboard and mouse adapter 220, modem 222, read only
memory (ROM) 224, hard disk drive (HDD) 226, CD-ROM drive 230,
universal serial bus (USB) ports and other communications ports
232, and PCI/PCIe devices 234 connect to south bridge and I/O
controller hub 204 through bus 238 and bus 240. PCI/PCIe devices
may include, for example, Ethernet adapters, add-in cards and PC
cards for notebook computers. PCI uses a card bus controller, while
PCIe does not. ROM 224 may be, for example, a flash binary
input/output system (BIOS).
[0035] Hard disk drive 226 and CD-ROM drive 230 connect to south
bridge and I/O controller hub 204 through bus 240. Hard disk drive
226 and CD-ROM drive 230 may use, for example, an integrated drive
electronics (IDE) or serial advanced technology attachment (SATA)
interface. Super I/O (SIO) device 236 may be connected to south
bridge and I/O controller hub 204.
[0036] An operating system runs on processing unit 206 and
coordinates and provides control of various components within data
processing system 200 in FIG. 2. As a client, the operating system
may be a commercially available operating system such as
Microsoft.RTM. Windows.RTM. XP (Microsoft.RTM. and Windows.RTM. are
trademarks of Microsoft Corporation in the United States, other
countries, or both). An object-oriented programming system, such as
the Java.TM. programming system, may run in conjunction with the
operating system and provides calls to the operating system from
Java.TM. programs or applications executing on data processing
system 200 (Java.TM. is a trademark of Sun Microsystems, Inc. in
the United States, other countries, or both).
[0037] As a server, data processing system 200 may be, for example,
an IBM.RTM. eServer pSeries.RTM. computer system, running the
Advanced Interactive Executive (AIX.RTM.) operating system or
LINUX.RTM. operating system (eServer, pSeries.RTM. and AIX.RTM. are
trademarks of International Business Machines Corporation in the
United States, other countries, or both while Linux.RTM. is a
trademark of Linus Torvalds in the United States, other countries,
or both). Data processing system 200 may be a symmetric
multiprocessor (SMP) system including a plurality of processors in
processing unit 206. Alternatively, a single processor system may
be employed.
[0038] Instructions for the operating system, the object-oriented
programming system, and applications or programs are located on
storage devices, such as hard disk drive 226, and may be loaded
into main memory 208 for execution by processing unit 206. The
processes for embodiments of the present invention are performed by
processing unit 206 using computer usable program code, which may
be located in a memory such as, for example, main memory 208, read
only memory 224, or in one or more peripheral devices 226 and
230.
[0039] Those of ordinary skill in the art will appreciate that the
hardware in FIGS. 1-2 may vary depending on the implementation.
Other internal hardware or peripheral devices, such as flash
memory, equivalent non-volatile memory, or optical disk drives and
the like, may be used in addition to or in place of the hardware
depicted in FIGS. 1-2. Also, the processes of the present invention
may be applied to a multiprocessor data processing system.
[0040] In some illustrative examples, data processing system 200
may be a personal digital assistant (PDA), which is configured with
flash memory to provide non-volatile memory for storing operating
system files and/or user-generated data.
[0041] A bus system may be comprised of one or more buses, such as
bus 238 or bus 240 as shown in FIG. 2. Of course the bus system may
be implemented using any type of communications fabric or
architecture that provides for a transfer of data between different
components or devices attached to the fabric or architecture. A
communications unit may include one or more devices used to
transmit and receive data, such as modem 222 or network adapter 212
of FIG. 2. A memory may be, for example, main memory 208, read only
memory 224, or a cache such as found in north bridge and memory
controller hub 202 in FIG. 2. The depicted examples in FIGS. 1-2
and above-described examples are not meant to imply architectural
limitations. For example, data processing system 200 also may be a
tablet computer, laptop computer, or telephone device in addition
to taking the form of a PDA.
[0042] The present invention is directed to a system, computer
implemented method and computer program product for dynamically
updating a Web page using browser-based messaging in order to
improve the usability and interactivity of Web applications.
According to an exemplary embodiment of the present invention, Web
page content is dynamically updated with On Demand Client Browser
Framework (OBF) enabled Web pages. More particularly, On Demand
Client (ODC)-enabled Web page data models are updated using a new
technique, referred to as "Web Messaging", that reduces round trips
to a Web server by employing a publish/subscribe message broker to
push updates to a client.
[0043] Real time update of data that changes often in a page is
more efficient via push mode than an entire page refresh, and also
allows for the preservation of local user changes and is more user
friendly than updating via Web Service. Web Messaging is an
extension of the publish/subscribe messaging system and employs a
different paradigm from that of Web Service. The publish/subscribe
messaging model is a push-based model where messages are
automatically broadcast to users, for example, as Web pages,
without the users having to issue requests for new messages.
[0044] According to an exemplary embodiment of the present
invention, a Web Messaging control, comprising several JSF
(Java.TM. Server Faces) tags, enables end users to access
publish/subscribe messaging systems from Web browsers, and allows
data on Web pages to be dynamically updated. JSF is a user
interface (UI) framework for Java.TM. Web applications, and a new
J2EE Standard. JSF is designed to significantly ease the burden of
writing and maintaining Java.TM. Web applications, and includes a
set of controls, including common Web controls (command button,
input text, radio button, etc.) and extended controls (Data table,
TabbedPanel, RichText, FileUpload) and related infrastructure.
These JSF tags for Web Messaging can be deployed on a Web page
using JSF tooling and allows a Web developer to configure the
control (specifying messaging server port number, message topic and
attributes, etc.), wherein the JSF tags include a set of Java.TM.
programs for generating necessary JavaScript.TM. and HTML code as
well as JavaScript.TM. library includes on Web pages.
[0045] According to a further exemplary embodiment of the
invention, a computer program product stored on a computer usable
medium is provided that will update the OBF model on a Web page by
pushing real time information from a messaging system. The
messaging data will then be rendered using JSF UI controls (such as
DataGrid and InputText, etc.). This cleanly separates the
population of a data model from rendering the data on a JSP
(JavaServer.TM. Pages).
[0046] According to a further exemplary embodiment of the
invention, a message published on a Messaging server is transported
to a Web page, processed and the model updated on the page, which
eventually will cause UI widgets to refresh themselves due to
binding and will allow end users to see data changes in the Web
application. As will be explained more fully hereinafter, two
flavors of Web Messaging implementations are supported according to
exemplary embodiments of the invention, including Java.TM. Applet
and JavaScript.TM. Web messaging clients.
[0047] According to yet another exemplary embodiment of the present
invention, a method is provided for deploying an application that
allows data to be dynamically updated on a Web page. The method
includes providing a computer infrastructure operable to update a
data model on a Web page that can generate necessary HTML and
JavaScript.TM. code, and that includes JavaScript.TM. library or
Java.TM. Applet, wherein JavaScript.TM. or Java.TM. Applet code can
transport a message published on a messaging server to a Web page,
process the message and update the model on the page, which will
eventually cause the UI widgets to refresh themselves due to
binding.
[0048] As was briefly discussed above, the OBF is able to cache a
certain amount of data inside its data model on a Web page at the
time of initial page loading, and can greatly improve the usability
(interactivity and responsiveness) of Web pages. OBF-enabled Web
pages, however, lack an intrinsic facility for keeping Data Objects
current while they are on a user's screen. In the exemplary Web
application of a stock portfolio described previously, stock prices
change with time and the Web pages have to be updated in order to
keep up with the changes.
[0049] FIG. 3 is a block diagram that schematically illustrates a
Web Messaging architecture according to an exemplary embodiment of
the present invention. In particular, FIG. 3 is a high level
diagram that illustrates the interaction of a Web server, a
messaging server and browsers at runtime.
[0050] The Web Messaging architecture is generally designated by
reference number 300. An end user at one of browser clients 302 has
requested OBF-enabled Web page 304 which displays his/her stock
portfolio information. As a result, a Java.TM. Server Page (JSP)
with a data grid showing portfolio composition with current stock
prices, as well as a pie chart graphically displaying the same
information, is downloaded from Web server 306. At the same time,
necessary JavaScript.TM. code included with Web Messaging control
308 is generated and downloaded along with the rest of OBF-enabled
Web page 304. Web Messaging control 308 on OBF-enabled Web page 304
establishes a connection with Messaging server 310 based on the
configuration (port number and topic, etc.) set up on the page by a
Web application developer.
[0051] Publisher 312 continuously publishes stock prices through
Messaging server 310. Messaging server 310 broadcasts the messages
to its message clients based on their topic subscriptions, in this
case, Web browser clients 302. Web Messaging control 308 on
OBF-enabled Web page 304 processes the messages and updates the OBF
model on the page. Eventually, the end user will be able to see the
stock prices updating automatically.
[0052] According to exemplary embodiments of the present invention,
two flavors of Web Messaging implementations are provided, namely
JavaScript.TM. and Java.TM. Applet Web messaging clients; and a Web
developer can choose between them based on their environment and
requirements. A Web developer, however, will only have to deal with
the same set of JSP tags or HTML tags by setting up slightly
different parameters on one of the tags. An end user will not
readily see the difference between the two configurations.
[0053] FIG. 4 is a block diagram that schematically illustrates a
JavaScript.TM. Web Messaging implementation of the Web Messaging
architecture illustrated in FIG. 3 according to an exemplary
embodiment of the present invention. The implementation is
generally designated by reference number 400, and uses
corresponding reference numbers to identify corresponding
components in the architecture illustrated in FIG. 3.
Implementation 400 includes JavaScript.TM. library 420 on browser
clients 402 maintaining communication with Messaging server 410 via
Web Messaging gateway 422 using HTTP tunneling and issuing HTTP
requests and responses inside HTML iframes.
[0054] FIG. 5 is a block diagram that schematically illustrates a
Java.TM. Applet Web Messaging implementation of the Web messaging
architecture illustrated in FIG. 3 according to an exemplary
embodiment of the present invention. The implementation is
generally designated by reference number 500 and also uses
corresponding reference numbers to identify corresponding
components in the architecture illustrated in FIG. 3. As shown in
FIG. 5, there are applet, Java.TM. Messaging client API and
JavaScript.TM. library 530 on browser clients 502 maintaining
communication with Messaging server 510.
[0055] FIG. 6 is a diagram that schematically illustrates how
various components and layers of a Web Messaging control interact
with one another according to an exemplary embodiment of the
present invention. On top is JSF tooling 600 which enables a
developer to drag and drop WebMessaging tags to a JSP, to bind the
control to a model, to set up a message topic, to map model object
attributes with message properties and to perform other
configuration activities. In this layer, the developer will make a
decision regarding which Messaging client type (JavaScript.TM. or
Java.TM. Applet) will be used. A flag (messaging type) will be
passed to the layers below. Based on the Messaging client decision,
necessary resources (JavaScript.TM. files, Jars, zips, etc.) will
be copied to the appropriate directories inside the project.
[0056] Immediately below JSF tooling 600 is WebMessaging JSF tag
runtime implementation 602, which is a very thin layer and
delegates most of the rendering work to the layer below it, namely,
WebMessaging Java.TM. emitter 604. WebMessaging Java.TM. emitter
604 exports all necessary JavaScript.TM. code for WebMessaging
control.
[0057] OBF WebMessaging control JavaScript.TM. layer 606 handles
interfacing with the OBF model as well as layers below. At the
startup of a Web page, data in the OBF model is used to configure
message topics, which in turn is used for message subscription.
WebMessaging control is bound with the OBF model. When any object,
whose parent is bound to the message topic templates, is created or
deleted, an event is fired to add or remove message subscriptions.
If any attribute of a model object, which is used to make up the
message topic by substituting tokens inside topic templates, is
updated, an event is also fired to remove the old topic if no more
subscriptions exist for the topic, and to add a new message topic
if the topic has not yet been subscribed. This layer also tracks
the relationship between topics and model objects. When a message
arrives, the right model object(s) will be updated based on this
mapping.
[0058] WebMessagingConnection common JavaScript.TM. interface layer
608 is designed to provide a uniform JavaScript.TM. interface for
Web Messaging regardless of whether the user decides to use a
JavaScript.TM. or Applet Messaging client type which is linked to
different Messaging servers. Based on the flag (messaging type)
passed down from layers above, this layer will set up necessary
resources. If the Applet Messaging client type is used, an applet
will be instantiated here. This layer can also directly serve the
common interface for HTML annotation JavaScript.TM. 620 for Web
Messaging as shown in FIG. 6.
[0059] At the bottom, based on the flag (messaging type), either
WebMessaging Java.TM. Applet layer 610 using WebSphere Business
Integration (WBI) Event Broker 614, or WebMessaging JavaScript.TM.
layer 612 using Whitewater messaging engine 616 is used to connect
with backend messaging systems. These two options will be discussed
more fully below.
[0060] WebMessaging Java.TM. Applet 610 supports a set of
publish/subscribe messaging actions to communicate with backend WBI
Event Broker 614. WebMessaging Java.TM. Applet 610 enables both a
real time update of Web pages with messages from WBI Event Broker
614 and the publication of messages to the broker.
[0061] WebMessaging Java.TM. Applet 610 uses a specialized subset
of the standard JMS API to maximize the JMS functionality that is
available while limiting the applet and supporting class download
size to approximately 100 kilobytes. The messaging support classes
are contained in the file "minimal.zip" which is distributed with
the applet and is made available in the application project.
Although JMS supports many types of messages, Web Messaging uses
only standard String JMS message properties for subscriptions. This
technique facilitates mapping of fields within messages to browser
model data or Web page elements.
[0062] WebMessaging Java.TM. Applet 610 only provides a set of APIs
that the JavaScript.TM. layer above can call, and expects a
callback handler. The callback handler will be a JavaScript.TM.
object, which represents common WebMessaging JavaScript.TM.
interface object 608 above. When a message arrives, the applet
calls the handler so that the OBF model will be updated.
[0063] The overall JavaScript.TM. client component comprises
essentially two sub-components, a client JavaScrip.TM.t library in
WebMessaging JavaScript.TM. layer 612 and a protocol handler
embedded in messaging engine 616. The JavaScript.TM. client
provides the client side functionality required to interact with
the server side protocol handler, and, hence, provides topic-based
messaging services to Web applications. The client library is
supplied in a ".js" file that can be referenced by an HTML document
and processed by a Web browser. The library includes core messaging
functionality (such as connect, send, addConsumers and disconnect),
and the ability to register callback functions such that message
event driven programming can be achieved in the JavaScript.TM.
environment.
[0064] The JavaScript.TM. messaging client provides the following
benefits: [0065] A "minimal" footprint messaging client (about 30
k) suitable for use in the Web domain [0066] Leverage of ubiquitous
client technologies such as HTML and JavaScript.TM. to minimize
requirements on the client machine other than standard browser
environments.
[0067] According to an exemplary embodiment of the present
invention, the library also includes optional layer 620 on top of
the basic messaging API to provide HTML annotation Web Messaging
capability in the client browser. HTML annotation Web Messaging
allows a page developer to directly annotate HTML elements in a
page with topic names such that contents of those elements can be
populated with message driven data in the user's browser
client.
[0068] FIG. 7 is a flowchart that illustrates a method for
dynamically updating a Web page according to an exemplary
embodiment of the present invention. The method is generally
designated by reference number 700, and begins by providing a Web
page that includes Web messaging tags, JavaScript.TM. and,
potentially, a Java.TM. library, and a selected data model that can
be bound to the Web messaging tags (Step 702). A messaging client
type is also selected (Step 704). A connection is established to a
Messaging server (Step 706), and topics are subscribed to from the
Messaging server (Step 708). Published messages relating to the
subscribed topics are then accepted from the Message server (Step
710), the accepted messages are processed (Step 712), and the
messages are updated into the data model to update the Web page
(Step 714).
[0069] It should be appreciated that while exemplary embodiments of
the present invention are described herein with reference to
updated Web pages using Web Messaging in an On Demand Client
Browser Framework (OBF) environment, the techniques described
herein could also be applied in other client-based processes that
requires data updating without departing from the scope of the
present invention.
[0070] It should also be appreciated that the Web browser, the
OBF-enabled Web page, and the Web Messaging control may be stored
in computer system memory such that the functional components of
the OBF-enabled Web page are provided as a computer program
product. The present invention can also be offered as a method on a
subscription or fee basis. For example, the OBF Web page and the
Web Messaging can be created, maintained, supported and/or deployed
by a service provider that offers the functions described herein
for customers. That is, a service provider can be used to provide
OBF-enabled Web pages with Web Messaging as described above.
[0071] The present invention thus provides a system, computer
implemented method and computer program product for dynamically
updating a Web page using browser-based messaging. A system for
dynamically updating a Web page according to an exemplary
embodiment of the present invention includes a Web page that
includes a plurality of Web messaging tags, and a selected data
model that can be bound to the Web messaging tags, and at least one
messaging client for accepting at least one message from a message
server and for processing the accepted at least one message into
the selected data model.
[0072] The invention can take the form of an entirely hardware
embodiment, an entirely software embodiment or an embodiment
containing both hardware and software elements. In a preferred
embodiment, the invention is implemented in software, which
includes but is not limited to firmware, resident software,
microcode, etc.
[0073] Furthermore, the invention can take the form of a computer
program product accessible from a computer-usable or
computer-readable medium providing program code for use by or in
connection with a computer or any instruction execution system. For
the purposes of this description, a computer-usable or computer
readable medium can be any tangible apparatus that can contain,
store, communicate, propagate, or transport the program for use by
or in connection with the instruction execution system, apparatus,
or device.
[0074] The medium can be an electronic, magnetic, optical,
electromagnetic, infrared, or semiconductor system (or apparatus or
device) or a propagation medium. Examples of a computer-readable
medium include a semiconductor or solid state memory, magnetic
tape, a removable computer diskette, a random access memory (RAM),
a read-only memory (ROM), a rigid magnetic disk and an optical
disk. Current examples of optical disks include compact disk-read
only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
[0075] A data processing system suitable for storing and/or
executing program code will include at least one processor coupled
directly or indirectly to memory elements through a system bus. The
memory elements can include local memory employed during actual
execution of the program code, bulk storage, and cache memories
which provide temporary storage of at least some program code in
order to reduce the number of times code must be retrieved from
bulk storage during execution.
[0076] Input/output or I/O devices (including but not limited to
keyboards, displays, pointing devices, etc.) can be coupled to the
system either directly or through intervening I/O controllers.
[0077] Network adapters may also be coupled to the system to enable
the data processing system to become coupled to other data
processing systems or remote printers or storage devices through
intervening private or public networks. Modems, cable modem and
Ethernet cards are just a few of the currently available types of
network adapters.
[0078] The description of the present invention has been presented
for purposes of illustration and description, and 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. The embodiment was chosen and described
in order to best explain the principles of the invention, 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.
* * * * *