|Publication number||US7702776 B2|
|Application number||US 10/575,980|
|Publication date||20 Apr 2010|
|Filing date||13 Oct 2004|
|Priority date||17 Oct 2003|
|Also published as||CN1954575A, DE10349015A1, DE502004005722D1, EP1673915A2, EP1673915B1, US20070271382, WO2005038662A2, WO2005038662A3|
|Publication number||10575980, 575980, PCT/2004/11489, PCT/EP/2004/011489, PCT/EP/2004/11489, PCT/EP/4/011489, PCT/EP/4/11489, PCT/EP2004/011489, PCT/EP2004/11489, PCT/EP2004011489, PCT/EP200411489, PCT/EP4/011489, PCT/EP4/11489, PCT/EP4011489, PCT/EP411489, US 7702776 B2, US 7702776B2, US-B2-7702776, US7702776 B2, US7702776B2|
|Inventors||Badreddine Douiri, Thomas Gysser, Frank Hackländer, Arno Pernozzoli|
|Original Assignee||Siemens Aktiengesellschaft|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (19), Non-Patent Citations (1), Referenced by (1), Classifications (18), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims priority to the German application No. 10349015.9, filed Oct. 17, 2003, and to the International Application No. PCT/EP2004/011489, filed Oct. 13, 2004 which are incorporated by reference herein in their entirety.
The present invention relates to an operating method for a server that communicates with a client, wherein the server, when a request for a page is transmitted to it by the client, transfers the requested page to the client.
The present invention also relates to a data medium having a computer program stored on the data medium for executing an operating method of said kind.
The present invention further relates to a server having a mass storage in which a computer program is stored, so that when the computer program is invoked by the server computer an operating method of said kind can be executed.
Methods, computer programs and servers of the aforementioned kind are generally known. They are used in particular for web applications, e.g. for internet and intranet applications.
Web applications are relatively anonymous. The server and the client usually know very little of one another. In particular it is generally not possible for the server to determine easily on the basis of a request for a page from which client this request was transmitted to it and from which state of the clients the request was made. Consequently, each request addressed to the server must usually include full information about the requesting client and about the requested page.
In order nonetheless to be able to apply certain default settings on the server side within a session between server and client (e.g. a choice of a language that is always to be used subsequently), it is known in particular that the client logs on to the server at the start of the session and the server transmits an attachment file (referred to as a “cookie”) to the client in addition to the requested page. The attachment file is appended by the client to every request addressed to this server. In other words it is transmitted back to the server by the client. In this case the attachment file is specific to the server. It is therefore transmitted in addition to the server by the client along with every request addressed to this server. The attachment file continues to be transmitted until either the attachment file is deleted on the client side or a new attachment file is transmitted by the server to the client, thereby overwriting the previous attachment file.
The preset default settings that are to be applied can be contained in the attachment file itself. Alternatively the attachment file can also contain a link to a memory area in the server. In this case the preset default settings are stored as such in the server, whereas in the first-mentioned case they are stored in the client.
The status of the session is usually bound to the session in the sense of the existence of the corresponding client-side communication program, e.g. an internet browser such as Internet Explorer from Microsoft. The prior art approach therefore operates without problems as long as the communication process is maintained on the client side and the communication with the server takes place via a single window.
However, it is generally known that it is possible to use multiple windows in parallel in one and the same internet browser. In the case of Microsoft's Internet Explorer, for example, multiple windows can be created by actuating the key combination “Control N” or by selecting the option “Open in new window”. Even in this case the prior art still causes no problems if, although multiple windows are used on the client side, the same preset default settings are always used in all the windows.
However, the prior art approach falls down if multiple windows are being used on the client side and different preset default settings are to be applied in the different windows. The reason is that, as already mentioned, the server is not able to differentiate from which of the windows the particular request was transmitted to it. In this situation the use of the attachment file also does not help, for a new window on the client side is in fact just a separate window, but not a separate process. Consequently the windows use the same attachment files.
An object of the present invention consists in creating an operating method for a server, a computer program corresponding herewith and the corresponding server by means of which such preset default settings can be individually applied for each window on the client side.
The object is achieved by means of an operating method for a server which communicates with a client in that
By means of this approach the server, although in fact still not able to recognize if a second window is opened on the client side (more on this later), can recognize if “obsolete” identification data is being transmitted to it by the client. On the basis of this circumstance, namely that the identification data is already obsolete or superseded, it can therefore recognize that a second window must have been opened. From the time of this recognition the server is therefore able to manage this second window separately from the first window.
In the simplest case the transmission identifier can be a sequential number or similar. Preferably, however, the transmission identifier is a globally unique identifier. For example, the transmission identifier can be what is referred to as a GUID. A GUID (global universal identifier) is formed on the basis of the server time—which is generally accurate to the nearest millisecond—and identification data of the server, for example a uniquely assigned identification number of the network card of the server or of the processor of the server.
By means of the approach according to the invention it is for example possible that selection data is assigned to the identification data and that if the transferred-back transmission identifier matches one of the stored transmission identifiers, the page newly transferred by the server to the client in response to the further request depends on the selection data assigned to the matching transmission identifier.
In the event that the transferred-back transmission identifier does not match any of the stored transmission identifiers, various approaches are possible. Thus, for example, a predefined start page can be transferred to the client. Preferably, however, the page newly transferred by the server to the client in response to the further request depends on the selection data assigned to one of the stored transmission identifiers. The server then, of course, also assigns this selection data to the additionally stored transmission identifier.
Preferably the identification data also includes a window identifier. If the transferred-back transmission identifier matches one of the stored transmission identifiers, the window identifier is retained in this case. If, on the other hand, the transferred-back transmission identifier does not match any of the stored transmission identifiers, the server assigns a new window identifier to the additionally stored transmission identifier.
As a result of this approach it is possible in particular to implement an efficient management of more than two client-side windows. Because of this approach, namely, it is possible for the server to recognize which window has been duplicated on the client side.
As a result of this approach it is also possible that in the event that the transferred-back transmission identifier does not match any of the stored transmission identifiers the page newly transferred by the server to the client in response to a further request depends on the selection data which is assigned to that one of the stored transmission identifiers whose window identifier matches the transferred-back window identifier.
In the simplest case the new window identifier can—analogously to the transmission identifier—once again be a sequential number. Preferably, however, it too is embodied as a GUID. In this case it can be embodied alternatively as an independently generated GUID or be identical to the transmission identifier generated immediately beforehand.
The server manages the identification data preferably in the form of a table which contains, in each row, the entries window identifier, transmission identifier and selection data. Instead of the selection data itself, a link (=pointer) to the selection data can, of course, also be stored in the table.
The checking sequence (first the transmission identifier or first the window identifier) is in principle left to the discretion of the person skilled in the art. Preferably, however, the window identifier will be checked first, and then the transmission identifier stored for this window identifier. The reason for this is that the window identifier transferred back by the client is always stored. The transmission identifier transferred back by the client, on the other hand, could already have been overwritten.
With web applications, basically two types of request transmission are known, namely what are referred to as Post requests and what are referred to as Get requests.
Post requests are based on the principle that the client fills out input fields of the page and then the filled-out input fields are transferred back to the server by the client. With Post requests all the input fields are always transferred back to the server by the client. The transmitted data includes, among other information, the request for the new page. For an orderly server-side handling of such Post requests in accordance with the present invention it is therefore possible, for example, that the server attaches the identification data to the transferred page as hidden input fields that are not displayed as well on the client side. According to the invention, therefore, hidden input fields are attached to the page which are not displayed as well when the page is displayed in the customary manner in a window of the client. The identification data has already been stored in advance in these input fields on the server side. They are therefore transferred back to the server by the client when the client sends a Post request.
With Get requests, on the other hand, a link address, usually what is referred to as a URL, is immediately transferred back by the client to the server. In this case the link address is part of the previously transferred page and is displayed as such along with the page in the window in which the client displays the page. If the user of the client selects this link address, the link address itself represents an immediate request for a further page.
If the page contains at least one such address for a further page, an orderly server-side handling of such a Get request in accordance with the present invention can be achieved by the server attaching the identification data to the transferred page as parameters, referred to as query parameters, assigned to the address.
A special instance of a response by the server to the receipt of a request is what is referred to as a server-side Response Redirect. A server-side Response Redirect is present when the server, in response to a request transmitted to it, does not transfer the requested page to the client, but upon receiving the further request initially transmits a third request to the client, which request is to be sent by the client back to the server. The server then transfers the requested page only in response to the transmission of the third request to the server. In this case there are two possibilities of guaranteeing an orderly handling of the request in accordance with the present invention on the server side.
On the one hand it is possible that the server attaches the identification data to the third request as assigned parameters. In this case the identification data is attached to the request itself. Alternatively it is also possible that the server attaches the identification data to the third request as an attachment file which is not transferred back by the client to the server with the third request. In this case, therefore, the server attaches the identification data to the third request as what is referred to as a transfer cookie. In this situation, as also in the case of Post requests, the identification data is attached to the page as hidden data. The program extracts the identification data and inserts it into the attachment file. In addition, the server transmits a delete command for this attachment file to the client together with the page which it transfers to the client in response to the third request.
Thus, a so-called transfer cookie is generated in this case also. In contrast to the Response Redirect, however, the transfer cookie is generated, not on the server side, but on the client side.
The server cannot recognize immediately if a page already transferred to the client is duplicated on the client side. Therefore, if the user of the client duplicates a page and thereafter works for a relatively long time with only one of the two versions of the duplicated page, but does not change the other version of the duplicate d page, this other version remains unchanged for the present. If the user of the client then sends a request to the server at a much later time from the other, still unchanged, version of the duplicated page, in this case the server takes over the selection data that is assigned to the changed version of the duplicated page at this time. However, the selection data may already have been substantially changed at this time. It can therefore be relatively complicated for the user to restore the status of the other version of the duplicated page which is actually wanted by the user. For this reason it is of advantage to recognize as early as possible if a page already transferred to the client is duplicated on the client side.
An immediate recognition of a duplication of this kind is possible in that
For then the client repeats the previous request immediately if the page is duplicated, with the result that the server can immediately recognize the duplication as such. With this approach, although the server also (mistakenly) recognizes a duplication if the user of the client only updates the page—without duplicating it—or reverts to a page that is still stored on the client side but is no longer displayed in this window. This is not critical, however, since in this case only one window is being managed on the server side, and in reality this window does not even exist on the client side. On the other hand it cannot happen that a window is duplicated on the client side and the server does not recognize this. In this case the request can be transmitted to the server in the form of a Post request or in the form of a Get request, dependent on the specific application. This also applies if the page was loaded for the first time in response to a Post request.
The operating method according to the invention is implemented as a computer program which is supplied to the server. In this case the computer program is supplied to the server via a data medium. Examples of a data medium of this kind are a CD-ROM or a streamer cartridge. The computer program is stored on the data medium in (exclusively) machine-readable form. At the same time the computer program can be stored on the data medium alternatively in compressed or in uncompressed form.
The data medium with the computer program stored thereon is introduced into a reader device by means of which the server can read the computer program stored on the data medium. It therefore reads the computer program from the data medium and stores it in a mass storage, for example on a hard disk. When the computer program is called from the hard disk (alternatively also from the data medium), the server is therefore able to execute the operating method according to the invention.
Further advantages and details will emerge from the following description of an exemplary embodiment in conjunction with the drawings, in which:
The server 1 has, as is generally customary, a number of components 4 to 8 which are connected to one another via a bus 9. The components 4 to 8 comprise in particular a processor 4, a mass storage 5 (typically one or more hard disks), a reader device 6, a timer 7, and a network card 8.
A data medium 10 on which a computer program 11 is stored in exclusively machine-readable form can be introduced into the reader device 6. Said computer program 11 is read from the data medium 10 and stored, as indicated by the dashed line in
In a step S3 a window identifier FeId is then set equal to the transmission identifier ÜbId just determined. The two identifiers ÜbId, FeId are then—see
In a step S5 the server 1 attaches the identification data FeId, ÜbId to the requested page. In this case the attachment is performed in such a way that if a further request for a page is made by the client 3 the identification data FeId, ÜbId is transferred back to the server 1 if and only if the request originates from the transfer of this page on the client 3 side.
According to a step S6 the server 1 also attaches a variable and a program to the requested page. The variable has an initial value. The program is embodied such that it initiates a new request for the previous page if the transferred page is copied on the client side. This will be dealt with in greater detail later. Step S6 is only optional here and is therefore represented only by a dashed outline in
In a step S8 the server 1 accepts a further input from the client 3. The server 1 thereupon checks first in a step S9 whether the client 3 has logged off. If this is the case, in a step S10 the server deletes the table 12 and terminates the execution of the method.
If the input in step S8 was not a logoff, then it was a new request. In this case the server 1 extracts the transferred-back identifiers ÜbId, FeId and the selection data SD from the transmitted request.
In a step S12 the server 1 then checks whether the transferred-back transmission identifier ÜbId matches the transmission identifier ÜbId which is assigned to the transferred-back window identifier FeId in the table 12. For the sake of better clarity, step S12 in
If a match was established in step S12, the request transmitted by the client 3 originates from a window of the client 3 already acquired and managed on the server side. In this case, in a step S13 analogous to step S2, a new transmission identifier ÜbId is determined and stored in the table 12 in the row in which the transferred-back window identifier FeId is also stored. The server 1 therefore stores the newly determined transmission identifier ÜbId in place of the transferred-back transmission identifier ÜbId in the table 12.
If, on the other hand, no match was established in step S12, a step S14 is executed. In step S14 the transmission identifier ÜbId is likewise newly determined in an analogous manner to the approach of step S2. Then, however, the window identifier FeId is set—analogously to step S3—equal to the transmission identifier ÜbId just newly determined. The two identifiers FeId, ÜbId are entered by the server 1 in a new row of the table 12. In addition, as part of step S14, the selection data SD which is assigned to the transferred-back window identifier FeId is copied into the now newly filled row of the table 12.
If the server 1 has received new selection data SD, in a step S15 it additionally modifies the selection data SD which is assigned to the current window identifier FeId. Depending on whether, as a result of the check in step S12, step S13 or step S14 has been executed, the data in this case is the transferred-back window identifier FeId or the newly determined window identifier FeId.
In a step S16 the server 1 checks next whether it can transfer the requested page directly or whether it must perform what is referred to as a Response Redirect. If it has to perform a Response Redirect, it executes a step S17 in which it transmits a new address, usually a URL address, in addition to the current window identifier FeId and the current transmission identifier ÜbId to the client 3. It then branches back to step S8.
Otherwise, the server 1 determines, on the basis of the selection data assigned to the current window identifier FeId and the current transmission identifier ÜbId in the table 12, which page is to be transferred to the client 3. Alternatively or in addition the contents of the page can also be modified. The server 1 then branches back to step S5.
In a step S20 the server 1 then checks whether the page to be transmitted includes a URL address to which the identifiers ÜbId and FeId have not yet been attached as query parameters. If this is the case, the server 1 executes a step S21 in which it attaches the identifiers ÜbId and FeId as query parameters to this address. From step S21 the server then returns to step S20. In this case step S20 in FIG. 4—analogously to step S12 in FIG. 2—is subdivided into two sub-steps.
Of the steps S17 shown in
By means of the operating method according to the invention it is therefore easily possible for the server 1 to individually manage a plurality of windows of the client 3.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5708780||7 Jun 1995||13 Jan 1998||Open Market, Inc.||Internet server access control and monitoring systems|
|US5774670||6 Oct 1995||30 Jun 1998||Netscape Communications Corporation||Persistent client state in a hypertext transfer protocol based client-server system|
|US5937160 *||1 May 1997||10 Aug 1999||Reedy Creek Technologies, Inc.||Systems, methods and computer program products for updating hypertext documents via electronic mail|
|US6047268||4 Nov 1997||4 Apr 2000||A.T.&T. Corporation||Method and apparatus for billing for transactions conducted over the internet|
|US6313855 *||4 Feb 2000||6 Nov 2001||Browse3D Corporation||System and method for web browsing|
|US6366947 *||20 Jan 1998||2 Apr 2002||Redmond Venture, Inc.||System and method for accelerating network interaction|
|US6456307 *||9 Sep 1998||24 Sep 2002||International Business Machines Corporation||Automatic icon generation|
|US6915482 *||28 Mar 2001||5 Jul 2005||Cyber Watcher As||Method and arrangement for web information monitoring|
|US7207044 *||21 Nov 2002||17 Apr 2007||Sun Microsystems, Inc.||Methods and systems for integrating with load balancers in a client and server system|
|US7246147 *||3 Feb 2003||17 Jul 2007||Canon Kabushiki Kaisha||Upload and retrieval by an image device of a scanned image to and from a web file server|
|US7600020 *||5 Jun 2008||6 Oct 2009||International Business Machines Corporation||System and program product for tracking web user sessions|
|US20020099936||16 Mar 2001||25 Jul 2002||International Business Machines Corporation||Secure session management and authentication for web sites|
|US20020111879 *||12 Feb 2002||15 Aug 2002||Antonio Melero||Method and system for selecting and purchasing products via a communications network|
|US20020184632 *||30 May 2001||5 Dec 2002||Reitmeier Glenn A.||Computer peripheral device for web-enhanced media services|
|US20030037108 *||16 Aug 2002||20 Feb 2003||Christopher Peiffer||System and method for maintaining statefulness during client-server interactions|
|US20030051022 *||18 Apr 2002||13 Mar 2003||Masaru Sogabe||Web page management support system|
|US20040030719 *||10 Feb 2003||12 Feb 2004||Jie Wei||Web page based dynamic book for document presentation and operation|
|US20040177327 *||31 Jan 2001||9 Sep 2004||Robert Kieffer||System and process for delivering and rendering scalable web pages|
|US20040255240 *||10 Jun 2003||16 Dec 2004||Charlie Udom||Image selection for variable documents|
|1||David Lane, Hugh E. Williams; "Web Database Applications with PHP & MySQL"; Mar. 2002; pp. 1-26; [Retrieved from internet at] http://www.oreilly.com/catalog/webdbapps/chapter/ch09.htlm; XP002283237.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7634332||3 May 2006||15 Dec 2009||United States Postal Service||Systems and methods for creating routes for powered industrial vehicles|
|U.S. Classification||709/224, 715/781, 709/203|
|International Classification||G06F15/173, G06F17/30, H04L29/08, H04L29/06|
|Cooperative Classification||H04L67/34, H04L67/14, H04L69/329, H04L67/02, G06F17/30899, H04L29/06|
|European Classification||H04L29/08N1, H04L29/08N13, H04L29/08N33, H04L29/06, G06F17/30W9|
|25 Jan 2007||AS||Assignment|
Owner name: SIEMENS AKTIENGESELLSCHAFT, GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DOUIRI, BADREDDINE;GYSSER, THOMAS;HACKLANDER, FRANK;AND OTHERS;REEL/FRAME:018819/0548;SIGNING DATES FROM 20060412 TO 20060420
Owner name: SIEMENS AKTIENGESELLSCHAFT,GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DOUIRI, BADREDDINE;GYSSER, THOMAS;HACKLANDER, FRANK;AND OTHERS;SIGNING DATES FROM 20060412 TO 20060420;REEL/FRAME:018819/0548
|16 Sep 2013||FPAY||Fee payment|
Year of fee payment: 4