Microsofts Bestrebungen zur Kombination von Software und Services „Software plus services (S+S)“

David Chappell fasst in seinem Whitepaper Microsofts Bestrebungen in Bereich „software plus services (S+S)“ zusammen. Das Whitepaper ist entscheiderorientiert, die Lektüre lohnt sich jedoch auch für Architekten und interessierte Entwickler.

BizTalk Track Basta! Spring 2008

Bisher fanden bei vergangenen Basta! Veranstaltungen vereinzelt Sessions zum Themenkomplex BizTalk statt. Erstmalig findet nun ein kompletter BizTalk Track statt. Geplant ist ein ein durchgängiges Beispiel, das in allen Sessions aus dem jeweiligen Blickwinkel betrachtet wird. Auf der Agenda finden Sie den Sie den BizTalk Track am 28-Feb-08, die Sessionbeschreibungen sind verlinkt.

Microsoft "Oslo" und die IDS Scheer AG — ein geschlossener BPM Kreislauf

Nach Aussage und Vorführung (Accenture, Avanade, IDS Scheer und Microsoft) während der Keynote auf der SOA and Business Process Conference Konferenz im November 07 in Redmond gibt es nun Bewegung im Versuch die fachliche Modellierung von Geschäftsprozessen besser in Folgeversionen von Microsoft BizTalk Server 2006 R2 zu integrieren und umzusetzen.

Mit dieser strategischen Initiative gilt es, IDS Scheer ARIS Software von der reinen Geschäftsablaufmodellierung zur Ablaufausführung, Überwachung, Simulation und Optimierung heranzuziehen. Die Bedeutungen für die (hohe) Erwartungshaltung innerhalb des Markts sind enorm:

1. eine große Erleichterung für Architekten und Entwickler

2. schnellere Verfügbarkeit von Lösungen für Anwender

Die geplante Integration und den Weg zu einem geschlossenen Lebenszyklus entnehmen Sie folgender Abbildung.

Service Virtualisierung mit der "Managed Services Engine (MSE)" – Ausblick auf zukünftige Oslo Funktionalität

Mit der Managed Services Engine (MSE) stellt Microsoft auf der SOA and Business Process Conference Konferenz im November 07 in Redmond eine Lösung zur Virtualisierung von Services vor. Der Ansatz kommt aus der „Microsoft Praxis“ wurde in einer ersten Versionen von Microsoft Consulting Services entwickelt und ist derzeit bei „Pattern and Practices“ beheimatet. Laut Microsoft soll dieser (sinnvolle) Baustein einer Service-orientierten Infrastruktur in der Microsoft Oslo Initiative münden. Technologisch ermöglicht die MSE bspw. die elegante Versionierung von Services, als auch deren Wiederverwendung. Technologisch basiert die MSE auf der Windows Communication Foundation (WCF).

Microsoft Oslo – die Vision

Die unter obigem Codenamen zusammengeführte Software wird als Einheit ab 2009 ausgeliefert (siehe Abbildung unten, zeitliche Freigabeplanung). Oslo stellt eine breit angelegte Microsoft Initiative dar, um Kommunikations- und Geschäftsprozess- Technologie für „composite applications“ auszuliefern. Dies sind Anwendungen, die neue Geschäftsabläufe auf bereits in einer Organisation vorhandene Abläufe, etwa ERP, darstellen und mit diesen via Web Services kommunizieren. Als herausragende Software in der als Oslo bezeichneten Initiative gilt BizTalk Server Version 6 (BizTalk Server 2006 R2 bezeichnet Microsoft intern als Version 5). Version 6 wird eine neue Kommunikationskomponente („messaging component“) aufsetzend auf der Windows Communication Foundation (WCF) und eine neue auf den Workflow Foundation (WF) aufsetzende Geschäftsprozess-/Ablauflogiklaufzeitumgebung („workflow engine“) auf den Markt bringen. Beide, WCF und WF, zu anfangs im .NET Framework 3.0 eingeschlossen, werden in zukünftigen Versionen einschließlich Oslo erhältlich sein, sind aber bisher nicht offiziell benannt und werden im Beitrag als .NET Framework „4“ bezeichnet. Zusätzlich wird BizTalk Server Version 6 weitere nicht im Framework enthaltene Komponenten umfassen:

1. Unterstützung für „publish-subscribe communication routing“ (Nachrichtenverteilung auf Basis von Metadaten).

2. Kommunikations-Adapter um Anbindungen zu bedeutenden Geschäftsanwendungen (zum Beispiel mySAP ERP, Siebel CRM) zu gewährleisten.

3. Unterstützung für die Bereitstellung von (Geschäfts)Abläufen auf Serverfarmen

Ein weiterer Teil von Oslo ist eine gemeinsam genutzte Repository Komponente, die Abläufe, „Web Service Contracts“ und andere Komponenten von „composite applications“ speichert und zentralisierte Entwicklung und Verwaltung unterstützt. Dieses Repository wird dann sowohl von BizTalk Server Version 6 als auch von Visual Studio (sehr wahrscheinlich mit dem Codename „Rosario“ bezeichnet und ca. 2009 verfügbar) genutzt; ebenfalls von zukünftigen Versionen der Systems Center Software wie Operations Manager, Überwachungssoftware und dem „configuration manager“ für Software UpDates und Softwarebestandsverwaltung. Die Art und Weise der Auslieferung des Repository muss noch geklärt werden – neben anderen Möglichkeiten könnte es Bestandteil vom .NET Framework „4“ sein, eine einzelne Software oder sogar ein (weiteres) Merkmal des Microsoft SQL Server Management Systems werden. Visual Studio wird weiterhin BizTalk Server die Entwicklungsumgebung und deren Mittel bereitstellen, um Kommunikations- und Geschäftsabläufe zu erschaffen.

Jedoch wird Version 6, ähnlich wie Vorgängerversionen, sehr wahrscheinlich Prozessmodellierungs- und Überwachungssoftware enthalten, die eben nicht Visual Studio benötigen, um Analysten zu unterstützen, die Geschäftsabläufe definieren und überprüfen (müssen).

Stand heute

Das bereits heute verfügbare SOA- und Geschäftsprozesssoftware-Portfolio von Microsoft spannt sich über einen breiten Bereich, der Geschäfts- und EDV-Strategie als auch Lösungsbereitstellung umfasst. Die Ansammlung gibt Verantwortlichen für Geschäftsführung, EDV-Fachleuten, Architekten und (Software)Entwicklern Handreichungen, Technologien und eine Reihe von (unterstützender) Software, um die Gesamtheit der Anwendungen und Tragweite ihrer Arbeitsweise, Entwürfe zukünftiger Anwendungen, deren Design, den Aufbau und die (weitere) Pflege, Aufrechterhaltung von SOA- und Geschäftsprozessstrategien und deren entsprechende Lösungsansätze zu gewährleisten, genauso Software im Umfeld eines Mitarbeiters in seinen Rollen zu berücksichtigen. Die Voraussetzung der Ergebnisse dieser Implementierung fach- und zeitgerechter Anwendungen und Optimierung von Geschäftsabläufen, welche tatsächlich die Produktivität anheben, die Kosten nachhaltig senken und vor allem aber organisatorische Flexibilität und rechtzeitige Anpassungsfähigkeit bedeuten, sind:

1. die (Rück)Besinnung auf bereits vorhandene (Lösungs-)Teile und Anwendungen

sowie

2. die Durchsetzung eines sich an Modellen orientierenden Vorgehens, um die Verquickung von tatsächlichen Geschäftsabläufen und Microsoft Technologien darzustellen

Weiter Information finden Sie auf der neu eingerichteten Oslo Homepage

Windows Workflow Foundation (WF) betreiben in BizTalk Server 2006 R2 – ein technischer Zwischenschritt in Richtung Oslo

Microsoft veröffentlicht Version 1 der in einem ersten „Preview“ zur TechEd 2007 in Orlando vorgestellten „BizTalk Server 2006 R2 Extensions For Windows Workflow Foundation SDK V1“. Das SDK erleichtert Architekten und Entwicklern das oft unterschätzte „Hosting“ von WF Workflows. Microsoft BizTalk Server führt Windows Workflows aus in seiner skalierbaren, handhabbaren Infrastruktur aus und bringt die Fähigkeiten des sichern Betriebs von Workflows ein. Dies ist ein Zwischenschritt und ein erster technischer Ausblick in Richtung Oslo, wo Windows Workflows dann auch nativ von BizTalk Server unterstützt werden sollen. Dieses SDK unterliegt Einschränkungen im Support durch Microsoft.

Microsoft ESB – erstes Fazit

Schlüsselfunktionalität gibt die ESB Guidance in ihrer Ausprägung als Basis einer Serviceorientierten Infrastruktur vor. Zusätzlich wird diese Funktionalität, neben ihrer Verfügbarkeit durch die Komponenten in der ESB Guidance, ebenso für externe Anwendungen durch eine Anzahl von Schlüsselwebdiensten („Core Web Services“) verfügbar gemacht (beispielsweise der Transformationsdienst oder dynamische Endpunktermittlung). Somit erhalten ESB Entwickler die Flexibilität, Anpassungen und Erweiterungen an den als Standard referenzierten Implementationen vorzunehmen, damit diese den besonderen SOI Anforderungen genügen. Die endgültige Veröffentlichung der ESB Guidance wird der Hersteller voraussichtlich unmittelbar nach Verfügbarkeit von BizTalk Server 2006 R2 (September 07) ankündigen.

Microsoft ESB – SOA Governance Integration

(Groß-)unternehmensbezogene Anwendungen haben robuste und verlässliche Management Merkmale zu unterstützen um mit Geschäftsanforderungen, Gesetzesvorgaben, Service Level Agreements (SLAs) und Kunden- und Handelspartner- Erwartungshaltungen im Einklang zu sein. Das vom Drittanbieter „SOA Software Inc.“ (siehe http://www.soa.com) verfügbare SOA-Softwaremanagementprodukt „SOA Software Management Point“ ist eine konzeptuelle Erweiterung zum „SOA Software Web Services Management Point“, die besonders auf die BizTalk Server 2006 R2 Umgebung anzuwenden ist und während der Ausführung die Kontrolle für Webdienstanwendungen garantiert. Der „SOA Software Management Point“ integriert sich vollständig (nativ) in den „SOA Software Service Manager“ und die „Workbench“ Produkte. Ungleich einem typischen Web Services Management Point steht diese Implementation mit Diensten durch die BizTalk Umgebung im Zusammenhang; ausgedrückt durch die BizTalk Server „Receive Locations“ und „Send Ports“. Gemäß der konfigurierbaren Natur der Receive und Send Ports (gegenüber einer Anzahl von BizTalk Adaptern konfiguriert), sind diese Dienste nicht notwendigerweise mit Web Diensten verbunden. Aber sie lassen sich als solche behandeln, und zwar im Sinne des „SOA Service Managers“ und der „SOA Workbench“.

Microsoft ESB – Funktionsweise

Der ESB nimmt eingehende Dokumente an und arbeitet mit ihnen. Die ausgeführten Maßnahmen können Übermittlung, Transformation, Ablauflogik, Zustellung und anderes einschließen, müssen es aber nicht unbedingt. Damit das ESB System funktioniert, benötigt es verschiedene mit dem vorgegebenen Dokument verbundene Anweisungen, die besagen, was geschehen soll. Es gelingt, indem man Metadaten zu den Dokumenten fügt, die eine Standardmenge von im Zusammenhang stehenden nutzbaren Eigenschaften liefern. Ein typischer Lebensablauf eines Dokuments, das ausserhalb des ESBs entsteht und durch den Microsoft BizTalk 2006 R2 ESB läuft, ist (siehe Abbildung):

1. Dokument ist bei einer „On-Ramp“ angenommen.
2. Eine Pipeline Komponente legt in den Nachrichtenmetadaten („Kontext“) stehende Eigenschaften fest (basierend auf entweder einer Komponenteneigenschaft oder einer SOAP Kopfzeile im übermittelten Dokument.
3. Dokument ist der BizTalk „MessageBox- Datenbank“ zugestellt.Basierend auf den Dokumentenmetadaten/ Kontexteigenschaften erhält ein Abonnent („Subscriber“) ein Dokument. Abonnenten können sein:

a. „Intermediaries”, beispielsweise Ablauflogik („Orchestrations”).

b. „Off-Ramps“, beispielweise ein beliebiger Zustelldienst („Delivery Agent“), der mit einer Guidance ausgestattet ist oder ein eigens aus gewählter Zustelldienst („Custom Delivery Agent“).

Als Alternative zu den „On-Ramps“ können Dokumente von BizTalk Anwendungen entstanden sein und in die MessageBox durch folgenden Prozess gelangen:

1. Dokument entsteht in einer Ablauflogik („Orchestration“).
2. ESB Metadaten Eigenschaften werden angefüllt.
3. Dokument wird durchgereicht zur MessageBox.
4. Weitere Verarbeitungsschritte entsprechend der Dokumentenmetadaten.

Die erzeugten Dokumente in die MessageBox einzulegen und dass Abonnenten („Subscriber“) sie gemäß den Verarbeitungsregeln („Processing Instruction“) aufnehmen, ist genau genommen ein „StateMachine“ Muster. Diese locker verbundene Vorgehensweise, um die Architektur von BizTalk Lösungen zu errichten, ergibt hochskalierbare Lösungen und gilt als von der Industrie angenommener Weg im Sinne einer beispielhaften Mustervorgehensweise.

Microsoft ESB – Installation

Die ESB Lösungsbausteine liegen im Quellcode aber auch als Installationsmedium vor. Installationsvoraussetzungen sind Microsoft Windows Server 2003 (Service Pack 2), .NET 3.0 und BizTalk Server 2006 R2. Die ESB Guidance ist selbst eine BizTalk Server 2006 R2 Anwendung, deren Installation dem Standardablauf einer BizTalk Anwendung folgt.

Microsoft ESB – Architektur

Die meisten heutigen Entwickler besitzen einen Hintergrund in code-orientierter, prozeduraler oder objektorientierter Programmierung. Deshalb übersehen sie bei der Entwicklung von BizTalk Lösungen leicht die BizTalk Server dokumentenorientierten Fähigkeiten. Der BizTalkServer 2006 R2 besitzt einen mächtigen „Publish/ Subscribe” Mechanismus. Dieser Mechanismus arbeitet durch das Erschaffen und Befüllen von „Subscriptions“ (Abonnement auf Eigenschaften/Metadaten von Nachrichten). Wenn ein neues Dokument in der „MessageBox-Datenbank“ (Hauptaufgaben: Persistenz von Nachrichten und Ablauflogiken) ankommt (siehe Abbildung unten), hält der Dokumentenagent nach Empfängern Ausschau und sendet das Dokument an jeden Endpunkt, für den ein Abonnement besteht. Diese lassen sich in vielfältiger Art und Weise aufstellen, einschliesslich des Anbindens einer Ablauflogik („Orchestration“) an einem Empfangspunkt („Receive Port“). Insgesamt gesehen bedeutet dies eine leistungsfähigere und skalierbarere Vorgehensweise. So lassen sich eine Reihe diskreter Unterprozesse schaffen und die Dokumenttypen definieren, die die Prozesse aufrufen ohne weitere Gedanken an die Folgeprozesse zu vergeben. Ein Prozess mag durch das Auftauchen eines Dokuments aktiviert sein, verrichtet seine Arbeit, um dann vielleicht ein weiteres Dokument zurück in die „MessageBox-Datenbank“ zu legen. Letzteres kann wiederum einen oder mehrere weitere Unterprozesse auslösen.

Einige der Schlüsselmerkmale dieser Vorgehensweise lauten:

• Skalierbarkeit („Scalability“): Diese Art von Lösung nimmt im vollen Umfang die Vorteile des BizTalk Servers 2006 R2 durch seine im Lieferumfang enthaltenen Steigerungsmöglichkeiten wahr.
• Erweiterbarkeit („Extensibility“): Zusätzliche Prozesse können in das System aufgenommen werden, ohne dass die bereits installierte Lösung geändert oder nochmals zu installieren ist.
• Elastizität/Leistungsspitzenverwaltung („Resilience/Surge-Handling“): Sollte eine plötzliche und unerwartete Leistungsspitze von eingehenden Dokumenten auftauchen, reihen sie sich in der MessageBox ein und werden anschließend, wie es möglich ist, abgearbeitet – optional werden weitere verarbeitende Server hinzugeschaltet.

Alles innerhalb der Microsoft ESB Guidance Anwendungen ist, in dem die BizTalk „MessageBox-Datenbank“ als Annahme und Ablieferpunkt dient, lose miteinander verknüpft. Die ESB Anleitung wurde mit dieser Architektur im Hintergrund entwickelt und benutzt sie ausführlich in ihrer Implementation.

Die Dienste und Komponenten fallen in sechs Kategorien:

• Web Dienste („Web Services“), die interne Dienste darstellen, wie zum Beispiel die Bestimmung/Auflösung von Endpunkten und die Übermittlungsweisen von Dokumenteninhalten. Schlüsseldienste („Core Services“), wie die von Software(„Agents“), die Übermittlungsweisen und Dokumentenablieferung darstellen.
• Empfangspunkte („On-Ramps“), die Dokumente in einer Reihe von Formaten und Protokollen wie SOAP; WSE, JMS (MQ Series) von außen empfangen; oder spezielle Formate und Protokolle benutzen.
• Versandpunkte („Off-Ramps“), die „Send Ports“ für die Auslieferung von Dokumenten, dabei Formate und Protokolle wie SOAP, WSE, JMS, (MQ Series) oder spezielle Formate und Protokolle benutzen.
• Verwaltung von Ausnahmen („Exception Management“), der Ausnahme Web Dienst („Exception Web Service“), der Ausnahmemanagement Mechanismus („Exception Management Mechanism“) und Komponenten, die Einzelheiten von Ausnahmen zum ESB Management Portal weiterleiten.
• Das Management Portal, welches „Provisioning“, Ausnahmebehandlung und B2B Dienste als auch Informationen über Prozessverlauf und andere operative (Maß-) Analysen darstellt.

Microsoft ESB - Bausteine

Microsoft liefert viele der benötigten Bausteine für den Ausbau einer umfassenden Service-Orientierten Infrastruktur durch seine Anwendungs- und Integrationsplattform, die Windows Server 2003 (R2), das .NET Framework 3.x und BizTalk Server 2006R2 einschliesst. Der Microsofts ESB bringt die Fähigkeiten mit:

• Dokumentenverteilung („Message Routing”)
• Dokumentenvalidierung („Message Validation”)
• Dokumententransformation („Message Transformation”)
• zentrales Ausnahmemanagement („Centralized Exception Management“)
• Erweiterbares Adaptersystemgefüge („Extensible Adapter Framework”)
• Dienste-Ablauflogik/Aggregation („Service Orchestration”)
• Geschäftsregelsystem („Business Rule Engine”)
• Fachliche Analyse („Business Activity Monitoring”)

Microsoft ESB Guidance (Anleitung) enthält einen Architekturleitfaden, Muster- und Erfahrungsbeispiele aus der Praxis, sowie BizTalk Server und .NET Komponenten, die es Microsoft Partnern erlauben, große und kleine ESB Lösungen auf der Microsoft Plattform aufzubauen. Ebenso besteht die Anleitung aus einer Anzahl von BizTalk Server Anwendungen. Die Anleitung liefert Softwarearchitekten und – entwicklern eine Menge häufig anzutreffender ESB Anwendungsfälle und Beispielszenarien. Diese sind innerhalb einer ESB Client Beispielanwendung zugänglich und durch eine Vielzahl veränderbarer Parameter auszuführen, um die Funktionalität der „ESB Core Engine“, der „Core Services“, des „ESB Management Portal“ und den dazugehörigen „Pipeline Komponenten“ (Nachrichtennach/-vorverarbeitung) aufzuzeigen. Aufgebaut auf einer modularen Architektur, finden viele der Microsoft ESB Guidance Komponenten als einzeln stehende Bausteine Verwendung. Somit erhalten ESB Softwarearchitekten und ‑entwickler die Flexibilität, Anpassungen und Erweiterungen an den als Standard referenzierten Implementationen vorzunehmen, damit diese den besonderen SOI Anforderungen genügen.

Microsoft ESB – Microsofts Betrachtungsweise

Der Begriff Enterprise Service Bus fällt oft im Zusammenhang der Implementation einer auf Service-Orientierte Architektur ausgelegten Infrastruktur. Jedoch zeigen gemachte Erfahrungen zur Verbreitung und Einsatz von SOAs, dass ein ESB nur einen der vielen Bausteine darstellt, die eine umfassende Service-Orientierte Infrastruktur (SOI) ausmachen. Der Begriff ESB formte sich in zahlreichen, unterschiedlichen Richtungen aus. Seine Definition hängt von der Auslegung einzelner ESB- und Integrationsplattform- Anbieter und von den Anforderungen besonderer SOA Initiativen ab. Auf der Grundlage der Erfahrungen, die Microsoft durch viele erfolgreiche, sich im bewährten Einsatz, befindliche SOI Implementationen sammelte, trifft nachfolgende Aussage zu: Ein Enterprise Service Bus lässt sich als Ansammlung von IT-Architekturbausteinen beschreiben, die sich auf herkömmliche EAI, nachrichten- orientierte Middleware, Web Dienste, .NET und Java Interoperabilität, (Groß-/Host-) Rechnerintegration und Interoperabilität mit Dienstverzeichnissen und zentral verwalteten IT-Bausteinen gründet. Anwendungen dieser Muster liefern eine Infrastruktur, die flexible und sichere Wiederverwendung von Diensten ermöglicht und die Fähigkeit, Dienste schnell zusammen in neue vollständige Geschäftsprozesse zu überführen (siehe Abbildung unten).

Microsoft ESB - Definitionen und Begriffserläuterungen

Als Einstieg die verschieden Definitionen und Begriffserläuterungen zu ESB:

Wikipedia

Wikipedia beschreibt den ESB als „…eine Softwarearchitekturkonstruktion, implementiert durch Technologien, die sich in der Kategorie der „Middleware“ Infrastrukturprodukte befinden. Sie gründen sich gewöhnlich auf Standards, die grundlegende Services oder Dienste für komplexere Architekturen durch eine ereignisgesteuerte oder auf Standards basierende „Message Engine“ (der Bus) bereitstellen

IBM

IBM definiert ESB als ein System das „… einemUnternehmen erlaubt, einen umfassenden, flexiblen und konsistenten Zugang zur Integration bei gleichzeitiger Verringerung der Komplexität der zu integrierenden Anwendungen zu besitzen. Wegen der komplexen und unterschiedlichen Natur der Geschäftsbedürfnisse stellt der Enterprise Service Bus eine evolutionäre Vorgehensweise dar, die Nachrichtenorientierung, Ereignissteuerung und Serviceorientierung als Vorgehensweise vereint, um Anwendungen und Dienste zu integrieren“. Das Unternehmen beschreibt die Vorteile folgendermaßen: „… höhere Wiederverwendung von IT-Lösungsbausteinen durch Trennung von Anwendungslogik und Integrationsaufgaben, um die Anzahl, Größe und Komplexität von Integrationsschnittstellen zu verringern“ und die daraus entstehende Möglichkeit „… Dienste hinzuzufügen oder zu ändern, bei einer minimalen Unterbrechung der existierenden im Betrieb befindlichen Softwarelösung; dabei anfallende Kosten zu verringern und eingeschlossenes Risiko zu mindern, wenn sich das Geschäftsmodell ändert und neue Möglichkeiten sich ergeben.“

Sonic Solutions

Sonic Solutions geben eine umfassende Untersuchung des ESB, indem sie die hauptsächlichen Gesichtspunkte, sowohl den IT- als auch geschäftsbezogenen Nutzen diskutieren. Die Beschreibung der Voraussetzung für den Enterprise Service Bus lautet: „Um Altes und Neues zu integrieren, benötigt eine Service Orientierte Architektur (SOA) eine Infrastruktur, die sich an jede IT-Ressource anbindet, unerheblich ob deren Technologie(-herkunft) und wo immer sie sich befindet“.

TIBCO

TIBCO Software definiert ESB als „… eine standardbasierte Kommunikationsschicht in einer Service Orientierten Architektur (SOA), die es ermöglicht, Dienste über mehrere Kommunikationsprotokolle zu benutzen, um die Verbreitung und das Verwalten von Diensten zu vereinfachen und die Wiederverwendung dieser in heterogenen (EDV-) Umgebungen zu fördern“. Der Hersteller schlägt vor „… um diese Fähigkeiten bereitzustellen, sollten ESBs beides unterstützen, zum einen offene Standards und zum anderen proprietäre Technologien: Dazu gehören Web Dienste und UDDI-basierteVerzeichnisse, um Dienste zu erkennen und zu veröffentlichen, Java Message Service (JMS) und andere, weit verbreitete Nachrichtenprotokolle, standardbasierte (XML) Transformationen und einfache Dokumentenweiterleitung“.

David Chappel

In den Ausführungen seines Buchs „Enterprise Service Bus” (ISBN: 0596006756), hält der Autor David Chappel fest, dass, „statt mit den traditionellen Nabe und Speiche („Hub and Spoke”; siehe auch Abbildung unten) Architekturen von unternehmensweiten Anwendungsintegrationsprodukten konform zu gehen, liefert der Enterprise Service Bus einen sehr breit verteilten Ansatz für Integration“. Er fügt hinzu, dass, „… [er] ausgestattet [ist] mit einzigartigen Fähigkeiten, die es einzelnen (Arbeits-) Bereichen oder Geschäftseinheiten erlauben, ihre Integrationsprojekte schrittweise, in kleinen Häppchen, auszubauen. Dabei erhalten die Abteilungen ihre Kontrolle vor Ort und Unabhängigkeit. Trotzdem sind sie in der Lage, jedes (Integrations-) Projekt in ein größeres, umfassenderes Integrationsgefüge oder Netz(werk) einzubinden.“

Microsoft ESB – angekündigte Roadmap

Der Softwarehersteller Microsoft hat den Anschluss an die bisherigen Enterprise Service Bus (ESB) Marktführer hergestellt, schickt sich nun aber selbst an, eine führende Rolle zu übernehmen.

Die Vorstellung des Microsoft ESB auf Basis des „BizTalk Servers 2006“ erfolgte bereits vor Jahresfrist auf der Microsoft SOA und BPM Konferenz in Redmond im Oktober 2006. Zurzeit ist die CTP3 (Community Technical Preview 3) allgemein verfügbar, dazu gab es eine eingeschränkt verfügbare Betaversion für ausgewählte BizTalk Server Partner. Die Veröffentlichung des ESB erfolgt laut Hersteller lizenzkostenfrei im erweiterten Lieferumfang von BizTalk Server 2006 R2.

In folgenden Posts lesen Sie relevante Aspekte zum geplanten Microsoft ESB: ausgehend von allgemeinen Grundlagen zu ESB, über den geplanten Funktionsumfang, bis zum Anwendungsszenarien.

BPM mit Microsoft – erstes Fazit

Als Unternehmen erreichen Sie mit der zuvor beschriebenem Ansatz- und Vorgehensweise leicht die Erfüllung und Sicherstellung oftmaliger und sehr umfangreicher Forderungen nach individuellen, sehr unterschiedlichen, aber nur bedingt vorher bestimmbaren, Ausprägungen eines (vereinzelten) Prozesses pro Geschäftsvorfall (beispielsweise Beschwerdemanagementprozess). Somit ändern Verantwortliche für Geschäftsabläufe, beziehungsweise und/ oder Beteiligte bei der Bearbeitung des gleichen Prozess – gemäss der vorhergehenden Modellierung – im Bedarfsfall wegen neuer Anforderungen auch die Ablauflogik bereits ablaufender Prozesse verlässlich, um die inhaltlich richtige Wiedergabe der Veränderung durch rechtzeitige Anpassung (wegen neuer Vorgaben, zusätzlicher Verordnungen etc.) bestehender Geschäftsabläufe stets zu gewährleisten.

BPM mit Microsoft – SOA im Zusammenspiel mit BPM

Die in vorherigen Post skizzierte Vorgehensweise durch ein BPM-Systemgerüst sichert auf jeden Fall den Nutzen von unternehmensweiter Anwendungsintegration. Aber die Ausführung geschieht in einer anderen Art und Weise: Statt einer von unten nach oben sich ausführenden SOA, also das weithin bekannte Einhüllen von relativ niedrig stehender Technologie, um sie innerhalb einer IT Abteilung immer bereit zu halten, um die Unterhaltungskosten zu senken, liefert das BPM System Gerüst eine von oben nach unten reichende SOA, die sich gerade den Nutzen der bekannten (bisherigen) Vorgehensweise sichert: Nämlich, dass Services durch rein geschäftsbezogene Prozessabläufe zusammengestellt und instrumentiert werden – sozusagen visualisierte und geschäftsablaufbezogene SOA statt einer beliebigen Anzahl von Web Services, die (verlassen) innerhalb einer IT Abteilung sich befinden.

BPM mit Microsoft – Blick zurück und nach vorne

Ein Blick zurück

Die Kostendynamik offenbart sich in einer Vielzahl von bekannten und manchmal durchaus Unstimmigkeit verbreitenden Art und Weise. Ändern sich beispielsweise die Geschäftsbedingungen, dann verändern sich ebenso die Anforderungen an das gesamte Gefüge der Geschäftsabläufe:

Eine neue (Code-basierende und – abhängige) Auslegung der Geschäftslogik war anzufordern, die unweigerlich weitere, andere typisch IT-getriebene Zyklen von Softwareentwicklungen nach sich zieht. Hersteller bieten daher oft gern eine „Formularsoftware“ an, die HTML-basierende Lösungen erstellt. Leider sind sie oft proprietär, die dann wiederum zu höheren Kosten in der Anpassung, Wartung und Pflege führen. Entwicklerbezogene Werkzeuge bestätigen und wahren weiterhin, dass die IT (Abteilung) allgemein der Flaschenhals bleibt. Mit der Zeit behindert die Bürde der IT (allgemein) die Beweglichkeit des (täglichen) Geschäftsablaufs und die Ermächtigung und Befähigung des Anwenders. Gleichermassen verschlimmert diese Situation die gefühlte „Trennung durch die IT (Konstellation)“ im Unternehmen oder sogar bei angeschlossenen Partnern und gibt stetig zunehmender Verärgerung der Benutzer und einer manchmal bereits um sich greifenden Ohnmacht (über die scheinbar festzementierten Zustände) zusätzliche Nahrung.

Ein Blick nach vorn

Auf der anderen Seite liefern wahre BPM Systeme das Rüstzeug für Entwicklung und Verteilung, aber noch wichtiger das System liefert ein vollständiges Gerüst. Ein Gerüst, das sowohl die zugrunde liegende Infrastruktur bereithält, welche die reibungslose Ablieferung von Geschäftsablauf und deren Prozessbausteinen gewährleistet, die untereinander durchaus verknüpft sein dürfen und die darum sich befindende technologische Umgebung. Das gleiche besagte Gerüst, gewährleistet eine Umgebung in der die IT (allgmein) und das (abstrahierte) Geschäftsleben zusammenarbeiten. Eine Umgebung, in der die darin Beteiligten fortlaufend ihre Arbeitsumgebung (kritisch) überwachen und (konstruktiv) verbessern, ohne dabei selbst für sogar kleinste Änderungen die Dienste der IT (Abteilung) nachzufragen. Genau genommen und wirkungsvoll fördert das Gerüst, die Abstraktion von genau angepassten Programmiercode in (immer weiter) wiederverwendbare Komponenten von Geschäftsabläufen (oder SOA Serviceleistungen). Teile oder Services, die Verantwortliche (für Prozesse), Beteiligte oder sogar Anwender direkt mit grafisch unterstützter Software in wiederholt ausführbare XML-basierende Business Process-Modelleselbständig oder sogar eigenständig zusammenstellen.

Diese Art von Funktionalität stellt sich wesentlich breiter auf als was bisher mit rein „ablauftechnisch orientierten Modellen“ möglich schien. Die nun erhältliche Funktionalität gestattet endlich die Anwendung(smöglichkeit), diskrete Elemente bestehender Vor,- und Altsysteme zu integrieren (dabei die bereits getätigten Investitionen erfolgreich zu bestätigen), aber auch die Fähigkeiten allgemeiner Softwareprodukte wie beispielsweise Microsoft BizTalk Server oder SharePoint Portal Server zu erweitern. Anstatt eingebettete, elektronische „Formularsoftware“ bereitzustellen, benutzt und sichert das BPM-System bereits vorhandene „Formularsoftware“ (als Technologien) innerhalb von ASP.NET, Microsoft Office System 2003 InfoPath, JSP, Windows Forms unter anderem, um (deren) „Formulare“ als wieder benutzbare, wertvolle IT-Bestandteile durch das vorher erwähnte Gerüst zugänglich zumachen. Das regelt das zugrunde liegende Gerüst auf eine verblüffend einfache Weise, in dem es die Benutzerschnittstelle (Interface) als Formular von der Logik des (anpassbaren) Geschäftsprozesses und allen anderen IT-Anwendungsbezügen (inhaltlich) trennt. Damit zeigt das nun bekannte Gerüstmodell zum ersten Mal dieses beispielhafte Merkmal für eine beliebige (n-fache) Ebenenstruktur auf, da sich ebenso Prozessmodelle von beliebigen darunter liegenden Prozessen oder-modellen bilden lassen.

Ja sogar darüber hinaus besteht das Prozessmodell nicht nur als reine visuelle (Ablauf-) Beschreibung, sondern es ist identisch mit der ausführbaren Geschäftslogik. Abgespeichert jetzt in XML als bisher in eigens geschriebenem Code, wird sie während der Laufzeit korrekt interpretiert. Deshalb ist es möglich, sollte es der Anwendungsfall notwendig machen, dass der dafür verantwortliche Mitarbeiter flexibel das Modell (der Geschäftlogik) beliebig anpasst. Die Fähigkeiten moderner BPM- Systeme wertvolle IT-Bestandteile (von Geschäftsprozessen) auf der Ebene des Prozessablaufs zusammenzustellen ist eigens durch die auf XML-basierende Architektur möglich, was etwa 2001 heranreifte. Viele andere Arbeitsfluss darstellende Softwareprodukte verkleiden sich als „wahrhaftige BPM Systeme“ und entstanden bereits in den 90ziger Jahren, also lange bevor XML und Web Services heranwuchsen.

BPM mit Microsoft – der Ansatz

Während der in vorherigen Post beschriebene Ansatz vielleicht eine Lösung darstellt, der zu ein paar wenigen Unternehmenskulturen passt, sieht die Wirklichkeit der bestmöglichen Lösungen genau umgekehrt aus: Die Integrationspunkte (in die Geschäftsabläufe) sind als wiederholt verwendbare Komponenten (durch IT) abstrahiert und konzipiert, um es Verantwortlichen zu ermöglichen, diese Komponenten in ihre Prozesse einzubinden – durch einfachste Konfiguration. Veränderungen, Anpassungen geschehen auf der Ebene der jeweiligen Geschäftsinhalte, während die Verteilung allgemein durch die Anwender beschleunigt wird. Statt durch eine weitere kostspielige Aufrechterhalten einer Infrastruktur beschränkt zu sein, erlaubt die zuvor skizzierte Vorgehensweise, dass sich die Geschäftsgepflogenheiten schnellstens auf die Marktanforderungen und Kundenbedürfnisse einstellen, somit einen Gleichklang herstellen.

BPM mit Microsoft – Grundüberlegung

Die richtige Gestaltung und fortlaufende Pflege von Geschäftsabläufen, das Business Process Management (BPM), verspricht eine verlockende Zukunft, denn als zentraler Mittelpunkt steht eine Managementphilosophie, die sich um fortwährende Verbesserung der Geschäftsabläufe kümmert. Untermauert wird diese Geschäftsphilosophie, dass sie ein ausgeklügeltes System zur Unterstützung darstellt, dass Anwendern, Entscheidungsträgern und IT-Fachleuten ermöglicht, usammenzuarbeiten und die Organisationsstrukturen auf dem neuesten Stand zu halten; damit die gesamte Unternehmensorganisation weiterzuentwickeln.

Die bisherige Ablauflogik durch weitverbreitete Technologien seit den 90er Jahren, als auch das Zentralstück vieler etablierter Hersteller, lässt dynamische oder sich laufend anpassbare Verbesserungen im Lebenszyklus nicht zu. In der Regel gilt dies auch für systemzentralistische EAI Plattformen. Tatsächlich bedeutet BPM aber die gemeinsame Instrumentation aller Gesichtspunkte des Verhaltens von Geschäftsabläufen:

1.) Mensch-zu- Mensch (Zusammenarbeit)

2.) Mensch-zu-System (Integration des (PC-)Systems)

3.) System-zu-System (EAI- und B2B-Integration)

Während viele der Hersteller von geschäftsablaufspezifischer Software darüber sprechen, Mensch-zu-System oder Systemzu-System Bedürfnisse zu adressieren, tun sie dies in der Regel auf der Aufgabenebene alleinig durch dafür geschriebenen oder erzeugten Code: Jegliche Veränderung im Arbeitsprozess oder den Vor-, Serversystemen verlangt nach einer Anpassung – oder wenigstens einer Bestätigung – an jedem Punkt, an dem ein Austausch stattfindet.

Darüber hinaus zielen diese Arten von Software darauf ab, Punkt (zu Punkt) Lösungen zu erstellen, die ein einziges System- oder Geschäftsproblem lösen; möglicherweise dabei eine jeweils verschiedene Prozessarchitektur oder Vorgehensweise anwenden. Damit sind sie nicht Teil eines gültigen Gerüsts, das eine allgemein benutzte Infrastruktur und gemeinsame Vorgehensweise liefert.

Auf der jeweiligen Technologieebene bedeutet diese Vorgehensweise, dass die Modelle der Geschäftsabläufe in einer entwicklertypischen Umgebung mit seinen Werkzeugen entstehen. Die erkannte Geschäftslogik schlussendlich in festen Code umgesetzt wird, dann entsprechend mit speziellen Anpassungen erweitert an Vor-, Alt- und wichtige Serversysteme angeschlossen. Das Ergebnis präsentiert sich als ein monolithisches, starres Gebilde, deren Anwender (und Architekten) sich völlig auf die IT-Abteilung verlassen, um auch nur geringste Änderungen vorzunehmen.