Unifying Distributed Technologies
Many of the features in WCF have their deep roots in a number of technologies such as ASMX, Enterprise Services, .NET Remoting, MSMQ, and WSE. Though this book won't cover all these technologies, it's always good to take a sneak peek at each of these to get a better understanding of WCF.
ASMX
A web service is a component on the Web that is accessible through open standards such as SOAP and HTTP. Accessing a remote component is not a new concept. It was previously accomplished through RMI, CORBA, and DCOM. But these distributed components are based on proprietary standards or protocols. Earlier distributed technologies had two main problems:
Interoperability
Crossing firewalls
These proprietary standards cannot interoperate with each other because they have their own binary standards and protocols. Additionally, they send binary messages through a nonstandard port that results in creating "holes" in corporate firewalls. Web services deviate from all these issues by relying on web standards or protocols instead of relying on proprietary protocols. Web services are based on the notion of a service and transfer the data in messages.
A web service is a class that inherits from System.Web.Services.WebService and contains the method to be exposed with the [WebMethod] attribute over it. Listing 2-1 contains a class named Employee that has two public methods named Gand so onustomer and DeleteCustomer. The method name Gand so onustomer will be consumed only as web service methods because it has been decorated with the [WebMethod] attribute.
Example. Sample XML Web Service Class
<%@ WebService Language="C#" Class="Order.Employee" %>
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
namespace Order
{
public class Employee : WebService
{
[WebMethod()]
public DataSet Gand so onustomer(int CustomerID)
{
// logic to retrieve customer
}public DataSet DeleteCustomer(int CustomerID)
{
// logic to delete Orders of a customer
}
}
} |
To access any remote components, you need a transport protocol, a message protocol, and the serialization mechanism for a client and server. In web services, the transport protocol is mainly HTTP, though it can be SMTP or TCP as well. As far as a message protocol is concerned, SOAP is the preferred and default message protocol. It also supports HTTP GET or HTTP POST. XML web services use XML serialization.
The following are the problems with ASMX:
An ASMX page contains a complete set of information that describes how the data will be formatted, how to wrap the data in a SOAP header, and how to prepare it to be sent. However, it doesn't tell you how to deliver it over the transports and to use a specific type of security. All of those transport-oriented notions are missing from today's ASMX services, and this is something that WCF enhances quite significantly.
Another limitation of ASMX is the tight coupling with the HTTP runtime and the dependence on IIS to host it. This problem is solved by WCF, which can be hosted by any Windows process that is able to host the .NET Framework 3.0.
ASMX service is instantiated on a per-call basis, while WCF gives you flexibility by providing various instancing options such as Singleton, private session, per call. (We discuss these in detail in Chapter 4.)
ASMX provides the way for interoperability but doesn't fulfill some of the basic requirements; for example, it does not provide or guarantee end-to-end security or reliable communication.
MSMQ
Distributed systems have been built for many years by using synchronous RPCs. This means the sender application must be online during each request while the receiver carries out the requested task. The receiver must be online for the sender to make requests, and the sender must be online to issue requests. In other words, both the sender and receiver need to be online to make the task operational. Some applications (especially ones supporting disconnected environments) need to communicate in an asynchronous manner. Asynchronous-based communication through messages has become one of the alternatives in distributed computing. In this communication model, the client begins the process by sending messages and then continues doing other work or even goes offline without waiting for the operation to complete. If the receiver is offline, the entire request from the sender gets stored in queues. Once the receiver is ready, it can consume the messages from the queue and do the necessary operations on it. The best advantage is that the sender and receiver do not need to be available at the same time. It also ensures the reliable delivery of messages in a loosely coupled environment.
Asynchronous-based communication requires a custom messaging infrastructure. Fortunately, many middleware systems such as IBM's MQSeries and Microsoft's MSMQ provide built-in powerful capabilities to address these issues. (These packaged software products provide transactional support, guaranteed delivery, and security.) Message queues are stores that hold application-specific messages. Applications can read, send, store, and delete the messages in queues.
MSMQ is a set of objects that allows you to perform queue messaging in Windows. You can use this technology to collect a series of messages, send them to the server for processing, and receive the results when they are finished. MSMQ essentially provides the infrastructure to develop highly available business-critical applications. System.Messaging is the .NET layer on top of MSMQ. It gives you the ability to build queued applications through .NET. One of the limitations in MSMQ is the ability to deal with corrupted messages. A message is referred to as corrupted when the message cannot get processed after several attempts. These corrupted message(s) block other messages in the queue. Since MSMQ does not support this feature, developers used to write a lot of code to deal with corrupted messages. Few features of MSMQ (such as security and searching on public queues) are tightly integrated with Active Directory. Another issue with MSMQ is that developers need to write MSMQ-specific plumbing code in client and service code especially while writing a complex listener code to listen these queues.
WSE
Web services have become the unvarying way for consuming the business logic across platforms. The core architecture of web services only formulates the way that a message gets formatted and how a web service can be defined in a standardized manner. This core architecture enables you to consume web services in an interoperable manner. As the business requirements that drive web services become more and more complex, developers require additional capabilities that current web services standards do not address. A few of those capabilities include the following:
Security
Routing
Reliable messaging
Transactions
Rather than providing these capabilities in a proprietary manner, it was necessary for the future of web services to provide these capabilities in an open way. Industry leaders such as Microsoft and IBM came together to provide these additional capabilities in a standardized manner and drafted some web service standards also known as the WS-* suite of protocols. This was done in order to create a standard infrastructure for building the next generation of web services. Some of the WS-* suite of protocols are HTTP, standards-based XML, SOAP, WS-Addressing, and Message Transmission Optimization Mechanism (MTOM). These protocols are merely the specifications and do not provide the implementation details. Microsoft has been generous enough to provide the class library on the top of the .NET Framework called WSE that encapsulates the implementations details and provides an easy-to-use API to consume these specifications. WSE is a runtime that is built on the .NET Framework and uses outbound and inbound message filters to intercept SOAP messages.
|
WSE is an appealing technology in that it fundamentally helps accelerate the adoption of WS-* standards. WSE 3 is the latest version of WSE.
Enterprise Services
Every distributed component requires some basic services to work in a multiuser environment. In the early days of COM, developers spent a large amount of time creating an infrastructure to handle a large number of transactions, provide queuing infrastructure, and so on, for running the components. COM+ (also known as component services) provides an infrastructure that applications utilize to access services and capabilities beyond the scope of the developers who are actually building those applications. It also supports multitier architecture by providing the surrogate process to host the business objects. In many ways, COM+ is a combination of COM, DCOM, MTS, and MSMQ in a single product. This application infrastructure includes services such as transactions, resource management, security, and synchronization. By providing these services, it enables you to concentrate on building serviced components rather than worrying about the infrastructure required to run these business components. COM+ has two types of applications, namely, server applications and library applications. A server application is hosted by the COM+ surrogate process and supports all the services. Contrary to this, library applications are hosted by the client process, and certain COM+ services such as queued components and object pooling are not available to a library application. One of the many advantages of component services is that it allows you to select the appropriate services.
COM+ was initially for providing an infrastructure to COM components, but this does not mean it cannot be used from .NET. .NET components can also utilize COM+ services through the attributes and classes residing in the System.EnterpriseServices namespace. .NET Enterprise Services, which is the .NET layer on top of COM+, gives a powerful distributed component technology capability by providing the necessary service infrastructure to .NET assemblies. The classes in .NET that can be hosted by the COM+ application and use COM+ services are called serviced components. Any class in .NET that derives directly or indirectly from the System.EnterpriseServices.ServicedComponent class is called a serviced component class. Listing 2-2 illustrates these concepts for a fictitious Account class.
Example. Serviced Component for the Account Class
using System.EnterpriseServices; using System; [Transaction(TransactionOption.Required)] public class Account : ServicedComponent {
[AutoComplete]
static void Main()
{
}
} |
Enterprise Services, or COM+, is a component-oriented technology. It is used inside the service boundary and implements the complex business logic as with transactions spanning multiple objects and spanning multiple resources. However, Enterprise Services applications are tightly coupled with the infrastructure. Microsoft has always regarded Enterprise Services as the core technology for providing the infrastructure, but it also suffers heavily from interoperability.