Kommunikation mit Server Applikation

D

DerLurch

Grünschnabel
Eclipse Plugin Kommunikation mit Server Applikation

Hallo tutorial Gemeinde,

Ich habe das jetzt mal sehr trocken formuliert, damit möglichst wenig Missverständnisse auftreten.

IST-Zustand:
Mehrere Clients (bis zu 20 gleichzeitig) benutzen ein Eclipse Plugin um auf eine SQL Server Datenbank zuzugreifen (jdbc mit Windowsauthentifizierung). Dieser Zugriff passiert momentan über SQL Queries, die im Eclipse Plugin fest definiert sind.
Eine solche Kommunikation birgt eine starke Kopplung, d.h. wenn sich die Datenbank ändert muss auch das Eclipse Plugin angepasst werden.
Die komplette Datenbank wird lokal als Objektstruktur gehalten und der Lesezugriff passiert dann auf dieser Objektstruktur. Schreibzugriff werden natürlich auf der Datenbank direkt gemacht.

SOLL-Zustand:
Auf dem Server soll eine Server Applikation laufen, die die SQL Datenbank vom Client entkoppelt und ein Interface anbietet, dass von jeglichen Datenbanktabellennamen etc. abstrahiert. Alle Clients kommunizieren dann nur noch mit der Server Applikation.

Nun stellen sich mir folgende Fragen:
Welche Technologien sind ratsam/ best practice für...
... die Kommunikation zwischen Client und Server? (HTTP, RMI, JSON)
... die Implementierung der Server Applikation? Hier hat die Performance die höchste Priorität. Alle Anfragen müssen möglichst schnell bearbeitet werden und keine Anfragen dürfen verloren gehen. Ansonsten wäre die Gefahr, dass falsche Daten in der Datenbank landen? (Ist eine einfache Java Applikation genügend?)
Kommunikation mit der Datenbank werden nur durch explizite User aktionen ausgelöst, sind also nicht besonders häufig (e.g. refresh, save etc..)

Freue mich auf eure Ratschläge und den folgenden Erfahrungsaustauch!

Grüße
Basti
 
Zuletzt bearbeitet:
Bei dem Eclipse Plugin handelt es sich um ein Tool um Testfälle zu spezifizieren. Das heisst Benutzer können in einem TreeEditor Strukturen erzeugen. Jedes TreeElement representiert dabei entweder ein rein strukturelles Element oder eine Testfallspezifikation. Diese TreeElemente können dann noch in einer anderen View spezieller bearbeitet/editiert werden.

Bei jeder Änderung im Tree wird die Datenbank direkt geupdatet. Bei Änderungen eines TreeElements wird die Datenbank nach einem "Save" geupdatet.

Das ist der Haupt Use Case des Tools, es bietet aber noch diverse andere Use Cases z.B. eine Suche, einen Trace, Requirementspezifizierung(auch als TreeViewer), diverse editoren etc.
 
Nunja, um einfach zu bleiben, würde ich einen Applikationsserver (Apache Tomcat) und einen REST-Service (Stichworte: resteasy, gson) hinstellen. Der Applserver ist bewährt, REST ist einfach angeeignet und implementiert (je nach Erfahrung) und durch JSON sehr schlank und HTTP ist auch einfach als Client zu verwenden.

Hier hat die Performance die höchste Priorität. Alle Anfragen müssen möglichst schnell bearbeitet werden und keine Anfragen dürfen verloren gehen. Ansonsten wäre die Gefahr, dass falsche Daten in der Datenbank landen?
Falsche Daten dürften eigentlich nur in einer Datenbank landen, wenn du sie falsch reinschreibst und/oder du kein Transaktionsmanagement verwendest (Transaktion öffnen, Daten verarbeiten, Transaktion bei Erfolg commiten und bei Exception rollbacken)

Was heisst möglichst schnell? Eine Nanosekunde? Eine Millisekunde? Eine Sekunde?
Dazu muss man bedenken, dass die Leitung zwischen Client und Server und zwischen Server und Datenbank vermutlich den grössten Bottleneck darstellt und dass so ein Request - so lange du nicht Pi auf die Millionste Stelle ausrechnest oder das Wetter für die nächsten 2 Wochen berechnest - vermutlich sehr wenig "Arbeitszeit" (also exkl. Zeit zu und von Datenbank) auf dem Server benötigt.

Ich würde hier eher bedenken, was man tun soll, damit der eine Client nicht die Daten eines anderen Client überschreibt. Dazu gibt's aber unterschiedliche Lösungen (Stichwort Locking)

Gruss,
slowy
 
Ersteinmal danke für die Antwort.

Transaktionsmanagement und Locking werden berücksichtigt.

Bezüglich der Performance reicht es aus, dass Anfragen innerhalb von ein paar Millisekunden bearbeitet werden. Auf dem Server werden sowieso kaum Berechnungen stattfinden. Ich schließe dann einfach aus deinem letzen Beitrag, dass es kein Problem ist, wenn 15-20 Clients frequentiell Anfragen an den Server stellen. Diese Anfragen wären größtenteils Schreiboperationen auf der Datenbank.

Wie würde dann die vom Server angebotene Schnittstelle nach aussehen(Falls ich mit RESTEasy arbeite)? Wären es eine Reihe von HTTP "Befehlen"?
In Zukunft sollen auch andere Tools diesen Server benutzen um beispielsweise TestLoggings in die Datenbank zu schreiben, dafür wäre eine saubere Schnittstelle sehr hilfreiche (nicht wie bisher rohe SQL Statements).

RESTEasy hat den Vorteil, dass es einfach zu implementieren ist, ibt es noch andere Gründe RESTEasy zu benutzen?

Grüße
Basti
 
Bezüglich der Performance reicht es aus, dass Anfragen innerhalb von ein paar Millisekunden bearbeitet werden.
Uhm, ein paar Millisekunden... Wenn wir davon ausgehen, dass 10ms vom Klick am Client, über Server/DB zurück zum Client zurück gemessen wird, wirst du das vermutlich so nicht erreichen. Client->Netzwerk->Applikationsserver->Netzwerk->Datenbank->Netzwerk->Applikationsserver->Netzwerk->Client -> sind schon viele Stellen, die durchgelaufen werden müssen.
Und ich kenne die Daten ja nicht, die du verschickst, aber die müssen dann auch mal von "JSON" zu "Java Objekten" geparst werden und die Ausgabe wieder zurück - das täuscht manchmal, aber auch das braucht Rechenzeit.
Aber ich denke, mit Hardware, die nicht gerade von 10 Jahren angeschafft wurde und du keine Megabytes an Daten hin- und herschickst, sind 100ms machbar und für einen Benutzer keinen merkbaren Unterschied zu 10ms.

Wie würde dann die vom Server angebotene Schnittstelle nach aussehen(Falls ich mit RESTEasy arbeite)? Wären es eine Reihe von HTTP "Befehlen"?
Jein. REST ist da eben ein Gemisch aus HTTP Befehlen und einer Programmierschnittstelle.
Prinzipiell:
GET = Ressource anfordern
POST = Ressource anlegen
Des weiteren definierst du dann eine Schnittstelle. Z.B. (RESTeasy)
Code: 
@Path("/kunde")
public interface KundeService{
  @GET // <- HTTP Method
  @Path("/search")
  Kunde searchKunde(Long idKunde);
}
Was wir in unseren Services machen ist immer ein In- und ein Outobjekt, welche als Präfix den dazugehörigen Methodennamen verwenden:
Code: 
GetKundeOut getKunde(GetKundeIn, kunde);

In Zukunft sollen auch andere Tools diesen Server benutzen um beispielsweise TestLoggings in die Datenbank zu schreiben, dafür wäre eine saubere Schnittstelle sehr hilfreiche (nicht wie bisher rohe SQL Statements).
Das ist natürlich immer das beste, wenn man möglichst viele Consumer beim Design eines Services an einen Tisch holt. Denn was für den einen Consumer in Ordnung ist, heisst dann nicht, dass ein anderer Consumer das auch so sieht. (Beispiel: Wenn eine Applikation alle Einträge in einer Tabelle lesen muss, eine andere Applikation aber nur die letzten 10 Einträge. Wenn man die Option "nur die letzten 10 Einträge" nicht zur Verfügung stellt, kann die zweite Applikation dann den grössten Teil der Daten wegwerfen). Und hier hat man dann das Problem bei "Breaking Changes" -> also wenn man eine Schnittstelle so abändert, dass ein Consumer nicht mehr damit arbeiten kann. Dazu fallen mir noch paar Stichworte ein:
- Governance (Welcher Consumer benutzt welchen Service / Welche Methode / Welche Version)
- Versionisierung (Müssen z.B: zwei Versionen parallel laufen können für Pilotierungen, Tests, etc)

RESTEasy hat den Vorteil, dass es einfach zu implementieren ist, ibt es noch andere Gründe RESTEasy zu benutzen?
Also nicht RESTEasy selbst hat den Vorteil, dass es einfach zu implementieren ist, sondern REST im allgemeinen.
Vorteile von REST/HTTP:
- HTTP kennt man, kann man sniffen und verstehen.
- HTTPS ist einfach eingerichtet
- Weitere Security Aspekte sind standardisiert (Basic-Auth, NTLM, etc)
- RESTService kann man einfach im Browser testen
- Verhältnis Nutzdaten/Overhead ist relativ gering, zum Beispiel im Vergleich zu SOAP/XML. "Nativere" Protokollen sind da vermutlich besser, weil insbesondere der HTTP Header wegfällt.
- Technologieunabhängig, heisst, dass man auch mit c# oder JavaScript - also auch Mobile Geräte - darauf zugreifen können.

Gruss,
slowy
 
Aha,

ich probiere RESTEasy aus.

Macht es einen Unterschied welcher Applikationsserver dahinter liegt? Du erwähntest Apache Tomcat. Wir arbeiten hier mit einem Microsoft Applikationsserver.

Grüße
Basti
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück