This Lab is a first step of the course (Session 1 + Session 2).

The main idea of this lab is to develop and deploy an intermediary Web service (IWS) between the Velib WS and some WS clients.

A first and minimal release of your lab project must consist in :

• a local Intermediary Web Service (on your own PC) that exposes a WS-SOAP API to access to the Velib Web Service (see lectures of session 2)
• a console client that allows to access to the IWS and request for the list of velib stations for a given city and the number of the available Velib at a given station.
  • Choose your own interactive instructions for that and add a “help” one to display all details about them.
  • Test this client not only on your PC but also remotely

You must now choose extensions of your project according to your technical affinity. These extension may concern different topics according to your centers of interest. The architecture will consist in a chain : Velib WS - IWS (Intermediary Web Service REST to SOAP) - Client of IWS

Topics are :

• Graphical User Interface for the client (Grade Scale : 6 points). Winforms is only an old simple framework to prototype basic graphical interfaces. Here, you can rather developp Web interfaces with WebForms (close to winforms design method to easily implement dynamic and interactive asp.net web pages) or other graphical client in other plateforms.
• Asynchronous Access : Replace all the accesses to WS (beetween Velib WS and IWS, between IWS and WS Clients) with asynchronous ones. Some indications can be find just below. (Grade Scale : 3 points)
• Cache management Add a cache in IWS, to reduce communications between Velib WS and IWS and propose various cache management policies (Grade Scale : 10 points)
• Functional extensions : use the google API and Velib API to plan the best way from one place to another using Velib (Grade Scale : 10 points)
• Security extension : user registration, tokens management, encryption. If the cache management providew variable Quality of Service accoding to subscription, tokens are necessary for billing (Grade Scale : 6 points).

• Of course the main interest of IWS is to be a kind of proxy in your company network to manage accesses to the external Velib WS. The natural architecture for that is to deploy IWS on a local server for virtualization for example with docker. Be careful this operation is not so simple because IWS must be a .Net Core project to deploy it on docker and unfortunately complete WCF is not supported on ASP .Net Core (only the client part in WCF !). Some indications can be find just below. (Mark Scale : 10 points)

• Extend IWS with monitoring functionalities, i.e. various indicators that you can get and compute about the IWS activity. For example, the number of clients during a given period, the number of client requests during a given period, the current average delay for the IWS to response, the number of requests on WS Velib during a given period and more according to your extensions (ex. cache monitoring). Your creativity is key to find various relevant indicators mainly based on statistical methods. All this information will be accessible through a second WS attached to IWS. A specific client will be developed to access to this Monitor WS remotely. This specific client will display some of this monitor information graphically or textually using some console tools. (Mark Scale : 5 points)

WS-Soap on .Net Core

BACK