Problem comes from the idea of setting up tauZaman system as a server.
1. Problem definition
At the website cs.arizona.edu, a tauZaman server is running. The server performs I/O in the Gregorian, Astronomy, and Islamic calendars. Christian at Aalborg and Curtis at WSU both want to use the service, but Christian wants his dates formatted differently (in Danish) than does Curtis (in English). So Christian starts a session with the service, then pushes the format properties that he would like. Curtis does the same. Christian then asks the server to create several instants by calling the Instant constructor. He passes a string containing a date (in Danish) to each constructor.
The problem is that in both Multical and timeADT (and our current design of tauzaman) the properties are stored in the CalendricSystem object. There is a single copy of each property (or property stack). In the above scenario, this means that since I pushed my formats after Christian pushed his, then when Christian tries to format a date, he uses my properties.
To implement a CalendricSystem service we somehow need to have each user have their own properties. So the properties have to be stored or association with user specific session.
2. Proposed Solution
The most important design criteria for TauZaman client and server are (in order);
- There should be no difference of code in server and client from the view of user (programmer). A TauZaman system might be client, server or both at the same time. The only difference is to set up a system as a server (server only) or client (client only) or use a server also as a client (server and client both).
- For a client, client's resources should be utilized as much as it can be. This means that, temporal data types (such as Period) and operations on them and operations related issues (such as LeftOperandSemantic) will be kept and handled in client side.
- First criteria reveals a difference in our system from general Java RMI designs. Generally, Java RMI designs (Distributed Systems in general or RPCs) consists of three components; Server, Client and the Servant. Server and Client share an interface, which Servant implements. And Client using this interface's stub, manage to connect Server and use service of Servant. But in our case, both client and server actually implements all interfaces, so in that sense there are no interfaces. But they both have same classes and can use one another's remote objects. And in this sense, they are both Servants.
- Under these criteria (especially from the second one), server notion of TauZaman is really consist of formatting of time values and Calendar support only. All underlined temporal data types and their operations will be handled in client. This understanding leads to specialization of classes in TauZaman into three;
1. ones, which are defined as remote objects. 2. ones, which are defined as serializable objects. 3. ones, which are neither remote objects nor serializables. (normal classes)
First type is needed, since we want to utilize a server's service but we want to do it transparently from the programmer. In other words, from the usage of a remote service, a programmer should not be aware of whether this service is a remote or a local one. Remote objects are formed in server sides and are passed to client as references.
Second type is needed, since when we form a temporal data type, we may need a remote service to parse a string temporal constant and return a Granule array to us. Since we want temporal data types live locally in client side, we have to pass server side produced Granule array by value. So, we have to declare Granule class as serializable.
Third type consists of other classes, which don't involve in client/server side interaction. For example, Instant, LeftOperandSemantics, etc.
Having stated types, let's try to identify them for each class in tauzaman package by package;.
2.1 Define Remote Objects
tauzaman
2.2 Define Serializable Objects
tauzaman.timestamp
tauzaman.calendricsystem
2.3 Define Normal Objects
tauzaman.calendricsystem, tauzaman.timestamp
tauzaman.calendar, tauzaman.field, tauzaman.temporaldatatypes, tauzaman.property
After defining the types of different TauZaman classes, now let's try to design the over-all client/server structure.
3. Structural Design (Client/Server)
Every TauZaman system has one CalendricSystemRepository, which manages the CalendricSystems living in the system. Since there may be more than one user using the same system, they may use single CalendricSystemRepository to load and use different CalendricSystems. Each of these users will have their own active CalendricSystem, which will be chose from their CalendricSystem set. Also, each of these users will have a PropertyManager for each different CalendricSystem they have, since one user may want to use one set of formatting properties and other may want to use others independently without any conflicts. Let's see all this in Figure 1 below.
