Neben all dem Hype rund um Software für Services und all den Innovationen im Bereich der Cloud Services bleibt das Thema der Serviceorientierung und Connectivity innerhalb eines Unternehmens nach wie vor hoch spannend. In diesem Blog Artikel möchte ich auf dieses Thema im Zusammenhang mit dem Microsoft Office SharePoint Server 2007 (MOSS) eingehen.
MOSS ist eine äußerst erfolgreiches Serverprodukt, welches bereits out-of-the-box zahlreiche Informationen für die Informationsspeicherung und Verarbeitung bietet. Bei Gesprächen über dieses Produkt komme ich jedoch relativ schnell zu dem Punkt an dem Interessierte die Fragen stellen wie: „…und wie bekomme ich Geschäftsdaten in die SharePoint Umgebung?“ oder „… und wie binde ich SharePoint an mein SAP System an?“.
Leider lässt sich diese Frage ohne eine detaillierte Kenntnis der vorhandenen IT Infrastruktur nicht so einfach beantworten. Grundsätzlich sind zwei Fragen zu beantworten:
- Welche Systeme und Schnittstellen sind in der IT-Landschaft vorhanden bzw. sollen eingesetzt werden?
- Auf welcher Architekturschicht soll eine Integration erfolgen?
Zunächst muss man sich ein Bild über die bestehenden Systeme und vorhandene Schnittstellen verschaffen. Bei einem vorhandenen SAP System stellt sich die Frage, ob ein SAP-System in „Reinform“ (d.h. ohne weitergehende Integrationstechnologien), SAP Netweaver/XI (oder eine andere Technologie, die SAP-Funktionen als WebServices anbieten kann) oder sogar ein SAP-Portal vorhanden ist.
Beim Microsoft-Technologiestack rund um SharePoint stellt sich die Frage, ob SharePoint alleine, SharePoint mit BizTalk-Adaptoren oder gar ein Gespann aus SharePoint und BizTalk zum Einsatz kommt. Je nach vorhandenen Technologien auf SAP- oder Microsoft-Seite ergeben sich unterschiedliche Anbindungsmöglichkeiten, die in folgender Abbildung skizziert sind.
Abb: Anbindung von Microsoft Office SharePoint Server (MOSS) an Backend-Systeme
Wenngleich diese Abbildung die tatsächlichen Möglichkeiten sehr vereinfacht, werden - so denke ich - die Alternativen deutlich:
Spalte A: SharePoint-SAP Integration
Soll ein ein SAP-System ohne spezielle Integrationskomponenten an SharePoint angebunden werden ergeben sich, je nach vorhandenem Microsoft-Technologiestack folgende Optionen:
-
Eigenentwicklung mit Partnerlösungender früher bekannte .NET Connector für SAP wird leider nicht weiterentwickelt. An dessen Stelle sind Partnerlösungen getreten, die eine .NET-Entwicklung von Integrationsfunktionen unterstützen (z.B.
ERPConnect.net)
-
Eigenentwicklung mit einem BizTalk Adapter für SAPEin solcher Adapter ermöglicht es, aus .NET Programmen, die ihre Kommunikation über
Windows Communication Foundation (WCF) regeln, über WCF auf SAP zuzugreifen. Hierüber ist es dann möglich SharePoint-Erweiterungen (WebParts, Features etc.) mit SAP-Zugriffen zu entwickeln.
-
Einsatz eines BizTalk Servers
Sicherlich die mächtigste Variante der Integration eines SAP-Systems. Hierbei können sowohl die Möglichkeiten der BizTalk Adapter (siehe oben) als auch die Möglichkeit des BizTalk-Servers SAP-Funktionen als WebServices anbieten zu können, genutzt werden. Über die Webservices-Variante ist es dann auch möglich, SAP-Daten und -Funktionen über MOSS-Konfiguration zu integrieren. So ist es beispielsweise möglich SAP-Funktionen über den
Business Data Catalog oder
Excel Services abzugreifen. Eine Positionierung des BizTalk Servers als Integrationspunkt hat darüber hinaus den Vorteil, dass dieser dann seine Stärken bei Integration zusätzlicher Systeme, Business Process Management (BPM), Business Activity Monitoring (BAM) etc. ausspielen kann und eine übergreifende Prozess- und Datensicht bietet.
Eine Integration ist über diese Varianten nur auf unteren Architekturschichten (Integrationsschicht, Anwendungssicht) möglich.
Spalte B: SharePoint-SAP Netweaver/XI
Mit SAP Netweaver/XI stehen auf SAP-Seite Erweiterungen zur Verfügung, die SAP-Funktionen bereits als Webservices anbieten können. Dies erweitert das Möglichkeitenspektrum dahingehend, dass MOSS auch ohne BizTalk Adapter bzw. BizTalk Server über Webservices mit SAP kommunizieren kann (wenngleich ohne BizTalk die Möglichkeiten eines MOSS-SAP-übegreifenden Business Process Managements (BPM) entfallen).
Auch hier ist die Integration auf untere Architekturschichten fokussiert.
Spalte C: SharePoint-SAP Portal
In dieser Variante ist das Spektrum der Möglichkeiten am größten. Neben den bisher vorliegenden Möglichkeiten kann das SAP Portal webbasierte GUI-Elemente (iViews, Portlets etc.) anbieten. Dies ermöglicht es, auf der Präsentationsschicht Inhalte von SAP in SharePoint zu integrieren. Dies ist beispielsweise über iView-, WSRP- oder PageView-Webparts möglich.
Fazit
Grundsätzlich gibt es eine breite Palette an Möglichkeiten, SharePoint mit SAP- (bzw. allgemein Backend-)Daten und Funktionen zu versorgen. Sowohl auf Microsoft-Stack- als auch auf SAP-Seite muss analysiert werden, welche Technologien vorhanden sind bzw. eingesetzt werden sollen, ob die Integration über Konfiguration (BDC, Excel Services) oder Entwicklung (WCF, BizTalk Technologie, Webservices) und auf welcher Architekturschicht (Frontend-, Anwendungs- oder Integrationsschicht) erfolgen soll.
In meinen beiden letzten Blogs zu Software plus Services und dem dadurch erweiterten Handlungsspielraum für Unternehmen habe ich bereit einiges zu Microsofts S+S Strategie geschrieben. In diesem Blog möchte ich kurz etwas zum Services-Spektrum, welches von Microsoft für Anwender und Entwickler bereitgestellt wird, schreiben.
Drei Kategorien von Services: Finished, Attached, Building Block
Hinsichtlich der angebotenen Services unterscheidet Microsoft drei Kategorien von Services: Finished Services stellen vollständige Anwendungen dar, die Anwendern (von Partnern oder Microsoft gehostet) als Dienste angeboten werden. Die Anwendungslogik wird vollständig vom Dienst bereitgestellt, der Anwender greift auf diesen über einen Thin Client (Webbrowser) zu. Die zweite Kategorie sind Attached Services, keine eigenständigen Anwendungen darstellen, sondern bestehende Client- oder Server-Anwendungen um Zusatzfunktionen erweitern. Building Block Services sind die dritte Servicekategorie. Entwickler können diese Dienste nutzen, um eigene Anwendungen zu erstellen, die dann wiederum entweder lokal betrieben werden und die Services im Internet aufrufen oder selbst bei einem Service Provider betrieben werden. Die folgende Tabelle stellt diese Servicekategorien gegenüber und listet jeweils weitere Details auf:
|
|
Finished Services |
Attached Services |
Building Block Services |
|
Alternative Bezeichnung |
Software as a Service (SaaS) |
Add-on Services |
Cloud Platform,
Platform as a Service (PaaS) |
|
Charakterisierung |
- Anwendungslogik als Dienst von einem Service Provider bereitgestellt
- Client ohne nennenswerte eigene Logik (z.B. Webbrowser)
|
- Anwendungslogik vor Ort beim Anwender betrieben
- Dienste erweitern die Anwendung um Zusatzfunktionen
|
- Anwendung basiert zu einem maßgeblichen Teil auf diesen Services
- Anwendung für den lokalen Betrieb oder für eine Ausführung beim Service Provider erstellt
|
|
Zielgruppe |
Anwender |
Anwender |
Entwickler |
|
Services von Microsoft (exemplarisch) |
|
|
|
Tabelle: Kategorien von Microsoft Services für Anwender und Entwickler
Mit diesem Services-Spektrum kann Microsoft die ganze Bandbreite von der Entwicklung eigener Software durch Anwender (bzw. deren Unternehmen) bis hin zum Bezug von Software als Service (Software as a Service, SaaS) abdecken. Auch bei der Eigenentwicklung von Anwendungen oder Anwendungsteilen können Unternehmen (oder ISVs) die Software für den Vor-Ort-Betrieb auslegen, oder auf eine Online Plattform (Platform as a Service, Paas) zurückgreifen, bei der der Betrieb dann von Microsoft-Partnern oder Microsoft selbst erfolgt. Folgende Abbildung bringt die Konzepte "Vor-Ort-Software", "SaaS" und "PaaS" in den Kontext, den ich bereits in meinem Blog zum Handlungsspielraum von Unternehmen beschrieben habe.
Abbildung: Software vs. Software as a Service vs. Platform as a Service von Microsoft
Weitere Informationen
Bei der Entscheidung, ob sie eine für den Eigenbedarf benötigte IT-Leistung selbst erstellen oder über einen externen Dienstleister beziehen, müssen Unternehmen zwischen Kontrolle über detaillierte Eigenschaften der Leistung und Economies of Scale bei der Leistungserbringung abwägen. Je weniger ausgefallene, individuelle Anforderungen vorliegen desto eher ist der Fremdbezug einer Standardleistung durch einen externen Anbieter möglich. Dieser profitiert von höheren Economies of Scale, da er die Leistung gegebenenfalls vielen Nachfragern anbieten kann. Für das nachfragende Unternehmen ergibt sich hieraus eine kostengünstigere Leistungsbereitstellung als dies durch Eigenleistung möglich wäre. Umgekehrt gilt: je wichtiger die Kontrolle über die Leistung (bei individuellen Anforderungen), desto eher wird diese im Unternehmen selbst erbracht, was mit tendenziell geringeren Economies of Scale erkauft wird.
Im Zusammenhang mit "Software plus Services" (S+S) kann die Frage nach Eigenleistung oder Fremdbezug sowohl für die Erstellung einer Software als auch für den Betrieb der Software gestellt werden. Folgende Abbildung zeigt wie durch diese beiden Handlungsalternativen für Unternehmen ein Handlungsspielraum für Softwareentwicklung und -betrieb aufgespannt wird.
Abbildung: Handlungsspielraum durch Software plus Services
Diese Abbildung ist inspiriert von den Ausführungen meines Kollegen, Gianpaolo Carraro, der in seinem Blog-Eintrag "Cloudy Future for the Enterprise and most likely for ISVs too" ebenfalls die Abwägung "Make or Buy" im Zusammenhang mit Implementierung und Betrieb ausführt. Ich habe mir die Freiheit genommen, seinen Ansatz ein wenig zu vereinfachen.
Entscheidung: Make or Buy (Kontrolle vs. Economies of Scale hinsichtlich Funktionalität)
Unternehmen stehen beim Einsatz von Software grundsätzlich vor der klassischen Entscheidung, ob sie die Software selbst erstellen (Make) oder das Standardprodukt von einem Softwarespezialisten beziehen (Buy). Bei der Eigenentwicklung haben sie maximalen Einfluss auf die implementierte Funktionalität. Beim Einsatz von Standardsoftware profitieren sie von hohen Economies of Scale des jeweiligen Anbieters, was die IT-Leistung tendenziell kostengünstiger macht.
Entscheidung: Eigen- oder Fremdbetrieb (Kontrolle vs. Economies of Scale hinsichtlich Service Level)
Diese „Make or Buy“-Entscheidung fällt nicht nur bei der Software selbst sondern auch beim Betrieb der Software an. In den letzten Jahren haben sich eine Reihe von Dienstanbietern auf den Betrieb von Anwendungssoftware spezialisiert und bieten Software als Dienst (Software as a Service, SaaS) an. Mit S+S positioniert sich Microsoft nicht mehr nur als Softwareanbieter sondern auch als Betreiber von Software. Unternehmen haben somit die Wahl, ob sie Software selbst vor Ort (On-Premise) betreiben oder von einem Partnerunternehmen oder von Microsoft hosten lassen wollen. Beim Betrieb durch Partner profitieren sie von hohen, bei Microsoft von maximalen Economies of Scale. Während sie bei Partnern bis Service Level zum Teil jedoch noch individuell aushandeln können, besteht beim Betrieb in Microsofts Rechenzentren nur eingeschränkt Einfluss auf die Ausgestaltung der jeweiligen Service Level.
Neue Herausforderungen beim Überschreiten der Unternehmensgrenze
Beim Betrieb von Software (bzw. Teilen von Software) außerhalb des Unternehmens stellen sich eine Reihe von grundlegend neuen Fragen. Diese betreffen beispielsweise die Service Level des Angebots, die Anbindung des Dienstleisters ans Unternehmen, Integration der extern betriebenen Anwendungen in die Unternehmens-IT, Datensicherheit, Zugriffsschutz etc.
Software plus Services als Weg zu mehr Handlungsalternativen
In der Abbildung oben wird eines deutlich: sowohl die Software vor Ort als auch die Services, die außerhalb des Unternehmens betrieben und als Service konsumiert werden, sind letztlich Software. Ob man im Zusammenhang mit "Software plus Services" etwas als Software (im engeren Sinn) oder Service bezeichnet, hängt vom Deployment-Modell ab (vor Ort: Software; beim Partner oder Microsoft: Service).
Software plus Services erweitert den Spielraum für Unternehmen. Durch das Angebot von Microsoft Services erhalten Unternehmen die Option, Teile der Unternehmens-IT nicht nur von Partnern (Hoster, Service Provider) sondern auch von Microsoft betreiben zu lassen. Für ISVs gilt: nicht nur ganze Anwendungen sondern auch Teile von Anwendungen können ausgelagert werden.
Weitere Informationen:
Auf der weltweiten Partnerkonferenz (WPC), die letzte Woche in Austin (Texas) stattfand, wurden Details zu Microsofts Online Services vorgestellt. In Zukunft werden bestimmte Serverprodukte (Exchange, SharePoint, OCS) auch als Service (Stichwort: Microsoft Online Services) angeboten. Eingebettet ist dieses neue Angebot in Microsofts Software plus Services Strategie. Diese möchte ich an dieser Stelle nochmals erläutern und ein wenig auf deren Bedeutung insbesondere für Unternehmen eingehen.
Software wird heute in Unternehmen in der Regel nach dem klassischen Muster eingesetzt: selbst geschriebene oder lizensierte Client- und Server-Anwendungen werden vor Ort (On-Premise) im Unternehmen betrieben und bereitgestellt. Daneben gewinnen aber Cloud Services, d.h. Services, auf die über das Internet zugegriffen wird, als Teil der Unternehmens-IT an Bedeutung. Dieser Trend zum Bezug von Software als Service (Software as a Service, SaaS) wird in Zukunft dafür sorgen, dass das IT-Portfolio von Unternehmen in der Regel aus einem Mix von vor Ort betriebener Software und Cloud Services besteht.
Diesem Szenario trägt Microsofts "Software plus Services" Strategie (S+S) Rechnung: Microsoft erweitert sein Produktportfolio schrittweise um Services bzw. bietet bestehende Serverprodukte in Zukunft auch als Service an. Damit erhalten Unternehmen die Möglichkeit für ihre IT Landschaft die Vorteile von lokaler Software (Kontrolle, Zugriff, Offline-Fähigkeit, …) mit den Vorteilen von Cloud Services (Skalierbarkeit, schnelle Bereitstellung, …) zu kombinieren. Abbildung 1 skizziert dieses Modell von Software plus Services.
Abbildung 1: Software + Services als Kombination von Vor-Ort-Software mit Cloud Services
So wie das gesamte Portfolio werden auch die Anwendungen selbst Kombinationen aus Client-, Server- und Services-Bestandteilen sein. Unternehmen können flexibel bestimmen welche Technologien jeweils zum Einsatz kommen, um die geforderte Funktionalität zu erbringen:
- Im Bereich der Clientsoftware sind die gewünschte User Experience an der Benutzerschnittstelle, Offline-Fähigkeit sowie die zu unterstützenden Endgeräte entscheidend.
- Für die eingesetzte Serversoftware sind Aspekte wie Kontrolle über die Serverumgebung, Eigentum an der Software, Anpassbarkeit an spezielle Anforderungen, Sicherheit der Installation und Vertrauen hinsichtlich der Datenspeicherung wichtig.
- Beim Bezug der Funktionalität als Service (bei dem die Serversoftware von einem Service Provider betrieben und als Dienst bereitgestellt wird) gewinnen Fragen nach schneller Bereitstellung, hoher Skalierbarkeit und geeigneten Service Leveln an Bedeutung.
In diesem Zusammenhang ist die Wahl eines geeigneten Partners wichtig. Dieser muss nicht nur in der Lage sein den Dienst in der geforderten Qualität bereitzustellen sondern auch entsprechend vertrauenswürdig sein.
Die Verlagerung von Funktionalitäten zu einem Service Provider wirft darüber hinaus gänzlich neue Fragestellungen auf:
- unter anderem muss die Netzwerkanbindung an den Serviceprovider entsprechend leistungsfähig sein
- Authentifizierung und Berechtigungen (Identity) müssen sich genauso verhalten wie es bei einer lokalen Installation der Fall wäre
- neben klassischer Lizensierung treten alternative Bezahlmodelle (Subscription, Webefinanzierung, individuelle Abrechnung nach Transaktions- oder Datenvolumen) in Erscheinung.
Microsoft bietet eine Plattform an, die all diese Fragen adressiert. Die Plattform umfasst neben verschiedenen Client- und Serveranwendungen mit den Online Services auch Cloud Services. All diese Produkte und Dienste basieren auf dem .NET Framework für das Entwicklungs- und Management-Werkzeuge zum Aufbau und Betrieb von S+S Lösungen bereit stehen.
Auch im Februar 2008 gibt es im MSDN Magazin eine Reihe interessanter Artikel für alle, die sich für OBAs, S+S und .NET 3.5 interessieren. Ebenso warten auch einige interessante Webcasts auf Besucher.
MSDN Magazin
Webcasts
Webcasts, bei denen nur ein Tag (aber keine Uhrzeit) angegeben ist, werden nur als Aufzeichnungen bereitgestellt. Der Termin gibt das Datum der Verfügbarkeit der Aufzeichnungen an.
Am vergangenen Donnerstag, denen 17.1.2008, durfte ich einen Webcast zum Thema Office Business Applications für technische Entscheider halten. Für alle, die keine Gelegenheit hatten, sich diesem Webcast anzuhören, möchte ich an dieser Stelle eine kurze Zusammenfassung geben und ein paar Worte zum Feedback, welches ich auf den Webcast erhalten habe, verlieren. Ohne dem Feedback allzu sehr vorausgreifen zu wollen, möchte ich schon an dieser Stelle darauf hinweisen, dass sich der Webcast an Entscheider und nicht an Entwickler richtete. Programmcode fehlt ebenso wie konkrete Umsetzungsbeispiele.
Definition und Potenziale von Office Business Applications
Bei Office Business Applications handelt es sich um eine neue Art von Anwendungen, die auf der Office Business Plattform entwickelt werden, und die Brücke zwischen den bekannten Frontend Produktivitätswerkzeugen der Office-Client-Familie bzw. der SharePoint Plattform und den Geschäftsanwendungen (z.B. Dynamics, SAP, Siebel, ...) im Backend schlagen.
Abb 1: OBAs als Bindeglied zwischen Office und den Backend-Geschäftsanwendungen
Diese Brückenschlagfunktion hilft es zusätzliche Potenziale der Geschäftsanwendungen freizusetzen, indem diese Anwendungen einem erweiterten Benutzerkreis zugänglich gemacht werden. Denn Anwender können in der ihnen vertrauten Office-Umgebung in ihrer täglichen Arbeit bleiben und trotzdem die Funktionen der Backend-Geschäftsanwendungen nutzen.
Technischer Überblick über die Office Business Plattform
Sowohl auf der Office-Client-Seite als auch im Bereich der Office Server Produkte wurden von Microsoft größere Investments getätigt, um Office zu einer Entwicklungsplattform weiterzuentwickeln.
Client Platform Investments
- Open XML Dateiformat (lesen und schreiben von Office-Dokumenten auch ohne die Client-Anwendungen)
- Verbessertes Add-In Modell
- Anpassbare Benutzeroberfläche (eigene Ribbons & Task Panes)
- Eigenes XML und XML Binding in Word
- Erweiterte BI Funktionen und Serverunterstützung in Excel (Excel Services)
- Vereinheitlichtes Objektmodell in Outlook
- Serverunterstützung und ein Managed Object Model in InfoPath (Forms Services)
Server Platform Investments
- Office SharePoint Server 2007
- Excel Services
- InfoPath Forms Services
- Business Data Catalog
- Erweiterbare Enterprise Search
- LOB Single Sign-on
- Content Management
- Windows SharePoint Services
- ASP.NET 2.0 Integration
- Workflow-Unterstützung
- Content Types und Metadaten
- Auditing
- Feature & Solution Deployment
- Technologien zum Zugriff auf die SharePoint Plattform
- Web GUI
- Objektmodell
- Web Services
Mit diesen Technologien steht eine leistungsfähige Plattform zur Verfügung, auf der sich Office basierende Anwendungen entwickeln lassen, die sowohl Client- als auch Serverkomponenten umfassen können.
Umsetzungskonzepte
Generelle Entwicklungsmöglichkeiten
Die MS Office Interactive Developer Map gibt einen guten Überblick über die Möglichkeiten, die ein Entwickler, der auf Basis der Officeplattform entwickelt, hat.
Schichtenarchitektur
Zur ersten Grobplanung einer Office Business Application gibt es von Microsoft einen Architekturvorschlag, der OBAs in vier Schichten unterteilt:
-
Präsentationsschicht
-
Produktivitätsschicht
-
Anwendungsschicht
-
Datenschicht
OBA Patterns
Zur Unterstützung der Feinplanung einer Implementierung konkreter Anwendungsfälle, gibt es von Microsoft so genannte OBA Patterns:
-
OBA Apps as a Reach Channel
-
Document Integration
-
Composite User Interface
-
Complementary Document Workflow
-
Discovery Navigation
-
Collaborative Site
-
Application Generated Tasks & Notifications
Diese sind zum Teil noch in Unter-Patterns untergliedert. Alle Patterns sind dokumentiert (Problemstellung, Lösungsansatz, Technologien) und mit Beispielen ausgestattet.
Mögliche Vorgehensweise
Für eine mögliche Umsetzung gibt es bereits eine bewährte Vorgehensweise. Diese untergliedert ein Umsetzungsprojekt in fünf Phasen:
-
Schaffung einer zentralen Prozess- und Datenhaltungsinstanz für die Zusammenarbeit innerhalb von Teams (z.B. mit SharePoint Team-Sites)
-
Implementierung einer Integrationslogik, zur teamübergreifenden Zusammenarbeit
-
Anbindung an die zentrale IT und dort betreute Geschäftsanwendungen
-
Anbindung an zentrale Datenbestände zur Unterstützung von BI-Anwendungen
-
Anbindung von Partnern (unternehmensexternen Services)
Werkzeuge
Für die Entwicklung von OBAs stehen für verschiedene Entwicklergruppen unterschiedliche Entwicklungswerkzeuge zur Verfügung:
-
SharePoint Designer für Power User, die in beschränktem Maße Anpassungen der Umgebung vornehmen können sollen
-
Visual Studio für die professionellen Entwickler. Diese erhalten zahlreiche Projektvorlagen für die Client- und Serverprogrammierung.
Fazit
Mit der Office Business Plattform steht die Basis zur Entwicklung leistungsfähiger Geschäftsapplikationen als Office Business Applikationen zur Verfügung. Neben dieser Plattform bietet Microsoft bereits zahlreiche Hilfestellungen in Form von Patterns und Practices, Referenzarchitekturen und Entwicklungs- und Managementwerkzeuge für verschiedene Entwicklergruppen.
Ziel dieses Webcast zwar erst einen groben Überblick über die Thematik zu geben, und die verschiedenen Aspekte wie bereitstehende Entwicklungskomponenten, Architekturkonzepte, Patterns, Vorgehensweisen und Werkzeuge im Kontext von Office Business Applications strukturieren. Bewusst habe ich hier die einzelnen Bereiche nur oberflächlich behandelt. In Folge-Webcast werde ich auf diese Themen noch vertieft eingehen, und auch in Form von Beispielen und Implementierungsvorführungen behandeln. Ich hoffe, damit auch die Zuhörer zufriedenzustellen, die sich im Webcast mehr Details gewünscht hätten.
Weitere Informationen
Aufzeichnung des Webcasts
Referenzarchitekturen:
Auch im Januar 2008 gibt es im MSDN und TechNet Magazine eine Reihe interessanter Artikel für alle, die sich für OBAs, S+S und .NET 3.5 interessieren. Ebenso warten auch einige interessante Webcasts auf Besucher.
MSDN Magazin
Technet Magazin
Webcasts
Webcasts, bei denen nur ein Tag (aber keine Uhrzeit) angegeben ist, werden nur als Aufzeichnungen bereitgestellt. Der Termin gibt das Datum der Verfügbarkeit der Aufzeichnungen an.
Microsoft ist leider nicht sehr eindeutig in der Kommunikation zum Thema "Plattform". Wo beispielsweise eine SAP relativ klar beschreibt, was unter ihrer Plattform zu verstehen ist, hängt die Antwort auf die Frage nach der konkreten Plattform bei Microsoft mitunter davon ab wen man fragt. Zum Teil liegt dies auch daran, dass das Spektrum dessen, was Microsoft mit seinem Produktangebot abdeckt, extrem breit ist. Microsoft adressiert nicht nur Unternehmenskunden (Serverprodukte, CRM, ...), sondern auch Privatanwender (Money, ...), "Gamer" (XBox, ...), Nachfrager an Unterhaltungselektronik (Zune, ...), und viele mehr.
Doch was versteht Microsoft nun tatsächlich unter der Microsoft Plattform?
Der Plattform-Begriff
Doch zunächst die allgemeine Frage, wie der Plattform-Begriff definiert ist. Unter Wikipedia findet man folgende Definition:
"In der Informationstechnologie beschreibt Plattform eine Hard- oder Softwareumgebung, in der Anwendungssoftware ausgeführt werden kann. Typische Plattformen beinhalten eine Architektur, ein Betriebssystem oder Programmiersprache und deren Laufzeitbibliotheken" [Quelle: Wikipedia; frei übersetzt]
Der Begriff wird hier sehr weit gefasst. Mit Plattform kann demnach eine Hardwareumgebung, einem Betriebssystemumgebung, oder eine Systemsoftware-Umgebung etc. gemeint sein. Diese Mehrdeutigkeit führt auch in der Microsoft-Welt dazu, dass verschiedene Dinge als Plattform bezeichnet werden. Steve Guggenheimer, General Manager, Application Platform & Development Marketing Division, hat vor einiger Zeit einen interessanten Vortrag, gehalten, in dem er eine Reihe konkreter Plattformen aufgeführt hat. Folgendes Schaubild gibt einen Überblick über diese Plattformen und deren Einbettung in die Gesamtplattform.
Abbildung 1: Die Microsoft Plattform
Die Microsoft Plattform ist hierbei die Obermenge über den hier aufgeführten Unterplattformen.
Die Windows Plattform
Microsoft ist ein Softwareunternehmen. Auch die im Produktportfolio enthaltene Hardware (Xbox, Zune, ...) ist vom Programmiererseite nur über eine Softwareschicht ansprechbar. Über der Hardwareplattform liegt mit der Windows Plattform eine Software, die von der zu Grunde liegenden Hardware abstrahiert. Dieser Plattform sind Produkte wie Windows Vista, Windows Server, Windows Mobile, ... enthalten.
.NET Plattform
Die .NET Plattform stellt ein Sonderfall dar. Sie selbst unmittelbar auf die Windows Plattform auf, und ist Kernbestandteil aller Funktions-, Entwicklungs- und Management-Plattformen der Application Plattform. .NET stellt hierbei das Grundgerüst in Form von Basisklassenbibliotheken (.NET Class Library), Werkzeugen (Visual Studio) und der Laufzeitumgebung (Common Language Runtime, CLR). Die anderen Plattformen erweitern diese Bereiche um jeweils spezifische Klassen, zusätzliche Werkzeuge (SDKs). Gemeinsam bleibt die Laufzeitumgebung.
Application Platform
Auf der .NET Plattform setzt die Application Plattform auf, die mit ihren Funktionspattformen, Management- und Entwicklungs-Plattformen die Entwicklung und den Betrieb leistungsfähiger Softwaresysteme ermöglicht. Folgende Funktionsplattformen sind enthalten:
- User Experience Plattform
- Office Plattform
- Business Intelligence (BI) Plattform
- SOA / BPM Plattform
- Data Management Plattform
Daneben gibt es noch die
- Development Plattform
- Management Plattform
Office Plattform
An dieser Stelle möchte ich die Officeplattform herausstellen. Microsoft positioniert Office nicht mehr nur als Sammlung verschiedener Büroanwendungen, sondern als Plattform für die Entwicklung leistungsfähiger Geschäftslösungen. Anwendungen Sie auf dieser Plattform entwickelt wurden und eine Brücke schlagen zwischen den bekannten Office Client- und Serveranwendungen und Backend-Systemen werden als Office Business Applications bezeichnet.
Weitere Informationen
Die kleinen Helferlein, die in Microsoft Vista eingeführt wurden und nun defaultmäßig am rechten Bildschirmrand ihr Dasein fristen, sind - meiner Meinung nach - ein äußerst unterschätztes Werkzeug im Rahmen der Desktop-Anwendungsentwicklung.
Technischer Überblick
Vista Gadgets sind kleine, HTML-basierte, als ZIP-Datei verpackte Projekte, die in der Vista Sidebar installiert werden. Minimaler Inhalt der ZIP-Dateien ist
- Manifest-Datei (gadget.xml) - diese Datei beschreibt das Grundgerüst eines Gadgets, d.h. Verweise auf die Startdatei des Gadgets, Icons für die Installationsdialoge etc.
- Gadget (z.B. gadget.html) - diese Datei beschreibt die Anzeige des Gadgets. Die Sidebar-Umgebung sorgt dafür, dass das HTML korrekt in der Sidebar angezeigt wird.
Zusätzlich können noch folgende Dateien enthalten sein
- Settings (z.B. settings.html) - diese enthält die Beschreibung zur Darstellung des Optionen-Dialogs zum Gadget
- Flyout (z.B. flyout.html) - diese Seite wird angezeigt, wenn das Gadget aus der Sidebar gezogen und auf dem Desktop abgelegt wird.
- alle weiteren Dateien, die für die Anzeige benötigt werden (z.B. Bilder, weitere HTML-Seiten)
Ein guter Einstieg ergibt sich (neben der Lektüre unten angegebener Internet-Ressourcen), wenn man eine vorliegende Gadget-Datei (Endung .gadget) einfach in eine ZIP-Datei (Änderung der Erweiterung auf .zip) ändert und dann mit einem beliebigen ZIP-Editor (z.B. WinZip) durchstöbert.
Anwendungslogik von Vista Gadgets
Wie oben zu sehen ist, bestehen Vista Gadgets aus ein paar Steuerdateien und HTML-Seiten (mit benötigten Inhaltsdateien wie Grafiken), die die Anzeige beschreiben. In einer Softwarelösung, die Vista Gadgets als Oberflächentechnologie einsetzt, kann Programmlogik auf zwei Arten enthalten sein:
- Programmlogik basierend auf JavaScript
Die benötigten JavaScript-Elemente können hier zusammen mit dem Gadget ausgeliefert werden. Wie gewohnt, kann das JavaScript in die HTML-Seiten eingebunden werden, oder in referenzierte Code-Dateien enthalten sein.
- Programmlogik basierend auf Webservices, die vom Gadget aufgerufen werden
Bei dieser Variante enthält das Gadget ebenfalls JavaScript. Dieses wird allerdings nur für die ereignisbasierte Steuerung (z.B. Reaktion auf ein Click-Event) und für Aufrufe der Webservices mit anschließender Verarbeitung der Rückgabewerte verwendet. Webservices stellen zusätzliche Geschäftslogik bereit.
Die Rolle im Rahmen von S+S
Vista Gadgets sind Bestandteil des "Software"-Teils im Rahmen von S+S. Für sie stellen sich Fragen der Bereitstellung (z.B. über eine Website), Installation etc. Der "Services"-Teil kann, wie der Name schon vermuten lässt, über Webservices implementiert werden, auf die von den Gadgets zugegriffen wird. Somit können S+S Lösungen unter Verwendung von Vista Sidebar Gadgets erstellt werden.
Weitere Informationen
Am Freitag vorletzter Woche (26.10.) war ich auf dem Microsoft MVP Open Day, einer Zusammenkunft von Microsofts Most Valuable Professionals (MVP). Dort kam ich mit einigen Vertretern ins Gespräch, und Thema war immer wieder Microsofts Software + Services Strategie, die doch noch viele Fragen aufwirft. Dies ist natürlich eine Herausforderung, wenn man das Thema Software + Services (S+S) auf der Fahne stehen hat.
Selbstverständlich gibt es Microsoft-intern jede Menge an Informationen zu S+S. Leider sind die meisten der Definitionen von S+S zu komplex, kompliziert und schwer jemandem vermittelbar, der in ein, zwei Sätzen wissen möchte, was S+S eigentlich ist. Deshalb möchte ich an dieser Stelle einen weiteren Versuch wagen, S+S zu definieren...
Was ist S+S?
Software + Services ist Microsofts Plattform-Strategie unter deren Dach sich sämtliche Produkte und Dienste von Microsoft vereinen und zusammen mit Technologien anderer Hersteller IT-Lösungen bestehend aus Client-, Server- und Service-Elementen ermöglichen.
S+S ist motiviert durch den Wunsch Kunden und Partnern Flexibilität bei Ihren IT-Lösungen zu ermöglichen und die Vorteile verschiedener IT-Konzepte wie Client-Server-Computing, Software-as-a-Service, Rich-Client-Software etc. in Kombination nutzbar zu machen. Denn keiner der genannten Ansätze hat sich für sich allein als der Beste und einzig Wahre herausgestellt. Und dies ist in Zukunft auch nicht zu erwarten. Bei Rich-Clients stellt sich das Deploymentproblem, Software-as-a-Service-Lösungen fallen häufig bei der User Experience ins Hintertreffen.
Die Liste der Probleme verschiedener IT-Ansätze ließe sich leicht weiterführen. Warum sich aber nicht einfach auf die Vorteile der Ansätze konzentrieren und die verschiedenen Konzepte vereinen? Warum nicht eine Lösung erstellen, die aus einem schicken Rich-Client besteht, der Daten auf einem Unternehmensserver ablegt und Software-Aktualisierungen über einen im Internet angebotenen Service bezieht? Genau dies ist die Idee von Software + Services. Das Beste aus verschiedenen IT-Konzepten zusammen zu bringen.
Microsoft arbeitet mit Hochdruck daran, noch Vieles an Informationen bereitzustellen und Antworten auf Fragen wie die Folgenden zu geben...
- Was bedeutet S+S für Entwickler, Integratoren, ... ?
- Wird Microsoft Konkurrenz zu Service-Anbietern?
- Was heißt das alles für Software-Architekten?
Ich werde daran arbeiten, Antworten auf derartige Fragen hier zu geben bzw. auf entsprechende Informationsquellen zu verweisen.
Haben Sie weitere Fragen und Anregungen zum Thema "Software + Services"? Zögern Sie nicht, diese hier zu stellen :-)
So, nachdem ich mich in den letzten Wochen fast ausschließlich mit der Projektleitung der Xtopia beschäftigt habe, kann ich - nachdem das Event nun vorbei ist - einen kurzen Rückblick vornehmen und auch einen Ausblick auf meine künftigen Aktivitäten wagen.
Zurückblickend...
war die Xtopia wirklich ein Erfolg. Die Keynote hatte mit 135 Minuten zwar eine stattliche Länge, allerdings gab's darin ein Feuerwerk von interessanten Sprechern, Demos und Showcases zu bestaunen. Das Video ist jetzt übrigens auf der Xtopia-Website zugreifbar. Auch die folgenden Vorträge und Workshops waren gut besucht, was auch der Qualität von Sprechern und Inhalten zu verdanken ist. Feedback von Teilnehmern bestätigt diesen Eindruck.
Vorausschauend...
kann ich sagen, dass ich mich jetzt freue, mich wieder mit Themen von Software-Architekten beschäftigen zu können. In Kürze folgen hier Artikel zu meinen Schwerpunktthemen:
- Office Business Applikationen
- Software + Services Strategie von Microsoft
So, stay tuned... !!!
Nachdem wir doch einiges an, sagen wir, "konstruktiv-kritischem" Feedback zur alten Website bekommen hatten, gingen wir das Thema "Relaunch der Xtopia Website" an. Et voilà: da ist sie nun, unter http://www.xtopia.de/ zu bewundern.
Übersichtlicher, klarer strukturiert, Einsatz von Silverlight, und, und, und, ...
Unbedingt ansehen und am besten auch gleich anmelden. Denn die Veranstaltung wird mit Ihren illustren Speakern, dem state-of-the-art Content und dem Rahmenprogramm ein wahrer Leckerbissen für alle, die sich für Silverlight, Web 2.0, neue Geschäftsmodelle usw. interessieren.
Also gleich durchstarten unter www.xtopia.de.
Für alle, die neu im Thema Office Business Applications (OBA) sind, und sich einen Überblick verschaffen wollen, gibt es auf MSDN zwei schöne Überblicksdokumente. Diese können über den URL
http://msdn2.microsoft.com/en-us/library/bb614539.aspx
aufgerufen werden. Über diese Seite gelangt man auf die Dokumente
Dort werden dann Grundlagen zu Office Business Applications beschrieben.
Anfang der Woche hat Microsoft eine weitere Referenzanwendung aus der Office Business Application (OBA) Initiative veröffentlicht. Es handelt sich um eine Beispielanwendung, die Anforderungen eines fiktiven Öl- und Gasversorgers im Bereich der Kraftwerkssteuerung und -überwachung abdeckt.
Folgende Technologien kommen bei der Anwendung unter anderem zum Einsatz:
- Microsoft Office SharePoint Server 2007
- Excel 2007 und Excel Services
- Microsoft Performance Point Monitoring Server 2007
- InfoPath Forms Services
- SQL Server Analysis Services
- SilverLight 1.1 Alpha
Damit können also nicht nur Business Intelligence (BI) Szenarien demonstriert werden, sondern auch neue Formen der Oberflächengestaltung von Web-Anwendungen über SilverLight.
Die Referenzanwendung kann über folgenden Link heruntergeladen werden:
http://msdn2.microsoft.com/en-us/architecture/bb643797.aspx
Die Seite enthält
- Präsentationen mit Beschreibungen der Anwendung
- Demo-Szenarien
- Videos, die einzelne Szenarien veranschaulichen
- Ein VPC-Image, das die Anwendung enthält
Für alle, die einen kompakten Überblick über Silverlight suchen, sei der Blog von Jens-Peter Kleinau empfohlen. Er beschreibt darin kurz und bündig, was Silverlight eigentlich ist und wie es sich von Adobe Flash unterscheidet. Sehr interessant zu lesen.
Und natürlich für jeden Silverlight-Interessierten hier nochmals der Hinweis auf die Xtopia, Microsofts Web-Konferenz im Oktober in Berlin. Da gibt's jede Menge Vorträge und Aussteller zum Thema Silverlight und als Sahnehäubchen für jeden Teilnehmer ein Softwarepaket als Give-Away.
