Page  00000716 DARRT: Distributed Audio Rendering & Retrieval using Triana - Experiments in applying Grid Computing technologies for audio processing Ian Taylor, Eddie Al-Shakarchi, Stephen David Beck School of Computer Science, Cardiff University Ian.J.Taylor@ cs.cardiff.ac.uk eddie @roughproductions.co.uk Center for Computation & Technology, Louisiana State University sdbeck@lsu.edu Abstract Triana is a Java-based software framework that facilitates computational workflows over networks of Grid enabled computers. The framework enables researchers to automatically find available computational resources, transfer necessary code and data to those resources, process that data, and pass that data to other computational processes on other computers. The advantage of using Grid-enabled computers for audio processing is the unlimited availability of computing resources both in terms of CPU power, and DSP-imposed computational limits. The DARRT project, "Distributed Audio Rendering & Retrieval using Triana," explores the potential uses of Gridcomputing technologies towards sound computation and music synthesis. Our team of researchers is using Triana to control a cluster of 32 Apple Xserve computers in order to demonstrate the potential of distributed audio rendering over a gigabit network. We are developing software objects that will function much like unit generators, software instruments or effects processors that can run simultaneously or in parallel on different machines across a common network. Ultimately, we envision a Web-services or peer-to-peer virtual sound design engine or synthesizer to which anyone on the Web can subscribe, utilize and provide component parts. 1 Introduction The generalized computation of audio signals is limited to either standalone CPU-based computation (i.e., single computer workstations or laptops), or collections of tightlyconnected DSP chip arrays (i.e., Symbolic Sound's Kyma system (Scaletti 2002) or IRCAM's ISPW (Lindemann and Dechelle 1990)). While CPU speeds have long been fast enough to process complex audio applications in real-time, the demand for CPU resources by newer system software has also increased, restricting full availability of the CPU, and limiting the level of computational complexity. The advantage of using off-host DSP farms (no general computing overhead) is offset by cost and physical limitations on DSP expansion. As well, DSPs are also hardware limited both in the complexity of their calculations and the amount of RAM they can access. The past five years have brought significant developments in the realm of Grid computing; that is, the aggregate use of a group of networked computers, leveraging their combined computational power through a coordinated distribution of tasks. Projects like Globus', GridSphere (Novotny, Russell, and Wehrens 2003), and the Grid Application Toolkit (Allen et al. 2003) have advanced Grid computing in computationally-intensive science domains such as numerical relativity and computational fluid dynamics. One project in particular, Triana, has been used in the realm of gravitational wave observation, using computational Grids to process one-dimensional signals using standard digital signal processing techniques. The goal of the DART project is to leverage this technology such that the same kind of DSP processing can be done with audio rate signals. This paper will discuss the background and history of Triana, some of Triana's existing DSP technologies, and some of the applications we have already made to audio-rate signal processing. Finally, we will close with a discussion of our future vision for this project, including the admittedly fanciful notion of peer-to-peer synthesizers. 1http://www.globus.org 716

Page  00000717 Figure 1: A simple audio processing work-flow, showing how a Schroeder reverb is applied to a signal by using a group, which contains the underlying algorithmic details. 2 Triana Triana (Majithia et al. 2004) is a graphical Problem Solving Environment (PSE) for composing data-driven applications. Work-flows (or data-flows) are constructed by dragging programming components, called tools, from the toolbox onto a workspace, and then drawing cables between these components to create a block diagram. Components can be aggregated visually to group functionality and compose new algorithm from existing components. For example, to add a digital Schroeder reverb to a piece of audio (see Figure 1), the file could be loaded (using LoadSound), then passed to a SchroderVerb group unit before being passed to the Play unit to hear the result. The SchroderVerb unit here is itself a group, which consists of a number of summed comb delays and all-pass filters, representing the inner workings of such an algorithm. Within Triana, a large suite of Java tools exist in a range of domains including signal, image and text processing. The signal processing tools are the most advanced as Triana was initially developed for signal analysis within the GEO600 gravitational wave project (GEO 600 Project 2004), who use the system to visualize and analyse one-dimensional signals (rather like an audio channel but sampled at a lower rate). Therefore a number of core mathematical, statistical and high-quality digital-signal processing algorithms already exist (around 300 signal processing and visualization units). 3 P2P and Grid Computing Technologies In the recent years, there has been an explosion of applications using peer-to-peer and Grid-computing technology. On the one hand, P2P has become ingrained in current grassroots Internet culture through applications like Gnutella2 and SETI@Home3. It has appeared in several popular magazines and frequently quoted as being crowned by Fortune as one of the four technologies that will shape the Internet's future. The popularity of P2P has spread through to academic and industrial circles, being propelled by media and widespread debate both in the courtroom and out. However, such enormous hype and controversy has led to some mistrust of such technology but in fact in reality, there is significant substance, especially relating to dynamic discovery, scalability and fault tolerance. In parallel, there has been a much academic and industrial interest in Grid computing, which is attempting to build the infrastructure to enable on-demand computing in a similar fashion to the way we access other utilities now, e.g., electricity. Further, the introduction of the Open Grid Services Architecture (OGSA) (Foster et al. 2002) has aligned this vision with the technological machine-to-machine capabilities of Web services. This convergence has gained a significant input from both commercial and non-commercial organizations and has a firm grounding in standardized Web technologies, essential for the ultimate goal of ubiquitous deployment. 3.1 Switchable Distributed Interfaces Triana takes advantage of these distributing systems technologies by integrating the Grid Application Toolkit (GAT) (Allen et al. 2003) and its peer-to-peer subset, called the GAP (Taylor et al. 2003). These interfaces provide applicationlevel capabilities for a number of different types of middleware. So, for example, within a Grid computing scenario, Triana could use the GAT's Globus GRAM (Grid Resource Allocation Manager) binding to execute applications on distributed resources or similarly it could use Jxta4 or P2PS (Wang 2005) discovery and pipe mechanisms to discover and communicate with peers in a P2P environment. 3.2 Grid Computing and the GAT The GAT interface provides application-level capabilities along with adapters that adapt these capabilities to the low level mechanisms, provided by the middleware e.g. Globus, 2http://gnutella.wego.com/ 3http://setiathome.ssl.berkeley.edu/ 4http://www. jxta.org/ 717

Page  00000718 Condor (Frey et al. 2001) etc. Within Triana we interface directly to the Java implementation of the GAT, which provides us with various capabilities, in particular, job submission (using GRAM, Condor or GRMS5) and file services, such as GridFTP for high speed Internet file transfer. The user effectively interacts using the standard Triana unit (component) and connection (cable) paradigm, where any unit (or group unit) can be submitted as a Job and the cables represent file movements to and from resources. In a sense, Triana is a graphical interface to the GAT and allows extremely user-friendly programming of Grid technologies. Further, Triana has implemented proxy units to generic job description interfaces so that legacy applications can be run locally or remotely by interacting with stdin/stout and/or file input and output. In this fashion, third party applications can be integrated within Triana workflows and distributed across the Grid. 3.3 P2P and Service-based Computing using the GAP The Grid Application Prototype Interface (GAP Interface) is a simple interface for advertising and discovering resources, and pipe based communication within dynamic service-oriented networks. It provides bindings to three different infrastructures: P2PS - a lightweight P2P middleware capable of advertisement, discovery and virtual communication within adhoc P2P networks. P2PS has a subset of the functionality of JXTA but is tailored for simplicity, efficiency and stability. Web Services - this allows applications to discover and interact with Web Services using the UDDI registry (UDDI 2000) and the Axis SOAP Engine (Apache 2005). Jxta - Jxta6 is a set of protocols for P2P discovery and communication within P2P networks. For distribution across dynamic networks, we use the P2PS binding. Peer to Peer Simplified (P2PS) (Wang 2005) came into being as a response to the complexity and overhead associated with Jxta. As its name suggests, it is a simple yet generic API for developing peer-to-peer systems.q P2PS encompasses intelligent discovery mechanisms, pipebased communication and makes it possible to easily create desirable network topologies for searching, such as decentralised ad-hoc networks with super peers or rendezvous 5http: / /www. gridlab. org 6http: //www. jxta.org/ Job Submission, File services A Graphical Grid Computing Environment or Portal D~eployment, discovery and -E-~~ ~ communication w Wlwith distributed services e g. P2P and (GSI) Web Gridvices e........................................................................................................................................................................................... El E.] Ed El............................................ Ea....................................................................................................................................... E l............. H E l Figure 2: An overview of the distributed architecture of Triana and its interaction with the GAT and GAP interfaces. nodes. P2PS is designed to cope with rapidly changing environments, where peers may come and go at frequent intervals. At the core of P2PS is the notion of a pipe: a virtual communication channel that is only bound to specific endpoints at connection time. When a peer publishes a pipe advertisement it only identifies the pipe by its name, id and the id of its host peer. A remote peer wishing to connect to a pipe must query an endpoint resolver for the host peer in order to determine an actual endpoint address that it can contact. In P2PS a peer can have multiple endpoint resolvers (e.g. TCP, UDP etc), with each resolving endpoints in different transport protocols or returning relay endpoints that bridge between protocols (e.g. to traverse a firewall). Also, the P2PS infrastructure employs XML in its discovery and communication protocols, which allows it to be independent of any implementation language and computing hardware. Assuming that suitable P2PS implementations exist, it should be possible to form a P2PS network that includes everything from super-computer peers to PDA peers. In terms of the GAP Interface, a binding between the GAP and P2PS is implemented that allows P2PS to be used via the GAP Interface. This means that it is possible to seamlessly use applications developed on top of the GAP Interface in a P2PS or Web services network just by switching the GAP binding used. Triana uses this implementation for all of its service-based communications and this forms the basis of its unit or group distribution. An overview of how the GAT and GAP interfaces are used within Triana is given in Figure 2. Here, we illustrate that the GAT is used for course-grained Grid computing services, whereas service-based communication is accomplished by the GAP and its bindings. The GAP also is 718

Page  00000719 used to provide the fine-grained distribution mechanisms for running its Java units remotely as services or as collections of services. This is described in the next section. 4 Distributing Triana Units or Groups Triana units or groups of units can be conveniently distributed to a number Triana launcher services, according to a distribution policy. A Triana Launcher Service is a GAPbased service that, when sent a workflow subsection (serialized in XML) via its control pipe, uses the GAP Interface to launch that subsection as a new Triana service. The actual form the Triana Launcher Service and the new Triana services take depends on the GAP binding employed; for example, if the Web Services/GAP binding is used then both the Triana Launcher Service and the new Triana services are created as Web Services. Units or Groups can be distributed in two ways, as: * Static Services: where the launcher creates a service which consists of the unit(or group) which is being distributed. A service is created and remains fixed at that endpoint. This could be used to create and deploy a Web service that plays audio for example. * Dynamic Services: are Triana launcher services that can dynamically execute sub Triana workflows. They are network-facing XML processors, which can be passed various different workflows for execution. In this way you can reuse the distributed Triana launchers for different tasks as and when required. Typically, executing a single service in a distributed fashion, e.g. sending the Play unit to another device for playback of the audio, would be achieved using a static service. This is because the functionality is located in a single place on the distributed network. However, if you wanted to distribute the audio to tens of distributed Play units for simultaneous playback in a spatially distributed sense, the the dynamic services would be used in conjunction with a distribution policy. The distribution policy specifies how the unit or group of units is distributed across the resources. We have two schemes implemented: pipeline and high-throughput. In the pipeline case, the Java processing units would be spliced vertically and distributed across the resources. So, for example, if the group consisted of five connected Java units and there were five resources then a unit would be placed on each resource and connections made between them. More commonly however, the high throughput mechanism is used to distributed the units horizontally; that is, a copy of the entire group is placed on each resource and data divided amongst them. In this fashion, you could for example, process computationally intensive tasks by splitting the audio stream into pieces and sending them to the same algorithm located across the distributed network for faster processing. You could also trigger remote synthesizers to generate complex audio for playback locally. In experiments so far, discussed in section 6, we have used both mechanisms. For the remote sound play, discussed in section 6.1, we used both the static and dynamic deployment mechanisms, whilst for the distributed computation (in section 6.2), we used the dynamic mechanism, using the highthroughput distributed policy. 5 Audio Processing in Triana Triana integrates both Grid and P2P technologies and has been used in a number of domains, from bioinformatics, investigating biodiversity patterns7, to gravitational wave observation, using computational Grids to process onedimensional signals using standard digital signal processing techniques (GEO 600 Project 2004). The goal of our project is to leverage this technology such that the same kind of DSP processing can be achieved with audio rate signals for the purposes of signal analysis, feature extraction, synthesis, and Music Information Retrieval (MIR). Given its modularity, its support for high quality audio, and its ability to distribute processes across a Grid of computers, Triana has the potential to be a vital piece of software that allows users to implement custom audio processing algorithms from their constituent elements, no matter their computational complexity. The Triana audio toolkit consists of several categorized hierarchical folders, each with an assortment of units based on the MultipleAudio Triana data type. This type utilises the JavaSound API classes in order to allow the use of high fidelity audio inside of Triana. The Audio toolkit tree is split into three main folders: Input, Output, and Processing. 5.1 Input Tools The audio input section houses one of the most important tools for Audio in Triana - the LoadSound unit. This unit allows the user to select an audio file (Wav, Aiff, Au) and outputs the data to the next unit. The user can select if the audio file is to be output in its entirety, or if the data should be streamed on to the next unit by chunking the data into fixedlength segments. 7The Biodiversity World project for collaborative exploration and analysis of global biodiversity patterns. See web site at: http://www. bdworld.ora/ 719

Page  00000720 Figure 3: A screenshot of the WaveViewer unit from the Audio/Output folder, displaying a waveform. 5.2 Output Tools The output tools section contains a varied collection of tools to allow the user to hear - and see - the audio data loaded into Triana, allowing for thorough analysis of the sounds. The Play unit is one of the most often used in this section, and allows the user to play back the audio file (both streamed, or as one large file). Triana gives the user a useful selection of other output tools, such as the WaveViewer unit (see Figure 3), which shows the current waveform with a time-amplitude relationship. This allows for a much more thorough analysis of the audio. Also included in the Output section is a group of audio writing tools (such as WriteWav, WriteAiff) that are currently in development, to allow the user to (re)save the audio after any amount of processing in Triana is complete. 5.3 Audio Processing Tools The audio processing tools in Triana form the core of its audio manipulation capabilities. Inside the audio processing toolkit is another level of categorised folders, covering a wide range of applications: Converters: for converting between audio formats and for separating stereo streams into two independent channels and vice versa. Delay: single delays, all pass filters and comb delays. Distortion: distortion algorithms and fuzz boxes. Dynamic: compressors, limiters and expanders. EQ: low pass, high pass and parametric EQ (in progress at present). Modulation: chorus, flanger, phaser and variable delays. Reverb: Schroeder verbs, and various presents from small rooms to large concert halls. Signal Analysis: FFT analysis for use in spectral processing, analysis/resynthesis, and signal analysis for music information retrieval Tools: faders, resampling modules, wave inverters, rectifiers and reversal algorithms. UserPresets: combinational effects (i.e. group units) encompassing several of the above algorithms with particular settings e.g. distorted flangers, exuberant reverbs, etc. The categories should be recognizable to regular users of audio processing or production software. Each folder contains units which are in themselves effects but also allow the user to create their custom algorithms from the smaller building blocks supplied with Triana. It is possible to break down complex algorithms into a group of functions (units) that when linked together in a particular fashion, are able to perform the task as a whole. This has been demonstrated earlier, with an example of grouping the comb and allpass filters in order to create a Schreoder Reverberator algorithm, which is then grouped, saved and reused as if it were a single unit. This unit aggregation gives the user more freedom to take advantage of Triana's modularity. One feature of interest resides in the Converters Folder; two units are available that allow the user to convert from MultipleAudio to a SampleSet Triana data type - and back again (MAudioToSSet and SSetToMAudio respectively). This opens up a whole range of possibilities to the user as they can now utilise many of the math and signal-processing units (of which there are hundreds!) to process the audio, and then convert data back to a MultipleAudio data type for playback. One example of how this technique could be used is given in Figure 4. Here, a Stereo2Mono unit (also in the converters folder) is used to split the stereo channels of an audio file or stream into two distinct mono channels. Each side is then converted to a SampleSet and fed into a Subtractor unit from the Math folder. This subtracts the left from the right stereo channel, which results in the removal of any sounds that is contained in both i.e. those panned in the middle of the stereo field. This is a simple way of removing vocals from many songs and leaving the (majority) of the backing track (because vocals in particular are normally panned down the centre). This is just a simple example of how a few of the Converter units could help users create their own algorithms. It must be remembered that the user is encouraged to try create different algorithms themselves, and experiment with different unit connection chains - and not only using the presets given in Triana. 720

Page  00000721 Figure 4: Audio is split and converted to a SampleSet data type, in order to subtract all music which is panned down the middle of the stereo field. This conversion is then reversed and played back The tools included in Triana are all high fidelity and work at 32-bit internally for extra sample accuracy. 5.4 Potential Users Triana, and specifically Triana as a audio processing tool, has a wide potential user base. The toolkit is aimed for use by: * Audio professionals and hobbyists who wish to create their own custom audio processing algorithms to import and process their data in Triana for a higher degree of control of customisability. Data could be imported into Triana, processed with the users algorithm of choice, and then exported back out and into their music sequencer. Much like other graphical programming audio programs (Max/MSP, Kyma, Tassman), musicians and engineers can experiment with new and innovative signal processing algorithms without having to be computer scientists or programmers. * Audio processing software/hardware developers/programmers who use Triana as a sketchpad for creating algorithms that could be incorporated into their own application at a later date. The developers could use Triana to acquire ideas the customised algorithm they require, then once the sound they wanted to create has been achieved, the algorithm could be ported into the programming language of their choice. Triana gives users the ability to save their algorithms as a grouped unit, or export as an application in its own right. * Scientists interested in the analysis of sound. For example, scientists researching into the development of spatial modelling algorithms. Triana has many uses, and the units created in the audio toolbox are not restricted to be used only for only musical applications. Already included in the Triana application are a variety of units which will work with units provided by the audio toolkit. For example it is possible to perform a Fast Fourier Transform on the audio data and convert the data into a SampleSet type, allowing for the audio to be viewed in the frequency domain using relevant graphers provided by Triana. This data can then be manipulated in numerous ways. * Programmers who wish to expand upon the audio toolkit in the future. For this reason the units must be logically designed. * As a tool to teach students about Digital Signal Processing. Due to the way Triana displays algorithms graphically - and in a very similar manner to the signal flow diagrams used in DSP fields, students could use Triana to directly hear the outcome of manipulating algorithms and signal flows, and make learning a much more practical and realistic process. Work is ongoing in Triana to continually build and develop its audio capabilities, create new units, and further develop and refine the audio engine. With Triana's ever expanding distributed processing capabilities, there is potential to create an even more powerful distributed audio processing system with Triana. 6 Current Achievements At the time of this paper's writing, our team has successfully run a number of tests demonstrating the viability of DARRT. Though modest, these initial trials have provided a proof-of-concept model, and encouraged us to continue with the project. 6.1 Remote Sound Play In our first proof-of-concept model, we streamed audio files over a network to Triana clients running on separate computers, which then played the file locally. We used Triana's service discovery interface to identify available peers on a wireless network. In one experiment, our Triana patch then uploaded a sound file, distributed the file to the network peers, and then played the sound directly on each network peer, using the dynamic distributed mechanism, described in section 4. Aside from running the peer service, the control 721

Page  00000722 of the networked computers was managed entirely by Triana. Applications of this particular demonstration could include intelligent sound distribution systems that utilize any available computer network. These systems could be deployed for electroacoustic concerts, museum installations, or home audio systems. Our application used both wired (100BaseT) and wireless (802.11b/g) networks. In the second experiment, we used the static deployment mechanism simultaneously across fifty laptops. During a Triana tutorial, we asked the participants to use the Triana discovery mechanisms to dynamically discover other devices on a wireless network. Each device ran as a peer, being both a client and a server. Each user then chose a random device then statically deployed the Play unit on that device. The result was that various sound files were played simultaneously on random machines in around the room! Although, this scenario is somewhat jovial, the underline mechanisms demonstrate a powerful tool for distribution in ad-hoc networks, where there are many uses. Another use here would be for aggregating devices on a home network as and when they join e.g. when you open your laptop and connect wirelessly to the network. 6.2 Distributed Audio Computation Our second proof-of-concept test distributed audio computation and playback across our 24-machine computer cluster. To this end, a signal processing flow was laid out in Triana (see figure 4 ) and then aggregated as a single process. This process was then distributed across available peer clients on the cluster. Running the application, the sound file was loaded onto the local machine, split into consecutive chunks, with each chunk sent to an available client for processing. The processed sound chunks were then returned to the local machine, and played back through the local host's sound output. The entire process was completed such that the playback of the sound was achieved without any audible latency. The success of the audio processing lies in the segmentation process that divides input sounds into chunks. Included with the chunks of audio are pre- and post-chunk windows of sound data. This insures that the data context for each sound chunk is maintained as if it were a continuous stream of audio data. 6.3 Music Information Retreival Triana is currently being applied as the front end to a project for creating a decentralized peer-to-peer MIR framework, which facilitates the analysis of the music files on each peer and retrieves results for comparison and analysis. The underlying framework is similar to BOINC8 but employs a decentralised architecture and allows the execution of Triana workflows on the distributed resources, which will be capable of analysing information and data from music files (mp3/wav/aif) available on the users' hard drives. We are investigating many index based and content based techniques, including statistical correlations of song names to extract commonalities in order to make future recommendations for users in search of new music genres. Further, we are investigating content-based analysis of the audio files, such as searching for the track tempo, timbre, pitch, mood, frequency range, etc, and generate histograms containing the results. Although the project is in early stages, the underlying decentralized peer to peer framework (P2PS (Wang 2005)) and distributed execution of workflows has been developed and we are in the process of customizing this for our audio and statistical analysis components. 7 Future Directions The future for distributed computing for audio looks strong. The most recent version of Logic Audio now includes distributed rendering capabilities, and our initial experiments with Triana demonstrate the potential for such processing across both ideal and non-ideal environments. Our roadmap for future development of DARRT begins with the adaptation of computationally intensive FFT-based processing algorithms, the inclusion of more tools for MIR applications, and the development of aggregated functions of complex signal processing for use by composers. Furthermore, we will begin to explore the potential of mounting such signal processing algorithms on remote computers using a web services or peer-to-peer model. In doing so, we can create a distributed signal processing environment to which users can subscribe to and utilize DSP processes as they are needed, in a modular fashion. 8 Acknowledgements This project is the result of an extended collaboration between the Center for Computation & Technology at LSU, and the Cardiff University. Special thanks go to the Triana development team at Cardiff, (Ian Wang, Matthew Shields, Eddie Al-shakarchi) and the DARRT team at LSU (Brian Willkie, Joseph Patrick). 8Berkeley Open Infrastructure for Network Computing. http:// boinc.berkeley.edu 722

Page  00000723 References Allen, G., K. Davis, K. N. Dolkas, N. D. Doulamis, T. Goodale, T. Kielmann, A. Merzky, J. Nabrzyski, J. Pukacki, T. Radke, M. Russell, E. Seidel, J. Shalf, and I. Taylor (2003, November). Enabling Applications on the Grid: A GridLab Overview. International Journal of High Performance Computing Applications: Special Issue on Grid Computing: Infrastructure and Applications 17(4), 449-466. Apache (2005). Apache Web Services Project - Axis. See website at http: //ws.apache. org/axis/. Foster, I., C. Kesselman, J. Nick, and S. Tuecke (2002). The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. Technical report, Open Grid Service Infrastructure WG, Global Grid Forum. Frey, J., T. Tannenbaum, M. Livny, I. Foster, and S. Tuecke (2001). Condor-G: A Computation Management Agent for Multi-Institutional Grids. In Proceedings of the 10th IEEE International Symposium on High Performance Distributed Computing (HPCD-'01). GEO 600 Project (2004, June). GEO 600 Homepage. See website athttp://www.geo600.uni-hannover.de/. Lindemann, E., S. M. and F. Dechelle (1990). The IRCAM Musical Workstation: Hardware overview and signal processing features. In Proceedings of the 1990 International Computer Music Conference, San Francisco. International Computer Music Association. Majithia, S., M. S. Shields, I. J. Taylor, and I. Wang (2004). Triana: A Graphical Web Service Composition and Execution Toolkit. In Proceedings of the IEEE International Conference on Web Services (ICWS'04), pp. 514-524. IEEE Computer Society. Novotny, J., M. Russell, and 0. Wehrens (2003). GridSphere: A Portal Framework for Building Collaborations. In 1st International Workshop on Middleware for Grid Computing (at ACM/IFIP/USENIX Middleware 2003). Scaletti, C. (2002, Winter). Computer music languages, Kyma and the future. Computer Music Journal 26(4), 69-72. Taylor, I., M. Shields, I. Wang, and 0. Rana (2003). Triana Applications within Grid Computing and Peer to Peer Environments. Journal of Grid Computing 1(2), 199-217. UDDI (2000, September). UDDI Technical White Paper. Technical report, OASIS UDDI. Wang, I. (2005, February). P2PS (Peer-to-Peer Simplified). In Proceedings of 13th Annual Mardi Gras Conference - Frontiers of Grid Applications and Technologies, pp. 54-59. Louisiana State University. 723