Kommunikation zwischen Delphi und Metro App (WCF?)

[CodeX]

Mein Wunsch ist es, zwischen meiner bestehenden Delphi-Anwendung und einer Metro-App, die ich gerade erstelle, zu kommunizieren.

Wenn meine Recherchen korrekt waren, ist die beste Möglichkeit dafür per WCF (info1, info2). Andere Vorschläge sind mehr als erwünscht!
Delphi XE3 hat für einen ähnlichen Einsatzzweck anscheinend den MetropolisSvc eingeführt, der aber wohl nur für die Live-Kachel-Aktualisierung zu gebrauchen ist.

Die einzigen beiden Resourcen, die ich zu WCF und Delphi gefunden habe, sind diese hier:
http://edn.embarcadero.com/article/36962
http://blogs.embarcadero.com/pawelgl...08/04/04/38508

Leider bekomme ich das nicht so recht mit meinem Delphi XE nachvollzogen. Ich weiß nichtmal, wie ich an "Add Reference" kommen soll. Da wird sich seit Veröffentlichung der Artikel vor 5 Jahren wohl ein bisschen was verändert haben...

Kann mir da bitte jemand weiterhelfen?

[Phoenix]

Zitat:

Zitat von CodeX (Beitrag 1182156)

Leider bekomme ich das nicht so recht mit meinem Delphi XE nachvollzogen. Ich weiß nichtmal, wie ich an "Add Reference" kommen soll. Da wird sich seit Veröffentlichung der Artikel vor 5 Jahren wohl ein bisschen was verändert haben...

Kann mir da bitte jemand weiterhelfen?

Äh, nein. Die beiden Artikel beziehen sich auf Delphi 2007, und zwar dort für Delphi .NET. Delphi für .NET wurde dann 2009 durch Oxygene for .NET aka Delphi Prism ersetzt.
Das heisst in XE ist das Zeug gar nicht mehr drin - da müsstest Du schon Prism / Oxygene nehmen. WCF (Windows Communication Foundation) ist eine reine .NET-Technologie, die Du von Delphi aus gar nicht ansprechen kannst.

Als alternative würde ich hergehen, und eine Kommunikation via TCP/IP (z.B. mit den Indy-Komponenten) aufbauen.
Problematisch wird höchstens, dass die Metro-Apps in dem Moment suspended werden, in dem sie verlassen wird. Das heisst in genau dem Moment wo die App gewechselt wird, steht der Prozess (und zwar 'hart' - wenn ein Halbes Netzwerk-Paket abgearbeitet wurde, dann wird die andere hälfte erst weiter bearbeitet, wenn die App wieder in den Vordergrund kommt).

Zudem darf sich eine Metro-App an und für sich nicht darauf verlassen, dass auf der gleichen Maschine ein bestimmter Dienst läuft (und ein Dienst nicht, dass eine Metro-App läuft).

In diesem Video hier wird das Konzept gut beschrieben: http://channel9.msdn.com/Events/BUIL...2011/TOOL-789C (Vor allem irgendwo bei ca. ±47 Minuten).

[mjustin]

Zitat:

Zitat von CodeX (Beitrag 1182156)

Mein Wunsch ist es, zwischen meiner bestehenden Delphi-Anwendung und einer Metro-App, die ich gerade erstelle, zu kommunizieren.

Wenn meine Recherchen korrekt waren, ist die beste Möglichkeit dafür per WCF

Wenn die "Metro" Anwendung (neuer Name ist "Modern UI") als Client, die Delphi Anwendung als Server arbeiten soll, dann ist es im Prinzip ganz einfach:

* die Delphi Anwendung muss einen SOAP Web Service Server anbieten (das geht ab Delphi Professional)
* die Metro Anwendung muss diesen Web Service konsumieren, also Requests an ihn senden können.

Für die Modern UI Anwendung kann dazu im Prinzip WCF verwendet werden (WCF Clients können problemlso auf nicht-.NET Webservices zugreifen, die entsprechend konfiguriert sind - zum Beispiel in Java mittels JAX-WS).

Ich würde aber dennoch erwägen, als "Vermittler" zwischen der Delphi und der Modern UI Anwendung einen .NET Dienst zu verwenden.

Zum Beispiel mittels HTTP als Kommunikationskanal

Modern UI App -> (über WCF) -> .NET Service (WCF Server) -> (über HTTP) -> Delphi Anwendung

Alternativ können natürlich auch andere Methoden der Interprozesskommunikationen benutzt werden, also Named Pipes, Memory Mapped Files, oder Message Queues (MSMQ und Co.)

Für die "beste" Lösung ist natürlich wichtig zu wissen, wie die Kommunikation aussehen soll - ob der Modern UI App Client Anfragen an die Delphi Anwendung senden soll, oder auch von Delphi aktiv Nachrichten an die Modern UI App übermittelt werden sollen.

[CodeX]

Vielen Dank für Deine Antwort! Ich freue mich, dass ich nicht der einzige bin, den die Thematik interessiert. :)

Zitat:

Zitat von Phoenix (Beitrag 1182164)

WCF (Windows Communication Foundation) ist eine reine .NET-Technologie, die Du von Delphi aus gar nicht ansprechen kannst.

Ohoh, das ist aber nicht gut. Ich dachte, da es sich um DLLs handelt, lassen sich deren Schnittstellen auch ganz normal verwenden. Wie sieht's dann statt dessen mit WWSAPI aus? Eine kurze Recherche zeigte, dass es das native Äquivalent zu WCF ist.
Letztlich ist es ja nur eine HTTP-Kommunikation. Der besagte MetropolisSvc-Service aus XE3 kommuniziert ja scheinbar auch nur per REST.
Dazu gleich mal zwei Fragen:

1. Ich finde leider keine verlässliche aktuelle Aussage von Microsoft, dass Metro-Apps mit einem lokalen Webserver kommunizieren dürfen. Vor ca. einem Jahr hieß es noch, dass dies nicht erlaubt sei. Es scheint mir aber so, als wäre diese Einschränkung aufgehoben worden. Findet jemand eine Quelle dazu?
2. Was ist die simpelste Möglichkeit, über meine Anwendung eine REST-Schnittstelle bereitzustellen? Hier wird "DataSnap REST Application" verwendet. Ich finde das nicht in meinem Delphi XE. Muss/Kann man das nachinstallieren?

Zitat:

Zitat von Phoenix (Beitrag 1182164)

Als alternative würde ich hergehen, und eine Kommunikation via TCP/IP (z.B. mit den Indy-Komponenten) aufbauen.
Problematisch wird höchstens, dass die Metro-Apps in dem Moment suspended werden, in dem sie verlassen wird. Das heisst in genau dem Moment wo die App gewechselt wird, steht der Prozess (und zwar 'hart' - wenn ein Halbes Netzwerk-Paket abgearbeitet wurde, dann wird die andere hälfte erst weiter bearbeitet, wenn die App wieder in den Vordergrund kommt).

Woher hast Du diese Information? Ausprobiert? Gelesen? Kommt das irgendwo im Video?
Warum sollte die Metro-App nicht mehr im Vordergrund sein, wenn sie über TCP/IP kommuniziert?

Zitat:

Zitat von Phoenix (Beitrag 1182164)

Zudem darf sich eine Metro-App an und für sich nicht darauf verlassen, dass auf der gleichen Maschine ein bestimmter Dienst läuft (und ein Dienst nicht, dass eine Metro-App läuft).

Gut, das ist ein anderes Problem. Da muss/kann man sich irgendwie mit arrangieren.

Zitat:

Zitat von Phoenix (Beitrag 1182164)

In diesem Video hier wird das Konzept gut beschrieben: http://channel9.msdn.com/Events/BUIL...2011/TOOL-789C (Vor allem irgendwo bei ca. ±47 Minuten).

Das Video ist auf jeden Fall eine gute Info, danke! Ich habe mir jetzt nur 15min an der besagten Stelle angeschaut, werde es mir aber noch komplett anschauen. Allerdings muss ich sagen, dass der Typ wohl nur über ein bestimmtes Teil-Thema gut Bescheid weiß. Die meisten Fragen zur Interoperabilität beantwortet er mit "I don't know. Go talk with the Windows guys", zudem ist das Video schon 1 Jahr alt (seit dem hat sich an den Schnittstellen und Spezifikationen noch einiges geändert). Da sollte man also vorsichtig sein.

[CodeX]

Zitat:

Zitat von mjustin (Beitrag 1182191)

"Metro" Anwendung (neuer Name ist "Modern UI")

Ganz formell heißt es wohl sogar "Windows Store application" ... aber der Einfachheit halber würde ich gerne bei Metro bleiben. ;)

Zitat:

Zitat von mjustin (Beitrag 1182191)

die Delphi Anwendung muss einen SOAP Web Service Server anbieten (das geht ab Delphi Professional)

Meinst Du, weil mal per SOAP die WCF-Schnittstelle bedienen kann und per REST nicht?
Dann als Vorlage einfach "SOAP Server Application" nehmen?

Zitat:

Zitat von mjustin (Beitrag 1182191)

WCF Clients können problemlso auf nicht-.NET Webservices zugreifen, die entsprechend konfiguriert sind - zum Beispiel in Java mittels JAX-WS).

Die naheliegende Frage wäre ja dann, wie ich das für Delphi konfigurieren kann?

Zitat:

Zitat von mjustin (Beitrag 1182191)

Ich würde aber dennoch erwägen, als "Vermittler" zwischen der Delphi und der Modern UI Anwendung einen .NET Dienst zu verwenden.

Ist das tatsächlich einfacher als den Delphi SOAP Server WCF-tauglich zu machen?
Jede zusätzliche zwischengeschaltete Komponente führt letzlich zu mehr Fehlerquellen...

Zitat:

Zitat von mjustin (Beitrag 1182191)

Alternativ können natürlich auch andere Methoden der Interprozesskommunikationen benutzt werden, also Named Pipes, Memory Mapped Files, oder Message Queues (MSMQ und Co.)

Ich war der Meinung, dass zumindest die ersten beiden Optionen bei Metro nicht erlaubt seien!?

Zitat:

Zitat von mjustin (Beitrag 1182191)

Für die "beste" Lösung ist natürlich wichtig zu wissen, wie die Kommunikation aussehen soll - ob der Modern UI App Client Anfragen an die Delphi Anwendung senden soll, oder auch von Delphi aktiv Nachrichten an die Modern UI App übermittelt werden sollen.

Ich wäre erstmal glücklich, wenn der aktive Weg von Metro -> Delphi funktionieren würde. Damit hätte ich gut 90% meiner Usecases abgedeckt. Die restlichen 10% würde ich danach zwar auch noch gerne angehen, aber ich glaube das ist noch ein ganz neues Fass. Irgendwelche Möglichkeiten für Push-Benachrichtigungen wird es ja hoffentlich geben. Diese Möglichkeit würde ich mir gerne nicht verbauen.

[mjustin]

Zitat:

Zitat von CodeX (Beitrag 1182194)

Meinst Du, weil mal per SOAP die WCF-Schnittstelle bedienen kann und per REST nicht?
Dann als Vorlage einfach "SOAP Server Application" nehmen?

Der erste deiner beiden Links (http://msdn.microsoft.com/en-us/library/hh556233.aspx) besagt, dass WCF nun auch nicht mehr empfohlen wird:

Zitat:

Use the WinRT syndication APIs instead of those exposed by WCF. For more information see, WinRT Syndication API

Typisch Microsoft :)

Diese API scheint Atom und RSS zu unterstützen.

Das sind zum Glück offene Standards.

Aber da ich kein Windows 8 und das passende Visual Studio habe, kann ich nicht sagen ob WCF nicht mehr geht bzw. auf lokale Server zugreifen kann.

Zitat:

Zitat von CodeX (Beitrag 1182194)

Zitat:

Zitat von mjustin (Beitrag 1182191)

WCF Clients können problemlso auf nicht-.NET Webservices zugreifen, die entsprechend konfiguriert sind - zum Beispiel in Java mittels JAX-WS).

Die naheliegende Frage wäre ja dann, wie ich das für Delphi konfigurieren kann?

In Delphi kann man da leider nicht viel konfigurieren. Ich habe z.B. Microsoft Dynamics CRM nur über einen C# Proxy anbinden können. Daher ist die Alternative RSS / Atom eigentlich nicht so schlecht, die jetzt von Microsoft empfohlen wird.

Zitat:

Zitat von CodeX (Beitrag 1182194)

Zitat:

Zitat von mjustin (Beitrag 1182191)

Alternativ können natürlich auch andere Methoden der Interprozesskommunikationen benutzt werden, also Named Pipes, Memory Mapped Files, oder Message Queues (MSMQ und Co.)

Ich war der Meinung, dass zumindest die ersten beiden Optionen bei Metro nicht erlaubt seien!?

Sorry, das bezog sich nur auf die Verbindung zwischen dem C# Service und der Delphi Anwendung, nicht die Verbindung Metro -> Service.

Zitat:

Zitat von CodeX (Beitrag 1182194)

Zitat:

Zitat von mjustin (Beitrag 1182191)

Für die "beste" Lösung ist natürlich wichtig zu wissen, wie die Kommunikation aussehen soll - ob der Modern UI App Client Anfragen an die Delphi Anwendung senden soll, oder auch von Delphi aktiv Nachrichten an die Modern UI App übermittelt werden sollen.

Ich wäre erstmal glücklich, wenn der aktive Weg von Metro -> Delphi funktionieren würde. Damit hätte ich gut 90% meiner Usecases abgedeckt. Die restlichen 10% würde ich danach zwar auch noch gerne angehen, aber ich glaube das ist noch ein ganz neues Fass. Irgendwelche Möglichkeiten für Push-Benachrichtigungen wird es ja hoffentlich geben. Diese Möglichkeit würde ich mir gerne nicht verbauen.

Für den Weg Metro -> Request -> Delphi -> Response -> Metro ist RSS / Atom geeignet, da es Web-basiert ist.

Duplex WCF funktioniert laut Stackoverflow nicht mit Metro, aber es soll angeblich möglich sein eine Metro App mit weitgehenden Rechten für Internetkommunikation auszustatten (http://stackoverflow.com/a/7507232/80901).

Wichtig ist noch die Frage der Topologie: soll die Delphi Anwendung der "Server" für viele Metro-Clients sein (1:N), oder sollen peer-to-peer Verbindungen (von einer Metro App zu einem Delphi Prozess, also 1:1) hergestellt werden?

p.s. in diesem FAQ wird erwähnt, dass es aus Metro Anwendungen keine localhost Verbindungen geben kann (ausser zur gleichen App):

How can a Metro app in Windows 8 communicate with a backend desktop app on the same machine?

Das bedeutet, die Delphi App muss auf einem anderen Rechner installiert sein.

p.p.s:

zu WCF Funktionen in Metro: WCF in Metro apps – supported functionality

[CodeX]

Zitat:

Zitat von mjustin (Beitrag 1182200)

Diese API scheint Atom und RSS zu unterstützen.

Ich schau mal, wie man damit dann mit Delphi arbeiten kann. Kann ich mir noch nicht so ganz vorstellen...

Zitat:

Zitat von mjustin (Beitrag 1182200)

Wichtig ist noch die Frage der Topologie: soll die Delphi Anwendung der "Server" für viele Metro-Clients sein (1:N), oder sollen peer-to-peer Verbindungen (von einer Metro App zu einem Delphi Prozess, also 1:1) hergestellt werden?

Definitiv 1:1!

Zitat:

Zitat von mjustin (Beitrag 1182200)

p.s. in diesem FAQ wird erwähnt, dass es aus Metro Anwendungen keine localhost Verbindungen geben kann (ausser zur gleichen App): How can a Metro app in Windows 8 communicate with a backend desktop app on the same machine?

Die Kommunikation dort ist teilweise schon ein Jahr alt und ich bin der Meinung, irgendwo gelesen zu haben, dass MS diese Einschränkung nach größerem Protest wieder verworfen hat. Dafür spricht auch der MetropolisSvc-Service aus XE3.
Ich versuche nachher nochmal, eine verlässliche Quelle zu finden. Wenn da jemand mehr Erfolg bei der Suche hat, sehr gerne!

[mjustin]

Zitat:

Zitat von CodeX (Beitrag 1182202)

Zitat:

Zitat von mjustin (Beitrag 1182200)

Diese API scheint Atom und RSS zu unterstützen.

Ich schau mal, wie man damit dann mit Delphi arbeiten kann. Kann ich mir noch nicht so ganz vorstellen...

Einfachstes XML über HTTP, kein Hexenwerk :)

Zitat:

Zitat von CodeX (Beitrag 1182202)

Zitat:

Zitat von mjustin (Beitrag 1182200)

Wichtig ist noch die Frage der Topologie: soll die Delphi Anwendung der "Server" für viele Metro-Clients sein (1:N), oder sollen peer-to-peer Verbindungen (von einer Metro App zu einem Delphi Prozess, also 1:1) hergestellt werden?

Definitiv 1:1!

Ok, das Delphi Programm wird dann natürlich eine Freischaltung der lokalen Firewall benötigen, sobald es einen TCP Port öffnet.

Zitat:

Zitat von CodeX (Beitrag 1182202)

Zitat:

Zitat von mjustin (Beitrag 1182200)

p.s. in diesem FAQ wird erwähnt, dass es aus Metro Anwendungen keine localhost Verbindungen geben kann (ausser zur gleichen App): How can a Metro app in Windows 8 communicate with a backend desktop app on the same machine?

Die Kommunikation dort ist teilweise schon ein Jahr alt und ich bin der Meinung, irgendwo gelesen zu haben, dass MS diese Einschränkung nach größerem Protest wieder verworfen hat. Dafür spricht auch der MetropolisSvc-Service aus XE3.
Ich versuche nachher nochmal, eine verlässliche Quelle zu finden. Wenn da jemand mehr Erfolg bei der Suche hat, sehr gerne!

Laut letztem Kommentar (vom August 2012 also relativ neu) des FAQ ist ein Workaround mit Sourcecode hier zu finden:

[GUIDE] How to bypass WinRT / Metro sandbox using simple trick

[CodeX]

Zitat:

Zitat von mjustin (Beitrag 1182203)

Laut letztem Kommentar (vom August 2012 also relativ neu) des FAQ ist ein Workaround mit Sourcecode hier zu finden:
[GUIDE] How to bypass WinRT / Metro sandbox using simple trick

Wenn ich das aber richtig sehe, wird dort BasicHttpBinding verwendet, letztlich also per WCF kommuniziert.

Zitat:

Zitat von mjustin (Beitrag 1182203)

Zitat:

Zitat von CodeX (Beitrag 1182202)

Zitat:

Zitat von mjustin (Beitrag 1182200)

Diese API scheint Atom und RSS zu unterstützen.

Ich schau mal, wie man damit dann mit Delphi arbeiten kann. Kann ich mir noch nicht so ganz vorstellen...

Einfachstes XML über HTTP, kein Hexenwerk :)

Gibt's denn dafür auch schon einen vorgefertigten Baukasten (wie bspw. die REST oder SOAP Server-Beispiele), den Du empfehlen würdest?

Zur Transparenz:
Ich habe heute nach ein paar Denkanstößen hier noch eine grundsätzliche Frage (ohne konkreten Delphi-Bezug) dazu auf SO gepostet.

[mjustin]

Zitat:

Zitat von CodeX (Beitrag 1182258)

Ich habe heute nach ein paar Denkanstößen hier noch eine grundsätzliche Frage (ohne konkreten Delphi-Bezug) dazu auf SO gepostet.

Das Ergebnis kann man wohl schon zusammenfassen:

* WinRT und Desktop Anwendungen können nicht kommunizieren, ausser in Debug-Umgebungen
* der MetropolisSvc in Delphi XE3 kommuniziert nicht mit WinRT, sondern nur mit einem Live Tile

Zitat (letzter Kommentar von gestern):

Zitat:

No, tiles themselves are not WinRT apps. For example, I have a tile for Outlook, Word, etc - but those are native apps. Start Tiles are kind of just icons on steroids. From what I can determine, and I could be wrong, the XE3 stuff is just creating a custom "icon" that is created to look like a Tile, if that makes sense. At the end of the day, there is no communication between the MetropolisSvc and WinRT. That is why their docs say you cannot use MetroplisSvc with a WinRT app.

Was sich mir noch nicht ganz erschliesst:

* wenn Metro Apps mit einem Web Server kommunizieren können (Wettervorhersage, Social Media etc.), und das über TCP/IP (HTTP) machen, warum geht das nicht wenn der Server lokal läuft? Oder irre ich mich und es geht (man kann statt localhost ja die IP Adresse des Netzwerkadapters angeben).