Web Services Interview Preparation Guide

Download PDF

SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.

UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web services protocol stack.
UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.
UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.

The Web Services Description Language (WSDL) currently represents the service description layer within the Web service protocol stack.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:
Information on all publicly available functions.
Data type information for all XML messages.
Binding information about the specific transport protocol to be used.
Address information for locating the specified service.
WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.

HTML: None, Web Services do not use HTML.
HTTP: How to type in a URL.
SOAP: None to minimal.
WSDL: None to minimal.
XML: None to considerable.

HTML: None, Web Services do not use HTML.
HTTP: How to turn on the 4th Dimension Web server.
SOAP: How to activate 4th Dimension Web Services.
WSDL: None to minimal.
XML: None.

Yes and no. The SOAP and WSDL standards are relatively new, but the idea of sending messages between programs over a network has been around for decades. Past efforts to create network-oriented distributed object frameworks like CORBA, DCOM, and Java RMI haven't gone to waste. While creating these tools, the computer science and application development communities discovered and learned important information about how to
build widely distributed systems. In the words of Tim Bray, co-editor of the XML 1.0 spec:
SOAP has the advantages that it's simpler and easier to implement than any existing alternative, and makes better use of the pervasive Web
infrastructure. The effect is that you can pull a system together using SOAP in weeks, not quarters. Obviously, the alternatives offer richer feature sets, particularly in the area of transaction semantics, security, and so on, but at a dramatically higher cost. SOAP will not sweep all before it; but it will be very widely deployed across the Internet and the intranets of this world.

Today's variety of computer platforms, operating systems, programming languages, and development environments shows no signs of diminishing. Heterogeneity is the norm in the IT world, has always been so, and will remain so for the foreseeable future. Getting diverse systems to communicate and cooperate is an ongoing challenge for many organizations. Past efforts to create an overall framework for network-oriented program integration, such as DCOM and CORBA, are complex, proprietary, and expensive to implement. Reducing the cost and complexity of integration projects is a driving force behind Web Services standardization and adoption. While current Web Service systems have fewer features
than a system like CORBA, today's Web Services offer more features than developers actually need. Fortunately, the largest software vendors in the world, including- Microsoft, IBM, Sun, and Oracle-are cooperating on the core Web Service standards. 4th Dimension's Web Services features enable developers to quickly and easily publish and subscribe to Web Services.

XML-RPC is a protocol that uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML and sent via HTTP POST; XML responses are embedded in the body of the HTTP response.
More succinctly, XML-RPC = HTTP + XML + Remote Procedure Calls.
Because XML-RPC is platform independent, diverse applications can communicate with one another. For example, a Java client can speak XML-RPC to a Perl server.
To get a quick sense of XML-RPC, here is a sample XML-RPC request to a weather service (with the HTTP Headers omitted):
<?xml version="1.0″ encoding="ISO-8859-1″?>
<methodCall>
<methodName>weather.getWeather</methodName>
<params>
<param><value>10016</value></param>
</params>
</methodCall>
The request consists of a simple element, which specifies the method name (getWeather) and any method parameters (zip code).

Here is a sample XML-RPC response from the weather service:
<?xml version="1.0″ encoding="ISO-8859-1″?>
<methodResponse>
<params>
<param>
<value><int>65</int></value>
</param>
</params>
</methodResponse>
The response consists of a single element, which specifies the return value (the current temperature). In this case, the return value is specified as an integer.
In many ways, XML-RPC is much simpler than SOAP, and therefore represents the easiest way to get started with Web services.
The official XML-RPC specification is available at XML-RPC.com. Dozens of XML-RPC implementations are available in Perl, Python, Java, and Ruby. See the XML-RPC home page for a complete list of implementations.

This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.
Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole zoo of newer, evolving protocols. These include WSFL (Web Services Flow Language), SOAP-DSIG (SOAP Security Extensions: Digital Signature), and USML (UDDI Search Markup Language). For an overview of these protocols.

This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.

This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.

This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).

The Web service protocol stack is an evolving set of protocols used to define, discover, and implement Web services. The core protocol stack consists of four layers:
★ Service Transport
★ XML Messaging
★ Service Discovery
★ Service Description

People have been using Remote Procedure Calls (RPC) for some time now, and they long ago discovered how to send such calls over HTTP.
So, what is really new about Web services? The answer is XML.
XML lies at the core of Web services, and provides a common language for describing Remote Procedure Calls, Web services, and Web service directories.
Prior to XML, one could share data among different applications, but XML makes this so much easier to do. In the same vein, one can share services and code without Web services, but XML makes it easier to do these as well.
By standardizing on XML, different applications can more easily talk to one another, and this makes software a whole lot more interesting.

Many people and companies have debated the exact definition of Web services. At a minimum, however, a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system.
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL).
XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language-Java can talk with Perl; Windows applications can talk with Unix applications.
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration.

The Installutil.exe tool.

The System.Diagnostics is the namespace, which must be included in a code to enable a Web service for writing events in an event log file.

The proxy file must be stored in the /bin directory. This directory is situated under the root directory of the application.

The Web services do not have any technique to maintain state. However, it can access ASP.NET objects, such as application and session if they extend from the WebService base class.

A client application uses a .disco file to locate or discover the documents that contain the description of a Web service. The .disco file contains links to other resources, which describe essential features, such as capabilities of a Web service. The links contained in a .disco file can refer to other discovery documents or XSD schemas. The description about the services and capabilities of a Web service is written in Web services Description Language (WSDL). A .disco file can also contain the information about other XML Web services that reside on the same or a different Web server.

The Serialization of the types, such as integers and strings, inside a SOAP message is called encoding. The SOAP objects use XML elements and attributes to serialized data, for example, encodingStyle is an attribute of the Envelop element, which is used to specify the encoding rules for a SOAP object.

There are many properties defined in the WebServices class:
★ Application - Obtains the application object for the current HTTP request
★ Context - Obtains the HttpContext object for the current request, which encapsulates all HTTP-specific context used by the HTTP server to process Web requests
★ Server - Obtains the HttpServerUtility object for the current request
★ Session - Obtains the HttpSessionState object for the current request
★ SoapVersion - Obtains the version of the SOAP protocol used to make the SOAP request to a Web service
★ User - Obtains the Server User Object. This property can be used to authenticate whether a user is authorized to execute the request.

The WebMethod attribute's EnableSession property enables you to enable session state for a Web method.

It is necessary to build a proxy class by using the wsdl.exe utility before a Web service can be consumed.

The two methods to discover the URL of Web services are:
★ Web service discovery tool (Disco.exe)
★ UDDI.