Kommunikation zwischen Delphi und Metro App (WCF?)

[CodeX]

Zitat von mjustin:

"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 von mjustin:

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 von mjustin:

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 von mjustin:

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 von mjustin:

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 von mjustin:

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 von CodeX:

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 von CodeX:

Zitat von mjustin:

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 von CodeX:

Zitat von mjustin:

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 von CodeX:

Zitat von mjustin:

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 von mjustin:

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 von mjustin:

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 von mjustin:

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 von CodeX:

Zitat von mjustin:

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 von CodeX:

Zitat von mjustin:

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 von CodeX:

Zitat von mjustin:

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 von mjustin:

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 von mjustin:

Zitat von CodeX:

Zitat von mjustin:

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 von CodeX:

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).

[CCRDude]

Zitat von mjustin:

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).

Ich vermute mal die Absicht dahinter ist: ein Dienst in der großen Wolke ist immer verfügbar, ein lokaler Dienst muss erst installiert sein, was über die Installationsmechanismen der Metro App über den Store nicht geht.