WO2001095231A2 - Systeme de traitement de donnees oriente objet a chargement progressif - Google Patents

Systeme de traitement de donnees oriente objet a chargement progressif Download PDF

Info

Publication number
WO2001095231A2
WO2001095231A2 PCT/FR2001/001730 FR0101730W WO0195231A2 WO 2001095231 A2 WO2001095231 A2 WO 2001095231A2 FR 0101730 W FR0101730 W FR 0101730W WO 0195231 A2 WO0195231 A2 WO 0195231A2
Authority
WO
WIPO (PCT)
Prior art keywords
objects
state
execution
created
server
Prior art date
Application number
PCT/FR2001/001730
Other languages
English (en)
Other versions
WO2001095231A3 (fr
Inventor
Enrico MAÏM
Original Assignee
Maim Enrico
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR0007250A external-priority patent/FR2805378A1/fr
Priority claimed from FR0007253A external-priority patent/FR2805379A1/fr
Priority claimed from FR0007246A external-priority patent/FR2807182A1/fr
Application filed by Maim Enrico filed Critical Maim Enrico
Publication of WO2001095231A2 publication Critical patent/WO2001095231A2/fr
Publication of WO2001095231A3 publication Critical patent/WO2001095231A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9562—Bookmark management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9024—Graphs; Linked lists

Definitions

  • the present invention relates generally to a data processing system, comprising a processor cooperating with a main memory for executing applications, the system being capable of executing an object-oriented application composed of a certain number of objects and links between these objects, as well as a corresponding data processing method.
  • the invention applies more particularly to the context of a client server computer architecture, where a “light” client station executes an application in interaction with a user, and where the objects of the application are instantiated and initialized from a waiter.
  • Transient objects are specific to each execution of an application linked to a document; they have a lifespan which can in no case exceed that of the execution of the application.
  • the state and characteristic values of permanent objects are, on the contrary, saved (knowing that we are here in a case where this backup is performed on a remote server) and survive from one execution to another.
  • a difficulty with applications executed in a client / server architecture as mentioned above lies in that they can require extremely long transfer times between the server and the client, and in particular be dependent on limited bandwidth and / or irregular in the network connecting the server to the client.
  • the main object of the present invention is therefore to propose a method and a processing system in which the loading of the objects of an application can be carried out in a way which places less strain on the network, and this in a totally transparent for both the application designer, the server administrator and the user.
  • the aforementioned objects are created not when the application is launched, but in a "lazy" manner, as and when they are needed, and this in a transparent manner.
  • the designer does not need to plan these aspects when modeling the application to be developed; they are automatically managed by the system.
  • the user for his part, does not have to worry about the objects which pass between his client station and the server, everything happens for him as if he had all the objects of the application.
  • Another objective of the invention is to allow objects to be produced by "anticipation" in order to ensure the fluidity of the execution of the application. According to this approach, even during execution, according to the model, new objects appear virtually and, as before, they are only produced as and when they are actually needed.
  • Yet another objective of the invention is to reduce the consumption of resources (processor and / or memory) at the client station.
  • resources processor and / or memory
  • objects that are not (or no longer) used can cease to be really existing, that is to say to be "virtualized”. They are deleted, transparently, after a certain latency period (to avoid unwanted deletions / creations), knowing that they can be carried out again when necessary.
  • the invention proposes, according to a first aspect, a data processing system, comprising a processor cooperating with a main memory for executing applications, the system being capable of executing an object-oriented application composed of a certain number of objects. and of links between these objects, characterized in that the number of objects of the application is greater than the number of objects contained in the main memory, and in that the system includes means for selectively creating in the main memory, according to the use of the links by the application, of the parts of said application concerned by these links object by object or group of objects by group of objects.
  • the system is able to access a secondary memory, and further comprises means for initializing an object created in main memory with the value of a corresponding object contained in the secondary memory.
  • the present invention provides a method of executing an application containing a plurality of objects associated with each other according to a structure in which each object is linked to any other object by a path which can include at least one intermediate object.
  • the objects being able to selectively adopt a created state and a virtual state, characterized in that it comprises, for each remote object to be executed from a source object, the following steps:
  • the structure is tree-like.
  • an object is linked to another object either directly or via a first common ancestor.
  • the tree structure has a permanently created root object, and in that it includes the additional steps consisting in:
  • the first parent object not created use the first path information to create, if necessary, by descending from the root object, any child object not already created and located between the root object and said parent object to create, and to create said parent object itself, then - use the second path information to create if necessary, by descending from said first common ancestor, any child object not already created and lying between said first common ancestor and the distant object, and to create the distant object itself - and
  • each of the objects of the structure incorporates a connection method capable of restoring to said object a reference to another object with which said object must interact.
  • connection method call contains index information representative of the level at which said common ancestor is located and path information from the common ancestor to the second object.
  • the method further comprises, after the step of storing in the source object a reference to the remote object, the steps consisting in:
  • the method further comprises, after the step of memorizing by the second object of said reference, the step consisting in:
  • - grouped objects include display objects.
  • the grouped objects include interface objects of the application with the outside.
  • - Said grouped display objects include objects belonging to the same information page transmitted by network.
  • At least one group contains an object to be created for immediate execution and at least one object to be created for future execution.
  • the invention proposes an object-oriented data processing system comprising an application containing a plurality of objects associated with each other according to a structure in which each object is linked to any other object by a path which can include at least one intermediate object, the objects being able to selectively adopt a created state and a virtual state, characterized in that:
  • said structure is a tree structure with N levels comprising a root object created permanently, while the other objects can selectively adopt a created state and a virtual state, and in that it further comprises:
  • the invention provides an object-oriented data processing system comprising an application containing a plurality of objects associated with each other according to a structure in which each object is linked to any other object by a path which can include at least one intermediate object, the objects being able to selectively adopt a created state and a virtual state, characterized in that: said structure is a tree structure with N levels comprising a root object created permanently, while the other objects can selectively adopt a created state and a virtual state, and in that it further comprises:
  • activity sequencing means for storing activity request messages from the various objects, for selectively authorizing said objects to carry out the requested activities in turn, and
  • the invention provides a data processing system, comprising a processor executing an object-oriented application, the execution of the application comprising chain executions of objects linked to each other, characterized in that the system comprises, when an object is to be executed, means capable, on the basis of links between objects, of passing said object, if necessary, from a virtual state, where only a trace of the object is contained in a working memory, in a real state, where the object is in executable form in said working memory.
  • this system further comprises means for passing a given object from its virtual state to its real state on the basis of an instruction to execute an object located upstream of said given object.
  • the present invention relates generally to object-oriented data processing systems.
  • the present invention therefore aims to provide this kind of object-oriented application with deterministic behavior, making it possible in particular to overcome these difficulties.
  • the present invention aims to solve this problem
  • a data processing system comprising processing means executing a reactive object-oriented application and in which there may be times when the behavior of different objects is seen by a user as occurring in parallel, and in which at least some of the objects have states in which an uninterruptible set of one or more first actions and / or an interruptible set of one or more second actions are executed respectively.
  • each state of each object is decomposed into a first sub-state if necessary, in which the only first actions are executed, and into one or more second sub-states if necessary, in which s 'respectively execute the second actions.
  • a sequencing means able to communicate bidirectionally with the objects in each of their second substates in order to organize in a sequential and reproducible manner the progress of the second actions in the said second substates while maintaining the parallel vision of the behavior of objects for the user.
  • a transition from an object to a state in which one or more first actions are executed brings said object into the first sub-state of said state automatically.
  • each object having second actions has a first sub-state in which is executed, in addition to the possible first actions, a sending by means of sequencing of a trigger request message, by said sequencing means, of the execution of the second action (s).
  • each object has an automatic transition from the first substate to an intermediate substate state awaiting an execution triggering event on the part of the sequencing means, capable of causing a transition from the object to the 'one of the second substates.
  • each object is capable of sending by means of sequencing an activity request message (Put (next, 7)) indicating that there is in this same object an interruptible set of one or more second actions, while the sequencing means comprises a means for memorizing the received messages, and a means for browsing the memorized messages in the order of their arrival.
  • an activity request message Put (next, 7)
  • each activity request message sent by an object contains at least one identification of the object.
  • each object comprises a counter for sending execution request request messages capable of making it possible to determine the possible lapse of a corresponding execution trigger event delivered by the sequencing means.
  • each object has a means of comparing the value contained in said counter with a value contained in an execution triggering event received by said object to enter said second given sub-state.
  • the storage means is also able to keep track of the actions performed by said objects.
  • the storage means is also able to store a succession of trace messages received by the sequencing means and each comprising:
  • each trace message also includes an identification of the state of said object before this transition.
  • each message capable of being received by the sequencing means includes type (next / trace) information making it possible to distinguish a trace message from an activity request message.
  • the storage means is capable of storing the trace messages with the activity request messages according to a sequence corresponding to their temporal succession, while the sequencing means further comprises a processing cursor capable of traversing, in the direction of the sequence, the only activity request messages for processing.
  • Each message is associated with information representative of its position in the storage means.
  • the sequencing means is also capable of sequentially organizing the course of the first actions caused by events external to the system.
  • each of these objects is able to send to the sequencing means, a request for corresponding activity, while the sequencing means is capable of delivering to the object making such a request a correspondence authorization message (Proceed) only when there is no other first cycle running.
  • each object capable of carrying out a first cycle is capable, at the end of the execution thereof, of sending to the sequencing means a message for the end of the first cycle, so that the sequencing means can then if necessary authorize another first cycle.
  • a third object of the present invention relates to a data processing system, comprising server means and at least one client station, the or at least one of the client stations comprising a processor capable of executing, in cooperation with the means. servers, an object-oriented application comprising replicated objects each comprising a client object and a server object intended to be executed in an identical manner respectively in the client station and in the server means.
  • the third object of the present invention aims to allow, under certain conditions, the sharing of one or more applications by several users operating on different client workstations. We therefore place our in a client / server IT architecture, where each client runs an application of which certain objects can be shared by other clients.
  • a shared permanent object will be used jointly by all customers. Each user shares with the others the characteristic values of the object (state, roles, etc.).
  • Private permanent objects will, however, be specific to each client. Customers will certainly use the same objects in the sense that they use the same application, but private permanent objects will be decorrelated from one customer to another.
  • a main object of the present invention is to be able to manage the sharing of one or more applications between several clients, and more particularly to be able to manage shared permanent objects, so that the modification of such an object by a user is postponed with all the customers concerned, ie those for whom this object must be executed.
  • the primary objective of the present invention is to ensure such persistence of treatment. To achieve this objective, it is necessary that the applications used jointly by the clients also run on the server, to implement a replication mechanism by "computation".
  • any modification of a shared permanent object due to a message coming from a transient object or from a private permanent object is also carried out on a server, by replicating the transition which is at the origin thereof. (the actions performed by the shared permanent object are therefore executed both at the client who has access to this object, and on the server). These modifications are then transferred from the server to each of the clients who actually own this object.
  • This is the first aspect of the system, namely "value" replication.
  • the present invention proposes a “mixed replication” mechanism:
  • the present invention provides a data processing system, comprising server means and at least one client station, the or at least one of the client stations comprising a processor capable of executing, in cooperation with the server means, a object-oriented application comprising replicated objects each comprising a client object and a server object intended to be executed in an identical manner respectively in the client station and in the server means, system characterized in that:
  • the application also includes non-replicated objects that can be executed in the client computer only,
  • At least some of the replicated objects are objects shared between said client station and at least one other client station, and in that the result of the execution of any server object of a shared object is reproduced in each of said other client stations.
  • said execution message of the server object of the same replicated object comprises:
  • FIG. 1 diagrams the sequential behavior of a plurality of objects, according to a fourth aspect of the present invention
  • FIG. 2 illustrates the standardized notation "UML”
  • FIG. 3 illustrates a simplified example of a class diagram
  • the FIG. 4 illustrates the state transition diagram for the aforementioned example
  • FIG. 5 represents a simplified object comprising a method
  • FIG 6 illustrates by a simplified example an equivalence between attribute of a class and link between two classes
  • the Figure 7 illustrates the equivalence between an action on transition and an intermediate state with automatic outgoing transition
  • Figure 8 illustrates the addition of a pseudo-state to a diag ramme of state-transition standard
  • figure 9 illustrates a simplified example of an object having two types of actions
  • Figure 10 illustrates an enriched example of the simplified example of Figure 3
  • Figure 11 illustrates the behavior of an object in Figure 10
  • Figure 12 illustrates the principle of decomposition of the states of an object
  • Figure 13 gives an example of an object to which the principle illustrated in the figure is applied
  • FIG. 14 illustrates the object after transformation according to this principle
  • FIG. 15 illustrates the structure of a message sent by the object
  • FIG. 16 illustrates the basic behavior of a sequencer in response to such a message
  • FIG. 17 illustrates the concept of cycle used according to the invention
  • FIG. 18 illustrates the behavior of objects under control of the sequencer for certain types of cycles
  • FIG. 19 illustrates by a state-transition diagram the behavior of the sequencer with the control illustrated in FIG. 18, FIG. 20 repeats FIG. 14 with an enrichment
  • FIG. 21 illustrates the same enrichment in the case where an object has a certain type of actions
  • FIG. 22 illustrates a succession of messages memorized by the sequencer
  • FIG. 22 illustrates a succession of messages memorized by the sequencer
  • FIG. 23 illustrates the state-transition diagram of the sequencer with a history management function
  • FIG. 24 illustrates an additional exploitation by the sequencer of the messages of the fi gure 22
  • figure 25 illustrates by a state-transition diagram the behavior of the sequencer modified consequently
  • figure 26 illustrates the complete state-transition diagram of the sequencer
  • figure 27 illustrates the initial state-transition diagrams of six objects in an exemplary implementation of the invention
  • FIG. 28 shows the new state transition diagrams of the objects according to the aspect of the invention illustrated so far
  • FIG. 29 illustrates the sequence diagram of certain events and actions in a certain phase for this same example
  • FIG. 30 illustrates an extract from the corresponding message list
  • FIG. 31 illustrates the sequence diagram in another phase
  • FIG. 32 illustrates a corresponding extract from the list of messages
  • FIG. 33 illustrates the sequence diagram in a third phase
  • FIG. 34 illustrates a corresponding extract from the list of messages
  • FIG. 35 illustrates the sequence diagram of another type of action managed by the sequencer
  • Figure 36 illustrates an example of objects and their links
  • Figure 37 illustrates a tree structure of objects and links
  • Figure 38 illustrates in more detail such a structure tree
  • FIG. 39 illustrates a path between objects
  • FIG. 40 illustrates a particular composition of links in a path
  • FIG. 41 illustrates the principle of grouping certain objects of a tree structure
  • FIG. 42 illustrates the application of such a grouping to viewing areas associated with objects
  • FIG. 43 illustrates links related to the proximity between viewing areas
  • FIG. 44 illustrates groupings of objects according to the same principle, with increasing granularity
  • figure 45 illustrates two possibilities of link transformations
  • figure 46 illustrates by a simplified UML diagram two types of objects, namely object itself or collection item
  • figures 47 and 48 illustrate a first phase of a method of connecting between objects
  • FIG. 49 illustrates in another form a grouping of objects
  • FIG. 50 illustrates a certain number of actions in a tree structure of objects in connection with objects of display grouped together on an object constituting a viewing area
  • FIG. 51 illustrates the corresponding sequence diagram
  • FIG. 52 to 55 illustrate an application to links of e changing composition
  • figure 56 illustrates a list of sequencer messages in the context of figures 52 to 55
  • figure 57 illustrates an object transition within the framework of an improvement
  • figure 58 illustrates the principle of a connection anticipation between objects
  • FIG. 59 illustrates such an anticipatory connection in the form of a UML diagram
  • FIG. 60 illustrates the corresponding sequence diagram
  • FIGS. 61 and 62 illustrate two modes of anticipatory connection of objects, depending on the type object
  • Figure 63 illustrates the basic architecture of a shared data server and client workstations
  • Figure 64 illustrates the manipulation of shared objects by two users of client workstations
  • Figure 65 illustrates a principle of replication mixed according to a sixth aspect of the invention
  • FIG. 66 illustrates the same principle, applied to the case where the shared objects are managed by two servers
  • FIG. 67 illustrates the state diagrams -transition for an example of four objects, three of which are of different types
  • FIG. 68 illustrates the behavior of these four objects during a transition caused by the user on one of the objects
  • FIG. 69 illustrates the associated behavior at the level of two message lists, respectively on the side of a client station and on the side of a server
  • FIG. 70 illustrates a codification of objects used in FIG. 71
  • FIG. 71 illustrates the propagation of a transition to from a client station to a server and to other client stations
  • FIG. 72 illustrates the same principle of propagation in the case where there are two servers.
  • Sequencer makes it possible to give each of the objects in turn a part of the resources corresponding to the sending of a message (therefore the carrying out of an action).
  • FIG. 1 of the drawings This objective is shown diagrammatically in FIG. 1 of the drawings, where it can be seen that independent actions of four objects A, B, C and D are organized in a determined order, according to a single unfolding process, allocating resources in turn to each of these objects.
  • Section 1 Section 1 - Framework
  • a Switch object which is in its initial “Idle” state, can receive a “TurnSwitch” event which triggers a transition from the “Idle” state to the same state, during which a “TurnLamp” message is sent to the “myLamp” object (of class “Lamp”).
  • This “TurnLamp” message becomes, for the lamp that receives it, an event triggering a transition from “Off” to “On”, or vice versa, depending on the state in which it is located.
  • FIG. 6 illustrates the equivalence between a class “Class 1” endowed with an attribute “Attributel (of class Class2)”, and the link between the two classes “Classel” and “Class2”.
  • transitions are seen as instantaneous whereas the states generally have a duration.
  • Each state E of an object thus corresponds to a part of its behavior. This part is described by a set of actions performed by the object in state E. These actions make it possible to trigger transitions of other objects, by the emission of the associated event.
  • B triggers the transition associated with the event "evt" in C (identified by the role "theC").
  • actions can be of two types:
  • a state will therefore be represented as illustrated by way of example in FIG. 9.
  • Do here specifies actions of type - 4cttv ⁇ ty).
  • an object when it enters a new state, an object performs its On Entry actions, then once these are completed, follow up on the Activity actions (denoted "Do / "). However, from the user's point of view, the objects perform the actions in parallel with each other (since the series of Activity actions can be interrupted). The purpose of the sequencing mechanism is to simulate this parallelism by shaking hands with the objects which thus perform their Activity actions in turn.
  • the models must be arranged in specific ways as we will see in the next section, this in a transparent way for the modeller.
  • the mechanism of the invention consists in scheduling the Activity actions of objects using a particular entity, namely a Sequencer.
  • a particular entity namely a Sequencer.
  • the states are transformed into a form which is called the "form canonical ”, as illustrated in detail in FIG. 12, canonical form in which these states are decomposed so that each action Activity corresponds to a state.
  • the Sequencer is then responsible for managing the transitions between the states corresponding to Activity actions.
  • the transformation into canonical form must respect the atomic character of the On Entry actions. Overall, the transformation into canonical form must therefore meet two constraints:
  • On Entry actions are grouped in a "Sentry" state, as illustrated in figure 11. So that these actions are not interrupted, the only outgoing transition from this state is an automatic transition.
  • An automatic transition is a transition with which no event is associated. Such a transition therefore takes place only after all the actions of the Sentry state have been carried out.
  • the object when the incoming transition is triggered (by another object for example), the object enters the Sentry state. In this state, the object performs all On Entry actions of state S. When all actions are performed, and only when they are done, the object enters the Sactivity state. As in the example, the object did not perform Activity actions in state S, it places itself in the sub-state Swait where it waits to receive an event allowing it to return to state T or in U state.
  • the object enters the Sentry state and performs all the On Entry actions provided for in the S state there. Then, the object automatically enters the Swait state.
  • Activity actions were planned in state S. Each of these actions is treated in a different state. We will call them sub-states of activity. The transition from one sub-state of activity to another takes place upon receipt of the next event. It is the Sequencer which emits this event to simulate the parallelism between the objects.
  • the object can receive an event associated with one of the outgoing transitions. At this point, the object leaves the Sactivity state (and therefore the activity sub-state in which it is located) to enter either T or U.
  • an object informs the sequencer of this by an appropriate message, and the sequencer writes in the trace the following information:
  • a cycle therefore begins when an object O leads another to make a transition, and ends when O takes over.
  • FIG. 17 illustrates an example where two cycles Cycle 1 and Cycle2 follow one another, the return from the object ObjectC occurring upon receipt of "EntryBl" because, if ObjectB changes state well, it has not action.
  • the Cycle2 cycle is similar, with browsing of ObjectA, ObjectC and ObjectD and return from ObjectD which has no action to perform.
  • an FCC First Cycle Counter built-in counter in the Sequencer is incremented. If, after incrementation, this counter is worth 1, then the Sequencer tells the object that the first cycle can begin by sending the message proceed. When the Sequencer receives EOFC, it decrements its first cycle counter.
  • the Sequencer When the Sequencer receives a BOFC while a first cycle is already in progress, it waits for the current cycle (as well as all those that are on hold) to be completed, before triggering the new first cycle.
  • an object will tell the sequencer that it has an activity to perform just before the last action of its On Entry part of the current state, by writing it in the history. (In case it has only one On Entry action in the current state, the object will inform the sequencer before performing the action). This is done by writing to the history using put.
  • the set of information stored in the history for each put must therefore be extended as follows: in addition to the information already presented, a put must also contain an obsolescence type and index.
  • the Sequencer sends next to the object specified in the put.
  • the processing of activities by the Sequencer can therefore be modeled by the state-transition diagram illustrated in FIG. 25.
  • A, B, and C are set in canonical form as illustrated in FIG. 28.
  • the history carries the information illustrated in FIG. 30.
  • the sequencer will start processing activities from the cursor position of the
  • the activities of an object can be interrupted by a change of state. It will be said that the Sequencer sends an obsolete next event if the object has made at least one transition since it issued the corresponding next type put. This can happen when the activities specific to a state are interrupted in the sense that we saw previously.
  • each object has a counter for put emissions of type next (initialized to zero at the start of execution). Each time an object emits a put (of trace or next type), it increments this counter before and, in the case of a put of next type, passes the value of the counter in the history. Incidentally, each object has also a PendingNext flag allowing to know if it is waiting or not for a next. When sending a next type of output, this flag goes to 1 (it is reset to 0 when the next is received). Subsequently, when the object receives a next and it also receives the value it had passed when sending the put of type next. The object then compares this value it receives with the current value of its counter. If the two values are equal, the next received must be processed, otherwise it is obsolete and is therefore ignored. A corresponding example is illustrated in Figure 35.
  • transient objects are specific to each execution of a document; they have a lifespan which can in no case exceed that of the execution of the application.
  • the state and characteristic values of permanent objects are, on the contrary, saved (knowing that we are here in a case where this backup is performed on a remote server) and survive from one execution to another.
  • the model (by means of which the document was created) indicates that, from the start of the 'execution, these objects already exist and are available to each other (depending on the associations defined in the model).
  • the basic principle of this chapter is however not to create these objects from the start, but in a “lazy” way (as and when they are needed), and this in a transparent way for the user.
  • the designer does not need to plan for these aspects when modeling the application to be developed; they are automatically managed by the system.
  • the user for his part, does not have to worry about the objects which pass between his client station and the server, everything happens for him as if he had all the objects of the application.
  • composition associations there is a composition (container-content relationship) which implies that an object cannot be content only by a single object (the containing object) at a given time.
  • composition associations are noted graphically in the form of solid diamonds. For example, in Figure 36, object A contains objects B, C and D.
  • An application therefore contains a set of objects, endowed with behavior. These behaviors are defined using state machines as we saw them in section 1 of the previous chapter.
  • Objects form a tree structure of composition links, within which any object is necessarily a component of another object. Any object therefore has a "path" which identifies it from the root of the application, the Root object, as illustrated in Figure 37.
  • the collection is represented by a Collection object which is static, and which appears in the tree structure based on the composition links.
  • the sub-objects of the Collection object represent the elements of the collection as shown in Figure 38, and are identified by indices.
  • the objects can also have between them other links than the composition links which form the structure of the application.
  • These links are the instantiations of the different associations existing between the classes of objects. It is via these links that objects can communicate, that is to say send messages to each other.
  • a link between two objects is defined by a path leading from one to the other, within the structure.
  • a link can be built using only composition links, we will call them “basic links”.
  • Figure 39 shows an example. In this figure, the path leading from D to C is formed from the composition links D_B, B_A and A_C. Such a path
  • the path leading from D to E can reuse the path established between D and C in the previous example: D_C and CJE. It is not necessary to go through B and A, but it is possible to determine the corresponding path which uses only the composition links. This will play a major role, as we will see in the first part of section 2 of chapter V, as far as the realization of objects is concerned.
  • a derived link that is to say exploiting a finite number of links (which can be basic and / or derived).
  • Display elements are grouped together to form different screens of the human machine interface of an application, different pages of a website, or different fields of vision in a 3D virtual reality environment for example. This grouping of display elements is carried out using specially created objects, which we call visuZone. Each group of display elements is linked to a visuZone object. These groups are not necessarily disjointed. Thus, FIG. 41 illustrates a group of display objects D, F and H grouped together.
  • the purpose of grouping display objects in this way is as follows: during execution, the loading of a display object belonging to a viewing area to a client, causes the loading of all other display objects from the same area. Depending on the desired anticipation depth, the objects (display or not) linked to the objects in the viewing area can also be loaded.
  • ViuZone objects can be moving a frame on a map.
  • VisuZone objects allow you to manage concepts such as geographic neighborhood and zoom.
  • visuZone objects The purpose of using visuZone objects here is to ensure that only the objects in the frame and those that are geographically close to it are present.
  • loading a visuZone object causes (automatically), in advance, the loading of display objects located in neighboring areas.
  • the depth of anticipation and the size of the viewing areas are the parameters that allow to overcome the granularity of the "mesh".
  • an interesting feature is also the possibility of zooming in and out at a given point on the map.
  • This function induces the concept of level of detail, therefore of hierarchy within visuZone objects, an example of such a hierarchy being illustrated in FIG. 44.
  • the higher visuZone object corresponds to the lower level of detail, while the objects visuZone below represent a median level of detail, and the lowest visuZone objects represent a higher level of detail.
  • Each visuZone object of the highest level of detail is linked to all the display objects of the finest granularity viewing area.
  • the visuZone object of the lowest level of detail (higher object) is linked to certain objects from all parts of the fragmented plan. This constitutes an overall view of the map where only the most striking elements appear.
  • the visuZone objects of the median level of detail (intermediate objects) are linked to additional objects of their respective quarter planes. These objects provide more precision on each quarter of a plane.
  • a zoom approach without level of detail can also be considered.
  • the lower visuZone objects are linked to all the objects in their plane fraction.
  • the intermediate visuZone objects are only linked to the lower objects, etc.
  • Root object When launching the application, only the document root (Root object) is created. It constitutes the root of the whole tree structure of the objects present in the document. From there, the other objects are "made” progressively, on request from another object, or in advance.
  • connection process (defined below) which is an integral part of the message sending process.
  • This reference once obtained, is stored by the object within the structured variable "port" which already contains the path.
  • This method can only work for paths formed from composition links only. Indeed, it is only by following the composition links that we can create the instances of the objects (an object can only be produced by its parent). Reaching an object by following a path implies being able to achieve the objects of this path which are only virtually present, hence the need for such a path to be based on composition links. For this, it is possible to reduce any link to the corresponding basic link, that is to say to the minimum set of composition links which constitute it.
  • Oo wants to connect to an object ON-
  • Oo has a path path which exploits the tree structure.
  • a value of this path can be stored in the port, but this value can also be modified programmatically during execution, knowing that a port (basic link) can only contain composition links.
  • a port includes a positive integer index value and a series of objects (O n ) ne [i..N]. index indicates at which level of the hierarchy, from the connecting object, is the common ancestor Oj.
  • the sequence (O n ) n S [i, N] gathers the objects which lead from Oi to O N , it constitutes the “descending” path (towards O N ), which we will denote descendingPath.
  • Each O n can designate either an object or a collection item. In the latter case, we will denote O n [p] where O n is X collection object which groups all the collection elements, and where p represents the index of the element within the collection.
  • O 0 implies that all objects, up to the common ancestor Oj, have been done at least once (even if they have been virtualized since).
  • connection process resides in the recursive call of a connect method carried by each object. This method returns the reference of the object to which we want to connect. It takes as argument the path (index, descendingPath) leading to the object to which we want to connect and the argument depth which indicates how deep the connections will be made, as we will see in section 3 of chapter V. This process is launched by calling the method symbolized by:
  • Oo connect ⁇ ndex, descendingPath, depth
  • Oo sends its own reference which O N stores in an inverseRef attribute. Indeed, if O N is virtualized, the reference that Oo has no longer has any meaning. O N must therefore warn Oo that it is virtualized by setting to Null its reference carried by Oo. It can do this through inverseRef. Oo then knows that he will have to reconnect to O N to send him a message.
  • each object has the reference of the Root object.
  • the reference of its parent is Null
  • it passes to the Root object the path which leads from the root to its parent.
  • the Root object can then instantiate the parent by connecting to it with the path it received. An illustration of this phenomenon is given in the example shown in Figure 47.
  • A knows its own path from the root (myB_myD_myA). It can therefore infer that of its parent D: myB_myD. This path is passed to the Root object which will then instantiate the missing objects up to D (here B in step 1 and D in step 2). ). Once D instantiated, its reference is passed to A by method return.
  • the connection process can then be summarized as follows:
  • the Root object sends a message to the visuZone object which groups the display elements that constitute the application's home page.
  • the visuZone object is black and the display objects are gray.
  • the visuZone object connects to its display elements, exactly according to the same process described above. This is detailed in figure 50, and can be translated by the state-transition diagram of figure 51.
  • composition links may be modified.
  • the fact that an object has only one parent at a given time does not prevent having several parents at different times.
  • the solid lines represent the composition links and the dotted lines represent the links of simple associations.
  • F has a path (1, G_I_J).
  • the value 1 indicates that you have to go up a notch in the hierarchy of ancestors of F to find the ancestor common to F and I (in this case D).
  • the path G_I_J shows that it is necessary to go through G and I to reach J. If I is virtualized, it is up to G to realize it again, the same between J and I.
  • compositional link between G and I is broken, and replaced by a link between H and I, as shown in Figure 53.
  • the structured variable port must contain, for parent-child composition links, not only the reference of the child, but also that of the object itself or of the new parent who replaces it.
  • G is the parent of I, and the reference to the parent it carries is a reference to itself.
  • the port variable of H then takes the form that G had in the previous step.
  • the parent reference points to H and itself, and the child reference points to I.
  • transient objects specific to the client computer and which do not survive the execution of the application
  • permanent objects (saved on a server).
  • a permanent object can be freely “virtualized” on the client (when it is not in use), since its current state can always be retrieved from the server.
  • a transient object can only be virtualized when it is in its initial state. In fact, by its nature, its state is only present in memory on the user's client computer, and is not saved anywhere. It can therefore only be carried out in its initial state. In fact, if a transient object were virtualized in a state other than its initial state, we would lose information.
  • Virtualization is triggered by visuZone objects: when display objects disappear from the screen (for example because the user has changed pages), a single timer is triggered. If no display element linked to the visuZone object is redisplayed before the timer expires, all the elements are virtualized.
  • F is a display object that can be virtualized.
  • History tells us that at the logical time t + 7, E was at the origin of a transition from F, then at time t + 5, D was at the origin of a transition from E , ... and so on until A whose transition was initiated by the user.
  • A, B, D, and E are therefore candidates for virtualization (virtualisable) when F is virtualized.
  • an object candidate for virtualization can be in the process of interacting with other objects, and it is therefore not necessary to virtualize it (it will be noted here that an interaction, close in time, expected with objects not related to the The current active visuZone object or its Vosins, is not an obstacle to virtualization if these objects are replicated and live on the server - see further chapter NI). To be able to detect these cases, we have several techniques:
  • each object has a PendingNext flag which indicates whether it is waiting for a next one to continue its activities.
  • An object in this case should of course not be virtualized, since it would be made again shortly after, as soon as it receives the next.
  • a virtualizable object in the cause and effect chain that led to the transition of a display object
  • the object records the CPU time (time of the central processing unit that executes it) in a lastActionTime attribute.
  • ⁇ time of the central processing unit that executes it
  • a probabilistic mechanism allowing to associate (manually, or by inference from the system) to each object a probability of being virtualized.
  • the structural approach offers the advantage of being transparent (does not require additional specification). It uses the links that have been previously established between the objects, depending on the structure of the associations in the model. This approach therefore does not give inevitably a lot of results when launching the application, but is more and more effective during execution.
  • the behavioral approach consists in running the application model with a certain number of steps in advance, thanks to additional specifications (annotations) explicitly provided in the model.
  • this involves adding to the model “anticipatory transitions” which represent the effects of the probable impulses that the system could receive from its external environment.
  • anticipatory transitions are not taken into account as real transitions (in other words, an anticipatory transition does not change the current state of the object but rather changes one or more working variables in which is simulated the future state), they nevertheless serve, in particular, to "realize” the objects which would be in the "virtual" state.
  • a Switch object can transition from
  • the modeller declares that the anticipatory transitions are anticipated with a time in advance ⁇ (he can declare this globally for the whole application or selectively).
  • the predictive transition of the Switch object is thus done after 3- ⁇ seconds if ⁇ ⁇ 3, and immediately otherwise, after entering the Off state.
  • the targeted object is a display element
  • anticipation is done through the visuZone object. It ensures the link between the targeted object (the first element and other items in the same group. But this intermediary must be transparent and therefore must not intervene in the calculation of the depth of anticipation.
  • FIG. 61 which illustrates a connection to the depth 2
  • the connection to a visuZone object does not count in the calculation of the anticipation depth.
  • visuZone objects can be linked with each other. This does not change the anticipation mechanism in any way, except that in this case the connection between visuZone objects counts in the calculation of the depth.
  • Figure 62 shows, still in the case of a connection to depth 2, that the connection between two visuZone objects counts in the calculation of the anticipation depth.
  • Section 1 Types of objects
  • transient objects there are two types of objects: transient objects and permanent objects.
  • permanent objects In this chapter, the latter category is subdivided into two: private permanent objects and shared permanent objects.
  • a shared permanent object can be used jointly by all clients. Each user shares with the others the characteristic values of the object (state, roles, etc.).
  • Private permanent objects are, as their name suggests, specific to each client. Customers certainly use the same objects in the sense that they use the same application, but private permanent objects are decorrelated from one customer to another.
  • Managing the sharing of one or more applications between several clients therefore amounts to managing shared permanent objects, in such a way that the modification of such an object by a user is carried over to all the clients concerned, ie those where this object really exists.
  • the first is based on replication by “values” of shared data.
  • the replication between the different PC clients can then be managed by means of a Database Management System on one or more common servers PS.
  • a Database Management System on one or more common servers PS.
  • Such a system ensures the permanence of shared information and takes care of concurrent access to data.
  • the management of determinism is not necessary. Indeed, the behavior of objects (the actions they perform) takes place with different clients and in no case on a server. The latter retaining only the different values (state ...) of the shared objects, it does not need to reproduce the behavior of the objects.
  • Each time a shared object O is modified by a client the values of O are updated in the data structure, and reproduced by clients who also use O.
  • Figure 64 illustrates the case where two users Userl and User2 handle different objects (black objects for Userl, white objects for User2).
  • Any modification of a shared permanent object due to a message coming from a transient object or from a private permanent object is also carried out on a server, by replicating the transition which is at the origin of it (the actions carried out by the shared permanent object are therefore executed both at the client who has locked this object, and on the server). These modifications are then transferred from the server to each of the clients who actually own this object.
  • Figure 65 illustrates the two types of replication between a client and a sharing server, when transient objects, private permanent objects and shared permanent objects are used.
  • transient objects private permanent objects
  • shared permanent objects shared permanent objects
  • Such an approach is not limited to the use of a single server, as shown in Figure 66 where there are two sharing servers Sharing Server 1 and Sharing Server 2 cooperating one with the other.
  • This replication mechanism can be split into two distinct phases: the replication on a server of a transition made by an object to a client (who is entitled to it in the sense of mutual exclusion), and the propagation of this same transition from the server to all clients who actually own (in the sense of the progressive loading mechanism) the object.
  • a permanent shared object SPO for “Shared Persistent Object” in English terminology
  • a customer C performs a transition due to the reception of a message from a transient object or from a private permanent object.
  • SPO Shared Persistent Object
  • A is a transient object
  • B and C are shared permanent objects
  • D is a private permanent object.
  • - object D is a permanent private object, the server application does not have visibility of it.
  • the message sent by B in state S5B is ignored.
  • FIG. 71 This can be materialized by the diagram of FIG. 71, to be considered in relation to the diagram of FIG. 70 which gives the representation of a transient object T and three shared permanent objects PI, P2 and P3.
  • T object forwards the PI object, and this is replicated to the server.
  • Client L actually owns the objects PI, P2 and P3. The transitions of each of these objects are replicated from the server.
  • Client M actually only has objects P2 and P3. Their transitions are replicated. The PI object is only there virtually, and its transition is not replicated.
  • transitions which are located downstream of the object P3 take place independently at the client K and the server.
  • Objects shared by clients may be spread across multiple servers.
  • the replication and propagation mechanism presented in chapters IV and V remains the same for each server taken separately.
  • Each server runs the application and regulates the objects it owns by means of a sequencer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un système de traitement de données comprend un processeur coopérant avec une mémoire principale pour exécuter des applications, le système étant apte à exécuter une application orientée objets composée d'un certain nombre d'objets et de liens entre ces objets. Ce système est remarquable en ce que le nombre d'objets de l'application est supérieur au nombre d'objets contenus dans la mémoire principale, et en ce que le système comporte des moyens pour sélectivement créer dans la mémoire principale, en fonction de l'utilisation des liens par l'application, des parties de ladite application concernées par ces liens objet par objet ou groupe d'objets par groupe d'objets. L'invention propose également un procédé et des systèmes de traitement associés.

Description

SYSTEME DE TRAITEMENT DE DONNEES ORIENTE OBJET A CHARGEMENT PROGRESSIF
La présente invention concerne d'une façon générale un système de traitement de données, comprenant un processeur coopérant avec une mémoire principale pour exécuter des applications, le système étant apte à exécuter une application orientée objets composée d'un certain nombre d'objets et de liens entre ces objets, ainsi qu'un procédé de traitement de données correspondant.
L'invention s'applique plus particulièrement au contexte d'une architecture informatique client serveur, où un poste client « léger » exécute une application en interaction avec un utilisateur, et où les objets de l'application sont instanciés et initialisées à partir d'un serveur.
On peut classer les objets en deux types principaux : les objets transitoires, et les objets permanents. Les objets transitoires sont propres à chaque exécution d'une application en liaison avec un document ; ils ont une durée de vie qui ne peut en aucun cas excéder celle de l'exécution de l'application. L'état et les valeurs caractéristiques des objets permanents sont, au contraire, sauvegardés (sachant que l'on est ici dans un cas où cette sauvegarde est effectuée sur un serveur distant) et survivent d'une exécution à l'autre.
De par la structure induite par le diagramme de classe de l'application, un certain nombre d'objets « existent » d'emblée au lancement de l'application : par exemple, le modèle (au moyen duquel le document a été créé) indique que, dès le début de l'exécution, ces objets existent déjà et sont à disposition les uns des autres (en fonction des associations définies dans le modèle).
Une difficulté avec les applications exécutées dans une architecture client/serveur telle que précitée réside en ce qu'elles peuvent nécessiter des temps de transfert extrêmement importants entre le serveur et le client, et se trouver en particulier tributaires d'une bande passante limitée et/ou irrégulière au niveau du réseau reliant le serveur au client.
La présente invention a pour donc pour objectif premier de proposer un procédé et un système de traitement dans lesquels le chargement des objets d'une application puisse s'effectuer d'une façon qui sollicite moins fortement le réseau, et ceci d'une manière totalement transparente tant pour le concepteur de l'application que pour l'administrateur du serveur et l'utilisateur.
Selon le principe de base de la présente invention, les objets précités sont créés non pas dès le lancement de l'application, mais de manière « paresseuse », au fur et à mesure de leur besoin, et ceci de manière transparente. Ainsi le concepteur n'a pas besoin de prévoir ces aspects lors de la modélisation de l'application à développer ; ils sont automatiquement gérés par le système. L'utilisateur, quant à lui, n'a pas à se soucier des objets qui transitent entre son poste client et le serveur, tout se passe pour lui comme s'il possédait l'ensemble des objets de l'application.
Ainsi, certains objets sont en fait absents quand, selon le modèle, ils devraient exister ; on dira qu'ils existent « virtuellement ». Le comportement de l'application n'en est pas gêné car ces objets sont créés ou « réalisés » selon un principe de «juste à temps », au fur et à mesure des besoins.
Un autre objectif de l'invention est de permettre de réaliser des objets par « anticipation » afin d'assurer la fluidité de l'exécution de l'application. Selon cette approche, même en cours d'exécution, selon le modèle, de nouveaux objets apparaissent virtuellement et, comme précédemment, ils ne sont réalisés qu'au fur et à mesure de leurs besoins réels.
La résultat est que le téléchargement des objets se fait progressivement. Cela permet de conserver des temps de chargement raisonnables notamment dans des conditions de bande passante faible et irrégulière du réseau.
Un autre objectif encore de l'invention est de réduire la consommation en ressources (processeur et/ou mémoire) au niveau du poste client. Plus précisément, les objets qui ne sont pas (ou plus) utilisés peuvent cesser d'être réellement existants, c'est-à-dire être « virtualisés ». Ils sont supprimés, de manière transparente, après un certain délai de latence (pour éviter des suppressions/créations intempestives), sachant qu'ils pourront être réalisés à nouveau quand nécessaire.
Plus précisément, l'invention propose selon un premier aspect un système de traitement de données, comprenant un processeur coopérant avec une mémoire principale pour exécuter des applications, le système étant apte à exécuter une application orientée objets composée d'un certain nombre d'objets et de liens entre ces objets, caractérisé en ce que le nombre d'objets de l'application est supérieur au nombre d'objets contenus dans la mémoire principale, et en ce que système comporte des moyens pour sélectivement créer dans la mémoire principale, en fonction de l'utilisation des liens par l'application, des parties de ladite application concernées par ces liens objet par objet ou groupe d'objets par groupe d'objets.
De façon avantageuse, le système est apte à accéder à une mémoire secondaire, et comprend en outre des moyens pour initialiser un objet créé en mémoire principale avec la valeur d'un objet correspondant contenue dans la mémoire secondaire.
Selon un deuxième aspect, la présente invention propose un procédé d'exécution d'une application contenant une pluralité d'objets associés entre eux selon une structure dans laquelle chaque objet est lié à tout autre objet par un chemin pouvant inclure au moins un objet intermédiaire, les objets pouvant sélectivement adopter un état créé et un état virtuel, caractérisé en ce qu'il comprend, pour chaque objet distant à exécuter à partir d'un objet source, les étapes suivantes :
- vérification de l'état créé ou non de l'objet distant,
- dans la négative, parcours du chemin entre l'objet source et l'objet distant à partir de l'objet source jusqu'à l'objet distant en passant le cas échéant par le ou les objets intermédiaires,
- création de l'objet distant, et
- stockage dans l'objet source d'une référence à l'objet distant créé en vue d'un accès ultérieur direct audit objet distant à partir dudit objet source.
Des aspects préférés, mais non limitatifs, de ce procédé sont les suivants :
- la structure est arborescente.
- un objet est lié à un autre objet soit directement, soit via un premier ancêtre commun.
- la structure arborescente possède un objet racine créé de façon permanente, et en ce qu'il comprend les étapes additionnelles consistant à :
- attribuer à chaque objet une première information de chemin décrivant le chemin de l'objet racine vers l'objet parent dudit objet ;
- associer à chaque objet un ensemble d'informations de lien comprenant, pour chacun des autres objets dont il est susceptible de causer directement l'exécution, une seconde information de chemin vers ledit autre objet;
- lors de l'exécution de l'objet source, déterminer à partir desdites informations de lien, si l'objet distant est ou non à l'état créé,
- dans l'affirmative, causer l'exécution de l'objet distant,
- dans la négative, parcourir la structure arborescente de l'objet source en direction de l'objet racine, d'objet enfant vers objet parent, jusqu'à un premier ancêtre commun entre l'objet source et l'objet distant, pour déterminer à chaque fois si l'objet parent est créé,
- pour le premier objet parent non créé, utiliser la première information de chemin pour créer le cas échéant, en descendant à partir de l'objet racine, tout objet enfant non déjà créé et se situant entre l'objet racine et ledit objet parent à créer, et pour créer ledit objet parent lui- même, puis - utiliser la seconde information de chemin pour créer le cas échéant, en descendant à partir dudit premier ancêtre commun, tout objet enfant non déjà créé et se situant entre ledit premier ancêtre commun et l'objet distant, et pour créer l'objet distant lui-même, et
- mettre à jour les informations de lien pour y indiquer que l'objet distant est créé.
- chacun des objets de la structure incorpore une méthode de connexion apte à restituer audit objet une référence d'un autre objet avec lequel ledit objet doit interagir.
- un appel de méthode de connexion contient une information d'index représentative du niveau auquel se trouve ledit ancêtre commun et une information de chemin de l'ancêtre commun vers le second objet.
- le procédé comprend en outre, après l'étape de stockage dans l'objet source d'une référence à l'objet distant, les étapes consistant à :
- provoquer l'envoi du premier objet vers le second objet d'une référence du premier objet,
- provoquer la mémorisation par le second objet de ladite référence.
- le procédé comprend en outre, après l'étape de mémorisation par le seconde objet de ladite référence, l'étape consistant à :
- lorsque le second objet s'apprête à passer de l'état créé à l'état virtuel, utiliser ladite référence mémorisée par le second objet pour adresser au premier objet un message représentatif d'une telle virtualisation.
- il existe des groupes d'objets tels que la création d'un objet d'un groupe donné implique la création des autres objets dudit groupe.
- les objets groupés comprennent des objets d'affichage.
- les objets groupés comprennent des objets d'interface de l'application avec l'extérieur.
- lesdits objets d'affichage groupés comprennent des objets appartenant à une même page d'informations transmise par réseau.
- au moins un groupe contient un objet à créer pour exécution immédiate et au moins un objet à créer pour exécution future.
Selon un troisième aspect, l'invention propose un système de traitement de données orienté objets comprenant une application contenant une pluralité d'objets associés entre eux selon une structure dans laquelle chaque objet est lié à tout autre objet par un chemin pouvant inclure au moins un objet intermédiaire, les objets pouvant sélectivement adopter un état créé et un état virtuel, caractérisé en ce que :
- ladite structure est une structure arborescente à N niveaux comportant un objet racine créé de façon permanente, tandis que les autres objets peuvent sélectivement adopter un état créé et un état virtuel, et en ce qu'il comprend en outre :
- des moyens de création des objets par mise en œuvre du procédé tel que défini ci- dessus, et
- des moyens pour sélectivement rendre virtuels au moins certains des objets créés après l'écoulement d'une durée déterminée pendant laquelle aucun des objets n'a été exécuté.
Selon un quatrième aspect, l'invention propose un système de traitement de données orienté objets comprenant une application contenant une pluralité d'objets associés entre eux selon une structure dans laquelle chaque objet est lié à tout autre objet par un chemin pouvant inclure au moins un objet intermédiaire, les objets pouvant sélectivement adopter un état créé et un état virtuel, caractérisé en ce que : - ladite structure est une structure arborescente à N niveaux comportant un objet racine créé de façon permanente, tandis que les autres objets peuvent sélectivement adopter un état créé et un état virtuel, et en ce qu'il comprend en outre :
- des moyens de création des objets par mise en œuvre du procédé tel que défini plus haut,
- des moyens de séquencement d'activité pour mémoriser des messages de demandes d'activité de la part des différents objets, pour sélectivement autoriser lesdits objets à exercer tour à tour les activités demandées, et
- des moyens pour sélectivement rendre virtuels au moins certains des objets après avoir vérifié au niveau des moyens de mémorisation qu'il n'existe pour aucun d'entre eux un message de demande d'activité mémorisé.
Selon un cinquième aspect, l'invention propose un système de traitement de données, comprenant un processeur exécutant une application orientée objets, l'exécution de l'application comportant des exécutions en chaîne d'objets liés les uns aux autres, caractérisé en ce que le système comporte, lorsqu'un objet doit être exécuté, des moyens aptes, sur la base des liens entre objets, à faire passer ledit objet, le cas échéant, d'un état virtuel, où seulement une trace de l'objet est contenue dans une mémoire de travail, à un état réel, où l'objet se trouve sous forme exécutable dans ladite mémoire de travail.
Avantageusement, ce système comprend en outre des moyens pour faire passer un objet donné de son état virtuel à son état réel sur la base d'une instruction d'exécution d'un objet situé en amont dudit objet donné.
Selon un deuxième objet de l'invention, la présente invention concerne d'une façon générale les systèmes de traitement de données orientés objet.
Il existe des applications orientées objet dans lesquelles, en raison de différents facteurs et notamment l'allocation de temps machine, l'allocation de temps de communication sur réseau, etc., le comportement de l'application pour l'utilisateur n'est pas perçu comme identique à chaque exécution, ou en d'autres termes n'est pas reproductible.
Ceci est indésirable en ce que l'utilisateur peut percevoir cette non-reproductibilité comme un défaut de l'application.
Notamment, lorsqu'une application orientée objets est exécutée dans un mode dit de « multi- threading » selon la terminologie anglo-saxonne et lorsque des objets de l'application sont répliqués pour être exécutés simultanément dans deux unités de traitement différentes (telles qu'un serveur et un poste client reliés par réseau), il n'est pas évident de gérer le déroulements des actions dans les deux objets exécutés pour qu'ils soient synchrones et pour obtenir un déroulement harmonieux de l'exécution de l'application.
La présente invention vise donc à doter ce genre d'application orientée objets d'un comportement déterministe, permettant notamment de pallier ces difficultés.
Ainsi, rechercher le déterminisme est le fruit d'une double motivation, permettant d'assurer les propriétés suivantes :
Pouvoir reproduire de façon identique une même exécution : un utilisateur s'attend à ce que l'application qu'il utilise soit reproductible, c'est-à-dire ait toujours le même comportement.
Pouvoir reproduire de façon identique une exécution entre plusieurs machines à l'aide d'un mécanisme de réplication par calcul.
Assurer un tel déterminisme est cependant loin d'être évident en particulier pour une application constituée de plusieurs objets « actifs » en même temps, c'est-à-dire qui évoluent en parallèle dans le mode de « multi-threading » précité. En effet un tel mode d'exécution, bien que présentant certains avantages, crée de façon inhérente du non-déterminisme, lié en particulier au fait que, d'une exécution à l'autre, l'occupation du système peut varier, et les tâches effectuées par les objets peuvent prendre plus ou moins de temps.
Une telle approche, où chaque objet évolue selon un déroulement (« thread » selon la terminologie anglosaxonne) indépendant, ne peut donc pas répondre à l'objectif de déterminisme recherché.
La présente invention vise à résoudre ce problème
Elle propose à cet effet un système de traitement de données, comprenant des moyens de traitement exécutant une application orientée objets réactive et dans laquelle il peut exister des instants où les comportements d'objets différents sont vus par un utilisateur comme se produisant en parallèle, et dans laquelle au moins certains des objets présentent des états dans lesquels s'exécutent respectivement un ensemble ininterruptible d'une ou plusieurs premières actions et/ou un ensemble interruptible d'une ou plusieurs secondes actions.
Le système est caractérisé en ce que chaque état de chaque objet est décomposé en un premier sous-état le cas échéant, dans lequel s'exécutent les seules premières actions, et en un ou plusieurs seconds sous-états le cas échéant, dans lesquels s'exécutent respectivement les secondes actions.
Il est prévu en association avec les seconds sous-états un moyen de séquencement apte à communiquer de façon bidirectionnelle avec les objets dans chacun de leurs seconds sous-états pour organiser de façon séquentielle et reproductible le déroulement des secondes actions dans lesdits seconds sous-états tout en conservant la vision parallèle des comportements des objets pour l'utilisateur.
Des aspects préférés, mais non limitatifs, du système selon l'invention sont les suivants :
- une transition d'un objet vers un état dans lequel s'exécutent une ou plusieurs premières actions amène ledit objet dans le premier sous-état dudit état de façon automatique.
- chaque objet possédant des secondes actions présente un premier sous-état dans lequel s'exécute, en sus des éventuelles premières actions, un envoi au moyen de séquencement d'un message de demande de déclenchement, par ledit moyen de séquencement, de l'exécution de la ou des secondes actions.
- chaque objet possède une transition automatique du premier sous-état vers un état sous-état intermédiaire d'attente d'un événement de déclenchement d'exécution de la part du moyen de séquencement, apte à provoquer une transition de l'objet vers l'un des seconds sous-états.
- la transition dudit sous-état intermédiaire vers l'un des seconds sous-états, de même que la transition d'un second sous-état vers un autre second sous-état, s'effectuent en réponse à un même événement (Next).
- chaque objet est apte à adresser au moyen de séquencement un message de demande d'activité (Put(next,...)) indiquant qu'il existe dans ce même objet un ensemble interruptible d'une ou plusieurs secondes actions, tandis que le moyen de séquencement comprend un moyen de mémorisation des messages reçus, et un moyen pour parcourir les messages mémorisés dans l'ordre de leur arrivée.
- chaque message de demande d'activité émis par un objet contient au moins une identification de l'objet.
- chaque objet comprend un compteur d'envois de messages de demande de déclenchement d'exécution apte à permettre de déterminer l'éventuelle caducité d'un événement de déclenchement d'exécution correspondant délivré par le moyen de séquencement.
- chaque objet possède un moyen de comparaison de la valeur contenue dans ledit compteur avec une valeur contenue dans un événement de déclenchement d'exécution reçu par ledit objet pour entrer dans ledit second sous-état donné. - le moyen de mémorisation est également apte à conserver la trace des actions effectuées par lesdits objets.
- le moyen de mémorisation est également apte à mémoriser une succession de messages de trace reçus par le moyen de séquencement et comprenant chacun:
- une identification de l'objet effectuant une transition ; et
- une identification de l'origine de l'événement qui a déclenché ladite transition.
- chaque message de trace comprend en outre une identification de l'état dudit objet avant cette transition.
- chaque message susceptible d'être reçu par le moyen de séquencement comprend une information de type (next/trace) permettant de distinguer un message de trace d'un message de demande d'activité.
- le moyen de mémorisation est apte à mémoriser les messages de trace avec les messages de demande d'activité selon une séquence correspondant à leur succession temporelle, tandis que le moyen de séquencement comprend en outre un curseur de traitement apte à parcourir, dans le sens de la séquence, les seuls messages de demande d'activité en vue de leur traitement.
- à chaque message est associée une information représentative de sa position dans le moyen de mémorisation.
- le moyen de séquencement est également apte à organiser de façon séquentielle le déroulement de premières actions causées par des événements extérieurs au système.
- il existe des objets aptes à exécuter une première action dite premier cycle en réponse à un événement extérieur au système, notamment provoqué par l'utilisateur, en ce que chacun de ces objets est apte à adresser au moyen de séquencement, une demande d'activité correspondante, tandis que le moyen de séquencement est apte à délivrer à l'objet effectuant une telle demande un message d'autorisation correspondance (Proceed) seulement lorsqu'il n'existe pas un autre premier cycle en cours d'exécution.
- chaque objet apte à effectuer un premier cycle est apte, lors de la fin de l'exécution de celui- ci, à adresser au moyen de séquencement un message de fin de premier cycle, de manière à ce que le moyen de séquencement puisse ensuite le cas échéant autoriser un autre premier cycle.
Enfin, un troisième objet de la présente invention concerne un système de traitement de données, comprenant des moyens serveurs et au moins un poste client, le ou au moins l'un des postes clients comportant un processeur apte à exécuter, en coopération avec les moyens serveurs, une application orientée objets comportant des objets répliqués comprenant chacun un objet client et un objet serveur destinés à être exécutés de façon identique respectivement dans le poste client et dans les moyens serveurs.
Plus précisément, le troisième objet de la présente invention vise à permettre, dans certaines conditions, le partage d'une ou plusieurs applications par plusieurs utilisateurs opérant sur des postes clients différents. On se place donc dans une architecture informatique client/serveur, où chaque client exécute une application dont certains objets peuvent être partagés par d'autres clients.
Dans une application orientée objets, on peut souhaiter que certains objets permanents adoptent un caractère partagé, et que certains autres objets permanents adoptent un caractère privé.
Un objet permanent partagé sera être utilisé conjointement par tous les clients. Chaque utilisateur partage avec les autres les valeurs caractéristiques de l'objet (état, rôles, etc.).
Lorsqu'un utilisateur modifie l'état d'un tel objet, cela sera ressenti chez tous les clients pour lesquels cet objet est exécuté. Les objets permanents privés seront en revanche propres à chaque client. Les clients utiliseront certes les mêmes objets au sens où ils utilisent la même application, mais les objets permanents privés seront décorrélés entre eux d'un client à l'autre.
Un objet principal de la présente invention est de pouvoir gérer le partage d'une ou plusieurs applications entre plusieurs clients, et plus particulièrement de pouvoir gérer des objets permanents partagés, de telle façon que la modification d'un tel objet par un utilisateur soit reportée chez tous les clients concernés, c'est à dire ceux pour lesquels cet objet doit être exécuté.
Il existe dans l'état de la technique plusieurs approches pour gérer le partage d'objets interclients. Ainsi une approche connue repose sur une réplication par « valeurs » des données partagées, notamment au moyen d'un Système de Gestion de Bases de Données sur un ou plusieurs serveurs communs. Un tel système assure la permanence des informations partagées et s'occupe des accès concurrents aux données.
Dans un tel contexte, une gestion du déterminisme n'est pas nécessaire. En effet, le comportement des objets (les actions qu'ils effectuent) a lieu chez les différents clients et en aucun cas sur le serveur. Ce dernier ne conservant que les différentes valeurs (état...) des objets partagés, il n'a pas besoin de reproduire le comportement des objets. A chaque modification d'un objet partagé chez un client, les valeurs de cet objet sont mises à jour dans la structure de données, et reproduites chez les clients qui utilisent également cet objet.
Si cette approche présente l'indéniable avantage de la simplicité, elle ne permet cependant pas la persistance des traitements. A partir du moment où aucun client ne travaille, les objets de l'application sont inertes puisqu'ils n'ont aucune vie sur le serveur. La persistance des traitements est surtout utile dans le cas d'applications de simulation où l'on ne voudrait pas nécessairement laisser le poste client allumé pour permettre la poursuite de la simulation.
La présente invention a pour objectif premier, dans le contexte précité, d'assurer une telle persistance de traitement. Pour atteindre cet objectif, il est nécessaire que les applications utilisées conjointement par les clients s'exécutent également sur le serveur, pour mettre en œuvre un mécanisme de réplication par « calcul ».
Comme on l'a vu plus haut, on veut permettre à des utilisateurs d'une application de partager certaines instances d'objets permanents partagés : les utilisateurs pourront interagir avec ces objets, mais chacun à leur tour. Quand un utilisateur modifiera un objet, étant donné que la même instance peut être partagée avec certains autres utilisateurs, ces derniers devront être notifiés de cette modification.
Cependant, dans certaines situations, des utilisateurs qui partagent des mêmes instances n'auront pas forcément tous réellement ces instances sur leur poste.
Selon la présente invention, toute modification d'un objet permanent partagé due à un message provenant d'un objet transitoire ou d'un objet permanent privé est aussi effectuée sur un serveur, par la réplication de la transition qui en est à l'origine (les actions effectuées par l'objet permanent partagé sont donc exécutées à la fois chez le client qui a l'accès à cet objet, et sur le serveur). Ces modifications sont ensuite reportées du serveur chez chacun des clients qui possède réellement cet objet. Ceci constitue le premier aspect du système, à savoir la réplication par « valeur ».
Si maintenant l'une des actions de l'objet permanent partagé provoque une transition d'un autre objet permanent partagé, celle-ci n'est pas répliquée du client (qui a l'accès à l'objet) sur le serveur. Elle est directement « calculée » par le serveur. Bien sûr, la modification de ce second objet permanent partagé est aussi reportée chez chacun des clients qui le possède réellement. Ceci constitue le deuxième aspect de la présente invention, à savoir la réplication par « calcul ». On comprend qu'un tel type de réplication n'est possible que si l'application partagée s'exécute également sur le serveur, en accord avec un modèle d'exécution particulier.
Ainsi, la présente invention propose un mécanisme de « réplication mixte » :
Par valeur : au sens où les transitions d'objets permanents partagés sont reproduites quand elles ont été causées par des objets purement locaux dont le serveur n'a pas la visibilité (transitoires et permanents privés) ;
Par calcul : au sens où les transitions d'objets permanents partagés sont déduites par le serveur quand elles ont été causées par un autre objet permanent partagé (dont le serveur a alors la visibilité).
Plus précisément, la présente invention propose un système de traitement de données, comprenant des moyens serveurs et au moins un poste client, le ou au moins l'un des postes clients comportant un processeur apte à exécuter, en coopération avec les moyens serveurs, une application orientée objets comportant des objets répliqués comprenant chacun un objet client et un objet serveur destinés à être exécutés de façon identique respectivement dans le poste client et dans les moyens serveurs, système caractérisé en ce que :
- l'application comprend également des objets non répliqués pouvant être exécutés dans le poste client seulement,
- en ce que l'exécution d'un objet non répliqué engendrant un message d'exécution de l'objet client d'un objet répliqué, engendre également vers lesdits moyens serveurs un message d'exécution de l'objet serveur du même objet répliqué,
- en ce que l'exécution de l'objet client d'un premier objet répliqué, engendrant un message d'exécution de l'objet client d'un second objet répliqué, n'engendre aucun message d'exécution vers lesdits moyens serveurs, tandis que dans ces derniers, l'exécution de l'objet serveur du premier objet répliqué engendre un message d'exécution de l'objet serveur du second objet répliqué.
De façon préférée, au moins certains des objets répliqués sont des objets partagés entre ledit poste client et au moins un autre poste client, et en ce que le résultat de l'exécution de tout objet serveur d'un objet partagé est reproduit dans chacun desdits autres postes clients. Avantageusement, ledit message d'exécution de l'objet serveur du même objet répliqué comprend :
- un identificateur de l'objet serveur ; et
- une information relative à l'état de l'objet partagé après sa transition.
D'autres aspects, buts et avantages de la présente invention apparaîtront mieux à la lecture de la description détaillée suivante d'une forme de réalisation préférée de celle-ci, donnée à titre d'exemple non limitatif et faite en référence aux dessins annexés, sur lesquels la figure 1 schématise le comportement séquentiel d'une pluralité d'objets, selon un quatrième aspect de la présente invention, la figure 2 illustre la notation normalisée « UML », la figure 3 illustre un exemple simplifié de diagramme de classe, la figure 4 illustre le diagramme d'état-transition pour l'exemple précité, la figure 5 représente un objet simplifié comportant une méthode, la figure 6 illustre par un exemple simplifié une équivalence entre attribut d'une classe et lien entre deux classes, la figure 7 illustre l'équivalence entre une action sur transition et un état intermédiaire à transition sortante automatique, la figure 8 illustre l'ajout d'un pseudo-état à un diagramme d'état-transition standard, la figure 9 illustre un exemple simplifié d'un objet possédant deux types d'actions, la figure 10 illustre un exemple enrichi de l'exemple simplifié de la figure 3, la figure 11 illustre le comportement d'un objet de la figure 10, la figure 12 illustre le principe de décomposition des états d'un objet, la figure 13 donne un exemple d'un objet auquel est appliqué le principe illustré sur la figure
12, la figure 14 illustre l'objet après transformation selon ce principe, la figure 15 illustre la structure d'un message émis par l'objet, la figure 16 illustre le comportement de base d'un séquenceur en réponse à un tel message, la figure 17 illustre la notion de cycle utilisée selon l'invention, la figure 18 illustre le comportement d'objets sous contrôle du séquenceur pour certains types de cycles, la figure 19 illustre par un diagramme d'état-transition le comportement du séquenceur avec le contrôle illustré sur la figure 18, la figure 20 reprend la figure 14 avec un enrichissement, la figure 21 illustre le même enrichissement dans le cas où un objet possède un certain type d'actions, la figure 22 illustre une succession de messages mémorisés par le séquenceur, la figure 23 illustre le diagramme d'état-transition du séquenceur avec une fonction de gestion d'historique, la figure 24 illustre une exploitation additionnelle par le séquenceur des messages de la figure 22, la figure 25 illustre par un diagramme d'état-transition le comportement du séquenceur modifié en conséquence, la figure 26 illustre le diagramme d'état-transition complet du séquenceur, la figure 27 illustre les diagrammes d'état-transition initiaux de six objets dans un exemple de mise en œuvre de l'invention, la figure 28 indique les nouveaux diagrammes d'état-transition des objets selon l'aspect de l'invention illustré jusqu'ici, la figure 29 illustre le diagramme de séquence de certains événements et actions dans une certaine phase pour ce même exemple, la figure 30 illustre un extrait de la liste de messages correspondante, la figure 31 illustre le diagramme de séquence dans une autre phase, la figure 32 illustre un extrait correspondant de la liste de messages, la figure 33 illustre le diagramme de séquence dans une troisième phase, la figure 34 illustre un extrait correspondant de la liste de messages, la figure 35 illustre le diagramme de séquence d'un autre type d'action géré par le séquenceur, la figure 36 illustre un exemple d'objets et de leurs liens, la figure 37 illustre une structure arborescente d'objets et de liens, la figure 38 illustre de façon plus détaillée une telle structure arborescente, la figure 39 illustre un chemin entre objets, la figure 40 illustre une composition particulière de liens dans un chemin, la figure 41 illustre le principe de regroupement de certains objets d'une structure arborescente, la figure 42 illustre l'application d'un tel regroupement à des zones de visualisation associées à des objets, la figure 43 illustre des liens en relation avec la proximité entre zones de visualisation, la figure 44 illustre des regroupements d'objets selon le même principe, avec une granularité croissante, la figure 45 illustre deux possibilités de transformations de liens, la figure 46 illustre par un diagramme UML simplifié deux types d'objets, à savoir objet proprement-dit ou élément de collection, les figures 47 et 48 illustrent une première phase d'un procédé de connexion entre objets, la figure 49 illustre sous une autre forme un regroupement d'objets, la figure 50 illustre un certain nombre d'actions dans une structure arborescente d'objets en liaison avec des objets d'affichage regroupés sur un objet constituant une zone de visualisation, la figure 51 illustre le diagramme de séquence correspondant, les figures 52 à 55 illustrent une application à des liens de composition changeants, la figure 56 illustre une liste de messages de séquenceur dans le contexte des figures 52 à 55, la figure 57 illustre une transition d'objet dans le cadre d'un perfectionnement, la figure 58 illustre le principe d'une connexion anticipative entre objets, la figure 59 illustre une telle connexion anticipative sous la forme d'un diagramme UML, la figure 60 illustre le diagramme de séquence correspondant, les figures 61 et 62 illustrent deux modes de connexion anticipative d'objets, en fonction du type d'objet, la figure 63 illustre l'architecture de base d'un serveur de données partagées et de postes clients, la figure 64 illustre la manipulation d'objets partagés par deux utilisateurs de postes clients, la figure 65 illustre un principe de réplication mixte selon un sixième aspect de l'invention, la figure 66 illustre le même principe, appliqué au cas où les objets partagés sont gérés par deux serveurs, la figure 67 illustre les diagrammes d'état-transition pour un exemple de quatre objets, dont trois sont de types différents, la figure 68 illustre le comportement de ces quatre objets lors d'une transition causée par l'utilisateur sur l'un des objets, la figure 69 illustre le comportement associé au niveau de deux listes de messages, respectivement du côté d'un poste client et du côté d'un serveur, la figure 70 illustre une codification d'objets utilisée sur la figure 71, la figure 71 illustre la propagation d'une transition à partir d'un poste client vers un serveur et vers d'autres postes clients, la figure 72 illustre le même principe de propagation dans le cas où il existe deux serveurs.
Chapitre 1 - Modèle d'exécution déterministe (Figures 1 à 35)
On va présenter une solution paticulière de déterminisme s'appuyant sur l'arbitrage des actions effectuées par les objets. Pour ce faire, les applications se voient dotées d'un objet particulier, constituant un Séquenceur. La fonctionnalité première du Séquenceur est de réussir à garantir le déterminisme tout en donnant un effet de parallélisme, nous parlerons de quasi-parallélisme. En effet, le Séquenceur permet de donner à chacun des objets à tour de rôle une partie des ressources correspondant à l'envoi d'un message (donc la réalisation d'une action).
Cet objectif est schématisé sur la figure 1 des dessins, où l'on observe que des actions indépendantes de quatre objets A, B, C et D sont organisées dans un ordre déterminé, selon un processus de déroulement unique, allouant tour à tour des ressources à chacun de ces objets.
Section 1 - Cadre
Nous nous référerons à la notion d'objet du jargon courant de l'informatique orientée-objet - conformément, par exemple, à l'ouvrage « The Unified Modeling Language (UML) Référence Manual », Rumbaugh, Booch et Jacobson, Addisson Wesley 1999.
Les applications que nous manipulons ici sont composées d'objets qui interagissent. Ces objets, et leurs relations, peuvent être définis à l'aide d'un diagramme de classe UML, dont un exemple est donné à la figure 2.
On rappellera ici que la notion de « Multiplicité » (par exemple le chiffre 3 associé à l'objet D indique le nombre d'objets de la classe qui peuvent être créés en cours d'exécution, et que la notion de « Rôle » (par exemple « theC » dans le lien entre B et D) indique le nom sous lequel un objet connaît un autre objet ; ici l'objet de la classe B connaît l'objet de la classe C sous le nom theC. C'est grâce au nom theC, que l'objet de B peut communiquer avec l'objet de C. A chaque objet défini (via sa classe) dans un diagramme de classe, on peut associer un comportement au moyen d'un diagramme d'état-transition. Un tel diagramme décrit le comportement des objets d'une classe donnée sous la forme d'une machine à état. Ainsi, à un instant donné, un objet est dans un état précis. Les objets changent d'état selon des transitions qui peuvent (ou non) être provoquées par des événements. Pour prendre un exemple très simplifié, on peut modéliser un interrupteur (« Switch ») et une lampe (« Lamp »), comme illustré sur la figure 3 des dessins.
Selon le modèle illustré sur la figure 4, un objet Switch, qui se trouve dans son état initial « Idle », peut recevoir un événement « TurnSwitch » qui déclenche une transition de l'état « Idle » vers le même état, lors de laquelle un message « TurnLamp » est envoyée à l'objet « myLamp » (de classe « Lamp »). Ce message « TurnLamp » devient, pour la lampe qui la reçoit, un événement déclenchant une transition de « Off » à « On », ou vice- versa, selon l'état dans lequel elle se trouve.
Le fait de pouvoir envoyer un message « TurnLamp » à un objet de la classe « Lamp » implique que cette classe expose la méthode correspondante. L'envoi du message revient en effet à appeler la méthode correspondante. (Noter que les messages peuvent avoir des arguments comme les méthodes). La représentation de la classe « Lamp » pourvue de la méthode TurnLamp est illustrée sur la figure 5.
Notons aussi que, dans la suite de la présente description, nous ne traitons pas les attributs, car nous les assimilons à des objets liés par des relations de compositions (c'est-à-dire des sous- objets), ce qui permet de les inclure dans le cas général du traitement des objets. (Les attributs se distinguent des objets en général, par le fait qu'ils n'ont pas de liens avec d'autres objets ; ceci ne contredit pas la généralisation ici faite). Pour mémoire, la figure 6 illustre l'équivalence entre une classe « Classe 1 » dotée d'un attribut « Attributel (de classe Classe2) », et le lien entre les deux classes « Classel » et « Classe2 ». Enfin, dans la suite de la présente description, nous ne traitons pas les cas d'actions spécifiées sur une transition, car celles-ci peuvent être transformées en une forme équivalente, dans laquelle les actions sont spécifiées dans un état intermédiaire qui a pour seule transition sortante une transition automatique. Pour la classe Switch de l'exemple précédent, une telle équivalence est illustrée sur la figure 7. Dans la suite de la description, nous considérons les diagrammes d'état-transition de la forme illustrée sur la figure 8. Le point noir désigne un « Pseudo Etat », qui symbolise l'état initial, c'est à dire l'état où se trouve l'objet juste après sa création. Un « Evénement » (ici « évènementl » pour la transition entre EtatO et Etatl) déclenche la transition à laquelle il est associé dès que l'objet le reçoit. Si aucun événement n'est associé à une transition, celle-ci a lieu dès que l'objet a terminé d'exécuter ses actions (elle est alors appelée « tansition automatique »). Enfin les « Actions » (ici par exemple « Entry/theC.evt » sont les tâches que l'objet peut effectuer dans un état donné.
Les transitions sont vues comme instantanées alors que les états ont généralement une durée. A chaque état E d'un objet correspond ainsi une partie de son comportement. Cette partie est décrite par un ensemble d'actions effectuées par l'objet dans l'état E. Ces actions permettent de déclencher des transitions d'autres objets, par l'émission de l'événement associé. Dans l'exemple ci-dessus, B déclenche la transition associé à l'événement « evt » chez C (identifié par le rôle « theC »). Au sein d'un état, les actions peuvent être de deux types :
• On Entry :
Ce sont les actions que l'objet effectue en entrant dans un état. Cette séquence d'actions ne peut en aucun cas être interrompue, elle a un caractère atomique.
• Activity : '
Ce sont les actions effectuées par l'objet une fois qu'il est entré dans son nouvel état (donc une fois la séquence atomique des actions On Entry terminée). Cela constitue un ensemble d'actions, chaque action étant atomique. La réception d'un événement associé à une transition peut par contre interrompre cette partie (entre deux actions atomiques). Un état peut n'avoir aucune action On Entry comme il peut en avoir plusieurs, il en est de même pour les actions Activity.
Un état sera donc représenté de la façon illustrée à titre d'exemple sur la figure 9. Notons que « Do » spécifie ici les actions de type--4cttvïty).
On va illustrer les actions Activity d'un état par prolongement de l'exemple de l'interrupteur et de la lampe présenté précédemment, illustré à nouveau sur la figure 10. Dans cet exemple, et comme illustré sur la figure 11, la lampe n'a aucune action de type On Entry dans son état On. Dans le cadre de la partie Activity (messages « Do/ ») de cet état, la lampe envoie par exemple quatre messages d'incrémentation à un compteur (« Counter »), mais cette activité (composée de ces 4 messages) peut être interrompue en cas de réception de message « TurnLamp ».
Plus généralement, lorsqu'il entre dans un nouvel état, un objet effectue ses actions On Entry, puis une fois celles-ci terminées, enchaînent sur les actions Activity (notées « Do / ... »). Cependant, du point de vue de l'utilisateur, les objets effectuent les actions en parallèle les uns avec les autres (puisque la série d'actions Activity peut être interrompue). Le but du mécanisme de séquencement est de simuler ce parallélisme en donnant la main aux objets qui effectuent ainsi leurs actions Activity chacun à leur tour.
Pour satisfaire à ces exigences, les modèles doivent être aménagés de façons particulières comme nous allons le voir dans la section suivante, ceci de manière transparente pour le modélisateur.
Section 2 - Aménagement des modèles
Mise sous forme canonique des objets
Pour simuler le parallélisme, le mécanisme de l'invention consiste à ordonnancer les actions Activity des objets à l'aide d'une entité particulière, à savoir un Séquenceur. Pour parvenir à cet ordonnancement, les états sont transformés en une forme que l'on appelle la « forme canonique », comme illustré en détail sur la figure 12, forme canonique dans laquelle ces états sont décomposés de telle sorte qu'à chaque action Activity corresponde un état. Le Séquenceur est alors chargé de piloter les transitions entre les états correspondant à des actions Activity. Cependant, la transformation en forme canonique doit respecter la caractère atomique des actions On Entry. Au global, la transformation en forme canonique doit donc respecter deux contraintes :
• préserver le caractère atomique des actions On Entry : Pour ce faire, les actions On Entry sont regroupées dans un état « Sentry », comme illustré sur la figure 11. Pour que ces actions ne soient pas interrompues, la seule transition sortante de cet état est une transition automatique. Une transition automatique est une transition à laquelle n'est associée aucun événement. Une telle transition n'a donc lieu qu'une fois toutes les actions de l'état Sentry effectuées.
Ainsi, lorsque la transition entrante est déclenchée (par un autre objet par exemple), l'objet entre dans l'état Sentry. Dans cet état, l'objet effectue toutes les actions On Entry de l'état S. Quand toutes les actions sont effectuées, et seulement quand elles le sont, l'objet entre dans l'état Sactivity. Comme dans l'exemple, l'objet n'effectuait pas d'actions Activity dans l'état S, il se place dans le sous-état Swait où il attend de recevoir un événement lui permettant de rentrer dans l'état T ou dans l'état U.
On notera ici que, dans la suite, afin d'apporter plus de clarté à la lecture, nous séparerons les actions Entry dans des sous-états différents.
• permettre d'établir un quasi parallélisme dans l'exécution des activités des objets. Plutôt que d'avoir un « thread » par objet, les activités de tous les objets peuvent être traitées dans un seul thread : celui du Séquenceur. Le rôle de ce Séquenceur sera donc de régir le passage d'un sous état d'activité à un autre par l'émission de l'événement next, pour tous les objets.
La mise sous forme canonique correspondante est illustrée sur la figure 12.
Comme précédemment, l'objet entre dans l'état Sentry et y effectue toute les actions On Entry prévues dans l'état S. Puis, l'objet entre automatiquement dans l'état Swait. Nous sommes ici dans le cas où des actions Activity étaient prévues dans l'état S. Chacune de ces actions est traitée dans un état différent. Nous les appellerons des sous états d'activité. La transition d'un sous état d'activité à un autre se fait à la réception de l'événement next. C'est le Séquenceur qui émet cet événement pour simuler le parallélisme entre les objets.
A tout moment, l'objet peut recevoir un événement associé à une des transitions sortantes. A ce moment là, l'objet sort de l'état Sactivity (et donc du sous-état d'activité dans lequel il se trouve) pour entrer soit dans T soit dans U.
Rôle de Swait
Les transitions sortantes de l'état S partent, dans la forme canonique, de l'état Sactivity. En effet, si elles partaient également de Sentry, les actions On Entry pourraient être interrompue, contre-disant leur caractère atomique. C'est pourquoi une fois les actions On Entry terminées, l'objet passe automatiquement dans le sous-état Swait de Sactivity. Dans cet état, l'objet attend de recevoir le premier next du Séquenceur, mais peut également passer à un autre état si un objet déclenche une des transitions sortantes.
On observera ici que la forme canonique décrite ci-dessus en référence à la figure 12 permet de représenter les diagrammes d'états transitions de Harel (états hiérarchiques et états orthogonaux) ; les transformations de ces cas étant évidentes pour l'homme du métier, elles ne seront pas décrites plus avant. Notion d'historique (trace)
Afin de pouvoir suivre ce qui se passe dans le système informatique, on peut disposer d'un historique qui relève toutes les actions effectuées par les objets et leur associe un temps logique.
Avant d'effectuer une action, un objet en informe le séquenceur par un message approprié, et le séquenceur écrit dans la trace les informations suivantes :
• Quel objet effectue la transition
• Quel était l'état de l'objet avant la transition (on l'appellera état précédent), au moyen d'un identifiant.
• Quelle est la « cause » de cette transition (soit l'utilisateur w-ïer le cas échéant, soit l'objet qui a causé la transition) On notera que les conditions spécifiées sur les transitions (voir UML - Unified Modeling Language, déjà mentionné) ou dans les états, peuvent également être notées dans la trace. Cet historique va jouer un rôle dans le procédé de virtualisation décrit dans le chapitre suivant. Considérons l'exemple d'un objet 01 illustré sur la figure 13. La mise sous forme canonique va donner le résultat illustré sur la figure 14 ; l'appel à put du Séquenceur, illustrée sur la figure 14, correspond à une écriture dans l'historique avec les éléments que nous avons mentionnés plus haut.
Supposons maintenant que l'utilisateur crée cet objet 01. Celui-ci va donc entrer dans l'état Sentry, et effectuer son action Entry 1. Au passage, la trace va être renseignée de la façon illustrée sur la figure 15.
Dans l'appel à méthode « Put(01, initial, user) », « 01 » désigne l'objet qui effectue la transition, « initial » désigne l'état précédent de l'objet, tandis que « user » désigne ici l'objet (en l'espèce une action de l'utilisateur) qui est à l'origine de la transition (que l'on appellera la « cause »). « 54 » désigne ici le temps logique auquel le message est reçu par le séquenceur. Le curseur d'écriture indique où doit se faire la prochaine entrée dans la trace. Le Séquenceur doit donc être capable de réagir à l'événement put, en écrivant les différentes informations reçues dans l'historique. Le comportement du séquenceur, en ce qui concerne la gestion de l'historique, peut alors être représenté de la façon illustrée sur la figure 16, où H représente Historique.
Exclusion mutuelle des premiers cycles
- Notion de cycle
Lorsqu'un objet déclenche un événement chez un autre (en lui envoyant un message ou par une notification de changement d'état si l'objet y est abonné, etc), il provoque un changement d'état de ce dernier. Dans son nouvel état, celui-ci peut lui-même faire changer d'état à un troisième objet, etc... Ceci jusqu'à ce que tous les objets touchés aient terminés leurs actions On Entry (les actions Activity étant du ressort du séquenceur comme nous le verrons par la suite). La main est alors rendue, par retour d'appel de méthode, à l'objet qui a déclenché la première transition : on parle alors de cycle. Par définition, un cycle est donc atomique au sens où il ne peut pas être interrompu.
Un cycle débute donc quand un objet O en amène un autre à effectuer une transition, et se termine quand O reprend la main.
Ainsi la figure 17 illustre un exemple où deux cycles Cycle 1 et Cycle2 se succèdent, le retour à partir de l'objet ObjetC se produisant dès la réception de « EntryBl » car, si ObjetB change bien d'état, il n'a pas d'action à effectuer. Le cycle Cycle2 est similaire, avec parcours des objets ObjetA, ObjetC et ObjetD et retour à partir d'ObjetD qui n'a pas d'action à effectuer.
- Notion de premier cycle Lorsqu'on considère l'ensemble des cycles d'une application, on se rend compte qu'il existe des cycles tout particuliers : ceux qui sont initiés par l'utilisateur. On parlera dans ce cas là de premiers cycles.
Ces premiers cycles sont importants car leur déclenchement dépend de l'utilisateur. Leur déroulement est de ce fait parallèle et ils peuvent entrer en conflit les uns avec les autres si jamais ils passent par les mêmes objets.
Pour gérer ce genre de problème, c'est-à-dire éviter d'avoir à effectuer des retours arrière (ou
« Rollback » selon la terminologie anglosaxonne), un mécanisme d'exclusion mutuelle de ces premiers cycles est nécessaire. Comme nous allons le voir dans la section suivante, une solution possible est de les mettre en séquence : ils sont alors traités les uns à la suite des autres en fonction de l'ordre selon lequel ils ont été déclenchés par l'utilisateur.
- Mécanisme mis en œuvre
Dans cette approche, chaque objet qui effectue une transition due à l'utilisateur prévient le
Séquenceur à l'aide de l'événement BOFC (BeginOfFirstCycle : début de premier cycle). Une fois le premier cycle terminé (on est revenu au premier objet par retour d'appel de méthode), l'objet prévient le Séquenceur que le premier cycle est terminé à l'aide de l'événement EOFC
(EndOfFirstCycle : fin de premier cycle).
A la réception d'un message BOFC, un compteur de premier cycle FCC (First Cycle Counter), intégré dans le Séquenceur, est incrémenté. Si, après incrémentation, ce compteur vaut 1, alors le Séquenceur dit à l'objet que le premier cycle peut commencer en envoyant le message proceed. Quand le Séquenceur reçoit EOFC, il décrémente son compteur de premier cycle.
Lorsque le Séquenceur reçoit un BOFC alors qu'un premier cycle est déjà en cours, il attend que le cycle en cours (ainsi que tout ceux qui sont en attente) soit terminé, avant de déclencher le nouveau premier cycle.
Un exemple de mise en œuvre est illustré sur le diagramme de la figure 18.
Le comportement du Séquenceur relativement aux BOFC et EOFC peut être représenté à l'aide du diagramme d'état-transition illustré quant à lui sur la figure 19.
Obtention du quasi parallélisme
Après avoir effectué leurs actions On Entry, les objets peuvent effectuer leurs actions Activity. Par définition ces actions ont lieu en parallèle. Le but de cette partie est de décrire le mécanisme de quasi parallélisme permettant de simuler le parallélisme des activités dans une approche purement séquentielle.
- Extension de l'historique
Comme nous l'avons vu, la décomposition en forme canonique dégage des sous-états d'activités. Le passage d'un de ces sous états à un autre se fait par l'événement next.
Ceci permet de piloter les différentes actions Activity de tous les objets qui effectuent leur activité. Ce pilotage est assuré par le Séquenceur, chargé d'émettre l'événement next aux objets en ayant fait la demande.
Pour ce faire, un objet va dire au séquenceur qu'il a une activité à effectuer juste avant la dernière action de sa partie On Entry de l'état courant, en l'écrivant dans l'historique. (Au cas où il n'a qu'une seule action On Entry dans l'état courant, l'objet va informer le séquenceur avant d'effectuer l'action). Ceci est effectué via l'écriture dans l'historique à l'aide de put.
L'ensemble d'informations stockées dans l'historique à chaque put doit donc être étendu de la façon suivante : en plus des informations déjà présentées, un put doit également contenir un type et un index d'obsolescence.
Le type indique s'il s'agit juste d'une simple écriture dans l'historique (type = trace), ou s'il s'agit d'une demande pour effectuer des activités (type = next). 'index d'obsolescence (renseigné uniquement dans le cas type = next) permet de détecter si un next reçu est caduque suite à un changement d'état pendant des activités.
Si nous reprenons notre exemple de mise sous forme canonique de la figure 14, nous obtenons maintenant ce qui est illustré sur la figure 20, et dans le cas où l'objet doit effectuer des actions
Activity, ce qui est illustré sur la figure 21.
Supposons qu'un utilisateur crée cet objet (dans le cas des actions Activity). Les informations figurant dans la trace pour cet objet vont donc être par exemple celles illustrées sur la figure
22.
Le diagramme d'état-transition présentant le comportement du Séquenceur pour la gestion de l'historique doit alors être étendu comme illustré sur la figure 23.
- Rôle du Séquenceur
Le rôle du Séquenceur est de régir les différentes activités des objets en simulant une exécution en parallèle. Pour ce faire, le Séquenceur exploite les informations de l'historique en suivant les différentes entrées, et en traitant les put dont type = next. Ceci est matérialisé par un autre curseur, le curseur de traitement, comme illustré sur la figure 24. Ce curseur indique donc, à chaque instant, où en est l'exécution de l'application.
A chaque fois que le curseur de traitement passe sur un put de type next, le Séquenceur envoie next à l'objet spécifié dans le put.
Le traitement des activités par le Séquenceur peut donc être modélisé par le diagramme d'état- transition illustré sur la figure 25.
Ainsi le diagramme d'état-transition complet du Séquenceur sera donc tel qu'illustré sur la figure 26.
Exemple
Considérons 6 objets A, B, C, D, E, et F. Ces objets ont les diagrammes d'état-transition qui sont illustrés sur la figure 27.
A, B, et C sont mis sous forme canonique de la façon illustrée sur la figure 28.
Supposons qu'un utilisateur déclenche le msgO de l'objet A. A entre donc dans l'état SI, il en découle un premier cycle, puis le Séquenceur arbitre les différentes activités. Ceci va être présenté dans le diagramme de séquence illustré sur la figure 29.
Au moment où le premier cycle se termine, l'historique porte les informations illustrées sur la figure 30.
Le séquenceur va commencer à traiter les activités à partir de la position du curseur du
Séquenceur. Pour chaque put de type next, il va envoyer à l'objet concerné le message next pour que celui-ci puisse continuer son activité. Si on poursuit l'exemple précédent jusqu'à son terme, on obtient le diagramme illustré sur la figure 31.
Lorsque le traitement du premier put de type next est terminé, le curseur de traitement passe au put dont type = next suivant, comme illustré sur la figure 32, et le traitement correspondant est illustré sur la figure 33.
Au final, la trace regroupe les informations illustrées sur la figure 34.
- Obsolescence des « next »
Les activités d'un objet peuvent être interrompues par un changement d'état. On dira que le Séquenceur envoie un événement next obsolète si l'objet a fait au moins une transition depuis qu'il a émis le put de type next correspondant. Ceci peut arriver lorsque les activités propres à un état sont interrompues au sens où nous l'avons vu précédemment.
Pour éviter ce problème, chaque objet dispose d'un compteur des émissions de put de type next (initialisé à zéro en début d'exécution). A chaque fois qu'un objet émet un put (de type trace ou next), il incrémenté auparavant ce compteur et, dans le cas d'un put de type next, passe la valeur du compteur dans l'historique. Accessoirement, chaque objet possède également un drapeau PendingNext permettant de savoir s'il est en attente ou non d'un next. A l'envoi d'unput de type next, ce drapeau passe à 1 (il est remis à 0 à la réception du next). Par la suite, quand l'objet reçoit un next et il reçoit également la valeur qu'il avait passé au moment de l'envoi du put de type next. L'objet compare alors cette valeur qu'il reçoit avec la valeur courante de son compteur. Si les deux valeurs sont égales, c'est que le next reçu doit être traité, sinon c'est qu'il est obsolète et est donc ignoré. Un exemple correspondant est illustré sur la figure 35.
Chapitre 2 -Mécanisme de chargement et déchargement progressifs (Figures 36 à 62)
Ce chapitre contribue au chapitre suivant, et vient compléter les techniques chapitre précédent. On se place ici dans le cadre d'une architecture informatique client/serveur, où un utilisateur exécute une application depuis un poste client « léger », dans le sens où les objets de l'application sont instanciés depuis un serveur. En fait, nous distinguons deux types d'objets : les objets transitoires, et les objets permanents. Les objets transitoires sont propres à chaque exécution d'un document ; ils ont une durée de vie qui ne peut en aucun cas excéder celle de l'exécution de l'application. L'état et les valeurs caractéristiques des objets permanents sont, au contraire, sauvegardés (sachant que l'on est ici dans un cas où cette sauvegarde est effectuée sur un serveur distant) et survivent d'une exécution à l'autre. De par la structure induite par le diagramme de classe, un certain nombre d'objets « existent » d'emblée au lancement de l'application : le modèle (au moyen duquel le document a été créé) indique que, dès le début de l'exécution, ces objets existent déjà et sont à disposition les uns des autres (en fonction des associations définies dans le modèle). Le principe de base de ce chapitre est cependant de ne pas créer ces objets dès le début, mais de manière « paresseuse » (au fur et à mesure de leur besoin), et ceci de manière transparente pour l'utilisateur. Le concepteur n'a en effet pas besoin de prévoir ces aspects lors de la modélisation de l'application à développer ; ils sont automatiquement gérés par le système. L'utilisateur, quant à lui, n'a pas à se soucier des objets qui transitent entre son poste client et le serveur, tout se passe pour lui comme s'il possédait l'ensemble des objets de l'application. Ainsi, certains objets sont en fait absents quand, selon le modèle, ils devraient exister ; on dit qu'ils existent virtuellement. Le comportement de l'application n'en est pas gêné car ces objets sont créés (réalisés) « just in time » en cas de besoin. Ils sont même réalisés par anticipation (« ahead of time ») afin d'assurer la fluidité de l'exécution. Même en cours d'exécution, selon le modèle de nouveaux objets apparaissent virtuellement et, toujours, ils ne sont réalisés qu'au fur et à mesure de leurs besoins réels.
De ce fait, le téléchargement des objets se fait progressivement. Cela permet de conserver des temps de chargement raisonnables dans des conditions de bande passante faible et irrégulière. Afin de réduire la consommation de ressources d'ordinateur, les objets qui ne sont pas (ou plus) utilisés peuvent cesser d'être réellement existants (ils peuvent être virtualisés). Ils sont supprimés, de manière transparente, après un certain délai de latence (pour éviter des suppressions/créations intempestives), sachant qu'ils pourront se réaliser à nouveau quand nécessaire.
Section 1 - Structure d'une application
Liens
La structure d'une application est basée sur le diagramme des classes et exploite les associations entre les classes. En cours d'exécution, la structure repose donc sur les liens entre les objets. Un lien est une instance d'association orientée. Parmi les différentes associations on distingue la composition (relation contenant-contenu) qui implique qu'un objet ne peut être contenu que par un seul objet (l'objet contenant) à un instant donné. Les associations de composition sont notées graphiquement sous la forme de losanges pleins. Par exemple, dans la figure 36, l'objet A contient les objets B, C et D.
Une application contient donc un ensemble d'objets, dotés de comportement. Ces comportements (ou behaviors) sont définis à l'aide de machines à états telles que nous les avons vues à la section 1 du chapitre précédent.
Les objets forment une structure arborescente de liens de composition, au sein de laquelle tout objet est nécessairement composant d'un autre objet. Tout objet a donc un « chemin » qui l'identifie depuis la racine de l'application, l'objet Root, comme illustré sur la figure 37.
Les techniques décrites ici peuvent s'appliquer à des structures dynamiques, c'est-à-dire dans lesquelles certains objets peuvent être créés et supprimés en cours d'exécution. Nous considérons que ces derniers sont regroupés au sein de ce que nous appelons une collection
(les procédés décrits ici pouvant tout aussi bien s'appliquer à n'importe quelle autre structure dynamique). La collection est représentée par un objet Collection qui est statique, et qui figure dans l'arborescence basée sur les liens de composition. Les sous objets de l'objet Collection représentent les éléments de la collection comme le montre la figure 38, et sont repérés par des indices.
Bien entendu, les objets peuvent aussi avoir entre eux d'autres liens que les liens de composition qui forment la structure de l'application. Ces liens sont les instanciations des différentes associations existant entre les classes des objets. C'est via ces liens que les objets peuvent communiquer, c'est-à-dire s'envoyer des messages.
Ces liens peuvent évoluer en cours d'exécution. En effet, une association relie deux classes.
Ceci sous-entend que l'instance d'une classe peut communiquer avec n'importe quelle instance de l'autre classe.
La communication entre un objet quelconque et un élément d'une collection (par exemple entre A et B[2] dans la figure précédente) se fera par l'intermédiaire de l'objet Collection correspondant, en précisant l'indice de l'élément voulu (ici 2).
Un lien entre deux objets est défini par un chemin menant de l'un à l'autre, au sein de la structure.
Un lien peut être construit en exploitant uniquement les liens de composition, nous les appellerons « liens de base ». La figure 39 en montre un exemple. Sur cette figure, le chemin menant de D à C est formé à partir des liens de composition D_B, B_A et A_C. Un tel chemin
(définissant un lien de base) est porté par l'objet au sein d'une variable structurée que nous appellerons « port ».
Mais un lien peut également exploiter des liens qui ont eux-mêmes été formés à partir de liens de composition, c'est ce que nous appellerons un « lien dérivé ». Nous en illustrons un exemple dans la figure 40.
Le chemin menant de D à E peut réutiliser le chemin établi entre D et C dans l'exemple précédent : D_C et CJE. Il n'est pas nécessaire de passer par B et par A, mais il est possible de déterminer le chemin correspondant qui n'exploite que les liens de composition. Ceci jouera un rôle majeur, comme nous le verrons dans la première partie de la section 2 du chapitre V, en ce qui concerne la réalisation des objets.
On peut donc définir un lien de façon récursive, comme étant soit :
• Un lien de base, c'est-à-dire n'exploitant que des liens de composition
• Un lien dérivé, c'est-à-dire exploitant un nombre fini de liens (pouvant être de base et/ou dérivés).
Objets d'affichage
Certains des objets d'une application sont des éléments d'affichage, tels qu'un bouton ou une zone de saisie par exemple. Les éléments d'affichage sont regroupés pour former différents écrans de l'interface homme machine d'une application, différentes pages d'un site Internet, ou différents champs de vision dans un environnement de réalité virtuelle en 3D par exemple. Ce regroupement des éléments d'affichage est réalisé à l'aide d'objets, créés spécialement, que nous appelons visuZone. Chaque groupe d'éléments d'affichage est lié à un objet visuZone. Ces groupes ne sont pas forcément disjoints. Ainsi la figure 41 illustre un groupe d'objets d'affichages D, F et H regroupés.
Regrouper de cette manière les objets d'affichage a le but suivant : en cours d'exécution, le chargement chez un client d'un objet d'affichage appartenant à une zone de visualisation, provoque le chargement de tous les autres objets d'affichage de la même zone. Selon la profondeur d'anticipation désirée, les objets (d'affichage ou non) reliés aux objets de la zone de visualisation peuvent également être chargés.
Un exemple intéressant d'utilisation desobjets visuZone peut être le déplacement d'un cadre sur une carte. Les objets visuZone permettent de gérer des concepts comme le voisinage géographique et le zoom.
• Voisinage géographique
On se place ici dans un contexte où l'application contient un nombre important de données, réparties de façon géographique sur un plan (par exemple la carte d'une ville). La navigation sur cette carte se fait au moyen d'un cadre de visualisation constitué par la surface de l'écran de l'utilisateur.
Le but de l'utilisation des objets visuZone est ici de faire en sorte que seuls les objets du cadre et ceux qui en sont géographiquement proches soient présents.
Pour réaliser cet objectif, il faut dans un premier temps morceler la zone en 2D à couvrir, et associer à chaque morceau un objet visuZone (c'est-à-dire relier tous les objets de ce morceau de plan à l'objet visuZone). Ceci est illustré sur la figure 42, où à chaque « morceau » du rectangle est associé un objet visuZone regroupant les objets, désignés par des points, qui y sont contenus.
Dans un second temps, il faut inclure la notion de proximité entre les zones de visualisation : il s'agit donc de relier les objets visuZone proches les unes des autres. On obtient ainsi un réseau maillé d'objets visuZone, comme illustré sur la figure 43, où les objets visuZone sont désignés par des cercles au droit de chaque « morceau », et où les liens entre de tels objets sont indiqués par des lignes droites.
Ainsi, le chargement d'un objet visuZone provoque (automatiquement), par anticipation, le chargement des objets d'affichage situés dans les zones voisines.
De cette manière, la profondeur d'anticipation et la taille des zones de visualisation sont les paramètres qui permettent déjouer sur la granularité du « maillage ».
• Zoom avant et arrière
Dans le type d'application que nous décrivons dans cet exemple, une fonctionnalité intéressante est également la possibilité d'effectuer des zooms avant et arrière en un point donné de la carte.
Cette fonction induit le concept de niveau de détail, donc de hiérarchie au sein des objets visuZone, un exemple d'une telle hiérarchie étant illustré sur la figure 44. L'objet visuZone supérieur correspond au niveau de détail moins élevé, alors que les objets visuZone situés au- dessous représentent un niveau de détail médian, et que les objets visuZone les plus bas représentent un niveau de détail plus élevé.
Chaque objet visuZone du niveau de détail le plus élevé est relié à tous les objets d'affichage de la zone de visualisation de granularité la plus fine.
L'objet visuZone du niveau de détail le moins élevé (objet supérieur) est relié à certains objets de toutes les parties du plan morcelé. Ceci constitue une vue globale de la carte où seuls les éléments les plus marquant apparaissent. Les objets visuZone du niveau de détail médian (objets intermédiaires) sont reliés à des objets supplémentaires de leur quart de plan respectif. Ces objets apportent plus de précision sur chaque quart de plan.
Enfin les objets visuZone du niveau de détail le plus élevé (objets inférieurs) sont reliés à tous les objets restant dans leur fraction de plan. A ce niveau, tous les objets sont chargés.
De même que pour la question de proximité, les objets visuZone correspondant aux différents niveaux de détail sont reliés entre eux dans un souci d'anticipation.
Une approche de zoom sans niveau de détail peut également être envisagée. Dans celle-ci, les objets visuZone inférieurs sont reliés à tous les objets de leur fraction de plan. Les objets visuZone intermédiaires ne sont reliés qu'aux objets inférieurs, etc...
Section 2 - Modalités de Réalisation et de Virtualisation des objets
Lors du lancement de l'application, seule la racine du document (objet Root) est réalisée. Elle constitue la racine de toute l'arborescence des objets présents dans le document. A partir de là, les autres objets sont « réalisés » au fur et à mesure, sur demande de la part d'un autre objet, ou par anticipation.
Ainsi, lorsqu'un objet doit envoyer un message à un autre objet non présent, la réalisation de ce dernier est effectuée au cours du processus d'envoi de message.
Ce processus est intercepté par une couche spéciale du système qui fait que les différents mécanismes mis en jeu dans ce chapitre (réalisation, virtualisation, anticipation) soient gérés de façon transparente pour le concepteur et l'utilisateur.
Dans toute application orientée objet, pour qu'un objet puisse envoyer un message à un autre objet, il faut qu'il existe entre eux un lien, au sens où nous l'avons défini précédemment. Ce lien est créé à partir du moment où l'objet émetteur connaît le chemin qui mène à l'objet destinataire au sein de la structure. Un tel lien n'a pas de caractère figé, il peut être « modifé » en cours d'exécution, en en modifiant le chemin.
Le rôle du chemin est de permettre, en parcourant la structure, de récupérer la référence de l'objet destinataire pour le contacter. L'obtention de cette référence est le but d'un mécanisme que nous appellerons procédé de connexion (défini ci-après) qui fait partie intégrante du processus d'envoi de message. Cette référence, une fois obtenue, est stockée par l'objet au sein de la variable structurée « port » qui contient déjà le chemin.
Ce procédé ne peut fonctionner que pour des chemins formés de liens de composition uniquement. En effet, ce n'est qu'en suivant les liens de composition que l'on peut créer les instances des objets (un objet ne peut être réalisé que par son parent). Atteindre un objet en suivant un chemin implique de pouvoir réaliser les objets de ce chemin qui ne sont que virtuellement présents, d'où la nécessité qu'un tel chemin repose sur les liens de composition. Pour cela, il est possible de ramener un lien quelconque au lien de base correspondant, c'est-à- dire à l'ensemble minimal de liens de composition qui le constituent.
Les deux cas possibles de transformation sont présentés sur la figure 45: dans les deux cas illustrés, la composition des liens de Oo à On, et de On à Om, peut se ramener au lien de base formé des liens de composition Oo_Oi, Oi_Oj, et Oj_Om.
Procédé de connexion (réalisation)
Supposons qu'un objet Oo veuille se connecter à un objet ON- Afin d'accéder à ON, Oo dispose d'un chemin path qui exploite la structure arborescente. Une valeur de ce chemin peut être stockée dans le port, mais cette valeur peut également être modifiée de façon programmatique en cours d'exécution, sachant qu'un port (lien de base) ne peut contenir que des liens de composition. Pour représenter un lien de base, un port comprend une valeur entière index positive et une suite d'objets (On)ne[i..N]. index indique à quel niveau de la hiérarchie, à partir de l'objet qui se connecte, se situe l'ancêtre commun Oj. La suite (On)nS[i,N] regroupe les objets qui mènent de Oi à ON, elle constitue le chemin « descendant » (vers ON), que nous noterons descendingPath.
Chaque On peut désigner soit un objet soit un élément de collection. Dans ce dernier cas, on notera On[p] où On est X objet collection qui regroupe tous les éléments de collection, et où p représente l'indice de l'élément au sein de la collection.
La structure UML correspondante est illustrée sur la figure 46.
La réalisation se faisant de parent à enfant (un objet ne peut être réalisé que par son unique parent au sens de la relation de composition), l'existence de O0 implique que tous les objets, jusqu'à l'ancêtre commun Oj, ont été réalisés au moins une fois (même s'ils ont pu être virtualisés depuis).
Le procédé de connexion réside en l'appel récursif d'une méthode connect portée par chaque objet. Cette méthode retourne la référence de l'objet auquel on désire se connecter. Elle prend comme argument le chemin (index,descendingPath) menant à l'objet auquel on veut se connecter et l'argument depth qui indique à quelle profondeur vont être effectuées les connexions, comme nous allons le voir dans la section 3 du chapitre V. Ce procédé est lancé en appelant la méthode symbolisée par :
Oo. connectβndex, descendingPath, depth) Une fois la référence de O récupérée, Oo envoie sa propre référence que ON stocke dans un attribut inverseRef. En effet, si ON est virtualisé, la référence que possède Oo n'a plus de sens. ON doit donc prévenir Oo qu'il est virtualisé en mettant à Null sa référence portée par Oo. Il peut le faire grâce à inverseRef. Oo sait alors qu'il devra se reconnecter à ON pour lui envoyer un message.
Si le parent d'un objet (qui désire se connecter) a été virtualisé, il est réalisé de nouveau au cours du procédé de connexion. Pour ce faire, chaque objet possède la référence de l'objet Root. Lorsqu'un objet détecte que son parent a été virtualisé (la référence de son parent est à Null), il passe à l'objet Root le chemin qui conduit de la racine à son parent. L'objet Root peut alors instancier le parent en s'y connectant avec le chemin qu'il a reçu. Une illustration de ce phénomène est donnée dans l'exemple montré à la figure 47.
Sur cette figure, supposons que A veuille envoyer un message à E en utilisant le lien défini par le chemin (3,myC_myE). A ne peut accéder à son parent D car ce dernier a été virtualisé (en gris sur la figure), A n'a donc plus la référence de D. Pour l'obtenir de nouveau, il lui faut passer par l'objet Root.
Maintenant en référence à la figure 48, A connaît son propre chemin depuis la racine (myB_myD_myA). Il peut donc inférer celui de son parent D : myB_myD. Ce chemin est passé à l'objet Root qui va alors procéder à l'instanciation des objets manquant jusqu'à D (ici B à l'étape 1 et D à l'étape 2). ). Une fois D instancié, sa référence est passée à A par retour de méthode. Le procédé de connexion peut alors se résumer comme suit :
• Parcours de l'arbre du modèle jusqu'à l'objet visé en passant par un ancêtre commun.
• Réalisation « au passage » des objets ayant été virtualisés, ou n'ayant pas encore été réalisés.
• Récupération de la référence de l'objet visé, qui est stockée dans la variable port.
• Envoi de la référence de l'objet qui se connecte à l'objet visé (inverseRef).
Prenons pour exemple le cas où, au lancement de l'application, l'objet Root envoie un message à l'objet visuZone qui regroupe les éléments d'affichage qui constituent la page d'accueil de l'application. On a le chemin illustré sur la figure 49, où l'objet Root est blanc, l'objet visuZone est noir et les objets d'affichage sont gris. A la réception de ce message, l'objet visuZone se connecte à ses éléments d'affichage, exactement selon le même procédé décrit ci-dessus. Ceci est détaillé dans la figure 50, et peut se traduire par le diagramme d'état-transition de la figure 51.
Cas de liens de composition non immuables
Optionnellement, en cours d'exécution, il se peut que des liens de composition soient modifiés. Le fait qu'un objet n'ait qu'un seul parent à un instant donné n'empêche pas d'avoir plusieurs parents à des instants différents.
Considérons l'arborescence illustrée sur la figure 52.
Sur cette figure, les traits pleins représentent les liens de composition et les traits pointillés représentent les liens d'associations simples. Afin d'obtenir la référence de J, F dispose d'un chemin (1, G_I_J). La valeur 1 indique qu'il faut remonter d'un cran dans la hiérarchie des ancêtres de F pour trouver l'ancêtre commun à F et I (en l'occurrence D). Le chemin G_I_J montre qu'il faut passer par G et I pour atteindre J. Si I est virtualisé, c'est à G de le réaliser de nouveau, de même entre J et I.
Supposons maintenant que le lien de composition entre G et I soit rompu, et remplacé par un lien entre H et I, comme le montre la figure 53.
Si J est virtualisé, F perd la référence qu'il avait préalablement acquise. Et dans le cas où F doit envoyer un autre message à J, il doit déterminer à nouveau cette référence grâce au chemin qu'il porte. Or, le parent de I ayant changé, le chemin en question n'a plus aucun sens.
Pour pallier à ce problème, nous introduisons une indirection. La variable structurée port doit contenir, pour les liens de composition de parent à enfant, non seulement la référence de l'enfant, mais également celle de l'objet lui-même ou du nouveau parent qui le remplace.
Si on reprend l'exemple de la figure 52, on obtient dans une première étape, comme illustré sur la figure 54, une référence vers le parent (flèche gris clair) et une référence vers le fils
(flèche gris foncé). G est le parent de I, et la référence vers le parent qu'il porte est une référence vers lui-même.
Et dans la seconde étape où H devient le parent de I, comme illustré sur la figure 55, la référence du parent de I portée par G est maintenant celle de H, tandis que la référence de G sur son ex-enfant I est mise à Null du fait que G n'en est plus le parent.
La variable port de H prend alors la forme qu'avait celle de G dans l'étape précédente. La référence parent pointe sur H et lui même, et la référence enfant pointe sur I.
G porte maintenant la référence de H, mais également le chemin qui mène à H
(3,myCjnyE_myH). Si H est virtualisé, G peut ainsi le réaliser à nouveau grâce à ce chemin.
Ainsi, lorsque F veut de nouveau obtenir la référence de I, il peut utiliser le même chemin
(1,G_I). Une indirection se fait alors automatiquement en suivant la référence parent de G vers
H.
Virtualisation
Le fait qu'un objet peut être virtualisé pour économiser des ressources d'ordinateur, a été introduit en début du présent chapitre.
Comme nous l'avons aussi vu en introduction de ce chapitre, nous disposons d'objets transitoires (propre au poste client et qui ne survivent pas à l'exécution de l'application) et des objets permanents (sauvegardés sur un serveur). Un objet permanent peut être librement « virtualisé » sur le client (quand il n'est pas utilisé), puisque son état courant peut toujours être récupéré à partir du serveur. Par contre, un objet transitoire ne peut être virtualisé que quand il est dans son état initial. En effet, de par sa nature, son état n'est présent qu'en mémoire sur le poste client de l'utilisateur, et n'est sauvegardé nulle part. Il ne peut donc être réalisé qu'à son état initial. De fait, si un objet transitoire était virtualisé dans un autre état que son état initial, nous perdrions de l'information. La virtualisation est déclenchée par les objets visuZone : lorsque des objets d'affichage disparaissent de l'écran (par exemple parce que l'utilisateur a changé de page), un temporisateur unique est déclenché. Si aucun élément d'affichage relié à l'objet visuZone n'est réaffiché avant l'expiration de la temporisation, tous les éléments sont virtualisés.
La virtualisation de ces éléments peut provoquer celles des objets qui y sont connectés (liés), ainsi que des objets qui sont connectés à ces derniers, et ainsi de suite. En effet, à l'aide de
Séquenceur et de l'historique, il est possible de retrouver quels sont les objets qui manipulent les objets d'affichage en suivant les relations de cause à effet (dans le sens des effets aux causes).
Supposons maintenant, dans l'exemple illustré sur la figure 56, que F soit un objet d'affichage pouvant être virtualisé. L'historique nous indique qu'à l'instant logique t+7, E était à l'origine d'une transition de F, puis à l'instant t+5, D était à l'origine d'une transition de E, ...et ainsi de suite jusqu'à A dont la transition était initiée par l'utilisateur. A, B, D, et E sont donc candidats à la virtualisation (virtualisables) quand F se virtualise.
Cependant, un objet candidat à virtualisation peut être en train d'interagir avec d'autres objets, et il ne faut alors pas le virtualiser (on notera ici qu'une interaction, proche dans le temps, prévue avec des objets non liés à l'objet visuZone actif courant ou à ses vosins, n'est pas un frein à la virtualisation si ces objets sont répliqués et vivent sur le serveur - voir plus loin chapitre NI). Pour pouvoir détecter ces cas de figure, on dispose de plusieurs techniques :
• Comme nous l'avons vu, chaque objet dispose d'un drapeau PendingNext qui indique si il est en attente d'un next pour poursuivre ses activités. Un objet dans ce cas ne doit bien sûr pas être virtualisé, puisqu'il serait réalisé à nouveau peu de temps après, dès qu'il recevrait le next.
• Un objet virtualisable (dans la chaîne de cause à effet qui a aboutit à la transition d'un objet d'affichage) peut être en train d'effectuer d'autres actions. Celles-ci sont alors reportées dans l'historique. Pour chaque objet virtualisable, il suffit de regarder dans l'historique s'il n'existe pas d'autres entrées le concernant (postérieures à celle figurant dans la chaîne de cause à effet).
• A chaque envoi de message, l'objet relève le temps CPU (temps de l'unité centrale de traitement qui l'exécute) dans un attribut lastActionTime. Lorsqu'un objet est déclaré potentiellement virtualisable (au sens où nous venons de le définir), on regarde de nouveau le temps CPU currentTime. Si currentTime - lastActionTime > δ, δ étant un intervalle de temps prédéterminé, alors l'objet n'a pas interagi depuis longtemps et peut donc être virtualisé. Si currentTime - lastActionTime < δ, l'objet n'est pas virtualisé et la propagation s'arrête dans cette direction : le système ne cherche pas à virtualiser les objets qui lui sont connectés. Des dispositifs complémentaires peuvent également être envisagés :
• Un système d'apprentissage qui va inférer les délais entre les différentes actions, ceci permettant d'éviter de virtualiser des objets juste avant qu'ils effectuent une action.
• Un mécanisme probabiliste permettant d'associer (de façon manuelle, ou par inférence de la part du système) à chaque objet une probabilité d'être virtualisé.
Section 3 - Mécanisme de réalisation anticipative
Deux grandes approches d'anticipation, non exclusives, peuvent être mises en œuvre : l'approche structurelle et l'approche comportementale.
L'approche structurelle, offre l'avantage d'être transparente (ne nécessite pas de spécification supplémentaire). Elle utilise les liens qui ont préalablement été établis entre les objets, en fonction de la structure des associations dans le modèle. Cette approche ne donne donc pas forcément beaucoup de résultats au lancement de l'application, mais est de plus en plus efficace au long de l'exécution.
Anticipation comportementale
L'approche comportementale consiste à exécuter le modèle de l'application avec un certain nombre de pas d'avance, grâce à des spécifications supplémentaires (des annotations) fournies explicitement dans le modèle. Il s'agit notamment d'ajouter dans le modèle des « transitions anticipatives » qui représentent les effets des impulsions probables que le système pourrait recevoir de son environnement extérieur.
Lors de l'exécution, les transitions anticipatives ne sont pas prises en compte comme de vraies transitions (autrement dit, une transition anticipative ne change pas l'état courant de l'objet mais change plutôt une -ou plusieurs- variable de travail dans laquelle est simulée l'état futur), elles servent néanmoins, notamment, à « réaliser » les objets qui seraient à l'état « virtuel ».
(On observera ici que l'anticipation comportementale peut aussi servir au raisonnement temporel, pour l'aide à la décision tactique par exemple).
Ainsi, dans l'exemple illustré sur la figure 57, un objet Switch peut effectuer une transition de
Off h On par le message turnOn. Pour que le système puisse automatiquement anticiper une transition de Ojfh On, ayant lieu trois secondes après l'entrée dans l'état Off, le modélisateur annote la transition anticipative (en pointillés) avec l'événement déclenchant time-outβs)
(bien entendu, il peut y ajouter des conditions, des actions, etc).
Le modélisateur déclare que les transitions anticipatives sont anticipées avec un temps d'avance δ (il peut déclarer ceci globalement pour toute l'application ou sélectivement). La transition prédictive de l'objet Switch se fait ainsi au bout de 3-δ secondes si δ<3, et immédiatement sinon, après l'entrée dans l'état Off.
Les transitions qui en découlent (les actions dans les états anticipés produisent des événements qui causent d'autres transitions) sont aussi anticipatives. Comme les premières, elles ne se font pas sur le même plan que l'exécution de l'application et servent à amplifier le processus de réalisation. Bien entendu, les états anticipés par le système n'ont aucun effet de bord
(notamment sur l'interface homme machine). Ainsi, dans l'exemple précédent, si on suppose que l'objet Switch, dans son état On, déclenche une transition d'un objet Lamp qui serait à l'état « virtuel », l'approche comportementale, par anticipation de la transition turnOn, permet de « réaliser » l'objet Lamp avant que l'utilisateur déclenche (directement ou indirectement) la transition turnOn réelle.
Dans la suite, nous décrivons l'approche structurelle, même si nous retiendrons que l'anticipation comportementale en constitue un complément important, puisqu'elle permet d'amplifier les avantages de l'anticipation structurelle (les deux approches ont une relation synergétique).
Anticipation structurelle
Comme nous l'avons vu dans la première partie de la section 2 du chapitre N, un argument depth (profondeur) est passé lors des appels à la méthode connect. Cet argument permet d'établir le degré d'anticipation que l'on désire atteindre. En effet, une fois la connexion de Oo à O terminée, si depth>0, ON établira ses propres connexions (à la profondeur souhaitée), comme le montre le schéma de la figure 58, qui illustre une connexion à la profondeur 3
(depth = 3).
Considérons maintenant le diagramme de classe illustré sur la figure 59, et supposons que les réalisations se font à la profondeur 1. Alors la connexion de l'objet visuZonel à l'objet B va provoquer non seulement la création de B, mais aussi celle de l'objet D via la connexion de B à D. Ceci est explicité dans le diagramme de séquence de la figure 60.
Cas des objets visuZones
Dans le cas où l'objet visé serait un élément d'affichage, l'anticipation se fait par l'intermédiaire de l'objet visuZone. Il assure le lien entre l'objet visé (le premier élément d'affichage) et les autres éléments du même groupe. Mais cet intermédiaire doit être transparent et ne doit donc pas intervenir dans le calcul de la profondeur d'anticipation.
Ainsi, dans la représentation de la figure 61 qui illustre une connexion à la profondeur 2, on observe que la connexion à un objet visuZone ne compte pas dans le calcul de la profondeur d'anticipation.
De plus, comme nous l'avons vu dans l'exemple du voisinage géographique, les objets visuZone peuvent être reliés les uns avec les autres. Ceci ne change en rien le mécanisme d'anticipation, si ce n'est que dans ce cas la connexion entre objets visuZone compte dans le calcul de la profondeur.
Ainsi la figure 62 montre, toujours dans le cas d'un connexion à la profondeur 2, que la connexion entre deux objets visuZone compte dans le calcul de la profondeur d'anticipation.
Chapitre 3 - Partage inter clients (Figures 63 à 72)
On va traiter ici du partage d'une ou plusieurs applications par plusieurs utilisateurs distants. On se place donc dans une architecture informatique client/serveur, où chaque client exécute une application dont certains objets peuvent être partagés par d'autres clients.
Section 1 - Types d'objets
Nous avons vu précédemment, dans le cadre du mécanisme de chargement progressif décrit dans le chapitre précédent, qu'il existe deux types d'objets : les objets transitoires et les objets permanents. Dans le présent chapitre, cette dernière catégorie est subdivisée en deux : les objets permanents privés et les objets permanents partagés.
Un objet permanent partagé peut être utilisé conjointement par tous les clients. Chaque utilisateur partage avec les autres les valeurs caractéristiques de l'objet (état, rôles, etc.).
Lorsqu'un utilisateur modifie l'état d'un tel objet, cela est ressenti chez tous les clients qui ont réalisé (au sens du mécanisme de chargement progressif) cet objet.
Les objets permanents privés sont, comme leur nom l'indique, propres à chaque client. Les clients utilisent certes les mêmes objets au sens où ils utilisent la même application, mais les objets permanents privés sont décorrélés entre eux d'un client à l'autre.
La gestion du partage d'une ou plusieurs applications entre plusieurs clients revient donc à gérer les objets permanents partagés, de telle façon que la modification d'un tel objet par un utilisateur soit reportée chez tous les clients concernés, c'est à dire ceux chez qui cet objet existe réellement.
Section 2 - Architecture
Plusieurs approches peuvent être suivies pour gérer le partage inter-clients. La première repose sur une réplication par « valeurs » des données partagées. En référence à la figure 63, la réplication entre les différents clients PC peut alors être gérée au moyen d'un Système de Gestion de Bases de Données sur un ou plusieurs serveurs communs PS. Un tel système assure la permanence des informations partagées et s'occupe des accès concurrents aux données. Dans un tel contexte, la gestion du déterminisme n'est pas nécessaire. En effet, le comportement des objets (les actions qu'ils effectuent) a lieu chez les différents clients et en aucun cas sur serveur. Ce dernier ne conservant que les différentes valeurs (état...) des objets partagés, il n'a pas besoin de reproduire le comportement des objets. A chaque modification d'un objet partagé O chez un client, les valeurs de O sont mises à jour dans la structure de données, et reproduites chez les clients qui utilisent également O.
Si cette approche présente l'indéniable avantage de la simplicité, elle ne permet cependant pas la persistance des traitements. A partir du moment où aucun client ne travaille, les objets de l'application sont inertes puisqu'ils n'ont aucune vie sur le serveur. La persistance des traitements est surtout utile dans le cas d'applications de simulation où l'on ne voufrait pas nécessairement laisser le poste client allumé pour permettre la poursuite de la simulation.
Permettre cette persistance de traitement fait l'objet de la deuxième approche que nous allons détailler dans ce chapitre. Elle implique que les applications utilisées conjointement par les clients s'exécutent également sur le serveur. Ceci permet, comme nous allons le voir dans le chapitre suivant, un mécanisme de réplication par calcul. Ce mécanisme requiert par contre d'assurer un haut degré de déterminisme du comportement des objets partagés et d'avoir à disposition un mécanisme de rollback pour rattraper le non-déterminisme entre client et serveur (exécution optimiste sur le serveur, voir section 5 du chapitre NI). Les applications sur le serveur disposent également d'un Séquenceur régulant les objets partagés.
Section 3 - Mécanisme de réplication
Comme nous l'avons vu, des utilisateurs d'une application peuvent partager certaines instances d'objets permanents partagés. Les utilisateurs peuvent interagir avec ces objets, mais chacun à leur tour grâce à un mécanisme d'exclusion mutuelle explicité plus loin. Quand un utilisateur modifie un objet, étant donné que la même instance peut être partagée avec certains autres utilisateurs, ces derniers doivent être notifiés de cette modification. Ainsi la figure 64 illustre le cas où deux utilisateurs Userl et User2 manipulent différents objets (objets noirs pour Userl, objets blancs pour User2).
Cependant, du fait du mécanisme de chargement progressif, des utilisateurs qui partagent des mêmes instances n'ont pas forcément tous réellement ces instances sur leur poste. Ainsi, quand un objet partagé est modifié, il n'est pas nécessaire de répliquer cette modification chez tous les clients qui partagent cette instance, mais uniquement chez ceux pour qui l'objet en question est réel (a été réalisé, et depuis n'a pas été virtualisé).
Toute modification d'un objet permanent partagé due à un message provenant d'un objet transitoire ou d'un objet permanent privé est aussi effectuée sur un serveur, par la réplication de la transition qui en est à l'origine (les actions effectuées par l'objet permanent partagé sont donc exécutées à la fois chez le client qui a verrouillé cet objet, et sur le serveur). Ces modifications sont ensuite reportées du serveur chez chacun des clients qui possède réellement cet objet. Ceci constitue le premier aspect de ce mécanisme de réplication : la réplication par « valeur ».
Si une des actions de l'objet permanent partagé provoque une transition d'un autre objet permanent partagé, celle-ci n'est pas répliquée du client (qui a le verrou) sur le serveur. Elle est directement « calculée » par le serveur. Bien sûr, la modification de ce second objet permanent partagé est aussi reportée chez chacun des clients qui le possède réellement. Ceci constitue le deuxième aspect de ce mécanisme de réplication : la réplication par « calcul ». Un tel type de réplication n'est possible que si l'application partagée s'exécute également sur le serveur, en accord avec le modèle d'exécution spécifié dans le chapitre IN (donc régulé par un Séquenceur). Ainsi, on dispose au global d'un mécanisme de « réplication mixte » :
• Par valeur : au sens où les transitions d'objets permanents partagés sont reproduites quand elles ont été causées par des objets purement locaux dont le serveur n'a pas la visibilité (transitoires et permanents privés)
• Par calcul : au sens où les transitions d'objets permanents partagés sont déduites par le serveur quand elles ont été causées par un autre objet permanent partagé (dont le serveur a alors la visibilité).
Ainsi la figure 65 illustre les deux types de réplication entre un client et un serveur de partage, lorsque sont mis en œuvre des objets transitoires, des objets permanents privés et des objets permanents partagés. Bien sûr, une telle approche n'est pas limitée à l'utilisation d'un seul serveur, comme le montre la figure 66 où il existe deux serveurs de partage Serveur de Partage 1 et Serveur de Partage 2 coopérant l'un avec l'autre.
Ce mécanisme de réplication peut être scindé en deux phases distinctes : la réplication sur un serveur d'une transition effectuée par un objet chez un client (qui en a le droit au sens de l'exclusion mutuelle), et la propagation de cette même transition du serveur chez tous les clients qui possèdent réellement (au sens du mécanisme de chargement progressif) l'objet.
Réplication sur un serveur depuis un poste client
Supposons qu'un objet permanent partagé SPO (pour « Shared Persistent Object » en terminologie anglosaxonne), chez un client C, effectue une transition due à la réception d'un message d'un objet transitoire ou d'un objet permanent privé. Les informations suivantes sont alors envoyées sur le serveur :
1. L'objet partagé qui effectue la transition
2. L'état précédent la transition (que nous appellerons état précédent)
3. L'état courant après la transition (que nous appellerons état courant)
4. Le temps logique correspondant à cette transition chez le client qui en est à l'origine
5. Le temps logique correspondant à la transition précédente chez le client qui en est à l'origine
Grâce aux informations 1. et 3., l'application sur le serveur retrouve de quel objet il s'agit et lui fait effectuer sa transition dans l'état spécifié. Les informations 2., 4. et 5. servent quant à elles à divers traitements de récupération d'erreurs explicités plus loin dans la section 5 du chapitre NI.
Lorsque l'objet permanent partagé effectue sa transition sur le serveur, il le fait pour un temps logique du Séquenceur de l'application serveur.
Considérons l'exemple où l'on dispose de quatre objets A, B, C et D. A est un objet transitoire, B et C sont des objets permanents partagés et D est un objet permanent privé.
Un extrait des diagrammes d'état-transition de ces objets est illustré sur la figure 67.
Supposons qu'un client K provoque la transition de l'état S0 à SI de l'objet A. On alors le déroulement illustré sur la figure 68 (les objets ont été mis sous forme canonique conformément à la description faite dans le chapitre IV).
Ceci se traduit au niveau du client K et du serveur de la façon suivante, illustrée sur la figure
69 :
- l 'objet B (partagé) effectue une transition due à un objet transitoire. Cette transition est répliquée sur le serveur.
- l'objet C (partagé) effectue une transition due à un objet permanent privé. Cette transition est répliquée sur le serveur.
- l'objet D est un objet permanent privé, l'application du serveur n'en a pas la visibilité. Le message envoyé par B dans l'état S5B est ignoré.
- puisqu'une application tourne sur le serveur, les transitions des objets partagés se font directement sur le serveur, indépendamment de celles qui ont lieu chez le client K.
Propagation d'une transition répliquée vers les clients concernés
Chaque fois qu'une transition d'un objet permanent partagé a lieu sur le serveur, elle est propagée sur chacun des postes clients qui possède réellement l'objet. Les clients qui ne possèdent un tel objet que virtuellement le récupéreront de toute façon à son état courant (sur le serveur) quand il sera réalisé à nouveau.
Ceci peut être matérialisé par le schéma de la figure 71, à considérer en relation avec le schéma de la figure 70 qui donne la représentation d'un objet transitoire T et de trois objets permanents partagés PI, P2 et P3. Tout d'abord, l'objet T fait transiter l'objet PI, et ceci est répliqué sur le serveur.
Le client L possède réellement les objets PI, P2 et P3. Les transitions de chacun de ces objets sont répliquées depuis le serveur.
Le client M ne possède réellement quant à lui que les objets P2 et P3. Leurs transitions sont répliquées. L'objet PI n'est là que virtuellement, et sa transition n'est pas répliquée.
Seul l'objet P3 est présent chez le client N, et sa transition est répliquée.
Les transitions qui se situent en aval de l'objet P3 ont lieu indépendamment chez le client K et le serveur.
Réplication dans un cadre multi-serveurs
Il se peut que les objets partagés par des clients soient répartis sur plusieurs serveurs. Le mécanisme de réplication et de propagation présenté dans les chapitres IV et V reste le même pour chaque serveur pris séparément. Chaque serveur exécute l'application et régule les objets qu'il possède au moyen d'un séquenceur.
De la même manière qu'une transition d'un objet partagé provoquée par un objet privé ou transitoire est répliquée par valeur, la transition d'un objet partagé d'un serveur provoquée par un objet partagé d'un autre serveur est également répliquée par valeur. Si d'autres objets partagés de ce serveur sont concernés par le cycle qui en découle, ils sont bien sûr répliqués par calcul. Le schéma de la figure 72 illustre ce mécanisme, dans lequel
- T fait transiter PI, et ceci est répliqué sur le serveur SI, et
- P2 fait transiter P3, et ceci est traité comme si P2 était transitoire ou privé : la réplication se fait par valeur.

Claims

REVENDICATIONS
1. Système de traitement de données, comprenant un processeur coopérant avec une mémoire principale pour exécuter des applications, le système étant apte à exécuter une application orientée objets composée d'un certain nombre d'objets et de liens entre ces objets, caractérisé en ce que le nombre d'objets de l'application est supérieur au nombre d'objets contenus dans la mémoire principale, et en ce que système comporte des moyens pour sélectivement créer dans la mémoire principale, en fonction de l'utilisation des liens par l'application, des parties de ladite application concernées par ces liens objet par objet ou groupe d'objets par groupe d'objets.
2. Système selon la revendication 1, caractérisé en ce qu'il est apte à accéder à une mémoire secondaire, et en ce qu'il comprend en outre des moyens pour initialiser un objet créé en mémoire principale avec la valeur d'un objet correspondant contenue dans la mémoire secondaire.
3. Procédé d'exécution d'une application contenant une pluralité d'objets associés entre eux selon une structure dans laquelle chaque objet est lié à tout autre objet par un chemin pouvant inclure au moins un objet intermédiaire, les objets pouvant sélectivement adopter un état créé et un état virtuel, caractérisé en ce qu'il comprend, pour chaque objet distant à exécuter à partir d'un objet source, les étapes suivantes :
- vérification de l'état créé ou non de l'objet distant,
- dans la négative, parcours du chemin entre l'objet source et l'objet distant à partir de l'objet source jusqu'à l'objet distant en passant le cas échéant par le ou les objets intermédiaires,
- création de l'objet distant, et
- stockage dans l'objet source d'une référence à l'objet distant créé en vue d'un accès ultérieur direct audit objet distant à partir dudit objet source.
4. Procédé selon la revendication 3, caractérisé en ce que la structure est arborescente.
5. Procédé selon la revendication 4, caractérisé en ce qu'un objet est lié à un autre objet soit directement, soit via un premier ancêtre commun.
6 Procédé selon la revendication 5, caractérisé en ce que la structure arborescente possède un objet racine créé de façon permanente, et en ce qu'il comprend les étapes additionnelles consistant à :
- attribuer à chaque objet une première information de chemin décrivant le chemin de l'objet racine vers l'objet parent dudit objet ;
- associer à chaque objet un ensemble d'informations de lien comprenant, pour chacun des autres objets dont il est susceptible de causer directement l'exécution, une seconde information de chemin vers ledit autre objet;
- lors de l'exécution de l'objet source, déterminer à partir desdites informations de lien, si l'objet distant est ou non à l'état créé,
- dans l'affirmative, causer l'exécution de l'objet distant,
- dans la négative, parcourir la structure arborescente de l'objet source en direction de l'objet racine, d'objet enfant vers objet parent, jusqu'à un premier ancêtre commun entre l'objet source et l'objet distant, pour déterminer à chaque fois si l'objet parent est créé,
- pour le premier objet parent non créé, utiliser la première information de chemin pour créer le cas échéant, en descendant à partir de l'objet racine, tout objet enfant non déjà créé et se situant entre l'objet racine et ledit objet parent à créer, et pour créer ledit objet parent lui- même, puis
- utiliser la seconde information de chemin pour créer le cas échéant, en descendant à partir dudit premier ancêtre commun, tout objet enfant non déjà créé et se situant entre ledit premier ancêtre commun et l'objet distant, et pour créer l'objet distant lui-même, et
- mettre à jour les informations de lien pour y indiquer que l'objet distant est créé.
7. Procédé selon l'une des revendications 3 à 6, caractérisé en ce que chacun des objets de la structure incorpore une méthode de connexion apte à restituer audit objet une référence d'un autre objet avec lequel ledit objet doit interagir.
8. Procédé selon la revendication 7, caractérisé en ce qu'un appel de méthode de connexion contient une information d'index représentative du niveau auquel se trouve ledit ancêtre commun et une information de chemin de l'ancêtre commun vers le second objet.
9. Procédé selon l'une des revendications 3 à 8, caractérisé en ce qu'il comprend en outre, après l'étape de stockage dans l'objet source d'une référence à l'objet distant, les étapes consistant à :
- provoquer l'envoi du premier objet vers le second objet d'une référence du premier objet,
- provoquer la mémorisation par le second objet de ladite référence.
10. Procédé selon la revendication 9, caractérisé en ce qu'il comprend en outre, après l'étape de mémorisation par le seconde objet de ladite référence, l'étape consistant à :
- lorsque le second objet s'apprête à passer de l'état créé à l'état virtuel, utiliser ladite référence mémorisée par le second objet pour adresser au premier objet un message représentatif d'une telle virtualisation.
11. Procédé selon l'une des revendications 3 à 10, caractérisé en ce qu'il existe des groupes d'objets tels que la création d'un objet d'un groupe donné implique la création des autres objets dudit groupe.
12. Procédé selon la revendication 11, caractérisé en ce que les objets groupés comprennent des objets d'affichage.
13. Procédé selon la revendication 12, caractérisé en ce que les objets groupés comprennent des objets d'interface de l'application avec l'extérieur.
14. Procédé selon l'une des revendications 12 et 13, caractérisé en ce que lesdits objets d'affichage groupés comprennent des objets appartenant à une même page d'informations transmise par réseau.
15. Procédé selon la revendication 11, caractérisé en ce qu'au moins un groupe contient un objet à créer pour exécution immédiate et au moins un objet à créer pour exécution future.
16. Système de traitement de données orienté objets comprenant une application contenant une pluralité d'objets associés entre eux selon une structure dans laquelle chaque objet est lié à tout autre objet par un chemin pouvant inclure au moins un objet intermédiaire, les objets pouvant sélectivement adopter un état créé et un état virtuel, caractérisé en ce que :
- ladite structure est une structure arborescente à N niveaux comportant un objet racine créé de façon permanente, tandis que les autres objets peuvent sélectivement adopter un état créé et un état virtuel, et en ce qu'il comprend en outre :
- des moyens de création des objets par mise en œuvre du procédé selon l'une des revendications 3 à 15, et
- des moyens pour sélectivement rendre virtuels au moins certains des objets créés après l'écoulement d'une durée déterminée pendant laquelle aucun des objets n'a été exécuté.
17. Système de traitement de données orienté objets comprenant une application contenant une pluralité d'objets associés entre eux selon une structure dans laquelle chaque objet est lié à tout autre objet par un chemin pouvant inclure au moins un objet intermédiaire, les objets pouvant sélectivement adopter un état créé et un état virtuel, caractérisé en ce que :
- ladite structure est une structure arborescente à N niveaux comportant un objet racine créé de façon permanente, tandis que les autres objets peuvent sélectivement adopter un état créé et un état virtuel, et en ce qu'il comprend en outre :
- des moyens de création des objets par mise en œuvre du procédé selon l'une des revendications 3 à 15,
- des moyens de séquencement d'activité pour mémoriser des messages de demandes d'activité de la part des différents objets, pour sélectivement autoriser lesdits objets à exercer tour à tour les activités demandées, et
- des moyens pour sélectivement rendre virtuels au moins certains des objets après avoir vérifié au niveau des moyens de mémorisation qu'il n'existe pour aucun d'entre eux un message de demande d'activité mémorisé.
18. Système de traitement de données, comprenant un processeur exécutant une application orientée objets, l'exécution de l'application comportant des exécutions en chaîne d'objets liés les uns aux autres, caractérisé en ce que le système comporte, lorsqu'un objet doit être exécuté, des moyens aptes, sur la base des liens entre objets, à faire passer ledit objet, le cas échéant, d'un état virtuel, où seulement une trace de l'objet est contenue dans une mémoire de travail, à un état réel, où l'objet se trouve sous forme exécutable dans ladite mémoire de travail.
19. Système selon la revendication 18, caractérisé en ce qu'il comprend en outre des moyens pour faire passer un objet donné de son état virtuel à son état réel sur la base d'une instruction d'exécution d'un objet situé en amont dudit objet donné.
20. Système de traitement de données, comprenant des moyens de traitement exécutant une application orientée objets réactive et dans laquelle il peut exister des instants où les comportements d'objets différents sont vus par un utilisateur comme se produisant en parallèle, et dans laquelle au moins certains des objets présentent des états dans lesquels s'exécutent respectivement un ensemble ininterruptible d'une ou plusieurs premières actions et/ou un ensemble interruptible d'une ou plusieurs secondes actions, caractérisé en ce que chaque état de chaque objet est décomposé en un premier sous-état le cas échéant, dans lequel s'exécutent les seules premières actions, et en un ou plusieurs seconds sous-états le cas échéant, dans lesquels s'exécutent respectivement les secondes actions, et en ce qu'il est prévu en association avec les seconds sous-états un moyen de séquencement apte à communiquer de façon bidirectionnelle avec les objets dans chacun de leurs seconds sous-états pour organiser de façon séquentielle et reproductible le déroulement des secondes actions dans lesdits seconds sous-états tout en conservant la vision parallèle des comportements des objets pour l'utilisateur.
21. Système selon la revendication 20, caractérisé en ce qu'une transition d'un objet vers un état dans lequel s'exécutent une ou plusieurs premières actions amène ledit objet dans le premier sous-état dudit état de façon automatique.
22. Système selon l'une des revendications.20 et 21, caractérisé en ce que chaque objet possédant des secondes actions présente un premier sous-état dans lequel s'exécute, en sus des éventuelles premières actions, un envoi au moyen de séquencement d'un message de demande de déclenchement, par ledit moyen de séquencement, de l'exécution de la ou des secondes actions.
23. Système selon la revendication 22, caractérisé en ce que chaque objet possède une transition automatique du premier sous-état vers un état sous-état intermédiaire d'attente d'un événement de déclenchement d'exécution de la part du moyen de séquencement, apte à provoquer une transition de l'objet vers l'un des seconds sous-états.
24. Système selon la revendication 22, caractérisé en ce que la transition dudit sous-état intermédiaire vers l'un des seconds sous-états, de même que la transition d'un second sous- état vers un autre second sous-état, s'effectuent en réponse à un même événement (Next).
25. Système selon l'une des revendication 20 à 24, caractérisé en ce que chaque objet est apte à adresser au moyen de séquencement un message de demande d'activité (Put(next,...)) indiquant qu'il existe dans ce même objet un ensemble interruptible d'une ou plusieurs secondes actions, et en ce que le moyen de séquencement comprend un moyen de mémorisation des messages reçus, et un moyen pour parcourir les messages mémorisés dans l'ordre de leur arrivée.
26. Système selon la revendication 25, caractérisée en ce que chaque message de demande d'activité émis par un objet contient au moins une identification de l'objet.
27. Système selon l'une des revendications 25 et 26, caractérisé en ce que chaque objet comprend un compteur d'envois de messages de demande de déclenchement d'exécution apte à permettre de déterminer l'éventuelle caducité d'un événement de déclenchement d'exécution correspondant délivré par le moyen de séquencement.
28. Système selon la revendication 27, caractérisé en ce que chaque objet possède un moyen de comparaison de la valeur contenue dans ledit compteur avec une valeur contenue dans un événement de déclenchement d'exécution reçu par ledit objet pour entrer dans ledit second sous-état donné.
29. Système selon l'une des revendications 25 à 28, caractérisé en ce que le moyen de mémorisation est également apte à conserver la trace des actions effectuées par lesdits objets.
30. Système selon la revendication 29, caractérisé en ce que le moyen de mémorisation est également apte à mémoriser une succession de messages de trace reçus par le moyen de séquencement et comprenant chacun:
- une identification de l'objet effectuant une transition ; et
- une identification de l'origine de l'événement qui a déclenché ladite transition.
31. Système selon la revendication 30, caractérisé en ce que chaque message de trace comprend en outre une identification de l'état dudit objet avant cette transition.
32. Système selon les revendications 30 et 31, caractérisé en ce que chaque message susceptible d'être reçu par le moyen de séquencement comprend une information de type (next/trace) permettant de distinguer un message de trace d'un message de demande d'activité.
33. Système selon la revendication 32, caractérisé en ce que le moyen de mémorisation est apte à mémoriser les messages de trace avec les messages de demande d'activité selon une séquence correspondant à leur succession temporelle, et en ce que le moyen de séquencement comprend en outre un curseur de traitement apte à parcourir, dans le sens de la séquence, les seuls messages de demande d'activité en vue de leur traitement.
34. Système selon l'une des revendications 30 à 33, caractérisé en ce qu'à chaque message est associée une information représentative de sa position dans le moyen de mémorisation.
35. Système selon l'une des revendications 20 à 34, caractérisé en ce que le moyen de séquencement est également apte à organiser de façon séquentielle le déroulement de premières actions causées par des événements extérieurs au système.
36. Système selon l'une des revendications 20 à 35, caractérisé en ce qu' il existe des objets aptes à exécuter une première action dite premier cycle en réponse à un événement extérieur au système, notamment provoqué par l'utilisateur, en ce que chacun de ces objets est apte à adresser au moyen de séquencement, une demande d'activité correspondante (BOFC), et en ce que le moyen de séquencement est apte à délivrer à l'objet effectuant une telle demande un message d'autorisation correspondance (Proceed) seulement lorsqu'il n'existe pas un autre premier cycle en cours d'exécution.
37. Système selon la revendication 36, caractérisé en ce que chaque objet apte à effectuer un premier cycle est apte, lors de la fin de l'exécution de celui-ci, à adresser au moyen de séquencement un message de fin de premier cycle (EOFC), de manière à ce que le moyen de séquencement puisse ensuite le cas échéant autoriser (Proceed) un autre premier cycle.
38. Système de traitement de données, comprenant des moyens serveurs et au moins un poste client, le ou au moins l'un des postes clients comportant un processeur apte à exécuter, en coopération avec les moyens serveurs, une application orientée objets comportant des objets répliqués comprenant chacun un objet client et un objet serveur destinés à être exécutés de façon identique respectivement dans le poste client et dans les moyens serveurs, système caractérisé en ce que :
- l'application comprend également des objets non répliqués pouvant être exécutés dans le poste client seulement,
- en ce que l'exécution d'un objet non répliqué engendrant un message d'exécution de l'objet client d'un objet répliqué, engendre également vers lesdits moyens serveurs un message d'exécution de l'objet serveur du même objet répliqué,
- en ce que l'exécution de l'objet client d'un premier objet répliqué, engendrant un message d'exécution de l'objet client d'un second objet répliqué, n'engendre aucun message d'exécution vers lesdits moyens serveurs, tandis que dans ces derniers, l'exécution de l'objet serveur du premier objet répliqué engendre un message d'exécution de l'objet serveur du second objet répliqué.
39. Système selon la revendication 38, caractérisé en ce qu'au moins certains des objets répliqués sont des objets partagés entre ledit poste client et au moins un autre poste client, et en ce que le résultat de l'exécution de tout objet serveur d'un objet partagé est reproduit dans chacun desdits autres postes clients.
40. Système selon l'une des revendications 38 et 39, caractérisé en ce que ledit message d'exécution de l'objet serveur du même objet répliqué comprend :
- un identificateur de l'objet serveur ; et
- une information relative à l'état de l'objet partagé après sa transition.
PCT/FR2001/001730 2000-06-06 2001-06-05 Systeme de traitement de donnees oriente objet a chargement progressif WO2001095231A2 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
FR00/07250 2000-06-06
FR00/07246 2000-06-06
FR0007250A FR2805378A1 (fr) 1999-11-10 2000-06-06 Systeme permettant l'execution partagee d'apllications par replication mixte
FR00/07253 2000-06-06
FR0007253A FR2805379A1 (fr) 1999-11-10 2000-06-06 Systeme de traitement de donnees apte a executer une application orientee objets reactive
FR0007246A FR2807182A1 (fr) 2000-04-03 2000-06-06 Systeme de traitement de donnees oriente objet a chargement progressif

Publications (2)

Publication Number Publication Date
WO2001095231A2 true WO2001095231A2 (fr) 2001-12-13
WO2001095231A3 WO2001095231A3 (fr) 2004-08-12

Family

ID=27248673

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/001730 WO2001095231A2 (fr) 2000-06-06 2001-06-05 Systeme de traitement de donnees oriente objet a chargement progressif

Country Status (1)

Country Link
WO (1) WO2001095231A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113296883A (zh) * 2021-02-22 2021-08-24 阿里巴巴集团控股有限公司 应用管理方法和装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BELLISSARD L ET AL: "Distributed application configuration" DISTRIBUTED COMPUTING SYSTEMS, 1996., PROCEEDINGS OF THE 16TH INTERNATIONAL CONFERENCE ON HONG KONG 27-30 MAY 1996, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 27 mai 1996 (1996-05-27), pages 579-585, XP010167593 ISBN: 0-8186-7399-0 *
P. BISHOP & N. WARREN: "Lazy instantiation: Balancing performance and resource usage" JAVAWORLD, [Online] 1 février 1999 (1999-02-01), pages 1-7, XP002260868 Extrait de l'Internet: URL:http://www.javaworld.com/javatips/jw-j avatip67_p.html> [extrait le 2003-11-06] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113296883A (zh) * 2021-02-22 2021-08-24 阿里巴巴集团控股有限公司 应用管理方法和装置
CN113296883B (zh) * 2021-02-22 2023-08-04 阿里巴巴集团控股有限公司 应用管理方法和装置

Also Published As

Publication number Publication date
WO2001095231A3 (fr) 2004-08-12

Similar Documents

Publication Publication Date Title
Carpenter et al. Cassandra: The Definitive Guide,(Revised)
EP4142259A1 (fr) Système et procédé pour faciliter le partage d&#39;espace virtuel tridimensionnel
Alapati Expert Hadoop administration: managing, tuning, and securing spark, YARN, and HDFS
KR20140014268A (ko) 클라우드 저장소
CA2110538A1 (fr) Systeme d&#39;information multimedia
FR2824160A1 (fr) Conteneur generique configurable de facon dynamique
Colace et al. A context-aware framework for cultural heritage applications
JP7416845B2 (ja) Ｇｕｉ応答時間を改善するために予測ベースのｇｕｉを生成するシステム及び方法
FR2805375A1 (fr) Systeme de partage d&#39;informations sur un reseau informatique
EP2593909A1 (fr) Processeur d&#39;analyse situationnelle
CA2370693C (fr) Systeme et methode de pilotage d&#39;un processus decisionnel lors de la poursuite d&#39;un but globale dans un domaine d&#39;application determine
Sriramoju Introduction to big data: infrastructure and networking considerations
FR3026878A1 (fr) Procede et dispositif de mise en relations d&#39;un ensemble d&#39;informations
CA2552821A1 (fr) Dispositif de simulation du monde reel par traitement asynchrone et chaotique
WO2001095231A2 (fr) Systeme de traitement de donnees oriente objet a chargement progressif
WO2008043392A1 (fr) Procede pour traiter des informations
Dhall et al. Scalability Patterns
EP3729273B1 (fr) Systeme et procede d&#39;elaboration et d&#39;execution de tests fonctionnels pour grappe de serveurs
Brown Reactive Applications with Akka. NET
EP0631675B1 (fr) Utilisation d&#39;un langage ayant une representation similaire pour les programmes et les donnees en informatique distribuee
EP3343410A1 (fr) Dispositif de traitement de flux de données à grande échelle
Mateos et al. The Cloud at Your Service: The when, how, and why of enterprise cloud computing
FR2807182A1 (fr) Systeme de traitement de donnees oriente objet a chargement progressif
FR3041450A1 (fr) Architecture client/serveur pour l&#39;administration d&#39;un supercalculateur
FR2807181A1 (fr) Procede et systeme de gestion, dans un poste informatique, de l&#39;affichage de fenetres lors d&#39;une operation de glisser-deposer

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP