DESIGN AND IMPLEMENTATION OF MMS PEERS

Architecture I

Figure 5 shows the architecture of the whole MMS kiosk system when a PDA is incapable of running a Jxta peer. The PDA, in this architecture, is used to access the services provided by the kiosk/shop (like the MMS message search, composition, and sending). The PDA to kiosk/shop interaction is a clientserver interaction. The kiosks and shops are the nodes in the P2P network here, not the customers' PDAs.

Figure 5: MMS kiosk environment architecture I

The PDA has been shown to have only an MMS composer, MMS player, and MMS sender. The MMS composer composes a message by aggregating all the media and presentation information provided by the user . The MMS sender performs a HTTP post to the MMS proxy-relay to send the message to its destination. An MMS player is also provided to the PDA client to view an MMS message before sending. The kiosk/shop is what provides the service to allow a customer to search for MMS messages and send them. The kiosk and the shops are part of a Jxta MMS peer group .

The protocols that the PDA can use to directly send to the MMS proxy are either HTTP or SMTP (if the MMS proxy-relay provides an SMTP interface). The communication between the kiosk/shop and the PDA can be over Bluetooth, IEEE 802.11b, or infrared. Infrared is not a good choice due to its very limited range (IrOBEX Specification, 2002).

Architecture II

Figure 6 shows the final architecture due to the availability of the Jxta platform for a PDA (Jxta platform, 2002) and the P2P advantages it offers over Architecture I. Unlike Architecture I, this architecture is almost fully P2P, except the interaction between the Jxta peer and the MMS proxy-relay. This offers the advantage that a customer can become part of a peer group due to other customers around him. This opens opportunities for customers to exchange MMS messages they have on their devices.

Figure 6: MMS kiosk environment architecture II

PDA MMS Peer Design

The MMS peer on the PDA consists of four modules:

• MMS composer

• MMS encoder and sender

• MMS player

• MMS Jxta search and share

MMS composer

This module allows a user to compose an MMS on the move (see Figure 7). It allows the user to select the media content and provide layout details and timing information for the slides of the MMS presentation. The process results in the generation of an SMIL file, which contains the presentation details of the media. Subsequently a Jar file (JAR documentation, 2002) is created with all the media files and the SMIL file. The MMS sender (in the next section) takes the Jar as its input, encodes it into an MMS, and sends it.

Figure 7: MMS composer design

MMS encoder and sender

MMS can be sent either using HTTP Post or SMTP if the MMS proxy-relay provides both interfaces (see Figure 8). The two modes of sending the message could be chosen based on the priority of the message. Using SMTP takes longer to send, as the message has to be ultimately encoded according to MMS standards (MMS encapsulation specification, 2002). Hence, SMTP could be used to send low-priority messages.

Figure 8: MMS sender design

MMS player

The MMS player takes a Jar as input, extracts all the media and SMIL parts , and uses a SMIL parser to parse the SMIL and play it (see Figure 9). The slides in the SMIL presentation are rendered using double buffering (Double buffering in Java, 2002). The AMR audio is first converted to the WAV format and then played. Imelody (.imy files) files (iMelody specification, 2002) cannot be played by the application at this stage.

Figure 9: MMS player design

It was observed that some WAV files with a certain header were not playing on WinCE 3.0 but were playing on the desktop (Win 2000). The AMR to WAV converter native code was modified to take care of the change. The native code to convert and play is used via the Java Native Interface (JNI; Java Native Interface, 2002).

MMS Jxta search and share

The MMS application once started represents a Jxta peer. The peer becomes a member of a universal group called the net peer group. The peer then starts to discover its peers and available peer groups. The search and share module relies on two main modules called the peer group manager and the search manager (see Figure 10). The search and share uses the content management service.

Figure 10: MMS search and share design

A peer group manager is created after the start-up of the Jxta platform. This manager monitors and influences peer group discovery. It maintains the list of groups the peer has currently joined and allows one to join, leave, and create peer groups. The search manager is the interface to the file sharing application. The content put up locally by the peer or remotely in the peer group is described by an MMS advertisement. The MMS advertisement allows propagation along normal Jxta discovery channels.

MMS Kiosk Design

According to Architecture I, the kiosk consists of three modules: one to compose and send an MMS message, a second to search for MMS content, and a third to handle requests from the PDA. In Architecture II, the kiosk is not much different from the PDA peer except that it would also be expected to act as a rendezvous and run a MMS Jxta service described below.

MMS Jxta service

Peers having access to the MMS proxy-relay provide the MMS Jxta service. The service is searched for by peers which do not have connection to the Internet and cannot access the MMS proxy-relay directly. The service advertisement contains the pipe advertisement so that other peers can connect to it and use it. This service should be run as a peer group service so that there is a higher chance of the availability of the service. When run as peer group service, the peers running the service rely on one peer group service advertisement instead of publishing their own for the same service.

Figure 11: MMS Jxta service design

Figure 12: MMS kiosk design for Jxta-enabled PDAs

Figure 13: Kiosk design for non-Jxta-enabled PDAs

Jxta proxy

Jxta proxy is required for devices that cannot run the Jxta core services yet. The Jxta proxy should receive the requests from the PDA client and then use the MMS search and messaging services on behalf of the PDA. It would also provide the interface to the transport protocol used between the kiosk/shop and the PDA.

Graphical User Interface Design

The graphical user interface (GUI) was designed keeping the PDA in mind. The user interface uses as many components that can be either easily clicked or tapped with a stylus. The following things were taken into consideration for the user interface design:

• A user would always want to have the list of peers and peer groups in front of him or her because of constant interaction with these entities.

• The limited screen size of the PDA requires that every function be provided without cluttering the screen. Thus every function is provided on a new screen.

• This sort of layout would be ideal if service clients are to be loaded dynamically upon discovery of a service.

Figure 14 shows the MMS player and sender GUI. It also shows the lists of peer groups and peers currently visible. The peer groups and peers lists keep getting updated automatically. Figure 15 shows the MMS search GUI. A user can enter the keywords and press enter to search. A button will be added also to allow easy use on the PDA.

Figure 14: MMS player and sender

Figure 15: MMS search

Figure 16 shows the MMS share GUI. It is similar to the MMS search GUI. It allows search for content in the current peer group. Figure 17 shows the MMS composer GUI. It is used to compose an MMS using various media files input by the user slide by slide. Figure 18 shows the Navigation menu, which is used to navigate to the various GUI components seen earlier. The design is such that the same region is used for the various functions. Figure 19 shows the Group menu that allows one to create, join, and leave a peer group after selecting in the peer group list below.

Figure 16: MMS share

Figure 17: MMS composer

Figure 18: Navigation menu

Figure 19: Group menu

Comparison with Other MMS Solutions

There are some other MMS clients for the PDA that exist now. The one from Anny Way (MMS ‚ Opportunities, migration and profits, 2003) is specifically for Pocket PC. EasyMessenger (EasyMessenger, 2003) from Oksijen Technologies is the only other Personal-Java-based MMS client but without the additional P2P features provided by us. Electric Pocket's Pixer (Pixer MMS, 2003) is another MMS client that only supports Pocket PC and Palm OS and can be used to send images only. There seems to be no work done on using MMS and Jxta together or for that matter not even EMS or SMS and Jxta.

All the solutions above are MMS clients with a view to sending multimedia messages, a progress from SMS or EMS. The MMS peer was developed with a view to making not only messaging a more pleasant and easier experience but also to provide features that would facilitate access to a variety of content. The searching and sharing of content from peers in the vicinity (shoppers) as well as content stores (kiosks) make it a compelling multimedia messaging solution.