# verteilte Anwendungen übers Internet



## Sascha Laurent (24. Feb 2010)

Hallo Leute,

da ich noch nicht soviel Ahnung von verteilten Anwendungen übers Internet habe ich zwei fragen hierzu:

Es ist doch richtig, daß man eine Anwendung auf dem Server erstellen kann und dann verteilt auch als Rich-Client abfragen kann. D.h. die Geschäftslogik liegt auf dem Server und die Views auf dem Client? 
Wie heißt das Protokoll das zwischen Server und Client fungiert? Ist das RMI? 
Wie werden die Datenpakete übertragen als XML? 
Wo könnte ich dieses Nachlesen, da mir leider jeglicher Bezug fehlt weiß ich nicht wonach ich googeln sollte. 
Was müßte man bei der Sicherheit beachten? Denn diese Pakete könnten doch abgefangen und ausgelesen werden?
Hierfür wäre doch ein Applikation-Server von nöten?

Danke
Sascha


----------



## Gast2 (24. Feb 2010)

Du kannst jedes Protokoll verwenden das du für geeignet hälst. du musst halt nur die Kommunikation zwischen dem Server und den Client sauber definieren. Ob du dafür SOAP, REST, RMI, JSON aber was anderes nimmst ist erstmal egal. 

Wegen der Sicherheit - du kannst auch SSL mit RMI nutzen.


----------



## Sascha Laurent (25. Feb 2010)

Jetzt habe ich doch ein Verständlichkeits Problem. Also RMI benutzt man um Funktionen auf einem anderen Server aufzurufen also z.B. bei EJB, Richtig? SOAP wird doch als SOAP over HTTP für WSDL in einer SOA verwendet, Richtig? REST ist eine Alternative zu SOAP, Richtig? JSON wird meines wissens nur in Webanwendungen eingesetzt, Richtig? Wie lautet aber die Verbindung zwischen einem mit z.B. SWT erstellten Rich-Client und dem Anwendungsserver? Woher weis die Rich-Client z.B. das es neu Funktionen gibt?

Danke
Sascha


----------



## Noctarius (26. Feb 2010)

SOAP, RMI, SIMON, ActiveMQ (teils) ... sind alles so genannte Remote Invocation Systeme. Du sagst dem Server damit "führ mir mal die Funktion aus und gib das Ergebnis her". Solche Implementierungen haben oft ein eigenes Protokol, prinzipiell kannst du aber auch ein eigenes definieren und quasi selbst TCP-Befehle direkt senden. Nur machen vieler solcher RI-Systeme die Arbeit einfacher, da man typensicher gegen Interfaces arbeiten kann.

Ein nettes Gimmick ist dabei Spring Remoting, welches als oberster Wrapper ein einheitliches API stellt und im Untergrund viele verschiedene RI-Implementierungen nutzen kann. Vor allem dann fein, wenn man mal die Geschwindigkeit von den Implementierungen testen will ohne den Code zu ändern.


----------



## Atze (26. Feb 2010)

man sollte sich aber auch überlegen, wo man damit durch muss. wenns über das web, bzw über firmengrenzen hinweg ist, vielleicht zu http greifen, weil man damit durch jede firewall kommt. beim rest wirds schwieriger.


----------



## Sascha Laurent (26. Feb 2010)

Noctarius hat gesagt.:


> SOAP, RMI, SIMON, ActiveMQ (teils) ... sind alles so genannte Remote Invocation Systeme. Du sagst dem Server damit "führ mir mal die Funktion aus und gib das Ergebnis her". Solche Implementierungen haben oft ein eigenes Protokol, prinzipiell kannst du aber auch ein eigenes definieren und quasi selbst TCP-Befehle direkt senden. Nur machen vieler solcher RI-Systeme die Arbeit einfacher, da man typensicher gegen Interfaces arbeiten kann.
> 
> Ein nettes Gimmick ist dabei Spring Remoting, welches als oberster Wrapper ein einheitliches API stellt und im Untergrund viele verschiedene RI-Implementierungen nutzen kann. Vor allem dann fein, wenn man mal die Geschwindigkeit von den Implementierungen testen will ohne den Code zu ändern.



Danke Noctarius 

Als erstes: Okay, das ist mir soweit erstmal klar.
Als zweites: Bringst du hier nicht ein paar Sachen durcheinander? SOAP und RMI sind Protokolle, Simon höre ich zum erstenmal (was ist das?) aber ActiveMQ ist doch ein Produkt von Apache und kein Protokoll. Das Protokoll hierfür ist doch JMS - Oder?
Ferner schreibst du "gegen Interface" dieses habe ich schon öfters gehört "gegen <etwas>" was heißt das?


----------



## damien (26. Feb 2010)

Gegen Interface bedeutet, dass du dir z.B. aus einer WSDL für SOAP sogenannte Stub und Skeletonklassen generieren kannst. Die Stubs benutzt du dann für deinen Client und programmierst gegen lokale Objekte, der Rest wird im Hintergrund automatisch gemacht (Kommunikation Client-Server).


----------



## FArt (26. Feb 2010)

Wenn man Client und Server in der Hand hat: Spring Remoting ist sehr einfach zu verwenden. Es gibt eine Implementierung und daszu ein Java Interface... und genau dieses kann man remote exposen und vom Client dann über einen (auch generischen) Stub bedienen... das ganze über beliebige Protokolle, z.B. RMI oder HTTP...


----------



## Noctarius (26. Feb 2010)

Sascha Laurent hat gesagt.:


> Danke Noctarius
> 
> Als erstes: Okay, das ist mir soweit erstmal klar.
> Als zweites: Bringst du hier nicht ein paar Sachen durcheinander? SOAP und RMI sind Protokolle, Simon höre ich zum erstenmal (was ist das?) aber ActiveMQ ist doch ein Produkt von Apache und kein Protokoll. Das Protokoll hierfür ist doch JMS - Oder?
> Ferner schreibst du "gegen Interface" dieses habe ich schon öfters gehört "gegen <etwas>" was heißt das?



RMI ist ein komplettes Remote Invocation System (Remote Method Invocation). SOAP ist eine Sammelbezeichnung für eine gesamte Palette von HTTP- bzw. TCP-basierten Protokollen (unter anderem für WSDL basierte Systeme). ActiveMQ ist ein Message-based-Queue System mit dem man nur Daten übertragen aber auch Remote Invocations machen kann. Auch hier ist JMS nur eine mögliche Transport-Schicht (aber eine der besten).

SpringRemoting wiederum ist ein Überbau über nahezu alle diese Techniken und vereinheitlicht über Wrapper die Bedienung.

SIMON ist ein von tuxedo gebastelter RMI Ersatz auf Basis von nio (also der aktuellen IO Schicht in Java) statt Socket und Serversocket wie RMI. Zusätzlich vereinfacht SIMON den Einsatz von SSL und vor allem werden viele Probleme von RMI (wie z.B. der nicht vorhandene Firewall-Support) gelöst. Sagen wir einfach SIMON ist das aktuallisierte RMI  (auch hier gibt es demnächst eine SpringRemoting Extention )


----------



## Sascha Laurent (27. Feb 2010)

Noctarius hat gesagt.:


> ActiveMQ ist ein Message-based-Queue System mit dem man nur Daten übertragen aber auch Remote Invocations machen kann. Auch hier ist JMS nur eine mögliche Transport-Schicht (aber eine der besten).



Danke für die Aufklärung Noctarius.

Eine Frage habe ich dann aber doch noch welches Protokoll außer JMS kann man denn sonst noch mit ActivMQ benutzen?

Danke
Sascha


----------



## Sascha Laurent (27. Feb 2010)

Habes nochmal durchgelesen und hoffe es jetzt verstanden zu haben. 

Also ActivMQ kann mit JMS, RMI, SIMON benutzt werden - Richtig? Gibt es noch andere, die zum Einsatz kommen? Wann lohnt sich welches Protokoll? Okay JMS ist mir klar, es hat Topic und Que und asynchron. RMI ist soweit ich weiß nur synchron einsetzbar und Simon bzw. die noch nicht genannten?

Ich habe versucht über SIMON in Wikipedia näheres zu erfahren, aber wegen der vielen Simon's habe ich es nicht gefunden. Hast du
eine Internetseite wo man sich schlauer machen kann?

Danke
Sascha

P.S. Sorry das mit Simon hat sich geklärt hätte besser googlen müssen. Wenn es interessiert auf root1.de - Software Engineering | ... where software needs get covered findet Ihr Informationen zu SIMON.


----------



## Noctarius (27. Feb 2010)

Sascha Laurent hat gesagt.:


> P.S. Sorry das mit Simon hat sich geklärt hätte besser googlen müssen. Wenn es interessiert auf root1.de - Software Engineering | ... where software needs get covered findet Ihr Informationen zu SIMON.



Brauchst doch hier im Forum nur tuxedo zu fragen wenn es um SIMON geht 

Zu ActiveMQ, da muss man nur die Website lesen 
Apache ActiveMQ -- Cross Language Clients


----------

