Rich Internet Applications mit ExtJS und Jersey
Kommentare

JSON und die Annotations
ExtJS bietet eingebaute Unterstützung für REST Web Services [10, 11]. REST exponiert Ressourcen als URLs und erlaubt deren Manipulation mittels der Standard-HTTP-Methoden GET,

JSON und die Annotations

ExtJS bietet eingebaute Unterstützung für REST Web Services [10, 11]. REST exponiert Ressourcen als URLs und erlaubt deren Manipulation mittels der Standard-HTTP-Methoden GET, PUT, POST und DELETE. Der Versicherte mit der ID 4711 wird dann z. B. mit dem folgenden URL gelöscht:

HTTP DELETE http://localhost/app/data/versicherte/4711

Als Format für die Serialisierung der zu übertragenden Objekte ist JSON eine sinnvolle Wahl, da es durch JavaScript einfacher zu verarbeiten ist und JSON generell besser lesbar und prägnanter ist als XML. Der Server verwendet den Java Stack von Webtechnologien. Dieser beinhaltet mit JAX-RS (JSR 311) ein eigenes API für REST Web Services. JAX-RS ordnet Methoden per Annotation URLs, HTTP-Methoden und Ein- und Ausgabeformate zu.

Unsere Anwendung verwendet die JAX-RS-Referenzimplementierung Jersey [12]. An keiner Stelle wird der Sourcecode der zu übertragenden Objekte selbst geändert. Damit ist Jersey ein typisches Beispiel für „separation of concerns“, da der Aspekt „REST Web Services“ vollständig von der fachlichen Logik getrennt ist und deklarativ den Klassen hinzugefügt werden kann. Abbildung 2 erläutert die resultierende Architektur, die dem SOFEA-(Service-Oriented-Frontend-Architecture-)Paradigma folgt [13].

Abb. 2: SOFEA-Architektur mit ExtJS und Jersey

Listing 3 zeigt die Java-Klasse User (gekürzt), deren Methode getUser() als Web Service unter dem relativen URL DATA/USER/LIST verfügbar ist. Wichtig ist die Annotation @Produces. Ihr Parameter MediaType.APPLICATION_JSON bestimmt, dass der Service als Austauschformat JSON generiert.

Listing 3
@XmlRootElement @Path("data/user")
public class User extends BasicUser {
    [.]
    @Path("/list")
    @GET @Produces({MediaType.APPLICATION_JSON})
    public List getUsers() { [.] return new LinkedList(); }
}

Die resultierende SOFEA-Architektur zeigt bereits zur Entwicklungszeit ihre Vorteile. Client und Server lassen sich fast vollständig unabhängig entwickeln. Der Client ruft während der Entwicklungszeit anstelle des Servers einfach URLs auf, hinter denen Textdateien mit JSON-Inhalt liegen, die dem entsprechen, was der Server sonst zurückliefern würde. Zentrale Bedeutung erhält die Absprache der Client/Server-Schnittstelle, also der Services. Vor allem Themen wie Fehlerbehandlung, Autorisierung, und Statusbehandlung müssen vorab geklärt und robust konzipiert sein. Die tatsächlichen Daten lassen sich auch später noch einfach erweitern, da man an dieser Stelle nahezu vollständig deskriptiv vorgehen kann. Die leichte Änderbarkeit und die starke Entkopplung unterstützen agile und iterative Vorgehensmodelle und erlauben somit eine schnellere und qualitativere Reaktion auf geänderte Anforderungen.


Auf den folgenden Seiten erwarten Euch folgenden Themen:

  • Odyssee im GUI-Raum
  • Rücksturz zur Wirklichkeit
  • Babylon A.D.
  • http 204 antwortet nicht
  • Das unentdeckte Land
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -