KR20020038575A - Method and apparatus for maintaining data integrity across distributed computer systems - Google Patents

Abstract

The present invention discloses a method and apparatus for maintaining data integrity across distributed computer systems. In one embodiment, the method includes transferring an object from a server application to a client application. The method also includes transmitting the object state from the server application to the client application. The method further comprises synchronizing the object state between the object, the server application and the client application, and updating the object by invoking a server application method after the synchronizing step. Also disclosed is a manufacturing apparatus and an article for performing the steps of the method.

Description

METHOD AND APPARATUS FOR MAINTAINING DATA INTEGRITY ACROSS DISTRIBUTED COMPUTER SYSTEMS

Currently, there are several different techniques for supporting information processing in a distributed environment. Each of these techniques has been designed to meet specific purposes. The remote procedure call system may, for example, run a program capable of executing a function on one computer on another computer. Object request brokers provide similar services, but with some minor modifications that follow the object description. Database connection systems allow a program to retrieve data from a database on another computer. The messaging system allows a program to communicate with each other on a remote computer, often storing messages and sending them when communication can be made if necessary. Public and subscriber systems allow a program to broadcast a message, and only the systems subscribed to the message receive the message. There are several different techniques in this field.

In many cases, communication technology provides the same services when communicating with other programs on the same computer, or when communicating with one on another computer; In some cases it even communicates with services within the same program. In other cases, other techniques should be used when communicating within other configurations.

However, the current state of the art creates some implementation problems. No existing service meets all the requirements of modern distributed applications. Other services are rarely integrated, which means that a program that needs some combination of services will have to do a lot of work to combine them. In practice, it is very difficult to do this without introducing small errors that compromise the integrity of the data. In addition, the exclusive nature of many of these services often makes it impossible for developers to combine them. For example, Microsoft provides an ORB called COM, which is based on conventional connection-based communication. Microsoft also provides a store-and-forward messaging system called MSMQ. However, COM does not support the use of MSMQ for communication and allows asynchronous invocation of services.

State shipping technology

Object request brokers

Currently, there are many systems that provide invocation of services within a remote server. These are often referred to as remote procedure call (RPC) services. Based on the object model, they are referred to as object request brokers. These systems are fundamentally invalidated in that they maintain the state of objects on the server. When a client-side program constructs a distributed system where it is desirable to refer to the individual characteristics that make up the state of a server-side object as a whole, developers typically have two choices, both of which are not interesting.

The object server presents individual properties using property retrieval methods of type getCurrentBalance and property setting methods such as setCurrentBalance. However, this can be very inefficient. In other words, in order to retrieve the complete picture of the object state, the client program will have to make a large number of requests. Modern network systems and database processing systems are not designed to handle a large number of small needs very efficiently. In other words, the overhead and latency of networks and databases will make this very expensive.

The object server can suggest a getState method that returns a data structure containing the entire state. This is more efficient because the entire state is passed from one conversation to the client, but it breaks the object model. First, if the state is coded as a typical struct of common non-object languages, the programming model breaks down, mixing object and non-object descriptions. If a state is coded as an object, then it is a local client-side object with very different characteristics, i.e. it has no methods and relationships with the server; The original service has two different types of objects, objects that have methods but no properties. To change the properties of the server object, applications must change the local state object and then pass it back to the server by calling a method like setState (theState). Also, after the client-side state is changed but not yet written back to the server, we have two contradictory state variants, and the processing logic gets different results depending on which variant is called. Because of these limitations in the transmission state, it is desirable to use object request brokers with services that handle the state more efficiently.

Database access system

There are many systems that provide remote access to database servers. Some of these systems include automatic cache processing. When a record is retrieved from the server, the application can retrieve the values from the record without requiring re-fetch again, changes to the records are kept in the cache, and again when a commit operation is executed. All are written to the server. Some of these systems are based on object descriptions in that they present search data in the form of objects in the application's programming language.

These systems are severely limited in that they retrieve the object from the client, but they cannot invoke the object's methods on the server. Object invocation methods on the server are, in that, once the state of the object is sent to the client, where the object is maintained, the state may change for the client, and the methods on the server are not important. This creates a challenge for these systems.

Note that this problem is also caused by a common relational (SQL) database that provides common support for executing stored procedures. For example, if a record is retrieved for a client, a change is made to the record in the client-side cache, and if these changes have not yet been written to the server, and if the stored procedure invokes the server side where the stored procedure is called, the stored procedure Will work the wrong data. Because of this limitation in supporting distributed processing, it is desirable to use database access systems with services that handle distributed processing more consistently.

Caching by Store Transfer Technology

Cache processing

Cache processing is a well known casul. Many systems provide local caching of information from database access tools to web browsers, improving response time and reducing network traffic.

The read cache is used to keep copies of the retrieved information. In other words, if an application requires the same information again, it may fetch it from the cache. The cache may be temporary, storing information only for one session, or it may be persistent to keep information on disk between sessions, or even to keep information even when the computer grows. Of course, if the information on the server changes, the cache is useless. This is acceptable in the case of web browsers, and the user is responsible for updating the information from the server. In other cases, this is unacceptable because the information is more dynamic, or because the application is more important. Asynchronous event notification of server-side changes is a proven technique for maintaining concurrency between elements of distributed applications. The application program can be operated by objects stored permanently in the database, and uses caching for its well-known performance gains. In other cases, if another application in the network changes the value of an object in the database, the system sends an event notification to the application to update the value of the object. The value is updated in the cache, and event notifications can be passed to the application to update its calculations or values in the on-screen.

The write cache is used to temporarily hold the changes made to the data. When a client-side application makes changes to objects in its cache, these changes are retained in the client-side write cache. Ultimately, changes are recorded through the database server. As long as the client and server are connected, changes are recorded when a commit operation is performed within the application. Depending on the cache manager and the concurrent control manager's method, changes may be written faster, but at least the recording is done at commit time.

Using a typical cache processing system, event notification (synchronizing changes from server to client) and cache recording (synchronizing from client to server) work effectively only if the client computer is connected to a database server. However, these systems cannot handle the case when the connection is lost. If the database server is inaccessible at commit time, changes are lost unless they are recorded. Similarly, since no notifications can be sent to the client, any changes that occur in the database while the systems are connected will be lost.

While the application is in a pending state specifically responding to a failure exception, it can wait for the connection to reset and the commit operation can complete, which is an undesirable solution for several reasons. First, this puts an application developer on the burden of handling this problem. It's difficult to handle these outages accurately, and not all application developers are likely to have the skills or budget to handle them correctly.

Secondly, the application essentially hangs during this wait. Because of incomplete transaction pending, no other database operations can be performed because they are part of the same transaction. In the end, it violates the meaning of the application.

In addition, if the application is intentionally or accidentally stopped, the pending state of the application will be lost, and all changes will be lost as well.

Systems may be disconnected for many reasons. There may be unplanned budgets. That is, network links may be temporarily stopped due to hardware or software failures, congestion, or wireless link interfaces. These unplanned budgets are more common today than in the past because more systems operate in a wide range of distributed configurations to communicate over uncertain dial-up or wireless links. There may also be planned budgets. For example, portable computers are only intermittently connected by sales representatives who use the machine to price future clients, and often may be connected to headquarters to download price changes.

In summary, existing cache processing systems are useful, but it is desirable to improve their operation in terms of communication budgets.

Event notification

The problem of data integrity is controversial for applications where conventional pessimistic concurrency control is used by locking objects in a database. If the application holds exclusive locks on the objects, other applications cannot update them, so no notifications need to be sent and no one needs to wait. There are at least two practical debates on this.

First, pessimistic simultaneous control is not practical in a wide range of distributed environments. Absolutely not where you have intermittent connections. The configuration prevents the salesperson from moving to hold the locks on the objects in the on-premises database, for example to prevent the headquarters from changing the price. Experience suggests by experience that only a practical concurrency control model is optimal in such a wide range of distributed environments, where remote applications do not have locks in the database and instead respond to event notifications.

Secondly, despite the management of locking, the change may be performed on the server by the calling method initiated by the same application. These side effects are then propagated to the remote application using event notification. In some cases, using the long-running method, the connection may be disconnected by the time the method is completed, so event notification needs to be waited for in the storage and transmission system.

While this overview is unlikely to appear in typical transaction processing applications, where server-side methods are short-running, there are other application types that require it today. For example, an application may maintain a track of files on disk, and the method called may be a backup operation; After the backup operation is completed, the changed write status flags must be sent to the application, and it needs to be waited because there is no need to interrupt the backup operation because the network link is temporarily interrupted.

Store-and-forward messaging systems

Storage and transmission is also a well known technique, where messages sent to a computer location are temporarily queued if the destination computer is unavailable and delivered as soon as a connection is established.

Persistence by reachability technology

In some systems, the object database operates under the provision that a potentially persistent class of objects is still temporary when created in the application. An object is permanent only when it is explicitly saved through the execution of any particular method or state.

In such a system, the objects may also be related to each other. These associations may be direct, such that an object has the property of including a direct pointer or an address or path to another object. Alternatively, they may be indirect, such that there is a third object that acts as a join or link between the two objects.

Such systems have at least one potential problem. In other words, a persistent object may have a dangling reference, a pointer to an object that has never been saved, so that it does not exist when the application wants to recreate the object structure.

A common solution to this problem is automatic persistence throughreachability, also called "transitive persistence." Systems using this technique automatically pass a reference, find all accessible objects from persistent objects, and save them.

However, these systems implement persistence through this accessibility only within a single database. More complex application systems that accept objects from several databases and support relationships between objects in separate databases do not provide automatic handling of persistence.

Dual object resolution technology

In all systems that retrieve data from a database, there is a possibility to retrieve the same data twice. This is the case within the simplest programs that read data from a file, and programs that use ordinary related tables. The possibility of double retrieval creates the possibility of a latent program error known as a lost update. Consider the following example written as a pseudo code:

If two first states occur simultaneously to find the same item, it is expected to have two changes applied to the same item's property, so that the property is increased by 300, but will not actually happen. The program has two copies of the original characteristic. For example, let's say the initial value is 10,000. The third statement of the program will form the characteristic 1100. The fourth statement will form the characteristic 1200. The fourth statement will write 1100 to the database. The last statement will write 1200 to the database. In practice, the addition of 100 is lost.

Note that transaction processing or concurrency control does not solve this problem, because an error occurs even when all operations occur within the same transaction context. Concurrency control prevents individual programs from colliding, but eliminates the possibility of errors in programming logic.

This is a simple error and it can be discussed that the programmer tests, noting that two first read operations are actually referenced to the same object. However, this may be difficult because object retrieval may be very indirect. We initially found two separate people, then locate the individual departments in which they work, and then the managers of these departments. It may not be obvious that we can reach the same person through two different paths. Similarly, we search for an object in one part of the program, and then run a query to search for some objects in parts that are not completely relevant, perhaps possibly written by another programmer, one of the objects Same as already fetched.

Due to the complexity of the missing update problem, no database system provides a solution. However, the applicant's system can be used to solve the problem and reduce the likelihood of missing updates.

Object databases

While potential problems can arise in all databases, in fact in all permanent repositories, it seems to be further hampered by object databases with closed language bindings. Since this object database appears to have a higher level, errors such as lost updates due to object surrogate copies, because applications present objects in the database, such as a large sea of objects that can pass seamlessly. To further stimulate. Similarly, developers using object databases expect more than users of simpler related databases.

Dynamic Concurrency Control Technology

In many cases, the application program requires typical properties of concurrency control, including atomicity, consistency, separation, and durability of operations performed on data retrieved from data sources. Many applications need to access transactional and non-transactional data sources, and the disclosed system is designed to support all providers.

Database systems typically rely on locking to ensure isolation of concurrently running transactions. A typical two-state locking approach requires that a transaction locks a database resource and keeps it locked until it is committed or aborted. This works well for applications that use a large number of short transactions. Two-state locking is less appropriate for modern web-based applications characterized by longer transactions, lower transaction rate, and moderate tier data caching. A lock on a well-known database resource, for example a long running transaction that maintains the number of books in a stock, protects all other transactions from running, thus paralyzing the entire web site. Thus, in recent years there has been an increased interest in alternative concurrency control mechanisms. In particular, optimal concurrency control mechanisms have been implemented in many database processing systems and application servers.

Optimal transactions consisting of two distinct states, a long-running read state followed by a short write phase, are also called a commit state. During the read state, objects are retrieved without locking and placed in a private transaction cache where they can be modified without executing other transactions. The objects are written back to the shared repository during the commit state. Instead of locking, the optimal transaction relies on the assumption that no other transaction deforms the objects while running. This assumption is valid before changes made by the transaction are saved in the database. Optimal concurrency control is believed to outperform other methods in systems with rows to reconcile disputes. Most of today's e-commerce applications fit this profile.

Previous implementations of optimal concurrency control mechanisms have been useful as sub-elements of larger database processing systems. Often, only data stored in these systems can be accessed in an optimal manner without locking. This situation clashes with the trend for informational and transient data access resulting from the increased use of the Internet. Web sites are often built around data stored in legacy data sources such as related and mainframe based databases.

Many modern application servers follow the typical "star" structure shown in FIG. Web server and application server processes are at the center of the star. They are connected to multiple web browsers and several information providers. The application server is responsible for bringing data from the information providers to the web server clients. Data caching and optimal transaction processing are also done in the middle tier where the application server is located.

This structure is appropriate only for applications with web-based, or "thin" clients, and those accessing a limited number of back end information providers. At the same time, it is not optimal for applications in which "thin" and "fat" clients are mixed. In this setting, the "pat" client needs to access the data present in the cache of the remote application server, which is not much improved compared to the typical client / server architecture. Also, taking raw data from a large number of information providers to a single central location may have low scalability concerns when the data needs to be transformed before it becomes available to clients.

Thus, there is a need for a method and apparatus that can more reliably maintain data integrity among distributed computer systems in a network.

Related Applications

The present invention is a continuation of US Provisional Patent Application of U.S. Application No. 60 / 131,019, filed Apr. 26, 1999, which discloses US Patent Application No. 09 / 408,213, filed September 17, 1999. Partial Serial Application, 09 / 408,213, which is a continuation of US Patent Application No. 08 / 829,929, filed Jul. 15, 1997, and 08 / 829,929, which is a US Provisional Patent Application, filed Jul. 18, 1996 Serial No. 60 / 021,980. Each of these applications is incorporated herein by reference.

The present invention is not based on federated sponsor research and development.

The present invention relates to the field of software-implementing methods, systems, and manufacturing regulations for maintaining data integrity across distributed computer systems.

1 shows a network having a conventional star structure.

2 shows a network with a distributed structure in accordance with the present invention.

Systems using the disclosed technology can maintain the integrity of data stored across a network of distributed computer systems. Using the disclosed technology, it is possible to achieve these and other objects, features and advantages, including the following.

• status transfer by remote function call;

Caching with storage transfer capability;

• persistence by reachability;

Double object resolution;

Dispersion methods; And

Dynamic Concurrency Controls.

The system of the present invention combines several known techniques in new ways and adds new techniques to address the problems of conventional systems. The system of the present invention raises several specific problems through specific combinations of techniques. The system also uniquely combines these services to provide a single infrastructure, which, in addition to typical databases (persistent storage without methods) and object databases (persistent storage with methods), Support providers (methods without permanent storage).

It is quite difficult to integrate different types of services without introducing a problem of completeness. Indeed, constructing a distributed application system is difficult in any case, since errors in program logic may only be apparent when traffic patterns are combined in an inappropriate way. The present system introduces several methods that address these problems, thus reducing the difficulty of forming distributed applications.

It is also quite difficult to construct a distributed application with good performance. How an entire application system is divided across several computer systems, and how communication is configured, often requires careful and fine-tuning. This is a difficult task for application developers. The system of the present application reduces the burden on the developer by automating some of the performance tuning and by making it easier to change the partition and coordinate communication without extensive modification of the application's source code. The system of the present application reduces many settings from the application, allows the system manager to optimize the operation of the application system within a particular configuration, and changes in useful techniques while minimizing errors without modifying the source code. Its ability to modify its operation in response to business needs, distributed structures and loads.

Terms

For purposes of explanation herein, the following definitions will be in addition to their common meaning. A "provider" is a software system that provides information or services. When distinction is important, we refer to "information providers" whose primary functions convey information, or "service providers" whose primary functions convey certain kinds of processing services. Information providers typically include relative object databases, directories, file systems, monitoring agents, the Internet, and other programs that provide data. Service providers include business applications, processing tools, backup agents, and other programs.

However, the distinction between service providers and information providers is rarely exact. For example, most recent databases provide support for invoking stored procedures, and the Internet may be used to locate orders as well as retrieve catalog data.

A "consumer" is a program that retrieves data, changes data, stores data, or invokes services. A consumer is a simple interactive tool, such as any kind of application program, or a browser that allows humans to interact with information or services.

Similarly, the distinction between providers and consumers is also not exact. A single software component may be a consumer and a provider at the same time. The provider responds to the request, but acts as a consumer while meeting these needs, but requires different services from other providers.

Also, the flow of information between the consumer and the provider is not always organized like a typical request / response. The provider sends event notifications or other messages to the consumer or other providers.

The system comprises software and hardware systems, whether they are located in the same process on one computer, in different processes on one computer, or in different processes on another computer; Whether they act as providers of information or services; They provide services that enable communication, whether sending or responding to requests or sending or responding to events.

State transfer combined by remote function call

Applicant's system combines the state transfer using remote method calls. When an object is accessed, its state is transmitted to the client in the manner of database access systems of the state of the art and stored in the client side cache. This coupling is done under a strict object model, and objects are exposed to the application as native objects in the application language through language binding. The state of the objects may be directly connected, and these accesses are resolved locally from the cache. The state may be updated directly, and these changes are kept locally in the cache and then written back to the server under a lazy-write algorithm. The lazy-light algorithm may determine the write-through at various times, depending on the concurrency control model and the optimization decision used, but at the end it is really written when the commit operation is called. Server-side methods are exposed through this language, which combines in the form of standard methods of the application programming language.

Pre- and after-method synchronization

Since these methods run on a server or some other computer, in the case of distributed methods the state between the client and the server or other affected computers must be synchronized. Thus, when the server-side method is invoked, the cache manager writes to the server all changes made to the state of the objects in the client application before the server-side method is actually invoked. Of course, such synchronization is not necessary when performing client-side methods.

The logic of the state synchronization service of Applicant's system can be modified to optimize the amount of information recorded. Some state changes are not appropriate for this method and thus do not need to be recorded at this point. In the general case, however, the state synchronization service cannot determine this because the methods may be implemented in many languages and may be complex at will. Therefore, on the sales side only, all property changes should be recorded. Of course, such manual control would be a possible variant of Applicant's system.

After the server-side method is called, it is necessary to synchronize the client-side cache and the database. This method has the side effect of changing the state of the object to which it belongs, or of other objects in the client cache. Thus, after the method is called, the relative synchronization service automatically synchronizes all objects in the modified cache in the server.

The method of fully accessing the database through the infrastructure of the present invention does not cause any problem. This infrastructure tracks all activities in progress and determines what changes have been made. If using direct technology to access a database that the infrastructure cannot track, the infrastructure may rely on event notifications from the database. Most database systems allow a program to register notifications of changes using "triggers" or other techniques, and the infrastructure can use these notifications as a basis for cache synchronization. .

If the infrastructure decides that no technology is useful, it should take a pessimistic approach to invalidate and refresh the entire cache. Note that in this case, no data is lost in the cache because all pending changes will be recorded before the method is called.

Application event notification

All of these "side effects" for objects that occur as a result of a method call are not only used to refresh the cache, but are also passed back to the client-side application as regular change notifications, so that the application is able to update the account in its calculation. Make the value available or display it in the user interface. There is no fundamental difference between changes made by other programs and changes caused by the site effect of the method. The application needs to notify them both.

Transaction processing

Under typical pessimistic concurrency control, the application keeps a lock on the records he reads. In such cases, the overall description of pre- and post-method synchronization does not include transaction processing at all. The order of the steps within the application is as follows.

All these operations operate within the same pessimistic transaction context. The only other effect is that the application must be ready to handle the change notifications resulting from the method side effect. Under normal circumstances, an application operating under pessimistic concurrency control is typically not involved in change notifications for the objects it controls in today's complex and multi-threaded applications, but is held within a window or thread. Some data may be transformed by other windows or threads, so in practice, some piece of code must be prepared to accept change notifications for any piece of data shared with any other entity.

However, when operating in an optimal concurrency control scheme, an application does not hold any locks on objects in the database. Every time changes are written to the database, they are validated and committed immediately. Since all pending changes are written to the database before calling the method, the method call automatically commits pending transactions. The result of the method call from the client application to the server is as follows:

Applicant's system provides other options described in detail with respect to dynamic concurrency control. Transaction processing services can switch to pessimistic concurrency control when the method is invoked. These run options are selected as part of the system's configuration settings.

Caching by Store Transfer

Given the limitations of conventional systems, it may be desirable to have an infrastructure that can accept transaction commits even when the connection is lost, and keep the transaction in the persistent store and transmission queues to send it when the connection is reestablished. have.

Applicant's system uniquely combines these two capabilities: cache processing and storage and transfer. Using store and forward messaging to provide information to the cache processing system, all notifications of server-side changes that occur during an outage are stored in a queue, and as soon as the connection is reestablished, the changes are delivered and reflected in the cache and application. .

Similarly, notification of client-side changes is also stored if necessary and sent to the server as soon as the connection is reestablished. Since this asynchronous recording to the server may have problematic interactions with the concurrency control mechanism, it may be disabled by an application program or by an administrative method.

Application transparency

An advantage of the integration of the present invention is that the application does not need to be aware of intermittent synchronous processes. The application may be written as if the objects have continuous and secure access to the database by a language combination that provides immediate access to a huge pool. The cache improves the performance of the application, store and transmit queuing ensures that all changes are delivered to the application, and there are no changes in the style of programming within the application.

Rapid resilience to accidental downtime

This integration of cache processing and storage and transmission queuing allows the entire system to recover more quickly in the event of a short period of accidental downtime. This accidental set up may be very short, in particular by dial-up or wireless connection. For example, the cellular phone connection may be disconnected while the vehicle is under the bridge, and reset within seconds or minutes. The application and cache manager may continue to operate during this shutdown. Nevertheless, notifications from the server may be lost.

In practice, most network protocols will detect lost connections, signal failures immediately to the database server, and this will be considered a total loss of operation. However, using storage and transfer techniques, the database server continues its operation to ensure that messages eventually arrive and that no failure messages are delivered to the database.

Continuously running applications

While the connection to the database server is intermittent, it is becoming more common for applications to run continuously. Vehicles, ships, and airplanes may have dispatching or routing ultra-lightweight portable computing devices, including continuously operating applications that process inventory, and personal digital assistants that may operate continuously. . In such cases, the cache may be kept alive continuously, and the change notification must be queued while the connection is down.

Continuous caching

The value of this integration of caching, storage and transfer increases even more when the cache is made persistent. If there is no persistent cache, the benefits described above are only obtained while the application, or at least the cache manager, remains operational. Using a conventional non-persistent cache, the values in the cache are discarded as soon as the cache manager is shut down. When it is restarted, the cache manager must fetch the objects from the database again, and since these values naturally represent the current values, there is no need to queue change notifications that have taken place. In many cases, however, it is quite beneficial to use a persistent cache that is persistent on the local store when the application or cache manager is shut down and recreated from the local store when the cache manager is restarted. In some cases, it is the cache manager's responsibility to persist the cache. In other cases, when operating on a portable personal computer, for example, it is the responsibility of the operating system.

Whatever was responsible for persisting the cache, the situation is logically equivalent to the long-running cache, and the storage and transmission queuing of change notifications is used to maintain the currency of the information in the cache.

Applicant's system may be in contrast to a replicated database, which may be configured to provide any similar benefits. However, database replication techniques rely on database homogeneity, which means that identical, or at least structurally and semantically similar databases can be used at all nodes. This is not practical for small computers, such as portable personal computers or palmtops, for example. In some cases, Applicant's system only provides benefits by persistent or non-persistent cache, which is a much more useless technology than a database.

Sustainability by Reachability

Applicant's system broadens the concept of persistence through reachability across several information providers. Whenever the infrastructure determines that an object needs to be persistent, it determines that the object will be persisted through the persistence-through-reachability algorithm, or because the application program explicitly requires it to be persistent. . This is selected through any one of a number of techniques, including the following examples.

The class to which the object belongs may be associated with a schema defined in a specific database, and the object is stored in the same database.

The class to which the object belongs is classified as a specific database storage regardless of where the schema comes from.

The object or class to which a specific object belongs may be dynamically associated with a particular storage.

The system can determine the storage to be used based on its own specific criteria.

In such cases, the two objects with an reachable relationship may be placed in different databases. The interrelationship between them can be applied through references that can be stored in different storage.

In this environment, the persistence by the reachable algorithm conforms to substantially the same way regardless of where the objects can be stored. As long as the objects are in the cache memory or the application's own memory, the correlations between the objects are known as a persistence infrastructure. The persistence by the reachability aspect of Applicant's system navigates these references by identifying all the objects that can be reached by each persistent object and making them persistent, and determines that the objects persist in the above general manner. . Then, one of the techniques listed above is used to determine the persistence for the subject of the database and affect the persistence in a general manner.

Duplicate Object Resolution

Applicant's system solves the problem of a subject replication solution by automatically detecting that a subject has already been retrieved from the database or patched from the client to the server. Since the system keeps all currently active targets in the cache, once the targets are patched, the system determines whether the newly patched target has replicated the existing objects in the cache, and if so discards the new replica and the Use what exists in the cache.

The technique returns the number of subjects that match a certain criterion by name, by following an in-object association, correlation or pointer from one subject to another whenever the subject is patched directly from the database. It can be applied by performing a query, by referencing a list of recently used objects, or by other techniques. It does not matter how the objects arrive, and if so, the system discards the new copy if it is detected as a duplicate.

Performance Improvement Variations

Of course, in many cases, the system can detect objects already patched and present in the cache to eliminate all requests to the database server, thereby reducing network congestion and database load and improving response time. . In other cases, the use of the database may be unavoidable, such as when executing a query. In any case, these deviations only affect performance and do not affect the basic operation of the system.

Distributed methods

Object databases that store objects, and these objects all have properties and methods. The schema defines the methods that exist for a given class of objects.

In a general target database, the methods apply to the same target database. The definition of the method simply gives the name, the class to which it belongs and no specific location specification is required, since the location is included in the location of the object.

In this environment, however, this may need to be applied in some part. For example:

The database may not be fully usable. For example, if objects are stored in the associated database, the capabilities of the methods of execution may be limited. In this case, the methods can be applied as separate programs, and will run on the same equipment where the database is present, and will do something else.

Full method execution capability for a given target database may need to replicate data for a small amount of storage. Replication is often used because of improved tolerance, reduced network congestion, and improved response time. However, if the replicated database does not support method execution, the system goes back and executes the methods on the source target databases.

Objects stored in the database may represent software or physical equipment of the system. These objects, such as routers, have the ability to programmatically manipulate operations on the object itself, management services can provide functions that apply elsewhere, and the application provides a graphical user interface. It is possible to provide a function to include, thereby operating at the user workstation. In all these cases, these services are viewed in a targeted way, even though they all apply on the network.

The methods of the class can apply to third-party inherited programs or external programs that require less developer control. The methods can be applied to different programming languages, databases or operating systems. Nevertheless, to simplify the use of these methods in application development, these various methods must be provided as part of the integration with the whole. Naturally, it is possible to generate a piece of software that is correlated with these individual method applications, but the creation of such connection services requires a lot of work, and all changes in configuration require changes in the code. Regardless of the location and type of the methods, there is a need to define and maintain the relationships externally through the registration of schemas.

Thus, Applicant's system allows schemas that include definitions of the method of specifying the location of the method, not just its name. In execution, the system allows applications to access a subject of the database, simply to invoke a method on the subject as standard, and to allow a built-in method. The system will manage the dispatching of method calls required for the appropriate location.

Apply method

The definition of the method must also specify how the method will be applied. This can be, for example, a C or C ++ DLL that is called by a normal subroutine call. It can also be a Java program, an executable program, or a BAT file. The schema identifies the technique used and how the method is invoked.

In addition, the method must specify how the object is identified. If the method is applied as an external program, it naturally does not have the context of the source object. The method schema specifies how the call is executed and in this way the content can be maintained.

Class and instance level methods

The technique for dealing with external applications of the methods works the same as in the instance level methods added to the object for the class-level methods added to the class. When invoking an external method configured as an instance level method, the identification of the original subject is passed to the method. The method is implemented, for example, as the conveyable identification is identified as part of a method definition, such as a conflict in the call in the schema, which means that the command line parameter or any suitable specific configuration at launch of the executable is do.

Line and follow-up methods

As previously discussed, a system that merges remote method calls with state transfers should attempt to synchronize the state between the client and server before and after the method is performed. In a distributed method, the state synchronization must include a computer on which the distributed method is executed.

This can be done in at least the following ways.

The state must be synchronized with the database providing persistent storage of the subject. The method can then retrieve the state of the database logger prior to execution. During the execution of the method, the system records all persistent state changes in the database. The client side cache manager recognizes these state changes and uses them as a basis for subsequent method state synchronization. Note that if the method is performed on a computer that already has a copy of the object in its cache, it does not need to patch the data in the database.

The state can be synchronized with the cache of the server executing the method.

Dynamic simultaneous control

Applicant's system applies a special dynamic simultaneous control mechanism based on a combination of locking (pessimistic) and unlocking (optimistic) simultaneous control strategies.

Each instance of the runtime system has its own target cache and its own transaction manager. It runs on a client device capable of providing local data access for non-web based applications. Some instances of the runtime may be bundled together in the middle tier. They can be accessed by the web clients and other runtime instances. Automatic load balancing ensures improved scalability. A detached runtime instance can be located adjacent to the inheritance database and used to perform object-related mappings. Objects are delivered in assembled form in the middle tire, which reduces the number of network messages required to access the objects.

The structure can successfully solve many non-trivial problems associated with transparent information that can be accessed in a distributed environment.

Variance Check

All existing application servers and transparent data access frameworks perform optimistic transaction verification in the middle tier, where shared target caches and private transaction caches are located. Verification is often accomplished by comparing date stamps for the subject of the private transaction cache with date stamps for the same subject of the shared cache. If the stamps are different then the verification is unsuccessful. Some systems perform verification by comparing before and after images for objects of different caches of the application server environment.

Optimistic transactions can access data through multiple instances of the runtime system. For example, any transaction initiated by the "App1" application shown in FIG. 2 is passed through at least three runtime instances when accessing data of the information provider "DB1".

In a preferred embodiment, each of these runtime instances maintains read and write settings of the transaction. When the transaction is executed, the read settings are compared with the write settings of the transactions already performed. The transaction is rejected if a non-empty intersection of the settings is detected in at least one runtime instance.

Provider-specific confirmation

In some cases, the rules for how a transaction must be confirmed can be specified for the applications. For example, consider a database of employee records. If an application changes the phone number of a record, other applications may be considered a confirmation unless they change the same phone number. However, if the employee name is changed, the identification of the transaction in which part of every record is attempted to be changed is questioned, and all such transactions are invalidated. This knowledge that phone numbers are not important but names are important can specify the application.

Applicant's system provides a standard interface between the provider and the runtime and registers itself to perform this, allowing the provider to take over the reliability of transaction confirmation. If the provider claims this responsibility, the runtime system asks the provider for confirmation. If the provider fails verification, the runtime leaves it as is and a more passive approach is used. In the configuration of some providers, others perform their own application-specific checks, while others may postpone checking for the runtime system.

Parallel check

The read and write settings of a distributed transaction divide multiple instances of the runtime system. When the transaction is executed, the confirmation is performed in parallel in all included runtime instances. Ideally, if a transaction accesses N information sources through N different runtime instances running on N different CPUs, the confirmation may be up to N times faster than when only one central application server is involved. Can be. The distribution characteristics given above in enterprise wide area data access will quickly become common.

Quick stop before confirmation

If an optimizing transaction is running, other programs can change the data used by the transaction—this is the basic principle of optimistic concurrent control. If collision changes to the data are detected in the confirmation state, use one of a number of techniques. This is also common in optimism and systems using Applicants' systems. However, the event detection system may send detections for all these conflicting changes to the runtime system and may abort the ongoing transaction in advance. This fast abort feature reduces the wasteful effort spent entering data into a transaction that will later be invalidated for the human operator. This fast shutdown feature also reduces the wasted load on computers, networks, and databases.

Quick interruption during distributed verification

Long-running optimizing transactions do not have to wait until the end of their read state to find invalidated by other transactions. When an executing transaction passes the confirmation state, it compares its write settings with the write settings of the currently active transaction and sends invalid events to all transactions that the intersection of the settings is not empty. The invalid events are propagated through a distributed event manager, among other features designed to provide event delivery and assurance.

Hybrid transaction

Systems that support fragmentation transaction management run on a per- transaction basis. The application indicates the mode of the transaction when it begins. The new transaction can be started in either pessimistic or optimistic mode.

The mode of transaction can be different on every provider as well as on every transaction. For example, some applications may have access to two data stores, one of which is a less personal personal database used as a local persistent cache, and a remote partial database containing shared data. Applicant's system avoids unnecessary confirmation overload by allowing the application to access the local database in a pessimistic mode. The shared database can still be accessed in an optimistic mode that is not locked.

This feature is particularly important when the invention is used to access non-transactional providers such as LDAP, ADSI, MAPI, and the NT file system. Optimistic concurrent control can provide isolation for transaction accessing if these providers need serialization. This can be disabled if not needed.

Unique wrapper API

Modern database systems provide support for optimistic transaction management to varying degrees. Unlike other transparent data access frameworks that use their own algorithms for managing various states of optimistic transactions, Applicants' systems can create unique capabilities of different information providers through the development of user wrappers. The wrapper API includes a basic optimistic concurrent control function that can be overridden by the wrapper developer. This is not seen in the ODBC, JDBC, and OLE DB APIs used by other programs.

Dynamic transaction

In the applicant's system, the state of the object (ie, the values of its characteristics) is transmitted to the point at which the object is used. For example, the application "App1" shown in FIG. 2 is the accessing objects of the cache of the local runtime instance. This is a clear presidential election compared to other systems in which the subject is spaced either on the server side or on the middle tire. Of course, if a server-side target method needs to be called, the state of the target is at the client, which may be required at the server to execute the method.

Applicants' system dynamically changes the transaction manager from an optimistic mode to a pessimistic mode while the transaction is running to solve this. The mode change is transparent to the application when the application invokes a server-side method. Only the providers used to perform the method are affected. All other providers continue to run in optimistic mode.

The mode switch is only necessary if the provider itself does not support some form of optimistic simultaneous control. Otherwise, the changes may be stored at the provider as part of the distributed optimistic transaction. For example, the distributed transaction does not change if the state of the subject is passed among various instances of the runtime system. This feature is necessary to support plug-in service providers such as System's own catalog manager.

Adaptive transaction

Optimistic transactions are not suitable for high-conflict applications on data items accessed by clients. In such an application, a number of optimistic transactions will not be able to pass the verification process which causes an unacceptably high rollback rate. The straightforward solution of all transactions starting in pessimistic mode is commonly used in other systems. This is too limited if the dispute level varies over time. For example, disputes in the real world are high from 8:00 am to 6:00 pm and low at rest.

Applicant's system provides a solution to this problem, which applies the neural network agent technology. One example of such a technique is described in more detail in US Pat. No. 09 / 084,620, which is hereby incorporated by reference. Transactions always start without explicitly defining their mode. If the dispute is low, they operate in an optimistic mode. If the rollback rate exceeds a certain limit, the default mode is automatically changed to pessimistic mode. The rollback rate can be maintained continuously within acceptable limits because the neural agent allows for reliable prediction if it accumulates enough knowledge.

Check for session-width events before execution

The infrastructure of Applicant's system is generally used extensively to identify events from provider to consumer. For example, a consumer may identify that objects maintained in the client side cache have changed in the database under optimistic same management, whereby the same transaction may be invalidated. Applications and providers can send events to each other in a comprehensive way.

In addition, different members that make client-side applications that need to communicate with each other are common. For example, a GUI application consists of multiple windows, some of which run on the same thread, some run on different threads in the same process, and some run on different processes.

These different application members may, for example, represent the same data segment with different appearances or different content. Of course, if the application member is changed and it is passed to the provider, all applications related to the subject identify the change. However, within one client-side application, event identification must be generated before the change is propagated at creation time. Naturally, if all application members are part of the same process, they will share data through a common session and a common cache. This should take into account:

Should members cooperate if they exist in different processes? The user sees different windows as part of the same application and does not know or care about its detailed configuration, such as threads or processes. For a user, some application must provide one set of data.

Regardless of the physical configuration of data sharing, the various application members, such as GUIs, must be identified when some data changes. This load should not be created by the developer, and as the number of members of the application increases, the number of identifying relationships also increases combinatorially. Each time a new member is added to the application, there is a possibility of accessing the same data as a new member that is additionally changed. This can be an expensive and inefficiently managed structure for developers. Instead, the infrastructure must provide an identification service that can automatically pass identification to members without waiting for the point of delivery if any data changes without considering the thread and process. Naturally, session boundaries are the basis for transaction management, and the sessions are isolated from each other until a change is delivered.

To solve these problems, Applicant's system provides two methods.

1. When an application member is connected to the infrastructure, it is combined with an existing session.

2, change event identifications are delivered within the session without including the provider before the delivery point.

Summary of Preferred Embodiments

hint

The target infrastructure is designed to reduce development effort, reduce programming errors, and generally provide a significant advantage in improving performance by transferring many of the remaining responsibilities to the application programmer to the infrastructure. This is also advantageous for developing graphical user interfaces (GUIs). Applicant's system enables a comprehensive user interface that is generated based on indicating the status of configured objects, and enables all tasks to move between them and execute methods with menus or buttons.

Applicant's system provides a method for the database designer or application developer to guide the work of the infrastructure through the definition of the hints.

Application isolation from execution

The hints of the present invention allow the developer to control the behavior of the application without dropping down to a low level abstraction, as well as the direct benefit of improving the infrastructure's work or reducing development effort. By defining the program as a high level of abstraction, most of the improved functionality of the system remains functional. Examples of such high level functionality may be compromised by being explicitly controlled in low level abstractions, including:

Cache management

Read previous

Record since

Remove replication target

By using the hints, a constant developer or database designer can adjust the behavior of the system without any apparent coordination-dependent states of the application program. The system has the advantage that it can be reconditioned in response to changes in the appropriate hardware, distributed configuration, load patterns or elements without any change in the application.

Apply to external target model

The general object management system of the Applicant's system is capable of providing different kinds of information and services. The general object model can be applied to any system that satisfies the minimized characteristics of the object system.

Using an interfacing module for Applicants' systems, wrappers, and providers may provide a number of special hints describing the features of the provider. Applications recognizing these hints can take full advantage of the improved features of the provider. Applications without information about the provider are manipulated in a general manner based on the standard target model. End comment.

Examples of hints

Performance tuning hints: A number of providers can classify hints that describe the optimal way to process information, the meanings of which are given below.

Prediction List-A list of suitable characteristics for use in the application, which is recommended to be included in any search.

Frames used for reading-a list of associations or other relationships for use in the grouping of objects for previous reading.

GUI hints: The provider can classify hints suggesting how the automatic GUI generator should display the following information, for example:

Grouping of properties on tabs of a form

Whether related objects are displayed in a common browser structure, such as a tree or network explorer, or a tab on a particular screen or form.

What default properties should be used when targets are displayed

What characteristics will be used as the name, "tool tip" document, long description, help document, icon, 3-D representation, sound or video of the voice

What members will appear on the content menu for the object

How the GUI handles navigation such as writing a target

How to apply auto-arrangement techniques to arrange the contents of an object under any particular type of combination

What format the numeric value will appear on the screen

What are the acceptable values for data entry

How to understand drag-and-drop operation

Source of hints

Such hints may be provided by either the provider or the consumer. Without hints, the system will operate in a standard manner. Hints by either the provider or the consumer will drive the operation of various system services. If the various hints overlap, the choice of which of these hints to use depends on the service.

Open and expand

The hints may be read or interpreted directly by various services or providers of the infrastructure, or by the application itself. Since the hints are an official part of the infrastructure's data model, all components can use them to generate hints. In addition, since the entire infrastructure is open and extensible, all services can be replaced with others and other strategies can be used to interpret the hints.

Hints do not cause failure

The target infrastructure defines the meaning of the operations provided. The hints provide the infrastructure derivation in a way to optimize the manipulation, but they should not be allowed to be limited.

Semantically, hints are a form of side-band communication. These are not confused with the general object characteristics. Applicant's system maintains the difference between the hints and general object characteristics. In conclusion, the definition of new hints or the removal of any hints does not alter the schema and does not require recompilation of the program.

Application processing hints

Since the hints are manipulated as part of the data or metadata that is generally processed in the system, any component can define or use them. This means that various parts of a distributed application can use hints to communicate how the processing is done. Using a mutually defined message protocol, the provider can directly retrieve the objects relevant to the GUI member and analyze the structure of the Guess.

These particular codes used in existing application systems often require special stimuli of complex sideband communication. These special codes must be maintained. For example, if the system switches from SNA to TCP / IP, the main database has access to the protocol that should be ported and the sideband protocol must also be ported. Through the application processing hint function of the Applicant's system, the special hints are logically inside the sideband, outside the general database congestion, but technically they are part of the mainstream protocol and do not require special management or maintenance.

cancel

Cache Manager's Cancel Support

In the volunteer system, the system may maintain a cache of all the objects patched in the database. Upon a change to the database, the new values are written to the cache.

A cancellation management function is added to the cache manager. The service records all changes in the cancellation queue. For a typical change of characteristic values, the cancellation queue simply records the previous value. For life changes, such as creation or destruction of objects, the cancellation queue records equivalent operations that can recover the following operations: delete for create, create for delete. In practice, the operations that can recover changes are very complex: for example, if a class is deleted, all instances of the class, all subclasses, all instances of all subclasses, all methods and such Other features of the classes are also removed. The cancellation manager stores reverse operations whenever possible. In some cases, a cancel operation may not be possible or practical, and in such cases the appropriate record is stored in the cancellation queue.

The cancellation manager provides cancellation and redo functions that the application can call directly, and can provide useful services to the GUI, such as a list of operation sequences of the cancellation queue, in a human readable form.

Cancel and Transaction Management

Note that the cancellation capability cannot be effectively provided by the rollback allowance of database transaction management systems. Database rollback is a very expensive operation, linked through a run-error user operation that is possible with a mouse click. In addition, no database transaction system provides redo, and very few provide multiple cancellations.

If a set of operations is sent in a transaction, this may cause problems in executing the cancellation of individual steps of the transaction. For example, if a user wants to transfer money from one account to another, it becomes a transaction involving one subtraction and the addition operation of Ana, which can cause problems in canceling the individual steps of the operation. . So, typically, a transfer operation merges the cancellation queue and makes all past operations of the current transaction into one cancelable operation. In some cases, certain counter-manipulations may be known as specific operations: in order for a particular method to be specified in the database schema that is the corresponding counter-method. In other cases, the transaction may not be canceled at all. However, the specific way in which the transaction is processed may vary in any particular system application.

Stackless cancellation model

The general approach to the cancel operation is the stack model: actions are canceled in the reverse order in which they were created and redone in the order in which they were created. In principle, however, they cannot prevent individual acts canceled in an arbitrary order. Random access revocation operations go in principle and are very useful in some cases.

Such random access cancellation is often excluded from the state of the art, because in many cases it is impossible. For example, if the operation 6 of the queue for creating the object and the operation 11 have changed the characteristics of the object, cancellation of only the operation 6 is impossible because the operation 11 is invalidated. However, this simple interpretation is not only possible. Any access cancellation may be allowed if the inner-dependencies of the actions are maintained. For example, act 6 automatically cancels act 11, but if act 7 is not related to act 11, or is related to other manipulations of the queue, this is itself canceled. do.

Such random access revocation is very useful in many cases for increasingly complex applications. In traditional online transaction processing, the order of operations is often greatly simplified and the random access cancellation has been limited, but is very useful in more complex knowledge-intensive applications.

Schema Tolerance

In theory, in an ideal case, all relevant objects could be stored in a single database and managed under a single schema. However, existing systems use several distributed databases, in which case a consistent schema is assumed, but substantial schema consistency is difficult to achieve. Technically, economically, for practical and administrative reasons, information can be stored in a database under inconsistent schemas. For example, after a transaction is accomplished, most of the government needs to be maintained in a current database that does not match the achiever schema. For example, a US company that has acquired Venezuela or a Russian organization needs to deal with the definition of different names, such as last name, first name, family name of mother, last name, patonymic, name in Russia.

Applicant's system accepts these schema inconsistencies and allows the application to seamlessly navigate between different databases. Consider the following example:

If the initial target boss is stored in database A under a specific schema, the employee determined as the staff may exist in different database B under a different schema. In other words, some employees may be stored in A and others in B. The system hides this distinction and allows the application to retrieve the properties and methods of the objects regardless of the stored location.

If the distinction between the two databases is severe, the application can signal the object to detect its location, adapting itself to a particular schema that retrieves, for example, the ancestor name.

Associations Among Entities

Combination abstraction

Applicant's system abstracts the concept of interrelationships between bodies as a combination. This combination is defined as part of the schema and some application programs allow the services of the invention to search for the combination. Since the definition is abstract, as long as it is removed from the physical application and exposed to a manner that preserves the meaning of the combination, the provider may refer to these correlations, such as foreign keys of the associated database, the target reference of the target database. For example, you can use any technique that can maintain ways of executing queues.

If the correlations are represented in combination, the application can easily explore the correlations. The combined objects simply appear as related objects in the application programming language. The application code may look like the following pseudo-code.

Combination is an abstraction that provides a bidirectional reference between two entities.

In most cases, the combined entities are objects, but the concept is not limited to the object. Combinations exist in every pair of objects with globally unique names, such as file paths, web page URLs, and UUID objects. For example, a combination from the attributes of a class can be assigned to a visual service for the verification method or attributes.

The combination also has its own additional attributes, such as creation date. A program that is a database management tool used by a human can define types of combinations and create individual combinations between the named bodies. The program is searched using these combinations and searches for either the combined bodies or the combined ones.

The combined bodies are automatically patched as needed: the combination is automatically dereferenced as an application that searches for a set of combined bodies.

The automatic dereference is efficient through automatic optimization and self-tuning techniques, for example:

The system does not immediately patch all targets on the getAssocoatedItems statement. Late patches are used so that targets are patched from the database if necessary.

The late patch is not used for each subject as needed. The late patch manager patches the targets in batches.

The system is self-tuning and adapts the size of the batch to the performance of the observed environment. Fast lead times increase the size of a batch. Late lead times reduce the size of the batch. More complex tuning algorithms can of course also be inserted here.

The performance tuning subsystem also allows developers to provide hints to bring the system into tune.

Combination registration

Various applications that can be used for the combination, such as the referenced objects, foreign key tables, methods or queries, can be used directly in the search without specific or metadata added. For example, consider a class called containment that is used to apply combinations. It maintains two references to the container object and the contained item:

These classes can be used directly for navigation by programs such as:

The final declaration says that the system searches for the object of class storage by using an attribute named container that can detect references to the current object, and then detects all objects referenced by the attribute included item. do.

The class storage is not special in every way, it is just a generic class. (This is similar to the concatenation in SQL with generic tables without specific features.)

However, the present invention has made this concept more general by allowing the containment class to register with the combination registration. This does not limit the use of the class in any way by the infrastructure in which the class is generally used in combination.

Similar registrations are made for other forms of associations, for a pair of direct object-to-object references (for one-to-one associations); It is not limited to search methods that logically search for objects associated with sets of object to object references (for 1 to N and N to N associations).

The associative registry provides numerous advantages, for example:

* Consumer applications do not need to know the implementation model used by a particular provider; They simply refer to the abstract concept of associations, and the infrastructure translates the reference into the appropriate actions given for the particular realization of the association.

Decoupling the application from the realization of the association makes it more resilient to changes in the provider's data model and allows for the replacement of the database provider with a very different type of database provider.

General purpose tools that do not know anything about the provider's application-level schema can use the association registry for immunity to discover what types of associations exist; This is especially useful for graphic browsers.

When generating a layer 2 model, the layer 2 generator may generate virtual properties based on registered association types; For example, we can register the association via a suppression class under the name content, thereby granting the application in an easier way the layer 2 code generator navigates the associations, and for the container class. Create virtual property content.

Reference to external objects

Associations between objects will refer to information stored in external providers. For example, the boss in the previous example may be stored in database A, and the staff may be stored in database B.

Automatic navigation of the associations and automatic de-referencing of the objects completely hides the difference from the application. The application can navigate between the objects, moving with each other, without worrying about where the objects are located.

Since the structure of the system hides the nature of the provider from the application, it is possible that these external references point to any form of data source; It is also not limited to non-object databases and data in people, files in a directory, or pages on the Internet.

Externally Stored Associations

In many cases, an application can use an existing database provider with a schema that cannot be changed.

In such cases, it is desirable to maintain the association between these objects in the providers. As a practical example, the information would be stored in a database of a commercial financial operations system, and it is desirable to refer to a person or departments and link the references to corresponding members in the directory. The link allows an email to be created, assuming an application that acts on and determines data in the database based on organizational data in the directory. However, if neither the database nor the directory can be changed, it may not be possible to store the association and simple connection between the databases. Applicant's system allows the associations to be stored in other databases. Thus, two databases that do not refer to each other and cannot be referenced to each other may nevertheless be linked.

In Applicant's system, the application navigates the associations in a standard way, and the task is to clarify where the association is stored when the application names the association to be used for the navigation. This minor inconvenience can be eliminated by registering the association in a registry. In this way, the association can be referred to by name, in a standard way, and the system searches in the registry, finds where the association is actually stored, and goes to an external association repository to obtain a link, Follow links to other objects.

Outer Loopback Associations

The same technique can be used to store associations that reference objects within a single database when the scheme cannot be changed to accommodate direct storage of the association.

Language Bindings

Applicant's system provides services through an application programming interface that includes Visual Basic and is available in common programming languages, including languages that support Java, C ++, and other COM.

Layer 1 Language Combination

Every system that accesses an information provider or service provider uses a core data model. In SQL-based systems such as ODBC and JDBC, the data model is tables of atomic components in cells that extend to stored processes. In an ORB, the data model is an interface and is essentially a description for a procedure call. Since the choice of data model embodies some tradeoffs, it is an essential part of any design:

If the data model is primitive, it limits the capacity of the system (e.g. SQL).

* If the data model is abundant, it requires a lot of capacity of providers working together and makes it difficult to connect native providers (eg Java RMI).

* If the data model is very specific, it cannot be adapted to adapt to other designs (eg Microsoft WMI).

If the data model is very general, it provides low levels of services and leaves all boundary intelligence to the application.

The current object model starts with what is called an item and proceeds to define a set of items and leads to the conceptualization of the names of the items, finally leading to named sets and item ownership. In this way, a compact and precise foundation is created for a self-describing data format that can be used to store, move and reference data. The data model is called layer 0.

The format is created to define high-level concepts, such as classes and objects, and properties and methods (layer 1), with specific classes such as computers and employees on top of the format (layer 2). .

The unique advantages of this design are:

The basic data model (layer 0) is simple enough to adapt existing systems without weighting any requirements on the object model.

Since the high-level model (Layer 1) is based on a simple Layer 0 model, it provides a more modern object model and richer boundaries for those providers who present this capacity without requiring simpler provider capacity. can do.

The realization of layer 1 combining is based on dynamic processing and thus is resistant to inconsistencies and changes. If the provider changes the data model, for example if the database schema changes, the layer 0 model automatically adapts to the change, and so does the layer 1 model. An application using the provider does not require change or recompilation and will not fail if it does not need to. In particular, the added capacities can simply be ignored if the application is not interested, but if the application uses the services of Applicant's system to perform immunity, new capacities will be discovered and investigated. The removed capacities do not affect applications that do not use these capacities. If an application tries to use the capacity being removed, it can simply get an exception message and try to recover.

Layer 2 proxy binding

Issue: resilience vs Assurance

When constructing and managing large application systems, there is a need for a system that includes components from previously existing components or components from other application systems while managing the consistency of the entire system. The term Configuration Management (or Version Management) refers to an activity that confirms that the various components of the system are coordinated, so that they interact and work together from the same assumption. In existing systems, batch management is generally seen as a build-time activity.

In Applicant's system, batch management is an uptime activity: the components of the system must communicate, negotiate and agree in a generic version; Each component must be resilient and able to continue operation even when the communicator is inconsistent.

In existing systems, this restoration can be accomplished through a dynamic interface, often referred to as late bond. Like COM's IDispatch-based interface, a late-bound system can adapt to any interface presented by a component.

However, when creating a software system, the full chronic-range is often undesirable because it eliminates the possibility of confirming the consistency of the batch at compile time with early coupling. Compile-time checking allows for a level of assurance that cannot be achieved with a chronic-range system, since run-time testing does not appear to be exhaustive.

Applicant's system combines restoration of chronic binding with confirmation of early binding.

Problem: Restoration vs. Convenient

The dynamic interface allows the consumer to modify the provider's description by asking the provider through introspection and reflection services. These services are typically provided within component architectures such as COM and also in database access services such as ODBC and embedded SQL.

The advantage of the system is that it is expensive. Programming for these interfaces is very difficult and error prone. To reduce the burden on application developers, we prefer an interface that exposes the data model of the desired business application while integrating the data model directly in the program environment. This is particularly advantageous in modern object-oriented languages such as C ++, Java and Visual Basic, which support a relatively rich range model.

solution

In existing systems, the advantages of these two methods cannot be used simultaneously. Early-range systems such as COM do not provide restoration or fluidity of chronic binding. Flow systems such as dynamic SQL do not provide confirmation and convenience of early joining.

Applicant's system combines these benefits through high-level language combining. The layer 2 proxy association exposes the objects available to the information provider in the form of native classes in a particular programming language. A developer defines a scheme in the database and uses the scheme in the application language: The proxy association is a central data provider.

This form of bonding provides several advantages over the layer 1 bonding without reducing the advantages of the core.

The fluidity of the layer 1 coupling and the ability to dynamically adapt providers through immunity carries a heavy burden on the developer. The layer 2 coupling presents the developer with a boundary configuration of the application area while reducing development and management effort.

Layer 1's dynamic adaptability, ie its ability to adapt to changes in the provider schema, makes it difficult to verify the correspondence between consumers and providers at compile time. The layer 2 combination creates classes in the target programming language or infrastructure, and these classes can be used for compile-time checking.

At the same time, the layer 2 combination is implemented on top of layer 1, enabling dynamic adaptation such as layer 1 applications. Thus, existing applications beyond the developer's control due to remote deployment, management difficulties, or cost issues can continue to operate with restoration of Layer 1. Applications that deserve compile-time verification can be run through the standard Layer 2 verification process.

Integrated Proxy and Persistence Combination

Problem: Limitation of Persistent Bonds

Integrated combinations

In Applicants' system, the Layer 2 persistence and proxy bindings are integrated into one integrated whole, reducing the risk of inconsistencies.

A developer can define the initial schema with the application program or with a database tool. The utility moves the schematic definition from one environment to another. If the source definition was the application program, a database schema is constructed and installed in the database. If the disclosure definition was the database, source code is generated for use in the application program. The developer improves the definition at some point; For example, by adding indexing and clustering definitions, changing the properties and their forms and features, and adding or changing server or client side methods. The utility of Applicant's system translates the definition from one language to another and synchronizes the two environments.

Features of the present invention

This integration is achieved through the following features of the present invention:

Syntax of the application program is the same for the two language combinations (the proxy and persistence models);

The database scheme is the same for the two combined models;

The application in both models uses the support library for the same operation;

The application in both models has the same boundary;

The code generator used in the proxy model generates code compatible with the persistence model preprocessor;

The schematic generator and code generator used in the persistence model generate a scheme and code compatible with the proxy system;

Both code preprocessors and code generators allow and protect user extensions.

Advantages

This integration offers at least two very important advantages:

First, integrated combinations support iterative development. Thus, the developer can use the two models repeatedly by moving forward and backward between the two operating methods.

Second, integrated combinations provide educational integration by limiting the application to a single source code model that facilitates learning the system.

While preferred embodiments for carrying out the invention are disclosed in detail, those skilled in the art will recognize various other designs and embodiments for carrying out the invention. Such alternative embodiments are within the scope of the present invention.

Claims (11)

A method of maintaining the integrity of data stored through distributed computer systems, Sending the object from the server application to the client application; Sending an object state from the server application to the client application; Synchronizing the object state between the object and the server application and the client application; And Updating the object by invoking a server application method after the synchronization method. 2. The method of claim 1, further comprising, after the updating step, resynchronizing the object state between the object and the server application and the client application. A method of maintaining the integrity of data stored through distributed computer systems, Detecting a connection stop between the server application and a client application by a server application; Storing, by the server application, all transactions by the client application during the connection outage; Detecting, by the client application, a connection stop between the server application and the client application; Storing, by the client application, all transactions by the server application during the connection outage; And And after the connection between the server application and the client application has been restored, forwarding all transactions between the server application and the client application. A method of maintaining the integrity of data stored through distributed computer systems, Identifying an object to be persisted; Determining a database provider for storing the object; And Storing the object in the database provider. 5. The method of claim 4, wherein the determining step includes selecting the database provider based on an association with an outline defined in a database maintained by the database provider. 5. The method of claim 4, wherein the determining step includes selecting the database provider based on a database associated with the class to which the object belongs. 5. The method of claim 4, wherein the determining step includes selecting the database provider based on the dynamic association of the database with the class to which the object belongs. A method of maintaining the integrity of data stored through distributed computer systems, At the client application, identifying an object to be fetched from the server application; Determining if an active version of the object was previously fetched from the server application; Requesting the object from the server application; And Receiving the object from the server application based on the requesting step. 9. The method of claim 8, further comprising discarding an object received from the server by receiving an active version of the object previously fetched from the server application. 9. The method of claim 8, wherein said requesting and receiving steps are performed only if an active version of said object has not been fetched previously from said server application. A method of maintaining the integrity of data stored through distributed computer systems, Storing a location identifier associated with the method of the object, wherein the location identifier represents a location for processing the method; Invoking the method; And Processing the method indicated by the location identifier.