JP2002543518A - Distributed software development environment - Google Patents

Abstract

(57) [Summary] The present invention relates to a distributed object-oriented software development environment. Objects for performing object operations can communicate with each other if the associated interfaces are compatible. The system environment provides a sequence of control and data to the object. Each interface of the object has a unique global identification value. Compatible interfaces are determined by registering the global identification and version of the interface with the management framework. The system environment can be used to establish an application network and perform consistent and responsive dynamic updates of the application network. The management framework may include a management object associated with an object of the application. The managed object communicates information about the object to the caretaker object. Thus, the caretaker object can control the processing of the object during application network setup or reconfiguration without object involvement. During the design stage, the management framework can also be used by software developers to perform limitless negotiations.

Description

DETAILED DESCRIPTION OF THE INVENTION

This application claims priority under provisional application number 60 / 131,506, entitled "Distributed Software Development Environment," the entire contents of which are incorporated herein by reference. It has been incorporated.

[0002] Background of the Invention 1. TECHNICAL FIELD OF THE INVENTION The present invention relates to a provided software environment for software development and maintenance.

[0003] 2. Description of the Related Art In conventional linear programming code, engineering a software system that is deployed on a large scale is difficult due to the complexity required to design and maintain the system. Also, small changes in the software at the request of the user require major parts of the entire program to be redesigned and rewritten. Object-oriented programming techniques have reduced the complexity of software development. A description of the problems related to software engineering that has been deployed on a large scale and an overview of solutions to those problems are described in "OMSOFT: Change Management Paradigm", Network, and, System Management, Vol. 6, No. 1, 1998. "OMSOFT: A Change Management Paradigm
, “Journal of Network and Systems Ma
nagement, Vol. 6, No. 1, 1998 by the inventor.

[0004] In object-oriented programming, an object is generally defined as a combination of data and operations performed on the data. An application network typically consists of objects (
A collection of programs are interconnected by a common interface. Object-oriented software systems typically provide an architectural specification called an object model. And it becomes a distributed object,
Enable to work with the application.

[0005] Object Management Group
An industry consortium called t Group (OMG) is a common consortium.
Object Request Broker Architecture (Common O
project Request Broker Architecture: CO
Under the (RBA) specification, standards were developed for object-oriented systems.
CORBA specifications define a distributed computing environment with a client-server system environment assigned for objects. CORBA's object broker provides a mechanism by which objects or other applications can request and receive responses from other objects managed by the system. The CORBA approach
As needed, multiple object brokers are utilized, with various components of a distributed system, to provide for the growth or relocation of system resources. Each of these multiple object brokers has access to information in the corresponding implementation and interface repositories.
Object requests are invisible to the user in that object operations can be performed on many some computing devices. Also, the entity that invokes the object operation does not need to know where the object operation resides or is executed.
Thus, the use of the CORBA approach allows individual users to see the existence of specific programs, or their details, when they are executed, in CORB
Because you are handled by the administrator of the system based on A, you are relieved of the responsibility to manage it. Further, by defining a fixed set of operations, the CORBA approach allows object brokers from different vendors to communicate with each other, providing more universal compatibility for the system.

[0006] New objects are added to the CORBA-based system simply by updating the information in the respective repositories, followed by information on how to connect to the objects, and the objects to be executed are interface and implementation. Included in the annotation repository. In this way, a CORBA-based system can be easily upgraded to provide new or changed objects. Because the object-oriented approach only needs to modify those interfaces to make the actual implementation of the operation of the objects visible to the user and to make existing applications work in a CORBA-based system. I do. Thus, it is not necessary to rewrite existing applications to work with the system.

US Pat. No. 5,838,970 describes that CORBA has several limitations. Initially, CORBA does not provide a mechanism for moving an object after the object has been created. Second, CORBA does not make individual user information accessible over a network and does not allow system resources to be managed at either the user level or the object level. Further, CORBA does not support the use of multiple versions of a given object type. CORBA also does not provide an effective means of duplicating highly used resources. The '970 patent describes an object-oriented computer environment in a method of processing, a method of processing or transmitting information that can change during the course of an operation. This environment is governed by the storage in many repositories accessible during the life cycle of the object and the information needed to initiate object operations. Repositories can be assigned different levels of priority to control the distribution of stored information. By using the information retrieved from the interchangeable repositories to affect object operations, computer-based information processing can be extended as needed. Also, a software upgrade can be performed by changing the contents of the application repository. CORBA selects and resolves shared variables, selects compatible application systems, reusable CO
It does not provide dynamic restructuring of the RBA component and has the additional disadvantage of supporting only a single interface.

[0008] The CORBA facility is in a very early developmental stage since it has not addressed the system management issues discussed earlier (for large network oriented applications). It is further noted that CORBA was designed without considering the strong impact of the actual system (system supporting network management, network provider operation, and services) on the object and interaction model. For example, CORBA closes the sender of the message until the receiver receives and recognizes it. This distorts the parallel processing of distributed applications. There may also be a deadlock between the sender and the recipient. Also, CORBA does not support multi-cycle transactions and does not support object and interface versioning. in addition,
CORBA does not address buffer loss associated with asynchronous communication. Thus, the programmer must increase the complexity of the object interface and handle possible buffer losses as part of the structure and protocol thus associated with the shared interface. This also greatly complicates the interface description of asynchronous CORBA components using CORBA IDL.

[0009] The conventional method of installing a newer version of an object or interface in a software application is to shut down the application and install a newer version. This method introduces an unacceptable delay while the application is denied by the user of the software. Administrators can check versions to determine if they are compatible. The object incompatibility results from at least one modification of the object's interface that makes the interface incompatible. Administrators can manually find compatible systems and decide which ones to run. Manual technology is Rakesh Agraway (Rake
sh Agraway) and H. et al. V. Jagadish (HV Jaga)
dish) "On Correctly Forming Versioned Objects" (On Correctly Configuring Versioned)
Objects), 1989, Proceedings of the 15th International Conference on VLDBs (Proc. Of the 15th. Intl.
Conf. on VLDBs, 1989. ). However, if there are multiple versions of an object, it is difficult for the administrator to determine compatible objects.

[0010] Conventional automation techniques use a rules-based approach to maintaining compatible application systems. For example, R. H. Katz (RH Katz)
And E. E. Chang, "Managing Change in a Comp-A."
1987, VLDB's 13th edition (ided Design Database).
Conference Procedure (Proc. Of the 13th VLDB)
Conf. , 1987. ). However, the configuration of large network applications and protocols on different interfaces are complex and difficult to represent in rules. Thus, dynamically updating to a newer version of the application, dynamically maintaining compatible systems, and dynamically rebuilding while the application is running;
It is desirable to provide an object-oriented software development environment that supports

SUMMARY OF THE INVENTION The present invention relates to a distributed object oriented software development environment. Objects for performing object operations can communicate with each other if the associated interfaces are compatible. The environment provides the object with a sequential flow of control and data.

Each interface of an object has a unique global identification value. Compatible interfaces are determined by registering the global identification number and version of the interface with the management framework. Preferably, the management framework allocates object versions and interface versions in an increasing manner. The distributed selection method can be used by the management framework to generate partial instructions of all inherently compatible interface application systems.

[0013] The modified CORBA IDL framework fundamentally changes the design process with a well-defined and meaningful object interface that does not rely on object synchronization problems. This environment simplifies the description of dependent / independent transaction complexes within network-oriented applications. Supported functions for the caretaker are to read / read the state of the object.
Write (write) and get / set (
set), the ability to get / set the state of the clock from outside without the cooperation of the components and the type details from the modified CORBA IDL description and then use the modified CORBA IDL framework Facilitates external monitoring and control of applications, such as the ability to transform raw data into meaningful data by placing meaningful descriptions in transactions.

The system environment can be used to establish an application network and perform consistent, transparent and dynamic updates of the application network. The management framework may include managed objects associated with the objects of the application. The management object communicates information about the object to the manager object. The caretaker object is
Object transactions can be controlled during the establishment or reconfiguration of application networks without object collaboration. At the design stage, the management framework can also be used by software developers to perform limitless negotiations.

[0015] The invention is more fully described with reference to the following drawings.

DETAILED DESCRIPTION Preferred embodiments of the present invention will be described in detail with reference to the embodiments illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings and description.

FIG. 1 is a simplified architectural diagram of a distributed software development environment 10 in accordance with the teachings of the present invention. This development environment 10 includes a plurality of frameworks. Each framework may implement aspects of the design, implementation, management, and network-facing application 12 and each may work independently or may interact with one or more frameworks. . The distributed network framework 14 dynamically sets objects and connects a plurality of objects. Transaction framework 1
5 provides control of transactions between objects. Interaction framework 16 provides control of interaction between objects. Modified COBR
The A IDL framework 18 includes an object-oriented operation for defining an object interface and an interface description language (interface).
(description language: IDL). The management framework 19 provides centralized management of object interfaces and object information. The life cycle framework 20 defines different stages of software development. Human Dimension Framework 21
It defines human interaction with the life cycle framework 20.

The framework of the distributed network 14 includes an interaction network of objects connected by compatible interfaces. An object is an asynchronous processing entity that can initiate a transaction request to another object and service a transaction request from another connected object. An object can be implemented as a collection of data structures and a set of operations on the data structures. An object shares its interface with other objects through an object port. For compatible interfaces, the data structure is the same and the protocol is properly understood by all object ports connecting to that interface. Object ports can be dynamically created by objects. Every object has a state. The state is a collection of values for a set of variables designated as state variables that globally characterize the object and its runtime behavior. A transaction initiated by an object receives the object and reaches a corresponding state. Each object can be associated with multiple object ports. The state of the distributed network is composed of the internal state of the constituent objects and the state of the interface between the objects.

FIG. 2A is a diagram illustrating components of the distributed network framework 14 in which the object 30a includes an object port 32a. Interface 34a connects to object port 32a. Interface 34a
Also connects to the object port 32c of the object 30c. The object port 32d of the object 30c connects to the interface 34b. The interface 34b also connects to the object port 32b of the object 30b. Therefore, the object 30a is connected to the object 30b through the object 30c. For example, object 30a is a client or initiator object that initiates a transaction. Object 30c is a receiver or server that receives transactional procedures and content from object 30a. The object 30c can change the received content.

The transaction framework 15 provides control using dynamic external recording and processing phases. A transaction is the sequence of a series of message exchanges between two or more objects, initiated by one of those objects. Thus, in the present invention, a transaction is
Includes an initiator object that exchanges messages with one or more dynamically changing numbers of receiver objects. The transaction is completed at the initiator object. The transaction ends in a finite amount of time, and the initiator object of the transaction is considered to be aware of the completion of the transaction. Each object port has a configuration and protocol that performs the transaction for that interface. A dependent transaction is a transaction whose completion depends on other transactions. An independent transaction is a transaction that can be completed on its own without depending on other transactions. All object ports can simultaneously service multiple independent or dependent transactions for the first time.

A transaction can include one or more transaction cycles. Transaction phases are assigned to transaction cycles. Each transaction phase is assigned a value. The number of transaction phases is specific to network oriented applications. The dynamically changing number of object ports can be associated with a transaction phase. An object port tuned directly to a higher transaction phase can monitor and control an object port tuned to a lower transaction phase without cooperating with an object port tuned to a lower phase. The content of the transaction can be referred to as a data bag corresponding to a mail delivery system where data is carried in a mail bag. The low transaction phase and control data bags are passed directly to the high phase. Once the current highest phase has acquired the data bag of the highest phase transaction, control is returned directly to the lowest phase object port.

Referring to FIG. 2B. As an example of the transaction framework 15, the objects 30a, 30b, and 30c are connected to a circular communication path 36. Objects 30a and 30b are in phase 0
Are arranged in the lower phase indicated by. Object 30c is located in the higher phase displayed by phase one. Object 30
c receives the data bag 35 and controls from the objects 30a and 30b. The object 30c can change the data bag 35 and return the data bag 35 to the objects 30a and 30b. For example, object 30c is a tester or managed object broker that needs to know the contents of low phase transactions. The tester can change the input to the object during the test phase. Managed object brokers can use the contents of low phase transactions to support transaction failure and recovery.

The interaction framework 16 is a group interaction mechanism where the interaction proceeds to provide a connection or communication path between two or more object ports. For example, the interaction framework 16 defines S. Das et al., "Basis for Matching in Objects", COMPCON (February 1991), Bhattacharya et al., "Microkernels for Wireless Information Networks," Kluwer Acad.
emic) (Spring 1993), the teachings of which are incorporated into this application for all purposes by reference thereto. Interaction framework 16 supports the selection and resolution of distributed information for all objects involved in a transaction. Every interface of an object is associated with an interaction port clock, and all transactions between connected object ports are implemented using the object port and the interaction port clock. The interaction framework 16 has a ring shape as described above, and can be represented by an interaction network having a circular communication path. Objects can be connected to rings via object ports. The data bags described above move around a ring in one direction, moving between groups of connected objects. Each object port can be tuned to a clock phase associated with the ring. The number of object ports connected to a particular clock phase can change dynamically. Clock phases are also called clock ports.

From each object port, the clock port receives data and two (asynchronous) control signals. The control signals are release (indicating the end of the step for that phase) and trigger (indicating the direct will of the other connected object ports for that phase). Once all ports are released and at least one triggers, the clock port sends an advance signal as well as the collected data bag to the next clock port present along the ring. The next clock port receiving this signal will send it to all object ports tuned to that clock port. If no higher phase exists, the clock port sends a progress instruction back to the object port connected to the same phase.

All object port sets for which an interaction has been set proceed in steps. Each step begins with the receipt of a release and / or trigger signal from the object port during the previous phase, followed by the receipt of a progress instruction from the interaction clock, and ends with the release / trigger signal of the current phase. The state of the application interaction is shared among the element objects and the clock ports linking them. Any number of clock ports can be created and / or removed as required by the application. Prior to removal, all object ports are detuned. When an object port is used in an application, it is connected to a particular phase, which is referred to as being tuned to that phase of the clock port. After successfully tuning to a particular phase, the object port can receive progress instructions and data bags from the clock port. After a phase becomes inactive, the object port is simply tuned to the active phase since the phase becomes inactive because the object port that is tuned to the active phase currently receives a progress command and the steps of the phase have not been completed. When an object port is detached from the ring, it is called detuning from a particular phase of the clock port. Once detuned, the object port does not receive data bags or progress commands on that object port.

FIGS. 3A and 3B are diagrams illustrating examples of implementations of the interaction framework 16 forming the interaction network 39.
The interaction network 39 includes objects 30a to 30d arranged along the ring 36. Each of the objects 30a to 30d is identified by an object ID value. Each object port 32a-d has its own port I
Identified by the D value. Clock ring 36 has a buffer size of one. Each object port 32a-b is connected to clock port 3 of clock ring 36.
8a (phase 0 or base phase). Similarly, the object ports 32c to 32d are connected to the clock port 38b (phase 1) of the clock ring 36.
Tuned to). All these objects 30a-d share the same interface 34. In the present embodiment, the object 30a has the object ID 1
, Port ID 500 and interface ID 9 and are tuned to phase 0.
Object 30b has object ID 1, port ID 600, and interface ID 9, and is tuned to phase 0. Object 30c has object ID3, port ID700, and interface ID9, and is tuned to phase 1. Object 30d has object ID 4, port ID 800, and interface ID 9, and is tuned to phase 1.

When clock ring 36 is generated, base phase 0 is automatically generated. As shown in FIG. 3B, phase 0 includes steps 1, 2, 3
, And up to step n. Phase 1 proceeds to step 1 when the ports 32a or 32b are tuned to a phase 0 release and when at least one of the ports 32a or 32b is triggered. The clock ring 36 in phase 0 gathers the data bags 35 and sends the gathered data bags 35 and progress instructions to the object ports 32c and 32d that are tuned to phase one. Object ports 32c and 32d that are tuned to phase 1 can read and modify the received data bag 35. Object port 32
When c and 32d finish the read / write operation, object ports 32c and 32d release and trigger on phase 1 and again clock ring 36 in phase 1 collects data bag 35 and collects data bag 3
5 and a progress command are sent to all ports tuned to phase 2. In FIG. 3A,
Since there are no ports tuned to phase 2 or tuned to a higher phase, clock ring 36 transmits the gathered data bag 35 and progress instructions along clock ring 36 and is tuned to the base phase. All the object ports that have been obtained get the progress instruction and data bag 35 in the next step of the base phase. Thus, step 1 for phase 0 ends, and if there is an object port tuned to it, phase 1 begins. Similarly, when step 1 for phase 1 ends, step 1 for phase 2 starts. If none is tuned to phase 2, then step 2 of the base phase begins. This is repeated until all transactions are completed.

In general, the arrival of a progress order indicates a response to each of the object ports written in the previous step due to all object ports being delivered to all recipients in the transaction. Clocking provides persistence to the data because the data is retained until another party accesses it. If, for a particular object port, the progress instruction is not delivered for the next step, it indicates that the previous step data has not yet been delivered. The object is notified of any failures by other means. One buffer size is supplied to each object port between steps in any phase by clocking to minimize the complexity of understanding, which can be used for object failure, clock failure, external transaction recovery,
And it is needed to address shortcomings such as internal transaction recovery.

[0029] Every object port sends a recovery signal indicating its completion of the current step for that phase. This release must be made to ensure the continued progress of the transaction in a finite amount of time. During this step, the object port has the data collected from the previous step, the write data desired to be collected (which may include multiple writes), or does nothing and immediately releases Send a signal. In any case, once the object sends a release signal, it will no longer read from the data bag,
There is no writing to it. The release of an object port tuned to a particular interaction network is an event. It indicates that the state of the object is not affected in any way by any communication that is generated by the asynchronous object and proceeds during the higher phases, and the latest receipt of the next progress instruction for that phase from the clock. The release indicates the point of dynamic reconstruction, stationary, sound, object, and the object state is stable with respect to its interaction until the latest receipt of the next progression instruction for that phase.

An object port trigger indicates an immediate will for other object ports that have been tuned to the clock ring in the next higher phase. To proceed to the next step, at least one trigger must be received by the clock ring from the object port indicating willingness to model time. This single will signal is delivered to all object ports at the end of the current step as the immediate next run command. The clock ring keeps track of how many object ports are tuned to each phase, not object ports. As soon as it receives all the releases, and at least one trigger from their object port, collect the individual elements to create a data bag, then tune the data bag and progress instruction to the next higher phase Send to all object ports. Thus, the clock is providing synchronization from the outside. It keeps a varying number of tracks of object ports synchronized to different phases, and then finally sends one progression instruction and data bag to the next higher phase. This complicates the high-phase tuned object ports because each object port captures only one event, the arrival of the advance signal, and not all events from each low-phase tuned object port. And thereby provide unlimited cooperation.

Table 1 shows an implementation of the source code for creating an object port of the appropriate size and number and registering the object port with the management framework 19 as described below.

[0032]

[Table 1]

[0033]

The modified CORBA IDL framework 18 is an object-oriented technology in software development supported by the environment 10. Modified CORBA
The IDL framework 18 uses OMG (Object Management).
The Common Object Request Broker: Architecture and Specs, published by The Group in 1992 ("The Common
Object Request Broker: Architecture
and CORBA standards, as described in a document entitled "Specifications and Specification" (hereinafter referred to as CORBA specifications), the teachings of which are incorporated herein by reference for all purposes. It will be appreciated that the features of the present invention may be applied to different implementations of an object-oriented system, and the CORBA specification specifies that objects can transparently generate and receive requests and responses in a distributed environment. Object Request Broker
er (ORB)). The object service is a CORBA service: Common Object Service Specification (Common Object)
A set of services that implements interfaces and objects that support basic functionality by using and implementing objects, as described in Service Specification. Common facilities are a group of services that are shared by applications that are less basic than object services, as described in CORBA Facilities: Common Object Facilities Spec.

The client requests a service by issuing a request. A request is an event, such as, for example, one that occurs at a particular time. The information associated with a request consists of an operation, a target object, zero (0) or greater (actual) parameters, and an optional request context. An object reference is an object name that reliably indicates a particular object. In particular, an object reference identifies the same object each time the reference is used in a request. Objects are indicated by a number of different object references. The request may have parameters that are used to pass data to the target object, and it may also have a request context that provides additional information about the request. Results and exceptions (if any) are returned to the client.

Objects can be created and removed. The result of object creation is revealed to the client in the form of an object reference pointing to the new object. The type is the associated predicate defined on the value (
Identifiable entity with a single-argument mathematical function with a Boolean result). If predicate is true to value, value satisfies the type. Satisfied values are called members of that type. CORBA
The standard includes two basic types of data: integers, floats, characters,
Basic types, including Booleans, counts, and columns, and structural types, including records, distinct unions, sequences, arrays, and interfaces, are defined.

An interface is a description of a set of possible operations that a client may request from an object. An object satisfies an interface if the object can be identified as a target object in each possible request described by the interface. An interface type is a type that is satisfied by any object that satisfies a particular interface. Interfaces and operations are specified in the modified CORBA IDL. The definition for an object of an interface can be defined in two ways. The interface may be statically defined in the modified CORBA IDL.
This language defines the types of objects according to the operations that can be performed on them and the parameters for those operations. Alternatively,
Or, additionally, an interface may be added to the CORBA interface repository service.

As specified in the CORBA specification, the ORB causes a client to send a request to an object. A client is an entity that wants to perform an operation on an object, and an object implementation is the code and data that actually implement the object. The ORB assumes responsibility for all of the mechanisms needed to find the object implementation for the request, prepares the object implementation to receive the request, and communicates the data that makes up the request. I do. The interface referenced by the client is completely independent of where the object is located, what programming language is implemented, or whether any other aspects are not reflected in the object's interface.

To make the request, the client can use a CORBA dynamic invocation interface, or a CORBA IDL stub. The client can also interact directly with the ORB for some functions. The object implementation receives requests as calls through skeletons created by CORBA IDL, or through dynamic skeletons. During the processing of the request, or at other times, the object implementation can invoke the object adapter and the ORB. The client performs the request by accessing the object reference for the object and knowing the type of object and the desired operation to be performed.

In the CORBA architecture, the ORB is not required to be implemented as a single component, but rather is defined by its interface. Any ORB implementation that provides a suitable interface is acceptable. The interface has three categories: all ORBs
It is organized into operations that are the same for implementation, operations that are specific to a particular type of object, and operations that are specific to a particular style of object implementation. The ORB interface is a direct interface to the ORB, the same for all ORBs, and is an interface that is independent of object interfaces or object adapters.

The modified CORBA IDL framework 18 also includes the following that describes an implementation used in the present invention. The modified CORBA IDL framework 18 is designed for asynchronous components where the calling and called parties are asynchronous. All functional descriptions are associated with the key operation "asynchronous" and indicate asynchronous operation. Thus, the sender does not need to be blocked until it is acknowledged by the receiver. Further, since the objects interact using the interaction framework 16, the designer need not be concerned with buffer loss.

The modified CORBA IDL framework 18 defines the multi-cycle steps of a transaction. The following is a skeleton specification in the modified CORBA IDL framework 18 for a multi-cycle transaction using the interaction framework 16.

[0043]

[Table 2]

The interface 34 may be implemented using a modified CORBA IDL framework 18. A global handle specific to the entire system is provided to the object 30 including the reference, object ID, port ID, interface ID, clock ring 36, and clock phases 38a, 38b. Global handles are independent of where they are located and in what programming language they are implemented.

FIG. 4 shows an implementation of the management framework 19 as a distributed management network 40. The object 30 and the interface 34 (not shown) are managed by the management object 42. The object version of the object 30 is distributed to the management object 42. The management object 42 serves to centrally manage information about the linked objects 30.
The management object 42 is an interface (INE) for network development.
The information is transmitted to the manager object 44 through the interface 45. The management person object 44 makes a decision on the interface development based on the information received from the management object 42. The manager object 44 combines information provided by the manager objects 42. The complexity of each managed object 42 is O (TNLog (N). If there is no managed object 42, MxT
Is the total number of objects 30 in the application. The complexity of distributed selection of compatible systems is O ((T + M) NLLog (N)). Thus, if T and N are constants, then the complexity of distributed selection of compatible systems is N Log (N). The caretaker object 44 supports a graphical user interface (GUI) to shape and control the evolution of the application, and the caretaker 47
2 to manage objects interactively. Object 3
A design of 0 is application specific.

FIG. 5 shows an implementation of a stage of the life cycle framework 20. Request stage 50 determines constraints such as, for example, cost, deadline, reliability, or size of object code. The project management planning stage 51 determines key components of software development, such as deliverability, milestones, and budget, to provide a project management plan. The spec and object oriented analysis stage 52 splits the requirements developed in the requirements stage 50 into a set of objects 30 having the interface 34 to generate the specifications. The splitting of requirements may depend on the project management plan developed in the project management planning stage 51 and the desired level of reusability of the object. The reusability of an object may be determined by checking the interface 34 and the object 30 for which the object matches wholly or partially. Perfectly matching objects 30 can be totally reused. Partially matching objects 30 may be assigned to developers to extend existing functionality to satisfy new requirements.

The design stage 53 determines the object 30 and the interface 34 based on the specifications and the specifications developed in the object-oriented analysis stage 52. A plurality of developers can determine the object 30 using negotiation between developers who are developing the interacting object 30. The developer negotiates a structure and protocol for the interface 34.

The implementation stage 54 determines the implementation of the object 30 and the interface 34. The single unit test may be performed by a third party in the automatic single unit test stage 55. After a successful test, the implementation will proceed to Management Framework 1 as described below.
9 and can be registered. Compatible systems are determined in a compatible system detection stage 56.

During the network-oriented source code walk-through stage 57, tests are performed on the implementation of the object 30 and the interface 34. The test results are sent to a management framework 19 that sends the results to the relevant developers and administrators.

The network-oriented integration test stage 58 integrates the objects 30 to check that the objects 30 are properly coupled to provide a product that meets the specifications determined in the specification and object-oriented analysis stage 52. To test. The interface input / output of the object 30 can be tested. The test results are sent to a management framework 19 that sends the results to the relevant developers and administrators.

The maintenance stage 59, after receipt, provides support for changes to the software developed in stages 50-58. During maintenance, the tested version of the object 30 may be updated dynamically. The maintenance stage 59 includes a requirements stage 50, a project management planning stage 51, a specification and object-oriented analysis stage 52, a design stage 53, an implementation stage 54, a network-oriented source code walk-through stage 57, or a network-oriented distributed semantic test stage. 58.

The human dimension framework 21 assigns relevant activities to software development team members during a life cycle stage as described in the life cycle framework 20. An implementation of the assignment by the human dimension framework 21 is shown in Table 2.

[0053]

[Table 3]

[0054]

In the spec and object oriented analysis stage 52, the developer obtains the initial specs 30 and the overall specs for each object 30 describing the interface 34. After that, the developer, to satisfy the new requirements,
You may be asked to enhance a particular version of the object 30 that is already available, or you may be given only the interface ID for the object 30 without any structure and protocol for each of the interfaces. . In the second case, the developer must completely design the new object 30.

In the design stage 53, a developer can use a negotiation process with another developer. For example, a developer can write a negotiation script with a modified CORBA IDL for each interface 34 at each step of the negotiation. The negotiation script is
It is registered with the management framework 19. The developer receives a negotiation script written as a modified CORBA IDL description from another relevant developer. The developer can use the received information, which represents the other developer's views on the structure and protocol for that particular interface, to modify the negotiation script. After all interfaces have been negotiated, the developer writes an object interface description with the modified CORBA IDL and registers the object interface description with the management framework 19. The management framework 19 uses the modified CORB
A Return the code created from the IDL description to the developer. An implementation of a preferred negotiation process is described in more detail below.

In the implementation stage 54, the developer completes the implementation and performs a single unit test. The developer registers the implemented object 30 with the management framework 19, for example, the object version may be incremented after testing as a result of modification. Detect compatible application system 56 creates a compatible application system. The developer takes necessary actions based on the results of the network-oriented source code walk-through stage 57 and the distributed semantic test stage 58.

In the network-oriented integration test stage 58, a distributed semantic test is performed to check that the objects 30 are correctly combined to achieve a product that meets the specifications. During the network-oriented integration test stage 58, the interface 34 is carefully tested. A tester can be used to test interfaces, status, and inputs / outputs for the object. The tester identifies any faults, categorizes them, and enters the results into the management framework 19 without correcting the faults.

During the maintenance stage 59, the maintenance manager notifies the maintenance programmer by delivering failure reports or specifications to enhance existing objects 30. The maintenance programmer provides corrective and adaptive maintenance changes to find and fix bugs in software developed using stages 50-59 described above, and allows testers and developers to Serves as a bond.

The following is an example of the development of a network application in the distributed software development environment 10 using the life cycle framework 20. During the request stage 50, information about network applications is gathered from end users or clients. FIG. 6 shows the network application 60 created by the request stage 50. The network application 60 includes an object 30a having an object ID 01 (hereinafter referred to as an object 01), an object 30b having an object ID 02 (hereinafter referred to as an object 02), and an object 30c having an object ID 03 (hereinafter referred to as an object 03). have. Each object 3
0a-c have respective state object ports 61a-c from which the state of each object 30 can be set or received. Each object 30a-30c
Has status interfaces 63a to 63c assigned as status interface IDs 1, 2, and 3, respectively. The state interface IDs 1, 2, and 3 are assigned to objects 01, 02, and 03, respectively. Each object 30a-c has a basic service object port 62a-c through which each object 30 sends or receives a request, processes the request, and is the object port 32 as described above. The response is sent back through the obtained basic service object port 62. The basic service interface 64 connects the basic service object ports 62 of the objects 01, 02, and 03. Interface 6
4 is assigned an interface ID 4. State object port 61a
-C and the basic service operation ports 62a-c are object port 3
It will be appreciated that the status interface 63 and the basic service interface 64 have an interface 34.

In the network application 60, a square operation (square operation)
object 01 sends a request message to the object 02 via the basic service interface 64 to perform the request. Object 0
1 receives the squared number from the object 02 via the basic service interface 64. Object 01 is a sum operation (summati)
on service), the basic service interface 6
4 sends a request message to the object 03. Summation (
n) is performed by adding n, n−1,..., 1, resulting in n (n + 1) / 2. Object 01 receives the summed number from object 03 via basic service interface 64. Integer is object 01
, Object 02, and object 03. Therefore, the objects 02 and 03 only provide services and do not generate any requests.

In the specification and object-oriented analysis stage 52, the interface ID
1-4 can be set to null (blank). The following specifications can be determined. Object 01 has two interfaces having interface IDs 1 and 4. Interface ID1 is an interface for state port 61a that supports get and set states and supports removing object 01 by set state operations. The basic service object port 62a can send a square or total request operation and receive an appropriate response. Object 02 has two interfaces having interface IDs 2 and 4. Interface ID2 supports get and set states, and also supports removing object 02 by set state operations.
1b. The basic service object port 62b receives, calculates, and outputs a response to the square request. Object 0
Reference numeral 3 has two interfaces having interface IDs 3 and 4. Interface ID3 is an interface for state port 61c that supports get and set states, and supports removing object 03 by set state operations. The basic service object port 62c of object 03 receives the total request, calculates, and outputs a response. In the design stage 63, the caretaker assigns the task of designing object 01, object 02, and object 03 to three developers identified as D1, D2, and D3, respectively.

The environment 10 can be used to implement negotiation between developers during software development of the application in the design stage 53. FIG. 7 is a flowchart illustrating an implementation of an unbounded negotiation method 70 in accordance with the teachings of the present invention. Unlimited negotiation provides negotiation by going through the steps. Block 72
In, the caretaker object 44 assigns the task of designing and implementing the object to the developer. At block 73, a negotiation network is established between the developer and the managed object 42. FIG. 8 is an implementation of a negotiation network 80 that may be used for the similar application network 60 shown in FIG. The negotiation network 80 has developers D1, D2, and D3. Developers D1, D2
, D3 by the caretaker object 44 to develop objects 30, referred to as object 01, object 02, and object 03,
Assigned respectively. At block 73, the caretaker object 44 can specify parameters when establishing the negotiation network 80. For example, the custodian object 44 has a negotiation network 80
When establishing a, login name, each password of developers D1, D2, and D3,
The object ID and the interface 2D for the objects 01, 02, and 03 can be specified. Each developer D1, D2, and D3 generates a respective developer negotiation object port 82a, 82b, and 82c for object 30a, object 30b, and object 30c. Each developer D1, D2, and D3 creates a respective object port 32a, 32b, 32c as a developer state port. The developer negotiation and status port are registered with the management object 42. The developer uses the state object port to obtain design specifications, object IDs, interface IDs, and other services that the developer needs as part of the lifecycle framework 20. At the end of the implementation and single unit test stage 54, the developer checks the object with the managed object 42 along with the implementation. Managed object 42 uses the same interface to return object version information to the developer. Each developer uses this interface at the end of each step of the negotiation process to check for modified IDL.
The management person object 44 includes the corresponding management-side state port objects 84a to 84c in the management object 42 and the INE management object port 83
Create The developer negotiation object port 85b and the manager INE port 85a are established in the manager object 44.

The administrator INE port 85a, the administrator negotiation port 85b, and the administrator IN
The E port 83 and the management negotiation ports 84a to 84c correspond to the management object 4
Registered with 2. The manager object 44 generates a clock, and connects the manager INE port 85a and the management INE port 83 on the management side. I
By using the NE interface 45, an administrator 47 (not shown) using the administrator object 44 controls the entire negotiation process. The manager object 44 transmits the negotiation-related data to the manager object 42. The management object 42 includes developer state object ports 32a-c and management negotiation ports 84a-c on the management object 42.
Allows connection to and from. In this scenario, the network 80, the administrator 47 decides to look directly at the negotiation process. The negotiation clock 86 is generated by the management object 42. The administrator negotiation object port 85b of the administrator object 44 is tuned to the base phase of the clock 86. When the port 85b obtains (gets) the progress command,
It is kept. The three developer negotiation object ports 82a-
All of c are tuned to the high phase of the negotiation clock 86. Port 85b then releases the port, and developer negotiation object ports 82a-c get a progress command signal.

At block 77, developers negotiate with each other until all developers have negotiated agreement. For example, developers D1, D2, and D3 send modified CORBA IDL framework 18 and a negotiation script written in English, along with the progress command, release, and trigger mechanisms described above, through developer negotiation object ports 82a-c. You can repeatedly agree by doing so. The modified CORBA IDL written by the developer at the end of each step of the negotiation is checked for syntactic correctness by a back-end IDL compiler supported in the developer environment.

In this embodiment, developers D1, D2, and D3 negotiate to agree on the structure and protocol for the interface of interface version 1.0, which is the common global interface interface ID4. Any developer D1, D2, D3 can negotiate a complete description of the structure and protocol for interface ID = 4 consistent with the individual design. For example, in step 1, developers D2 and D3 may not want to suggest anything. Thus, D2 and D3 may or may not release step 1 and trigger. In step 1, the developer D1 creates a proposal. Table 3 is an example of a negotiation script of the developer D1.

[0067]

[Table 4]

The developer D1 sends a negotiation script to the developer negotiation object port 82a, and then releases and triggers the developer negotiation object port 82a. Triggers are sent to developers D2 and D3 at the earliest possible time to exchange developer D1's negotiation script. At this point, developers D1, D2, and D3 release and trigger, and only developer D1 writes to developer negotiation object port 82a. The negotiation clock 86 collects negotiation scripts and creates a data bag 35 (not shown). In this case, only one developer D1 has transmitted the negotiation script in the current step, so only one negotiation structure element is in the data bag 35. The negotiation clock 86 distributes progress instructions to the data bag 35 and to the administrator negotiation object port 85b tuned to a different phase 0. Upon receiving the progress command, the caretaker object 44 can examine the data and the received negotiation script and understand the manner of the group negotiation step 1. The caretaker object 44 understands that the developer D1 has proposed a change. After completing the inspection, the caretaker object 44 writes the data back to the caretaker negotiation object port 85b, so that the elements received by the caretaker negotiation object port 85b are not removed or modified, but are in a different phase 1 Can be distributed to developers D2 and D3 connected to The manager object 44
Release and trigger the administrator negotiation object port 85b for the base phase. The negotiation clock 86 collects this new phase data and builds up the data bag 35. A negotiation clock 86 distributes progress instructions to the data bag 35 and to the developer negotiation object ports 82a-c that are tuned to phase one. Upon receiving the progress command, developer D1 may do nothing in this step 2. Developer D1
Release may or may not trigger. Developers D2 and D3 can read and understand the proposed changes from developer D1, and disagree or completely agree on individual parts of the structure and protocol. If both developers D2 and D3 agree, the negotiation is completed. Alternatively, the negotiation may involve all developers D1, D
2, and until D3 agrees. Table 4 is an example of a developer negotiation script for step 2.

[0069]

[Table 5]

Table 5 is an example of a developer D3 negotiation script in step 2.

[0071]

[Table 6]

Both developer D2 and developer D3 write their individually acceptable statements in their respective developer negotiation object ports 82b and 82c in modified COMRA IDL and English, and write their respective developer negotiation object ports. Release and trigger 82b and 82c. The negotiation clock 86 delivers the modified data bag 35b again, and gives a progress command to the manager object 44. Manager object 44
Confirms that the developers D2 and D3 have already agreed. Thus, the caretaker object 44 does not interfere at this step to avoid conflicts. The caretaker object 44, for the received element,
Negotiator negotiation object port 85b without any changes
And sends the release and trigger to the administrator negotiation object port 85b. The negotiation clock 86 delivers the new data bag 35b and gives a progress command to the developer object ports 32a to 32c. Developer D2 and developer D3 do not need to do anything. Developer D1
Understands that developers D2 and D3 have already agreed, which is the structure and protocol for interface ID = 4, interface version = 1.0.

At block 78, the developers D 1, D 2, and D 3 implement in the implementation stage 54 for their individual object versions, including interface ID = 4, interface version = 1.0 Complete. Each developer D1, D2, and D3 writes an implementation completion message and a release / trigger to their negotiation port. When the custodian negotiation object port 85b obtains a progress command and examines its contents, the custodian object 44 understands that the developer has completed the implementation. The manager object 44 writes to the manager negotiation object port 85b and releases / triggers. The object ports 32a to 32c obtain an instruction to proceed to the fourth step. All of the developers D1, D2, and D3 have completed implementation and at this point interface ID = 4,
It knows that the negotiation transaction for interface version = 1.0 has been completed. From this point, a new developer object port 3
0 can participate in this negotiation process and a new transaction is initiated by the developer in the updated configuration.

As described above, the caretaker object 44 tunes to all negotiation proceedings in the application and observes transparently to control the negotiation process. In large network applications, there may be hundreds of different active negotiation groups. The caretaker object 44 may require hundreds of ports for external observation and control. Instead of the custodian object 44 tuning directly to all negotiation proceedings (by creating a port in the custodian object), the custodian object 44 is already tuned to all clocks in the application. A plurality of management objects 42 with management negotiation objects can be used, resulting in
Get all information (negotiation proceedings). Although this approach includes an admin object 44 that sends commands to the admin objects 42, it reduces the number of ports in the admin object 44, and the original approach was to Object 42
This reduces the number of request messages between them. The approach used can be selected based on the network application.

Generally, the progress command is not the developer itself, but the negotiation clock 8.
6 so that only at the beginning of each new step (if a progress order arrives) does the developer's thinking deviate from the essential issues of the design, Independence will lead to uninterrupted negotiations (joint development). In the negotiations described above, the status of the caretaker object 42 in the different phases is totally transparent to multiple developers. If the caretaker object gets a progress order in the base phase, then in the higher phases, the developer negotiation port will already be released automatically, and multiple developers will be asked about where their data traverses. You may be ignorant. The caretaker object port captures one progression instruction and a bag modified by an entire group of developers at each step, resulting in increased caretaker productivity and reduced complexity. Also, developers do not need to know the number of developers connected to the negotiation process, where they are located, and when they are working. This can increase developer productivity. Each developer is waiting for a progress instruction to come to the negotiation port for the next step, which is the independence of the elements described above. The number of elements in the bag received with the progress instruction indicates the number of developers involved, which is dynamic and set by a clock. The arrival of the advance command on all ports tuned to different phases is controlled by the clock and depends on the number of developers dynamically tuned to the clock.

Table 6 is the design of the end of the negotiation stopped in the modified CORBA IDL.

Table 6 Step 1: If the object port goes to step 1, D1's object 01 writes an appropriate message to the basic service object port to initialize the transaction. Square reque (square reque)
Either st) or a summation request can be executed. Data entered by the user is copied onto the structure in the appropriate message type. Object 01 then releases and triggers on the basic service object port of step 1. The object 02 and the object 03 release and trigger when receiving the progress command of step S1.

Step 2: If the object port goes to step 2, the object 0
1 does not execute except release and trigger. Object 02 and object 03 read the data and interpret it. If it is a square request (square request), object 02 calculates the square and copies the response in the appropriate message type on the output structure. Object 02 writes its output structure to the base service object port, releases that port, and triggers. Object 03 does not execute other than release and trigger. If it is a summation request (summation request), object 03 calculates its response and writes it to the service object port. Object 03 and Object 02 release and trigger their basic service object ports.

Step 3: If the object port goes to step 3, the object 0
1 reads the incoming data and interprets it to understand that the final output has already been received. This indicates the end of the transaction in the initiator (object 01). Object 02 and object 03 are
Release and trigger an object port without writing anything.
Object 01 either immediately initiates another transaction cycle, or simply releases and triggers without writing anything to its port.

In the implementation stage 54, a developer may follow the steps shown in FIG. 9 to implement the network application 60 shown in FIG. In block 90, the object 30a
Are determined, each state interface 63a-c supports a set or get state of the objects 30a-c and is implemented to discard the objects 30a-c. For example, the state is selected as a corresponding integer, which corresponds to a transaction in network application 60. In the network application 60, each status port 61a-61c is defined to have two fields: the first field is a message type field indicating a set or get operation of the operation. Yes, the second field is a status value field that contains the status of the objects 30a-c. The developer D1 selects such that the initial state of the object 01 is 0. Thus, whenever object 01 sends one request for one service, its state changes to one. Upon receiving the response,
The state of object 01 is changed to 0. Similarly, the developers D2 and D3 initialize the object states of the corresponding objects 02 and 03 to 0, respectively. Object 02 or Object 03
Receives a request from object 01, its state changes to 1. As soon as the response goes to the same step, its state changes back to zero. For example, status message types can be assigned as defined below: 1 indicates a set, 2 indicates a get, 3 indicates an ack for the set, and 4 indicates Response about get (get_ack
), 5 indicates a request for extinction (die), and 6 indicates a received and updated extinction. According to the teachings of the present invention, these message numbers and state types can be changed between multiple objects, which is determined by the developer, but the overall support is per object. Must be provided by the developer.

At block 92, an object port is associated with each object interface for the plurality of objects. Thus, status ports 61a-61c are associated with respective status interfaces 63a-63c, and basic service object ports 62a-62c are associated with basic service interface 64. At block 94, a transaction is determined for the request to process and the incoming message. At block 96, the interface may be described using a modified CORBA IDL. The description content of each modified CORBA IDL is determined for each object interface. The description of the modified CORBA IDL includes, for example, an interface ID (interface identification), an interface version, and initiator / receiver information (Initiator / Receiver).
Describes the structure and transactions of the object interface, including I.Information. In network application 60, developer D1 writes two separate modified CORBA IDLs for two interfaces with interface IDs 1 and 4 in object 01. Modified CORBA ID for interface ID1 of object 01
An implementation of the description of L is shown in Table 7.

[0082]

[Table 7]

[0083]

An implementation of the description of the modified CORBA IDL for object 01, interface ID4 is shown in Table 8.

[0085]

[Table 8]

[0086]

An implementation of the description of the modified CORBA IDL for object 02, interface ID 4 is shown in Table 9. Interface ID
= 2 IDL description of developer D2 and modified CORBA of developer D3
The IDL description is determined similarly.

[0088]

[Table 9]

[0089]

At block 97, each determined object interface is implemented as a separate source file. The separated source files determine the overall object code for the network application 60. For example, the source code for object 01 comprises two ports: a state object port 61a having a state port ID of appropriate size and a basic service port 62 having a service port ID.
a. The port ID indicates that the two port services are different and that they are uniquely identified in the application system. In order to access the services provided by these ports, the administrator must know the corresponding port ID. The port ID or service port ID is similar to the property of the object that the manager must obtain from the object in order to use the service.

Examples of functions used to generate source code and their descriptions are provided below.

OMF_CreatePort (PortID, PortSize):
In this method, the object 30 has a port size (PortSize).
) Is generated. The object 30 receives and sends data through this object port. The port ID is an integer that uniquely identifies an object service from the entire application system. For example, the object port is an object port 32, a state object port 61, or a basic service object port 62.

OMF_Registration (PortID): The method
By allowing the object 30 to register with the management unit of the port having the port ID, the administrator is allowed to access the service of the object.

OMF_Advanced (PortID): This method causes the object 30 to determine whether the object port having the port ID has issued a progress command. If a progress command has been issued, the process returns to the tuning process again; otherwise, it is an error.

OMF_ReadData (PortID): This method causes the object port with the port ID to check whether there is one or more elements in the bag to be read. If correct, return to non-zero state.

OMF_LoadData (PortID, PortSize, I
ninputStructure): This method uses the port size (P
ortSize) allows loading bytes.

OMF_WriteData (PortID, PortSize,
OutputStructure: This method uses an output structure (Output
Structure) allows writing a port size byte to an object port having a port ID.

OMF_Release (PortID): This method uses the port ID
Can be released. The object port holder uses this to send out the stable state of the object when requested by the caretaker (through the managed object).

OMF_Trigger (PortID): This method uses the port ID
To trigger on an object port with

An example of source code developed as an implementation of object 01 is shown in Table 10.

[0101]

[Table 10]

[0102]

[0103]

[0104]

At block 98, each implemented object 30 is registered with the management framework 19 which returns an object version number. Testing of the objects may be specified and performed in a network-oriented source code work and a network-oriented integration test stage 58 through stage 57. The developer registers the object in the management framework 19. For example, the developer D1 can input information as shown in the table 11.

[0106]

[Table 11]

The management framework 19 returns an appropriate object version number. In this case, version 1.0 is returned to the developer D1. Similarly, developers D2 and D3 also register information on their respective objects. For both, the managed object returns 1.0 as the object version number.

Objects and interfaces can evolve gradually during the development of network applications. During development, object versions may become incompatible for the following reasons: That is, the reason for this is that the object 30
Is registered in the management framework 19 at a different time, or the original version of the object 30 is deleted. FIG. 10 is a flowchart of a method for determining compatible applications 100 in environment 10. At block 101, an object table for linking object versions and interface versions is determined. The column names are the object ID, object version, and interface ID (
For example, 1, 2, 3, 4). The value associated with the column is the interface version associated with the individual interface. The object version column indicates an object version. According to the preferred embodiment, the objects 30 are inserted into the object table so that the m implementations persist from one another as one block and only the object version number is incremented, resulting in multiple interfaces. All implementations up to the Mth are arranged to obtain all unique combinations of versions <I ₁ ... I _m >.

According to the preferred embodiment, a plurality of object tables are created and this table is increased. Thus, for each unique version of the interface, the object version will continue to increase. As fixed new interface versions are created, they are inserted into the object table to keep the table growing.

All of the object tables are sorted by the number of the object table denoted by T. The number of the interface in the application is denoted by I. The object 30 has a plurality of interfaces, and the maximum number of interfaces in one object is represented by Oimax. Interfaces 34, 1-4 in network application 60
, And 63a-c are all assumed to evolve gradually. As the application evolves over time, no interface remains unchanged over time (when compared to other interfaces in the application). This assumption is used at an intermediate stage of the combined operation, as described below, to limit the number of records. N is a variable number for the object version in the object table. The complexity of the data table selection method is NlogN.

Table 12 shows an implementation of the object table of the application network 60 shown in FIG. For example, version 1.0 of object 01 implements interfaces 1 and 4, each interface having interface version 1.0.

[0112]

[Table 12]

For example, Object 1 contains two object versions 1.0 and 1.1 as shown in Table 12. A new version is created for interface ID4, interface version 1.0, and interface ID1, interface Ver1.0, and inserted between object Ver1.0 and object Ver1.1. This new object version is, for example, object Ver1.0, such as object Ver1.01.
And the object version between 1.1 and 1.1.

At block 102, the entire table is sorted for object versions. If there are multiple new implementations available for each unique combination of interface versions, the most recent version for that combination is used in the sorted table. For example, object 2 has object versions 1.0 and 1..
1 which have similar combinations as interface versions 2 and 4 as shown in Table 10. Object version 1
. 1 is the latest version of the combination of a plurality of interface versions, the M-th version. The object version 1.1 is determined after fixing the bag without changing the interface version. This new object version 1.1 is inserted into the sorted table to keep the implementations of the combined blocks.

[0115]

[Table 13]

At block 103, the first two object tables are sorted for a common plurality of interface IDs. For example, object 01 and object 02 have a common interface ID4.

Table 14 shows the sorting for interface ID 4 for object 01 and object 02.

[0118]

[Table 14]

At block 104, the first two object tables are joined for all of the common basic service interfaces 64 of the application 60 to produce an intermediate join result as shown in Table 15. When there are a plurality of common interfaces between the object tables, and each of the interface versions of the common interface matches, a pair of object versions determined by the AND condition are output.

[0120]

[Table 15]

At block 105, the object table of the next object is sorted using the previous result with respect to the common interface ID. The object 03 shares one common interface ID4 with the objects 01 and 02. Table 16 contains object 03 interface ID
4 shows the output after sorting for No. 4. Blocks 103-105 are repeated to process all object tables.

[0122]

[Table 16]

At block 106, the final combination is determined by combining the intermediate results for the next sorted object determined from the previous steps.
Table 17 shows the final combination result of objects 01, 02, and 03.

[0124]

[Table 17]

FIGS. 11A-11B illustrate the evolution of the example described above. The rectangular box-shaped columns indicate that the corresponding object evolves gradually with bag fixation or modification of the interface version. The circled columns on the right indicate that the corresponding interface will evolve to adapt to changing application requirements. The connecting edge indicates the interface version implemented by the object version. Compatible systems are labeled CS-I, CS-II, and CS-III in FIG. 11B. The corresponding interface version is shown on the right. The system is CS-I.Object 02 version 1.
0, the new object 02 version 1.1 and the second
Result in a compatible system CS-II. Interface ID 4
Changes in the interface ID interface version 1.0 to interface version 1.1 and the third compatible system CS-III
Change to

FIG. 12 shows the execution of the block 103 by the management framework 19 to obtain interface information distributed from the objects 01, 02 and 03. The objects 01, 02 and 03 of each object are distributed to a plurality of management objects 42 called M1, M2 and M3, respectively. For object 01, object 02 and object 03 of each object, the caretaker object 42
Assign increasing object version numbers. For example, each object table shown in the table 15 can be managed under a separate management object 42. The number of tables in the object table depends on the management object 42 and the number of queried object versions. Each managed object 4
The information about the interface distributed and stored in the management object 4
2, the management object 42 can execute the blocks 103 to 105. The caretaker object 44 considers the results of blocks 103-105 from the management object 42 and executes blocks 106 and 107.

The management framework 19 can interact with the life cycle framework 20. Specification stage 52
In an age 52), the interface ID of the object 30 is specified by the manager object 44 and sent to the developer by the management object 42. The developer completes execution stage 54 and then executes a single unit test. The executed object is registered in the management object 42. The interface ID, the associated interface version number, and the source and IDL files associated with the registered object 30 are sent to the management object 42. For example, as shown in Table 18, object 01 having two interface IDs 1 and 4 sends the following information to managed object 42.

[0128]

[Table 18]

The management object returns an appropriate object version number. The management object 42 holds the following tracks: for example, if the current version for which the object 30 is registered has already been registered and this current registration is a new implementation for the same combination of interface versions. , The management object 42 immediately returns the next object version number. The object version number starts with the base object version for that combination of interface versions. If the current version for object 30 has not yet been registered and admin object 44 has not identified any increasing numbers for that interface version combination, the management object 42 returns an entirely new object version for the combination. other,
The management object 42 returns the number assigned by the manager object 44. A bad registration process will result in the developer retrying the registration.

At the beginning of the spec and object oriented analysis stage 52, the global interface ID for each object 30 is specified in the managed object. The developer first obtains this information from the management object 42.
For each object 30, the caretaker object 44 can generate a recent version (MRV) object ID table in the managed object 42 having a column name as the interface ID associated with the object ID. The range of values associated with a column is the interface version number associated with that interface. Each time registration is successful, the MRV object ID table is updated. For any unique combination of interface versions, managed object 42 keeps only the most recent implementation in this table. This table is used by the caretaker object 44 to perform block 106 to perform a join operation on all distributed interfaces. Manager object 4 of object 30
For every table generated by 4, managed object 42 creates another table called the ALLVERSIONS object ID table associated with the object ID and holds all object versions associated with the objects therein. . This table is unknown to the caretaker object 44. When using the increasing object version number policy, the caretaker object 44 instructs the management object to increase the object version number for each unique combination of interface versions. The management object 42 updates this information in the MRV object ID table. Thus, for the starting object version number, all interface versions and selections of the caretaker object 44 are entered into the MRV object ID table.

Preferably, for every registration having a new combination of interface versions, the managed object 42 returns the next number from the sequence of 1, 2, 3, 4, 5,... N as the object version. The next number returned is found by the managed object 42 from the MRV object ID table.
For example, the management object 42 has the first interface version of the input interface version.
Returns 1.0 for the unique combination of For subsequent executions of the same combination of interface versions, the managed object 42 will have 1.1, 1.2, 1.3
... 1. Returns n sequentially. When a second unique combination of interface versions is entered, managed object 42 returns 2.0.

If there is no MRV record, it is a completely new combination of interface versions, meaning that the caretaker object 44 has not specified any starting object version numbers. For that combination, the management object 42 determines which number, starting from 1.0 (from the MRV object ID table), has been used,
Returns the next number from 2 ... The management object 42 updates the MRV object ID table and the ALLVERSIONS object ID table.

If a recent version exists and the MRV object version in the MRV object ID table is -1, it is a completely new combination of interface versions, but the caretaker object 44 starts for that combination. Object version number is specified. (The MRV object version is set to -1 to indicate that the version does not yet exist). In this case, the management object 42 returns the number designated to the developer by the manager object 44. The management object 42 is an MRV object ID table tuple MRV_object version (old is -1).
Is changed to the number designated by the manager 44 (the number indicating the first latest version number). Thereafter, the ALLVERSIONS object ID table is updated with the new tuple containing object version information.

If there is no recent version and the MRV object version is not -1, it is a repeated combination of interface versions. For this combination, a lookup is performed to find the object version in the MRV object ID table. The lookup returns the latest version number of the object version. For example, it can be 1.0 or 1.1
Or, a value obtained by adding 0.1 to the number given to the version number, such as 1.2. The entry of the MRV object version into the MRV object ID table is changed to return the resulting new version number. ALL
The VERSIONS object ID table is also updated to a newer version number. The version number is returned to the developer by the management object 42.

If all object versions have the same interface version number associated with an interface, then the set of object versions is a “compatible interface”. For each distributed interface, the set of object versions forms a "compatible application" if the connected set of object versions is a compatible interface. All columns with the same interface ID are equal and the associated object version and interface version are designed (the number of columns in the output) to be valid for all unique compatible systems (partial order). Is equal to the number of the object in the application plus the number of the interface), all MRV object ID tables are merged. Thus, the internal coupling that occurs is an AND condition for multiple distributed interfaces. Janitor object 4
4 can make up an SQL query for the same and send it to the managed object 42. The management object 42 executes it and returns all tuples to the manager object 44. From the partial order of all compatible systems, the administrator can select compatible systems for deployment as appropriate.

In the implementation of the distributed management network, the management object 4
4 writes a separate SQL string for each managed object 42 domain. Each SQL string contains only local objects, but the admin object 44 works for both local and distributed interfaces as well. Each managed object 42 cannot make a complete decision on its outgoing interface. Each managed object 42 executes the SQL string and returns a result to the managed object 44. After obtaining responses from all managed objects 42, for all distributed interfaces that get the corresponding object and interface version, the manager object 44 performs a high-level combination of all intermediate results. The complexity of the assigned selection algorithm is NLog (N), where N is the number of the object version (the selectivity for a particular interface version value is limited by a constant).

Hereinafter, an example of a command supported for the administrator object 44 will be described.

[0138] 1. CreateObject / DestroyObject: The manager object 44 sends this command to the management object 42 together with the object ID, the object version, and the StartPortID. The object ID and the object version are the object 3 to be executed.
0 is uniquely identified. The management object 42 checks its own database where the information about the object ID and the object version is stored. The management object 42 updates the information in this database when the developer succeeds in the check-in. The management object 42 extracts the executable information and the argument, and stores all DLL files (
Copy). By using OS-level system commands, object 30 is executed with command line arguments. The first two arguments are: the host name that the clock server is running on, and the socket ID that the parent clock is polling for child connections. The third argument is a port name space (port) of the object 30 in the entire application network.
StartPortID indicating the name space. Different objects 30 do not have the same port name space. Upon receiving a successful creation of the object 30 from the lower level system, the managed object 42 returns a success message to the manager 44. On the other hand, it also returns failure. 1. Removal of the object is achieved using the kill / die protocol (using the appropriate set operation) via the state port. CreatePort / DestroyPort: This command dynamically changes the object port 32 for different interactions of the application.
In order to tune in the managed object (by the managed object)
Used to create object port 32. Object port 32
Is used to obtain the state of the object 30 and the clock. Port 32 of managed object 42 can be used to transparently disable / enable interaction from the outside. Disabling / enabling the interaction is achieved by using the HoldClock / Release command described below. The manager object 44 transmits the generated PortID, interface ID, and interface version. The last two values in the preamble are the IDL description associated with the interface version and the IDL backend (Bac
kend) and is used to extract the size of the object port 32. The CreatePort method has two parameters: Serv
The port ID indicating the ice ID and the size of the object port 32. The size of the object port 32 depends on the interface ID, interface version, and architecture. Since the human manager 44 can access the service of the object port 32 by holding the port ID, the generated object port 32 is registered in the management object 42. On the same line, object ports 32 can be removed if those services are no longer needed for network applications.

[0139] 3. CreateClock / DestroyClock: This command is
Used to generate a clock for the management object 42. It has only one parameter: Clo which must be unique in the system environment 10
ckID. Once a clock with a ClockID is generated, it is registered with the management system to access its services. When the clock is generated, it appears with the base phase. Any object port 32 tuned to that phase immediately gets the first progress command. After obtaining the first progress instruction, some create additional phases and tune more object ports 32 (application specific). The clock can also be removed if the service is no longer needed by the application.

[0140] 4. AddPhase / DestroyClockPhase: This command dynamically generates an improved phase for the base phase of the clock.
The object port 32 is then tuned to the refined phase.
Application behavior changes by adding newer phases for observation and control. Similarly, clock phases can be eliminated. The method of adding a phase has two parameters: BaseCloc
kID and RefinedClockID. Each phase of the clock is a separate service provided by the clock, and the caretaker object 44 accesses them separately as required.

[0141] 5. Tune / Detune Port: This command is used to tune (connect) different object ports 32 to different phases of different clocks in the application. This is a specific application, 3
Requires two parameters: PortID, ClockID, PhaseHa
ndle (base phase means ClockID, RefinedClock
is specified as above for any other phase that uses the kID). The plurality of object ports 32 can be detuned when their role is completed as part of a different interaction.

[0142] 6. Set / Get State of object: To set / get the state of the object 30, the manager 44 first sets the state interface ID.
And the interface version must be identified. After obtaining the IDL description for the object's state interface, the caretaker object 44 provides it to IDL Backend. The compiler for that backend IDL is:
For each element of all interface structures, a FieldNumber,
Generate FieldType, FieldOffset, and FieldSize. It also generates the actual size of the object port 32. The administrator 47 needs to understand the data bag 35 and the individual elements of its state. This feature is needed to allow transparent access to interactions. For example, for interface ID = 1,2,3, the IDL backend outputs as follows:

[0143]

[Table 19]

To set the state, the caretaker object 44 has a MessageType
The data field of e1 can be written. Then, the manager object 44 writes the StateValue. Information about 1, 0, etc. is obtained from the state IDL. In this way, the manager object 44 prepares the above raw bytes (4 bytes of information in the above example). Then, Set
The command is sent to the managed object 42, which is connected to the object's state interface, along with the raw byte data and the size of the raw byte. Managed object 32 may also obtain the raw byte size by receiving the object's state interface ID and interface version. Once a set command is received, the managed object port 32 writes that fact to the object 30 via its object port 32. If it receives a response from object 30, managed object 42
A response is returned to the manager object 44.

To obtain the status, the caretaker object 44 can write to the Data field of MessageType2. Information about 2 is obtained from the IDL of the state. Similar steps are performed to set the state. In addition, the caretaker object 44 uses the previous technique to split the raw four bytes received from the management object 42 into appropriately meaningful data. A method in which the manager 47 refers to meaningful data is supported. For example, the administrator 47 can refer to the following:

[0146]

[Table 20]

[0147] 7. SetState / GetState of Clocks (link
s) (CollectBag, WriteBag): Instead of the configuration associated with the state interface of object 30, use the IDL configuration associated with a different interaction. For example, an interface ID = 4 and an interface version = 1.0 are used. IDL Backend generates the following:

[0148]

[Table 21]

[0149] 8. Hold / Release Clock: The Hold Clock command tells the managed object 42 to hold the next progress command at the specified object port 32 until notified by the manager object 44.
Unless notified by the manager object 44, the management object 42
Does not release object port 32. Object ports 32 connected to other different phases within the same clock do not get progress notification and therefore remain stationary and stable. The caretaker object 44 can hold the progress signal as needed to analyze the application status. The hold is released by a specific release clock command from the manager object 44. Only when the managed object 42 sends a release along its port object 32 can the plurality of object ports 32 tuned to the next higher or lower phase communicate with each other.

[0150] 9. GetIDLs of Interfaces: By using this command, the caretaker object 44 can obtain the IDL description of the object 30 associated with different interfaces. If the manager object 44 receives IDL descriptions from the management object 42, those IDL descriptions are copies to the local database. This function is available when IDL
To be able to see.

[0151] 10. Register / Deregister port: These commands allow object ports 32 created within object 30 to be registered with managed object 42. Just then, the caretaker object 44 can access the service. The caretaker object 44 defines a port name space for each object 30 in the application system. Port services can be unregistered when no longer needed by the application.

The management framework 19 can be used to set up applications transparently and consistently. FIG. 12 shows an example of a network application set up by the administrator object 44. The caretaker object 44 sets up the network application 109, specifies initial conditions, and initiates and controls development changes and analysis. The caretaker object 44 determines the state of the objects 01, 02 and 03, and the state object ports 61a-c and the basic service object ports 62a-c
Are associated with the respective objects 01, 02 and 03. The caretaker object 44 receives all IDL descriptions for the interface of objects 01, 02 and 03. The backend IDL compiler receives the modified C
A meaningful description of ORBA IDL can be provided. FIG. 13 is a flowchart of a method for setting up the transaction network 110. Prior to setting up the network application, the INE is activated, as shown in block 111. Referring to FIG. 12, INE interface 45 is activated. The manager object 44 and the manager object 42 can execute the following methods for generating and registering the respective INE ports.

[0153]

[Table 22]

Referring to block 112 of FIG. 13, a clock is generated and registered in manager object 44 and management object 42. As shown in FIG. 12, the clock 86m is generated by the manager object 44 and registered in the manager object 44 and the management object 42. For example, ClockID = 5
The clock with 0 is the command OMF_CreateClock (Clock
ID). INE port 85a is tuned to the base phase of clock 86m using the following command:

[0155]

[Table 23]

At block 113, the caretaker object 44 instructs the management object 42 to create a port for each interface. For example, in network application 109, four ports are created, each associated with interface IDs 1, 2, 3, and 4. The manager object 44 transmits the interface ID and the interface version. Port 2, port 3, port 4, and port 5 are assigned to the management object ports. The sizes of the managed object ports 2 to 5 are established by the manager object 44. For example, managed object ports 2-5 each have a size of 4 bytes, this value being application specific.

At block 114, the caretaker object 44 instructs the managed object 42 to create the object. For example, the manager object 44 is 3
Manage messages to generate one object (: object ID is 1, object Ver is 1.0; object ID is 2, object Ver is 1.0; object ID is 3, object Ver is 1.0) Send to object 42. The three objects have their corresponding state object ports 61a-c and basic service object ports 62a-62c respectively.
Generate and register c.

At block 115, the managed object 42 displays each object status port 6
A clock is generated to connect 1a-c to managed object state ports 2-4. For example, ClockID = 1 is generated to connect the status port of the object 01 and the management status port 2 generated for the object 01. ClockID = 2 is generated to connect the status port of the object 02 and the management status port 3 generated for the object 02. Cl
OckID = 3 is generated to connect the state port of the object 03 to the management state port Port4 generated for the object 03. ClockID = 4 is generated to connect management state port 5 for interface ID = 4 to the base phase.

At block 116, the caretaker object 44 tunes the object status port and the management status ports 2-4. For example, the status port and management status port Port2 of object 01 are tuned to the base phase with ClockID = 1. The state of the object 02 and the management state port Port3 are Clo
Tune to base phase with ckID = 2. The status port and the management status port PORT4 of the object 03 are set to the base phase of ClockID = 3. The management state port Port5 is tuned to the base phase of ClockID = 4.

At block 117, the manager 44 initializes the state of the object 30.
For example, the manager 44 collects 4-byte raw data (using IDL output) and sends it to the management object 42 via the INE interface 45 in order to initially set the state of the object 30 to 0. The management object 42 writes the four bytes to the appropriate port connected to the corresponding management status port. The response received by the management object 42 is returned to the manager object 44 via the INE 45. The same is repeated for all object states.

The manager object 44 instructs to hold the clock related to the management status port 5 of the management object 42. On the immediately following advance command, the clock is held by managed object 42. It does not release the current step. It sends a response to the caretaker object 44. Thereafter, the caretaker object 44 can add phases and dynamically tune the three application service ports 62a-c to a new phase of the clock. The management person object 44 instructs the management object 42 to release the clock. After the management object 42 executes the command from the caretaker object 44, the application service port first obtains a progress command and an empty bag. At this time, object 01 is any other object 02
, 03 can be sent to any request. Objects tuned to the base phase must transfer data and hold released ports unless there is a request by the custodian object 44 to hold the clock. This ensures continuous progress of the application at this time. Application setup is complete. The caretaker object 44 can continue to monitor the state of the object and the state of the clock. Managed object ports 42 can be dynamically detuned from the application until dynamic reconfiguration is required, as described below.

Dynamic reconfiguration of network applications involves the implementation of adding and deleting new object versions to the object state and service ports of the application network without shutting down services of existing objects. For example, bug resolution will result in a newer version. For example, if an independent transaction is completed or in progress, the object ports can be tuned or detuned. In the method of the present invention, dynamic reconfiguration occurs at the quiesce point of the application. The quiesce point is established by the managed object 42 by following the interaction framework 16 in which the managed object 42 in progress only receives when all object port bases are released and at least one port is started. Receipt of the progress command by the management object 42 is a stationary point. Therefore, before any changes are incorporated, the object can be arbitrarily sent a message, the clock collects the message and sends it to the managed object, and a quiesce state waiting for management to get progress instructions from the clock. Without forcing, quiescence is achieved automatically.

FIG. 12B illustrates the minimization of disruption to achieve quiescence. Application objects are not forced to become quiescent. Objects 01, 02 and 03 spontaneously send responses. The clock collects the data and sends it to management. Management waits for a progress command from the clock. This reduces management complexity. The administrator can incorporate changes only if the administrator has a progress order and has control. The holding is performed only for receiving the progress command. The caretaker transparently understands the completion of an independent transaction from the outside.

FIG. 14 is a schematic diagram of a network application 109 in which a new version of an object is dynamically implemented. The existing object 02 has two active interfaces: a state interface 2 and a BasicServicePort interface 4. Object 02 is
Before detuning from each clock phase, both of these interfaces must be inactive. Initially, the manager object 44 sends the hold clock associated with the interface ID = 4 message to the manager object 42. In the next immediately proceeding command of the management port Port5 connected to the interface ID = 4, the clock is held by the management object. The caretaker object 44 gets a notification about the clock hold. In the notification, the manager object 44 obtains the data bag 35 (not shown). From the IDL backend compiler for which the size, type, and offset were generated, the caretaker object 44 knows the components in the data bag 35. The information obtained by the manager object 44 is the initial condition of the clock. At this point, objects 01, 02 and 03 have already been released for the previous step and at least one trigger has been issued since managed object 42 is holding its clock advance instruction associated with interface ID = 4. , And wait for the next earliest progress order. At this point, object states 01, 02 and 03 are stable for this interface. Objects 01, 02 and 03 do not know who the message spans between steps, but rather data, release and trigger (if necessary)
Is voluntarily distributed, and management including information is transparent to the object on which it operates. The caretaker object 44 can decode the raw bytes received from the managed object 42 for the distributed interface ID = 4 using IDL Backend. For example, the output will be one of the following:

[0165]

[Table 24]

The purpose is to replace object 02 version 1.0 with object 02 version 1.1. Depending on the situation, the caretaker object 44
You must map the situation to the IDL description associated with the currently running version and understand how the transaction proceeds and when this point. The caretaker object 44 must find out whether the input affects the state of the object. From the IDL of object 02, the following scenarios can be established: For situation # 1, object 01 has just begun a transaction; the state of object 01 is 1; the state of object 02 is 0;
The state of object 03 is 0; if the old and new object versions have the same state transitions,
The old version can be replaced by a new one and the new version of object 02 can be initialized to zero. Thereafter, the transaction can be continued and the caretaker object 44 must release the held clock. If the old and new object versions do not have the same state transition, the caretaker object 44 must find the new version's equivalent state and initialize it. If the caretaker object 44 cannot find an equivalent state, it proceeds the transaction another step and holds again. Repeat the previous steps until the independent transaction completes at the initiator. At the end of the transaction,
If necessary, all objects can be replaced.

[0167] 2. For situation # 2 or # 3 or # 4, the state of object 02 is 0, and if the old and new object versions have the same state transition, the old version can be replaced by the new one The new version of 02 must be initialized to 0. Thereafter, the transaction must be continued and the caretaker object must release the held clock. If the old and new object versions do not have the same state transition, the caretaker object 44 must find an equivalent state for the newer version and initialize it. If the caretaker object 44 cannot find an equivalent state, it proceeds the transaction another step and holds it again. Repeat the previous step until the initiator completes its independent processing. At the end of the transaction, all objects can be replaced if necessary.

The old object 02 can be replaced at any step of the transaction, as a result of which the manager 47 can draw by mapping the situation to the IDL description: TRANSAC_NAME_SQUARESUM. If the caretaker object 44 cannot find the mapping state for the new object version, it causes the transaction to go to another cycle and hold it again. Check and repeat this process until the transaction is completed at the initiator. Also, when necessary, find an equivalent state.
In this embodiment, the manager object 44 can complete the states of the objects 01, 02, and 03 by paying attention to the input. Alternatively, the caretaker object 44 needs the state of the object and the link before determining the status of the object 30.

If it is scenario # 1, for example, the caretaker object 44 finds that the new object version has a state that can be initialized to 0, and that its behavior is the same as the old version. Manager object 44 notifies manager object 42 to detune the object 02 service port from the clock. The management object 42 executes it. Object 02
Cannot exchange any further progress commands or data. Object 01 and Object 03 also cannot receive progress instructions or data,
Therefore, no further communication is possible. The manager object 44 sends a message to the management object 42 to obtain the status of the object 02. The management object 42 sends a state acquisition request to the object state of the object 02. Object 02 announces a stable state and managed object 42 receives on port 3.

The management object returns the state information to the manager object 44, and the manager object 44 understands the actual state information again. Janitor object 4
4 sends a removal message to destroy object 02. The removal message is sent to object 02 and a response is received by managed object 42. At this time, the connection of the status port of the old object 02 and clockID = 2 is removed from the connection of the status port of 02 and the managed object port 3. When this message is received, the old object 0
2 removes itself and further the Basic service port 62b. The caretaker object 44 is notified of the removal. It is noted that the caretaker object 44 also holds ClockID = 4 in the base phase. Managed object port 3 is removed.

The caretaker object 44 contains a new version of the object, for example, 1.1
Produces. The caretaker object 44 creates a port at managed object port 6, creates a clock with ClockID = 5, and then tunes the new object state port and the new management port Port6 created at the base phase of the clock. If there is a direct one-to-one state mapping, the caretaker object 44 sets the new object state to the value obtained from the old object, otherwise it can set the new object to the equivalent state. . Later, the service port of the new object is tuned to phase one of the clock. Clock data received by the caretaker immediately after the hold of the clock is written to the clock by the caretaker object 44, which releases the clock. Then, all three object ports for objects 01, 02 and 03 get a progress signal. Object 02 immediately receives a request from object 01 in the path held by the caretaker object 44. The application continues as in the earlier form. Neighboring objects 01 and 03 have no knowledge of the replacement of object 02.

FIG. 15 is a schematic diagram illustrating dynamically implementing a new version of an interface. For example, the interface ID = 4 indicates a third field (third f) indicating an object ID indicating from which object the object came.
field). First, the manager object 44 sends the hold clock associated with the message of interface ID = 4 to the management object 42. On the next proceeding instruction of managed object port 5 connected to interface ID = 4, the clock is held by managed object 42. The caretaker object 44 receives a notification about the hold of the clock. Based on the notification, the manager object 44 stores the data bag 35
(Not shown) to get the data and understand it. This information obtained by the caretaker object 44 is the initial condition of the clock. At this point, since holding the clock advance instruction associated with interface ID = 4, objects 01, 02 and 03 have already been released for all previous and
At least one trigger has been sent and the next progress command is waiting for the earliest next progress command.

As explained above, four situations are possible. Since all three need to be replaced, the transaction must be completed at initiator object 01, or an equivalent state must be found. in this case,
All objects are removed and a new object version with a new interface version is entered into the system. In some situations, the caretaker object 44 notifies the management object 42 to detune the object 02 service port from the clock. The management object 42 executes it. Object 02 cannot exchange any further progress commands or data. Object 01 and Object 03 also cannot receive progress instructions or data, and therefore cannot communicate anymore. The manager object 44 sends a message for obtaining the state of the object 02 to the manager object 42. The management object 42 sends the status acquisition request to the object 02
To the object state interface. Object 02 announces a stable state and managed object 42 receives on port 3.

Similarly, the service ports of the old objects 01 and 03 are
Detuned from clock. The manager object 42 obtains the states of the object 01 and the object 03. The management object 42 returns the status information to the manager object 44, and the manager object 44 understands the actual status information again.

The caretaker object 44 sends a removal message to remove the object 02. The removal message is sent to the object and a response is received by managed object 42. The state port of the old object 02 is then detuned. ClockID = 2 connecting the state port of object 02 and the managed object port 3 created for object 02 is
Removed. Old object 02 removes itself and also the basic service port based on receipt of this message. Janitor object 4
4 is notified about its removal. Similar steps are repeated for objects 01 and 03. Managed object 42 is still in base phase C
It is noted that lockID = 4 is being held. Management port Port
2, 3 and 4 are removed.

The caretaker object 44 creates a new version of version 1.1 of object 01. The caretaker object 44 creates a port at managed object port 6, creates a clock with ClockID = 5, and then tunes the new object's state port and the new management port created at the base phase of the clock. If there is a direct one-to-one state, the caretaker object 44 sets the new object state to the value obtained from the old object, otherwise sets the new object to an equivalent state. The same is repeated for object 02 and object 03. The state is appropriately set by the manager object 44. Soon,
The caretaker object 44 creates a port 9 that is 6 bytes in size. The caretaker object 44 creates a clock and tunes port 9 to the base of that clock. The manager object 44 instructs the manager object 42 to hold the clock. Upon the arrival of the next progress command, the management object 42
Informs the manager object 44 about it. Manager object 44
Can create a phase 1 in the clock, tune all three new Basic service ports of the new object to that phase, and then release the clock.

The clock data received by the manager object 44 immediately after holding the clock 4 has only 4 bytes of information. However, the new clock has 6 bytes of information. Since deploying the application is consistent, the caretaker object 44 must change the initial conditions of the interface as appropriate.
The caretaker object 44 can change the old clock data, which is then written to the clock 8 via the management object 42. Later, the caretaker object 44 releases the clock. Right now, all three ports of the object have obtained a progress command and the caretaker has written to the data bag 35 so that the application continues as it was in its original form. None of the old objects 01, 02 and 03 are relevant.

Dependent transactions are handled in the same way that independent transactions are handled by the caretaker object 44. The caretaker object 44 must wait until the management port is tuned to the interface receiving the progress command. The interface supports dependent transactions. Only after all other dependent and / or independent transactions on the interface have completed the managed object port receives a progress command. A progress order is not easily received, but a progress order will be received someday (
Both dependent and independent transactions are completed at the initiator in a limited amount of time). Eventually, as the management port goes forward, the caretaker can hold it, analyze the state, and then make the appropriate changes. Dependency graphs are used to determine the state of an object. The administrator can analyze the state of all objects by the dependency graph. In an IDL description, instead of using an independent transaction, the description indicates the degree of dependence.

It can be seen that the above-described embodiments have demonstrated only a few of the many specific embodiments that represent applications of the scheme of the present invention. Various and improved other arrangements are readily invented by those skilled in the art according to the above schemes without departing from the scope of the invention.

[Brief description of the drawings]

FIG. 1 is an architecture diagram of a distributed software development environment according to the teachings of the present invention.

FIG. 2A is a schematic diagram of a distributed network of multiple objects.

FIG. 2B is a schematic diagram of a distributed network of multiple objects in a two-phase transaction.

FIG. 3A is a schematic diagram of an interaction network and phases.

FIG. 3B is a schematic diagram of the steps of the different phases in the interaction clock.

FIG. 4 is a schematic diagram of a distributed management network.

FIG. 5 is a schematic diagram of a stage of a life cycle.

FIG. 6 is a schematic diagram of a network application.

FIG. 7 is a flowchart of a method of unlimited negotiation.

FIG. 8 is a schematic diagram of a negotiation network.

FIG. 9 is a block diagram of steps for realizing a network application.

FIG. 10 is a flowchart of a method for determining compatible applications.

FIG. 11A is a schematic diagram of a deployed network application.

11B is a schematic diagram of a plurality of compatible applications according to the development shown in FIG. 11A.

FIG. 12A is a schematic diagram illustrating a consistent, transparent network application set by a human caretaker.

FIG. 12B is a schematic diagram showing minimization of splitting to achieve inactivity.

FIG. 13 is a flowchart of a method for setting up a consistent and transparent application network.

FIG. 14 is a schematic diagram of the network application shown in FIG. 11 during relocation for object replacement.

FIG. 15 is a schematic diagram of the network application shown in FIG. 11 during relocation to implement a new version of the interface.

──────────────────────────────────────────────────続 き Continuation of front page (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE ), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SL, SZ, TZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, DM, 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, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW (72 ) Inventors: Surya Narayana, Manjunas, M. Highland Park, New Jersey, United States, Cedar Lane 110A F-Term (Reference) 5B076 AC01 DB00 DC07 DD05 [Continued Summary] Yes. During the design stage, the management framework can also be used by software developers to perform limitless negotiations.

Claims (58)

[Claims] 1. An object comprising: a plurality of objects for performing an object operation; each object including an object interface; at least one object port connected to the respective object interface of the object; An interaction means for connecting one of the object ports to another of the object ports of the object, wherein the object interface is compatible, and the interaction means has the compatible interface. One of the objects communicates with the other one of the objects when the dynamically changing settings provide control from the object operation and sequential flow of data. Distributed object-oriented software development environment that can. 2. The interaction means is represented by a circular communication path,
The development environment of claim 1 wherein a first said object port is connected to said circular communication path for receiving information from at least a second said object port connected to said circular communication path. 3. The development environment according to claim 1, wherein said interface is described in a modified CORBA interface description language. 4. A management system comprising a plurality of managed objects, each said managed object being associated with at least one of said objects, comprising: a manager object; and an evolution of a network connecting said managed object to said manager object. The development environment according to claim 1, further comprising an interface for managing an object by the management object. 5. The development environment according to claim 4, wherein said manager object assigns increasing object version numbers to said objects. 6. The development environment of claim 5, wherein the caretaker object assigns a monotonically increasing interface version to the object interface, and each of the object interfaces has a unique global ID in the application network. 7. The apparatus of claim 6, further comprising means for determining the compatible interface of the object by registering the global ID and the object version number of the object having the managed object. Development environment. 8. A means for determining a row representing the object version of the object in the network application, and an object table including a column representing an object ID and an interface ID; and determining the determined object table for the object version. Means for sorting; sorting the first sorted object table for the first object and the second sorted object table for the second object with a common interface ID. Means for connecting the first sorted object table with respect to the interface ID and the second sorted object, 7. Development of serial further comprising means for extracting from the connection of the object tables, the. 9. A means for sorting a next object table relating to the common interface ID, and using the connected first sorted object table and the second sorted object table. 9. The development environment of claim 8, further comprising: means for connecting a next object table. 10. A specification stage in which the object and the interface are defined, a design stage in which the interface of the object is negotiated, an implementation stage in which the negotiated interface of the object is implemented, and The development environment of claim 1, further comprising a life cycle framework that includes a test stage in which the implemented interface is tested. 11. A. Determining a caretaker object; b. Determining at least one managed object; c. The manager object and the management object by indicating by the manager object an object having the at least one management object that generates a plurality of objects for performing object operations (each of the objects includes an object interface). Determining an interface for network evolution (INE) between d. And d. Generating interaction means for connecting the at least one object to the managed object; e. Determining at least one managed object port associated with the managed object; f. Determining at least one object port associated with the object; g. Advancing negotiations from the object port to the managed object port. A method for implementing negotiation during software development. 12. The method of claim 11, further comprising: assigning from the caretaker object a task of designing the object to each of developers associated with at least one of the objects. 13. The method of claim 12, further comprising the step of creating a developer negotiation port by said developer for each of said objects to be developed. 14. The method of claim 13, further comprising registering the developer negotiation port with the caretaker object. 15. The method of claim 14, further comprising: creating a management negotiation port for the managed object, each of which is associated with a respective one of the developer negotiation ports. 16. The step g, wherein said respective administrator negotiation port for proceeding to a designated object is transmitted to said respective developer negotiation port via said respective developer negotiation port, said negotiation script being described in the modified CORBA IDL by said developer. 16. The method of claim 15, comprising sending 17. The modified CORBA ID received at the managed object.
17. The method of claim 16, further comprising sending the script written in L to the caretaker object through the INE. 18. The modified CORBA I received on the caretaker object.
The method of claim 17, further comprising translating the script written in DL into human-readable data. 19. The method of claim 11, wherein advancing the negotiation is repeated until all developers agree. 20. The method of claim 19, wherein the negotiation determines an object interface defined in a modified CORBA IDL. 21. determining a plurality of objects; associating an object port with each of the objects; determining a transaction for exchanging messages between the objects; and an object interface to each of the objects. And implementing a respective determined object interface, wherein the messages are sequentially exchanged between the objects having the compatible object interface. . 22. The method of claim 21, further comprising registering the object interface with the implemented object and a management framework, wherein the management framework returns an object ID, an object version ID, and an interface version ID. 23. The method of claim 22, wherein said implementing step further comprises determining a network application having said object version ID that is compatible. 24. The step of determining a network application having a compatible object version comprises the steps of: a. Determining an object table that includes a row representing the object ID and the object version ID, and a column representing the interface version ID; b. Sorting the determined object table with respect to the object version ID; c. Sorting a first said sorted object table for a first said object and a second said sorted object table for a second said object with respect to said common interface ID; d. . Connecting said first sorted object and said second sorted object with respect to said interface ID forming a connection of said object table; e. 24. The method of claim 23, further comprising: extracting the compatible object from the connection in the object table; and extracting the compatible object from the connection in the object table. 25. f. Sorting the next object table with respect to the common interface ID; g. 25. The method of claim 24, further comprising: using the connected object table of step d to connect the next object table. 26. The method of claim 24, wherein said object table is generated to obtain said object version ID and said interface version ID incrementing in said row and said column. 27. Determining a plurality of managed objects, each said managed object being associated with at least one of said objects; determining a manager object; connecting said managed object to said manager object. 22. The method of claim 21, further comprising: determining an interface for network evolution; and managing the object by the administrator object interacting with the managed object. 28. The method of claim 27, further comprising: updating the determined object; and assigning an updated object version number to the updated object via the managed object by the manager object. Method. 29. The method of claim 27, further comprising: updating the object interface; and assigning the updated object via the managed object an interface version number that is incremented by the manager object. 30. a. Determining a caretaker object; b. Determining at least one managed object; c. The custodian object determines an interface for network evolution (INE) between the custodian object and the managed object, and at least one object for performing an object operation (each of the objects has an object interface). Indicating the at least one managed object by the caretaker object that generates the d. The INE for connecting the object to the managed object;
Generating an interaction means also connected to the manager object and the manager object; e. Advancing the initialized state to the object by the INE to advance the managed object to the initialized state; advancing the managed object from the managed object to the object to the initialized state; Initializing the state of the object at the caretaker object. 31. f. Determining an administrator object INE port for the administrator object; g. Determining a managed object INE port for the managed object; h. 31. The method of claim 30, further comprising: after step c, associating the INE port for the manager object and the INE port for the managed object with the INE. 32. The method of claim 31, further comprising: determining at least one port associated with the managed object; and determining at least one object port associated with each of the objects. 33. The object interface of claim 28, wherein the modified CORBA I
31. The method of claim 30, defined in DL. 34. A step of determining a manager object; determining at least one management object; and determining, by the manager object, the at least one management object that generates at least one object for performing an object operation. Objects (each said object includes an object interface,
Determining an interface for network evolution (INE) between the manager object and the managed object by indicating the original state) and connecting the at least one object to the managed object. Generating at least one managed object port associated with the managed object; determining at least one managed object port associated with the managed object; and modifying the managed object by the managed object. Establishing a quiesce point for at least one of said objects to be dynamically modified. 35. The method of claim 34, further comprising sending data to update said at least one object from said object to said caretaker object. 36. determining the port of the object to be changed; sending a remove command from the caretaker object to reconfigure the port to be changed; Generating a new version of the object, sending the new version of the object to the managed object, generating a new object with the new version of the object, and creating a new object associated with the new object. 36. The method of claim 35, further comprising: determining an object port. 37. If the original state of the object is the same as the state of the new version of the object, determining at the caretaker object; and if the original object version and the new version have the same state. Replacing the original object version with the new version; and if the original object version and the new version do not have the same state, determine an equivalent state in the caretaker object and replace the original version with the new version. 37. The method of claim 36, further comprising: replacing. 38. The method of claim 37, further comprising advancing data for updating said at least one interface version from one of said objects to said caretaker object. 39. determining a number of the object to be changed for the update of the interface version; and sending a removal command from the administrator to reconstruct the number of the object to be changed. Generating a new version of each number of the object that is changed in the caretaker object; sending the new version to the managed object; and generating a number that matches the new object with the new version. 39. The method of claim 38, further comprising: 40. The object interface of claim 1, wherein the modified CORBA I
35. The method of claim 34 defined in DL. 41. A means for determining a manager object, a means for determining at least one management object, and the at least one management object for generating a plurality of objects for executing an object operation by the manager object. object(
Determining an interface for network evolution (INE) between the caretaker object and the managed object by indicating each of the objects includes an object interface; and Means for generating interaction means for connecting one object, means for determining at least one managed object port associated with the managed object, means for determining at least one object port associated with the object, and the object Means for facilitating negotiation from a port to the managed object port; and a system for implementing negotiation during software development. 42. The system of claim 41, further comprising means for generating a developer negotiation port by said developer for each said evolving object. 43. The system of claim 42, further comprising means for registering said developer negotiation port having said caretaker object. 44. The system of claim 43, further comprising means for generating a management negotiation port at the management object associated with one of the developer negotiation ports. 45. The system of claim 44, wherein the negotiation is written with a modified CORBA IDL. 46. A means for determining a plurality of objects; means for associating an object port with each of said objects; means for determining a transaction for exchanging messages between said objects; A network application, comprising: means for determining an object interface; and means for implementing each determined object interface, wherein the messages are sequentially exchanged between the objects having the compatible object interfaces. A system that implements 47. The system of claim 46, further comprising means for registering said implemented object and said object interface having a management framework, said management framework returning an object ID, an object version ID, and an interface version ID. 48. The system of claim 47, wherein said means for implementing comprises means for determining a network application compatible with said object version ID. 49. The means for determining a network application having a compatible object version comprises: an object including the object ID, a line representing the object version ID, and a column representing the interface version ID. Means for determining a table; means for sorting the determined object table with respect to the object version ID; and first and second sorted object tables for the first object with respect to a common interface ID. Means for sorting a second said sorted object table for said two objects; and said first said sorting with respect to said interface ID forming a connection of said object table. The system of claim 48 comprising been a means for connecting the object and the second of said sorted objects, means for extracting an object in said compatible from the connection of the object table, the. 50. The object interface according to claim 50, wherein the modified CORBA I
47. The system of claim 46 defined in DL. 51. A means for determining a custodian object; means for deciding at least one managed object; and wherein said custodian object comprises an evolving network (INE) between said custodian object and said managed object. Means for determining an interface for performing the object operation and pointing to the at least one managed object by the caretaker object generating at least one object (each said object including an object interface) for performing an object operation; Means for generating interaction means also connected to the INE and the caretaker object for connecting the object to the object, and the first means for advancing the managed object to the initialized state. Reduction to the state proceeds to the object by the INE was advances the managed objects state of being the initialization from the managed object to said object,
Means for initializing the state of the object at the caretaker object. 52. An administrator object IN for the administrator object
Means for determining an E port; means for determining a managed object INE port for the managed object; and associating the INE port for the manager object and the INE port for the managed object with the INE. 52. The system of claim 51, further comprising: 53. The apparatus of claim 52, further comprising: means for determining at least one port associated with the managed object; and means for determining at least one object port associated with each of the objects. system. 54. The object interface according to claim 54, wherein the modified CORBA I
52. The system of claim 51 defined in DL. 55. A means for determining an administrator object; means for determining at least one management object; and said at least one management object generating at least one object for executing an object operation by said administrator object. Objects (each said object includes an object interface,
Means for determining an interface for network evolution (INE) between the manager object and the managed object by indicating the original state) and connecting the at least one object to the managed object. Generating at least one managed object port associated with the managed object; determining at least one managed object port associated with the managed object; and modifying the managed object by the managed object. Means for establishing a quiesce point for at least one of said objects to be dynamically modified. 56. A means for advancing data for updating the at least one object from the object to the caretaker object; means for determining the port of the object to be changed; removing the port to be changed Means for sending a remove command from the caretaker object to generate a new version of the object that is changed in the caretaker object; means for advancing the new version of the object to the managed object; The system of claim 55, further comprising: means for creating a new object having the new version of the object; and means for determining a new object port associated with the new object. 57. Means for advancing data for updating said at least one interface version from one of said objects to said caretaker object; and for said object being modified for said updating of said interface version. Means for determining a number; means for sending a remove command from the manager to reconstruct the number of the object to be changed; generating a new version of each of the number of the object to be changed in the manager object. 57. The system of claim 56, further comprising: means for advancing the new version to the managed object; and means for generating a number that matches a new object with the new version. 58. The object interface of claim 28, wherein the modified CORBA I
56. The system of claim 55 defined in DL.