Professional ASP.NET 1.0 Special Edition- P39 pptx

</SayHelloResponse> </soap:Body> </soap:Envelope> The value of the <SayHelloResult> element is now an array of bytes. These bytes are a single-pass, symmetric (DES) encryption of the string "Secret Message". The EncryptionExtension attribute that we added to the function encrypts the value after the message is serialized into SOAP - allowing us to send a valid SOAP message that can be routed between various intermediaries as well as sent over alternative protocols. And our data remains secure as it is sent over the network. To decrypt the message, we use the same attribute, but add it to the proxy that the application using our service uses: <EncryptionExtension(Decrypt=DecryptMode.Request)> _ <SoapDocumentMethodAttribute("http://tempuri.org/SayHello", Use:=SoapBindingUse.Literal, ParameterStyle:= SoapParameterStyle.Wrapped)> _ Public Function SayHello() As String Dim results() As Object = Me.Invoke("SayHello", New Object(0) {}) Return CType(results(0),String) End Function Instead of setting an Encrypt property in the EncryptionExtension attribute, we now set a Decrypt property. This instructs the EncryptionExtension to decrypt any incoming messages. The result is that data is encrypted on the wire as it's exchanged, and decrypted again by the intended recipient. The ProcessMessage function of EncryptionExtension follows: public override void ProcessMessage(SoapMessage message) { switch (message.Stage) { case SoapMessageStage.BeforeSerialize: break; case SoapMessageStage.AfterSerialize: Encrypt(); break; case SoapMessageStage.BeforeDeserialize: Decrypt(); break; case SoapMessageStage.AfterDeserialize: break; default: throw new Exception("invalid stage"); } } It's very similar to the tracing extension we looked at earlier. However, instead of writing the SOAP message to a file, this extension is capable of using DES encryption to both encrypt and decrypt the SOAP message. Here's the Encrypt() routine that is called: private void Encrypt() { newStream.Position = 0; if (encryptMode == EncryptMode.Response) newStream = EncryptSoap(newStream); Copy(newStream, oldStream); } If the Encrypt property of the attribute is set to EncryptMode.Response, then the Encrypt() function will call another routine, EncryptSoap: public MemoryStream EncryptSoap(Stream streamToEncrypt) { streamToEncrypt.Position = 0; XmlTextReader reader = new XmlTextReader(streamToEncrypt); XmlDocument dom = new XmlDocument(); dom.Load(reader); XmlNamespaceManager nsmgr = new XmlNamespaceManager(dom.NameTable); nsmgr.AddNamespace("soap", "http://schemas.xmlsoap.org/soap/envelope/"); XmlNode node = dom.SelectSingleNode("//soap:Body", nsmgr); node = node.FirstChild.FirstChild; byte[] outData = Encrypt(node.InnerText); StringBuilder s = new StringBuilder(); for(int i=0; i<outData.Length; i++) { if(i==(outData.Length-1)) s.Append(outData[i]); else s.Append(outData[i] + " "); } node.InnerText = s.ToString(); MemoryStream ms = new MemoryStream(); dom.Save(ms); ms.Position = 0; return ms; } EncryptSoap() reads in the memory stream that represents the SOAP message and navigates down to the appropriate node. Once this is found, the Encrypt() method that accepts a string and returns the DES encrypted byte array is called. Afterwards, EncryptSoap() simply converts the encrypted byte array to a string and adds that string back into the SOAP message stream, which is then returned. Although this is quite a complex sample, it should provide you with an excellent starting point with which to build more secure Web Services. Here are some recommendations:  Ideally this encryption extension should be using asymmetric encryption, rather than having both the web service and the proxy sharing the same key.  A SOAP header should be used to send additional details about the message relating to the encryption. For example, details of the public key (if you were to re-implement this to support asymmetric encoding), as well as an encrypted timestamp to prevent replay attacks should be sent  Currently the message exchange only supports clear-text requests (from the proxy) and encrypted results. Ideally, the extension should support encrypted requests. These suggestions are beyond the scope of what can be covered in this chapter. However, hopefully they will be implemented in the near future and released into the public domain. Summary We started this chapter by discussing the general problem of finding Web Services that we might want to use. To address the problem we looked at Universal Description, Discovery, and Integration (UDDI), and how organizations can use it to find and register Web Services. We then stepped through the use of UDDI, using Microsoft's UDDI node, to demonstrate its typical use in discovering SOAP Web Services. After discussing the uses of UDDI, we mentioned that we still needed a way of describing the capabilities of Web Services, such as the protocols they support as well as the data types and XML schemas that may be used. To address this problem, we introduced Web Service Description Language (WSDL). Thanks to WSDL, we can build software based on the XML blueprint of a web service. We discussed the use of both Visual Studio .NET, and the command-line tool wsdl.exe to create this proxy software. After creating proxies with both of these tools we demonstrated how to use them and stepped through some common scenarios, including setting the timeout value and using HTTP cookies. Following our discussion of building .NET proxies for Web Services, we diverted our discussion to HTML screen scraping and how we could use a simple WSDL document and the support for regular expressions in .NET to easily turn any web site into a Web Service. Next. we mentioned several design decisions for Web Services. We looked at handling exceptions and how to use SOAP headers to send out-of-band data (that is, data that doesn't belong as part of the body of the SOAP message). Finally, we discussed Security - both the options provided by ASP.NET, such as Forms or Windows authentication, and some custom security and encryption options that can be implemented. That completes our coverage of Web Services. In the next chapter we'll turn our attention to Mobile Controls. Mobile Controls The Mobile Internet Toolkit is an extension to the controls available in the .NET framework that adds support for mobile devices. It is a collection of controls that, when placed in ASP.NET pages, will vary their output depending on the browsing device, and allow for content types other that HTML, such as WML (Wireless Markup Language) and cHTML (Compact HTML). In this chapter we will detail these controls and give examples of their use. We'll start with a tour of the wireless web, with a look at what is available and a discussion of WAP. Next we'll look at the mobile controls, including a reference section on the controls available. Moving on, we'll see some of the more advanced techniques we can use to streamline mobile web applications, before finishing off with a few guesses as to what the future holds for mobile controls, and wireless Internet access. A Summary of the Wireless Web Recently, there has been a huge surge of interest in wireless Internet access, and indeed in mobile computing in general. As we have become increasingly dependent on the World Wide Web we have developed a desire to access it from anywhere. The technology now exists to enable us to do this, although the exact nature of this access is quite different from 'traditional' Internet access. This difference has caused many problems, both for device manufacturers and consumers, as it has frequently been overlooked. Often, consumers have expected to get an all-singing, all-dancing, web-surfing gadget, and have been disappointed with what they have ended up with. However, the underlying potential of such devices is unquestionable. In order to make sense of this we need to look at features inherent in the types of device that can be used for mobile Internet access. The most obvious of these features is that the device will be small. It follows on from this that:  Display area is limited, being far smaller than a PC monitor and (at least in the immediate future) likely to lack the associated color capabilities in order to maximize battery life and minimize cost  Processing power and memory is unlikely to compete with PCs  Multimedia capabilities will be severely challenged Already it's obvious that we cannot expect the sort of web experience that we are becoming accustomed to using web browsers on our PC. To further illustrate this, consider the Wrox web site displayed on the screen of an Internet capable mobile phone: I think you'd have a hard time navigating through this site- if you could even read it! Of course, larger screened devices are available, such as the (significantly more expensive) Personal Digital Assistant (PDA) type devices out there. Some of the cutting edge ones even claim to support resolutions up to 640x480 pixels, so perhaps there is hope for viewing complex HTML pages. Most standard PDAs with smaller screens are also capable of viewing HTML, although the experience can be quite different from using a traditional web browser. There are also concerns when we consider the 'wireless' aspect of mobile Internet access. Put plainly, we can never expect the sort of bandwidth that is possible in hardwired systems. Not only that, but the signal quality is likely to be variable- we might temporarily lose communications; by driving through a tunnel, for example. Current systems allow a data transfer rate of around 9600 baud, which is comparable to the modems of yesteryear, and about six times slower than you might expect on a standard modem line (and orders of magnitude slower than more professional systems). Although many mobile networks will implement systems allowing for faster access in the future, speeds will always be slower than we might achieve on a PC. When this is taken into account we can hardly expect streaming multimedia web sites on mobile devices, unless there is some interesting paint drying near you that you can watch while things download. Up till now we've been considering the bad points. After reading the foregoing you may well be asking yourself how mobile Internet access has ever got off the ground. But, there are many things that are possible with mobile devices that aren't with PCs. It is only when we consider these possibilities that the true power becomes clear. The key point to remember is that mobile Internet access is mobile. It is available anywhere and anytime, without having to lug much hardware around with you. In addition, the fact that you carry it with you means that you are likely to be interested in information that pertains to your current situation and position (such as "Where's the closest Indian restaurant?"). In theory this kind of 'location-dependent' information should be accessible without actually entering information about where you are. After all, the network operator knows more or less where you are from the network cell you are in. Unfortunately, this kind of application has yet to appear at the time of writing. It seems that network operators aren't too keen on handing out this information yet, although developments are occurring regularly, and I wouldn't be surprised if this was possible by the time you read this. So, we know that mobile Internet access is a good idea, but, in the face of all the problems mentioned earlier, how do we make it work? Luckily, this isn't something we have to work out for ourselves. A lot of serious thought has been expended to come up with standards to get things moving. One solution that has taken off in Japan and is starting to spread into the rest of the world is i-Mode. This technology uses a cut-down version of HTML known as i-Mode cHTML (similar but not identical to the W3C cHTML standard). The standard that has the greatest prominence in Europe and the United States is the Wireless Application Protocol (WAP). WAP If you've had any experience using mobile devices to connect to Internet services, you've more than likely used a WAP-enabled device. Not only that, but I'd say it was very likely that you've heard the term 'WAP' on TV, seen it in magazines, and heard how much people seem to hate it. However, if you analyze the problems that people have with WAP, such as "It's too slow", "There's no color", "All the WAP sites look rubbish", and so on, you may notice that these can in all cases be explained by the limitations we looked at in the last section- and we weren't even considering WAP there. Even so, it seems perfectly reasonable to wonder why we should bother with WAP at all. In actual fact, WAP does quite a good job of dealing with these limitations, but the end result is still not enough to satisfy the e-generation. However, WAP is ready for the next generation of mobile communication networks- without major changes- and is likely to start to become more accepted as bandwidth increases. Of course, many people ask whether WAP will be here at all, or whether it will be replaced with something else. In order to address this point we need to take a step back and look at exactly what WAP is, and how it works. The objective of WAP is, logically enough, to get information from the Internet to a mobile client. This isn't exactly simple, not least due to the fact that there is no physical connection between the Internet and the wireless network. In addition, building up any communication protocol is a lengthy process (I, for one, wouldn't fancy sitting down and reading through the specifications drawn up for Internet communications, even if I did have a spare month or two). Deciding what form data should take, what security measures should be taken, how data should be compressed and transmitted, etc. is by no means simple. This is one thing that we can relax about though, the architects of WAP (the WAP forum) have analyzed the issues involved, and the results work fine. To summarize, the gap between the Internet and the wireless network is filled by what is known as a WAP gateway, which acts primarily as a protocol converter. Resources on the Internet are accessed by this gateway in much the same way as Internet clients do- using HTTP. The gateway does this when it receives a request from a WAP enabled device, which is transmitted using WAP protocols. Once it has fetched the resource required, the gateway may perform additional processing (such as compressing files to optimize transmission) if necessary, and then will transmit the result back to the mobile client, again using WAP protocols. This is illustrated in the figure below: This leads to a few questions, such as "What form do WAP resources take on the Internet?" and "How is security propagated between the mobile client and the origin server?" Again, these questions have been thought of already, which is part of the reason why the WAP specification (freely available from www.wapforum.org) is so large and consists of so many sections. The latest version of this specification released (in July 2001) was WAP 2.0, but for now most browsers use the older version, 1.1, with a few using version 1.2, last updated June 2000. Version 1.1 is the version we'll concentrate on here. Instead of listing all the documents, I'll just point out the categories to which they belong:  General WAP technologies- a selection of documents setting out the objectives of the WAP specification, and the various enabling technologies.  The WAP protocol stack and WAP gateways- the means by which information is exchanged with the Internet, optimized to be as efficient as possible in a low bandwidth environment.  WAP language specifications- specifics on the way in which applications may be created for WAP-enabled devices.  The WAP push specification- information on server-initiated WAP exchanges (that is, how information may be transmitted to WAP enabled devices without a direct request for it). Much of this specification is advanced, certainly more advanced than we want to get into here, but it's reassuring to know that it is there. Consider the WAP language specification section. This is the part of the specification that details how resources should be formatted on servers (as well as how they may be compressed for wireless transmission). From the discussion in the last section, it shouldn't be too much of a surprise to find out that HTML isn't the language used by WAP devices. HTML is a relatively heavyweight language, containing much functionality that just doesn't fit in with the idea of quick mobile Internet access. It makes far more sense to create something new for the bulk of cheap mobile devices, something relatively simple, optimized for the considerations we looked at earlier, and lightweight. Something, in fact, like WML- the Wireless Markup Language. We'll take a look at this in the next section. Note that more complex devices, such as PDAs, don't suffer from quite such strict limitations when it comes to Internet content. Since they typically have larger screens than WAP enabled mobile phones they are more suited to HTML - or at least very simple HTML to avoid the low bandwidth problem. Other options include cHTML, a variant of which is used in i-Mode as noted earlier, and the new XHTML standard used in WAP version 2.0. In case you are worried that omitting a full discussion of the new XHTML dialect is not 'future proofing' you, rest assured that enough of the key concepts and structure of WML survives. Learning WML will stand you in good stead for later XHTML devices. Also, as we will discuss later, using the mobile controls is to some extent language independent, so there's even less to worry about. After looking at all this, I hope I can convince you that WAP is here to stay. So many technical challenges have been overcome, and so much groundwork is in place, that launching a new and completely different means of wireless Internet access would be like reinventing the wheel. Of course, there are places where improvements may be made, but WAP is much more likely to evolve than to die. WML The Wireless Markup Language (WML) is the WAP forum's solution to the problem of formatting content for display on WAP browsers. It is an XML application and shares some features with HTML, although comparisons between these languages aren't that simple to draw. As we saw earlier, a web 'page' (taken here as the atomic unit of a web site) isn't an obvious choice for a fragment of a WAP site. For a start many web pages contain far more information than would be usable on a mobile device, and the concept of separate frames containing extra information is also not easily translatable. A single WML file is often called a deck, and contains one or more cards. Each card can be thought of as a screen-full of information, complete with text, graphics, hyperlinks, etc. Depending on the characteristics of the browser, and the device used to display a given card, this 'screen' may fit completely into the device display area, be accessible via scrolling keys, or require other modes of user intervention to navigate through. Navigation between cards may be within a single deck, or between decks: [...]... a professional web site- using templates and style properties Viewing Generated Code In each browser used in the last section different code was generated Most browsers enable us to view the sourcecode for the page being displayed (that is, the code generated by the ASP.NET processor, not the ASP.NET code itself) However, this is not always the case It can be useful to see the code generated by an ASP.NET. .. place back in the history stack, and return us to the first card Now let's look at the code that achieved this The code starts with the standard XML declaration necessary for any XML file: Next we have the DOCTYPE for the XML file, that is, the resource that specifies the WML 1.1 syntax and enables validation: ... essential to use the techniques found in the rest of this chapter, although it may be useful to get a wider understanding of wireless Internet access Device Interoperability Before we move on to look at the ASP.NET mobile controls, it is worth considering what is probably the main problem with WML WML was designed to specify content, not layout, meaning that different devices will often display the same WML... It is possible to detect the browser type by examining the HTTP_USER_AGENT header and then redirect the browser accordingly Slightly more advanced is the technique of generating WML dynamically, using ASP.NET or any other code generation technology However, this can be tricky to implement, as many minor things can need changing, which can make the code very confusing This may also result in you creating... different browsers I have used this to good effect, although it is tricky to get started and requires a great deal of foresight to structure your stylesheets in an appropriate fashion Finally, you can use ASP.NET mobile controls These may not allow as much versatility as other methods, but certainly seem to work OK and require much less effort on your part As well as being able to generate WML they also... the structure of WML pages can help you to design mobile web forms in a better way We'll spend the rest of this chapter examining these controls Introduction to Mobile Controls Mobile controls are the ASP.NET solution to creating web applications that are usable by multiple platforms The current release supports HTML 3.2, WML 1.1, and cHTML browsers, and allows third party customization for other types... Simply download and install the most up to date version of the SDK and you're ready to use the examples in this chapter The techniques for using mobile controls are similar to those required for other ASP.NET controls, so much of the code may look familiar to you, particularly that required for event handling, etc However, there are differences in the way we need to structure our pages to contain mobile... may then access WML files using standard URL format Let's look at an example of a WML deck This file can be found in the downloadable code for this chapter with the filename example1.wml: Welcome! Continue . specification released (in July 20 01) was WAP 2 .0, but for now most browsers use the older version, 1. 1, with a few using version 1. 2, last updated June 200 0. Version 1. 1 is the version we'll. filename example1.wml: <?xml version=" ;1. 0& quot;?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1. 1//EN" "http://www.wapforum.org/DTD/wml _1. 1.xml">. <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1. 1//EN" "http://www.wapforum.org/DTD/wml _1. 1.xml"> Note that we're not using WML 1. 2 here. This is because most current devices