quali tecnologie utilizzare per il server middleware in .net?

Question

Non so se questa è una domanda stupida! Ho cercato sul Web senza colpi utili. Io sono un utente di rete (C#). Voglio sviluppare un server, può essere chiamato un server middleware (in realtà non sono sicuro), che svolge le seguenti attività, Ho un server che non può essere modificato e molti i client che richiedono il server e ricevono i risultati. Posso modificare i client. Ora voglio sviluppare un software che riceve richieste client, controllare se il server è occupato o quante attività sono accodate al server, memorizzare le richieste client nel database temporaneo se il server è occupato, recuperare le richieste accodate nel database temporaneo e in avanti al server e poi ricevere i risultati e in avanti per i clienti e le questioni like.The sono

1. quali tecnologie sono i migliori da utilizzare, pur rimanendo in dotnet, WCF, Webservives, servizi remoti, o altro ?

2. quanto è complessa questa attività presupponendo che ci siano attività come la gestione delle transazioni, il bilanciamento del carico, la registrazione, i meccanismi di controllo di sicurezza e simili?

3. quali cose devo leggere per eseguire queste attività?

4. durante la ricerca trovo cose come middleware in java ma non in dotnet. qual è il motivo?

Answer 1

Middleware è un termine molto ampio, si sta in particolare parlando di un proxy:

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

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

che è anche un middleware, naturalmente.

Le altre risposte dipendono dalle tecnologie utilizzate per la comunicazione client-server (servizi Web, REST, json, ...?), Quanto è complessa la logica del server e quante richieste è necessario gestire. ..

La cosa più semplice che potrebbe funzionare nello scenario è un bilanciamento del carico (http://en.wikipedia.org/wiki/Load_balancing_(computing)) che inoltra richieste a due o più server, a seconda del carico del server. Ovviamente questo funziona solo se è possibile replicare le istanze del server.

Mettere un middleware che memorizza una coda se il server è occupato potrebbe funzionare, ma nulla assicura circa la possibilità di superare la capacità di coda di quella delega troppo, e non ci si va di nuovo ...

Answer 2

In .NET l'approccio consigliato per un server middleware è quello di utilizzare Enterprise services che fornisce un'API .NET su COM +.

COM + fornisce tutte le funzionalità citate (nel punto 2) in applicazioni .NET.

WCF sostituisce il servizio remoto, ma si basa interamente sull'interoperabilità. Sebbene fornisca sicurezza e funzionalità transazionali, queste sono orientate verso la comunicazione tra 2 endpoint, non gli oggetti dell'applicazione.

Answer 3

Risposta breve: dai suoni se questo, se si desidera solo tamponare il server dal sovraccarico, è possibile farla franca gestendo la richiesta in modo asincrono. WCF supporta MSMQ in modo nativo. MSMQ supporta DTC in modo che i messaggi possano essere posizionati e rimossi a livello transazionale.

L'argomento più ampio di Middleware è un termine abbastanza "sfocato" (come lo sono termini come Transazioni, ESB, ecc.). MS ha prodotti in questo spazio. Questo include:

• queing tecnologie (Message Oriented Middleware) MSMQ (alternative includono IBM WebSphere MQ, Coniglio MQ ecc)
• XA/ACID/TP monitor - Microsoft DTC
• EAI - Microsoft ha BizTalk per l'integrazione (Ci sono molti altri venditori qui)
• ESB - Microsoft ha BizTalk. È anche possibile consultare MS Managed Service Engine (MSE) per la virtualizzazione dei servizi.Questo è defunta
• Per l'integrazione RESTful, WebAPI
• BPM/BPEL - Anche in questo caso, MS hanno BizTalk. Può anche includere il monitoraggio e la segnalazione del livello aziendale
• Aspetti operativi - come descritto - gestione, monitoraggio, bilanciamento del carico, limitazione, accordi SLA sui servizi ecc.
• Per servizi Web (e estensioni WS), WCF. Ci sono un gran numero di opzioni di configurazione qui che per lo più astraggono la necessità di cambiare il codice quando tra i protocolli di commutazione.

E questo è solo l'inizio :)

Answer 4

per # 1:

, fornire ulteriori informazioni circa il vostro compito: 1. Stima approssimativa per la quantità di clienti 5, 100, 10000, 1000000 2. Dimensione stimata dei dati che andranno avanti e indietro tra client e server 3. Dove i client lavoreranno in Internet o Intranet? Eventuali restrizioni di sicurezza? 4. Il client sarà un'applicazione standalone o un'applicazione web (come la pagina o il widget sulla pagina)?

Per 3 #:

Se tutto quello che lei ha citato in 2 # devono essere implementate come parte del compito, quindi non credo che si può solo leggere alcuni libri e attuarlo. Oppure il risultato dell'implementazione sarà lontano dai requisiti di produzione. Consiglio di assumere un architetto o di esternalizzarlo a un team esperto. Solo per informazioni generali posso consigliare di leggere - "Modelli di architettura di applicazioni aziendali" di Martin Fowler. Ma solo la lettura non può sostituire l'esperienza.

Per n. 4: Credo ci siano anche sistemi middleware per .Net. Esistono sistemi middleware commerciali che funzionano con Java, .Net & C++.

IMO Microsoft ha selezionato un altro approccio e quindi la comunità Java. Hanno fornito framework che ti permettono di costruire quello che chiami "middleware". Primo sguardo su WCF & REST. La coda può essere facilmente implementata nel DB. Se non è sufficiente esaminare WCF & MS MQ. Se non ti piace MS MQ guarda Amazon SQS. Se non è abbastanza, guarda in BizTalk.

P.S. Le piattaforme Java e .NET sono così grandi che puoi costruire ciò che vuoi su entrambi. Non ha senso passare da .NET a Java o da Java a .Net solo perché pensi che qualcosa manchi nella piattaforma.