Last week, Microsoft took the covers off its 'Dublin' application server strategy. Hardly a general purpose appserver, Dublin provides a business process server extension of Windows Server 2008 that becomes the deployment pillar for Oslo. Microsoft intends Dublin to simplify deployment to a broader class of business developers through greater inclusion of easy-to-use prebuilt templates. However, Dublin does not yet address the overlap with BizTalk Server, Microsoft's original process-oriented composite application platform. Dublin is focused on promoting declarative rather than code-based development of complex, workflow- or process-based applications on Windows platformsMicrosoft used to boast that it had no such use for an application server because the windows platform could handle everything. Recently it changed course with the formal announcement of Dublin, the codename for its new application server. Why did Microsoft change its strategy? One word: Oslo.
Oslo is Microsoft's strategy for promoting model-driven development of business-process-oriented composite applications. However, because the distributed nature of composite applications exerts unique demands on server performance, Microsoft decided it needed a more focused answer. Consequently, Dublin is not simply the .NET equivalent of WebSphere, WebLogic, or JBoss, but instead is a purpose-built business process server extension of Windows Server 2008 designed to simplify and optimize composite applications modeled using Oslo.
Dublin's goals are aimed at making workflow-based composite applications:
simpler to develop, by providing templates for a wider array of workflow models just as easy to deploy as conventional RPC-like web applications are on Internet Information Server, Microsoft's HTTP server add-on to Windows server better suited for declarative rather than code-based development, by improving scalability so developers requiring high-performance, high-throughput applications will not be forced to drop down to coding as frequently. Dublin leverages new features in the upcoming 4.0 versions of WCF and WF, which in turn will be part of the .NET 4.0 Framework. For WCF, highlights are simplifying deployment, not just the for the WS-* web services protocols currently supported, but also to lighter-weight alternatives such as RESTful services and plain old XML, while adding more agility through use of ATOM feeds. For WF, it means more accessibility to less hardcore developers through the addition of templates for a wider range of workflow types, such as state machine, flow charting, and the ability to configure through checkbox rather than hard coding more sophisticated workflow application capabilities such as compensating transactions and persistence. And with support of XAML, Microsoft's XML-based language that is used by Web 2.0 designers with its Expressions tool, Oslo composites deployed on Dublin can, in effect, have their screens painted with Expressions without having to translate code bases.
Dublin and BizTalk: twins separated by birthSo, what becomes of BizTalk, Microsoft's original platform for assembling and integrating composite applications? BizTalk, which follows more of a classical EAI hub model, also has its own workflow engine that predates WF. With Dublin, both continue to be separate architectural paths.
Microsoft explains that BizTalk is more for classic hub-based application-to-application (A2A) and business-to-business (B2B) integration use cases. By contrast, Dublin is intended for the more distributed world of composite SOA-based applications. Admittedly, in a siloed world where you have legacy applications following a more hub-oriented integration model, plus newer generation composite applications that follow more dynamic, distributed models, that distinction would be fully valid.
The dilemma, however, is that in most organizations architectures tend to evolve over time, and therefore the distinction between first-generation A2A or web-services applications and those that are more dynamically composed is no longer so clear cut. Ripping and replacing BizTalk integrations with Dublin because it has more agile BPM workflows is simply not an economically sound response.
Consider a B2B example involving an EDI-like BizTalk message hub integration. The customer is a manufacturer with a global supply chain that is now having to re-optimize based on escalating fuel costs, changes in demand across different geographies, and the sudden impact of tightening credit. A logical solution could embed some newer-style, more dynamic Dublin workflows in a loose coupling with their existing BizTalk message hub. Once Microsoft Dublin graduates from codename to a real product with an actual product name, it must offer prebuilt templates for customers seeking to support exactly those use cases.
Re:
http://www.ovum.com/news/euronews.asp?id=7409
