Interface Definition Language - was benutzen?

Shade Of Mine

Hallo Leute.

Ich habe ein System für das ich RPCs implementieren muss. Das technische ansich ist kein Problem, nur wenn ich jetzt eine Definition einer Klasse auf dem Server habe - was verwendet man da am besten als Interface Definition Language über die ich dann die Stubs generieren lasse?

Ich war bisher nur immer dummer User und bei Java & Co wird einem da ja die ganze Arbeit abgenommen. Ich kenne im Prinzip nur die Microsoft Interface Definition Language aber ich nehme mal an dass es mittlerweile modernere Sachen gibt

Gibt es offene Standards?

Am liebsten etwas was nicht unnötig kompliziert ist (schliesslich muss ich es ja implementieren) :p

danke schonmal

Prof84

Morgen Shade,

IDL ist keine Erfindung von MS, sondern der OSF. Diese fand in der ersten Version von CORBA der OMG seinen großen Einzug:
http://www.omg.org/docs/formal/02-06-07.pdf
MS hat dieses Konzept bei der Entwicklung von COM bzw. OLE übernommen.
Den State-of-Art würde ich in SOA sehen, wie es auch bei den COM+-Server mit SOAP, WSDL, UDDI und Co von MS übernommen wurde. Mit Einzug des .NET Standards ist SOA Basis außerhalb der .NET Platform für den Remoteprocess.

Ich würde nicht sagen, dass die harte Koppelung von Komponenten ((D)COM(+), CORBA, DCE etc) über IDL out wären. Aber sie haben doch stark abgenommen.

Mit moderner Toolunterstützung ist die Entwicklung des WS selbst schnell gemacht, die Verwaltung solcher System wird allerdings schnell kompliziert.
Ein Nachteil des ESB ist, dass es nicht möglich ist Komponenten im Remoteprozess zu teilen wie bei z.B. COM+ oder CORBA.

Bei Einzelrechnersysteme empfehle ich aber die .NET Platform zu nutzen und die COM+-Schnittstelle oder Win32-API zu nutzen. Diese ist sozusagen in der Platformn integriert (Assemblies).

Welcher Anwendungszweck für Dich das Beste ist, hängt von Deinen Anwendungsrahmen ab.

cu
:xmas1: P84

Shade Of Mine

Prof84 schrieb:

IDL ist keine Erfindung von MS, sondern der OSF. Diese fand in der ersten Version von CORBA der OMG seinen großen Einzug:
http://www.omg.org/docs/formal/02-06-07.pdf
MS hat dieses Konzept bei der Entwicklung von COM bzw. OLE übernommen.

Ah, ok. ich kenne das eben nur von DLLs und dazu gibts in der MSDN eben den abschnitt "Microsoft Interface Definition Language" - deshalb dachte ich es sei was Microsoft spezifisches. Naja, egal. Danke fuer die Aufklaerung.

Ich würde nicht sagen, dass die harte Koppelung von Komponenten ((D)COM(+), CORBA, DCE etc) über IDL out wären. Aber sie haben doch stark abgenommen.

mhm...
ich brauche jedenfalls eine art interface aus dem ich die stubs generiere...

Mit moderner Toolunterstützung ist die Entwicklung des WS selbst schnell gemacht, die Verwaltung solcher System wird allerdings schnell kompliziert.
Ein Nachteil des ESB ist, dass es nicht möglich ist Komponenten im Remoteprozess zu teilen wie bei z.B. COM+ oder CORBA.

Bei Einzelrechnersysteme empfehle ich aber die .NET Platform zu nutzen und die COM+-Schnittstelle oder Win32-API zu nutzen. Diese ist sozusagen in der Platformn integriert (Assemblies).

Das ganze laeuft in PHP und JavaScript - lames webzeugs halt :p

dh ich habe leider kein unterliegendes Framework dass ich verwenden kann

Die low level Konzepte sind bereits implementiert - sprich ich kann problemlos einen remote procedure call machen (serialisieren, transferieren der daten, etwaige exception die am anderen ende geworfen werden,... das alles laeuft schon). Das ganze soll nun aber etwas leichter zu handhaben sein, indem man eben ueber stubs geht, die die ganze client/server kommunikation vor dem user verstecken.

aber danke. du hast mir jedenfalls mal genug lesestoff gegeben

Von wo nach wo gehts jetzt? Wenn Javascript das Ziel ist, dann kannst du auch gleich JSON verschicken, ganz ohne Stubkram.

Prof84

Shade Of Mine schrieb:

...ich brauche jedenfalls eine art interface aus dem ich die stubs generiere...

Das ganze laeuft in PHP und JavaScript - lames webzeugs halt :p

dh ich habe leider kein unterliegendes Framework dass ich verwenden kann

Die low level Konzepte sind bereits implementiert - sprich ich kann problemlos einen remote procedure call machen (serialisieren, transferieren der daten, etwaige exception die am anderen ende geworfen werden,... das alles laeuft schon). Das ganze soll nun aber etwas leichter zu handhaben sein, indem man eben ueber stubs geht, die die ganze client/server kommunikation vor dem user verstecken.

PHP und JS mit IDL??? ... das war wohl nix ... :xmas2:

Nee, nee! Das macht man heute alles mit WS:
http://de.wikipedia.org/wiki/SOAP
http://de.wikipedia.org/wiki/Webservice

Da gibt es mit Sicherheit heutzutage genug PEAR Pakete oder PHP-Module zu.
Ahja, gefunden:
http://www.pear.php.net/package/SOAP
http://www.evolt.org/article/The_PEAR_SOAP_Implementation/21/49993/
http://de3.php.net/manual/de/ref.soap.php

Zur Einleitung lies hier:
http://www.aifb.uni-karlsruhe.de/Lehre/Winter2002-03/webservice/unterlagen/folien/V4_SOAP.pdf

Weiterhin solltest Du eine Technik im Auge behalten, die zwar nicht neu ist,
aber unter dem Buzzword AJAX gerade recht 'hipp'. Das ist diesmal wirklich ein Buzzword, weil wir diese Techniken schon jahrelang eingesetzt haben.

http://de.wikipedia.org/wiki/Ajax_(Programmierung)
http://www.phpcenter.de/beitraege/detail.php?a_id=734
http://pear.php.net/package/HTML_AJAX

So! Jetzt hast Du was zu lesen!

cu
:xmas1: P84

Shade Of Mine

Es sind keine Webservices. Zumindest nicht im herkömmlichen Sinn.

Es ist keine Webseite die einen Service zur Verfügung stellt, sondern ein Netz aus Servern die untereinander kommunizieren. Ich denke nicht dass SOAP da der richtige Ansatz wäre (zuviel Overhead).

Ich hätte PHP vielleicht nicht erwähnen sollen

Das low Level System steht auch schon - ich soll es jetzt lediglich einfacher Nutzbar machen.

Prof84

Shade Of Mine schrieb:

Es sind keine Webservices. Zumindest nicht im herkömmlichen Sinn.

Es ist keine Webseite die einen Service zur Verfügung stellt, sondern ein Netz aus Servern die untereinander kommunizieren. Ich denke nicht dass SOAP da der richtige Ansatz wäre (zuviel Overhead).

Hast wohl kein Bock gehabt die Sachen durchzulesen :xmas2: :

SOAP dient einer Server-2-Server Kommunikation. Da ist eigentlich grundsätzlich keine Webseite zwischen geschaltet.
WS und AJAX ist wahrscheinlich die erste und einzige Wahl. Weil ein Cluster mit statische P2P-Verbindung für RPC das System gnadenlos ausbremst.
Einfach eine SOAP Message als Broadcasting Signal an die Server senden, eine Session für die Response anlegen und dann noch beim angepingten Server eine IoC einziehen.
http://de.wikipedia.org/wiki/Inversion_of_Control
Der Request-Server derminiert den Thread einstweilen und wird erst wieder akiv, wenn eine neue SOAP gesendet werden soll oder die Response eintrifft; von welchem Server auch immer.
Und Overhead ist da gar keiner. Das macht man heute alles über Tools z.B.:
http://www.altova.com/videos.asp?type=0&video=xmlspy
http://www.sparxsystems.com/products/ea.html

Verstehst Du was von EAI? Weil gerade Weihnachten ist ...

Enterprise Integration Patterns | ISBN: 0321200683 Patterns of Enterprise Application Architecture | ISBN: 0321127420

Shade Of Mine schrieb:

Das low Level System steht auch schon - ich soll es jetzt lediglich einfacher Nutzbar machen.

Was soll das jetzt bedeuten ? Was ist bei euch ein Low Level System?

@Shade Of Mine: darfst du das Problem nicht genauer beschreiben? Sag doch mal genau von wo nach wo?

SOAP ist arschlahm, aufjdenfall die Java Variante (Java kann schneller mit Servern kommunizieren).