Eventuali valide alternative ai WCF e WSDL per gli endpoint di integrazione?

Question

Il mio datore di lavoro è un fornitore di software per un mercato specifico. I nostri clienti a integrare il nostro sistema con gli altri che utilizzano i servizi web. Usiamo la tecnologia di Microsoft, ed i nostri servizi web implementati in ASP.NET e WCF.

E 'giunto il momento di rivedere la nostra attuale gamma di servizi, e venire con gli standard aziendali per le integrazioni future. Sto leggendo "Enterprise Integration Pattern," e sto anche cercando un po 'alla NServiceBus e Mass Transit. Questi possono semplificare questioni come il controllo delle versioni contratto e test di unità, ma sembrano essere più utili per fornire un bus di servizio interno, non per esporre servizi a clienti esterni.

I nostri clienti sono su molte piattaforme diverse, e richiedono i nostri servizi per essere conforme agli standard. Che può significare cose diverse per persone diverse, ma penso che sia lecito ritenere che vogliono accedere ai servizi web descritti con WSDL.

In questo scenario, è WCF la strada da percorrere?

Answer 1

WCF è di gran lunga la più conforme agli standard pila sulla piattaforma Microsoft. La cosa bella è che è molto flessibile per diversi clienti "out of the box", e se ci sono cose che ti fanno dolore, la maggior parte di essi possono essere modificati tramite comportamenti personalizzati senza troppi problemi.

Answer 2

Un'alternativa che vi consiglio di solito è l'integrazione su AMQP tra le message broker. Questo è stato possibile utilizzare il paradigma spinta invece del polling (che è molto potente e scalabile in confronto)!

Si potrebbe impostare il proprio broker, come ad esempio RabbitMQ, a livello locale. Poi ci si lascia che il tuo partner di integrazione istituito uno. (Easy: basta scaricarlo ).

Se il vostro partner è l'integrazione dallo stesso data center, si sarebbe risparmiare ad assumere alcune divisioni rete - che significa che potrebbe condividere il broker . D'altra parte, se si è su reti diverse, è possibile impostare il broker nel modo rel="nofollow"> federazione . (Run rabbitmq-plugins enable rabbitmq_federation e rel="nofollow"> all'altro mediatore)

Ora è possibile utilizzare per esempio MassTransit:

ServiceBusFactory.New(sbc =>
{
    sbc.UseRabbitMqRouting();
    sbc.ReceiveFrom("rabbitmq://rabbitmq.mydomain.local/myvhost/myapplication");
    // sbc.Subscribe( s => s ... );
});

, come si farebbe quando non fare alcuna integrazione.

Se si guarda a http: //rabbitmq.mydomain.local: 55672 / ora si vuole trovare l'interfaccia di amministrazione per RabbitMQ. MassTransit crea uno scambio per ogni tipo di messaggio (l'invio di un messaggio di questo tipo a che Exchange ventaglio a tutti gli abbonati), che si possono mettere le regole di autorizzazione on.

regole di autorizzazione possono essere sotto forma di regex per utente oppure può essere integrato in LDAP. Consultare la documentazione per questo.

Si sarebbe anche bisogno di SSL nel caso in cui si sta andando sulla WAN e non si dispone di un tunnel IPSec - che la documentazione è qui: http://www.rabbitmq.com/ssl.html e si abilita in questo modo .

Questo è tutto! Buon divertimento!

Post scriptum: se ti senti in su per un'avventura che vi aiuterà a gestire tutti i vostri infrastruttura come effetto collaterale, si può dare un'occhiata a burattino . Puppet è un provisioner e configurazione del gestore del server; in questo caso si sarebbe interessati alla creazione di SSL con il burattino. In primo luogo, ordinare un certificato sottodominio wild-card per il dominio, quindi utilizzare tale cert per firmare altri certificati: è possibile delegare che - vedi la guida RabbitMQ in cui si afferma: "Ora siamo in grado di generare la chiave e certificati che la nostra prova di Certificate Authority utilizzerà ". - generare un certificato firma-richiesta per il certificato invece di creare una nuova autorità - e lasciare che RMQ utilizzare questo per SSL -. Sarà valido per internet