Service framework for a distributed object network system

Details Service framework for a distributed object network system Service framework for a distributed object network system

1997-11-13

2001-03-27

Coulter, Kenneth R. (Department: 2154)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

Reexamination Certificate

active

06209018

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to programmed computers and, more particularly, to an improved method and apparatus for providing a service framework for a distributed object network system.
BACKGROUND
Computer systems that provide users access to limited resources are well known. For example, a client-server system represents a common paradigm for providing shared access to a limited resource such as a computer database on a server. The typical client-server system includes a computer (the “server”) in which one or more limited resources reside (e.g., are stored) and one or more satellite computers (the “clients”) which access the limited resources. The access is generally performed over an electronic communication system. The clients access the limited resources on an as needed basis.
A server typically includes a computer or multiple computers connected via an electronic communication system, services (e.g., a data service that provides access to a database residing in a computer or a distributed service residing in multiple computers connected via an electronic communication system), and a storage for storing the services. The storage typically includes some combination of random access memory (“RAM”) and magnetic media, such as tapes and disks or optical media, and other storage devices. Depending on the requirements of the system, the server may be a personal desktop computer that includes a hard-disk, a large mainframe computer that includes multiple tape drives, or some other kind of computer.
A client may be a personal computer, a workstation, or some other kind of computer. A client may be either remote from the server (i.e., the client accesses the server via an electronic communication system) or local to the server (e.g., the client accesses the server via a local bus). A client may include one or more “applications” such as a word processor, a web browser, or database interface software to access information from a database on a server. Some of the applications may be under the control of a human operator and others may run automatically or under the control of another application.
An electronic communication system (“network”) may include commercial telephone lines as well as dedicated communication lines to carry data signals between the server and the client.
Prior client-server approaches allow a limited number of clients to access limited resources residing in a server. In particular, in the typical client-server environment, the workload characteristics are predictable and well known because of the predetermined limit on the number of clients and the well known nature of the clients.
However, increasing Internet usage presents a unique problem for providing a dramatically increasing and unpredictable number of clients efficient and fair allocation of access to limited resources residing in a server. Accordingly, prior client-server approaches are inadequate for the Internet environment, because the number of concurrent users in the Internet environment generally exceeds the number of concurrent users in a typical client-server environment and is generally more unpredictable.
A Common Object Request Broker Architecture (CORBA) represents a partial attempt to address the problem of providing an increasing and unpredictable number of users access to limited resources residing in a server. CORBA provides a client/server middleware defined by an industry consortium called the Object Management Group (OMG), which includes over 700 companies representing the entire spectrum of the computer industry.
In particular, CORBA defines an implementation-independent component-based middleware. CORBA allows intelligent components to discover each other and interoperate on an object bus called an Object Request Bus (ORB). CORBA objects can reside anywhere on a network. Remote clients can access a CORBA object via method invocations. Clients do not need to know where a CORBA object resides or on which operating system the CORBA object is executed. Thus, a client can access a CORBA object that resides in the same process or on a machine in another country connected via the Internet.
Further, both the language and compiler used to create CORBA objects are transparent to clients. For example, a CORBA object may be implemented as a set of C++ classes, in JAVA bytecode, or in COBOL code. Thus, the implementation of the CORBA object is irrelevant to the client. The client only needs to know the interface of the CORBA object. CORBA uses an Interface Definition Language (IDL) to define a CORBA object's interface, and the IDL also allows for specifying a component's attributes such as the parent classes it inherits from and the methods its interface supports. For example, a CORBA object provides an implementation for the CORBA object's IDL interface using a language for which an IDL mapping exists. In particular, CORBA defines a standard mapping from the IDL to other implementation languages such as C++, JAVA, ADA, etc.
A CORBA IDL compiler generates client-side stubs and server-side skeletons for the CORBA object's IDL interface.
CORBA also specifies bus-related services for creating and deleting objects, accessing them by name, storing them in persistent stores, externalizing their states, and defining ad hoc relationships between them. Accordingly, CORBA provides a flexible distributed-object middleware that provides client-server interoperability. CORBA and JAVA are both further described in “Client/Server Programming with JAVA™ and CORBA” by Robert Orfali and Dan Harkey (John Wiley & Sons: New York, N.Y., 1997).
FIG. 1
shows a typical CORBA environment
38
. A client
40
connects to a server
54
via a network
44
(e.g., via the Internet). A client
42
connects to the server
54
via a network
46
(e.g., via the Internet). A client
50
connects to the server
54
via a network
48
(e.g., via the Internet). CORBA provides local/remote transparency in a distributed object network as shown in
FIG. 1
by providing Internet Inter-ORB Protocol (IIOP) services
52
. An ORB service represents a standard CORBA service that can broker inter-object calls within a single process, multiple processes running within the same machine, or multiple processes running within different machines that may be across multiple networks and operating systems. For example, the client
42
includes an application that uses client-side stubs to obtain an object reference (e.g., a handle) to a remote CORBA object and to dispatch method invocations to the remote CORBA object. The communication between the client and the server-side object uses the IIOP.
Referring to
FIG. 1
, the server
54
includes a relational database management systems (RDBMS)
60
(e.g., residing in a storage of the server
54
). The server
54
also includes a data service
56
, which can be implemented as a collection of CORBA objects, that encapsulates the limited resource, the RDBMS
60
. For example, the data service
56
may provide a set of operations that can execute SQL queries, stored procedures, and perform connection management.
Referring to
FIG. 1
, the data service
56
can be used by standard applications (e.g., a database interface) that reside in the clients
40
,
42
, and
50
. The clients
40
,
42
, and
50
obtain a handle (e.g., an object reference) to bind to the data service
56
. In particular, CORBA's object location mechanism includes the CORBA client stubs which offer a bind mechanism to locate a remote object and obtain an object reference for the remote object. Accordingly, the server
54
provides various services such as the data service
56
. The server
54
also includes standard CORBA support services in a CORBA layer
58
for activating the data service
56
and administering the data service
56
.
However, the standard CORBA support services do not provide significant client-side encapsulation for requesting a service, efficient workload balancing, a substantial variety of access modes, or robust fault tolerance. Accordingly, an impr

Affiliated with

Also associated with

Rating

Service framework for a distributed object network system does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Service framework for a distributed object network system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Service framework for a distributed object network system will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2516687