Friday, April 3, 2009

ASP.NET Web Service and Remoting Interview Questions Part II

16. What is Remoting?

Ans. The process of communication between different operating system processes, regardless of whether they are on the same computer. The .NET remoting system is an architecture designed to simplify communication between objects living in different application domains, whether on the same computer or not, and between different contexts, whether in the same application domain or not.

17. Difference between web services & remoting?

Ans. ASP.NET Web Services .NET Remoting
Protocol Can be accessed only over HTTP Can be accessed over any protocol (including TCP, HTTP, SMTP and so on)
State Management Web services work in a stateless environment Provide support for both stateful and stateless environments through Singleton and SingleCall objects
Type System Web services support only the datatypes defined in the XSD type system, limiting the number of objects that can be serialized. Using binary communication, .NET Remoting can provide support for rich type system
Interoperability Web services support interoperability across platforms, and are ideal for heterogeneous environments. .NET remoting requires the client be built using .NET, enforcing homogenous environment.
Reliability Highly reliable due to the fact that Web services are always hosted in IIS Can also take advantage of IIS for fault isolation. If IIS is not used, application needs to provide plumbing for ensuring the reliability of the application.
Extensibility Provides extensibility by allowing us to intercept the SOAP messages during the serialization and deserialization stages. Very extensible by allowing us to customize the different components of the .NET remoting framework.
Ease-of-Programming Easy-to-create and deploy. Complex to program.

18. Though both the .NET Remoting infrastructure and ASP.NET Web services can enable cross-process communication, each is designed to benefit a different target audience. ASP.NET Web services provide a simple programming model and a wide reach. .NET Remoting provides a more complex programming model and has a much narrower reach.
As explained before, the clear performance advantage provided by TCPChannel-remoting should make you think about using this channel whenever you can afford to do so. If you can create direct TCP connections from your clients to your server and if you need to support only the .NET platform, you should go for this channel. If you are going to go cross-platform or you have the requirement of supporting SOAP via HTTP, you should definitely go for ASP.NET Web services.
Both the .NET remoting and ASP.NET Web services are powerful technologies that provide a suitable framework for developing distributed applications. It is important to understand how both technologies work and then choose the one that is right for your application. For applications that require interoperability and must function over public networks, Web services are probably the best bet. For those that require communications with other .NET components and where performance is a key priority, .NET Remoting is the best choice. In short, use Web services when you need to send and receive data from different computing platforms, use .NET Remoting when sending and receiving data between .NET applications. In some architectural scenarios, you might also be able to use.NET Remoting in conjunction with ASP.NET Web services and take advantage of the best of both worlds.
The Key difference between ASP.NET webservices and .NET Remoting is how they serialize data into messages and the format they choose for metadata. ASP.NET uses XML serializer for serializing or Marshalling. And XSD is used for Metadata. .NET Remoting relies on System.Runtime.Serialization.Formatter.Binary and System.Runtime.Serialization.SOAPFormatter and relies on .NET CLR Runtime assemblies for metadata.

19. Can you pass SOAP messages through remoting?

20. CAO and SAO.

Ans. Client Activated objects are those remote objects whose Lifetime is directly Controlled by the client. This is in direct contrast to SAO. Where the server, not the client has complete control over the lifetime of the objects.
Client activated objects are instantiated on the server as soon as the client request the object to be created. Unlike as SAO a CAO doesn’t delay the object creation until the first method is called on the object. (In SAO the object is instantiated when the client calls the method on the object)

21. singleton and singlecall.

Singleton types never have more than one instance at any one time. If an instance exists, all client requests are serviced by that instance.
Single Call types always have one instance per client request. The next method invocation will be serviced by a different server instance, even if the previous instance has not yet been recycled by the system.

22. What is Asynchronous Web Services?

23. Web Client class and its methods?

24. Flow of remoting?

25. What is the use of trace utility?

Ans. Using the SOAP Trace Utility
The Microsoft® Simple Object Access Protocol (SOAP) Toolkit 2.0 includes a TCP/IP trace utility, MSSOAPT.EXE. You use this trace utility to view the SOAP messages sent by HTTP between a SOAP client and a service on the server.
Using the Trace Utility on the Server
To see all of a service's messages received from and sent to all clients, perform the following steps on the server.
1. On the server, open the Web Services Description Language (WSDL) file.
2. In the WSDL file, locate the element that corresponds to the service and change the location attribute for this element to port 8080. For example, if the location attribute specifies
change this attribute to .
3. Run MSSOAPT.exe.
4. On the File menu, point to New, and either click Formatted Trace (if you don't want to see HTTP headers) or click Unformatted Trace (if you do want to see HTTP headers).
5. In the Trace Setup dialog box, click OK to accept the default values.
Using the Trace Utility on the Client
To see all messages sent to and received from a service, do the following steps on the client.
6. Copy the WSDL file from the server to the client.
7. Modify location attribute of the element in the local copy of the WSDL document to direct the client to localhost:8080 and make a note of the current host and port. For example, if the WSDL contains , change it to and make note of "MyServer".
8. On the client, run MSSOPT.exe.
9. On the File menu, point to New, and either click Formatted Trace (if you don't want to see HTTP headers) or click Unformatted Trace (if you do want to see HTTP headers).
10. In the Destination host box, enter the host specified in Step 2.
11. In the Destination port box, enter the port specified in Step 2.
12. Click OK.

1 comment:

Eran Smith said...
This comment has been removed by the author.