Konzeption Business Applikation

[Radiohead]

Hallo,

Wir sind im Zuge einer Diplomarbeit am Planen einer Businessapplikation für kleine und mittlere Unternehmen.

Unsere ursprünglichen Gedanken waren einen JavaFX Client, eine MySql DB und einen JBoss mit EJB 3 zu verwenden. An JavaFX und Mysql möchten wir festhalten.

Nun haben wir die Anforderung dass die Applikation leichtgewichtig lauffähig sein soll. D.h. es gibt Zielpersonen welche diese App Standalone auf ihrem Client oder Notebook laufen lassen wollen. Es gibt aber in Zukunft auch Zielpersonen welche mit mehreren Clients auf einen Server verbinden möchten. Auch sind in Zukunft Erweiterungen Richtung Rule Engine und Process Engine angedacht.

Das heisst, wir möchten eine Architektur, die es erlaubt in einer ersten Phase ohne einen zu installierenden Appikationsserver auszukommen. In einer späteren Phase sollte es aber möglich sein, ohne grösseren Aufwand einen Applikationsserver einzusetzen.

Ohne jetzt eine grössere Diskussion auslösen zu wollen, habe ich im Forum bereits gelesen, dass Spring ohne App Server lauffähig ist und aber auch mit.

Könnte Spring ein Ansatz für unsere Anforderung sein, oder gibt es auch Ansätze mit EJB3 welche uns da helfen könnten ?

Leider ist das Gebiet riesengross und die Erfahrung relativ klein :noe:

Wir würden uns über Eure Inputs freuen.

Radiohead

 

[FArt]

Spring mit Spring-Remoting kann (auch für Client-Server) eine für dich tragfähige Lösung sein.
Eine bessere Entscheidung kann man mit den wenigen Informationen über funktionale (und vor allem nicht-funktionale) Anforderungen (du hast vermutlich selber noch nicht viel mehr) treffen.

Frag dich selber, welchen Vorteil EJBs dir gegenüber der einfachen Spring-Lösung bieten würden. Container Managed Transactions? Security, z.B. über JAAS? Wichtige Services (z.B. JMS) oder Abstraktionsschichten (Resourceadapter), die man sonst (mühsam?) selber klöppeln müsste?

Vorteile von Spring: du verbaust dir nicht den Weg in den AS. Ein sauberes Design mit Spring lässt sich relativ einfach in die JEE Welt migrieren.

 

[byte]

Spring bietet die Möglichkeit, Remote Services als POJOs zu entwickeln. Wie diese dann verfügbar gemacht werden, ist reine Konfiguration. Das kann dann z.B. per RMI, HTTP oder als normale Spring Beans (also lokale Java Objekte) passieren. Du hast also grundsätzlich die Möglichkeit, daraus sowohl eine Standalone- als auch eine Client-Server Variante zu builden.

Ich würde die Architektur aber eher auf Client-Server ausrichten, da das noch andere Konsequenzen mit sich zieht. Für gewöhnlich reicht als Server ein einfacher Servlet Container aus (z.B. Tomcat oder Jetty). Diese kann man ohne Probleme im Embedded Modus starten, ebenso wie MySQL. Insofern könnte eine Standalone Variante einfach einen lokalen Jetty + MySQL starten und über localhost verbinden.

Auf diese Weise habt ihr eine einheitliche Architektur und werdet nicht in einer späten Entwicklungsphase vor unvorhersehbare Probleme gestellt.

 

[FArt]

Insofern könnte eine Standalone Variante einfach einen lokalen Jetty + MySQL starten und über localhost verbinden.

Das sehe ich nicht so. Das dadurch unnötige duchgeführte Marshalling/Unmarshalling kostet Ressourcen und Performance.

Ein sauberes Design erlaubt es aber trotztdem, eine Applikation Standalone laufen zu lassen oder bestimmte Services Remote zu exposen (bei Bedarf). Dieses Aussage ist nicht uneingeschränkt gültig, aber ich denke doch, dass man für die meisten Applikation so arbeiten kann.

 

[byte]

Das sehe ich nicht so. Das dadurch unnötige duchgeführte Marshalling/Unmarshalling kostet Ressourcen und Performance.

Ein sauberes Design erlaubt es aber trotztdem, eine Applikation Standalone laufen zu lassen oder bestimmte Services Remote zu exposen (bei Bedarf). Dieses Aussage ist nicht uneingeschränkt gültig, aber ich denke doch, dass man für die meisten Applikation so arbeiten kann.

Das sehe ich nicht so. Wenn die Anwendung in beiden Varianten (Standalone und Client-Server) vernünftig laufen soll, dann impliziert das, dass sie auch als Client-Server über localhost vernünftig laufen wird. Der entstehende Overhead ist idR überhaupt nicht spürbar, sofern man die Anwendung nicht auf uralter Hardware laufen lässt. Grade ein Embedded Jetty ist total lightweight, auch was die Größe angeht.

Entwickelt man stattdessen tatsächlich eine Standalone Version (ohne JEE) und eine Client-Server Version (mit JEE), dann führt das zu einem deutlichen Mehraufwand bei der Entwicklung. Spring erleichtert hier zwar einiges, viele Features sind aber nur über einen WebApplicationContext verfügbar. Und dafür brauchst Du einen Servlet Container.

 

[FArt]

viele Features sind aber nur über einen WebApplicationContext verfügbar. Und dafür brauchst Du einen Servlet Container

Das ist wahr. Aber einen Kontext habe ich auch in Spring. Mit der richtigen Kapselung kann ich aus dem einen das andere machen, aber eben nur bei Bedarf. Es hängt viel von einem sauberen Design ab...

 

[Radiohead]

Hallo zusammen

Vielen herzlichen Dank für Eure Ausführungen. Die helfen uns weiter und wir können uns mal gezielt über die beiden Varianten informieren.