Discussion :

[Battant]

Bonjour,

Peut-être connaissez-vous le podcast nipdev de la communauté niptech. Je l'ai découvert sur ituns.

Dans ce cadre là, j'ai entendu parlé d'application réactive.

Voici le lien pour ceux que ça intéresse.

Épisode consacré aux applications réactives.

http://nipcast.com/nipdev-13-les-app...ons-reactives/

podcast nipdev

http://nipcast.com/category/nipdev/

Ce concept m'a l'aire assez séduisant et semble aller plus loin que le multi threding ou la gestion d'événement.

Formé en java, je pensait appliquer une partie de ces concept dans ma prochaine application de gestion de facturation de rendez-vous ou encore dans mon une prochaine version de mon application de gestion d'un commerce d'abricot.

Questions

Le fait d'utiliser des api de type réactive application, est-ce une manière d'optimiser le programme ?

A propos, d'optimisation, on m'a conseiller de profiler mon programme mais comment faire ça le plus simplement dans la dernière version d'eclipse ?

Je prévoyait aussi utiliser un système de classe ORM pour gérer la base de donnée. Une classe par table.

Mais en fait quelles sont les avantages et inconvénients de tout ça ?

Merci de me répondre.

S'ils fréquentent ce forum, je salue bien Fabrice oiseau ainsi que toute la communauté nipdev.et je les remercie pour ce sujet très intéressants.Je l'invite aussi à me répondre.

Salutations à tous,

[Battant]

Bonjour,

Voici un résumé de ce que j'ai trouvé au sujet des applications réactivent

http://nipcast.com/nipdev-13-les-app...ons-reactives/


Spécialisent java, je ne suis pas formé en scala. Il semble toutefois qu'il s'agit d'un mélange entre python et java un peu comme jython.

Puis-je faire des applications réactive avec akka en utilisant java ou faut-il utiliser Rex


http://github.com/Netflix/RxJava

Est-ce que quelqu'un a déjà utiliser cet api.

Est-ce simple ?

où trouver des exemples ?

Merci de me répondre

Salutations

[Sebajuste]

L'application réactive est avant tout un paradigme (qui n'a rien de nouveau d'ailleurs), aussi il n'est pas spécialement lié à un framework.

Il est tout à fait possible de faire du réactif avec du Java "de base".
A mon sens, il a deux avantages :
- diminuer le nombre de thread (1 thread = 1 tâche est une manière de faire complètement obsolète)
- Obtenir des applications en temps réel relatif. C'est à dire qu'on ne peut pas assurer que la réponse sera obtenue en moins de x millisecondes, mais qu'elle sera traitée au plus tôt.

Pour la gestion des threads, je prendrais l'exemple des socket.

En java, les "Socket" sont bloquant. Créer un serveur avec des Socket de base nécessite de faire 1 thread par client connecté. Avec java.nio on peut passer par des Selector : un objet qui retourne uniquement les sockets ayant quelque chose à faire : un seul et unique thread estalors nécéssaire, quelque soit le nombre de client.

Avec JEE, les serveurs d'applications utilisent déjà ces outils. Le serveur dispose alors d'un pool de thread (un petit nombre, quelques dizaines grand maximum). Chaque nouvelle requète sera traité par un thread libre du pool.
Il faut donc voir les appels de nos EJB, Servlet... comme des évènements. Ce qui signifie aussi que ces évènements doivnet être très court : si tous les thread du pool sont utilisés, les autres "évènements" (les autres requètes HTTP) seront mise en attente.

L'idée est donc de découper un traitement de requête en plusieurs traitement, pouvant être parallélisé :
- soit les traitement peuvent d'exécuter en parallèle
- soit les traitements sont séquentiels; à ce moment chaque traitement bloquant (ex: utilisation de la base de données) sera traité par un nouveau thread. Le thread appelant pouvant alors être "libéré"; c'est à dire qu'il va pouvoir se terminer rapidement, afin de traiter une nouvelle requète.

Les dernières version de JEE gèrent les appel de bean dans d'autres thread par le biais de l'annotation @Asynchronous, et du retour de méthode avec l'objet Future<>. Ont peut également créer des pool de thread directement dans le serveur d'application (comme une connexion à une base de données) que l'on récupère dans notre programme avec JNDI, et les annotations de types @Resource


La véritable difficulté technique il me semble, et de créer un callback de retour d'information asynchrone sur le client. Si le client est une page web, utilisant javascript et Ajax, le callback de retour sera celui de la requète HTTP. Or, si le serveur traite la requète par plusieurs thread consécutif, le retour du premier appel sera certes très rapide (le serveur ne gardant pas la mail, et délègue le traitement), mais la réponse ne sera tout simplement pas prête !

Il faudrait donc faire des requêtes à interval régulière, pour savoir si la réponse est prête. En plus d'être peu performant, il est alors nécessaire de distinguer chaque couple requète/réponse par un système d'ID : si une réponse est prête, il faut se souvenir de quelle requête elle est issue.


Le moyen le plus performant à mon avis reste les websocket : les requètes / réponses sont envoyées et reçus immédiatement par un "flux", et non par des multitudes de requêtes.
De plus, les flux de données sont particulièrement adaptés aux applications réactives : si la réponse contient des centaines de résultats, sans liens spécifiques entre entre eux, on peut commencer à renvoyer les premiers résultats générés, alors que le traitement coté serveur n'est pas encore terminé.

[Tcharl]

+ 1 pour Websocket.

Intra Appli, tu peux aussi utiliser du JMS et un concept de bus de message (tous les messages transitent par un et un seul broker, te permettant de monitorer le tout/greffer des traitements globaux.
Chacun de ces messages, qu'ils soient JMS/Websocket sont transformés par par le broker pour être écouté par un protocole où l'autre (comme ça, pas d'ennui de conversion de message).
Tu peux aussi utiliser des EIP ( patterns d'intégration d'entreprise) pour router tes messages (voir Apache Camel).

Bref le but est de rester asynchrone sur toute ta stack: aux niveau des E/S (nio2/streams/Futures), services (JMS/STOMP over Websocket (ActiveMQ)), etc... Et de tout découpler en microservices autonomes et sans états (Stateless) pour augmenter les opportunités de parallèlisation et de réutilisabilité.

[Battant]

Bonjour,

Vous parlez de Serveur ça tombe bien puisque j'en ai un pour pouvoir charger de réceptionner les message qu'il soit d'erreur et autre d'un programme.

Voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
 
package debugserver;
import java.awt.*;
 
import javax.swing.*;
 
import abricotshopmanager.AbricoshopManager;
 
import java.net.*;
import java.io.*;
import java.text.DateFormat;
import java.util.*;
 
 
 
 
public class Server {
  final static int PORT = 4321;
 
  static Socket service;
 
 
  public Server () { 
 
	  init();
  }
 
 
 
 
  private void init() {
 
 
    	Dimension dimScrean = Toolkit.getDefaultToolkit().getScreenSize();
    	JFrame server = new JFrame("server");
    	server.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
    	server.setSize(150,0);
    	// Mettre la fenêtre en bas à droite
    	server.setLocation(dimScrean.width - server.getWidth(),dimScrean.height - server.getHeight());
 
    	server.setVisible(true);
      // préparation du serveur
      // réseau
 
	  try {
 
	  ServerSocket ecoute = new ServerSocket(PORT);
 
	  while (true) {
	        service = ecoute.accept();
	        Thread serviceThread = new Thread (new ServiceThread() );
	        serviceThread.start();
	        serviceThread.setName("connect thread");
	      }      
 
 
      }
 
 
    catch (BindException be) {
    	System.err.println("Le serveur a quitter car un autre et déjà en utilisation");
    	System.exit(-1);
    }  
    catch (IOException ioe) {
      System.err.println(("Problème au niveau du serveur : "+ ioe.getMessage()) + "il est : "+formateDate() );
      ioe.printStackTrace();
    }
  }
 
 
 
 
 
/**
 * Cette méthode créer et formate la date du jour
 @return String
 */
 static String formateDate() {
	  TimeZone tz =  TimeZone.getTimeZone("Europe/Paris");
 
  Calendar calendar = Calendar.getInstance(tz);
  Date date = new Date();
      TimeZone.setDefault(TimeZone.getTimeZone("Europe/Paris"));
      calendar.setTime(date);
      DateFormat df = DateFormat.getDateInstance(DateFormat.SHORT, Locale.FRENCH);
 
	return ("Report_"+df.format(date)+" "+calendar.get(Calendar.HOUR_OF_DAY)+'_'+calendar.get(Calendar.MINUTE)+'_'+ calendar.get(Calendar.SECOND)+".log").replace('/', '_');
 
 
}
 
 
  public static void main (String [] args) {
    new Server();
  }
 
}
class ServiceThread implements Runnable {
 
	public void run() {
		// TODO Auto-generated method stub
		 BufferedReader rd;
		 String message;
		 try {
			 rd = new BufferedReader(new InputStreamReader(Server. service.
			getInputStream()));
			 System.out.println("Nouvelle connection à : "+Server.formateDate());
 
			 while ( (message = rd.readLine()) != null) {
				 writeInfile(message);
 
 
	  }
	} 
		 catch (IOException ioe) {
			 System.out.println("Le client a quitté : "+Server. formateDate());   
			 if (! ioe.getMessage().contains("reset")) {
				 System.err.println("L'erreur suivante s'est produite à  :"+Server.formateDate()+" \n le message est :"+ ioe.getMessage());
				 ioe.printStackTrace();  
		 	}
		}
	}
 
	private synchronized void writeInfile (String message) {
				 String messgage = null;
 
				File fileErrorOutput = new File (Server.formateDate());
				FileOutputStream fileError = null;
				PrintStream fosErrorSender = null;
 
		try {
			fileError = new FileOutputStream(fileErrorOutput,true);
			fosErrorSender = new PrintStream(fileErrorOutput);
 
	          System.out.println(new String("Nouveau message  +" +
                      fileErrorOutput.getName()));
fosErrorSender.println(message);
System.out.println(message);
fosErrorSender.flush();
		}
		catch (IOException ioe) {
			System.err.println("Imposible d'écrire dans le fichier de log "+fileErrorOutput.getName() + "il est : "+formateDate() + "Message : "+ioe.getMessage());
			ioe.printStackTrace();
		}
 
		finally {
			try {
				fosErrorSender.close();
 
				fileError.close();
 
				if (fileErrorOutput.length() == 0) { // aucune erreur n'est survenue
					fileErrorOutput.delete();
					System.out.println("Le fichier a été supprimé");
					}
				}
			catch (FileNotFoundException fne) {
				System.err.println("Le fichier : " + fileErrorOutput.getName() +" N'a pas été trouvé dans le répertoire du serveur.  Il est :" + Server.formateDate()+ "Message : "+fne.getMessage() );
			}
			catch (IOException ioe) {
				System.err.println("Un problème est survenu lors de l'écriture dans le ficher : "+fileErrorOutput.getName());
				ioe.getStackTrace();
				}
		}	
 
 
	}
 
    public static String formateDate() {
  		  TimeZone tz =  TimeZone.getTimeZone("Europe/Paris");
 
  	  Calendar calendar = Calendar.getInstance(tz);
  	  java.util.Date date = new java.util.Date();
 
  	      TimeZone.setDefault(tz);
 
  	      calendar.setTime(date);
 
  	      DateFormat df = DateFormat.getDateInstance(DateFormat.SHORT, Locale.FRENCH);
  	      if (AbricoshopManager.isDebug()) {
  			   System.out.println("Retourner une date formatée.");
  		   }
 
  		return (df.format(date)+" "+calendar.get(Calendar.HOUR_OF_DAY)+'_'+calendar.get(Calendar.MINUTE)+'_'+ calendar.get(Calendar.SECOND));
 
 
  	}
}

Qu'est-ce que ce code vous inspire ?

Comment peut-on modifier ce code pour le rendre ce code réacrtif.

A mon avis, le principal problème ce situe au niveau des while (true)

J'aurais voulus mettree des événement à la réception de lla requête du programme client.sachant que ce programme utilise le protocole tcp avec des streem et non des datagramepacket.


Les deux code que j'aimerais mettre en événement ou réactif et que j'estime bloquant.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
	  ServerSocket ecoute = new ServerSocket(PORT);
 
	  while (true) {
	        service = ecoute.accept();
	        Thread serviceThread = new Thread (new ServiceThread() );
	        serviceThread.start();
	        serviceThread.setName("connect thread");
	      }

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
			 while ( (message = rd.readLine()) != null) {

Quel est votre avis là dessus ?

Merci pour votre aide.

Salutations

[Tcharl]

Re-,

Pourquoi as-tu une architecture client/serveur sur une application locale? Dans le but d'en faire une distribuée à l'avenir?
De même, je pense qu'il y a un souci de nommage, j'ai du mal à voir une JFrame côté serveur .

Niveau socket, ce sont des opérations de très (très) bas niveau, ça irait pour un petit projet perso (mais du coup je vois mal l'intérêt de distribuer le tout).
Il existe en Java des APIs de bien plus haut niveau: les Servlets (et notamment les Websockets, qui permettent l'asynchrone).
Cela nécessite de faire tourner ton code serveur sur un conteneur de Servlet (type Tomcat, WildFly...).
Si tu veux te lancer dans l'aventure, voici la documentation relative en utilisant le Spring framework (tu pourras trouver des exemples sur Spring un peu partout sur Internet): http://spring.io/guides/gs/messaging-stomp-websocket/.

La même chose avec la norme JEE7: http://docs.oracle.com/javaee/7/tuto.../websocket.htm

[Sebajuste]

@Tcharl : même au niveau pro, il peut être intéressant de créer un serveur avec une gestion "bas niveau" des sockets, si les flux de données n'ont strictement rien à voir avec le protocole HTTP, ou autre protocole connus ( je dis ça, car c'est ce qu'on fait dans notre boite ^^ )

@Battant : Par contre, l'investissement est colossal, et utiliser des socket nécessite d'être absolument sur de ne pas réinventer la roue.

Si vraiment tu dois passer par là, alors tu ne dois pas utiliser de mutliple thread !

Ceci est donc à bannir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Thread serviceThread = new Thread (new ServiceThread() );

Pour ça, oublies les Socket et ServerSocket. Utilise plutôt les classes comme SocketChannel, ServerSocketChannel et Selector. Fait une recherche avec les mots clef "java nio socket" sur ton moteur de recherche préféré
Avec ça, toute la partie communication réseau peut être géré par un seul et unique Thread.

Il faut alors traiter les différentes opérations ( Connexion / Déconnexion / Récéption de packet ) comme des évènements. C'est là qu'il faut utiliser un pool de Thread ( en utilisant la classe "Executors").

Nombre de thread limité + programmation évènementielle = application réactive.

Ce terme de "application réactive" n'a strictement rien de nouveau. C'est même par là que la programmation a commencé ! Elle est juste tombé en désuétude sur les serveurs web, car le protocole HTTP n'a jamais vraiment été adapté pour le traitement de flux. D'où l'intérêt des WebSocket, qui apporte enfin la possibilité de récupérer sur le client web un évènement provenant du coté serveur.

[Tcharl]

Merci sebajuste pour cette réponse.
Par contre, pour une communication sans rapport avec http, j'aurais tendance à utiliser JMS/STOMP plutôt qu'à manipuler des executors à la main.

[thelvin]

Ce terme de "application réactive" n'a strictement rien de nouveau. C'est même par là que la programmation a commencé ! Elle est juste tombé en désuétude sur les serveurs web, car le protocole HTTP n'a jamais vraiment été adapté pour le traitement de flux. D'où l'intérêt des WebSocket, qui apporte enfin la possibilité de récupérer sur le client web un évènement provenant du coté serveur.

En réalité le protocole HTTP n'a pas de gros problème avec ça, c'est plutôt qu'il suggère autrement et que les implémentations de l'époque, faisaient comme il suggère : une requête d'URL = une ressource immutable et typée.
Si tu veux envoyer des données au fur et à mesure que tu en as à envoyer, sans jamais fermer la connexion, ben... Fais-le. HTTP ne t'en empêche pas. C'est comme ça que fonctionnent les Server-Side Events et il n'y a pas de problème.

L'intérêt des WebSockets, c'est que c'est de la communication continue dans les deux sens. Ce qui évite d'ouvrir une communication continue de A vers B et une communication continue de B vers A qui soient distinctes pour des raisons fantoches.
Et encore, c'est surtout que c'est de la communication bien normalisée pour être utilisée directement avec des API JavaScript haut niveau. Parce que, de même que le serveur peut parfaitement s'il veut envoyer en continu sa réponse HTTP, le client peut très bien envoyer en continu sa requête HTTP et les deux se parler l'un à l'autre comme ça (c'est d'ailleurs ce que font les websockets, parfaitement respectueuses du protocole HTTP, même si elle le font avec un Connection Upgrade.) Ce serait une légère entorse aux bases de HTTP en cela que le serveur n'a pas le droit de commencer à répondre tant que le client n'a pas fini d'envoyer s'il n'y a pas eu Connection Upgrade. Mais bon... Cette règle elle sert à rien à part aider un peu les proxies. 'Suffit d'enlever la règle qui gêne et depuis le début c'était parfaitement faisable en HTTP.

[Battant]

Bonjour,

Pour info, mon application client ne se connecte au serveur que pour envoyer le message d'erreur ou autre via TCP (PrintStream)

Il avait beaucoup d'intérêt lorsqu'il était possible pour moi de voir les bug a distance quand l'application était connectée à internet via une adresse dyndns.org. Un jour, je trouve le routeur déconnecté et je constate que le service est non seulement plus géré mais est devenu payant.

J'ai donc abandonné et le serveur n'a d'intérêt que si le programme client est exécuter sur le réseau privé de mon domicile ce qui n'est pas toujours le cas.

Je suis bien abonné à un hébergeur mais il supporte le php et mysql uniquement. Dans ces condition ça serait difficile voir impossible de l’exécuter chez l'hébergeur.

Que feriez.vous dans ces conditions ?

Merci de me répondre

Salutations

[Tcharl]

Tu as des offres gratuites d'hébergement Java: Openshift (c'est sûr) et Cloudbees (je crois).

[Battant]

Bonjour,

Concernant l'application client, que feriez-vous pour par exemple rendre les appel jdbc ResultSet, prepareStatement, Connection etc non bloquant et réactif ?

Merci de me répondre

Salutations

[Tcharl]

Je dirais de threader en amont, ou utiliser une base in-memory type hazelcast ou gridgain comme tampon (les accès disques sont souvent l'endroit ou ça coince).
Enfin n'écoutes quand même pas trop ce que je dis, je vais transformer ton logiciel en usine à gaz (réactive, certe) :p

[Battant]

Bonjour,

Comme base de donnée j'avais borland jdatastore et il faudrait maintenant trouver une autre solution durable portable sur tous les système et sur une clef USB.

Cette base de donnée devrait être à fichiers amovible et si possible open source pour éviter des coût lié à des logiciels propriétaire dont vous apprenez un jour qu'il n'est plus vendu et plus supporté. J'ai eus la même chose plusieurs fois

Et bien sur la réactivité devrait être à considérer.

En parlant d'autre chose j'ai également entendu dire dans un des épisodes de nipdev consacré à neosql qu'il était difficile dans un schémas relationnel classique de rajouter des table au model et des champ à une table une fois la base de donnée chargée.

Pourriez-vous m'aider a choisir une nouvelle base de donnée durable avant d'effectuer une migration ?

Je précise que jdatastore était transactionnel et que donc ça dois être le ça de la nouvelle base.

Merci pour votre aide

Salutations

[Tcharl]

Tu as l'embarras du choix parmis les bases open sources:
Pour les bases de données qui tournent en mode 'service':
Mysql, MariaDB.
Pour celle en mémoire, ou persistance sous forme de fichier:
DerbyDb, HSQLDB.

Le top étant d'utiliser JPA (Java Persistence API)/ et JTA (Java Transaction API) pour ne pas être dépendant d'un SGBD et ne pas manipuler resultsets et consorts...

Bon développement!

[Sebajuste]

Merci sebajuste pour cette réponse.
Par contre, pour une communication sans rapport avec http, j'aurais tendance à utiliser JMS/STOMP plutôt qu'à manipuler des executors à la main.

Là encore, tout dépend du contexte d'utilisation. Un client JMS peut être particulièrement lourd ! Je reprends notre cas comme exemple : nos programmes "clients" sont des cartes électroniques embarquées de très faible puissance / capacité RAM. Nous ne disposons que des protocoles DHCP, DNS et TCP/UDP. Implémenter la couche nécessaire pour traiter les messages JMS est impensable. Même la couche HTTP est trop lourde en terme de taille de packet !

Concernant l'application client, que feriez-vous pour par exemple rendre les appel jdbc ResultSet, prepareStatement, Connection etc non bloquant et réactif ?

Pour ça, visualisons déjà ce qu'on ferait en tant "normal". On aurait un seul thread, qui va effectuer les opérations suivantes:

- [thread-client] Récupèrer l'évènement du client qui demande les infos
- [thread-client] Récupérer une connexion à la base de données
- [thread-client] Préparer la requète SQL (avec les paramètres du client)
- [thread-client] Envoyer la requète SQL, et attendre la réponse
- [thread-client] Traiter la réponse
- [thread-client] Renvoyer le résultat total au client, et va pouvoir traiter une nouvelle requète d'un client

Comme le traitement de la requète SQL est bloquant, le thread sera bloqué. Or, le nombre de thread disponnible pour traiter les requètes clients sont limités. Si tous les thread sont bloqué (parce qu'ils font tous des requètes SQL; par exemple), alors les nouvelles demande de client seront mises en attendre. Ce qui peut être dommageable si certaines de ces requêtes ne nécessitent pas de traitement lourd / bloquant.
Pour éviter celà, il faut que les thread qui gèrent les requètes de client "rendent la main" le plus rapidement possible, afin de ne pas immobiliser des ressources pour "rien" (en admettant qu'attendre une réponse de la base de données soit du temps "perdu" ).

Dans la nouvelle architecture, nous avons toujours notre pool de thread qui va gérer les requètes des client. Mais nous auront également un autre pool de thread, qui va gérer les requètes SQL.

Ce qui donne :

- [thread-client-1] Récupèrer l'évènement du client qui demande les infos
- [thread-client-1] Renvoyer la demande à un thread de connexion SQL
- [thread-client-1] Rend la main, et va pouvoir traiter une nouvelle requète d'un client
- [thread-SQL] Récupérer une connexion à la base de données
- [thread-SQL] Préparer la requète SQL (avec les paramètres du client)
- [thread-SQL] Envoyer la requète SQL, et attendre la réponse
- [thread-SQL] Renvoyer le résultat à un thread client, et va pouvoir traiter une nouvelle requète SQL
- [thread-client-2] Récupèrer l'évènement de réponse du thread SQL
- [thread-client-2] Traiter la réponse
- [thread-client-2] Renvoyer le résultat total au client, et va pouvoir traiter une nouvelle requète d'un client

[professeur shadoko]

Là encore, tout dépend du contexte d'utilisation. Un client JMS peut être particulièrement lourd ! Je reprends notre cas comme exemple : nos programmes "clients" sont des cartes électroniques embarquées de très faible puissance / capacité RAM. Nous ne disposons que des protocoles DHCP, DNS et TCP/UDP. Implémenter la couche nécessaire pour traiter les messages JMS est impensable. Même la couche HTTP est trop lourde en terme de taille de packet !

nous qui avons des clients plus "lourds" on utilise JGroups sur UDP et des identifiants de correlation pour reconnaitre les accusés de reception et les réponses. On a plusieurs "bus" pour des contextes d'utilisation différents (certains sont en broadcast).
Je reconnais que je ne connaissais pas Rx et que j'ai donc écrit le framework d'utilisation à ma sauce ... non standard ... il va falloir que je reconsidère la question (mes abstractions étant différentes)
ah oui: un point emm...bétant ... toutes les commandes sont exécutées par un Thread avec un nom qui représente la commande et les arguments ... ceci pour permettre un monitorat/debugging distant ...

[Battant]

Bonjour,

Bon, il ne faut pas tout mélanger.

Il y a 2 programmes

1. Le programme de gestion du commerce d'abricots qui est éxcrit avec des requêtes SQL classique qui serait difficile à réécrire avec java persistance API

2. Le programme de gestion de facturations de rendez-vous récurrent qui est encore à l'état de conception et qui devrait quant à lui dès le départ être écrit correctement pour être réactifs, durable lisible sur toutes les plate forme et transportable sur clef usb et surment open source donc on gpl mais payant car, seul Je n’aurais certainement pas le temps de gérer la maintenance. Il faudra donc créer une communauté.

3. Le cas des serveur web http qui ne concerne pas mes programme.

Dans mes programmes il y en a deux
1. Le Serveur pour le programme de gestion d'abricots charger uniquement de recueillir la sortie standard et celle des erreur de mon programme.

Le serveur de gestion de facturation dont le rôle est principalement de :

Lorsqu'un rendez-vous est passé, le marqué comme effectuer si l'utilisateur ne l'a pas annuler..

A la fin du mois ou lorsque x rendez-vous se sont passé clore la facture en cours.

Concernant le programme de facturation, me conseillez-vous d'utiliser une couche ORM (Une classe par entité) ?

Quel est l'intérêt de ce fonctionnement implémenter entre autre dans dolibarr et openERP ?

Comment fonctionne la java persistance api ?

sous quelle licence est-elle distribuée ?

Avez-vous des exemples ?

Enfin j'aimerais utiliser des format ouvert est durable et surtout durable. Peut-on le faire avec cette api ?

Merci pour votre réponse

Salutations

[Tcharl]

Bonjour Battant,

JPA est une JSR (une API normée, intégrée à JEE), il y a donc des chances qu'elle soit durable!
Tu as plusieurs implémentations, la plus connue étant Hibernate (mais sous license EPL), mais tu as aussi OpenJPA (sous license Apache).
Pour utiliser JPA, tu as plusieurs solutions:
* Utiliser un conteneur JEE (JBOSS WildFly, TomEE, GlassFish) qui contiennent tous une implémentation JPA out-of-the-box
* Utiliser Spring ou Deltaspike et l'implémentation JPA qui te plait (ces deux frameworks permettent l'injection de dépendances et servent de glue entre les différentes briques). Cette dernière solution étant bien sûr plus difficile à mettre en place.

Oui, JPA est un ORM: Une Classe ~= Une table en base et une requête JPQL (~=SQL te renvoie des instances d'objets).

Tu peux trouver nombre d'exemples sur le net de projets utilisant JPA étant donné que nombre d'entreprises utilisent JavaEE et que c'est une des compétences les plus demandées dans la programmation. Au pire, la documentation Oracle est une bonne aide (même si elle parait austère à première vue, c'est une très bonne référence complète): http://docs.oracle.com/javaee/6/tutorial/doc/bnbpy.html.

J'ai aussi un exemple d'une table, mais il est assez difficile à comprendre vu qu'il combine nombre de technologies (OSGI, Lombok, CDI...), aussi je le déconseille pour une première approche, mais plutôt comme pense bête (les fichiers et classes sont présents et documentés): https://github.com/OsgiliathEnterpri...ello.model.jpa

Bonne chance dans la découverte de JEE (si jamais tu t'y lances)!

Charlie

[Battant]

Bonjour,

Il me semble que c'est la deuxième de fois qu'on me parle de J2EE dans cette discussions.

J'aimerais quelque renseignement à ce sujet SVP

Bien que cette api soit déstinée aux entreprise est-elle

1. inclus dans openjdk 7
2. utilisable n'importe ou et gratuitement même dans le cadre d'un programme de facturation ou de gestion basique comme les deux que j'ai cité précédemment
3. Open source ?

Merci pour votre réponse

Salutations