2. Outline
• Introduction
• Motivation
• Technologies:
– GridSphere,
– Java Media Framework,
– NaradaBrokering.
• System Architecture
• Experiments
• Issues
• Conclusions
13 July 2006 2
3. Introduction
• Portsmouth and Reading’s role in the Sakai VRE
project is to develop and deploy a number of
portlet-based tools and services.
• In particular we are looking at:
– Collaborative tools based on NaradaBrokering,
– Semantic Web tools based on RDF,
– Bridging technologies to enable legacy applications,
– Peer-to-Peer technologies.
• Portsmouth and Reading are developing JSR-168
portlets, on the basis that Sakai will consume
portlets via the WSRP consumer developed within
the project.
• In this talk we will recount our experiences
developing, deploying and testing chat and video
conferencing services based on NaradaBrokering,
13 July 2006 GridSphere and the Java Media Framework. 3
4. Collaborative Service
• Motivation:
– Investigate NaradaBrokering that is also
partially funded by the e-Science programme,
which other UK Universities and organisations
are interested.
– Add useful tools for the Sakai Demonstrator,
– To create a chat and video conferencing
system that work-site users and external
users may communicate with.
– To provide the ability to conference with
many participants, i.e. meetings or
teleconferences.
– Note: this work was completed in Jan 2005.
13 July 2006 4
5. Technologies Choices
• GridShpere:
– Supports JSR-168 and WebSphere portlets,
– Provides a portal framework, not just a portal, but a
development infrastructure.
– Has an active support and user community.
• NaradaBrokering:
– Unified messaging framework with support for Grid and
Web Services,
– Software multi-casting with support for different
transport protocols,
– Supports video conferencing with Global-MMCS.
• Java Media Framework:
– Java-based solution for handling time-sensitive data,
– Ability to capture video and compress streams in different
formats,
– Supports the Real-Time Protocol.
13 July 2006 5
6. Portals - GridSphere
• The GridSphere framework provides an
open-source portlet-based Web portal.
• The framework allows developers to
manage and deploy portlets within the
container.
• GridSphere supports JSR-168 and
WebSphere-based portlets.
• GridSphere also supports GridPortlets
for managing jobs and data on the Grid.
• GridSphere uses Apache Tomcat as its
container – though it can also use Jetty.
13 July 2006 6
7. Java Media Framework (JMF)
• JMF provides an interface for Java applications to
interact with media or time sensitive data.
• JMF includes codecs and protocols, such as:
– Support for Quick Time movies,
– MP3 playback,
– Video/audio capture,
– Supports the Real Time Protocol (RTP),
– H.263 video conferencing codec (compression format).
• JMF is available in two formats:
– Performance Pack, for only Linux, Solaris and Windows:
• Includes native libraries for codecs and capturing from
devices,
– Platform Independent version:
• Includes partial capability for codecs and no video capturing.
13 July 2006 7
8. NaradaBrokering
• NaradaBrokering is developed by the Community Grids
Lab at Indiana University.
• Originally designed to provide software multi-casting
for real-time collaborative systems.
• Asynchronous messaging system that is JMS 1.02b
compliant.
• Publish, subscribe and bind architecture with JMS
topics.
• NaradaBrokering supports other capabilities:
– Video Conferencing via Global-MMCS,
– Peer-to-Peer with JXTA,
– Grid and Web Services.
• Provides a number of transport protocols:
– HTTP/HTTPS, TCP/NIO-TCP and UDP.
13 July 2006 8
9. NB Chat and Video Architecture
• The NB Chat and Video System consists of
portlets, portlet services and Java applets from
a users perspective:
– Chat portlet,
– Video Conferencing portlet,
– NaradaBrokering portlet service,
– Userlist portlet service,
– JMF applet.
• The servers consist of:
– NaradaBrokering,
– Apache Tomcat,
– GridSphere,
– Global-MMCS.
13 July 2006 9
11. The Chat Service (1)
• The Chat Service consists of:
– A Chat portlet,
– A NaradaBrokering portlet service,
– A Userlist portlet service.
• The Chat portlet provides the interface and user
notification messages.
• The NaradaBrokering portlet service, handles all
connections and messages to be sent/received
for all connected users.
• The Userlist portlet service tracks connected
users and stores user information.
13 July 2006 11
14. An Example System Set-up
N a ra d a B r o k e r in g , B r o k e r
c lo u d
P o r tle t S e s s io n
B ro k e r S e rv e r J M S T o p ic C o n n e c tio n O b je c t
J M S P u b lis h e rs S e s s io n O b je c t
J M S S u b s c r ib e r S e s s io n O b je c t
N a ra d a B r o k e r J M S T o p ic P u b lis h er O b je c t
J M S T o p ic S u b s c r ib e r O b je c t
C h at
T o p ic N JM S T o p ic U s e r n a m e
J M S T o p ic S tr in g
J M S C o n n e c tio n P ro p e r tie s
J M S T e x t M e s s a g e s R e c e iv e d
J M S T e x t M e s s a g es t o S e n d
T om c at C o n n e c tio n S ta t u s
C o n ta in e r
G r id s p h e r e
S e s s io n
S e s s io n in fo - 3
in fo - 2
N a r a d a B ro k e r in g
S e r v ic e
S e s s io n
S e s s io n
in fo - 4
in fo - 1
C hat V id e o
C h at V id e o
C lie n t 1
C h at V id e o
C lie n t 4
C hat V id e o
13 July 2006 C lie n t 3
14
C lie n t 2
15. The Chat Service (4)
• Each user has a PortletSession, which hold all
connection information per a user.
• The Chat portlet and the NaradaBrokering portlet
service use PortletSessions for the communication
of messages and connection information.
• Messages are sent by the NaradaBrokering portlet
service to a JMS Chat topic on the broker.
• Each user has an associated asynchronous
MesaageListener, which stores any received
messages inside their PortletSession.
13 July 2006 15
16. The Video Service (1)
• The Video Service consists of:
– A Video Conferencing portlet,
– JMF Applets,
– A Userlist portlet service.
• The Video Conferencing portlet displays a
list of available cameras and loads the
relevant JMF applet.
• The Userlist portlet provides the video
stream topics and other details, to
initiate the video conference.
13 July 2006 16
17. The Video Service (2)
The Video Camera Subscription Interface
13 July 2006 17
18. The Video Service (3)
• Users may publish a web-cam or
subscribe to other registered web-cams.
• The video conferencing portlet gathers
user information from the Userlist
portlet service, to display a list of any
available cameras.
• The video conferencing portlet generates
an applet tag with the connection details.
• The applet then connects to a broker to
initialise a video conference.
13 July 2006 18
19. Video Service (4)
• There are two JMF applets:
– A transmitting applet which captures a device,
– A receiving applet which displays a video stream.
• The transmitting applet captures a users Web-cam as
RTP data and encapsulates it within the
NaradaRTPConnector.
• The receiving applet uses the NaradaRTPConnector to
extract the video stream and plays it with a JMF player.
• This means that only one UDP port is required to be open
on the broker for users to use the video conferencing.
• The chat facility also only requires one TCP port on the
broker.
• This is unlike VRVS or Access Grid which requires a
range of ports to be open.
13 July 2006 19
20. Chat and Video Services
• The presentation layers are separated
from the logic – an MVC design pattern.
• All inter-portlet communications are
undertaken with either PortletSessions
or via portlet services.
• The portlet services interact with
external sources, while the portlets only
deal with the layout and passing of
information to the services.
13 July 2006 20
21. NB Chat and Video System
Experiment
• The Chat and Video Portlet was tested with four cameras
and five users.
• Each participant was connected to the chat room and
four cameras where published.
• All participants subscribed to all four cameras.
• To stress test the system all participants subscribed
multiple times to all four cameras.
• The limitations of the number of subscriptions each user
could make, was only limited by their system resources.
• The maximum obtained was 18 subscriptions with one
published camera, by a single user.
• The broker and GridSphere consistently utilised 500
MBytes of memory, peaking to 643 MBytes.
13 July 2006 21
22. NB Chat and Video System Experiment
13 July 2006 22
23. Issues
• The RTPLinkManager in NaradaBrokering (0.99RC4) has
‘hardwired’ ports, even though there is a configuration file.
• NaradaBrokering’s RTP session configuration file is not
dynamic; it requires a broker restart.
• When many messages are sent to the broker memory usage
increases and eventually the broker fails.
• The system suffers from session bloating with this portlet
and thus consumes a lot of memory.
• Memory is not reclaimed by the system.
• JMF has compatibility issues with web-cams and Linux.
• Refreshing the chat room messages automatically requires
other technologies, such as AJAX and/or JavaScript.
• Closing the an applet’s connection is problematic; needs the
whole browser to be shutdown.
13 July 2006 23
24. Conclusions
• As proof of concept the system does work,
however, some of the technologies and
standards need to mature.
• Installing JMF is still problematic for
platforms other than Windows and seems
to be a dormant project, with few updates.
• JSR-168 does not accommodate for the
concept of portlet services, thus portlets
could be very large and not easily reusable.
• NaradaBrokering’s RTP support and JMS
API needs to be extended to improve its
capabilities.
13 July 2006 24