Oktober 2007 - Einträge

Guerilla SOA
29 Oktober 07 01:20 | Daniel Liebhart | mit no comments

Der Analyst Dana Gardner fasst in einem Blog Eintrag "SOA Insights analysts view IBM’s information umbrella, explore SAP’s Business Objects grab and define ‘Guerilla SOA" (http://blogs.zdnet.com/Gardner/?p=2565) die Diskussionen verschiedener IT Experten und Analysten zusammen. Besonders interessant ist dabei der Abschnitt "On WOA and Guerilla SOA"

Umbrella SOA

Der Begriff "Umbrella SOA" beschreibt den Ansatz der grossen Hersteller SOA als Gesamtarchitektur der IT eines Unternehmens anzusehen. Diese Gesamtarchitektur beschreibt nicht nur die technischen Systeme, sondern auch die Art und Weise, wie Software entwickelt werden soll und wie der Gesamtbetrieb realisiert und kontrolliert werden soll. Also von SOA Governance bis hin zum Bau von Software Factories. Und der Hersteller hat sämtliche Werkzeuge dazu. Und tatsächlich; Die SOA-Modelle vieler Hersteller, Analysten und Berater wirken umfangreich und kompliziert. Hinter vielen dieser Modelle steckt die Vorstellung, mit SOA sämtliche Schwierigkeiten, die nun mal mit dem Bau, dem Betrieb und dem Unterhalt von Informationssystemen verbunden sind, lösen zu können. Hinzukommt der unübersichtliche Wald von Standards, die in Zusammenhang mit der Basistechnologie von SOA - Web Services - entwickelt werden. Beides neigt dazu, die zentralen Vorteile von SOA zu verdecken und SOA als ein Modell erscheinen zu lassen, das komplex und mit sehr grossen Investitionen verbunden ist und nur durch essenzielle Veränderungen der bestehenden IT-Systeme umgesetzt werden kann. 

Web Oriented Architecture

Unter Web Oriented Architecture (WOA - auch Enterprise Web 2.0 oder Enterprise 3.0 genannt) wird ein etwas anderer Ansatz verstanden. Es sollen kleinere Anwendungen basierend auf Web Services realisiert werden können. Dabei soll die Realisierung sehr nahe an den konventionellen Web Anwendungen umgesetzt werden. Dies bedeutet vor allem, dass Web Service Schnittstellen so gestaltet werden, dass sie im "REST Stil", also mit ressourcen-orientierten Interfaces arbeiten. Resource-Centric Interfaces nennt man auch Content-Centric Interfaces. Als Operationen lassen sie lediglich die Standard-HTTP-Methoden GET, POST, PUT und DELETE zu. Die Funktionalität eines Web Service wird mit Resource-Centric Interfaces als implizite Funktion einer Resource umgesetzt, die im Falle eines Aufrufes der entsprechenden HTTP-Methode ausgeführt wird. Eine Ressource kann als Dokument angesehen werden. Der Serviceaufruf ist dann lediglich eine Anforderung dieses Dokuments über das Web. Das Dokument selbst ist eine logische Komponente, die Daten hierarchisch strukturiert und die Operationen auf diesen Daten als Operationen auf einzelnen Dokumentteilen ausführt. Sie ist aber alleine durch die Tatsache, dass ausschließlich HTTP-Methoden als Operationen verwendet werden, sehr mächtig in Bezug auf die Flexibilität und die Möglichkeiten der universellen Ausbreitung eines Dienstes über die gebräuchlichen Internet-Mechanismen.

Guerilla SOA

Wenn mit SOA nur sehr grosse Systeme oder gar ganze Systemlandschaften basierend zu realisieren sind, so ist das für kleine und mittlere Unternehmen oder für Abteilungen, die ein bestimmtes Problem mit Software lösen möchten, kein vernünftiger Weg. Unter Guerilla SOA werden Realisierungen verstanden, die oft an den Vorgaben der zentralen IT Standardisierung vorbeigehen und sich durch einen sehr grossen Pragmatismus auszeichnen. Es wird also die praktische und schnell realisierbare Lösung gesucht. Ob jedoch Guerilla SOA mit WOA tatsächlich immer der wirklich pragmatische Weg ist, bleibt abzuwarten. Denn es ist nicht einfach, Resource-Centric Interfaces einzusetzen. Sie unterscheiden sich substantiell von den üblichen Schnittstellen (Methoden-Orientiert oder Meldungs-Orientiert) und sind gewöhnungsbedürftig.

Pragmatische Umsetzung von SOA

Guerilla SOA kann jedoch auch etwas anders verstanden werden. Als pragmatische Umsetzung von Lösungen basierend auf einer SOA, bedeutet es die Reduktion der einzusetzenden Werkzeuge auf das notwendigste. Dies bedeutet aus meiner Sicht die einfache Erweiterung der üblichen Schichtung von Anwendungen und Architekturen um eine Service- und eine Orchestrierungs-Ebene und damit die Möglichkeit, mit Hilfe von SOA Ordnung in eine bestehende heterogene Systemlandschaft zu bringen und bestehende Systeme weiterzuverwenden. Und es bedeutet ganz sicher eine Beschränkung auf die drei wichtigsten Standards SOAP, WSDL und BPEL. Und es kann bedeuten, dass die Schnittstellen so nahe wie möglich an den bestehenden Systemen realisiert werden, also methoden-orientierte Schnittstellen eingesetzt werden.

Abgelegt unter: , , ,
Service Systems
29 Oktober 07 12:40 | Daniel Liebhart | mit no comments

Im Zentrum einer SOA steht der Service. Selbstverständlich steht im Rahmen einer Software-Architektur der technische Service, der mit einer Web Service Schnittstelle versehen ist, im vordergrund. Der Service kann jedoch auch etwas genereller betrachtet werden; im weiteren Sinn als Dienstleistung. Was für den technischen Service eine SOA darstellt ist für den nicht-technischen Service ein Service System.

Was sind Service Systeme?

Service Systeme versehe ich als Netzwerke bestehend aus Menschen, Technologie und Organisationen mit dem Ziel, wertschöpfende Leistungen zu erbringen. Die Schaffung solcher Netzwerke wird in naher Zukunft einen neuen Berufzweig beschäftigen - den Service Engineer. Unter dem Begriff Service-Sciences Management and Engineering (SSME) entstehen zurzeit auf internationaler Ebene eine Reihe von Initiativen.

Ein Service ist mehr als ein Web Service

Aus technischer Sicht ist ein Service eine sich selbst beschreibende, offene Komponente, die eine schnelle und kostengünstige Zusammenstellung von verteilten Anwendungen ermöglicht. In einer SOA stellt der Service einen Schritt in einem ausführbaren Geschäftsprozess dar. Der ausführbare Geschäftsprozess wird in BPEL (Business Process Execution Language) modelliert, der Service selbst wird als standardisierter Web Service realisiert. Ein technischer Service ist in jedem Fall eine Unterstützungsfunktion für eine betriebliche Tätigkeit. Aus betrieblicher Sicht ist ein Service "eine Veränderung des Zustandes einer wirtschaftliche Entität - einer Person oder einer Ware -, die durch die Aktivität einer anderen wirtschaftlichen Entität im Einverständnis mit der zu verändernden Entität durchgeführt wird." So definiert das neue Produktklassifikationssystem der USA den Service. Der Begriff "Service" stammt aus den 30er Jahren des letzten Jahrhunderts. Diejenigen Branchen, die nicht in die Bereiche Produktionsgewinnung (Landwirtschaft) und Produktionsverarbeitung (Herstellung) passten, wurden unter "Service" zusammengefasst, der auch als "Tertiärer Sektor" definiert wird. Die Aktivität in diesem Sektor sind sehr breit, sie umfassen Bereiche wie die öffentliche Verwaltung, das Gesundheitswesen, die Finanzen, den Verkehr, die Bildung, die Kommunikation und das Business. Eines ist jedoch jedem Service gemeinsam, es ist in jedem Fall ein Netzwerk bestehend aus Menschen, Technologie und Organisationen mit dem Ziel, wertschöpfende Leistungen zu erbringen.

Die Konsequenzen der ökonomischen Bedeutung des Service

Der tertiäre Sektor oder auch der Dienstleistungssektor ist die dominante Form ökonomischer Tätigkeit, die in hoch entwickelten Ländern bis zu 80% eines BIP ausmacht. Die enormen Produktivitätssteigerungen in der Landwirtschaft und in der Güterherstellung sind nicht zuletzt dadurch bedingt, dass Menschen, die beispielsweise in der Landwirtschaft gearbeitet haben, neu in wissensintensiven Berufen tätig sind, die die landwirtschaftliche Produktion unterstützten. So sind spezialisierter Branchen, wie die Herstellung von hochwertigem Saatgut, der Produktion von Landwirtschaftsmaschinen, der Organisation von Warenterminbörsen, Logistikbetriebe und Verwaltungen, entstanden. Dieselbe Entwicklung hat die industrielle Produktion durchlaufen. Die dominante Form ökonomischer Tätigkeit ist der Service. Diese Tätigkeit unterscheidet sich grundlegend von der Warenproduktion. Der zentrale Gegenstand eines wirtschaftlichen Austausches ist nicht mehr eine Ware, sondern ein immaterieller Gegenstand, die Dienstleistung. Im Gegensatz zum Warenaustausch bedingt die Bereitstellung von Services einen möglichst detaillierten Austausch von Kontextinformationen. Eine gute Dienstleistung ist optimal auf das Geschäft des Kunden abgestimmt. Dies bedeutet, dass der Leistungserbringer das Geschäft des Kunden möglichst gut verstehen muss. Ein weiterer wichtiger Unterschied ist der Charakter der Service-Transaktion. Der Austausch wird durch beide Parteien gleichzeitig initiiert und die Leistungserbringung und der Leistungsbezug erfolgt parallel. Die Tiefe der Beziehung zwischen dem Leistungserbringer und dem Kunden hängt von der Art des Kunden ab. Ein B2B Service bedingt eine langfristige und umfassende Beziehung, während B2C Services auf episodische Bedürfnisse ausgerichtet sind. Zentrales Element einer Servicebeziehung ist der Austausch von explizitem und implizitem Wissen zwischen allen Beteiligten. Der Austausch des expliziten Wissens ist durch den Datenaustausch bereits heute möglich, wenn auch die entsprechenden formalen Standards und die notwendige Transparenz der Unternehmen erst in Zukunft - beispielsweise mit SOA - realisiert werden wird. Der Austausch des impliziten Wissens gestaltet sich jedoch wesentlich schwieriger. Das klassische Beispiel für implizites Wissen ist die Fähigkeit Fahrrad zu fahren. Es ist sehr einfach, zu zeigen, wie man ein Fahrrad fährt, es ist jedoch sehr aufwändig, diese Fähigkeit explizit zu beschreiben. Das implizite Wissen eines Unternehmens macht jedoch in vielen Fällen den strategischen Marktvorteil der Firma aus. Der Austausch dieses Wissen wird neue Arten der Interaktion zwischen Leistungserbringer und Kunden erfordern.

Der Service Engineer der Zukunft und seine Hilfsmittel

In Zukunft werden Services mehr und mehr als zentraler Bestandteil der unternehmerischen Tätigkeit anerkannt und organisiert werden, so werden neben bestehendenn F&E Abteilungen und Produktfactories neue Service Creation Groups Entstehen. Service Systems werden zu einer wichtigen Grundlage der Unternehmensstrategie und es wird ein neuer Berufsstand entstehen; der Service Engineer. Er ist für die Innovation von Services und für die Überwachung der Leistungserbringung zuständig. Ausserdem ist er der Impulsgeber für die Transformation von Unternehmen von der traditionellen Produktionsstätte in Richtung Service System Provider. Sein wichtigstes Hilfsmittel sind Informationssysteme, die den Austausch von expliziten und impliziten Informationen während der Serviceleistung erlauben. Diese Informationssysteme unterstützen die Innovation von Services durch die Bereitstellung von Instrumenten, die eine dynamische Modellierung Sozio-Technologischer Systeme beispielsweise durch "Agent-Based Modelling" erlauben. Solche Modelle werden dann in Geschäftsprozesse abgebildet und als ausführbare Prozesse in die entsprechenden IT-Systeme umgesetzt. Während der Austausch von expliziten Informationen durch "Service based Computing" bereits absehbar ist, wird der Austausch impliziter Informationen den Einsatz neuer Technologien in Unternehmen und Organisationen mit sich bringen. So ist ein Service System als Netzwerk nur dann vollständig, wenn alle Beteiligten in Echtzeit implizite Informationen austauschen, sich also bei der Arbeit gegenseitig über die Schultern schauen können, unabhängig davon, wo sie sich gerade aufhalten. Dies wird durch den Einsatz von Technologien, wie beispielsweise einer Weiterentwicklung der Second Life Plattform für Unternehmen oder der Anpassung von Online Game Engines für Service Value Chains, möglich.

 

Abgelegt unter: ,
Oracle möchte BEA kaufen - Gute Idee!
16 Oktober 07 04:24 | Daniel Liebhart | mit no comments

Der Hersteller von Application Server und Middleware-Komponenten, BEA Systems, hat von Oracle ein Übernahmeangebot bekommen. BEA war einst einer der Marktführer im Application Server Bereich, hat jedoch in letzter Zeit sehr an Schwung verloren. Vielleicht auch desshalb, weil mit SOA und den Ansprüchen der Kunden an Integrationskomponenten hohe Investitionen in AquaLogik und WebLogik notwendig gewesen wären, um mit IBM WebSphere und Oracle Fusion Middleware mitzuhalten. BEA hat aufgrund ihrer langen Präsenz auf dem Markt eine sehr grosse Kundenbasis. Diese Kunden würden eine Integration von BEA in die Oracle Produktfamilie profitieren. Es ist davon auszugehen, dass die Standardprodukte PeopleSoft, JDEdwards, Siebel und auch die E-Business Suite als Servicekomponenten mit vorgefertigten Geschäftsprozessen in BPEL auf den Markt kommen werden. Hat nun ein Kunde bereits BEA im Einsatz, so wird eine Integration dieser Komponenten zu einen funktionierenden Ganzen sicher sehr viel Einfacher, wenn die BEA Produkte Teil der Oracle Fusion Middleware Produktfamilie werden.

Abgelegt unter: , ,