 |
Claims  |
|
|
What is claimed is:
1. A distributed system including a plurality of computer systems coupled
together through a common communication network, a first one of said
computer systems corresponding to a non distributed computing environment
(DCE) computer system which includes a first type of operating system for
running non DCE application programs on said first one of said computer
systems and a second one of said systems corresponding to a DCE system
including a second type of operating system which is compatible with said
DCE system for running application programs compiled on said second system
and wherein said distributed system further includes:
an ally component and a distributed computing environment (DCE) application
system installed in said second system to run in conjunction with said
second type of operating system, said DCE application system including a
plurality of basic distributed services and a remote procedure call (RPC)
component for processing remote procedure calls between client and server
application programs communicating through a pair of RPC stub components
according to a predetermined RPC protocol, said ally component including a
plurality of management routines for enabling local requests made by said
client application programs running on said first system to be processed
by accessing said plurality of distributed service components of said DCE
system; and,
an RPC runtime component included in said first computer system, said RPC
runtime component including a RPC subcomponent and an application program
interface (API) subcomponent operatively coupled to each other, said RPC
subcomponent including a minimum number of ported routines responsive to a
corresponding number of standard DCE RPC requests for determining when any
local client request is to be forwarded to said ally component of said
second computer system and said API subcomponent including a plurality of
subroutines for enabling transfer of said each local client request
received from said RPC subcomponent of said RPC component of said first
computer system to said ally component of said second computer system
using said predetermined RPC protocol established by said client and
server RPC stubs for accessing a designated one of said distributed
service components of said DCE application system of said second computer
system thereby eliminating the need of having to port said DCE service
components to operate on said first computer system.
2. The system of claim 1 wherein said first type of operating system is a
proprietary operating system which does not include facilities to support
said DCE application system.
3. The system of claim 1 wherein said second operating system is a UNIX
based operating system which includes facilities to support said DCE
system.
4. The system of 1 wherein said DCE application system includes a number of
software layers, a first DCE layer including said plurality of components
for providing a plurality of basic distributed services and a second layer
including said RPC component of said DCE application system.
5. The system of claim 4 wherein said ally component is also included in
said second layer.
6. The system of claim 1 wherein RPC communications between said first and
second computer systems is established according to statements defining an
ally interface and wherein said second system further includes an
interface definition language (IDL) compiler, said IDL compiler being used
to compile said statements into said RPC stub components and said first
computer system including a compatible compiler for compiling said client
application programs, said compatible compiler compiling said RPC stubs
produced by said IDL compiler before being installed on said first
computer system.
7. The system of claim 1 wherein said plurality of components includes a
naming service component, a security service component, a time service
component and a threads service component.
8. The system of claim 1 wherein said API subcomponent of said first
computer system includes routines for performing operations for initially
establishing association with said ally component for having said ally
component carrying certain binding operations and naming service
operations.
9. The system of claim 1 wherein said ally component routines for
processing said client requests by generating standard DCE calls to said
RPC component of said DCE application system installed in said second
computer system.
10. The system of claim 9 wherein said ally component includes a routine
for performing initialization sequence of operations in response to a
first computer client request received from said first system.
11. A method of providing a distributed computing environment (DCE) in a
system which includes a plurality of computer systems for a first one of
said system which is a non-DCE computer system that does not have
operating system facilities for directly supporting DCE services for
application programs running in said non-DCE computer system and a second
one of said computer systems which is a DCE computer system that includes
a DCE application system for providing said DCE services, said DCE
application system containing a plurality of components for performing
said DCE services without having to port said DCE components to said first
computer system, said method comprising the steps of:
a. coupling said first and second computer systems together for enabling
said computer systems to process remote procedure (RPC) calls between
client and server application programs running on said first and second
computer systems respectively which communicate through a pair of RPC stub
components;
b. installing in said first computer system, an RPC runtime component which
includes an application program interface (API) component to operate in
conjunction with said operating system facilities of said first computer
system, said RPC runtime component including a number of routines
responsive to standard DCE requests for determining when any client
request for local services can not be performed by said first computer
system and said API component including a plurality of subroutines for
enabling transfer of said local client request to said second computer
system using a predetermined RPC protocol established by said client and
server RPC stubs;
c. installing in said second computer system, an ally component to run said
second computer system in conjunction with said DCE components said ally
component including a plurality of routines for communicating with said
RPC runtime component and for processing said client requests received
from said RPC runtime component of said first computer system for
performing requested DCE services using said DCE components of said second
computer system for those DCE components which were not ported to run on
said first computer system;
d. determining by a mapping operation performed by said number of routines
of said RPC runtime component of said first computer system which local
client request can not be performed locally by said RPC runtime component
because of not having ported said DCE components to said first computer
system; and,
e. translating and transferring by said API component of said RPC component
of said first computer system, each client request which can not be
performed locally as determined in step d into a form for receipt by said
ally component for execution either by said ally component or by said ally
component and said DCE components installed on said second computer
system.
12. The method of claim 11 wherein said method further includes the steps
of:
including in said DCE application system of said second computer system a
number of servers which couples to said DCE application system RPC
component; and,
(g) including in said ally component routines for executing client requests
by accessing corresponding ones of said servers through said RPC component
for performing DCE services for said client application programs running
on said first computer system.
13. A distributed system including a plurality of computer systems coupled
together through a common communication network, a first one of said
computer systems corresponding to a non distributed computing environment
(DCE) computer system which includes a first type of operating system for
running non DCE application programs on said first one of said computer
systems and a second one of said systems corresponding to a DCE system
including a second type of operating system which is compatible with said
DCE system for running application programs compiled on said second system
and wherein said distributed system further includes:
an ally component and a distributed computing environment (DCE) application
system installed in said second system to run in conjunction with said
second type of operating system, said DCE application system including a
plurality of basic distributed services and a remote procedure call (RPC)
component for processing remote procedure calls between client and server
application programs communicating through a pair of RPC stub components
according to a predetermined RPC protocol, said ally component including a
plurality of management routines for enabling local request made by said
client application programs running on said first system to be processed
by accessing said plurality of distributed service components of said DCE
system wherein said ally component includes a plurality of sections for
processing different types of requests received from said RPC runtime
component of said first computer system, said plurality of sections
including a requests section, a forwarding service section coupled to said
request section, a naming service section coupled to said requests section
and a security service section coupled to said requests section; and,
an RPC runtime component included in said first computer system, said RPC
runtime component including a RPC subcomponent and an application program
interface (API) subcomponent operatively coupled to each other, said RPC
subcomponent including a minimum number of ported routines responsive to a
corresponding number of standard DCE RPC requests for determining when any
local client request is to be forwarded to said requests section of said
ally component of said second computer system and said API subcomponent
including a plurality of subroutines for enabling transfer of said each
local client request received from said RPC subcomponent of said first
computer system to said requests section of said ally component of said
second computer system using said predetermined RPC protocol established
by said client and server RPC stubs for accessing designated ones of said
distributed service components of said DCE application system of said
second computer system through other sections of said plurality of
sections of said ally component thereby eliminating the need of having to
port said DCE service components to operate on said first computer system.
14. A distributed system including a plurality of computer systems coupled
together through a common communication network, a first one of said
computer systems corresponding to a non distributed computing environment
(DCE) computer system which includes a first type of operating system for
running non DCE application programs on said first one of said computer
systems and a second one of said systems corresponding to a DCE system
including a second type of operating system which is compatible with said
DCE system for running application programs compiled on said second system
and wherein said distributed system further includes:
an ally component and a distributed computing environment (DCE) application
system installed in said second system to run in conjunction with said
second type of operating system, said DCE application system including a
plurality of basic distributed services and a remote procedure call (RPC)
component for processing remote procedure calls between client and server
application programs communicating through a pair of RPC stub components
according to a predetermined RPC protocol, said ally component including a
plurality of management routines for enabling local request made by said
client application programs running on said first system to be processed
by accessing said plurality of distributed service components of said DCE
system; and,
an RPC runtime component included in said first computer system, said RPC
runtime component including a RPC subcomponent and an application program
interface (API) subcomponent operatively coupled to each other, said RPC
subcomponent including a minimum number of ported routines responsive to a
corresponding number of standard DCE RPC requests for determining when any
local client request is to be forwarded to said ally component of said
second computer system and said API subcomponent including a plurality of
subroutines for enabling transfer of said each local client request
received from said RPC subcomponent of said first computer system to said
ally component of said second computer system using said predetermined RPC
protocol established by said client and server RPC stubs for accessing a
designated one of said distributed service components of said DCE
application system of said second computer system thereby eliminating the
need of having to port said DCE service components to operate on said
first computer system, said RPC runtime component being constructed by
compiling statements which include #ifdef declarations designating those
portions of said RPC runtime component which form part of a common porting
kit from those portions of said RPC runtime component which are specific
to the architecture of said first system thereby facilitating said porting
of DCE services to different types of non DCE based computer systems. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Field of Use
This invention relates to data processing systems and more particularly to
systems which operate in a distributed computing environment.
2. Prior Art
In the 1980's, computer hardware vendors have responded to the need to
provide users with access to UNIX* based systems. Some vendors have
provided such access by interconnecting or integrating their proprietary
systems with UNIX based systems through the use of separate processor
boards and separate operating systems. An example of this type of system
is described in U.S. Pat. No. 5,027,271 entitled "Apparatus and Method for
Alterable Resource Partitioning Enforcement in a Data Processing System
having Central Processing Units using Different Operating Systems" which
issued on Jun. 25, 1991.
* UNIX is a registered trademark of X/Open Company Limited
Other approaches include hosting an UNIX environment or process running
under a proprietary system and providing external communication/networking
functions implemented on a UNIX based platform. These systems allow end
user UNIX based systems to use client software to request services from
proprietary systems. Examples of these systems are The OPEN7 and OPEN8
systems manufactured by Bull HN Information Systems Inc.
With the continued increases in the speed and power of computer hardware
and the development of high speed local area networks, it becomes even
more important to be able to combine large numbers of different vendor
systems and high speed networks. Such systems are called distributed
systems in contrast to centralized systems. The above mentioned OPEN7 and
OPEN8 systems are also examples of such distributed systems. Such systems
are more economical, provide greater total computing power and provide
greater reliability than centralized systems.
However, there are certain problems associated with such systems in terms
of the lack of distributed software, network communications and message
security. In 1990, the Open Software Foundation, Inc. (OSF), a consortium
of computer vendors, announced its choice of a set of integrated services
that would provide a comprehensive Distributed Computing Environment (DCE)
for the development, use and maintenance of distributed applications
without regard to the underlying complexity of the computing network. The
DCE architecture is described in the publications entitled, "OSF
Distributed Computing Environment Rationale" by Open Software Foundation,
Inc. dated May 14, 1990 and "Distributed Computing Environment, An
Overview" by Open Software Foundation dated January, 1992.
The DCE architecture envisions support from a platform like a UNIX based
platform which includes facilities utilized by such architecture. This
poses problems for those vendors which wish to offer such services on a
non-UNIX based platform. This problem is further compounded when a vendor
wishes to provide such DCE architecture on several different proprietary
platforms.
In general, the approach has been to port a substantial number of software
services from the proprietary system platform to the UNIX based system
platform or visa versa or the addition of special hardware facilities and
software for running the UNIX based operating system in another
environment. This has proved quite costly and has required the allocation
of substantial resources. Additionally, these system platforms have
required continuous support in order to provide timely upgrades and
enhancements.
Accordingly, it is a primary object of the present invention to provide a
technical solution which allows DCE services to provided in an incremental
way on a proprietary system platform.
It is a further object of the present invention to provide such incremental
services in a timely fashion on several different proprietary system
platforms.
SUMMARY OF THE INVENTION
The above objects and advantages are achieved in a preferred embodiment of
the distributed system of the present invention. The distributed system
includes a non-distributed computer environment (DCE) computer system and
at least one DCE computer system which are loosely coupled together
through a communications network operating with a standard communications
protocol. In the preferred embodiment, the non-DCE and DCE computer
systems operate under the control of a non-UNIX/proprietary and UNIX based
operating systems respectively. The non-DCE computer system further
includes application client software for providing access to the DCE
service components via a remote procedure call (RPC) mechanism obtained
through the ally software included on the DCE computer system.
According to the present invention, the distributed system further includes
three major components which are distributed between the non-DCE and DCE
systems. The components are a client side RPC runtime service component
which includes an ally application program interface (API) component and
an ally component. The arrangement allows non-DCE user distributed
applications through client and server software to access DCE service
components through the ally component using the RPC mechanism of the
non-DCE and DCE systems.
According to the present invention, only those DCE service components which
are absolutely necessary are ported to run on the non-DCE system. Other
non-ported services are imported from the Ally component through the
application program interface (API) component of the non-DCE computer
system.
In the present invention, a plurality of APIs are defined for the ally
component and are "exported" to the client RPC runtime service components.
These APIs are contained in the API component included in the client RPC
runtime on the non-DCE system and define the functions required to be
performed by the ally component in providing the client application access
to the DCE services through the RPC mechanisms of both the non-DCE and DCE
systems. According to the present invention, the client application
containing the IDL descriptions of the Ally interfaces/specifications are
translated into client stub source code by an IDL compiler resident on the
DCE system. To complete the building of the client application, a non-DCE
system compiler is then used to compile and link the client stub source
code with the client RPC runtime component routines on the non-DCE system.
The components of the non-DCE system implemented according to the present
invention are partitioned into two parts: a common porting kit and a
platform porting kit. The common port kit includes components common to
all non-DCE systems and just has to be ported once to the non-DCE
reference system. The platform porting kit includes the components which
are specific/unique to each non-DCE system and the kit modified when
moving from one non-DCE system to another. For example, the platform
porting kit includes the RPC runtime environment dependencies, network
data representation, import library and communication interface protocols.
The common porting kit includes the client RPC runtime common portion, the
ally and the API libraries.
Such partitioning allows all of the different nonDCE systems to be
implemented in parallel. Also, it reduces cost in upgrading since the
common porting kit need only be changed once for all systems. The use of
separate platform porting kits permits modifications to made to different
systems without affecting any of the other systems.
The novel features which are believed to be characteristic of the invention
both as to its organization and method of operation, together with further
objects and advantages will be better understood from the following
description when considered in connection with the accompanying drawings.
It is to be expressly understood, however, that each of the drawings are
given for the purpose of illustration and description only and are not
intended as a definition of the limits of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1a shows the major components of the distributed computing environment
(DCE) architecture included in the preferred embodiment of the present
invention.
FIGS. 1b through 1d show in greater detail, the DCE RPC component service
of FIG. 1a.
FIG. 1e shows a prior art distributed system configured to perform a DCE
RPC operation.
FIG. 2a shows in block diagram form, a distributed system which
incorporates the components of the present invention.
FIG. 2b shows in greater detail, the ally component of FIG. 2a.
FIGS. 3a through 3c are flow diagrams which diagrammatically illustrate
some of the operations performed by the systems of FIG. 2a.
FIGS. 4a through 4c are diagrams used to illustrate the operation of the
preferred embodiment of the present invention.
GENERAL DESCRIPTION OF DCE ARCHITECTURE
FIG. 1a illustrates the OSF DCE architecture used in the system of the
present invention. As shown, DCE includes a set of server components for
providing distributed services that support the development, use and
maintenance of distributed applications in a heterogeneous networked
environment. The server components include a remote procedure call (RPC)
service component including presentation service, a Naming (Directory)
service component, a Security service component, a Threads service
component, a Time service component and a Distributed file system service
component.
The RPC service component is an access mechanism which implements the model
of the simple procedure call within the client/server architecture for
allowing programs to call procedures located on other systems without such
message passing or I/O being at all visible to the programmer. The DCE RPC
service component enables distributed applications to be defined and built
in an object oriented way.
Remote procedures are viewed as operations on objects (e.g. printers,
files, computing units) rather than as calls to particular systems or
server processes. As discussed herein, it hides from the programmer
various network complexities such as the means for locating and accessing
host systems on which the required services are running. It also makes it
easier to produce programs that are less dependent on system
configurations such as host names and locations. The RPC service component
service design is based on the Apollo Network Computing System (NCS) which
provides a clearly specified RPC protocol that is independent of the
underlying transport layer and runs over either connectionless or
connection oriented lower layers.
The RPC service component consists of both a development tool and a runtime
system/service (RTS). The development tool consists of a language (and its
compiler) that supports the development of distributed applications
following the client/server model. It automatically generates code that
transforms procedure calls into network messages. The development tool is
discussed later herein with reference to FIG. 1d to the extent necessary
for an understanding of the present invention.
The RPC runtime service/system implements the network protocols by which
the client and server sides of an application communicate. Also, DCE RPC
includes software for generating unique identifiers which are useful in
identifying service interfaces and other resources.
The DCE Directory or Naming Service component is a central repository for
information about resources in the distributed system. Typical resources
are users, machines, and RPC-based services. The information consists of
the name of the resource and its associated attributes. Typical attributes
could include a user's home directory, or the location of an RPC-based
server. The DCE Directory Service comprises several parts: the Cell
Directory Service (CDS), the Global Directory Service (GDS), the Global
Directory Agent (GDA), and a directory service programming interface. The
Cell Directory Service (CDS) manages a database of information about the
resources in a group of machines called a DCE cell. The Global Directory
Service implements an international standard directory service and
provides a global namespace that connects the local DCE cells into one
worldwide hierarchy. The Global Directory Agent (GDA) acts as a go-between
for cell and global directory services. Both CDS and GDS are accessed
using a single directory service application programming interface (API)
and the X/Open Directory Service (XDS) API.
The DCE Security Service component provides secure communications and
controlled access to resources in the distributed system. There are three
aspects to DCE security: authentication, secure communication, and
authorization. These aspects are implemented by several services and
facilities that together comprise the DCE Security Service, including the
Registry Service, the Authentication Service, and Privilege Service, the
Access Control List (ACL) Facility, and the Login Facility. The identity
of a DCE user or service is verified, or authenticated, by the
Authentication Service. Communication is protected by the integration of
DCE RPC with the Security Service-communication over the network can be
checked for tampering or encrypted for privacy. Finally, access to
resources is controlled by comparing the credentials conferred to a user
by the Privilege Service with the rights to the resource, which are
specified in the resource's Access Control List. The Login Facility
initializes a user's security environment, and the Registry Service
manages the information (such as user accounts) in the DCE Security
database.
The DCE Threads Service component supports the creation, management, and
synchronization of multiple threads of control within a single process.
This component is conceptually a part of the operating system layer, the
layer below DCE. If the host operating system already supports threads,
DCE can use that software and DCE Threads is not necessary. However, not
all operating systems provide a threads facility, and DCE components
require that threads be present, so this user-level threads package is
included in DCE.
The Distributed File System Service component allows users to access and
share files stored on a File Server anywhere on the network, without
having to know the physical location of the file. Files are part of a
single, global namespace, so no matter where in the network a user is, the
file can be found using the same name. The Distributed File Service
achieves high performance, particularly through caching of file system
data, so that many users can access files that are located on a given File
Server without prohibitive amounts of network traffic and resulting
delays. DCE DFS includes a physical file system, the DCE Local File System
(LFS), which supports special features that are useful in a distributed
environment. They include the ability to replicate data; log file system
data, enabling quick recovery after a crash; simplify administration by
dividing the file system into easily managed units called filesets; and
associate ACLs with files and directories.
The DCE Time Service component provides synchronized time on the computers
participating in a Distributed Computing Environment. DTS synchronizes a
DCE host's time with Coordinated Universal Time (UTC), an international
time standard.
THE DCE RPC RUNTIME SYSTEM ARCHITECTURE
FIG. 1b shows in greater detail, the DCE RPC run time system (RTS). As
shown, the system is divided into three major components. These are the
Communication Services (CS), Naming services (NS), and Management services
(MS). The CS is responsible for carrying out the actual work being done
when a remote procedure is called. That is, it accesses the network and
provides the means for simultaneously executing different transport and
RPC protocols. As shown, the CS includes a network address family
extension services section, a common communication services section, a RPC
protocol machines section and a common network services section which
contains network independent functions such as read, write, open and
close.
The network address family extension services section provides functions
for manipulating addresses within separate modules for each network
service which present the same interface to the CCS. Whenever a network
specific operation such as returning the endpoint in a network address
needs to be performed, the CCS makes the corresponding function call
causing the activation of the specific module determined during
initialization time. The RPC protocol machines provides functions for
handling different protocols. The hiding of two supported RPC protocols,
connection oriented or connectionless (datagram) based is achieved in the
same way as described above. For each RPC protocol machine, an
initialization routine returns function pointer arrays which present a
common interface to the CCS. The CCS uses them to make data transfer
calls, collect statistics, access the relevant fields in the binding
representation structure and notify the RPC protocol machine of network
events.
The NS accesses the distributed system's naming service such as an X.500
directory to locate servers by specifying an interface or an object which
have to be exported by servers and imported by clients. The NS manages RPC
services either locally or remotely. Remote management functions are a
subset of local ones and are made available via the RPC mechanism.
FIG. 1c shows the CCS in greater detail. As shown, the CCS includes an
initialization service component, a thread service component, a call
service component, a network listener service component, a binding service
component, a security service component, an interface service component,
an object service component, a communications management service component
and a utility service component.
The initialization service component sets up the RPC environment and the
creation of prerequisites for communication services such as the
allocation of static tables. Also, transport and RPC protocols to be
supported are also established. A table is generated during initialization
that assigns an identifier (RPC protocol sequence id) to each combination
of network, transport and RPC protocols. These types of identifiers appear
later as attributes to structures that specify interfaces. Thus, an
interface representation data structure may exist several times for the
same interface but with different protocol sequence identifiers associated
with it. When the RTS library is build as a non-shared image, the
initialization routines are called when either the application or stub
first calls the CS.
The thread service component contains functions for manipulating threads
such as creating and destroying them. It also manages a table that keeps
track of a thread's status and relates it to the RPC context it is
executing. In the DCE RPC implementation, there is a client call thread
for each request an application makes. This thread executes all of the
stub and CS code. When all of the parameters are marshalled and passed to
the network, the client thread is blocked until the result of the call is
returned.
The call service component provides functions of sending and receiving
data. It also manipulates the call handle data structure which serves as a
parameter for all the functions in the component. The important components
of this structure are the binding representation structure which contains
information about the remote partner, interface and operation
identification, a thread identifier, dynamic information such as the
employed transfer syntax, and RPC protocol specific information. The other
parameter common to the call service functions is the I/O vector which is
an array of buffer descriptors. The buffers pointed to in the I/O vector
provide the memory for the marshalled data. The routines in the call
service are used to start and end transfers or to send and receive data.
Data is sent or received in fragments for larger quantities of data these
calls have to be repeated until all the data is processed, There is a
special call that is utilized to indicate to the remote RPC process that
the last chunk of data belonging to the same request or response is being
sent.
The network listener service component detects events on any network and
delivers them to the correct RPC protocol manager (PM). It accesses an
internal table where network descriptors are related to RPC protocol
sequences (transport and RPC protocols). It manages that table (add,
delete operations) as well as monitors the network itself. For example, it
checks the liveliness of the remote partner in the case a connectionless
protocol is employed. The network listener service component further
manages the network listener thread (creation, termination, notification
of events).
The binding service component provides functions to manipulate the binding
representation data structure or binding handle. A client makes a request
to the naming service to first obtain this structure. The binding handle
contains information that relates a client to the server process. It
consists of the location of the server the entire presentation address
consisting of the server network address and the communication port of the
server process), an object identifier, an interface identifier and further
RPC protocol specific information. This structure is pointed to in the
call handle which is part of every function in the call service component.
The RPC security service component provides for the selection of four
levels of security. These are the performance of authentication on every
association establishment, the performance of authentication on every
call, the enforcement of integrity on every packet and the enforcement of
privacy on every packet. The interface service component includes
functions to handle the internal interface registry table which keeps
track of all of the interfaces registered with CCS. It contains interface
uuids, version numbers and operation counts.
The object service component manipulates another internal table that
relates objects to the types to which they belong. Particular objects
include servers, server groups and configuration profiles. The
communication management service component includes functions for managing
all of the CS: CCS, network services, and the RPC protocol services. This
includes processing incoming calls, indicating how fault messages should
be treated, allowing or barring shut-downs, and gathering statistics. The
utility service component includes the functions for handling uuid, timers
and buffers.
The RPC naming service component of FIG. 1b provides the following groups
of services: operations for manipulating binding handles, none of which
imply communications between the client and server (e.g. export, import,
lookup); operations for retrieving information about entries in general
(e.g. interfaces and objects exported by a server); operations on server
groups (e.g. create, delete, add, remove members); operations on profiles;
and interfaces for managing applications for creating or deleting name
service entries in a consistent manner.
The Management Service component of FIG. 1b provides functions that can
only be used by an application to manage itself locally and functions that
can be called to manage remote RPC based applications. In the case of the
latter, an application to be managed has to make itself available by
calling the appropriate run-time functions. An application can control
remote access to its management interface through authenticated RPC
services. Examples of local management services are calls to inquire about
or set time-out values for binding handles or alerts. Examples of remote
management functions are to determine whether a server is listening for
incoming calls, start/stop listening on a server or collect statistics.
RPC SERVICE COMPONENT ARCHITECTURE
FIG. 1d shows the basic components of the DCE RPC service component. As
previously mentioned, this component consists of both a development tool
and the runtime system described in connection with FIG. 1c. The
development tool includes an UUID generator, the RPC Interface Definition
Language (IDL) and an IDL compiler. The RPC runtime system includes a
client or server application, an RPC stub interface, an RPC runtime
interface and the RPC runtime system (RTS) which includes the previously
described components.
Development Tool
The UUID generator is an interactive utility that creates UUIDs (universal
unique identifiers). The significance of a given UUID depends entirely on
its context and when the UUID is declared in the definition of an
interface, it defines that interface uniquely from all other interfaces.
A specific RPC interface is written in IDL which is a high level
descriptive language whose syntax resembles that of the ANSI C programming
| | |
