The most important services in Figure 5.1 are the object services, the other services can be thought of as utility services, which are necessary for performing operations on the business objects which are residing in the object services.
5.3 Services 49
NamingService
TransactionService
SecurityService
ObjectService
DataService
TaskService Client
Client Client
Network/RMI
Fundamental services
Utility services One object service For a group of Business objects
Figure 5.1: Overview of the basic components in the distributed system
Two special services are also shown in the figure, which are the data and the task service. These services are more or less Zephyr specific, and the distinction between a service or a client is not so clear for these two services. In one sense the data and the task services can be considered as clients, as they are being served by some business objects.
5.3.1 Naming service
The naming service is simple. Each object service registers itself with the naming service, and when this happens, the object service informs the naming service about which business objects the object service is serving. Clients or other services can then use the naming service to look up the object service for a particular group of business objects.
In any well designed object oriented system an object instance should represent a unique identity. There should never exist two or more in-stances of an object which represent the same identity. This might seem obvious and easy to implement, but this is not as simple as it seems.
For instance, consider an object which represents a specific wind farm.
If two instance were created of this object, and two users were making changes to the state of these two instances, then we would end up with two different states representing the same wind farm. Therefore, each business object needs to be identified with a unique id. As the naming service is the registry of all object services, the naming service has the potential to generate unique id’s. The id is represented by a long value, which means that there are roughly 2·1019 unique id’s available.
The algorithm which is used to generate id’s is simple. The naming service does not generate the id itself, it generates seeds which are used by the object services to generated id’s for business objects that are created in a particular object service.
5.3.2 Object service
An object service is a business object manager. The problem with object uniqueness was mentioned in the previous section. It is the object service
5.3 Services 51 responsibility to keep track of the business objects. If a request is made for a business object with a particular id, this id is compared to a master list of business object instances. If the instance is in the master list, a reference to the business object is returned. If the id is not in the list, the object service creates a new instance of the business object. The state of the object is restored from the object store, the id of this object is added to the master list and a reference to the object is returned. The object service also manages the creation of new business objects and generation of id’s for new business objects.
The master list is implemented as a hashtable with a special kind of weak references to the business objects. This has to do with the Java imple-mentation of garbage collection. In the distributed garbage collection, the garbage collector thread has to poll the remote references which exist to the objects in the JVM. The master list request information from the garbage collector about references to business objects. When only one references exist to a business object, then this must be the reference in the master list. When this happens the object reference is removed from the master list, and the object is now free to be garbage collected.
The reason for using this implementation has to do with performance.
There is no need to fill up memory with business objects that are not being used, therefore, business objects which are not referenced should be garbage collected.
The object service also has some utility methods for browsing the busi-ness objects in the service, like information on how many objects of a give type are in the object store and methods for retrieving references to all objects of a given type. Furthermore, lookup queries can be executed on the descriptor property of business objects. The matching semantics and the descriptor property will be described in Section5.4.
5.3.3 Security service
The role of the security service is to authenticate users. Based on a user name and a password the security service generates a unique digital signature. The signature is created using the SecureRandom class in the Java API, and consist of 32 bytes.
Users are authenticated from a user database, where the user names and passwords are stored. A signature is only created if the user name and password match. All access operations on business objects are validated with the security service. As it is the security service which creates the signatures, it is the only instance which knows the particular combination of user name, password and signature. This concept therefore provides a high level of security.
5.3.4 Transactions and Transaction service
As mentioned previously, there is a need to group a multitude of opera-tions into a single atomic operation in a distributed system.
Three things happen when a user makes the first write request on a business object. The first step is to create a lock on the object. The lock is identified by the users signature, if the object is currently locked, and the signature holding the lock is not the same as the one requesting the lock, an exception is thrown. The next step has to do with the transaction. The transaction contains a factory method, when a write request is made on a business object, this transaction factory method is called by the business object, passing on the signature of the user who made the write request. If a transaction for the signature does not exist a new transaction is created and this transaction asks the transaction service to register this transaction. The transaction is responsible for making a copy of the business object state on the storage media, before the first write actually occurs. If the two first steps succeed, a snapshot is taken of the business objects state.
The transaction keeps track of all modified business objects which are being modified by a user with a particular signature. Each time a write request is made on a business object, the business object uses the trans-action factory method to get the transtrans-action for this signature. The business object then informs the transaction that the object has been modified.
One single user might have several transactions, this is the case if the user modifies business objects in several object services. As shown in Figure5.1the transaction instances reside in the object services, and the
5.3 Services 53 transaction service holds a registry of signatures to transactions. Once the user has finished modifying business objects, he only needs to make a single call to the transactions service with his signature, requesting that all his transactions should be saved.
The transactions service now calls the save methods in the transactions, which is turn call the save methods in all the business objects which have been modified as a part of the transactions. If the save operations succeed, the transactions service call commit on all the transactions, which is turn call commit on all the just save business objects.
Several things can happen during a transaction. A network error might occur, and if the user is only half way through his operation, the safest option is to restore the business objects back to the original state before the operation started. The user can then call the transaction service, requesting a roll back of his transactions. This results in a roll back or restore of all objects which have been modified so far as a part of the transaction.
If an error occurs between the save and commit phase of the transaction, the transaction is responsible for restoring the copy of the business object state on the storage media. The business object itself restore the state from the snapshot which was taken of the object before the first write occurred on the object.
If the user disappears, i.e. in the case of a network error, then the lock will not be renewed and the lock takes care of asking the business objects to restore themselves.
5.3.5 Data service
The data service is responsible for feeding data from the external sources into business objects residing in object services. These business objects, which in general are tables and columns, will be described later.
How the external data is provided to the data service depends on the particular utility. The data can for instance be fetched from a ftp server.
This is how the data from the Danish Meteorological Institute is provided
to the system, WPPT, running at the Danish utilities Elsam, Elkraft and SEAS.
Without going into details, the data service cycle is the following: The data service is running at specific time intervals. At each run the service checks for new data. When new data is available, the first step is to validate the data. Zephyr uses the validation model from the WPPT system described in Paper G. Once the data has been validated, the data is put into the target business objects, this happens via the business object proxies. A task is then created which contains the necessary code for calling update and predict methods in the affected business object proxies. The task is then sent of to the task service which executes the task, and the data service is ready to receive new data.
The separation of data retrieval and model calculation is important. The measurements are receive at a rather high frequency, namely in the order of minutes, and it can not be guaranteed that the model updates will be finished within this time frame. Therefore, the data service cannot wait, it has to be ready to receive new data before the model calculations are finished. The data which is received at high frequency does not need to trigger model updates, it is only when new weather predictions are received that the models need to be updated, in the current setup this is each 6 hour. This way the models can be quite complex, as they have a considerable time to finish the calculations.
5.3.6 Task service
The task service is quite simple. It executes tasks which are handed to it from e.g. other services or clients. A task is an object which implements a specific interface. The interface only requires that the task object implements a run method. The task service starts the task by calling this run method.
When a task is handed to the task service from some source service or client, the task service requires that the source specifies a reference to a remote object which implements a specific interface. This interface requires that the remote object implements a finish method. Once the task run method has finished running in the task service, the task service
5.4 The business object super-classes 55