Conseil d'architecture SI avec partie mobile

Bonjour,
Je poste ce message dans l'espoir d'avoir quelques conseils sur l'architecture et la faisabilité d'un projet SI d'auto école.


En gros au sein d'une auto école, une base de données regroupe toutes les informations concernant les plannings des élèves et des moniteurs.


L'idée est d'envoyer à chaque fin de journée ou semaine le planning des moniteurs via sms.

Le SI doit permettre également aux moniteurs de valider ou non la présence d'un élève sur la route afin de débiter les heures de cours prises par l'élève.

Je m'y connais en java et là j'attaque tout ce qui est java mobile.
Mes questions :

1) Est ce que ça vous parait jouable ?
2) Par quoi dois je commencer ?
3) Quelle architecture me conseillée vous ?
J'ai lu pas mal de doc et je ne vois pas pas à part le net ou un truc du genre gprs quelle interface réseau utliser pour faire communiquer les mobiles et la base de données du siège de l'auto école.

Merci pour vos réponses et vos conseils.

à part la fonction d'envoi d'sms (si on imagine qu'il faut envoyer de mail par ex) me parait une question simple et classique mais sinon la partie envoi d'sms et plus original et sort du cadre du si pour rentrer dans un cadre de TELECOM donc cette interface pour l'envoi d'sms doit etre fournie par un operateur specialisé en cela de manière à ce que le SI puisse communiquer avec cette interface à travers un WEBservice par exemple .

Utiliser les SMS comme couche de transport est assez original. En supposant qu'on identifie les SMS à interpréter en fonction du numéro d'appel ou de leur format - comment filtrer ceux qui... - enfin pourquoi pas?
Une question peut être le nombre de caractères limités à quelques centaines (je ne sais plus de mémoire mais c'est pas beaucoup).

Est-on aujourd'hui condamné à utiliser une telle couche de transport? Ne peut on pas supposer que les mobiles pourraient utiliser une interface au dessus de TCP/IP que permet d'avoir GPRS/Edge?

Cela permettrait à une application WEB développée pour 'mobile' - avec des contraintes côté interface utilisateur - de s'appuyer sur une couche de services assez 'standard' et utilisable depuis n'importe quel terminal (un PC connecté à Internet par exemple).

Dans ces affaires, le soucis est l'"utilisabilité"(*) de l'interface utilisateur et son éventuelle portabilité sur des environnements d'exploitation différents: il sera difficile de garder le même mobile 'longtemps' et les coûts de tests de l'interface sur des mobiles particuliers doit être raisonnable.
(*) désolé je ne sais pas traduire usuability en français.
-W

d'après mes souvenir, qui datent un peut, tu ne pas pas traiter de sms si celui n'est pas reçu au moment où l'application est ouverte, je veut dire qu'il faut que l'application soit lancé avant l'envoie de sms.

Sinon, tu peut prendre le problème a l'envers, au lieu d'envoyer, tu peut demander au utilisateur de l'application d'aller chercher (il faudra un serveur, ou une page perso par exemple). On reviens sur une connexion http basique avec requête et traitement du résultat.Genre pour chaque séance , aux début, l'utilisateur peut choisir de dire si oui où non l'élève est venue.

Par contre, comme disait wiztricks (enfin si j'ai bien compris) tu peut faire une sorte de site wap, avec par exemple un login et un password pour identifier le moniteur, qui accèderais a son planning, et qui aurai juste un bouton a appuyer pour validé le fait que l'élève soit présent. Cela passerai sur tous les mobiles qui vont sur le wap/web, tu n'aurais pas le coût (temps) du portage sur diffèrent téléphones.

Citation:

---

Envoyé par crazycrow

Par contre, comme disait wiztricks (enfin si j'ai bien compris) tu peut faire une sorte de site wap, avec par exemple un login et un password pour identifier le moniteur, qui accèderais a son planning, et qui aurai juste un bouton a appuyer pour validé le fait que l'élève soit présent. Cela passerai sur tous les mobiles qui vont sur le wap/web, tu n'aurais pas le coût (temps) du portage sur diffèrent téléphones.

---

C'est a peu près çà... Je suis assez vague sur la définition d'une application WEB car tout est dans la répartition des activités faites entre le morceau qui s'exécute sur le mobile et ce qui s'exécute à distance.
Il peut être intéressant d'avoir un minimum d'intelligence locale: pas la peine de se connecter tout le temps pour rapporter les élèves, récupérer le planning de la semaine. D'autant que nous avons beaucoup de capacités de calcul et de stockage 'en local'.
Puisque nous sommes en Europe, Nokia propose Qt comme IDE (iPhone c'est Objective-C), d'autre c'est je ne sais quoi d'autre.
Après on peut tenter WAP mais çà ne tient pas encore toutes ses promesses: d'un téléphone à l'autre les différences sont subtiles et côté IHM ça coûte.
Pas facile de faire un choix sans trop fermer les mobiles supportés, les possibilités de l'IHM, la perénité des technologies utilisées,...
- W

salut,

amha, le principal souci auquel tu devras faire face sont les soucis d'incompatibilités entre les différents téléphones J2ME.

Donc si ton projet est spécifique à une auto-école bien précise, et que tu optes pour un 'client lourd' en J2ME, imposer l'utilisation d'un unique modèle de téléphone te ferait économiser énormément de temps de développement.

Pour les moyens de communication, tout dépend si:
- tu veux obligatoirement du push (ie. que les utilisateurs de téléphone soient prévenus dès qu'une nouvelle info est dispo)
- ou si un principe de polling: les utilisateurs iront plus ou moins régulièrement vérifier s'ils ont de nouvelles infos.

Si le principe du polling est acceptable et que tu choisis des téléphones relativement récents et qui ont un navigateur web, un simple site web dynamique (en PHP, J2EE ou autre) serait amha très rapide à coder et probablement plus 'portable' d'un téléphone à un autre : à partir du moment ou le téléphone est assez récent pour intégrer un browser web et que les pages du site sont basiques (HTML pur), n'importe quel téléphone pourrait faire l'affaire.

Enfin, question coût, un simple accès 'DATA' (GPRS, EDGE, 3G) au net n'est plus très chère comparée aux SMS. Elle permet plus de choses (cf. limitation taille d'un SMS), réutilisation de technos 'standards' (XML, ...) et nécessitera à coup sûr beaucoup moins d'effort de développement.

nounouk est allé trop loin un client lourd J2ME et un accès DATA sur les mobile de l'auto ecole cela suppose que les mobiles ont accès DATA de type gprs edge voir 3G, moi pour une entreprise comme l'auto ecole j'opterai plus pour les sms en plus normalement il y des operateur qui offre la possibilté d'utiliser leur interface de type webservice pour envoyer des sms moyenant un tarif bien sure . donc il suffit que le systeme de 'lautoecole utilise ses xebservice pour envoyer ses messages

J'ai attendu d'avoir les réponses mais je les ai eues donc merci.

Le but de la partie est vraiment de faire au plus simple et évidemment au moins cher.
L'efficacité est le maitre mot.Pour les mobiles, pas de contrainte particulère, effectivement le donneur d'ordres est pret à mettre le prix pour l'achat d'un ensemble de terminaux identiques.

wiztricks, tu dis qu'utiliser les SMS comme couche transport est original.
Qu'entends tu par là ? Est ce que tu veux dire que c'est pas très malin ou est ce vraiment original dans le sens premier du terme ?

Citation:

---

Envoyé par xino972

wiztricks, tu dis qu'utiliser les SMS comme couche transport est original.
Qu'entends tu par là ? Est ce que tu veux dire que c'est pas très malin ou est ce vraiment original dans le sens premier du terme ?

---

Je pense qu'il voulait dire que a complexifiait les choses. Si mes souvenirs sont bons:

- ça implique que ton serveur central devra émettre des SMS, et donc tu devras souscrire à une offre d'un prestataire tiers pour pouvoir le faire

- ça implique que ton logiciel sera capable de récupérer les SMS reus par le téléphone pour les traiter et donc te guide vers un modèle en 'push' (plus contraignant même si pas impossible, sauf en J2ME).

- a risque de poser des limitations et une complexification de l'implémentation, notamment (mais pas seulement) du fait des contraintes inhérentes à la technologie SMS elle-même (taille des messages par exemple).

D'une faon générale, si tu peux toi-même choisir les terminaux, nul doute que tu pourras choisir parmis ceux qui permettent d'avoir un accès 'data' et donc communiquer via le réseau comme tu le ferais sur n'importe quel réseau IP standard (internet, ...). Ca offrira amha beaucoup plus de souplesse et une plus grande facilité de développement (donc rapidité, donc coût moindre).

Ok.Merci pour toutes ces précisions très intéressantes.
Je suis en pleine réflexion.Le projet doit normalement démarrer courant Janvier.