The XML Web Services in Visual Studio. Summary: Microsoft® Visual Studio® .NET and XML Web Services offer a simple, flexible and standard model, developers who can use the platform, programming language or object models Write a combined application. This article will help you quickly learn to create and access XML Web Services using Visual Studio .NET. This article contains some links to English sites.
Directory Introduction Using Visual Studio Use Visual Studio to create XML Web Services Use Visual Studio to deploy XML Web Services to access XML Web Services Summary Introduction XML Web Services is a programmable unit that can be accessed by the potential heterogeneous system . XML Web Services depends to a large extent, which has been widely accepted to support interoperable XML, HTTP, and other Internet standards.
XML Web Services can be used inside or via Internet access to multiple applications internally or through Internet access. XML Web Services can be accessed through standard interfaces, allowing a heterogeneous system to work with the same web.
XML Web Services did not follow the general code portability, but provided a viable solution that allows data and systems to work together. XML Web Services uses XML-based messages to exchange data between multiple systems that use different component models, operating systems, and programming languages. The developer can create an application with the same way as components typically used in distributed applications, and combine different sources of XML Web Services.
One core feature of XML Web Services is the high abstraction of the implementation and use of services. The XML Web Services Client and XML Web Services provider will no longer need any other information in addition to the need to understand the other party's input, output, and location, in addition to the need to understand the other.
XML Web Services brought the development of distributed applications into a new era. The interoperability of the application was sacrificed using a dedicated tight coupling system. XML Web Services pushes interoperability to a brand new height. As a revolutionary progress in the new generation of Internet, XML Web Services will become the infrastructure of all computing devices.
For more information, see Programming The Web With XML Web Services.
The XML Web ServicesASP.NET page framework written with hosted code is also the framework of XML Web Services that uses managed code. Therefore, XML Web Services can access a number of functions of the .NET framework, such as authentication, cache, and status management. In this way, developers can focus on creating or accessing XML Web Services without having to write infrastructure code.
In the ASP.NET application model, the web page is designed to use the .aspx extension browser. In order to distinguish XML Web Services and regular ASP.NET pages, XML Web Services uses the .asmx extension.
XML Web Services consists of an XML Web Services entry point and a code that implements the XML Web Services feature. In ASP.NET, .asmx file acts as an addressable entry point of XML Web Services. It refers to the code of the pre-compiled program, the file support code or .asmx file itself contains the code.
With XML Web Services, there are two basic operations:
Creating XML Web Services - When you create an XML Web Services, it is actually created an application that will function to the XML Web Services client. Access XML Web Services - When accessing XML Web Services, the client application will find, reference, and use the features included in the XML Web Services. XML Web Services can be separate applications or subcomponents of large web applications. The minimum requirement is that the client must be able to send messages to XML Web Services. For more information, see XML Web Services in Managed Code.
Creating XML Web Services using Visual Studio To create XML Web Services with Visual Studio, you need to access the ASP.NET application (the application will be created in a Web project) WEB server. There are many kinds of Web projects. When you want to use XML Web Services with managed code in Visual Studio .NET, you can use the ASP.NET Web Service project template. After creating an XML Web Services project in Visual Studio, you will see the Component Designer. The component designer is the design interface of XML Web Services. You can add components to XML Web Services using the Design view and use the Code view to view or edit the code associated with XML Web Services.
After creating an ASP.NET Web Service project in Visual Studio, it constructs a web application project structure on the web server while constructing a Visual Studio solution file on your local computer. The solution file (.sln) contains configuration and generate settings and saves a series of files associated with the project. In addition, Visual Studio automatically creates files and references necessary to support XML Web Services. After completion, the Visual Studio integration development environment (IDE) will display .asmx files in the Design view.
By default, Visual Studio will use the "support code file" (such as service1.asmx.vb or service1.asmx.cs) when you use the ASP.NET Web Service Template to create XML Web Services. The support code file contains code that implements the XML Web Services feature. By default, the Solution Explorer hides support code files. When viewing the Code view of the .asmx file, you actually check the content of the support code file. The .asmx file itself contains processing instructions WebService, which indicates where you can find XML Web Services implementation. After generating XML Web Services with hosted code, ASP.NET will automatically provide infrastructure and process XML Web Services requests and responses, including analysis and create a Simple Object Access Protocol (SOAP) message. The compiled output is a .dll file, which is located in the bin folder of the project.
For more information, see Creating XML Web Services in Managed Code.
The WebService Processing Instructions WebService Processing Instruction provides the necessary information to the ASP.NET environment, such as the class that implements the XML Web Services feature. The following is an example of the WebService handling instruction in the .asmx file: 'Visual Basic <% @ Webservice Language = "VB" CodeBeHind = "Service1.asmx.vb" Class = "WebService1.service1"%>
// c # <% @ Webservice Language = "C #" codebehind = "service1.asmx.cs" class = "WebService1.service1"%> Note: To view the contents of the .asmx file in the Solution Explorer (Solution Explorer) Please use the .asmx file with right-click, click Open With in the shortcut menu. In the Open WITH dialog, select Source Code (Source Code) Editor, and then click Open. The Language property indicates the programming language used by the development of XML Web Services. You can create XML Web Services using any language compatible with .NET (such as Visual Basic .NET or Visual C #). The support code file associated with the .asmx page is indicated by the CodeBehind property. The class attribute indicates a class that supports the XML Web Services feature in the support code file.
For more information, see Code Model for XML Web Services in Managed Code.
The System.Web.Services.WebService class System.Web.Services.WebService class defines an optional base class for XML Web Services and provides permissions for direct access to common ASP.NET objects (such as applications and session status objects). By default, XML Web Services created in the form of managed code inherits this class using Visual Studio. XML Web Services can inherit this class to get access to ASP.NET inherent objects such as Request and session.
If the XML Web Services does not inherit this class, you can also access the ASP.NET inherent objects from System.Web.httpContext.current. The class that implements XML Web Services must be public and must have a common default constructor (without parameters constructor). This way, ASP.NET can create an instance of the XML Web Services class to process incoming XML Web Services requests.
For more information, see Inheriting from The Webservice Class.
WebService properties Each XML Web Services requires unique namespaces that allow the client application to divide XML Web Services that may use the same method name. The default namespace of XML Web Services created in Visual Studio .NET is "http://tempuri.org/". Although the namespace is similar to a typical URL, it cannot be viewed in a web browser, it is just a unique identifier. Note: You may want to provide a web page in the location containing the XML Web Services information you provide. The WebService property provides the following properties:
Description - The value of this property contains a descriptive message, which will be displayed to XML Web Services after the descriptive message (such as the service description and service help page) of XML Web Services (such as the Service Description and Service Help page). Name - This property contains the name of XML Web Services. By default, this value is the name of the class that implements XML Web Services. The Name property identifies the local part of the XML Limit Name of XML Web Services. The Name property is also used to display the name of XML Web Services on the service help page. Namespace - This property contains the default namespace of XML Web Services. The XML namespace provides a method for creating a name in an XML document that can be identified by the Unified Resource Identifier (URI). Using XML namespaces, you can uniquely identify elements or properties in the XML document. Thus, in the service description of XML Web Services, NameSpace is used as the default namespace of XML elements directly related to XML Web Services. If you do not specify a namespace, use the default namespace http://tempuri.org/. The following sample code illustrates the usage of the WebService property:
'Visual Basic
// c # [WebSpace (Namespace = "http: // myserver / mywebservices /", description = "This can put some descriptive text.", Name = "Myfavoritesservice")] Public Class Service1: System.Web.Services. WebService {// implement code. } For more information, see Using The Webserve Attribute.
When you create an XML Web Services at a managed code, you can specify the method available in XML Web Services by placing the WebMethod property before the public method declares. The Private method does not act as the entry point of XML Web Services, although they can use the same class and XML Web Services code can call them. The WebMethod property must be applied to each public method that can be used as part of the XML Web Services.
The WebMethod property contains several properties that configure the XML Web Services behavior. For example, you can use this property to provide a short description in the Related Service Help page. WebMethod properties offer the following properties:
BufferResponse - When set to true (default setting), ASP.NET caching the response to the client before the response is sent downward. Cache is a very effective way to improve performance by reducing communication between the auxiliary process and the Internet Information Services (IIS) process. When set to false, ASP.NET will have a 16 kb block in response. Typically, this property is set to false only if all the contents of the response will be cached in memory. For example, a collection of items that flow out of the database is being written. The default value is TRUE unless otherwise specified. Cacheduration - The value of this property specifies the number of seconds required for the ASP.NET cache each unique parameter setting result. The default value is 0 unless otherwise specified, this setting will disable the result cache. Description - This property provides an instructions for the XML Web Services method, which is displayed in the Service Help page. The default value is an empty string unless otherwise specified. EnableSession - ASP.NET will not be able to access the session status of the XML Web Services method when set to false (default setting). When set to TRUE, XML Web Services can access session status collections directly from HTTPContext.Current.Session; inheriting the WebService base class, you can use the WebService.Session property to access. MessageName - This property allows XML Web Services to uniquely identify overload using alias. The default value is the method name unless otherwise specified. After the value is specified for the message, the resulting SOAP message reflects this name instead of the actual method name. TransactionOption - The value of this property specifies whether the XML Web Services method can act as the root of the transaction. Although the TransactionOption property can be set to the TRANSActionOption enumeration type, the XML Web Services method has only two possible behavior: it does not participate in the transaction (Disabled, NotSupported, and Supported) or create a new transaction (Required and RequiresNew). The default value is TransactionOption.disabled unless otherwise specified. To use this property, you need to add a reference to System.EnterpriseServices.dll. This namespace contains methods and properties that provide a distributed transaction model that can be found in COM services. The System.EnterpriseServices.ContextUtil class allows you to set the transaction with the Setabort or SetComplete method. The following sample code illustrates the usage of the webmethod property:
'Visual BasicPublic Class Service1 Inherits System.Web.Services.WebService
Deploying XML Web Services using Visual Studio When using Visual Studio .NET to create XML Web Services with managed code, standard deployment models should be used: Compile items, and then deploy the result file to the production server. The project.dll file contains all other class files (.asmx.vb or .asmx.cs) and all other class files in the project, but not contain .asmx file itself. You can then deploy this item .dll file to the production server without having to come with any source code. When XML Web Services receives a request, the project .dll file will be loaded and executed.
Figure 1: Deploy XML Web Services
To deploy XML Web Services to a non-development server, you can add web installation items, or copy the required files to the target server. To make your XML Web Services for others, you need to deploy it to the web server accessible to the target client.
For more information, see Deploying XML Web Services In Managed Code.
The service help page calls the .asmx file from the web browser, without providing the identified query string, .asmx file returns an automatically generated service help page for XML Web Services.
For example, to access the XML Web Services for the XML Web Services called Service1.asmx (part of the WebService1 item in the local computer), you can use the following URLs:
Http: //localhost/webservice1/service1.asmx This service help page provides a list of XML Web Services and a list of methods you can access by programming. Each method includes a link to its detailed information. Alternatively, this help page also includes links to XML Web Services documentation documents.
Figure 2: Service Help Page
The file name of the service help page is specified in the
For more information, see Configuration Options for XML Web Services CREATED Using ASP.NET.
The Service Method Help Page Service Method Help page provides details related to the specific XML Web Services method. This page allows you to call the method of using the HTTP-POST protocol. However, it is then unable to call a method of requiring complex input parameters such as a DataSet. In addition, the XML Web Services method must support the HTTP-POST protocol to enable this feature. The request and response message example of the protocol (XML Web Services method supported) is also provided at the bottom of the service method help page.
Figure 3: Service Method Help Page
For example, to access the XML Web Services method called MyWebMethod in a service1.asmx (part of the WebService1 item in the local computer), you can use the following URLs:
Http://localhost/webservice1/service1.asmx? OP = MyWebMethod For more information, see Exploring XML Web Services Content.
The Web Service Description (.wsdl) Service Help page also provides links to the XML Web Services service description, the service description is a formal definition of the XML Web Services feature. The service description is a document that uses the Web Service Description Language (WSDL) syntax. The service note defines the message format contract that the client needs to follow when exchange information exchange information with XML Web Services.
Web Service Description Example
MIME: MIMEXML Part = "body" />
XML Web Services found that XML Web Services found that the process of positioning and querying XML Web Services is a basic step in accessing XML Web Services. Through the discovery process, the XML Web Services client can understand if an XML Web Services exists in the design phase, and how it functions, and how to interact with it.
However, the Web site that implements XML Web Services does not need to support this discovery process, but is responsible for the service (such as the XML Web Services directory) by another site. In addition, there may be no disclosed methods can be used to find services, such as when creating a private service.
For more information, see XML Web Services Discovery.
Static Discovery (.disco) can enable XML Web Services discovery by publishing a .disco file (an XML document, which contains links to other discovery documents, XSD scenarios, and service descriptions). The XML Web Services that automatically created using ASP.NET can provide the generated discovery document. For example, to access the XML Web Services discovered documentation called Service1.asmx (part of the WebService1 item in the local computer), you can use the following URL: http: //localhost/webservice1/service1.asmx? Disco The following example shows the discovery document structure:
Dynamic Discovery (.vsdisco) Dynamic Discovery is ASP.NET to perform iterative search to find available XML Web Services by developing a folder hierarchy on a web server to find available XML Web Services. Dynamic discovery (.vsdisco) file is an XML-based file that can contain zero or multiple
By default, dynamic discovery is disabled by Web.config. To actively control which XML Web Services clients can discover the service and use only dynamic discovery on the development web server. When deploying XML Web Services when you deploy XML Web Services, you want to create and publish a static discovery file (.disco) for the XML Web Services that you want to discover. For more information, see Deploying XML Web Services In Managed Code.
After the Web Service directory deployed XML Web Services, if you want others to use, you need to consider how to let developers find it. Making XML Web Services can be used for most people to register it in the XML Web Services directory. General Description, Discovery and Integration (UDDI) projects provide a directory for companies and their services.
For more information, see XML Web Services Directories.
Accessing the XML Web ServicesXML Web Services client using Visual Studio refers to any reference to and using XML Web Services. It doesn't have to be client-based applications. In fact, in most cases, your XML Web Services client may be other web applications (such as web forms or other XML Web Services). When accessing XML Web Services with managed code, the proxy class and .NET framework will process all structural code.
Accessing XML Web Services from hosting code is a simple process. First, add a web reference to the XML Web Services project you want to access. Web references use as a proxy method to create a proxy class for each public XML Web Services method. Second, add the namespace of the web reference. Finally, create a proxy class instance and access the type of method like accessing other classes.
For more information, see Accessing XML Web Services in Managed Code.
Find XML Web Services and add web references Sometimes, you may be both the provider of XML Web Services, and the user of XML Web Services. In this case, you may know the location and function of XML Web Services. But at other times, you may be access to XML Web Services provided by others. In this case, you may not know if XML Web Services meet your requirements.
In order to simplify the code model, the application written by hosting code uses a web reference to represent each local XML Web Services. Add a web reference to your project by using the Add Web Reference dialog. This dialog allows you to browse your local server, Microsoft UDDI directory, and XML Web Services on the Internet.
The Add Web Reference dialog box uses the XML Web Services discovery process, and finds the appropriate XML Web Services on the Web site browsing from the dialog. For a given address, it is designed to find the XML Web Services discovery (DISCO) document and finally find the XML Web Description Document (Comply with the syntax of the Web Service Description Language [WSDL] to ask the Web site.
When you use the Add Web Reference dialog to find the XML Web Services to your application, click the Add Reference button to tell Visual Studio to download a copy of the service instruction to your local computer and then generate access. The proxy class of the selected XML Web Services. The proxy class contains some methods to synchronize or asynchronously call the open XML Web Services method. For more information, see Locating XML Web Services.
Dynamic and static URLWEB references can use a static URL or a dynamic URL can also be used. The web reference URL property of the web reference is used to specify the URL of the referenced XML Web Services. By default, this property is set to the URL of the selected XML Web Services (a static URL).
If you reserve the URL Behavior property settings as default static, when you create a class instance, the hardcoded URL is used to set the URL property of the proxy class.
If you set the URL Behavior property of the web reference to Dynamics, the application will get URLs from the
When you add a web reference, you can also create a proxy class using the same tool (XML Web Services Description Language Tools) used by Visual Studio. This method is useful when you cannot access XML Web Services from a computer where Visual Studio is installed. For example, when the network where the XML Web Services is located until running, it cannot be accessed by the client. Then, you have to manually add a tool generated by the application project.
For more information, see Managing Project Web References.
The proxy class generated using the proxy class has its own namespace. Before creating a proxy instance, you must add namespaces to the client application. For other classes, you must first create an instance before calling a method. This process does not differ from the creation of other class instances.
When using Visual Studio generated from the proxy class generated in the service description of the XML Web Services, the XML Web Services that uses managed code is relatively simple. To access the XML Web Services method, your client application should call the corresponding proxy object synchronization method or asynchronous method. These methods do the necessary work to remotely call the required XML Web Services methods. By default, the proxy class uses SOAP to access the XML Web Services method because SOAP supports the three supported protocol operations (HTTP-GET, HTTP-POST, and HTTP-SOAP) support the most abundant data type. The proxy class generated by the Add Web Reference process is from the System.Web.Service.Protocols.SoAphttpClientProtocol class, which contains several properties to control the behavior of this class to access XML Web Services.
In addition, the SOAPHTTPCLIENTPROTOCOL class also provides the following properties:
ClientCertificates - This property allows the client to pass one or more client certificates (also called Authenticode X.509 V.3 certificates) when calling an XML Web Services method. CookieContainer - If the XML Web Services method uses a session status, then pass a cookie to the XML Web Services client in the response header (session that identifies the XML Web Services client). For the XML Web Services client that receives the cookie, you must create a new instance of a cookieContainer and specify its property as a cookieContainer before calling an XML Web Services method. This ensures that cookie can be correctly included in subsequent requests. Credentials - When using the Credentials property, the XML Web Services client must instantiate the class (such as NetworkCredential), and then set the customer credential dedicated to the verification mechanism. The NetworkCredential class can be used to set validation credentials using basic, summary, NTLM, and Kerberos authentication mechanisms. PreAuthenticate - When PreAuthenticate is True, if the verification mechanism supports this setting, the WWW verification title will be sent with the first request. When PreAuthenticate is false (default), you can send a request to the XML Web Services method without first user authentication. If you know the Web Service needs to be verified, you can save a round-trip operation by setting the property to true. Proxy - This property needs to be used if the client needs to use the proxy settings found in the system settings. You can use the WebProxy class to set the proxy settings because it can implement iWebProxy. Otherwise, the default proxy settings may be set in the configuration file. Timeout - Timeout (milliseconds) is used to simultaneously call XML Web Services. The default is 100,000 milliseconds. Set the Timeout property value to timeout.infinite, indicating that the request is not timeout. However, the web server may still be able to cause requests to time when the server is timed. URL - The default value of this property is determined by the Location property found in the service description of the generated proxy class. For more information, see the SOAPHTTPCLIENTPROTOCOL CLASS. When you call an XML Web Services method Add a web reference to XML Web Services, you can call the XML Web Services disclosure and access the results like accessing other component methods.
In the following sample code, the client application (Application1) accesses an XML Web Services with a web reference (CONVERTER), which contains the proxy class service1, and the proxy class has a method of calling XML Web Services CONVERTTTTTTEMPERAS. The bold line in the code is necessary to access the XML Web Services.
'Visual BasicImports SystemModule Module1 Sub Main () Dim cService As New Converter.Service1 () Dim dFahrenheit As Double Dim dCelsius As Double Console.Write ( "Fahrenheit:") dFahrenheit = Convert.ToDouble (Console.ReadLine ()) dCelsius = cService.ConvertTemperature (dFahrenheit) Console.Write ( "Celsius:") Console.WriteLine (dCelsius.ToString ()) End SubEnd Module // C # using System; namespace Application1 {class Class1 {static void Main () {Converter.Service1 cService = new Converter.Service1 (); Console.WriteLine ( "Fahrenheit:"); double dFahrenheit = Convert.ToDouble (Console.ReadLine ()); double dCelsius = cService.ConvertTemperature (dFahrenheit); Console.Write ( "° C : "); Console.WriteLine (DCELSIUS.TOSTRING ());}}} Summary XML Web Services provides the ability to exchange messages with standard protocols (HTTP, XML, SOAP, and WSDL) in a loose coupling environment. The message can be structured, with type, or loose definition. Since XML Web Services is based on standard protocol, your XML Web Services application can communicate with many implementations, platforms, and devices.
You can use the ASP.NET page framework to create XML Web Services and allow these XML Web Services to access a number of features of the .NET framework. Since the ASP.NET and the .NET framework is based on the XML Web Services with managed code, developers can focus on creating or accessing XML Web Services without having to write infrastructure code.
When you use Visual Studio to generate the proxy class generated in the XML Web Services service description, the XML Web Services that uses managed code is relatively simple. The proxy class code converts the method call to the request message and returns the response information to the return value of the method.
