||The present invention relates to an apparatus adapted to respond to a request message from a remote user device for web page information. More particularly, the present invention provides web servers and in particular and not exclusively to a web server for responding to request messages received via the internet from remote user devices and to a web server capable of responding with web page code tailored to meet the capabilities of the remote user device.
The user of the internet has recently flourished to the extent where almost every business concern has its own website to provide information and online purchasing facilities. The majority of such websites have in the past been accessed by remote user devices which are PCs (Personal Computers) using one of a relatively small number of available browser applications so that, by and large, the websites were required to output web page code in a single format for viewing at the user device.
More recently, there has been a proliferation in new
internet enabled devices such as PDAs (Personal Digital
Assistants), mobile telephones with WAP (Wireless Application
Protocol) facilities, IDTV (Interactive Digital Television),
information kiosks, games, consoles and home appliances. The
capabilities of these devices vary considerably from device to
device, both in their display function in terms of screen size
and colour processing ability, bandwidth and available memory as
well as variables associated with communication including
image format, communication protocol and markup language.
In order to enable users of these different devices to access their websites, many businesses have resorted to building separate web servers to serve each device type. This however creates data management problems where a customer may wish to have the option of using different devices to communicate with the merchant using the same account details for example, the merchant then requiring a proliferation of different web server applications to be managed and updated when required with new or additional material.
An alternative approach has been to provide a separate port of a website for access by an alternative type of user device, the separate port obtaining the required web page code by translating the original PC based web page code, typically in HyperText Markup Language (HTML) format, to other device formats such as Wireless Markup Language (WML) used for WAP telephones. Such solutions however generally have failed to deliver optimum presentation to the user of the device. The translating process (often referred to as "transcoding") is difficult to engineer. For example, it is necessary to provide appropriate selection of information which is to be omitted from display in the device having lower capabilities than the PC. This difficulty is compounded when it is necessary to update the original PC web page
code because the transcoding process must also be re-engineered.
It has also been proposed that the protocols used for accessing web page information over the internet should be unified by the adoption of standards in order to overcome problems resulting from remote user devices having different capabilities. The use of Extensible Markup Language (XML) as a format for web page code has been proposed. XML is a mark-up language for defining content and can be used with XSL (Extensible Stylesheets Language) used to transform XML documents with style sheets at the point of presentation. As yet however, such standards have not been adopted and this solution is not seen as optimum for all device types.
The present invention seeks to provide an improved web server with multi-channel capabilities able to serve different types of remote user device.
According to the present invention there is disclosed an apparatus for responding to a request message from a remote user device for web page information by generating web page code representative of one or more web pages to be displayed by the user device and outputting a response message comprising the web page code.
Preferably the apparatus comprises extracting means for extracting from the request message a device type
identifier identifying the remote user device as being one of a set of possible device types having different capabilities.
The apparatus preferably has a processor for operating a code generating engine to generate the web page code, first memory means for storing the web page information as a set of instructions, and second memory means for storing device dependent information for each of the different device types for tailoring the web page code to the capabilities of the device type.
The code generating engine preferably comprises interpreting means for interpreting the instructions with reference to selected device dependent information corresponding to the device type identifier, the code generating means thereby being operable to generate the web page code in a form in which the web page code is tailored to the capabilities of the remote user device.
Preferred embodiments of the present invention will now be described by way of example only and with reference to the accompanying drawings of which:
Figure 1 is a schematic overview of connection between a web server and remote user devices;
Figure 2A is a schematic diagram of the web server of Figure l;
Figure 2B is a functional diagram for illustrating signal flow in the web server of Figure 2A;
Figure 3 is a schematic diagram of policy tables for use with the web server of Figure 2;
Figure 4 is a schematic diagram illustrating operation of the code generating engine;
Figure 5A illustrates a layout for a PC;
Figure 5B illustrates a layout for a television;
Figure 5C illustrates a layout for a PDA;
Figure 5D illustrates a layout for a WAP telephone;
Figure 5E illustrates layout for a device having a large screen;
Figure 5F illustrates the display of fragments in a device having a small screen;
Figure 5G illustrates a multi-menu structure in a large screen device;
Figure 5H illustrates the relationship between control segments and content segments in the layout of Figure 5G;
Figure 6 illustrates the hierarchy of a device policy table;
Figure 7 illustrates schematically the software provided to the web server;
Figure 8 illustrates schematically the hardware required by the web server;
Figure 9 illustrates schematically the separation of content code and presentation of information for use by the code generating engine;
Figure 10 illustrates schematically a system comprising a production server and a development server;
Figure 11 illustrates the exchange of signals in the system of Figure 10 when a new type of user device is encountered for the first time;
Figure 12 illustrates schematically a server having a cache memory;
Figure 13 is a flowchart illustrating the method of operation of a gateway server of Figure 12;
Figure 14 is a flowchart illustrating operation of a dynamic web page server of Figure 12;
Figure 15 is a schematic diagram illustrating a component logic software module;
Figure 16 is a flowchart illustrating operation of code generation using the component logic software module;
Figure 17 is a diagram illustrating the hierarchy of data objects which are different versions of data referenced by a single component name;
Figure 18 illustrates the hierarchy of text objects with different text code sizes and languages;
Figure 19 illustrates the signal flow in a web server in which pane dissection occurs;
Figure 20 is a flowchart illustrating pane dissection;
Figure 21 illustrates the dissection of a pane into
Figure 22 illustrates use of a user session memory
during form filling;
Figure 23 illustrates the dissection of a pane used in form filling;
Figure 24 illustrates the function of the graphical user interface; and
Figure 25 is a flowchart illustrating a method of file storage.
Figure 1 illustrates a web server 1 connected to remote user devices 2 via the internet 3. The remote user devices are illustrated to be a PC, television, PDA, and a mobile telephone with WAP facility but can include any number of different devices with internet capability. The web server 1 is provided with a web server GUI (Graphical User Interface) 4 enabling an operator of the web server to author documents and generally control and maintain operation of the web server. The web server 1 is also connected via the internet 3 to a service centre 5 which acquires information-concerning any new types of user device and provides the web server 1 with consequential software revision when required.
Figure 2A is a simplified schematic diagram of the web server 1 of Figure 1. The web server 1 includes a processor 20 which operates a code generating engine 21 in the form of an application which is run by the
processor on demand in order to generate web page code. The code generating engine 21 in this embodiment is written in the Java programming language and during operation of the web server exists in the working memory of the processor 20 in compiled form as byte codes and is implementable within a Java run time environment.
A memory 22 stores content code 23 which defines web page information in the form of documents written in a mark up language which in the present example is JSPl.l (Java Server Pages). These documents are typically authored by the operator of the web server 1 using the graphical user interface 4. The memory 22 also stores operational data 24 which includes for example data which may need to be incorporated into web page code generated at run time in response to specific queries originating from the user device 2 and data acquired by monitoring usage of the web server. Data objects referenced by the content code 23 are stored in a database 19. These data objects may include files containing images or text and other forms of data objects which an author may wish to include in the web page code to be generated.
Device dependent information 25 is also stored in memory 22 and consists primarily of policy tables described below. The memory 22 also stores program code 26 which may be accessed by the processor 20 during operation of the server 1 or used to retrieve software
such as the code generating engine 21 at the time of startup. The program code 26 also includes code defining a set of tags used in a mark up language in which the documents are authored as described below.
An interface 27 communicates between a databus 28 serving the processor 20 and memory 22 and external connection to the internet 3 for receiving request messages and transmitting response messages.
A device identification engine 29 is provided for extracting from received messages a device type identifier for identifying the remote user device 2 by type. The device identification engine 29 in the present example is implemented in software by the processor 20. In this example, a request message received via the internet contains a HyperText Transfer Protocol (HTTP) header which includes an ID string declaring the name of the user agent which the originating device has used when generating the request message. The name of the user agent software defines for example the browser version and markup language capability of the device and is used by the device identification engine 29 to identify the originating device using the device type identifier which may for example be stored as a lookup table.
The HTTP header may also yield information contained in a cookie regarding details of the user who has originated the request message. Such cookies may contain
other data used for personalisation of the response made by the web server 1.
Figure 2B is a further illustration of the web server 1 showing functional elements in a manner which illustrates the signal flow. A front end processor 300 provides a communications interface for request messages received from the internet 3 and response messages transmitted to the user device 2 via the internet. The front end processor 300 sends URL information 301 to a web application processor 302 which determines from the URL the appropriate information to be included in a web page requested by the user. The web application processor 302 has access to a database 303 which may be local to the processor or may be at a remote location which is accessible via an appropriate communications link.
The web application processor 302 outputs a document 304 comprising instructions for generating web page code. The document 304 is not itself capable of being interpreted by a browser of a user device and therefore does not constitute "web page code" for the purpose of the present description.
The document 304 is input to the code generating engine 21 which generates web page code with reference to content data structure 305 and the set of policy tables 40. The output of the code generating engine is
a web page code document 306 which is now in a form which is capable of being interpreted by the browser of the user device 2. The web page code document 306 is received by the front end processor 300 and packaged as a response message transmitted via the internet 3 through the user device 2.
To enable the code generating engine 21 to select the appropriate data from the content data structure 305 and to access the appropriate policy tables 40, it also requires the input of a device type identifier 45 which is provided by device identification engine 29 in response to receiving a message header signal 307 from the front end processor 300, this signal comprising information extracted from the message header of the request message received from the user device.
Figure 3 illustrates schematically the policy tables 40 which constitute the device dependent information 25 of Figure 2A.
In the present context, the term "policy" is used to signify information to be utilised by the code generating engine 21 and which can be defined differently for different device types, either out of necessity because of different technical capabilities of different device types or as a result of choice exercised by the author of the content code 23.
The policy tables 40 include a device policy table
30 which contains a number of fields relating to different technical aspects of the device type. By way of example, table 1 below lists a small number of device policies that can be associated with the device type and which each correspond to one field (i.e. row) of the table. Values are illustrated for a single device type (i.e. a single column). The device policy table 30 in practice will include a large number of different fields and values for multiple device types using a hierarchical table structure to represent the table in compact form..
TABLE 1 - Part of Device Policy Table
By accessing the device policy table 30, the code generating engine 21 thereby is able to exercise decision making regarding choice of code generation to suit the technical capabilities of the user device 2. For example, if an image is to be included as an image file in the web page code, it is necessary for the code generating engine 21 to have knowledge of the form of
image data compression available to the user device 2 from which the request message originated. The device policy table 30 includes fields indicating whether GIF or JPEG format images can be decompressed by the device. Similarly, audio files may be compressed in a number of different forms including MP3 format and the device policy table 30 also includes a field indicating whether the device supports MP3.
The protocol policy table 31 is responsible for mapping equivalences between device output protocols, . which are generally termed markup languages. Examples are WML, HTML, Handheld Device Markup Language (HDML) and compact HTML (cHTML). Table 2 is an example of six of the fields in the protocol policy table 31 for a single one of the device types.
TABLE 2 - Part of Protocol Policy Table
A style policy table 32 contains a number of fields which define parameters such as font family, font size, font weight and colour of headings, image borders and paragraph background as illustrated in Table 3 which shows part of the style policy table for a single one of the device types. The code generating engine 21 is thereby able to generate code appropriate to the device type, in accordance with a predetermined decision which may for example reflect an agreed style adopted as a general trading style by a particular business entity.
The way in which stylistic information is handled varies between different devices, and indeed between different device output protocols. For some, style information must be included within the generated web page code. For others, style information must be provided in separately generated code, often called a "style sheet".
TABLE 3 - Part of Style Policy Table
A themes policy table 33 similarly contains fields relating to decorative embellishments and logos adopted by business entities for their web pages and enables the author of the themes policy to tailor the decorative features and aspects of logo such as size for each of the device types.
A layouts policy table 35 contains fields relating to the layout of elements comprising text, logos, images etc at the point of rendering the image in the user device in order to take account for example of different screen shape and size for different device types.
A dynamic policy table 36 contains fields allowing code for different device types to be tailored according to time varying parameters. As an example, a mobile telephone having WAP facilities may have a bandwidth for
receiving response messages which varies with time according of the strength of signal available via the cellular mobile telephone network used by the telephone to connect to the internet. The dynamic policy may be configured to generate code requiring low bandwidth under low bandwidth conditions and higher bandwidth under better conditions. The amount of image data for example may be regulated in order to control the bandwidth required to carry the response message. Simply by omitting a logo or other image, the speed with which the response message can be downloaded to the device can be maintained under poor signal strength conditions.
A component policy table 37 is also provided the purpose of which is to determine selection of data objects as described below.
Figure 4 illustrates schematically the manner in which the code generating engine 21 makes use of the data in the policy tables 40. At startup, the processor 20 retrieves a startup program from the stored program code 26 and runs the startup program to assimilate the information in the policy tables 40 into a series of Java objects (Java beans) referred to herein as policy objects 41 which are then made available within a run time environment 46 of the code generating engine 21. The run time environment is provided by an appropriate Java Virtual Machine. The policy objects 41 each deal with
specific aspects of code generation and contain logic and data objects configured such that each policy object has knowledge of all of the relevant information available from the policy tables 40 for each device type. One policy object 41 for example may be concerned with image format capability whereas another policy object may be concerned with choice of markup language for the output code. The code generating engine 21 at run time processes a compiled version of a document of the content code 23, the code consisting of a series of instructions 42, each instruction including one of a set of markup tags 43.
In Figure 4, tag 43 is illustrated as being one of a number of custom or smart tags which, as represented schematically in Figure 4, refers when processed to a set of classes 44 which have been written to carry out the required function of the tags. These classes 44 in turn refer to one or more of the policy objects 41 whenever a program decision is to be taken which is dependent upon the device type on the basis of data contained in the policy tables 40.
Examples of custom tags 43 provided in accordance with the present embodiment are summarised in tables 4 and 5. All of the tags utilised in defining the content code 23 are device aware in the sense that they are implemented as JSP custom tags and are associated with
Java classes which access Java beans (policy objects 41) to make device dependent decisions. The more primitive tags are referred to here as simple in-line tags as shown in Table 4. More complex tags are referred to as major block tags in Table 5. The major tags typically translate into more than one tag in the markup language of the resulting generated code, for example HTML.
The device identification engine 29 operated by-processor 20 extracts from a header of the received request message from a remote user device 2 information which identifies the device type and outputs a device type identifier 45 which is input to the code generating engine 21 to enable the set of classes 44 to extract the required information from the policy objects 41.
An example of a document is given at Appendix 1 and comprises a set of instructions 42 including tags 43 to constitute the content code 23 in the markup language
operated upon by the code generating engine 21. At line 2 for example, the tag