Web Server Programming phần 9 docx

will eventually emerge. One possible extension might be simple scriptable web avatars that can conduct some transactions automatically. These could for example run on those workstations that are permanently connected to the Internet via DSL; they could perform tasks like accepting and filtering advertising email, and selecting news items from a news feed. When a user returns to their workstation, they will find a r eview of the day’s material already prepared as a display document. But these are all things for the future, a future that you can help create. 11.3 Peer-to-peer Obviously, there is lots of raw computing power out there in Net-world. Think of all those Pentium 4 PCs with 256 Mbyte of memory, 40 Gbyte of disk storage and a clock speed of 2.5 GHz or more, permanently attached to the Internet via DSL modems. Part of the day these machines are ‘busy’ being used for Net games, ‘perving the Pornnet’, conducting discussions on chat servers, and so forth. Most of the day, these machines are idle. The idle machines represent a huge potential resource of computational power. This distrib - uted computational power represents a technical solution – the right problem just needs to be found. The conventional Internet style is ‘thin client displays data from big server’. This style does not attempt to exploit the computational power of the client. ‘ Peer’-style approaches treat the p artners in a network more equally; each can contribute to an overall system, though maybe in different ways. DNS represents a successful if rather specialized peer- to-peer system; each of the zone name servers handles a small part of the work, and all work together to solve the problem of mapping domain names to IP addresses. Akamai’s groups of content servers, which duplicate the multimedia content of web sites, can also be thought of as a proven application of another specialized form of peer-style computing. ‘Peer-to-peer’ technologies attempt to find other more general applications for the distributed computing power. There are many different ‘peer-to-peer’technologies. Their common element is a move away from th e thin clien t/power server web model. They may involve sharing o f CPU power, sharing of disk space for temporary data, or sharing of disk space for long-term replication o f data. Their architectures vary. DNS has a strict hierarchical structure, with its root servers and servers in each domain and sub-domain. There is a well-defined distri - bution of responsibility: each server handles requests for names and addresses in its zone and may delegate responsibility to other name servers handling sub-domains. Other peer- to-peer systems h ave a central authority – a server that delegates tasks to worker machines, or which acts as a contact point where potential collaborators may identify one another. Other systems are more amorphous; these systems have multiple contact points; from these, collaborators pick up the IP addresses of some arbitrary set of machines that happen to be working at the same time. This arbitrary set of machines becomes the collaboration group for the new participant. The SETI@Home project represents one of the longest running examples of peer-to- peer systems that use a centralized architecture. This ‘Search for Extraterrestrial Intelli - gence’ involves the processing of data recorded on radio telescopes. The recorded data is 490 Future technologies? random noise in the radio spectrum; the searchers hope that somewhere in all the record - ings there will be a trace of a weak but regular signal. Regular signals would indicate deliberate radio transmissions; these would imply the existence of an intelligent life form controlling their source. Participants in the SETI@Ho me project must first download an analysis program; this program can run instead of a screensaver when a computer is idle. When running, this program asks the main SETI@Home server for another block of radio data; the data block gets downloaded and processed. The client returns a summary that is then checked by the SETI@Home server for any significant signal. The SETI@Home model has been adopted in a number of other systems that involve a large computational task that can be broken into regular sub-tasks. An example use was the cracking of one of RSA’s encryption challenges. RSA had published some encrypted messages; the challenge was to d ecrypt one to reveal a secret. The encryption algorithm was known, there was just a rath er large number of possible encryption keys, so a brute force method was applicable. The code was cracked using a SETI@Home-like mecha - nism for distributing subsets of the range of keys to each of the thousands of participating computers. An example of a more useful application of this technology is the Stanford Alzheimer and Amyloidogenic Disease Research Program; this requires studies of how proteins fold to into a specific three-dimensional shapes. This project is one of several sponsored in part by Intel ( http://www.intel.com/cure/); Intel’s aim is to in crease the number of applications for this form of collaborative computation. The Napster file-sharing system raised the prominence of peer-to-peer systems. Napster again had a central node. Napster clients would connect to this node, registering their IP addresses and providing details of resources (mostly pirated audio recordings) that they were making available. The central server also handled search requests. A client seeking a particular named resource could run a search request at Napster’s server; the result would be a list of IP addresses of those other clients who were offering copies of that resource. The client seeking a resource would then open a peer connection to a chosen one of the clients offering that reso urce. With its thirty millio n clients, Napster established that there was a potential market for an alternate, lower cost m echanism for distributing audio recordings. The technically sophisticated users of the old Napster system have moved on to a more truly peer-to-peer distributed system known as Gnutella (along with others such as KaZaA). Like Napster, Gnutella is in the ‘business’ of ‘file sharing’. However, there is no single point of vulnerability (not even to attacks by lawyers). There are published lists of IP addresses for machines that will normally be operational and participating in the Gnutella network, but these machines may not actually offer any shared resources. Would-be participants in the Gnutella network try connecting to these known sites until one responds. The new participant registers its current IP address (usually a transient IP address as allocated by an ISP for a dial-in session) and downloads the IP addresses of a collection of currently registered participants. The collection of IP addresses represents the new participant’s commun ity with whom files can be sh ared. Of course, these commu - nities overlap and the entire world of Gnutella can be reached by a message that traverses the necessary number of hops. A Gnutella member can ‘broadcast’a request for a resource to tho se other participants for whom it h as IP addresses. The recipients of this request may be able to respond directly; otherwise, they can rebroadcast the request to the members of Peer-to-peer 491 their own view of the Gnutella community. The hard part is to prevent the same request being replicated and repeatedly being exchanged between machines; there are limits on how many hops a request may take, and other limits on propagation. There are other file sharing systems that proclaim aims nobler than the sharing of com - pressed audio files. Both Freenet and Publius are concerned with publication of informa - tion in a form that will resist censorship. Members provide permanent storage for files; these maybe encrypted and signed with digests to guarantee their authenticity. Persons seeking a particular document will be able to find its decrypt key and then find a copy of the document somewhere on the network. There are already companies seeking to find ways o f co mmercially exploiting the CPU- sharing and file-sharing facets of the peer-to-peer systems. Other companies are exploring the use of peer-to-peer architectures to support various models for collaborative groupwork or workflow systems. These companies include United Devices (which is col - laborating with Intel on the SETI@Home-derived ‘distributed supercomputer’ approach), and Endeavours Technology and Ikimbo, who are exploring ways of combining Napster- like file sharing and instant m essaging to build systems f or ad hoc collaborative work groups. 11.4 andonto‘WebServices’ A client’s order, entered via a form in an HTML page and recorded by a script, a servlet, o r maybe even an EJB, is just the start of a chain of activities. In the server company, the order must be processed further. It may be possible to fulfill the order from stock, but it may be necessary to purchase parts from one or more suppliers. When the ordered items are complete, delivery by a courier must be arranged. The ordering of parts and the arrangements with couriers and so forth, all involve exchanges of data between the com- puter systems of the various companies that are involved in the overall commercial transaction. Obviously, it is attractive to automate these data exchanges among companies. It seems quite inappropriate for a clerk to have to read a printout of an e-commerce order and re- enter much of the same data in a web form generated by a supplier’s computer system. It would be more efficient if the computer systems involved could communicate directly. This section takes a brief look at existing technologies and newer ‘web service’technol - ogies that can help in the further automation of web commerce. 11.4.1 The existing world of distributed objects In the last decade, such collaboration among computer systems has generally involved the use of distributed object technology with implementations based on CORBA (Common Object Request Broker Architecture) or Microsoft’s evolving COM/COM+/DCOM/ DNA/ systems, or Java RMI, or more recently Java EJB systems. While these implemen - tation technologies have many similarities, CORBA is the most complete and sophisti - cated. CORBA/RMI/EJB/DCOM systems all involve client–server relationships among 492 Future technologies? objects that exist in programs running on the computer systems of the companies partici - pating in collaborative commercial activities. If you were developing a system that could deal with a customer’s order and p lace any orders for additional parts from one of your suppliers, you would start by getting the inter - face for the CORBA object that your parts supplier uses to handle business-to-business orders. This interface would specify the operations (i.e. methods or member functions) that the object supported along with details of their arguments, data types used and excep - tions th rown. This interface would be defined in the CO RBA Interface Definition Lan - guage (IDL). You would choose your implementation language (say C++ for example), and you would then pass the IDL describing the supplier’s server object through an IDL- to-C++ compiler. This process would generate a class defining the client-side stubs (proxy objects) that you could use in your C++ CORBA client program. Your program would create an instance of this stub class and arrange for it to bind through the network to the supplier’s actual order-handling object; then your code would treat this stub object as if it were the real order-handling object. Your supplier would pro - vide information on how to do the binding (most likely, the supplier would give you the URL of its CORBA name server and the name of the object that you needed to contact). Ultimately, the supplier’s information and name server process would yield some kind of object identifier with the TCP/IP address of a host process and an internal id entifier for th e server object. (If both you and your supplier were using a sophisticated CORBA imple- mentation, the object identifier might include additional data such as the identifiers of replicated server processes that handle load balancing or failure rollover, along with data on security constraints that could automate the exchange of client and server authentica- tion certificates.) Th e identifier gets embedded in an instance of the client-side stub object in your program, and is used to open a TCP/IP connection when a server operation is first requested. When you ran your program, the requests that your code made to your stub object would be converted into messages that would invoke actions by the real order-handler object running in your supplier’s computer. Your code could be in C++; your supplier’s version might be in Cobol, Ada, C++, Java or any of the other languages that has a defined IDL-to-language mapping. Data exchange is efficient; complex data structures are easily transferred. For example the CORBA system supports things like iterators that allow large collections of results to be obtained a group at a time. The client–server TCP/IP connec - tion is normally kept open, allowing the sequences of requests and responses that make up a typical commercial transaction. The connection is closed when the client no longer needs the service. If you were considerably more ambitious, you could make use of CORBA’s ‘dynamic invocation’. This allows your client program to obtain details of a server interface at run time. Once your program has details of the operations supported by the server object, it can construct request objects that name the method and incorporate argument values. It is a bit like using Java reflection to invoke methods of a Java object, but the CORBA stan - dards define how these dynamic calls can be made irrespective o f the implementation lan - guages used in the client and server processes. Obviously, it is much harder to write a program that can generate requests to a server, or servers, whose functionality is poten - tially changeable. Dynamic CORBA has always b een a rarity. and on to ‘Web Services’ 493 CORBA’s strength is in the standardized services that it provides to supplement the basics of a remote object invocation. These services include support for distributed trans - actions, events, and naming services. The CORBA transaction service allows a client to define a transactional context that then can be applied to a sequence of operations on dif - ferent servers and databases; the transaction service hand les all the comp lexities of coor - dinating a distributed transaction . An events or ‘notifications’ service allows a client to register with an event channel expressing an interest in certain types of data message; for example, a client might register with a ‘stock ticker’ event channel expressing a desire to be informed when prices of certain stocks change by more than a specified amount. The event channel receives a stream of messages such as stock prices, handles the message fil - tering tasks for each client, and invokes callbacks on a client when data of interest appear. CORBA has a conventional naming service that returns an object reference for a known object; the naming service is like the phonebook white pages: you look up the name of a known service agency or trade person and you get their number. CORBA also has a ‘trader service’ that is analogous to the phonebook ‘yellow pages’. You use the phonebook yellow pages by looking at the advertisements placed by various service providers or trade p ersons in a p articular category, and pick the service you wish to contact. A CORBA trader process has a repository where service suppliers (‘exporters’) can publish d etails of the services that they offer. A service is characterized by its interface (the operations that are supported) and by a set of properties. The properties used to characterize a service have to be agreed by service providers; they are typically ‘quality of service’-style proper- ties, or charging rates for services. A particular service provider exports a service to the trader by supplying values for these property fields. A client seeking a service provider can contact a CORBA trader, specifying the service required. The client can submit constraints; these are defined in a reasonably complete language for manipulating boolean-valued expressions. The constraints define combina- tions of tests that are to be applied to the property values of the different exporters of a ser- vice; a client seeks only those exporters whose offers satisfy the specified constraints. The trader applies these constraints to check th e suitability of services published by different exporters. Traders can be federated; a trader can forward a client’s request to other traders who might have more suitable services registered. Eventually, the client receives a set of data records identifying the possible servers. Client code can then select and bind to a chosen server. Traders are a standard part of the CORBA world and are available with most CORBA implementations. Interestingly, the success stories for CORBA as published by suppliers like Iona and Inprise very rarely include any story praising the success of a trader-based system (transactions, events and other services all figure prominently, but traders don’t seem popular). Most use of traders has been for internal company applications. There was never much progress toward having competing companies agree to standard IDL service interfaces, and associated quality of service properties, that could be published in feder - ated traders and accessed by clients working across the Internet. The main disadvantages of CORBA (and comparable technologies) are the perceived complexity of pro gramming an d difficulties with interoperability. Programming for the client side is usually quite simple, but on the server side the programmer must deal with many resource management issues in addition to application coding. 494 Future technologies? There are really two aspects to th e interoperability problems: Micro soft, and inconsistent implementations of the evolving CORBA standard. While more than eight hundred compa - nies worldwide have cooperated within the Object Management Group to develop the CORBA technologies for heavy duty systems integration and legacy system maintenance, Microsoft has insisted on the creation of its proprietary COM, COM+, DCOM, DNA product group. There are bridging mechanisms – CORBA programs can invoke operations on Microsoft COM objects – but these mechanisms for interoperation are limited and clumsy. The other problem is that CORBA implementations do vary. At any particular time, CORBA implementations from different vendors may match versions from CORBA 2.2 through to the latest 2.6 or whatever. The implementations will only be partly interoperable; basic invocations on objects in th e other system will work, but more advanced cap abilities (like security elements in object references) may not be supported, or a particular imple - mentation might not support the current notification (event) service etc. There are other problems with systems that communicate using TCP/IP. Many compa - nies use firewalls that restrict access to a few ports – such as the HTTP port 80. These fire - walls block communications to other ports, such as the ports that are dynamically allocated for CORBA clients and servers. The developers o f Java RMI ran into this problem when first creating the RMI network protocol and so provided an alternative communications protocol based on HTTP. This RMI/HTTP protocol is costly. Clients out- side the firewall package their requests as HTTP post requests. The HTTP daemon uses CGI; each request gets handled by a server-side CGI program that reads the posted request and reconstructs the origin al RMI request that is then sent to the RMI server within the firewall protected zone. The response is picked up by the CGI program, packaged as an HTTP response and returned to the client. This is hideously clumsy, but it works. There is a serious anomaly here. Systems administrators block ports because they worry that request traffic to arbitrary ports may involve operations being run on their machines; then they permit operation traffic to tunnel through HTTP (so losing the security they thought they had gained an d adding a substan tial bottleneck to the traffic flow). Despite its faults, CORBA is a mature product with many implementations and much support. But now it is to be replaced by the new ‘Web Services’ technologies. 11.4.2 Steps towards a future world of distributed objects The term ‘Web Services’ covers a group of interrelated technologies. The components include a service directory system that is considerably more ambitious than the CORBA trader scheme, a service d escription system that will replace CORBA IDL style descrip - tions, and a remote procedure call mechanism that r elies on message traffic tunneling through HTTP or SMTP (the mail protocol). There are many claims advanced for Web Services, but one of the most emphatic is that this technology group will realize the poten - tial f or dynamic creation of integrated applications that was promised but never really achieved with CORBA trader and CORBA dynamic invocation schemes. Web Services originated with a much less ambitious system. In the late 1990s, a system was defined that allowed remote procedure calls (RPC) to be made in a technology-neu - tral manner. All conventional RPC mechanisms are technology-specific. The original RPC mechanisms were defined for C programs and depend on client stubs generated and on to ‘Web Services’ 495 through programs like rpcgen; these stubs communicated with server-side infrastructure using a standardized but RPC-specific protocol. Java RMI again has its client stubs and server components, and another quite different wire protocol for communication. CORBA, as described in the previous section, has its Internet InterOrb Protocol for com - munication between its clien t stubs an d its server infrastructure. The Microsoft world had another scheme for COM and its derivatives. The XML-RPC proposal (originally from the UserLand company) avoided these technology specific communications protocols, and so allowed the client and server implementation technologies to be completely separated. All remote calls are ultimately similar. They involve a request message that identifies the method to be executed, the argument data for the method and the server where the operation will run (i.e. ‘server process’ as IP address and port, and where appropriate a ‘server object’ as identified by some opaque identifier interpreted only in the server pro - cess). A response is invariably some form of data structure that packages either an excep - tion or a function result along with any ‘out’ argument values. With XML-RPC, these request and response messages b ecame plain text messages. Such messages h ave complex but regular structures; naturally, XML emerges as the appropriate mechanism for defining the structures of these text messages. An XML DTD or Schema can define the forms for the messages, specifying the structure in terms of elements that represent a method call. A method call element would obviously contain an attribute or nested element with the method name, and a number of nested elements each characterized by type and value for the arguments. A client using XML-RPC can use a textual template an d s ubstitute in strings that represent the values of the actual arguments for a call. An XML-RPC r equest was pos ted via H TTP to a URL that rep resented a web server script (ASP or similar) or a CGI program. This script or CGI program had to parse the incoming XML document and extract details of the actual server object, method and argu- ments. Then the CGI program would act as a proxy client invoking the real server. At this point, it is again technology-specific; a COM service would be invoked using COM mech - anisms, and a Java RMI service would be invoked using RMI technology (you can’t avoid the technology-specific programming, you can merely move it out of the actual client and into a proxy client). The server’s r esponse (encoded in a technology-specific manner) would be retrieved by the CGI program or web server script and converted into textual form. At this stage, the intermediary code could again use a simple text template for the response and slot the returned data into the appropriate fields. The web server then returns the XML response document as the result of the original HTTP post request. The client would n eed to parse the XML document and extract the returned data values. This is another example of the adage that ‘all problems in computer science are solved by using another level of indirection’. Here, the p roblem of technology-specific client- side coding and communications protocols has been solved by indirection through the additional server-side intermediary. Everything technology-specific is confined to the server realm; client and communications are technology neutral. Of course, you always pay in terms of performance costs when you add a level of indirection. Here, the costs are noticeable. Conventional RPC mechanisms aim for efficiency. TCP/IP connections are established and maintained open for the duration of a sequence of requests and responses; data 496 Future technologies? representations of requests and responses are designed for efficiency of data transfer and encoding/decoding at communications endpoints; and state can be maintained in server- side objects. A CORBA Iterator is an ex ample where server state is useful and complex structures can be transferred. Iterators are returned when a client requests a large number of data records. A CORBA iterator allows these to be transferred a group at a time co m - pactly represented in network-friendly sized packages. In contrast to the conventional wire-efficient RPC mechanisms, X ML-RPC is costly. Each request and response requires the establishment of a new TCP/IP connection to a web server. This is going to matter when the client–server interaction involves long sequences of requests. Each interaction involves XML parsing; firstly the server must interpret the request, and subsequently the client must parse the response document. XML-RPC favors stateless servers with single-shot requests–responses. Instead of some - thing like the statefu l CO RBA iterator that r eturns data in parts, an XML-RPC server for the same data access role would return a gigantic XML text document containing a full set of results. These performance problems did not figure too highly in early XML-RPC applications, many of which were proof of concept applications where the service was a low-use, stateless server with methods that involved minimal data transfer (e.g. a weather service that gives the forecast for a specified city). A revised version of X ML-RPC was submitted to the W3C (the body that standardizes everything to do with the web); the proposal was sponsored by Microsoft, IBM and Ariba, along with UserLand and other smaller companies. This revision became SOAP: the Simple Object Access Protocol. (Subsequent revisions dropped the ‘Simple Object Access’ interpretation because SOAP servers can be procedural programs! SOAP is now merely an uninterpreted name for a protocol.) Of course, an XML-RPC or SOAP client program must possess details of the server and the methods that it offers. With Java RMI and EJB, such details took the form of the defini- tion of a ‘Remote’ interface; with CORBA, the details were defined using the Interface Definition Language. Essentially, an interface defines a class, listing its methods. Each method is characterized by a return type and by a list of parameters that are also character - ized by their data types. Obviously, such an interface declaration can be represented as a structured textual document. Once again, XML has a role: it can be used to define th ese interface documents. Defining the interfaces of servers is the role of the Web Services Description Language (WSDL) component of Web Services. WSDL documents define the location of a server (its URI), individual message formats and operations (request and response message combinations). The Universal Discovery, Description, and Integration component of Web Services is the enhanced replacement of the CORBA trader system. The intent of UDDI is to have a number of registries where service sup pliers can pub lish d etails o f th eir serv ices. Both Microsoft and IBM run production and prototyping UDDI registries to encourage the adoption o f these technologies. Companies offering network-accessible computational services will advertise these services in major registries. A UDDI directory entry has a number of subsections. The ‘business entity’ data include company name, address, description (which o ften reads like a corporate ‘vision state - ment’!), and so forth, along with codes from standard classifications (e.g. North and on to ‘Web Services’ 497 American Industry Classification S ystem) that characterize a business’s activities (e.g. Microsoft Corporation has an entry that records it as an instance of the NAICS ‘Software Publisher’category). The ‘business services’ data contain descriptions of services offered along with ‘binding temp lates’ that specify these services. Services are not limited to HTTP-based web services; a company may list things like fax contacts, phone lines for ‘help desks’, and mail and ftp servers. Even if an entry is given for a ‘uddi-org:http’ binding, this may simply represent the URL of one of the company’s web pages. A ‘busi - ness service’ entry f or an actual web service will include a r eference to a ‘tmodel’ record; among other d ata, this tmodel reco rd will include a link to the WSDL in terface definition for the service. (There is no direct analog of the CORBA tr ader ‘properties’ section that allowed quality of service parameters to accompany an advertised interface.) 11.4.3 UDDI, WSDL and SOAP This section contains a few small illustrations that may help make mo re concrete the var - ious Web Services components. A UDDI directory, such as that available at http://uddi.microsoft.com/, can be searched for service providers using a number of criteria including NAICS classification code and geographic location. For example, a geographic search for service providers in Menlo Park and in Palo Alto Califo rnia (location of the Stanford Research Institu te, Stan- ford University etc. – the very heart of e-World) revealed just two providers: Glenbrook Systems Incorporated, which has its company home page online, and RDC Interactive, which has listed th e names and contact details of three senior executives; neither company defined any other service. Another search using NAICS categories (Information/Data Processing Services) was mo re successful, resulting in 28 providers, so me of who m defined actual web services. Examples of web services include those of digipot.com, Calc and IBM. Digipot sup- ports o nline lo tto services on http://contest.eraserver.net/; its serv ices includ e facilities for logging in, getting details of results and game statistics and so forth, and all are defined via WSDL documents linked to the UDDI records. The Calc services proved to be dead links; they purportedly included a four-function calculator accessible via SOAP, and a more intriguing service that claimed it would find MP3 recordings. IBM nat - urally defines many services (IBM and Microsoft are collaborating on Web Services, hence the IBM entry in the Microsoft UDDI). IBM’s service entries include references to web pages (e.g. http://www.ibm.com/PartnerWorld/) and telephone and email contact points. A SOAP-based web service for publishing UDDI entries to IBM’s prototyping registry was listed, but access to the WSDL definition was blocked by a server security setting. (Another of the web service providers will have had no responses to his offerings; he had registered his access address as http://localhost.) The http://www.xmethods.org/ server is a location where rather more WSDL-defined services can be easily located. A part of the xmethods listing of r ecently introduced web services is shown in Table 11.1. The majority of these services are best described as ‘proof of concept’ exercises. In these, the server h as only a single function, or group of similar functions, with a string argument for a number, zip code, ISBN or similar, and returns a single string result. The co ncept of a remote proced ure call is sufficiently well established 498 Future technologies? and on to ‘Web Services’ 499 Service name Description Airline Carrier Codes Provides two-letter codes for all known commercial airline carriers ApniUrdu Urdu Translator Translates English Sentences into Urdu BibleWebservice Retrieves Biblical text Periodic Table Get atomic weight, symbol and atomic number for all elements Amazon.com Web Services Access Amazon.com using SOAP MapPoint Comprehensive mapping and geographical information service ImageConversion Converts images between bitmap, JPEG, and GIF file formats. HK Weather Forecast Get 5 days Hong Kong weather forecast Currency Convertor Get conversion rate from one currency to another currency UPS Online Tracking Web Service Retrieve UPS online tracking information great circle distance Great circle distance between two points of longitude, latitude Convert Number to Words in Spanish Convert number to words in Spanish InfosVille Returns longitude, latitude and height from a given city; only for France UPC Database Lookup Look up grocery items by UPC number Country – Population Lookup Service Gives the population for a given country BorlandBabel A ‘babel fish’ that speaks Swedish Chefish, Jive, Drawl, Eleet and other dialects Monthly Car Payment Calculates your monthly car payment Captain Haddock’s Curser Generates random curses from Captain Haddock in various languages Belgium Cities Search on postal codes and cities in Belgium. GetLocalTime Returns the local time in South Africa Temperature Conversion Service Converts Fahrenheit to Centigrade and vice versa Calculator Simple math calculations Agni Find MP3 Finds MP3 files on the Internet Inch « Millimeter Converter Converts inches « mm Table 11.1 Some of the Web Services published at http://www.xmethods.com/ (highlighted entries are discussed in the text). [...]... simple dialogs and alerts, and even change the appearance of items in the page Server- side scripting elements add yet more complexity to an HTML source document A browser should never receive a page containing any server- side scripts; instead, the web server should have processed them prior to sending the page to the client Server- side script elements are replaced by automatically generated fragments... Microsoft’s web servers The final word in this section is left to Captain Haddock at his residence at http:// www.tankebolaget.se/ (the WSDL service definition for Captain Haddock’s Curser is http://www.tankebolaget.se/scripts/Haddock.exe/wsdl/IHaddock/) When asked to comment on the human readability of WSDL service definitions, the Captain responded ‘huggormsavföda’ 11.4.4 Web service promises Existing web. .. stateless servers Each request is independent; no state memory is needed, no transactional boundaries need be honored, nothing gets changed in the server- side databases Web Services don’t have to be so limited For example, services can access ‘Session’ and ‘Application’ objects in much the same way as PHP, ASP or servlet/JSP applications; HTTP cookies are again used as session keys But even with some server- side... services that provide details of atomic weights The Web Service that is hosted at http://soap.fmui.de/webservices.php offers the methods: and on to Web Services’ G getNameBySymbol G getMassBySymbol G getNumberBySymbol G 511 getElementBySymbol along with others like getNameByNumber and getMeltingPointByNumber, The rival service hosted at http://www.webservicex.net/ has a more limited range of methods:... to Passport What is their case? How has this progressed? (6) Microsoft Passport first appeared in 199 9 It is used in MSN sites, and there are a few other major sites such as eBay that utilize Passport, but the growth of use has not been that marked Research the penetration of Passport into commercial web sites and write a report on current usage and on the factors that have resulted in slower than... data that are intended to disrupt your server) JavaScript checks must always be repeated in your server- side programs Their role is simply to avoid time-wastage associated with innocent errors There is no point in sending form data to a server and invoking a CGI program if a simple check will reveal that the data would be rejected Some of the packages used to prepare web pages include macros that can add... development of supplementary web portals feeding traffic to Amazon should not be a major imperative for other companies; any use of these Amazon Web Services must support a company’s own core activities Of course, from Amazon’s perspective there will be no justification for maintaining these Web Services if their use by client companies simply places a load on Amazon’s server machines and databases... fragments of content text and HTML formatting tags; this generated content text will typically contain data extracted from a server- side database A fully featured HTML source document can be very complex It may contain serverside scripting elements that are interpreted on the web server There can be script code that is being returned to the client for execution in the browser There will be structural... these pages using its own server applications, with these applications invoking Microsoft MapPoint web services as needed Of course, such a company could also use MapPoint services from within purely in-house Windows and Java applications that need map data A MapPoint application requires use of the Microsoft-hosted services with their databases, and of an application (MapPoint Server) that must run on... (MapPoint Server) that must run on one of the company’s own servers This application acts as a proxy through which the Microsoft-hosted components are accessed Microsoft can also supply software for wireless GPS clients; demonstration services include instant messaging for groups of mobile users who happen to be in the and on to Web Services’ 5 09 same area The MapPoint service has to be purchased, and . the server where the operation will run (i.e. server process’ as IP address and port, and where appropriate a server object’ as identified by some opaque identifier interpreted only in the server. connection to a web server. This is going to matter when the client server interaction involves long sequences of requests. Each interaction involves XML parsing; firstly the server must interpret. documents. Defining the interfaces of servers is the role of the Web Services Description Language (WSDL) component of Web Services. WSDL documents define the location of a server (its URI), individual