Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1995-07-21
2001-07-24
Courtenay, III, St.-John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C717S152000
Reexamination Certificate
active
06266708
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to data processing and, more specifically, to object-oriented programming systems and processes.
2. Description of the Related Art
Application programs are sequences of program instructions that are executed on programmable, general purpose computers to perform problem-solving tasks. Application programs are very important within the computer industry because they allow users of the computer system to perform meaningful work. In fact, application programs are so important that the ultimate value of the whole computer system is often judged based on the quality and number of application programs that it can execute.
Application programs can be developed to aid computer system users in a wide variety of tasks. For example, there have been many application programs written to aid users in tasks that are related to banking, inventory control, and scientific analysis. Typically, application programs are developed by individuals or teams of individuals in a way that addresses the specific problem at hand. However, developing an application program is not an easy process. Indeed, the process of developing application programs is fraught with many inherent pitfalls.
One problem is that each application program typically requires different types of data to be maintained and different manipulations to be performed on the data. For example, banking transactions must be confirmed and logged, inventory orders must be validated, and scientific operations must be checked for errors. As a result, application programs are often designed to be unique unto themselves. That is, the program instructions are application-dependent even though the low-level tasks performed by different application programs all involve the storage, retrieval, and manipulation of data. Of course, this not only is wasteful but also leads to the additional problem of having to maintain a series of application programs that all store, retrieve, and manipulate data in different ways.
Another problem associated with application program development is that communication between different application programs is often difficult. Communication between present day application programs is usually accomplished through what are referred to as application program interfaces or APIs for short. Since APIs rigidly define both the manner in which data can be exchanged and the particular items of data that can be exchanged, it is sometimes difficult to change an application program to handle different data or to make a previously created application program communicate with a new application program.
Adding features to application programs is yet another problem because the entire application program must typically be recompiled to activate the new feature. This is a daunting task because many application programs include literally tens of thousands of lines of programming instructions, which means that recompilation can be an extremely long process.
Still another problem with application program development is extending or modifying an existing application program so that it can take advantage of a new programming development. For example, modifying an application program that was originally designed to execute on a single processor computer system such that it could operate on a multiprocessor system can involve considerable effort and a substantial amount of redesign.
From the discussion above, it should be apparent that there is a need for an application program development mechanism that allows for the development of application programs that 1) do not involve duplication of effort to perform common tasks, 2) do not place heavy burdens on program maintenance, and 3) permit the addition of program features without requiring total recompilation and/or redesign. Moreover, there is a need for an application program development mechanism that provides a standard program interface that facilitates communication between application programs. The present invention satisfies these needs.
SUMMARY OF THE INVENTION
In accordance with the present invention, a reusable object-oriented (OO) framework for use with object-oriented programming systems permits plug-compatible application program development in either local or distributed computing environments. The framework includes one or more objects of a class called “Socket” that receive and process program operations comprising packets of work. As various applications execute, they require servicing of the packets of work, which are represented in the framework by objects of a class called “WorkUnit”. When a WorkUnit object is generated by an application, it in turn generates an object of a class called “Retriever”, which is associated with the appropriate Socket object needed for servicing the WorkUnit. The Retriever object retrieves the Socket object from an object of a class called “SessionInfo” to service the WorkUnit object. If the ScssionInfo object does not already contain an instance of the Socket object being retrieved, it will generate one, add it to the SessionInfo object, and return it to the requesting WorkUnit object. The SessionInfo object is a single object for maintaining registries of Socket objects and objects of a class called “ApplInfo”. ApplInfo objects contain application specific information that can be used, manipulated, and shared between one or more WorkUnits of a given application. WorkUnit objects of an application can retrieve ApplInfo objects from the SessionInfo object by use of a Retriever object which is associated with the appropriate ApplInfo object. If the SessionInfo object does not already contain an instance of the ApplInfo object being retrieved, it will generate one, add it to the SessionInfo object, and return it to the requesting WorkUnit object.
The only responsibility of the Socket objects is to receive and perform WorkUnit objects. The Socket objects perform WorkUnit objects by invoking them. A WorkUnit object is invoked by calling a “doIt” method, which is defined by the framework user according to the application program being developed. WorkUnit objects generate other WorkUnit objects and send them to Socket objects to be received and processed. Many WorkUnit objects may subdivide a given application into many smaller work packets which are all represented by WorkUnit objects. The WorkUnit objects chained together collectively perform the larger work packet of the application itself. The framework includes a core set of classes, including SessionInfo, Socket, ApplInfo, Retriever, and WorkUnit classes. In addition, some of these classes such as Socket, ApplInfo, Retriever, and WorkUnit may be further customized through the use of inheritance. In this way, the framework provides a means for defining program work packets and for sharing such defined work packets among several application programs. Thus, application development time is reduced because application programs can be developed around “plug-compatible” work objects that provide commonly needed functions and users have the flexibility to define extensible classes for custom functions. That is, the framework provides application developers with the ability to use core, predefined classes and also to add further classes without worrying about compatibility problems and without need for total recompilation.
If desired, different socket types can be defined for different work packets. For example, an object of a class called “FirstSocket” can process WorkUnit objects by invoking a “doItS1” method and an object of a class called “SecondSocket” can process WorkUnit objects by invoking a “doItS2” method. These “doIt” methods (in the generic sense of the term) are user-defined by the framework client (i.e., they are pure virtual functions) in the derived classes of FirstSocketWorkUnit and could in the first case (doItS 1) request information and in the second case (doItS2) process that information. Socket objects run in their own thread of control or process on multiprocessing systems and can therefore p
Austvold Shawn M.
Cline Marshall P.
Dahl Daniel R.
Evans Jim
Gaertner Peter M.
Baker & Maxham
Courtenay, III St.-John
International Business Machines - Corporation
Martin Derek P.
Martin & Associates L.L.C.
LandOfFree
Object oriented application program development framework... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object oriented application program development framework..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object oriented application program development framework... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2485292