Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2000-09-21
2003-12-16
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000, C709S241000, C709S241000, C709S241000, C709S241000
Reexamination Certificate
active
06665734
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer software, and deals more particularly with a method, system, and computer program product for blending object-oriented programming languages with traditional programming languages such that they can execute and share data in a coordinated and integrated manner.
2. Description of the Related Art
Many modern program development environments include both object-oriented (OO) components and traditional non-object-oriented (non-OO) or procedural programming language constructs. The OO components are often used in the user interface. They may also be the main data objects that describe the business system (e.g. Customer objects, Order objects, and so forth in a customer ordering application). The business logic of the application, however, might not be written using an OO language, but might be written instead in a more traditional procedural programming language. It might even be legacy code that only uses OO objects by introduction of a new graphical user interface (GUI). The OO and procedural constructs might even use two completely different namespaces.
A problem arises when developers need to merge the OO and non-OO technologies in a productive way. When application environments include a mix of OO objects and non-OO programming language constructs, there is typically no efficient way for the business logic written in the non-OO programming language to interface with and manipulate the OO objects without interrupting the flow of the business logic.
The problem of integrating OO and non-OO languages was discussed in “Bridging traditional and object technologies: Creating transitional applications”, A. H. Lindsey and P. R. Hoffman,
IBM Systems Journal,
Vol. 36, No. 1, (1997), which focuses on rapid application development using visual programming and object-oriented techniques. The section titled “Part and Object Scripting from within Traditional Languages” discusses the need to provide access to visual parts from within non-OO code. The approach described therein is to introduce an “object handle” into the non-OO code namespace, and then to provide addressability to objects in the GUI namespace using instances of object handles to (1) get to parts on the GUI, and (2) get to other OO objects. This approach was intended to enable sending messages to parts or objects, passing arguments, and signaling events that the part or object understood.
The disclosed solution had a number of problems in actual implementation, however. First, it was very complicated, leading to even more difficulties for developers attempting to “bridge the gap” between OO and traditional programming. In addition, the object handle concept did not fit well into the non-OO data item concepts, where a number of the concepts used in the OO world (null values, etc.) do not typically exist. Furthermore, the built-in functions described in the disclosed solution required developers to code complicated data conversion techniques in order to pass arguments of the proper type.
There have been other attempts to bridge this gap between OO objects and non-OO languages, but they have proved inadequate. One prior art approach uses visual connections depicted on a GUI to control OO objects. Several graphical composition editors are commercially available to support this type of programming, which may function adequately for very simple scenarios. However, in a real application system this approach quickly becomes a maintenance and performance nightmare. The graphical representation of the OO objects becomes cluttered with visual connections to control the OO objects directly, or to execute OO scripts to control the objects. In addition to being visually cumbersome, these visual connections cannot be driven effectively from within the business logic because there is no non-OO construct to fire the GUI visual events in amongst the other non-OO code.
Another prior art approach is the “PerformRequest” support which is provided in the IBM VisualAge® Generator (hereinafter, “VG”) product. (VisualAge is a registered trademark of IBM.) This PerformRequest technique allows the VG non-OO code to set up an object to manipulate the OO objects after a business logic component has completed execution. This allows some level of mixing OO objects and non-OO programming languages, but it is inefficient and unnatural because the interaction with the OO objects does not take place during the natural flow of the business logic. Instead, the non-OO business logic must come to the end of the currently-executing component (where a component is analogous to a subroutine or function), and then control can be given over to the OO context where results of the business logic may be reflected in the objects and on the GUI. (Note: the term “context”is used herein in a general sense and not as a specific computer science term. For example, “OO world”, “OO environment”, and “OO context” are all intended to be synonymous.) The data used by the two parts of the system (i.e. the GUI part and the business logic part) is not synchronized, and there is therefore no way to manipulate an OO object in one business logic statement and then immediately use the results of that OO object change in the next business logic statement.
There are many situations in which the business logic code needs to directly interact with OO methods as the business logic executes, rather than awaiting completion of the invoked business logic, such that the two parts of the system can execute in an integrated manner. Prior art systems do not provide this type of integration. To illustrate the problem, suppose the business logic performs analysis or error checking of data values which an application user enters into the fields of a user interface panel. Further suppose that this analysis code is designed to display an error message window, at run-time, upon detecting a problem with any of the input data values. Preferably, each detected error would be displayed as it is detected. If the procedural business logic construct has no facility for returning control to the GUI context until all of the business logic corresponding to the invoked GUI event has completed, the error message window will not be displayed at the most appropriate time (and any related OO logic will not execute in-line, before other business logic data processing occurs). This delay between detecting an error and presenting it on the GUI, while control is forced to remain in the business logic being executed until that code completely finishes, leads to an unnatural, inefficient reflection of the results of the business logic's processing on the user interface.
In many application scenarios this non-integrated execution presents an especially undesirable approach. Suppose, in this same example, that the application allows the user to enter values of several fields into the GUI before invoking the business logic which analyzes each field value. (This approach may be useful, for example, when the value of one field dictates the allowable values of another field.) It may therefore happen that multiple error messages are generated while the business logic executes. Because the non-integrated code does not present error messages upon detection, the developer must typically provide a means for saving each generated message until all the analysis code completes, and a means for then displaying each message in sequence (preferably, in order of the business logic processing). This may be done, for example, by creating a collection or table of error messages as the procedural analysis code executes, and then iteratively processing each saved element of the created structure in the GUI code for display to the user when the analysis code is complete. However, this approach is quite cumbersome and is therefore undesirable.
Many other scenarios can be envisaged where the lack of integration between OO and non-OO parts of a system presents similar difficulties.
In the general case, developers are left with the choice of presenting th
Akilov Alex Abraham
Huynh Tuyet Diem
Lindsey Anthony Hayden
Lindsey Beth Bridgers
Wilson Timothy
Cao Diem
Doubet Marcia L.
Doudnikoff Gregory M.
Follansbee John
International Business Machines - Corporation
LandOfFree
Blending object-oriented objects with traditional... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Blending object-oriented objects with traditional..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Blending object-oriented objects with traditional... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3160937