Creating applications within data processing systems by...

Details Creating applications within data processing systems by... Creating applications within data processing systems by...

1998-12-03

2003-10-21

Dam, Tuan Q. (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Code generation

C717S108000, C717S140000, C709S241000

Reexamination Certificate

active

06637020

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to an improved method of developing applications for data processing systems, and in particular to provide such an improved method wherein applications are created utilizing object-oriented programming components. Still more particularly, the present invention relates to an improved method of developing applications for data processing systems utilizing object-oriented programming language within a distributed object oriented system environment wherein program components are wired dynamically to create client side applications.
2. Description of the Related Art
A generalized structure for a conventional data processing system includes one or more processing units connected to a system memory device (random access memory or RAM) and to various peripheral, or input/output (I/O) devices. The I/O devices typically include a display monitor, a keyboard, a graphical pointer (mouse), and a permanent storage device (hard disk). The system memory device is utilized by a processing unit in carrying out program instructions, and stores: those instructions as well as data values that are fed to or generated by the programs. A processing unit communicates with the other components by various means, including one or more interconnects (buses), or direct access channels. A data processing system may have many additional components, such as serial and parallel ports for connection to, e.g., printers, and network adapters. Other components might further be utilized in conjunction with the foregoing; for example, a display adapter might be utilized to control a video display monitor, and a memory controller can be utilized to access the system memory, etc.
FIG. 1
depicts the basic structure of a conventional data processing system
10
. Data processing system
10
has at least one central processing unit (CPU) or processor
12
which is connected to several peripheral devices, including input/output devices
14
(such as a display monitor, keyboard, and graphical pointing device) for the user interface, a permanent memory device
16
(such as a hard disk) for storing the data processor's operating system and user programs, and a temporary memory device
18
(such as random access memory or RAM) that is utilized by processor
12
to carry out program instructions. Processor
12
communicates with the peripheral devices by various means, including a bus
20
or a direct channel
22
(more than one bus may be provided utilizing a bus bridge).
Data processing system
10
may have many additional components which are not shown such as serial, parallel, and USB ports for connection to, e.g., modems or printers. Those skilled in the art will further appreciate that there are other components that might be utilized in conjunction with those shown in the block diagram of
FIG. 1
; for example, a display adapter connected to processor
12
might be utilized to control a video display monitor, and a memory controller may be utilized as an interface between temporary its memory device
18
and processor
12
. Data processing system
10
also includes firmware
24
whose primary purpose is to seek out and load an operating system from one of the peripherals (usually permanent memory device
16
) whenever data processing system
10
is first turned on.
The operation of data processing systems of the type depicted in
FIG. 1
is well known in the art. Program information comprising instructions and/or data is stored on permanent memory device
16
and may be selectively copied into temporary memory device
18
once data processing system
10
is powered on. Processor
12
executes the instructions within such program information and generates text or graphical information for presentation on display output device connected via graphics adapter, where the information may be viewed by a user. The user may selectively control operation of data processing system
10
through input entered on one of input/output devices
14
.
A data processing system program is accordingly a set of program instructions which are adapted to perform certain functions by acting upon, or in response to, the I/O devices. Program instructions that are carried out by the processor are, at that lowest level, binary in form, i.e., a series of ones and zeros. These executable (machine-readable) program instructions are produced from higher-level instructions written in a programming language. The programming language may still be low-level such as assembly language (which is difficult to utilize since instructions appear as hexadecimal bytes), or may be a higher level language in which instructions are created utilizing more easily understood words and symbols.
In an attempt to simplify programming, and yet still provide powerful development tools, programmers have created “object-oriented” programming languages in which each variable, function, etc., can be considered an object of a particular class. Object oriented programming is governed by the Common Object Request Broker Architecture (CORBA) standard which originates from the Core Object Model.
The main goals of the Core Object Model are portability and interoperability. Interoperability means being able to invoke operations on objects regardless of where they are located, which platform they execute on, or what programming language they are implemented in. This is achieved by the Object Request Broker (ORB), which relies on the semantics of objects and operations described in the Core Object Model. The ORB also requires some extensions to the core which provide specifications for specific communication protocols, an interface definition syntax, and basic services to object implementations. CORBA provides several extensions: Objects, defined simply as models of entities or concepts; Operations signatures (parameters and return values) where an operation is an action offered by an object which is known to the outside world by its signature. Further, an operation's signature has the following components: a name, a set of parameters, and a set of result types. Operation signatures are unique within a particular object.
An interface is a collection of operation signatures and attributes. Typically, the interface to an object is the set of operations offered by that object. Interfaces are related to one another by substitutability relationships. This means that an object offering an interface can be utilized in place of an object offering a “similar” interface. The Core Object Model simply defines substitutability as being able to utilize one interface in place of another without “interaction error”.
Since interfaces may offer operations with the same signatures that have different purposes and semantics, it is useful to have an assertion of compatibility between them. In order to ensure a semantic relationship, the model introduces inheritance. If interface A inherits from interface B, then A offers all of the operations of B, and may also offer some additional operations. The set of operations of A is therefore a superset of the operations of B, and hence A is substitutable for B.
At the heart of CORBA is the Interface Definition Language (IDL). It provides a way of defining the interfaces of objects independently of the programming language in which they are implemented. It is a strongly typed declarative language with a rich set of data types for describing complex parameters. An IDL interface acts as a contract between developers of objects and the eventual users of their interfaces. It also allows the utilization of CORBA objects to compile the interface definitions into hidden code for the transmission of invocation requests across networks and machine architectures without knowledge of the network protocol, the target machine architecture, or even the location of the object being invoked.
IDL definitions inform clients of what operations an object supports, the types of their parameters, and what return types to expect. A client programmer needs only the IDL to write client code that is ready to

Affiliated with

Also associated with

Rating

Creating applications within data processing systems by... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Creating applications within data processing systems by..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Creating applications within data processing systems by... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3151209