Normal
Mit Java EE bohrt man gleich richtig große Löcher. Wie greifen die Nutzen denn auf die Dienste zu? Mit einer Web-Anwendung? Oder etwa mit Swing/SWT/JavaFX und Rich-Clients? Das würde das Design schon etwas beeinflussen.Im Prinzip hat man bei Java EE-Apps eine RMI/REST/SOAP-Fassade, dahinter die EJB-Services für die Business-Logik. Die Services können mit JPA auf die DB zugreifen. Hibernate "sieht" man (im Idealfall?) nicht, das ist "nur" ein JPA-Provider. Im Fall von GlassFish wäre es auch Eclipse Link, die Referenz-Implementierung für JPA 2.x. JBoss nutzt Hibernate als PJA-Provider, ja, aber durch die JPA-API ist das (im Idealfall) egal.
Mit Java EE bohrt man gleich richtig große Löcher. Wie greifen die Nutzen denn auf die Dienste zu? Mit einer Web-Anwendung? Oder etwa mit Swing/SWT/JavaFX und Rich-Clients? Das würde das Design schon etwas beeinflussen.
Im Prinzip hat man bei Java EE-Apps eine RMI/REST/SOAP-Fassade, dahinter die EJB-Services für die Business-Logik. Die Services können mit JPA auf die DB zugreifen. Hibernate "sieht" man (im Idealfall?) nicht, das ist "nur" ein JPA-Provider. Im Fall von GlassFish wäre es auch Eclipse Link, die Referenz-Implementierung für JPA 2.x. JBoss nutzt Hibernate als PJA-Provider, ja, aber durch die JPA-API ist das (im Idealfall) egal.
