task is notified when the task has finished.
Several task services can be running on different computers, and e.g. the data service has the option to spawn of tasks on several different com-puters. This can be important if Zephyr is used by a large utility owing hundreds of wind farms, as this might lead to calculation times which cannot be performed within a reasonable time on a single computer. This way wind farm models which do not depend on each other, can perform their calculations simultaneously on different computers.
5.4 The business object super-classes
5.4.1 Object relations
Figure5.2 shows a simplified overview of the relations between the vari-ous super-classes for the business objects and the client to server mapping between the business objects and the business object proxy. A business object is an object which inherits from the Persistent object, the issues related to persisting the business object and the fact that the object can be shared by several other objects, is surfaced in the SharedServerObject and the Persistent classes.
Each business object has two objects and one interface related to it. The business object proxy or the ClientCache has already been mentioned in Section5.2. Each specific business object which inherits from Persistent has a corresponding proxy which inherits from ClientCache. The second object is the business object persistence handler or peer. This object surfaces storage details for different storage media. The interface is a remote interface, which specifies which methods in the business object can be invoked from objects in other JVM.
The business object itself resides in the object service, but other objects residing in e.g. - a client or in another service should never communicate directly with the business object. This communication should be surfaces through the proxy.
Persistent
Figure 5.2: Simplified object model for the business object super-classes and related objects.
The state of the business object is persistent, i.e. - if the machine where an object service is running on goes down, the business objects in that service can all be restored. Furthermore, if a business object is not being used by any client or other service, this object is removed from the object service memory, and only restored when requested.
5.4.2 Distributed event model notification
A synchronization mechanism exist between the SharedServerObject and the ClientCache. The purpose of this mechanism is to provide a conve-nient way for a business object and the business object proxy to synchro-nize their states. The mechanism is similar to the event model pattern used in user interface components, but special considerations needs to be taken into account when the event model is transferred to a fragile network connection.
The synchronization mechanism is simple, and the reason for this has to do with the fact that it is not feasible to use complex event semantics over a network. The methods which are involved in the synchronization are defined by the two interfaces RemoteObserverable and RemoteObserver shown in Figure5.2.
5.4 The business object super-classes 57 The RemoteObserverable takes two methods addObserver and deleteOb-server. The RemoteObserver only requires an update method to be im-plemented. The add/delete methods manage a registry of ClientCaches which are interested in knowing about business object state changes.
When a state change occurs in a business object, the business object no-tifies all registered ClientCaches by calling the update method. A special object called RemoteEvent is passed to the ClientCache via the update method. This object describes the type of change which occurred in the business object.
Some key points in this process are of importance. It can not be guaran-teed that the calls to the update methods are performed chronologically, therefore one of the property in the RemoteEvent is a sequence num-ber. This is an ever increasing number, and it is guaranteed that the sequence number increases between two subsequent state changes in a business object, the sequence number can therefore be used to order the state changes chronologically. Performance is also important, the RMI implementation in Java implies that a remote call does not finish be-fore the remote object method finishes. Therebe-fore, the notification from a business object to different proxies in different JVM is performed in threads. Similarly, the consumption of the event in the proxy is handled in a thread, which means the call to the proxy finishes as fast as pos-sible. The thread which is created in the proxy, is then pushed into a thread queue, and the treads are executed one at a time as it can not be guaranteed that the proxy environment is thread safe. For instance the graphical user interface API, Swing, which is a part of the Java Foundations Classes (JFC) API is not thread safe.
5.4.3 Object locking
As shown in Figure 5.2 the persistent object inherits from the Shared-ServerObject. This object handles the logic involved with the fact that the object potentially is accessed by several other objects simultane-ously. Write or update access to the business object results in a lock on the object. Before the first write occurs on a business object, a snapshot is taken of the object. The snapshot is not discarded before the write accesses are explicitly committed.
The lock is associated with a digital signature created by the security service, which uniquely identifies the user holding the lock. If the lock is not renewed within a fixed amount of time, the lock is released and the object is restored back to its original state. The state is restored using the snapshot which was taken of the object before the first write was performed on the object.
5.4.4 Persistence
As shown in Figure 5.2 the persistent object is associated with a per-sistence handler/peer. This handler is assigned to the business object when a new instance is created, and a particular type of business objects share the same handler. The type of handler which is assigned depends on a configuration parameter in the system, and different handlers can therefore be selected based on how the business object is actually made persistent. In the current system flat file persistence handlers are used, the handlers are capable of reading the state of a business object and assigning a state to a business object; the state itself is saved/loaded in/from a binary file. This architecture implies that the storage details are transparent to the business object, changing the storage media means that only the handler needs to be replaced, the business objects stay un-changed.
5.4.5 The descriptor
All business objects are associated with a descriptor property. This prop-erty is a simple object, which only contains fields of primitive types, i.e.
String, Integer, Long, Float, Double. The idea of this property is to facilitate fast and easy business object searching based on intuitive crite-ria. A descriptor object can e.g. contain fields like manufacturer, make, model, name, etc.
A query can be executed via methods in the object service managing the business objects of interest. The query itself is represented by a query object, which is similar to the descriptor object, i.e. - the query object only contains fields of primitive types. The matching semantics is the