« November 2007 | Main | January 2008 »
GET http://localhost:8080/cotodo/users
gibt mir:
Weiterhin habe ich mir eine kleine Testanwendung geschrieben. Im Moment arbeite ich noch daran, per ajax meine GET/POST/PUT/DELETEs abzusetzen.
Als nächstes werde ich mich jetzt den unterschiedlichen Ausgabeformaten zuwenden und der Behandlung von POST/PUT Inputs
Jetzt wo es an die Listen geht:
ist so etwas REST konform?
http://localhost/users?q=sonne
Immerhin müsste ein Listenabruf ja per GET erfolgen, also kann man die query nicht per POST übermitteln.
ich bin in der seltsamen Situation, einen Draytek Vigor 2930 VS hier zu haben und ihn nicht zu brauchen…. Was der alles kann (außer Wlan - das was ich eigentlich brauche) steht auf der Produktseite bei Draytek.. Ich wollte mal fragen ob den jemand haben will. Im Moment liegt der Preis bei so 300 EUR. Wenn nicht, dann stelle ich den einfach bei Ebay rein :-).
Ich bin mittlerweile soweit, dass mir ein
Request: GET http://localhost:8080/cotodo/resources/users
eine Liste ala
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<users uri="http://localhost:8080/cotodo/resources/users/">
<userRef uri="http://localhost:8080/cotodo/resources/users/3/"><userId>3</userId></userRef>
<userRef uri="http://localhost:8080/cotodo/resources/users/52/"><userId>52</userId></userRef>
<userRef uri="http://localhost:8080/cotodo/resources/users/53/"><userId>53</userId></userRef>
</users>
zurückgibt. Das gleiche ist auch als JSON Format möglich.
Ein Post von
<user><name>Test31</name><password>testtest</password></user>
wird mit einem status 200 (okay) quittiert. Der erstellte User sieht dann so aus:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user uri="http://localhost:8080/cotodo/resources/users/54/">
<name>Test31</name>
<password>5a671c66aefea124cc08b76ea6d30bb</password>
<userId>54</userId>
</user>
(Die ID wird automatisch generiert, das Passwort wird im User Objekt per md5 gehashed)
Soweit die guten Nachrichten… alle meine aktuellen Probleme kommen gleich :-(
Soooo da das ja bei den Benutzern schon so wunderbar klappt, hier dann mal meine Probleme:
Wie in einem der letzten Posts erwähnt, möchte ich gerne eine Abhängigkeit meiner Entries untereinander haben. Das heißt, ich möchte unter einem Eintrag n Untereinträge haben. Das Klassendiagramm schaut dann so aus:
Meine Tabelle sieht so aus:
Ja eigentlich recht simpel. Nun bietet JPA im Rahmen von Annotation genau eine solche OneToMany Beziehung an.
@OneToMany(cascade=CascadeType.REMOVE)
private List <Entries> _child_entries = new Vector<Entries>();
In dieser Liste würden dann alle Kinder des Eintrages stehen. Da ich mal einfach annehme, dass es unnötig ist, auf DB Ebene noch Foreign Keys zu erstellen, hoffe ich einfach mal, dass das so laufen wird.
Weiterhin habe ich eine Relations Tabelle, die mir die Benutzter mit den Einträgen verbindet und auch sicherstellt, dass n Benutzer für einen Eintrag zuständig sein können:
Hier beginnt es nun problematisch zu werden. Okay es gibt in dem EJB Buch eine Beschreibung wie man ManyToMany Beziehungen modelliert, allerdings habe ich hier ja auch ein Attribut “status”, welches ja an sich nichts mit der Relation zu tun hat, allerdings schon logisch von dieser Abhängt.
Es würde sich meiner Meinung nach anbieten, dieses als seperates Objekt zu machen. Ich habe mir das erstmal durch Netbeans generieren lassen. Es ist nun zugegebenermaßen etwas sperrig (weil Netbeans eine eigene PrimaryKey Class drum generieren will, damit sichergestellt ist, dass bei Neuerstellung alle notwendigen Schlüssel belegt sind), allerdings denke ich, dass es eine hinreichende Funktionalität bietet, um erst einmal weiter zu arbeiten.
Kommen wir nun zum Highlight :-/. Es geht darum, dass die JDBC Anbindung von MySQL seltsamerweise Schwierigkeiten mit Daten zu haben scheint. Siehe dazu auch MySQL Bug #19274. Ich werde jetzt mal versuchen, eine aktuelle Version zu installieren, die das Problem nicht mehr haben soll. Es geht halt nur darum, dass MySQL mit leeren Datumsangaben (ala 0000-00-00 00:00:00) nichts anfangen kann und eine exception wirft. Das ist in sofern ja nicht schlimm, als das ich einfach einen Eintrag erstellt habe und dann mal hoffe, dass ich damit den Fehler vermeide. Ich fand weiterhin eine interessante Übersicht, wie JDBC die DB Attribute nach Java überführt:
Zu guter Letzte suche ich eine Möglichkeit, um einen klassischen HTTP Redirect (Status 303/301 usw.) Mit der Jersey Umgebung hin bekomme. Es gibt dazu sogar eine Diskussion in dem Blog von Angry Bill unter JSR 311, JAX-RS: Comment and suggestions. Ich fände eine Lösung mit einer @Location Annotation sehr gut. Bisher fand ich nur folgende Lösung, welche ich aber bisher noch nicht ausgiebig testen konnte: Philosophical content negotiation aus dem Blog von Paul Sandoz (da steht jede Menge zu REST und JSR311 drin)
Abschließend noch eine Bemerkung zu der letzten Diskussion über die Queries. Im REST-Test von Sun werden u.a. die Pagination-Settings an die URL angehängt also gibt es dann in etwas folgendes als Aufruf:
Request: GET http://localhost:8080/cotodo/resources/users/start=0&max=10×tamp=1196991596495
Irgendwie schaut das schon wesentlich unübersichtlicher aus. Aber letztendlich muss ich mich eh noch damit befassen, wie ich die Parameter aus der URI extrahiere. Da ich nicht annehme, dass sich die beiden Möglichkeiten großartig unterscheiden werden, kann man sich ja direkt gleich mit der richtigen Lösung befassen. Ein Problem was ich sehe, ist allerdings die Eindeutigkeit der Parameter, weil diese ja bei steigender Anzahl einen größeren Teil der URI bilden dürften. Letztendlich ist es aber das gleich Problem wie bei allen Methodenaufrufen, bei denen man anhand eines Aufrufes auch nicht ohne weiteres sagen kann, wofür welcher Wert nun wirklich steht.
Hello world!
Nachdem ich mit Gerald am vergangen Freitag Abend mich ein wenig ausgetauscht habe und wir über die unsere Ansätze in der Erstellung einer EJB3 JEE Anwendung gesprochen hatten, kamen mir doch schon ein wenig Zweifel, ob denn meine Anwendung nun vollständig rechtfertigt, ein EJB im Titel meiner Arbeit zu führen :-).
Nachdem ich mir dann noch ein mal das Buch über EJB2 und JPA (in dem leider die Konzentration arg auf JPA liegt) zur Brust genommen habe (kann man das bei Büchern so sagen?). Und auch noch mal die EJB3 Specs von Sun (das war übrigens mal JSR220) sowie eine recht gute Zusammenfassung und ein paar Tutorials (u.a. dieses hierangesehen habe, bin ich der Meinung, dass meine bisherigen Bemühungen definitiv in die richtige Richtung gingen (ist doch auch mal schön sowas).
Noch dazu weiß ich nun, dass ich JPA mit Annotation und einer Stateless Session Bean benutzen möchte. (Das Stateless resultiert einzig und alleine aus dem REST Ansatz). Dementsprechend kam mir die Idee, in meiner Arbeit auch definitiv ein paar Sequenzdiagramme benutzen möchte - da Zustandsdiagramme mir - zumindest momentan - eher witzlos erscheinen.
Als weiteren Punkt habe ich aus dem Treffen mitgenommen (sind heute irgendwie lauter Ratgeber-Formulierungen), mir endlich mal eine Gesamtübersicht über meine Funktionen zu erstellen. Da zu einem ordentlichen UseCase auch eine Beschreibung gehört (so habe ich es zumindest gelernt), poste ist jetzt hier erstmal zwei Diagramme unter Vorbehalt (der Beschreibungsteil ist noch in Arbeit und das Packet geht dann alsbald auf Tour, ganz ehrlich Phillip).
Ich habe mich dafür entschieden, jeweils zwei Diagramme, jeweils für den Bereich Aufgaben und für den Bereich Benutzer(-verwaltung) zu erstellen:
Wie schon erwähnt: Die Beschreibungen der einzelnen Cases ist zum größten Teil fertig, da mit aber bis grad noch Dinge einfielen, die noch nicht durch die existierenden UseCases abgedeckt sind, möchte ich noch mal mindestens eine Nacht drüber schlafen. Auch ob ich nicht doch die Möglichkeit für verschiedene Benutzergruppen einbauen möchte schwebt mir noch im Kopf herum. Es wäre im Moment noch eine kleinere Änderung in der Datenbank und würde am Code bisher noch nicht wirkliche viele Umbauten nötig machen.
Meinen Router habe ich jetzt mal bei Ebay rein gesetzt. Mal schaun was da so rauskommt. Weiterhin habe ich mich mal mit dem Programm Flock vertraut gemacht. Das basiert auf der Firefox Engine und ist perfekt geeignet, wenn man Dinge bloggen möchte, wenn man Feeds vernüftig lesen will (und interessanten daraus bloggen will) und um Bilder von FlickR oder Videos von Youtube sehen möchte (und interessanten daraus bloggen will ^^). Weil irgendwie stehe ich mit dem Editor hier noch auf Kriegsfuß. Das Programm ist recht gut, funktioniert auch tadellos mit meinem - privaten - Wordpress-basiertem Blog, hat allerdings so seine Probleme mit MovableType wie es scheint. Ich bilde mir zwar ein, dass die RPC Schnittstelle richtig ist, aber laufen wills dennoch nicht. Vielleicht nutzt das ja jemand auch und hat es geschafft, Flock zu überreden, auf dieser Blog-Software auch tätig zu werden :-).
Nachdem ich alle notwendigen Relationen in der Datenbank abgebildet habe, habe ich jetzt meine Annotations zwischen den Objekten fertig gestellt.
Es gibt ein paar interessante Dinge, so zum Beispiel eine rekursive Relation innerhalb von 2 Tasks (Aufgaben). Das heißt, eine Aufgabe kann n Unteraufgaben haben.
Weiterhin enthält jede Aufgaben ein Array von Empfängern und einen Sender.
Ich sehe grade, dass müsste in dem Fall kein Array sein.
Also ist das eine ManyToOne/OneToMany Beziehung. Werde ich dann noch ändern.
Ich war natürlich wieder einmal vorschnell. Hatte ich ja nicht etwas falsch gemacht
(sowas mache ich ja nicht :D), sondern schlicht etwas vergessen. ich spare mir jetzt
mal, die neuen UMLs hoch zu laden ;-). Letztendlich war die eine ManyToMany
Beziehung zwischen Users und Tasks natürlich die Leute, die Tasks an andere User
weiter delegieren. Das können ja pro Task n sein. Hat alles seine Richtigkeit. Die Welt
steht noch und ich gehe schlafen ^^. Was fehlte war einfach eine
OneToMany/ManyToOne Beziehung zwischen Tasks und Users!
Als letztes kann eine Gruppe (nun habe ich so doch mit rein genommen) 1 bis n Benutzer haben. Genauso kann ein Benutzer in 1 bis n Gruppen sein.
Eine Gruppe wird immer neu erstellt und entsprechender Benutzer hineingepackt, wenn eine Aufgabe mit einem Projekt-Flag (dazu später mehr) zu entsprechendem Benutzer zu geordnet wird. D.h. wenn besagter Benutzer Ersteller oder Verantwortlicher der Aufgabe (und deren Unteraufgaben) ist.
Hier mal das UML der Entitäten:
Wenn Interesse daran besteht, wie man die Abbildung im Einzelnen (im Code) abbildet, kann ich dazu auch noch etwas schreiben.
Und abschließend noch mal eine Übersicht aller Klassen, die ich bislang so habe.
Hierbei steht das E für Entität. Ein S steht für eine Systemklasse. Ein R für eine Klasse für eine einzelne REST Resource und eine R# für eine Resourcenliste.
P.S.: Ich teste grade Flock mit den Tipps von Daniel.... bin ich ja mal gespannt, was da raus kommt ;-).
Vielen Dank noch mal Daniel, dass Du Dein Wissen teilst.
Blogged with Flock
1. JPA Entity: Wie wird aus einer Datenbank Tabelle ein Java Objekt
2. JAXP: Wie bekomme ich von meiner JPA Entity möglichst einfach eine Repräsentation in XML (JSON geht auch, aber erstmal reicht mir XML).
3. JSR311/Jersey: Wie gelingt, es die Ressourcen an bestimmte URIs zu binden?
Hier dann als mal Teil 1:
Folgende Tabelle:
TABLE Users
================================
import java.io.Serializable;
import java.util.Collection;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.JoinTable;
import javax.persistence.ManyToMany;
import javax.persistence.NamedQueries;
import javax.persistence.NamedQuery;
import javax.persistence.OneToMany;
import javax.persistence.Table;
/*
Leider scheint der JPA Layer verschiedene Schlüsselwörter für sicher selber in Anspruch zu nehmen. "User" scheint dazu zu gehören.
Ich musste also diese Klasse hier dann Users nennen und blieb bei den Entitäten nun bei dem Plural.
*/
@Entity
@Table(name = "Users")
public class Users implements Serializable {
@Id
@Column(name = "user_id", nullable = false)
private Integer userId;
@Column(name = "forename", nullable = false)
private String forename;
@Column(name = "surname", nullable = false)
private String surname;
@Column(name = "email", nullable = false)
private String email;
@Column(name = "password", nullable = false)
private String password;
/*
Hier kommt dann noch eine Reihe von den Beziehungen der Entitäten untereinander. Das lasse ich hier jetzt auch mal weg, weil es zum Thema keine Rollen spielt. Als Beispiel mal eine Beziehung zu der Table Tasks über folgende Tabelle:
TABLE UsersTasks
===============================
[ task_id | user_id | send_to ]
===============================
Hierbei ist "task_id" die ID des Tasks ;-). user_id ist die ID des Users, welcher den Tasks erstellt hat. send_to enthält die ID des Users, an den der Task als Auftrag geschickt worden ist. Da es n Empfänger seien sollen, muss das ganze natürlich in eine externe Tabelle ausgelagert werden.
*/
@ManyToMany
@JoinTable(name="UsersTasks",
joinColumns=@JoinColumn(name="user_id"),
inverseJoinColumns=@JoinColumn(name="task_id"))
private Collection<Tasks> SendTaskCollection;
@ManyToMany
@JoinTable(name="UsersTasks",
joinColumns=@JoinColumn(name="send_to"),
inverseJoinColumns=@JoinColumn(name="task_id"))
private Collection<Tasks> ReceivedTaskCollection;
/*
...
*/
/*
als (quasi virtuelle) Attribute erhält jede Users Klasse nun zwei Collections, welche halt nicht direkt in der Users Tabelle gespeichert werden, aber durch die Relationen in der UsersTasks Tabelle abgelegt sind.
*/
public Users() {
}
public Users(Integer userId) {
this.userId = userId;
}
public Users(Integer userId, String forename, String surname, String email, String password) {
this.userId = userId;
this.forename = forename;
this.surname = surname;
this.email = email;
this.password = Tools.md5(password);
}
/*
Es folgt nun die übliche Anzahl an gettern/settern. Hierbei habe ich mich entschlossen, nicht stumpfsinnig alle Attribute per set zu öffnen, sondern wirklich nur jene, bei denen es notwendig ist. Die beiden Listen aus den obigen relationen sollten nur lesbar sein. Der Empfänger/Ersteller werden im Task direkt angegeben.
Als Beispiel hier mal setter/getter für das Passwort:
*/
/*
...
*/
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = Tools.md5(password);
}
/*
...
*/
}
Blogged with Flock
Blogged with Flock
Ich gebe zu, ich habe es lang vor mir her geschoben:
Neben all der schönen REST-fähigen Implementierung, ist Sicherheit ein Bereich, der bisher ein wenig zu kurz kam. Zwar habe ich schon eine schöne Möglichkeit gefunden, wie man mit YUI eine Anmeldung über HTTP AUTH hin bekommt, aber letztendlich fehlt(e) bisher die komplette Serverseite.
Ich habe jetzt einiger Zeit gesucht und bin zu dem Ergebnis gekommen, dass mir der Java Application Server (sei es Tomcat, Glassfish o.a.) bereits mehrere JAAS basierte Module zur Verfügung stellt.
Diese Entscheidung traf ich (da es hierbei sicherlich auch Einschränkungen einzugehen gilt) u.a. nach dem Lesen dieses Artikels.
Darin wird einem abgeraten, eine Logion/Session Verwaltung in Eigenregie zu erstellen, da hierdurch teilweise ein Sicherheitsrisiko eingegangen wird.
Nach weitere Suche kam ich zu einem interessanten Artikel von Shing Wai Chan, in dem er die Einrichtung eines JDBCRealm auf einem GlassFish Server beschreibt. Bis auf das die Standard digest-Algorithmen auf den verschiedenen Application Servern unterschiedlich sind, sollte dies unter den verschiedenen Systemen lauffähig sein.
Aufgrund der Übersichtlichkeit und da ich ungern Systeme in meinen Datentabellen rumfuhrwerken lasse, habe ich mir für die entsprechend benötigten Tabellen 2 Views angelegt:
So habe ich in meiner config Datei (sun-web.xml) folgende Zeilen eingefügt:
Also Session Methode werde ich mich dann wohl für eine Cookie basierte Session entscheiden, weil eine URL-encodierte Session die schönen REST-URIs verschandeln würde und dadurch auch den Austausch mit YUI erschweren mag.
Meine beiden letzten Punkte auf der Agenda (die ich diese Jahr noch durchbekommen will (!!!), sind folgende:
Blogged with Flock
Moin...
bevor das Jahr zu Ende geht, und es so scheint, als würde ich nix tun:
Ich bin momentan dabei nach Patchwork Manie meine Texte zusammen zu schreiben - denke aber, dass ich da mal ein paar Tage konzentriert dran sitzen sollte, um mal eine Grundstruktur zu finden.
Weiterhin bin ich momentan dabei, mir einen JavaScript Client zu bauen. Wie vielleicht einiger wissen, benutze ich da das YUI Framework. Dennoch ist es z.B. notwendig, die Entities, welche auf Serverseite (u.a. die JPA Pojos) existieren, auch auf Clientseite abzubilden. Ich bin also momentan dabei, mir mein User.Task und Group Objekt, nebst Abhängigkeiten aufzubauen. Da ich nicht wegen jeder Abhängigkeit einen neuen HTTPRequest senden möchte, speichere ich mir die Objekte in seperate Arrays zwischen und lade die Daten dann nur nach Bedarf nach. Das klappt auch soweit ganz gut, aber letztendlich fehlt es mir irgendwie an den JS Eigenheiten in Bezug auf OOP Programmierung :-D.
Sobald mein Client mit den Grundfunktionen steht, werde ich mich wieder dem Thema Authorisierung/Authentifiszierung über HTTP-AUTH und SSL befassen.
Ist irgendwie ein Riesenbereich und meine bisherigen Erfahrungen sagen mir, dass man es entweder ganz oder gar nicht machen sollte :-). Alleine das Thema Rollenverteilung kann ja schon Bücher füllen. Ich hadere noch ein wenig damit, eine geeignete Lösung zu finden, um alle Request, die nach "/" gehen an ein Formular weiterzuleiten, welches dann über SSL eine Anmeldung realisiert. Weiterhin denke ich, dass ich zumindest alle Anfragen durch eine eigene EJB schleusen müsste, um jeweils Userdaten auf Serverseite anhand der SSL Session zu finden.
Neben dem eBook EJB in Action fand ich u.a. hier weitere Informationen zum Thema. Wie ich bisher ja schon geschildert habe, realisiere ich den notwendigen realm für die Userdaten meines Java Application Servers über Views in der Datenbank. Letzendlich bleiben aber auch hier noch Fragen offen:
1. Gibt es eine Möglichkeit, alle notwendigen Einstellungen ohne Admin Konsole zu erstellen (also quasi über eine Build Script, welches dem Server dann einen Sec Realm darbietet)
2. Ist das ganze Server unabhängig (also z.B. auf Tomcat und Glassfish beidermaßen gleich lauffähig)
3. (zählt auch eher zu 2) welche der vielen Config Dateien gilt es jetzt zu erweitern ( neben einer web.xml gibt es diverse sun-*.xml)
Ist also noch viel zu tun - nur schön, dass es sich mal wieder herausgestellt hat, dass der JS Anteil relativ leicht von der Hand geht. Es muckt zwar hier und da noch ein wenig auf, aber das bekommt man dann auch recht schnell in den Griff.
Ich wünsche allen ein erfolgreiches 2008 und verweise dann hiermit noch mal auf meinen Post in meinem privaten Blog. (ich kann mir nicht helfen, aber letztendlich muss ich am Schriftbild da noch mal arbeiten :-D)
Blogged with Flock
This page contains all entries posted to Philipps paper equivalent Blog in December 2007. They are listed from oldest to newest.
November 2007 is the previous archive.
January 2008 is the next archive.
Many more can be found on the main index page or by looking through the archives.