Be Expert with us in .NET and SQL Server

  Agenda

•  What is an XML Web service?
• What does an XML Web service do?
• XML Web Services in .NET lWSDL, DISCO and UDDI
• Developing XML Web Services
• Securing XML Web services
• Web Service Exception
• Web Service and .NET Remoting
• Web Service and BizTalk

  What is an XML Web Service?

 

 

 

 

 

 

A programmable application component accessible via standard Web protocols that provides a universal language for applications to talk to each other - XML Web services allow applications to communicate regardless of operating system or programming language via the Internet. They can be implemented on any platform and are defined through public standards organizations such as the W3C. And with XML Web services, not only can applications share data, but they can also invoke capabilities from other applications without regard to how other applications were built. Sharing data through XML allows them to be independent of each other while simultaneously giving them the ability to loosely link themselves into a collaborating group that performs a particular task.

 What is the difference between a Web site and an XML Web Service - Web sites are about presenting information to a user: they are the communication vehicle for servers to talk to users. XML Web services, on the other hand, offer a direct means for applications to interact with other applications. Applications hosted internally, as well as on remote systems, can communicate via the Internet by using XML and SOAP messages. XML Web services are built on standard Web protocols; HTTP and XML. The technology innovations for XML Web services are: DISCO (Discovery) and UDDI (Universal Description, discovery, and Integration) – Standards for locating XML Web services SOAP (Simple Object Access Protocol) – Explicit serialization (HTTP + XML description) protocol used in service exchanges WSDL (XML Web services Description Language) – XML document describing the location and interfaces a particular service supports – the client’s contract.

  What Does an XML Web Service Do?

•   Expose functionality as a service and allow applications to share data
•   Can be called across platforms and operating systems and regardless of programming language

  XML Web Services in .NET

  The .NET Framework provides a bi-directional mapping between the elements of the Web and the elements of the Framework.  XML Web Services actually map well to existing technologies and to the .NET Framework. This slide shows how the mappings can be visualized. For instance, you can see that the concept of application data maps to XML which carries the data while the objects in the framework provides the features we normally see in objects that are called locally or in client/server applications. The objects are instantiations of classes which provide methods that can be called by an application. So, from the perspective of the calling application, an XML Web service looks like a method (or function) call to a traditional object. The middle column titled Web shows the areas that define the services features across the Web. For instance, the XML Schema Definition (XSD) language represents an XML schema that describes a service just like a class provides the description for an object.

  Web Service Description Language (WSDL) and SOAP

•   “TypeLib for SOAP”
• Uniform representation for services : Transport Protocol neutral ,Access Protocol neutral (not only SOAP)
• Describes how to call an XML Web service

  DISCO

•  DISCO is a proprietary file format placed at the root of a Web directory
• Visual Studio generates the DISCO for your XML Web service when you generate your service
• Easy discovery model for HTTP

  Universal Description, Discovery and Integration (UDDI)

•   Registry (Directory) for Web Services
•   UDDI itself is a Web service – can be programmatically accessed
•   Businesses can publish to registry and query registry
•   May point to WSDL files
•   Initiative driven by Microsoft, IBM, Compaq, Intel, Sun, Oracle and 250+ other companies

  Visual Studio .NET and XML Web Services

•   Visual Studio .NET creates XML Web Services for you
•   Generates the plumbing i.e., SOAP, DISCO, WSDL, etc…
•   Automates the creation of the project files

 

 

 

 

 

 

 

 

  Creating an XML Web Service

  <%@ WebService Language = “C#“ Class = “MyClass“ %>

using System.Web.Services;
public class MyClass: WebServices
{
  [ WebMethod ]
  public int Compute1(int i1, int i2)
  {
    return i1 + i2;
  }

 [ WebMethod ]  public int Compute2(int i1, int i2)
  {
    if (i1 > i2) return i1 – i2;
    else return i2 – i1;
  }
} Note:  Use either [SoapDocumentService] or [SoapRpcService] attribute to control basic WSDL details  Web Services Description Language (WSDL) defines two styles for how an XML Web service method, which it calls an operation, can be formatted in a SOAP request or a SOAP response: RPC and Document.   The Rpc/encoded is deprecated, only use it when required for interop.  The [SoapDocumentService] is the default if not specified.

  Creating An XML Web Service
Demo

•   XML Web Services 101
•  Create a simple XML Web service

  XML Web Services Clients Create ASP.NET page to use XML Web Service Demonstrate: How to register Web services? •How to use a Web service? •How calling a Web service is like calling a function or method?

 

 

 

 

Generating Web Service proxy using “wsdl.exe”

•  Utility to generate code for xml web service clients and xml web services using ASP.NET from WSDL contract files, XSD schemas and .discomap discovery documents. 
• Allow greater control in generating the proxy class.

1. Specify the language (C#, VB.NET, or JS)
2. Specify the namespace for greater interoperability
3. Specify the web service url from a configuration file
4. Specify the protocol
5. Specify the proxy server if needed

(technical guide notes:-)

  wsdl.exe <options> <url or path> <url or path> …      – OPTIONS – <url or path> –     A url or path to a WSDL contract, an XSD schema or .discomap document. /nologo     Suppresses the banner. /language:<language>     The language to use for the generated proxy class.  Choose from ‘CS’,     ‘VB’, ‘JS’ or provide a fully-qualified name for a class implementing     System.CodeDom.Compiler.CodeDomProvider.  The default is ‘CS’ (CSharp).     Short form is ‘/l:’. /server     Generate an abstract class for an xml web service implementation using     ASP.NET based on the contracts. The default is to generate client proxy     classes. /namespace:<namespace>     The namespace for the generated proxy or template.  The default namespace     is the global namespace. Short form is ‘/n:’. /out:<fileName>     The filename for the generated proxy code. The default name is derived from     the service name. Short form is ‘/o:’. /protocol:<protocol>     Override the default protocol to implement.  Choose from ‘SOAP’, ‘HttpGet’,     ‘HttpPost’, or custom protocol as specifiied in the configuration file. /username:<username> /password:<password> /domain:<domain>     The credentials to use when the connecting to a server that     requires authentication. Short forms are ‘/u:’, ‘/p:’ and ‘/d:’. /proxy:<url>     The url of the proxy server to use for http requests.     The default is to use the system proxy setting. /proxyusername:<username> /proxypassword:<password> /proxydomain:<domain>     The credentials to use when the connecting to a proxy server that     requires authentication. Short forms are ‘/pu:’, ‘/pp:’ and ‘/pd:’. /appsettingurlkey:<key>     The configuration key to use in the code generation to read the default     value for the Url property. The default is to not read from the config     file. Short form is ‘/urlkey:’. /appsettingbaseurl:<baseurl>     The base url to use when calculating the url fragment. The     appsettingurlkey option must also be specified. The url fragment is     the result of calculating the relative url from the appsettingbaseurl     to the url in the WSDL document. Short form is ‘/baseurl:’.

  Returning Data from an XML Web Service

  DataSets can be returned from XML Web service and work well in most cases.  In addition, they can be easily generated with wizard.  DataSets are a feature of ADO.NET and therefore require the .NET Framework.

  If a consuming application can use a DataSet, it uses it as is. If the consuming application cannot use a DataSet, it receives XML from the DataSet.  You can also use XML methods of the DataSet to extract and return XML.

 Consuming Data from an XML Web Service

    Using ADO.NET DataSets

 Create an XML Web Service which returns and ADO.NET DataSet.

  Show how XML is returned to the browser, but DataSet returned to application that uses a DataSet

•   How to return data from a DataSet
•   How DataSets automatically serialize themselves
•   How to consume data from a Web service

  Additional notes: The BizTalk server can orchestrate and consume XML Web services.

  The SoapException can either be thrown by the common language runtime or by an XML Web service method. The common language runtime can throw a SoapException if a response to a request is not formatted correctly. XML Web service methods can generate a SoapException by simply throwing an exception within the XML Web service method. If the client accessed the method over SOAP, the exception is caught on the server and wrapped inside a new SoapException.

  The SoapException thrown has the following property values:

 Message: The Message property of the original exception.

 Code: Specifies a SOAP fault code representing an error occurred during the processing of a client call on the server, where the problem was not due to the message contents.

  Actor: The url of the XML Web service method.

  Detail: A null reference (Nothing in Visual Basic), but an empty detail element is present in the fault element.

  The code fragment demonstrates how to handle a CLR exception, wrap the exception in a SoapException, and rethrow the exception to the client

  Web Service Exception

  try {    // do something… } catch(Exception e) {   // clean up code…   throw new SoapException(…); }

 

  Designing an XML Web Service

  When you are designing an XML Web service, you must consider the following things: (Remember, stateless is good.)

• Group related operations and data into one method

  Network round trips are expensive. As with any distributed application, someone using XML Web services must consolidate method calls into chunkier operations that accept all needed data as parameters.

•   Use output caching to improve performance

  The output from an XML Web service method can be cached by the server and returned to clients without invoking the method. You can control the duration of the output in the cache by setting the CacheDuration property of the WebMethodAttribute on a per-method basis.

•   Define your input and output data structures using XSD schemas

  When you return a DataSet or an XML document, the client needs to know the structure of the data you are returning. Use XSD schemas to formally define this structure, but it is unnecessary to create them from scratch. A DataSet will generate the schema for you and XSD.exe can generate a schema given an XML document. You might want to tweak those generated schemas to cause them to more accurately and specifically describe the data you are returning and/or receiving.

•   Separate XML Web service from underlying business logic

  While you can implement the business logic in an XML Web service, it is not the best idea. Separating the business logic into components and then creating XML Web services that use those components is a better direction because it lets you design a business logic object model according to the application’s needs. Then this object model can be used from several facades including an XML Web service, ASP.NET pages or even a facade that is invoked by Visual Basic .NET clients using remoting.

• Design and test for interoperability

  Depending on your needs, some or all of your XML Web service clients may not be .NET clients. The .NET XML Web service builds on standards and is created for interoperability. To ensure your XML Web service can be invoked by the target client type, you must take into consideration the data structures exchanged between your service and the client. For example, when you return a DataSet, a non-.NET client will receive it as an XML document. The client then wants to make changes to it and send it back to your service to apply those changes. If your service is expecting a DataSet back, the client must update the XML document in a specific way (i.e. with before and after images of each changed row). It might be easier for the client in this case to deal with an XML document and make the updates directly. In any case, you must think through how non-.NET clients will interact with your XML Web service.