Dot Net Interview Questions - Part 11

1. How you will protect / secure a web service?
   For the most part, things that you do to secure a Web site can be used to secure a Web Service. If you need to encrypt the data exchange, you use Secure Sockets Layer (SSL) or a Virtual Private Network to keep the bits secure. For authentication, use HTTP Basic or Digest authentication with Microsoft® Windows® integration to figure out who the caller is.
   these items cannot:
• Parse a SOAP request for valid values
• Authenticate access at the Web Method level (they can authenticate at the Web Service level)
• Stop reading a request as soon as it is recognized as invalid
2. How will you expose/publish a webservice?
3. What is disco file?
4. What’s the attribute for webservice method? What is the namespace for creating webservice?
   [WebMethod]
   using System.Web;
   using System.Web.Services;
5. What is Remoting?
   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.
6. Difference between web services & remoting?

	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.

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.

7. Can you pass SOAP messages through remoting?
8. CAO and SAO.
   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)
9. 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.
10. What is Asynchronous Web Services?
11. Web Client class and its methods?
12. Flow of remoting?
13. What is the use of trace utility?
    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.

0. On the server, open the Web Services Description Language (WSDL) file.
1. 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 .
2. Run MSSOAPT.exe.
3. 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).
4. 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.

5. Copy the WSDL file from the server to the client.
6. 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".
7. On the client, run MSSOPT.exe.
8. 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).
9. In the Destination host box, enter the host specified in Step 2.
10. In the Destination port box, enter the port specified in Step 2.
11. Click OK.
13. Explain the concept of data island?
14. How to use XML DOM model on client side using JavaScript.
15. What are the ways to create a tree view control using XML, XSL & JavaScript?
16. Questions on XPathNavigator, and the other classes in System.XML Namespace?
17. What is Use of Template in XSL?
18. What is “Well Formed XML” and “Valid XML”
19. How you will do SubString in XSL