Today, Dwight takes us on a tour of the web services made available to us via ASP.NET. We learn about implementing interfaces, dynamic binding, class inheritance and interface inheritance. This piece comes from chapter seven of .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223-054-1, 2004).
Web Services Description Language WSDL documents contain metadata about a client’s input and output parameters from an invocation externally. This means a user is invoking a method externally. In addition, the WSDL file describes the service’s functionality. In essence, the file facilitates interaction between disparate clients by providing the requisite information on how to achieve interoperability between them.
Let’s create a small web service in ASP.NET and then inspect the WSDL file. The first task required for building a web service in the .NET world is creating a virtual directory in Internet Information Services.
Create a folder on the server, and name it “MySOAPExamples.”
In Windows 2000 or Windows XP, select Start | Control Panel | Administrative Tools | Internet Information Services. Open IIS, right-click the default web site, select New, and then select Virtual Directory. A dialog box will appear on your screen. Select Next, and enter MySOAPExamples in the Alias dialog box. Make sure the subdirectory is already created somewhere on the hard drive. Finally, proceed to Finish to generate the virtual directory.
Create a new project in Visual Studio .NET called “IFCEBrokerage.”
Rename Webservice1.asmx to IFCEBrokerageFirm.asmx. The extension .asmx represents an ASP.NET web service extension.
The namespace should be named “namespace IFCEBrokerage.”
Enter the code shown in Listing 6.
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
; using System.Web; using System.Web.Services; namespace IFCEBrokerage { public class SecuritiesExchange : System.Web.Services.WebService { [WebMethod] public double StockQuote(string symbol)
{ double quotePrice=0;
switch(symbol)
{ case "JANS": quotePrice = 29.95;
break; case "MSFT": quotePrice = 49.97;
break; case "ORCL": quotePrice = 37.72;
break; } return quotePrice; } } }
Several IFCEBrokerageFirm items require clarification. An excellent place to begin learning about them is in web service namespaces. Table 1 displays them with comments.
These namespaces enable developers to create XML web services using ASP.NET and XML web service clients. XML web services represent applications that enhance the ability to exchange messages in a loosely coupled environment using protocols such as HTTP, XML, XSD, SOAP, andWSDL. They facilitate constructing modular applications in a heterogeneous environment that promotes interoperability between applications, smart client devices, and implementations. NOTE The WebMethodAttribute class must be applied to any method where a developer wants to expose it programmatically.
Class
Description
WebMethodAttribute
Adding this attribute to a method when defining a web service created in ASP.NET makes the method callable from remote web clients.
Web Service
This class defines the optional class for XML web srvices, thereby providing access to common ASP.NET objects, for example, applications and sessions state.
WebServiceAttribute
This class is used to append additional information to an XML web service, such as a string explaining its functionality.
WebServiceBindingAttribute
Declares binding for one or more XML web service methods implemented within the class that is implementing the web service.
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
Because the implementation of a web service is encapsulated within a class, it is important to define an end point for the web service. The .asmx file serves as the end point for the web service. When a client calls the .asmx file, the ASP.NET runtime processes the file.
Usually, each .asmx page has a language directive at the top of the page, as displayed here:
The first time the web service is called, the ASP.NET runtime uses the Language directive to compile the code first to MSIL and subsequently to the language specified by the directive. In this case, the directive specifies the C# .NET programming language. This means the IFCEBrokerage class code shares the CLR runtime services and data types defined in the CTS with all other .NET programming languages.
NOTE The Class attribute bears the fully qualified name of the class that implements the web service. Because the default language in the machine.config file is set to “vb,” the IFCEBrokerageFirm.asmx language should be set to C# .NET. Here is the machine.config file segment:
It is also wise to place the web service’s implementation in its own assembly. By convention, the assembly is placed within the web application’s bin directory because this directory is placed within the search path. The SecuritiesExchange web service client can access this web service only through HTTP for the simple reason that ASP.NET supports only this transmission protocol. However, the web service supports three kinds of protocol bindings:
SOAP
HTTP Get
HTTP POST
All ASP.NET web services support SOAP because the SOAP body content is strongly typed and is XML based through the XSD Schema. Web Services Documentation ASP.NET’s runtime includes services such as documentation. This is a major benefit because the CLR uses System.Reflection to generate two kinds of documentation:
Documentation utilized by clients so they can interact with web services
Documents referenced by people
HTML-based documents are accessible by entering the URL in a browser. Both the WebMethod and its companion attributeWebService expose the Description property.
Listing 7 demonstrates how to include documentation in the IFCEBrokerage.asmx file. Listing 7Adding the Description attribute
using System
; using System.Web; using System.Web.Services; namespace IFCEBrokerage { [WebService(Description ="This demonstrates how to use the Description attribute")] public class SecuritiesExchange : System.Web.Services.WebService {
[WebMethod] public double StockQuote(string symbol) { double quotePrice= 0;
switch(symbol)
{ case "JANS": quotePrice = 29.95;
break; case "MSFT": quotePrice = 49.97;
break; case "ORCL": quotePrice = 37.72;
break; }
return quotePrice; } } }
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
The documentation automatically generated for the IFCEBrokerageFirm is shown in Listing 8: Listing 8Sample documentation for IFCEBrokerageFirm
SecuritiesExchange This demonstrates how to
use the Description attribute The following operations are supported. For a formal definition, please review the Service Description. StockQuote This web service is using http://tempuri.org/ as its default namespace. Recommendation: Change the default namespace before the XML Web service is made public.
Examining Namespaces
Each XML web service needs a unique namespace in order for client applications to distinguish it from other services on the Web. The http://tempuri.org/ namespace is available for XML web services that are under development, but published XML web services should use a more permanent namespace.
Your XML web service should be identified by a namespace that you control. For example, you can use your company’s Internet domain name as part of the namespace. Although many XML web service namespaces look like URLs, they need not point to actual resources on the Web. (XML web service namespaces are URIs.)
For XML web services created using ASP.NET, the default namespace can be changed using theWebService attribute’s Namespace property. TheWebService attribute is an attribute applied to the class that contains the XML web service methods. Listing 9 shows an example that sets the namespace to http://microsoft.com/webservices/.
Listing 9 HTML-based documentation
C
# [WebService(Namespace="http://microsoft.com/webservices/")] public class MyWebService { // implementation } Visual Basic.NET <WebService(Namespace:="http://microsoft.com/ webservices/")> Public Class MyWebService ' implementation End Class For more details on XML namespaces, see the W3C recommendation on Namespaces in XML. For more details on WSDL, see the WSDL Specification. For more details on URIs, see RFC 2396.
This web page shows the method exposed by the web service StockQuote. It also provides the following recommendation:
Recommendation
: Change the default namespace before the XML web service is made public.
And it lists some examples for changing the namespace.
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
</operation> </binding> <service name="SecuritiesExchange"> <documentation>This demonstrates how to use the Description attribute</documentation> <port name="SecuritiesExchangeSoap" binding="s0:SecuritiesExchangeSoap">
TheWSDL file has several interesting characteristics, described shortly in some detail.
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
The WSDL file defines its own namespace. WSDL adds a targetNamespace attribute to the <definitions> element. The targetNamespace attribute may not use a relative URI. Conversely, it must use the fully qualified URL. The namespace allows the author to qualify references to entities contained within the WSDL document.
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
By doing this, the WSDL file assigns the prefix wsdlns to reference the namespace. This prefix fully qualifies all references to entities combined within the document. In addition, it sets prefixes for the <types> element as well as the XSD Schema. The <definitions> element sets boundaries for a specified name. All elements declared within the WSDL file define entities for messages and ports. Assign entities utilizing the Name attribute.
In a production environment, it is imperative to change the target namespace to your own. The temporary namespace displayed in the WSDL document, for example,
targetNamespace
="http://tempuri.org/"
xmlns=http://schemas.xmlsoap.org/wsdl/
specifies the http://tempuri.org namespace. It is better to do the following:
targetNamespace
="http://IFCEBrokerageFirm.com/"
xmlns="http://schemas.xmlsoap.org">
Returning to Listing 10, the <types> element contains XSD Schema information contained within the WSDL file. For example, examine the following document segment, and observe how the schema element appears as an immediate child of <types>. In addition, <types> functions as a container for XSD Schema complex types.
The same is true for StockQuoteResponse. Its type is s:double. The <message> element contains two parts, the message name and the part name. The message name is StockQuoteSOAPIn. The part name is parameters, and the element is s0:StockQuote. Notice that the message segment contains both a
The <message> element contains descriptions for logical elements of messages.
The <part> represents a parameter passed to the method.
The <portType> element defines a list of operations, each individually assigned to a specified <operation> child element. In this case, SecuritiesExchange SOAP is the portType name. The <operation> name is StockQuote. The input and output messages are
s0
:StockQuoteIn
and
s0
:StockQuoteOut
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
Recall that an interface is made up of a set of signatures, which in turn are made up of an operation’s name, the objects that it accepts as parameters, and its return values. The interface represents the entire set of requests that are sent to the interface. For example, by typing an interface, that is, Type IFCE, the interface accepts all requests for operations defined in that interface. Two objects representing the type can share individual parts of an interface. In addition, interfaces can contain other interfaces, referred to as subsets. Frequently, we can refer to a subtype as inheriting from its supertype interface.
Interfaces are fundamental to object-oriented programming. An interface represents an abstract concept by declaring its intentions, but never reveals the how. In essence, the interface says nothing about its implementation. This is a win-win situation for developers. They can mutually share the same interface and write totally unique implementations without conflict, as long as they adhere to the interface’s signature.
Dynamic Binding Interfaces support dynamic binding for disparate objects sharing the same signature. For example, developers can submit a request to an object with confidence, knowing it will accept the request because it supports object substitutability. One object containing the same interface is interchangeable with another object at runtime, courtesy of a mechanism called polymorphism. As long as the object’s signature is adhered to, the object will process any request with equanimity.
During component-based development, you construct the interface so a client invocation on a specified service will never know how the request is implemented. Encapsulation shields the implementation from the client. Therefore, you can think of an interface as having two parts:
Interface Defines a set of public method signatures but provides no implementations
Published interface A uniquely identifiable interface made available through a registry to clients for dynamic discovery
Interfaces declared in Java or managed C++ typically provide only method signatures. Therefore, they describe why but not how the interface should be implemented. This allows for multiple implementations and allows services or components to enhance both flexibility and scalability. However, the stateless Internet environment does not guarantee that the interface’s implementation is always secure and compliant with any behavioral specification. Despite this limitation, businesses are gravitating toward more service-oriented systems. Perhaps it is possible to adhere to the safe practice of defining a behavioral interface.
Objects are created by instantiating a class. This process allocates storage for the object’s internal data consisting of instance variables. This in turn binds the object with its variable types. By employing a methodology called class inheritance, the subclass inherits all parent data type definitions and its behavioral characteristics. This means objects will perform operations defined in both the parent and child classes.
The sole purpose of an abstract class is to define a common interface for its child subclasses. However, an instance of this class can never be instantiated. Operations defined by an abstract class are called abstract operations, whereas classes that are not declared as abstract are called concrete classes. Abstract classes describe general behavioral characteristics, whereas concrete classes define more specific operations on an interface’s signature.
Class Inheritance vs. Interface Inheritance
It is important to distinguish between an object’s class and its type. A class defines an object’s internal state and provides information on how to implement it. For example, superclass Employer is inheritable by several subclass employee types. A salaried employee defines its implementation in reference to class Employer. An employee retained on commission defines its behavior in reference to class Employer, and so on. In essence, class inheritance is just a mechanism for implementing and extending a specified class’s functionality.
To be a bit banal, a child inherits all genetic characteristics from his/her parents, but extends the parents’ genetic and social inclinations by building on them and becoming an individual person. Interface inheritance reduces implementation dependencies between subsystems and components. Therefore, it is safe to assume that programming to an interface is better than programming to an implementation. Best practices suggest it is better to declare variables that are instances of an abstract class rather than instances of a concrete class.
In conclusion, perhaps one of the most important concepts is learning how to design reusable components. In addition, knowing how to implement abstract interfaces is essential to designing web-based applications in ASP.NET. Remember, the .NET Framework and the ASP.NET runtime are composed of reusable components and interfaces. Therein lies the key to understanding .NET and ASP.NET.
Remember: This is part one of chapter 7 .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004). If you like what you see, feel free to click on the following link to get your own copy! Buy this book now.
/ 17 
ASP.Net Application
Web Services Description Language
