Although the Visual Studio Integrated Development Environment (IDE) is a highly productive tool for building ASP.NET Web services, it is not a required tool. The .NET Framework itself comes bundled with the Visual Basic .NET and C# command-line compilers as well as other tools that you can use to build ASP.NET Web services.
ASP.NET Web services require a Web-addressable entry point file, an assembly that implements the functionality of the service, a Web Service Description (WSDL) document an optional Discovery (DISCO) document, and an optional UDDI registration.
Web services built with the .NET Framework leverage the ASP.NET infrastructure, tools, and runtime. Of course, ASP.NET itself is built upon the foundation of the .NET Framework and the Common Language Runtime (CLR), providing all the benefits of these technologies to your Web service implementation.
These relationships are also important because they affect the physical structure of Web services on the .NET platform. The power of this model is quite evident as you begin to dissect the various pieces of a Web service on the .NET platform and gain an understanding of the features that are provided by these technologies.
Before you start working with the .NET Framework to build a Web service application, you must consider a few environmental factors related to your software and network configuration. These considerations will directly affect how you build, debug, and deploy your ASP.NET Web services.
ASP.NET Web service development requirements
The typical development environment for an ASP.NET Web service application usually consists of the following elements:
A personal workstation with the.NET Framework SDK installed
A development Web server that is configured to host and run a development (nonrelease) version of your Web service
A production Web server that is configured to host the final run-time (release) version of your Web service Often, the personal workstation and development Web server are combined on a single computer. This makes design, implementation, and debugging easier during the early
development stages of your Web service.
If you prefer to develop Web services on a remote Web server, you should make sure that at least the runtime portion of the .NET Framework is installed and configured. With this configuration, you only need worry about copying your Web service implementation files to an appropriately configured virtual directory on the Web server.
Creating the Web service application
ASP.NET Web services are ASP.NET applications. Good practice dictates that ASP.NET applications have a Web server virtual directory defined for them. This allows more flexibility in configuring and customizing the Web service from a Web application perspective. Therefore, we will create a virtual directory for our CTemp Web service.
Follow these steps:
1. Create a directory under the Web server root directory (typically inetpub/ wwwroot) named CTemp.
2. From the Microsoft Windows 2000 Start menu, choose Settings ® Control Panel.
3. Double-click the Administrative Tools icon.
4. Within the Administrative Tools group, double-click the Internet Services Manager icon. This will display the Internet Information Services window.
Handling errors
The .NET Framework, via the CLR, provides excellent support for handling errors via exceptions. Applications built on the .NET Framework can throw and catch exceptions to handle all types of run-time errors. This support is also available to Web services. Generally, you will want to use exceptions to communicate run-time errors back to Web service consumers for conditions that your service cannot handle effectively.
As you can see in our implementation of the CTemp Web method, there are several cases in which we must throw exceptions based on invalid input obtained from the consumer in the method call.
Web services communicate exceptions to consumers via SOAP exception messages. A SOAP exception is represented by the SoapException class in the .NET Framework's System.Web.Services.Protocols namespace. As a Web service consumer, you can wrap calls to Web service methods within try . . . catch blocks to intercept exceptions thrown by Web services.
Referring to our CTemp implementation, arguments that cannot be processed as specified by the consumer cause the Web service to throw an ArgumentException exception. This exception is serialized into a SOAPException message and returned to the consumer.
Note that communicating exceptions to Web service consumers is only supported via SOAP. Therefore, if you use HTTP -GET or HTTP -POST to call a Web service method (as is the case when using a Web browser to test and invoke Web services), you cannot get exceptions transported back to the browser. In this case, the exception within the Web service is handled by the Web server, which results in the transmission of a server error page back to the consumer.
Debugging the Web Service
Sometimes, testing your Web service as outlined in the last section will reveal flaws in your implementation or other unexpected results. If this occurs, you may need to debug your Web service. For those of you who have experience in trying to debug priorgeneration ASP applications, you will find that the .NET Framework SDK and ASP.NET have much-improved support for testing and debugging your Web service applications.
The .NET SDK debugger, named Dbgclr.exe, is located in the .NET SDK installation folder, which is typically found at Program Files\Microsoft.NET\ FrameworkSDK\ GuiDebug.
RELATED POST
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
ASP.NET Web services require a Web-addressable entry point file, an assembly that implements the functionality of the service, a Web Service Description (WSDL) document an optional Discovery (DISCO) document, and an optional UDDI registration.
Web services built with the .NET Framework leverage the ASP.NET infrastructure, tools, and runtime. Of course, ASP.NET itself is built upon the foundation of the .NET Framework and the Common Language Runtime (CLR), providing all the benefits of these technologies to your Web service implementation.
These relationships are also important because they affect the physical structure of Web services on the .NET platform. The power of this model is quite evident as you begin to dissect the various pieces of a Web service on the .NET platform and gain an understanding of the features that are provided by these technologies.
Before you start working with the .NET Framework to build a Web service application, you must consider a few environmental factors related to your software and network configuration. These considerations will directly affect how you build, debug, and deploy your ASP.NET Web services.
ASP.NET Web service development requirements
The typical development environment for an ASP.NET Web service application usually consists of the following elements:
A personal workstation with the.NET Framework SDK installed
A development Web server that is configured to host and run a development (nonrelease) version of your Web service
A production Web server that is configured to host the final run-time (release) version of your Web service Often, the personal workstation and development Web server are combined on a single computer. This makes design, implementation, and debugging easier during the early
development stages of your Web service.
If you prefer to develop Web services on a remote Web server, you should make sure that at least the runtime portion of the .NET Framework is installed and configured. With this configuration, you only need worry about copying your Web service implementation files to an appropriately configured virtual directory on the Web server.
Creating the Web service application
ASP.NET Web services are ASP.NET applications. Good practice dictates that ASP.NET applications have a Web server virtual directory defined for them. This allows more flexibility in configuring and customizing the Web service from a Web application perspective. Therefore, we will create a virtual directory for our CTemp Web service.
Follow these steps:
1. Create a directory under the Web server root directory (typically inetpub/ wwwroot) named CTemp.
2. From the Microsoft Windows 2000 Start menu, choose Settings ® Control Panel.
3. Double-click the Administrative Tools icon.
4. Within the Administrative Tools group, double-click the Internet Services Manager icon. This will display the Internet Information Services window.
Handling errors
The .NET Framework, via the CLR, provides excellent support for handling errors via exceptions. Applications built on the .NET Framework can throw and catch exceptions to handle all types of run-time errors. This support is also available to Web services. Generally, you will want to use exceptions to communicate run-time errors back to Web service consumers for conditions that your service cannot handle effectively.
As you can see in our implementation of the CTemp Web method, there are several cases in which we must throw exceptions based on invalid input obtained from the consumer in the method call.
Web services communicate exceptions to consumers via SOAP exception messages. A SOAP exception is represented by the SoapException class in the .NET Framework's System.Web.Services.Protocols namespace. As a Web service consumer, you can wrap calls to Web service methods within try . . . catch blocks to intercept exceptions thrown by Web services.
Referring to our CTemp implementation, arguments that cannot be processed as specified by the consumer cause the Web service to throw an ArgumentException exception. This exception is serialized into a SOAPException message and returned to the consumer.
Note that communicating exceptions to Web service consumers is only supported via SOAP. Therefore, if you use HTTP -GET or HTTP -POST to call a Web service method (as is the case when using a Web browser to test and invoke Web services), you cannot get exceptions transported back to the browser. In this case, the exception within the Web service is handled by the Web server, which results in the transmission of a server error page back to the consumer.
Debugging the Web Service
Sometimes, testing your Web service as outlined in the last section will reveal flaws in your implementation or other unexpected results. If this occurs, you may need to debug your Web service. For those of you who have experience in trying to debug priorgeneration ASP applications, you will find that the .NET Framework SDK and ASP.NET have much-improved support for testing and debugging your Web service applications.
The .NET SDK debugger, named Dbgclr.exe, is located in the .NET SDK installation folder, which is typically found at Program Files\Microsoft.NET\ FrameworkSDK\ GuiDebug.
RELATED POST
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
No comments:
Post a Comment