Coexisting with Existing Technology

With .NET, Microsoft espouses a vision of how the Internet can make businesses more efficient and deliver services to consumers. WCF takes all the capabilities of the existing technology stacks while not relying upon any of them. WCF is a new investment and relies on the classes that are available in the .NET Framework 3.0. All your existing investments will run side by side with WCF. Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed. It also provides you with an opportunity to communicate with, or even replace, existing Windows communications APIs and technologies, including ASMX, ASP.NET web services, Web Services Enhancements (WSE), Enterprise Services, System.Messaging, and .NET Remoting.

Hosting Services

A class implementing a WCF service is typically compiled into a library, and thus it needs a process to host the services. If you look at earlier distributed technologies, you will find that most of the distributed technologies are bound with only one hosting environment. For example, ASMX web services can be hosted only with HttpRuntime on IIS. A COM+ application requires component services as the hosting environment. .NET Remoting is a bit more flexible, with channels and transports being used. This limits the variety of clients that can access your component.

WCF has been made with a vision to allow endpoints to be seamlessly available for any kind of scenario and thereby ready to meet any requirement. A WCF component can be hosted in any kind of environment in .NET 3.0, be it a console application, Windows application, or IIS. To be honest, it hardly matters that the WCF client knows which environment is hosting its services. (Not only does it provide you with a variety of hosting environments, it also supports various activation models.) By hosting the service in IIS, it offers a lot of benefits such as automatic object activation and periodic recycling. Along with providing a lot of benefits, it comes with a tight coupling with HTTP. However, WCF gives you the freedom to self-host a WCF service. (Chapter 5 details the hosting options.) This is the reason for calling the WCF services services as opposed to web services. The terminologies have changed because you can host services without a web server. Earlier, web services used a default transport protocol such as HTTP. WCF provides different transport mechanisms such as TCP, Custom, UDP, and MSMQ.

Migration/Integration with Existing Technology

WCF, being the next-generation way of developing distributed applications, has raised the curiosity level of developers working in existing distributed technologies. This is true because existing applications are likely to be impacted in the near future. There are already a lot of investments in applications built on ASMX, WSE, and System.EnterpriseServices. Here are some important questions when thinking about working with WCF:

• Will new applications developed using WCF work with your existing applications? For example, will your new WCF transacted application work with your existing transaction application built on System.Transactions?

• Will your existing applications be able to upgrade with WCF?

Fortunately, the answers to these questions are yes and yes! In truth, existing distributed applications cannot be migrated to WCF in a single day. Microsoft has created a durable surface for WCF to interoperate with existing investments. The WCF team consists of the same developers who built the System.Messaging, System.EnterpriseServices, WSE ASMX, and .NET Remoting technologies. WCF can use WS-* or HTTP bindings to communicate with ASMX pages, as shown in Figure 2-5. In other words, integration with existing systems was on the minds of the WCF team from the beginning.

Microsoft has implemented a set of capabilities within the WCF product suite to enable you to interact with and to reuse COM+ applications without having to fundamentally change your programming experience. Therefore, if you have COM+ applications, WCF lets you essentially write code that can access existing WCF applications as if they were COM+ applications.

This technology is simple to use. The samples that accompany WCF show how to use it. Also, a command-line tool called COMSVCConfig.exe (discussed in Chapter 10) lets an existing COM+ application spit out a WCF stub to interoperate with COM+ applications. The stub brokers call back and forth between the stub and COM+ application. MSMQ also integrates well with WCF. If you have an existing MSMQ application and use it to send messages back and forth between systems using queues, then WCF offers an msmqIntegrationBinding binding that allows communication with existing MSMQ applications. If you want to use a WCF application to utilize MSMQ on the wire, this binding is available to you so your applications can communicate with MSMQ applications openly.

A WCF application not only interoperates with applications running on other platforms but also integrates with other distributed programming models that Microsoft has come up with over the past ten years. Microsoft has been providing the upgrade path through the use of wizards, which are the easy way to perform complex tasks. Honestly, these wizards are good in labs and can be used only for upgrading sample and testing applications. Using wizards to upgrade a complex application is ill advised. This time, Microsoft, having learned from past experiences of wizards to migrate applications, is using a more practical approach by providing a bunch of white papers and guidance, samples, demos, and examples illustrating how to port applications from ASMX, Enterprise Services, .NET Remoting, WSE, and MSMQ to WCF and other technologies. These examples also address many of the concerns you'll have when going through the porting process.

Components vs. Services

Reusability is the key to success in a distributed environment. Most of the architecture focuses on the way to maximize the components' usage in an easy and efficient manner. Most components are built on an object-oriented paradigm that also provides reuse in terms of encap-sulating the state (data) and behavior (function) in a container called a class. We have already discussed the flaws in object-oriented technology in applications that mandate the need of loosely coupled distributed systems. Services compose a distributed system that can loosely couple one another to achieve a particular business goal. These services can later be composed differently to achieve a different business goal.

A lot of confusion exists about the terms component and services; a component is compiled code. It can be assembled to build applications and can also be deployed. Ease of reusability, maintenance, and lower application costs are some of the major factors for initiating component-based development. Most of the time, the term component has been associated with object-oriented programming but as per our earlier definition, you can use components to build services. The functionality that gets added on top of the component features is the service definition. This service description gets deployed with the components, and the communication with the service is governed by data contracts and policies.

The term services is used widely in various contexts. In service orientation, the term service is that which adheres to the four tenets of service orientation, and services are independently versioned, deployed, operated, and secured in a message-oriented fashion. To paraphrase Martin Fowler from his book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley, 2003), interesting applications rarely live in isolation. We discussed some of the challenges we face when trying to integrate applications in a homogeneous environment in Chapter 1. These can range from the tactical issues that a developer may face to the more strategic issues in a corporate environment where the challenges are quite difficult.

For a more detailed understanding of WCF's unified programming model, please refer to Chapter 3. The WCF stack maps almost on a one-to-one basis to all the SOA principles, as shown in Figure 2-6, which covers both the concrete and abstract implementations. WCF simplifies the development of connected systems because it unifies a wide range of distributed systems in a composite and extensible architecture. This architecture can span various transport layers, security systems, messaging patterns, network topologies, and hosting models.

Building an application in terms of a service and not components also provides enormous benefits in terms of the reuse of code, the reuse of service and functionality, and the ability to glue together far more dynamic, far more agile business applications and business services. WCF makes it easy for developers to create services that adhere to the principle of service orientation. If you are an OO person, you will find a few things to be restrictive in SOA. The SOA world is a world of messages and not objects. Few key features (such as the ability to pass an object reference) exist in the current technology stack that are not available in WCF. Actually, the paradigm has shifted now from object oriented to service oriented, and it makes more sense to pass messages between services instead of objects.

Support of Visual Studio 2005

WCF is a technology that comes with the .NET Framework 3.0. One of the advantages of using the .NET Framework is that you can use any of the languages supported by the CLR to build SOA applications. Any technology can be successful only if it has the required tools and designers to develop the components. Since the introduction of Visual Basic, Microsoft has always tried to simplify development by utilizing Visual Studio and the integrated development environment (IDE). WCF is actually one of the pillars for Windows Vista but can also run on Windows XP and Windows 2003 through the .NET Framework 3.0. Visual Studio 2005 supports WCF.

Figure 2-7 demonstrates that you get the required templates, IntelliSense in the configuration file, and the familiar IDE for creating WCF services. Developers who are already familiar with the Visual Studio IDE can leverage it to create service-oriented connected systems. You don't need to learn a new language for creating service-oriented applications. Languages such as C# and VB .NET, plus all the other CLR-compatible languages, have been extended to use the capabilities of the classes of WCF. Chapter 4 discusses the Visual Studio IDE and how WCF utilizes the IDE.

One Service, Multiple Endpoints

If you look at the current distributed technology stack, you will find that services are tightly coupled with the transport, the channels, the URLs, and the features the stack provides such as security and reliability. Service development is greatly affected by the transport you use. After defining the service, you have to specify some vital information such as what this service can do, how can it be accessed, and where it is available. These three are encapsulated in endpoints. An endpoint contains information that gives the path through which the service is available. One service can have multiple endpoints, which makes it flexible and interoperable for any application requirements. Each of these endpoints can differ in the address, binding requirements, or contract getting implemented.

WCF provides a unique way to create services independent of the transport being used. Figure 2-8 shows that the same service can be exposed with two different endpoints. Both of the endpoints have different binding requirements. For example, Endpoint 1 and Endpoint 2 have the transaction support but run on different transport protocols. In the future, if you need to have another client that has different binding requirements, all you need to do is create another endpoint in the configuration file. This enables you to serve the needs of two or more clients requiring the same business logic encapsulated in the service with different technical capabilities.

Integration Technologies

In addition to extending the functionality of the .NET Framework and Visual Studio 2005, you can use WCF with BizTalk Server to provide both brokered and unbrokered application-to-application communication. Actually, BizTalk Server and WCF are complementary to each other. BizTalk Server provides business process orchestration, message transformation, business activity monitoring, and more, through designers and visual tools. WCF provides a unified framework for building secure and reliable transacted services. BizTalk Server is a key technology in and is responsible for orchestrating WCF services. In future versions of BizTalk Server, the orchestration process will use workflow foundation. BizTalk Server provides a WCF adapter that enables WFC services to be incorporated into business process orchestration. In future versions of BizTalk Server, the integration between these technologies will be even more seamless, with WCF providing the core messaging and web service capabilities of BizTalk Server and with WCF integrated in the native protocol of BizTalk Server.