A system, method and computer program storage device providing event and/or state sharing support e.g., for building object-oriented interactive groupware in wide-area distributed environments (such as the Internet). For collaborative applications programmed using events, mechanisms are provided for sharing application-specific events. For example: an event based programming model allows applications to post an event and triggers corresponding ERUs (Event Reaction Unit) in reaction to a received event; preconditions for control activation of ERUs; and event consistency policy objects implement application specified event consistency model. Some policy examples are: a policy in which event order is not guaranteed, but all events are guaranteed to be sent to the ERUs eventually; and a policy that first triggers local ERUs and then posts the event to the server. An out-of-order event is detected using the event notification from the server; and an automatic detection of out-of-order events seen by ERUs in the local workstation in this optimistic event execution model. For applications requiring support for state sharing, an asynchronous model for updating replicated state, which supports atomicity of updates across multiple shared objects is described. Coupled with a flexible marshaling framework, this allows existing application data-structure classes to be easily extended and made shareable, while providing support for context-sensitive state marshaling applications. To solve the problem of replica consistency, a novel combination of three mechanisms is used: global locks; detection of incorrect update ordering; and cloning a subset of the shared objects for state re-initialization. To reduce network load due to fine-grained user interaction, a framework for application specified event batching, called Late Event Modification (LEM), enhances the event interface to allow applications to modify the event objects after posting them to the set.

Un dispositivo di memorizzazione del sistema, di metodo e di programma destinato all'elaboratore che fornisce l'evento e/o dichiara la compartecipazione del supporto per esempio, dato che il groupware interattivo orientato oggettivamente della costruzione nella largo-zona ha distribuito gli ambienti (quale il Internet). Per le applicazioni di collaborazione programmate usando gli eventi, i meccanismi sono forniti per la compartecipazione degli eventi di application-specifico. Per esempio: un modello di programmazione basato evento permette che le applicazioni inviino un evento e gli inneschi ERUs corrispondente (unità di reazione di evento) nella reazione ad un evento ricevuto; presupposti per l'attivazione di controllo di ERUs; e gli oggetti di politica di consistenza di evento effettuano il modello di consistenza di evento specificato applicazione. Alcuni esempi di politica sono: una politica in cui l'ordine di evento non è garantito, ma tutti gli eventi è garantito per essere trasmesso finalmente al ERUs; e una politica che il primo innesca ERUs locale ed allora invia l'evento all'assistente. Un evento out-of-order è rilevato usando la notifica di evento dall'assistente; e una rilevazione automatica degli eventi out-of-order visti da ERUs nella stazione di lavoro locale in questo modello ottimista di esecuzione di evento. Per le applicazioni che richiedono il supporto per dichiari ripartendosi, un modello asincrono per l'aggiornamento ripiegato dichiarano, che sostiene il atomicity degli aggiornamenti attraverso gli oggetti comuni multipli è descritto. Accoppiato con una struttura marshaling flessibile, questo permette che i codici categoria attuali della dato-struttura di applicazione facilmente si estendano e resi ripartibili, mentre fornisce il supporto per context-sensitive dichiara le applicazioni marshaling. Per risolvere il problema di consistenza della replica, una combinazione del romanzo di tre meccanismi è usata: serrature globali; rilevazione di ordinamento errato dell'aggiornamento; e la clonazione un sottoinsieme degli oggetti comuni per dichiara il re-initialization. Per ridurre il carico della rete dovuto interazione a grana fine dell'utente, una struttura per l'applicazione ha specificato l'evento che ammucchia, denominato modifica ritardata di evento (LEM), aumenta l'interfaccia di evento per permettere che le applicazioni modifichino gli oggetti di evento dopo l'invio loro all'insieme.