Introduzione
Vediamo alcune caratteristiche del servizio MMS:

• il modello delle transazioni per la gestione del rapporto di consegna.
• l'analisi della codifica binaria di un messaggio, utile per comprendere alcune funzionalità in modo indipendente dalle librerie disponibili.
• il protocollo SOAP come standard per l'invio di MMS.

Gestione del rapporto di consegna
Un servizio affidabile non perde mai i messaggi, o al più consente di conoscere lo stato del messaggio; di solito si usa un messaggio di avvenuta ricezione (acknowledgement).
Mentre un servizio che non garantisce la totale affidabilità è solitamente più veloce.
I servizi affidabili più conosciuti sono quelli della rete Internet e coinvolgono diversi protocolli come il trasferimento di file e l'invio di posta elettronica con notifica di avvenuta ricezione. Mentre tra i servizi non affidabili i più utilizzati c'è l'invio di posta elettronica e le applicazioni multimediali nelle reti di calcolatori geografiche che richiedono grande velocità di trasmissione, ma dove il contenuto informativo non viene significativamente alterato se alcuni pacchetti non giungono a destinazione (ad esempio la videoconferenza).
Allo stesso modo del servizio di posta elettronica, di solito il servizio MMS è un servizio non affidabile. Il servizio MMS è affidabile solo se viene implementato il rapporto di consegna attraverso la gestione del Message-Id.
Quando un messaggio viene consegnato ad un centro MMS questo assegna un identificativo univoco al mondo, il Message-Id. Ciascun centro MMS usa le sue politiche di identificazione come indirizzo del host mittente, la data di invio ed altro.

Questo il modello delle transazioni di un sistema per la gestione del rapporto di consegna di un messaggio MMS:

1. - l'applicazione invia un messaggio al centro MMS, l'header X-Mms-Delivery-Report della primitiva M-Send.req deve essere impostato su YES.
2. - il centro MMS risponde con un pacchetto MMS, la primitiva M-Send.conf, dove l'header Message-Id assume su un certo valore (ad esempio 00000000000001).
3. - il centro MMS invia all'applicazione un pacchetto MMS, primitiva M-Delivery.ind, con lo stesso Message-Id (quindi 00000000000001).
   

L'implementazione del rapporto di consegna avviene attraverso la gestione Message-Id.

Figura 1 - Modello delle transazioni

Questi i 6 headers generati dalla primitiva M-Delivery.ind:

• X-Mms-Message-Type - obbligatorio, il tipo di primitiva che è sempre M-Delivery.ind.
• X-Mms-MMS-Version - obbligatorio, la versione degli MMS che ora è la 1.0.
• Message-Id - obbligatorio, l'identificativo del messaggio.
• To - obbligatorio, il mittente.
• X-Mms-Status - obbligatorio, lo stato del messaggio che può essere EXPIRED, RETRIEVED, REJECTED, FORWARDED.
• Date - obbligatorio, data del messaggio.

Il rapporto di consegna descrive lo stato del messaggio: EXPIRED il messaggio non può essere consegnato ed è stato cancellato dal centro MMS, RETRIEVED il messaggio contiene qualche errore, REJECTED il destinatario rifiuta di prelevare il messaggio, FORWARDED il messaggio è stato consegnato.

Codifica binaria
Nell'articolo precedente abbiamo utilizzato le Nokia MMS Java Library per costruire il messaggio (intestazione e corpo) da recapitare al centro MMS ( Nokia MMSC EAIF Emulator).
Prima di inviare il messaggio però è necessario codificare lo stesso, in particolare il codice Java utilizzato era il seguente:

MMEncoder encoder=new MMEncoder();
encoder.setMessage(messaggio);
encoder.encodeMessage();
byte[] out = encoder.getMessage()

Se vengono adoperate le nuove librerie della Nokia o librerie di altri produttori il codice risulta diverso, in ogni caso però il messaggio deve essere codificato in un flusso di byte dello standard MMS [3].
Vediamo alcune di queste regole e analizziamo il messaggio dell'articolo precedente, il quale visualizzato dall'emulatore della Nokia Epoc 32 [4], ma si possono usare anche altri emulatori, è questo:

Figura 2 - La prima parte del messaggio visualizzato con Epoc 32

Mentre questa è la codifica di alcuni campi di un MMS:

Bcc 0x81, Cc 0x82, Content-Location 0x83, Content-Type 0x84, Date 0x85, Delivery-Report 0x86, Delivery-Time 0x87, Expiry 0x88, From 0x89, Message-Class 0x8A, Message-Id 0x8B, Message-Type 0x8C, MMS-Version 0x8D, Message-Size 0x8E, Priority 0x8F, Read-Reply 0x90,
Report-Allowed 0x91, Response-Status 0x92, Response-Text 0x93, Sender-Visibility 0x94, Status 0x95, Subject 0x96, To 0x97, Transaction-Id 0x98.

Anche il valore che può assumere un campo è caratterizzato da una codifica esadecimale. Ad esempio la primitiva M-Send.req assume il valore 0x80, mentre la primitiva M-Delivery-ind assume il valore 0x86. Inoltre il primo byte di ogni messaggio multimediale indica il campo Message-Type.
Quindi un messaggio multimediale in cui i due primi byte sono 0x8C80 significa che il tipo di messaggio (header Message-Type) corrisponde alla primitiva M.Send.req.

Riprendendo il messaggio dell'articolo precedente questo è un pezzo di codifica esadecimale,
viene evidenziato:

X-Mms-Message-Type: M.Send-req
X-Mms-Transaction-Id: 00000001
From: 123.124.125.125
To: 3401212341
Cc: 3472333331
Bcc: john@enterprise.com

Figura 3 - Codifica binaria di un messaggio

Il protocollo SOAP e la comunicazione con un centro MMS
Le applicazioni distribuite rappresentano una parte importante della produzione software.
Una parte molto complessa della elaborazione distribuita consiste nella gestione delle chiamate remote: si tratta di chiamare del codice residente su un server passandogli eventualmente dei parametri, e riceverne la risposta anch'essa con un'opportuna codifica.
Attualmente esistono molti standard per la codifica e la trasmissione delle chiamate e delle risposte: CORBA uno standard industriale, RMI di SUN o DCOM di Microsoft.
SOAP si propone come sostituto per tutti questi protocolli.
Il protocollo di trasporto di SOAP è quasi sempre su HTTP, mentre l'informazione viene codificata in XML:

• Hyper Text Transfer Protocol permette di chiamare codice remoto passando senza problemi attraverso i firewall.
• XML permette l'indipendenza della piattaforma tra client e server, è cosi possibile sviluppare lo strato software del client in un linguaggio e lo strato software del server in un altro linguaggio.

Il 3GPP è l'organizzazione il cui compito è definire l'architettura della rete ed i protocolli di comunicazione del servizio MMS. Le ultime specifiche del 3GPP definiscono l'utilizzo di SOAP come protocollo di comunicazione MM7 da una applicazione (VAS Value Adding Service) ad un centro MMS.
Questa l'architettura di riferimento:

Figura 4 - SOAP e il servizio MMS

Conclusioni
La continua diffusione di telefoni a colori e la possibilità di incorporare immagini, audio e video clip in un messaggio permetterà di utilizzare sempre più gli MMS al posto dei messaggi di testo SMS.
Gli strumenti a disposizione di un programmatore per lo studio e/o per lo sviluppo di applicazioni MMS non mancano: abbiamo utilizzato le Nokia MMS Java Library che realizzano la comunicazione con un centro MMS attraverso HTTP [5] e da poco è disponibile l'ultimo ambiente di sviluppo Nokia [6] con il pieno supporto a SOAP conforme alle specifiche 3GPP [8]. Ma non solo, esistono anche altre librerie e tools completamente gratuiti, tra cui il più interessante è l'Openwave Mobile SDK e le API sono anche qui in Java [7].

Bibliografia e Strumenti
[1] "MMS Architecture Overview", Wap Forum www.wapforum.org.
[2] "MMS Client Transaction", Wap Forum www.wapforum.org.
[3] "MMS Encapsulation Protocol" Wap Forum www.wapforum.org.
[4] Nokia 5100 SDK, Nokia 6650 MMS Concept SDK, Nokia 7210 Mobile Handset Simulator (MMS/WAP), Nokia 7600 MMS Concept SDK, Serie 60 Content Authoring SDK Epoc 32, www.forum.nokia.com.
[5] Nokia MMS Java Library Ver 1.1, 4-Marzo-2002, www.forum.nokia.com.
[6] Nokia Mobile Server Services SDK 1.3 20-Gennaio-2004, www.forum.nokia.com.
[7] Openwave Mobile SDK Wap, www.openwave.com.
[8] 3rd Generation Parternship Program, www.3gpp.org