MUM Architecture |
|
MUM Distributed Architecture First and foremost, we claim that only management operations executed in client locality can guarantee service continuity by promptly foreseeing and reacting to client handoffs. For that reason, MUM adopts a proxy-based infrastructure to grant service continuity and provides client devices with companion application-layer middleware proxies running at client access locality, i.e., Session Proxies, able to personalize service continuity management depending on and local executing context and client profile. With more details, the distributed MUM architecture includes the following entities:
| ||
MUM Distributed Architecture |
||
MUM Internal Architecture The internal architecture of our MUM middleware implementation consists of several facilities, in the following (see figure) we report its main facilities. MUM session proxy and client stub are the components working to handle the handoff management process to maintain service continuity. |
||
MUM Internal Architecture |
||
Proxy/stub facilities include:
Those three facilities form a pipeline; each stage of that pipeline exploits full context visibility and output data from the previous stage to trigger control actions over the following stage.
Service gateways comprise three generic facilities for continuous multimedia provisioning over the traditional Internet:
To ease integration with more traditional continuous service provisioning infrastructures MUM employs all most diffused standard application-level protocols: RealTime Protocol (RTP), Session Initiation Protocol (SIP), and RealTime Streaming Protocol (RTSP). In addition, to facilitate portability MUM is is implemented in Java and exploits pure-Java technologies such as Java Media Framework (JMF) and Java API for Integrated Networks (JAIN). |
||
8-nov-06 |