# cms mit beliebigen clients (z.b. flash) -> JMX oder EJB



## busch-d (28. Feb 2006)

Ich sitze vor der Realisierung einer relativ großen Community. Das interessante wird sein, dass es ein komplettes CMS sein soll, jedoch mit Flash Frontend. Es geht um die implementation des Datenmodells, und wir haben uns für Java entschieden, da die Verbindung zu Flash relativ einfach ist. Die Lösung soll so schmal wie möglich gehalten werden, jedoch muss es möglich sein, weitere Clients einzuschalten, wie zum beispiel ein Administrationstool (oder weitere WebClients) . 

Welche Techniken würdet Ihr vorschlagen? Für mich kamen bis jetzt JMX (plus bereitstellung eines WebServices)  und J2EE (EJBs)  in frage. Man denke an eine schmale Lösung!

Wenn bekannt, würde ich auch gern auf fertige OpenSource Projekte zurückgreifen um den Aufwand so gering wie möglich zu halten.

Ich wäre für Ideen und Statements dankbar!

Gruß,
Daniel Busch


schwachsinn, falsche Rubrik, sorry! -> Bitte nach J2EE veschieben!


----------



## Roar (28. Feb 2006)

hi, vielleicht ist openlaszlowas für dich. ist ne kostenlose, open source alternative zu flex und is glaub ich dazu da was du machen willst 



> schwachsinn, falsche Rubrik, sorry! -> Bitte nach J2EE veschieben!


 schon geschehen


----------



## busch-d (28. Feb 2006)

vielen dank für die idee. aber um das flashfrontend kümmert sich ein flash-profi. Das problem ist, dass das datenmodell und der adminbereich definitiv mit java gebastelt wird und die verschiedenen frontends mit verschiedenen programmiersprachen, wie zum beispiel flash. die frontends greifen aber ebenfalls auf das selbe datenmodell zu wie die admintools. es geht mir ja darum, dass nicht für jede oberfläche neu zu schreiben (ähnlich MVC) die frage ist jetzt, auf welcher technik ich das model aufsetzte. da mir j2ee mit ejbs etwas overhead erscheint. ich möchte eine möglichst schmale lösung. und da bin ich auf jmx und mbeans gestoßen. nur welche der beiden lösungen ist nun das richtige? oder eine ganz andere?


----------



## Bleiglanz (2. Mrz 2006)

jmx und mbeans haben mit der sache überhaupt nix zu tun, es wäre irrsinn damit ein backend anzugehen

die meisten j2ee server VERWENDEN diese Techniken, um damit ihr Komponentenmodell (Container, EJBs, usw.) aufzubauen; man kann da schlecht von Hand anfangen


mein Vorschlag für eine "schmale" Lösung:

Frontend: Flash

Schnittstelle: Servlets, die in einem normalen Webserver (Tomcat, Jetty) laufen

Backend: eine Datenbank, die über JDBC angesprochen wird (oder Hibernate o.ä)


----------



## busch-d (2. Mrz 2006)

auch ne lösung; man könnte doch die einzelnen objekte als mbeans ablegen und dann über webservice darauf zugrben. aber servlets machen natürlich auch sinn, wobei ich dann für die persistensschicht dochauf entitybeans zurückgreifen wüprde, oder nicht?


----------



## Bleiglanz (2. Mrz 2006)

nein, vergiss entitybeans (wenn du dich nicht mit EJB und dem ganzen Zeugs auskennst)

gibt auch gute andere Lösungen (Castor, Kodo, Hibernate, usw.) die etwas leichter in der Handhabung sind als Entity EJB


----------



## busch-d (2. Mrz 2006)

Auskennen tue ich mich, habe auch schon Projekte realisiert. Trotzdem danke für die Tips, welches der Frameworks würdest du denn empfehlen? Wichtig ist mir, dass ich die Persistensschicht ohne Probleme austauschen und ggf. auf andere Server verlagern kann (bei application servern normalerweise kein problem), deshalb erster gedanke entitybeans.


----------



## Bleiglanz (2. Mrz 2006)

na wenn du schon erfahrung hast, nimm halt sessionbeans und entity ejbs für das backend 

ist aber ein gewisser overhead, je nach projektgrösse ist der Aufwand doch enorm

so richtig "zum Auswechseln" gibts eigentlich ausser JDO und Entity-EJB keine Mechanismen, eventuell Hibernate verwenden und auf konforme EJB3 Syntax achten...


----------



## busch-d (2. Mrz 2006)

ja, genau das ist das problem, jeglicher overhead soll natürlich nach möglichkeit vermieden werden. Kosten/Nutzen eben. Abgesehen hab ich auch nicht ewig zeit für das Projekt.

Zur Info: Das Projekt ist so groß, dass es mit großer Wahrscheinlichkeit geclustert werden muss. Jetzt noch nicht, aber später. Das wäre mit EJBs numal gewährleistet.

Ich würde jetzt instinktiv erstmal CMP Entities nehmen und zu Optimierungszwecken ggf. später einzelne auf BMP umbauen. Kommentare dazu?



			
				Bleiglanz hat gesagt.:
			
		

> na wenn du schon erfahrung hast, nimm halt sessionbeans und entity ejbs für das backend





			
				Bleiglanz hat gesagt.:
			
		

> nein, vergiss entitybeans (wenn du dich nicht mit EJB und dem ganzen Zeugs auskennst)


nich böse sein, Tips sind mir wichtig, aber bitte frei von Bewehrtungen! Arroganz ist hier am falschen Platz. Trotzdem Danke!


----------



## Bleiglanz (2. Mrz 2006)

> Das Projekt ist so groß, dass es mit großer Wahrscheinlichkeit geclustert werden muss.


dann musst du praktisch einen J2EE Applicationserver verwenden und die Verwendung von EJBs liegt relativ nahe; aber auch dann ist der Aufbau eines Clusters noch keineswegs leicht


> und zu Optimierungszwecken ggf. später einzelne auf BMP umbauen.


nein, nimm nur CMPs

dass du mit BMP eine bessere Performance erzielen kannst ist ein ziemlicher Mythos; i.A. ist man mit CMP besser dran



> Arroganz ist hier am falschen Platz


Wo, wenn nicht hier? Und wer, wenn nicht ICH?


----------

