CA2263571A1 - System development tool for distributed object oriented computing - Google Patents

Abstract

A development tool for building large scale distributed object oriented (LSDOO) computer systems, which systems typically include a plurality of clients (26), a plurality of servers (29), and a distributed object infrastructure (25) for communicating client requests for services to servers. The development tool includes a series of templates (12) providing predetermined object design patterns, a code generator (15) and, preferably, a set of basic distributed services (21). The code generator (15) is arranged to produce, from an object oriented system model (11) created by a user for defining desired server processes (33) to be requested by client processes (32) and incorporating selected ones of the design patterns, a client access layer (27) for each client process, isolating client application code from the distributed object infrastructure (25); a server access layer (28) for each server process, isolating server application code from the distributed object infrastructure (25); and a stub portion (29) of the server application code for implementing each service, including provision for the user to integrate an implementation of server semantics. The set of basic distributed services may include a file replication service (30) for replicating files within the system and a service finder service (31) for the discovery of the services available in the system.

Description

CA 02263~7l l999-02-l6 TITLE
SYSTEM DEVELOPMENT TOOL FOR DISTRIBUTED OBJECT
ORIENTED COMPUTING

FIELD OF THE IN~/'ENTION
This invention relates to distributed object oriented computing systems, particularlv large scale distributed object oriented systems (LSDOO). Such a system has objects associated with many machines, typically machines linked in a computer net~vork, which cooperate to autonomously perform some business function. Guidelines on the size of 0 system contemplated are typically those including some 1 million to 100 million objects, 100 to 1000 users, executing a total of 1000 to ~0000 operations per second on approximately 100 to 1000 machines.

BAC~GROUN~ TO THE IN~/'ENTION
Distributed~ object oriented (OO) technologies offer developers of applications for installation on computer networks many potential advantages in deploying their applications. Object oriented techniques provide a controlled environment in which to manage complexity and change. Distributed computing allows applications to operate over a wide geographical area while providing a resilient environment in the event of a failure in part of the network.
In general terms, LSDOO systems have the potential to provide acceptable reliability for a minim~l cost, allowing scaling by a factor of ten (with the upper end approaching global enterprise systems), support standardized interaction with other business-critical systems and efficiently support operations, not merelv effect data storage.
An example of a kno~n standard for building such svstems developed hy the Object Mana_ement Group, Inc. (OMG), a consortium of software ~endors and end users, is the Common Object Request Broker Architecture (CORBA). The CORBA object request broker (ORB) is an application framework for providing interoperability bet~,veen objects, which may be implemented in disparate languages and may execute on different machines in a non-homogeneous enviror~nent. CORBA is a very flexible architecture allowing the objects to transparently make requests and receive responses within the framework.
Reference may be made to the CO~B,4 2. 0~IIOP Specificatio~l the CORB~ Se~ices Specificatio~ and other rele-~an~ specifications published by OMG.
Whilst CORBA and similar DOO architectures have a wide range of applications~ their complexihy results in high development costs for large svstems. These costs flow first from the problem of assimilating the verv lengthy specifications for these architectures which provide a multitude of possible choices for addressing particular tasks.
and secondlv from the problem of identifying which combinations of these choices provide optimal solu~ions to broader design requirements.

CA 02263~71 1999-02-16 ~urther, re~ ing the benefits of distributed, object oriented technologies is challenging, with many developer concerns to be addressed including:
~ Scalability - how to build systems that scale to tens of machines and up to ten million CORBA objects.
5 ~ Performance - how to build systems with satisfactory performance.
~ Fault tolerance - how to achieve availability for 24 hours of 7 days of every week.
~ Persistence - how to efficiently and securely retain object state in a high performance distributed environment.
~ Management - how to manage non-ccntralized computer systems.
10 ~ Implem~nt~tion - how to contain development, testing effort and risk, while allowing high re-use of software.
European Patent Publication EP 727739 in the name of International Business Machines discloses a prograrnming interface for converting network management application programs written in an object-oriented language into network communications protocols.
Intemational Patent Publication No. WO 97/22925 in the narne of Object Dvnamics Corp.
discloses a system for designing and constructing software components and systems by assembling them from independent parts which is compatible with and extends existing object models. US Patent No. 5699310 in the name of Garloff et al. discloses a computer system wherein object oriented management techniques are used with a code generator for generating source code from user entered specifications. However these earlier disclosures do not describe a development tool and method for building LSDOO systems characterised by desi~n patterns providing the power and flexibility of those set out below.
Glossar~
Unless otherwise specified or apparent from context of usage, the following terms take the meanings attnbuted to them below:
"Attribute": an NState datum exposed by get and (usually) set operations.
"Broadcast Delegation": a delegation to all Confederates.
"Bulk Operation": an operation that accesses a lot (or all of) the NState of an object.
"Client": an application .. ;at requires access to one or more services;
"Cluster": the Peer-Clu - distribution model comprises machines orgaruzed into clusters. Cluslers cooperate as peers and machines within clusters are specialized.
"Collection": an object that references a set of Members that possess some commonality; preferably an unordered set of objects;
"Confederates'': the Collections that forrn a Federation.

CA 02263C?71 1999-02-16 "CORL?A Object": an object for which a client may obtain a CORBA object reference.
"COSS": common object services.
"Dele~ation": one object involving another object to execute an operation.
"Design pattern": a design solution for addressing LSDOO issues that anse in system design.
]o "Directed delegation": delegation to an identified subset of Confederates.
"Distribution Model": describes how machines and data links are phvsically organized to implement a system.
"Explicit Group'': a Group Operation, where the members are listed by identity.
"Factory": an object that creates other objects.
~0 "Federation": a set of Collections cooperating to provide a faster, cheaper or more reliable service.
"Friend": a relationship wherein objects share IState, but appear to have independent NState.
2s "Gateway": a CORBA representation of a non-CORBA environment.
"Generic interface": an interface that identifies underlying problem domain commonality existing between specific interfaces.
"Graceful failure': a system responding to component failure by continuing to perform operations not directlv affected by the failure.
"Group operation": an operation where one basic operation is applied to a number of objects.
"Identitv": an NState datum that has a irnmutable one-to-one relationship with an object.
"Implicit group'': a Group operation where the members are defined by a search predicate.
"IState': the state stored by an object?s implementation.
"Life-cvcle": the process of creating, copying, relocating and destroying an object.
4~
"LSDOO': Large Scale Distributed OO, typicallv a system that has objects onmanv machines that cooperate to autonomously perfoml some business function.

CA 02263~71 1999-02-16 "Member": an object that is referenced by a Collection.
"Natural collection": a Collection that is re~uired to support svstem functionality.
"Normalized object": an object is normalized if the following are all true:
(i) the state of the object does not overlap with any other object, ~ii) the semantics of the object are defined and implemented by the object alone; and (iii) its interface is just sufficient to access all state and change it in 0 any way consistent with the object semantics.
"Normalized system": a system is normalized if all objects in the system are normalized.
"NState": Normalized State, the minimum amount of state needed for an object to exhibit the correct behaviour.
"Object": The OO concept of object, ie. an atom of state (NState) that hasidentity and is accessed through a defined interface. An object is the fundarnental component of a LSDOO system~ which mav be a zo hardware device (such as a printer) or a software application (such as a print manager).
"Object reference": a pointer to an object that has an irnmutable many-to-one relationship to the object.
"OOPL": Object Oriented Progr~mming Language.
"Partition": a physical grouping of objects. where each object is associated with exactly one partition. There is generally a one-one correspondence between a Partition and a set of computin_ hardware.
"Performance collection'': a Collection that improves s~stem perforrnance by providing efficient implementation of Group Operations.
"Replica": One of the IState duplicates of a replicated Object.
"Replication": the duplication of an object's IStatc at several physical locations.
"RDBMS": relational database mana~ement svstem.
"Second class object'': an object that cannot be refer: . d by a CORBA Objec Reference.
"Service'': an abstract provider of functionality, defined by CORBA IDL
4~ interfaces. ( A~ service is typically provided bv logically grouped objects co-operating with one another.) "~ree descent'': a form of recursive Dele(~ation. ~ here the delegates form a tree.

CA 02263~71 1999-02-16 "Worm": a form of recursive Delegation, where the delegates from an ~bi graph.
"Wrapper": an internal interface that protects system components from changes - s and defects in other components, common services and infrastructure.

OBJECT OF THE INVENTION
It is an object of the present invention to provide a development tool for largescale distributed object oriented computer systems which ameliorates or overcomes at least o some of the problems associated with the prior art.
It is another object of the present invention to provide a method for developing large scale distributed object oriented computer systems wnich implements a small number of powerful CORBA usage models, allowing developers to focus on object modeling and implementing business logic.
1S It is yet anotner object of the present invention to provide a system development tool andlor method for large scale distributed object oriented computmg that provldes:
~ guidelines on system modeling using CORBA;
~ a modeling tool for tr~3n~l~ring abstract object models into deployable CORBA
20 interface design language (IDL);
~ a code generator, including code libraries, for generating infrastructure level code for producing CORBA clients, servers, factories and collections; and ~ system management functions for distributed configuration, debugging, ~mini.~tration and performance measurement.
Further objects will be evident from the following description.

DISCLOSURE OF IHE INVENTION
In one form, although it need not be the only or indeed the broadest form, the invention resides in a development tool for building a large scale distributed object oriented 30 computer system, which system includes a plurality of clients, a plurality of servers, and a distributed object infrastructure for communicating client requests for services to servers, said development tool comprising:
(a) a series of templates providing predetermined object design patterns, including -(i) an object identity pattern, facilitating unique identification of each object, (ii) a collection pattern. facilitating the logical grouping of objects having some commonality, (iii) a group operation pattern, facilitating operations targeted at a set of objects, (iv) a friend pattern, facilitating association of one object with another object independentl~v of clients, and (v) a partition pattern~ facilitating physical grouping of objects for performance .. . .. .... .. . ..

CA 02263~71 1999-02-16 purposes;
(b) a code generator arranged to produce, from an object oriented system model created by a user for defining desired server processes to be requested by client processes and incorporating selected ones of the object design pattems~ the following -(i) a client access layer for each client process. isolating client application code from the distributed object infrastructure, (ii) a server access laver for each server process. isolating server application code from the distributed object infrastructure~ and (iii) a stub portion of server application code for implementing each service.
including provision for the user to integrate an implementation of server semantics.
Suitably the development tool further comprises a set of basic distributed services including a service finder service for the discovery of the services available in the system.
If required, the senes of templates mav further include one or more of the following object design patterns:
(vi) a federation pattern, a set of collections cooperating to provide an improved service;
(vii) a unified service pattern, facilitating the optimal choice of a collection from the set ~vithin a federation; andlor (viii) a bulk operation pattern, facilitating multiple operations on a particularlv identified object.
Preferably the object identity is an attribute of an object, is represented usino a structured narne and allows for object replication.
In preferencc. objects grouped into a collection are known as members and 25 knowledge of a collection s members may be kept e~;plicitly. such as in the forrn of a list. or implicitly by the application of a rule.
Preferably the set of objects to which a group operation applies is known as the scope of the gro-lp operation, which scope may be explicitly or implicitly defined.
An explicitly defined group operation is based on an underlyin, operation 30 supported bv objects comprisin~ the service and a parameter to the operation. suitably a list of object identifiers, defines the scope.
An -eplicitl v defined ~roun operation is not based on an underlying operation and a client specif. ;llter is applied to th ob1ects to define the scope of Ille operation.
Suit~ .y hVO objects are friends if thev do not appear associated to clients via3~ the distributed object infrastructurc. but appear associated to one another.
Preferably a partition is a phvsical _rouping of objects, wherein each object inthe system is associated ~ith onlv one partition. ~vhich partition corresponds to a set of computer hardware.
ln preference. ~he collections hl a federation are able to dele~ate opera~ions to CA 02263~71 1999-02-16 each other in order to provide a faster, more extensive or more reliable service.
Suitably~ a unified service is a federated collection wherein a predetermined sub-set of collections is transparent to clients.
The client access layer preferably includes agent classes to access the objects that implement a service and other classes tO represent data structures manipulated by the agent classes.
In preference, the agent classes separate interface code for the distributed object infrastmcture from the client application code and encapsulates an object's identity, interface and the means to address its implementation(s).
lo The server access layer may include service managers for m~n~ing objects with respect to any partitions and allows for the creation and deletion of objects.
The server access layer preferably includes adapter classes for providing access to objects that implement a service.
Suitably the set of basic distributed services further includes a file replication 5 service for replicating hles within the system.
The set of basic distributed services are preferably provided by code libraries.If required~ the system utilizes the CORBA standard, wherein:
(a) the distributed object infrastructure comprises an object request broker (ORB);
(b) the object oriented system model is modeled using CORBA concepts; and 20 (c) the server interface is generated in accordance with CORBA interface design language (IDL).
In further fomm, the invention resides in a method for the development of a large scale distributed object oriented computer svstem. which system includes a plurality of clients, a plurality of servers, and a distributed object infrastructure for communicating client requests for scrvices to servers. said deveiopment method including the steps of:
(a) selecting one or more templates. from a series of templates for predeterrnined object design patterns, which include -(i) an object identity pattem, facilitating unique identification of each object, (ii) a collection pattern, facilitating the logical grouping of objects having some commonality, (iii) a group operation pattern, facilitating operations targeted at a set of objects, (iv) a friend pattern, facilitating association of one object with another object independentlv of clients, and (v) a partition pattern. facilitating ph~sical grouping of objects for perforrnance purposes;
(b) creating an object oriented svstem model for defining desired server processes to be requested bv client processes. which model incorporates selected object design patterns: and (c? generating. from the object oriented svstem model~ code modules for the following -(i) a client access la~er for each client process. isolatinc~ client application code CA 02263~71 1999-02-16 from the distributed object infrastructure, (ii) a server access layer for each server process. isolating server application code from the distributed object infrastructure, and (iii~ a stub portion of the server application code for implementing each service, including provision for the user to integrate an implementation of server semantics Preferably the method includes the further step of providing a set of basic distributed services including a service finder service for the discovery of the services available in the system.
Preferably the series of templates available for selection in step (c) may o further include one or more of the following object design patterns:
(vi) a federation pattern. being a set of collections cooperating to provide an improved service, (vii) a unified service pattern, facilitating the optimal choice of a collection from the set within a federation, and/or (viii) a bulk operalion pattern, facilitating multiple operations on a particularly identified object;
If the object identity pattern is selected, representing the identity attribute of an object by using a structured name, which attribute may also allow for object replication.
If the collection pattern is selected, referring to objects grouped into a collection as members and keeping knowledge of a collection's members either explicitly, such as in the form of a list. or implicitly by the application of a rule.
If the group operation pattem is selected, referring to the set of objects to which a group operation applies as the scope of the group operation. which scope may be explicitly or implicitly defined.
If the friend pattern is sclected. arranging friend objects such that they do not appear associated to clients via the distributed object infrastructure. but they appear associated to one another.
If the partition pattern is selected. assigning a physical grouping of objects to the partition wherein each object in the system is associated with only one such partition, which partition corresponds to a sct of computer hardware.
If the federation patlern is selected, allowing the collections to delegate opcrations to each other in order to ~ ~ ide a faster. more extensive or more reliable service.
If the unified service, ;~. rn is sele 'd. arranging a predetermined sub-set of collections within a federated collection to be Iransparent to clients requestin~ unified '~ service.
The step of generating a client access laver preferably includes the further step of generating agent classes to access the objects which implement a selvice and other classes to represent data structures manipulated bv the agent classes.
The step of ~generalln~ agent classes preferablv includes separating interface CA 02263~71 1999-02-16 code for the distributed object inf~astructurc from the client application code and encapsulating an object's identity. interface and providing means to address itsimplementation(s) .
The step of generating a server access laver may include the provision of service mana~ers for managing o~jects with respect to any partitions and facilitates the creation and deletion of objects.
The step of generating a server access layer preferably allows for adapter classes to provide access to objects that implement a service.
The step of providing a set of basic distributed services may further include 0 the step of providing a fiie replication service for replicating files within the system.
In another form the invention resides in a large scale object oriented system built using the development tool or development method set out in any of the preceding statements, wherein the object oriented system includes a cornrnon ~lmini.stration interface.
Suitablv the cornrnon ~lministration interface facilitates remote manaEement of all unified services in the svstem. including the provision of test, enable. disable~ backup and restart functions.
Most suitably the a(lministration interface also supports a set of attributes for which each unified service may be queried, including one or more of version nurnber, copyright inforrnation, status, host machine, process identity or like attributes.
BRIEF DETAILS OF THE DRAWINGS
To assist in understanding the invention preferred embodiments will now be described with reference to the follo~ving drawing figures in which:
FIG.l is a diagram of a computer network over which objects may be distributed in a large scale OO system.
FIG.2is a diagram of usage model for the development tool of a firs~ embodiment;FIG.3 is an overview of the architecture of the first embodiment;
FIG.4 is a diagrarn illustrating the graph of a Collection design pattern;
FIG.5 is a diagrarn illustrating a Collection implemented using a Pull model;
FIG.6 is a diagrarn illustrating a Collection implemented using a Push model;
FIG.7 is a diagram showin_ a Group Operation delegating to individual operations:
FIG.~ is a diagram showing a Group Operation delegating to another Group Operation;
FIG.9 depicts an example of the Friend desi~n pattern;
3' FIG. 10 depicts a Peer-Clus~er Distribution Model wherein Clusters relate to the Partition desi~n pattern;
FIG.ll shows a Federated Collection;
FIG.l~ illustrates an example of a Transparently Federated Factory;
FIG. I ~ sho~ ~s an arranQement of Federation interfaces existin~ between two . . ., ~ , .

CA 02263~71 1999-02-16 Confederate objects;
FIG. 14 illustrates an example of a Unified Service pattern;
FIG. 15 illustrates a typical client/server scenario involving Unified FederatedServers;
FIG. 16 depicts the operation of an object identifier (OID);
FIG. 17 shows the relationship between the Adaptor and Impl classes in a server process of the embodiment; and FIG. 18 shows the interaction between tlle ServiceLocator service and a ServiceManager.
DETAILED DESCRIPTION OF THE DRAWINGS
Overview FIG. l shows a computer network on which objects of an OO system may be distributed. The networl~ may include computing machines, such as computer terminals or PCs l and file or print servers 2 interconnected to a network backbone 3 or other 1~ communications infrastructure for sharing instructions and data with one another. The computing machines may be located at widely spaced locations 4, 5 and 6, whereby branches of the networ}c backbone may be interconnected b~ a s~A~itching device, such as router 7. In this context, an example of an object might be a particular printer 8 and an example of a service might be a file storage function.
Referring to FIG. 2, integers of the system development tool l 0, as it might beimplemented in the present embodiment, to produce a system compliant with the CORBA
standard is shown. A working knowledge of CORBA is assumed in the following description, otherwise reference should be made to the CORBA specifications mentioned above. The developer first conceives a logical object model l l using a common object modeling technique ~ith the assistance of a design guide l~. In the embodiment the deveiopment tool further includes a model wizard l 3 which assists the developer to specify a CORBA system model 14 expressed in a universal modeling language (IJML). In other embodiments the system model may be produced by some other tool, such as another object oriented computer aided software engineenng (CASE) tool. or the model wizard might be 30 initialized w ith a pre-existing UML model or other OO model.
When the developer is satisfied that the CORBA system model is correct~ the code generator in the form of a code wizard l 5 takes the S~rt-m model and produces:
- the CORBA interface design languag ~ (IDL) modui~
- an implementation for the services 17. including h ~i~s for the developer specified 3~ object semantics 1 8; and - a simplified client interface l9 to the services.
Suitably the devcloper l0 codes object semantics IS in an appropriate language such as C+l, which is convenientlv the lan~ua(~e used by the code ~izard for the simplified client interface l9 in the embodiment. Other embodiments mi(Jht use Ja~a. SmallTall~ or lil;e CA 02263~71 1999-02-16 languages suited to OO sofr~vare. A set of basic distributed services is also provided by the development tool library 21, which includes other comrnon functions.
A CORBA compliant object request broker (ORB) ~0, the environment within which the system operates, is also to be supplied. Commercially available products such as Visigenic's "Visibroker" or Iona Technologies' "Orbi~;" are suitable for this purpose.
It is envisaged that appropriate tar~et operating systems will be Sun Microsvstems~
"Solaris", Hewlett Packard's "HPUX' or MicrosoR Corporation's "NT" or any other suitable multi-tasking OS.
The executables for the servers 2~ and default client 23 are then produced by 0 linking the generated modules 16, 17, 19 and developer hand coded modules 18 together with the externally sourced ORB components 20. The developer can extend or modify any of the code wizard output files in order to modify their initial choices or to use CORBA
concepts that are more complex than those supported by the development tool. Forconvenience, the svstem development tool 10 of the embodiment mav also be referred to ' hereinafter as "ORBMaster".
Architecture FIG. 3 shows a typical client/server view of a generated service generated by the embodiment. Key aspects of the ORBMaster architecture shown in this diagrarn are the Client Application Code 26, the Client Access Layer 27, the Server Access Layer 28, the 20 Server Application Code 29, and the basic services, which include the File Replication Service 30 and the Service Finder Service 31. It will be appreciated that the client process 32, the server process 33 and basic services communicate via the distributed object infrastructure. in the form of the ORB 25.
The ORBMaster architecture allows service developers to concentrate 2~ development effort in the areas of application code (Client Application Code and Server Application Code). It does this by providing some useful distributed services (file replication and service finding), code of some useful design patterns (group operations, unified service, etc., as discussed below) The architecture also provides client and server access layers (CAL and SAL) which separate ORB dependent code from application specific code, and 30 code which implements distribution aspects of the service from code that implements the other service semantics.
The most fundamental component in the OO architecture is the object. In the client/ser~rer paradigm~ groups of objects cooperate to provide services~ and services are accessed by client applications. The ORBMaster architecture. in contrast to CORBA, relies 3~ on the concept of objects that have identity, support interfaces and have implementations.
Identitv is represented using structured names that are the attributes of the objects; interfaces are defined using IDL ~nd implementations are addressed using CORBA object references.
Accordingiy, ORBMaster obiects are !ust first class CORBA objects with the addition of identit~ . Identitv is implicit in the design pattems described below.

....

CA 02263~71 1999-02-16 W O 9~/58313 12 PCT/AU98/00464 There is a many-to-one relationship between naming attributes and objects.
Naming attributes are read-only attributes of objects. One of the naming attributes of an object is designated as its ObjectIdentifier (OID). There is a one-to-one relationship between OIDs and objects. OIDs are used both as the database key and as the object_key (within the CORBA Interoperable Object Reference (IOR)) for the object. Object references either address the current implementation of an object or address nothing. That is, an object reference for one object can never subsequently be used to address a different object. Object references may change when an object moves, they therefore cannot represent object identity. As a consequence object references should not be persistified by clients (OIDs lo should be used instead). The architecture allows objects to have more than one implementation, that is~ for objects to be replicated.
A service is functionality, logically grouped to meet some distinguished business need. A service is implemented by a group of related service provider objects.
Services are identified by OrD (i.e. name). A set of ServiceManagers that all support the 1~ same unified service are effectivelv a single replicated object (with service name as their OID). There are generally two kinds of service provider objects, as follows:
ServiceManagers - provide the operations of the service which deal with distribution management, group operations on collections of component objects, life-cycle management of component objects; and component objects - the smallest separately identifiable components of the statemanaged by the service. Both ServiceManagers and component objects are implemented within sen~er processes. The implementation of ServiceManagers and component objects are separated into the Server Access Layer (SAL) and the Ser~er Application Code as shown in FIG. ~. The SAL is described in more detail in the section entitled 'Server Access Layer' below.
One aim of the system development tool at least with respect to client applications, is to provide full access to the services without the need to understand the CORBA architecture. The ORBMaster Client Access Laver (CAL) seeks to achieve this aim. The CAL separates application code from code needed to access the objects that 30 implement the services. The interface between the CAL and the application code does not expose anv of the C classes generated from the ~nterface Definition Language (IDL) for the service. The CAL is discussed in m ore detail in the section entitled 'Client Access Laver' belo~v.
Interface This section contrasts the role of an interface in LSDOO with OOPL
interfaces. such as C++ header files. The role of an interface is to offer a definition of a service. The role of an implementation is to implement the service bv acting on the object's state to perforrn the defined operations. A developer needs a concept of object state to use the service. Admittedly. this mav not be the actual state used in a real implementatiom rather~ il CA 02263~71 1999-02-16 W O 98/58313 13 PCT/AU981'~~161 is the concept of "NState" the Normalized state that a reference object would have. ~Tithout the concept of NState~ the object's operations appear disconnected. For example. consider a basic name server:
i~lte~face NameSe~erl'' booleall udd(i-2 stri~ anZe. i)l Objec~ ~la~7ted boolea~l delete(i)l stri~lg name);
Objectfi)ld(in stri~lg ~lame), ,,1, This IDL precisely specifies the syntax of the interface. The token names imply the ]o operation semantics. AssDg, for example, that the add() operation is associating a 'name' with a 'named'. If that association is valid (according to some set of rules), the return result will be true. The single return from find() indicates that narne must be unique. Comments can increase this underst~n~lin~. It implies inter-operation semantics. It could be assumed that the find() operation will retum objects that match name and have suffered more successful add() operations than delete() operations. This understandin~ can be augrnented through comments that describe NState. It says nothinc~ about qua]ity of service. That is~
how fast, how many, or how reliable?
Failing to expose an ob~ect's NState makes the interface unusable as the operations have no interconnectedness. As an overreaction to RDBMS, OO designers have 20 traditionall~ gone to great lengths to avoid discussing object state regarding this as merely an implementation issue. This reticence validly applies to implementation state (IState), however NState must be discussed. Moreover NState is not an amorphous blob~ it has structure. One useful NState concept is that of Attribute. An Attribute is an NState datum which has an operation to ~et and usually set its value. Getting an Attribute does not change " the ~State. Setting it will either chan~e its value to that proposed or. if it would violate the object semantics. fail. Setting one Attribute changes no other parts of the NState. A special type of Attribute is the reiatio~Z this is an Attribute whose tvpe is Object reference.
Another special type of Attribute is a name this is an Attribute that has a many-to-one relationship with an object. A special type of name is a ~el this is an immutable narne. A
30 special type of key is identitv this is the key that has a one-to-one relationship with an object.
NState that is not exposed as an Attribute will be cxposed throu~h operations consta~
operations are desi~ned to leave NState unchanged.
The concepts of NState. Attribute. relation. key~ name~ constant operations and qualitv are too imponant to the functionalitv of applications to avoid in interfaces.
3~ However, none of these concepts are intnnsical]v expressible in CORBA's IDL grarnmar.
The IDL attribute is close~ but is sub-functional as it cannot support user defined exceptions.
Therefore. conventions must be de-~eloped~ published. and consistently applied to encode these concepts in IDL. CORBA does specifv an Interface Repository (I~) service. However.
this service has a ~erv small role because it is solelv a s~ a~- ~eposilo)~ it has no ~ ay of 4~ expressin~ anv of the other complexities that compnse an interface. The IR is probabl~

CA 02263~71 1999-02-16 solely useful for Gatewavs and rudimentary Browsers. that is~ things which have no concept of a service beyond that of syntax.
Desi(Jn Patterns The system deveiopment tool of the embodiment provides an architecture for building distributed applications based on CORBA. This section describes a number of ORBMaster design patterns. which are templates for designing systems. Each pattem addresses one or more LSDOO issues. For further details of design pattern concepts see Gamma, E. et al.; Desig7ls Patterns, Addison Wesley, New York, 1995 and Mowbray, T. J.
et al., CORBA Desigr~ Patterns, Wiley, 1997. The patterns discussed below are particularly 10 useful and find important roles in servers constructed with the assistance of the system development tool . The developer can selectively apply tlle design pattems to system design as indicated by the design guide 12 and the logical model l l, whilst focussing on the patterns that address the system's most pressing business priorities.
~ Collection Pattem ~5 A Collection is an object that references a set of objects possessing some cornmonality that addresses issucs of performance and system modeling. This pattern works with the Friend and Federation pattems described belo-v. A Collection is an object that references a set of Members. The Members are objects that have some form of commonality and it is this that the Collection manages. The following are examples of Collections:
20 - a Name server represents a set of objects, each of which has a name. thus the Collection supports search by name;
- a Topology server represents a set of objects, each of which has relations. Ihus the Collection supports search-bv-relation;
- a COr~BA-IP ~ateway consists of objects that represent interface protocol (IP) 2~ concepts and a Collection that represents the set of IP objects. thus the Collection suppons IP-type operations, such as find the object corresponding to a _iven IP address; and - an Error log is a Collection of error objects, thus the Collection supports the life-cycle of error objects, their retrieval. and related statistics.
~ A Collection always knows its Members. It may keep this knou~led~e 30 explicitly, for example. as a list of the Members object references or implicitly via some rule~
for example any object with an IP address matching 123.2'.*.*. A Member can be a part of multiple Collections for example, a Pr;.- ~er object mav be ~ ~ of a name server Collection.
an inventory Collection and a IP object .,.tewav Collection. . he knowledge a Member has about its Collections can vary. Some Mcmbers have a ti_ht relationship with their Collection }~ they know its identity and are designed to inter vork with it, for example, gateway members.
Other objects may not be cognisant of who. if anyone, is collecting them. Such objects ma~
support func~ions that easilv allow them to he collected. such as life-cvcle and state-chan_e noti fications .
Collection is Ihe most pervasive LSDOO pattem and is highly likely to be CA 02263~71 1999-02-16 W O 98/58313 ~5 PCT/AU98/00464 used in the design process. In an RDBMS system all the data is available in tables for you to access via a simple query language. In contrast a typical OO system starts with an initial object, this will reveal other objects, and those objects still others, until all the objects in which you are interested have been discovered. Any objects that are disconnected from the ~, relation graph are unobtainable. With reference to FIG. 4, the root of the graph is the initial object reference 35 you obtain from the ORB using a statement such as CORBA::resolve_initial_references(). The Collections are the non-leaf objects 35. 36, 37 and 3~ in the graph illustrated in FIG 4.
A major function of tradition OO modeling is identifying the Collections.
10 Such identification and the techniques for doing it are similar for ~SDOO. The following are cornmon situations in which reveal Collections in an object model - attribute searching, for example, find the printers which are out of paper;
- group operations, eg. find printers which are off-line and set them to on-line;
- naming, eg. find the object with the IP address 12.34.56.78;

5 - containment relationships, eg. return a list of the printed circuit boards in the equipment; or - connectivity, eg. find the least-cost path connecting two end-point objects.
Collections may return pointers to some of their members typically modeling searching, naming or containment, return some NState of their members analogous to table 20 look-up, perform operations on their members (active Collections), manage the life-cycle of their members such as cascade delete. You can apply the Collection pattern in combination with other OO concepts. Many Collections have non-Collection aspects, for example, a printer object may be a Collection of its component objects as well as implementing the printer function. More examples of combining Collection with other OO concepts are:
~5 - the Federation pattern, which allows Collections to cooperate in answenmg more wide-ranging queries;
- the Friend pattern, as discussed below;
- the Factory, wherein the combination of Collection and factory has an efficient implementation see further below; and 30 - Gateway, wherein a gateway to a non-CORBA environment usually has a Coilection that represents the foreign environment as a whole, and individual objects that represent the forei~n concept of object.
The interface to a Collection has operations which provide the Collection s functionality, for example. find members by name; has some operation to add and remove 3~ members (gateway/Collections are a possible exception); usually supports Federation; and supports cancellation and the incremental return of results~ if results are large or responses slow. There are a number of approaches for addin~ and removing members. Some useful ones are a Factorv if a Collection is also a Factorv. everv object created bv the Fac~ory is automatically a Member: offer a Collection supports an add member and remo~ e member CA 02263~71 1999-02-16 operation; Gateway if a Collection is a Gateway into a foreign domain. membership of the Collection is usually expressed in that domain. For example, installing an IP router will cause membership of the IP Gateway Collection with the corresponding net mask.
Building efficient and flexible Collections is a challenge, scale is the nemesisof the Collection. The problem is how the Collection is able to maintain enough of its members' state to efficiently execute its operations. For example, a Pnnter Collection that support return a list of printers that are faulty could execute that operation either by polling each printer (which is slow if there are many printers) or by searching a local cache of printer state (which requires the cache to be kept in synchronism with the printer state). The Friend 0 pattern provides one solution to Collective NState a Collection that is a Friend of its members can quick~y access their IState. For exarnple, finding the printers whose manufacturer=HP is easy if the printers IState is stored in an RDBMS. The Friendrelationship has some disadvantages that are discussed in the friend pattern.
Non-Friend Collections must m~int:~in a list of Members. This is enough to support the pull and push data sharing models, as shown in FIGS. ~ and 6:
- the pull model 40 requires the Members 42 to have a State interface 43 that allows the Collection 41 to access their NState as required. (The pull model can be used to maintain a cache, delegate on demand, or execute collective operations.) - the push model 45 requires a Collection to have an Offer interface 47 that can be used 20 to update the collective NState. (The push can come from either the Member 48 or a third party).
The push model is easy to implement from the Collection's perspective, at the expense of client complexity. The pull model is more Member-friendly, at the expense of the Collection. Delegation is usually slow and caches are complex to maintain using the pull model. Collections can be difficult to design and build and they tend to pervade design.
therefore reuse of standard Collections should be considered. Whilst custom interfaces may be designed, they should be implemented using standard coded implementations.
Candidate standard Collections are as follows:
- Name Server for any Collection which has onc or more globally unique kevs and 30 returns the corresponding object, for example, an rP gateway which converts an IP address to an object reference;
- OMG compatible Tra~ r for any Collection which selects one object from many, based on attribut - s that rarely ~ ,ange for exarnple finding the best printer;- OV Teie. ~ Topology l'~r any Collection where one object establishes some form of 3~ relationship with another object, for example the relationship between owners and owned objects. There are few good implementations of standard services at the moment. which somewhat limits this approach. Moreover. a standard solution will always be slower than a custom built one.
~ Bulk Operation (or Natural Collection) Pattern CA 02263~71 1999-02-16 W O 98t58313 PCT/AU98/00464 A derivative of the Collection pattern~ which can be referred to as a Natural Collection~ implements Bulk Operation. Multiple operations on a particu}arly identified object are considered to be Bulk Operations. A Natural Collection is a Collection required for a Normalized system model. Natural Collections are Collections that are required to implement the system's functionality, they are part of a Norrnalized system.
When designing an LSDOO system in common with any OO system, you start with an abstract object model. This is a model that captures the logic of the system, without being polluted by implementation issues. You then map the abstract object model onto the particular implementation technology, in this case CORBA. Natural collections are 0 a mapping of the abstract concept of collection. It is likely to be difficult to recognize the Natural Collections for a system, as they result from traditional OO modeling. Considered in object oriented pro~ramming language (OOPL) terms, there are some Natural Collections that may not reco~nize in an LSDOO system; these are:
- Many OOPLs have the concept of class data~ for example, C~ or Java static member functions and data. DOO does not have this concept. You should explicitly mode} class data using Natura} Collection objects.
- The OOPL concepts of construction, for example, the C~ and Java new() operators, are global operations not performed on any particular object. In DOO the new operation must be executed on some specific object typically a combined Factory/Collection object. When 20 you perform event traces or CRC to test your object model? be very careful to exarnine how you found each object and what you used to create it. You must be able to trace each object back to the initial Object Reference you get from the ORB, that is, using the CORBA:.resolve_i~2itial_refere~1ces~) statement.
Natural Collection interfaces expand on the interface structure described for Collections. The following themes often arise in l~atural Collection functionality:
- lookup by narne for details of what constitutes a name. see thc discussion of the role of Interface, above;
- search for objects conforming to some predicate formed from the object s Attributes;
- object life-cycle operations, particularly cascade delete; and 30 - collective themes specific to your project possible examples are path-selection, propagation. and best-choice. A comrnon interface expression should be developed for these common themes. Here are some examples and caveats:
- Name your Collection interfaces predictably for example~ a collection of Xs is called XCollection.
3~ - There should be consistent support for Bulk Operations. notifications, and the like.
- Look for combining Performance Collection operations with your Natural Collection.
- Use exceptions carefully. For example "Object not found" is rarely an exception condition. i~ is an expected outcome of searchin and name lookup. A recurrent theme of Natural Collection interfaces is the operation that returns a list of objects typically search CA 02263~,71 1999-02-16 operations. There are several options for representing the returned objects:
- Return the object reference if there are not too many and your typical client will not immediatelv make a 'get attributes' call on each of the retumed references.
- Retum object Identity plus Attributes, if that is what vour typical client needs and the Attribute size is not too big.
- Return object Identity if there are many objects.
If you return Identity, you must provide a Group Operation for converting Identity to Object Reference. If you do not, you are implementing non-CORBA compliant or Second class objects. In implementation. Collection interfaces may show a great deal of similarity (list o return, cancel, incremental result, Federation and the like). This is all 'house-keeping' code that you should wrap on the client and server sides.
~ Group Operation (or Performance Collection) Pattem A further derivative of the Collection pattem. which might be referred to as a Performance Collection. implements Group Operations. Opera~ions that target many objects rather than just one are considered to be Group Operations. The effect of a Group Operation is the same as repeatedly executing a single operation. There are two forms of group operation, Explicit and Implicit:
- an Explicit group is where the client lists the target objects for example, return the status attribute of the objects referenced by this list of objects; and 20 - an Implicit group is where the client specifies a membership condition and the group consists of all objects matchIng that criteria for example, execute self test on each object that has status faulty.
Performance Collections do not arise from the object modeling process. They arise from a dilisrent search of a svstem's dvnamic behaviour. using techniques such as event.
2~ There are h~o conditions required for a Group Operation to be worthwhile first clients must be interested in the planned groupings and secondly the group operation must be sigruficantly faster than the corresponding single ol~erations. The factors that make an worthwhile explicit group include:
- the clients must hold a list of references you need to consider how that can happen;
30 (The obvious way is that a client is given a list of object pointers by some operation. such as a search operation. A more subtle way is a client progressively accumulating individual pointers~ .
- the clients often perform the exact same opcratioi~ on each l~ect in the list; (~or example~ a ciient wishes to perforrn the test operation on many of pnnters to which it holds pointers).
- the ~roup operation must be faster than the single operations. (This depends on issues discussed in lnterface. A rule-of-thumb is that single operations returning less than 2kb of data are candidates for group operation).
The factors that make an interestin_ implicit (group are as follows:

CA 02263~7l l999-02-l6 - some Natural Collection should offer an operation that takes a membership criteria and returns a list of object pointers typically some forrn of search operation;
- the clients often perforrn the exact same operation on each returned objecl; and - the ~group operation must be faster than the combined search and single operations.
All implicit group operations meet this criterion. except for e~treme cases.
An important decision on explicit group interface design is how to point to the target objects? A CORBA Object Reference is a poor choice because it is slow to marshal, and hard to efficiently delegate (see below for discussion of the Federation Pattern). Some key attribute is usually a good choice. A Group interface should correspond to its underlying 0 single operation interface. To aid the developers and maintainers of a system, a predictable correspondence is desirable. For example, the single operation:
Result X::M(in_args, ol~t_args), would correspond to the explicit Group Operation:
sequence~esull >XCollectio~l . :M(sequenc~<Xid>. in_args, sequence<o2lt_args>).

A mapping between the exceptions raised by the Single and the Group Operations should be defined. Generally. the Group Operation should not raise user exceptions as it will be unclear exactly to what an exception corresponds.
Irnplicit Groups can suffer population explosion if the Collection has N list returning operations and its Members have M Single operations, there are N*M implicit Group Operations on the Collection. This can be reduced to N+M by getting all the list-returning opcrations to return object Identity; and providing Group Operations on a sequence of object Identities.
~s A Performance Collection is far more effective w}len its Members are friends of the Collection. However~ there are certain caveats of the Friend pattern. Friend u ill allo~
you to make these speed improvements:
- for group size N, you will save N- I ORB round trips approximately 5(N- 1 ) ms;
- if the Group Operations use object Identity rather than object reference, si~rnificant time will be saved in marshalling references, approximately N ms; and - if the IState is held in an RDBMS, you will get substantially faster operation using bull; database operations. It is likely to be advantageous to Federate any Perforrnance Collections. The general approaches to federated delegation are discussed below in relation to the Federation pattern. However there is a special issue in dele~ating group operations.
3~ Group operations should not dele~gate to a set of single operations as shown in FIG. 7.
inefficienc!. Rather group operations should delegate to group operations as depicted in FIG. ~, which is more efficient. The initial collection breaks up the group into a set of groups. each targeted to exactly one implementing collection. This should ensure that group operation performance is maintained.
40 ~ Friend Pattern CA 02263~71 1999-02-16 One fundamental property of an object is encapsulatio~t~ that is. the object state is available through a published interface only. Unfortunately. accessing encapsulated objects through a CORBA interface for current CORBA implementations is a relatively slow operation, typically allowing only a few hundred operations per second. The friend pattern 50 relaxes the strict encapsulation model as depicted in FIG. 9. Two objects 51 and 52 are friends if they appear to clients to be encapsulated 53. but do not appear encapsulated to each other 54. Friend is a useful pattem because the interface through which the friends cornmunicate is designed to be faster or richer than a published CORBA interface. Friend objects share IState for perforrnance, but do not share NState. They address perforrnance 0 issues and work with the Collection and Factory pattems.
An example of Friend behaviour is a Printer Collection that implements 'return printers that are off-line' by accessing the database in which the Printer objects store their IState. Friend behaviour need not be symmetrical. Using the example above, the Pnnter objects may never access the Collection IState. An ohject can be a friend of many objects of many types. If objects are implemented by the sarne process, they can share IState stored in memory. If the objects share the same dis~, they can share IState stored in a database. Formally, Gateways and their members are inherently Friends the friend interface is the foreign domain. This discussion avoids this rather obvious case and instead focuses on where Friend is used for performance reasons.
Friend is an important pattern in extracting reasonable performance from LSDOO. This is because a friend interface can operate hundreds of times faster than a CORBA interface, while the overall system retains its essential OO character. Because Friend conflicts with pure OO concepts, its application should be limited to areas ~vhere it adds a si~nificant performance benefit. Scarch operations on Natural Collections using the pull state model. and all operations on Perforrnance Collections will be sigr.uficantlv faster if the collection and members are friends. Without Friend, these operations have either simple, inefficient implementations or complex, efficient implementations. With Friend, simple, efficient implementations are possible.
If one person is the solely responsible for implementation of the objects in a 3() given system, then the ~iend concept will not be a limitation at all and the system will look OO and pure CORBA from without. If other developers are expected to implement some of the objects in the syslem. then those points of integration must also be pure CORBA. that is~
not rely on Friend relationships. However it is rarely necessary that every object in your svstem be re-implementable independently of every other.
A group of objects that must be implemented together is the concept of extensibility boundary. Outside the boundary objects can be replaced at will, inside the boundary there are restrictions. By analogy, consider the hardware of a printer-PC svstem.
The pnnter is outside of the extensibilitv boundary of the PC. therefore there is a published interface and any conforming printer implementation is acceptable. Consider now the toner CA 02263~7l l999-02-l6 cartridge in the printer even though this is an encapsulated unit, it does not h~ve a published interface and cannot be replaced with a different implementation. The toner cartridge is inside the extensibility boundary of the printer. Presumably the printer manufacturer could have negotiated and conformed to a toner cartrid_e industrv standard, however the value of extensibility at that level of granularity was not worth the costs. In LSDOO terrns. the printer and toner cartridge are friends, the printer and PC are not It is as unrealistic for e~ery object in an LSDOO system to be independently re-implementable, than it is to expect every component in a printer to be so. Friend is a candidate implementation for objects ~vithin an extensibility boundary.
The external interface to objects that are friends should not be influenced by that fact. That is, from without, the friend objects should appear as pure CORBA objects.
The interface between the friends is discussed in relation to implementation belo~. Even though the objects appear to be pure CORBA objects. there are 3 three further levels of independence:
Dependent, an object is Dependent if it has NState that can not be set to all valid values via the published interface. The term Dependent implies that there is some non-CORBA access to the object, this may be from some foreig~n domain or from some other object via a friend interface;
- Weak Independence, two objects are Weakly Independent if every operation could, in 20 principle be done though a published interface. In practice, that implementation may be impracticably slow; and - Strong Independence, two objects are Strongly Independent if one may be replaced with a ne-v implementation without changing the system ' s function or perforrnance.
Typically, objects within an e~;tensibility boundary are Dependent~ objects outside the extensible boundary are Stronglv Independent.
There are many techniques for implementing the Friend interface. Some exarnple approaches are:
- One object can store its state in an RDBMS. and the other object can access the database. This approach is attractive for implementin~ search operations in Natural 30 Collections, or Group operations in Performance Collections.
- The objects may share in-memory state. either in the same process, or shared memorv bet~een processes.
- The obJects can use a CORBA interface. and achieve high speed by linking the client and server into the same process. Note that this is still a friend interface. it does not support Strong~ Independence.
Weali Independence is achieved throu_h interface design. Strong Independence requires interface desim and implementation design. Two approaches to Strong Independence are:
- Add. the Collection supports an add() operation which allo~vs the addition of non-,.. " .. . .

CA 02263~71 1999-02-16 friends. The Collection is therefore a mix of Friends and non-Friends. Assuming vou want to provide egalitarian quality of service, an efficient non-Friend implementation has to be built, thus vou can drop the Friend pattern altogether.
- Federate, the Collection supports a Federation interface which allows a foreign Collection to participate in implementing your Collection's operations. This provides Strong Independence and retains your efficient and simple Friend implementation. However, the foreign developer now has the burden of implementing part of the Collection as well as Members. In summary, although there appears to be two approaches, the "Add" approach is considered pointless.
An analogous situation is where IP routers externally expose IP ports, however, in~ernally and between themselves they need not use IP protocols. As discussed above, the Friend interface gives two objects a privileged relationship. This privilege is not available to other developer's objects, therefore the extensibility of the system is reduced.
~ Partition Pattern (or Distribution Model) s A Distnbution Model describes how objects map onto machines, addressing the issues of perforrnance, reliability, and manageability within a system. CORBA allows clients to be unaware of the location of objects the ORB guarantees that the system ~ ill work where ever objects are located. However, the location substantially affects the svstem s performance and reliability. A Distribution Model describes the following:
20 - what machines exist in the system, that is, their type, number, and purpose;
- which objects reside on which machines~ that is, how Collections, Members, andReplicas are distributed over the machines; and - what data flows exist, that is, how much data is transferred between each pair of machines. .~ Distrihution Model exists as either a Meta-model or a Deployment model. The Deployed Distribution Model is that implemented bv a particular customer. The Meta Dis~ribution Model is the complete set of Deplovment models allowed for by the system deslgner.
Both system and component designers need a Meta Distribution Model.
System designers need a detailed model one that accommodates the needs of tar_et users.
30 Component designers only need a general model but with enough detail to demonstrate that the component is usefully deployable. System developers have an obligation to end-users to ensure that they ually design their Deployment Distribution Modei users withou~ a large system backgro- will not expect to do this themselves. Success without a Dis~nbution Model is as like I randomly connecting cables~ hubs. and routers would be in producing a 3~ LAN.
Component developers should expose CORBA interfaces to allow the Meta-model to be instantiated as a Deployment model. System developers can either use CORBA
or foreign interfaces~ such as command line or configuration files. The following implementation issues should be considered when desi~nin~ a Distribution Model:

CA 02263~71 1999-02-16 - the smallest and largest system size including a post-deployment growth path;
- data flows in parbicular identifying and exploiting cohesion between clients and servers;
- a system adrninistration strategy including backup, software upgrade~ and machine 5 maintenance; and - the effects of machine and network failures. Both Meta and Deployment models need to consider these things the difference is in generality. Meta-model design must interact with the system object model and interface design to exploit Collection, Federation. Replication and Friend patterns. Deployment model design must select machines, network bandwidth, O machine location, system configuration, and end-usage. It is not necessary to be too ambitious for many reasorls, it is unlikely that the largest deployed system will be more than ten times larger than the smallest.
The abstract goal of the Distribution Model is to reduce the cost of ownership.
Apart from the obvious cost of ownership issues such as hardware, software~ and the like~ a s large component will be ~rlmini~tration. Rules of thumb for ~dmini.stration costs are. in a first order approximation the cost is proportional to the number of database machines~ whilst in a second order approximation the cost is proportional to the number of things that have to be configured. The Distribution Model for many current systems is one server machine with several UI machines. It is reasonable to expect CORBA systems to deploy on tens, to 20 possibly hundreds, of server machines. Beyond this level surprising difficulties may well be encountered.
FIG. 10 illustrates an example of one useful Distribution Model. the Peer-Cluster Distribution Model 55 that has the following salient features:
- Machines within each Cluster have special functions. eg. a database machine or an 25 event handler.
- Clusters 56, 57 and 58 are equally functional peers.
- Entry level would have one Cluster comprising one machine, deployment can scale-up by adding either machines to Clusters or Clusters to the system.
- For many systems, this model will scale to about ten Clusters each of about ten 30 machines.
- Administrative costs are reduced because:
(i) the number of database machines is usually equal to the number of Clusters:
and (ii) each Cluster is configured with only information about itself and the identit~
of its peers.
- Clusters are located near to external systems 59~ 60 and 61 with which they inter-work.
- Users 6~ 63 and 6i primarilv inter-work ~vith a nearbv Cluster. ie. Clusters 56~ 5 and 58 respec~ivelv. Ho~e~er. nothin, precludes access to data located anvwhere in the . .

CA 02263~71 1999-02-16 system.
Clusters establish the concept of Partition. Partition is a design pattern embodying physical grouping for performance purposes. This is unrelated to the logical concept of domain, which is a logical grouping of objects for various administrative purposes. Manv real world svstems exhibit a peer cluster model, for exatnple telephonv switches are peers which have intemal structure growth occurs by either intemally expanding the existing switches or by adding new ones. The peer ciuster model rarely scales beyond 1 00 machines.
~ Federation Pattem Federation allows Collections to cooperate to provide a better service, thereby addressing the issues of system performance and reliability. Many objects delegate by using some other object when executing their operations. Collections often use a specific forrn of delegation called Federation. FIG. l l depicts a Federated Collection 65. Federation occurs when groups of Collection objects (known as Confederates 66 and 67) are designed to cooperate to provide a better service than they could individually; ie. a faster, more extensible and more reliable Name servers are a good example of Federated Collections. Each narne server holds a fraction of the name space and has pointers to other name servers. If a ser-~er cannot answer a request, it delegates to a server that can. The fact that a particular Collection 20 federates is of interest to the client Federation is part of the Collection's NState model. For example, when using an IP name server, it is important to the client which fraction of the total IP name space is searched (the NState scope), it is not important how it is searched (IState model). Federation can also be:
- Transparent. in which case the client is not involved in achieving~ Federalion. The ~nified Service Pattern is a special case of Transparent Federation.
- Translucent, in which case the client has some involvement in achieving Federation.
Another special use of Federation applies to Collection/Factory objects. The COSS Life-cycle describes some models for an object ~actory and a common theme is "where is the object located?" One approach is let the client decide the object is located on the same 30 machine as the Factory. Another approach is to let the Federated Factories decide~ thus the factorics jointly decide location based on some aigorithm unknown to the client. FIG. 12 depicts a Tr iparentlv Federated Factory 70 where, for example, each Confederate (72, 73) handles a pa.~cular IP address masl~. Creation re~uests 71 are delegated bv the Federation 70 to the correct Confederate. In the example from confederate 72 to confederate 73 which 3~ returns 74 a new object 75.
Federation is a key pattern for scaling up the number of objects mana ed by a svstem. When a system is scaled up and computers added to the svstem~ more collection objects wili need to be added. This is an inevitable consequence of phvsical implementation.
However. ciients should be insulated to the greatest extent from physical implementation CA 02263~71 1999-02-16 issues. Federation reconciles the conflict as it allows multiple physical objects while retaining the illusion of one logical collection. The following situations can be indicators that Federation is needed, they are illustrated using a PrinterCollection as follows:- A Collection has Members on multiple machines. This indicates local Collections on each machine, with Federation of the Collections. The local Collections could exploit Friend implementations for improved performance. For example, a PrinterCollection exists on each machine that has Printer objects, the PrinterCollections delegate searches to each other.
- A client usually accesses specific subsets of Members but occasionally accesses more. This indicates Collections that exploit the localized data access pattern but Federate to o access global data. Loca}ized access, which is often associated with domains, is cornmon in management systems. For example, PrinterCollection objects are organized on departmental lines. Most queries can be answered by the department's PrinterCollection, but it wil~
delegate if needed.
- Graceful failure is required~ ie. the system continues to perforrn operations not directly effected by a component failure. This indicates a Federated Collection that delegates operations to the working Confederates. For exarnple, if a ~uery requires a PrintcrCollection that is not working, it will be avoided and a partial result returned.
- Extensibility by others developers is required, particularly where the other Collections have very different implementations. This indicates a Federated Collection, with different developers providing their respective implementations. For example~ in a Federated Collection of IP and common management interface service (CMIS) managed printers, each Collection will issue requests in its respective protocol and interpret the responses into CORBA return values.
It is possible that Federation comes naturallv from the Col}ection interface.
2~ For exarnple~ in a COSS Name Service the NameContext objects are Colleclions and the resolve() operation delegates to the other NameContext objects using their norrnal interface.
Natural interfaces are usually associated with the Worrn, Tree Descent and Directed Delegation implementations. Sometimes a special Federation interface is required~ this is usually associated ~vith Broadcast Delegation impiementations.
The interfaces should support Transparent Federation (rather than . Translucent)~ unless there is inforrnation available to the client that influences the operation of Federation and that inforrnation is difficult to give to the Collection. Federation is an algorithm that the Confederates iointly execute implying inter-object cornmunications.
Therefore, Federation and its attendant algonthrn is part of the Collection's ~State model it 3~ is not merely an IState issue. Admittedly, a transparentlv Federated service ~ ill have t-~o t~pes of clients Confederates and others the others will be uninterested in the Federation algorithm. Theref'ore. it is clearer to have a general and a Federation interface on the Confederates. FIG. 13 depicts the Federation interfaces 7() that exist bet~een t~ o Confederates 71 and 7~. being distinct from the respective general or Client interfaces 73 and CA 02263~71 1999-02-16 W O 98/58313 ~6 PCT/AU98/00464 74.
When considerinc implementation it is probably true that. for a multi-machine implemcntation~ all Collections should be federated. Federation can give lots of advantages for little cost. However, the goal of the federation should be carefillly considered 5 (perfomnance. reliability~ or the like)~ to ensure the implementation does achieve the desired goal. The pnmary issue for implementing Federation is "how to achieve delegation?" Some exarnple approaches to delegation include tree descent. worrns, directed and broadcast delegation.
- Tree Descent requires Members to have a natural tree structure. The Collectiono delegates to other Confederates by descending the tree, for exarnple fully distinguished narne (FDN) resolution in a M.3100 network representation. Tree Descent has predictable and acceptable perforrnance.
- Worrns rcquire the Members to be interconnected as a general graph. The Collection delegates bv traversing the nodes in the graph, for example a 'shortest path algorithrn' for 15 network roulin_ Issues which affect Worrns include cvcle detection, goal seeking, and non-predictable worst case perfomnance.
- Directed delegation is where the delegating Confederate can directly identify the delegated Confederate. This often arises in partitioned problems. For exarnple, telephone number can be separated into a number of directories any number can always be delegated to 20 the correct directory by exarnining the number. Directed Delegation has predictable and acceptable perforrnance.
- Broadcast delegation is when the delegating Confederate cannot identify a particular delegate Confederate, therefore~ the only solution is to delegate to all Confederates and accumulate the responscs. For example. a Federated Alarm Lo~ requires the query find the alarms that occurred in the last five minutes to be broadcast. Broadcast delegation has predictable but poor perforrnance. All of these delegation approaches can exhibit _raceful failure. Tree Descent and Directed delegations can be more authoritative in deciaring they have totally executed the operation. Womms and Broadcast delegations are more affected by Members which are not part of the solution~ therefore. these algorithms sometimes 30 incorrectly report partial execution. To avoid a single point of failure, Directed and Broadcast Federations should offer the client a cho~ce of Collection objects on which to execute the operations for details see the discussion of the IJnified Service Pattem below.
Some conclusions flowing from the above discussion are as follows:
- Tree descent is a consistently ood perfomner.
35 - Worms can perforrn particularly poorly, howe-er. good performance is possible for some problems. For example, telecom networks are designed to have a short path (fewer than say five hops) between any two terrnination points a womm ~ ill perforrn well in discovering the shortest path in such a network.
- Directed Delegation is a ~ood perfomner. provided the problem can be partitioned CA 02263~71 1999-02-16 such that every Confederate need not be visited. The larger the system gets, the more this will be required and the more likely it is to be true. For example. if there is three PrinterCollection objects, a particular ~uery is likely to hit many of them if you have 300, it will still hit about three.
- Broadcast~ though it responds in constant time~ does not scale verv well. After the question: "How to delegate?"; comes the question "To wllom?". The Worm and Tree Descent approaches typically have the delegation target implied in the Member and Collection interfaces. For example, COSS Naming delegates based on context names that are NState concepts.
0 Broadcast delegation has a simple solution delegate to all the Confederates All you need is a method for Confederates to tell each other of their existence a Replicated registration base is a good approach. Directed Delegation is more complex, it can be broken into three parts:
- Who are the Confederates? A registration base. as for Broadcast dele~ation, is a good 1~ approach.
- How do they partition the space? You need a partition rule, based on either a natural key (such as FDN) or a surrogate key (such as a partitioned sequence nurnber). Good manageability requires each Confederate store its own partition rule. The others inquire of it when needed this avoids the need for a global configuration base.
20 - Hou to key into the space? Operations make the key explicit, for example passing object identity or some other key.
One subtle problem that affects broadcast delegation is looping the initial Confederate broadcasts to its peers that then must know not to re-broadcast. There are many solutions, some of which pollute the client interface. The best approach is to use a specific 2~ federation mterface whose implementation does not re-broadcast. Efficient dele_ation is generally important for a distributed system. It is a design decision that is difficult to change it impacts design of object keys and identity. If done poorly, it will limit your abilitv to scale and federate. This discussion has identified some implementation approaches, however, a thorough analysis is required for particular systems.
Analogies to the Federation pattern may be drawn with Name services such as DNS or X.500, and with a help desk which can answer simple queries, whereas morecomplex ones are delegated to more experienced staff and defects are directed todevelopment engineers.
It is tempting to have a private Federation interface this makes the Confederates distributed Friends. This breaks the Strong Independence charactenstics of Friends. As such, it may be acceptable for a product, however, it is rarelv acceptable for a reusable platform component. The system should preferablv be designed to minimi7e use of Broadcast and contain the performance of Worrns. It is tempting to desi~n Federated Collections Ihat can answer globallv scoped queries. This is acceptable for a svstem needin~

CA 02263~71 1999-02-16 one to ten m~chines or Clusters. It fails thereafter, for details see the section above dealing with the Distribution Model Pattem. You could design a non-CORBA Federation scheme one approach is to publishin_ a database schema. This low-cost mechanism is a Friend relationship and. thereforc. has tl1e inherent limitations associated ~vith violatin(~ object encapsulation.
~ Unified Service Pattern A Unified Service is a convenient to use and reliable Federated Collection that accordingly works with the Friend, Collection and Federation patterns. The desirable characteristics of a Federated Collection is one:
- that is transparently Federated;
- where there is a mechanism for a client to obtain a Confederate based on the name of the service alone;
- where all Confederates respond to any operation identically with the possible exception of speed;
s - where the Confederate returned to the client shall be one that has acceptable (preferably good) performance; and - where the client can obtain another Confederate if one fails. These characteristics give a Unified Service reliability and usability.
Any Federated Service implemented using Broadcast or Directed delegation 20 76 should be a Unified Service. Unified Service 75 has an interface 78 to select 76 and re-select 77 Confederates based on the name of the service. A Unified service is built as a front-end to a Federated Service~ as depicted in FIG. 14. The front-end requires the ability to select the 'best' Confederate 79 from those available. It is tempting to implement this as a Trader operation. However, single point-of-failure can limit this approacl1. Theimplementation of 'best' should consider the following:
- Confederates that are not working are not 'best'.
- Confederates that are lightly ioaded are better than those that are heavily loaded.
- Confederates ~vhich have a shorter network delay and higher bandwidth connectivity are better.
Ticket agencies are analogous to Unified Services. Thev have many Confederates (bookin~ clerks), there is ~ ~nfederate selector (phone directory and call distributor), all Confederates can provide I ame service (b~lt some are slower), and failure of one Confederate has no effect on the se ce. It shoul~ - noted that Tree Descenl and Worm delegated Fedcrations execute operations on a i~..ember and are ~lenerally not candidates for IJnified Services.
FIG. 15 illustrates the operation of United Federated Servers in a clientlsever scenario 80. There is provided an ORB 81 that is in communication with a client 8'. a first ser~er 83. a second server 84 and a service finder 85. The operation of Ser~ice Finder Services is descnbed in more detail belo~. Entities A. B and C are available from first CA 02263~71 1999-02-16 server 83. whilst entities D and E are available from second server 84. An example of the operation of the first and second servers, which are United Federated Servers. is as follows:
1. client ~2 requests the service finder 85 for a server (which supports a specified service) and the service finder returns the first server 83;
2. client 82 invokes operation on the first server 83;
3. first server 83 invo~es operation on the second server ~4~ because the request cannot be totally serviced by the first server 83;
4. first server 83 retums a result (entity E) to the client 82, which client in turn invokes operation on entity E.
io Functional View This section provides a functional view of an ORBMaster generated service.
The ORBMaster architecture recogruzes that there are common functions performed by all services, which common functions are addressed by the architecture. In many cases they are completely implemented by generated code or library code. The common funclions are 1~ grouped together into the followin~P categories:
- distribution management;
- group operations;
- management of client/server interactions; and - component object lifecycle. As described in the introduction to services above~ these 20 functions are performed by ServiceManager objects.
~ Distribution Management In the ORBMaster architecture all ServiceManagers are unified service providers. This means that the details of the distribution model adopted bv a service are hidden from the clients of that service. The unified service design pattem allows clients to 2~ treat all component objects as belonging to a single collection renardless of their distribution.
In order to be able to provide this single collection view, all ServiceMana~ers must support the following interfaces:
resolve, given an OID, return the object's reference or return the ORBMasterIDL. . NoSucll Object exception.~0 In addition~ ServiceManagers, which allow clients to create component objects must support:
create, given (at least) the read-only attributes (except OID if the service nenerates this), create a new object or return the ORBMasterIDL::ObJect.~l) eadl ~xists exception.
Note: These interfaces are encapsulated within the ORBMaster ~enerated Access Layers;
see the overvie~v above in conjunction with FIG. 3.
The system development tool supports both the replication of component objects and the partitioninP of component objects for distribution models. If component ohjects are replicated then their state is stored bv more than one of the ServiceMana~ers for the ~Piven service. The OE~BMaster architecture enables replication of objects bv separatin_ CA 02263~71 1999-02-16 the concepts of object identity from object implementation. The current embodiment of the system development tool does not provide direct support for replicating object state.
However, the ORBMaster File Replication Service can be used by ser~ice developers for this purpose. Other embodiments of the system development too1 will provide more support for .s replication. If component objects are partitioned then their state is stored by only one Service~anager. For these services two related issues that must be addressed. namelv OID
resolution and component object location management.
OID resolution (mapping from OID to object reference) for partitioned component objects is logically a two step process. First find the authoritative ServiceManager, then ask the authoritative ServiceManager to resolve the OID or return the O~BMAsterlDL. :NoSuchObject exception ServiceManagers are authoritative for OIDs if they can determine, ~vithout reference to other ServiceManagers, whether or not the OrD represents a component object of the service.
Authoritative service managers aiso create the component objects for which the~ are s ~uthoritati~e (if the service supports object creation~.
When object partitioning is used object resolution is based on an object registration tree. An object registration tree is a tree where the nodes represent authority for the sub tree of which they are the root. The nodes have names bound to them and OIDs are structured names where components correspond to these names. The OID may have more 20 components than those corresponding to nodes in the object registration tree 90, as illustrated in FIG. 16.
In the exarnple the OIDs consist of three components, service name. chun~
name and id. ie. OID = "printer/chunk2/123/2~,". Whilst object registration trees in the present embodiment have depth ~. other embodiments mav support arbitrarv OIDs and 2s ob~ect registration trees of any depth. OlDs are absolute names defined relative to a cornmon root 91. The intermediate nodes 9' and 93 effectively g~roup the services by service name, for example "printer" node 92. The leaf nodes 94, 95, 96 and 97 in the object registration tree are ServiceManagers that support the resolve and (if the service supports it) create operations.
ORBMaster generated services provide support for their users (ty~picallv only those actin_ in system ~lministrator roles) to specifv where component objects will be located in t~-s,o ways:
- bv s~ ying which ScrviceManager will create, g~ en component objcct (this is expressed u , partitioning rule); noting that not all ser~dces allo-v clients to create component obj ects; and - by moving component objects after thev are created; wherein nodes in the object registration tree are objects which support the CosLifeCvclc. .LifeCl cieob/'?ct. n20ve operation. thus allowin ~
groups of component ob~ects to be moved based on their OIDs. A partitioning mle defines a CA 02263~71 1999-02-16 mapping from values for a sub-set of the attributes given to an object when it is created to the name bound to a leaf node in the object registration tree.
If one of the attributes to the create operation is the OID it is an error if the operation is invoked with an OID which does not also resolve to the same node in the object registration tree to which the partitioning rule maps. Object creation (where supported) of partitioned component objects is logically a two step process:
- find the authoritative ServiceManager, to which the partitioning rule maps; and - ask the authoritative ServiceManager to create the new object and return its object reference or return the ORBMasterlDL::ObjectAlreadvExists exception if the object already 0 exists.
~ Group Operations Group operations are those operations that apply to more than one component object. The set of objects to which a particular invocation of a group operation applies is known as the scope of the operation. Group operations are supported by ServiceManagers, ra~her than component objects. Group operations are cateLorized accordin~ to the following cntena:
- scope definition;
- support for partial completion;
- delegation method; and 20 - transactional behaviour.
The scope of a group operation is defined either explicitly or implicitly.
Explicitly defined group operations are based on an underlying operation supported by component objects of the service, are e~uivalent to invoking the underlying component object operation for every object in the scope, have their scope explicitlv defined by a parameter to the operation (a list of OIDs)~ exist solely for reasons of implementation efficiency, and have their interface generated by the system development tool based on the developer specified underlying component object interface. Whilst implicitly defined group operations are not based on an underlying operation on an individual component object, have their scope determined by the selvice by it applying a client specified filter to all the 30 component objects of the service, exist because they implement problem domain semantics identified bv the developer ~rather than for reasons of implementation efficiency), and have their interface partially generated by the system development tool based on the developer specified interface. Impiicitly defined group operations are typicallv query interfaces.
The code generator generates the interface for an explicitly defined scope group operation from a developer specified component object interface. The component object interface which is used as the basis of a group operation preferablv should:
- retum void;
- have zero or more in parameters of any type;
- have an optional out parameters which can return any type;

- only raise user exceptions that contain an O~RBMaster/DL::Rett~rnCode structure as their data contents.
Component operations should therefore be of the form:
interface < inte~ face> ~
void <base operation> ( ~<in arg list>
out <result tvpe> <Otll param> O
raises ( <exception list> .

o where:
~inte~ face> is the narne of the component object interface defined by the developer;
<base operation> is the developer defined underlying operation on a component object;
<in arg list> is the optional list of in parameters;
s <result type> is the type of the out pararneter;
<out paranl > is the optional out parameter; and <exception list> is the optional list of user exceptions raised by the operation.
An exarnple of the IDL generated by the system development tool is:
1. A structure (in the scope of the module that contains <interface>):
struct <interface> <base operation>Result 1 boolean valid [ ~reh~rn type> <out param> ]
ORBMasterIDL::OID oid;
OhBMasterIDL::Re~urnCode rc, where:
valid indicates whether the other fields in the structure (except rc which is alwavs valid) are valid;
<out param> is the value rcturned that is associated with the object identified by oid (only exists if <base operation> has an out parameter);
oid is the OID of the object for which the structure holds the result; and rc represents the exception that would have been returned by the component object operation.

7. A typedef definine a sequence of -inlerface><base operaliol7>Resul~s.
n~pedef seyuence <

<interface><base operation>Result > <inte~face>~baseoperalion~ResultList;
3. An operation (defined on the ServiceManaeer interface):
l oid <in~erface><base operallon~Gro7lp ~

WO 9~/58313 PCT/AU98/00464 i~l ORBMaslerIDL::OIDList oids ~<in arg list> ~
out <i~te~ace><base operatio~7>ResultList results ), where:
oids defines the scope of the operation <in arg list> is the op~ional list of in parameters supported by <base operalio~results is the list of results obtained for the operation.
The following is an example of a component object operation getName for ~ which the developer requires the svstem development tool to generate a group operation:
module ~;xample 1~
inte~ace X ~' void getName ( out string name);
,~, 1~ ,,1 For this example the system development tool generates the additional IDL shown below:
module ~xample ~
inte~ace X f void getName f out string ~1ame) 3j /I Start ORBMaster generated IDL

struct Xget~ameResult 2s boolean valid string name ORBMasterIDL. :OID oid;
ORBAqasterIDL:. Retur n Code rc;
';
t!~pedefseyuence< XgetNa~7leResL~lt >
Xget~rameResultList, i~zte~face XMa~zager t Xgetl~iameGroup ( i~Z ORBMasterIDL::OIDList oids out XgetNameResultList results) ~ Il Il END ORBMaster generated Il The C~ CAL and SAL interface classes which encapsulate tlle IDL interfaces defined above are described in the example provided in the section on 'Access Layers' belo~s The operations have an implicitlv defined scope are defined by the developer and identified to the svstem development tool as implicitlv scoped group operations.
4~ Group operations mav also suppon partial completion. By this is meant that ~ ~ ....

CA 02263~71 1999-02-16 the service which implements the operation will make a best effort to apply the operation to all objects in the scope. Those that are available to the service will have the operation applied to them~ It would be desirable for the clients to be inforrned when an object in the scope could not be contacted. In the case of implicitly scoped group operations, this may not be s possible because the service may partition the component objects and it may not be able to detemline which objects are actually in the scope (say if some partitions are unavailable when the operation is executed). For explicitly scoped group operations the system development tool requires that services return an ObjectU7lavailable retum code associated with each object that was not available. For implicitly scoped group operations the system 0 development tool requires that services return a parameter of type ORBMasterIDL::Res~ltAuthoritv along with the result.
The delegation methods include those set out briefly below:
- none, which applies only to operations on services based on replicated component objects;
15 - directed, which applies only to operations on services based on partitioned component objects and to explicitly scoped group operations; and - broadcast, ~vhich applies only to operations on services based on partitioned component objects and applies to both implicitly and explicitlv scoped group operations. It is anticipated that transactional operations will be supported by other embodiments of 20 ORBMaster.
~ Management of Client/Server Interactions (Result Iterators) Group operations that are queries typically retum a list of individual "results"to their clients. If these queries are implemented using an rDL operation per query the following will result:
25 - the query client must allocate the memorv requircd to receive all the "results" before any "result" becomes available; and - the qucry client cannot start acting on some of the "results" until the whole operation is complete. Result Iterators are a standard design pattem which are used to solve these problems. This design pattem consists of a standard form for the IDL which defines these 30 interfaces, a templated class, ORBMaster~ eszlltIferator~class 7~>. which forms part of the ORBMaster Support Library, and ORBMaster generated agent classes which use the temrlated class.
The system deve ~rnent tool Resultlterator desi~,n pattem uses three IDL
operations to implement each query:
35 1. an operation which retums the first batch of results;
2. an operation which retums the next batch of results; and 3. a cancel operation ~vhich allows the client to notify his lack of interest in the querv.
A batch of results is a set that contains no more than a client specified number of individual results The ser~er detemnines the aclual number of results in the batch as described below:

CA 02263~71 1999-02-16 - The operation which returns the first batch blocks until either:
(i) at least one result is available; or (ii) the server determines that all available data has been searched;
and then returns those results that are available (but no more than the client specified number). The server outputs a resultId that the client uses as the identifier for the query. It also outputs a boolean isLast which is set to true when all available data has been searched by the server.
The operation which returns the next batch behaves similarly except that it takes the resultId as input. Once a result has been returned to the client it is discarded by the server so that o each result is only ever returned once. The cancel operation is essentially a notification to the server that the client has no more interest in the query. It has no semantics other than this.
The server may use this notification to release resources that it has allocated to the query execution.
The following example shows a query, getAII~ which returns a verv long list of strings:
typedef se4uence< string > ResultList;
interface X ?~
//
//an operation which can return a very //large list of strings as its result.
//
void getAll(out ResultList vervLongList), ~, In order to make use of result iterators this query is implemented by the following operations:
~nodule Lxample ~ interface X ' void get~ll( in sl~ort batc1lSize, out ResultList firstBatch, out string resultId, out boolean isLast), void getAll_nextf in string resullId, ~ in s~zort batc~zSize, 3~ ~ out Resultl ist nextBatch, out hoolean is~ast), ~oid cancel( in slring resl{ltld), ~, 4() ,1 ~ Life-cvcle management Some ser-ices allo~v clients to create component objects and some do not. If clients can create component ob3ects then, ~vhen the object is created. it must alreadv have all CA 02263~71 1999-02-16 its read-only attributes defined. This means that the create operation must either take, as input, values for all those attributes. or the service must generate them. Typically the only read-only attribute that is generated by the service is the OID. Therefore the OID is either specified by the client as an input parameter to the create operation or it is generated by the service as part of the implementation of the create operation.
Access Layers The Client Access Layer (CAL) separates application code from code needed to access the objects that implement the services. The interface bet~veen the CAL and the application code does not expose any of the C~ classes generated from the IDL for the o service. Similarly, the ORBMaster Server Access Layer (SAL) separates the application code in the server from the IDL generated code used to access it. Further details of the CAL
and SAL of the preferred embodiment are set out below.
Client Access Layer (CAL) The classes that provide an interface between client app}ication code and the CAL consist of:
- agent classes used to access the distributed objects which implement a service; and - classes which represent the data structures manipulated by the agent classes. Agent classes serve t~,vo main purposes to separate IDL generated code from application code and to provide a complete encapsulation of the object, ie. one which encapsulates the identity of 20 the object, its interface, and the means to address its implementation(s). In effect, the agent classes and the supporting data structure classes, are an altemative C~ mapping for IDL.
The next sub-section explains the justification for introducing a non-standard altemate C+~
IDL mapping.
~ Justification for providing an altemate C binding for IDL
~5 There are t~,vo main justifications for the provision of an alternate C ; IDL
mapping:
1. Developers require a large amount of training before they are proficient developers of CORBA services and the client code that accesses them:
(a) The classes which define the interfaces to the CAL and SAL (unlike the standard C~ IDL mappings) use the standard template library of ANSI C~. This means that C~ proficient developers already understand the data structures that are a major l~art of the interface.
(b~ The statldard IDL mappings present more than one way of doing a task (eg.
th i- more t~lan one model for memory management), by providing a simpler interface ~vith less options, Ihe SAL and CAL interface classes are consequently easier to use.
(c) The standard IDL mappings expose more complex concepts to users (eg. the standard obj ect reference is a much more complex concept than the svstem development tool's agent classes).

2. Standard C~ mappings for IDL do not address object identity and object mobility.
(a) CORBA object references do not allow comparison for equality.
(b) CORBA object references may change (eg. if an object is moved from being implemented by one server to another).
(c) CORBA object references are unsuitable for use as database keys for the persistent storage of objects since they are too big.
~ Alternale IDL bindings The altemate client side mappings for the IDL are developed in accordance with a set of mapping rules. These rules are typically as follows:
0 1, For each IDL interface, a C++ agent class is provided. The name of the C~ agent class is: <IDL module>_<IDL i~lterface>Agenl.
2. Agent class inheritance (public virtual) mirrors the inheritance of the IDL interfaces, for example:
//IDL module module Example 1' interface X ~
void oppr_x(), ~;
inte~ace Y . X ~
void oppr y();
3, ~, llC~ agent Classes class Example_X4gent .
public l lrtual ORBMaste~_Agent //details of class omitted ,1, class Example_Y~lgent .
public l~irlual Example_.~4ge~lt //details of class omitted ~;
3. Agent classes contain a method for each IDL defined operation for the corresponding interface, All these operations return OVErrors and use STL data types rather than data types generated bv the IDL compiler.
3~ 4. Agent classes provide assignrnent operators and copy constructors that have the same semantics as those for ORBMaster_~lgenl.
5. LDL defined structs are represented as C~ classes. The naming convention for these classes is (depending on the scope of the IDL struct):
<IDL module>_<IDL interface>_<Structure name>; or <IDL module>_<Structure name>.

6. Classes that represent IDL constructs mana~e their own memorv and have constrUctors that provide the initial values for all their data members. On construction they , . .. .

CA 02263~71 1999-02-16 W O 98/58313 PCTiAU98/00464 take copies of all the provided data members. They support assignment operators and copy constructors that result in deep copies of the source objects.
~ Agent Classes Instances of these agent classes represent the distributed objects from the point of view of a client of those objects. Agent objects always contain the OID of the distributed object that they represent. For the case of agents for component objects this is the OID of the component object, for the case agents for SenviceManager objects this is the name of the service. When the agent is used to access the object, the CORBA object reference for the object must also be present. Agent classes obtain these object references 0 when required. Instances of agent classes are bound to distributed objects by the following methods:
- binding them to stIings which represent OIDs;
- assi~ing one agent to another, following assignment both agents now represent the same object;
5 - constructing one agent using another as source, fol]owing construction both a~ents now represent the same object;
- binding them to CORBA object references (only a~ailable to ORBMaster code within the CAL and SAL- not to application code).
If the CORBA object reference is not present when it is required the agent 20 resolves the OrD to the appropriate CORBA object reference automatically. The agent classes also intercept system exceptions, and, when they occur, re-resolve OIDs to CORBA
object references. This allows the same agent to be used to access different object implementations without inten~ention by the client of the object. This is useful in the following example cases:
2~ - an object is moved by an administrator to balance load;
- one replicated copy of an object fails and is automatically substituted for by another.
An error is returned to the client only if a successful automatic resolution is not possible.
The purpose of the agent classes is to provide a clear separation between CORBA dependent code and application code. As a consequence of this separation, no 30 CORBA header files or header files generated by the IDL compiler are included in the header files for agent classes. Implementations of agent classes (-vhich obviously do depend on ORB Cf ) are obscured by havin~ each agent class include a private data memDer which is a pointer ~J an instance of a hidden access layer class (the access layer class header file is not provided for general use but is available only for internal use within the Ciient and 3~ Sen~er Access Layers). The following class is provided as part of the ORBMaster Support Library of the embodiment to support the agent paradigm ORBII~as~er_Age)lt~ which serves hvo purposes:
- a base class which is speciali;~ed by agent classes for specific objects implemented by ORBMasler senvers. ie. it encapsulales the commonalitv of all agent classes; and - can be used to represent any object implemented bv an ORBMaster server.
This class is accessed by the developer and a man page is included for it. as follows:
#include <std/s~ring>
#include <ORBMaster.hh>
#i~zclude <OYError.hh>
class ORBMaste-_AgentAL
class ORBMaster_Agent ~
friend class ORBMaster_AgentAL;
public.
ORBMaster_Agent() ORBMaster_Agen~(const ORBMaster_Agent~ src);
l~irtual ~ORBMaster_AgentO, ORBMaster_Agent& operator=( const ORBMaster_Agent~ rhs);
virtual OVErrorgetOID( 0~2BMaster_StructuredNam~ & theOID) const; virtual OVErrorge~OR(string& iorStr) const;
virtual void bindfconst ORBMaster_St)~ctl~redName& oid);
virtual OYError exists(bool &result) const;
protected:
ORBMaster_AgentAL *impl ORBMaster_StmcturedNarne oid; }
2s The system development tool also generates (from the IDL) the specific agent classes that inherit from ORBMaster_Agent. The system development tool generates these agent classes together with their complete impiementation. Like the ORBMaster_Agent classes, the specific agent classes contain hidden access layer objects. These similarhr~ contain CORBA
30 object references. Also~ like the ORBMns~er_Agcnt class. these specific agent classes allo-deveiopers to bind the agents to specific CORBA objects using copy constructors,assignrnent operators and the bind method. Note: Because CORBA object references are not enough to identify the objects which support the system development tool senvices. agents cannot usually be bound to CORBA object references.
Sen~er Access Layer (SAL) There are two basic assumptions behind the implementation of the system development tool servers:
1. Component objects are aiwavs persistently stored by some object storage service.
The object storage service may be a relational, or 00 database or it mav be an external application (as in the case of a CORBA ~ateway to a legacy system. or to network devices accessed v ia a network management protocol); and . Sen~iceManagers l~now the partitioning of component objects. that is. for a given , . , ,.. .. . . ~ ., .

CA 02263~71 1999-02-16 component object they know which ServiceManager is authoritative for it. but they delegate to the object storage service the knowledge as to whether a given object actually exists or not.
The object storage service provides an applications program interface (API~ which, given an OID, either locates the state of the component object or indicates that the OID does not represent a valid component object.
If the service being implemented supports the concept of objects being created and deleted then the object storage service provides an API that does this lifecyclemanagement.
0 Note: Although the term r'object storage service" is used, the actual service may do much more than just store the objects persistently, for example it may be a complete application.
The point is that it should preferably at least: manage lifecycle~ answer object e~istence queries and store the objects persistently~
The above assumptions then allow the following:
- a distributed service to be built using a non distributed object storage service;
allow the service to scale up to the scalability limit of the object storage service and not be limited by the ORB;
- the friend relationship which exists between ServiceManagers and the componentobjects for which they are authoritative to be exploited by allowing the internal state of the 20 component objects to be accessed by the ServiceManager;
- avoid the need for ServiceManagers to separately keep track of which objects exist thereby removing the need for them to synchronize this inforrnation between themselves and the object storage service; and - ServiceManagers to swap component object implementation objects into and out of 2~ memory at will because both the object's state and the knowledg~e of the object's existence is persistentlv stored by the object stora~e service.
The assumptions described above amount to requiring a very clean separation of responsibilities between the classes that encapsulate the SAL and the classes that encapsulate the service implementation. In fact this separation is so complete that the 30 ORBMaster approach is essentially an application of the CORBA gateway server design pattern. This pattem is normaliy on!-~ applied to legacy system encapsulation, however the system development tool applies it ~ all servers because of the benefits it pro-ides in decoupiing ORB dependent code fr application cc e. ~IG. 17 shows the interactions between the server CT+ objects in the server access layer (SAL) and the server application 3~ code.
The SAL includes a ServiceManager Adaptor 100 which manages access and memorv for the ServiceManager implementation 101 and contains the ORBMaster_ServerCache 10'. The server cache controls the swapping of the Component Object Adaptors 103 listed in the LRU. which object adaptors in turn conlrol access and CA 02263~7l l999-02-l6 memory for the respective Component Object Implementations which are swapped in and out ofthe Object Storage Service 10~. The Object Storage Service 105 may be an RDBMS, an OO DBMS or a legacy application, which service:
1. creates and deletes component objects;
2. answers queries re~arding the existence of component objects; and 3 . stores component objects.
~ SAL / SAC Interface Corresponding to every IDL defined interface are two classes:
- an Impl class which is provided by the system development tool only in the form of a 10 stub; these exist within the Server Application Code as shown in FIG. 3;
- an Adaptor class which is derived from the IDL generated server stubs and is fillly implemented by the system development tool; these exist within the Server Access Layer shown in FIG. 3.
Like the agent classes~ the Impl classes support a method for each operation defined in the IDL interface. In fact~ the name and si~nature of these methods are identical to those in the corresponding agent class. The suggested naming convention for lrnpl classes is:
<IDL module>_<IDL inteYface>Impl Developers provide the act~tal implementation of these classes by building on the stub implementations generated by the system development tool. Developers can choose to 20 implement these classes as stateless gateways to the object storage service or they may cache component state in them.
The infrastructure classes are derived from the IDL compiler generated server stubs.
These classes provide the access path bet~een the ORB and the developer providedimplementations. The suggested naming convention for infrastructure classes is:
2~ <IDL ~1lodule>_~IDL i)7terface>~dapto~
The server application code never accesses lmpl class methods directly. All access to Impl objects is via the corresponding Adaptor object. This means that ~vhen an objectimplementation needs to access another object (even of the sarne class), it uses an agent object. Failure of developers to use agent classes in code that they supply may introduce 30 problems relating to thread safety and memorv addressing.
~ Lifecycle and memorv management The memorv management of each Impl object is handled by the infrastructure.
That is, developers never directlv construct or destruct a <IDL ~7l0dt~1e>_<IDL
inte7~face>lmpl, this is done by the corresponding <IDL module~_<IDL i~lte~face>Adaptor.
3~ Similarl~, in the case of component objects, the infrastructure (ie. Adaplor classes) is responsible for initiating the swapping in and out of the component objects. The developer is only required to provide anv ser~ice specific swap in or swap out implementation.
Clients create and dclete component objects via operalions on a ServiceManac~er. The create and delete operations used for component object lifecycle .

CA 02263~71 1999-02-16 management are not special to the system development tool. The implementation of these operations, like all other operations, involves an Adaptor object (in this case the Adaptor object for the ServiceManager) calling through to its corresponding ServiceManager Impl object. ServiceManager objects are created when the ser~er process which instantiates them :- is started with the "install" command line option set. Similarly they are deleted when the server process ~vhich instantiates them is started with the ~'deinstall cornmand line option set. In other words, installation afimini.strators explicitly mange the lifecycle of ServiceManager objects.
~ Distribution issues 0 FIG. 17 shows how instances of the C~ classes in a server interact within a single process. The Adaptor classes for ServiceManagers have the responsibility for encapsulating distribution concepts. This means that the Impl classes for ServiceManagers are not concerned with issues of distribution, they simply implement the service on a single host. In other words all operations on Lrnpl classes are implemented bv only referring to the 1~ local object storage service. Adaptors provide the distributed view bv delegation to the appropriate peer ServiceManagers (by using broadcast or directed dele_ation to the peer ServiceMana~ers as appropriate).
~ C~ Classes The following classes are provided as part of thc Support Library to help implement ORBMaster servers:

- ORBMaster_Componen~
an abstract ~ase class for component object implementations;
2~ class Of 2BMaster_Co-nponen~
private.
~irtzlal OYErrorswap_in() = 0, virtual OVErrorswap_out(bool &refilsed) = 0, - ORBMaste~_Se~verCache although part of the support library, developers do not access these objects directly.
The system development tool also generates (from the IDL) an Adaptor and a Impl class for every IDL interface. For the case of component objects the Impl class inhents from ORBAlaster_Con~pone7ll. For each se~vice. the svstem development tool also ~enerates a file which defines a main~) function. ~-'his function instantiates the Adaptor object that implements a ServiceManager for that service.
Common IDL
The following IDL defines common data t~rpes used bv all services:
4~ ntodule ORBA~aster j' n pedef OVErrorService::E~t~ Id ~o~tAzo1zorih!~eason CA 02263~71 1999-02-16 typedef sequence< Non~utl~o~itvReason >
NonA uthorityReasonList ,1, Fiie Replication Service s The File Replication Service supports the replication of files within a CORBA
installation. The Fi]e Replication Service of the embodiment depends on the followin_:
- the particular CORBA ORB;
- the ODBC Access Layer; and .
- a POSIX compliant system interface. This limited dependency enables other services 0 to be built on top of the File Replication Service without the complication ofinterdependencies. The File Replication Service is implemented using objects that support the standard IDL interfaces ReplicationManager and ReplicationClient. For each host in the installation there is at most one Replicationl\~anager object. A set of ReplicationManagers can be formed into a peer group. Within a peer group all 1~ ReplicationManagers keep object references to all other ReplicationManagers in the peer group.
The purpose of each ReplicationManager is to m~int~in a local copy of a set of files so that the contents of these local file copies are "approximately" synchronized across the peer group. Clients of the Replication Service define which files are to be replicated.
20 ReplicationClient objects register themselves with ReplicationManager objects. On registration~ ReplicationClients specify the files in which they have an interest. Files are specified using identifiers rather than file names allowing the local version of the file to have different narnes on different hosts. The service treats a group of files as a single entit~ in that the group is considered to be modified if any file in the group is modified and all files in the 2~ group are replicatcd when the group is modified.
~ Assumptions The File Replication Service supports the replication of files subject to the following restrictions (these typically express orders of magnitude rather then exact limits):
- 10 hosls per peer group;
- 10 files per host;
- 500 characters per file;
- file updates occur rarely (only a few changes per day);
- clocks on all hosts in a peer group are synchronized to ~vithin about 10 seconds:
- modifications to one file are propagated to other copies of the file using distributed 3~ operations: copies may therefore be out of date until chan_es propagate to them modifications are propagated to all hosts that are reachable by the host on which the modification w as made within 1 minute of the change occurring;
- if a host looses connecti-itv with the source of a modification then it shall become ahgned wlth n w Ithm ~ mmutes of regaining connectlvlty.

~ Interface Definition module The following is an example of an interface definition module:
module ORBMasterFR
typedef string Filel~ame;
t,vpedefsequence<FileName> FileNameList, typedef string FileConfents typedefsequence~FileContents> FileContentsList typedef string FileGroupld typedef se~uence< FileGroupId > FileGroupIdList struct FileAccessProblem string fileName; //the file name string hostName //the host name string operation //the svstem call //vhich causes tlle pro~lenl string errorA1sg //tlte error message ,1 exception File ~l ccessProblem 1~
FileAccessProblem problem //Describes the file problem ~;
exception No~ocalBindings exception Uninitialized ~J~5 exception WrongNumberOfFiles 1~
unsig7led shon actuallVumber ,3, 11 All clients of the Replication Service must support this Il interface interface ReplicationClient // indicates that the file group has chan~ed void updatefin FileGroupId modified~ileGroup) ,1, typedef unsigned long irimeStamp inte~ face ~eplicationManager 1, Define the local file names for a fi1e group.
Il If narnes alreadv exist for the group then replace them.
void setNamesForGroup~
in FileGroz~pIdfileGrollpId, in FileNamel ist localNames) , Get the local narnes fo~ a file group.
/! Returns an empt~ list if no names e~;ist for /I the given group.
FileNameList getNamesForGroup( in FileGroupId fileGroupld) /I Retums a list of all the clints registered.
Il If no clients are registered then the list is ernpty.
ObjectIdList gelClienls(j // Retllrns a list of the file groups for a given client.
0 // Returns an empty list if the client is not registered.
FileGroz~pIdList getGroupsForClient( in ObjectId client);
/I Get the version number for the specified file group.
1S 11 A value of zero indicates that the ReplicationManager Il does not have any local files for this group.
TimeStamp get Yersion f in FileGroupId f~leGroup);
/I Receive a file group and, if the input group is more // recent than the local group, update the local group and call Il the update operation on the registered clients.
Il Updating the file group is atomic so that. if this Il operation returns successfully, the changes to the file /I system have been completed.
void upLoad~
in FileG- oupId fileGroupId in FileContentsLis~ fileGroupCo~ltents instringsol~rce 1/ hostnameoforiginator i~l Ti7neSta~t?p vcrsio~t ) raises i T~rongNumberO~iles // A registration e~;ists for the // file group but the number of // elements in FileGroupContents // is not the number of files // in the group FileAccessProblem, /1 A local file could not be written ), !/ Registers a client's interesl in a file group.
//Does nothing if the client is alreadv registered //for the group. Clients can be regis~cred for //muitiple groups.
//The client is identified bv clientId NOT clientObj.
~ oid registerClient( i~ ObjectId clientId i~l Replicario~lClie~tt clie~ltObJ, i~l FileGrot~pIdfileGrot~pId) raises ~

CA 02263~71 1999-02-16 No~ocalBindings, 1/ There are no local file // names defined for the file group Uninitialized // clients cannot be registered 1/ until the ReplicationManager 11 is initialized ), /IRemoves an existing registrations for this client.
//Does nothing if the registration does not exist.
void unregisterClient( in ObjectId clien~Id, in ~ileGroupIdfileGroupId );
Il reads well known file/s which stores the Il object reference of all other RepiicationManagers in a 1I peer group; if the ReplicationManager has not yet been Il initialized then this operation initializes it void loadPeers() raises 1~
FileAccessProblem IICan't load the peers };
J;
~;
~ Defining a Peer Group All ReplicationManagers in a peer g~roup m~int~in their own local knowledge of all other ReplicationManagers in the peer group. They do this using CORBA object references. If the server process which instantiates a ReplicationManager is started in install mode it creates a persistent ReplicationManager and stores its CORBA object reference in a file (in a well known directory) ~ith the same name as the host on which the server is executing. Whcn the loadPeers operation is invoked. the complete set of CORBA object references for ReplicationManagers in the peer group must be stored as files in Ihe well-known directory. It is an a-lministrative task to ensure that the contents of the directory containing CORBA object references are identical on every host in the peer ,roup. The loadPeers operation reads the files containing the CORBA object references in order to find out the all the ReplicationManagers in the peer group. The loadPeers operation s~ores the object references for the peers in the relational databasc. When ReplicationMana_ers are started in other than install mode, the database is used to obtain the peers. This means that the ability for a ReplicalionManager to start only depends on the a-ailabilitv of the loca~
database.
The a~imini.~trative procedure for initialising a peer group is then as follows:- start all servers supporting ReplicationManagers in the peer group in install mode -each will u~rite their CORBA object reference to a file ~ith the local host name as the file narne;
- ensure that each host has a complete set of CORBA object reference files Inothino CA 02263~71 1999-02-16 required here if the directory containing the CORBA object references is mounted using NF S);
- invoke the loadPeers operation on each ReplicationManager in the peer group.
Services which depend on the File Replication Service can only be started after the peer .
group IS IllltlallZed.
~ Managing Client Registrations The registerClient operation on the ReplicationManager interface defines which file groups a particular client object is interested in. The unregisterClient undoes a registration. File groups are identified by strings (not file names). Client registrations are 0 made persistent by ReplicationManagers. Clients are notified when a file group for which they are registered is modified, however, if a client is not contactable by the ReplicatiorlManager when a file group is modified, then no attempt is made to inform the client when it subse~uently becomes available. It is the responsibility of the client to obtain the latest copy of its files when it starts up to ensure that it aware of anv chan_es which 15 occurred while it was down.
~ Source-push algorithm for file modification The File Replication Service assurnes that the files that it replicates can be modified directly via the file system. Each ReplicationManager polls the file system at regular (configurable~ intervals in order to determine if a file group for which it has client 20 registrations has been modified. Once a ReplicationManager has determined that a file group has been modified it pushes the modified file group out to all its peers by invoking the upLoad operation on them. It also notifies all its interested clients by invoking the update operation on them. When it invokes the upLoad operation it uses the most recent file modification time (in seconds since 00:00:00 GMT Jan 1 1970) for files in the group as the 2~ file group version nurnber (the version p~rameter to the upLoad operation). It is the responsibilit~ of the ReplicationManager that detected the modification (the source) to ensure that the new version is pushed out to all its peers. This means that it will retry the upLoad operation until it succeeds (even if it is stopped and subsequently restarted). The retry interval is configurable.
When the upLoad operation is invoked the target ReplicationManaoer checks whether the input file Proup is more recent than its local copy. It does this by comparing the input version parameter ~vith its stored vaiue. If these differ bv more than the maximum error in system clocks (configurable) then the most recent is taken as the larger version number.
Other~vise the version numbers are disregarded and the input host name and local host name 3~ are compared. The most recent is then taken as the one strcmp deterrnines is the greater.
Using this arbitrary ordering on host name means that if t~vo or more different modifications occur at approximatelv the same time, onlv one modification ~vill succeed. If the input is more recent then the ReplicationManager updates its local copy, informs its clients and stores the input version number as the version number for the group. If the input is not more .... ~.. ~ .. . . .. ..

CA 02263~71 1999-02-16 recent then the ReplicationManager just returns.
As well as version numbers, ReplicationManagers persistently store the time stamps associated with each local file. They do this so that they can detect when a file is modified. On start-up they deterrnine if a file group has been modified while they were down 5 by comparing the persistently stored time-stamps with the values obtained from the file system. By persistently storing these time-stamps they are able to treat the case of "file modification while they were down" as a normal file group modification as described above.
~ Peer group start up When a ReplicationManager is created its stored version numbers and file 0 time stamps are set to zero. As client registrations occur, a ReplicationManager will detect that the stored time-stamps are less than the actual values and so push the local copies of files out to all the peers. The most efficient way to start up a peer group is to have only one copy in the peer group of each file group.
Service Finder Service ~s The Service Finder Service is implemented using objects that support the interfaces ServiceLocator and ServiceManager. Every host in the in~t~lla~ion has at most one ServiceLocator. ServiceLocators manage a repository of ServiceManagers and allow clients to find ServiceManagers based on service name, proxirnity to the ServiceLocator, and location. The Server Finder Service depends on the following:
20 - the particular CORBA ORB specified;
- the ODBC Access Layer;
- a POSIX compliant system interface;
- the CORBA Notification Service ~ Assumptions 25 The following assumptions apply to the embodiment:
- the installation consists of about 10 hosts - the hosts in the installation are defined at installation time and not altered; and - ServiceManagers may be dynamically added and removed from an installation.
~ lnterface Definition~0 module ORBMasterSF ~
tvpedef string Sen~iceName;
tvpedef sequence < Se7~iceName > ServiceNameList tl r - -lef string Location;
tl ~ef sequence < Locatio~l > LocationList;~5 inte~ face ServiceManager t!~pedef sequence <ServiceManager> ManagerList interface Sen~iceLocator Ivpedefsequence <ServiceLocator> LocatorList~0 e~ception AlreadvRegistered ~;
exception NotRegistered }, interface SenviceManager .
CosLifeCycle. :Factor,v~inder readonly attribute Sen~iceName serviceName;
readonly attribute Location location;
,1;
interface SenviceLocator ~' // Registers a ServiceManager, stores the tuple:
// (serviceName, location, ServiceManager).
// ServiceManager is identified by its seIviceName and // location attributes.
void registerManagerf in SenviceManager ServiceManagerObj) raises ( AlreadyRegistered 1/ a ServiceManager is already // registered with this ServiceLocator for the 1/ service and location );
// used to distribute notifications about the existence // of aServiceManager void notifv~ddManagerf in Sen~iceName serviceName in Location location in SenviceManager ServiceManagerObj~;
// Removes an existing registration.
void tlnregisterManager( in ServiceName sen~iceName in Location location) raises( NotRegistered void noti~RemoveManager( in ServiceNartle se~iceName in Location location) // gets a locally registered ServiceManager for the // specified service. If no matching ServiceManager exists // returns a NIL object reference.

.. ... ., .. ., .. . ~ ~ --W O 98/58313 PCT/~U98/00464 //If testRequired is tme then the ServiceLocator tests the //availability of ServiceManagers and does not consider //unavailable ServiceManagers to exist.
ServiceManager getLocalManager( in Se~iceName service, in bool testRequired), // gets the best ServiceManager for the Il specified service.If no matching ServiceManager exists 0 /I returns a NIL object reference.
// If testRequired is true then the ServiceLocator tests /t the availability of ServiceManagers and does not consider //unavailable managers to exist.
ORBMaster::ResultStatus getBestManager( in ServiceNamese~ice, in bool testReq~ired, out ServiceManager Manager), /I gets locally registered ServiccManagers.
1I The services parameter is used to filter the results Il based on service narne.
Il If the services list is empty then no filtering by service narne ll applies.
/l The locations pararneter is used to filter the results ~5 /l based on location.
Il If the locations list is empt-v then no filtering by location Il applies.
ManagerList getLocalRegisteredManagers( in ServiceNameList services, in LocationList locations), Il gets all registered Servi cManagers.
ll The services parameter !S ~lsed to filter the results ll based on service name.
11 If the services list is empty then no filtering by service narne Il applies.
'I The locations pararneter is used to filter the results / based on location.
, ' If the locations list is emptv then no filtering by location CA 02263~71 1999-02-16 1/ applies.
ORBMaster:.~esultStatus getAllRegisteredManagersf in Se~iceName~ ist services, in LocationList locations, out ManagerList Managers), };
};
~ ServiceLocator All ServiceLocators in a peer group m~int~in their own local knowledge of all 0 other ServiceLocators in the peer group. They do this in the embodiment using CORBA
object references. If the server process which inct~ntiates a ServiceLocator is started in install mode it creates a persistent ServiceLocator and stores its CORBA object reference in a file (in a well known directory) with the sarne name as the host on which the server is executing.
When the loadPeers operation is invoked, the complete set of CORBA object references for ServiceLocators in the peer group must be stored as files in the well known directory. It is an ~(lmirlistrative task to ensure that the contents of the directory containing CORBA object references are identical on every host in the peer group. The loadPeers operation reads the files containing the CORBA object references in order to find out the all the ServiceLocators in the peer group. The loadPeers operation stores the object references for the peers in the relational database. When ServiceLocators are started, in other than install mode, the database is used to obtain the peers. This means that the ability for a ServiceLocator to start only depends on the availability of the local database. A typical ~mini~trative procedure for initi~ ing a peer group is then:
- start all servers supporting ServiceLocator in the peer group in install mode, each will write their CORBA object reference to a file with the local host narne as the file name;
- ensure that each host has a complete set of CORBA object reference files (nothing required here if the directory containing the CORBA object references is mounte~ using NFS); and - invoke the loadPeers operation on each ServiceLocator in the peer group.
Each ServiceLocater maintains a persistent list of the ServiceManagers that it has registered. It stores this list in the relational database using the ODBC access layer. A
ServiceLocator does not store the registrations that are managed by its peer ServiceLocators.
Clients make requests for ServiceManagers for specific services by invoking the 3~ getBestManager on any ServiceLocator. ~here are typically two circumstances in which a client will request a ServiceManager:
1. the client is binding an agent in order to cornrnunicate with a ServiceManauer the first time; or 2 the client has just got a system exception when a~empting to communica[e with a CA 02263~71 1999-02-16 ServiceManager.
The service is designed on the assumption that most ServiceManagers are available when required (ie. case 1 above is the usual case). This means that the service does not check the availability of ServiceManagers unless the client explicitly requests that it do so. Clients will only request a check when they have reason to think that a ServiceManager has become unavailable (ie case 2 above). There would be little point in using a cache when responding to requests for ServiceManagers if all ServiceManagers were checked for availability. However, since there is typically no availability check made, a ServiceLocator can use a cache to good effect when responding to requests. Each ServiceLocator therefore 10 m~int~in.c a local in-memory cache which stores tuples: (service, name, ServiceManager) obtained from the results of previous attempts to locate ServiceManagers. The tuple stored in the cache corresponds to the first response to a broadcast request for managers of the service.
Clients set the parameter testRequired to true when they have had a communications failure else thev set it to false. Processing a getBestManager request then depends on the value of the testRequired pararneter as described below.
When the getBestManager operation is invoked, the following steps are used to deterrnine which ServiceManager to return:
- If there is a ServiceManager for the specified service registered with the ServiceLocator then return it, otherwise;
20 - If there is an entry in the cache for the specified service then return it, otherwise;
- Broadcast a getLocalManager request to all peer ServiceLocators. The testRequired parameter is set to true for these operations because the extra time to contact the ServiceManager is not very significant given that a remote broadcast is being done. The first response obtained is placed in the cache and returned to the client.
2~ When the getBestManager operation is invoked, the following steps are used to determine which ServiceManager to return:
- If there is a ServiceManager for the specified service registered with the ServiceLocator then attempt to cornrnunicate with it (say get its location attribute).
- If it can be contacted then return it, otherwise:
30 - If there is an entry in the cache for the specified service then attempt to communicate with it. If it can be contacted then return it otherwise invalidate the cache entry and:
- Broadcast a getLocalManager request to all p ServiceLocators. The testRequired parameter is set to true for tnese operations The first response obtained is placed in the cache and returned to the client.
3 ~ ~ ServiceManager Defining a peer group can be considered as follows. The members of a peer group of ServiceManagers can be obtained by invoking the getAllRegisteredManagers operation on anv ServiceLocaton specifving the appropriate scrver name. This operation uses a broadcast to locate the ServiceManagers and is therefore a potentially expensive operation.

CA 02263~71 1999-02-16 It is typically members of a particular peer group themselves who need to determine the other peers in the group. Therefore, as an alternative to the expensive getAllRegisteredManagers operation, ServiceLocators enable ServiceManagers to store their own peer groups. They do this by sending notifications whenever members join or leave the 5 peer group.
If ServiceManagers wish to m~int~in thcir own peer group membership lists then they need to register as notification receivers with their local ServiceLocator as notification producer. ServiceLocators distribute the knowledge of when members join and leave the groups using the notifyAddManager and notifyRemoveManager operations, as o shown diagrammatically in FIG. 18. The steps in the distribution are as follows:
1. ServiceManager for location X 1 l 0 registers the location with the local ServiceLocator 1 1 1;
2. The local ServiceLocator l l l invokes a notifvAddManager process on each of its peer Service~ocators 11 2, 11 3 and 114;
15 3. ServiceLocators sends notification cont~ining the ServiceManager's object reference to the notification service 115, which notification is received by peer ServiceManagers 1 16 and l 17.
ServiceManagers can then build a cache of their peers using getAllRegisteredMa~agers to get initial contents and using notifications to m~int~in it.
20 Summ~ry It will be appreciated from the foregoing that the development tool of the invention provides the following benefits for developers of large scale object oriented systems:
(a) reduced training costs for development tearn members - few have to be CORBA
2~ literate, fewer still need to be CORBA expert;
(b) design time is reduced, because the development tool includes pacl~a_ ed usage models to match particular needs;
(c) coding time is reduced because the code generator and ~ibraries provide proven reliable modules, and the tool presents a simplified interface to the client and server 30 application code, and (d) test time is reduced because developers write less of the code, the code they do write is less complex and they are guided away from erroneous usa_e.
The system development method and tool of Ihe invention allows developers to focus on providing the functionality of an application. rather than on the distributed, 3~ object oriented infrastructure required to deliver the applications services. It is also important to understand that the system development tool and method of the invention may be applied with substantially equal benefits to distributed object oriented svstem architectures other than OMG's CORBA. The svstem development tool is suitable for adding distribution to an existinP computer application to extend its performance and scalability or for transparentl~

federating systems to provide unified access methods. The system development tool is particularly suited to developing new systems for distributed telecommunications or financial services.
Throughout the specification the aim has been to describe preferred 5 embodiments of the invention rather than iimiting the invention to one particular embodiment or specific collection of features.

Claims (38)

1. A development tool for building a large scale distributed object oriented computer system, which system includes a plurality of clients, a plurality of servers, and a distributed object infrastructure for communicating client requests for services to servers, said development tool comprising:
(a) a series of templates providing predetermined object design patterns, including -(i) an object identity pattern, facilitating unique identification of each object, (ii) a collection pattern, facilitating the logical grouping of objects having some commonality, (iii) a group operation pattern, facilitating operations targeted at a set of objects, (iv) a friend pattern, facilitating association of one object with another object independently of clients, and (v) a partition pattern, facilitating physical grouping of objects for system performance purposes;
(b) a code generator arranged to generate, from an object oriented system model created by a user for defining desired server processes to be requested by client processes and incorporating selected ones of the design patterns, the following -(i) a client access layer for each client process, isolating client application code from the distributed object infrastructure, (ii) a server access layer for each server process, isolating server application code from the distributed object infrastructure, and (iii) a stub portion of the server application code for implementing each service, including provision for the user to integrate an implementation of server semantics.

2. The development tool as claimed in claim 1 further comprising a set of basic distributed services including a service finder service for the discovery of the services available in the system.

3. The development tool as claimed in claim 1 or claim 2 wherein the series of templates may further include one or more of the following object design patterns:
(vi) a federation pattern, being a set of collections cooperating to provide an improved service;
(vii) a unified service pattern, facilitating the optimal choice of a collection from the set within a federation; and/or (viii) a bulk operation pattern, facilitating multiple operations on a particularly identified object.

4. The development tool of any one of claims 1 to 3 wherein object identity is an attribute of an object and is represented using a structured name.

5. The development tool of claim 4 wherein the object identity attribute allows for object replication.

6. The development tool of any one of claims 1 to 5 wherein objects grouped into a collection are known as members and knowledge of a collection's members is kept either explicitly or implicitly.

7. The development tool of any one of claims 1 to 6 wherein a set of objects to which a group operation applies is known as the scope of the group operation, which scope may be explicitly or implicitly defined.

8. The development tool of claim 7 wherein an explicitly defined group operation is based on an underlying operation supported by objects comprising the service and a list of object identifiers defines the scope of the group operation.

9. The development tool of claim 7 wherein an implicitly defined group operation is not based on an underlying operation and a client specified filter or rule is applied to the objects to define the scope of the group operation.

10. The development tool of any one of claims 1 to 9 wherein two objects are friends if they do not appear associated to clients via the distributed object infrastructure, but the two objects appear associated to one another.

11. The development tool of any one of claims 1 to 10 wherein a partition is a physical grouping of objects, wherein each object in the system is associated with only one partition, which partition corresponds to a set of computer hardware.

12. The development tool of any one of claims 3 to 11 wherein collections in a federation are able to delegate operations to each other in order to provide a faster, more extensive or more reliable service.

13. The development tool of any one of claims 3 to 12 wherein a unified service is a federated collection wherein a predetermined sub-set of collections is transparent to clients requesting the unified service.

14. The development tool of any one of claims 1 to 13 wherein the client access layer includes agent classes to access objects which implement a service and other classes to represent data structures manipulated by the agent classes.

15. The development tool of claim 14 wherein the agent classes effectively separate interface code for the distributed object infrastructure from the client application code and encapsulate an object's identity, interface and means to address its implementation(s).

16. The development tool of any one of claims 1 to 15 wherein the server access layer includes service managers for managing objects with respect to any partitions and allows for the creation and deletion of objects.

17. The development tool of claim 16 wherein the server access layer includes adapter classes for providing access to objects which implement a service.

18. The development tool of any one of claims 2 to 17 wherein the set of basic distributed services further includes a file replication service for replicating files within the system.

19. The development tool of any one of claims 1 to 18 wherein the system utilizes the CORBA standard such that:
(a) the distributed object infrastructure comprises an object request broker (ORB);
(b) the object oriented system model is modeled using CORBA concepts; and (c) the server interface is generated in accordance with CORBA interface design language (IDL).

20. A method for the development of a large scale distributed object oriented computer system, which system includes a plurality of clients, a plurality of servers, and a distributed object infrastructure for communicating client requests for services to servers, said development method including the steps of:
(a) selecting one or more templates, from a series of templates for predetermined object design patterns, which include -(i) an object identity pattern, facilitating unique identification of each object, (ii) a collection pattern, facilitating the logical grouping of objects having some commonality, (iii) a group operation pattern, facilitating operations targeted at a set of objects, (iv) a friend pattern, facilitating association of one object with another object independently of clients, and (v) a partition pattern, facilitating physical grouping of objects for performance purposes;
(b) creating an object oriented system model for defining desired server processes to be requested by client processes, which model incorporates selected object design patterns; and (c) generating, from the object oriented system model, code modules for the following -(i) a client access layer for each client process, isolating client application code from the distributed object infrastructure, (ii) a server access layer for each server process. isolating server application code from the distributed object infrastructure, and (iv) a stub portion of the server application code for implementing each service, including provision for the user to integrate an implementation of server semantics.

21. The system development method as claimed in claim 20 further including the step of providing a set of basic distributed services including a service finder service for the discovery of the services available in the system.

22. The system development method as claimed in either claim 20 or claim 21 wherein the series of templates available for selection in step (c) may further include one or more of the following object design patterns:
(vi) a federation pattern, being a set of collections cooperating to provide an improved service, (vii) a unified service pattern. facilitating the optimal choice of a collection from the set within a federation, and/or (viii) a bulk operation pattern, facilitating multiple operations on a particularly identified object.

23. The system development method as claimed in any one of claims 20 to 22 including the step of representing the identity attribute of an object by using a structured name.

24. The system development method as claimed in claim 23 wherein the object identity attribute allows for object replication.

25. The system development method as claimed in any one of claims 20 to 24 including the step of referring to objects grouped into a collection as members and keeping knowledge of a collection's members either explicitly or implicitly.

26. The system development method as claimed in any one of claims 20 to 25 including the step of referring to a set of objects to which a group operation applies as the scope of the group operation, which scope may be explicitly or implicitly defined.

27. The system development method as claimed in any one of claims 20 to 26 including the step of arranging friend objects such that they do not appear associated to clients via the distributed object infrastructure, but they appear associated to one another.

28. The system development method as claimed in any one of claims 20 to 27 including the step of assigning a physical grouping of objects to a partition wherein each object in the system is associated with only one such partition, which partition corresponds to a set of computer hardware.

29. The system development method as claimed in any one of claims 22 to 28 including the step of allowing collections in a federation to delegate operations to one other in order to provide a faster, more extensive or more reliable service.

30. The system development method as claimed in any one of claims 22 to 29 including the step of arranging a predetermined sub-set of collections within a federated collection to be transparent to clients requesting unified service.

31. The system development method as claimed in any one of claims 20 to 30 including the step of step of generating a client access layer includes the step of generating agent classes to access the objects which implement a service and other classes to represent data structures manipulated by the agent classes.

32. The system development method as claimed in claim 31 wherein the step of generating agent classes includes the steps of separating interface code for the distributed object infrastructure from the client application code and encapsulating an object's identity.
interface and providing means to address its implementation(s).

33. The system development method as claimed in any one of claims 20 to 32 wherein the step of generating a server access layer includes the provision of service managers for managing objects with respect to any partitions, which service manager facilitates the creation and deletion of objects.

34. The system development method as claimed in claim 33 wherein the step of generating a server access layer includes the provision of adapter classes to provide access to objects that implement the service.

35. The system development method of any one of claims 21 to 34 wherein the step of providing a set of basic distributed services further includes providing a file replication service for replicating files within the system.

36. A large scale object oriented system built using the development tool of any one of claims 1 to 19 or according to the method of any one of claims 20 to 35, wherein the object oriented system includes a common administration interface.

37. The large scale object oriented system of claim 36 wherein the commonadministration interface facilitates remote management of all unified services in the system, including the provision of test, enable, disable, backup and restart functions.

38. The large scale object oriented system of claim 37 wherein the administration interface also supports a set of attributes for which each unified service may be queried, including one or more of version number, copyright information, status, host machine, process identity or like attributes.