Conseils pour une application Java ( client/serveur )

Bonjour, je me tourne vers vous afin d'avoir des conseils pour le développement d'une application. Je ne demande pas de code ni application toute faite, mais bien avoir des conseils.

L'idée générale :
Un poste est connecté à un réseau privé ( type intranet ), l'utilisateur souhaite obtenir des fichiers sur un second poste connecté sur le même réseau privé.
Le hic est que le poste 1 ne peut se connecter au poste 2 et inversement. Ces deux postes se trouvant sur un sous réseau différent

Pour réaliser ce projet, il y a un serveur central qui lui a accès aux deux postes.

Il faut ici que le poste un fasse une demande au serveur, que le serveur copie les fichiers depuis le poste deux puis les recopie sur le poste un.

Le tout est réalisé en JAVA.

--------------

Question : Comment concevriez vous ce type de projet ?

Merci pour vos conseils.

Comme tu en dis peu, je vais supposer que c'est pour une application "sérieuse", au sens où il faut se poser des questions sur la sécurité, la charge réseau, la charge de la machine

Conseils de base:
chaque demande est numérotée avec un UUID (id unique)
l'utilisateur est identifié. L'ip de la machine suffit elle?
comment gères tu la défaillance de la machine centrale? Si elle ne répond pas, tu fais quoi?


Vérifier la sécurité:
pour une demande, il doit être possible de voir que son fichier. Pas de répertoire partagé où tout le monde met son petit fichier que tout le monde peut lire
quels types de fichier autoriser?

Maintenance:
un fichier est disponible k minutes, et pas plus, pour ne pas surcharger le serveur central.

Réseau:
les fichiers peuvent être zippés pendant l'envoi
test de checksum à l'arrivée?

Voilà... Peux tu nous en dire plus?

réponse d'entreprise: je vais voir dans les très nombreuses solutions de collaborations qui existent déjà si une de ces solution de partage de connaissances / fichiers ne suffit pas à mes besoins et j'économise des semaines de dev à mon patron :)

Citation:

---

Envoyé par tchize_

réponse d'entreprise: je vais voir dans les très nombreuses solutions de collaborations qui existent déjà si une de ces solution de partage de connaissances / fichiers ne suffit pas à mes besoins et j'économise des semaines de dev à mon patron :)

---

réponse de développeur: je vais voir dans les très nombreuses solutions de collaborations qui existent déjà si une de ces solution de partage de connaissances / fichiers ne suffit pas à mes besoins et je pars en vacances.:mouarf:

Citation:

---

Envoyé par tchize_

réponse d'entreprise: je vais voir dans les très nombreuses solutions de collaborations qui existent déjà si une de ces solution de partage de connaissances / fichiers ne suffit pas à mes besoins et j'économise des semaines de dev à mon patron :)

---

:ccool:
Mais j'ai une question: si un dev interne coute moins cher, maintenance incluse, que recommandes tu?

Citation:

---

Envoyé par rmaker

Comme tu en dis peu, je vais supposer que c'est pour une application "sérieuse", au sens où il faut se poser des questions sur la sécurité, la charge réseau, la charge de la machine

Conseils de base:
chaque demande est numérotée avec un UUID (id unique)
l'utilisateur est identifié. L'ip de la machine suffit elle?
comment gères tu la défaillance de la machine centrale? Si elle ne répond pas, tu fais quoi?


Vérifier la sécurité:
pour une demande, il doit être possible de voir que son fichier. Pas de répertoire partagé où tout le monde met son petit fichier que tout le monde peut lire
quels types de fichier autoriser?

Maintenance:
un fichier est disponible k minutes, et pas plus, pour ne pas surcharger le serveur central.

Réseau:
les fichiers peuvent être zippés pendant l'envoi
test de checksum à l'arrivée?

Voilà... Peux tu nous en dire plus?

---

Merci pour cette première réponse, et pour répondre à tes questions :
L'adresse IP est suffisante pour identifier l'utilisateur. Quant à la défaillance de la machine centrale, ben si elle n'est pas disponible, l'utilisateur contactera un technicien sur place.

L'utilisateur va demander un nom de dossier au serveur, il n'a pas besoin de voir le reste des dossiers/fichiers. C'est le serveur qui sait où il doit chercher.
Exemple : dossier 1234_DOSSIER où 1234 correspond au numéro de la machine et _ DOSSIER au dossier demandé.
Les utilisateurs ont la liste des numéros de machine après il reste que le nom du dossier qu'ils connaissent aussi.

On peut faire une demande de dossier mais pas en mettre c'est à sens unique.

Pour la disponibilité des fichiers, il reste disponible 24/24 7/7 ...

Pour l'idée de zipper les fichiers avant oui effectivement ca peut simplifier le travail.

Il également que je garde une trace des actions, qui a demandé quoi et quand ... faut que je logs tout.

Citation:

---

Envoyé par tchize_

réponse d'entreprise: je vais voir dans les très nombreuses solutions de collaborations qui existent déjà si une de ces solution de partage de connaissances / fichiers ne suffit pas à mes besoins et j'économise des semaines de dev à mon patron :)

---

Faire faire des économies à mon patron boué , mais de tête comme ca vois tu une "solution de collaboration qui existe déjà" ? :p

Citation:

---

Envoyé par professeur shadoko

réponse de développeur: je vais voir dans les très nombreuses solutions de collaborations qui existent déjà si une de ces solution de partage de connaissances / fichiers ne suffit pas à mes besoins et je pars en vacances.:mouarf:

---

Partir en vacances la je dis oui !! mais même chose de tête comme ca vois tu une "solution de collaboration qui existe déjà" ? :p

Citation:

---

Envoyé par rmaker

:ccool:
Mais j'ai une question: si un dev interne coute moins cher, maintenance incluse, que recommandes tu?

---

De vérifier si ça va vraiment couter moin cher.

Un dev interne, ça coute en moyenne, là ou je suis, ~5000€/mois (salaire, chauffage, bureau, matériel, primes, impots, onss). Donc deux semaines de dev, ça reviens à payer 2000€. Donc en fait, il faudrait plutot voir avec les services concernés en leur disant "au fai, ca va couter 2000€ pour résoudre ce problème, on le fait"? En général t'aura un management qui va dire "2000€ juste parce qu'il ne veulent pas un simple disque partagé sur un serveur? C'est non" :)


Entre ça, et passer 1 semaine à configurer une solution open source ou commercial qui possède l'avantage d'avoir déjà été bien testée, en général, y a pas photo.

Par expérience, en général, le bon développeur doué a deux sales habitudes:
1) il sous estime le travail requis (oubli de tenir compte du temps de déploiement, du temps de formations des utilisateurs, des bugs, des coûts de maintenance pour des bugs obscurs qu'on découvrira dans 3 mois, du temps qu'il va bouffer à ces collègues de la production pour faire telle ou telle configuration sur le serveur)
2) de penser immédiatement "comment je construit une application pour résoudre ce besoin" au lieu de passer par la case "tri des besoins par priorité" et "évaluation des solutions commerciales" :)

Pour les solutions collaboratives qui existent:

-> Un simple serveur de fichier type windows avec des partages que les gens montent => Tous les dossiers sont accessibles à tout le monde (c'est bêtement comme ça que collaborent une bonne partie de nos équipes ici)
-> Des serveur un peux plus évolués type groupware
-> Des système de documentation partagée en ligne type wiki ou type googledoc
-> Des suites de collaboration type microsoft sharepoint (payant), alfreso (open source), liferay, ...

Bref, en passant une journée à chercher, on trouve pas mal de solution :)