tauZaman DESIGN DECISIONS (User Registration)
Problem comes from the idea of setting up tauZaman system as a server.
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.
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;
ones, which are defined as remote objects.
ones, which are defined as serializable objects.
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;.
TauZamanSystem, TauZamanRemoteServiceHandlerImpl, TauZamanRemoteServiceImpl, TauZamanLocalService classes and TauZamanRemoteServiceHandler, TauZamanRemoteService interfaces.
tauzaman.timestamp
Granule, TimeValue classes.
tauzaman.calendricsystem
Granularity (since Granule contains Granularity in it)
tauzaman.calendricsystem, tauzaman.timestamp
all classes except above
tauzaman.calendar, tauzaman.field, tauzaman.temporaldatatypes, tauzaman.property
all classes
After defining the types of different TauZaman classes, now let's try to design the over-all client/server structure.
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.
One question that may arise is that, why don't we keep CalendricSystem, PropertyManager tuples in CalendricSystemRepository? The answer is, this structure is more intuitive. A user owns a PropertyManager and it should keep in its proper space. Also keeping them in CalendricSystemRepository will incur more indirections to uniquely identify each user and its CalendricSystems and their PropertyManagers.
Now, from this picture we can understand that we have to derive another class, called TauZamanService, which users can initialize their own objects. These objects help to load CalendricSystems via a single CalendricSystemRepository. So, a client who wants service of a specific TauZaman system should have a TauZamanService object of that system, which in turn has a reference to that TauZaman system's unique CalendricSystemRepository. (In the above picture, user is substituted by a TauZaman(Local/Remote)Service object.) Be aware that a client can also have a local service, which is a TauZamanService object formed by its own TauZaman system.
Having defined TauZamanService class, one may ask two important questions.
1. How can a client, who wants a service of a TauZaman system (locally or remotely), get a TauZamanService object. Locally this is easy since one can always instantiates a class by using its public constructor. However, remotely this is not possible in Java RMI (except using Remote Object Activation). A remote object (TauZamanService in our case) should be instantiated and registered in java rmiregistry first by server. But, this is not what we want, we want that client should have their own TauZamanService remote objects and they want to form when they want.
2. If a client gets several TauZamanServices from several TauZaman systems (possibly including local one), it has to manage them eventually. For example, let's look at this scenario;
A client has 4 TauZamanService objects from 4 TauZaman systems. One of these systems is its own local system. And after configuring them (loading CalendricSystems and pushing some Properties for formatting) individually, it executes this line;
Instant i = new Instant("<date> September, 20, 2002 </date>");
what happens next? Constructor of local Instant class will be called, and some TauZaman service should parse the string according to some format and form the timestamp. But where is this TauZaman service and which service we are talking about? Since there are 4 services registered by this client.
To resolve these two problems, we have to have two other classes, which are called TauZamanSystem and TauZamanRemoteServiceHandler, whose names conform to service and management understanding through out the whole design decisions.
How does it solve the first problem?
As we stated, a TauZaman system can be server, client or both. No matter what type, each TauZaman system should instantiate a single TauZamanSystem, which provides TauZamanLocalService to local users and provides TauZamanRemoteServiceHandlers, which allows remote users to connect and get TauZamanRemoteService.
To set up a TauZaman system as a server, all we have to do is registering this TauZamanRemoteServiceHandler object with java rmiregistry and make url of the host visible to clients. Note that without going through this process, TauZamanSystem can still serve locally.
For an end-user parent TauZamanSystem is the only way to get a local or a remote service. And to provide both, TauZamanSystem includes two methods; one of them asks user a URL, which is the URL of a remote TauZamanRemoteServiceHandler and returns a TauZamanRemoteService, which is a remote object of another TauZamanSystem, the other method does not take any URL and returns a TauZamanLocalService.
For a programmer, the difference between a remote and a local object should be visible (see reasons). However, methods both TauZamanRemoteService and TauZamanLocalService include are same (actually TauZamanRemoteService contains an instance of TauZamanLocalService in its host). And in that sense process is transparent to an end-user.
How does it solve the second problem?
In client's TauZaman system, there will be one (local) TauZamanRemoteServiceHandler, which can set one of TauZaman services (remote or local) as active TauZaman service. So, when an instant is instantiated (which is always done locally!), all information that is needed is in the active TauZaman service (local or remote), which is pointed by TauZamanRemoteServiceHandler. As can be noted, this is very similar to CalendricSystem and active CalendricSystem interaction. Should we need all TauZaman services used by the user to be kept in a TauZamanRemoteServiceHandler? No, since it is programmer's responsibility to keep them.
Now, let's look at figure 2 to try to see all these design decisions in one picture.
3.1 Explanation of Figure
In the above figure, a user in the client side opened two TauZaman services (note that there is no java representation of TauZamanService; a TauZaman service can be local, TauZamanLocalService or remote TauZamanRemoteService), one local (TZLS) and the other remote (TZRS, which is drawn on both client and server side. But it is drawn blurry in client side and bold in server side to reflect that it is a remote object residing on server side). Note that TauZamanRemoteService, TZRS, is provided through, TauZamanRemoteServiceHandler, TZRSH, which is set by a local user (admin) in Server side. Each TauZaman service (TZRS and TZLS) keeps a table mapping from each loaded CalendricSystem to its private PropertyManager.
3.2 An Abstract Example
Let's assume that a user desires to form an Instant, "September, 17, 2003" by using both a local and remote TauZaman service. To interpret "September, 02, 2002" our user wants to use Gregorian Calendar of american Calendric System.
see the java code.
There is one problem may be raised about the above code. We did not activate any Property other than default ones, although we could. Or although it is transparent to the user, Instant constructor will make use of (local/remote depending of active service) Input class to parse the passed input string. The trouble is, should we perform all Calendar related operations through methods of corresponding TauZaman service or should we get the related classes from corresponding TauZaman service and apply operations on instances of those classes. To make it clear see the distinction between these piece of codes;
Code Style 1
/* get the Property Manager corresponding to active Calendric System in local service */
PropertyManager pm = localService.getPropertyManager();
/* form the names of focus Properties */
String focusPropertyNames[] = {"InstantInputFormatProperty"};
/* activate the Property */
pm.propertyActivate(new URL("http://www.eecs.wsu.edu/~burgun/otherProperties.xml"), focusPropertyNames);
Code Style 2
/* form the names of focus Properties */
String focusPropertyNames[] = {"InstantInputFormatProperty"};
/* activate the Property without getting handle to PropertyManager */
localService.propertyActivate(new URL("http://www.eecs.wsu.edu/~burgun/otherProperties.xml"), focusPropertyNames);
So what are the differences;
Latter code style has no handles to Calendar related services, such as CalendricSystemRepository, CalendricSystem, Property, Input, Output, etc. That means we don't have to declare these classes as Remotes. That helps in three ways;
Reducing the number of remote objects will make system reliable and secure. (weak reason)
Reducing the number of remote objects will make code seem less complex in client side. (another weak reason)
Reducing the number of remote objects will reduce response time since there will not be extra communications to get remote objects from server. (a good one, especially with Input and Output)
Having no handles to those classes also mean that, we have to have their services as methods inside TauZamanService class. Such as, propertyActivate(), propertyDeactivate(), loadCalendricSystem(), parseInput(), parseOutput(). The problem with this is TauZamanService class will have a union of some methods of in classes, CalendricSystemRepository, CalendricSystem, Property, Input and Output. This number may be 10-12. In short, an instance of TauZamanService will be a bundle, which provides user a bag of methods to interact with Calendar related services only.
On the other hand, having handles to each Calendar related classes CalendricSystemRepository, CalendricSystem, Property, Input and Output by making them remote has this advantage;
More flexibility for a experienced user. (Normally a user may not want to deal with CalendricSystem and Property separately!!)
We have to make a decision between these two ideas. It seems code style 2 is slightly better than the first with the idea of containing a bag of methods related only to Calendar services. After all tauZamanService is all about this. But, by this we repeat the functionality that we had in Calendar related classes in TauZamanService class.
Having read these, analyze the 3 different example usage of TauZaman system;
See other proposed (rejected) solutions for user registration process.