Discussion :

[dracorb]

Bonjour

Je ne sais pas si je suis au bon endroit pour cette question, et je m'en excuse si ce n'est pas le cas.

D'abord, je vais essayer de clarifier le sujet.

Dans le cadre d'un stage, je doit réaliser une interface permettant de faciliter la récupération d'informations concernant des fichiers logs, en partant seulement dans leur nom.
La difficulté réside dans le fait que les logs sont stockées à 2 endroits (très différents):
- le premier est une arborescence UNIX, UNIX étant ouvert via le programme Exceed (Hummingbird)
- le second est un progiciel financier nommé Summit tournant sous Windows (XP en l'occurence)

Pour UNIX, je m'en sors, même si pour le moment l'application se contente d'aller chercher la localisation du fichier (mais bon une fois que je l'ai c'est pas trop dur de récupérer les infos).
Pour Summit, je n'ai pas encore été voir dedans à quoi ça ressemblait vraiment, mais d'après ma responsable de stage c'est du style base de données.

Donc maintenant que j'ai exposé la situation, voici ma question:

Comment faire pour pouvoir récupérer les informations des 2 endroits?

A - Les sources de l'application doivent être dans UNIX et le code devra ouvrir Summit qui est dans Windows
B - L'executable de l'application (et ce qui va avec) doit être dans Windows et le code doit ouvrir Summit et UNIX via Exceed
C - Impossible d'avoir les 2 dans le même programme, il faudra 2 applications
D - La réponse D


Merci d'avance de vos réponses/solutions/conseils (barrer la(les) mention(s) inutile(s))

[dracorb]

Petit up


Si vous pouviez au moins me dire ce qui est faisable ou non dans les 3 solutions évoquées

[michon]

Pour moi le problème n'est pas clair.

Je ne vois pas ce qui empêcherai un programme de récupérer un fichier à la fois sur une machine UNIX et sur une machine Windows...

De plus, que le code soit exécuter depuis UNIX ou Windows, je ne vois pas ce que cela peut changer. Il suffira d'écrire les méthodes de connexion en conséquence, mais tout est faisable.

Car en gros si j'ai bien compris, tu souhaite que ton programme puis se connecter sur une machine UNIX, en récupérer un fichier/donnée , et qu'il puisse aussi se connecter sur une machine Windows pour récupérer la aussi un fichier/donnée ?

[yaraco]

Si tu dois rendre une partie de ton code dépendante de l'environnement, tu peux par exemple utiliser System.getProperty("os.name").

Que ton programme tourne sous Unix ou Windows est indifférent du moment que tu peux accéder à tes fichiers. Ensuite je ne connais pas les logiciels dont tu parles.

[dracorb]

J'ai essayé de faire un schéma sous paint pour faciliter la compréhension



Mon programme se trouve dans l'arborescence UNIX et doit récupérer des informations dans une sous-arborescence de la principale ET dans une table (ou groupe de table) de Summit qui lui se trouve dans Windows XP.
Sachant que j'accède à l'arborescence de UNIX grace à Exceed qui se lance sous Windows XP.

Donc la question:
A - Est-ce que je peux récupérer les informations de la table de Summit sans sortir mon programme de l'arborescence UNIX? (comment?)
B - Je devrais mettre mon programme directement dans Windows XP, auquel cas le code devra lancer Summit et Exceed? (comment?)
C - Il n'est pas possible d'appliquer une des 2 premières propositions, auquel cas il faudra avoir 2 programmes distincts

Voilà, j'espère avoir réussi à clarifier les choses cette fois.

[yaraco]

Malheureusement ce qui n'est pas clair, c'est les logiciels que tu utilises.

C'est quoi ça Summit??? C'est ça? http://www.miesoftware.com/product_overview.cfm

Si on en croit leur site, ça utilise Access. Et se connecter à une base distante ça ne pose pas de problème en java.

Mais vu que j'ai jamais vu ce logiciel, je peux pas en dire plus. Juste qu'à priori, java en lui même ne s'oppose pas à du cross plateforme.

[michon]

?

Ton programme tourne sur ta machine Unix, et tu passe par une appli sur XP pour aller lancer ton prog sur Unix qui doit revenir lire un fichier sur XP ??

A quoi te sert vraiment ce "Exceed" ? Car de ce que tu explique, je n'en voi pas l'interêt...

Si tu exécute ton programme sur Unix, il n'aura aucun mal à aller fouiller une arborescence de ta machine unix, et il suffit donc d'écrire une méthode afin de te connecter sur ta machine XP et de récupérer le fichier / copie de fichier / information que tu souhaite dans tes données de Summit.

Suivant la méthode de stockage dans les fichiers, il se peut même que tu n'es pas besoin de passer par Summit pour en lire les fichiers de données...

Ensuite, peu être une autre idée, mais si tu accède à ton arborescence Unix via Exceed (toujours pas compris pourquoi), n'a tu pas moyen de passer en paramètre le fichier ou la donnée correspondante de Summit ? Comme ca ton programme la récupère comme paramètre, et il n'aura qu'a aller chercher celle se trouvant sur ta machine Unix.

Sinon pour tes questions...

A => Il suffit que ton programme aille lire la fichier data de ton Summit, ou lui demande d'éxecuter une requête suivant comment sont stockés les données (je ne connais pas Summit)

B => Sur Xp ou sur Unix, les deux fonctionneront, suffit d'écrire le code adéquate.

C => tout est possible, tout est réalisable, c'est le jeux de la vie ! euh... de la prog, dsl

[sinok]

Malheureusement ce qui n'est pas clair, c'est les logiciels que tu utilises.

C'est quoi ça Summit??? C'est ça? http://www.miesoftware.com/product_overview.cfm

Si on en croit leur site, ça utilise Access. Et se connecter à une base distante ça ne pose pas de problème en java.

C'est pas vraiment ça comme appli mais plutôt ceci: http://www.misys.com/tcm/markets/otc...ns-summit.html

Et accessoirement le pont odbc:jdbc de java n'est pas effectif sous unix (vu qu'odbc n'est que partiellement implémenté sous unix/linux, et que les drivers access open source, ce n'est pas vraiment ça...).


Pour revenir au cas ci dessus, le but serait d'avoir une interface commune dont le but est de fournir à ton programme les logs sous le bon format.
Puis de créer deux implémentations (ou plus si il y a plus de deux types de sources disponibles) de cette interface, une effectuant les recherches sous unix, l'autre s'occupant d'extraire les logs de Summit au moyen des API fournies par le programme (ce qu'il a l'air de faire)...

[tchize_]

Et accessoirement le pont odbc:jdbc de java n'est pas effectif sous unix (vu qu'odbc n'est que partiellement implémenté sous unix/linux, et que les drivers access open source, ce n'est pas vraiment ça...).

Non ca ne devrais pas poser de problème, car le serveur ODBC qui tournera, il est sous windows, là ou se trouve la table access et où access fournis de son coté un pont odbc:access.

Donc on va avoir, normalement

unix -> jdbc -> driver odbc -> réseau -> serveur ODBC windows -> driver Access windows -> fichier access.

Mais vu q'access lock les fichiers, de toutes facons, vous avez le risque de devoir arrêter votre programme XP le temps d'accéder à la base.

Que dit le vendeur à ce sujet (et vérifiez que la licence d'utilisation vous autorise bien à faire ça)

[dracorb]

Ok alors:

- Summit c'est bien le lien que donne sinok (progiciel financier)
- Exceed je sais pas trop détailler ce que c'est, mais c'est la seule façon disponible d'entrer dans l'arborescence UNIX (que ça soit en manuel ou dans le code)

Ton programme tourne sur ta machine Unix, et tu passe par une appli sur XP pour aller lancer ton prog sur Unix qui doit revenir lire un fichier sur XP ??

Non, le système de base de la machine est Windows XP (au démarrage). De là je peux accéder à l'arborescence UNIX à partir d'Exceed. Mon programme se trouve dans cette arborescence, et lors de la recherche du fichier log, s'il ne l'a pas trouvé dans UNIX, il doit aller chercher dans Summit (qui lui est sous XP).

Suivant la méthode de stockage dans les fichiers, il se peut même que tu n'es pas besoin de passer par Summit pour en lire les fichiers de données...

Faudra que je me renseigne.



Par contre, c'est quoi "odbc", "jdbc" et "API" ?

[tchize_]

Bon alors, on va clarifier: tu as un seul OS et pas deux comme tu nous l'a présenté, avec deux système des fichiers accessibles, vraisemblablement dans C:\ et D:\, l'un surement en FAT32 et l'autre, on va dire en ext3

Exceed est donc juste un driver qui monte la partition en question (qu'elle soit locale ou distante, on s'en tappe).

Ton programme java n'a pas besoin d'être dans l'arborescene linux, t'emmerde pas, garde le coté partition windows t'aura plus facile à le géré. Dans tous les cas, il tourenera sous windows.

Ceci étant dit, la partie log d'un coté est facilé: aller chercher un fichier à un endroit précis. Ca se code en deux coup de cuillère.

La deuxième partie est plus compliquée, tu va devoir accéder à la base de donnée access, donc en utilisant l'api JDBC de java. Pour plus de détails sur JDBC: voir la
et pour access: http://java.developpez.com/faq/jdbc/...ers#accessOdbc

API= Application Programming Interface
ODBC= protocole de communication base de donnée standardisé, principalement sous windiows
JDBC API standard d'accès aux bases de données sous java

[dracorb]

tu as un seul OS et pas deux comme tu nous l'a présenté

Bonne nouvelle ça, reste à trouver où c'est planqué exactement.

Merci

[sinok]

La deuxième partie est plus compliquée, tu va devoir accéder à la base de donnée access, donc en utilisant l'api JDBC de java. Pour plus de détails sur JDBC: voir la
et pour access: http://java.developpez.com/faq/jdbc/...ers#accessOdbc

API= Application Programming Interface
ODBC= protocole de communication base de donnée standardisé, principalement sous windiows
JDBC API standard d'accès aux bases de données sous java

En fait access n'a rien à faire ici. Sa mention vient d'un des posts précédents ou un membre s'est planté sur summit. J'espère bien qu'un sort de finance de marché n'est pas basé sur access...

[tchize_]

ha oui tiens, ben faudra voir quelle base de donnée et ou sont les logs

PS: en fait, ca ne m'étonnerais qu'à moitié vu mon expérience

[sinok]

Mouaif, ça n'en a pas trop la gueule:

• Connectivity - Summit FT’s open architecture, APIs and toolkit enable smooth integration and the ability to easily customise your environment
• Reliability – The high performance distributed processing within Summit allows for deployment of loosely coupled engines for maximum flexibility and resilience
• Flexibility – customisable .NET user interface, Excel integration with open adaptive architecture
• Configurability – Etoolkit for full customisation and APIs for interfacing to inhouse and external systems. We provide many ready-to-use interfaces.
• Scalability – the solution features a distributed architecture optimised for high volume as well as complex calculations.
• Grid enabled - increasing volumes of complex calculations organisations are looking for a resolution for faster answers. Summit’s out-of-the box grid enabled interface with DataSynapse enables results of complex calculations and risk reports to be returned in minutes rather than hours. It speeds-up compute intensive portfolio analytics providing the agility to react to market changes quickly.
• Choice of delivery option - hosted or in house delivery. The Misys Summit ASP provides a high level of customisation yet ensures rapid and efficient delivery along with a predictable price.
• SOA Vision – Our Summit solution offers a range of web services and we are working towards our vision of an SOA architecture for Summit FT to offer even greater flexibility and speed
• Managed hosted - with the Misys Summit ASP you uniquely benefit from a solution proven over 18 years in derivatives and treasury operations – the choice is yours – in-house install or ASP

Ca sent plutôt l'API maison de monitoring.