JY Tigli Homepages

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== REST and SOAP WS, VELIB Project ======

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

{{ :cours:ws-rest_and_ws-soap:wsveliblabarchi.png?400|}}

==== Velib Gateway Web Service ====

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

==== Choose your Extensions ====

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 : 

== Development : ==
  * **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)**.

== Deployment : ==

  * 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)**

== Monitoring ==
  * 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)**
 
==== Choose your partner and your contract ====

<note warning>
Fill this [[https://docs.google.com/forms/d/e/1FAIpQLSfSdZc46U0-E6RMsV5T8W0qnUb0oYeSPbEiEFUEPiwaKBlFZQ/viewform|formular]] before April 2nd (02/05/19, 00:00)

</note> 

==== Evaluation of the Lab ====

<note warning> 

Le projet sera mené en binôme mais lors de deux dernières séances du module, une audition de 5 min. étudiant par étudiant permettra d'évaluer votre investissement ** personnel **

Le Projet sera évaluable à partir semaine 20 et de la version déposée sur votre GitHub. 

Sur votre GitHub, vous rajouterez un README qui contiendra la liste des extensions ci-dessus rajoutées et testées.

** Il contiendra aussi étape après étape toutes les phases pour tester la compilation, le déploiement et le monitoring de vos projets.**

** Il contiendra aussi une présentation graphique type slides de votre architecture et des extensions traités **

** vous devrez aussi présenter les extensions que vous avez traitées seul ou votre % d'investissement dans une extension traitée à deux. Cela devra être fait en collaboration avec votre binôme car la somme des investissements doit être cohérente**

Si votre adresse de GitHub est erroné ou non publique sans que vous m'ayez donné l'accès, le projet sera considéré comme non rendu.  

</note>


===== Complementary Tutorials  =====

=== Async / Await Task and WCF  ===

=== WCF and Web Services Programming for Docker ===
|||

|OS or Docker for OS | kind of container | kind of Framework | Complete WCF | WCF Client Side | 
|Windows||.Net Framework|Y||
|Docker for Windows|Windows|.Net core 2.0|N|Y|
|Docker for Windows|Windows|.Net core 2.0|N|Y|
|Docker for Windows|Linux|.Net core 2.0|N|Y|
|Docker for Linux|Linux|.Net core 2.0|N|Y|

=== WS-SOAP with ASP .Net Core ===

==== WS-Soap on .Net Core ====
[[cours:ws-rest_and_ws-soap:Soap-core|]]



[[https://www.tigli.fr/doku.php?id=cours:service_oriented_computing_and_web_services_2017_2018|BACK]]