ARCHITECTURAL DESIGN
5.1 Architectural choices
To fulfill functional and non-functional requirements, it is indispensable to adopt a service-oriented multi-tier and multi-layer architecture with the most common and recent standards.
The idea is to distribute the application over multiple computers, structuring the system into a set of physical tiers using Web Services for communication; each tier then will be splitted into layers using components spanned across multiple levels of abstraction.
Using a service-oriented architecture (SOA) involves the creation of one or more independent services, with defined interfaces, which can be called to perform their tasks in a standard way, without having foreknowledge of the calling application and without the application having knowledge of how they actually perform tasks.
A tier is composed of the programs running on one or more computers that share one or more of the following characteristics:
• system resource consumption profile – the components hosted on the tier’s computers may use a set of system resources in a similar way (server configuration is optimized on a tier basis)
• operational requirements – tier’s computers often share common operational requirements, such as security, scalability, availability, reliability and performance
• design constraints – a tier may be dedicated to computers that share a common design constraint
A layer is a part of a tier composed of one or more modules, at the same level of abstraction, which share the implemented tier’s functionality and provide services to other layers.
Each layer should be loosely coupled to the layers underneath: components in one layer can interact only with peers in the same level or components from lower levels.
There are two general approaches to layering: strictly layered and relaxed layered.
A strictly layered approach constrains components in one layer to interacting only with peers and with the layer directly below.
A relaxed layered approach loosens the constraints such that a component can interact with components from any lower layer.
In this way efficiency can be improved because the system does not have to forward simple calls from one layer to the next; on the other hand, the relaxed approach does not provide the same level of isolation between the layers and makes it more difficult to swap out a lower layer without affecting higher layers.
It is quite common for enterprise application architects to compose their solutions into the following three layers:
• presentation – responsible for interacting with the user (UI)
• business logic – implements the business functionality of the solution
• data access – encapsulates the code that accesses the persistent data stores such as a file or a database
The word layer is often used interchangeably with tier; however there is a distinction between the two: conceptually, a tier is the hardware equivalent of a software architecture layer; whereas layers logically structure application’s components, tiers physically structure solution’s servers.
Using the approach depicted above has the following benefits:
− maintenance of and enhancements to the solution are easier due to the low coupling and the high cohesion between the layers and the ability to switch out varying implementations of the layer interfaces
− other solutions should be able to reuse functionality exposed by the various layers, especially if the layer interfaces are designed with reuse in mind
− distributed development is easier if the work can be distributed at layer boundaries
− distributing the layers over multiple physical tiers can improve scalability, fault-tolerance and performance
− each tier can be optimized for specific resource usage profiles
− each tier can have a different security profile
− each tier can be designed for different operational characteristics
− each tier can be separately modified to respond to changes in load, requirements, hosting strategy and so on; this flexibility tends to reduce overall total cost of ownership, because servers can be added and removed as the business requirements and technical environment change
− tiers can be deployed to meet geographical, political and legal requirements
− tiers ease some of the administrative and deployment burden associated with distributed solutions
GRAssTrack multi-tier architecture could be illustrated as follow:
FIGURE 5.1 – GRAssTrack multi-tier architecture
Almost all tiers use a multi-layered application to provide their functionalities:
• GRAssTrack Mobile (GTM) is appointed to data collection on Psion handhelds and synchronization with the server
• GRAssTrack Server (GTS) implements the SOA exposing a Web Service and deals with database operations, that is storage and synchronization: GTM synchronization concurrency is not accidental, so, instead of locking the database to avoid it, GTM collected data will be initially inserted in a buffer table and only from time to time they will be really synchronized
• GRAssTrack Job Runner (GTJR) is responsible for launching synchronization on GTS every now and then
• GRAssTrack Desktop (GTD) provides information about tracked assets and their location displaying it on a map or a plan and helps in making logistics decisions; GTD will not be developed because it does not fall within the specified requirements
5.2 Software architecture
The programming language that will be used is C#.
The spoken name of the language is “C sharp” in reference to the musical sharp sign, which increases a tone denoted by a letter (between A and G) by half a tone; for ease of typing it was decided to represent the sharp sign by a pound symbol, which is on any keyboard, rather than the “musically correct” sharp sign.
The sharp symbol is based on four plus signs, a representation of two C++
increment operators.
C# is a modern garbage-collected runtime-compiled language developed by Microsoft as part of the .NET initiative and later approved as a standard by ECMA and ISO.
This language has a procedural, object-oriented syntax based on C++ and includes aspects of several other programming languages, most notably Delphi and Java, improving them with additional new features and changes and a particular emphasis on simplification.
The de facto standard implementation of the C# language is Microsoft’s C#
compiler, included in every installation of .NET Framework SDK, used inside Microsoft’s own Visual C# IDE and directly invoked from Borland’s C# Builder and the open source SharpDevelop IDEs.
Alternative C# compilers are:
• Microsoft’s Rotor project – currently called Shared Source Common Language Infrastructure and licensed for educational and research use only, provides a shared source implementation of the Common Language Runtime (CLR), a C# compiler and a subset of the required Common Language Infrastructure (CLI) framework libraries as they appear in the EMCA specification
• The Mono project – provides an open source C# compiler (written in C#
itself), a complete open source implementation of the CLI including the required framework libraries as they appear in the EMCA specification and a nearly complete implementation of the remaining Microsoft proprietary .NET class libraries (libraries not documented or included in the EMCA specification but included in Microsoft’s standard .NET Framework distribution)
• The DotGNU project – provides an open source C# compiler (written in C), a nearly complete implementation of the CLI including the required framework libraries as they appear in the EMCA specification and subset of some of the remaining Microsoft proprietary .NET class libraries
5.2.1 GRAssTrack Mobile
.NET Compact Framework (.NET CF or NETCF) is a much smaller set of class libraries than the .NET Framework tuned for size and performance for devices.
Applications to be run on Windows CE .NET 4.2 could be developed with Visual Studio 2003 using .NET CF 1.1.
Visual Studio 2005 Windows CE 5.0 projects can also be used to develop applications for Windows CE 4.2 based devices, since .NET CF 2.0 SP1 supports them, but GUI problems may arise.
Therefore VS 2003 will be used for GTM and this will greatly impact on development time because .NET CF 1.1 lacks support for serial communication (serial ports, Bluetooth, GPS), configuration files, XML Schema-Validation, Xpath, thread handling (join, abort and other useful methods are missing as well as thread protection management) and functionalities provided by the controls that are supported (many other controls are missing).
Microsoft recommends OpenNETCF Smart Device Framework to enrich and extend the .NET CF with a set of class libraries and controls libraries which help bridging the gap between the compact and the full framework; thus OpenNETCF will be used when needed.
GTM will have the following architecture:
FIGURE 5.2 – GTM package diagram
5.2.1.1 Settings
.NET CF does not support configuration files, so a very simple form of
“App.config” XML file containing key-value pairs of settings will be used.
FIGURE 5.3 – Settings clas diagram
XmlSettings will implement settings retrieval, while AppConfig will be used to do type checking and error management.
5.2.1.2 Power management
Every mobile device is equipped with a battery, so, in order to to make it last as long as possible, it is necessary to manage power, turning off software and hardware components that are not currently used.
Power management package will contain:
• PowerManager abstract class – used to turn on/off Bluetooth and Wi-Fi radios and the RFID reader as well as to monitor the insertion of the handheld into the cradle
• CradlingMonitor class – used to monitor the insertion into the cradle
• PsionTeklogix package – containing a specialization of PowerManager that uses device dependent libraries (extensibility adding more packages)
FIGURE 5.4 – Power management class diagram
5.2.1.3 GPS
To read data from a GPS receiver is indispensable to use serial communication and process data as it arrives.
Fortunately the bulk of the work is done by the OpenNETCF SDF and only few other classes will be necessary to orchestrate the whole.
FIGURE 5.5 – GPS class diagram
5.2.1.4 RFID
The use of an internal RFID interrogator requires serial communication to get data read from the tag.
Serial port management is implemented in OpenNETCF libraries, so only classes to interact with them are needed.
FIGURE 5.6 – RFID class diagram
5.2.1.5 GTM core
This is the heart of GRAssTrack Mobile and will have a three-layer architecture.
FIGURE 5.7 – GTM core class diagram
Using the packages described above, GTM core classes will load settings, manage power, manage user interface, receive GPS and RFID data, store information in an XML file and synchronize it with GTS: all GTM requirements will be fulfilled.
5.2.2 GRAssTrack Server
GTS will be developed with VS 2005 (.NET Framework 2.0) and will provide a Web Service, callable from GTM and GTJR, to synchronize data with GTSDB.
The WS will run on Microsoft IIS web/application server.
FIGURE 5.8 – GTS package diagram
FIGURE 5.9 – GTS core class diagram
All packages have been detailed together with GTS core because they will contain only one class.
Obviously Mail package and Mailer class will be used to implement an SMTP client so that it will be possible to send administrative emails in case of errors.
Operation class will be used to validate and verify XML input data and to convert it into a form that can be easily stored in the database.
DbAccess will perform database CRUD operations using AnyDbProvider that will in turn call the database driver written for .NET development by the DBMS producer.
AnyDbms package and AnyDbProvider class will be used to give the user much more flexibility in the choice of the DBMS: thanks to Microsoft DbProviderFactory, a great example of the abstract factory design pattern, data access could be made generic or provider independent (DbProviderFactory is an abstract base class and every driver must provide an implementation for it).
This provider agnostic approach is a great enhancement introduced in the .NET Framework 2.0 and is supported by IBM DB2, Oracle Database, Microsoft SQL Server and MySQL, the most important database servers (SQL Server will be used).
5.2.3 GRAssTrack Job Runner GTJR has the following architecture:
FIGURE 5.10 – GTJR package diagram
Except for Job scheduler, all packages have been detailed together with GTJR core because they will contain only one class.
FIGURE 5.11 – Job scheduler class diagram
FIGURE 5.12 – GTJR core class diagram
Job scheduler package is appointed to provide a .NET wrapper to Windows Task Scheduler COM objects.
ScheduledTasks, Task and TriggerList will use Interop package classes and interfaces to access COM objects, while Triggers package will contain classes which represent the events that trigger the execution of a task.
GTJR will be scheduled with Job scheduler to run database synchronization tasks.
It has a four-layer architecture in which Program is a class used to decide whether to use a GUI or not: in GUI mode GTJR let the user choose schedule start time and interval (from 1 to 24 hours), while in “silent” mode it calls GTS Web Service to perform synchronization.
Mail package and Mailer class are the same used in GTS and will be used to implement an SMTP client so that it will be possible to send administrative emails in case of errors.
Event logger class will be used to log success or failure so that they can be showed by Windows Event Viewer.
