Moin…
bevor das Jahr zu Ende geht, und es so scheint, als würde ich nichts 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 Client-Seite 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 separate 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 Autorisierung/Authentifizierung ü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 User-Daten 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 User-Daten 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)

Da ich mir ja langsam mal Gedanken machen sollte, wie ich meine Arbeit strukturiere. Habe ich mal angefangen, beispielhaft, die Schritte zu sammeln, welche notwendig sind, um eine DB Table mit Hilfe der Java Möglichkeiten REST fähig zu machen.
Ich gedenke dies in 3 Teile zu tun:

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:

Als allererstes möchte ich die folgende Datenbank Tabelle als ein einfaches POJO (Plain Old Java Object) abbilden und die Annotations machen, welche notwendig sind, damit JPA auch weiß, wie es mit der Klasse umzugehen hat.
Folgende Tabelle:

TABLE Users
===================================================
[ user_id | email | forename | surname | password ]
===================================================

Die nachfolgende Klasse ist dann das passende POJO dazu:

/*
ne ganze menge imports:
*/
import de.hausswolff.cotodo.tools.Tools;
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 selbst in Anspruch zu nehmen. 
"User" gehört scheinbar auch dazu.
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 Rolle 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 SendTaskCollection;

    @ManyToMany
    @JoinTable(name="UsersTasks",
    joinColumns=@JoinColumn(name="send_to"),
    inverseJoinColumns=@JoinColumn(name="task_id"))
    private Collection 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);
    }

...

}

Ich habe vieles aus der Klasse weg gelassen, was nicht unbedingt für die Funktion von JPA notwendig ist, aber durchaus der besseren Lesbarkeit dient. Wichtig ist, dass es einen Standard-Konstruktor gibt.
Weiter geht es mit JAXP. Also der Repräsentation von obiger Klasse in XML.