.Net Remoting Overview

Distributed application is a set of components distributed across network and work as if all the components are there on the same computer. These components based technologies can be developed using DCOM, CORBA, RMI etc. These technologies are good for intranet environment.

Microsoft has provided suitable framework for developing distributed application through .Net Remoting and Web Services. Remoting.net allows components to interact across application domains, processes, and machine boundaries. It enables your applications to take advantage of remote resources in a networked environment.

Web Services are best suited when clients outside the firewall calling components on the server over the Internet.

Remoting.Net is the best solution when clients and components are inside the firewall. It requires the client to be built using .NET which means it can’t work in heterogeneous environments.

.Net Remoting uses channels (HTTP and TCP channels) to transport messages to and from remotable objects. The HTTP channel uses the SOAP protocol to transport messages which means all messages are serialized to XML. The TCP channel uses a binary stream to transport the messages.

.Net Remoting supports two activation modes: Singleton and SingleCall. Singleton mode allows only one instance of an object at any time which means all requests are serviced by the single instance. You can maintain state across each request using this mode. SingleCall Mode creates a new instance of the object for each client request and are stateless.

.NET Remoting when hosted with IIS, can use all the security features of ASP.NET. But you need to implement your own security features for the application if channel is hosted in the process other than aspnet_wp.exe.

What is .Net Remoting?

.Net Remoting enables communication between applications across separate domains or networks. .Net objects are exposed to remote processes to have interprocess communication. With remoting, we can use TCP or HTTP communications protocols on any port. We can use text or binary formatting. .Net Remoting supports server activated (single call and singleton) as well as client activated objects.

Describe the .Net Remoting Architecture.

.Net Remoing allows communication between server and client objects. To facilitate this, when new instance of remote object is created in the client application, the client receives reference (called proxy) to the server object. This proxy object contains references to all the methods and properties of the server object. When the client object calls any method (the call actually on proxy object), which resolves the references and invokes server object, receives the result and pass on to the client application.

What are the remotable and non-remotable objects in .Net Remoting.

The remotable objects are the objects which can be distributed accross domains, can be used with domain. The non-remotable objects are the objects which can't be distributed accross domains. In distributed system, if an object is very big, we can make it non-remotable object.

Describe the type of remotable objects in .Net Remoting.

Marshal-by-value-objects - When client calls a method on marshal-by-value-object, the remoting system creates a copy of this object and passes the copy to the client application domain. The copy hence received can handle any method call in client domain. Using Marshal-by-value-object reduces resource consuming trip across network.
Marshal-by-reference-object - When client calls a method on Marshal by reference object, the remoting system create proxy object in the caller application that contains the reference of all method and properties of the object.

What are the types of activation modes in .Net remoting?

Server Activation Mode: In this mode, objects are created on the server when we call a method in the server class and not when we create instance using new. In this type of scenario, the client is always connected with server but the services are activated only when we call the method of the server class. We can create server activated object as a Singleton or SingleCall object. If we create server object as singleton, a single instance will manage all the clients. If we create server object as singlecall, the remoting system creates object each time a client method invokes a remote object.

Client Activation Mode: This object gets created when we create instance using new keyword. In this mode, client application domain defines the lifetimes of client activated objects. The client domain defines the lifetimes of client-activated objects. They use lifetime leases to determine the duration of their existence and after the lifetime expires, the object is marked for GC.

Describe the term Channel in .Net Remoting.

In .Net Remoting, an application use Channel to send message to another application which is runing in different domain or process. Before sending message, Channel converts message into appropriate format like XML or binary format. The channel that carries message(Mashalled parameter) can use protocal like TCP and HTTP. Channel can be HTTPChannel and TCPChannel. The HTTPChannel use soapFormatter to serialize messages into the XML format using SOAP protocal. Using SOAP method allows the client to call method on the remote object that might not be using .Net framework. The TCPChannel use binaryFormatter to serialize message into binary stream.

DCOM vs .Net Remoting

Answer - .Net Remoting is the successor of Distributed component object Model(DCOM). Both these technology are introduced by Microsoft that enable inter-process communication across application domains. DCOM was very successful technology. But it is never treated as best technology for inter-process communication because of lack of its support for interoperability across platform.

.Net Remoting is a new technology that ship with .Net Framework. It has all those features which are missing in DCOM. There are other pain involve with DCOM such as difficult to control format or channels, message trace is painful, change in configuration setting such as channels or port is not easy. DCOM is hard to learn and complicated to deploy and to maintain.

Differences between these two technologies are as follows.

DCOM technology is based on the COM architecture whereas .NET Remoting is primarily based on .NET Frameworks.

DCOM is based on proprietary binary protocol which is not supported by all object model, thus has big drawbacks in the internet world.

DCOM is based on RPC protocol whereas .Net Remoting can use TCP or HTTP protocol which is stardard protocal in the market.

DCOM is not firewall friendly, can't choose port. .Net Remoting, on the other hand, works easily across firewalls.

.Net Remoting supports cross platform communication which is not possible with DCOM (only for windows platform).

Components created DCOM involves complex deployment in windows registries whereas .Net Remoting involves easy deployment using either xml based configuration file or programmatically in the code.

DCOM uses windows security features whereas .Net Remoting can use security features of IIS if hosted with ASP.NET. .Net Remoting, if hosted other than ASP worker process, allows to create own security mechanism for the application.

In DCOM, server is started by Service Control Manager (SCM) upon receiving the activation request from the client whereas in .Net Remoting, IIS is responsible to start server service. If not hosted with IIS then client request will fail if the Remoting server is not already started.

DCOM manages remote object lifetime by frequent pinging of clients whereas .Net Remoting has more efficient leasing mechanisms to maintain object lifetime.

Define windows process

Answer - A process is an instance of a running application.
Each process is allocated its own block of available RAM space.
No process can access another process code or data.
If the process crashes, it dies alone without taking the entire OS or a bunch of other applications down.

Advantages of .Net Web Services

Web Services are supported on a wide range of platforms.

Web services may extend its interface and add new methods without affecting the clients as long as they still provide the old methods and parameters.

• A client makes a request to a web service, the web service returns the result, and the connection is closed. There is no permanent connection. This makes it easy to scale up and support many clients at a time.
• Firewalls can pose a challenge for distributed object technologies. The only thing that almost always gets through firewalls is HTTP traffic on ports 80 and 443. Because web services use HTTP, they can pass through firewalls without explicit configuration.

Explain in brief Web Service Standards.

Following are the standards used by web services:

WSDL
WSDL is used to create interface definition for a web services. It describes all about methods to the client, i.e. methods available in a web service, their parameters and return values.

SOAP

SOAP, Simple Object Access Protocol is a communication protocol, a way to structure data, based on XML. The web services use SOAP message format to encode information before sending.

HTTP
The SOAP message format in web services uses HTTP as communication protocol, i.e. SOAP messages are sent over HTTP channels.

DISCO
It is used to create discovery documents that provide links to multiple web service endpoints. The DISCO standard creates a single file that groups a list of related web services. A company can publish a DISCO file on its server that contains links to all the web services it provides.

UDDI
A standard for creating business registries that catalog companies, the web services they provide, and the corresponding URLs for their WSDL contracts.

Define the specifications that help in the discovery of a web service.

DISCO

DISCO, an abbreviation of discovery, is a file that groups together a list of related web services. A company that offers web services publishes a DISCO file on its server that has links of all the web services it provides. The client requests this file to see all the available web services. This standard is useful when client already know about a company that offers web services. You can also use DISCO standard while working in local network. It is not helpful to find all web services over the internet.

UDDI

UDDI (Universal Description, Discovery, and Integration) offers centralized directory for web services over the internet. It hosts web services from different companies and can be used by the clients to find web services of their specific need. To make web services shared publicly, they have to be published in UDDI.

What are the data types supported by Web Services?

.Net web services are built on XML-based standards for exchanging data. This means .NET web services can support only those data types that can be recognized by the XML schema standard. There are many proprietary .Net objects such as FileSteam, Eventlog etc. are not supported in the web services. These data types are .Net specific types that are not universally recognized, i.e. .Net specific only.

You can even exchange custom objects using .Net web services. The only limitation is that only public data members are transmitted, and all public members and properties must use one of the other supported data types.

You can use DataSet and DataTable to return information from database but can't use other ADO.NET objects such as DataColumns and DataRows.

.Net offers a distributed technology called .Net remoting that can plays around wide range of .Net specific data type. But unfortunately, .Net remoting doesn't support client other than .Net.

Testing and consuming a .Net web service.

Testing a Web Service

.NET has a test web page that ASP.NET uses automatically when you request the URL of an .asmx file in a browser. This page uses reflection to read and show information about the web services, such as the names of the methods it provides.

Consuming a Web Service

Web services are built on XML standard. So, a client needs to equip itself to understand XML-based message in order to exchange messages. The .Net framework provides proxy component that enable clients to interact with web services. The proxy has all necessary information that can be utilized by the client application to share data with web services.

The proxy class wraps the calls to the web service's methods. It generates SOAP message format and manages the transmission of the messages over the network (using HTTP). When it receives the response message, it converts the results back to the corresponding .NET data types.

You can create a proxy class in .NET in two ways:

By using wsdl.exe command-line tool
By using Visual Studio web reference feature

Why do we need .Net Web Services?

We have a number of heterogeneous technologies available on internet. The demand for reusable components across platforms and programming languages are high. Most of the components have the limitation that they can't share or exchange data across different platforms, they are mostly language specific or platform specific. The technologies like COM, RMI, CORBA etc. contributed best to fulfill requirements to some extent, but components result from these said technologies are mostly either language specific or platform specific.

To avoid above problem, we need to have web services. Through web services we have overcome the problem of interoperability between languages and platforms. Web services uses SOAP as transport protocol which uses a text based messaging model, i.e. XML to communicate between disparate systems.

Deploying a Web Service

Deploying the .Net Web Services is as simple as any ASP.NET application. Similar to ASP.NET applications, you need to copy or upload the .ASMX file and the .DISCO files to the appropriate directories, and that's it.

Explain in brief different distributed technologies.

The need of distributed technologies arises with the requirement of distributed computing applications. The distributed computing allows partitioning of application logic into units and spreading the unit over different computers of a network or across different networks. This helps in spreading out loads over many computers. The components once developed can be reuse by other applications. There are many technologies developed to allow the distribution and reuse of application logic.

Advantages of the distributed components:

• The key benefit of having distributed components is that they spread out the load over different machines.
• The components can be upgraded without disturbing the clients' code.
• The distributed application improves security. For example, a company who has many agents wouldn’t like those agents to have direct access to its database. Instead, these agents can be granted access to the components running on the corporate server which can be controlled and restricted.

Web services vs. CORBA and DCOM.

Web services
Web services use HTTP protocol for sending and receiving messages between the applications.
The data encoding in web services is based on XML.
Web services are defined using WSDL (Web Services Description Language).

• Web services are discovered using UDDI (Universal Description, Discovery and Integration).
• Web services are firewalls friendly.
• Web services supports interoperability i.e. cross platform integration is possible.

CORBA and DCOM

• These technologies use non-standard protocol, i.e. CORBA uses IIOP (Inter Internet Object Protocol), and DCOM uses RPC (Remote Procedure Calls)
• CORBA components are defined using CORBA Interface Description Language; DCOM components are defined using Microsoft Interface definition languages
• CORBA components are discovered using the CORBA registry, DCOM using the Registry.
• DCOM is a proprietary protocol that does not support interoperability and has firewall problems as DCOM transfers data in binary format and it uses many ports to call remote functions.
• CORBA uses the IIOP protocol, which is non-Internet friendly.
• CORBA and DCOM are fine for building enterprise applications that runs on the same platform and not good enough for applications that span platforms and languages.

When to use .Net Remoting over Web services

.Net Remoting provides distributed solution for a corporate use. So, if you need distributed environment to be implemented for internal use, .Net remoting is the best choice. If you require a faster distributed solution, .Net Remoting with TCP protocal using binary format is faster than Web services. .Net Remoting is better solution when large transfer of data is required.

How does .Net Remoting works?

Remoting.Net allows components to interact across application domains, processes, and machine boundaries, thus allows applications to access remote resources in a networked environment. The interaction of components is made possible through proxy in remoting architecture. When a client calls the remote method, it’s the proxy that receives the call. The proxy then encodes the message using formatter. The messages are then sent over the channel to the server process where listening channel receives the call and passes it to the remoting system. The requested method is then invoked and results are returned back to the client.

.Net Remoting provides an infrastructure where objects of different AppDomains can interact. A client interacts with server object using .Net Remoting architecture. An object interacts with other objects outside AppDomains using proxy since the objects can't access directly anything outside AppDomain.

Point to be noted.
A remote object is implemented by inheriting MarshalByRefObject class.
A client has to obtain proxy activating a remote object by calling CreateInstance, GetObject, or new.
Local objects can be passed as parameters when making remote calls. Local objects are passed by value in a remote call.
The object passed as parameter in a remote call must be serialized.

Activation Model
You need to activate remote object before use. There are two activation modes in .Net Remoting
Server Activation
In this mode, objects are created automatically when a client attempts to access the object. The object doesn't get created when you use new keyword to create instance of the server class.
Client Activation
In this mode, objects are created when you use new keyword to create instance of the server class.

A server object is created and deployed on the network that serves client requests. The server objects have to be registered with the CLR before it can be accessed by client. The details that have to be provided to the CLR are

Name of the assembly that should be loaded to activate the object
The namespace and type name of the object
The name of the endpoint where the object can be accessed
The channels to be used by client to communicate have to be registered.
The registered channels then start listening for clients to connect.

Once a remote object has been deployed, clients can connect and invoke methods on the server object.

In order to access remote object, the client first activates the object by calling new, GetObject, or CreateInstance. On activation request, a proxy is created to represent the remote object. The client message in the serialized form is transported to the server. The type of serialization depends on the channel. For example, when the HTTP channel is used, all messages are serialized to XML and transported over SOAP. On the other hand, TCP uses binary serialization.

On the server side, the requested method is then invoked and results are packaged in a message and returned back by to the client. If the target object is of type SingleCall, it will automatically be garbage collected after the call completes.

Approaches to access server objects in Remoting.Net

First one to have copy of server object on the client machine and accessing local copy of object to call method. This method is good suited when the object is not very big not having too many methods. Copying big object is wastage of client resources which includes network resources and processing time.

The second approach is to create a proxy object that returns reference of all the methods and properties of server object in the client domain. The proxy acts as local object, fake server object on the client machine. Any method call from the client will be served by proxy which in turn access server domain to get response from server object. This approach is good when the object is big with many methods.

Remotable and Nonremotable objects

You have two categories of objects in distributed applications: Remotable and Nonremotable objects.

Nonremotable object can’t be accessed outside its own application domain. This kind of object doesn't allow its methods or properties to be used by remoting system. Remotable objects can be accessed outside its own application domain. The remoting system can use methods and properties of this kind of object.

There are two types of remotable objects

Marshal-by-value-objects - When client calls a method on marshal-by-value-object, the remoting system creates a copy of this object and passes the copy to the client application domain. The copy hence received can handle any method call in client domain. Using Marshal-by-value-object reduces resource consuming trip across network.

Marshal-by-reference-object - When client calls a method on Marshal by reference object, the remoting system create proxy object in the caller application that contains the reference of all method and properties of the object.

Explain the protocols a .Net Web Service uses.

In .Net, a web service is bind with three different protocols such as HTTP/POST, HTTP/GET, and SOAP. This allows client with three options to choose for communication. The protocols are included in the WSDL file that is automatically generated in .NET.

Http-Get and Http-Post can only be used when name/value pairs of data is dealt with. But when data is complex in nature such as ASP.NET dataset, XML notes etc, then we can use SOAP that serializes data in simpler form before sending.

Explain how to document web services.

ASP.NET web services are considered as self documenting as they provides all information about what methods are available and what parameters they require using XML based standard called WSDL. We can also provide addition information about the web services using their WebService and WebMethod attributes.

You can add descriptions to each method through the Description property of the WebMethod attribute and to the entire web service as a whole using the Description property of the WebService attribute. You can also apply a descriptive name to the web service using the Name property of the WebService attribute. The attributes have name, description and namespace as properties which are shown in following example:

[WebService(Name = "Customer Service", Description = "Retrieve the Customer details",Namespace=http://www.apress.com/ProASP.NET/)]
public class Customer : System.Web.Services.WebService
{
[WebMethod(Description = "Returns Customer Count")]
public int GetCustomerCount()
{ ... }

[WebMethod(Description = "Returns the list of Customer")]
public DataSet GetCustomer()
{ ... }
}

Namespace allows your web service to be uniquely identified. By default, ASP.NET web services use the default XML namespace http://tempuri.org/, which is suitable only for testing. XML namespace simply identifies your web service. XML namespaces usually look like URLs. However, they don't need to correspond to a valid Internet location.

Explain when do we required ASP.NET web services.

ASP.NET web services are the great way to expose your middle tier components via internet. These components offer no issue communicating across firewalls as they use SOAP as transport protocols that transmit structured data using HTTP channel. Thus, message can be easily exchanged through port 80, i.e. through internet data port without being getting hampered by corporate firewalls or proxy server.

Web services can fit in the situation when we require integrating disparate systems written by separate vendors via internet.

Web services are primarily being used for B2B integration like authorizing employees, supplier, electronically signing of invoice etc.