Preparing For WCF

Now you've seen how WCF services can be created and used. However, WCF is not ready with the release date of .NET 2.0. You can be best prepared for WCF by using today's technologies if you use them carefully with WCF in mind.

By using ASP.NET to develop Web services you have a great path to WCF. You can use Web Services Enhancements (WSE) if more Web service features are needed than are available with ASP.NET. WSE offers security, custom hosting of services, and the use of the TCP channel.

If services such as automatic transactions, object pooling, or separate processes are needed, Enterprise Services is a good option. You will see soon how Enterprise Services can be integrated with WCF.

For disconnected scenarios, where the client and server may run at different times (for example, with a notebook system), you should use System.Messaging.

For a fast communication between .NET applications, .NET Remoting with a binary formatter can be a good option. Be aware that .NET Remoting should only be used for communication between .NET applications on both sides of the channel. .NET Remoting is not a choice for platform-independent services.

Let's look at how these technologies can be integrated with WCF.

.NET Remoting

The major features of .NET Remoting are that you can use any application as a host, with the binary formatter faster communication than with ASP.NET Web services is possible, and you can have stateful and stateless objects. In this chapter, you've already seen that WCF supports any host and fast communication with NetProfileXXX bindings.

With .NET Remoting you can create stateless and stateful components. The .NET Remoting terms are well-known single-call and client-activated objects for stateless and stateful components. With well- known-singleton just a single object is shared for all clients. Using WCF, the behavior of instantiating objects is defined with the attribute [ServiceBehavior]. The InstanceMode property can have the values PerCall, PrivateSession, SharedSession, and Singleton. PerCall means that a new instance is created with every method call, PrivateSession defines that the same object is used within a session, setting the value to SharedSession allows sharing the same object across different sessions. With the value Singleton, just one instance is shared for all clients.

Object Type	.NET Remoting	WCF
Stateful objects	Client-Activated Objects	InstanceMode.PrivateSession InstanceMode.SharedSession
Stateless objects	Wellknown, SingleCall	InstanceMode.PerCall
Singleton	Wellknown, Singleton	InstanceMode.Singleton

 [ServiceBehavior(InstanceMode=InstanceMode.PerCall)] public class CourseRegistration : ICourseRegistration { 

How can you decide about using .NET Remoting or ASP.NET Web services today? .NET Remoting should only be used for communication between .NET applications on both sides of the channel. .NET Remoting is not a choice for platform-independent services.

As of today, there's no plan to offer accessing direct interop between .NET Remoting and WCF applications. You have to rewrite your .NET Remoting services for using WCF's features. If you factor the functionality of your service-code to separate classes, it shouldn't be a big issue to do that. With the service class you just have to remove the derivation from the base class MarshalByRefObject, and add the required attributes. The .NET Remoting configuration files can be replaced by WCF configuration. It also helps if you are using interfaces for the service classes.

There will be more issues if you extend .NET Remoting by using sinks. There's no easy way to change the sink code to create WCF interception code. Here the programming model is very different. However, the functionality of many sinks that you might implement today can be readily available with WCF. There wouldn't be the need to migrate these sinks. For the other sinks where you don't find corresponding functionality with WCF you should factor the functionality of the sinks to separate classes to make it easy for reusing at least part of your code.

If there's no need to use the new features of WCF with .NET Remoting applications, .NET Remoting and WCF can run side by side.

ASP.NET Web Services

With ASP.NET Web services, you can create platform-independent services today. Using ASP.NET to create Web services is a good option for being prepared for WCF in the future: ASP.NET Web services and WCF can interoperate directly. A WCF client can access an ASP.NET Web service, and a .NET 2.0 Web services proxy can access an WCF service. For this interoperability, the binding BasicProfile is used with WCF.

Porting the ASP.NET Web service to WCF is not a big deal, too. WCF can be hosted in ASP.NET; you just have to create a .svc file as shown earlier. The attributes [WebMethod] need to be changed to [OperationContract]. Other attributes can be added as needed, and you can get the additional WCF features for your service.

Enterprise Services

If you write serviced components today, there's a great migration path to WCF. Without changing the serviced components, you can create a WCF front-end that offers Web services access to the serviced components. Also, with the WCF service moniker, a COM client can access WCF services.

With the ComSvcConfig utility, you can create a WCF front-end to an Enterprise Services application:

 ComSvcConfig add /application:OrderControlComponent /interface:Wrox.ProCSharp.EnterpriseServices.OrderControl, IOrderControl /hosting:was /webDirectory:OrderControl /mex 

The option /application specifies the COM+ application, /interface the interface of the application that should be made available as a Web service. The option /hosting defines the process where the service should be hosted. The possible values for the /hosting option are was and complus. was uses a virtual directory of IIS, with complus the COM+ application process itself is used as the hosting process. The setting for /webDirectory specifies the virtual directory of the service. This directory must be configured with IIS before the WCF service is created. With the option /mex a metadata endpoint is created that can be used by WCF clients to read the metadata of the service.

The other way around, using COM clients to access WCF services, can be done too. In such a scenario, proxy code for the client must be created with the svcutil utility:

svcutil "http://localhost/OrderControl/OrderControl.svc" /language:c# /out:proxy.cs

The resulting proxy.cs file must be put into an assembly that is strongly signed and has the assembly attribute [ComVisible]applied:

 [assembly: ComVisible(true)] 

For this assembly, a COM Callable Wrapper (CCW) must be created and configured with the regasm utility (see Chapter 33, "COM Interoperability"), and the assembly must be installed into the GAC (see Chapter 15, "Assemblies"). When this is done, the COM client can access the service using a WCF service moniker. The code is an example of a VBScript client application using the service moniker:

 Set proxy = GetObject( "service:address=http://localhost/OrderControl/OrderControl.svc,  binding=wsProfileBinding, contract={}") 

As you've seen, WCF and Enterprise Services has a great interoperability features. The same can be said about Message queuing.

Message Queuing

Message Queuing is the technology that can be used in a disconnected environment. It's not necessary that the client and server applications are running during the same time (as it is necessary with asynchronous programming). Here the sending application writes messages to a queue, and the receiving application that can run on different times reads messages from the queue.

Using WCF, the WCF client application can write messages to the queue that are read from applications that make use of the System.Messaging namespace (see Chapter 31, Message Queuing). The other way around, using WCF as a service and classes from the System.Messaging namespace for the client application, can be done similarly. With both scenarios, the binding MsmqIntegration is used. This binding doesn't support authentication.

If both the sending and receiving applications are using WCF, the binding NetProfileMsmq can be used that also offers security integration with Message Queuing.