DOT NET REMOTING QUESTIONS |
Answer: When any object is to be sent across the transport channel, it must be serialized and packed into a data format that can be transmitted with the wire. On the other end of the wire, this serialized data is read and deserialized back to the actual object. This Serialization is done by message-serialization formatters which convert the field or object's state into a format that is helpful for storage or transmission. Dot Net framework provides us two message-serialization formatters one of them is a binary serialization formatter which converts an object's state into a binary stream and other is SOAP serialization formatter which converts it into an XML string representation that's human readable. The binary serialization formatter much slightly faster.
Question:-What is Channels ?
Answer: Remote objects are accessed through Channels. Channels physically transport the messages to and from remote objects. There are two existing channels TcpChannel and HttpChannel. Their names give away the protocols that they use. In addition, the TcpChannel or HttpChannel can be extended, or a new channel created if you determine the existing channels do not meet your needs.
| Question:-What is .NET Remoting ? Answer: .NET Remoting is an enabler for application communication. It is a generic system for different applications to use to communicate with one another. .NET objects are exposed to remote processes, thus allowing interprocess communication. The applications can be located on the same computer, different computers on the same network, or even computers across separate networks. Question:- .NET Remoting versus Distributed COM ? Answer: In the past interprocess communication between applications was handled through Distributed COM, or DCOM. DCOM works well and the performance is adequate when applications exist on computers of similar type on the same network. However, DCOM has its drawbacks in the Internet connected world. DCOM relies on a proprietary binary protocol that not all object models support, which hinders interoperability across platforms. In addition, have you tried to get DCOM to work through a firewall? DCOM wants to communicate over a range of ports that are typically blocked by firewalls. There are a ways to get it to work, but they either decrease the effectiveness of the firewall (why bother to even have the firewall if you open up a ton of ports on it), or require you to get a firewall that allows support for binary traffic over port 80. |
Question:- Security in Remoting ?
Answer: Security is of paramount importance to any distributed application. Although the .NET Remoting infrastructure does not define any security features itself, because distributed applications are managed code they have full access to all of the .NET security features. In addition, the HTTP channel, when used with IIS, allows you to take full advantage of the authentication and authorization features that are available to Web based protocols. If you choose to use a protocol other than HTTP with IIS, then you have the opportunity to create your own security infrastructure.
Question:-Advantage of Remoting over Web Services ?
Answer: .NET Remoting is a distributed objects infrastructure. It allows processes to share objects—to call methods on and access properties of objects that are hosted in different application domains within the same process, different processes executing on the same computer, on computers on an intranet, or on computers distributed over wide areas. .NET Remoting supports many different communications protocols, including the SOAP/HTTP protocol used by ASP.NET Web services. Support for other protocols makes it possible to provide much faster communications in .NET Remoting than would be possible with ASP.NET Web services. The ASP.NET programming model is tied specifically to IIS, and is limited to creating Web services that use the producer/consumer model. .NET Remoting, on the other hand, can share objects from any type of application.
The .NET Remoting system, as an integral part of the .NET Framework, supports full .NET type system fidelity. You can pass any object across the wire to a client. This is in contrast to ASP.NET, which is limited to data types that can be expressed with WSDL and XSD.
Question:- Scope of publication ?
Answer: .NET Remoting exposes objects to other application domains as if they are local, with a few exceptions. The two exceptions most likely to trip you up are:
• Static members are never remoted. Remoting always deals with some form of object instance member.
• Private methods are never remoted. You cannot wrap and pass a delegate to a private method. This includes remote event handlers.
The other exceptions are less likely to cause you trouble. The online documentation provides a complete list and explanation of the exceptions.
Question:-What are the Proxies ?
Answer: In the general sense, a proxy is any object that stands in for another, either servicing requests directly or passing the requests on to the object for which it is standing in. In .NET Remoting, the proxy manages the marshaling process and the other tasks required to make cross-boundary calls. The .NET Remoting infrastructure automatically handles creation and management of proxies, although it is possible to create your own proxy classes to plug in to and customize proxy creation, marshaling, and other proxy-related tasks.
Question:-What is Abstract ?
Answer: .NET Remoting provides a powerful and high performance way of working with remote objects. Architecturally, .NET Remote objects are a perfect fit for accessing resources across the network without the overhead posed by SOAP based WebServices. .NET Remoting is easier to use than Java's RMI, but definately more difficult than creating a WebService.
Question:-Some Important Notes
Answer: The dependence on assembly metadata implies that client applications must understand .NET concepts. As a result, applications that make use of .NET Remoting are not interoperable with other systems. Although it's possible to write an XML Web service using .NET Remoting, it's not practical when you consider that ASP.NET is designed specifically for that task. In most cases, in order to use .NET Remoting, both the client and the server must be .NET applications. This makes .NET Remoting a poor choice if you want non-.NET clients to access your service.
Before we get into the nuts and bolts of how Remoting works and how to write programs that take advantage of it, you need to understand some basic Remoting concepts.
Question:-.NET Remoting Overview ?
Answer: .NET Remoting is very flexible. You have a wide range of communications options and activation methods, as well as full control over a distributed object's lifecycle. You can choose TCP or HTTP communications protocols on any port, using text or binary formatting. The .NET Remoting infrastructure supports server activated (single call and singleton) and client activated objects. .NET Remoting gives you many opportunities to "plug in" to the system to customize lifecycle management, marshaling, serialization, messaging, and other services.