[go: up one dir, main page]

WO2003009097A2 - Appareil et procede de creation d'une architecture de gestion des versions de classe - Google Patents

Appareil et procede de creation d'une architecture de gestion des versions de classe Download PDF

Info

Publication number
WO2003009097A2
WO2003009097A2 PCT/US2002/022603 US0222603W WO03009097A2 WO 2003009097 A2 WO2003009097 A2 WO 2003009097A2 US 0222603 W US0222603 W US 0222603W WO 03009097 A2 WO03009097 A2 WO 03009097A2
Authority
WO
WIPO (PCT)
Prior art keywords
class
version
classes
interface
software instructions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2002/022603
Other languages
English (en)
Other versions
WO2003009097A3 (fr
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
VIBRANT SOLUTIONS
Original Assignee
VIBRANT SOLUTIONS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by VIBRANT SOLUTIONS filed Critical VIBRANT SOLUTIONS
Priority to AU2002320557A priority Critical patent/AU2002320557A1/en
Publication of WO2003009097A2 publication Critical patent/WO2003009097A2/fr
Publication of WO2003009097A3 publication Critical patent/WO2003009097A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented

Definitions

  • TITLE APPARATUS AND METHOD FOR PROVIDING A CLASS
  • the Internet is operated by Internet Service Providers (ISPs). These ISP's provide access to literally millions upon millions of users who rely upon ISPs to provide rapid access to the many web sites that are available. The ISPs in turn rely upon the millions of users for income for access as well as income derived from advertising and other services. Thus the ISPs have a vested interest in keeping its users happy.
  • ISPs Internet Service Providers
  • Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks.
  • a typical server may have the following configuration: Dell 6450 w/4 Intel 700 MHz Xeon Processors
  • object-oriented programming concepts One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object-oriented programming concepts.
  • object-oriented programming is to create small, reusable sections of program code known as "objects" that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures.
  • the modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle.
  • by creating and re-using a comprehensive set of well- tested objects a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
  • Object-oriented programming is a method of program implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.
  • Object-oriented programming differs from standard procedural programming in that it uses objects, not algorithms, as the fundamental building blocks for creating computer programs. This difference stems from the fact that the design focus of object-oriented programming technology is wholly different than that of procedural programming technology.
  • the focus of procedural-based design is on the overall process used to solve the problem; whereas the focus of object-oriented design is on casting the problem as a set of autonomous entities that can work together to provide a solution.
  • the autonomous entities of object-oriented technology are, of course, objects.
  • Object- oriented technology is significantly different from procedural technology because problems are broken down into sets of cooperating objects instead of into hierarchies of nested computer programs or procedures.
  • the object system isolates the requester of services (client objects) from the providers of services (server objects) by a well defined encapsulating interface.
  • client objects sends request messages to server objects to perform any necessary or desired function.
  • the message identifies a specific method to be performed by the server object, and also supplies any required parameters.
  • the server object receives and inte ⁇ rets the message, and can then decide what service to perform.
  • a central concept in object-oriented programming is the "class."
  • a class is a template or prototype that defines a type of object.
  • a class outlines or describes the characteristics or makeup of objects that belong to that class.
  • objects can be created that belong to the class without having to rewrite the entire definition for each new object as it is created. This feature of object-oriented programming promotes the reusability of existing object definitions and promotes more efficient use of code.
  • Patent No. 5,974,428 discloses a class versioning and mapping system that allows a user to request a desired class without knowing which class version is the most recent or correct version for the desired class.
  • This class versioning and mapping system uses a version mapping mechanism to cross reference the requested class, select the most recent or best version of the requested class, and then return an object to the user that belongs to the selected class.
  • U.S. Patent No. 6,119,130 discloses a method and apparatus that allow schema version evolution to occur without requiring applications that expect older schema versions to be recompiled is provided.
  • each application that requests data is supplied the data in the format that the application expects.
  • a mechanism is provided for tracking the evolution of data types without losing information.
  • mechanisms are provided for determining the format expected by the application and the format in which the data is currently stored.
  • a mechanism is also provided for converting the data from the stored format to the expected format when the two formats do not match.
  • a data migration strategy is described in which data is gradually migrated to newer formats when the data is updated by applications that expect a more recent format than the format in which the data is currently stored.
  • the present invention is an architecture for versioning of classes of objects "on the fly,” that is, without recompiling.
  • the system and method of the present invention allows class versioning gradually over time as the system is used by system users.
  • the present invention accomplishes this by modeling the network and customers of, for example, a large ISP. It should be noted that while the example of an ISP is being used throughout this application, this is not meant as a limitation. Clearly the techniques, methods and architecture of the present invention can be used in any large data processing environment having disparate operating systems and application software.
  • Figures 1A-D illustrate the overall process of a first embodiment of the present invention.
  • Figure 6 illustrates top-level and mid-level class additions in accordance with a second embodiment of the present invention.
  • Figures 7 illustrates the consequences of bottom-level class additions in accordance with a second embodiment of the present invention.
  • Figure 8 illustrates the consequences of mid-level class changes in accordance with a second embodiment of the present invention.
  • the class versioning architecture of the present invention provides: on-the-fly addition and retraction of class attributes to improve the implementation of methods while providing backwards compatibility with older application clients; on-the-fly addition and retraction of class associations with other classes to add new functionality to existing methods; and on-the-fly addition of polymo ⁇ hic class operations to add new functionality for new application clients.
  • Figure 1A illustrates the first step in which Router vl 110 is created, committed
  • Figure IB illustrates the second step.
  • Router v2 120 is created, committed, and deployed.
  • Router#l is then transitioned from vl to v2 122.
  • the third step is illustrated in Figure IC, wherein Router v3 130 is created, compiled, and deployed with Router#l transitioned from v2 to v3 132.
  • the final step is illustrated in Figure ID, wherein Router v3 132 is rolled back to Router v2 122.
  • each persistence class is mapped into a table in relational database.
  • Each table of a subclass has all the columns inherited from its parent class in addition to its own columns.
  • One row is inserted into the table of the class when an instance is saved into database.
  • POET RSMAP utility creates a "polymo ⁇ hic" view for each parent class table, which 'unions' all the subclass tables.
  • this first embodiment relies on explicit class versioning scheme, it needs to run "TypeFilter" to substitute any occurrence of interface or class names in user code. Although this has the advantage of making the class versioning scheme transparent to users, it causes extra overhead in compilation and may introduce potential problems.
  • Figure 2 illustrates the consequences of top-level and mid-level class additions.
  • ForwardingDevicelf vl interface 212 and generates the ForwardingDevice _vl class 214 to implement that interface 212.
  • IpForwarder If _vl interface 222, and generates the IpForwarder _vl class 224 to both (1) implement that interface 222 and (2) inherit, via inheritance relationship 226, from the ForwardingDevice _vl class 214.
  • Figure 4 illustrates the consequences of a class change.
  • IpForwarder class 220' and hence changes IpForwarder If _vl interface 222 and IpForwarder _vl class 224 to generate IpForwarderIf_v2 interface 422, IpForwarder _v2 class 424 and inheritance relationships 426, 428
  • the meta model compiler must create new versions of all of the child classes that inherit from a changed parent class so the children pick up the changes to the parent.
  • the meta model compiler recurses down the tree until all the child classes (i.e., CiscoIpForwarderExample class 330) have new versions.
  • the meta model compiler must make the new version of each interface class inherit the interface of the previous version. As the meta model compiler recurses down the tree, it ensures that all the child interfaces, CiscoIpForwarderExamplelf interface 332 have new versions (i.e., v2) 432 that inherit 438 from the old version (i.e., v7) 332. Note that the second and subsequent versions of an interface inherit from both the interface above them in the tree and the previous version of the interface. Sometimes inheriting from the interface above is redundant, but doing so reduces code complexity.
  • FIG. 5A-D A second, and preferred embodiment of the class versioning of the present invention and instance transitioning is shown in Figures 5A-D. This second scheme also shows a typical scenario, which is not meant to cover all the cases of the present invention.
  • Figure 5A illustrates the first step in which Router vl 510 is created, committed, and deployed.
  • An instance Router#l 512 is created and the links 514 to Router#l are added.
  • the class name generated by the meta model compiler 511 does not contain any version information and that the generated class contains a static attribute of the class version.
  • the instance contains an instanceVid, of which it is created.
  • the present invention again uses a persistent storage database 516 with the POET SQL Object Factory or "FastObjects" object oriented database mapping software available from POET Software of San Mateo, California.
  • FIG. 5B illustrates the second step.
  • Router v2 520 is created, committed by meta model compiler 511, and deployed.
  • Router#l is then transitioned 522.
  • versionld in Router#l is "1". After transitioning, it is set to "2".
  • no new instance is created.
  • no link 514 is transitioned.
  • the third step is illustrated in Figure 5C, wherein Router v3 530 is created, compiled, and deployed. Router#l is transitioned 532.
  • a backup instance 538 is created to save the previous attribute values.
  • versionld of Router#l is set to "3", which is the latest version of that class.
  • Router#l is restored from the backup instance 538. Its versionld is set back to "2". After rollback, the backup instance 538 is removed and the v2 Router class is available to the running system. If links 514 are modified by the user after transition to a COMPILED (as opposed to commited) type, the original set of links can not be rolled back.
  • a "polymo ⁇ hic" view includes all the direct subclasses. Since the system does not allow user to subtype directly, the size of this view should not grow out of control.
  • the present invention preferably implements a mechanism to allow users to iterate through the query over multiple short transactions.
  • the system needs to backup transitioned instances to support "rollback" for non-committed types only to simplify testing.
  • it does not need to support instance backup and rollback since the user should not deploy a non- committed type. The user is no longer able to create instances of old versions of a type.
  • Figure 6 illustrates the consequences of top-level and mid-level class additions in the second embodiment of the present invention.
  • ForwardingDevicelf interface 612 and generates the ForwardingDevice class 614 to implement that interface 612.
  • Figure 7 illustrates the consequences of a bottom-level class addition in the second embodiment of the present invention.
  • creating a CiscoIpForwarderExample class 730 creates an interface 732 and a class 734 that implements it. It also creates the inheritance relationship 736 with IpForwarder class 624.
  • Figure 8 illustrates the consequences of a class change in the second embodiment of the present invention.
  • the meta model compiler must create new versions of all of the child classes that inherit from a changed parent class so the children pick up the changes to the parent.
  • the meta model compiler recurses down the tree until all the child classes (i.e., CiscoIpForwarderExample class 730) have new versions.
  • the meta model compiler must make the new version of each interface class inherit the interface of the previous version.
  • CiscoIpForwarderExamplelf interface 732 have new versions 832 that inherit 838 from the old version 732. Note that the second and subsequent versions of an interface inherit from both the interface above them in the tree and the previous version of the interface. Sometimes inheriting from the interface above is redundant, but doing so reduces code complexity.
  • an organization can obtain a unified view of customers, services and networks, understand the relationships among key business data, represent complex IP services, obtain a pre-built core model of networks, services and rules for easy customization, access integrated data at multiple levels of abstractions to solve a variety of business problems, allow easy adaptation to business dynamics and obtain superior data integrity at substantial cost savings over existing systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention concerne une programmation orientée vers l'objet et, plus spécifiquement, la création d'un environnement dans lequel un serveur d'applications peut continuer à fonctionner, tandis que son propriétaire y effectue divers types de modifications en utilisant une architecture de gestion des versions permettant de gérer des modifications de versions s'adressant à des classes dans des environnements orientés vers l'objet. Dans un premier mode de réalisation, ledit système utilise un schéma de gestion des versions explicite, tandis que dans un second mode de réalisation, il utilise une gestion des versions implicite. Dans les deux systèmes, des versions subséquentes sont créées, compilées et déployées au vol, de telle manière que ces versions subséquentes de la classe d'objets héritent de tous les attributs, des associations et des opérations provenant de versions antérieures de l'objet, et que toutes les versions de la classe d'objets sont déployées par mappage de chaque classe dans un dispositif de stockage de pérennité.
PCT/US2002/022603 2001-07-16 2002-07-16 Appareil et procede de creation d'une architecture de gestion des versions de classe Ceased WO2003009097A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002320557A AU2002320557A1 (en) 2001-07-16 2002-07-16 Apparatus and method for providing a class versioning architecture

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US30704101P 2001-07-16 2001-07-16
US60/307,041 2001-07-16

Publications (2)

Publication Number Publication Date
WO2003009097A2 true WO2003009097A2 (fr) 2003-01-30
WO2003009097A3 WO2003009097A3 (fr) 2003-04-03

Family

ID=23187979

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/022603 Ceased WO2003009097A2 (fr) 2001-07-16 2002-07-16 Appareil et procede de creation d'une architecture de gestion des versions de classe

Country Status (2)

Country Link
AU (1) AU2002320557A1 (fr)
WO (1) WO2003009097A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11279008B2 (en) 2018-07-05 2022-03-22 Stryker European Operations Holdings, LLC Automatic screw driver with screw cartridge
CN114546457A (zh) * 2022-02-25 2022-05-27 掌阅科技股份有限公司 多版本应用的插件实现方法、电子设备及存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5881292A (en) * 1996-09-26 1999-03-09 Microsoft Corporation Dynamic versioning system for multiple users of multi-module software system
US6442753B1 (en) * 1997-08-28 2002-08-27 International Business Machines Corporation Apparatus and method for checking dependencies among classes in an object-oriented program
US6226652B1 (en) * 1997-09-05 2001-05-01 International Business Machines Corp. Method and system for automatically detecting collision and selecting updated versions of a set of files
US6360363B1 (en) * 1997-12-31 2002-03-19 Eternal Systems, Inc. Live upgrade process for object-oriented programs
JPH11259284A (ja) * 1998-03-12 1999-09-24 Fujitsu Ltd オンラインプログラム更新システム及びプログラム更新用プログラムを記録したコンピュータ読み取り可能な記録媒体
US6202205B1 (en) * 1998-07-21 2001-03-13 Hewlett-Packard Company System and method for profile-based, on-the-fly optimization of library code

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11279008B2 (en) 2018-07-05 2022-03-22 Stryker European Operations Holdings, LLC Automatic screw driver with screw cartridge
CN114546457A (zh) * 2022-02-25 2022-05-27 掌阅科技股份有限公司 多版本应用的插件实现方法、电子设备及存储介质

Also Published As

Publication number Publication date
AU2002320557A1 (en) 2003-03-03
WO2003009097A3 (fr) 2003-04-03

Similar Documents

Publication Publication Date Title
US7979842B2 (en) Extensibility application programming interface and framework for meta-model objects
CN1318956C (zh) 软件构件插件程序结构的系统和方法
US5974428A (en) Method and apparatus for class version naming and mapping
US7207002B2 (en) Serialization and preservation of objects
US6868425B1 (en) Versions and workspaces in an object repository
US6442753B1 (en) Apparatus and method for checking dependencies among classes in an object-oriented program
US6564377B1 (en) Self-describing components within a software catalog
US6944845B2 (en) Implementation for an object oriented run-time extensible item
US6173439B1 (en) Interface mechanism and method for accessing non-object oriented data from within an object oriented framework
US5659735A (en) Object-oriented system for program version and history database management system for various program components
US7840597B2 (en) Method and apparatus for managing metadata associated with entities in a computing system
US20120296961A1 (en) Session management within a multi-tiered enterprise network
US6289500B1 (en) Object mechanism and method that creates domain-neutral objects with domain-specific run-time extensions in an appropriate collection
US7140000B2 (en) Knowledge oriented programming
US7770159B2 (en) Virtual types
US6405363B1 (en) Class casting support for run-time extensible items in an object oriented framework
AU2010201505A1 (en) Transparent EJB support and horizontal data partitioning
US7219341B2 (en) Code analysis for selective runtime data processing
US8707260B2 (en) Resolving interdependencies between heterogeneous artifacts in a software system
US6195791B1 (en) Object mechanism and method for coupling together processes to define a desired processing environment in an object oriented framework
US20080098037A1 (en) Markup language based database upgrades
US6192368B1 (en) Apparatus and method for automatically propagating a change made to at least one of a plurality of objects to at least one data structure containing data relating to the plurality of objects
US20060101444A1 (en) Global object system
US20030033442A1 (en) Apparatus and method for providing a class versioning architecture
US20030037313A1 (en) System and method for class transitioning

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP