Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Preparing for Indigo—Choosing the Right Technology Today

Today .NET offers three distinct technologies for application connectivity: Web services, remoting, and Enterprise Services. Each offers something that the other does not: interoperability, extensibility, and productivity. In preparing for Indigo, you need to choose today a technology that best approximates its programming model, most likely Enterprise Services.




Application Security Testing: An Integral Part of DevOps

ndigo is the next generation application connectivity and services from Microsoft, superseding the variety of .NET connectivity solutions available today: ASMX Web services, Remoting, and Enterprise Services. Since .NET debuted some five years ago, all three technologies have been inundated in either hype or misconceptions. With Indigo around the corner, it is time to take a long hard look at these three technologies, and separate fact from myth so that you will be best prepared for Indigo. This article starts by examining the existing technologies, describing their merits and shortcomings, putting them in the correct perspective of a modern distributed application, and suggests where to best apply them. Then the article briefly describes the Indigo programming model, and assesses how to best mitigate the cost of the migration.

Crossing Boundaries with Web Services
Web services are a generic name used to describe method invocation using a text-based protocol over HTTP. Web services are not synonymous with SOAP—most non-binary, text-based protocols such as HTTP GET or HTTP POST could qualify as Web services. Web services are not specific to the Web and are often used by intranet-based applications. In fact, today, most deployed Web services actually are used in the context of intranets. The architecture of Web services is simplicity itself—a Web server such as IIS receives a request over HTTP. It is then up to the Web server to interpret that request. In .NET, a request for an ASMX page causes IIS to load a corresponding Web application in a worker process and let a set of .NET DLLs use a class associated with that ASMX page to handle the request. This architecture is shown in Figure 1. .NET does the conversions from the request payload (often in SOAP XML) to Web method calls. .NET is also responsible for converting returned values from managed types to standard text-based representations. Under .NET 2.0, the Web server need not even be IIS—any running process can easily become a HTTP requests handler.

Figure 1: .NET Web services architecture.
Converting types to and from text representation has a performance penalty, but more important is the limitation on the expressiveness of the types you can expose on the Web service methods. In addition, using HTTP as a connectionless protocol imposes certain restrictions on the object model, as it is best-suited for single call objects. Maintaining state is usually confined to a session. Because Web services themselves are based on simple text-based protocols, they lack the ability to support high level business semantics. With respect to security, raw Web services have no support for propagating security call context, single sign-on authentication, credential management, impersonation, and so on. Web services do not flow transactions, and there is no way using raw Web services to comprise a few Web service calls into a single logical transaction. Web services lack concurrency management so they leave developers susceptible to distributed deadlock and hard to resolve reentrancy issues. To address these issues, you need to implement complex emerging standards such as WS-Security or WS-AT (Atomic Transactions). Since most of these emerging standards are still, well, emerging, anything concrete you do now is likely to be proprietary and couple the service provider to the service consumers. In addition, extending Web services is a notorious task, and while .NET makes it easier than other platforms, it is still not a job for the faint of heart, and well beyond the reach of most developers.

You can use Web services to cross all types of boundaries
The reason organizations and developers are willing to put up with these shortcoming is interoperability. Since Web services cater to the lowest common denominator (text over HTTP), virtually every operating system, Web server, and development technology can expose or consume Web services. Imagine a .NET client that wants to interact with a J2EE component. Neither one of these technologies support natively calling the other, yet both support Web services, so you can use Web services to interoperate between the two. C++ components on Windows can use Web services to interact with C++ components on Linux. In general, any kind of technology boundary, from operating system to development language can be bridged using Web services. The presence of a firewall poses another kind of a boundary; a trust boundary in this case. Fortunately, since all that is exchanged between the Web service provider and the Web service consumer is text, most firewalls will allow Web services calls by default. In general, you can use Web services to cross all types of boundaries: technological, trust and security, deployment topology, organizational, geographical, and so on.

Extensibility with .NET Remoting
.NET remoting is a .NET-specific technology used to cross app domain boundaries. .NET remoting requires both the client and the object to be running in .NET, and the server object must derive from a class called MarshalByRefObject. The .NET remoting architecture is a modular and extensible architecture. The basic building blocks on the client side are proxies, formatters, and transport channels, and on the host side, the building blocks are transport channels, formatters, and call dispatchers. These building blocks are shown in Figure 2. The client interacts with a proxy which .NET creates on the fly based on the object's metadata. The proxy converts the method call to a message and passes it through a set of message sinks. The default configuration uses two sinks—one to serialize the message (the Formatter), and the other to transport it (the Channel). On the server side, there are two message sinks that accept the message, deserialize it, build the stack on the object, and make the call.

Figure 2: .NET remoting architecture.
When the call returns the process is reversed. Out of the box, .NET 2.0 supports two message formats—binary and SOAP, and three channels—TCP, HTTP, and IPC. For best performance across machine boundaries you should use binary format over TCP. However, if a firewall is present, you can use SOAP over HTTP to go across the firewall. In the scope of a single machine you can use IPC to make inter-process communication calls. IPC is based on named pipes and will refuse any calls from outside the machine. .NET remoting usually requires the developers to provide their own hosting process for the remote object. Remoting supports several object activation models that cater to most (but not all) needs of scalability and throughput. In addition, there are complex issues involving managing the lifetime of the remote object using leasing and sponsorship, and most types of callbacks and events are disabled by default, though you can unlock them.

Figure 3: Extending .NET remoting.
Out of the box, the only high level services offered by remoting in .NET 2.0 is call security—you can propagate the security call context, authenticate and authorize callers, and even sign and encrypt the messages. Similar to Web services, remoting by default does not offer any other services such as transaction propagation, host life time management, concurrency management, discontented calls, event broadcasting, etc. Remoting's saving grace is its architecture. Almost every point in the architecture in extensible, and you can inject your own message processing sinks both on the client and on the server side (see Figure 3). These message processing sinks can perform pre- and post-call services, such as custom security, logging and tracing, concurrency management, caching, transaction management, and many more. A specific type of remote objects called context-bound objects is specifically designed for extensibility this way, and it offers a concurrency management service out of the box.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date