1

NaradaBrokering Video and Chat Services

Mark Baker and Rahim Lakhoo

Distributed Systems Group University of Portsmouth

{Mark.Baker@computer.org, Rahim.Lakhoo@port.ac.uk}

Date: 6th January 2005

1. Introduction...............................................................................................................................................2 2. The Development Technologies...........................................................................................................2

2.1 Introduction.........................................................................................................................................2 2.2 GridSphere .........................................................................................................................................3 2.2 NaradaBrokering .............................................................................................................................5 2.3 The Java Media Framework (JMF) ...............................................................................................6

3. The NaradaBrokering Chat and Video System..............................................................................8 3.1 System Architecture.........................................................................................................................8 3.2 The Chat Portlet .............................................................................................................................11 3.3 The Video Portlet ...........................................................................................................................12 3.4 The NaradaBrokering Portlet Service ......................................................................................13 3.5 The Userl ist Portlet Service.........................................................................................................13 3.6 The JMF Applet ...............................................................................................................................14 3.7 Summary............................................................................................................................................14 3.8 Further Comments ...........................................................................................................................15

4. The NaradaBrokering Chat and Video System Tria ls ...............................................................15 4.1 Introduction.......................................................................................................................................15 4.2 The Experiment................................................................................................................................15 4.3 Summary............................................................................................................................................18 4.4 Further Comments ...........................................................................................................................18

5. The Portlet and Service Development and Deployment .............................................................18 5.1 Introduction.......................................................................................................................................18 5.2 NaradaBrokering ...........................................................................................................................18 5.3 GridSphere .......................................................................................................................................19 5.4 JMF ......................................................................................................................................................20

6. Summary and Conclusions....................................................................................................................20 6.1 Summary............................................................................................................................................20 6.2 Conclusions........................................................................................................................................21

References....................................................................................................................................................22

2

Abstract This report discusses the design, development and testing of portlets and services that were used to build a NaradaBrokering-based chat and video conferencing system. Extensive experience gained while developing this collaborative system, have led us to believe th a t i t best to freeze its development, and wait until the various technologies that it rel ies on to become more stable and robust. 1. Introduction The Distributed Systems Group (DSG) at the University of Portsmouth is one of four partners involved in the Sakai VRE Demonstrator Project that is led by the University of Lancaster [1]. The DSG’s contribution to the project is to explore and develop a number of prototype portlet tools and services that can enhance the user’s experience. In particular, the DSG is working on collaborative, semantic and peer-to-peer tools and services. One particular set of services that the DSG has been developing is the NaradaBrokering-based chat and video conferencing system. It is intended that the system will a id users of the VRE to collaborate and interact from a portal level. The prototype system will a l low participants to join and correspond in chat rooms and start up video conferencing sessions with multiple participants. The chat room service emulates the popular Internet Relay Chat (IRC)[2], which is a wel l established on the Internet. GridSphere [3] was the chosen Portal container and development framework, in which the portlet was to be developed. NaradaBrokering [4] was used to provide the backend messaging middleware, and the Java Media Framework (JMF) [5] al lowed for video capture. The transport of real-time audio and video data was via Real- time Transport Protocol (RTP) sessions that were provided by JMF on the cl ient side and Global-MMCS [6] on the server side. The rest of the report is organised as fol lows. The development technologies used are discussed in section 2. In section 3 we describe the NaradaBrokering Chat and Video System in depth. Wh i le section 4, we outl ine and detail the testing and evaluation of the system developed. Section 5 summarises the development and deployment issues that were encountered. Finally, in section 6, we summarise and make a number of conclusions about the work carried out. 2. The Development Technologies 2.1 Introduction The development strategy of the DSG for this project is based on complying with the JSR-168 portlet standard [7], with the rationale that Sakai [8] and the other portal frameworks a l l support or intend to support this API. This section of the report outl ines the various technologies that were used to develop and test the NaradaBrokering chat and video services. The choice of technologies used to develop and host the chat and video services are to a certa in degree fixed, and to an extent are based on our need to rapidly develop and explore the capabil i ties and issues that may present themselves. All the technologies associated with th is development, specif ical ly, NaradaBrokering, GridSphere, JMF and JSR-168 portlets, are al l Java-based. This provides portabil i ty, interoperabil i ty and aids rapid development of the portlets and accompanying services. The capabil i ties of NaradaBrokering were a lso an area of investigation, as it is an open source JMS-compliant brokering system, with e-Science Programme funding too. NaradaBrokering provides an array of features, some of which are relevant to our development, such as software multicasting. GridSphere is a JSR-168 compliant portal

3

container and development framework, which is actively supported; it also provides a range of user and portal management services. Web-based real- time graphics are sti l l problematic when being rendered within a Web browser. The tried and tested Java Applet is sti l l the only simple and easi ly deployable method to accomplish this. JMF is the only Java-based framework offered by Sun Microsystems for interfacing Java with multimedia capabil i ties, such as audio/video streaming or MP3 audio playback. 2.2 GridSphere GridSphere provides a JSR-168 compliant platform for developing portlets. GridSphere is based on IBM’s WebSphere [9], as its name implies. Its original development was motivated by the need to provide an open-source portal to support Grid enabled portlets and services. GridSphere is Java-based and is thus compatible with any operating systems where there is a compliant JVM. GridSphere uses Apache Jakarta’s Tomcat [10] as its application container. The core framework’s standard API are community based and makes the use of design patterns, namely Model View Controllers (MVC) to separate the logic from the presentation layers Error! Reference source not found.. Core portlets and portlet services are bundled with GridSphere: these a l low the administration and deployment of portlets and users al ike. GridSphere is available in two different formats, for UNIX-based and Windows platforms. Apache Ant [12] is required to instal l GridSphere, a long with Apache Tomcat. The instal lation of Apache Tomcat is a prerequisite and the environment variable CATALINA_HOME must a lso point to Tomcat’s location. The tomcat-users.xml fi le must be updated to include the “gridsphere” user, so that GridSphere has the rights to manage applications as needed. Once the source has been unpacked, the command ant install wil l build and instal l the system. GridSphere detects the location of Tomcat and places the instal lation and database in the webapps directory of Tomcat. A successful insta l lation wil l result in GridSphere appearing as per Figure 1.

Figure 1: The default GridSphere login prompt

4

After user authentication has taken place, a set of portlets are displayed, as shown in Figure 2, al lowing users or administrators al ike to customise their environment. The most useful section, from a users perspective, is the portlet group membership, which a l lows users to subscribe to different portlets or groups of portlets.

Figure 2: The GridSphere login page

The use of GridSphere, as a portlet development framework, is based on our experience over the last eighteen months. The choice of framework used should have l i ttle affect on the portlets that are produced, as long as they are JSR-168 compliant. Apart from the deployment phase, the portlets in this project comply with JSR-168. To develop portlets under GridSphere the original insta l lation source, from which GridSphere was built, is needed to build a new portlet project1. The command ant new-project wil l create a skeleton for the portlet project. The ant script asks whether the portlet is to be a GridSphere/WebSphere or JSR compliant portlet, in which case JSR is chosen. Within the GridSphere projects directory, a new directory is created with the skeleton portlet, including Ant build scripts and sample XML fi les. Inside the skeleton portlet, the src directory must include portlets and optionally services in the package path, for GridSphere to correctly load a portlet. All of the portlet’s front-end presentation layouts are coded in Java Server Pages (JSP)[13], located under Tomcat’s webapps directory. GridSphere provides UI Tags that are JSR-168 compatible; these tags are placed in the JSP pages and can be accessed from the portlet source code. This provides an easy and simple mechanism to interface with GUI components. GridSphere configures the three JSR-168 modes by default, view, edit and help. The edit mode al lows the user to customise any settings available, while the view mode is the default view for the portlet. However, custom modes, which are portal dependent, may be described in the portlet.xml fi le. GridSphere provides both WebSphere and JSR-168-based portlets with the abil i ty to util ise portlet services. Portlet services could be ordinary Java classes, as the source code of GridSphere reveals. However, services used for the development and testing of portlets 1 There is a dependency in the template that refers back to the source code – a jar fi le is needed. This dependency can be overcome by editing the build properties fi le.

5

within GridSphere have certa in advantages. Portlet services can encapsulate the core logic and functionality of a portlet. This not only minimises the size and complexity of portlet’s source code, but also provides a reusable l ibrary that other portlets may access. Other advantages include, a built- in persistence manager to ease the seria l isation of objects and built- in access control, for role based “secure services”. The main advantage for development is the easy integration of a testing framework to support the production of JUnit tests [14]. Portlet services can be transformed into normal Java classes. Once the portlet is ready to be deployed, the command ant deploy is issued from the project’s directory. The portlet wil l now be accessible from the GridSphere instal lation located in Tomcat. The portlet may also be deployed via the GridSphere Portlet Application Manager GUI, a lthough the portlet must be packaged into a WAR fi le. The Ant build script target war must be executed, from the project’s directory, instead of using the target deploy. uPortal [14] is our second portal framework that is being used for testing the portlets th at are developed; it is another open source portal project, which also supports JSR-168 compliant portlets. Even though uPortal was originally used as an underlying framework for the Sakai Project, it does not natively support JSR-168 portlets. uPortal 2.3 supports JSR-168 through a Portlet-to-Channel adapter [16], a lthough support is planned for with uPortal release 3.0 and will be managed by Apache’s Pluto [17]. Currently, uPortal 3.0 has not been officia l ly released. One aspect of uPortal that is sti l l less than desirable is th a t the management of users is not available via the Portal i tself; instead, command line directives must be issued on the host executing the server. The instal lation of uPortal is similar to that of GridSphere, although an instance of HSQL database [18] version 1.7.x is an external dependency. The HSQL database must be configured to use port 8887, for uPortal. To deploy portlets under uPortal, they must be packaged into a WAR f i le. WAR fi les may only be instal led from the libs/portlets directory, under the uPortal source, which can only be located on the server itself. Apache Ant is used to instal l portlets with a command ant deployPortletApp –DportletApp=all. This command will instal l a l l portlets found in the libs/portlets directory. Individual portlets can be instal led by replacing all, with the location of a WAR fi le. uPortal l ike other Portals, modifies the portlet’s XML fi les to suit i ts own implementation, this process then becomes a configuration or insta l lation instead of a deployment. The steps to migrate portlets, which uti l ise GridSphere UI tags, to Apache Pluto and other portals can be found elsewhere [19]. The differences between a portal’s deployment of portlets is concerned with the differences within the XML fi les and the packaging of UI tag dependencies. GridSphere provides an intuitive development framework, which many other portals frameworks lack. Having a portal without the capabil ities to develop portlets with in i t makes the developer’s task harder. uPortal for instance, wil l only accept packaged WAR fi les, and does not provide any support to create new portlet projects; thus requiring a separate development environment, such as Eclipse [20]. In addition, the GUI provided by GridSphere is extensive, al lowing a range of administrative tasks to be accomplished, without needing access to the GridSphere’s Ant scripts. 2.2 NaradaBrokering The NaradaBrokering project has been underway in the Community Grids Lab at Indiana University [21] for the past four years. The project is a lso part funded by the UK e-Science Open Middleware Infrastructure Institute (OMII) as part of its managed programme [22]. Although originally designed to provide software multi-casting for real-time collaboration, it now aims to provide a unified messaging environment that incorporates the capabil i ty to support the Grid and Web Services, Peer-to-Peer and video conferencing[23].

6

NaradaBrokering is Sun JMS compliant (version 1.02.b) [24][25]. This messaging standard al lows application components to exchange standardised messages within an asynchronous environment. The JMS specif ication is used to develop Message Orientated Middleware (MOM) and defines how messages are to be communicated via queues or topics. NaradaBrokering also provides a variety of transport protocols including HTTP, TCP, NIO/TCP, UDP, and SSL. NaradaBrokering is an asynchronous messaging infrastructure with a publish, subscribe and bind-based architecture. Networks of collaborating brokers are arranged in a cluster topology, with a hierarchy of clusters, super-clusters, and super-super-clusters [26]. Each broker is assigned a logical address within the network, which corresponds to its location and contains a Broker Node Map (BNM) for the calculation of routes, based on broker hops. The NaradaBrokering transport framework provides the capabil i ty for each l ink between brokers to implement a different underlying protocol [27]. The security framework with in NaradaBrokering incorporates an encryption key management structure, supporting a variety of algorithms, for topics, publishers, and subscribers [28]. A built- in performance aggregation service can monitor l inks originating from a broker and typically displays values for the average message [29] delay, latency, jitter, throughput, and loss rates. Audio and video conferencing is accomplished with the a id of the Real-Time Protocol (RTP) [30][31] and JMF. Support for JXTA Peer-to-Peer [32] end-points communicating over the broker network is propagated though a proxy [33]. With in NaradaBrokering, topics can be defined as string based, and they can be coupled with SQL l ike queries, tag=value pairs, integer based, or XML based with XPath queries. Subscriptions are organised in a hierarchical fash ion, whereby brokers store client subscriptions, and super-cluster nodes, a lso known as cluster controllers, record broker subscriptions. Subscribers implement a MessageListener, which is invoked by the broker upon receipt of a message, providing asynchronous delivery of messages. The body of a message may match one of five types, Stream, Map, Text, Object, or Bytes message. Events in NaradaBrokering are defined as time stamped messages, the broker responds to these events and routes them to the appropriate endpoint [34]. 2.3 The Java Media Framework (JMF) The Java Media Framework was developed by Sun Microsystems and provides an interface for Java applications to interact with media or time sensitive data. JMF functionali ty includes codecs and protocols, such as Quick Time movies, MP3 playback and Real Time Protocol support. JMF can capture, transmit, or receive video or audio from various sources, such as a Web-cam or microphone. When combined with the RTP support it can host multicasting video transmissions. JMF is available in two main formats, the Performance Pack and the Platform Independent version. The Performance Pack is only available for three operating systems, Windows, Linux and Solaris; this version offers native l ibraries for interfacing with capture devices and codecs. The platform independent version, does not support capturing video from devices, but does a l low capturing audio. This pure Java version of JMF may receive some media streams for playback, a full l ist of capabil i ties can be found in [35]. Even though the Performance Pack of JMF can support video capture, the under lying OS must have compatible drivers and devices instal led. JMF comprises of four main components, which are metaphors for video players and output displays [34]. These are, the CaptureDevice, DataSource, Player and Destination. The DataSource encapsulates the media stream, wh ile the Player provides processing and controllers. Obviously, the Destination is the output or display and the CaptureDevice is a camera or input device. Figure 3 shows JMF’s architecture;

7

DataSources and Players are integral components of the Presentation and Processing API layer.

Figure 3: High-Level JMF Architecture

JMF can transmit time sensitive data. This is ach ieved by using the RTP, which is independent of any underlying transport protocol and thus to implement an RTP session with JMF, RTPSockets are required. RTPSockets have two channels, one for data the other for control messages, both channels are bi-directional. A SessionManager is responsible for extracting RTP packets from the RTPSockets and a Player is used to actually present the stream at the Destination. The H.263 ITU-I standard for video compression, a l lows for medium quality, low-bitrate video conferencing. It was designed to be usable with bandwidth as low as 20-24 bit/s [37]. H.263 streams are transported over RTP, enabling multicast audio/video conference sessions. H.263 improves on its predecessor H.261, with four, additional performance related options namely, Unrestricted Motion Vectors, Syntax-based arithmetic coding, Advance prediction, and forward and backward frame prediction. JMF supports this standard amongst other popular video/audio compression formats. JMF is bundled with a three useful tools, jmstudio, jmfinit and jmfregistry: • jmfinit is a command line util i ty used to initia l ise and search for any devices

attached to the system. • jmfregistry, configures a properties fi le, jmf.properties, which contains al l of

the devices and settings for a JMF application. • jmstudio is a reference application that includes most of JMF’s capabil i ties, such as

capturing devices, transmitting streams and playing video fi les. This application is a lso a useful tool for testing compatibil i ty with hardware or operating systems.

The instal lation procedure for JMF is dependent on the version; the Performance Pack has additional steps if it is not being instal led on Windows. To instal l JMF on Linux the jmf.jar fi le must be placed on the Java classpath. This is the only step required to instal l JMF with the Platform Independent version. The loading of native OS l ibraries is the next challenge. The JMF support documents state that to export the LD_LIBRARY_PATH variable with the location of the JMF l ibraries ($JMFHOME/lib), however it has unpredictable results. It was found more rel iable to add the location of the native libraries to /etc/ld.so.conf. A diagnostics Applet is available for testing the instal lation. JMF allows developers to incorporate time-sensitive media into their Java applications or Applets. It a lso lays the foundation for other Java frameworks such as JavaTV, which is designed to support interactive television services. For our purposes, JMF is the only Java framework, which offers the capabil i ty to interface to a Web-cam and display video streams via a Web browser.

8

3. The NaradaBrokering Chat and Video System This section discusses the architecture of the NaradaBrokering Chat and Video system. This is followed by an outl ine of the individual parts of the application. The design decisions wil l be explained for the chat and video portlets, the NaradaBrokering and Userl ist service as well as the video Applet. 3.1 System Architecture The system architecture is broken into logic and presentation layers, which are represented primarily by portlets and their services. With regards to client and server aspects, a l l components bar the Applet execute on the server side. All cl ient interactions are via the browser/server side. As the planned use of this system was to be within a collaborative environment, it was seen fit to replicate the IRC interface. Unlike most of the popular instant messaging systems that focus on private conversations, the IRC portlet’s focal point is chat rooms; with each room being associated with a topic or subject. Figure 4, shows the architecture of the system. Starting with a users perspective, the presentation of what are essentia l ly Web forms, are displayed to the user via JSP tags. Any actions or invocations from the user are handled at the respective portlet. The cha t portlet’s main task with in the NaradaBrokering service is to simply invoke methods and exchange objects. This portlet a lso connects to the Userlist service, so that a l ist of users currently online can be viewed. Otherwise, the chat portlet handles user notif ications, inputs, messages and other actions. Also shown in Figure 4, is the video portlet. This portlet only needs use of the Userlist service, which provides the video portlet with updated user information. Users have the ir video stream details stored in the backend Userlist service. The video portlet displays a l ist of currently avai lable cameras to which a user could subscribe. The other task for this portlet is that it must handle the generation of Applets, which must load the correct video stream. Although the NaradaBrokering and Userlist services, do not exchange information directly, they both, either access information or modify information held in the user’s portlet session. The Userl ist service organises user information into a custom class and stores this information in a searchable format, which is shared amongst al l users. The cha t service is responsible for managing connections, sending and receiving messages, to and from NaradaBrokering, individually for every user. Two Applets are included, one for transmitting video data, the other for receiving it. The transmitting Applet has to capture the users Web-cam and publish i t to a JMS topic. The receiving Applet only subscribes to a given topic and displays a video feed if present. Also noticeable in Figure 4, is the MySQL [39] database, util ised by GridSphere. GridSphere does have the option of using other databases, such as its built- in database. MySQL was found to offer a robust platform.

9

Chat

NB Portlet

Service

NB Porlet Services

MySQL DB

Gridsphere

Tomcat Container

Video Conf

Portlets

Portal Server

NaradaBroker

System - listening

on open ports

Remote Server

Client Video Applet

Narada RTP Connector

RTP Transmitter

JMF Webcam

Capture

RTP Receiver

JMF Player

JSP

Client Interface

User List

Portlet

Service

Narada RTP

Server

Globalmmcs

Figure 4: The Architecture of the NaradaBrokering Chat and Video System

10

NardaBroker

Chat

Topic N

NaradaBrokering, Broker cloud

Client 3

Chat Video

Client 2

Chat Video

Client 1

Chat Video

Client 4

Chat Video

Portlet Session

JMS TopicConnection Object

JMS Publishers Session Object

JMS Subscriber Session Object

JMS Topic Publisher Object

JMS Topic Subscriber Object

JMS Topic Username

JMS Topic String

JMS Connection Properties

JMS Text Messages Received

JMS Text Messages to Send

Connection Status

Broker Server

Gridsphere

NaradaBrokering

Service

Session

info - 1

Session

info - 2

Session

info - 3

Session

info - 4

Tomcat Container

Figure 5: NaradaBrokering Chat and Video, Portlet Sessions

Figure 5, shows the location of portlet session accesses or modifications within the system. The communication payload between the chat service and the portlet is the portlet session itself. The portlet session is the only way to individually identify a users request or response. Thus when a user wishes to send a message to a chat room, it actually inserts the message to be sent into their portlet session with an attribute identifier so that it may be retrieved by the service. Also contained in the session are the connection objects and objects associated with the connection, these are l isted in Figure 5. Connection objects are stored, extracted and util ised from the portlet session when required. The server hosting NaradaBrokering must have at least one port configured and accessible, on both TCP and UDP. By default, this is 3045. TCP connections are primarily used for any chat communications, while UDP is uti l ised for video/audio.

11

3.2 The Chat Portlet The Chat Portlet is where the majority of user interactions occur. It supports a l l three default JSR-168 portlet modes, view, edit and help. The view mode displays a chat box where chat room messages are shown, an input box for sending messages and a l ist of online users. Figure 6, shows the portlet’s view mode after a successful connection.

Figure 6: The Chat Portlet Default View

The chat portlets edit mode al lows the user to customise the connection settings for the cha t room. This involves inputting the broker’s address, port number and protocol, or simply opting for a default chat room connection. A user can choose to connect via a number of protocols including, non-blocking TCP, normal TCP, UDP or HTTP; this maximises the connectivity options for interactions between the portlet and NaradaBrokering. The disconnection mechanism is a lso avai lable from here. Figure 7, shows the edit mode of the portlet. User notifications are presented in this view; the messages are dependent on the connection status.

Figure 7: The Chat Portlet Edit View

The help mode was introduced as a simple way to include specific help for this portlet and currently it contains links to updated user guides. Figure 8, shows the help view.

12

Figure 8: The Chat Portlet Help View

When a message is sent to the NaradaBrokering portlet service, the Chat Portlet encapsulates the text into the user’s session. This can be extracted from the message by the NaradaBrokering portlet service. The NaradaBrokering portlet service provides a reusable service that can be used by different portlets. In the view mode of the Chat Portlet, the chat area is where al l messages are displayed, is dynamically created. This area a lso accepts HTML instructions, which a l lows font and style changes. This capabil i ty is meant to mimic the command syntax used by IRC. A l ist of currently online users is presented in the bottom left hand corner of the portlet. The Userl ist service provides a l ist of currently logged in users for the portlet to iterate and present in a l ist-box. 3.3 The Video Portlet The Video Portlet provides an interface for the user to either publish or subscribe to the available cameras. This portlet extracts a l ist of currently subscribed user cameras from the Userl ist service. Once a user’s camera has been selected for subscription, the portlet dynamically creates a Java Applet tag with the appropriate parameters for a connection to the specified video stream. When the portlet is refreshed, the Applet wil l sti l l stay ‘a l ive’, thus al lowing the user to freely navigate through the system. Figure 9, shows the video portlet interface.

Figure 9: The Video Portlet

Two different Applets are loaded by this portlet. One for capturing a Web-cam and transmitting the video stream, which is activated via the publish button. The other Applet is for subscribing to a user’s video stream. When subscribing to a video topic, some user information is displayed in the portlet, which can be seen in Figure 9. This is a lso the same information passed onto the Applet. A JMF player window with the requested video feed is presented to the user, when there is a successful connection.

13

3.4 The NaradaBrokering Portlet Service The NaradaBrokering portlet service is one of the core components of the whole system. The service was originally designed as an ordinary class that is accessed via the portlet. However, upon further investigation it was found that a portlet service complements the system, with better integration, design and implementation. The portlet service a lso provides some advanced features, useful to this project, such as the built- in persistence, security, JUnit testing and a reusable API. In this particular case, GridSphere a l lows JSR-168 portlets to access portlet services, through its API. Figure 4, shows the location of the NaradaBrokering portlet service, within the whole system. When a user wishes to make a connection to a chat topic located on a remote broker, the connection details are sent to the service from the portlet. These connection details are used to make a JMS subscription to the topic requested. If a successful connection is made, a notification is sent across the chat topic, to a l l users. If the connection is unsuccessful, a message is replayed to the font end, which in this case is the chat portlet. The chat portlet then displays an error message understandable by the user. Once subscribed to a chat topic al l messages are received by the NaradaBrokering portlet service asynchronously. A JMS MessageListener is initiated per user connected, via the Mlist class. The Mlist class is the component that is actually subscribed to a particular topic on the user’s behalf. The Mlist class reta ins a reference of a user’s portlet session and inserts any messages received into the session. In addition, a timestamp of when the message was received is also appended to the messages. Not only does, the NaradaBrokering portlet service provide methods to send messages, start connections and close connections, but also returns information about any of the users connections, including their connection status and the protocol used. Most of the work carried out by the NaradaBrokering portlet service is JMS related and in some situations can be l imited to the broker’s implementation of the JMS specif ication. With the portlet service’s built- in persistence capabil i ty, there is a lso the possibil i ty for messages, to be seria l ised and stored as a chat log record, providing backdated conversations. It is a lso viable that the service can store information about the last connection made so that it could be reused. With regards to security, the service could authenticate against a l ist of roles and/or privileges so that authorised users could only access topic connections. The NaradaBrokering portlet service itself acts as a black box or generic connection point with a l l users util ising the same service. In this case, GridSphere itself handles a l l concurrent access issues. 3.5 The Userlist Portlet Service Wh ile the NaradaBrokering portlet service has the fundamental requirement to create individual connections and messages. The Userl ist service needs to share information in a common format. The location of the Userl ist service with in the system can be seen in Figure 4. The need to develop this service arose from the fact that the NaradaBrokering API could not provide a similar feature. The two front-end chat and video portlets uti l ise the same Userl ist service, but require the information for different purposes. The Chat portlet only needs to view the full l ist, so th at i t may establish a l ist of logged in users. Whereas the video portlet only needs to know about users that have already published a camera. The Userlist service also manages the a l location of video topic numbers for each logged in user. NaradaBrokering does not automate this procedure and thus the portlet service needs

14

to manage this functionality. Two topics are a l located per user. One topic is for the video stream and the other is for the control messages. The Userl ist service uses a hashmap in which a custom user class is stored. The key to the hashmap is the user’s name. The hashmap key makes the username so that duplicate entries are impossible. The hashmap also al lows users to be searched for too. The user class includes information such as chat room topic and username, as shown in Figure 9 3.6 The JMF Applet The transmitting Applet has both the transmitting and receiving functions. What this means is that the transmitting Applet not only transmits the video feed, but also receives the same feed. This provides the user with a view of actual transmission that others wi l l view, instead of clone of what is to be sent. Thus, only the transmitting Applets functionality wil l be discussed. The transmitting Applet consists of the components shown in Figure 4. The NaradaRTPConnector encapsulates the RTP data into JMS byte messages. These messages are then used by the Global-MMCS instantiation on the broker. Messages are sent to integer-based topics over UDP. The NaradaRTPConnector establishes the connection with a UDP application type ping, which tests the availabil i ty of the broker’s port. JMF provides RTP support, device capturing and playback windows. The RTP transmitter creates the RTP data manager for the captured datasource and prepares it for transmission. The video stream is compressed into the H.263 format that is optimised for this type of transmission. With regards to receiving RTP data, the RTP receiver takes messages received from NaradaBrokering, in which the payload is the RTP video and plays the content in a JMF playerwindow. JMF’s compatibil i ty with various Web-cams, over various platforms, forced the implementation of the device capturing method to be altered. The transmitting Applet checks which operating system is currently in use and then sets the capture device accordingly. In this scenario, only Windows and Linux were catered for, with the capture device being vfw://0 and v4l://0 respectively. Th is method uses only the first capture device instal led on a system. It was deemed unlikely that a user would have more than one Web-cam attached. 3.7 Summary In this section, we have attempted to discuss the design aspects of the NaradaBrokering Chat and Video system. We have also tried to justify the reasoning behind the architectural decisions, which has resulted in the system described. Although theoretical ly and physically the NaradaBrokering Chat and Video system works, it is not entirely feasible solution. Parts of the current prototype util ise GridSphere dependent functions, such as portlet services, to achieve the desired functionality. JSR-168 needs to mature further to be able to cope with complex portlets. The system’s portabil i ty is a lso hindered by JMF not functioning on al l platforms, or with al l Web-cams. This in itself establishes an issue, which may have to be addressed by new projects or further technological developments. When considering the NaradaBrokering Chat and Video system for use by general researchers, the task involved in instal l ing and deploying the software and its dependencies is diff icult. Most of the software instal lat ion and set-up required by the services is probably beyond the capacity of most non-technical researchers.

15

3.8 Further Comments The planned use of the system is that each site hosting the NaradaBrokering Chat and Video service wil l have a local broker instal led in their organisation. Each of these site brokers wil l then join and share information, such as chat room messages. Although some minor, adjustments would have to be made, to the inter-site communications required for the Userl ist service. This change would primarily be the sharing of user lists via another JMS topic, to provide a more proficient registry. To refresh the chat window requires the a id of other technologies, such as AJAX [40], which is not ideal. AJAX allows the chat text box to be refreshed with new messages without resorting to a full-page refresh. Along with this, some sort of server-side implementation for the rendering of video would then only require JMF for capturing from a device. This would minimise the dependency on third party components. Uti l ising the portlet services built- in persistence capabil i ties could be used to store messages and connection objects not only for logging, but a lso for fault tolerance in the case of where a Web browser crashes, or there are unexpected user disconnections. 4. The NaradaBrokering Chat and Video System Trials 4.1 Introduction During the development of the chat and video system a number of tria ls were carried out to try to simulate ‘real-world’ use of the service. This involved a number of participants at different physical locations with various interconnection bandwidths and latencies. This gave a perspective of the system’s performance and functionality, for an average user. 4.2 The Experiment Each user was instructed to login to GridSphere and connect to a chat room, with a certa in IP and port. After which, each user with a compatible Web-cam was asked to publish their video feed. In turn al l participants subscribed to al l published cameras, once this step was completed, the memory consumption of the server hosting NaradaBrokering and GridSphere was recorded. In addition, users were requested to give note the CPU and memory use of their PC’s and report any anomalies. The users were a lso asked to subscribe multiple times to al l cameras’ to replicate the system under load, in a ‘real-world’ scenario. Figure 10, shows a client’s Linux platform with multiple video streams active. In this particular case, eighteen streams were subscribed to, with one camera being published by this user. Figure 11, shows a client’s Windows platform running multiple video streams, and displays the frame rate and bit rate information. The additional statistics are given by JMF. It was also possible for the Windows client to ach ieve sixteen camera subscriptions. As can be seen in Figure 12, each user is given a different font colour, which was randomly assigned at login. Some colours wil l need to be ‘blacklisted’ as such, as it can be seen from Figure 12, that readabil i ty could be affected. Wh ile the tria ls took place, the memory use of the server and processes were noted. It was observed that our instantiation of Tomcat/GridSphere consumed 204 Mbytes upon start-up. In addition, 162 Mbytes of the memory used by our Tomcat/GridSphere setup was not ‘freed’ or recla imed by the server, when GridSphere was shutdown. NaradaBrokering consumed 20 Mbytes of memory when loaded and once shutdown the server did not recla im 10 Mbytes of this used space. NaradaBrokering was not used during this time, just simply loaded and unloaded. When both Tomcat/Gridsphere and NaradaBrokering were loaded 228 Mbytes of memory was consumed on the server.

16

Figure 10: NaradaBrokering Chat and Video Portlet Trail on Linux

Figure 11: NaradaBrokering Chat and Video system Trial on Windows

17

Figure 12: The Chat Portlet during the Trail

It was observed during the tria ls that the hosting server consumed an increasing amount of memory. Rogue connections to the broker from GridSphere appeared if the portlet could not close the connection. During the tria ls NaradaBrokering and Tomcat/GridSphere required to be restarted due to the rogue connections from the portlet and video streaming Applets. When the al located memory used by Tomcat/GridSphere could not be recla imed and services were struggling to find resources, the server required rebooting. Both NaradaBrokering and Tomcat/GridSphere peaked at a combined memory use of 643 Mbytes for just the two processes, and both consistently consumed 500 Mbytes or more during actual operation. Comments and feedback from the tria l participants included some interesting issues with JMF on the Windows platform. JMF includes an application JMStudio, which when loaded is executed as a Java Webstart application. The reasoning behind JMF’s use of Java Webstart for this application is not fully understood. The JMStudio application repeatedly crashing was a lso observed by the same user. JMF caused another user’s Windows machine to ‘hang’, while continuously searching for a Web-cam. JMF fa i led to notify the user that i t did not find a Web-cam, nor did it stop looking for the Web-cam, even though it was attached to the users machine. It was a lso recorded in the tria ls that inconsistent user sessions held in the client’s Web browser, caused portlet exceptions, when the NaradaBrokering Chat and Video system was trying to access information contained in the session. The session reference is held in the client’s Web browser. When this session is not destroyed or removed from the Web browser, GridSphere reuses it. If the old session is used, it confuses the condition/exception handling in the NaradaBrokering Chat and Video system and results in null objects. This error occurs when only a tab in a Web browser is closed rather than the browser application, without cleanly disconnecting a connection from NaradaBrokering. To clear the session from a Web browser a user must close down the entire browser and restart it from scratch.

18

4.3 Summary In this section the NaradaBrokering Chat and Video system tria l set-up, results and observations have been recounted. User feedback, experiences and observations have a lso been presented. The NaradaBrokering Chat and Video system does work and the experiments participants did hold a video-conference, for some length of time. However, what was not discussed here was the time and effort required to recompile NaradaBrokering with the appropriate port numbers and instal l GridSphere a long with the NaradaBrokering Chat and Video system, which was significant. It was also necessary to produce a lengthy client user guide and instal lation instructions for users [41]. As proof of concept the NaradaBrokering Chat and Video system works adequately, a lthough it would require substantia l work, with regards to the technologies used, when redistributing a production version. 4.4 Further Comments It was observed that JMF can consume a lot of processor time and seems to uti l ise substantia l ly more CPU on Windows than on Linux. Home users did not require alterations to any port configurations, as long as they a l lowed traff ic out from their network. Earl ier experiments had seen more issues with the video conferencing service; this was mainly due to connections not being closed properly. In addition, previous tests yielded less success with Web-cam detection. These tria ls were conducted without audio; this particular feature would need to be developed and tested too. 5. The Portlet and Service Development and Deployment 5.1 Introduction The development and deployment of the NaradaBrokering Chat and Video conferencing system has not been stra ightforward. A number of issues and problems have been encountered, which have ranged from running out of memory to those concerning capturing video streams in JMF under Linux. This section of the report attempts to describe the issues encountered when developing and deploying the various components. 5.2 NaradaBrokering From the benchmarks carried out in previous tests with NaradaBrokering 0.99-rc4 [41], i t was seen that multiple consumers, subscribing to a single producer could cause high memory use, when many JMS messages are transmitted. This is due, to NaradaBrokering not having any flow control for message transmissions. Although the messages and video streams consume minimal bandwidth, when scaled to 100’s of users or more, it could become more of an issue. The RTPLinkManager within the broker has ‘hardwired’ ports, thus if the default ports are changed in the configuration file, the Global-MMCS RTP server wil l fa i l to load. Line 83 of the RTPLinkManager class needs to be modified to match the brokers NIOTCP port, i f not configured to the default 3045. After which the source code of NaradaBrokering needs to be recompiled, this is less than ideal. To actually switch on the Global-MMCS RTP support within NaradaBrokering the configuration fi le requires a lteration and the server needs restarting. There is no script provided by NaradaBrokering to stop the broker, which means manual intervention is required to kil l the broker process. The connection or linking of two or more brokers together is a manual process and may involve restarting the broker if connections are lost. In addition, no registry or discovery functionality is currently working to aid the

19

creation/connection of broker clouds. The Broker Locator feature was found but did not seem to work or was not fully implemented at that time. With NaradaBrokering, private video conferencing sessions can be configured via a text fi le. This text fi le contains a list of IP addresses to ensure, that only clients from certain subnets may connect to a particular conference. However, any modifications to this fi le would require the broker to be restarted, thus not providing a dynamic solution at run-time. Therefore, the management of video sessions between users was implemented in the portlet services, which a l locates two video stream topics per user. One topic is for the video stream itself, while the other is for control messages. The portlet services were required to a l locate video topics to users, as the broker does not automate th is procedure. NaradaBrokering does not seem to faci l i tate a means to list a l l clients and their respective usernames, who are subscribed to a particular chat topic, from a remote location. Thus, a list of users was managed by the portlet services. This issue wil l grow substantia l ly when many brokers at differing locations are connected together. NaradaBrokering provides some client API’s for establishing a video conferencing session. However, these l ibraries are only partia l ly implemented and present numerous problems, especia l ly with regards to closing connections to the broker. Some of the NaradaBrokering code used for the client side Java Applets contain while loops, with Thread.sleep statements. These while loops are the main contributors to the high CPU usage levels seen by users, when receiving or transmitting video. 5.3 GridSphere Due to the nature of GridSphere’s implementation, a l l information is shared via a user’s portlet view. Thus, portlet sessions are the only way to provide individual views of messages per a user. This would not be much of an issue if only one chat room was avai lable for subscription, which is not the case. A user should be able to connect to any chat room they wish, much like a normal IRC. With the use of portlet sessions storing such information, GridSphere’s memory consumption increases as more messages and connections are established. The only alternative is to hold this information in a persistent store, but this may not be ideal when the server is heavi ly loaded, as increased delays are inevitable. This issue has been discussed on the GridSphere mail ing list and is known as ‘session bloating’. It is not only limited to GridSphere as uPortal has seen similar issues, detai ls can be found in [43]. Upon connection to a chat room, it was a lso observed that two threads are created per user connection. This would inevitably mean that double the numbers of threads are created in comparison to the number of users. Issues could arise when dealing with large numbers of potentia l users. JSR-168 seems to be a basic API, which does not provide advanced features or concepts such as portlet services. Nevertheless, GridSphere does a l low JSR portlets to access and use portlet services, which means it has certa in advantages over other portals. The reason behind portlet services was initia l ly conceived from user services. Whi le portlet services a l low multiple portlets to use its API, only one instance is loaded. The counter part of a portlet service is a user service, which is loaded on a per user basis. It was seen that a normal Java class acts much like a portlet service. It was noted that multiple re-deployments of portlets would corrupt GridSphere’s internal database. To avoid this issue another database, MySQL, was used instead of the internal HSQL database,. MySQL provided a far more robust storage mechanism, although the migration of the data from one database to another is not so simple.

20

5.4 JMF JMF’s platform compatibil i ty is of concern for Linux users. There is no support for Apple or BSD at a l l. The method to l ist a l l capture devices found/registered is not avai lable from the Applet under Linux. This is only true for Linux as Windows works fine, from the same browser and settings. This suggests that the browser’s security sandbox implementation under Linux is more rigorous. Other developers have had similar experiences with this issue, which can be seen at [44] and [45]. Solaris was not examined, and one would assume that Solaris being Sun Microsystems own operating system that it would ensure that JMF would work correctly on its platform. Thus a hard coded version of the Applet was implemented; the Applet detects the OS and sets the device to be the first camera device registered. For the JMF Applet to connect to another server, which typically differs from the one from wh ich it originated, a Java policy fi le must be placed in the clients home directory. Not al l Web-cams are compatible with JMF, especia l ly with regards to the RTP/H263 format requirements that are needed to send the video stream. JMF does not notify a user that their Web-cam is either not compatible or capable of this function. It was observed that jmfinit infinitely loops when trying to detect a camera that is not compatible, this may occur on Windows or Linux. Audio capturing was not developed after a negative experience with JMF and video capturing. Although, after further investigation it is l ikely that JMF audio capturing wil l work on any platform, as the JDK supports this feature, leaving less rel iance on JMF. From a clients perspective JMF is not the easiest of insta l lations, unless insta l l ing under Windows. Instructions for the portlet services were made to ease the clients JMF instal lation in this effort, which rel ied on the user placing library fi les in the correct place under the JRE. This was not only a simpler approach but was also al lowed a universal insta l l for any platform. JMF seems to be a sta le project as the current version was released in May 2003, while the last update was distributed back in November 2004. The Internet is full of forums with users having issues with JMF, which suggests that some of the code is not as stable or usable as i t cla ims. An alternative method for the video conferencing would be to capture a series of JPEG images from the camera, to mimic a video stream. As the video quality differs from camera to camera, with the current implementation, JPEG’s could provide a high quali ty low frame rate solution. 6. Summary and Conclusions 6.1 Summary This report has provided an overview to the technologies used and the experiences gained while developing and deploying the NaradaBrokering Chat and Video System. The report provides an insight to the technologies used namely, GridSphere, NaradaBrokering and JMF. We have a lso discussed the various technology choices, development decisions and tria ls to test the system. Finally, we have high lighted the issues surrounding the development and deployment of the whole system. The DSG has developed the NaradaBrokering Chat and Video system as part of JISC funded Sakai VRE demonstrator project. The aim of the chat and video system was to a l low researchers to collaborate via the Internet with ease. The NaradaBrokering Chat and Video system is designed to be JSR-168 compliant. GridSphere provides a portal development framework, in which portlets may be created and deployed. Although GridSphere is not without its issues, it stands up well against other portals, such as uPortal. NaradaBrokering communicates the video-conferencing, via

21

JMS brokers, its usabil i ty is hampered by rudimentary implementation, with regards to a production environment. The Java Media Framework seems to be the only Java-based framework that can manage time-sensitive data, such as video/audio streams or RTP sessions. JMF is hampered by platform dependencies, device compatibil i ty and instal lation issues. The NaradaBrokering Chat and Video system arch itecture was based on the choice of development and deployment technologies, which in itself is a compromise due to their emerging nature. The time to develop and deploy the overall system was greatly lengthen due to the need to overcome a number of technological hurdles and features inherent in the various technologies used. The NaradaBrokering Chat and Video system consists of five components, the chat and video portlets, the JMF Applets and the NaradaBrokering and the Userlist portlet services. The portlets manage and present the interface to the user and the JMF Applets transmit or receive the video feeds, while the portlet services contain the functionality of the system, such as connection and user management. A number of tria ls of the system were also conducted to test it under ‘real-world’ conditions. These tria ls were successful, but showed the various weaknesses in the technologies used to support and host the system. Four web-cams were published with each participant subscribing as many times as possible to the four published cameras. A maximum of eighteen subscriptions was atta ined by a single participant. The number of subscriptions possible by a client was l imited by the client’s resources, such as memory and bandwidth. Issues were seen with rogue connections and the excess memory used by the services. During the development and deployment of the system, a number of issues were discovered or exposed. These have highlighted the problems and issues involved when developing the system, these would either discourage or cause diff iculties for a user, to either insta l l or use the system. 6.2 Conclusions Although the NaradaBrokering Chat and Video System works as prototype, it provides a less than ideal solution. Most of the issues lie with various technologies and their implementations use to produce and provide the various services. NaradaBrokering requires some sort of GUI front end for its management, as ordinary users would find using the existing command line interface, a l i ttle daunting. In addition, the fact that NaradaBrokering and JMF are easier to insta l l under Windows rather than Linux also brings forward another issue, which is related to the widespread use of free and open source software, such as GNU/Linux, as opposed to Windows. NaradaBrokering’s client API does cla im to support other video/audio conferencing interfaces such as VIC [46] and RAT [47]. However, this does then extend the rel iance on third party components, thus increasing the complexity of the system being developed or used. GridSphere has a number of issues, especia l ly with regards to the internal database, re-deployments of portlets and memory use. One feature of GridSphere is the need for its source code to make a template for a portlet project and subsequent deployment. In addition, the fact that GridSphere’s WAR fi le build method does not currently work without editing the build.xml fi le and setting the gswebapp.dir variable to the appropriate directory. Without setting this variable a WAR fi le cannot be produced and the redistribution of the NaradaBrokering Chat and Video system becomes trickier. This implies that a l l users need to download GridSphere’s source code, rather then a binary distribution. Even when a WAR can be produced there is always a certa in amount of customisation of the XML fi les that are needed for successful redeployment into another portal framework. As mentioned earl ier in the report, JMF seems to be a dormant project, with only a couple of updates over the last three years. Along with platform dependency issues, JMF does not inspire confidence. However there does not seem to currently be any Java a lternative to JMF.

22

An alternative solution, would be to embed and plugin a professional viewer, such as Apple’s QuickTime [49] into a customised portlet JSR-168, when compared to existing proprietary portlet APIs, such as IBM’s WebSphere, seems to be lacking a full feature set. A new and recent development is JSR-286 [48], which is set to supersede JSR-168, with advanced features, such as WSRP, Inter-portlet communication, portlet fi l ters and enhancements to the portlet tag library, is currently being discussed by the community. It is hoped, these additional features wil l solve some of the issues presented in this report, especia l ly with regards to portlet services. GridSphere seems to have the most updates from the technologies used and thus seems to have the least issues from the three technologies. NaradaBrokering has received an update since the start of this project, a lthough the updates are not as regular as wished. JMF stands as the only production software and is below par, updates for JMF are even less frequent than the other technologies used. The state of JMF portrays a direct correlation to i ts performance. With these current issues, we have recommended that development is frozen unti l the technologies used by the system mature to a stage that they are suitable for use within a production environment. References [1] Sakai, VRE Demonstrator Project,

http://www.jisc.ac.uk/index.cfm?name=vre_sakai_portal [2] Internet Relay Chat (IRC), http://www.irc.org [3] GridSphere, http://www.gridsphere.org [4] NaradaBrokering, http://www.naradabrokering.org [5] JMF, http://java.sun.com/products/java-media/jmf/ [6] Global-MMCS, http://www.globalmmcs.org/ [7] JSR -168 specif ication, http://www.jcp.org/en/jsr/detail?id=168 [8] The Sakai Project, http://www.sakaiproject.org/ [9] IBM WebSphere, http://www-306.ibm.com/software/genservers/portal/ [10] Jakarta Apache Tomcat, http://tomcat.apache.org [11] GridSphere, http://www.gridpshere.com/ [12] Apache Ant, http://ant.apache.org [13] Java Server Pages (JSP), http://java.sun.com/products/jsp/ [14] Junit, http://www.junit.org/ [15] uPortal, http://www.uportal.org [16] uPortal FAQ, http://www.uportal.org/faq.html [17] Apache Pluto, http://portals.apache.org/pluto/ [18] HSQLDB, http://www.hsqldb.org/ [19] DrRockit.com,

http://www.drrockit.com/space/JSR+168+Hello+World+Portlet+using+GridSphere+UI+Tags

[20] Eclipse, http://www.eclipse.org [21] Community Grids Lab, http://www.communitygrids.iu.edu/ [22] Open Middleware Infrastructure Institute (OMII), http://www.omii.ac.uk/ [23] Fox. G, Pall ickara. S, and Parastatidis, S. Towards Flexible Messaging for SOAP Based

Services, Proceedings of the IEEE/ACM Supercomputing Conference 2004, Pittsburgh, PA.

[24] Java Messaging Service (JMS) Specif ication 1.0.2b, http://java.sun.com/products/jms/ [25] Fox. G, and Pall ickara. S. JMS Compliance in the Narada Event Brokering System,

Proceedings of the 2002 International Conference on Internet Computing (IC-02), Volume 2 pp 391-397, 2002

23

[26] S, Pall ickara and G. Fox, On the Matching Of Events in Distributed Brokering Systems, Proceedings of IEEE ITCC Conference on Information Technology, April 2004. Volume II pp 68-76.

[27] Pall ickara. S, Fox. G, Gunduz. G. Y, Liu. H, Uyar. A, and Varank. M., A Transport Framework for Distributed Brokering Systems, Proceedings of the International Conference on Paralle l and Distributed Processing Techniques and Applications, (PDPTA’03), Volume II pp 772-778.

[28] Pall ickara. S, Pierce. M, Yan. Y, and Huang. Y., A Security Framework for Distributed Brokering Systems. Technical Report, http://www.naradabrokering.org/papers/NB-SecurityFramework.pdf

[29] Gunduz. G, Pall ickara. S, and Fox. G., A Portal Based Approach to Viewing Aggregated Network Performance Data in Distributed Brokering Systems, Proceedings of the 2003 International Conference on Internet Computing, Volume II pp 495-501.

[30] RTP: A Transport Protocol for Real-Time Applications (IETF RFC 1889), http://www.ietf.org/rfc/rfc1889.txt

[31] Uyar. A, Pall ickara. S, and Fox. G., Towards an Architecture for Audio Video Conferencing in Distributed Brokering Systems, Proceedings of the 2003 International Conference on Communications in Computing pp 17-23.

[32] JXTA, http://www.jxta.org/ [33] Fox. G, Pall ickara. S, and Rao. X., Scaleable Event Infrastructure for Peer to Peer Grids,

Proceedings of the ACM Java Grande, ISCOPE Conference 2002, pp 66-75. Seattle, WA. [34] Pall ickara. S, and Fox. G., A Scheme for Reliable Delivery of Events in Distributed

Middleware Systems, Proceedings of the IEEE International Conference on Autonomic Computing, New York, NY, pp. 328-329, 2004

[35] JMF 2.1.1 Supported Formats, http://java.sun.com/products/java-media/jmf/2.1.1/formats.html

[36] JMF API Guide, http://java.sun.com/products/java-media/jmf/2.1.1/guide/JMFTOC.html

[37] Java Network management and Security. H.263: Video CODEC for Medium Quality Videoconferencing, http://www.javvin.com/protocolH263.html

[38] JavaTV, http://java.sun.com/products/javatv/ [39] MySQL Database, http://www.mysql.com [40] AJAX DWR, http://getahead.ltd.uk/dwr/ [41] NaradaBrokering Video and Chat Systems documentation,

http://dsg.port.ac.uk/projects/VRE/docs/ [42] M.A. Baker, M. Grove and R. Lakhoo, A Preliminary Performance Evaluation of jGMA

With the NaradaBrokering Framework, DSG Technical Report DSGTR29062005, June 2005, http://dsg.port.ac.uk/~raz/NB_JgmaReport0605.pdf

[43] Z. A. Shaw, uPortal 1.x memory usage Analysis, University of British Columbia , http://www.interchange.ubc.ca/zshaw/analysis/memory/

[44] JMF Interest Archives, http://archives.java.sun.com/cgi-bin/wa?A2=ind0207&L=jmf-interest&D=0&P=1162

[45] Java Forums, http://forum.java.sun.com/thread.jspa?forumID=28&h i l i te=false&start=0&threadID=333682&range=15&q=

[46] Video Conferencing Tool (VIC), http://www-nrg.ee.lbl.gov/vic/ [47] Robust Audio Tool (RAT), http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/ [48] JSR-286, Portlet specif ication 2.0, http://www.jcp.org/en/jsr/detail?id=286 [49] Quicktime, http://www.apple.com/quicktime/