EP0894392A2 - Systeme et procede servant a acceder a des donnees - Google Patents

Systeme et procede servant a acceder a des donnees

Info

Publication number
EP0894392A2
EP0894392A2 EP97922344A EP97922344A EP0894392A2 EP 0894392 A2 EP0894392 A2 EP 0894392A2 EP 97922344 A EP97922344 A EP 97922344A EP 97922344 A EP97922344 A EP 97922344A EP 0894392 A2 EP0894392 A2 EP 0894392A2
Authority
EP
European Patent Office
Prior art keywords
client
server
request
token
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP97922344A
Other languages
German (de)
English (en)
Inventor
Robert T. Bisbee
Cynthia H. Evans
Robert O. Thomas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intergraph Corp
Original Assignee
Intergraph Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intergraph Corp filed Critical Intergraph Corp
Publication of EP0894392A2 publication Critical patent/EP0894392A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • This invention relates to computer systems, and more particularly to client-server computer systems that provide access to on-line data.
  • a common use of client-server computer systems is the retrieval of information by the client system of data stored on a server system over a network connection.
  • the network involved in such a retrieval may be the public Internet or a private Intranet.
  • An Intranet is a private network, generally augmenting or replacing a Local Area Network (LAN) within an office, yet based upon the widely available Internet technology.
  • HTTP Hypertext Transaction Protocol the protocol that carries the network communications between many existing client and server systems.
  • HTTP is a high-level set of networking functions that rides on top of lower-level basic network protocols.
  • a good example of a superset protocol is the well-known TCP/IP high-level protocol, which is built on top of the low-level IP protocol.
  • IP is essentially the assembly-language of networking protocols. It offers very basic low-level functions for forming a network connection between two locations on the network (such as between a client and a server), but IP offers very little error handling recovery. In contrast, TCP/IP builds off of IP to provide features to guarantee error-free transmissions over the network. In this same fashion, the HTTP protocol builds on present day networking protocols to allow efficient client-server connections over a network where it is expected that a large volume of data (principally due to graphics information) will be transferred between the two. In its most common form of use, HTTP is a stateless protocol. The "state" of a client- server transaction refers to what the client is doing/requesting now, in relation to the past 0
  • a stateless protocol means that the communications are one ⁇ way requests, and that the requests are not being tracked.
  • the client would have to make fully encapsulated requests to a server.
  • the server would receive the request, process it and send the client the result, and then immediately drop the connection between the server and client. After the drop there is no persisting record at the server of information related to the communication channel that was just closed, and no information related to the client system or to the specific user of the client system.
  • follow-on communications between the client and server that are logically connected require that a new communication channel be established for the follow-on communications without reference to or use of prior information.
  • This process requires a repeat expenditure of system overhead by both the client and the server systems to set up a new channel for each HTTP communication, as well as expenditure of other resources to re-transmit information from the client to the server that may be needed to access the information being sought.
  • the client is required to transmit state information to the server if the client wishes to perform an ongoing dialog with the server.
  • the stateless connection is adequate.
  • OLTP on-line transaction processing system
  • OLAP on-line access processing
  • the invention will be described here in terms of an OLTP, however it will be understood that the present invention has broader application than the OLTP system described.
  • the invention may find utility in any communications system requiring multiple interactions or transactions within a user session, and which provides client context within the server for follow-on interactions
  • An on-line transaction processing system typically provides a computer system comprising a client-server arrangement having three tiers, although a two tier system will also be desc ⁇ bed below for completeness
  • a plurality of client systems at the first tier level having keyboards and display monitors provide input and output directly to human users who have a need to remotely access a database of information records.
  • Network connections connect the client systems to a second tier comp ⁇ sing application servers that provide the application software such as an inventory control system oi an airline reservation system that deals with user requests, performing data collection and validation and supplying usei responses and other application services
  • Netwoik connections connect the application servers to a third tier comprising, typically, a single or small number of database servers that contain the basic information records, e.g., inventory or airline seats, that are queried and updated as the human users interact with the data through the application system.
  • Networks in an OLTP may be local area networks or wide area networks as the physical distances between the client and the server systems requires.
  • a Web server comprises a hardware and software combination suitable for operation as a server on the World Wide Web, an increasingly commercially-oriented segment of the publicly available Internet network.
  • the Windows operating system is used in the application tier, however, experience shows that the overall capacity of the OLTP system is substantially less for the same hardware than the capacity when the UNIX operating system is used. Solving this capacity problem would encourage OLTP systems to be implemented using Web server technology on a private Intranet network, or using Web servers as OLTP application servers or data servers on the World Wide Web itself. Additional details on the background and the problem being solved by the present invention will be found in the article "Putting the Data Warehouse on the Intranet", appearing in Internet Systems, May 1996, a periodical published by Miller Freeman as a supplement to the periodical DBMS.
  • the present invention provides an increase in capacity in a client-server system that uses a stateless protocol to access server data.
  • the invention does this by improving network communication efficiency over the network linking the server system to the client system.
  • the server For each initial client system transaction request, the server generates a unique identifier, or token, which is returned over the network to the client system, the receipt of which token acts to hold the logical connection to the server in an active or open condition until the client system is finished with the connection and releases it.
  • the token is used to identify client state information, also referred to as user context information, retained at the server for use with follow-on communications with the client.
  • follow-on communications from the client include the token, which the server uses to identify the stored client stale information
  • the present invention further reduces network overhead by keeping alive the network connection between server system and client system, thereby reducing total system overhead.
  • the server creates only a single or a small number of operating system processes within the server system in response to a comparatively large number of client system transaction requests Used individually or in combination, these improvements increase the capacity of a chent-servei system based upon a stateless communication protocol.
  • the data access system would include a client computer and a server. At least one database maintained on the server, the database having information to be distributed to the client computer and a token associated with the client, wherein the token represents the status of communications between the client computer and the server.
  • the status of communications includes the identity of the client and the context of any communications between the client computei and the server.
  • the communications between a client and a server may be encrypted, using a proprietary or public-key cryptosystem, allowing for secure communication over a communication link (e.g. network, satellite broadcasts, or cable TV) lacking in security.
  • FIG. 1 shows a block diagram of a prior art three-tier OLTP system based on the UNIX operating system.
  • FIG. 2 shows a block diagram of an embodiment of a three-tier OLTP system according to the present invention using the Windows NT Servei operating system at the application server tier
  • FIG. 3 shows a block diagram of an embodiment of a three-tier OLTP system implemented as a two-tier system wherein the database server software and the application server software for a particulai database are provided within a single computer system using the Windows NT Server operating system.
  • FIG. 4 shows diagrammatically certain memory and software interaction between application system software and client system software to effect improvements of the present invention
  • FIG 5 is a How-chart of the interaction between a client and a server communicating in accordance with an embodiment of the present invention
  • FIG 6 is a more detailed view of two steps contained within the FIG 5 flow-chait
  • FIG 7 is a flow-chart showing the general handling of cookies by a preferred embodiment
  • FIG 1 is an example prior art three-tier OLTP implementing an inventory control system.
  • database server 10 provides common access to information records for users connected to on line client system 30
  • Server 10 includes magnetic disk or other non- volatile storage that contains a database of information records necessary for implementation of an inventory control system.
  • Server 10 manages the database using one of a number of commercially available database management systems, such as the Oracle system sold by Oracle Co ⁇ oration of Redwood Shores, California.
  • Database server 10 receives and responds to lequests for database services over network 15 from one or more application servers 20 which implement a data-dependent software application, such as an inventory control system Application servei 20 receives and responds to requests for inventory control services over network 25 from one or more client systems 30
  • a data-dependent software application such as an inventory control system
  • Application servei 20 receives and responds to requests for inventory control services over network 25 from one or more client systems 30
  • One or more human users interact with each client system 30 using keyboard, mouse, display monitor, printer or any number of other input/output devices to utilize the inventory control system.
  • prior art OLTP systems of this type generally utilize the UNIX operating system at each tier of the system.
  • Database server 10 and application server 20 typically communicate over network 15 utilizing calls for database services that are native to the particular database manager being utilized, Oracle in this specific embodiment, or else the ODBC Open Database Connectivity protocol which is an industry standard database communication protocol. All commercially important database management systems generally available, including Oracle, will accept standard ODBC requests and will provide standard ODBC responses over network 15.
  • ODBC is used illustratively throughout, but it will be understood to represent generally ODBC, the transaction language native to the specific database management system (DBMS), or any other transaction language suitable for database communications.
  • Application server 20 and client system 30 using the UNIX operating system typically communicate over network 25 utilizing the Telnet UNIX industry standard communication protocol.
  • the UNIX operating system at application server 20 can handle a significant number of simultaneous Telnet connections, so that total OLTP system capacity is sufficient for its intended pu ⁇ ose.
  • FIG. 2 shows a block diagram of an embodiment of a three-tier OLTP system according to the present invention using the Windows NT Server operating system at the application server tier.
  • Database server 40 and application server 50 communicate over network connection 45 using the ODBC or other protocol in a manner similar to the prior art system.
  • Application server 50 is advantageously implemented using Web server technology under Windows NT Server.
  • the HTTP Hypertext Transport Protocol is used on network 55 to communicate with client system 60.
  • Client system 60 may use any operating system supporting the HTTP protocol, such as UNIX or one of the Windows products.
  • the Web server features of the application server 50 are implemented in software using the Visual C++ Version 4.1 suite of development software trom Microsoft. Any programming language could be used, but this suite of software is particularly advantageous This suite includes the Miciosoft Foundation Classes and the ISAP1 Internet Server Application Program Interface software
  • the ISAPI provides rudimentary Web server and HTTP features that can be built upon using the Visual C++ compiler provided in the suite
  • client system 60 communication with application server 50 over network connection 55 using the HTTP protocol is implemented using the ISAPI expanded in an appropriate fashion to coopeiate with the software implemented at server 50 In this way, application server 50 and client system 60 cooperate to reduce the communication load over network connection 55.
  • FIG 3 shows a block diagram ot an embodiment of a thiee-tier OLTP system implemented as a two-tier system wherein the database servei software and the application server software for one particular database of the OLTP system aie provided within a combination server 70 using the Windows NT Server operating system
  • ODBC oi othei piotocol communication between the database management system and the application system software is accomplished with dnect software communication between the two software systems rather than using a network connection
  • the Windows NT Server operating system cooperates by supporting ODBC and other communication between separate systems
  • FIG 4 shows diagrammatically certain memory and software interaction between application system software and client system softwaie to effect improvements of the present ⁇ n ⁇ ent ⁇ on
  • the application reserves an area in volatile memory for the opened communication channel, and creates a token, a unique element ot data, to identify the new user session and the new client This token is sent back to the client to identify the new session, which the client retains in volatile memory.
  • Subsequent communications between client and application include the token to identify the communication session being utilized, and cause the user or client context information to be retained on the server as long as needed. So long as the context information is retained, the application server is able to make subsequent and repeated interchanges with the database server in response to client requests during the session.
  • the client has responsibility for notifying the application when the session is ended and is to be dropped.
  • the application releases the memory that was reserved for the context information and the token is released.
  • FIG. 4 also illustrates a portion of volatile memory used in the token and context arrangement just described.
  • Application server 50 reserves a memory area 51 when a new initial client communication is received, and a token is created and stored away as a pointer to the client state information stored in memory area 51.
  • Various items of client state, or context, information may be advantageously stored in memory area 51, depending on the needs of the specific application.
  • an identifier of the current warehouse of interest to the user of the client system may be stored in memory area 51.
  • the warehouse identifier information can then be included in ODBC or other protocol interactions with the DBMS.
  • the current warehouse identifier may be changed from time-to-time as the user's utilization of the inventory system continues over subsequent inquiries during the same session, and the token returned from the client with the subsequent inquiries provides an effective means for locating and updating the user context information.
  • the token is transmitted over network connection 55 to client system 60 where it is retained in memory area 61, which may be volatile or non- volatile, depending on the embodiment, until no longer needed.
  • the token may be retained in volatile memory only until the next transmission of data back to the application server wherein the token is included in the return data.
  • the token may be retained at the client system for a longer period of time, depending on the advantageous use that can be made of the token by the client system, as, for example, until the end of the session.
  • the token may be retained at the client system at least until the text transmission of data back to the application server, and for a longer period, for example, in embodiments wherein client system 60 supports a plurality of human users, and user context information useful to the client is maintained in the client system, or embodiments wherein the token serves different or additional functions, such as a role in security features or other functions related to database functions, application functions, client functions or communication functions.
  • client system 60 transmits the token to application system 50 in one or more subsequent communications to identify the session and the memory area 51 allocated to the client state information. While the session with the client is open, application server 50 is able to make any number of database interchanges with the database server over the ODBC communication channel, either a channel provided by network as illustrated in FIG. 2, or a channel provided by software as illustrated in FIG. 3.
  • keep_alive feature provided by certain implementations of the HTTP protocol.
  • Such an implementation is found in the HTTP protocol provided by the Web server software available from Microsoft for use with Windows NT Server, and by the Microsoft Internet Explorer Web browser software that operates in conjunction with Windows NT.
  • the client system of FIG. 2 or FIG. 3 makes the keep_alive feature available.
  • the recipient of the request maintains the communication channel until it is released by the requester. In this way system overhead is further reduced and system capacity is further increased for multiple interactions or transactions within a session.
  • the HTTP communication channel between the client and application servers can be made continuous as long as reasonably needed.
  • an application server to initiate a keep_alive request to the client system when the application server has a need to transmit relatively large amounts of data requested by the client, such as graphics data, usually in repeated transmissions
  • the application prevents the communication channel from being dropped until the application has finished transmitting all the data requested during subsequent transmissions by the application
  • the client makes a keep_al ⁇ ve request to the application in anticipation of a number of repeated interchanges of information with the application Having received a keep_al ⁇ ve request from the client
  • the Web server if designed to operate with the keep_al ⁇ ve option, can choose to honor the keep_ahve request or not
  • the Web server in conjunction with the application software, honors the keep_al ⁇ ve request and returns a notification to that effect to the client. Thereafter, communications over the HTTP network connection is more efficient since the connection is not
  • FIGS. 5 and 6 show, in flow-chart form, an over- view of the interaction between a client system and the server system in an illustrative application server computer progiam for a simplified example inventory control system having features in accordance with the present invention that has been described hereinabove
  • step 100 a client initially types in the Universal Resource Locator (URL) address of the server system to contact.
  • URL Universal Resource Locator
  • the server verifies whether or not the server already has context data for the contacting Client If there is no context data for the client, at step 104, the server returns a login form to the client, which requests that the client submit identification information At step 106, the client submits the filled in login form, and the server, at step 108, creates user context information and the cookie associated with that context information Then, at step 110, the server sends the client a menu of actions/functions the client can request the server perform, where embedded within the form is the cookie associated with the client's context information. At step 112, the client selects an action from the menu, and this selection is transmitted to the server. Embedded within this and other communications with the server is the cookie value generated in step 108.
  • step 116 If the client has not chosen to quit the program at step 114, resulting in an end to the connection with the server at step 116, the program flow loops back to step 102 in which the server verifies there is a context for the client (which has just been created at step 108), and then at step 118 the server evaluates the selected action/function chosen in step 112. If the request is not valid, either due to the current context for the user, garbled transmission, or some other error, at step 122, the server sends the client an error message.
  • the server performs the chosen action/function.
  • FIG. 6 shows at steps 150-162, for one preferred embodiment of the present invention, the available actions/functions the client may request.
  • the server evaluates whether the client chose to print new order results, step 152, print delivery results at step 154, print payment results at step 156, print stock levels at step 158, print order status information at step 160, or process a login form at step 162.
  • the client login form is treated as any other request the client may make.
  • step 126 of FIGS. 5 and 6, the server transmits to the client the results of performing the requested function.
  • FIG. 5 indicates that after returning results in step 126, program control loops back to step 110 in which the user is then presented with the menu of actions/functions that may be performed.
  • Described hereinbelow is a more detailed-view of the illustrative inventory control program utilized in FIG. 5 and FIG. 6.
  • the illustrative program was compiled with the Microsoft Visual C++ Compiler Version 4.1 to form an embodiment of the present invention, but another compiler and or language may have been used instead. Also note that the following description is not intended to be a fully functional nor fully operational inventory control application.
  • the inventory control application provides HTML Hypertext Markup Language forms to the client system through Web server software.
  • the user of the client system using an available Web browser such as the Microsoft Internet Explorer Web browser, types information into the forms and selects screen buttons appearing on the forms.
  • the Web browser at the client system returns each filled-in form to the application system, which parses the form (Fig. 5 step 118) and selects the information of interest (step 124).
  • the application In response to a login form (step 106) identifying a new u.ser session, the application will reserve an area of user context memory and assign a token (step 108), referred to as the "cookie" in the computer program code described hereinbelow.
  • the cookie is inserted into each of the forms that will thereafter be sent to the user of the client system.
  • the cookie that was placed in the form by the application identifies the user session for the application.
  • the application uses the cookie to locate the user context information to aid further processing of the information provided on the form, or for communicating with the database server, or both.
  • the form data is returned to the application which determines that the Exit button was pressed.
  • the application then releases the user context memory and releases the cookie (token) for re-use by another user, ending the current user session (step 116).
  • each contains a reference to a cookie (token), and this cookie is used to load a context for a particular user.
  • the context is a memory area reserved for the cookie in each form that will be returned to the user.
  • a preferred embodiment will utilize data structures containing fields for tracking data relevant to the transaction taking place between the client and server. For example, once such structure, referenced herein as the raw data form structure, contains entries for identifying the form in use by the client, entries for a product, service or resource being reviewed by the client, quantity indicators, and other data concerning a transaction taking place with a client.
  • Such data structures are then used by the support functions to enter and manipulate transaction data.
  • One such support function is PrintStaticPage(), which is used to send responses back to a client's browser.
  • PrintStaticPage() is used to send responses back to a client's browser.
  • a client user will connect to a server computer through a Web browser, and be presented with a form allowing the u.ser to indicate an action to be performed by the server, such as to perform a price check.
  • different components to the invention perform the database retrieval operation, and the PrintStaticPageQ is then called to dynamically create a formatted HTML page containing the results of the request. This formatted HTML page is then sent back to the client browser so that the results of the request may be seen.
  • VerifyNewOrderLineQ Another support function is VerifyNewOrderLineQ, which verifies that a user's input to a form is valid, and returns an error indicating the location of any errors (such as unexpected blank responses).
  • This function is representative of a set of functions which each verify a certain type of input field. Verifying), VerifyShortQ, etc. are also in this set. VerifyNewOrderLine is more complex in that it checks an entire order line (composed of multiple fields) for validity.
  • PrintNewOrderResults() which is also a function representative of a set of functions, one for each specific transaction, and which interprets a user's response to input forms and generates the appropriate response page data (which is then given to PrintStaticPage() for transmittal to the client browser).
  • This function is passed a pointer to the user's query data, and a pointer to a raw form data structure containing all possible fields that may be assigned values during interacting with a particular client. Initially this function (as do most functions in a preferred embodiment) uses the user's assigned cookie to retrieve the current context data for that client from the server.
  • entries from the raw form are copied into a predefined database-access field.
  • This access field as well as other database related structures and operations used by a preferred embodiment to interact with a SQL-type database, have been defined in the Microsoft TPC-C Benchmark Kit, version 2.04
  • PAYMENT_DATA is filled with data concerning exactly when in time the transaction took place, the nature and status of the transaction, etc. This retrieval is accomplished by passing the predefined structure to a SQLOrderStatus() function (defined by the Benchmark Kit), which queries the appropriate SQL database and fills in the predefined structure
  • SQLOrderStatus() function defined by the Benchmark Kit
  • handling functions which inte ⁇ ret user responses to the forms and provide some of the basic functions found in an inventory control system
  • the cookie is retrieved from the form, converted from a string into a number, and the number used to index into an array (m_pContext) of user context information from an operating server
  • One such handling function is ProcessLog ⁇ nForm(), this function generates a request for the allocation of a new user context memory area and the creation of an associated cookie that refers to it.
  • Another handling function ParseFormData(), breaks up the data string comprising the form sent from the client system into individual data units, the cookie being one such data unit.
  • Another handling function, SelectPageQ takes the cookie returned from the client system in string form, converts it into a number that can be used as an index into the user context array, and checks its validity. Then the function branches into one of a number of paths that process a specific request made by the user (step 124), and determines which output page should be displayed back to the user.
  • each of the forms labeled nform and oform are created at the outset during login, and initialized with the cookie for future use Input received from a user are tagged, such that if the user pressed the exit button, the server program would receive an action case of 'E', causing a function call to release the user context memory area and the cookie. Other actions are similarly tagged for processing by the server.
  • HttpExtensionProcQ Another handling function is HttpExtensionProcQ, this function, in response to a keep_al ⁇ ve iequest from the client, this function complies with the request and returns a value to the client that keeps the network connection active
  • each client communication from the Web browser to the Web server includes a request to keep the connection alive
  • the Web server complies and returns a similar request to the client.
  • FreeContext() that deletes the user context and marks the array slot free for future use
  • this function receives as an argument a cookie, and if a user session is associated with the cookie, the associated database connection is closed, and associated resources released
  • FIG 7 is a flow-chart showing the general handling of cookies by a preferred embodiment.
  • the program waits 200 for a usei request to be received, during the first request, a connection is automatically established with a servei
  • a check is made 202 to determine whether a token was embedded in the request, and if not, an initial context is created 204 on the server.
  • the users' request is then processed 206 according to the request type and associated data.
  • the client's sate information is updated according to the transaction processed.
  • a test is made 208 to determine if the action taken by the user was to perform a logoff from the server.
  • the context for the user is deleted 210 and a logoff response (without a cookie/token) is presented to the user and the user drops the connection. If it was not a logoff request, then the user is sent a response 210 (containing a cookie) corresponding to the results of the requested transaction. The connection is not dropped by the user, and the server continues to wait 200 for further requests from the user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Système client-serveur utilisant un protocole sans état afin d'accéder aux données du serveur par l'intermédiaire d'un réseau (55). Ce système peut mettre en application un traitement de transaction en ligne, dans lequel un client (60) utilise un logiciel informatique spécialisé afin de produire des formulaires d'entrée servant à indiquer l'information à extraire d'un serveur d'application (50). Un identificateur unique est généré afin d'identifier un client particulier et est intégré dans les communications entre le client (60) et le serveur d'application (50), la présence d'un identificateur provoquant le maintien d'une connexion de réseau active (55) avec le client par le serveur d'application (50), et permettant au serveur d'application de maintenir une information d'état côté serveur, telle qu'une information à distribuer à l'ordinateur du client ou à l'identificateur du client, ainsi que toute autre information souhaitée concernant les activités du client. Le maintien d'une connexion active, par rapport à un arrêt et à une reprise du contact, limite la surcharge du réseau. Un serveur de base de données (40) peut fonctionner en association avec le serveur d'application (50) par l'intermédiaire de communications sur une deuxième connexion de réseau (45) afin de mémoriser l'information côté serveur. Le serveur d'application (50) peut être mis en application au moyen de la technologie du serveur de Web. Si on utilise le Protocole de Transfert Hypertexte HTTP sur un réseau (55) afin de communiquer avec le client (60), le client (60) peut utiliser tout système d'exploitation supportant le protocole HTTP.
EP97922344A 1996-04-19 1997-04-17 Systeme et procede servant a acceder a des donnees Withdrawn EP0894392A2 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US1636896P 1996-04-19 1996-04-19
US16368P 1996-04-19
US1748396P 1996-04-26 1996-04-26
US17483P 1996-04-26
US2457196P 1996-08-26 1996-08-26
US24571P 1996-08-26
PCT/US1997/006468 WO1997040457A2 (fr) 1996-04-19 1997-04-17 Systeme et procede servant a acceder a des donnees

Publications (1)

Publication Number Publication Date
EP0894392A2 true EP0894392A2 (fr) 1999-02-03

Family

ID=27360548

Family Applications (1)

Application Number Title Priority Date Filing Date
EP97922344A Withdrawn EP0894392A2 (fr) 1996-04-19 1997-04-17 Systeme et procede servant a acceder a des donnees

Country Status (2)

Country Link
EP (1) EP0894392A2 (fr)
WO (1) WO1997040457A2 (fr)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026404A (en) * 1997-02-03 2000-02-15 Oracle Corporation Method and system for executing and operation in a distributed environment
US6845505B1 (en) 1997-02-03 2005-01-18 Oracle International Corporation Web request broker controlling multiple processes
US6710786B1 (en) 1997-02-03 2004-03-23 Oracle International Corporation Method and apparatus for incorporating state information into a URL
US6225995B1 (en) 1997-10-31 2001-05-01 Oracle Corporaton Method and apparatus for incorporating state information into a URL
US6247056B1 (en) 1997-02-03 2001-06-12 Oracle Corporation Method and apparatus for handling client request with a distributed web application server
US6334114B1 (en) * 1997-10-31 2001-12-25 Oracle Corporation Method and apparatus for performing transactions in a stateless web environment which supports a declarative paradigm
GB2333379A (en) 1998-01-16 1999-07-21 Ibm Client/server computing
GB2336006A (en) * 1998-03-31 1999-10-06 Ibm Client/server computing with client selectable location of transaction objects
EP1628454B1 (fr) 1998-04-28 2018-12-26 Nokia Technologies Oy Procédé et réseau pour la gestion de sessions du protocole wsp (wireless session protocol)
US6751654B2 (en) * 1999-03-31 2004-06-15 International Business Machines Corporation Simulating web cookies for non-cookie capable browsers
US6877095B1 (en) 2000-03-09 2005-04-05 Microsoft Corporation Session-state manager
JP3466998B2 (ja) 2000-07-06 2003-11-17 株式会社東芝 通信装置及びその制御方法
US7512715B2 (en) * 2003-09-26 2009-03-31 Nokia Corporation System and method for requesting a resource over at least one network with reduced overhead
US8156203B2 (en) 2008-09-15 2012-04-10 Microsoft Corporation Dye injected request generation
CN111382152B (zh) * 2018-12-27 2023-10-20 杭州海康威视数字技术股份有限公司 数据表处理方法、装置及存储介质
CN109639730A (zh) * 2019-01-21 2019-04-16 北京工业大学 基于令牌的http无状态协议下信息系统数据接口认证方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9740457A2 *

Also Published As

Publication number Publication date
WO1997040457A2 (fr) 1997-10-30
WO1997040457A3 (fr) 1997-12-11

Similar Documents

Publication Publication Date Title
US6038562A (en) Interface to support state-dependent web applications accessing a relational database
US6360250B1 (en) Apparatus and method for sharing information in simultaneously viewed documents on a communication system
AU734533B2 (en) Apparatus and method for identifying clients accessing network sites
US7171472B2 (en) Shared internet storage resource, user interface system, and method
JP4729172B2 (ja) 宣言型パラダイムをサポートするステートレスなウェブ環境におけるトランザクションを実行するための方法および装置
US7035828B2 (en) Method and system for modifying and transmitting data between a portable computer and a network
US7752634B1 (en) Non-intrusive personalization of web services
US7490135B2 (en) Method for providing node targeted content in an addressable network
WO1997040457A2 (fr) Systeme et procede servant a acceder a des donnees
US6363398B1 (en) Database access using active server pages
US6353851B1 (en) Method and apparatus for sharing asymmetric information and services in simultaneously viewed documents on a communication system
US6691100B1 (en) HTML/DHTML web interface system and method
US7970862B2 (en) Web services response templates
US8949311B2 (en) Dynamic, non-intrusive personalization of web services
US20100185614A1 (en) Shared Internet storage resource, user interface system, and method
US7496578B2 (en) Shared internet storage resource, user interface system, and method
JP2006501558A (ja) ウェブ・アプリケーション用のウェブ・ページのセッションをユーザに表示する装置と方法
US6175864B1 (en) Method and apparatus for storyboard scripting of application programs running on a computer system
WO2002073339A2 (fr) Acces aux donnees centre sur l'identite
AU6047898A (en) Web request broker controlling multiple processes
WO2001050299A2 (fr) Systeme et procede pour la divulgation incrementielle d'informations personnelles a des fournisseurs de contenus
EP1325424A2 (fr) Procede et systeme d'assemblage de contenu produit simultanement
US6631424B1 (en) Distributing information using a computer
US6915341B2 (en) System for sending messages to all users in a web hosting environment
WO2003090111A1 (fr) Procede de renouvellement de l'affichage d'un navigateur web en temps reel, et support d'enregistrement correspondant

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19980902

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): BE DE FR GB IT LU NL

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20011101