Discussion :

[xino972]

Bonjour,

Je suis amené à réalisé un projet de gestion au sein d'une petite entreprise.
5/6 utilisateurs de prévus avec une gestion des droits prévue.
L'application est essentiellement constitué de formulaire avec mise à jour des données.Il n'y pas de traitement lourd a faire.


Pour l'instant je réfléchis à l'architecture :


J'ai pensé a j2ee avec 3 les tiers.
J'avais pensé a soit du eclipse rcp/swt ou du swing comme client.

Ma question : je souhaite aller au plus simple donc est ce qu'une application simple client / serveur ne conviendrait pas ou est ce que je dois plutot m'orienter vers du j2ee ?

[*alexandre*]

C'est plus un choix stratégique qu'autre chose, tout dépend comment tu veux projeter ton application dans quelques années.

[Tommy31]

Oui difficile de d'esquisser une réponse convenable sans éléments supplémentaires.

[xino972]

Quels éléments supplémentaires est ce que je dois spécifier ?

[*alexandre*]

Comment est organisé votre SI, les applications sont elles hétérogènes, les serveurs, les bases de données travailler vous avec du .NET du JEE. Quelles sont vos besoins en terme d'accès aux réseaux.

Dois-tu partager un Single Sign On ...

Y a beaucoup de points.

[wiztricks]

Pour 6 utilisateurs, vous n'avez pas de soucis de performance 'à priori', peut être des points d'intégration à un existant, comment sera exploité la chose voire les axes d'évolution à privilégier.

J'opterais plutôt pour une construction légère.
Ruby on Rails, Groovy, les frameworks Pylons/Django sur Python sont peut être des directions à envisager.

- W

[*alexandre*]

Pour 6 utilisateurs, vous n'avez pas de soucis de performance 'à priori', peut être des points d'intégration à un existant, comment sera exploité la chose voire les axes d'évolution à privilégier.

J'opterais plutôt pour une construction légère.
Ruby on Rails, Groovy, les frameworks Pylons/Django sur Python sont peut être des directions à envisager.

- W

Sur quoi tu te bases pour proposer des technos il n'a pas esquisser le SI et les demandes ?

Comment il fera s'il existe dans le SI des applications qui utilisent JPA, JMX et JMS et une architecture SOA qui distribue le traitement sur un filesystem du type Google ou Hadoop pour des batchs nécessitant des traîtements de plus 100'000 fichiers

Tu peux rien proposer sans une description des besoins et de l'architecture de base initiale

[wiztricks]

Sur quoi tu te bases pour proposer des technos il n'a pas esquisser le SI et les demandes ?

Comment il fera s'il existe dans le SI des applications qui utilisent JPA, JMX et JMS et une architecture SOA qui distribue le traitement sur un filesystem du type Google ou Hadoop pour des batchs nécessitant des traîtements de plus 100'000 fichiers

Je n'ai pas proposé de techno bien précise sinon des attributs qu'on retrouve en partie les technos que j'ai cité.

Tu peux rien proposer sans une description des besoins et de l'architecture de base initiale

La description initiale donne quelques indications de dimensionnement et d'intégration qui ne laissent pas supposer qu'on ait des traitements lourds à effectuer. Elles sont bien sur insuffisantes pour un design détaillé mais, il y a assez de points "d'accroches" pour s'amuser à secouer un peu la chose.

En disant "J2EE n'est-ce pas déjà trop lourd?", j'essaie de provoquer une réaction de l'auteur pour qu'il nous éclaire sur certaines omissions.
Mais l'auteur n'est pas joueur ou parti en week end...
Pas grave
- W

[xino972]

Désolé les gars j'étais en vacances.
Bon j'ai suivi la conversation...Ben effectivement peut être que j2EE dans un premier temps c'est lourd mais a vrai dire je n'en sais rien.
Etant donné que le système devra grossir assez rapidement je ne sais pas si c'est un mauvais choix des le départ.

Qu'en pensez vous ?

[wiztricks]

Désolé les gars j'étais en vacances.
Bon j'ai suivi la conversation...Ben effectivement peut être que j2EE dans un premier temps c'est lourd mais a vrai dire je n'en sais rien.
Etant donné que le système devra grossir assez rapidement je ne sais pas si c'est un mauvais choix des le départ.

Qu'en pensez vous ?

C'est une petite boite: chaque euro mal investit met sa vie en danger.

Ce qui à priori ne peut évoluer que lentement est le modèle de donnée et le schéma de la base.
J2EE a une certaine tendance à lier objets métiers à la fonction de persistance qui si on n'y prend garde peut être lourde à faire évoluer.
-W

[*alexandre*]

C'est une petite boite: chaque euro mal investit met sa vie en danger.

Ce qui à priori ne peut évoluer que lentement est le modèle de donnée et le schéma de la base.
J2EE a une certaine tendance à lier objets métiers à la fonction de persistance qui si on n'y prend garde peut être lourde à faire évoluer.
-W

pourquoi donc si tu utilises un ORM la seule chose qui change se sont des entités, les dao ne changent jamais ni les services vu qu'en principe un service est un simple business delegate sur la couche dao ?

[wiztricks]

pourquoi donc si tu utilises un ORM la seule chose qui change se sont des entités, les dao ne changent jamais ni les services vu qu'en principe un service est un simple business delegate sur la couche dao ?

Dans ce modèle le SGDB n'a qu'un composant de la fonction de persistance pour des services métiers. Ca oublie un peu que le SGDB peut faire de nombreuse choses bien plus efficacement que remontant systématiquement tout là haut.
Cela réduit les possibilités d'évolution de la plate-forme...
Ce qui n'est jamais très malin car nous n'avons jamais d'indication fiable sur la durée de vie.

Mais je suis d'accord que dans une logique SSII, livrer rapidement et possibilité d'évolution au delà de 6 à 12 mois ne sont pas des logiques faciles à concilier.
Cela permet aussi de limiter les compétences nécessaires à la réalisation aux savoirs faire Java. Pour le SGDB, on fera du tuning s'il y a des problèmes de performances.
-W

[*alexandre*]

Dans ce modèle le SGDB n'a qu'un composant de la fonction de persistance pour des services métiers. Ca oublie un peu que le SGDB peut faire de nombreuse choses bien plus efficacement que remontant systématiquement tout là haut.
Cela réduit les possibilités d'évolution de la plate-forme...
Ce qui n'est jamais très malin car nous n'avons jamais d'indication fiable sur la durée de vie.

Mais je suis d'accord que dans une logique SSII, livrer rapidement et possibilité d'évolution au delà de 6 à 12 mois ne sont pas des logiques faciles à concilier.
Cela permet aussi de limiter les compétences nécessaires à la réalisation aux savoirs faire Java. Pour le SGDB, on fera du tuning s'il y a des problèmes de performances.
-W

Je vais te choquer mais moi je suis pour l'augmentation de ressources matériels pour ne pas avoir besoin de recourir à des manipulations de plus bas niveau

Ceci afin de garder à l'esprit que les technologies objet reste intacte

[wiztricks]

Je vais te choquer mais moi je suis pour l'augmentation de ressources matériels pour ne pas avoir besoin de recourir à des manipulations de plus bas niveau

Ceci afin de garder à l'esprit que les technologies objet reste intacte

Tu ne me choques pas et nombreux sont ceux qui partagent ton point de vue.

Les anglo-saxons ont un dicton qui me parait approprié:
"When the only tool you have is a hammer, every problem looks like a nail."

-W