A l'hora de definir el projecte cal tenir en compte l'arquitectura, ja que d'ella pot dependre l'èxit del nostre projecte.
Per a les aplicacions destinades als dispositius mòbils disposem de sis tipologies / estils d'arquitectura: Thick Client, Rich Client, Streaming, Thin Client, Messaging, No Client.
Per tal de poder decidir quina aplicar a la midlet, primer de tot procediré a fer una breu explicació de cadascuna d'elles:
1. Thick Client:
Tenim que tant les dades com el codi es troba emmagatzemat al dispositiu, això implica que l'aplicació s'ha d'encarregar de la gestió de l'espai de memòria.
Avantatges: Funciona independentment de si el dispositiu disposa de cobertura o no. A més, ens permet treballar amb perifèrics i l'aplicació de estratègies de seguretat.
Restriccions: És complex de desenvolupar, de testejar i de mantenir. El fet de treballar de forma desconnectada augmenta la complexitat ja que podem tenir conflictes a l'hora d'actualitzar la informació, tot hi que això ho haurem de solucionar amb les polítiques de reescriptura.
S'aconsella aplicar aquesta arquitectura quan l'aplicació requereix càlculs sofisticats, quan els requeriments de l'aplicació no depenen de la latència de la xarxa, però sobretot quan es requereix treballar amb perifèrics.
Per tant, en el cas de la nostra midlet potser no seria interessant aplicar aquest tipus d'arquitectura ja que està basada per a la utilització de perifèrics que nosaltres no requerim.
2. Rich Client
En aquest cas, el codi continua guardant-se al dispositiu però les dades no tenen per què ser guardades.
Avantatges: El cost de realització és més baix que el Thick Client, també millora el cost de la gestió i de les operacions. Aquesta arquitectura té el potencial per ser la més potent i la més difícil de dissenyar. El codi local suporta estratègies de seguretat pròpies.
Restriccions: Les operacions fora de línea només estan disponibles si l'aplicació no requereix accés a les dades en temps real. És millor aplicar aquesta arquitectura en un rang limitat de tipus de dispositius. Tecnologies com J2ME pateixen variacions substancials d'un dispositiu a un altre, fet que fa incrementar el cost i la complexitat.
S'aconsella utilitzar aquesta arquitectura quan es requereixen tractaments en local, com pot ser la validació d'unes dades. També s'aconsella per a quan l'aplicació no requereix accedir a les dades del servidor en temps real.
3. Streaming
Aquest tipus d'arquitectura es reserva per aplicacions que requereixin "objectes multimèdia". No és una arquitectura gaire utilitzada per les corporacions. La seguretat de les dades depèn de factors externs a l'aplicació, com poden ser els drets digitals de gestió o les xarxes virtuals privades.
Avantatges: És una arquitectura que esta optimitzada per l'enviament de àudio i vídeo a un ampli públic.
Restriccions: Requereix un gran ample de banda, que las xarxes tinguin baixa latència i un processador bastant potent. El cost pot ser significant si la xarxa a de carregar grans paquets de dades.
S'opta per aquesta arquitectura quan necessitem treballar amb àudio i vídeo.
4. Thin Client
Les aplicacions que empren aquesta arquitectura utilitzen un client genèric pre-instal·lat per fer l'aplicació i l’ intèrpret del codi. No tenim dades guardades en el dispositiu excepte les cookies.
Avantatges: Encara es redueix més el TCO (Typical Total Cost of Ownership), perquè ara no tenim ni codi ni dades en el dispositiu. La informació està centralitzada i s'accedeix a ella a través d'un explorador web.
Restriccions: Aquest tipus d'arquitectura requereix d'una bona cobertura de xarxa i amb una baixa latència. El dispositiu ha de tenir pre-instal·lat un explorador o un client flash (no és habitual trobar clients flash en els telèfons mòbils). La utilitat de l'aplicació es inferior que els clients thick o rich. A més tot hi que cada vegada els exploradors estan més estandaritzats pateixen importants variacions en funció dels dispositiu en el qual s'utilitzin.
Es recomana recórrer a aquesta arquitectura quan tenim garantida una bona cobertura. Quan les aplicacions són simples i apropiades per ser executades en un explorador, i les condicions de seguretat són satisfetes mitjançant HTTPS.
5. Messaging
Les aplicacions que treballen sota aquesta arquitectura utilitzen el mail, SMS o IM per enviar informació al dispositiu client. L'usuari pot respondre mitjançant un missatge.
Avantatges: La simplicitat. És una arquitectura que es basa en tecnologia que ja està feta com pot ser el e-mail mòbil i els missatges curts. A més és pot aplicar a qualsevol telèfon mòbil.
Restriccions:És una arquitectura poc útil, donat que l'usuari ha d'indicar les accions amb els missatges SMS. A més no tenim la garantia de que arribin sempre els missatges enviats.
Es recomana aquesta arquitectura quan necessitem realitzar simples transaccions o notificacions. Cal tenir en compte que hi ha un elevat nombre de dispositius clientes no suportats.
6. No client
Consisteix en una arquitectura limitada per aquelles transaccions on el to de trucada o el reconeixement de veus interactives és un model d'interacció vàlid.
No és el que estem buscant per aplicar al projecte.
Un cop analitzades totes les possibilitats i coneixent els requeriments de l’aplicació client penso que la millor opció seria la Rich Client basada en J2ME entre altres raons perquè:
· és la que esta pensada per a tecnologies de la plataforma Java, per tant requerim d’aquesta tecnologia ja que la midlet és una aplicació J2ME.
· La tecnologia J2ME ens permet accedir a les dades de l’usuari del dispositiu mòbil, ja que són les que conté la seva agenda amb les que volem treballar.
· No té exigències amb la cobertura ni la latència de la xarxa.
· Se’ns permet treballar sense cobertura, que és el que ens interessa, ja que només la necessitarem quan requerim dur a terme la sincronització de dades, no necessitem accedir a aquestes en temps real.
· No ens genera la necessitat de tenir un dispositiu mòbil especialment potent ni amb gran quantitat d’espai lliure a la memòria ja que en aquesta guardarem només les dades de configuració necessàries per a que l’aplicació funcioni, un exemple d’aquestes són URL del servidor, username, password d’accés, ... és a dir dades amb poc pes espaial.
