(Rejected) 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 seriablizable.
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;.
Process that determines which components are remotely accessible.
TauZamanServiceManager, TauZamanService classes.
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 CalendricSystemManager, which manages the CalendricSystems living in the system. Since there may be more than one user using the same system, they may use single CalendricSystemManager 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 CalendricSystemManage? 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 CalendricSystemManage 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 CalendricSystemManager. 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 single CalendricSystemManager. (as in the above picture, so user in above picture is substituted by a tauZamanService 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 constructor. However, remotely this is not possible in Java RMI. A remote object (tauZamanService in our case) should be instantiated and registered in javarmiregistry first by server. But, this is not what we want, we want that a clients 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 scenerio;
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 yet another class, which is called tauZamanServiceManager, conforming to service and manager 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 tauZamanServiceManager, which produces tauZamanServices for users (either locally or remotely in a server case). To set up a tauZaman system as a server, all we have to do is registering this tauZamanServiceManager object with javarmiregistry and make url of the host visible to clients. By doing this, it can still server locally as well as remotely. If a setting up tauZaman system as a server is not what is wanted, then don't register it. It'll be just a client serving locally! One last thing to ask is, how will a tauZamanServiceManager knows whether it should form a remote tauZamanService or local? The answer is, it won't! If a user provides a url, then a remote tauZamanServiceManager (that corresponds to given url) will be invoked to produce a remote tauZamanService object and return it. Otherwise a local one will be formed. For a programmer, none of them is visible. Only thing she/he will have is, a tauZamanService ready to serve (if no problem occurs during object creating, such as MalformedURL, etc.).
How does it solve the second problem?
In client's tauZaman system, there will be one (local) tauZamanServiceManager, which can set one of tauZamanServices (remote or local) as active tauZamanService. So, when an instant is instantiated (which is always done locally!), all information that is needed is in the active tauZamanService (local or remote), which is pointed by tauZamanServiceManager (local). As can be noted, this is very similar to CalendricSystem and active CalendricSystem interaction. Should we need all tauZamanServices used by the user to be kept in a tauZamanServiceManager? 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 TauZamanServices, one local (tzs1) and the other remote (tzs2, 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). Each tzs (TauZamanService) keeps a table mapping from each loaded CalendricSystem to its private PropertyManager. Red line is drawn to make the distinction between active CalendricSystem reference in every TauZamanService object and active TauZamanService for every TauZamanServiceManager.
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 TauZamanService. 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 TauZamanService or should we get the related classes from corresponding TauZamanService 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 CalendricSystemManager, 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, CalendricSystemManager, 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 CalendricSystemManager, 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;
Reasons that we did not go with this design;
Main reason is having one class for both remote and local TauZaman services. From now on instances of this class (TauZamanService) will be referred as Possible Remote Object (PRO), since it is just possible for a TauZamanService to become a remote object.
It may create confusions for future programmers (maintenance).
A PRO should implement Remote interface even if it'll solely be used as a local object. but then PROs should extend UnicastRemoteObject, which registers any object activated (remote or local) with RMI. This creates problems, if we intend to activate a PRO but use it as a local object. There is a work around to this problem. We may not extend UnicastRemoteObject and the explicitly export the object to RMI by using a static method of UnicastRemoteObject. But for reliability issues, it is usually advised to extend it. [If one does not extend it, PRO should provide its own java.Object's methods, such as; hash, equals, string] Even if we don't extend UnicastRemoteObject, interfaces and remote methods of PRO should implement java.rmi.Remote and throw java.rmi.RemoteException.
As we touched at the end of item 2, A PRO's methods should have the capability to throw java.rmi.RemoteException [even the constructor]. That means even a local user should also catch them. This is not meaningful and desirable. A work-around would be to throw java.lang.Exception instead of RemoteException and wrap TauZamanException into java.lang.Exception. But this is worse, since a user may (and probably will) want to deal with specific Exceptions.
This design brings a full transparency to end-user in terms of TauZaman services. An end-user, who opened remote and local services can not know, which service is remote and which does not. What is the consequence of this regarding Distributed Systems;
If a user assumes that a TauZaman service is local, which is in fact remote, then this assumption may lead to long response time, unexpected behaviors (due to Distributed Garbage Collection, such as lease time of remote objects) and wrong handling of exceptions.
So, a distinction should be made between local and remote services. In an ideal world (ideal garbage collection, network) full transparency is favorable, however, not in our case. With this distinction system is still transparent, since methods remote and local services provide are same.
See other proposed (rejected) solutions for user registration process.