The previous section provides a discussion on the various messaging technologies, which are only the tools that MMS peers use to deliver their contents. What is more important is the distributed peer-to-peer model, which allows various MMS peers to discover and communicate with each other. This section gives a brief overview of distributed computing models and describes in detail one peer-to-peer technology, i.e., Jxta.
Today, the most common distributed computing model is the client-server model (Chambers, Duce, & Jones, 1984). Figure 1 depicts the typical clientserver architecture.
In the client-server architecture, clients request services and servers provide those services. A variety of servers exist in today's Internet ‚ ‚ Web servers, mail servers, FTP servers, etc. The client-server architecture is an example of a centralized architecture, where the whole network depends on central points to provide services. Regardless of the number of clients , the network can exist only if a server exists (Berson, 1992).
Like the client-server architecture, P2P is also a distributed computing model (Yemini, 1987). However, the P2P architecture is a decentralized architecture where neither client nor server status exists in a network (Madron, 1993). Every entity in the network, referred to as a peer , has equal status, meaning that an entity can either request a service (a client trait) or provide a service (a server trait). Figure 2 illustrates a P2P network.
Though peers all have equal status in the network, they don't all necessarily have equal physical capabilities. A P2P network might consist of peers with varying capabilities, from mobile devices to mainframes (Budiarto & Masahiko, 2002). A mobile peer might not be able to act as a server due to its intrinsic limitations, even though the network does not restrict it in any way.
Both networking models feature advantages and disadvantages. One can visualize from Figure 1 that as a client-server network grows (i.e., as more and more clients are added), the pressure on the central point, the server, increases (giving rise to "hot spots"). As each client is added, the central point weakens and its failure can destroy the whole network.
A P2P network delivers a quite different scenario. Since every entity (or peer) in the network is an active participant, each peer contributes certain resources to the network, such as storage space and CPU cycles. As more and more peers join the network, the network's capability increases. A P2P network also differs from the client-server model in that the P2P network can be considered alive even if only one peer is active. The P2P network is unavailable only when no peers are active.
Different protocols, different architectures, different implementations . That accurately describes current P2P solutions. Currently, developers use diverse methodologies and approaches to create P2P applications. Standards, abundant in the client-server world, are noticeably absent in the P2P world. To tackle this deficit, Sun developed Jxta (http://www.jxta.org/.).
Jxta strives to provide a base P2P infrastructure over which other P2P applications can be built (Project Jxta, 2002). This base consists of a set of protocols that are language independent, platform independent, and network agnostic . These protocols address the bare necessities for building generic P2P applications (Jxta technology overview, 2002). Designed to be simple with low overheads, the protocols target to build, to quote the Jxta vision statement, "every device with a digital heartbeat".
Jxta currently defines six protocols (Jxta protocol specification, 2002), but not all Jxta peers are required to implement all six of them . The number of protocols a peer implements depends on that peer's capabilities. A peer could use just one protocol. Peers can also extend or replace any protocol, depending on its particular requirements (Brookshier, 2002).
Peer and Peer Groups With today's limit on connectivity and available bandwidth, harnessing the entire Internet as one huge P2P network is impractical . Instead, some partitioning is necessary. The logical partitioning of the physical network creates working sets of peers called peer groups . Peer group memberships can overlap with no restriction; in other words, any peer can belong to as many peer groups as necessary. The Jxta specification does not dictate or recommend an appropriate way of forming peer groups. In a Jxta network, a peer group is a collection of peers that share resources and services.
Jxta Services Jxta services are available for shared use by peers within a peer group. In fact, a peer may join a group primarily to use the services available within that group. A set of services, called core services , is essential to the basic operation of a Jxta network. One instance of a core service already seen is the membership service. Table 2 shows the core services included in version 1.0 of the Jxta specification.
Service name | Description |
---|---|
Pipe | The main means of communications between peers; provides an abstraction for a one-way, asynchronous conduit for information transfer. |
Membership | Determines which peers belong to a peer group; handles arrival and departure of peers within a peer group. |
Access | Security service for controlling access to services and resources within a peer group; a sort of security manager for the peer group. |
Discovery | A way peers can discover each other, the existence of other peer groups, pipes, services, and the like. |
Resolver | Allows peers to refer to each other, peer groups, pipes, or services indirectly through a reference (called an advertisement in Jxta lingo); the resolver binds the reference to an implementation at run time. |
The initial reference implementation of project Jxta does not provide any services beyond the five listed in Table 2. Even some of the core services, such as the access service dealing with security, are implemented in a very basic way.
Pipes One way to transfer data, files, information, code, or multimedia content between peers is through logical pipes, as defined by the Jxta specification. Jxta pipes are used to send messages (with arbitrary content) between peers. A pipe instance is, logically speaking, a resource within a peer group. The actual implementation of a pipe instance is typically through the pipe service. Unlike conventional UNIX-like systems, Jxta pipes are unidirectional and asynchronous.
Regardless of the type of pipe, the blocks of information carried though the pipe are referred to as Jxta message.
Messages Jxta messages are data bundles that are passed from one peer to another through pipes. The Jxta specification is again as generic as possible here so as not to inadvertently introduce any implementation-dependent policies into the definition of a message. A message is defined to be an arbitrarily sized bundle, consisting of an envelope and a body. The envelope is in a standard format that contains:
A header
Source endpoint information (in URI form)
Destination endpoint information (in URI form)
A message digest (optional ‚ ‚ for security purposes)
The body of a message is of arbitrary length and can contain an optional credential (for security purposes) and content.
Advertisements Advertisements are the less obvious cousins of messages. Jxta advertisements are also XML documents. The content of an advertisement describes the properties of a Jxta component instance, such as a peer, a peer group, a pipe, or a service. For example, a peer having access to an advertisement of another peer can try to connect directly to that other peer . A peer having access to an advertisement of a peer group can use the advertisement to join that group. The current Internet analogue to an advertisement is the domain name and DNS record of a Web site.
Jxta's XML-based messaging is similar to Microsoft's .Net and SOAP technologies. But that is a very thin foundation for comparison. As more and more third-party protocols make use of XML, it will become obvious that just using XML as a message format says nothing at all about an actual networking technology. Comparing the high-level, policy-rich, Web-services-based infrastructure that is .Net to the low-level, fundamental, policy-neutral nature of Jxta is a futile exercise.
Project Jxta and the Jini project are also fundamentally different. Both of them have some similarity in higher-level interaction, enabling true distributed computing over a network. However, the similarity abruptly ends there. Strategic differences between the two are: Jxta started life as a completely interoperable technology (any platform, any programming language, any vendor). Sun is a mere contributor in the community. Jini is a Java-centered technology that Sun will integrate and deploy strategically in future product offerings. Sun will maintain a degree of control over Jini's evolution.
In a P2P environment like Jxta, commonly accessed information gets replicated (the peers have a choice to keep a copy of content passing through them) and becomes available at peers fewer hops away. This avoids "hot spots" and is ideal for content sharing where the content can be of any type. For an MMS kiosk searching for multimedia messages, the situation is no different and it would thus be ideal to use a P2P framework to advertise and search for multimedia messages and media content.
A simple scenario is when a shop in a shopping mall adds more product brochures (in the form of MMS presentations) to its peer and advertises them. Subsequently, the kiosk would discover the new content and make it available to customers wishing to use the service from the kiosk. In a shopping mall this is likely to happen often as shops are always finding new ways of providing exciting offers to its customers. For example, shops providing multimedia messages for entertainment purposes would be updating their message collections often.
In another shopping mall scenario, a customer with a PDA walks into a shop, automatically connects to a peer within range , and begins searching for MMS messages and also an MMS service if it does not have the capability to connect to the MMS proxy-relay itself. In such a case, the PDA becomes a part of a peer group formed with the other customers around it. Hence, the search is not limited to the shopping mall peer-to-peer network but also to an ad hoc network created by the presence of other customers.
In a frequently changing environment like this, a P2P model like Jxta, with its dynamic resolution of peers and advertising and discovery capabilities, would be ideal to find the freshest content.
Most shopping malls have information kiosks , which could be equipped with a network point and wireless service access capabilities using technologies like Bluetooth or 802.11b (IEEE 802.11, 2002). Location-specific MMS content could be provided to customers in the vicinity of a kiosk or a shop. MMS would just be one of the many other services that can be provided at the kiosk, especially for mobile devices not connected to the cellular network or not subscribed to data services but with Bluetooth or 802.11b access.
The shops could provide product brochures, cards, postcards, pictures, comic strips , sounds, songs, etc. in the form of MMS presentations, which could be used by a customer to send to another person. The information kiosk could perform searches across the mall's network to update its multimedia message repository and provide a common contact point for all the shops in the mall.
The requirement here is to provide enhanced customer service. The customer need not visit all the shops and need not verbally describe a product to another person before making a decision to buy something. Instead he or she could simply send the product brochures to the other person via MMS. These kiosks could also provide multimedia messages intended for fun and entertainment purposes and charge for them. Alternatively, shops could provide free MMS as a value-added service to their customers.