Discussion :

[neuropathie]

Bonjour,
Je dois mettre en place une architecture de projet en technologies Microsoft. Le projet consiste en la mise en place d'une API. Cette API doit par le biais de Webservices prendre des données sous format XML d'un middleware, traiter ces données pour remplir une base de données.
D'un autre côté des application Web et mobiles peuvent à n'importe quel moment par le biais de webservices contacter l'API pour interroger la base de données.
Ma proposition est basée sur du ASP.NET, C#, Linq, entity Framework.

Est ce que quelqu'un aurait une idée ou une aide à ce sujet, sur les technologies mais plus en terme d'architecture de l'API.

Merci d'avance.

[chamamo]

D'après ce que tu viens de décrire, je pencherai pour ASP.NET Web Api.

[DotNetMatt]

Ca dépend, ASP.NET Web API est très bien pour des projets légers, type appels en AJAX (REST/JSON), et surtout pour des besoins très classiques.

Cependant si on a besoin de gérer des scénarios particuliers (type one way messaging, queues de messages, duplex, etc.), ou encore si on veut utiliser des canaux de communication rapides (TCP/UDP/Named Pipes...), il faut se tourner vers WCF.

Donc ça dépend pas mal de ton projet, si les communications passent pas internet ou si tout se fait en local, etc...

[jouana]

Je te conseil WPF service application + ado.net

Facile à utiliser dans tes projet après via les web references

[chamamo]

Ca dépend, ASP.NET Web API est très bien pour des projets légers, type appels en AJAX (REST/JSON), et surtout pour des besoins très classiques.

Légers? tu peux détailler s'il te plait? car j'ai mis en place un back office en Web Api qui peut être consommé depuis plusieurs type d'appareil (pc, pda, mobile) qui est assez conséquent et jusqu'à présent je n'ai eu aucun souci, ce que j'aime le plus c'est la facilité de le mettre en place, moins de config...etc.

Cependant si on a besoin de gérer des scénarios particuliers (type one way messaging, queues de messages, duplex, etc.), ou encore si on veut utiliser des canaux de communication rapides (TCP/UDP/Named Pipes...), il faut se tourner vers WCF.

Entièrement d'accord.

Donc ça dépend pas mal de ton projet, si les communications passent pas internet ou si tout se fait en local, etc...

Je ne sais pas si ça change quelque chose, que ce soit WCF ou Web Api les deux peuvent être déployé sur internet ou en réseau local

[neuropathie]

Merci pour vos réponses,
Mon client actuellement est une banque (donc coté sécurité ca doit etre poussé)
Le client met à ma disposition des fichiers XML et ca s'arrete là. De mon coté mon API doit etre capable de prendre ces fichiers XML, les traiter et remplir la base de données.
D'un autre coté des appli mobiles et portails web peuvent utliser mon API pour accéder à la base de données.
Il peut exister des cas de mise à jour, c'est à dire qu'un utilisateur peut mettre à jour certaines données et l'API met à jour la base
Donc pour moi le plus important par ordre de priorité:
-l'API et son architecture.
-la sécurité de l'API
-L'API vers la base de données.

[DotNetMatt]

Légers? tu peux détailler s'il te plait? car j'ai mis en place un back office en Web Api qui peut être consommé depuis plusieurs type d'appareil (pc, pda, mobile) qui est assez conséquent et jusqu'à présent je n'ai eu aucun souci, ce que j'aime le plus c'est la facilité de le mettre en place, moins de config...etc.

Par "léger" il fallait comprendre ce que j'ai écrit un peu plus loin, à savoir des besoins classiques, et surtout purement HTTP. C'est d'ailleurs pour cela que Web API est préfixé par ASP.NET.

Je ne sais pas si ça change quelque chose, que ce soit WCF ou Web Api les deux peuvent être déployé sur internet ou en réseau local

Oui mais pour les scénarios spécifiques que j'ai décrit (TCP/UDP...), il vaut mieux être en local. On peut certes faire du TCP over Internet mais bon ce n'est semble-t-il pas la meilleure chose à faire.

[EDIT] En complément, voici les principales différences entre WCF et ASP.NET Web API : WCF and ASP.NET Web API

[jouana]

tu n'as pas vraiment le choix et TCP c'est mieux que de l'UDP à travers le web

Même si c'est plus lourd

[neuropathie]

Merci pour vos réponses.
J'ai décidé d'utiliser WCF pour des soucis d'évolutivité quand aux fonctions à venir sur l'API.
Maintenant, WCF en mode windows service ou en mode hebergé sur IIS? et quels sont vos retours d'expériences à ce sujet.

Merci d'avance.

[Invité]

Avec l'hébergement au sein d'un service Windows tu actives/désactives ton service WCF de façon explicite. Tous les protocoles (donc tous les bindings) sont pris en compte.

Avec l'hébergement au sein de IIS, ton service WCF sera traité comme s'il s'agissait d'un site/application web et tu dois passer par un fichier .svc. À partir de .Net 4.0 ce fichier n'a pas besoin d'être créé physiquement tu peux passer par le fichier de configuration web.config pour la configuration de ton service. L'activation est faite à la première requête reçue d'un client. Les désactivations se font à chaque recyclage du pool. Si tu exposes ton service à travers ASP.net alors tu bénéficies de tous les avantages de cette techno.Tu peux utiliser tous les protocoles qu'à partir de IIS 7 avec WAS. Les anciennes version de IIS sont limitées au protocole HTTP.

Ma liste n'est pas exhaustive mais au vu de ça :

Ma proposition est basée sur du ASP.NET, C#, Linq, entity Framework.

je partirai pour IIS vu que tu parles d'ASP.Net.

[neuropathie]

Merci pour vos réponses.
Maintenant je cherche à tracer l'architecture de l'API.
Tout en sachant que la répartition logique des fonctionnalités est:
- Couche sécurité
- Couche web services, réception des données clients, et envoi navigateur
- Couche traitement des donnees
- Couche accès aux données

Des idées sur cela?

Merci d'avance.

[Invité]

- Couche sécurité

Il n'y a pas de couche sécurité au sens couche logicielle. La sécurité est gérée au niveau de la couche service dans ton cas. Pour la sécurité au niveau transport tu peux utiliser le protocole https et tu peux rechercher comment faire pour les autres protocoles. WCF permet aussi d'encrypter le contenu des messages.

- Couche web services, réception des données clients, et envoi navigateur

Si tu as déjà travailler avec des services Web alors ce point ne devrait pas te poser problème. Je te conseille d'abords d'apprendre comment fonctionnent les services web et en gros quelles problématiques permet de résoudre l'architecture SOA (Service Oriented Architecture)

- Couche traitement des donnees

Il s'agira ici d'avoir une couche de logique métier en gros c'est la logique de ton service. Certains mettent cette logique directement dans l'implémentation des opérations de service mais je te conseille d'externaliser la logique et d'y faire appel là où tu en auras besoin.

- Couche accès aux données

Contiendra tout ce qui est interaction direct avec la base de données. En gros ce que te génère ton ORM ici Entity Framework.