"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.
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?
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?
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...
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!?
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.