Datenaustausch zwischen App und Desktop

[hhcm]

Hallo zusammen,

ich suche gerade nach einer Möglichkeit einen Datenaustausch zwischen einer Android App und einer Windowsanwendung zu bewerkstelligen.
Es geht sich hauptsächlich um Textdaten.

In der App wird auf einen Button gedrückt. Dort wird ein Befehl an die Windowsanwendung geschickt.
Die Windowsanwendung baut eine Verbindung zu einer Datenbank auf, die abgefragten Daten sollen dann im XML oder Json Format der App bereitgestellt werden.

Das ganze muss über das Internet funktionieren (Portfreigabe), sollte also auch eine gewisse Sicherheit mitbringen.

Ich fand die Tethering Komponenten recht interessant, kann aber keine Informationen finden ob das ganze auch über das Internet funktioniert.
Wie z.B würde das Pairing oder die Portfreigabe laufen.

Gibts es hier jemanden der so etwas schon gemacht hat?

[mkinzler]

Beim Tethering wird eine lokale Bluetooth-Verbindung bestehen bzw. müssen sich die Geräte im selben (WLAN)-Netz befinden.

In Deinem Fall würde sich ein (Rest-)Service anbieten, auf den beide zugreifen.

[Mavarik]

Zitat:

Zitat von mkinzler (Beitrag 1350463)

In Deinem Fall würde sich ein (Rest-)Service anbieten, auf den beide zugreifen.

Dem ist nix mehr hinzuzufügen! :stupid:

[hhcm]

Schade, ich dachte ich könnte das ganze mit den Boardmitteln von Delphi Professional erledigen.

[mkinzler]

Wenn sich Dein Handy per VPN in das Firmennetz einwählt könnte es funktionieren.
Einen REST(ful)-Service ist auch mit Pro möglich.

[hhcm]

Das ganze mit VPN zu verbinden wird nachher zu kompliziert für den Endanwender.

Rest-Server mit Pro? Wahrscheinlich selbst implementieren über einen IdHttpServer richtig?

[mkinzler]

http://www.delphipraxis.net/184570-e...erstellen.html
https://github.com/danieleteti/delphimvcframework
http://synopse.info/fossil/wiki?name=SQLite3+Framework
https://secure.habariwebcomponents.de/demo/index.html

[Mavarik]

Zitat:

Zitat von hhcm (Beitrag 1350613)

Das ganze mit VPN zu verbinden wird nachher zu kompliziert für den Endanwender.

Rest-Server mit Pro? Wahrscheinlich selbst implementieren über einen IdHttpServer richtig?

Zum Beispiel oder eine ISAPI.DLL (oder Standalone) für den Webserver...

Ich eigentlich mit wenigen Zeilen aufgesetzt...

[Bambini]

Zitat:

Zitat von hhcm (Beitrag 1350613)

Das ganze mit VPN zu verbinden wird nachher zu kompliziert für den Endanwender.

Rest-Server mit Pro? Wahrscheinlich selbst implementieren über einen IdHttpServer richtig?

Das IP Tethering ist ein wenig hakelig mit den Firewalls. Wenn die Handy App sich mit dem PC per IP unterhalten soll, muss es an dessen Firewall vorbei.
Das Bluetooth Tethering habe ich noch nicht funktionierend hinbekommen.

Wie wäre der Austausch der Daten per File Up- und Download, via Google Drive oder Dropbox o.a..
TMS bietet hier ein paar Controls an, die das Handling abnehmen:
https://www.tmssoftware.com/site/cloudpack.asp
Soweit ich gesehen habe, gibt es das auch für FMX.

[mkinzler]

Fände ich etwas umständlich.

[mjustin]

Zitat:

Zitat von mkinzler (Beitrag 1350617)

https://secure.habariwebcomponents.de/demo/index.html

Die "Habari Web Components" sind unter neuem Namen und open source nun hier zu finden:
https://github.com/michaelJustin/daraja-framework
https://www.habarisoft.com/daraja_framework.html

Und die REST Erweiterung hier:
https://github.com/michaelJustin/daraja-restful

[Bambini]

Zitat:

Zitat von mkinzler (Beitrag 1350647)

Fände ich etwas umständlich.

Zugegeben. Ich nutze zur Zeit auch nur die Lösung per UDP Broadcast und TCP/IP.
Da es aber leider nicht auf jedem Kunden Rechner funktioniert und man nicht immer die Hand auf die Firewall bekommt,
hat die Methode über die Files auch seinen Charme.

[Bambini]

Zitat:

Zitat von mjustin (Beitrag 1350648)

Zitat:

Zitat von mkinzler (Beitrag 1350617)

https://secure.habariwebcomponents.de/demo/index.html

Die "Habari Web Components" sind unter neuem Namen und open source nun hier zu finden:
https://github.com/michaelJustin/daraja-framework
https://www.habarisoft.com/daraja_framework.html

Und die REST Erweiterung hier:
https://github.com/michaelJustin/daraja-restful

Wollt ihr einen ganzen Webserver in die PC Anwendung bauen?

[mjustin]

Zitat:

Zitat von Bambini (Beitrag 1350652)

Wollt ihr einen ganzen Webserver in die PC Anwendung bauen?

Huh?

Zitat:

Zitat:

Das ganze muss über das Internet funktionieren (Portfreigabe)

Wenn die App mit dem Windows Netzwerk über Internet kommunizieren soll, dann wird sich ein Server wohl kaum vermeiden lassen.

Den würde ich natürlich nicht in die PC Anwendung einbauen.

Umgekehrt wird ein Schuh draus: der Server ist auch von der Windows Anwendung erreichbar, mehr oder weniger direkt via Intranet.

Durch geschicktes Abfragen des Servers erfährt die Windows Anwendung dann, was die App gesendet hat.

[hhcm]

Also für eine TCP/IP Client/Server Umgebung über die Cloud zu gehen scheidet echt aus. Auch wenn ich so ziemlich alle TMS Komponenten registriert habe.

Ziel ist eine App (Client) und eine Windows Middleware (Server)

Also kein Iss,Apache o.ä. Einfach ein Standalone Service oder VCL Anwendung mit Oberfläche.

Habari Components und das Delphi MVC Framework werden ich mir mal ansehen.
mORMot hört sich schwer interessant an, aber die Doku erschlägt mich ein wenig.

[mjustin]

Zitat:

Zitat von hhcm (Beitrag 1350655)

Also für eine TCP/IP Client/Server Umgebung über die Cloud zu gehen scheidet echt aus. Auch wenn ich so ziemlich alle TMS Komponenten registriert habe.

Ziel ist eine App (Client) und eine Windows Middleware (Server)

Also kein Iss,Apache o.ä. Einfach ein Standalone Service oder VCL Anwendung mit Oberfläche.

Halbe Zustimmung von mir:

ein IIS oder Apache-Modul ist nicht nötig, aber es hat enorme Vorteile wenn man einen Apache HTTP Server als Reverse Proxy vorschaltet:

App -> Internet -> Apache HTTP Server auf Port 80 oder 443 -> Delphi HTTP Server auf Port 8080 (auf gleichem System)

Der Apache übernimmt dann alle fortgeschrittenen Aufgaben wie HTTPS, Kontext-Mapping etc. und entlastet dadurch die Delphi Entwicklung um einiges.

[Mavarik]

Zitat:

Zitat von hhcm (Beitrag 1350456)

Das ganze muss über das Internet funktionieren (Portfreigabe), sollte also auch eine gewisse Sicherheit mitbringen.

Also Internetkommunikation mit einem Server...

Zitat:

Zitat von hhcm (Beitrag 1350655)

Also kein Iss,Apache o.ä. Einfach ein Standalone Service oder VCL Anwendung mit Oberfläche.

Das was den nun?

Über das Internet bedeutet doch ein Server also genau IIS oder was auch immer...
Es sei den Du meinst VPN, aber das hast Du ja schon ausgeschlossen:

Zitat:

Zitat von hhcm (Beitrag 1350613)

Das ganze mit VPN zu verbinden wird nachher zu kompliziert für den Endanwender.

Oder willst Du einfach mit einer App über das LOKALE WLAN zu einer Desktop App verbinden...

Also doch App-Teathering oder per hand mit UDP & TCP/IP.

Mavarik :shock:

PS.:

Zitat:

Zitat von hhcm (Beitrag 1350456)

Gibts es hier jemanden der so etwas schon gemacht hat?

Ja! Alle Varianten...

[hhcm]

Das ganze soll als Mobile Client für eine Datenbank Anwendung dienen.

Da ich über die App nicht direkt auf die Datenbank zugreifen möchte, sollte es eine Middleware geben.

Einem Endkunden kann ich keinen Reverseproxy zumuten.

App Installieren. Windows Middleware Konfigurieren und loslegen.
Natürlich vorausgesetzt das eine Statische IP oder ein dyndns Dienst zur Verfügung steht. Das ist aber nebensächlich.

[mjustin]

Zitat:

Zitat von hhcm (Beitrag 1350665)

Das ganze soll als Mobile Client für eine Datenbank Anwendung dienen.

Da ich über die App nicht direkt auf die Datenbank zugreifen möchte, sollte es eine Middleware geben.

Einem Endkunden kann ich keinen Reverseproxy zumuten.

App Installieren. Windows Middleware Konfigurieren und loslegen.

Was aber klar sein sollte: der Endkunde muss dazu die Firewall für eingehende (!) Verbindungen von beliebigen Client-IP Adressen (!) öffnen. Obskure Delphi-Anwendungen, die Server-Ports öffnen, könnten die eine oder andere hochgezogene Augenbraue auslösen. Aber "no risk, no fun" :)

[hhcm]

Und ein Webserver ist da anders ?

[mjustin]

Zitat:

Zitat von hhcm (Beitrag 1350671)

Und ein Webserver ist da anders ?

Im Unterschied zu einer Middleware, die direkt auf dem Rechner installiert sein muss auf dem die Delphi Anwendung läuft, ist ein dedizierter Webserver (in der DMZ) etwas anderes, ja.

[Bambini]

Zitat:

Zitat von hhcm (Beitrag 1350671)

Und ein Webserver ist da anders ?

War die Ursprungsfrage nicht, Daten zwischen Desktop <-> App auszutauschen oder doch direkt zur DB via Web/AppServer?

[mjustin]

Zitat:

Zitat von Bambini (Beitrag 1350675)

Zitat:

Zitat von hhcm (Beitrag 1350671)

Und ein Webserver ist da anders ?

War die Ursprungsfrage nicht, Daten zwischen Desktop <-> App auszutauschen oder doch direkt zur DB via Web/AppServer?

So hatte ich es verstanden:

App -> Internet -> Windowsanwendung -> Intranet -> Datenbankserver (und zurück).

Zitat:

In der App wird auf einen Button gedrückt. Dort wird ein Befehl an die Windowsanwendung geschickt.
Die Windowsanwendung baut eine Verbindung zu einer Datenbank auf, die abgefragten Daten sollen dann im XML oder Json Format der App bereitgestellt werden.

Dann ist die Windowsanwendung einerseits ein aus dem Intranet erreichbarer Server (für die App) und andererseits ein Client (für die Datenbank), also eine Art Applikationsserver.

[Mavarik]

[QUOTE=hhcm;1350665]Das ganze soll als Mobile Client für eine Datenbank Anwendung dienen.

Da ich über die App nicht direkt auf die Datenbank zugreifen möchte, sollte es eine Middleware geben.
QUOTE]

Also einen REST-Server!

Zitat:

Zitat von hhcm (Beitrag 1350665)

App Installieren. Windows Middleware Konfigurieren und loslegen.
Natürlich vorausgesetzt das eine Statische IP oder ein dyndns Dienst zur Verfügung steht. Das ist aber nebensächlich.

Würde ich zwar nicht machen, aber geht...

Einfach einen REST-Server im Internet aufsetzen und einen Tunnel vom Datenbankserver zum Restserver aufbauen!

[hhcm]

Zitat:

Zitat von mjustin (Beitrag 1350678)

Dann ist die Windowsanwendung einerseits ein aus dem Intranet erreichbarer Server (für die App) und andererseits ein Client (für die Datenbank), also eine Art Applikationsserver.

Genau. Daher bleibt wohl nichts anderes als auf dem Applikationsserver einem REST Service zu implementieren.

Es geht sich nicht um einen besonderen Dienst bei dem ich den Service stelle.
Sondern bei jedem Anwender muss ein eigener her. DA muss die Installation allein zu bewältigen sein.

[Jumpy]

Vielleicht solltest du als Entwickler/Vertreiber der Software zusätzlich einen "Vermittlungs-Server" (zentral für alle Kunden) zur Verfügung stellen, der hilft, die Verbindung zw. App und PC herzustellen, so dass eine dynamische IP beim PC kein Problem mehr ist. Wie z.B. bei TeamViewer registriert sich der PC bei deinem Server bekommt dann so eine Nummer. Die App registriert sich beim Server, man gibt diese Nummer ein und die App bekommt die Infos/IP für den PC, so dass sie sich verbinden kann.

[hhcm]

Zitat:

Zitat von Jumpy (Beitrag 1350697)

Vielleicht solltest du als Entwickler/Vertreiber der Software zusätzlich einen "Vermittlungs-Server" (zentral für alle Kunden) zur Verfügung stellen.....

Die Idee hatte ich auch schon. Sie wurde aber sehr schnell wieder verworfen.
Es gibt mit Sicherheit "nur" ca. 2-300 Apps die zum Einsatz kommen. Da fallen mir nur die Kanonen und die Spatzen ein. :)

[Darlo]

Zitat:

Zitat von hhcm (Beitrag 1350729)

Zitat:

Zitat von Jumpy (Beitrag 1350697)

Vielleicht solltest du als Entwickler/Vertreiber der Software zusätzlich einen "Vermittlungs-Server" (zentral für alle Kunden) zur Verfügung stellen.....

Die Idee hatte ich auch schon. Sie wurde aber sehr schnell wieder verworfen.
Es gibt mit Sicherheit "nur" ca. 2-300 Apps die zum Einsatz kommen. Da fallen mir nur die Kanonen und die Spatzen ein. :)

Dann melde Dich doch kostenlos bei Amazon AWS an. Da bekommst Du quasi für 1 Jahr einen Virtuellen Windows-Server kostenlos. Nach dem kostenlosen Jahr kannst ja dann entscheiden ob sich das Projekt lohnt.

[Mavarik]

Zitat:

Zitat von hhcm (Beitrag 1350729)

Die Idee hatte ich auch schon. Sie wurde aber sehr schnell wieder verworfen.
Es gibt mit Sicherheit "nur" ca. 2-300 Apps die zum Einsatz kommen. Da fallen mir nur die Kanonen und die Spatzen ein. :)

Ein kleiner Vermittlungsdienst - 20 Zeilen Sourcecode - nennst Du "Kanonen auf Spatzen"?

So ein Dienst läuft doch quasi für nix nebenher auf einem Webserver... Besonders wenn es nur max 300 Apps sind...

Bei 10 Mio. Apps würde ich es mir 2x überlegen...

[sh17]

hier etwas als Idee, ein RelayServer:

https://github.com/thinktecture/relayserver

Ansonsten würde ich Richtung Reverse Proxy gehen.

[sh17]

Zitat:

Zitat von Jumpy (Beitrag 1350697)

Vielleicht solltest du als Entwickler/Vertreiber der Software zusätzlich einen "Vermittlungs-Server" (zentral für alle Kunden) zur Verfügung stellen, der hilft, die Verbindung zw. App und PC herzustellen, so dass eine dynamische IP beim PC kein Problem mehr ist. Wie z.B. bei TeamViewer registriert sich der PC bei deinem Server bekommt dann so eine Nummer. Die App registriert sich beim Server, man gibt diese Nummer ein und die App bekommt die Infos/IP für den PC, so dass sie sich verbinden kann.

Wie müsste denn so ein Vermittlungsserver aufgebaut sein? Muss man dazu zwischen Intranet-Server und Internet-Server eine TCP-IP-Verbindung aufbauen und halten und allen Datenverkehr darüber weiterleiten? Also einen HTTP-Request einpacken, ins Intranet schicken, dort auspacken, Zielserver aufrufen und die Antwort wieder einpacken und zurück....

[Mavarik]

Zitat:

Zitat von sh17 (Beitrag 1355979)

Wie müsste denn so ein Vermittlungsserver aufgebaut sein? Muss man dazu zwischen Intranet-Server und Internet-Server eine TCP-IP-Verbindung aufbauen und halten und allen Datenverkehr darüber weiterleiten? Also einen HTTP-Request einpacken, ins Intranet schicken, dort auspacken, Zielserver aufrufen und die Antwort wieder einpacken und zurück....

Emm... Nein

Damit Du durch die Firewalls kommst machst Du nur einen Relay der Ports...