Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing – Network resources access controlling
Reexamination Certificate
1997-03-12
2002-12-17
Rinehart, Mark H. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
Network resources access controlling
C709S241000, C709S203000, C709S225000, C717S139000, C717S163000, C717S165000, C717S166000
Reexamination Certificate
active
06496865
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to accessing network server resources and, more particularly, to a system and method for providing interpreter applications access to server resources in a distributed network.
2. Related Art
Internetworking is the process of establishing and maintaining communications and transferring data among multiple nodes in a distributed network system. The nodes are connected by a common communication medium such as copper or fiber optic cabling and may have a series of intermediate active nodes, such as routers or bridges. The nodes communicate with each other using a common information exchange protocol, such as IPX or TCP/IP.
The purpose of an internetwork is to provide end-to-end service between a client node and a server node to share resources such as information stored in files, databases, etc.; print, facsimile, CD-ROM and other services; and other resources located locally and remotely relative to the server. The client and server nodes are generally computers such as workstations and PCs.
The client node typically includes application programs that request access to resources located on the server node. The server node, which may be, for example, a NetWare® server available from Novell, Incorporated or a Windows NT® server available from Microsoft Corporation, is typically a computer dedicated to providing access to the above resources in response to requests generated by the client nodes. (NetWare is a registered trademark of Novell, Inc., and Windows NT is a registered trademark of Microsoft Corp.)
When the client application makes a request, the request is intercepted by a redirector in the client node and passed either to the local operating system or to network client libraries and a network client process for transmission to the server node. The network client libraries translate the request parameters from the library environment to a format appropriate for the network client process. The network client process places the request parameters into a network packet and invokes a network driver on the client node. The network driver packages the request and forwards it onto the network using an appropriate packet format and media-access method. The request is received by a corresponding network driver on the server node that provides the request to a request handler in the server. The request handler, which is typically part of the server operating system, performs the necessary operations to process the request. The resulting reply is returned to the client node in a similar manner.
It is well known that different versions of an application program are generally required to enable it to operate with different types of operating systems. For example, WordPerfect® for Windows 95™ will not function on the Windows™ 3.1 operating system. (WordPerfect is a registered trademark of Corel, Inc., Windows 95 is a trademark and Windows is a registered trademark of Microsoft Corp.) To enable a single version of an application to execute on different types of operating systems, programs providing a standard application program interface (API) have been recently developed. These programs, referred to as interpreter programs or simply interpreters, operate at a functional level above the client or server operating system. The interpreter program, referred to hereinafter as an interpreter system, executes application programs written in the language of the interpreter system. These applications are referred to hereinafter as interpreter applications. The interpreter system isolates the interpreter applications from the particular requirements of each type of operating system.
An interpreter system generally includes an interpreter engine and interpreter libraries. The interpreter engine translates interpreter applications to system-level instructions appropriate for the host (client or server) operating system. Unlike a compiler which converts programs written in a higher level language (source code) to system-level instructions (object code) for subsequent execution by the processor, the interpreter engine executes source code by translating interpreter commands directly into processor instructions and executing these instructions on the processor. The interpreter libraries define the API that performs functions such as input/output, networking and utility functions utilized by the interpreter applications to access client and server resources. Examples of interpreter systems include the Java Virtual Machine™ (Java™) and the associated Java Development Kit (JDK) available from Sun Microsystems, ActiveX™ available from Microsoft Corporation, and the widely available Smalitalk interpreter, which executes instructions written in the Smalltalk programming language. (Java Virtual Machine and Java are trademarks of Sun Microsystems, Inc. and ActiveX is a trademark of Microsoft Corp.)
Generally, the interpreter libraries are implemented in an object-oriented programming language and are generally referred to as object or class libraries. The interpreter libraries include a number of service libraries. Two of these service libraries which are of particular importance to the present invention are the commonly known network service libraries and the input/output (I/O) service libraries. The I/O service libraries provide the interpreter application with the ability to access local resources on the client node. For example, the I/O service libraries include objects for reading and writing to a file. The technique which is used by these objects is based upon the concept of a stream. A stream is a sequence of data, such as strings or arrays of bytes or other objects, transferred over a period of time from/to a desired resource. In particular, these I/O libraries include a generic “stream” object class whose methods could be extended to operate on a structure such as a file. For example, when an interpreter application accesses a local file on a client node, stream objects enable the interpreter application to perform file operations such as reading and writing a stream of data to/from the local file. In Java, generic stream objects are extended by file stream objects which use the same programming interface. Other stream objects are used by an interpreter application to operate on a local file.
Network service libraries provide the interpreter application with the ability to access server resources using an application-level communications protocol. Also, interpreters such as Java often include what is commonly referred to as distributed objects, which allow an interpreter system of a first node to transfer a request directly to an interpreter system on a second node for processing. When implementing distributed objects, the interpreter system transfers a request from the interpreter application to distributed objects on the first node which then transfers the request to distributed objects on the second node. The distributed objects on the server node execute the request as if the request was generated locally and returns a reply to the requesting distributed objects on the client node. The requesting distributed objects provide the interpreter application with the reply as if it was generated locally. Different types of distributed object systems exist, such as CORBA, RMI, and DCOM.
Although interpreter systems provide a standardized API, the I/O service libraries do not include objects that support the file access methods necessary to access a particular class of server nodes that require access to occur through an installable file system (IFS). As is well known, an installable file system is an interface found on client operating systems which allows network vendors to provide access to file systems which would normally be foreign to the client operating system. Servers that support communication with an IFS on a client node include, for example, NetWare, Windows NT and Network File System (NFS) servers.
A conventional approach for providing interpreter applications access to resources on servers is to i
Echols Grant G.
Sumsion John G.
Dinsmore & Shohl LLP
Novell Inc.
Rinehart Mark H.
Vaughn, Jr. William C.
LandOfFree
System and method for providing interpreter applications... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for providing interpreter applications..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for providing interpreter applications... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2961438