Best Practice - mit EJB's Kongfigurationsdateien bearbeiten?

TheDarkRose

TheDarkRose

Gesperrter Benutzer
Im Moment bin ich dabei ein kleines Servermanagement Tool zu schreiben. Dazu muss ich aber am Server auch gewisse Konfigrationsdateien bearbeiten. Fakt ist ja, dass man aus einem Application Server nicht direkt auf Dateien zugreift. Aber wie macht man das dann? Schreibt man ein kleines lokales eigenständiges Tool, welches per JMS mit dem AS kommuniziert und das Tool modifiziert dann die Dateien. Oder gibt es andere Wege dies zu lösen?
 
M

mvitz

Top Contributor
Die Idee über JMS geht bestimmt, ansonsten gibt es afaik für jeden AS die Möglichkeit sich einen (dann natürlich speziell auf den AS abgestimmten) FileProvider zu schreiben, den man dann wiederum aus einer EJB nutzen kann. Ansonsten Konfiguration nicht in nem File, sondern in der DB abspeichern?
 
M

Marcinek

Gast
Ahja ;D - Danke.

Das Problem bekommt man nur, wnen man direkt in die EJB die Fachlogik unterbringt.

Wie wäre es, wenn man die EJB Schicht nur dazu nutzt um entsprechende Business Logik aufzurufen.

Client <--> EJB <---> BO's

EJB sucht in ihrem Kontext die entsprechenden BOS und leitet die Anfrage weiter.

Die BOs liefern die Antwort an die EJB.

Die BOs dürfen dann natürlich keine EJB-Container funktionen nutzen um weiter portalbel zu sein.
 
TheDarkRose

TheDarkRose

Gesperrter Benutzer
mvitz hat gesagt.:
Die Idee über JMS geht bestimmt, ansonsten gibt es afaik für jeden AS die Möglichkeit sich einen (dann natürlich speziell auf den AS abgestimmten) FileProvider zu schreiben, den man dann wiederum aus einer EJB nutzen kann. Ansonsten Konfiguration nicht in nem File, sondern in der DB abspeichern?
Zum Vergrößern anklicken....

Ja, das meiste kommt eh in eine Datenbank oder auch LDAP (Java und LDAP = grausam). Aber manche Serverdienste lassen sich leider nicht gegen ein DB-Backend konfigurieren. Und dabei fällt mir gerade auf, dass es auch der Fall sein kann, dass sich die Serverdienste auf einem anderen Server als wie der AS befinden. Dann bleibt eh nur mehr lokales Tool und Kommunikation mit JMS übrig, oder? Btw. lässt sich JMS über SSL verschlüsseln?
 
M

mvitz

Top Contributor
Marcinek hat gesagt.:
Ahja ;D - Danke.

Das Problem bekommt man nur, wnen man direkt in die EJB die Fachlogik unterbringt.

Wie wäre es, wenn man die EJB Schicht nur dazu nutzt um entsprechende Business Logik aufzurufen.

Client <--> EJB <---> BO's

EJB sucht in ihrem Kontext die entsprechenden BOS und leitet die Anfrage weiter.

Die BOs liefern die Antwort an die EJB.

Die BOs dürfen dann natürlich keine EJB-Container funktionen nutzen um weiter portalbel zu sein.
Zum Vergrößern anklicken....

Also, wenn in den BOs dann auf Files zugegriffen wird (außer der Zugriff ist lesend und dann sollte er über getResourceAsStream erfolgen), ist es weiterhin verboten. Nur weil du eine Schicht zwischen EJB und File Access legst, greift die EJB immer noch auf Files zu, was verboten ist ;)
 
M

Marcinek

Gast
Jein.

Es geht hier nur um die Portabilität deiner EJB zwischen EJB Containern.

Wenn die BO Schicht nicht auf den EJB Container angeweisen ist (was ist gefordert habe), dann kannst du die nun kleine (schlanke) EJB Schicht leicht portieren. (E.g. Remote Interfaces oder Annotationen ändern).

Wenn du in deinen EJBs Containerspezifischen Code nutzt, dann hast du ehh verloren ;D
 
TheDarkRose

TheDarkRose

Gesperrter Benutzer
Nee, EJB's programmiere ich brav gegen die JavaEE Api, und nicht spezifisch gegen einen AS. Ist eh schon verrückt genug, dass man für einen Application Client AS-spezifisch programmieren muss.

Was haltet ihr von der JMS-Lösung?
 
M

mvitz

Top Contributor
Bleiben dann ja nur die folgenden Möglichkeiten

1. AS spezifischen Filesystem Adapter
2. JMS Kommunikation mit externem System
3. RMI Kommunikation mit externem System
4. WS Kommunikation mit externem System (SOAP oder REST)
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
H JSF-EJB Best Practices Application Tier 1

Ähnliche Java Themen

Aktuelle Jobs

Neue Themen


Oben