| Vista Communications Layer Targets Web Services |
| Oct. 31, 2005 |
|
The Windows Communication Foundation (WCF) is a new developer framework that helps developers build Web services that tie together applications, both within an organization and between business partners, without relying on a common vendor. WCF (previously code-named Indigo) provides developers with a message-oriented API and implements a number of standardized and emerging Web service protocols and could help corporate developers integrate applications with less code and faster development times than other Web service platforms. However, Microsoft's developer tools are still immature, and some IT architects worry that the Web service specifications are being standardized too quickly. WCF will be built into Windows Vista and available as an add-on to current versions of Windows. Framework for Web Services Many organizations are moving to "service-oriented architectures" to aid integration of their applications. In a service-oriented architecture, key applications all have Web service front ends that enable them to communicate with other applications using XML-formatted messages, typically over standard Internet protocols. A service-oriented architecture thus simplifies the integration of diverse applications and technologies. However, as they move to integrate their applications and systems across OSs and middleware platforms, these organizations often discover they need new, interoperable, Web-based solutions for problems they previously solved with proprietary systems, such as the following:
WCF is Microsoft's latest implementation of the Web services protocols that address these problems. The protocols are collectively referred to as "WS-*" (because the specification names usually begin with the prefix "WS-," as in WS-ReliableMessaging) and are being developed by Microsoft, along with other key industry players, such as BEA, IBM, and VeriSign. The WS-* protocols are being submitted to a variety of organizations for standardization, including the Organization for the Advancement of Structured Industry Systems (OASIS). Although Microsoft hopes WCF will make Windows the best platform for building and deploying these advanced Web services, WCF is not the only Web services platform the company is working on. As an interim step and to help developers who are unwilling to wait until WCF ships, Microsoft has also built a toolkit, known as the Web Services Enhancements (WSE), that supports some of the WS-* standards. Building Blocks of WCF WCF aims to provide a consistent framework for building Web services that is flexible enough to adapt to new standards as they emerge. To that end, WCF is built around a few key concepts that are essential to service-oriented architectures.
The combination of an address, a binding, and a contract is known as an endpoint, and a Web service can contain multiple endpoints. For example, a service for processing orders might have one endpoint for obtaining the status of an order and one for entering new orders. The status endpoint might be accessible via simple HTTP while the endpoint for entering an order might require guaranteed message delivery and use a binding that requires WS-ReliableMessaging. An endpoint is described using Web Services Description Language (WSDL) and applications that communicate with a Web service first read the service's WSDL descriptions to discover its endpoints and choose the appropriate communication mechanisms for them. The power of WCF is its ability to separate the actions performed by a Web service from the way it is accessed. It does this by separating a service's code from its address, binding, and contract (that is, its endpoints). WCF logic is contained in the source code, while the rest of the information is contained in a separate configuration file. This allows developers to create business logic and IT administrators to determine the best way to access that logic. For example, an administrator could take a Web service originally developed for use on an intranet and that used HTTPS security and reconfigure it for use on an extranet simply by adjusting the configuration file to require WS-Security instead. WCF will automatically generate the appropriate WSDL description of the service based on the configuration. Tying Up Loose Ends In addition to giving developers a framework for building Web services, WCF plays an important role for Microsoft—it provides the company with a way to tie together the disparate products and components that have made up its distributed computing technologies, including ASP.NET Web services (often known as "ASMX"), .NET Remoting, and COM+ Enterprise Services. Although each of these technologies was originally developed for different purposes—Web hosting, remote object support, and intranet support for distributed database transactions, respectively—in recent years they have each grown to support some form of Web services. However, each uses a different programming model and API for building and accessing Web services. For example, ASP.NET offers the simplest way to build Web services, but it doesn't support advanced Web services protocols, such as WS-Security. By replacing a hodgepodge of technologies with a single, companywide infrastructure for Web services—WCF—Microsoft is able to provide developers with a simpler, more understandable platform that gives access to the complete set of Web services capabilities. Lack of Tools, Concerns About WS-* Despite the benefits provided by WCF, issues have arisen that IT planners should consider before using it. First, developing interoperable Web services is likely to require a different style of development than that used by most Visual Basic (VB) developers. Second, WS-* protocols are new and are being standardized before they have received widespread adoption. The Easy Way or the Right Way? A Web service developer must create a WSDL definition (formatted as an XML schema) of their service's contract. Microsoft's product demonstrations illustrate a development style known as "code-first," in which the developer creates a set of APIs in a programming language of her choice and then uses automated tools to generate an XML representation of those APIs. The alternative approach, generally referred to as "contract-first," specifies the contract directly in XML and then creates a representation of that contract in the appropriate programming language. The difference has significant implications. Advocates of contract-first development point out that because a Web service is usually developed at the same time as the clients that will be using it, and because the client and service will be communicating via XML, the interfaces and contracts should be directly specified in XML to help ensure that the service is well-designed and interoperates reliably. (In some cases, the definitions will come from third parties or industrywide standards, such as SWIFT for electronic banking.) Using automated tools that translate the developer's API from a programming language to XML, they argue, raises the risk that developers will inadvertently create a Web service that is difficult to use with a platform or programming language other than the one it was created with. This essentially parallels the experience developers faced using COM—Microsoft's previous (and proprietary) technology for distributed systems. Although it was theoretically possible to write code in VB or C++ and automatically generate the underlying contract definition, it proved difficult in practice. Many language constructs available in VB or C++ were difficult to represent in COM's contract definition language, and developers who used code-first development often found they had created objects in one programming language that were difficult to use from another. However, contract-first development is significantly more complex than code-first, which is probably why most vendors, including Microsoft, emphasize code-first in their demonstrations. Contract-first development requires that developers be familiar with the concept of XML schemas (which many aren't) and that vendors produce high-quality tools for building and verifying XML schemas (which most don't). The long-term success of the WCF and the Web services platform will likely require Microsoft to produce much better XML schema tools than it currently does and to educate developers on the right way to build Web services—not just the easy way. WS-Overkill? In addition to the lack of tools for contract-first development, some developers and architects have raised concerns about the emerging WS-* standards themselves. The arguments against the WS-* specifications boil down to the following issues: Premature standardization. Building large-scale distributed applications is a complex process, and critics argue that the WS-* specifications are being ratified without any real-world experience to verify that they work as well in practice as they do in theory. These critics contend that the most successful standardization efforts are those that standardize already accepted technologies and practices rather than develop entirely new ones. Overkill. In addition, critics of the WS-* process claim that the entire effort is overkill and that the vast majority of Web applications can work just fine with much simpler technologies. Advocates of this approach often use one of two acronyms to describe their preferred architecture: Plain Old XML (POX) and Representational State Transfer (REST). However, WCF does not require that developers use the advanced WS-* protocols. In fact, WCF can be used to create Web services that rely on nothing more than the most basic XML and HTPP standards. Resources More information about WCF can be found at msdn.microsoft.com/windowsvista. Although the information about WCF here is not specific enough to be useful to developers, developers might want to watch this space for better information, such as the useful information previously available when WCF was known as Indigo. The MSDN Web Services Developer Center is at msdn.microsoft.com/webservices. The WCF programming model is described in more detail at msdn.microsoft.com/library/en-us/dnlong/html/progindigoch3.asp. Other aspects of Windows Vista are covered in "Longhorn Becoming Compelling Vista?" on page 3 of the Nov. 2005 Update and "New Graphics Framework Built Around .NET, XML" on page 12 of the Nov. 2005 Update. The tenets that make up a service-oriented architecture are discussed in "Principles of Service-Oriented Architectures" on page 23 of the June 2004 Update. The benefits of contract-first development are discussed at msdn.microsoft.com/msdnmag/issues/05/05/ServiceStation/default.aspx. Details on WSE 3.0 can be found at msdn.microsoft.com/library/en-us/dnwse/html/newwse3.asp. |