Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-09-08
2001-07-24
Breene, John (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06266666
ABSTRACT:
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
The present invention relates generally to distributed computing systems and, more particularly, to a system and methods for improving data access and operation in distributed computer environments.
Today, most computers are linked to other computer systems via a computer network. Well-known examples of computer networks include local-area networks (LANs) where the computers are geographically close together (e.g., in the same building), and wide-area networks (WANs) where the computers are farther apart and are connected by telephone lines or radio waves.
Often, networks are configured as “client/server” networks, such that each computer on the network is either a “client” or a “server.” Servers are powerful computers or processes dedicated to managing shared resources, such as storage (i.e., disk drives), printers, modems, or the like. Servers are often dedicated, meaning that they perform no other tasks besides their server tasks. For instance, a database server is a computer system that manages database information, including processing database queries from various clients. The client part of this client-server architecture typically comprises PCs or workstations which rely on a server to perform some operations. Typically, a client runs a “client application” that relies on a server to perform some operations, such as returning particular database information.
Often, client-server architecture is thought of as a “two-tier architecture,” one in which the user interface runs on the client or “front end” and the database is stored on the server or “back end.” The actual business rules or application logic driving operation of the application can run on either the client or the server (or even be partitioned between the two). In a typical deployment of such a system, a client application, such as one created by an information service (IS) shop, resides on all of the client or end-user machines. Such client applications interact with host database engines (e.g., Sybase® SQL Server™), executing business logic which traditionally ran at the client machines.
More recently, the development model has shifted from standard client/server or two-tier development to a three-tier, component-based development model. This newer client/server architecture introduces three well-defined and separate processes, each typically running on a different platform. A “first tier” provides the user interface, which runs on the user's computer (i.e., the client). Next, a “second tier” provides the functional modules that actually process data. This middle tier typically runs on a server, often called an “application server.” A “third tier” furnishes a database management system (DBMS) that stores the data required by the middle tier. This tier may run on a second server called the database server.
The three-tier design has many advantages over traditional two-tier or single-tier designs. For example, the added modularity makes it easier to modify or replace one tier without affecting the other tiers. Separating the application functions from the database functions makes it easier to implement load balancing. Thus, by partitioning applications cleanly into presentation, application logic, and data sections, the result will be enhanced scalability, reusability, security, and manageability.
In a typical client/server environment, the client knows about the database directly and can submit a database query for retrieving a result set which is generally returned as a tabular data set. In a three-tier environment, particularly a component-based one, the client never communicates directly with the database. Instead, the client typically communicates through one or more components. Components themselves are defined using one or more interfaces, where each interface is a collection of method. In general, components return information via output parameters. In the conventional, standard client/server development model, in contrast, information is often returned from databases in the form of tabular result sets, via a database interface such as Open Database Connectivity (ODBC). A typical three-tier environment would, for example, include a middle tier comprising business objects implementing business rules (logic) for a particular organization. The business objects, not the client, communicates with the database. Nevertheless, there is still the desire to have client/server features, such as scrollable results and data input fields.
Since existing tools were created for the client/server model, they are better suited or adapted to receiving table-based or tabular “result sets” for retrieving complex data. Also, tabular data tends to be a more efficient way to retrieve data from a relational database, such as from Sybase® SQL Server. At the same time, however, components provide distinct advantages. In particular, they provide a well-designed model and interface, so that reusable code is achievable with minimal effort.
One common mechanism for retrieving tabular data through component-based interfaces is to return output parameters in the form of arrays of structures, or arrays of objects. The approach is problematic, however. First, present-day automated development tools that allow a developer to rapidly build application programs are tied to tabular data interfaces, such as ODBC. Such tools allow the developer to “bind” the visual controls to relational data, quickly build forms for data entry, and quickly generate reports for reporting information of interest. Quite simply, components that return arrays of structures cannot participate in this level of automation. Second, existing network transport mechanisms for returning these kinds of structures tend to have poor performance. Traditional transport mechanisms have generally been much better suited at transporting tabular data.
What is needed is a solution in which provides a simplified database connectivity interface for communicating with components, including Java and ActiveX components, as well as conventional C components, such that the interfaces of the components can be called for returning a tabular result set to the client. The present invention fulfills this and other needs.
SUMMARY OF THE INVENTION
A Component Transaction Server (CTS) is described, which provides a framework for deploying the middle-tier logic of distributed component-based applications. The CTS simplifies the creation and administration of Internet applications that service thousands of simultaneous clients. The CTS components, which execute on the middle-tier between end-user client applications and remote databases, provide efficient management of client sessions, security, threads, third-tier database connections, and transaction flow, without requiring specialized knowledge on the part of the component developer. The system's scalability and platform independence allows one to develop application on inexpensive uniprocessor machines, then deploy the application on an enterprise-grade multiprocessor server.
The CTS architecture supports a variety of thin-client front ends, including Java applets deployed on the Internet or Web, PowerBuilder™ clients deployed on a standard desktop, or any ActiveX client. Web-based clients communicate with server components executing in the CTS kernel using HTTP (HyperText Transport Protocol) and an HTTP server embedded in CTS. Windows-based clients communicate with server components using a streaming protocol, such as Sybase® Tabular Data Stream (TDS) protocol.
The CTS kernel includes a Session Management module, a Security module, a Result Set module, a Thread Polling module, a Transaction Management module, and a Connection Po
Ireland Evan
Van Couvering David W.
Breene John
Rayyan Susan
Smart John A.
Sybase Inc.
LandOfFree
Component transaction server for developing and deploying... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Component transaction server for developing and deploying..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Component transaction server for developing and deploying... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2537316