quelles technologies utiliser pour le serveur middleware dans .net?

Question

Je ne sais pas si c'est une question idiote! J'ai cherché sur le web sans aucun résultat utile. Je suis un utilisateur net point (C#) .Je veux développer un serveur, il peut être appelé un serveur middleware (en fait je ne suis pas sûr), qui effectue les tâches suivantes, J'ai un serveur qui ne peut pas être modifié et beaucoup les clients qui demandent le serveur et reçoivent les résultats. Je peux modifier les clients. Maintenant, je veux développer un logiciel qui reçoit les demandes des clients, vérifier si le serveur est occupé ou combien de tâches sont mises en file d'attente sur le serveur, stocker les requêtes client dans la base de données temporaire si le serveur est occupé. base de données temporaire et transmettre au serveur et reçoivent ensuite les résultats et à transmettre aux clients et aux questions like.The sont

1. technologies qui sont les mieux à utiliser tout en restant dans dotnet, WCF, Webservives, Remoting ou autre ? Quelle est la complexité de cette tâche en supposant qu'il existe des tâches telles que la gestion des transactions, l'équilibrage de charge, la journalisation, les mécanismes de vérification de sécurité, etc.?

2. Que devrais-je lire pour effectuer ces tâches?

3. lors de la recherche, je trouve des choses comme middleware en java mais pas en dotnet. quelle est la raison?

Answer 1

Middleware est un terme très large, vous parlez spécifiquement un proxy:

http://en.wikipedia.org/wiki/Proxy_server

http://en.wikipedia.org/wiki/Proxy_pattern

Ce qui est aussi un middleware, bien sûr. Les autres réponses dépendent des technologies que vous utilisez pour la communication client-serveur (services Web, REST, json, ...?), De la complexité de la logique de votre serveur et du nombre de requêtes que vous devez gérer. ..

la chose la plus simple qui pourrait éventuellement travailler dans votre scénario est un équilibreur de charge (http://en.wikipedia.org/wiki/Load_balancing_(computing)) qui transmet les requêtes à deux ou plusieurs serveurs, en fonction de la charge du serveur. Évidemment, cela ne fonctionne que si vous pouvez répliquer vos instances de serveur.

Mettre un middleware qui stocke une file d'attente si le serveur est occupé pourrait fonctionner, mais rien ne garantit la possibilité de dépasser la capacité de file d'attente de cette procuration aussi, et là vous allez à nouveau ...

Answer 2

Dans .NET l'approche recommandée pour un serveur middleware est d'utiliser Enterprise services qui fournit une API .NET sur COM +. COM + fournit toutes les fonctionnalités que vous mentionnez (au point 2) aux applications .NET.

WCF remplace Remoting, mais est tout au sujet de l'interopérabilité. Bien qu'il fournisse des fonctionnalités de sécurité et de transaction, ceux-ci sont orientés vers la communication entre deux points de terminaison, et non avec vos objets d'application.

Answer 3

Réponse courte: À partir des sons si cela est le cas, si vous voulez simplement protéger votre serveur contre les surcharges, vous pouvez vous en sortir en traitant la requête de manière asynchrone. WCF prend en charge MSMQ nativement. MSMQ prend en charge DTC afin que les messages puissent être placés et supprimés de manière transactionnelle.

Le plus grand sujet de Middleware est tout à fait un terme « floue » (comme les termes tels que les transactions, ESB, etc.). MS a des produits dans cet espace. Cela comprend:

• technologies files d'attentes (Message Oriented Middleware) MSMQ (Les alternatives comprennent IBM Websphere MQ, lapin MQ etc.)
• Moniteurs XA/acide/TP - Microsoft DTC
• EAI - Microsoft a BizTalk pour l'intégration (Il y a beaucoup d'autres fournisseurs ici)
• ESB - Microsoft a BizTalk. Vous pouvez également consulter le MS Managed Service Engine (MSE) pour la virtualisation des services.C'est défunte
• Pour l'intégration RESTful, WebAPI
• BPM/BPEL - Encore une fois, MS BizTalk. Peut également inclure la surveillance et le reporting au niveau de l'entreprise.
• Pour les services Web (et les extensions WS), WCF, comme vous l'avez décrit, gestion, surveillance, équilibrage de charge, limitation, accords de SLA. Il y a ici un grand nombre d'options de configuration qui éliminent la nécessité de changer de code entre les protocoles de commutation.

Et cela qu'effleurer la surface :)

Answer 4

Pour # 1:

S'il vous plaît fournir des informations supplémentaires sur votre tâche: 1. Estimation approximative pour la quantité de clients 5, 100, 10000, 1000000 2. taille estimée des données qui entrera vigueur et retour entre le client et le serveur 3. Lorsque les clients travailleront dans Internet ou Intranet? Des restrictions par sécurité? 4. Le client sera une application autonome ou une application Web (comme une page ou un widget sur la page)?

Pour # 3:

Si tout ce que vous avez mentionné dans # 2 doit être mis en œuvre dans le cadre de la tâche, alors je ne crois pas que vous pouvez simplement lire quelques livres et la mettre en œuvre. Ou le résultat de la mise en œuvre sera loin des exigences de production. Je recommande d'embaucher un architecte ou de l'impartir à une équipe expérimentée. Juste pour des informations générales, je peux vous recommander de lire - "Patterns of enterprise application architecture" par Martin Fowler. Mais la simple lecture ne peut pas remplacer l'expérience.

Pour # 4: Je crois qu'il ya des systèmes middleware pour .Net aussi. Il existe des systèmes middleware commerciaux qui fonctionnent avec Java, .Net & C++.

OMI Microsoft sélectionné autre approche, puis la communauté Java. Ils ont fourni des frameworks qui vous permettent de construire ce que vous appelez "middleware". Premier regard dans WCF & REST. La file d'attente peut être implémentée facilement dans la base de données. Si ce n'est pas assez regarder dans WCF & MS MQ. Si vous n'aimez pas MS MQ, regardez Amazon SQS. Si ce n'est pas assez regarder dans BizTalk.

post-scriptum Les plates-formes Java et .NET sont si énormes que vous pouvez construire ce que vous voulez sur les deux. Cela n'a pas de sens de passer de .NET à Java ou de Java à .Net juste parce que vous pensez que quelque chose est manqué dans la plate-forme.