Grafische Einführung in die Java-Fernkommunikationstechnologie und Prinzipanalyse

Im verteilten Service-Framework ist eines der grundlegendsten Probleme die Art und Weise, wie Remote-Services kommunizieren. Es gibt viele Technologien, die Remote-Kommunikation im Java-Bereich erreichen können, wie zum Beispiel: RMI, MINA, ESB, Burlap, Hessian, SOAP, EJB, JMS usw., welche Beziehung besteht zwischen diesen Begriffen und auf welchen Prinzipien basieren sie? Das Verständnis dieser Begriffe ist das Grundwissen für die Implementierung eines verteilten Service-Frameworks. Wenn hohe Leistungsanforderungen bestehen, ist ein erforderlich tiefes Verständnis der Mechanismen hinter diesen Technologien.

1 Grundprinzip

Um die Kommunikation zwischen Netzwerkmaschinen zu erreichen, müssen wir uns zunächst die Grundprinzipien der Netzwerkkommunikation in Computersystemen ansehen. Auf der zugrunde liegenden Ebene muss die Netzwerkkommunikation Folgendes tun Streams konvertieren Die Übertragung von einem Computer zu einem anderen wird basierend auf Übertragungsprotokollen und Netzwerk-E/A implementiert. Zu den bekannteren Übertragungsprotokollen gehören TCP, UDP usw. TCP und UDP basieren alle auf dem Socket-Konzept und werden für bestimmte Typen erweitert Zu den Anwendungsszenarien gehören hauptsächlich Bio, Nio und AIO. Die gesamte verteilte Anwendungskommunikation wird nur aus Gründen der Benutzerfreundlichkeit der Anwendung bereitgestellt Näher an der Anwendung. Einfach zu verwendendes Anwendungsschichtprotokoll.

2 Nachrichtenmodus

Letztendlich ist ein Unternehmensanwendungssystem die Verarbeitung von Daten, und für ein Unternehmensanwendungssystem mit mehreren Subsystemen ist seine grundlegende Unterstützung zweifellos die Verarbeitung von Nachrichten. Im Gegensatz zu Objekten handelt es sich bei einer Nachricht im Wesentlichen um eine Datenstruktur (natürlich kann ein Objekt auch als spezielle Nachricht betrachtet werden). Diese Daten müssen sowohl vom Verbraucher als auch vom Dienst identifiziert werden werden in unterschiedlichen Prozessen (Maschinen) gespeichert und können von mehreren völlig unterschiedlichen Clients genutzt werden. Messaging scheint besser zu sein als File Passing und Remote Procedure Call (RPC), da es eine bessere Plattformunabhängigkeit aufweist und gleichzeitige und asynchrone Aufrufe gut unterstützen kann.

Für Web Service und RESTful kann es als Ableitung oder Kapselung der Messaging-Technologie angesehen werden.

2.1 Nachrichtenkanalmodus

Der von uns häufig verwendete Nachrichtenmodus ist der Nachrichtenkanalmodus, wie in der Abbildung dargestellt.

Der Nachrichtenkanal ist eine indirekte Schicht, die zwischen dem Client (Verbraucher) und dem Dienst (Produzent) eingeführt wird und die Beziehung zwischen den beiden effektiv auflösen kann. Solange das Nachrichtenformat, das beide Parteien kommunizieren müssen, sowie der Mechanismus und der Zeitpunkt der Verarbeitung der Nachricht implementiert sind, kann der Verbraucher den Produzenten „ignorieren“. Tatsächlich kann dieses Modell mehrere Produzenten und Verbraucher unterstützen. Beispielsweise können wir mehrere Produzenten Nachrichten an den Nachrichtenkanal senden lassen. Da der Konsument den Produzenten nicht kennt, muss er nicht berücksichtigen, welcher Produzent die Nachricht gesendet hat.

Obwohl der Nachrichtenkanal den Produzenten und den Konsumenten entkoppelt, sodass wir den Produzenten und den Konsumenten beliebig erweitern können, führt er auch ihre jeweiligen Abhängigkeiten vom Nachrichtenkanal ein, da der Standort der Kanalressource bekannt sein muss. Um diese Abhängigkeit vom Kanal zu verringern, können Sie erwägen, den Lookup-Dienst einzuführen, um die Kanalressource zu finden. In JMS können Sie beispielsweise die Nachrichtenkanalwarteschlange über JNDI abrufen. Um volle Flexibilität zu erreichen, können kanalbezogene Informationen in der Konfigurationsdatei gespeichert werden. Der Lookup-Dienst erhält den Kanal zunächst durch Lesen der Konfigurationsdatei.

Nachrichtenkanäle liegen normalerweise in Form von Warteschlangen vor. Diese First-In-First-Out-Datenstruktur ist zweifellos am besten für dieses Nachrichtenverarbeitungsszenario geeignet. MSMQ, IBM MQ, JBoss MQ von Microsoft sowie die Open-Source-Programme RabbitMQ und Apache ActiveMQ implementieren alle den Message Channel-Modus über Warteschlangen. Wenn Sie sich für die Verwendung des Message-Channel-Modells entscheiden, ist es daher notwendiger, eine umfassende Analyse und einen Kompromiss zwischen verschiedenen Produkten durchzuführen, die dieses Modell unter dem Gesichtspunkt der Qualitätsattribute implementieren. Zum Beispiel die Unterstützung des Nachrichtenkanals für Parallelität und Leistung; ob der Nachrichtenkanal die Fehlerbehandlung vollständig berücksichtigt; Unterstützung für Nachrichtenpersistenz, Notfallwiederherstellung (Failover) und Clustering.

Da es sich bei den vom Kanal übertragenen Nachrichten häufig um wichtige Geschäftsdaten handelt, hat dies katastrophale Auswirkungen auf das System, sobald der Kanal zu einem Fehlerpunkt oder einer Sicherheitslücke wird.

Der Mechanismus von JNDI wird hier ebenfalls erwähnt. Da JNDI von der spezifischen Implementierung abhängt, können wir hier nur die Implementierung von JNDI von JBoss erklären:

In der Zukunft Nach dem Objekt Die Instanz ist an den JBoss-JNP-Server gebunden. Wenn das Remote-Ende die Methode context.lookup() verwendet, um die Remote-Objektinstanz abzurufen, und mit dem Aufruf beginnt, besteht die Implementierungsmethode von JBoss JNDI darin, die Objektinstanz vom JNP-Server abzurufen und zu serialisieren Zurück zum lokalen Deserialisieren und dann lokal Klassenaufrufe durchführen.

Durch diesen Mechanismus können Sie wissen, dass der lokale Ort tatsächlich eine Klasse haben muss, die an die Objektinstanz auf jboss gebunden ist. Andernfalls schlägt die Deserialisierung definitiv fehl und es muss eine Remotekommunikation durchgeführt werden. Dies dient dazu, eine Aktion auszuführen aus der Ferne und erhalten Sie die entsprechenden Ergebnisse. Es ist ersichtlich, dass eine Remote-Kommunikation nicht ausschließlich auf Basis von JNDI erreicht werden kann.

Aber JNDI ist auch ein wichtiger technischer Punkt bei der Implementierung des verteilten Service-Frameworks, da es wie ejb zum Erreichen transparenter Remote- und lokaler Aufrufe verwendet werden kann. Darüber hinaus ist es auch ein guter versteckter tatsächlicher Bereitstellungsmechanismus (nur Lösungen). (z. B. Datenquelle).

2.2 Publisher-Subscriber-Modell

Sobald ein Nachrichtenkanal mehrere Verbraucher unterstützen muss, stehen Sie möglicherweise vor der Wahl zwischen zwei Modellen: Pull-Modell und Push-Modell. Das Pull-Modell wird vom Verbraucher der Nachricht initiiert, und die Initiative liegt in den Händen des Verbrauchers, der entsprechend seiner eigenen Situation einen Anruf beim Produzenten einleitet. Wie in der Abbildung gezeigt:

Eine weitere Ausführungsform des Pull-Modells besteht darin, dass der Produzent den Verbraucher darüber informiert, dass sich sein Status geändert hat, wenn sich der Status ändert. Der benachrichtigte Verbraucher wird jedoch einen Rückruf verwenden, um detailliertere Informationen zu erhalten, indem er das übergebene Verbraucherobjekt aufruft.

In einem nachrichtenbasierten verteilten System hört der Verbraucher des Pull-Modells normalerweise regelmäßig nach einem voreingestellten Zeitintervall in Form eines Batch-Jobs den Kanalstatus ab. Sobald festgestellt wird, dass eine Nachricht übermittelt wurde, wird sie an den eigentlichen Prozessor (der auch als Verbraucher betrachtet werden kann) übertragen, um die Nachricht zu verarbeiten und damit verbundene Dienste auszuführen.

Die Initiative zur Förderung des Modells liegt häufig in den Händen des Herstellers, und der Verbraucher wartet passiv auf Benachrichtigungen des Herstellers, was erfordert, dass der Hersteller die relevanten Informationen des Verbrauchers kennt. Wie in der Abbildung gezeigt:

Für das Push-Modell muss der Verbraucher den Produzenten nicht kennen. Wenn ein Produzent einen Verbraucher benachrichtigt, wird häufig die Nachricht (oder das Ereignis) übermittelt, nicht der Produzent selbst. Gleichzeitig können Hersteller in der gekapselten Benachrichtigungslogik auch unterschiedliche Verbraucher je nach Situation registrieren oder unterschiedliche Verbraucher je nach Statusänderung benachrichtigen.

Beide Modelle haben ihre eigenen Vorteile. Der Vorteil des Pull-Modells besteht darin, dass es Verbraucher weiter von ihrer Abhängigkeit vom Kanal entlasten und über Hintergrundaufgaben regelmäßig auf den Nachrichtenkanal zugreifen kann. Der Nachteil besteht darin, dass ein separater Serviceprozess in Form eines Zeitplans eingeführt und ausgeführt werden muss. Beim Push-Modell dient der Nachrichtenkanal tatsächlich als Gegenstand der Verbraucherbeobachtung. Sobald eine Nachricht entdeckt wird, wird der Verbraucher benachrichtigt, die Nachricht zu verarbeiten. Unabhängig vom Push- oder Pull-Modell kann für Nachrichtenobjekte ein Mechanismus ähnlich dem Observer-Muster verwendet werden, um Verbraucherabonnements für Produzenten zu implementieren. Daher wird dieser Mechanismus häufig als Publisher-Subscriber-Muster bezeichnet, wie in gezeigt die Abbildung:

Normalerweise werden Herausgeber und Abonnenten auf der Infrastruktur registriert, die zur Verbreitung von Änderungen verwendet wird (d. h. Nachrichtenkanäle). Der Herausgeber versteht den Nachrichtenkanal aktiv, sodass er Nachrichten an den Kanal senden kann. Sobald der Nachrichtenkanal die Nachricht empfängt, ruft er die im Kanal registrierten Abonnenten aktiv auf, um den Verbrauch des Nachrichteninhalts abzuschließen.

Für Abonnenten gibt es zwei Möglichkeiten, Nachrichten zu verarbeiten. Eine Möglichkeit ist der Broadcast-Mechanismus. Wenn die Nachricht im Nachrichtenkanal zu diesem Zeitpunkt aus der Warteschlange entfernt wird, muss auch das Nachrichtenobjekt kopiert werden, um die Nachricht an mehrere Abonnenten zu übermitteln . Beispielsweise gibt es mehrere Subsysteme, die Kundeninformationen aus dem CRM-System abrufen und auf der Grundlage der übergebenen Kundeninformationen entsprechende Verarbeitungen durchführen müssen. Der Nachrichtenkanal wird zu diesem Zeitpunkt auch als Ausbreitungskanal bezeichnet. Die andere Methode ist ein Preemption-Mechanismus, der einer synchronen Methode folgt und nur ein Abonnent die Nachricht gleichzeitig verarbeiten kann . Ein Nachrichtenkanal, der das Publisher-Subscriber-Muster implementiert, wählt den einzigen derzeit inaktiven Abonnenten aus, entfernt die Nachricht aus der Warteschlange und übergibt sie an die Nachrichtenverarbeitungsmethode des Abonnenten.

Derzeit gibt es viele Nachrichten-Middlewares, die das Publisher-Subscriber-Muster gut unterstützen können, wie zum Beispiel die MessagePublisher- und MessageSubscriber-Schnittstellen, die für Topic-Objekte in der JMS-Schnittstellenspezifikation bereitgestellt werden. RabbitMQ bietet auch eine eigene Implementierung dieses Musters. Obwohl MSMQ von Microsoft einen Ereignismechanismus eingeführt hat, kann dieser Ereignisse auslösen, um Abonnenten zu benachrichtigen, wenn die Warteschlange eine Nachricht empfängt. Es handelt sich jedoch nicht unbedingt um eine Implementierung des Publisher-Subscriber-Musters. NServiceBus, mit Microsoft MVP Udi Dahan als Hauptmitwirkender, paketiert MSMQ und WCF weiter und kann dieses Modell gut implementieren.

2.3 Message-Router-Modus

Ob es sich um den Message-Channel-Modus oder den Publisher-Subscriber-Modus handelt, die Warteschlange spielt dabei eine zentrale Rolle. Wenn das System jedoch immer komplexer wird, werden auch die Leistungsanforderungen immer höher. Zu diesem Zeitpunkt muss das System möglicherweise die gleichzeitige Bereitstellung mehrerer Warteschlangen unterstützen und erfordert möglicherweise die Bereitstellung unterschiedlicher Warteschlangen . Diese Warteschlangen können je nach Definition unterschiedliche Nachrichten empfangen, z. B. Auftragsverarbeitungsnachrichten, Protokollinformationen, Abfrageaufgabennachrichten usw. Derzeit ist es nicht angemessen, dass Nachrichtenproduzenten und -konsumenten die Verantwortung für die Bestimmung des Nachrichtenübermittlungspfads übernehmen. Tatsächlich ist diese Art der Verantwortungszuweisung gemäß dem S-Prinzip der Einzelverantwortung auch unangemessen. Sie ist nicht förderlich für die Wiederverwendung von Geschäftslogik und führt auch zu einer Kopplung zwischen Produzenten, Verbrauchern und Nachrichtenwarteschlangen, wodurch die Erweiterung beeinträchtigt wird System.

Da diese drei Objekte (Komponenten) nicht für die Übernahme solcher Aufgaben geeignet sind, ist es notwendig, ein neues Objekt einzuführen, das speziell für die Funktion der Pfadauswahl zuständig ist. Dies ist die sogenannte Nachricht Router-Muster , wie in der Abbildung gezeigt:

Durch Nachrichtenrouting können wir Routingregeln konfigurieren, um den Pfad der Nachrichtenübermittlung anzugeben und den entsprechenden Produzenten anzugeben der spezifische Verbraucherverbrauch. Geben Sie beispielsweise das Routing-Schlüsselwort an und verwenden Sie es, um eine bestimmte Warteschlange an den angegebenen Produzenten (oder Verbraucher) zu binden. Die Routing-Unterstützung bietet Flexibilität bei der Nachrichtenübermittlung und -verarbeitung und trägt außerdem dazu bei, die Nachrichtenverarbeitungsfähigkeiten des gesamten Systems zu verbessern. Gleichzeitig kapselt das Routing-Objekt effektiv die Logik zum Finden und Anpassen von Nachrichtenpfaden, genau wie ein Vermittler (Meditator), der für die Koordinierung der Beziehung zwischen Nachrichten, Warteschlangen und Pfadadressierung verantwortlich ist.

3 Protokoll auf Anwendungsebene

Remote-Service-Kommunikation. Das zu erreichende Ziel besteht darin, eine Anfrage auf einem Computer zu initiieren, und der andere Computer verarbeitet die Anfrage entsprechend, nachdem er sie erhalten hat, und gibt sie zurück result to Auf der Anforderungsseite gibt es Anforderungsmethoden wie Einweganforderung, synchrone Anforderung, asynchrone Anforderung usw. Gemäß dem Prinzip der Netzwerkkommunikation muss dazu die Anforderung in einen Stream umgewandelt werden Übertragen Sie es über das Übertragungsprotokoll an das entfernte Ende. Der Endcomputer verarbeitet den angeforderten Stream nach Abschluss der Verarbeitung, konvertiert ihn in einen Stream und sendet ihn über das Übertragungsprotokoll an das anrufende Ende zurück.

Das Prinzip ist wie folgt, aber zur Vereinfachung der Anwendung hat die Branche viele Protokolle auf Anwendungsebene eingeführt, die auf diesem Prinzip basieren, sodass nicht jeder solche Dinge auf niedriger Ebene, normalerweise Anwendungen, direkt bedienen muss -Fernkommunikation auf Ebene Das Protokoll bietet Folgendes:

1. Um die Probleme der direkten Durchführung von Stream-Vorgängen zu vermeiden, stellt es ein Standardübertragungsformat bereit, das einfacher zu verwenden oder besser geeignet ist Sprache;

2. Die Implementierung des Netzwerkkommunikationsmechanismus besteht darin, das Übertragungsformat für Sie in einen Stream umzuwandeln und ihn nach dem Empfang des Streams an den Remote-Computer zu übertragen , der Remote-Computer wandelt es in ein Übertragungsformat um und speichert es oder verwendet es auf eine bestimmte Weise, um den Remote-Computer zu benachrichtigen.

Wenn wir also Fernkommunikationsprotokolle auf Anwendungsebene lernen, können wir mit diesen Fragen lernen:

1. Standardformat für die Übertragung Was ist das?

2. Wie wandelt man die Anfrage in einen übertragenen Stream um?

3. Wie empfange und verarbeite ich Streams?

4. Was ist das Übertragungsprotokoll?

Das Remote-Kommunikationsprotokoll auf Anwendungsebene wird jedoch keine große Verbesserung im Übertragungsprotokoll bewirken. Es betrifft hauptsächlich den Stream-Betrieb, sodass die Anwendungsschicht Streams generieren und Streams verarbeiten kann. Es entspricht eher der verwendeten Sprache oder dem verwendeten Standard und ist normalerweise optional. Die bekanntesten im Java-Bereich sind: RMI, XML-RPC, Binary-RPC, SOAP, CORBA, JMS. Um genau zu sein, werfen Sie einen Blick auf diese Protokolle auf Anwendungsebene für die Remote-Kommunikation.

3.1 RMI (Remote Method Invocation)

RMI ist ein typisches Remote-Kommunikationsprotokoll, das für Java angepasst wurde. Wir alle wissen, dass wir dies in einer einzelnen VM erreichen können, indem wir die Java-Objektinstanz direkt aufrufen. Dann wäre es natürlich am besten, wenn diese Methode für die Fernkommunikation verwendet werden könnte. Dieser Fernkommunikationsmechanismus heißt RPC (Remote Procedure Call), und RMI wurde für dieses Ziel entwickelt.

RMI verwendet Stubs und Skeletons, um mit entfernten Objekten zu kommunizieren. Der Stub fungiert als Client-Proxy des Remote-Objekts und verfügt über dieselbe Remote-Schnittstelle wie das Remote-Objekt. Der Aufruf des Remote-Objekts erfolgt tatsächlich durch Aufrufen des Client-Proxy-Objekt-Stubs des Objekts Es handelt sich um ein lokales TCP/IP-Protokoll. Der Client ruft einige Methoden direkt auf dem Server auf. Der Vorteil besteht darin, dass es stark typisiert ist und Fehler während der Kompilierung überprüft werden können. Der Nachteil besteht darin, dass es nur auf der JAVA-Sprache basieren kann und Client und Server eng miteinander verbunden sind.

Werfen wir einen Blick auf das Prinzip eines vollständigen Remote-Kommunikationsprozesses auf Basis von RMI:

1. Der Kunde initiiert eine Anfrage und die Anfrage wird ausgeführt an den RMI-Client weitergeleitet.

2. Die Stub-Klasse serialisiert die angeforderten Schnittstellen, Methoden, Parameter und andere Informationen angeforderte Informationen basierend auf Socket Stream zum Server;

3. Der Server empfängt den Stream und leitet ihn an die entsprechende Skelton-Klasse weiter.

4. Die Skelton-Klasse deserialisiert die eigentliche Verarbeitungsklasse

5. Nachdem die Verarbeitungsklasse die Verarbeitung abgeschlossen hat, wird das Ergebnis an die Skelton-Klasse zurückgegeben.

6. Die Skelton-Klasse serialisiert das Ergebnis und sendet es der Stream zum Client über den Socket. Der Stub am Ende wird nach dem Empfang des Streams deserialisiert und gibt das deserialisierte Java-Objekt an den Aufrufer zurück.

7. Basierend auf den Prinzipien beantworten wir einige Fragen, die zuvor beim Erlernen von Protokollen auf Anwendungsebene aufkamen:

Übertragungsstandards Was ist das Format?

ist ein Java ObjectStream.

1. Wie wandelt man die Anfrage in einen übertragenen Stream um?
Konvertieren Sie die angeforderten Java-Objektinformationen basierend auf dem Java-Serialisierungsmechanismus in einen Stream.

2. Wie empfange und verarbeite ich Streams?
Starten Sie den entsprechenden Überwachungsport gemäß dem angenommenen Protokoll. Wenn ein Stream eingeht, wird der Stream basierend auf dem Java-Serialisierungsmechanismus deserialisiert und die entsprechenden Verarbeitungsobjektinformationen werden gemäß dem RMI-Protokoll abgerufen, aufgerufen und verarbeitet Die Verarbeitung ist abgeschlossen. Das Endergebnis wird auch basierend auf dem Java-Serialisierungsmechanismus zurückgegeben.

3. Was ist das Übertragungsprotokoll?
Steckdose.

4. 3.2 XML-RPC

RPC verwendet den C/S-Modus, übernimmt das http-Protokoll, sendet eine Anfrage an den Server und wartet darauf, dass der Server das Ergebnis zurückgibt. Die Anfrage umfasst einen Parametersatz und einen Textsatz, normalerweise in der Form „Klassenname.Methodenname“. Der Vorteil besteht darin, dass es sprach- und plattformübergreifend ist und die C-Seite und die S-Seite eine größere Unabhängigkeit haben. Der Nachteil besteht darin, dass es keine Objekte unterstützt und keine Fehler im Compiler überprüfen kann, sondern nur zur Laufzeit .

XML-RPC ist ebenfalls ein Remote-Aufrufprotokoll ähnlich wie RMI. Der Unterschied zu RMI besteht darin, dass es das Standard-XML-Format verwendet, um die angeforderten Informationen (angeforderte Objekte, Methoden, Parameter usw.) zu definieren Welche Vorteile bietet das? Es kann auch in der sprachübergreifenden Kommunikation eingesetzt werden.

Werfen wir einen Blick auf einen Fernkommunikationsprozess des XML-RPC-Protokolls:

Der Client initiiert eine Anfrage und füllt die Anfrageinformationen entsprechend aus XML-RPC-Protokoll;

1. Nach Abschluss des Füllvorgangs wird das XML in einen Stream umgewandelt und über das Übertragungsprotokoll

2. übertragen Empfangen und konvertieren Sie die angeforderten Informationen nach dem XML-RPC-Protokoll.

3. Schreiben Sie das Ergebnis nach der Verarbeitung in XML. RPC-Protokoll und geben Sie es zurück.

4. Beantworten Sie in ähnlicher Weise die Frage:

Was ist das Standardformat für die Übertragung?

Standardformat XML.

1. Wie wandelt man die Anfrage in einen übertragenen Stream um?
XML in Stream konvertieren.

2. Wie empfange und verarbeite ich Streams?
Erhalten Sie den angeforderten Stream über den Überwachungsport, konvertieren Sie ihn in XML, erhalten Sie die angeforderten Informationen gemäß dem Protokoll, verarbeiten Sie sie, schreiben Sie das Ergebnis in XML und geben Sie es zurück.

3. Was ist das Übertragungsprotokoll?
Http.

4. 3.3 Binär-RPC

Wie Sie am Namen erkennen können, ähnelt Binär-RPC XML-RPC. Der einzige Unterschied besteht im Standardformat der Übertragung wird aus XML für das Binärformat konvertiert.

Beantworten Sie in ähnlicher Weise die Frage:

Was ist das Standardformat für die Übertragung?

Binärdateien im Standardformat.

1. Wie wandelt man die Anfrage in einen übertragenen Stream um?
Konvertieren Sie Dateien im Binärformat in Streams.

2. Wie empfange und verarbeite ich Streams?
Rufen Sie den angeforderten Stream über den Überwachungsport ab, konvertieren Sie ihn in eine Binärdatei, erhalten Sie die angeforderten Informationen gemäß dem Protokoll, verarbeiten Sie sie, schreiben Sie das Ergebnis in XML und geben Sie es zurück.

3. Was ist das Übertragungsprotokoll?
Http.

4. 3.4 SOAP

SOAP bedeutet ursprünglich Simple Object Access Protocol, ein leichtes Kommunikationsprotokoll für den Informationsaustausch auf Basis von XML für verteilte Umgebungen SOAP ist eine erweiterte Version von XML RPC, beide sind http+XML. Der einzige Unterschied besteht darin, dass die von beiden definierten XML-Spezifikationen unterschiedlich sind Webservice, also hier keine weitere Ausarbeitung.

Die von Web Service bereitgestellten Dienste basieren auf Webcontainern. Es ähnelt einem Remote-Dienstanbieter, beispielsweise einem Wettervorhersagedienst stellt einen Request-Response-Mechanismus dar, der system- und plattformübergreifend ist. Die Bereitstellung von Diensten erfolgt über ein Servlet.

Zuerst ruft der Client die WSDL von WebService vom Server ab und generiert gleichzeitig eine Proxy-Klasse (Proxy-Klasse) auf dem Client. Diese Proxy-Klasse ist für die Anforderung und Antwort verantwortlich WebService-Server. Wenn ein Datenelement (im XML-Format) in einen Datenstrom im SOAP-Format gekapselt und an den Server gesendet wird, wird ein Prozessobjekt generiert und das von der Anforderung empfangene SOAP-Paket analysiert und anschließend verarbeitet. Nach Abschluss der Verarbeitung wird das Berechnungsergebnis in SOAP verpackt und das Paket dann als Antwort an die Proxy-Klasse des Clients gesendet. In ähnlicher Weise analysiert die Proxy-Klasse auch das SOAP-Paket und führt nachfolgende Vorgänge aus. Dies ist ein laufender Prozess von WebService.

Webservice ist im Allgemeinen in 5 Ebenen unterteilt:

1. HTTP-Transportkanal;

2. XML-Datenformat;

3. SOAP-Kapselungsformat;

4. Wie WSDL beschrieben wird;

5. UDDI UDDI ist ein Verzeichnisdienst, mit dem Unternehmen Webservices registrieren und durchsuchen können;

3.5 JMS

JMS ist ein Mittel und eine Methode zur Realisierung einer Fernkommunikation im Java-Bereich. Die auf JMS basierende Fernkommunikation unterscheidet sich von RPC, obwohl dies möglich ist Da es jedoch nicht auf Protokollebene definiert ist, glauben wir nicht, dass JMS ein RPC-Protokoll ist, sondern tatsächlich ein Remote-Kommunikationsprotokoll. Es gibt auch ähnliche Dinge wie JMS in anderen Sprachsystemen, die vereinheitlicht werden können Der Mechanismus wird als Nachrichtenmechanismus bezeichnet, und der Nachrichtenmechanismus ist normalerweise ein Kommunikationsmechanismus, der in Bereichen mit hoher Parallelität und verteilten Feldern empfohlen wird. Das Hauptproblem hierbei ist die Fehlertoleranz.

JMS ist ein Java-Nachrichtendienst, der über den JMS-Dienst asynchrone Nachrichten übertragen kann. JMS unterstützt zwei Nachrichtenmodelle: Point-to-Point (P2P) und Publish/Subscribe (Pub/Sub), nämlich das Point-to-Point- und das Publish-Subscribe-Modell .

Schauen wir uns den Prozess einer Remote-Kommunikation in JMS an:

1. Der Client wandelt die Anfrage in eine Nachricht um, die den JMS-Vorschriften entspricht

2. Stellen Sie die Nachricht über die JMS-API in die JMS-Warteschlange oder das JMS-Thema ein.

3. Wenn es sich um eine JMS-Warteschlange handelt, wird sie an das entsprechende Ziel gesendet Warteschlange. Wenn es sich um ein Thema handelt, wird es an die JMS-Warteschlange gesendet, die dieses Thema abonniert hat.

4. Das Verarbeitungsende erhält die Nachricht durch Rotieren der JMS-Warteschlange. Nach dem Empfang der Nachricht analysiert es die Nachricht und verarbeitet sie gemäß dem JMS-Protokoll.

Beantworten Sie in ähnlicher Weise die Frage:

1. Was ist das Standardformat für die Übertragung? Von JMS angegebene Nachricht.

2. Wie wandelt man die Anfrage in einen übertragenen Stream um? Fügen Sie die Parameterinformationen in die Nachricht ein.

3. Wie empfange und verarbeite ich Streams? Die JMS-Warteschlange wird rotierend darauf trainiert, die Nachricht zu empfangen. Nach Abschluss der Verarbeitung wird die Nachricht weiterhin zum Senden oder Multicasting in die Warteschlange gestellt.

4. Was ist das Übertragungsprotokoll? Kein Limit.

Basierend auf JMS ist es auch eine der am häufigsten verwendeten Methoden zur Implementierung asynchroner Remote-Aufrufe.

4 Unterschiede zwischen

4.1 RPC und RMI

1. RPC ist sprachübergreifend, während RMI nur Java unterstützt.

2. RMI ruft Remote-Objektmethoden auf, sodass Methoden Java-Objekte und grundlegende Datentypen zurückgeben können, während RPC das Konzept von Objekten nicht unterstützt und an RPC-Dienste übertragene Nachrichten durch externe Daten dargestellt werden Darstellung (XDR) Sprachdarstellung, die die Unterschiede zwischen Endian-Klassen und Datentypstrukturen abstrahiert. Es können nur von XDR definierte Datentypen übergeben werden. Man kann sagen, dass RMI ein objektorientierter Java-RPC ist.

3. Bei Methodenaufrufen in RMI ermöglicht die Remote-Schnittstelle, dass jede Remote-Methode eine Methodensignatur hat. Wenn eine Methode auf dem Server ausgeführt wird, aber keine passende Signatur zur Remote-Schnittstelle hinzugefügt wird, kann die neue Methode vom RMI-Client nicht aufgerufen werden. Wenn in RPC eine Anforderung beim RPC-Server eintrifft, enthält die Anforderung einen Parametersatz und einen Textwert, normalerweise in der Form „Klassenname.Methodenname“. Dies zeigt dem RPC-Server an, dass sich die angeforderte Methode in der Klasse mit dem Namen „Methodenname“ befindet. Der RPC-Server sucht dann nach einer passenden Klasse und Methode und verwendet sie als Eingabe für diesen Methodenparametertyp. Der Parametertyp entspricht hier dem Typ in der RPC-Anfrage. Sobald der Abgleich erfolgreich ist, wird diese Methode aufgerufen und das Ergebnis codiert und an den Client zurückgegeben.

4. RPC selbst hat keine Spezifikationen, aber der grundlegende Arbeitsmechanismus ist derselbe, nämlich: Serialisierung/Deserialisierung+Stub+Skelett ist RPC. Zum Beispiel: rmi .net-remoting ws/soap/rest hessian xmlrpc thrift potocolbuffer.

5. Java bietet eine vollständige Socket-Kommunikationsschnittstelle, aber Sockets erfordern, dass Client und Server Daten mithilfe von Protokollen auf Anwendungsebene codieren und austauschen. Ein Protokoll, das Sockets ersetzt, ist RPC (Remote Procedure Call), das die Kommunikationsschnittstelle für Prozeduraufrufe abstrahiert und es für Programmierer so bequem macht, eine Remote-Prozedur aufzurufen wie eine lokale Prozedur. Das RPC-System verwendet XDR, um die Parameter und Rückgabewerte von Remote-Aufrufen zu kodieren. Da RPC jedoch keine Objekte unterstützt, ist der objektorientierte Remote-Aufruf RMI (Remote Method Invocation) zu einer unvermeidlichen Wahl geworden. Mit RMI ist das Aufrufen entfernter Objekte genauso bequem wie das Aufrufen lokaler Objekte. RMI verwendet das Kommunikationsprotokoll JRMP (Java Remote Method Protocol), eine Remote-Aufrufmethode, die auf dem TCP/IP-Protokoll basiert.

4.2 JMS und RMI

1. Mithilfe des JMS-Dienstes werden Objekte physisch asynchron direkt von einer JVM im Netzwerk zu einer anderen verschoben. Auf einer JVM ( Es handelt sich um einen Nachrichtenbenachrichtigungsmechanismus, während das RMI-Objekt an die lokale JVM gebunden ist und nur die Funktionsparameter und Rückgabewerte über das Netzwerk übertragen werden (es handelt sich um einen Anforderungs-Antwort-Mechanismus).

2. RMI ist im Allgemeinen synchron, das heißt, wenn der Client eine Methode des Servers aufruft, muss er warten, bis die andere Partei zurückkehrt, bevor er diesen Prozess weiter ausführen kann Das Aufrufen einer lokalen Methode fühlt sich an. Ebenso ist dies auch eine Funktion von RMI. JMS sendet im Allgemeinen nur von einem Punkt aus eine Nachricht an den Nachrichtenserver. Nach dem Senden ist es im Allgemeinen egal, wer die Nachricht verwendet. Daher sind RMI-Anwendungen im Allgemeinen eng gekoppelt, während JMS-Anwendungen relativ locker gekoppelt sind.

4.3 Webservice und RMI

RMI überträgt serialisierbare Java-Objekte über das TCP-Protokoll und kann nur auf virtuellen Java-Maschinen, Bindungssprachen und Clients verwendet werden. Sowohl der Client als auch Der Server muss Java sein. Für Webservice gilt diese Einschränkung nicht. Webservice überträgt XML-Textdateien unabhängig von Sprache und Plattform über das HTTP-Protokoll.

4.4 Webservice und JMS

Webservice konzentriert sich auf den Remote-Service-Aufruf und JMS konzentriert sich auf den Informationsaustausch.

In den meisten Fällen handelt es sich bei Webservice um eine direkte Interaktion zwischen zwei Systemen (Consumer Producer), während es sich bei JMS in den meisten Fällen um eine Drei-Parteien-Systeminteraktion (Consumer Producer) handelt. Natürlich kann JMS auch die Kommunikation im Request-Response-Modus implementieren, sofern entweder der Consumer oder der Producer auch als Broker fungiert.

JMS kann asynchrone Aufrufe erreichen, die den Client und den Dienstanbieter vollständig isolieren und Verkehrsspitzen standhalten. WebService-Dienste werden normalerweise synchron aufgerufen und erfordern eine komplexe Objektkonvertierung. Im Vergleich zu SOAP sind dies jetzt der Fall eine gute http-Architekturlösung;

JMS ist eine Nachrichtenspezifikation auf der Java-Plattform. Im Allgemeinen ist eine JMS-Nachricht kein XML, sondern ein Java-Objekt. Offensichtlich berücksichtigt JMS keine heterogenen Systeme. Aber glücklicherweise haben die meisten JMS-Anbieter (also verschiedene Implementierungsprodukte von JMS) das heterogene Problem gelöst. Im Vergleich zur plattformübergreifenden WebService-Plattform hat jede ihre eigenen Vorzüge.

5 Optionale Implementierungstechnologien

Derzeit kann das Java-Feld zur Implementierung von Frameworks oder Bibliotheken für die Remote-Kommunikation verwendet werden. Zu den bekannten gehören: JBoss-Remoting, Spring-Remoting, Hessian, Burlap , XFire (Axis), ActiveMQ, Mina, Mule, EJB3 usw., lassen Sie uns eine kurze Einführung und Bewertung geben. Um ein verteiltes Service-Framework zu erstellen, müssen Sie ein sehr tiefes Verständnis für diese Dinge haben Das Framework für verteilte Dienste umfasst tatsächlich die Lösung von Problemen im verteilten Bereich und im Bereich der Anwendungsebene.

Natürlich können Sie auch Ihr eigenes Kommunikationsframework oder Ihre eigene Bibliothek implementieren, die auf dem Prinzip der Remote-Netzwerkkommunikation (Transportprotokoll + Net IO) basiert.

Welche Fragen werden Sie in die Studie einbringen, wenn Sie diese Fernkommunikations-Frameworks oder -Bibliotheken verstehen? Auf welchem ​​Protokoll basiert

1. ?

2. Wie initiiere ich eine Anfrage?

3. Wie konvertiere ich die Anfrage in ein Format, das dem Protokoll entspricht?

4. Welches Übertragungsprotokoll wird für die Übertragung verwendet?

5. Welchen Mechanismus verwendet der Antwortende, um Anfragen zu empfangen?

6. Wie kann ich den Stream im Transportformat wiederherstellen?

7. Wie soll nach der Bearbeitung reagiert werden?

5.1 Spring-Remoting

Spring-Remoting ist ein von Spring im Java-Bereich bereitgestelltes Remote-Kommunikationsframework, auf dem auch gewöhnliche Spring Beans problemlos basieren können Konvertiert in In einem bestimmten Remote-Protokoll veröffentlicht, können Sie die Spring Bean auch als remote aufgerufene Bean konfigurieren. Auf welchem ​​Protokoll basiert

1. ? Als Remote-Kommunikations-Framework integriert Spring mehrere Remote-Kommunikationsbibliotheken, um mehrere Protokolle wie RMI, http+io, XML-RPC, Binary-RPC usw. zu unterstützen.

2. Wie initiiere ich eine Anfrage? Da in Spring eine Proxy-Implementierung für Remote-Calling-Beans verwendet wird, wird die Anforderung vollständig über den Service-Interface-Aufruf initiiert.

3. Wie konvertiere ich die Anfrage in ein Format, das dem Protokoll entspricht? Spring konvertiert die angeforderten Objektinformationen gemäß dem Protokoll in einen Stream. Spring Http Invoker wird beispielsweise basierend auf einem von Spring selbst definierten Protokoll implementiert, und die Anforderungsinformationen werden basierend auf Java konvertiert Serialisierungsmechanismus. Transport für Streams.

4. Welches Transportprotokoll wird für die Übertragung verwendet? Unterstützt mehrere Übertragungsprotokolle wie RMI, http usw.

5. Welchen Mechanismus verwendet der Antwortende, um Anfragen zu empfangen? Der Responder folgt der Protokollmethode, um Anfragen zu empfangen. Für Benutzer müssen sie nur normale Spring Beans über die Spring-Konfiguration als Responder oder Server konfigurieren.

6. Wie kann ich den Stream im Transportformat wiederherstellen? Wiederherstellung gemäß dem Protokoll.

7. Wie soll nach der Bearbeitung reagiert werden? Kehren Sie einfach direkt nach der Verarbeitung zurück, und Spring-Remoting führt die entsprechende Serialisierung gemäß der Protokollmethode durch.

5.2 Hessian

Hessian ist eine Remote-Kommunikationsbibliothek, die auf Binär-RPC basiert und von Caucho bereitgestellt wird. Auf welchem ​​Protokoll basiert

1. ? Implementiert basierend auf dem Binary-RPC-Protokoll.

2. Wie initiiere ich eine Anfrage? Anfragen müssen über die von Hessian selbst bereitgestellte API initiiert werden.

3. Wie konvertiere ich die Anfrage in ein Format, das dem Protokoll entspricht? Hessian serialisiert die Anforderungsinformationen über seinen benutzerdefinierten Serialisierungsmechanismus, um einen Binärstream zu generieren.

4. Welches Transportprotokoll wird für die Übertragung verwendet? Hessische Übertragungen basieren auf dem HTTP-Protokoll.

5. Welchen Mechanismus verwendet der Antwortende, um Anfragen zu empfangen? Der Responder empfängt Anfragen basierend auf der von Hessian bereitgestellten API.

6. Wie kann ich den Stream im Transportformat wiederherstellen? Hessian deserialisiert die Anforderungsinformationen gemäß seinem privaten Serialisierungsmechanismus und ist bei der Übergabe an den Benutzer bereits das entsprechende Anforderungsinformationsobjekt.

7. Wie soll nach der Bearbeitung reagiert werden? Kehren Sie direkt nach der Verarbeitung zurück, und Hessian serialisiert das Ergebnisobjekt und überträgt es an das aufrufende Ende.

5.3 Burlap

Burlap wird auch von Caucho bereitgestellt. Der Unterschied zu Hessian besteht darin, dass es auf dem XML-RPC-Protokoll basiert. Auf welchem ​​Protokoll basiert

1. ? Implementiert basierend auf dem XML-RPC-Protokoll.

2. Wie initiiere ich eine Anfrage? Basierend auf der von Burlap bereitgestellten API.

3. Wie konvertiere ich die Anfrage in ein Format, das dem Protokoll entspricht? Konvertieren Sie die Anforderungsinformationen in ein XML-Format, das dem Protokoll entspricht, und wandeln Sie sie zur Übertragung in einen Stream um.

4. Welches Transportprotokoll wird für die Übertragung verwendet? HTTP-Protokoll.

5. Welchen Mechanismus verwendet der Antwortende, um Anfragen zu empfangen? HTTP-Anfragen abhören.

6. Wie kann ich den Stream im Transportformat wiederherstellen? Wiederherstellung gemäß XML-RPC-Protokoll.

7. Wie soll nach der Bearbeitung reagiert werden? Das Rückgabeergebnis wird in XML geschrieben und von Burlap an das aufrufende Ende zurückgegeben.

5,4 Es bedeutet auch, die Webservice-Methode zu verwenden. Auf welchem ​​Protokoll basiert

1. ?

   Basierend auf dem SOAP-Protokoll.

2. Wie initiiere ich eine Anfrage?

   Rufen Sie direkt an, nachdem Sie den Proxy des Remote-Dienstes erhalten haben.

3. Wie konvertiere ich die Anfrage in ein Format, das dem Protokoll entspricht?

   Konvertieren Sie die Anforderungsinformationen in ein XML-Format, das dem SOAP-Protokoll folgt, und konvertieren Sie sie dann in einen Stream zur Übertragung durch das Framework.

4. Welches Transportprotokoll wird für die Übertragung verwendet?

   HTTP-Protokoll.

5. Welchen Mechanismus verwendet der Antwortende, um Anfragen zu empfangen?

   HTTP-Anfragen abhören.

6. Wie kann ich den Stream im Transportformat wiederherstellen?

   Wiederherstellung gemäß SOAP-Protokoll.

7. Wie soll nach der Bearbeitung reagiert werden?

   Das Rückgabeergebnis wird in XML geschrieben und vom Framework an die aufrufende Seite zurückgegeben.

5.5 ActiveMQ

ActiveMQ ist eine gute Wahl, um eine Remote-Kommunikation basierend auf einem Nachrichtenmechanismus wie JMS zu implementieren Der Nachrichtenmechanismus selbst ermöglicht die einfache Implementierung von synchronen/asynchronen/unidirektionalen Anrufen usw., und der Nachrichtenmechanismus ist auch aus Sicht der Fehlertoleranz eine gute Wahl. Dies ist eine wichtige Grundlage für Erlang Fehlertoleranz erreichen können. Auf welchem ​​Protokoll basiert

1. ?

   Basierend auf dem JMS-Protokoll.

2. Wie initiiere ich eine Anfrage?

   Folgen Sie der JMS-API, um Anfragen zu stellen.

3. Wie konvertiere ich die Anfrage in ein Format, das dem Protokoll entspricht?

   Ich bin mir nicht sicher, ich vermute, dass es sich um einen binären Stream handelt.

4. Welches Transportprotokoll wird für die Übertragung verwendet?

   Unterstützt mehrere Übertragungsprotokolle wie Socket, http usw.

5. Welchen Mechanismus verwendet der Antwortende, um Anfragen zu empfangen?

   Hören Sie sich den Port an, der dem Protokoll entspricht.

6. Wie kann ich den Stream im Transportformat wiederherstellen?

   Das Gleiche wie bei Frage 3.

7. Wie soll nach der Bearbeitung reagiert werden?

   Folgen Sie der JMS-API, um Nachrichten zu generieren und sie in die JMS-Warteschlange zu schreiben.

5.6 Mina

Mina ist ein von Apache Network IO bereitgestelltes Framework oder Bibliothek, das im Wesentlichen auf BIO basiert Mina verwendet NIO, wenn die Parallelität zunimmt, wird NIO im Vergleich zu BIO eine deutliche Leistungsverbesserung aufweisen, und die Verbesserung der Java-Leistung hängt eng mit der engen Integration von NIO und dem Betriebssystem zusammen. Auf welchem ​​Protokoll basiert

1. ?

   Basierend auf reinem Socket+NIO.

2. Wie initiiere ich eine Anfrage?

   Über die von Mina bereitgestellte Client-API.

3. Wie konvertiere ich die Anfrage in ein Format, das dem Protokoll entspricht?

   Mina folgt dem Java-Serialisierungsmechanismus, um das Anforderungsobjekt zu serialisieren.

4. Welches Transportprotokoll wird für die Übertragung verwendet?

   Unterstützt mehrere Übertragungsprotokolle wie Socket, http usw.

5. Welchen Mechanismus verwendet der Antwortende, um Anfragen zu empfangen?

   Überwachen Sie den Protokollport im NIO-Modus.

6. Wie kann ich den Stream im Transportformat wiederherstellen?

   Deserialisieren Sie das Anforderungsobjekt gemäß dem Java-Serialisierungsmechanismus.

7. Wie soll nach der Bearbeitung reagiert werden?

   Folgen Sie der Mina-API für Rücksendungen.

MINA ist NIO, daher ist es keine Überraschung, dass es asynchrone Aufrufe unterstützt.

6 Entwicklung und aktuelle Situation des RPC-Frameworks

RPC (Remote Procedure Call) ist ein Remote-Aufrufprotokoll. Einfach ausgedrückt, ermöglicht es Anwendungen, Remote-Methoden genauso aufzurufen wie lokale Methoden . Der Prozess oder Dienst kann in vielen Szenarien angewendet werden, z. B. bei verteilten Diensten, verteiltem Rechnen, Remote-Dienstaufrufen usw. Apropos RPC: Jeder kennt es. In der Branche gibt es viele hervorragende Open-Source-RPC-Frameworks wie Dubbo, Thrift, gRPC, Hprose usw. Lassen Sie uns kurz die Eigenschaften von RPC und gängige Remote-Aufrufmethoden sowie einige hervorragende Open-Source-RPC-Frameworks vorstellen.

Im Vergleich zu anderen Remote-Aufrufmethoden können RPC, HTTP, RMI und Web Service alle Remote-Aufrufe abschließen, aber die Implementierungsmethoden und Schwerpunkte sind unterschiedlich.

6.1 RPC und HTTP

HTTP (HyperText Transfer Protocol) ist ein Kommunikationsprotokoll auf Anwendungsebene, das Standardsemantik verwendet, um auf bestimmte Ressourcen (Bilder, Schnittstellen usw.) zuzugreifen Server im Netzwerk können den Inhalt der Vereinbarung identifizieren. Das HTTP-Protokoll ist ein Ressourcenzugriffsprotokoll, über das Remote-Anfragen abgeschlossen und Anfrageergebnisse zurückgegeben werden können.

Die Vorteile von HTTP sind Einfachheit, Benutzerfreundlichkeit, gute Verständlichkeit und Sprachunabhängigkeit. Es wird häufig bei Remote-Serviceanrufen verwendet, einschließlich Weibo. Der Nachteil von HTTP besteht darin, dass der Protokollheader schwerer ist und die Verbindung zwischen der allgemeinen Anfrage und dem spezifischen Server lang ist, was DNS-Auflösung, Nginx-Proxy usw. umfassen kann.

RPC ist eine Protokollspezifikation. HTTP kann als Implementierung von RPC betrachtet werden, oder HTTP kann als Übertragungsprotokoll von RPC verwendet werden. Der RPC-Dienst weist einen relativ hohen Automatisierungsgrad auf, kann leistungsstarke Dienstverwaltungsfunktionen realisieren, ist in Kombination mit Sprache benutzerfreundlicher und weist eine hervorragende Leistung auf. Im Vergleich zu HTTP besteht der Nachteil von RPC darin, dass es relativ komplex ist und der Lernaufwand etwas höher ist.

6.2 RPC und RMI

RMI (Remote Method Invocation) bezieht sich auf den Remote-Methodenaufruf in der Java-Sprache. Jede Methode in RMI verfügt über eine Methodensignatur Remote-Methodenaufruf. RMI kann nur in der Java-Sprache verwendet werden. Sie können sich RMI als objektorientierten Java-RPC vorstellen.

6.3 RPC und Webdienst

Webdienst ist eine Architekturmethode zum Veröffentlichen, Abfragen und Aufrufen von Diensten basierend auf dem Web, wobei der Schwerpunkt auf der Verwaltung und Nutzung von Diensten liegt. Webdienste beschreiben Dienste im Allgemeinen über WSDL und verwenden SOAP, um Dienste über HTTP aufzurufen.

RPC ist ein Fernzugriffsprotokoll, während Web Service eine Architektur ist, die auch Serviceaufrufe über RPC durchführen kann, sodass Web Service besser für den Vergleich mit demselben RPC-Framework geeignet ist. Wenn das RPC-Framework die Diensterkennung und -verwaltung bereitstellt und HTTP als Transportprotokoll verwendet, handelt es sich tatsächlich um einen Webdienst.

Im Vergleich zum Webdienst kann das RPC-Framework eine detailliertere Verwaltung von Diensten durchführen, einschließlich Flusskontrolle, SLA-Verwaltung usw., und bietet größere Vorteile bei Mikrodiensten und verteiltem Computing.

RPC kann auf dem HTTP- oder TCP-Protokoll basieren. Es ist ein RPC, der auf dem HTTP-Protokoll basiert. Er bietet eine gute plattformübergreifende Leistung, ist jedoch nicht so gut wie RPC, der auf dem TCP-Protokoll basiert. Es gibt zwei Aspekte, die sich direkt auf die Leistung von RPC auswirken: der eine ist die Übertragungsmethode und der andere die Serialisierung.

Wie wir alle wissen, ist TCP ein Protokoll der Transportschicht, HTTP ist ein Protokoll der Anwendungsschicht und die Transportschicht ist niedriger als die Anwendungsschicht. In Bezug auf die Datenübertragung gilt: Je niedriger die Schicht, desto schneller. Daher muss TCP im Allgemeinen schneller sein als HTTP Quick.

7 Zusammenfassung

Im Bereich der Fernkommunikation gibt es noch viele Wissenspunkte, zum Beispiel: Kommunikationsprotokoll (Socket/tcp/http/udp/rmi /xml -rpc usw.), Nachrichtenmechanismus, Netzwerk-IO (BIO/NIO/AIO), MultiThread, transparente Lösung für lokale Anrufe und Remote-Anrufe (einschließlich Java-KlasseLoader, dynamischer Proxy, Unit-Test usw.) , asynchrone und synchrone Aufrufe, Verarbeitungsmechanismen der Netzwerkkommunikation (automatische Wiederverbindung, Broadcast, Ausnahmen, Poolverarbeitung usw.), Java-Serialisierung (private Serialisierungsmechanismen verschiedener Protokolle usw.), Implementierungsprinzipien verschiedener Frameworks (Übertragungsformate, Anleitungen). Konvertieren Sie das Transportformat in einen Stream, wie Sie die Anforderungsinformationen in ein Transportformat konvertieren, wie Sie den Stream empfangen, wie Sie den Stream im Transportformat wiederherstellen usw.) , welche davon Sie beherrschen müssen Es hängt von den tatsächlichen Anforderungen ab. Nur wenn Sie die Prinzipien verstehen, können Sie ein privates Remote-Kommunikationsprotokoll entsprechend Ihren Anforderungen erstellen Ich bin der Meinung, dass zumindest die oben genannten Wissenspunkte verstanden werden müssen.

Verwandte Artikel:

Java-Implementierung von Get-, PUT-, POST- und Löschanforderungen

Detaillierte Einführung in die Java-Programmierung – Zusammenfassung häufiger Probleme

Detaillierte Erläuterung der Java-Multithreading-Grundlagen

Das obige ist der detaillierte Inhalt vonGrafische Einführung in die Java-Fernkommunikationstechnologie und Prinzipanalyse. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!