Discussion :

[ttamttam]

Bonjour,
Je viens récemment de terminer mon service servant à :
- rappatrier un fichier de gestion de personnel depuis un serveur distant
- créer un parseur capable et conserver seulement les informations et non les caractères spéciaux
- lancer un SQL LOADER pour faire un insertion dans une base de donnée Oracle
- éxécuter une instruction MERGE pour mettre à jour ou insérer les données parsées depuis ma table temporaire vers ma table principale
Et voila
Donc maintenant je dois créer un programme capable de paramétrer se service(par exemple: choisir quel fichier je veux rappatrier, modifier le fichier de controle du SQL LOADER,...) En clair je dois quasiment gérer tout les paramètres de mon application et je ne sais pas par où commencer à chercher et ou chercher.
Si quelqu'un a des connaissances ou des tuyaux, je suis très preneurs !

[ced600]

va falloir être plus précis sur ce que tu veux faire, parce que là je ne sais pas ce que tu attends comme info.

[DrZoune]

bonjour, je travaille avec ttamttam sur ce projet, je connait donc les besoins:

il s'agit de créer une IHM permettant à un utilisateur de modifier certaines variables à l'intérieur du service windows(qui s'exécute toutes les 6heures), par exemple:
l'utilisateur rentre dans une textbox l'adresse du fichier à rappatrier via ftp et la valeur de la variable 'fich_uri' est modifiée directement dans le service

Le truc c'est que nous ne savons pas du tout comment nous y prendre et par où commencer , c'est pourquoi nos explications ne sont peut être pas très claires...

[Bluedeep]

Exposer une interface WCF dans le service, c'est de loin le plus simple.

[ced600]

Bon il y a deux ou trois post qui circule sur la communication inter-process sur le forum, ils devraient encore être sur la première page.
Regardez les, vous verrez des choses qui vous intéresse.

J'ai été à votre place (besoin de communiquer entre un service et une application) mais finalement pour différentes raisons, cela ne s'est pas fait.
A l'époque j'avais estimé que la meilleur façon de faire pour moi, serait d'ouvrir un port sur lequel écouterais le service, et un autre surlequel il enverrais des donnés.
De même pour l'autre application.
Bien sur pour communiquer, l'un des softs envois les donnés sur le port d'écoute de l'autre, et pour la réponse on fait l'inverse sur les deux autres ports.

Pour ouvrir les ports j'aurais utiliser les Sockets (je ne sais pas où ils sont dans les versions récentes de .net mais sur les autres sujets on en parle).

Après pour l'échange d'information, il faut choisir un protocole de communication pour échanger les données. Vous pouvez prendre TCP/IP, SIP, ou tout autre protocole qui serait adapté à votre besoin.

[ced600]

Exposer une interface WCF dans le service, c'est de loin le plus simple.

Connais pas. MS à l'air d'avoir fait pas mal de chose coté service depuis la version 1.1 du framework.

[Bluedeep]

J'ai fait un raccourci : en gros, il expose ses méthodes d'administration, les décrits dans une interface, mets les attributs ServiceContract sur l'interface et ServiceBehavior sur l'implémentation, puis il fait le client qui connecte le service et appel les méthodes en question.

[ced600]

J'ai fait un raccourci : en gros, il expose ses méthodes d'administration, les décrits dans une interface, mets les attributs ServiceContract sur l'interface et ServiceBehavior sur l'implémentation, puis il fait le client qui connecte le service et appel les méthodes en question.

Un peu comme un objet com en fait ?

[Bluedeep]

Un peu comme un objet com en fait ?

Euh ... non, c'est du WCF, pas du COM.

Tu peux le faire aussi en Remoting, mais c'est un peu plus lourd.

[The_badger_man]

C'est comme un web service qui tournerait au sein de ton service.

[ced600]

C'est comme un web service qui tournerait au sein de ton service.

Ok parfait, très intéressant, je n'ai pas besoin de faire de service pour l'instant mais je note dans un coin que WCF (World Championship FofoBestWriter ) existe pour plus tard.

[ttamttam]

Nous revoila,
on vient d'avoir une réunion avec notre chef de projet et il nous a expliqué ce qu'il attendait de nous !
en fait on doit faire deux programmes distincts : notre service et notre application de paramétrage !
La relation entre les deux sera un fichier XML qui sera généré et modifiable par notre appli de paramétrage et notre service chargera à intervale régulié les données du fichier XML.
Tous les paramètres de notre service doivent etre modifiables (url du serveur de rapatriement du fichier, nom du fichier à rapatrier, fichier de controle du SQL loader, timer d'éxécution du service et du parçage du fichier,...)
Le fichier XML contiendra tous les paramètres de notre service.
Si vous aviez des suggestions et ou des orientations de tuto et autres, nous sommes tout ouïes

[ced600]

Suggestion :
XPath pour la gestion de votre fichier xml. Et le liens pour plus de requêtes : http://jerome.developpez.com/xmlxsl/xpath/?lpage=paths

Pour l'utilisation de votre fichier par vos deux applications : ATTENTION à la tentative d'accés au fichier par vos deux applications.

Ma suggestions du jour :
Utilisé FileSystemWatcher, dans le service, pour surveiller la présence ou non du fichier dans un répertoire.
S'il est présent le service le parse et lit les informations qu'il contient sinon il ne fait rien.
S'il est modifié, il fait une mise à jour.
De l'autre coté votre application de configuration crée un nouveau fichier temporaire dans un répertorie temporaire, et une fois que l'utilisateur à fini ses modifications (il fait un save), votre application remplace le fichier xml surveiller par le service par ce nouveau fichier.

[Bluedeep]

Nous revoila,
on vient d'avoir une réunion avec notre chef de projet et il nous a expliqué ce qu'il attendait de nous !
en fait on doit faire deux programmes distincts : notre service et notre application de paramétrage !
La relation entre les deux sera un fichier XML qui sera généré et modifiable par notre appli de paramétrage et notre service chargera à intervale régulié les données du fichier XML.

Curieux choix. Pourquoi ne pas modifier en temps réel les propriétés du service ?

[ttamttam]

C'est notre chef de projet qui nous l'impose donc a pô le choix !
Le service doit tourner tout le temps, on ne doit pas l'arréter pour modifier les paramètres, tout doit pouvoir tourner en meme temps et prendre les modifications en compte en temps réel, du moins quand le timer le dira.
Car il nous faut un timer pour le chargement des données par le service et un timer pour le chargement de tout le service, sachant que les deux ne devant pas s'effectuer en meme temps.

[Bluedeep]

C'est notre chef de projet qui nous l'impose donc a pô le choix !
Le service doit tourner tout le temps, on ne doit pas l'arréter pour modifier les paramètres,

Ca c'est logique, mais le passage de paramètres par chargement régulier d'un fichier Xml me semble inutilement lourd.

Car il nous faut un timer pour le chargement des données par le service et un timer pour le chargement de tout le service, sachant que les deux ne devant pas s'effectuer en meme temps.

Manifestement votre CP ne maitrise pas bien les arcannes des articulations WCF/Services.

[ttamttam]

Manifestement votre CP ne maitrise pas bien les arcannes des articulations WCF/Services.

Tu as peut etre raison mais je ne sais pas vraiment par ou commencer.
Je viens de lire un tuto sur XML car je ne la maitrise pas forcément bien et donc je viens de créer un fichier avec tous les paramètres de notre service.
Si tu as des pistes à nous indiquer ou des conseils !

[ttamttam]

Merci ced600, j'avais pas vu ton post et il est ce qu'il nous fallait pour nous diriger dans notre developpement.
(DrZoune est tombé amoureux de toi )
On va étudier ca à fond.

[ced600]

Curieux choix. Pourquoi ne pas modifier en temps réel les propriétés du service ?

Aucun accés au service depuis l'extérieur, les possibilités de piratage du service devienne limité par exemple.
Ainsi on ne peut pas détourner l'utilisation du service, tout ce que l'on peut faire c'est jouer avec sa configuration, mais s'il est bien développé, il ne pourra rien faire d'imprévu.

Bon ok avec WCF si tu n'expose que les propriétés du service, alors tu n'as pas trop de problème.

Mais en fait je comparais avec mon autre idée de faire du TCP/IP.

[ced600]

Merci ced600, j'avais pas vu ton post et il est ce qu'il nous fallait pour nous diriger dans notre developpement.
(DrZoune est tombé amoureux de toi )
On va étudier ca à fond.

lol

Je sais cela fait celà avec tout le monde, comment ne pas tomber amoureux d'un dieu
Boum !!!! -> ça c'est la tête qui explose

Nan juste que j'ai déjà pensé à ce genre de solution car j'ai été proche de devoir faire quelque chose dans le genre.

Mais vu de la description du WCF que propose Bluedeep, je ne pense pasque cela sera plus bloquant que l'utilisation de fichier XML.
En effet dans les deux cas, tu devra mettre ton application en pause 1 seconde le temps de prendre en compte les nouvelles valeur.

Dans le cas de WCF, il suffirait que tu expose une seule méthode update qui prend en paramètre une liste comprenant tes valeurs.
Ton application de configurations se chargera de créer la liste et d'appeler la méthode update du service.

En utilisant par exemple le state design pattern (patron de conception) sur ton service, et les events, tu pourras dans update mettre en état pause ton service, modifier tes paramètres, et remettre en route le service.
Je pense même que cela sera plus rapide coté service qu'avec le fichier xml car tu n'aura pas à ouvrir un fichier xml et le parser (ce qui est long je le constate car je parse actuellement un petit fichier xml).
Cela ne devrait pas prendre plus d'une seconde de traitement avec WCF.

Bref je te conseille de te renseigner sur les deux idées et de voir ce qui est le mieux pour votre cas, quitte à aller devoir convaincre ton CP d'utiliser le WCF.
(Un ensemble de transparent expliquant la techno, et son interet pour votre porjet, et une comparaison à l'autre méthode vous permettra de le convaincre )