je dois redévelopper une application de gestion pour 100 cliens environ, je
suis allé hier aux webdays 2005 à nantes (bravo d'ailleurs pour leur
prestation), j'étais parti avec un développement accessible sur TSE pour les
100 clients pour éviter les inconvénients de client riche (mise à jour,
version OS...) puis faire quelques pages ASP.NET, mais j'ai vu hier que la
nouvelle plateforme studio proposait des mises à jours vers les clients,
j'hésite donc maintenant à développer un client Riche avec des service Web
pour accéder aux données (en lecture et écriture), le choix est déterminant
pouvez-vous me faire partager votre expériance.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christophe Lauer [MS]
Bonjour,
Boris wrote:
je dois redévelopper une application de gestion pour 100 cliens environ, je suis allé hier aux webdays 2005 à nantes (bravo d'ailleurs pour leur prestation), j'étais parti avec un développement accessible sur TSE pour les 100 clients pour éviter les inconvénients de client riche (mise à jour, version OS...) puis faire quelques pages ASP.NET, mais j'ai vu hier que la nouvelle plateforme studio proposait des mises à jours vers les clients, j'hésite donc maintenant à développer un client Riche avec des service Web pour accéder aux données (en lecture et écriture), le choix est déterminant pouvez-vous me faire partager votre expériance.
Dans votre cas - vous partez d'une feuille blanche et vous n'avez pas à "vivre avec un existant" - j'aurais naturellement tendance à vous orienter vers la développement d'applications .NET de type "client riche" déployables via la technologie ClickOnce, à laquelle vous faites référence.
Ma perception est que Terminal Services prend tout son sens pour rendre utilisable à distance une application qui n'avait pas été prévue pour cet usage lors de sa conception, typiquement les applications Client-Serveur 2 tiers.
Sachez qu'en outre, l'utilisation optimale de Terminal Services suppose de respecter un certain nombre de principes de design, qui sont regroupés dans le document suivant : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service10012002.asp
Vous évoquez 100 clients. Sans doute voudrez-vous étudier le document suivant qui donne des informations de sizing du ou des serveur(s) Terminal Services en fonction du nombre de sessions simultanément ouvertes. 100 sessions simultanées nécessite déjà un "beau" serveur pour encaisser la charge : http://www.microsoft.com/windows2000/techinfo/administration/terminal/tscaling.asp
En outre, l'utilisation de Terminal Services implique pour chaque utilisateur d'acquérir une licence d'accès client au service Terminal Server. Vous voudrez sans doute prendre ceci en compte dans votre étude budgétaire.
Enfin, j'ai bien compris que vous demandiez plutôt des avis et retours d'expérience "terrain" d'utilisateurs et non pas de personnes de Microsoft, mais je pense que ces premiers éléments de réponse pourront permettre d'engager les discussions sur vos interrogations.
Cordialement,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://www.microsoft.com/france/msdn/ This posting is provided "AS IS" with no warranties, and confers no rights.
Bonjour,
Boris wrote:
je dois redévelopper une application de gestion pour 100 cliens
environ, je suis allé hier aux webdays 2005 à nantes (bravo
d'ailleurs pour leur prestation), j'étais parti avec un développement
accessible sur TSE pour les 100 clients pour éviter les inconvénients
de client riche (mise à jour, version OS...) puis faire quelques
pages ASP.NET, mais j'ai vu hier que la nouvelle plateforme studio
proposait des mises à jours vers les clients, j'hésite donc
maintenant à développer un client Riche avec des service Web pour
accéder aux données (en lecture et écriture), le choix est
déterminant pouvez-vous me faire partager votre expériance.
Dans votre cas - vous partez d'une feuille blanche et vous n'avez pas à
"vivre avec un existant" - j'aurais naturellement tendance à vous orienter
vers la développement d'applications .NET de type "client riche" déployables
via la technologie ClickOnce, à laquelle vous faites référence.
Ma perception est que Terminal Services prend tout son sens pour rendre
utilisable à distance une application qui n'avait pas été prévue pour cet
usage lors de sa conception, typiquement les applications Client-Serveur 2
tiers.
Sachez qu'en outre, l'utilisation optimale de Terminal Services suppose de
respecter un certain nombre de principes de design, qui sont regroupés dans
le document suivant :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service10012002.asp
Vous évoquez 100 clients. Sans doute voudrez-vous étudier le document
suivant qui donne des informations de sizing du ou des serveur(s) Terminal
Services en fonction du nombre de sessions simultanément ouvertes. 100
sessions simultanées nécessite déjà un "beau" serveur pour encaisser la
charge :
http://www.microsoft.com/windows2000/techinfo/administration/terminal/tscaling.asp
En outre, l'utilisation de Terminal Services implique pour chaque
utilisateur d'acquérir une licence d'accès client au service Terminal
Server. Vous voudrez sans doute prendre ceci en compte dans votre étude
budgétaire.
Enfin, j'ai bien compris que vous demandiez plutôt des avis et retours
d'expérience "terrain" d'utilisateurs et non pas de personnes de Microsoft,
mais je pense que ces premiers éléments de réponse pourront permettre
d'engager les discussions sur vos interrogations.
Cordialement,
--
Christophe Lauer - Relations Techniques Editeurs de Logiciels
Division Développeurs et Plateforme d'Entreprise - Microsoft France
http://www.microsoft.com/france/msdn/
This posting is provided "AS IS" with no warranties, and confers no
rights.
je dois redévelopper une application de gestion pour 100 cliens environ, je suis allé hier aux webdays 2005 à nantes (bravo d'ailleurs pour leur prestation), j'étais parti avec un développement accessible sur TSE pour les 100 clients pour éviter les inconvénients de client riche (mise à jour, version OS...) puis faire quelques pages ASP.NET, mais j'ai vu hier que la nouvelle plateforme studio proposait des mises à jours vers les clients, j'hésite donc maintenant à développer un client Riche avec des service Web pour accéder aux données (en lecture et écriture), le choix est déterminant pouvez-vous me faire partager votre expériance.
Dans votre cas - vous partez d'une feuille blanche et vous n'avez pas à "vivre avec un existant" - j'aurais naturellement tendance à vous orienter vers la développement d'applications .NET de type "client riche" déployables via la technologie ClickOnce, à laquelle vous faites référence.
Ma perception est que Terminal Services prend tout son sens pour rendre utilisable à distance une application qui n'avait pas été prévue pour cet usage lors de sa conception, typiquement les applications Client-Serveur 2 tiers.
Sachez qu'en outre, l'utilisation optimale de Terminal Services suppose de respecter un certain nombre de principes de design, qui sont regroupés dans le document suivant : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service10012002.asp
Vous évoquez 100 clients. Sans doute voudrez-vous étudier le document suivant qui donne des informations de sizing du ou des serveur(s) Terminal Services en fonction du nombre de sessions simultanément ouvertes. 100 sessions simultanées nécessite déjà un "beau" serveur pour encaisser la charge : http://www.microsoft.com/windows2000/techinfo/administration/terminal/tscaling.asp
En outre, l'utilisation de Terminal Services implique pour chaque utilisateur d'acquérir une licence d'accès client au service Terminal Server. Vous voudrez sans doute prendre ceci en compte dans votre étude budgétaire.
Enfin, j'ai bien compris que vous demandiez plutôt des avis et retours d'expérience "terrain" d'utilisateurs et non pas de personnes de Microsoft, mais je pense que ces premiers éléments de réponse pourront permettre d'engager les discussions sur vos interrogations.
Cordialement,
-- Christophe Lauer - Relations Techniques Editeurs de Logiciels Division Développeurs et Plateforme d'Entreprise - Microsoft France http://www.microsoft.com/france/msdn/ This posting is provided "AS IS" with no warranties, and confers no rights.
