.NET web services Interview Questions And Answers

Web service is the way to publish application's function on web that can be accessible to the rest of the world.
Web services are the components that can be used by other applications
ASP.NET offers easy way to develop web services, just precede the functions with a special WebMethod ()> attribute in order them to work as Web Service.
Web services are discovered using UDDI directory services.
Web services are built on XML standard and use SOAP protocol that allows them to communicate across different platforms and programming languages.
Web services easily manage to work across corporate firewalls as they use HTTP protocol which is firewall friendly.
Web services platform elements are
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)
The web services are built on internet standards that are not platform or language specific.
The .Net framework provides in-built classes to build and consume web services.
The components offered by web services are reusable.
The examples of web service components can be shipment tracking, translation utility, weather forecasting, sports scores etc.

SOAP, Simple Object Access Protocol is a communication protocol, a way to structure data before transmitting it, is based on XML standard. It is developed to allow communication between applications of different platforms and programming languages via internet.

It can use range of protocols such as HTTP, FTP, SMTP, Post office protocal 3(POP3) to carry documents.

Http-Get, Http-Post works with name/value pair which means transferring complex object is not possible with these protocols, whereas SOAP serializes complex structure, such as ASP.NET DataSets, complex arrays, custom types and XML nodes before transmitting and thus allows exchange of complex objects between applications.

Two components can easily communicate using Remote Procedure Calls protocol. But because of their compatibility and security issues, most of firewalls and proxy server block this type of messages. SOAP uses HTTP channel to transport which makes it widely accepted protocal over the internet.

WSDL stands for Web Services Description Language, an XML-based language that describes Web services and how to access and locate them.

UDDI stands for Universal Description, Discovery and Integration. It is an open, Internet-based specification that offers directory service for storing information about web services.

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.

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.

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.

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 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.

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.

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
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.

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.

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.

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.

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

.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.

Both .Net Web services and .Net Remoting are Microsoft solutions for distributed application. Before choosing one of them for application development, let’s identify the differences between these technologies.

Protocol
.Net web services can be accessed only over HTTP whereas .Net remoting can be accessed over any protocol including TCP, HTTP, or SMTP.

Performance
In terms of performance, .Net remoting is faster than its counterpart web service when it uses TCP channel with binary formatter. But if you use soap formatter in .net remoting, web services with soap formatter either with TCP or HTTP channel provides faster solution.

Security
.NET Remoting can be hosted either in IIS or in other container. If hosted in IIS, .NET Remoting can benefit all security advantages of IIS. But when hosted other than IIS, the application has to take care security aspect itself.
On the other hand, .Net web services are hosted in IIS, by default. So, it leverages all features of security provided by IIS.

State Management
Web services are a stateless in nature like web application. You need to use state mechanism to retain state. You can use session or application object to maintain state. In .Net Remoting, Singleton objects can share state whereas if you don’t need to maintain state, you can use Singlecall objects.

Interoperability
Web services support heterogeneous environments which means client and remote object can be built in any platform.
.NET remoting requires the client be built using .NET, enforcing homogenous environment.

Reliability
Since .Net web services are hosted using IIS, they are reliable whereas .Net remoting application needs to maintain security on its own if not hosted using IIS. When hosted in IIS, .Net remoting is also as reliable as web services.

Ease of development
Create and consuming .Net web services are easier process. To create remoting object, you need create remote object, hosting application to host remoting object and configuration file to specify type of channel and formatter to be used by remoting object.

XML Web services are more restricted than objects exposed over .NET Remoting.
XML Web services support open standards that target cross-platform use.
XML Web services are generally easier to create and due to the restricted nature of XML Web services, the design issues are simplified.
XML Web services support only SOAP message formatting, which uses larger XML text messages.
Communication with .NET Remoting can be faster than XML Web service communication with a binary formatter.
XML Web services are designed for use between companies and organizations.
XML Web services don't require a dedicated hosting program because they are always hosted by ASP.NET.
Consumers can use XML Web services just as easily as they can download HTML pages from the Internet. Thus there's no need for an administrator to open additional ports on a firewall as they work through MS-IIS and ASP.NET