CA2172423A1 - Method and apparatus for generation and installation of distributed objects on a distributed object system - Google Patents

Abstract

A method and apparatus for installing distributed objects on a distributed object system is described. In one aspect the distributed objects include wrapper classes that inherit object attributes through an inheritance relationship with a developer-written servant class of objects, the developer-written servant classes inheriting attributes through an optional inheritance relationship with an interface class of objects. In a preferred embodiment, the wrapper classes provide an interface mechanism between the methods of the servant class of objects and the object request broker mechanism of the distributed object system. Also included is an apparatus for creating and installing the distributed object in the memory of a computer on a distributed object system. The invention further includes a mechanism for distinguishing deployed distributed objects from development distributed objects.

Description

METHOD AND APPARATUS FOR GENERATION AND INSTALLATION OF DISTRIBUTED

BACKGROUND OF THE INVENTION
5 1. The Field of the Invention The present invention relates to the fields of distributed cO~ nlli~lg systems, client-server computing and object-oriented ~,o~ .""~ . More specifically, the present invention includes a method and app&l~lus for creating and in.ctAlling objects on a distributed object system.
2. The Relevant Art 10 Object oriented plugl~ g methodologies have received h~cl~asing attention over the past several yearc in ,Gspollse to the i"c~asi"g tendency for sorlwale developed using traditional prog,~ ."ing methods to be delivered late and over budget. One problem with traditional pro~ """il-g techniques stems from the em~hasis placed on procedural models and "linear"
code that often is extremely liffil~ult to design and Ill~il"; ;" Generally, large programs created 15 using traditional methods are "brittle", that is, even small changes can affect all elements of the prog,anll,lilJg code. Thus, minor changes made to the sonw~uc; in response to user demands can require major redesign and lewlilillg of the entire program.

Object oriented prog,~"",.;l~g strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the 20 prog~ er with a more hlluilive app~ùacll to modeling real world problems. In addition objects encapsulate related data and plocedulGs so as to hide that inf(,llllalion from the rem~inder of the program by allowing access to the data and procedures only through the object's interface.
Hence changes to the data and or proce~lul.,s of the object are relatively isolated from the rem~inder of the program. This provides code that is more easily ~ ed as comp&l~d to 25 code written using traditional ~ hods, as changes to an object's code do not affect the code in the other objects. In addition, the inherent modular nature of objects allows individual objects to be reused in dirrer~i~t programs. Thus, ~uglan~llel~ can develop libl~;es of "tried and true"
objects that can be used over and over again in dirrt;l~lll applications. This incl~;ases soÇlw~e reliability while decreasing development time, as reliable progl~.~....;..g code may be used 30 repeatedly.
The object l~æta~,hor in distributed systems is a useful technique as it sep~ tes the object's interface from its illl~,lement~lion; thus allowing software ~e~ign~rs to take advantage of the functionalities of various objects available to them without having to worry about the details of the object's implementation. The programmer need only be aware of the object's interface. In addition, object oriented distributed systems allow for multiple implementations of a single interface, which interface ~nay reside on different computing platforms that have been connected through a network. Thus, a prog~ lnler working on one Illacllil)e of a network may make a call 5 to an object about which the pro~ ""l~el has no detailed knowledge with the confidence that at the appl~op~iate time that tlle remote object will be accessed and return its data so that the progl~l"~lle,j code will function plope~ly. Such a system thus maximizes the inherent advantages of object oriented methodologies by taking full advantage of their modularity and encapsulation.
10 Attempts to provide such facilities have been made using object oriented distributed ~y~lellls that are based upon a client-server model, in which object-se. ~ provide inte,races to clients that make requests of the object-servers. Typically in such :jy~t;nls~ these servers are objects consisting of data and associated methods. The clients obtain access to the functionalities of the object-servers by executing calls on them, which calls are mediated by the distributed system.
15 When the object-server receives the call it executes the a~r~p,iate method and transmits the result back to the object-client. The client and object-server coll~llullicate through an Object Request Broker (ORB) which is used to locate the various distributed objects and establish communications therebetween.
Although the advantages to employing object ori~nt~d progl~.,-",il-g methodologies through 20 distributed object systems are .cignific~nt, there remain major hurdles to their implemellt~lion.
An extremely difficult hurdle stems from the hlcleased ~lem~n-1 on object progl~wm~ to provide the functionalities in their code necess~ y to make their objects pe~ro~m plope,ly on the distributed object system. For example, objects in the distributed object system must be capable of activation and deletion by the ORB in r~s~llse to uncoordinated and often concurrent 25 requests from clients. Objects must also be capable of lc;sl)ondil,g to multiple simultaneous requests, i.e., they must be capable of supl)ollillg multithreaded operation.

Unfortunately, most progl~ ";~g objects ~;ull~ tly in çxi.etçn~e are not written to support the functionalities required for placelllt;l~l on a disllil,ul~d Opel~ lg system. Thus, the hl~plelllenlalion of existing objects on such ~y~tt;llls would require much retooling of the existing 30 object software. This would lessen the advantages afforded by object prog,~ gmethodologies as existing pr~~ .g objects would not be easily available in distributed object ~y~lenls.
An additional difficulty with h~ple."f~ e distributed objects on di~llibuled object sy~lenls arises from the need to inform the system of the plesence of the objects at the time of their 35 in.~t~ ion. Since all client r~uesls are plucessed through the object request broker, or ORB, the ORB must have knowledge of the e~ ,nce of the objects. Furthermore, it is preferable in distributed object systems to have functionalities that allow for a clear distinction b~lweell -objects that are in the devclopment phase and objects that are available to users on the distributed object system generally. Providing such awareness poses various difficulties for the programmer who must bear the burden of implem~nting a wide variety of "housekeeping"
operations to take advantage of the benefits of the distributed object system.
S The full plulllise of object oriented m~tho~lologies, especially the advantages afforded by their modularity, have yet to be achieved. In particular, it would be highly desirable to allow pro~l~nllæl~ and other users the ability to create and install distributed objects in a relatively l~dns~al~llt fashion so that objects created in dirrèlGnl progld..~ g languages and/or objects residing on different colll~ulillg platforms can be made available on distributed object systems 10 without extensive modification of progl;1.. ;l~g code or placing an undue burden on the user.
Thus, it would be ~lerel~ble to have a system capable of h~n~lling the formation and installation of distributed objects that ~ il";~s the need for the progln.lllller or the user to be f~mili~r with the details of distributed object systems. More plcrel~ble is a system in which progr:~mming objects that are not distributed can be transformed into a distributed object relatively 15 transparently with respect to the progl~ ller or the user.
.

SUMMARY OF THE INVENTION
The present invention includes a method and a~pa~ s for forrning and in~t~lling distributed objects in a distributed object system. Using the method and appalat~ls of the invention distributed objects can be formed and in~t~ d on distributed object ~y~Lellls without extensive 20 modification to the objects and without the re4ui~lllellt that the progl~lllller or user of the object have an extensive familiarity with providing support for distributed object systems in the prog~n--.-i~g code of their objects. Thus, using the method and app~lus of the invention objects can be brought onto a di~LIibuled object system with greater efficiency and ease than heretofore available.
25 In one embodiment, the present i..~/elltioll provides a coll~ultr-illlple~ nted method for creating a distributed object suitable for use on a di~ led object system. The method of the inventiûn includes the steps of first providing interface files describing hltelr~ces contained in the distributed object, providing hll~)leu.rn~ ion files describing distributed object implelllent~lions, providing servant class files desclibing a servant class of object 30 imple.llenlalions, and optionally providing data schema files desc.i~illg ~~ nl data. The interface, impleme.~ ion, servant class and persistent data schema files are compiled under conl~ult;r control to produce compiled header and source files co.lc~pollding to the interface, hlll)lulllelll~lion, servant class and pel~islenl data schema files, in which the source files collc~pollding to the implenlenl~tion files include templ~te source files. Finally, the header and 35 source files are linked under colll~uler control with the wl~per class so that the wl~per class has an inhe.;~ 1n-~e relationship with respect to the servant class whe.eill the wr~p~r class is derived from the servant class to create thereby the disllil,uled object.

-In one embodiment the method further includes the steps of discrimin~ting between a distributed object intended for development and a distributed object intended for deployment.
The header and source files for distributed objects intended for development are linked with a development object file. Di~llibu~ed objects that are intended for deployment are packaged and S an interface registry file is created for registration with the object request broker mechanism of the distributed object system.
In another embodiment, the present invention includes a computer system for producing a distributed object suitable for use on a distributed object system. The co"ll,uler system of the invention includes a compiling lllechallism for compiling h~lelr~ce definition files including 10 object interface definitions h~le.~ ion files describing distributed object h~plelnenla~ions and servant class files of developer-defined object ilnplemel,l~lions to produce collespollding header and source files. The COIl,~ule, system further includes a linking mechanism to link the source and header files produced by the compiling mechanislll with a w~pper class containing functions and services for operating the distributed object on the distributed object system. The 15 linker is effective to establish an inhe,il~lce relationship belween the w,~per class and the servant class in which the w,~r class is derived from the servant class. In one embodiment, the colll~,uler system of the invention includes a compiling ~ çh~l~ism and a linking mechanism effective to produce a template file COI.t;.;l~i.,g a p,~tolypical version of the servant class.
In still another embodiment the present invention includes a distributed object suitable for use 20 on a distributed object system. The distributed object includes a call to a developer-written function that is conlained in a servant class col.~ il-g developer-written code. In addition, the distributed object of the invention further includes w~per ~l~lell~"~ conlained in a w,~per class of objects. The wl~per slat~lllelll~ include invocations of services for supporting the operation of the distributed object on the distributed object system. The w~alJper class has an 25 inhlqrit~nce relationship with the servant class wherein the w~pel class is derived from the developer-written servant class of objects.
In another embodiment, the servant class of the distributed object of the invention inherits from an interface class of interfaces to se~vices con~ined in the ~v,~pper class. A preferred embodiment is one wherein the di~ilibllled object is located in the llællloly of a computer in a 30 di~llibuled object system whelehl the di~ led object of the invention c~,..~....l..icates with other distnbuted objects through an object request broker Illf~rllAn~ In one embodiment, the services provided by the Wl~p~[ class provide an interf~e Illechal-islll belween the developer-written methods co"l~ ed in the servant class and the object request broker mech~ni~m 35 Further advantages and features of the present invention will become app~u- nl when the detailed description below is read in conjunction with the accolllpanyil~g figures.

BRIEF DESCRIP~ION OF THE DRAWINGS
Figure 1 is an illustration of a co~ uLer network supporting a distributed object system.
Figure 2 is a schematic illustration of a computer shown in Figure 1.
Figure 3 is an illustration of the relationship between objects in a distributed object system 5 and an object request broker.
Figure 4 is a detailed illustration of the co""l,u.,i~tion betweel1 a client and an object as illustrated in Figure 3.
Figure 5 illustrates an inheritance hierarchy in accordance with prior art teachings.
Figures 6A and 6B r~lesents inhP. ;~ e hiel~chies in accordance with the present10 ` invention.
Figures 7A and 7B illustrate developer-written and method functions. Figure 7A illustrates a developer written function. Figure 7B replcisenl~ the wl~ppillg of a developer written-function of Figure 7A by w,a~,per statenlenls to produce a method function in accordal~ce with the present invention.
15 Figure 8 is an illustration of the flow of information in the distributed object function of the invention.
Figure 9 is a floweh~ illu~lldlillg the construction of a development distributed object of the invention.
Figure 10 is a flowch~l illu~kalillg in greater detail the compiling step 906 of Figure 9.
Figure 1 1 is a flowch~ l illu~ ing in greater detail the registration step 910 of Figure 9.
Figure 12 is a flowch~l ill~lsllàling the deployment of a distributed object in a distributed object system.

DESCRIPTION OF SPECIFIC EMBODIMENTS

I. DEFINITIONS
25 As used herein, the term "disL,ibuled object" or "object" refers to an e~ ar.,~ ted package of code and data that can be manipulated by operations defined in the int~.rf~ce of the di~llibuled object. Thus, distributed objects will be seen by those skilled in the art as including the basic plope,lies that define traditional plugl,.lll~ g objects. However, distributed objects differ from traditional pro~ ",il-g objects by the inclusion of two i"~po~ l f~,alul~s. First, distributed -objects are multilingual. The interfaces of distributed objects are defined using an interface definition language that c~n be mapped to a variety of different progl;..,-,l,i"g languages. One such interface definition language is IDL. Second, distributed objects are location-independent, i.e., distributed objects can be located anywhere in a network. This contrasts sharply with S traditional pro~ "-",il,g objects which typically exist in a single address space: the address space of the client. Distributed objects can be object-clients or object-servers, depending upon whether they are sending requests to other objects or replying to requests from other objects.
Requests and replies are made through an object request broker (ORB) that is aware of the locations and status of the objects.
10 A "distributed object system" or "distributed object envi~unlllel-l" refers to a system colnplisillg remote objects that co""",l-~ic~t~ through an ORB that is aware of the locations and status of the objects in the distributed object system. In a prefcl,cd embodiment, objects communicate using the methods described in co-pending U.S. Patent Application Serial No.
(Attorney Docket No. SUNlP023), entitled "Methods and Apparatus for ~l~n~ging 15 Collections of Objects", by Dwight F. Hare, et al., filed March 22, 1995; U.S. Patent Application Serial No. (Attorney Docket No. SUNlP018) entitled "Method and Apparatus for l~n:lging Connections for Coll-lllunicatiûn Among Objects in a Di~llibuled Object System" by David Brownell, et al., filed March 22, 1995; U.S. Patent Application Serial No. (Attorney Docket No. SUNlP025) entitled "Methods, Apparatus and Data 20 Structures for Man~ging Objects" by David Brownell, et al., filed March 22, 1995; and U.S.
Patent Application Serial No. (Attorney Docket No. SUNlP030), entitled "Methods and Apparatus for lVl~n:-ging Colll~uler Processes" by Anthony Menges, et al., filed March 22, 1995. Each of these U.S. Patent Applications is incol~ûl~led herein by rerelcllcc in its entirety.
A plcfcllcd system architecture for imple....o.~ g such an ORB is provided by the Common 25 Object Request Broker Archile~;lult (CORBA) specification. The CORBA specification is defined by the Object Management Group (OMG). Under the CORBA, a distributed object system is defined in terms of a client-server model wllclcin target objects, or servers, provides services to clients that request such services.
An "object Icrclcnce~ or "objref" con~ s a pointer to another object. The creation and 30 definition of object references will be familiar with those skilled in the art.
A "client" as defined herein refers to an entity that sends a request to an object, which object is referred to herein as a '~servei'. Thus, clients invoke operations, or implementations, from servers. In a distributed object e.lvilul~ ,n~, clients need not have knowledge of the implclllenlalion progr~mming l~ngllage, nor does the illl~le..~ ion have to have knowledge of 35 the client's progl~ g language due to the rc.luhcmclll of mnltilingual character of such objects. Clients and servers in distributed object envilul.ll~enl~ need only co.. iç~te in terms of the interface definition language. As noted above, the request by the client to the server, and the server's reply to the client, is handled by the ORB.
An "object interface," is a specification of the operations, allribules, and exceptions that an object provides. Preferably, object interfaces for distributed objects are written using, e.g., IDL.
5 As noted above, objects perform services through their interfaces. The use of interfaces therefore relieves the need of clients to be aware of the prog~ ling languages used to define the methods and data of the objects in the service.

II. PHYSICAL EMBODIMENT
The present invention employs various process steps involving data stored in col~pulcr 10 sy~lcllls. These steps are those requiring physical manipulation of physical quantities. Usually, though not necess~ily, these qu~ntitiçs take the form of electrical or magnetic signals capable of being stored, transferred, combined, colllpa~cd, and otherwise manipulated. It is sometimes convenient, principally for reasons of common usage, to refer to these signals as bits, values, elements, variables, characters, data structures, or the like. It should lclllenlbelcd, however, that 15 all of these and similar terms are to be associated with the app~ ,iate physical quantities and are merely convenient labels applied to these ~ l;PS.
Further, the manipulations pclrolllled are often referred to in terms, such as identifying, running, or compaling. In any of the operations described herein that form part of the present invention, these operations are machine operations. Useful machines for pclrolllling the 20 operations of the present invention include general p~ ose digital conl~ulcl~ or other similar devices. In all cases, there should be borne in mind the distinction between the method of operations in opel~ling a colll~uler and the method of coln~ul~tion itself. The present invention relates to method steps for opel~lillg a colll~ulcr in processing electrical or other physical signals to generate other desired physical signals.
25 The present invention also relates to an a~p~lus for pclrolll~illg these operations. This al)~alalus may be specially constructed for the required purposes, or it may be a general purpose colll~uler sele~ ely a;liv~ed or reconfigured by a co~ tr program stored in the co,ll~ul~r.
The processes presented herein are not inhe~ ly related to any particular co,ll~uler or other apparatus. In particular, various general ~ ose machines may be used with programs written 30 in acco,dal~ce with the teachings herein, or it may be more collvt;lli~nl to construct a more specialized appal~lus to pelrol,ll the required method steps. The required ~llu-;lult; for a variety of these machines will appear from the description given below.
In an embodiment of the present hl~cnlion, disllilJIllcd objects are located on one or more colllpultil~ linked together by a co~ ,.J~r n~lwcJlh such as the n~,lwolh illustrated at 100 in 35 Figure 1. As seen in the Figure, lKlwolh 100 includes col~puler 102 which colll~,uler is coupled -to a network 104. Network 104 can further include a server, router or the like 106 in addition to other computers 108, 110, and 112 such that data and instructions can be passed among the networked computers. The design, construction and implementation of computer networks will be familiar to those of skill in the art.
Computers 102, 106, 108, 110, and 112 are illustrated schematically with respect to Figure 2 at 200. Each computer includes a central processin~ unit (CPU) 202 which CPU is coupled bidirectionally with random access Illellloly (RAM) 204 and unidirectionally with read only memory (ROM) 206. Typically, RAM 204 includes pro~ ."i~-~ instructions and data,including distributed objects and their associated data and instructions, for processes currently opel~tillg on CPU 202. ROM 206 typically includes basic operating instructions, data and objects used by the computer to perform its functions. In addition, a mass storage device 208, such as a hard disk, CD ROM, magneto-optical (floptical) drive, tape drive or the like, is coupled bidirectionally with CPU 202. Mass storage device 208 generally includes additional prog,~."~ g instructions, data and objects that typically are not in active use by the CPU, although the address space may be ~ccessed by the CPU, e.g., for virtual memory or the like.
Each of the above described computers further includes an input/output source 210 that typically includes input media such as a keyl~oald, pointer devices (e.g., a mouse or stylus) and the like.
Each coll~ulel can also include a I1GlWUI1~ conneelion 212. Additional mass storage devices (not shown) may also be connected to CPU 202 through network connection 212. It will be appreciated by those skilled in the art that the above described hanlw~t; and software elements, as well as nelwol~ing devices, are of standard design and construction.
Residing on each of the con,~ult;l~ across the netwulk are a variety of plucesses and objects, which processes and objects can be in conl~l,unication with each other, either within the memory space of the same machine or within the Illelll{)l~ spaces of two or more machines residing on the network. As noted above, an object resides in a server process and functions to respond to a request made by a client In distributed object :,y~l~lns, the co~ ic~tion of the request b~lween the client and the object is mP~ tPd by an object request broker (ORB).
An example of such client/server relationships in a distributed object system is illustrated in Figure 3 at 300, where a first client 302 resides in a process 304, a second client 306 and an object 308 reside in a second process 310 and a client/object 312 and second object 314 reside in a third process 316. It will be appreciated that col~ .tions can be established belweell clients and objects in different plocesses, e.g., bel~l process 304 and process 310, or between clients and objects in the sarne process (e.g., client 306 and object 308). Each process may reside on sepal~e cu~ tlel(s) col-n~le~l actoss a nelwoll~, or two or more process may be located on the same machine. In addition, the clie4t(s) and object(s) may be execute~l within processes on one or more threads. The use of objects, plocesses and threads will be familiar to those of skill in the art.

-Regardless of the physical location of the processes, each process communicates to another process through an object request broker ~llechanism (ORB) 318. ORB 318 typically includes at least one dæmon for processing connection requests from clients and servers such as Dæmon 320. Thus in terms of the definitions provided above, clients, such as clients 302 and 306, 5 request, or "invoke", replies from objects, such as objects 308 and 314, by first establishing connections 322 and 324 with the ORB respectively. The requests are processed by the ORB
and the Dæmon which communicate with target objects 308 and 314 over connections 326 and 332 respectively. The ORB then establishes comle~:lions l~lween the processes con~ining the apploL..iate clients and servers, such as connections 334 (connecting processes 304 and 310), 10 336 (connecting plocesses 304 and 316) and 338 (connecting processes 310 and 316). In a preferred embodiment, objects can act both as clients and servers, such as client/object 312 which comlllu.licates with ORB 318 over connections 328 and 330. The details of establishing connections among objects in a diskibuted object system are discussed in the above-cited co-pending U.S. Patent Application Serial Nos. (Attorney Docket No. SUNlP023);(Attorney Docket No. SUNlP018); (Attorney Docket No. SUNlP030); and (Attorney Docket No. SUNlP025).
The sequence of events which comprise coll~.lul.icdlion between a client and an object is illustrated in greater detail with respect to Figure 4 at 400. There, client 302 seeks to collllllullicate with object 308. Formally, from the ~tandpoinl of the client, an invocation of 20 object 308 requires the use of an object l~felt;nce within the client that points to object 308 as illustrated by arrow 401. T~owever, to accommodate the need for ..~ g a high degree of generality in the system, the actual flow of inrulll.dlion comprising the i..voca~on is somewhat more complicated. In reality, the hlvoc~lion of object 308 requires the request to kavel from client 302 to a stub 402 associated with the client, which stub provides an interface between 25 client 302 and ORB 3 i 8. The stub delellllilles the necessary form~t~ing to send the message to the remote object. The communication bel~eell the stub and ORB is illuskated by arrow 404.
Using the methods described above, ORB 318 collllll.lllicates with object adapter 408 as shown at 406 which object adapter is effective to locate and/or launch object 308. When object 308 is loaded into memory and is running, the object adapter passes the h~vocalion as shown at 410 to 30 a skeleton 412 for object 308. The skeleton leceives the request from the object adapter and calls the a~,plo~liate operation, or method, in the object and fo~w~ds to the client any return values.
Thus, it will be appreciated that distributed objects require an extensive amount of progl~ in~ effort beyond that required to create a non-diskibuted object to operate pl~,pelly.
On the client side, not only must object l~;f~lt;nces be made available, but stubs must be made 35 available for colllnlullication with the ORB. On the server side skeletons must be provided to interface with the object adapter which object adapter in~rfaces with the ORB. It will also be appreciated that this example pel~ s only to the coll..llunication between a client and an object.
Those of skill will realize that still more m~lifi(~tions are l~lired in order to support other -system functions, such as the launching and deletion of objects and the operation of various housekeeping functions required by the distributed object system.
Generally, the support functions or services required for developer-written objects or classes of objects to function in a given ope~ g system environment are provided using libraries of 5 support objects that can be accessed by the developer-written object or class. The libraries thus provide a centralized source for code that a developer can access when writing progr:-mming code for a developer-written object or class. In object progr~mming, such access is often provided by establishing inhsrit~nre relationships between the developer-written object or class and classes containing support functions and/or services in the libraries. The creation and use of 10 inheritance relationships is well known to those of skill in the art of object progl~ -g.
The present invention provides the support functions and services ~-~cess~. y for the operation of objects in a distributèd object system in a ll~nspa.enl manner by employing a mechanism of inheritance dirrelcnt from that practiced in the prior art. Under prior art methods, as illustrated in Figure 5, a developer-written object or class inherits from a base class of system support 15 functions and services that provides the developer with access to the various system functions required for implenlellt~lion of the servant object. The base class in turn inherits from an interface class that supplies the ~ uil~d interface ~UIibules for the system utilities. It will be appreciated that the interface class may optionally be included within the base class as indicated by the dashed box. Generally the interface class is a "pure" class, i.e., the class provides only 20 interfaces, not methods.
Those of skill in the art will appl~ciale that such a ~ ;lule forces the lc;s~nsibility and burden of incoll,ol~ g all of the desired system functions and hllelr~ces that are required to make the object work onto the developer. Generally, the developer is required to implement the necessa, ~ functions and services by writing the ~plupliate calls and invocations to the 25 functions and services into the developer-written object or class and linking that object or class to libraries belonging to the base class and/or intt~rface classes at the time of compilation. As will be appreciated by those of skill in the art, in a di~llibuled opeidlillg envir~lllllellt such as described above with respect to Figures 3 and 4 this re.~ lllelll places a tremendous burden on the developer to hlcol~ol~le and define the n~.ce~ structures needed to support the existence 30 of the object on the distributed object system.
. .
The present invention avoids this difficulty by incol~ lillg an "inverted" inhelilailce structure in which the distributed object is a Illelllber of a wl~;per class of object development functions and services that inherits from the developer-written, or servant, class, i.e., the class of interest to the progi~nllller and user, to provide a distributed object capable of functioning on 35 a distributed object system. As will be seen below, such an inhefilance structure allows for the gene.~lion of distributed object classes that il~cûlpol~le all of the necess~y and optional progi~.,....ing code required to operate a distributed object on a distributed object system in _ addition to the functions provided by the developer-written object or class. Thus, it will be seen that the present invention removes the burdens on the developer described above by providing substantially transparently the pro~ ."~ g code required for distributed objects to operate in distributed object systems.
5 In one embodiment, shown in Figure 6A, the wl~per class inherits from the developer-written object/class (servant class) which in turn inherits from the above-described h~telr~ce class. As noted above, the h~telrace class provides the interfaces for the functions and services of the wlapper class, as intlic~ted by the dashed line in the Figure. In addition, to allow the skeleton to call code in the wla~per class, the wl~per class further inherits from an object 10 adapter (OA) Interface Class. In one embodiment, one OA I~ lrace Class is provided for each interface registered with the ORB. The wl~ppcr class may optionally further inherit from one or more additional classes depending on the ~ .ni7.~tion of the system support functions. In one embodiment, shown in Figure 6B, the wl~per class inherits from the developer-written class (and, in turn, from the inheritance class) in addition to an OA interface class and an internal class 15 that conlains additional functions and services. In one embodiment, these additional functions and services are not available to the prog~ llær, but are private to the system.
The inversion of inheritance structure is accomplished in part by a procedure referred to herein as "wld~ g", in which sl~t~lllc.lls hll~le~ g wla~er class services are placed around a call to the developer written function. This code structure is illustrated with reference to 20 Figures 7A and 7B. In Figure 7A, a developer-written function F() is shown. As will be farniliar to those of skill in the art, especi~lly those skilled in the art of progl;.. ~il-g in the C or C~+ languages, the developer-written function co,lll,lises a ~l~tclllelll of the function name and any ~ ulll~nl~ taken by the function plus the statements that comprise the workings of the function, shown as ellipses within the braces.
25 Figure 7B illu~lldles a method function, Dist_Obj_F(), implemPnted in accordance with the present invention in which a call to a developer-written runclioll has been bracketed or "wrapped" by wla~per statements or code that implement the support services of the wl~pper class (Wrapper_Stmt_A, Wrapper_Stmt_B, Wrapper_Stmt_C and Wrapper_Stmt_D) above and below a call to the developer-written runclioll F() These ~lalel,Rllt~ may be function calls or 30 inline functions written in progli.. ;~g code (e.g., in C++). It will be appreciated that the wl~per ~ 1IR111~ may include paired ~l~t~lll~,ll~ that bracket the call to the developer-written function, e.g., a first ~talelllellt to initiate a service prior to the operation of the developer-written function and a second statement following the execution of the developer-written function to exit the service, in addition to individual ~lalelllellls that are written either before or after the call to 35 the developer-written function. In one embodiment, the distributed object created using such a structure is a member of the wl~per class which provides the distributed object support for the functions required for operation in a distributed object system in addition to any optional system features the prog~ er wishes to implement.
In a one embodiment, the services provided by the ~ er class include object lifecycle services, object request broker and object adapter services, registration services, multithreading 5 services, subobject services, refdata services, reaper services, object reference services and tracing and logging services. It will be appreciated by those of skill in the art, however, that this list of services is by no means exhaustive nor is the inclusion of each family of functions and/or services listed nece~.s~. ;Iy required for the installation and/or operation of a distributed object in a distributed object system. Families of services may be added or removed from the wrapper 10 class wilhoul departing from the scope of the present invention. In general, the number, type and o.~anization of the services compri.cing the wl~r class will depend on the nature of the operating system, the object request broker ~ cllanism and the object adapter mech~ni.cm. It will be further appreciated that these services may be hll~le.lle~ d in a variety of ways using methods known to those of skill in the art. In one embodiment some of these services are 15 implemented in acco~dallce with CORBA specifications.
In one particular embodiment, the above-mentioned lifecycle services include object creation functions, object deletion functions, object activation functions, object deactivation functions, server startup functions, server shutdown functions and server installation functions. These functions allow for the creation, installation, operation and deletion of objects and servers in the 20 distributed object system. An implemenlation of some of these functions is described in co-pending U.S. Patent Application Serial No. (Attorney Docket No. SUNlP035), entitled "Method and Apparatus for ~ ging Objects and Processes in a Distributed Object Operating Envi.on...ent" by Alan Snyder, filed con.;ull~nlly h~;lcwilh and incol~ol~ted herein by reference.
25 The creation functions are used to create disLIibu~d objects that are recognized by the ORB in addition to object references to the created objects. In one embodiment, these functions are available only within object servers co~ g the object i,l,l~le~ ion and are used primarily within the methods contained in factory objects (see, e.g., co-pending U.S. Patent Application Serial No. (Attorney Docket No. SUN1P019) entitled "Method and Al,p~ s for 30 ~n~ging Relalionsllips Among Objects in a Distributed Object Envil~nnl~llt", by Bruce E.
Martin, et al., filed March 22, 1995, and inco.~G,aled herein by reference).
Deletion functions provide a means for ~el~ting an object from the distributed object system.
In one embodiment, the deletion r~nclioll does not imm~ tely remove the object from the distributed object system, but rather sets a flag that enables the object to be deleted upon the 35 deactiv~lion of the object. This allows the object to behave colrt~;lly in the face of concurrent requests. Preferably, the check for the flag set by the deletion function can be made by the system or can be pelru.llled manually, i.e., by code written by the progl~ er. In another -embodiment, a deletion hook may be defined that allows the invocation of a programmer-written function by the system upon the deletion of an object.
Activation functions allow for the activation of objects so that the objects are available on the distributed object system. In one embodiment, the system ~elro~ s the activation of objects that 5 receive invocations or upon the installation of new objects on the distributed object system. In a preferred embodiment, a C++ servant (i.e., a C++ implellænlalion of the interface of the object) is created upon activation of the object. In another preferred embodiment, an activation hook is defined such that the system will invoke a plugl~l~ler-written function just prior to activation of the object. The activation hook may be used to accomplish a variety of actions, e.g., to 10 initialize the transient state of the servant, establish conspil~eies (see U.S. Patent Application Serial No. (Attorney Docket No. SUNlP028), entitled "Method and Apparatus for Conspiracy Among Objects" by Aahlad Yeturu, filed and incorporated herein by reference) and provide access to ~~ lent data (see U.S. Patent Application Serial No.
(Attorney Docket No. SUNlP021), entitled "Method and Appal~lus for Providing Tl~nspalent 15 Persistence in a Distributed Object Operating System" by Mark W. Hapner, filed which is incorporated herein by reference.
Conversely, deactivation functions render objects unresponsive to invocations made on the objects following deactivation. However, dea~;tiY~led objects may still process invocations made prior to deactivation. Generally, dea~;liv~lion frees system resources used by the object, e.g., 20 such as the C++ servant associated with the object as described above. In one embodiment, deactivation is handled by the system aul(J~ lly after the object has been dt;lt~ hled to have been idle for a set period of time (e.g., 15 minutes or 1 hour). Of course, those of skill will recognize that automatic dea~;liv~lion may be disabled and instead ~,rol,lled using progl~,llller supplied conditions and functions. In another embodiment a dea~;liv~lion hook is provided to 25 allow the execution of a prog,~ r-written function at the time of dea~livalion.
Server startup functions are used to pelrul~ll tasks at the time of the server's !~un.~hing on the distributed object system, although pl~rel~ibly not in conjullction with startups performed solely to install or remove the object from the distributed object system. In one embodiment, the server startup functions are hooks that are invoked during server startup, preferably, but not 30 necessarily, before any requests are processed by the server.
Server shutdown functions cease server execution. As with dea.;~ivation functions, shutdown functions are plGîelably activated a~Jlu~ ic~lly following a specific period of time (e.g., one hour). In a pr~felled embodiment, the .lululllatic execution of the server shutdown function can be disabled or modified by the ~ ullll~r. Server shutdown hooks may also be used to invoke 35 pro~,l~lllller-written functions at the time of server shutdown.

Server installation hooks are also provided in one embodiment. These allow the invocation of a programmer-written function during server installation. In another embodiment, the function returns a Boolean (true or false) value. If the value is "true", server installation proceeds; if "false" installation is aborted. It will be appreciated that such a hook will be useful in che~l~ing 5 for the presence of system lc;soul~;es that are vital to server operation at runtime. If the resources are not present, inst~ tion of the server can be aborted, prerel~bly l~lullling an exception.
In one embodiment, registration functions are included for registering an object on the object request broker mech~ni.~m, unregi~tenng an object on the object request broker mechanism and a finding a service provided by an object registered with the object request broker. The use of 10 such functions will be known to those of skill in the art. The registration function registers an object in an area of computer nlellloly ~igned for object registration. The unregister function removes the registration of objects from those areas of colllpuler nlelllol~ assigned for object registration, and returns the object lcreleilces. The find function sear~ es pre-allocated areas of memory allotted to objects that provide the desired service. Preferably, some of these functions 15 are implemented in accordance with CORBA guidelines.

It will be appreciated that still more functions can be defined to handle interaction between the distributed object and the distributed object system and/or object adapter. For example, functions can be included to allow objects to define and access reference data. Other functions can be used to create and identify subobjects as described in co-pending U.S. Patent Application 20 Serial No. (Attorney Docket No. SUNlP023) and object references. Still other functions may be used to implement tracing and logging of code execution. Yet other functions can be used to support mulLilllleadillg. The choice and implt;lllentalion of such functions will depend on the particular details of the di~LIibuled object system, as will.be apl)~cnt to those having skill in the art.
25 By way of example, in one embodiment the wl~per class complises several types of lllelllber functions including method functions, service runclions, creation functions and support functions. Each of these functions is in~ ded in one of the above-described services, but will be described in additional detail below. Again, it will be appl~ci.-ted that impleu .~ A~ ion of the functions can be accomplished in a variety of ways, as will be apparellt to one of skill in the art, 30 and that one or more of these function may be omitted, or the functions augmented by additional functions, without departing from the invention.
Method functions are invoked by the skeleton when an object r~ceiv~;s a request from a client.
These functions include "housekeeping" actions such as ~quiring mutex locks on a data structure, logging the object's activity, testing for deletion of the object prior to receipt of the 35 invucalion, acquiring persistent data and the like. These functions contain wl~per code that "wraps" calls to functions in the servant class that are similar to the method function. An example of the structure of a method function is shown below.

method_function(arguments){
wrapper code;
result = servant::function(arguments);
wrapper code;
return result;
}

The ~lale,llenl "result = servant::function(a,~ ,l,el.ls)" will be recognized by those of skill in the art as a sl~lellltil l that sets the value of the variable "result" of wrapped function "method_function" equal to the developer-written function "s~lv~l::function(arguments)". It 10 will be seen that the function method_function is capable of ~u~pol~ g operation in a distributed object system and implementing the desired developer-written function by virtue of including the wl~per code in addition to the call to the developer-written function.
In one embodiment, a method function in accoldance with the present invention appears as follows:

Log Entry Acquire Lock Begin Transaction Log Acquiring Lock Test for Deletion Fetch Subobject ID
Call F(j Delete Subobject ID
End Transaction Release Lock Log Exit/Exception Log Entry and Log Exit/Exception are wl~)per code implementing the logging of the execution of the method function. The ~.lap~r code Acquire Lock and Release Lock implement mutex locks on data stored in lllelll~ for the purposes of m~ .,eaded progl;~ g operations. Begin Transaction and End Transaction are wlapper code defining the endpoints of 30 the operation of the object on the data in llælll~ . Fetch and delete subobject ID are wl~yper code that implements subobject operations as ~lic~ sed in co-pending U.S. Patent Application Serial No. (Attorney Docket No. SUNlP023). As mentioned above, these statements are paired around the developer-written function as they require a starting action before the function call followed by a le. in;l~AI i~lg action after the function call. Test for deletion is wl ~pper 35 code that detellnines whether the object is in the deleted state, at which point an exception is returned to the client. This ~ e~ ,nt appears only once, before the call to the developer-written function. Call F() is, of course, a call to the developer-written function. The implelll~..lalion of the wl~per code will be ayl)~t;l~t to those of skill in the art. It will also be appreciated that one or more of the above-described w,a~r code features can be omitted at the option of the ~0 developer.
Service functions provide services that the servant class can use. In one embodiment, these functions are called from the servant class by use of the above-described interface class. In addition, these functions are not wrapped as the w.apper code described above, but may be called by the developer within the developer's own code. These functions can include, e.g., functions to acquire and release locks on data structures, functions to activate and delete objects, functions to check for deletion, functions to define object lifespan, and functions to make and 5 abort changes to persistent data.
In one embodiment, the service functions include a Delete function to delete an object, a Deleted function to check the deletion flag for an object to de~e. ",i-,e if that object is in a deleted state, and a Check_For_Deleted function to raise an exception to the client if the object is in a deleted state. In addition, a Refdata function to obtain the lere~Gllce data for an object, a Facility 10 function to return a class-specific tracing facility for logging information specific to the object implemGmlalion class, a Commit function to detPI IlI;I-iilp~ the end of atomic unit of change for writing persistent data to storage, and an Abort function to abort changes to the last actual commit may be provided. Further, a Lock function to explicitly reacquire a mutex after the lock has been released, a Read_Lock function to lGac4uhG a lock for a read operation after the lock 15 has been released, a Write_Lock function to reacquire a lock for a write operation after the lock has been released and an Unlock function to release a lock may be included.
Additional service functions can include a De~;liv~le function to allow an object to deactivate itself and destroy the associated servant, a Create_Subobject function to create subobjects, a Timeout function to set a Illi~ idle time for an object before that object is deactivated, and a 20 Servant_Objref function to obtain the ORB object reference for an object. The implementation of these functions will depend on the nature of the distributed object system and will be familiar with those having skill in the art. It will also be recognized that the foregoing list of functions is but one embodiment of the invention and that functions listed above can be removed or replaced without depa"ing from the invention.
25 Creation functions aré static lllGlllber functions that are public. These can be called from other code in the server, such as a registration hook (described above) or a factory object method.
Creation functions are not called through the ;.~. rhne class, but rather are called directly by name. In one embodiment, the Creation functions include a Creator function to create an h~l~lce of a servant class and its pe~ ' Ql~ data which the creator function stores in the refdata 30 of the object. The creator function also signals the OA to create the object and calls any initiAli7A~ion hooks that have been defined by the pl~gl~ ler (see above), Support functions are called either by the object adapter (e.g., to activate an object) or from or elsGwllelG in the wldpper library. In one embo~imP.nt, these functions are not available to the developer, but are private and Un(lo-;u~ e~1 The support functions include a Constructor 35 function to initi~li7to, a mutex lock, find the ~.~ nt data for the object and attach the ~. ~ t;;n data to the servant. A Destructor function is also included to test for object deletion and, if the object is deleted, delete the pel sis~ll data associated with that object.

-Start-Up and Shut-Down support functions may also be included. The Start-Up function serves to open persistent data storage, register the class with the ORB and invoke any start-up or register hooks. The Shut-Down function closes pel~islellt data storage and calls any shut-down hooks. A Config~lre function defines a tracing facility to allow tracing events to be posted and 5 calls any configuration hooks. An Activation function is available to create the servant, call the user's activation hook and notify the object adapter (OA) that the object is active. A Dea~ alion function quiesces the object, calls the above-desc,ibed de~livdlion function, unquiesces the object and checks for the deletion flag. If the flag is set, the ORB is notified to dispose of the object and any deactivation or delete hooks are called. The servant is then deleted. A
10 De~;liv~lion Upcall function may also be included to allow the OA to call the deacliv~lion function.
The operation of a distributed object produced by the above-described Wldppillg is illustrated at 800 in Figure 8. As described above, an object adapter 802 (OA) sends a request (arrow 804) to the distributed object 805. The distributed object 805 is seen to col~lplise two layers, the 15 skeleton 806 that comprises those functions and services that handle h~ ions with the object adapter, and a second layer 808 that c~ es the vl~per class, the call to the developer-written function and those functions that handle the h~lt;,~.;~ion of the distributed object with the ORB. An invocalion to the distributed object is handled initially by the first layer which processes messages sent to and received from the object adapter. When the p&.~ sent to 20 the skeleton of the distributed object are passed to the second layer (not shown), the developer-written function 810 is called (p~ll.w~y 1). The function is executed by the developer-written function and any result is returned to the client via skeleton 806 (patllw~y 2).
A distributed object including the above-described inhelil~1ce ~lluclult; can be created using methods known to those of skill in the art for creating objects and linking code from libl~ies 25 into objects and methods for establishing inh~.rit~n- e relationships among classes. These methods can include those when;ill the developer provides the code required to establish the inheritance relationships. Preferably, however, at least some of the code that comprises the distributed object, including the arol~ ioned i~.h~ e ~ clule, is genel~ted for the developer, e.g., by a processor, pre-processor, compiler or the like, so that the prog~n~ er is 30 relieved at least somewhat from the burden of providing code to support the operation of the distributed object on the distributed object system.
In one embodiment? the present in~,ell~ioll includes a method and app~ s for generating a distributed object in which the developer provides one or more input files in addition to progl;~.-"~ g code that defines a developer-written, or servant, object and/or class. From these 35 input files one or more templates are gellelal~d containing a prototypical version of the servant class in which the functions are empty or contain co.. ~ or instluctions for the developer.
The developer provides the a~plupliate information to produce code that, when compiled and -linked with the wl~pper class, produces a distributed object capable of running on a distributed object system.
One method of forming the distributed objects of the invention for development purposes is illustrated with respect to Figure 9 at 900. Starting at step 902, various input files are created by 5 the developer at step 904. Preferably, these files are text (ASCII) files that include the information necessary for a compiler to process the developers code, wrap the code in the applvpliate functions required for operation of the object on the distributed object system and link the compiled code to the a~plu~fiate interface class, OA interface class, servant class and, optionally, internal class libraries. It will be appreciated by those of skill in the art that such files 10 can be created using any text plocessol. It will be further appreciated that the actual content of these files will vary depehding on the particular compilers being used, which compilers will vary in turn with the particular ope~dting system employed. In one embodiment, the opel~ling system is the Solaris~ operating system available from Sun Micro~y~lems of Mountain View, CA.
15 In one embodiment, the input files c~llplise a file or files cont~ining the pa,~l~eters and instructions for the object's interface; a file or files cont~ining the p~eters and instructions for the implelllel,lalion of the object; a file or files that contain the p~ll~ and instructions defining the servant classes for the object's implelllenlalions; and a file or files that include compiled object code and shared libraries that contain code called by the object servers and/or 20 client programs. In addition, shell scripts, package definition files and various make files can be used to gene.~le the distributed object of the invention. Further, a file or files containing pel~i~lenl data schema can be included as can an exception message catalog. The creation of such files will be well known to those of skill in the art.
The interface definition file(s) can be written using the Inlelrdce Definition Language, or IDL, 25 and any L~l~i~lc;nl data schema files can be written using Data Definition Language, or DDL.
These languages will be familiar to those of skill in the art. In a plerell~d embodiment, the data menlbel~ defined in the DDL file are stored using the persistent storage ~l~echanism described in co-pending U.S. Patent Application Serial No. (Attorney Docket No. SUNlP034).
The file or files describing the pa i~læle.~ and h~llu~;lions for the object's hllple.l~enl~lions will 30 preferably contain inter alia instructions describing how the objects are to be created, activated and deactivated, as well as timeout p~i~æl~ls for servers.
Package definition files are used to create the package of libraries, i...rl~..ænlations and interfaces that define the object for in~t~ tion as deployed objects (i.e., objects for general use on the distributed object system as opposed to develop.llent objects that are generally intended 35 for the use of the developer). It will be appreciated that the exact nature of the package definition files will depend on the nature of the opel~ling system controlling the ORB. In one embodiment, the Opelaling system is the Solaris~ o~.idling system and the package files include a package definition file defining the name and attributes of the package, a prototype file defining a set of installable files and directories to be included in the package upon installation, a postinstall file comprising a script that is run after installation of the package and a preremove file that contains a script that is executed before a p~.~lrAge is dein.~tAIIe(l In addition, the package definition files 5 may further include a depend file that lists the dependencies of the package on other software packages and a copyright notice file.
The make files include files that define the co~ ol-el-l~ to be consl~ ;led by the compilers and linkers used to form the distributed object and the locations of those files. These colllpollelll~ include interface shared libraries, pel~ ll data object files, object 10 implementations, object servers, client programs, shell scripts and packages. These files can further include definitions of additional colllponent~ (e.g., source files) and rules for building nonstandard components. In addition, the files can also identify subdirectories contAining additional inputs and subdil~clolies col,lAi~ g package definitions. These files further identify the package into which the installable conl~l1ents are to be composed.
15 At step 906 the implementation, inte.rfAce and optional pel~ ent data files are compiled. The compiling of the input files is pelrol.ned using compilers of standard design and construction and is described in more detail below with respect to Figure 10. At step 908 the interfaces of the objects are registered with the object request broker as des.;libed in greater detail below with respect to Figure 11. At step 910 the servers and implen~enlalions are started to cause self-20 registration with the object request broker, as described in co-pending U.S. Patent Application Serial No. (Attorney Docket No. SUNlP030). The sequence terminates at step 912.
In one embodiment, the above-described procedures are performed recursively on each subdhGclol~r identified in the make files.
The compiling step 906 is described in greater detail with respect to Figure 10 at 1000.
25 There, beginning with step 1002, the interface definition library files are compiled to produce header and source files àt step 1004. These header and source ~lles are then compiled by using standard compilers that are collllllclcially available.
In one embo-~im~l-t, the il~lel r~r,e definition files are written using IDL and are complied by an IDL compiler to produce C+~ header and source files for each IOL file. A plerelled IDL
30 compiler is described in co-pending U.S. Patent Application Serial Nos. (Docket No.
P774), entitled "Compiler With Generic Front End and DY..A~;CAI1Y Loadable Back Ends", and (Docket No. P775), entitled "Method and System for Type Identification for Multiple Inl~lraces in a Distributed Object System", both of which are inco~ ed herein by lt;fel~;nce These files are then compiled by a C++ compiler to ~luduce a shared library. In another 35 pl`~r~ d embodiment, the IDL compiler is capable of l~.n,.~lling the interf~ce of objects that are being developed to avoid conrli~ with eyi~ting objects that are "deployed" on the system so as to IIIAil~ the integrity of objects that are c~ y in use by clients on the distributed object system. For each interface definition file (e.g., IDL file), the interface compiler is run to produce a special interface repository (IFR) file that includes the inforrnation necessary to install the interface in the ORB of a local or remote machine. The production of such an IFR file can be accomplished using standard techniques.
5 Next, at step 1006, any persistent data definition files used to describe persistent data are compiled to produce header and source code which is then compiled into the final object. Again, this is performed using standard colllllle~ially available compilers. As described above for the interface definition files, the data definition files are plc;ft;ldl~ly written using DDL and are compiled using a DDL compiler to produce C~+ header and source files which are compiled 10 using a C++ compiler to genel~te an object file.
At step 1008 the implell,enl~tion files are compiled to produce header and source code. The implementation files are p.erel~bly compiled to produce C++ header and source files. In a preferred embodiment, the compilation produces one or more template source files for editing by the developer. These files contain source code that includes the al!pl~liate interface and library 15 ler~lcnces and other code required by the object, in addition to sections that are edited by the prog~an~lnel to define those portions of the source code not capable of genel~lion by the implementation file compiler, e.g., the developer-written functions. This simplifies the construction of the servant class.
At step 1010 the servant class files are compiled using standard methods to produce the 20 object file and, at step 1012, the object servers and client programs are constructed using standard techniques. The procedure then te"llil~AIçs at step 1014.
Each object server that is defined in the make files is constructed by the linker using the object files and shared libraries gene,~ted as des~ ,ed above. In addition, a set of system shared libraries is linked in to provide support for the opelalhlg system in addition to the ORB and OA.
25 In a plc;relled embodiment, a special object file is linked in for development objects, i.e., objects that are under development (not for general use), to avoid conflicts with deployed objects that are in general use on the distributed object system. In one embodiment, this linking operation includes setting a flag to hldicate that dirfe~ t file names and identifiers be used for registration to avoid conflicts with any deployed servers. In addition the file paths and search paths for any 30 factories used by the object are altered to avoid conflicts with file and search paths for deployed object factories.
In a preferred embodiment, the construction of the server includes the addition of a spy object that col.,lllullicates to the system at defined intervals certain information about the server. In addition, the spy object supports operations illl~ tP.d by the system to change certain system 35 level parameters, including tracing states, operations to request server shutdown, operations to attach a debugger to the server, operations to return pa~ e~ to the system, operations to delete the server, operations to return all possible tracing categories and operations to support destruction of the server. These features are described in co-pending U.S. Patent Application Serial Nos. (Docket No. P750), entitled "System and Method to Control and Administer Object Servers Using First Class Distributed Objects"; and (Docket No.
5 P749), entitled "System and Method for Del~. ",i~ g and Manipulating Configuration Information of Servers in a Distributed Object Enviru.l.--e..t" both of which are incol~ol~t~d herein by reference.
Each client prograrn de~med in the make files is also constructed by the linker using the object files and shared libraries described above, as well as being linked to a set of system shared 10 libraries. For "development" clients, i.e., clients not intended for general use but for use as aids in object development, a special object file is linked to the client to alter the search paths used by the client so that development factories are found in preference to deployed factories. In one embodiment, the development fartories are ignored if they do not support the interface expected by the client.
The interface registration step 908 of Figure 9 is illustrated in greater detail at Figure 11.
Beginning at step 1102, the h~ l~e definition files are first registered with the object request broker by loading the a~plopliate IFR file at step 1104. At step 1106 the servers are executed to cause thereby registration of themselves and their h"~len-c;lllalions with the ORB. The sequence le-lninates at step 1108.
With respect to registration steps 908 and 910, it will be appreciated that the actual operations required to register an object will vary depending on the details of the o~l~th~g system and ORB being used. In one embodiment, the object is registered with both the ORB and the opel~ g system. With respect to the ORB, regiskation preferably includes depositing with the ORB the interface definitions, the hllplc~ ~lion definitions and the definitions of the server programs. This provides to the ORB the requisite information for the ORB to locate the correct skeleton for the server. Registration is described in more detail in co-pending U.S. Patent Application Serial No. (Attorney Docket No. SUNlP030).
The regiskation of objects which are to be deployed on the distributed object system for general use (not development) is desc, ;l~d with respect to Figure 12 at 1200. Beginning at initial step 1202, the input files are created for the i'deployed object" at step 1204 in the same manner described above. These are the same input files described above with respect to development objects and clients. The files are compiled and object servers and clients are constructed at step 1206, again as ~ l~.tially described above, except that no renaming of the interface, or file or search paths is pelr~,l..led and no special object file is linked as for 35 development objects.

-At step 1208 the staging areas, areas of memory allocated for storing the installable files associated with the objects, are cleared. For each subdirectory described in the make files, the installable files for each component are copied to the apprupliate staging area and scripts are constructed as described below. This step can be performed using standard techniques.
S At step 1210 the following sequence of operations is pelrc,~ ed. For each interface definition file, a postinstall shell script fragment is genel~tt;d that runs the interface definition file compiler to load an IFR file associated with that interface. This fragment file is placed in an applc.pliate staging area. For each server, a postinstall shell script fragment is generated that runs the server with a special con~llalld to cause installation of the server and its implelllent~lions with the ORB
10 and to create and register any factory objects. In addition, a preremove shell script fragment is generated that kills, holds down and unregisters the server and optionally deletes the associated data factory. These fragment files are also placed in the a~plul liate staging area. In addition, a postinstall fidglllenl is genelaled that creates the dhectoly used for the server's data files and placed in an applupliate staging area. These steps can be pelr~ lled using methods well known 15 to those having skill in the art.
At step 1212, the postinstall file fragments generated as described above are concatenated together along with a script to form a package poslillslall script for each package defined in the make files. This concatenation is pelr(Jlllled in a order such that the fr~gm~nt~ generated from the interface definition files are registered before the interfaces that inherit from them.
20 Preferably, the developer can include a po~linsLall script file or write a replacement file. In addition, for each package a package pl~ uve script is created that includes the above-described preremove rl;lg",~ t~. Preferably, the developer can include a preremove script or write a replacelllent file. For each declared package, a package cont~ining the di~llibuled object having the above-described inhelil~ce ~llu~;lule and which is capable of opel~tillg on the 25 distlibuted object system is then constructed using the provided and gelle~ d package definition files and the installable files in the associated staging area. These steps can be performed using methods well known to those having skill in the art. The sequence of operations then termin~tes at step 1214.
Thus, it will be seen that the present invention provides a method and ~pal~lus for creating 30 and in.~t~lling distributed objects on a distributed object system in which support for the distributed object system is built into the distributed object in a highly lr~spalent manner.
Using the method and apparatus of the invention, objects currently available that do not support the fealules of a distributed object system can be installed on such a system withûut e~l~,n~ive r~wliling of the object's code. In addition, using the present invention pro~l~nllllel~ and users 35 who are not farniliar with distributed objects can develop such objects and/or take advantage of distributed object systems without undue difflculty.

'_ Although the foregoing invention has been described in some detail for purposes of clarity of unders~n(~ing, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims.

Claims (43)

1. A computer-implemented method for creating a distributed object suitable for use on a distributed object system, comprising the steps of:
a) providing i) interface files describing interfaces contained in the distributed object, ii) implementation files describing distributed object implementations, iii) servant class files describing a servant class of object implementations, and b) compiling under computer control the interface, implementation and servant class files to produce compiled header and source files corresponding to said interface, implementation and servant class files, wherein the source files corresponding to the implementation files include template source files; and c) linking under computer control the header and source files with a wrapper class containing functions and services for operating the distributed object on the distributed object system, so that the wrapper class has an inheritance relationship with respect to the servant class wherein the wrapper class is derived from the servant class to create thereby the distributed object.

2. The computer-implemented method of claim 1, wherein the template source files contain a prototypical version of the servant class.

3. The computer-implemented method of claim 1, further including the steps of providing an interface class of interfaces for selected services in the wrapper class and linking the servant class to the interface class so that the servant class inherits from the interface class.

4. The computer-implemented method of claim 3, wherein the interface class is a pure class.

5. The computer-implemented method of claim 1, further including the step of wrapping calls to developer-defined functions in the servant class with wrapper statements.

6. The computer-implemented method of claim 1, further including the step of providing under computer control at least one shared library comprising code used by the distributed object.

7. The computer-implemented method of claim 1, further including the step of distinguishing distributed objects suitable for development purposes from distributed objects suitable for deployment on the distributed object system using a computer controlled discrimination mechanism.

8. The computer-implemented method of claim 7, wherein the step of distinguishing further includes the step of linking under computer control a development object file with the header and source files when the distributed object is suitable for development purposes.

9. The computer-implemented method of claim 7, wherein the step of distinguishing further includes the steps of a) producing under computer control an interface registry file for registering deployed distributed objects with the object request broker mechanism; and b) packaging under computer control the deployed distributed object in a package device when the distributed object is suitable for deployment purposes.

10. The computer-implemented method of claim 1, wherein the computer-implementedmethod is performed on a computer residing on a distributed object system which includes a plurality of networked computers having memories in which reside other distributed objects and which distributed object system further includes an object request broker mechanism and an object adapter mechanism.

11. The computer-implemented method of claim 10, further including the step of providing an object adapter interface class for each interface registered with the object request broker mechanism.

12. The computer-implemented method of claim 11, further comprising the step of registering under computer control the distributed object and the implementations of the distributed object with the object request broker mechanism to enable the distributed object to communicate with the resident distributed objects.

13. The computer-implemented method of claim 10, wherein the services in the wrapper class provide a computer controlled interface mechanism between the methods contained in the servant class of objects and the object request broker mechanism.

14. The computer-implemented method of claim 13, wherein the wrapper class includes object lifecycle services, object request broker and object adapter services, registration services, multithreading services, subobject services, refdata services, reaper services, object reference services and tracing and logging services.

15. The computer-implemented method of claim 14, wherein said lifecycle services include object creation functions, object deletion functions, object activation functions, object deactivation functions, server startup functions, server shutdown functions and server installation functions.

16. The computer-implemented method of claim 14, wherein said registration services include functions for registering an object on said object request broker mechanism, unregistering an object on said object request broker mechanism, and finding a service provided by said object request broker mechanism.

17. The computer-implemented method of claim 1, further including the step of providing persistent data schema files describing persistent data.

18. The computer-implemented method of claim 17, wherein said step of compiling provides header and source files corresponding to said persistent data schema files.

19. A distributed object produced by the computer-implemented method of claim 1.

20. A computer system for producing a distributed object suitable for use on a distributed object system, comprising a) a compiling mechanism for compiling i) an interface definition file including object interface definitions, ii) an implementation file describing distributed object implementations and iii) servant class files of developer-defined object implementations to produce corresponding header and source files; and b) a linking mechanism effective to link the source and header files produced by the compiling mechanism with a wrapper class containing functions and services for operating the distributed object on the distributed object system, wherein the linker is effective to establish an inheritance relationship between the wrapperclass and the servant class wherein the wrapper class is derived from the servant class to create thereby the distributed object.

21. The computer system of claim 20, wherein the compiling and linking mechanisms are effective to produce a template file containing a prototypical version of the servant class.

22. The computer system of claim 20, further including an interface class containing interfaces for services contained in the wrapper class and wherein the compiling and linking mechanisms are effective to establish an inheritance relationship between the interface and servant classes in which the servant class is derived from the interface class.

23. The computer system of claim 20, wherein the compiling and linking mechanisms are effective to wrap calls to developer-defined functions in the servant class with wrapper statements.

24. The computer system of claim 20, wherein the compiling and linking mechanisms are effective to produce header and source files corresponding to input files including interface definition files, implementation files and the servant class files and the linker is effective to link the header and source files with the wrapper class to produce the distributed object.

25. The computer system of claim 20, further including a discrimination mechanism for distinguishing between distributed objects to be used for development purposes from distributed objects to be deployed on the distributed object system.

26. The computer system of claim 25, wherein the compiling and linking mechanism is effective to link a development object file with the header and source files produced by the compiling and linking mechanism when the distributed object is to be used for development purposes.

27. The computer system of claim 25, further including a registration mechanism for registering the distributed object with the object request broker mechanism under computer control an interface registry file associated with the distributed object and a packaging mechanism for producing the distributed object in a package when the distributed object is to be deployed on the distributed object system.

28. The computer system of claim 20, wherein the computer system comprises a computer on a distributed object system including a plurality of networked computers having memories in which reside other distributed objects, which distributed object system further includes an object request broker mechanism and an object adapter mechanism.

29. The computer system of claim 28, further including an object adapter interface class for each distributed object registered with the object request broker mechanism and the compiling and linking mechanism is effective to create an inheritance relationship between the wrapper class and the object adapter interface class wherein the wrapper class is derived from the object adapter interface class.

30. A distributed object produced using the computer system of claim 20.

31. A distributed object suitable for use on a distributed object system, comprising a) a call to a developer-written function contained in a developer-written servant class of objects;
b) wrapper statements contained in a wrapper class of objects, which wrapper class has an inheritance relationship with the servant class wherein the wrapper class is derived from the developer-written servant class of developer-written objects, the wrapper statements including services for supporting the operation of the distributed object on the distributed object system.

32. The object of claim 31, wherein the developer-written servant objects inherit object attributes through an inheritance relationship with an interface class of objects that contains interfaces for selected services in the wrapper class.

33. The object of claim 32, wherein the interface class of objects is a pure class that comprises interfaces to services in the wrapper class.

34. The object of claim 31, wherein the object is located in the memory of a computer coupled with a network of computers that comprises a distributed object system containing distributed objects, wherein said distributed objects communicate using an object request broker mechanism.

35. The object of claim 34, wherein the wrapper class of objects provides an interface mechanism between the methods contained in the developer-written class of objects and the object request broker mechanism.

36. The object of claim 35, wherein said wrapper functions include object lifecycle functions, object request broker and object adapter functions, registration functions, multithreading functions, subobject functions, refdata functions, reaper functions, object reference functions and tracing and logging functions.

37. The object of claim 36, wherein said lifecycle functions include object creation functions, object deletion functions, object activation functions, object deactivation functions, server startup functions, server shutdown functions and server installation functions.

38. The object of claim 36, wherein said registration functions include functions for registering an object on said object request broker mechanism, unregistering an object on said object request broker mechanism, finding a service provided by said object request broker mechanism and finding all services provided by said object request brokermechanism.

39. The object of claim 34, wherein said object is a development distributed object.

40. The object of claim 34, wherein said distributed object is a deployed distributed object.

41. The object of claim 31, wherein said object is contained in a runtime package mechanism installed in said memory of said computer.

42. The object of claim 31, wherein said object includes a spy object device for implementing system administration functions.

43. The object of claim 31, wherein functions contained in said developer-written servant class of objects are wrapped by said wrapper functions.