Implementing the management system

The implementation of the management system was quite comprehensive and took just a bit less than a quarter of the entire project duration, totaling 7747 lines of PHP code and 799 lines of HTML. Although quite some design changes took place during this period, the requirements were implemented easily due to the clear structure of the system.

One of the largest changes in the project was in the set of use cases. At first various use cases were defined very distinctively from one another, including: PutHotspotUp, PutHotspotDownForMain- tenance, DeployNewAPFirmware, DeployNewHotspotConfiguration, PutFirewallTunnelUp, Put-

FirewallTunnelDown, SendNetworkAnnouncement and RetrieveUsageStatistics. Due to the fact that most of these use cases are quite different from the other use cases means the design can get (unnecessarily) complicated.

The first choice was to drop the use case RetrieveUsageStatistics. This use case was introduced for roaming partners to retrieve usage information of their users who have roamed onto the Mobidot network. This information can however be sent automatically (without user initiation) to the roam- ing partner by means of an extension of the RADIUS protocol, and this functionality is implemented by the Chillispot captive portal.

Another choice was to embed SendNetworkAnnouncement into the management of hotspots and ac- cess points. Essentially a network announcement needs to be sent only when the hotspot goes down temporarily for maintenance, it preferably will never be needed for any other cause, as we don't want to bother the user too much. As such it is unnecessary to model it as a separate use case. Yet another choice which led to the removal of use cases was the choice to use permanent firewall tunnels instead of temporary firewall tunnels. These tunnels are needed to enable the use of proto- cols such as SNMP in cases where the Mobidot AP is not directly addressable, for example in SNAT-enabled networks. The reason why this was needed will be discussed in the 'Problem domain' section of the first chapter. This choice led to the removal of the PutFirewallTunnelUp and PutFire- wallTunnelDown use cases.

The final choice (related to the changes in use cases) was composed of the removal of several use cases, but all for the same reason. The remaining use cases in essence all adjust the state of the sys- tem in one way or another. Such actions can be caught in general management use cases. For ex- ample PutHotspotUp and PutHotspotDownForMaintenance just adjust the status of a hotspot, and basically are edit operations in the management of hotspots. Further, DeployNewAPFirmware basic- ally is an add operation in a firmware management use case. The DeployNewHotspotConfiguration use case can be dealt with in the same way. Due to these changes also a new composite use case is introduced: ManageFirmware.

Some other changes were made in the modeling of parts of the system in terms of class diagrams. First of all, during the design phase the choice was made to create helper classes which would aid in the creation of the necessary HTML output. During the implementation however, a very handy tem- plate engine was found, which could generate HTML from text files with variable substitution. Due to the use of this engine, the helper classes could be dropped. Another, more important, design change was the choice to drop the differentiation between master and slave access points. Rather, access points would be looked at as stand alone units. Each access point offers wireless access to the neighborhood it is placed in, and as such it doesn't need to know about fellow access points. It only needs to deal with wireless IP traffic, and it needs to know where to hand it off to.

Further, the distinction between Mobidot users and users from roaming partners was dropped, as this is (in terms of usage logging, authentication checks, etc) already taken care of by Chillispot. From then on, users would be modeled by an UserAccount object, making the design again easier. Lastly, having separate Status classes (HotspotStatus, APStatus) also made the design unnecessary difficult, particularly because there is little status information, so it can just as well be handled in- side the Hotspot and AP objects.

Finally, a problem was encountered in the storage back ends. It was chosen to implemented it in a very general manner, such that it can be reused for storing any type of information. This was done using the bridge pattern, and using only a pre-defined set of functions in the implementer classes. As

such there were basically four operations: get, insert, update and delete. This however limits the us- ability of the storage back end, as it can only perform as much as these pre-defined functions can perform. Without adding functions it was possible to add just enough functionality to the existing functions to support more extensive queries, i.e. for sorting data in a particular order, paginate re- cords and operate on multiple sets of data in one shot. This was done by using arguments which were unused by default, unless they would have a value. Further, in situations where it was needed, database transactions would be composed of multiple queries, i.e. creating, updating or deleting con- figurations, including their firewall and traffic shaping configurations.