Integrating in the Cloud - part 2
06/29/2009 01:02 PM
It’s been a while since I first wrote my post about SaaS/S+S –based integration. At that time I thought that I don’t see too much benefit in Microsoft’s .NET Services –based messaging platform, but there could be some benefit starting using hosted workflow services – a part of .NET Services. I thought to write another post pretty quickly after the first one, but then I started to think – and wasn’t so sure any more about the benefits of the hosted workflow any more.
Azure surely is a nice technology stack. It gives the software vendor possibility for fast time-to-market when developing cloud-based software – putting your .NET application into the cloud can be pretty straightforward task. No need to negotiate about hardware configurations, SLAs and all that stuff – just upload your app and start paying your fees based on the usage. If you need to scale your application up, just do that using your self-service portal and that’s it. That’s how deploying S+S applications should be.
If you think about Azure as a software hosting platform, there is a need for certain complementary services in addition to running the actual application. You need the data tier – thus SQL Services. But there are some other services whose function in the overall Azure stack is not as simply justifiable. These technologies rise from those pre-Azure experimental, integration-related hosted technologies that were earlier known as BizTalk Services – now known as Azure .NET Services.
In my earlier post I said that I don’t think there’s too much benefit in the basic hosted messaging service. Now I am not so sure any more. If you remember, one of the early goals of Web Services was that by running WS protocols on top of HTTP lets messages travel easily across business boundaries. Sure, outbound messaging over port 80 (or 443) can be easily achieved, but those messages need to end up somewhere. And letting external applications access your applications within your network is not a simple task even if the protocol is HTTP or HTTPS. But it’s another story if there is an external party, a hosted publish-subscribe “cloud” where your application (whether a client or a server) connects – this way you can always have the control over the connections from or to your applications.
The .NET Services Service Bus could be a solution for this B2B networking problem, if the trust issues do not become a problem. The easiest way to communicate with the “cloud” here is using WCF from your applications, but Service Bus is interoperable, providing SOAP and REST interfaces. The Access Control element of .NET Services provides adequate authentication and authorization capabilities, combined with identity federation. If you can trust your messages to pass over third party, there actually is a catch in this technology.
But then the Workflow Service. Access Control and Service Bus elements of .NET Services fit nicely to some hosted application development scenarios (and even better to B2B integration scenarios), but I don’t see very good reason for Workflow Service to exist as a separate technology. If you think about the workflow in the context of Azure, it should provide the basis for application functionality; workflow is the application. And if the Azure core services provide the application hosting, why the workflow should be a separate technology? I am not sure if Microsoft is going to provide “Dublin” style of WF and WCF hosting as a part of Azure, but if they are going to do this, what would be the reason for existence of Workflow Service?
In my opinion, Workflow Service is a remainder of the experimental technologies coming from BizTalk Services. It does not fit into Azure very well. It could possibly be used in B2B integration scenarios, but if you want to create a B2B integration broker, why wouldn’t you just install a BizTalk Server and provide the full feature set for your customers (remember SPLA licenses)? Or maybe Microsoft could provide these services?
Response to “Integrating in the Cloud - part 2”
I think one of the key areas for the ISB will be opportunities it offers in opening your on premis LOB applications to mobile workers or people in other locations.
There are a whole lot of opportunities in terms of globalisation challenges which I think Azure will help with from messaging to master data type solutions in the cloud.
On your point about the workflow service I havent looked at this for ages so not sure how it has advanced (if at all) but I think one of the things in the future where this could have a place would be in the area of industry standard processes. At present we have lots of industry standard messaging and communication specifications but actually when you look at an industry most of the processes from a business perspective are the same, and often differences per organisation are really down to the applications with which they implement their processes.
If you think about ISV offerings like GXS Trading Grid where this is a hosted service which allows you to connect partners, imagine if this actually used some cloud based workflow to conduct cross organisation business process and each organisation just had to offer services to be able to plug into these workflows and become a service provider for this process.
Response to “Integrating in the Cloud - part 2”
Just checked .NET Services web site (http://www.microsoft.com/azure/netservices.mspx), and Workflow Service has disappeared... Not it's all about service bus and access control. So, maybe my guess was right - it was just an experimental technology that didn't fit well in the overall stack.