1
`
`GOOGLE-1017
`Google Inc. v. Micrografx LLC
`IPR2014-00532
`
`

`

`FOR THE PURPOSES OF INFORMATION ONLY
`
`CodcsusedtoidendfyStatespaItytothePCTmthefiontpagesofpalnphletspubUshingimemational
`applications under the PCT.
`
`GA
`
`§5§§EEEE=E§QEE‘WFES
`
`much
`Amn-
`Barbuda-
`Belgium
`
`ll
`36
`3.]
`IR
`BY
`CA
`Cl"
`CG
`CI!
`CI
`CM
`CN
`(3
`CZ
`DE
`DK
`['5
`II
`[R
`
`‘5U 0mm
`
`as
`
`Demon-tic People'l ”public
`of Kan
`chublic of Kam-
`in
`Sri Linh
`Luxembourg
`Livia
`
`WW
`
`2
`
`

`

`“KHKNWKS
`
`PCWCAMMMSB
`
`SYSTEM AND METHOD FOR PROVIDING INTEROPERABILITY AMONG
`
`HETEROGENEOUS OBJECT SYSTEMS
`
`1
`
`.
`
`J E' J:
`
`5
`
`10
`
`15
`
`The present invention relates to object-oriented
`software systems and related methods for digital computers.
`' W
`
`Using object-oriented software techniques, software
`applications' for digital computers are created by combining
`software objects.
`To facilitate this process, object-
`oriented software systems typically provide an architecture
`specification, called the object model, which enables all
`objects developed to the specification to work together
`seamlessly in an application.. Examples of object models
`would include the Object Management Group's Common Object
`Request Broker Architecture (CORBA), and Microsoft's Common
`Object Model
`(COM.)
`Such systems also typically provide
`software, called the object system, which implements the
`basic features provided for in the object model.
`
`20
`
`25
`
`30
`
`3S
`
`There are numerous object systems,
`some very general in
`- nature such as Microsoft's Object Linking and Embedding
`(OLE)
`(which follows the COM object model). or IBM's
`Distributed System Object Model
`(DSOM), and Iona's ORBIX,
`(which both follow the CORBA object model).
`See for
`
`the OLE 2 Programmers Reference, Volume 1 and 2,
`example:
`Microsoft Press, 1994;
`the IBM SOMobjects Developer Toolkit
`V2.0, Programmers Reference Manual, 1993;
`Iona ORBIX,
`Advanced Programmers Guide, 1994; and The Common Object
`Request Broker: Architecture and Specification Ch. 6., OMG,
`1991;
`these references are hereby incorporated herein by
`reference.
`
`Other object systems are designed to provide specific
`functionality,
`for example,
`in areas such as groupware or
`relational database - e.g. Lotus Notes. Still other object
`systems are specific to particular to applications - e.g.
`
`SUBSTITUTE SHEET (RULE 26)
`
`3
`
`

`

`“KHMNUMS
`
`PCUCA%MWBH
`
`Novell's AppWare Bus, Hewlett Packard's Broadcast Message
`Server, and Microsoft Visual Basic's VBX object mechanism.
`
`See for example:
`
`the Lotus Notes Programmers Reference
`
`Manual, 1993;
`
`the Novell Visual AppBuilder Programmers
`
`5
`
`Reference Manual, 1994;
`
`the Hewlett Packard Softbench BMS,
`
`Programmers Reference Manual, 1992; and Microsoft Visual
`Basic 3.0 Professional Features Book 1, Control Development
`
`Guide, 1993;
`
`these references are also hereby incorporated
`
`herein by reference.
`In creating a software application it is desirable to
`
`10
`
`combine objects from various object systems, because
`
`different object systems are best suited to different tasks,
`
`and because the best solution is usually built from the best
`parts (i.e. objects.) However, objects from various object
`systems don't naturally work together for a number of
`reasons.
`
`15
`
`Object systems are rendered incompatible due to
`
`differences in the means by which objects are created,
`
`methods are called and properties are set in each object
`
`20
`
`including differences in the fundamental mechanisms
`system,
`used as well differences in low-level calling conventions
`
`such as the physical layout of types and classes.
`For
`example at the fundamental level,
`some object systems, such
`as COM, use direct C++ calling mechanisms. Others such as
`25 DSOM pre-process source code so that in place of a direct
`in
`call, a function from the object system is called which,
`turn, returns a pointer to the real method. This pointer is
`dereferenced to actually call the method. Still other
`object systems such as OLE Automation provide specialized
`functions developers must use to call methods (this is often
`referred to as a Dynamic Invocation Interface or DII). These
`
`30
`
`functions take the method to be called as an argument, as
`well as the method's arguments (usually packed into a
`particular format), and they call the method for the
`3S developer. There are numerous other broad differences and
`
`4
`
`

`

`
`
`WO 96/08765
`
`PCT/CA95I00513
`
`variants in fundamental calling mechanisms.
`
`Each of these
`
`fundamental mechanisms also differ in detail.
`
`For example,
`
`CORBA requires an environment pointer argument
`
`(and has an
`
`optional context argument), while other object systems do
`not.
`
`In addition to the vast differences in fundamental
`
`calling mechanisms,
`
`there are many differences in low—level
`
`calling conventions, sometimes referred to as procedure
`
`calling conventions.
`
`For example, different object systems
`
`handle the return value from methods differently when the
`
`type of the return value is a float or a structure.
`
`In one
`
`case the value may be returned on the processor stack, while
`
`in another the value may be placed in a register. Thus,
`
`using the return value of a method from a different object
`
`system would result in an error. Other examples of
`
`differences in procedure calling conventions would include
`
`how structures are packed into memory, and how arguments are
`
`placed on the stack.
`
`Various object systems also support various types which
`
`may not be compatible with other object systems.
`
`Simple
`
`examples of types include language types such as integers,
`
`floats, etc. More complex language types include arrays,
`
`strings, and objects. There are also semantic types such as
`
`"variable types" like the CORBA Any, and the COM VARIANT.
`
`Semantic types differ from language types in that they have
`
`a particular semantic meaning to the system. While certain
`
`semantic types may conceptually mean the same thing among
`
`various object systems,
`
`their corresponding language
`
`representation and implementation may be entirely different.
`
`A common example is strings.
`
`In COM, strings are
`
`represented using a "BSTR"
`
`(a non-NULL terminated string
`
`which contains length information), while in CORBA, strings
`
`are the traditional C language byte array (NULL terminated
`
`with no length information). As a result, a COM object
`
`couldn't pass a BSTR to a CORBA object because any functions
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`5
`
`

`

`W0 96/08765
`
`PCT/CA95/00513
`
`that operate on strings, such as copying and comparison,
`
`used in the CORBA object would fail. Likewise, while
`
`"variable types" such as the CORBA Any and the COM VERIANT
`
`“mean" the same thing,
`
`they aren't compatible.
`
`In addition, object systems have various rules about
`
`lifecycle management which may be incompatible.
`
`The term
`
`lifecycle management refers to the process required when
`
`creating, storing, and deleting objects.
`
`For example, COM
`
`requires developers to perform reference counting so objects
`
`10
`
`can be automatically deleted. Relational databases have
`
`much more sophisticated lifecycle management, while CORBA
`
`has only very simple lifecycle management with no reference
`
`counting.
`
`The above issue of lifecycle management is challenging
`
`15
`
`because often, objects are passed as arguments to methods.
`
`Consider the case where an object in one object system calls
`
`a method of an object in a foreign object system and passes
`
`an object
`
`(from its object system)
`
`in as an argument to the
`
`method.
`
`Since the foreign object system only understands
`
`20
`
`its own objects,
`
`the object argument must be dynamically
`
`converted to a corresponding object in the foreign object
`
`In other words, a new object must be created in the
`system.
`foreign object system to match the original object passed in
`
`as an argument. All such dynamic lifecycle management —
`
`25
`
`object creation, with its corresponding object destruction —
`must be handled properly if object system interoperability
`
`is to work.
`
`Another aspect of object system interoperability is
`
`differences in exception and error handling among object
`
`3O
`
`systems. Errors or exceptions encountered within the code
`for an object typically must also be dealt with in the
`
`If the two objects are from
`object which called the code.
`different object systems, and the error handling mechanisms
`
`are incompatible, software failure may result.
`
`35
`
`Various object systems provide different ways to
`
`6
`
`

`

`
`
`WO 96/08765
`
`PCT/CA95I00513
`
`dynamically query for information about objects. This
`
`functionality is required for object systems that provide a
`
`general macro script recording facility as well as for
`
`object systems that provide distributed computing
`
`capabilities.
`
`See for example Ch. 1-3 of Microsoft's OLE 2
`
`Programmers Reference Volume 2, Apple's Inside Macintosh:
`
`Interapplication Communication Ch.
`
`8
`
`(hereby incorporated
`
`herein by reference), or the Object Management Group's The
`
`Common Object Request Broker: Architecture and Specification
`
`Ch. 6.
`
`Thus,
`
`incompatibilities in the mechanisms to query
`
`for information about objects results in significant
`
`restrictions in the ways that objects may be used in other
`
`object systems.
`
`As mentioned previously, object systems each have
`
`different design goals. As a result, each typically has
`
`functionality that isn't available in other object systems.
`
`Two examples of this are: CORBA namespaces (which COM
`
`doesn't have); and COM objects supporting multiple
`
`interfaces (which CORBA doesn't have).
`
`Software errors can
`
`result if an object is asked to perform some action that is
`
`only available in another object system.‘
`
`In summary then, a sought after goal has been to
`
`provide interoperability among various object systems.
`
`Different object systems place different requirements on
`
`objects, so specialized software systems are required to
`
`enable interoperability.
`
`The prior art includes approaches
`
`to providing interoperability between object systems. Three
`
`solutions are of interest:
`
`stub.function wrappers; a common
`
`wire protocol; and dynamic converters.
`
`with the stub function wrapper method, an automated
`
`tool is used to generate stub functions which ”wrap" objects
`
`in code that follows the specification of another Object
`
`model. That is,
`
`the tool creates an object class in the
`
`foreign object system that contains only the code necessary
`
`to forward requests to the native object. This "stub“ code
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`7
`
`

`

`WO 96108765
`
`PCI‘ICA95100513
`
`The stub
`is then compiled and linked into an application .
`function method is exemplified by the COM interoperability
`
`provided with IBM's DSOM for Windows. Using it, developers
`who have DSOM objects and want to use them from within COM
`
`use an automatic tool to generate source code for
`
`The source code for the COM
`corresponding COM objects.
`objects is simply a set of stub functions which forward
`calls to DSOM.
`For example, when the COM application calls
`
`a method of the COM object,
`
`the method simply re—calls the
`
`10
`
`DSOM version of the method.
`
`One automated tool to create a set of stub function
`
`wrappers provides one—way interoperability between two
`object systems.
`To provide two—way interoperability — as is
`required for dynamic lifecycle management, a second tool has
`to be written.
`If an additional object system is to be
`
`supported, and full interoperability among all three systems
`is required, an additional four automated tools must be
`written.
`In fact,
`the number of such tools required for
`
`interoperability among N object systems is Nq-N In
`addition, for each object c1ass,I?-N versions of stub
`wrapper functions must be generated, managed and supported.
`Given that any particular application will have hundreds of
`
`Furthermore,
`this is a significant disadvantage.
`classes,
`this method provides no support for the remainder of
`
`interoperability issues such as dealing with type
`conversions,
`low level calling convention differences,
`lifecycle management differences, differences in error and
`exception handling, querying, or.functionality differences.
`As a result, users of the object must code such conversions
`into their software manually, making it apparent that the
`object is from another object system (i.e.
`the object is
`clearly not indistinguishable from native object.) Finally,
`support for new object systems is not dynamic, so code must
`
`15
`
`20
`
`25
`
`30
`
`be recompiled and relinked.
`Dynamic converters are designed to provide
`
`35
`
`8
`
`

`

`WO 96108765
`
`PCTICA95N0513
`
`interoperability between two object systems that both
`
`support a dynamic invocation interface (DII).
`
`A DII
`
`"dynamically invokes" methods. That is, a DII is a set of
`
`functions that will call an object's methods for the
`
`5 developer dynamically, and pass arguments to the methods
`
`using a pre-defined convention, rather than requiring that
`
`the call be compiled into the application.
`
`A dynamic
`
`converter is a hard-coded map between two DIIs. When a
`
`method is called,
`
`the converter code packages the
`
`10
`
`information into a format suitable for the DII of the second
`
`object system,
`
`then calls the method.
`
`As with the stub wrapper mechanism,
`
`this approach
`
`requires DF—N converters in order to support N object
`
`systems.
`Furthermore, dynamic converters only work with
`15 object systems that support a DII. Moreover because they
`
`use a DII their performance suffers. And, as with the stub
`
`wrapper method,
`
`this method provides no general support for
`
`the remainder of interoperability issues such as dealing
`
`with type conversions, differences in error and exception
`
`20 handling, querying, or functionality differences — thereby
`
`being unable to provide foreign objects which are
`
`indistinguishable from native objects.
`
`The common wire protocol method is designed to work
`
`with distributed object systems,
`
`that is, object systems
`
`25 whose objects may be located on different computers having
`
`different machine architectures. With the common wire
`
`protocol method, object systems which share a common
`
`underlying distributed computing system (DCS) - the "common
`
`wire“ — can interoperate The common distributed computing
`
`30
`
`system enables object systems to transfer language data
`
`types, because a non NLN language data type transfer
`
`mechanism is provided by the DCS.
`
`This approach addresses the issue of low level calling
`
`conventions and provides mapping of low level data types.
`
`35 The complexity of supporting N object systems depends
`
`9
`
`

`

`WO 96/08765
`
`PCT/CA95I00513
`
`directly upon whether the object systems share the same
`
`object model.
`
`If so,
`
`there is no need to provide
`
`interoperability between fundamental calling convention
`
`differences, semantic type differences,
`
`lifecycle management
`
`differences, differences in error and exception handling, or
`
`functionality differences, and each object system requires
`
`only to support the DCS. This case would be exemplified by
`
`interoperability among various CORBA object systems such as
`
`IBM's DSOM, Iona's Orbix, Hewlett Packard's DOMF, etc. which
`
`10
`
`can each use the Open Software Foundation's Distributed
`
`(DCE).
`Computing Environment
`If interoperability is among object systems that don't
`
`share a common object model,
`
`the approach requires NLN
`
`converters to deal with the remaining issues.
`
`Furthermore,
`
`15
`
`this method doesn't work at all if the object systems which
`
`must interoperate are not built on top of a shared
`
`distributed computing system. And the approach is very
`
`resource intensive due to the reliance on a DCS. While it
`
`handles transfer of simple data types, it provides no
`
`20
`
`general mechanism to handle more complex type conversions,
`
`lifecycle management differences, differences in error and
`
`exception handling, querying, or functionality differences —
`
`reSulting in similar deficiencies to other prior art.
`
`Along with the above prior art directly addressing the
`
`25
`
`issue of object system interoperability,
`
`there is other
`
`prior art addressing various elements of the problem, each
`in a different context.
`
`There have been a number of systems that have dealt
`
`with the issue of mapping between different low-level
`
`30
`
`calling conventions.
`
`In U.S. Pat. No. 4,736,321, a method
`
`was described wherein an interactive language workspace,
`
`APL, was able to call external language procedures.
`
`In it,
`
`FORTRAN functions were declared to the APL environment, and
`
`the APL environment mapped the APL calls and arguments into
`
`35
`
`FORTRAN calling conVentions.
`
`The method in this patent is
`
`10
`
`10
`
`

`

`
`
`WO 96/08765
`
`PCT/CA95I00513
`
`specific to the interactive APL language environment and
`provides unidirectional access from APL to multiple
`languages (FORTRAN and Assembler).
`The method doesn't
`
`support bi-directional access among any number of languages,
`
`and doesn't work among compiled language code systems.
`
`A similar mechanism was described for Prolog in U.S.
`
`Pat. No. 5,274,821 wherein a Prolog language procedure could
`
`In this
`call external language functions and vice versa.
`patent,
`the mapping was accomplished using a table driven
`
`approach. That is, mapping of Prolog to multiple languages,
`
`and mapping multiple languages to Prolog was accomplished by
`describing the low level calling convention to the system in
`
`a table. This information was used at execution time to
`
`dynamically perform the mapping. As with the method in U.S.
`
`Pat. No. 4,736,321,
`
`this method is specific to an
`
`interactive language environment,
`
`in this case, Prolog.
`
`It
`
`provides bi-directional mapping from Prolog to N languages,
`but not among N languages.
`The method doesn't work among
`compiled language code systems, and in any case would
`
`10
`
`15
`
`20
`
`require bP-N conversion tables.
`
`A mechanism was described in U.S. Pat. No. 5,210,876
`
`wherein an interpreter is able to call a compiled procedure,
`
`which in turn, calls an interpreted procedure.
`
`The means
`
`was to generate a new intermediate compiled procedure which
`
`is called by the original compiled procedure.
`
`The new
`
`compiled procedure was then dynamically linked with the
`
`original compiled procedure.
`
`The new generated procedure
`
`converted arguments to the format required by the
`
`interpreter,
`
`then called the interpreted procedure.
`
`Finally,
`
`the results were converted back to those required
`
`by the compiled language. As with other prior art,
`
`this
`
`patent facilitates an interpreted environment calling
`compiled language code.' And as with other prior art, NLN
`
`code generators would be required to support procedure
`
`calling convention conversion among N systems.
`
`25
`
`30
`
`35
`
`11
`
`11
`
`

`

`W0 SIG/08765
`
`PCI'ICA95I00513
`
`_10-
`
`U.S. Pat. No. 5,097,533 describes a method for
`
`interfacing various pre-determined computer languages to a
`
`single software system.
`
`In it, code is written for each
`
`language to map from the API in the language to a single API
`
`5
`
`for the underlying software system. This patent maps
`
`procedure calling conventions from N languages to one by
`
`writing code to perform the mapping for each.
`
`The method
`
`does not work for conversion among N language conventions,
`
`and in any case would require NhN code blocks to be
`
`10 written.
`
`In U.S. Pat. No. 5,146,593, a method is described
`
`wherein a single software interface is used to call a
`
`plurality of procedures.
`
`In fact,
`
`this is but one example
`
`of a DII - a DII designed for mapping to different
`15 programming languages.
`In it, the method uses tables to
`describe the low level calling conventions of the particular
`
`language.
`
`The user (i.e.
`
`the software developer wishing to
`
`make the calls) links the DII interface with their
`
`application and uses it to make all their calls by passing
`it a procedure identifier, and data structures in a
`
`20
`
`predefined format.
`The method doesn't support
`interoperability among N language calling conventions, and
`
`would also require NhN tables should the approach attempt
`
`to be extended for that purpose.
`
`25
`
`The above patents share the fact that they are designed
`
`to provide a mechanism to deal with the differences between
`low-level calling conventions of various languages. With
`
`the exception of U.S. Pat. No. 5,210,876 they each provide a
`
`means of converting various language types as well.
`
`30 However,
`
`they don't address the issue of differences between
`
`they each a
`In fact,
`high level calling conventions.
`provide a different high level calling convention,
`so they
`have no need to. Nor do they provide any support for
`
`mapping between semantic types.
`Other patents,
`for example U.S. Pat. No. 5,187,787 have
`
`35
`
`12
`
`12
`
`

`

`WO 96108765
`
`PCI'{CM/00513
`
`- 11 _
`
`dealt with the issue of mapping between semantic types.
`
`In
`
`this patent, mapping between semantic types was but one
`
`element of a larger system used to provide a communications
`
`interface which decoupled two software applications.
`
`In it,
`
`the semantic types used in the communication were designed
`
`by to be self-describing.
`
`The patent teaches that the
`
`semantic description must be separated from the data
`
`representation for interoperability. Further, developers
`
`use a system API to access data, which may be located
`
`elsewhere, and in another semantic form. Thus,
`
`the
`
`mechanism requires explicit knowledge on the part of the
`
`developer to use the decoupled data, and is analogous to a
`
`single DII, with the same consequent limitations..
`
`In U.S. Pat. No. 5,278,978, a method was described to
`
`transfer information between two databases. As a part of
`
`the system, a mechanism was described to map between both
`
`language types and semantic types.
`
`Each language type was
`
`tagged with a canonical identifier called a marker
`
`descriptor. Likewise, separately, each semantic type was
`
`tagged with a canonical identifier called a type definition.
`
`When data was received from another database,
`
`the
`
`descriptions were used to perform a conversion.
`
`Each
`
`database was required to have predefined descriptions of all
`
`other machine environments and semantic types,
`
`i.e.IW—N
`
`conversion descriptions, because conversion was performed at
`
`the receiving database.
`
`W
`
`This invention provides in some embodiments a single
`
`system in a digital computer enabling software objects from
`
`multiple heterogeneous object systems to interoperate bi—
`
`directionally and to be combined in the creation of a larger
`software system. Objects from a foreign object system are
`
`unmodified, yet appear to be native to the object system in
`
`which they are used or accessed.
`
`Support for additional
`
`object systems may be added dynamically while the system is
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`13
`
`13
`
`

`

`WO 96/08765
`
`PCT[CASS/00513
`
`- 12 -
`
`executing,
`
`thereby adding bi—directional interoperability
`
`with all other Supported object systems.
`
`A mechanism is
`
`also provided whereby features in one object system may be
`
`supported in other object systems without
`
`the necessity of
`
`modifying objects.
`
`I
`
`For a foreign object
`
`to be used in another object
`
`system,
`
`the system of these embodiments constructs a native
`
`proxy object (indistinguishable from other native objects)
`
`for the real foreign object.
`
`The proxy object contains an
`
`identifier to the real object, as well as a pointer to a
`
`software description of how to access and manipulate the
`
`object - e.g. how to call its methods, set its properties,
`
`and handle exceptions. When the proxy object is '
`
`manipulated, it follows the instructions in the software
`
`description which,
`
`in turn, results in the corresponding
`
`manipulation of the foreign object.
`
`The system of these embodiments provides a number of
`
`object—oriented frameworks with default implementations.
`
`There are frameworks to:
`
`dynamically locate objects in an
`
`object system-specific or uniform namespace;
`
`describe the
`
`characteristics of an object class or instance;
`
`describe
`
`both semantic and language types;
`
`“execute" the software
`
`descriptions to forward manipulations of the proxy object to
`
`the real foreign object;
`
`handle errors and exceptions;
`
`create, copy, destroy, and manage the lifecycle of objects;
`
`and a framework to “export" object definitions — i.e.
`
`to
`
`make objects in one object system appear as object classes
`
`indistinguishable from native object classes temporarily or
`
`10
`
`15
`
`20
`
`25
`
`permanently in other object systems.
`
`3O
`
`In addition,
`
`there is a framework to add extra
`
`information to the description of any object class.
`
`Such
`
`added information is called a "mixin". When an object is
`
`manipulated in a way it doesn't support, for example if it
`
`is asked to return the middle element of a collection but it
`
`35
`
`doesn't support such a method,
`
`the system asks the mixins
`
`14
`
`14
`
`

`

`WO 96/08765
`
`PCI'ICA95/00513
`
`-13-
`
`associated with the object if they can support
`
`the request.
`
`If so,
`
`they take over and perform the request.
`
`In this way,
`
`a general mechanism is provided to extend the capabilities
`
`of objects in an object system with features of other object
`
`systems that they wouldn't naturally support.
`
`Extensions to the default implementations of each of
`
`the above frameworks are grouped by object system, and
`
`packaged into libraries called Object System Adapters
`
`(OSAs).
`
`OSAs can be dynamically loaded into the OSA
`
`10
`
`Registry framework of the system,
`
`thus adding everything
`
`necessary to dynamically support new object systems and
`
`previde full interoperability with other object systems.
`
`It will be obvious to those skilled in the art that the
`
`system may be used stand-alone, or embedded as an element of
`
`15
`
`a larger software system.
`
`Further embodiments of the invention are also provided:
`
`(A)
`
`a system and method to enable the creation of a
`
`“universal object", i.e. a single object which appears to be
`implemented in a plurality of object systems simultaneously,
`and which can dynamically change which object systems it
`
`20
`
`supports.
`
`Said system also enables the creation of objects
`
`in individual, application, and server configurations.
`
`Further, such objects may be based upon interpreted or
`
`compiled language technology;
`
`25
`
`30
`
`35
`
`(B)
`
`a system and method - either library—based or
`
`interactive — to enable the construction of object classes
`
`including the aforementioned "universal object", where such
`
`system in the creation of said object classes, may
`
`constitute a subclass of,
`
`incorporate, or embed instances
`
`of, objects from a plurality of object systems;
`
`(C)
`
`a system and method to enable object classes and
`
`objects to be relocated among applications and servers in
`
`one or more object systems while the applications and
`
`servers are executing, and without disruption of software
`
`utilizing said object classes and objects, even if it too is
`
`15
`
`15
`
`

`

`WO 96/08765
`
`PCT/CA95]00513
`
`-14-
`
`executing.
`
`The foregoing aspects of the invention may be more
`
`readily understood by reference to the following
`
`5
`
`detailed description, furnished in connection with the
`
`following drawings,
`
`in which:
`
`FIG. 1 is a simplified overview of a system (in
`
`use)
`
`in accordance with a preferred embodiment of the
`
`invention;
`
`10
`
`,
`
`FIG. 2 is an overview of the system architecture
`
`in accordance with a preferred embodiment of the
`
`invention;
`
`FIG. 3 shows Object System Adapters of Fig.
`
`2
`
`plugged into the Adapter Registry Framework;
`FIG. 4 shOws the description of a class with one
`
`15
`
`method and one property in accordance with the
`
`embodiment of Fig. 2;
`
`FIG. 5 shows a nested type description in
`
`accordance with the embodiment of Fig. 2;
`
`20
`
`FIG.
`
`6 shows the description of a method which
`
`follows the CORBA C language calling convention;
`
`FIG. 7 shows the description of a similar method .
`
`which is called using a Dynamic Invocation Interface;
`
`FIG. 8 shows the typical lifecycle of an object;
`
`25
`
`FIG.
`
`9 shoWs the process used to expose classes
`
`using the system of Fig. 2;
`FIG. 10 shows a typical proxy object in accordance
`with the embodiment of Fig. 2;
`'
`
`FIG. 11 shows individual, application, and server
`
`30
`
`configurations of "universal objects" in accordance
`with a preferred embodiment of the invention;
`FIG. 12a illustrates an example of the system
`
`16
`
`16
`
`

`

`WO 96108765
`
`PCT/CW5”
`
`-14a-
`
`enabling a universal object in an individual
`
`configuration; and
`
`FIGS. 12b and 12c illustrate application and
`
`server configurations respectively.
`5 REE—21W
`Fig. 1 shows a simplified overview of the system
`105 in use in a digital computer in accordance with a
`
`preferred embodiment of the invention. Process 101 is
`
`implemented using a first object system, referred to as
`the "native" object system, distinct from a second
`
`10
`
`object system in which
`
`17
`
`17
`
`

`

`WO 96/08765
`
`-
`
`-15-
`
`PCT/CA95I00513
`
`process 102, and object 103 are implemented.
`
`The second
`
`object system,
`
`implementing process 102 and object 103,
`
`is
`
`referred to as the "foreign" object system (foreign relative
`
`to the process 101 which is using the object 103).
`
`The
`
`system 105 has constructed a proxy object 100.
`
`The proxy
`
`object 100 appears indistinguishable from other objects
`
`implemented using the native object system in process 101.
`
`The proxy object 100 established by system 105 contains a
`pointer to the real object 103, as well as to a software
`
`10
`
`description 104, of how to access and manipulate the real
`
`object 103 - e.g. how to call its methods, set its
`
`properties, and handle exceptions. When process 101
`
`manipulates proxy object 100,
`
`the manipulations are
`
`intercepted by the system and forwarded to the real object
`
`15
`
`103.
`
`The system forwards the manipulation by following the,
`
`instructions in the software description 104, which,
`
`in
`
`turn, results in the corresponding manipulation of the real
`
`object 103.
`
`The system can follow the instructions in the
`
`software description 104 regardless of which object system
`
`20
`
`created it,
`
`thus resulting in a non-NhN approach to object
`
`system interoperability.
`Referring to Fig. 2,
`
`there is shown a simplified
`
`architecture diagram of the system in accordance with a
`
`preferred embodiment of the inyention. As described below,
`
`25
`
`applicants have successfully implemented this embodiment on
`
`a wide range of hardware platforms in a wide range of object
`
`systems.
`
`In the diagram,
`
`the triangular symbol 110
`
`indicates that items to its right are subclasses.
`
`The
`
`system includes nine frameworks as follows:
`
`30
`
`the Location and Enumeration Framework 1 to dynamically
`
`locate objects in an object system-specific or uniform
`
`namespace.
`
`Included in this framework is the ability to
`
`determine the characteristics of objects that have been
`
`located;
`
`18
`
`18
`
`

`

`
`
`
`
`WO 96/08765
`
`PCT/CA95I00513
`
`5
`
`10
`
`15
`
`the Forwarding Engine Framework 4 to I'execute" the software
`descriptions to forward manipulations of the proxy
`object to the real foreign object;
`the Error and Exception Handling Framework 5 to handle
`errors and exceptions;
`the Lifecycle Management Framework 6 to create, copy,
`destroy, and manage the lifecycle of objects; and
`the Object Exporting Framework 7 to “export" object
`definitions — i.e.
`to make objects in one object system
`appear as object classes indistinguishable from native
`object classes temporarily or permanently in other
`object systems.
`
`20
`
`there is the Mixin Support Framework 8 to
`In addition,
`add extra information to the description of any object
`class, enabling the support in all object systems of
`features found only in one object system. There is also the
`OSA Registry Framework 9 to load, unload, and manage Object
`System Adapters (OSAs) 10.
`The OSAs 10 are libraries that
`package together extensions to the default implementation of
`each aforementioned framework provided by the system. When
`25 added,
`they provide full bi—directional interoperability
`among all other object systems with corresponding OSAs
`loaded.
`
`A more detailed architecture diagram may be found in the
`Visual Edge Software Ltd. Class Registry Functional
`30 Specification included herein at the end of the Detailed
`Description of Specific Embodiments (pages (41-143).
`It
`
`SIBSTITUTE SHEET (RULE 26)
`
`19
`
`19
`
`

`

`WO 96/08765
`
`PCT[CASS/00513
`
`_ 17 _
`
`Fig.
`
`3 shows the OSA Registry framework 9 as well as a
`
`number of OSAs
`
`loaded.
`
`In this configuration,
`
`the system
`
`provides interoperability among the four object systems
`
`corresponding to the OSAs.
`A specific embodiment of the invention has been written
`in C++ and runs on Microsoft windows 3.1 and Windows NT,
`IBM
`
`05/2 and AIX, Sun Microsystems SunOS and Solaris, as well as
`
`on Hewlett Packard HP—UX. Object System Adapters have been
`
`IBM SOM and DSOM,
`implemented for Microsoft OLE Automation,
`Microsoft COM, and for the Microsoft Visual Basic VBX object
`
`10
`
`In addition, an OSA has been implemented for an
`system.
`interpretive language environment.
`The embodiment currently
`provides support for enabling objects implemented in pure
`C++ to be used in object systems with corresponding OSAs.
`
`15
`
`Likewise,
`
`the embodiment currently provides support for
`
`enabling software written in C (i.e. not written to any
`
`object system)
`
`to be us