Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-03-08
2002-03-12
Black, Thomas (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06356920
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to networked computer systems in which a plurality of interconnected computer systems exchange data.
BACKGROUND OF THE INVENTION
The present invention relates to computer systems interconnected by a network, suitably configured to transfer data between one another. A computer system connected to the network processes data from a plurality of data sources. A data source can be an input device attached to the computer system, or can be a storage device, memory, database, or other computer system attached either locally or remotely to the computer system via a network. In the network of computers, at any given time, a computer system may assume a specific role, relative to the processing of data. A computer system that sends a request for data from another computer system is said to be a Client system
1
. The computer system that processes requests from other computer systems is said to be a Server system
2
. When a Client sends a request for data to a Server, the Server may retrieve some of the requested data from its local resources, and some of the data from an External source
3
on the network. The Server
2
in this case acts as a Client to an External source
3
, requesting the appropriate data, and the External source
3
acts as a Server. Thus, a computer system on the network may at one time perform the role of a Client, and at another time perform the role of a Server.
Servers on the network are designed to satisfy requests for a particular type of data. For example, a database server may be designed to accept Structured Query Language (SQL) requests from clients. The database server will execute the SQL and return the resulting database data to the requesting client. A Hyper Text Transfer Protocol (HTTP) server (or Web Server) accepts HTTP request from client systems (generally Web Browsers), processes the requests, and returns the resulting Hyper Text Markup Language (HTML) to the client. In an enterprise business environment, such as the Information Processing environment of a large company, a Server system may accept requests for customer account information. A Client may send the request to the Server in an agreed-upon format, and the Server locates the information within its system or a connected system, then returns the customer account information to the Client. Frequently, in the enterprise business environment, the nature of the large systems involved dictates that the data exchange uses a custom data format instead of an industry standard such as SQL or HTML.
Large corporations often house data in a multitude of sources, such as a host, database, server, or other information source. Often, one computer system may need to retrieve data from many other systems in order to perform its function. Systems in this environment contain complex programs that understand the intricacies of interfacing to each system that contains a data item in need. Such programs are complex to write and maintain, require great expense to development and modify, and are large in size due to the amount of code required for the large number of interfaces. In addition, typical systems access data sequentially, thus perform operations slowly more slowly than if data could be retrieved in parallel. More advanced systems perform some data retrievals in parallel, but the complexity of this type of system requires greatly more experienced programmers and testers, thus significantly increasing the cost of system development. Finally, the code developed to interface to each system and each data source is not easily reused in other systems in the enterprise for a variety of reasons. Program A may be a customer service application and may access servers
1
,
2
, and
3
. Program B developed by another group may be a billing system that accesses servers
1
,
2
, and
4
. Some reasons for low success rate of reuse are the fact that programs perform vastly different functions (service vs. billing), so developers often do not recognize the possibilities of reusing code. Tools to assist in reuse are not widely used, developers are generally slow to be convinced that existing components will precisely fit their needs, and current engineering practices that emphasize reuse have not been widely adopted in many corporations. In the cases where code is reused, it often is copied and customized by a programmer, requiring work for the customization and testing for the resulting implementation.
When a Client requires data from many different sources, it must contain a method and apparatus to send a request to each Server providing each type of required data. The Client also must have a method and apparatus to both receive the response data from the Server and to make sensible use of the data. Likewise, a Server needs a method and apparatus to process requests from Clients, and return resulting data to them. In the typical enterprise computer system environment, the methods and apparatuses for both Client and Server must be developed, integrated, tested, and deployed.
The methods and apparatuses necessary for a Client to usefully retrieve and process data from a Server is called an Interface. The code components involved in an Interface are shown in FIG.
3
. The Client makes a request from the Request Code
4
, which contains the method and apparatus to send the request to the Server and receive the result. The Request Code uses information from the Data Source Description Code
5
component located on the Client, which contains the method and apparatus to identify how to physically connect and maintain a connection to the Server. The Server component contains a Service Processor
6
that contains the method and apparatus to receive the request, cause the Server to process the request, then return the results to the Client. The Request Code for the Client receives the request, then identifies and interprets each element of information in the return using the method and apparatus contained in the Parsing Code
7
. In total,
4
components must be developed for each interface.
Many computer systems use standard interface components such as those supporting SQL requests to database management systems (DBMS) to drastically reduce development time. Unfortunately, many computer systems in large enterprise environments require interfaces customized for the particular Client and Server pair. For these systems, a large number of interface components must be developed. As an example, assume two client systems interface with
4
server systems as shown in FIG.
3
. Each server requires a Service Processor. Each Client requires Request Code, Server Description Code, and Parsing Code for each interface, therefore Client
1
requires 9 components and Client
2
requires 9 components, for a total of 22 total development components for the depicted interfaces. It is possible for Clients to share interface components, for example, Client
2
can reuse the code developed in Client
1
for its interface to Server
1
. However, it is more often the case in large enterprise environments for Client
1
and Client
2
to be developed by separate groups, and the opportunity to reuse the code is not exploited.
There is a need for an interface strategy that organizes the implementation of the interface components, so that interface components are only developed a single time, regardless of the number of Clients implementing similar interfaces to various servers. This would result in fewer development resources being expended, because many of the interface components would be developed a single time, instead of once for each Client system.
Client systems generally request data in a sequence of steps. For example, a customer service application may perform the following sequence of processing steps: 1) obtain a customer phone number from the user, 2) request account information such as name, address, and account number from a Server, 3) send request to another Server to retrieve current order information, 4) send a request to the same server to retrieve order detail information, 5
Black Thomas
Halling Dale B.
Jury David
X-Aware, Inc
LandOfFree
Dynamic, hierarchical data exchange system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Dynamic, hierarchical data exchange system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic, hierarchical data exchange system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2859187