1. Einleitung
Heutzutage sucht jedes Unternehmen nach Möglichkeiten, seine Produktionseffizienz zu verbessern, und erforscht auch aktiv die Neuorganisation seiner IT-Ressourcen. IT-Organisationen haben bei der Bewältigung dieser Probleme mithilfe von SOA-Technologien (Service Oriented Architecture) einige Fortschritte erzielt. In den meisten Fällen wird jedoch nur ein kleiner Teil des gesamten IT-Serviceportfolios implementiert. Derzeit zielen die meisten Bemühungen in diesem Bereich lediglich darauf ab, einen „gerade ausreichenden“ Stand der SOA-Einführung zu erreichen – die Fähigkeit zu verbessern, Anwendungen zu erstellen und sie schneller, besser und kostengünstiger in den Markt zu integrieren. Und wie wir gelernt haben, ist das Erreichen dieser Ziele leichter gesagt als getan.
2. Herkömmliche Middleware-basierte Verbundanwendungen
Fakt ist, dass SOA eine Art Middleware ist – und in traditionellen Fällen ist Middleware oft auf weitere Middleware angewiesen, um Daten in einen verbraucherfreundlichen Zustand zu übersetzen. Wenn Sie schließlich herausfinden, dass die Erstellung einer Verbundanwendung, die SOA-Technologie integriert, nicht nur die Verwendung eines Portals (Middleware), sondern möglicherweise auch die Verwendung einer BPEL-Engine (oder sogar Middleware) zur Orchestrierung erfordert, ist dies natürlich der Fall sehr enttäuscht. Schlimmer noch: Sie arbeiten möglicherweise in einer Organisation, die UDDI-Register veröffentlicht und zahlreiche Webdienste registriert. Leider gibt es in den meisten Fällen nur sehr wenige Anwendungen, die diese Dienste tatsächlich nutzen. Wie könnte das der Fall sein?
Sollte die Unfähigkeit, Anwendungen zu erstellen, die diese SOA-Dienste nutzen, zu dem Schluss führen, dass etwas nicht stimmt, weil es für Entwickler von Geschäftsinhalten zu schwierig ist, Anwendungen zu erstellen, die SOA-Dienste direkt nutzen? Sich auf andere IT-Organisationen zu verlassen, um solche Anwendungen für uns zu erstellen, ist das Fehlen einer SOA-Governance-Struktur meiner Meinung nach ein „Ja“. Und es gibt einen sehr wichtigen Grund: Es ist zu schwierig, solche von der IT-Organisation bereitgestellten SOA-Dienste nur für Geschäftsentwickler zu nutzen und zu nutzen. Tatsächlich ist das eigentliche Problem das Fehlen einer einfachen Möglichkeit, eine SOA-Schnittstelle hinzuzufügen – und! Das ist der Vorteil der Kombination von AJAX-Technologie und SOA.
Typischerweise wird ein SOA-Dienst als lose gekoppelter Webdienst implementiert, der Geschäftsfunktionen kapselt und verfügbar macht. Das mag sehr einfach klingen, ist aber sehr komplex und schwierig umzusetzen. Entwickler diskutieren häufig über die Entwicklungsgranularität von SOA-Diensten. Die meisten Entwickler sind sich jedoch einig, dass die Entwicklungsgranularität auf „Geschäftsebene“ am besten geeignet ist. Allerdings ist es immer noch erforderlich, dass eine große Anzahl relevanter Fachexperten an Bord kommt und mit Geschäftsinhalten arbeitet, um den Umfang dieser Dienste festzulegen.
3. Die Renaissance von SOA
Glücklicherweise interessieren sich die Menschen in letzter Zeit stark für SOA. Vielleicht erkennen Unternehmen endlich, dass SOA ihnen tatsächlich enorm helfen kann. Möglicherweise ist dies auf bessere Entwicklungstools und Webdienste zurückzuführen, die von Amazon, Yahoo und eBay gefördert werden. Vielleicht ist es AJAX? Ja – deshalb schreibe ich diesen Artikel. Im Ernst, ich denke, dass AJAX zu einer wichtigen treibenden Kraft geworden ist, um das Verständnis der Menschen für SOA zu erneuern, insbesondere in den heutigen hybriden Anwendungsfeldern verschiedener neuer Technologien. Doch wie sollten diese beiden sehr unterschiedlichen Technologien kombiniert und miteinander verbunden werden, um mehr Leistung freizusetzen? Werfen wir zunächst einen Blick auf Wikipedias Definition der aktuellen AJAX-Technologie. Es handelt sich um Webseiten, SOA wird jedoch überhaupt nicht erwähnt. Die Beschreibung lautet:
„AJAX, was für ‚Asynchronous JavaScript+XML‘ steht, ist eine Webentwicklungstechnologie zum Erstellen interaktiver Webanwendungen. Ihr Zweck besteht darin, die Front-End-Webseite durch den Austausch einer kleinen Datenmenge mit dem Server einfacher zu machen.“ im Hintergrund. Es fühlt sich reaktionsfähiger an; daher muss nicht jedes Mal, wenn ein Benutzer eine Änderung vornimmt, die gesamte Webseite neu geladen werden. Das ultimative Ziel besteht darin, die Interaktivität, Reaktionsfähigkeit und Benutzerfreundlichkeit weiter zu verbessern.
SOA wird in dieser Definition nicht erwähnt. Kein Wunder, da sich frühe AJAX-Anwendungen auf die Verbesserung der Funktionalität und Benutzerfreundlichkeit von Seiten konzentrierten. Dies wurde in zahlreichen Anwendungen wie Google Maps, Flickr und Yahoo Mail bewiesen. Es sind jedoch nicht diese verbraucherorientierten Anwendungen, die mich vom Potenzial von AJAX begeistern, sondern die Geschäftsanwendungen, die hinter der Firewall eines Unternehmens laufen und die wirklich von den Vorzügen von AJAX profitieren, denn es zeigt uns zwei Hauptmerkmale: Die eine ist ein Kunde -seitiges Programmiermodell und das andere ist eine einfache Implementierung asynchroner Aufrufe an den Server. Diese beiden Schlüsselfunktionen – die Fähigkeit, Logik auf dem Client (Browser) anzuwenden und die Möglichkeit, auf Serverdaten zuzugreifen, ohne die Webseite zu unterbrechen – öffnen die Tür für die Entwicklung neuer, umfangreicherer Web 2.0-Unternehmensanwendungen. So viele mögliche Anwendungsbereiche des Programms .
Ich habe bereits erwähnt, dass SOA keine Schnittstelle hat. Hier kommt AJAX ins Spiel – es verleiht SOA ein anständiges Aussehen. Lassen Sie mich hier bitte etwas näher erläutern. Wir könnten genauso gut darüber nachdenken, was passieren würde, wenn SOA-Dienste online erscheinen würden. Solche Dienste müssen normalerweise in einem Register oder Lager registriert werden (wenn wir Glück haben) und können dann für den Konsum verwendet werden. Schauen wir uns zum Beispiel an, was auf der StrikeIron-Website ( www.StrikeIron.com ) verfügbar ist. StrikeIron hat erfolgreich einen „Web-Services-Marktplatz“ für die breite Öffentlichkeit geschaffen. Auf den ersten Blick ähnelt der Verzeichnismechanismus in StrikeIron einer Liste, die in einer Kleinunternehmensanwendung bereitgestellt wird. Aber später werden Sie feststellen, dass es sich nicht nur um Anwendungen handelt, sondern um Webdienste. Das Konzept, dass ein einzelnes Unternehmen WSDL/REST-Webdienste für ein breites Spektrum von Verbrauchern bereitstellt, hat viele Auswirkungen. Aber werfen wir zunächst einen Blick darauf, was dieses Unternehmen verkauft. Nach Angaben von StrikeIron (das den Zugang zu diesen Diensten ermöglicht) gehören zu den beliebtesten Webdiensten:
· US-Adressüberprüfung
· Globaler SMS-Dienst
· Umsatz- und Verbrauchssteuer
· E-Mail-Überprüfung
· Reverse Phone Lookup
Nichts Zweifellos alles Diese Webdienste sind sehr nützlich und können in vielen verschiedenen Bereichen eingesetzt werden. Aber gleichzeitig sind sie zu „Ware“. Mit anderen Worten: Es ist mir möglicherweise egal, wer diese Dienste anbietet, sondern ich möchte nur die Informationen erhalten, die ich möchte. Würde ich andererseits einfach einen beliebigen Webdienst nutzen, um Bargeld von meinem Girokonto auf mein Sparkonto zu überweisen? Ich muss zunächst Vertrauen in diesen Dienst aufbauen, also eine gewisse Beziehung zu dem Anbieter aufbauen, der ihn anbietet. Dieser „Vertrauenskreis“, der zwischen mir (dem Verbraucher) und dem Dienstleister besteht, stellt auch die Beziehung innerhalb des Unternehmens und seiner Partner dar.
4. Kombination von AJAX- und SOA-Technologie
Die oben beschriebene Methode kann auch von Unternehmen übernommen werden, um ihre Webdienste einer breiteren Benutzerbasis bereitzustellen. Über einen Web-Services-Markt können Unternehmen verschiedene Web-Services registrieren – und diese Web-Services sind normalerweise nur innerhalb des Unternehmens oder für Partner verfügbar. Natürlich wollen die Marktanbieter, dass dies geschieht, aber was noch wichtiger ist: Wir sehen eine Chance, die AJAX+SOA-Technologie einzusetzen, um eine neue Klasse von Web 2.0-Geschäftsanwendungen voranzutreiben.
Zum ersten Mal hatten die Menschen das Gefühl, dass Anwendungsentwicklung und SOA endlich zusammenkommen. Wir verfügen über Geschäftsfunktionen, die in wiederverwendbarer Form beschrieben werden – einem SOA-Service. Wir haben allgegenwärtige Konnektivität – das Web. Wir haben Browser, die sich als die neuen Anwendungscontainer erweisen. Wir haben ein Programmiermodell für diese Art von Anwendungscontainer/Browser – JavaScript. Und sie alle nutzen offene Standards! Was verlangen wir eigentlich noch?
Ich würde mir insbesondere eine schnellere Möglichkeit zur Entwicklung von Anwendungen auf der Grundlage aller oben genannten Technologien wünschen – eine Möglichkeit, Anwendungen zu erstellen, ohne auf Middleware angewiesen zu sein, die in SOA-Dienste integriert ist. Genau das soll eine Webanwendung können – „direkte Anbindung an SOA“. Diese „direkte Verbindung zu SOA“ sollte in der Lage sein, traditionelle Portalbarrieren und schwergewichtige Prozess-Engines zu umgehen, um direkt (zumindest konzeptionell; wir werden später mehr darüber erfahren) auf SOA-Dienste zuzugreifen. Damit meine ich nicht nur Webdienste, es können auch BPEL-Orchestrierungsdienste, grobkörnige POJO-Dienste, RSS-Feeds oder alles andere sein, das als „Dienst“ verfügbar gemacht werden kann. Selbstverständlich sollten die Schnittstellen über offene Standards offengelegt werden.
Dieses neue Entwicklungs- und Laufzeitmodell schafft eine neue Möglichkeit, anwendungsgesteuerte Verbundanwendungen zu erstellen. Es hat den Reiz eines Client/Server-Typs, ohne den schweren Ballast traditioneller schwerer Client/Server. Es läuft browserseitig und kann je nach Anforderung implementiert werden.
5. Benutzerbasierte Verbundanwendungen
In den letzten Jahren haben wir alle vom Konzept der „Verbundanwendungen“ gehört. Die meisten Anbieter sprechen jedoch von „zusammengesetzten Diensten“ – als Möglichkeit, ihre Host-Dienste in andere, nützlichere Dienste oder Portalanwendungen umzustrukturieren. Lassen Sie mich zur weiteren Erläuterung eine Analogie anführen.
AcmeGrid, unser fiktiver Grid-Computing-Anbieter in diesem Artikel, bietet einen Dienst – Grid-Computing – an, der es Ihren Anwendungen ermöglicht, als Dienst ausgeführt zu werden. Die Kunden des Unternehmens sagten, sie wollten eine Möglichkeit, viele Dienste zu einem grobkörnigen Dienst zu kombinieren. Daher hat AcmeGrid natürlich einen Eclipse-basierten AcmeGrid Composite Application Builder (CAB) veröffentlicht. Interessanterweise ähnelt CAB stark einem BPEL-Designer, ist jedoch enger in die von AcmeGrid veröffentlichten Dienste integriert. Obwohl sehr schön, handelt es sich jedoch nicht um eine echte Anwendung, sondern bestenfalls nur um eine Dienstleistung. Im Wesentlichen ähnelt CAB eher einem Service Builder. Aber wer braucht einen Service Builder, wenn wir versuchen, Anwendungen zu erstellen? Bald kündigte ein weiterer fiktiver Anbieter, nennen wir ihn AcmePortal, seinen Portal Composite Application Builder (PCAB) an. Es wird auch mit einem Eclipse-basierten Designer ausgeliefert; obwohl es auch wie ein BPEL-Designer aussieht und sich anfühlt, „weiß“ dieses Programm, wie man Portale erstellt. In vielen Fällen funktioniert ein Portal genauso gut wie eine Anwendung. Wer jedoch darauf besteht, ein Portal in eine Anwendung umzuwandeln, wird vergebens sein.
Tatsächlich möchte ich wirklich eine benutzerbasierte Verbundanwendung implementieren und nicht eine Middleware-basierte Verbundanwendung. Dazu brauchte ich eine Entwicklungs- und Laufzeitplattform, die AJAX und SOA nicht nur nutzen, sondern auch beide verwalten konnte. Einige Anbieter haben das Konzept von AJAX-Anwendungen noch einen Schritt weitergeführt und WSDL-basierte Webdienste direkt aus dem Browser aufgerufen, was im Wesentlichen ein SOAP-Aufruf ist. Dieser Ansatz hat sogar einen Namen – „Client/SOA“. Für einfache Nicht-Unternehmens- oder Verbraucheranwendungen mag dies in Ordnung sein, für echte Unternehmensprogramme jedoch nicht. Warum? Denn wenn Sie einen Webdienst direkt aus dem Browser aufrufen, ist die Überwachungsfunktion gleichbedeutend mit der Übergabe an den Browser – was einfach bedeutet, dass überhaupt kein Überwachungsproblem vorliegt. Abbildung 1 zeigt das Blockdiagramm der unbeaufsichtigten Webdienstnutzung. Ich habe noch nie ein Unternehmen getroffen, das seine Dienste nicht überwacht hat, und ich glaube nicht, dass Unternehmen dies zulassen würden, nur weil wir darin technisch sehr effizient sind. Wenn Sie mir nicht glauben, denken Sie daran, dass Unternehmen ihre Firewalls niemals für andere Anwendungen als HTTP und SSL öffnen. Egal wie sehr wir die Systemadministratoren überzeugen, sie werden keine anderen Ports öffnen.
6. Wir brauchen eine neue Art von Plattform.
Wie aus dem oben Gesagten hervorgeht, geht es bei uns nicht nur um AJAX- und SOA-Technologien. Was wir tatsächlich brauchen, ist eine Plattform, die die notwendigen Überwachungsfunktionen für die Koexistenz von AJAX und SOA im Unternehmen bereitstellen kann. Diese Plattform bietet auch die Möglichkeit, SOA-Dienste aus Kundensicht zu nutzen und kann auch den Dienstverbrauch überwachen. Abbildung 2 zeigt, wie Webdienste über ein Service-Gateway verwaltet werden können. Ein Service-Gateway ist eigentlich eine serverseitige Abstraktion, die den Servicezugriff im Namen des Clients überwacht und reguliert. In dem Fall, den wir gerade besprochen haben, handelt es sich dabei um eine browserbasierte AJAX-Anwendung. Das Schöne an der Verwendung eines Service-Gateways ist, dass Sie nicht darauf beschränkt sind, nur auf Dienste zuzugreifen, die innerhalb des Unternehmens ausgeführt werden. Dieses Service-Gateway kann jeden im Unternehmen registrierten Service überwachen. Bei einem WSDL-basierten Webdienst registriert das Unternehmen die WSDL, und die WSDL stellt zur Laufzeit eine Bindung an den Dienst bereit. Dabei kann es sich um einen Dienst handeln, der im Rechenzentrum eines Unternehmens ausgeführt wird, es könnte sich aber genauso gut um einen Dienst handeln, der im Rechenzentrum einer Partnerschaft ausgeführt wird. Wenn ein Unternehmen (durch Regulierung) Anwendungen den Zugriff auf Dienste erlaubt, spielt es keine Rolle, wo diese Dienste ausgeführt werden.
7. Fazit
Nach der Lektüre dieses Artikels hoffe ich, dass Sie die Leistungsfähigkeit der Kombination von AJAX und SOA zu schätzen wissen – insbesondere, wie die beiden nebeneinander existieren und neue Arten webbasierter Anwendungen mit den für die Unternehmensdienstanwendung erforderlichen regulatorischen Funktionen ermöglichen können . Ich bin fest davon überzeugt, dass wir am Vorabend einer neuen Ära voller erstaunlicher Möglichkeiten stehen. Im Web 2.0-Zeitalter sind soziale Netzwerke, das Teilen von Bildern und verschiedene Anmerkungstechnologien allesamt großartig, aber was wirklich einflussreich ist, ist die Reaktion von Web 2.0 auf Unternehmen.