Exploiting an Evolutionary Accident in Web3D ... - CiteSeerX

Exploiting an Evolutionary Accident in Web3D Communications to Integrate Application Components Chris Thorne* School of Computer Science and Software Engineering The University of Western Australia Abstract The Virtual Reality Modeling Language (VRML) ushered in a new era in computer graphics by providing the first international standard 3D format for the Web (web3D). Unfortunately, some who tried VRML applications found they did not work and naturally blamed the language. However, the problem often lay in the sensitivity to different client software environments of the programming interfaces used to extend VRML. In many cases, VRML applications had to be extended to include things VRML lacked, such as sophisticated user interface and interactivity, database access, multiuser support, security and system integration support. These important aspects of modern systems were added via a programming interface (PI), called the External Authoring Interface (EAI). The problem was that applications based on the EAI would not work reliably due to changes in the client environment by competitive commercial stakeholders, affecting things like the support for a required third party programming language. It is this problem that often lead to unsatisfactory user experiences, not VRML itself. Below the client battlefield radar, three small web3D functions accidentally evolved, in symbiosis with the Web, to provide an alternative integration method built on a simple but solid foundation: the Hypertext Transport Protocol (HTTP). HTTP is the protocol from which the very fabric of the Web was woven. This paper presents methods to integrate web3D application components directly via HTTP. The three web3D functions are used in combination to implement a communication cycle that makes use of persistent state stored in web services. The approach uses open standards, is portable across platforms and resilient to changes in client environment. Applications based on this approach will work more reliably on disparate end user systems and enable developers to leverage increasingly sophisticated web advances. CR Categories: 1.3.2 [Computer Graphics]: Distributed / networked graphics Keywords: Web 3D, scene graph, architecture, protocol, web page, web services, state, stateless, statefull, programming interface, HTML, HTTP

1. Overview of web3D architecture and interfaces To aid understanding of how a web3D program communicates with other programs, the conceptual architecture of an application with a web3D component and external components is shown in Figure 1. A web3D program is called a browser because it is generally viewed as a 3D web browser. The browser interprets web3D files, multimedia files or streams and presents audio-visual content as an interactive world to the user. Generally, the browser retrieves files over the Internet using HTTP. A PI can be used to communicate events between the browser and external programs. A rendering Application Programmer Interface (API) shows the world on a display device.

Figure 1 Conceptual architecture of an application with a web3D component and external components The EAI allowed external application components to interact with a VRML scene graph. It could thereby be used as a general integration mechanism to satisfy the disparate feature demands from applications, vendors and users alike. However, the following historical discussion reveals how problems with using the EAI developed under changes wrought by market forces over the past decade. The historical review identifies three web3D functions, which though unchanged since inception, nonetheless acquired sophisticated integration capability from their relationship to the Web as it evolved more powerful parameterisation and web services. An architecture for using this trio of functions for system integration and network communication is presented. The architecture and integration approach is illustrated with an example of how they work in a real-world scenario. A breakdown of core HTTP integration methods from which more complex user interaction can be built is presented. Alternative networking approaches are then compared and the benefits of the HTTP method proposed here are summarised before providing concluding remarks.

2. Historical journey of web3D external interfacing The commercial war that would affect VRML did not begin for some years after its inception. VRML was conceived by Pesce et al. [Pesce et al. 1994] who were inspired by the development of the mother of all networks, the Web, and dreams of a virtual cyberspace. VRML reached version 2 as an international standard in 1997 [VRML]. From 1996 the EAI was proposed as an informative annex to VRML 2. An EAI ISO standardisation process began but it took until 2004 before it was finally approved as a standard [EAI]. It was in 1998 that certain battle lines resolved from the “dotcom” struggle and caught the EAI in their crossfire. In this pivotal year, SGI suspended its Cosmo 3D development team and ceased support for VRML and their CosmoPlayer web3D browser. Many applications relied on CosmoPlayer's Java EAI implementation and they became stranded with an unsupported browser. Also in 1998, resulting from a legal dispute with Sun, Microsoft froze the Java Virtual

machine (JVM) supported in IE at version 1.1 [Gilbert 2003], further complicating development for those wanting to use Java. Netscape later removed its support for a JVM in its browsers forcing users to install Java separately. Netscape browser development then stalled for a time. EAI applications could still be run if an earlier version of Netscape (4.X) or a suitable version of IE was installed – but that created a problem for those wanting to use up-to-date web browsers. Some time after that, Netscape was resurrected in the Mozilla project and in the process changed its Javascript-Java interface that some EAI applications relied on for communication between the web browser and VRML browser, preventing them from working. When Microsoft released IE version 6, it removed Java support. In summary, all these changes meant that a client installation environment had to be very specific and frozen before a PI based application would work reliably. In 2004, VRML evolved into a new standard, eXtensible 3D (X3D) with a new PI, the Scene Access Interface (SAI). Since the SAI occupies the same architectural position as the EAI (Figure 1), it is still not independent of client environment differences so it could suffer from similar issues. However, these factors should be mitigated somewhat by a better interface design and open source support. Open source web3D browsers, such as the currently available xj3D [xj3D] and Freewrl [Freewrl], provide an attractive and low risk option for application development [Blais et al. 2001; Kochy et al. 2002; Zoi et al. 2003]. While the EAI lived interesting times, the Web was evolving new aspects that offered an alternative approach to programmed external authoring. Beginning earlier, in 1994, the W3C approved the URL encoding standard that allowed parameters to be added to a URL. The latest version of this standard has recently been updated [Berners-Lee et al. 2004]. URL parameterisation opened up the possibility of doing more sophisticated things with a URL request such as database queries. Web3D could not take advantage of URL encoding until VRML 2 added a new trio of functions that dynamically modify the scene from a URL: 1. createVrmlFromURL, 2. LoadURL, and 3. Anchor. The first two are web3D browser commands that can be used in internal “scripts”. The functions are defined in the EAI specification [EAI] but rather than using a PI, they communicate direct to external programs via HTTP to request and retrieve a URL designated resource. Anchor is a scene graph node [VRML], not part of the EAI. It has to be activated by an event such as a user click but otherwise has similar function to LoadURL. Therefore, for simplicity the remaining discussion will only give examples using LoadURL together with createVrmlFromURL. The original design of web3D was a pull model [Coors 1998]: resources identified by a simple web3D file URL were pulled from the Web. Web3D has many scene nodes that use URLs, as well as the three URL based functions already described. The true power of the trio began to be unlocked by extending the form of the pull model's simple URL from: http:///file.wrl to use a functional URL: one which initiated some processing, such as a database query, before returning a VRML file. Early approaches of this kind used a static file reference like “file.html”, where the file contains a script that makes its own URL request to a server database [Zlatanova 1999]:

http:///file.html which then returns a VRML file. This is an indirect network service request because a server database query is sent by a script in the HTML file rather than directly from the URL function in the web3D browser. Recognition of the database access possibilities of web3D URL based functions lead to a number of applications and experiments that modified web3D worlds using remote queries to databases [Stoter and Zlatanova 2003; Zlatanova 1999; Coors 1998; Gahedan 1998]. Such methods were exemplified by Lipkin's [Lipkin 1998] recommended practices for VRML database access but remained with the stateless request-response pull-from-web model, like Zlatanova's use of Anchor for database queries. Not everyone went along the URL function-query path. Some used the EAI with Java script code in a highly specific client installation environment to enable their applications to dynamically access databases and other external processing over a network [Maranne and Vaucher 2003; Coors 1998]. It is also worth noting that others took a more proprietary approach by providing a mini Java 3D browser that downloaded with the 3D file, using their own format and protocol [Cult3d; Anfy3D; Contact 3D; Cortona Jet; Kaon]. These had less problems with client environment differences because the PI was downloaded with the 3D world, they just needed Java support. As this paper is concerned with an open standards approach I will not discuss the proprietary technologies further. As the Web continued to evolve, it became easier to go beyond the database pull model. With the development of advanced web services, such as Apache web server [Apache] in 1995, and more recently Jboss in 1999 [Jboss] and Jakarta Struts in 2000 [Jakarta], the stage was set for doing more server side processing, including advanced server-driven user interfaces. These developments go beyond the pull model by allowing web service requests direct from the 3D world like : http:///?param1=value¶m2 =value2¶m3=value3 where “webService” refers to a server side operation and the parts following the “?” are a set of one or more attribute-value pairs that are parameters for the operation. The parameters are pushed to the server in the URL encoded request, processed and stored for later processing. The following section describes how to use the direct web service request model to create a complete pushprocess-pull cycle. This approach builds on an earlier proposal for using URL encoding with web3D by Thorne and Haines [2004].

3. Using HTTP for network application integration

Figure 2 Architecture for integration using direct networking and a statefull communication cycle implemented on top of multiple stateless HTTP transactions

The HTTP request-response cycle is called stateless because each transaction is performed without knowledge of previous transactions [Webopedia]. With the development of web services and their ability to store persistent state, a web3D client can now use HTTP to leverage this capability, instead of just pulling information from a web server using stateless transactions. In the push-process-pull model detailed in this section, data (or state) is first pushed to the web services component of the application in a URL encoded request. Server side processing is then initiated by the functional URL, with persistent state over multiple requests stored and modified by the server component. Results are pulled back by the web3D component in a later HTTP transaction. This approach enables a user to manipulate the 3D world by interaction with the web services page and manipulate the web services from the 3D interface. Therefore, even though the web3D client does all the work - the pushing and pulling - communication between application components appears two-way to the user. This type of two-way communication cycle is statefull because of the use of persistent state over multiple HTTP request-response transactions. With the direct networking model shown in Figure 2, traditional PIs on the client do not have to be used for integrating components. Application programming once done on the client can now move to web services. This suits larger, enterprise level, multiuser applications. There are few cases where a HTTP network integration model has been capitalised on in a significant application. The work of Belfore, II and Chitithoti [2000] is closest to the methods described in this paper. They used URL encoding to log information to java web services and createVrmlFromURL for creating objects from logs and other data. This paper provides a more comprehensive description of how to use createVrmlFromURL in combination with either loadURL or Anchor to implement several types of statefull communication cycles. The system of Zlatanova's [Zlatanova 1999; Stoter and Zlatanova 2003] performs URL requests using Anchor. However, Zlatanova only uses the Anchor node with static references to HTML pages to indirectly fetch data from the server. There is no direct pushing of state onto the server by the web3D client and no two-way, statefull communication cycle. Many other systems are in the same category [Ressler et al. 1996; Cowie 2002], although Ressler et al. use static Python scripts in place of static HTML pages to query a server database and Cowie uses a static reference to a JSP page. None of these except Belfore, II and Chitithoti [2000] used URL encoding to push state directly from VRML to an application component nor do they use a statefull communication cycle as described here. An application using the far greater power of the trio, combining URL encoding and the direct network push-process-pull cycle, is the ongoing planetearth project by Thorne and Weiley [2003]. Some web3D applications gave the appearance of HTTP network integration simply because they had a multi-frame user interface [Chen et al. 1997; Ranga and Gramoll 1999; Campbell, 1998; Wilson et al. 2000]. These applications utilise hyperlinks in web3D or HTML to pull information from a web server and display it in different HTML frames. However, the web server is not part of the application: it contains no application logic or state. The web server is part of the external environment. Therefore, these examples do not integrate application components via HTTP. Further, there is no indication that these applications used URL encoding to push state directly from VRML to an application component or that any kind of statefull communication cycle was used.

Figure 3 shows a combined 3D and 2D web interface from the planet-earth project with the web3D client in a HTML frame on the left and a web services component displaying its user interface in the right HTML frame. The right frame provides all of the advanced user interface capabilities that have evolved for 2D web pages. This integrated web services user interface can also be used to provide web based login access control and security, multiuser support and user database access.

Figure 3 Multi frame web3D and web services application compponents integrated by direct network communication without using EAI based programming interfaces on the client. Communication between components is through a two-way statefull cycle on top of stateless http transactions. Figure 4 illustrates HTTP communication between web3D client and web services using an example of dynamically adding a house to a world. The Figure shows the sequence of interactive steps and data flow from/to the LoadURL and createVrmlFromURL functions.

Figure 4 Web3D direct networked communication Push-ProcessPull cycle using loadURL in combination with createVrmlFromURL and showing steps to create a house in 3D world Let's have a closer look at our URL functions and see how are used in the example of Figure 4. In steps 1 and 2, a loadURL

function is called. A loadURL command looks like: Browser.loadURL ('http://:/application/control/selectHouse? type = cottage&position=10 200 100', 'target=rightFrame'); It's first parameter, “/application/control/selectHouse”, identifies an external service: a Java Server Page (JSP). The information following the “?” is passed to the JSP and may include things like default type and current location. The second loadURL parameter specifies a HTML frame, “target=rightFrame”, for the JSP to display the service's interactive interface (a web page entry form). This loadURL command allows the 3D client to access web services with a much more sophisticated user interface than is possible in web3D because all of the HTML, DHTML fields, buttons, other widgets and advanced formatting using Cascading Style Sheets (CSS) are available. In step 3 of Figure 4, the user selects a house to create. The JSP stores the user's input for later processing, making the interaction statefull. In step 4, a createVrmlFromURL command is used: Browser.createVrmlFromURL (http:// / application/control/createHouse?, self, 'positionHouse' ); This command instructs the web3D browser to send a HTTP request with the given URL and create VRML scene nodes from the response that is returned. It may also push additional parameters. “positionHouse” is the name of an internal VRML script function to process the response. “self” identifies the script in which the function resides. “createHouse” identifies a Java action class that executes with all the parameters originally pushed to the server and any modifications the user made. The term action class is a web services term referring to a class that executes to perform a service request. In Step 5, the action class for createHouse retrieves parameters stored in the web services by selectHouse and uses them to construct a VRML node representing the house which is then returned in the HTTP response to the 3D client. The example of Figure 4 has shown how the tiny trio combine to provide a minimal capability for effective use of web services, but what great power can come from so little!

4. Comparison of alternative network approaches to distributed application integration Three network integration methods were identified in the historical review: the PI method, indirect HTTP networking via static file URLs and the direct HTTP method of this paper. This section compares the strengths and weaknesses of the direct HTTP method detailed in the last section with the other two. When using a PI, there are more network protocols to choose from: HTTP, multicast [RFC 966], unicast TCP [RFC 793] and UDP [RFC 768] are the most common choices. A full explanation of each protocol is outside the scope of this paper, so comparisons will be made based on efficiency and portability of the point-topoint protocols: HTTP, UDP and unicast, multicast has multiple recipients and operates at a lower network layer. An application that requires high speed data throughput requires an efficient protocol. HTTP communication is less efficient because it uses a four step cycle [RFC1945] to transfer some data: 1. open a connection, 2. send request, 3. receive response data,

4. close connection. Unicast TCP has a lower overhead. A TCP connection is first opened so that data can be transferred. Information can then be transferred any number of times before the connection is closed. Each transfer is a two-step cycle: send data and receive response, so, for a large number of transfers, it is close to an average of two communications per transfer. Note that opening and closing a connection for TCP and HTTP (which uses TCP) involves more than one transmission between client and host [Kurose and Ross 2004]. The most efficient method for point-to-point communication is UDP [Kurose and Ross 2004] because it does not require a response from the recipient – it just sends and forgets. UDP therefore requires only one communication per information transfer. Each communication step is subject to network delay (often called lag): the time to get information from client to server or back again. The greater the distance between client and server plus the more network nodes between the two, the greater the lag. Therefore, in order of most total lag to least, there is HTTP, followed by unicast, then UDP. Applications where fast communication is important or mission critical will most likely use TCP or UDP. The military and emergency services of Maranne and Vaucher [2003] make use of PIs with the more efficient, non HTTP methods to meet high throughput requirements. Apart from lower total lag, these non HTTP methods have one other big advantage: smaller data packets due to binary encoding and compression. HTTP 1.0 uses text based requests and any HTML page requested is text leading to larger communication packet sizes and therefore less efficiency. Weaknesses of these non HTTP methods are that greater control over the network configuration can be necessary and firewalls may prevent communication. An application using the indirect HTTP method of Zlatanova is the slowest of the three options being compared here: it first requires a HTTP cycle to access the web page and then another for the web page to perform its URL query, thus double the total lag of a direct HTTP communication. An advantage of the HTTP methods is portability: they are more likely to be able to work on any client than the PI based systems. The other protocols, accessible through PIs, may not be supported by the application's environment or the network environment itself – requiring significant control over the client installation and network configuration. Another advantage is accessibility: HTTP can be used where other methods cannot: such as through firewalls, so it is available to a larger proportion of people. The lower efficiency of HTTP is becoming less of a problem as time goes on. Once again, this is due to the Web's evolution. The HTTP specification has moved to 1.1 and in doing so gained a number of efficiency related benefits. HTTP 1.1 allows the client to send multiple responses during each session, reducing the overhead of opening and closing a socket. It also allows for binary compression, reducing the size of packets transmitted and hence the time to transmit. A future advancement of the X3D specification may be to explicitly support HTTP 1.1 (HTTP itself is not explicit in the specification – it is implied). Lastly, peer-topeer solutions are gaining traction as legitimate industry application technology. A further advancement to web3D may be to support peer communication links, so that servers may push information back to clients rather than clients always having to do

all the work. It should also be noted that improvements in networking, such as increased penetration of broadband, lessens the lower efficiency objection to HTTP. In brief, the PI networking method is the most efficient, followed by direct HTTP then indirect HTTP. The most portable and accessible are the HTTP methods and their efficiency is improving with time due to continuing Web and network advances.

5. Three simple ways to implement two-frame integrated application with statefull method The createHouse example used to describe the push-process-pull model is a combination of simpler direct networking integration methods. This section describes in detail three simple ways to use the direct network approach to integrate application components. The same two-frame application interface with one 3D frame integrated with one HTML frame is used for each. The examples illustrate different user interaction alternatives and how interframe communication is handled in each case, starting from the simplest and going to progressively more complex user interactions. Figure 5 describes the objects that are referred to in each example. It shows the communications paths between client and server components. JSPs display HTML pages in the right frame in response to loadURL requests, handle the user input/output and store input for Java action classes to pick up later. Java action classes handle requests from the 3D frame by createVrmlFromURL calls.

The poll addresses a Java action class on the server which itself is periodically checking for the information from the JSP. If the expected information is not available the action class returns a null response. When the user selects the viewpoint, the JSP stores it. The action class will then read the viewpoint and send it in response to the next poll. The viewpoint selection stored on the server is then cleared, so the whole process can be repeated. Although a lot goes on behind the scene, HTML only user interaction is the simplest way to manipulate the 3D window. People are more familiar with web page interaction and modern web page technology provides a rich set of tools to make the 2D user interaction simple and powerful. Note that some level of scripting using javascript is often used to enhance web pages and this is another capability that comes for free with this web page integration technique. This example used loadURL together with createVrmlFromURL to achieve its purpose. An even simpler scenario is where there is no affect on the right hand frame and no user interaction. The 3D world may just want information directly from the server. In this case, a createVrmlFromURL request is made and the information returned directly from an action class. If the information is not available, polling will be required. Polling is not the most efficient technique for communication over a network. A technique for improving efficiency is described in 5.5.

5.2 web3D only user interaction In this type of interaction, the user performs an action in the 3D world that displays a web page in the right hand frame. A simple example is clicking on an object to display information about it. Suppose a house is in view and the user wants to know its price, number of rooms and other real estate statistics. Behind the dynamic changes visible to the user, the following steps occur. After the user clicks on the house, a loadURL function is executed with a URL that addresses an action class and a target=”rightFrame”. The action class queries a database then passes the results to a JSP. The JSP converts the information to HTML and sends this back to the web browser. The web browser then displays real estate statistics in the right hand frame. Although users are less familiar with 3D interfaces, if the 3D interface and interaction is simple and well designed it should not pose a difficulty and they gain the benefit of web based queries.

5.3 3D interaction followed by HTML input Figure 5 Dataflow between web3D client and server components for createVrmlFromURL and LoadURL functions

5.1 HTML frame only user interaction In this type of interaction, users only operate a web form in the right hand frame and the 3D world responds dynamically. For clarity consider the concrete example of viewpoint selection. The HTML form is displayed by a JSP after a normal web browsing action, such as clicking on a hyperlink or entering a url into web browser (e.g. http://www.planet-earth.org/enter.html). The 3D world performs a periodic polling script, waiting for a specific user input - a viewpoint selection. A poll is a request for a specific piece of information that is repeated regularly. Figure 5 shows how createVrmlFromURL is used to perform polling.

This method is a combination of the previous two, such as in the steps 1-5 of Figure 4. The web page that appears on the right frame is a data entry form. The user is expected to enter something and when finished a web3D object is returned to the 3D world. The initiating action in the 3D world this time causes two events simultaneously: the loadURL is called to initiate the web page form and a polling script is started to retrieve the web3D object when available. As both of these methods have been described separately they will not be elaborated further.

5.4 More complex interactions More complex interactions can be made from combinations of the above three methods. The createHouse example involved both

loadURL driven data entry and polling processes. A full application would also require navigating to a place in the 3D world where the house is to be placed. The three interaction methods described use loadURL in combination with createVrmlFromURL to implement a statefull communication cycle. Anchor can also be used with createVrmlFromURL in a similar manner. These three interaction methods are simple but sufficient building blocks for very effective and powerful integrated web2D and web3D applications. Depending on the desired application feature, the choice of which method to use will be driven by usability guidelines and what is needed from the client and server components. The only other consideration is efficiency, particularly of the polling method, and this is discussed in the next section.

5.5 Efficient polling with the HTTP pull model When a user interacts with something, a response should be within 1 second [Neilson 1994], otherwise the application will be considered boring or not very usable. If the interaction involves an underlying polling operation, as most of the interactions using the direct HTTP method would, that polling should not introduce a delay of more than a second. In order to keep delays below this limit, polling frequency has to be high – at least once a second. Consider if the application was a multiuser system with a hundred simultaneous users. With a polling frequency of 1 second for viewpoint selection alone the server would be receiving 100 requests per second. Now, if the web3D application was also querying the server for other information this could easily lead to server overload. Luckily, polling efficiency can be improved by reducing the network request frequency without slowing the response to user's actions. This can be achieved by using an architectural feature of both the client and server software: multi threading support. Multi threading refers to the parallel execution of two or more parts of a software program or system. When createVrmlFromURL is called, it does not wait for a response to the HTTP request – the web3D browser continues with other operations. A part of the createVrmlFromURL call sets up a script function to receive the response instead. This script function waits for the response while the rest of the browser executes. When it receives a response, it processes it in parallel to the rest of the browser's processing. On the server is another case of multi threading. An action class receives the createVrmlFromURL request and processes it in parallel to other web services, including JSPs. What follows is a sequential description of events, describing how the threaded design of web3D client and web services can be used to reduce network polling overhead while maintaining a responsive system. The earlier example of creating a house will be used to illustrate. We begin with the user selecting a create house option from a menu in the 3D world. This initiates a loadURL command: Browser.loadURL ('http://:/application/control/selectHouse', 'target=rightFrame'); that causes the selectHouse JSP to display a form to enter house parameters in the right frame. At the same time an internal script is started that begins polling the createHouse Java action class on the server using: Browser.createVrmlFromURL (http:// / application/control/createHouse, self, 'positionHouse' );

Recall that 'positionHouse' is a script function on the 3D client that processes the HTTP response from createHouse. On the server, the createHouse action class runs in parallel to the selectHouse JSP and other web services while the user is entering the house parameters. The advantage of this is that if we delay execution of createHouse it does not delay any other programs. Therefore we cause createHouse to delay for up to one minute if the user has not finished entering house parameters, checking every half second for the user to finish data entry. If the user has finished during this time it immediately sends a response to positionHouse. On the web3D client the next poll is only sent after receiving a response. When the createHouse action class is delayed, the response is delayed, resulting in an average polling frequency of one minute while achieving a response time to user interaction of half a second. This delayed polling algorithm leads to low network and server overhead while achieving high application responsiveness.

6. Benefits of direct network, statefull approach The benefits of the direct HTTP network protocol approach to web3D application component integration are: 1. It provides access to sophisticated 2D web user interface features not available in web3D, for free; 2. Reduced risk: the application does not depend on proprietary technology in client environment; 3. Stable communications system. HTTP, being the cornerstone of the Web, is available on all systems and is here to stay; 4. More useful communication by utilising persistent server side state and application logic; 5. Access to powerful web services for database, security and other processing controllable by the developer; 6. Fully open standards compliance; 7. Portability: all web3D browsers support the three functions so any client environment running a VRML/X3D browser can be used. 8. Wider accessibility: generally not blocked by firewalls. 9. Its does not require control over network configuration, in contrast to multicast and some unicast solutions. 10. Improving capability and efficiency through its link to a Web which continues to evolve. These benefits have been described in relation to HTTP because that is the only protocol available in VRML. X3D adds “stream” based communication via the the createX3DFromStream function. A “stream” is equivalent to a file read or network connection equivalent to unicast, raises the possibility of using a faster I/O mechanism than HTTP for the create function using. However, unlike the HTTP functions described here, there is no stream based method to send information in the other direction when the call is made: this is purely a pull function.

7. Conclusion Web3D's reliability suffered because its EAI programming interface used for integrating components tended to fail under changes to the client environment. An alternative integration solution to the EAI has been presented that exploits the accident of three web3D functions evolving via their HTTP link to the Web. It has been shown how these functions can be used in combination to implement a variety of statefull, two-way communications between web3D and web services. This solution is as reliable and as widely supported as the web because the web itself is woven from the same HTTP thread.

A general architecture for system integration using the network approach has been described. Some important features lacking in web3D: sophisticated user interface and interactivity, database access, multiuser support, security and system integration, can be added in a manner that does not compromise platform portability and accessibility. With this approach, web3D applications that rely on integration with other components are more likely to work when users on disparate client systems try them. In addition, all the power of integrated web page user interfaces and web services is available for the developer to construct a large distributed application that does not risk being sacrificed on the altar of commerce.

8. Acknowledgments Thanks to Ping Interactive Broadband for permission to use images from the planet-earth.org application. Thanks also to both anonymous and known reviewers for their helpful comments.

References APACHE. http://www.apache.org. ANFY3D. http://any3D.com. CONTACT 3D. http://www.blaxxun.com/en/products/blaxxun3d. BELFORE, L. A. II, CHITITHOTI, S. 2000. An Interactive Land Use VRML Application (ILUVA) with Servlet Assist, Proceedings of the 2000 Winter Simulation Conference. 1823-1830. BLAIS,C., BRUTZMAN, D., HORNER, D., NICLAUS, S. 2001. Web-based 3D technology for scenario authoring and visualisation: the SAVAGE project, Interservice/Industry Training, Simulation and Education Conference (I/ITSEC) 2001, Orlando, Florida. CAMPBELL, D.A. 1998. VRML In Architectural Construction Documents: A Case Study, VRML98, Monterey CAUSA. COORS, V. and JUNG, V. 1998. Using VRML as an Interface to the 3D Data Warehouse, Proceedings of VRML'98, New York. CORTONA JET. http://parallelgraphics.com. COWIE, D. 2002. Use JSP to create your own VRML world, http://builder.com.com/5100-6371-1050067.html. CULT3D. http://www.cult3D.com. CHEN, S, Myers, R., Pasetto, R. 1997. The out of box experience: lessons learned creating compelling VRML 2.0 content, Proceedings of the second symposium on Virtual reality modeling language, Monterey, California, United States. ISBN:0-89791-886-X. 83 - ff. EAI. ISO/IEC 14772-2:2004. The Virtual Reality Modeling Language, Part 2. JBOSS. http://www.jboss.org. JAKARTA. http://jakarta.apache.org. KAON. http://kaon.com. KOCHY, K. KIRSCHBAUM, C., TSCHIRLEY, R., MARKLE, S. 2002. A client server architecture based on secure communication for visualization of an interaction with 3D medical data, Proceedings of EuroPACS 2002, Oulu University Press. Oulu, 63-65. KUROSE and ROSS, 2004. Computer Networking: A top-down approach featuring the Internet, 3rd edition, Addison Wesley, 2004. http://kia.etel.ru/lib/Networking/kurose/apps/http.htm. FREEWRL. http://freewrl.sourceforge.net/. GAHEDAN, M. 1998. Scatterplots and scenes: visualization techniques for exploratory analysis, Computers, Environment and Urban systems, Vol. 22, No. 1, 43-56.

GILBERT, H. 2003. The Tragedy of Microsoft and Java, Technology and Planning, Yale University. http://pclt.cis.yale.edu/pclt/mscase/microsoft_java.htm. LIPKIN, D. 1998. VRML Informative Annex, Recommended Practices for SQL Database Access, Oracle Corporation, December 1998. MARANNE, E and VAUCHER, E. 2003. De La formation A L'Action, ING Magazine, No16. Mars-Avril 2003, pp4-7. NEILSON, J. 1994. Usability Engineering, published by Morgan Kaufmann, San Francisco, chapter 5. ISBN 0-12-518406-9. PESCE, M., KENNARD, P. and PARISI, A. 1994. Cyberspace, First International Conference on WWW, Geneva, May. RESSLER, S., Wang, Q., Bodarky, S., Sheppard, C., Seidman, G. 1996. VIM: Using VRML to Access Manufacturing Data, Information Technology Laboratory, National Institute of Standards and Technology. RFC 1945 - Hypertext Transfer Protocol – HTTP/1.0, May 1996. RFC 793 - Transmission Control Protocol, DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION, 1981. RFC 768 - User Datagram Protocol, J. Postel, ISI, 28, 1980. RFC 966 - Host groups: A multicast extension to the Internet Protocol, Network Working Group, S. E. Deering, D. R. Cheriton, Stanford University, December 1985. RANGA, K. and GRAMOLL, K. 1999. Design Education over the Internet using VRML, American Society of Engineering Education (ASEE) 1999 Conference, June 20-23, Charlotte, NC. STOTER, J. and ZLATANOVA, S. 2003. Visualisation and editing of 3D objects organised in a DBMS, Proceedings of the EuroSDR Com. V. Workshop on Visualisation and Rendering, 22-24 January, 2003, Enschede, The Netherlands, 16. THORNE, C. and HAINES, K. 2004. Gateway and Protocol for Modern Cyberspace, Proceedings of the SIGGRAPH 2004 conference on Web graphics: in conjunction with ACM SIGGRAPH 2004: Web Graphics, Session: 3D, Conference CD ROM, Los Angeles, CA, 8-12 August, 2004. THORNE, C. and WEILEY, V. 2003. Earth's Avatar: The Web Augmented Virtual Earth (WAVE), Proceedings of the SIGGRAPH 2003 conference on Web graphics: in conjunction with the 30th annual conference on Computer graphics and interactive techniques, Conference CD ROM, San Diego, CA, 27-31 July, 2003. BERNERS-LEE, T., FIELDING, R., MASINTER, L. 2004. Uniform Resource Identifier (URI): Generic Syntax, http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html. VRML. ISO/IEC 14772-1:1997. The Virtual Reality Modeling Language, Part 1. WEBOPEDIA, http://www.webopedia.com/TERM/H/HTTP.html. WILSON, N., YERGEAU, D. and DUTTON, R. 2000. Internet Based Prototyping of Micro-Electro-Mechanical Systems, International Conference of Computational Engineering & Sciences, Aug. 2000. XJ3D web site, http://www.xj3d.org/. ZLATANOVA, S. 1999. VRML for 3D GIS, ITC, Enshede, The Nertherland. ZOI, S., MELAS, J, KALLIARAS, P. and MITROU, N. 2003. An open framework for the prototyping and delivery of multimedia-rich virtual learning experiences through the internet, WSCG, Vol 11, ISSN 123-6972. _________________________ e-mail: [email protected]

*