Method and apparatus for interactively connecting distributed objects to a graphic user interface

1.

FIELD OF THE INVENTION

0001This invention relates to object-oriented programming and, more specifically, to the interactive connection of distributed objects to a graphic user interface (GUI).

2.

BACKGROUND

0002A software application typically includes a GUI that provides an interface between an application user and the application. In an object-oriented environment, the GUI uses GUI objects to control the fields in the GUI. To use the data input via the GUI, an application object is connected to the GUI object. Data entered in a GUI field is forwarded to the application object via the connection formed between the GUI object and the application object. In a distributed environment, the GUI object and application object can reside on different computer systems.

0003In the prior art, it is necessary to generate customized code for use by the software application to create the connection between the GUI object and the application object. This is a disadvantage because it makes the code more complicated and increases the cost in time associated with development of an application. The following provides a background of prior art development environments and the need to generate such custom code.

Development Environment

0004A GUI is typically created using a development environment. An example of a technology that provides a development environment is OpenStep. OpenStep™ is an open, high-volume portable standard for object-oriented computing. It provides a standard application programming interface (API). The OpenStep specification is based on NeXTStep. NeXTStep™ is an object-oriented operating system of NeXT Software, Inc.

0005The NeXTStep environment runs in the Mach operating system (OS). The Mach OS is a microkernel-based operating systems. A microkernel-based OS provides a basic level of services with the bulk of the operating system services supplied by user-level services. For example, the Mach kernel provides process management, memory management, communication and Input/Output services. Services such as files and directories are handled by user-level processes.

0006Solaris™ is a UNIX operating environment that can run on multiple hardware platforms such as Intel x86, SPARC, and PowerPC processors. OpenWindows™ is a windowing system based on the X11 windowing specification that runs in Solaris. The X11/DPS is a windowing system that runs in OpenWindows. Solaris, OpenWindows, and X11/DPS are products that are available from Sun Microsystems, Inc. (Sun Microsystems, Inc., OpenWindows, X11/DPS, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and certain other countries.) An implementation of OpenStep runs in the Solaris operating environment.

Development Tools

0007A development environment such as that provided by OpenStep includes tools that can be used to develop a software application. Examples of such tools are: InterfaceBuilder (IB) and ProjectBuilder (PB).

0008The PB is a tool that can be used to logically group, connect, and manage the files and components of an application. A project file contains all of the information about the end product (e.g., a software application). A project can be a stand-alone application, a subproject that is contained within another project, a bundle that contains resources that can be used by other applications, for example.

0009The IB is a tool that can be used to build a GUI for an application. It assists in the design and definition of the presentation layer of an application. The IB provides a GUI that allows a developer to drag objects such as text fields, radio buttons, and custom views to the application window. The IB saves an application's objects in a file referred to as a pickled object file (e.g., a nib file).

0010The IB also allows the developer to make connections between the application's interface and other application objects. A connection can be used to send a message between an interface object and another object, for example. A connection is typically made by defining an outlet. An outlet is an instance variable in an Objective-C class that can store a pointer to another object (e.g., type "id"). The value of the instance variable is typically set to the "id" of an object in the nib file such as a GUI object. When an outlet is set to the "id" of an object, this is known as a connection.

Object Interface

0011An interface defines how an object can communicate, or interact, with another object. An interface defines an object's type, attributes, the methods it exports, and the method parameters. An object that understands another object's interface can generate a request for the other object to perform an operation.

0012Binding refers to the linking of the software interface to the code that implements the interface. Dynamic binding only requires that the interface be determined at the time a message is sent between the objects. In contrast, if the binding is static, the interface for the client and server is determined at compile or build time.

0013Typing refers to the identification of an object's type, or class. Static typing requires that an object's type be known at compile time. In contrast, it is not necessary to know the type, or class, of an object at compile-time if dynamic typing is used. Instead, an object's type may be determined at run time.

0014Both C++ and Objective-C support dynamic, or run time, binding. However, C++ does not support dynamic typing. A C++ object's type must be declared at compile time. In contrast, an Objective-C object's type does not need to be available at compile time. Objective-C object typing can be dynamic (i.e., determined at run time).

Distributed Environment

0015Software applications can take advantage of a distributed computing capability referred to as distributed objects. Using distributed objects, a first object (a client object) can send a message to a second object (a server object) regardless of the physical location of either object. That is, the client and server objects can reside on different machines.

0016The distributed object technology uses a name server and a local proxy to allow a client object to communicate with a server object. A name server is used to register the server object. A client accesses the name server to look up the name of the server object. Using the name information, the client object directs a message to the server object.

0017Instead of going directly from the client to the server, the message is actually received by a proxy object that resides on the same machine as the client object. The proxy object forwards the message to the server object on the server object's machine. A response generated by the server object is forwarded to the client object via the proxy object. The client object need not know the location of the server object. As far as the client object is concerned, the proxy object is the server object. However, the proxy object is only a vehicle for forwarding the message to the server object via the network. The details of the network communication is therefore hidden from the client object.

0018NEO provides a development environment and run time system for developing and deploying distributed objects on a CORBA infrastructure having an OpenStep GUI. The NEO product is intended for developing and delivering distributed object applications based on a CORBA-compliant infrastructure.

0019A CORBA object has an associated definition that is used to specify the object's interface. The definition is parsed at run time and stored in a repository. A server provides access to the repository at run time to determine a CORBA object's interface.

0020A CORBA object such as an object created using the NEO framework, a NEO object, is therefore dependent on a connection with the server. The connection to the server is not made while a developer is using the IB, but rather when a nib file is actually loaded at run time.

0021The applications developed using the NEO product use an OpenStep object-oriented GUI tool kit. The GUI tool kit contains Objective-C object classes. The IB provides the ability to connect an instance of a GUI tool kit Objective-C object class to another Objective-C object instance. For example, a GUI text field object that allows text entry such as an employee name is connected to an employee name Objective-C object that performs operations on the employee name.

Custom Code Generation

0022A developer typically uses an IB to create an object and establish a connection between the GUI object (e.g., text field object) and an application object (e.g., employee name Objective-C object). For example, a connection is formed by specifying an outlet of one object to point to another object. If the application object is an Objective-C object, it is not necessary to specify the outlet's type statically (i.e., at build time). The type can be determined dynamically at run time. If, however, the application object is a C++ object, the outlet must have a static type that matches the run time type of the C++ application object. To match, the static type of the C++ application object can be the same type as, or a subclass of, the outlet's type.

0023If the application object is a CORBA object, it is necessary to generate customized code that obtains the CORBA object from a name server and to form the connection between the GUI object and the CORBA object. The code generation is either performed by the application software developer or a development tool such as an IB. Customized code generation must be performed for each application which requires additional development time and expense. In addition, the use of customized code adds to the complexity of the application's code.

SUMMARY OF THE INVENTION

0024A connection is dynamically created between a graphic user interface (GUI) and a statically typed, distributed object using the present invention. The connection is created without requiring a developer to write customized code or using a program development tool to generate customized code. Using the present invention, the connection is established dynamically at run time using declarative information specified at build time.

0025A template object is generated at build time that contains type and name information for a surrogate object. The surrogate object acts as a proxy for a distributed object (e.g., CORBA distributed object). At run time, the template object is used to identify the surrogate object. The surrogate object is connected to the GUI object at run time. The surrogate can be a statically-typed object. Thus, the present invention can be used to form a dynamic connection between a GUI object and a statically-typed object. The GUI object is connected to the distributed object via the surrogate object.

0026The name information stored in the template object at build time is used to query a name server for an untyped surrogate object of a distributed object. The untyped surrogate object is transformed into a typed surrogate object at run time using the type information of the template object. A connection is formed between the typed surrogate object and the GUI object.

0027The present invention will now be further described, by way of example, with reference to the accompanying drawings, in which:-

0028Figure 1 provides an example of a general purpose computer to be used in accordance with embodiments of the present invention.

0029Figure 2 illustrates the creation of a dynamic connection to a static object according to an embodiment of the present invention.

0030Figure 3 provides a diagram of a connection between a GUI object and a CORBA distributed object.

0031Figures 4A-4B provides a process flow for template and surrogate object creation according to an embodiment of the present invention.

0032Figure 5 provides an example of the process flow illustrated in Figures 4A-4B.

DETAILED DESCRIPTION OF THE INVENTION

0033A method and apparatus for interactively connecting distributed objects to a graphic user interface is described. In the following description, numerous specific details are set forth in order to provide a more thorough description of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to obscure the invention.

0034The present invention can be implemented on a general purpose computer such as illustrated in Figure 1. A keyboard 110 and mouse 111 are coupled to a bi-directional system bus 118. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to CPU 113. The computer system of Figure 1 also includes a video memory 114, main memory 115 and mass storage 112, all coupled to bi-directional system bus 118 along with keyboard 110, mouse 111 and CPU 113. The mass storage 112 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology. Bus 118 may contain, for example, 32 address lines for addressing video memory 114 or main memory 115. The system bus 118 also includes, for example, a 32-bit DATA bus for transferring DATA between and among the components, such as CPU 113, main memory 115, video memory 114 and mass storage 112. Alternatively, multiplex DATA/address lines may be used instead of separate DATA and address lines.

0035In the preferred embodiment of this invention, the CPU 113 is a 32-bit microprocessor manufactured by Motorola, such as the 680X0 processor, a 80X86 microprocessor manufactured by Intel, or a SPARC microprocessor. However, any other suitable microprocessor or microcomputer may be utilized. Main memory 115 is comprised of dynamic random access memory (DRAM). Video memory 114 is a dual-ported video random access memory. One port of the video memory 114 is coupled to video amplifier 116. The video amplifier 116 is used to drive the cathode ray tube (CRT) raster monitor 117. Video amplifier 116 is well known in the art and may be implemented by any suitable means. This circuitry converts pixel DATA stored in video memory 114 to a raster signal suitable for use by monitor 117. Monitor 117 is a type of monitor suitable for displaying graphic images.

0036The computer system described above is for purposes of example only. The present invention may be implemented in any type of computer system or programming or processing environment. When a general purpose computer system such as the one described executes the processes and process flows described herein, it is configured to interactively connect distributed objects to a GUI.

0037The present invention can dynamically create the connection between an Objective-C object and a C++ statically-typed object, for example. Figure 2 illustrates the creation of a dynamic connection to a static object according to an embodiment of the present invention. The Objective-C object is GUI object 200. GUI object 200 is a dynamically typed object. In the preferred embodiment, adapter object 204 is used as an intermediate object between an Objective-C object and another object such as a C++ object. Adapter object 204 performs functions such as data translation, for example. Adapter object 204 is preferably a dynamic object. However, it should be apparent that the present invention-can be used without adapter object 204. As an alternative, GUI object 200 can perform the functions performed by adapter object 204, for example.

0038At development (or build) time, connection 206 is established between adapter object 204 and template object 210. Connection 206 is specified using an IB, for example. Connection 208 is established at run time. Connection 208 connects adapter object 204 to surrogate object 212. Surrogate object 212 is a statically typed C++ object. Surrogate object 212 can be used as a local proxy for a distributed object such as a CORBA object, for example.

0039Information is stored in the nib file created by the IB at development time that is used to dynamically create surrogate object 212 and dynamically establish connection 208. The nib file contains a definition for template object 210. The definition includes: 1) a service name for surrogate object 212, and 2) the type of the surrogate object 212.

0040When the nib file is loaded at run time, the definition of template object 210 is encountered. Template object 210 is used to determine a CORBA reference for the distributed object associated with surrogate object 212. The type information is used to identify a type narrowing function referred to as a narrowing function, for surrogate object 212. The narrowing function transforms the surrogate object 212 into an object that is a sub-type, or subclass, of a CORBA supertype. Connection 208 is established between adapter object 204 and surrogate object 212. Connection 208 is formed by setting an outlet instance variable of adapter object 204 to point to surrogate object 212, for example.

0041GUI object 200 and surrogate object 212 are connected via adapter object 204 and connection 208. GUI object 200 is connected to adapter object 204 via connection 202. Connection 202 is formed by assigning a value to an outlet of GUI object 200, for example. GUI object 200 can send a message to adapter object 204 via connection 202. Connection 208 is used to forward the message generated by GUI object 200 to surrogate object 212. If surrogate object 212 is acting as a proxy for another object (i.e., a CORBA object), surrogate object 212 can forward the message to the other object.

0042Using the present invention, it is unnecessary for a developer to generate customized code to create surrogate object 212 and connection 208 at run time. That is, it is unnecessary for a developer or an IB to generate code to determine the CORBA reference for surrogate object 212, initiate the creation of surrogate object 212, and establish connection 208 between adapter object 204 and surrogate object 212. Thus, the present invention can be used to automatically create a connection between a dynamically-typed GUI object and a statically-typed, C++ object at run time. Further, the present invention can be used to automatically create an interactive connection between a GUI object and a CORBA object, if the statically-typed, C++ object is a surrogate, or proxy, for the CORBA object.

0043Figure 3 provides a diagram of a connection between a GUI object and a CORBA distributed object. GUI object 300 is connected to adapter object 306 via connection 304. Connection 304 can be formed by setting outlet instance variable 302 of GUI object 300 to point to adapter object 306, for example. GUI object 300 and adapter object 306 can be Objective-C, dynamically-type objects. Connection 304 is preferably set using the IB. GUI object 300 can be connected to CORBA object 320 at run time.

0044In the preferred embodiment, the connection between GUI object 300 and CORBA object 320 is established via adapter object 306, surrogate object 312 and CORBA server 316 at run time. At run time, surrogate object 312 is created and connection 310 is established between adapter object 306 and surrogate object 312.

0045Surrogate object 312 is created at run time based on a definition in an application's nib file of template object 210, for example. Preferably, a development tool such as the IB is used to define template object 210 at build time. In one example, a <i>Make Template Object</i> menu command of the IB can be selected. The <i>Make Template Object</i> command is used to indicate that an instance of template object 210 is to be included in the application's nib file definition. A result of a <i>Make Template Object</i> selection is the inclusion of a definition for template object 210 in the application's nib file. The GUI of the IB can be used to establish a connection between GUI object 200 and surrogate object 212. This connection is specified by graphically connecting icons that represent adapter object 204 and template object 210. The IB is also used to specify the service name for, and type (or class) of, surrogate object 212.

0046The information specified using the IB is stored in a nib file of the application being developed. Specifically, the nib file contains a declaration for template object 210 along with declarations for adapter object 204 and GUI object 200. The declaration for template object 210 includes declarations for the name and type values of surrogate object 212.

0047When the software application is invoked or run, the application is loaded into memory for execution. The application's run time environment is initialized. The application's nib file is examined and entries in the nib file are used to create instances of objects. When the declaration for template object 210 is encountered, an instance of the object class for template object 210 is created. A creation method of the template object class is used to create template object 210. In the preferred embodiment, the creation method is also used to initiate the creation of surrogate object 212. Figures 4A-4B provides a process flow for template and surrogate object creation according to an embodiment of the present invention.

0048At step 402, the nib file is loaded. At step 404, an instance of the template object class is created. At step 406, the template object's creation method is invoked. At step 408, the type value contained in the nib file is used to generate the name of an narrowing function. The narrowing function is used to narrow a supertype obtained from the CORBA server to the surrogate object's type. At step 410, a symbol lookup is performed in a dynamic link library for the surrogate's stub code to obtain a pointer to the narrowing function. At step 412, the name server is queried to obtain an untyped CORBA object reference using the service name information (e.g., a string) stored in the template object.

0049The untyped CORBA object reference can be a reference to an untyped surrogate object. The untyped surrogate object is created when the look up operation is performed at step 412. The untyped object reference actually has the root type of the object class hierarchy. The root class is referred to as the base supertype. At step 414, the narrowing function and untyped, or supertyped, object reference are used to narrow the object reference to the surrogate object. That is, for example, the supertype is narrowed to the type specified in the type information of the template declaration using the narrowing function. At step 416, an outlet of the adapter object (e.g., adapter object 306) is set to point to the surrogate object (e.g., surrogate object 312).

0050An error may occur during the processing of the nib file template object entry. At step 412, for example, an object reference may not be found in the name server. Such a failure can be reported using an alert panel or by printing a message. If no errors occur, outlet 308 of adapter object 306 is pointing to a valid surrogate object (e.g., surrogate object 312) after the initialization process is finished. If an error occurred, outlet 308 is preferably a null pointer. The application can determine whether to proceed or terminate.

0051Figure 5 provides an example of the flow illustrated in Figures 4A-4B. Template object 500 includes a type information 502A and a name information 502B. Type information 502A becomes the input for name mangling routine 504. Name mangling routine 504 is, for example, the name mangling routine provided in a C++ ABI. Name mangling routine 504 constructs a narrowing function name from type information 502A. The narrowing function name is used as input to dynamic link library symbol lookup, or dlsym, function 508. Dlsym function 508 performs a symbol lookup in stub library 510 to obtain a pointer, or function symbol, to the narrowing function having the narrowing function name.

0052Name information 502B is used by the run time library to invoke a find operation 514 (i.e., <i>ODF::Service::find())</i> on name server 516. Name server 516 obtains an untyped CORBA object reference to the surrogate object (i.e., <i>CORBA::ObjectRef)</i> associated with the service specified by the name information 502B. Narrowing function 520 is invoked using the function symbol, or pointer, obtained using dlsym function 508. The surrogate object containing the untyped CORBA object obtained from name server 516 is an argument of narrowing function 520. Narrowing function 520 transforms the surrogate object to a C++ subtype. An outlet of source object 522 (e.g., adapter object 306) is set to point to the surrogate object (e.g., surrogate object 312).

0053The present invention's functionality can be reused across applications. Software application developers can incorporate the invention's functionality in multiple applications without generating a separate instance of code for each application.

0054Thus, a method and apparatus for the interactively connecting distributed objects to a graphic user interface has been described in conjunction with one or more specific embodiments. The invention is defined by the claims and their full scope of equivalents.