Wir befinden uns derzeit in einem Stadium unseres Produktlebenszyklus, in dem wir über den Wechsel zu Web Services nachdenken. Unser System ist in Java geschrieben, das aus einer Reihe von Client- und Server-Anwendungen besteht, die über TCP-Sockets miteinander kommunizieren und auch Inline-SQL zum Abrufen und Aktualisieren von Daten (yuk! I know) mit unserer eigenen SQL Connection-Klasse verwenden Das verwendet dann die java.sql.Connection, um eine Verbindung mit einer SQL Server-Datenbank herzustellen, die den Microsoft JDBC-Treiber verwendet.
Die Anwendungen sind über TCP-Sockets miteinander verbunden. Sie fordern Daten von einander an und schieben Daten aneinander. Was ganz gut funktioniert.
Gedanke
Wir versuchen also, den gesamten Datenzugriff und die TCP-Kommunikation in einen Webservice zu konvertieren.
Der Web-Service wäre so konzipiert, dass er auf einer unternehmenssicheren Internetseite läuft. Die Idee wäre, dass Benutzer ihre Clients von zu Hause aus mit dem Webdienst verbinden könnten, wenn sie nicht im Firmennetzwerk sind, oder bei der Arbeit, wenn sie es sind.
Die Clientanwendungen senden / empfangen die Nachrichten an / von den serverseitigen Anwendungen unter Verwendung des Webdienstes. Die Client-Anwendungen würden Daten in der Datenbank über den Web-Service abrufen und aktualisieren.
Frage
Ich möchte nur wissen, was die Leute erleben, wenn sie etwas mit der 2-Wege-Kommunikation (Anfrage und Push) über einen Web-Service tun (wenn möglich) und was die Gedanken darüber sind, dies zu tun.
Die Konvertierung des Datenzugriffs in einen Web-Service scheint einfach genug zu sein - ich kann einige Probleme mit der Leistung vorhersehen, bei denen große Datenmengen in einigen Teilen des Systems abgerufen werden.
Ich schaue mir verschiedene Lesestoffe an, da es schon eine Weile her ist, seit ich Webservices angefasst habe (mit C # und ASP.NET). Derzeit lesen Sie "Erstellen von Webdiensten mit Java ™: Sinn für XML, SOAP, WSDL und UDDI". Ich muss zugeben, ich dachte, Web-Services wären immer staatenlos, aber ich habe gerade gelesen, dass sie es nicht sind!
Danke,
Andez
Es hilft, WebServices als die gleiche wie jede andere Webanwendung auf der Transportschicht zu betrachten. Es verwendet HTTP / HTTPS-Protokolle in der gleichen Weise, es ist nur, dass anstelle des Sendens von HTML XML in einem vordefinierten Format (SOAP) sendet. Als solche:
Halten Sie diese Einschränkungen und Funktionen im Hinterkopf, denken Sie über Ihre Anforderungen nach und wie sie sich gegenseitig zuordnen. Wenn Sie echte Zwei-Wege-Kommunikation (Push) benötigen, sind Web-Services nicht ideal. Sie sind Client / Server, Anfrage / Antwort orientiert. Um den Push zu erreichen, müssten Sie vom Kunden abfragen. Eine mögliche Alternative könnte sein, dass sowohl der "Server" als auch der "Client" als Web-Service- "Server" fungieren. Das würde bedeuten, einige leichte Servlet-Engines mit dem Client zu bündeln (wie Jetty), damit der "Server" Web-Service-Aufrufe an den "Client" machen kann. Eine andere Möglichkeit ist die Betrachtung von Zweiwege-RMI / IOOP.
Ein weiterer Weg wäre, die Kommunikationsschicht so zu halten, wie Sie sie heute haben. Es gibt keinen inhärenten Vorteil beim Refactoring für Web Services, nur um Web Services zu verwenden. Wenn sie keinen Nutzen hinzufügen, ist es nur Verschwendung. Wie Sie bereits erwähnt haben, kommt Web Service mit einer Menge zusätzlichen Aufwands (ausführliches Protokoll, Servlet-Engine usw.), so dass die zusätzlichen Kosten und die Entwicklungszeit wirklich mit einem klaren Nutzen ausgeglichen werden müssen. Wie das Sprichwort sagt "wenn es nicht kaputt ist, repariere es nicht". Wie Sie sagen, die aktuelle Lösung "funktioniert einwandfrei", würde ich wahrscheinlich nicht ändern. Das bin nur ich.
Tags und Links java sockets web-services tcp