This document is intented to be a brief description of the architecture of the Test system. Will also include comments on the decisions made and a summary of the configurations that the system allows.

The prototype is divided in three areas: Clients, Internal Infrastructure and External systems (Diagram.png):

- Clients contains the simulations of the mobile clients. 
	Projects are located in the "Clients" solution folder:
	WebForms asp.net application that will simulate three mobile clients classic + JQuery(Default.aspx), KnockoutJS (Knockout.aspx) and AngularJS (Angular.aspx). In addition to that a Class library with Basic business logic is placed inside the same solution folder.
	
- Internal Infrastructure.
	Models the system that is in charge of getting information from the third party systems, transforming it and exposing it to the mobile clients via JSON WebService.
	BookingService: Exposes functionality to the mobile clients (GetAvailability, GetLastRequests)
	BookingModule:	Contians the business logic, Data Access, and entites (Availability Requests can be persisted on a local SQLCompact or a remote SQLServer database)
	CoreLibrary: Commo Util functions and Objects
	FeatureAccessLibrary: Common interface to access functionality (Bookings in this case). Exposes an interface that the external systems, via a simple Service locator, external systems are registered.

- External Systems.
	Here the proxies to the external systems are placed.
	ThirdPartyBookingLibrary is implementing the IBookingSystem interface. A mapping of the objects from the service reference to the common "BookingModule" objects is done.
	ThirdPartyMockService. Simulated version of the provided service, with the same public interface, used for testing, development, and as an example of the Service registration for the "Feature Access" concept.
	ThirdPartyMockBookingLibrary proxy to the mock service, analogue to ThirdPartyBookingLibrary.

Comments:
---------------------------------------------------------------------
The Provided webservice is not working at the moment, so everything is configured to use the mock service.
To change it back to the real one or an updated url, please change:
BookingService/Web.config:
<add key="UseMockService" value="true" />	set to false to use the one defined below
Correct url
<endpoint address="http://ec2-54-254-233-245.ap-southeast-1.compute.amazonaws.com/Ink.CandidateTest_deploy/Service1.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IThirdPartyBookingService" contract="ThirdPartyBookingServiceReference.IBooking" name="BasicHttpBinding_IThirdPartyBookingService" />
	
Infrastructure considerations:
---------------------------------------------------------------------
All projects hosted on the local IIS:
- BookingMockService
- BookingService
- BookingWebFormsClient
If the IIS Features were activated after .Net Framework installation, please execute "aspnet_regiis -i" in order to have the project working.

In addition to that, deployed versions of the following elements can be found:
BookingService: http://albertobolsa.com/BookingMockService/BookingService.svc?wsdl
ThirdPartyMockService: http://albertobolsa.com/BookingService/BookingService.svc
MobileClients: inkglobaltest.albertobolsa.com

Commented ServiceReferences, and Endpoints for the available systems can be found on App.config and Web.config inside the involved projects. 

Connection Strings
------------------------------------------------------------------------
The system can persist data to a SqlCompact Database or a SqlServer Database
Both options are ready to use and only need to be selected inside the Web.config inside the "Booking Service" project.
Sql Scripts can be found inside "Booking Module" project.
The data access layer is done using native ADO.net, an alternative would be using Entity framework, NHibernate, custom generated code based on the database structure, or non relational like MongoDB. As I didn't know the performance requirements, I took the simplest as a placeholder, and only a change on the DataAccessLayer would be required to change the data access policy.

Configuration Keys
-------------------------------------------------------------------------
The next elements can be configured inside the Booking Service:
MaxRequestsToDisplay: Number of Availability requests that the user will recieve.
LogAvailabilityRequests: Boolean flag indicating whether to log the availability requests on the database.
UseMockService: Boolean flag to register the real service or the developed mock service.

Resources:
------------------------------------------------------------------------
I've decided to use only a Common Resource file per Client because the number of elements I will have to use are limited, that should follow company guidelines, but for simplicity reasons I've only "prefixed" the keys with things like "H_" for headers, "BTN_" for button texts, etc .. and I've used no prefix for Resources that might be used many times for different things.

"Dependency Injection"
--------------------------------------------------------------------------
In order to get flexibility on the number and shape of the third party systems that can be used. I've implemented a simple Service Locator.
External system proxies implement a common interface, and an instance of that implementation is registered for use via "Feature access library".

DatePicker control:
-------------------------------------------------------------------------
For consistency across versions of the application I've used an opensource calendar (http://eternicode.github.io/bootstrap-datepicker) based on bootstrap, other good options, but with license required would have been KendoUI (Favourite) or Telerik asp.net server side control.


