Generation of delegating implementation for IDL interfaces...

Details Generation of delegating implementation for IDL interfaces... Generation of delegating implementation for IDL interfaces...

2001-05-18

2004-09-07

Kincaid, Kristine (Department: 2174)

Computer graphics processing and selective visual display system

Display driving control circuitry

Controlling the condition of display elements

C345S215000, C345S215000, C345S215000, C345S215000, C717S116000, C717S108000, C717S110000, C709S241000, C709S241000

Reexamination Certificate

active

06788317

ABSTRACT:

BACKGROUND OF INVENTION
Applications developed using distributed objects such as Common Object Request Broker Architecture (CORBA) naturally lend themselves to multi-tiered architecture, fostering a neat separation of functionality. A three-tiered application has a user interface code tier, a computation code (or business logic) tier, and a database access tier. All interactions between the tiers occur via the interfaces that all CORBA objects publish.
FIG. 1
illustrates the transition from monolithic applications to multi-tiered, modular applications. A first generation system (
2
) has a graphical user interface (GUI) (
8
), a business logic (
10
), and a data store (
12
) all combined into one monolithic application. A next generation system (
4
) has the GUI (
8
) and the business logic (
10
) as one application with an interface to the data store (
12
). A latest generation system (
6
) has three distinct tiers. A first tier or user interface (UI) tier (
20
) includes one or more GUI (
8
), which interface with one or more service logic (
13
) in a second tier or service tier (
22
). The service logic (
13
) in the service tier (
22
) interfaces with other service logic (
13
), one or more GUI (
8
), and one or more data sources (
14
). A third tier or data store tier (
24
) includes one or more data sources (
14
), which interface with one or more service logic (
13
).
The UI tier is the layer of user interaction. The focus is on efficient user interface design and accessibility. The UI tier can reside on a user desktop, on an Intranet, or on the Internet. Multiple implementations of the UI tier may be deployed accessing the same server. The UI tier usually invokes methods on the service tier and, therefore, acts as a client. The service tier is server-based code with which client code interacts. The service tier is made up of business objects (CORBA objects that perform logical business functions, such as inventory control, budget, sales order, and billing). These objects usually invoke methods on the data store tier objects. The data store tier is made up of objects that encapsulate database routines and interact directly with the database management system product or products.
CORBA is the standard distributed object architecture developed by an Object Management Group (OMG) consortium. The mission of the OMG is to create a specification of architecture for an open software bus, or Object Request Broker (ORB), on which object components written by different vendors can interoperate across networks and operation systems.
The ORB is middleware that establishes the client-server relationships between objects by interacting and making requests to differing objects. The ORB sits between distributed (CORBA) objects in the second tier of the three tier architecture and operates as a class library enabling low-level communication between parts (objects) of CORBA applications. Programmers usually write applications logic in CORBA and the application logic is then connected to the data store by using some other application, e.g., ODBC, JDBC, proprietary, etc. Usually only objects in the application logic communicate using the ORB. Using the ORB, a client transparently invokes a method on a server object, which can be on the same machine or across a network. The ORB intercepts a call and is responsible for finding an object that can implement a request, pass the object a plurality of parameters, invoke the method, and return the results. The client does not have to be aware where the object is located, the programming language of the object, the operating system of the object, or any other system aspects that are not part of the interface of the object. In other words, the application logic can be run on many hosts in many operating systems and parts of the application logic can be written in different computer languages.
The diagram, shown in
FIG. 2
, shows a method request (
30
) sent from a client (
32
) to an instance of a CORBA object implementation, e.g., servant (
36
) (the actual code and data that implements the CORBA object) in a server (
34
). The client (
32
) is any code that invokes a method on the CORBA object. The client (
32
) of the CORBA object has an object reference (
38
) for the object and the client (
32
) uses this object reference (
38
) to issue method request (
30
). If the server object (
36
) is remote, the object reference (
38
) points to a stub function (
40
), which uses the ORB machinery (
42
) to forward invocations to the server object (
36
). The stub function (
40
) encapsulates the actual object reference (
38
), providing what seems like a direct interface to the remote object in the local environment. The stub function (
40
) uses the ORB (
42
) to identify the machine that runs the server object and, in turn, asks for that machine's ORB (
44
) for a connection to the object's server (
34
). When the stub function (
40
) has the connection, the stub function (
40
) sends the object reference (
38
) and parameters to the skeleton code (
46
) linked to an implementation of a destination object. The skeleton code (
46
) transforms the object reference (
38
) and parameters into the required implementation-specific format and calls the object. Any results or exceptions are returned along the same path.
The client (
32
) has no knowledge of the location of the CORBA object, implementation details of the CORBA object, or which ORB (
44
) is used to access the CORBA object. A client ORB (
42
) and a server ORB (
44
) communicate via the OMG-specified Internet InterORB Protocol (IIOP) (
48
). The client (
32
) may only invoke methods that are specified in the interface of the CORBA object. The interface of the CORBA object is defined using the OMG Interface Definition Language (IDL). CORBA objects can be written in any programming language for which there is mapping from IDL to that language (e.g., Java™, C++, C, Smalltalk, COBOL, and ADA). The IDL defines an object type and specifies a set of named methods and parameters, as well as the exception types that these methods may return. An IDL compiler translates the CORBA object's interface into a specific programming language according to an appropriate OMG language mapping.
Referring to
FIG. 2
, the stub files (
40
) and skeleton files (
46
) are generated by an IDL compiler for each object type. Stub files (
40
) present the client (
32
) with access to IDL-defined methods in the client programming language. The server skeleton files (
46
) figuratively glue the object implementation to the ORB (
44
) runtime. The ORB (
44
) uses the skeletons (
46
) to dispatch methods to the servants (
36
).
All CORBA objects support an IDL interface. The IDL interface defines an object type and can inherit from one or more other interfaces. The IDL syntax is very similar to that of Java™ or C++. The IDL is mapped into each programming language to provide access to object interfaces from that particular language. Using an IDL compiler of a CORBA implementation for Java™, the IDL interfaces are translated to Java™ constructs according to IDL to Java™ language mapping. For each IDL interface, IDL compiler generates a Java™ interface, classes, and other “.java” files needed, including the stub files and the skeleton files.
As a general guide, creating a CORBA-based distributed application has five steps as shown in FIG.
3
. The first step is to define a remote interface (Step
50
). The interface is defined using the IDL. Also, by using the IDL, the possibility exists to implement clients and servers in any other CORBA-compliant language. If the client is being implemented for an existing CORBA service, or the server for an existing client, the IDL interfaces come from the implementer, e.g., a service provider or vendor. The IDL compiler is then run over those interfaces.
Referring to
FIG. 3
, the second step is to compile the remote interface (Step
52
). When the IDL compiler is run over the interface definition file, the Java™ version of the interface is generated alo

Affiliated with

Also associated with

Rating

Generation of delegating implementation for IDL interfaces... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Generation of delegating implementation for IDL interfaces..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generation of delegating implementation for IDL interfaces... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3239489