BizTalk Labs - Why an Internet Service Bus?

So following on from my post on the weekend about trying to build my first end to end cloud demo, I've started poking around the latest BizTalk Labs SDK (a.k.a BizTalk Services).

First thing that hit me, as I played around with these services is, it's all about web service publishing. The SDK samples are very strong, and it's all based on the WCF model of contracts and channels.

Now, when I first saw the BizTalk Labs release, I honestly pictured a hosted orchestration environment in my head, but what I can see now is that this is probably their long term vision, but as with everything, small steps in a +ve direction.

This release is all about helping developers publicly face their WCF services to the outside world. Why is this important?

Well, if I'm building a great internal service to do some high-value function, and am back-ending that service to internal back-end systems, maybe something like CRM "Titan" (just as an example yeah ;)), then what do I do if I need to start offering that service to the rest of the world?

Well, I could try and set up the infrastructure internally to host and deliver that service to a public, and make sure that my critical back-end system is well protected, and have all the high-availability infrastructure plumbed to make sure the service is reliable, scalable, etc. But again, that's not always possible for small organisations, and as we now know (yesh, yesh, just nod), the next gen web platform is all about removing the barriers to entry, so the best, not just the biggest players can enter the cloud business space.

So, how do I do that now in the BizTalk Services space? Really simply.

Step 1: Build your WCF server to provide your service endpoint function. Now, remember (with the SOA groans in the background), make sure it's atomic, and provides a single business aspect. So lets have "UpdateCustomerActivity(CustomerActivityEvent)" rather than 4 smaller methods that the end consumer needs to orchestrate themselves (you could have 4 separate methods, only, just make sure that the are truly atomic, and not constantly being called together by consumers, otherwise you should raise the endpoint level).

Step 2: Wire your service endpoint up to the BizTalk Services relay endpoint. Now why this rocks my panties is it provides a secure (CardSpace secure momma) channel for other consumers, outside your firewall, to connect to your service! They just bind to the BizTalk Services relay endpoint, and the message gets sent to your service!

Step 3: Create a consumer that binds to the relay endpoint for your service via BizTalk Services, and now your messaging in a connected way.

Now, it's important that peeps focus on the fact that, BizTalk Services, or any Internet Services Bus, is about pushing the complexity inside the firewall, where you can control it better, and moving the hard to deliver, high scalable stuff to the cloud, ala the messaging backbone. That way, the barrier to enter this space is low, because as soon as you cook up your service, you can publish it, with minimal infrastructure requirements. Now, reality is, you still need some public facing infrastructure, such as perimeter firewalls and routers, etc, but what you don't need is the moving parts of an Enterprise Service Bus facing the outside world (cos lets face it, the public world is scary), and that's good for you and me! YOU and ME!!!... :)