A few weeks back I was at a breakfast briefing on connected systems (Microsoft’s view of web services and BizTalk Server), delivered by David Gristwood (one of Microsoft UK’s Architect Evangelists). Even though I’m not a developer, I think I understood most of what David had to say (although many of my colleagues’ blogs will undoubtedly have more to offer in this subject area).
David explained how the need to connect applications has led to a shift towards service orientation as applications have longer lifetime and no longer consist of just a single executable program. Consequently there are requirements for application customisation and integration (generally loosely coupled) with the four tenets of a service oriented architecture (SOA) being:
- Explicit boundaries.
- Autonomous services (i.e. other services do not have to wait for your schedule).
- Shared schema and contract (not class).
- Compatibility based on policy (generally written in XML).
The Web Services Interoperability Organization‘s WS-* architecture is about providing a framework for web services with broad industry support (in the same way that the open system interconnection 7 layer network model has become the industry model for networking).
Basic web services operate well but are easy to make inoperable. As such WS-I is concerned with identifying the lowest common denominator – the basic profile (BP) or core set of specifications that provide the foundation for web services.
When developing web services, Visual Studio 2005 (codenamed Whidbey) will represent a huge step forward with the Microsoft .NET Framework v2.0 including numerous improvements in the web services protocol stack and ASMX (ASP.NET web services) representing an ongoing evolution towards the Windows communication foundation (formerly codenamed Indigo).
Although coding first and using web methods is still a good way to producing web services, there is a move to interface-based service contracts – first designing the interface using web service definition language (WSDL) and then adding contracts. The new application connection designer (ACD) (codenamed Whitehorse) is a visual tool to drag and drop connections which represent service contracts, allowing the generation of skeleton projects and the basic code required to implement/consume contracts.
In terms of standards and interoperability, this code is WS-I BP 1.1 compliant by default (and hence fits well into the WS-* architecture), whilst ASMX web services automatically support simple object access protocol (SOAP) 1.1 and 1.2.
Web services enhancements (WSE) is a fully supported download which sits on top of ASMX and extends the existing web services support within the Microsoft .NET Framework. WSE is a set of classes to implement on-the-wire standards and is actually an implementation of several WS-* specifications including WS-Addressing and WS-Security, to provide end-to-end message-level security (in a more sophisticated manner than SOAP over HTTP). The current version is WSE 2.0 SP3, and WSE 3.0 will be released with Visual Studio 2005 (due to a dependency on the Microsoft .NET Framework v2.0), with new features including:
- Message transmission optimization mechanism (MTOM) for binary data transfer, replacing SOAP with attachments and WS-Attachments/direct Internet message encapsulation (DIME).
- Enhancements to WS-Security/WS-Policy.
It should be noted that there are no guarantees that WSE 2.0 and 3.0 will be wire-level or object-model compatible, but there will be side-by-side support for the two versions. WSE 3.0 is likely to be wire-compatible with the Windows communication foundation (which will ultimately replace WSE around the end of 2006).
The Windows communication foundation itself is about productivity (writing less code), interoperability (binary, highly-optimised interoperability between computers, dropping to WS-I BP 1.1 if required) and service oriented development. Implemented as a set of classes, the Windows communication foundation takes messages, transforms them, maps them to a structure and pushes them to the receiving code.
To illustrate the productivity gains, using an example cited by Microsoft, an application implemented using Visual Studio .NET 2003 consisting of 56296 lines of code (20379 lines of security, 5988 lines for reliable messaging, 25507 lines for transactions, and 4442 lines for infrastructure) was reduced using WSE to 27321 lines of code (10 lines for security, 1804 lines for reliable messaging, and no change to the 25507 lines for transactions) and reduced further using the Windows communication foundation to just 3 lines of code (1 line for security, 1 line for reliable messaging and 1 line for the transactions)! This sounds extreme to me; but even an infrastructure architect like myself can appreciate that less code means easier management.
In terms of a roadmap, the Windows communication foundation will supersede existing connected systems technologies (e.g. ASMX), but other technologies will continue to exist, supported by the Windows communication foundation (e.g. enterprise services, .NET remoting, COM, COM+ and MSMQ).
Another tool in Microsoft’s integration arsenal is the SQL Server 2005 Service Broker, which will provide a SQL-to-SQL binary data messaging protocol, allowing developers who are familiar with the database programming model to think about queues as databases and to take data from queues as as a kind of hanging query/result sets. Over time, this will be adapted to use the Windows communication foundation so that this will run on top of the Service Broker protocol before eventually allowing the Windows communication foundation to become the transport for WS-* interoperability.
Of course, Microsoft’s most significant integration product for connected systems is BizTalk Server. At 1.5 million lines of C# code, BizTalk Server 2004 is one of the largest Microsoft .NET products written to date (although SQL Server 2005 will exceed this at around 3 million lines). BizTalk Server allows the mesh of point-to-point web service (and other) connections to be replaced with a BizTalk Server “hub”.
Another advantage of such a process is the ability to take business processes out of (potentially unstable) code and allow BizTalk’s orchestration model to handle the business processes.
BizTalk 2004 is the first Microsoft.NET incarnation of the product (the previous two versions were not .NET applications). Built on the ASP.NET application stack and including WS-I v1.0 support (and a v2.0 adapter), BizTalk Server 2004 is integrated with Visual Studio.NET 2003 and the Office System 2003 with additional features including business activity monitoring, human workflow services and a business rules engine. BizTalk Server 2006 is due to follow the SQL Server 2005 and Visual Server 2005 launch in November 2005 and (according to Microsoft) will offer simplified setup, migration and deployment, comprehensive management and operations, and business user empowerment. An adapter for the Windows communication framework is also expected later in 2006. Future versions of BizTalk Server will be built natively on the Windows communication foundation and will offer support for the next version of Windows Server (codenamed Longhorn) as well as the dynamic systems initiative (DSI).
Ultimately, the Windows communication foundation will become a transport layer for connected systems, with BizTalk Server providing orchestration. With continued support for WS-* standards, truly connected systems may well become a reality for many organisations.
One thought on “The Microsoft view of connected systems”