externe Schnittstelle entwickeln

[george]

Hey,

ich soll eine Schnittstelle entwickeln, die das externe Steuern einer Hardwarekomponente ermöglichen soll.
Damit meine ich, ich stelle Funktionalität zur Verfügung, die der Anwender nutzen kann. Die Programmiersprache des Anwenders ist dabei egal(z.B. Visual Basic). Ich muss also eine Schnittstelle zur Verfügung stellen, die sprachunabhängig ist.
Wie würdet ihr dies realisieren? Eventuell als DLL?
Danke

greets george

[Leonidas]

Ich würde es als XML-RPC-Dienst zur Verfügung stellen: Viele Programmiersprachen unterstützen (d.h. haben Libs für) XML-RPC und für die meisten Zwecke reicht es glaube ich auch aus.
Hat auch den Vorteil, dass die Schnittstelle nicht auf dem gleichen Rechner sein muss, und auch nicht das gleiche OS oder gar den gleichen Compiler nutzen muss. Bei einer DLL hast du eben das Problem, dass du unter Linux sofort ausgeschlossen bist. Zusätzlich hast du das Problem, dass du die Schnittstelle erstmal kompilieren musst.

[gerold]

Ich würde es als XML-RPC-Dienst zur Verfügung stellen:

Hi!

Das kann ich nur unterstützen. Zusätzlich möchte ich aber auch noch ein einfaches Kommandozeileninterface vorschlagen. Allerdings nur, wenn die Kommunikation nur in eine Richtung geht. Also, wenn z.B. einfach nur ein paar Relais geschaltet werden sollen.

Code: Alles auswählen

schalte.py --switch1=on --switch2=off --switch3=on
schalte.py --switch1=off --switch2=on --switch3=off

Wenn es komplexer wird, dann ist ein Dienst (=Service, =Daemon), der per XML-RPC kommuniziert, eine wirklich gute Idee.
Wie ein HTTP-Server, ist so ein XML-RPC-Server komplett unabhängig von der Programmiersprache.

http://www.python-forum.de/topic-5478.html

mfg
Gerold


Edit: HTML-->HTTP

[Leonidas]

Wie ein HTML-Server, ist so ein XML-RPC-Server komplett unabhängig von der Programmiersprache.

Kleine Korrektur: HTTP-Server statt HTML-Server

Aber ansonsten hat gerold vollkommen recht, für ganz einfache Sachen eignet sich natürlich ein Kommandozeilenprogramm auch sehr gut.

[george]

Hey,

danke für eure Antworten.
Mit XMLRPC habe ich noch nicht gearbeitet. Werde es mir mal anschauen.
Mir ist an der Stelle noch nicht ganz klar, wie z.B. ein VisualBasic-Client zugreifen kann.

Zwei weitere Alternativen, über die ich nachdedacht habe, sind:

1.) Kleiner Netzwerk-Server mit twisted und TCP/IP
(ich denke, dass XMLRPC so ähnlich funktioniert, oder?)
2.) einen kleinen COM-Server bauen. Habe das folgende Beispiel gefunden
Beispiel

Ich denke aber, dass diese Idee verschiedene Nachteile bietet.
Wie sind eure Erfahrungen hierzu?


greets george

Edit by gerold: URL gekürzt

[gerold]

Mir ist an der Stelle noch nicht ganz klar, wie z.B. ein VisualBasic-Client zugreifen kann.

Hi george!

1.) Wenn du eine Lösung suchst, die nur unter Windows laufen soll, dann solltest du das auch schon bei der Frage dazuschreiben.

2.) "Visual Basic 6" und "Visual Basic.NET" sind zwei paar Schuhe. Welches davon meinst du?

mfg
Gerold

[gerold]

http://forums.microsoft.com/MSDN/ShowPo ... 9&SiteID=1

http://comxmlrpc.sourceforge.net/

[george]

Hey gerold,

1.) Wenn du eine Lösung suchst, die nur unter Windows laufen soll, dann solltest du das auch schon bei der Frage dazuschreiben.

Sorry. Das Client-OS ist ein Windowssystem.

2.) "Visual Basic 6" und "Visual Basic.NET" sind zwei paar Schuhe. Welches davon meinst du?

Das ist vom Kunden noch nicht eindeutig spezifiziert worden.
Ich muss also so designen, dass die Programmiersprache des Clients eher sekundär ist.

Danke
greets george

[Leonidas]

Mit XMLRPC habe ich noch nicht gearbeitet. Werde es mir mal anschauen.
Mir ist an der Stelle noch nicht ganz klar, wie z.B. ein VisualBasic-Client zugreifen kann.

Über eine Library.

1.) Kleiner Netzwerk-Server mit twisted und TCP/IP
(ich denke, dass XMLRPC so ähnlich funktioniert, oder?)

Ähnlich, aber wesentlich einfacher.

2.) einen kleinen COM-Server bauen. Habe das folgende Beispiel gefunden
Beispiel

Also COM finde ich persönlich nicht so toll - die COM-Unterstützung ist zwar gegeben, aber die Unterstützung für XML-RPC ist Python-Seitens wesentlich besser, sie ist sogar in der stdlib.

2.) "Visual Basic 6" und "Visual Basic.NET" sind zwei paar Schuhe. Welches davon meinst du?

Das ist vom Kunden noch nicht eindeutig spezifiziert worden.
Ich muss also so designen, dass die Programmiersprache des Clients eher sekundär ist.

COM und XML-RPC erfüllen beide dieses Kriterium. XML-RPC sogar noch mehr, da es mehr XML-RPC Libraties für verschiedene Programmiersprachen gibt, als COM-Libraries.

Wenn du in die Implementations-Liste auf xmlrpc.com guckst, dann siehst du dort 5 Client und eine Server-Implementation für VB (du brauchst aber sowieso nur Client). Ich muss zugeben, dass ich irgendwann mal aus Spass eine dieser Libraries (comxmlrpc oder vbXMLRPC, das weiß ich nicht mehr genau) aus Python heraus über COM benutzt habe. Und für .NET gibt es auch zwei Libraries (wovon eine allerdings einen toten Link hat).

[george]

Hey Leonidas,

danke noch einmal für deine ausführliche Antwort und den Hinweis zu den Beispielen.
Ich denke, dass ich es als XMLRPC entwickeln werde(wie auch von gerold geraten).
Danke

greets george

[dev]

1.) Kleiner Netzwerk-Server mit twisted und TCP/IP
(ich denke, dass XMLRPC so ähnlich funktioniert, oder?)

Ähnlich, aber wesentlich einfacher.

Wieso eigentlich wesentlich einfacher? (Mal abgesehen davon, daß wir hier gerade quer durch die Schichten vergleichen.)

http://www.python-forum.de/post-46983.html#46983

Mir liegt fern hier einen Glaubenskrieg vom Zaun zu brechen, mich würde nur interessieren, wieso nahezu immer, wenn der Begriff Twisted fällt, sofort Kreuze, Weihwasser und Knoblauch gezückt werden.

Ich beobachte Twisted seit mehreren Jahren und nutze es seit nunmehr zwei Jahren exzessiv für meine Projekte.
Wobei ich zugegebenerweise viele Bereiche des Frameworks auf Grund dessen schieren Umfangs noch nicht genutzt habe.

Ich würde es aber auf jeden Fall nicht mehr missen wollen.

Liegt es vielleicht an den Deferreds?
An der Idee threads zu vermeiden?
An der Dokumentationssituation?

Ciao,
dev

[Leonidas]

Wieso eigentlich wesentlich einfacher? (Mal abgesehen davon, daß wir hier gerade quer durch die Schichten vergleichen.)

Aus mehreren Gründen: es ist mitgeliefert (man muss also nicht Twisted rauspacken, weil es schon seit langem in der stdlib ist), es ist gut dokumentiert. Verlutlich ist auch der Quelltext einfacher verständlich, weil es einfacher gestrickt ist als das Framework Twisted.

http://www.python-forum.de/post-46983.html#46983

Zugegeben, simpel. Das ist SimpleXMLRPCServer aber auch.

Mir liegt fern hier einen Glaubenskrieg vom Zaun zu brechen, mich würde nur interessieren, wieso nahezu immer, wenn der Begriff Twisted fällt, sofort Kreuze, Weihwasser und Knoblauch gezückt werden.

Hehe Twisted hat halt so den Ruf die Kanone für Spatzen zu sein.

Ich beobachte Twisted seit mehreren Jahren und nutze es seit nunmehr zwei Jahren exzessiv für meine Projekte.
Wobei ich zugegebenerweise viele Bereiche des Frameworks auf Grund dessen schieren Umfangs noch nicht genutzt habe.

Ich würde es aber auf jeden Fall nicht mehr missen wollen.

Das ist doch wunderbar - ich habe nicht behauptet, das Twisted schlecht sei. Nur fand ich die Arbeit mit Twisted Words eher unangenehm, da sich die Twisted IRClib komplett anders verhalten hat als die Twisted Jabber-Lib und diese wieder komplett anders als xmpppy.

Nun, dev, sag selbst: würdest du, um mal schnell eine Schnittstelle herzustellen, Twisted verwenden, mit dem Wissen, dass man dann Twisted extra installieren muss, obwohl die stdlib das gleiche bietet? Nein, es geht um eine einfache Schnittstelle, nicht um einen Server mit tausenden Requests pro Minute.

[george]

Hey,

würdest du, um mal schnell eine Schnittstelle herzustellen, Twisted verwenden, mit dem Wissen, dass man dann Twisted extra installieren muss, obwohl die stdlib das gleiche bietet? Nein, es geht um eine einfache Schnittstelle, nicht um einen Server mit tausenden Requests pro Minute.

Da muss ich Leonidas recht geben. Bedingt durch die Einfachheit, werde ich es, wie bereits erwähnt, als xmlrpc implementieren.

Ich beobachte Twisted seit mehreren Jahren und nutze es seit nunmehr zwei Jahren exzessiv für meine Projekte.
Wobei ich zugegebenerweise viele Bereiche des Frameworks auf Grund dessen schieren Umfangs noch nicht genutzt habe.

Ich würde es aber auf jeden Fall nicht mehr missen wollen.

Da kann ich dev nur zustimmen. Ich habe, basierend auf twisted, einen Datenserver zum Pollen von elektronischen Geräten entwickelt und war begeistert über dieses Framework.
Ich muss aber auch gestehen, dass das Framework recht komplex ist und es sicherlich einen gewissen Zeitrahmen in Anspruch nimmt, um es einigermaßen zu verstehen.

greets george