qué tecnologías usar para el servidor de middleware en .net?

Question

¡No sé si esta es una pregunta tonta! Busqué en la web sin hits útiles. Soy un usuario de dot net (C#). Deseo desarrollar un servidor, se puede llamar servidor de middleware (en realidad no estoy seguro), que realiza las siguientes tareas, Tengo un servidor que no se puede modificar y muchos clientes que solicitan el servidor y reciben los resultados. Puedo modificar los clientes. Ahora quiero desarrollar software que reciba solicitudes de clientes, verificar si el servidor está ocupado o cuántas tareas están en cola en el servidor, almacenar las solicitudes de clientes en la base de datos temporal si el servidor está ocupado, buscar las solicitudes en cola en el servidor base de datos temporal y hacia adelante en el servidor y luego recibir los resultados y transmitir a los clientes y las preguntas son similares.El

1. qué tecnologías son mejores para usar mientras se permanece en dotnet, WCF, Webservives, la comunicación remota, u otro ?

2. ¿Cuán compleja es esta tarea, suponiendo que hay tareas como la gestión de transacciones, el equilibrio de carga, el registro, los mecanismos de comprobación de seguridad y similares?

3. ¿Qué cosas debería leer para hacer estas tareas?

4. durante la búsqueda encuentro cosas como middleware en java pero no en dotnet. ¿cual es la razon?

Answer 1

Middleware es un término muy amplio, que está específicamente hablando de un proxy:

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

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

que también es un middleware, por supuesto.

Las otras respuestas dependen de qué tecnologías esté utilizando para la comunicación cliente-servidor (servicios web, REST, json, ...), cuán compleja es su lógica de servidor y cuántas solicitudes debe manejar. ..

Lo más simple que podría funcionar en su situación es un equilibrador de carga (http://en.wikipedia.org/wiki/Load_balancing_(computing)) que envía solicitudes a dos o más servidores, según la carga del servidor. Obviamente, eso solo funciona si puede replicar las instancias de su servidor.

Poner un middleware que almacena una cola si el servidor está ocupado podría funcionar, pero nada asegura acerca de la posibilidad de exceder la capacidad de la cola de ese proxy también, y hay que ir de nuevo ...

Answer 2

En .NET el enfoque recomendado para un servidor de middleware es usar Enterprise services que proporciona una API de .NET sobre COM +.

COM + proporciona todas las características que menciona (en el punto 2) para las aplicaciones .NET.

WCF reemplaza a Remoting pero se trata de la interoperabilidad. Si bien proporciona características de seguridad y transaccionales, estas están orientadas a la comunicación entre 2 puntos finales, no sus objetos de aplicación.

Answer 3

Respuesta corta: Según los sonidos, si solo desea almacenar en búfer su servidor de sobrecarga, puede manejar el pedido de forma asíncrona. WCF es compatible con MSMQ de forma nativa. MSMQ es compatible con DTC, por lo que los mensajes se pueden colocar y eliminar de forma transaccional.

El tema más amplio de Middleware es un término bastante "confuso" (como lo son los términos como Transacciones, ESB, etc.). MS tiene productos en este espacio. Esto incluye:

• tecnologías Queing (Message Oriented Middleware) MSMQ (Las alternativas incluyen IBM Websphere MQ, conejo MQ, etc.)
• XA/ácido Monitores/TP - Microsoft DTC
• EAI - Microsoft ha BizTalk para la integración (Hay muchos otros proveedores aquí)
• ESB - Microsoft tiene BizTalk. También puede consultar el MS Service Engine (MSE) para la virtualización de servicios.Esto es desaparecida
• Para la integración REST, WebAPI
• BPM/BPEL - Una vez más, MS tiene BizTalk. También puede incluir monitoreo e informes de nivel empresarial
• Aspectos operacionales, como ya ha descrito, administración, supervisión, equilibrio de carga, regulación, acuerdos de SLA en servicios, etc.
• Para servicios web (y WS Extensions), WCF. Aquí hay una gran cantidad de opciones de configuración que en su mayoría abstraen la necesidad de cambiar el código cuando se cambian los protocolos.

y esto es sólo arañando la superficie :)

Answer 4

Para # 1:

Sírvanse proporcionar información adicional acerca de su tarea: 1. Estimación aproximada de la cantidad de clientes 5, 100, 10000, 1000000 2. Tamaño estimado de los datos que entrarán en vigor entre el cliente y el servidor 3. ¿Dónde los clientes trabajarán en Internet o Intranet? ¿Alguna restricción por seguridad? 4. ¿El cliente será una aplicación independiente o una aplicación web (como una página o artilugio en la página)?

Para # 3:

Si todo lo que usted ha mencionado en el # 2 se debe implementar como parte de la tarea, entonces no creo que sólo puede leer algunos libros y ponerlo en práctica. O el resultado de la implementación estará lejos de los requisitos de producción. Recomiendo contratar arquitecto o subcontratarlo a un equipo experimentado. Solo para información general puedo recomendar leer: "Patrones de arquitectura de aplicaciones empresariales" Por Martin Fowler. Pero solo leer no puede reemplazar la experiencia.

Para # 4: Creo que hay sistemas de middleware para .Net también. Existen sistemas de middleware comerciales que funcionan con Java, .Net & C++.

IMO Microsoft seleccionó otro enfoque que la comunidad Java. Proporcionaron marcos que le permiten construir lo que llama "middleware". Primero mira en WCF & REST. La cola puede ser fácil de implementar en la base de datos. Si no es suficiente, busque en WCF & MS MQ. Si no te gusta MS MQ mira Amazon SQS. Si no es suficiente, mire en BizTalk.

P.S. Las plataformas Java y .NET son tan grandes que puedes construir lo que quieras en ambas. No tiene sentido saltar de .NET a Java o de Java a .Net solo porque piensas que algo se pierde en la plataforma.