Any viable alternatives to WCF and WSDL for integration endpoints?

Question

My employer is a software vendor for a specific market. Our customers integrate our system with others using web services. We use Microsoft technology, and our web services are implemented in ASP.NET and WCF.

The time has come to review our current set of services, and come up with company standards for future integrations. I am reading "Enterprise Integration Patterns," and I've also been looking a little bit at nServiceBus and Mass Transit. These may simplify issues like contract versioning and unit testing, but they seem to be most useful for providing an internal service bus, not for exposing services to external clients.

Our customers are on many different platforms, and require our services to be standards compliant. That may mean different things to different people, but I think it is safe to assume that they want to access web services described with WSDL.

In this scenario, is WCF the way to go?

Answer 1

WCF is by far the most standards-compliant stack on the Microsoft platform. The nice thing is that it's very flexible for different clients "out of the box", and if there are things that cause you grief, most of them can be changed via custom behaviors without too much trouble.

Answer 2

An alternative that I normally recommend is integration over AMQP between your message brokers. That was you can use the push paradigm instead of the polling one (which is very powerful and scalable in comparison)!

You'd set up your own broker, such as RabbitMQ, locally. Then you'd let your integration partner set up one. (Easy: just download it).

If your partner is integrating from the same data center, you'd be save to assume few network splits - meaning you could share the broker. On the other hand, if you are on different networks, you can set up the broker in federation mode. (Run rabbitmq-plugins enable rabbitmq_federation and point to the other broker)

Now you can use e.g. MassTransit:

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

, like you would do when not doing any integration.

If you look at http://rabbitmq.mydomain.local:55672/ now you will find the administration interface for RabbitMQ. MassTransit creates an exchange for each message type (sending such a message to that exchange will fan out to all subscribers), which you can put authorization rules on.

Authorization rules can be in the form of regex per user or it can be integrated into LDAP. Consult the documentation for this.

You'd also need SSL in the case that you're going over the WAN and you don't have an IPSec tunnel - that documentation is here: http://www.rabbitmq.com/ssl.html and you enable it like this.

That's it! Enjoy!

Post scriptum: if you are feeling up for an adventure that will help you manage all of your infrastructure as a side-effect, you can have a look at puppet. Puppet is a provisioner and configuration manager of servers; in this case you'd be interested in setting up SSL with puppet. First, order a wild-card subdomain certificate for your domain, then use that cert to sign other certificates: you can delegate that - see the rabbitmq guide where it states "Now we can generate the key and certificates that our test Certificate Authority will use." - generate a certificate-signing-request for the certificate instead of creating a new authority - and let RMQ use this for SSL - it will be valid for the internet.