Obwohl ich überzeugter Java Jünger bin blicke ich von Zeit zu Zeit zu Microsofts .NET. Ganz sicher werde ich in meinem Alter nicht zu C# oder Visual Basic wechseln. Mein Blick gilt vielmehr den Innovationen rund um das frühzeitige Erkennen von Trends, die in die Java und Web Services Welt überschwappen könnten. Mit .NET 4 kommen auch zahlreiche Neuerungen im WCF. In diesem Post werde ich nur Neuerungen beschreiben, die auch für nicht .NET Entwickler interessant sind.
Zur Familie der WS-*Standards kommt in .NET Version 4 WS-Discovery hinzu. Über WS-Discovery können Services Endpoints bekannt machen und Clients können gezielt nach Services Adressen suchen. In lokalen Netzen kann für Suche und Bekanntmachungen die Multicast Funktionalität von UDP verwendet werden. Zwischen verschiedenen Netzwerken kann mittels SOAP ein Discovery Proxy befragt werden.
WS-Discovery enthält einiges was ich mir vor fast einem Jahrzehnt von UDDI versprochen habe. Beispielsweise eine einfache API für die Suche nach Adressen über Kriterien. Hoffentlich zieht Sun bzw. Oracle bald nach und bietet .NET Kompatibilität im Metro Stack an. Damit wäre dann WS-Discovery auch für Java verfügbar.
Neu in WCF ist auch der Routing Service. Über eine Basisklasse lassen sich mit nur wenigen Zeilen Code und etwas Konfiguration verschiedenste Routing Aufgaben lösen, für die wir in der Java Welt oft komplexeste ESB Produkte einsetzen. So unterstützt der Routing Service alle von WCF unterstützten Protokolle und Message Exchange Patterns. Werden mehrere Protokolle verwendet, so arbeitet der Router als Protocol Bridge z. B. zwischen SOAP und UDP. Über Filter können die Enterprise Integration Patterns Recipient List und Content Based Router realisiert werden. Selbst Load Balancing ist mittels alternativer Endpunkte leicht zu realisieren.
Einige Features für REST Services wurden in .NET 4 aus dem WCF REST Starter Kit übernommen. Praktisch finde ich die Automatic Help Page, die für installierte REST Services erzeugt wird. Über Sie bekommt man Informationen über die unterstützten HTTP Methoden oder Nachrichtenformate wie z.B. XML, JSON usw.. Aufgerufen wird die Help Page durch das Anhängen von help an eine REST Endpoint URL. Für XML Nachrichten wird ein XML Template sowie ein XML Schema erzeugt, aus dem der Aufbau über Nachricht ersichtlich wird. Um Caching in Verbindung mit REST zu erleichtern, erzeugt .NET aus der Angabe eines Profils automatisch die passenden HTTP Header.
Der „BPEL Killer“ Workflow Services, der bereits in .NET 3.5 enthalten war, wurde in .NET 4 um weitere Features ergänzt. Die Workflows sind für langlaufende Prozesse gedacht, bei denen auf externe Ereignisse gewartet werden muss. Mit den Visual Studio 2010 Designer können Workflows grafisch erstellt und als XAML Dateien abgespeichert werden. Ein Workflow wird wie ein BPEL Prozess aus Aktivitäten zusammengebaut. Die Namen der Aktivitäten wie zum Beispiel Receive, SendReply und Sequence ähneln denen von BPEL. Auch der von BPEL bekannte Correlation Mechanismus steht dem Entwickler zur Verfügung. Die in der BPEL Entwicklung lästigen Partnerlinks und PartnerLinkTypes fehlen allerdings. Dafür arbeitet man direkt mit Endpoints. Die Entwicklung mit Microsofts Workflow Services sieht so einfach aus, wie man das vergeblich von BPEL erwartet hatte. Eine Persistierung der wartenden Prozesse in eine Datenbank ist selbstverständlich möglich. Besonders die Verbindung von Web Services, Workflows und XAML Oberflächen für die Human Interactions lassen mich in Microsoft Workflow einen BPEL Killer sehen. Ich hoffe, dass die Workflow Services eine Vereinfachung bei der nächsten BPEL Version bewirken.
Mit .NET bleibt Microsoft weiterhin der Schrittmacher in der Web Services Welt. Der Java Welt bleibt nichts anderes übrig als zu folgen.
Posts
