Sunato ist Microsoft Partner im Bereich ‚Application Integration‘

IT-Systeme sind schon längst keine Insellösungen mehr. IT-Systeme in Unternehmen sind bis auf wenige Ausnahmen nicht autark,  sondern mit anderen Systemen verbunden und bilden darüber erst ihren Mehrwert. Es existieren Technologien wie der Microsoft BizTalk Server oder Windows Azure AppFabric, die das Verbinden bzw. das Integrieren von IT-Systemen ermöglichen. Die besondere Herausforderung bei einem solchen Vorhaben ist, die richtige Technologie bzw. die richtige Mischung von Technologien zu bestimmen und diese optimal anzuwenden.  Genau dieser Herausforderung stellen wir uns bei der Sunato GmbH täglich. Durch unser Knowhow verbinden wir IT-Systeme und gehen sogar einen Schritt weiter, indem wir die technische Anbindung von Mitarbeitern an die Unternehmensprozesse z.B. durch mobile Apps gestalten.

Unser Motto lautet deshalb auch einfach intelligent verbunden.

Für uns ist es selbstverständlich, dass wir in der aktuellen Rolle ständig unsere Kompetenzen und unser Wissen ausbauen. Wir freuen uns daher besonders über die erfolgreiche Microsoft Partner Zertifizierung im entsprechenden Bereich Application Integration! 

Windows Phone 7 als Enterprise und B2B Lösung für mobile Prozesse: App Deployment im Enterprise Kontext

Nachdem die modernen mobilen Plattformen wie z.B. Windows Phone 7 im Consumer Markt ihren festen Platz gefunden haben, ist die Zeit für den nächsten logischen Schritt reif geworden. Das Thema Mobile Enterprise ist auf dem Vormarsch und wird die künftigen Entwicklungen in dem Mobile Segment deutlich beeinflussen. Viele Unternehmen haben das Potenzial von Mobile Enterprise frühzeitig erkannt und realisieren Enterprise Apps. Dennoch stellt sich die Frage, wie gut die heutigen mobilen Plattformen, die ursprünglich auf den Consumer Mark zugeschnitten wurden, die Enterprise Anforderungen abdecken können.

In diesem Beitrag geben wir einen Ausblick zum Thema App Deployment (Verteilen vom mobilen Lösungen)  im Enterpreise Kontext mit Schwerpunkt Microsoft Windows Phone 7.

Die Anforderungen an das App Deployment im Enterprise Kontext sind klar: Unternehmen möchten Ihre Enterprise Apps durch Auswahl geeigneter Deployment Mechanismen verteilen, kontrollieren, automatisch updaten und ggf. zurückziehen. Das Deployment muss bestimmte Unternehmensrichtlinien wie z.B. Privacy und Security erfüllen.

App Deployment bei Microsoft Windows Phone 7

Abbildung 1: App Deployment bei Microsoft Windows Phone 7

Die Plattform Microsoft Windows Phone 7 bietet aktuell nur ein einziges Deployment Mechanismus an -  das zentrale und öffentliche App Deployment über den Marketplace.  Auf den ersten Blick scheint dieses Mechanismus, die oben erwähnten Anforderungen an ein App Deployment im Enterprise Kontext nicht erfüllen zu können. Dennoch der erste Blick täuscht!  

Lösungsszenario App Login Prozess

Abbildung 2: Lösungsszenario App Login Prozess

Als Lösung in diesem Szenario implementieren wir bei unseren Apps eigene Benutzer Login Prozesse. Auf diesem Wege haben die Unternehmen trotz der Offenheit des Marketplace die Möglichkeiten, Anforderungen an das Deployment und den Einsatz der mobilen Applikationen wie Privacy und Security zu erfüllen und die Vorteile des öffentlichen Marketplace wie z.B. Deployment über die Unternehmensgrenzen hinaus zu bewahren.

Ein solcher Prozess muss sowohl auf der Seite der mobilen Applikation realisiert werden als auch im Backend implementiert werden. Um den Unternehmen bestmögliche Flexibilität zu ermöglichen, realisieren wir die Backend-Komponenten unter anderem auch als Cloud-Version auf Windows Azure.

Als nächsten Schritt Richtung Mobile Enterprise plant Microsoft die Einführung von zwei Neuerungen im Marketplace durch das Mango Update in den kommenden Monaten:

Private Deployment: Diese Neuerung ist für Unternehmen interessant, die Apps im Enterprise Kontext einsetzen oder einsetzen wollen. Apps die durch dieses Mechanismus verteilt werden, sind im öffentlichen Marketplace nicht sichtbar. Die Installation erfolgt über das Verteilen des so genannten Deeplinks zu der App. Auf dieser Wiese können nur Benutzer, die diesen Link erhalten haben, die App installieren. Diese Lösung wird eine gewisse “Privatspähre” den Unternehmen im Punkto Deployment geben, dennoch würden die Unternehmen auf eigene Login Prozesse nicht verzichten können, denn sollte der Deeplink abhanden gekommen sein, kann jeder, der den Link kennt, die App installieren.

Beta Deployment: Diese Neuerung ist aus unserer Sicht für alle App Hersteller interessant und würde die App Entwicklung deutlich verbessern. Apps die durch dieses Mechanismus verteilt werden, sind ähnlich wie beim Private Deployment im öffentlichen Marketplace nicht sichtbar. Der wesentliche Unterschied zum Private Deployment ist das Ziel des Beta Deployments: die Tests (also die Beta Tests) von Apps  sollen vereinfacht werden, indem die Tester Apps mittels Deeplinks aus dem Marketplace herunterladen können. Bis jetzt wurden Testversionen nur per direktes Verteilen vom Entwicklungsrechner auf das WP7-Gerät geladen, was nicht immer die beste Lösung ist, wenn z.B.  das Team verteilt ist, oder der Kunde sich weit weg befindet. Beim Beta Deployment können Apps auch ohne Zertifizierung zum Test bereitgestellt werden. Ein Beta Deployment wird zeitlich begrenzt sein.

Diese Neuerungen werden das Deployment und insbesondere den Enterprise Einsatz von Windows Phone 7 Apps noch attraktiver machen. Dadurch ist aber nicht die endgültige Ausbaustufe im Enterprise Kontext erreicht worden, sondern aus unserer Sicht nur der nächste notwendige Schritt in die richtige Richtung gemacht worden. Aus diesem Grund begleiten wir schon heute viele Kunden bei der Einführung von Windows Phone 7 als Enterprise und B2B Lösung für mobile Prozesse im Unternehmen. Wenn auch Sie Interesse daran haben, nehmen Sie mit uns Kontakt auf.

Was kostet der Betrieb von Windows Azure AppFabric – Berechnung der laufenden Kosten, Bestimmung der benutzten Verbindungen

Die Cloud-Lösung von Microsoft – Windows Azure AppFabric ermöglicht neue Integrationsszenarien insbesondere im Enterprise Kontext. Das Kostenmodell erscheint auf dem ersten Blick einfach und klar. Es werden benutzte Verbindungen, Transaktionen zum Access Control und verursachter Datentransfer abgerechnet. Dabei von den genannten drei Komponenten ist die Anzahl der benutzen Verbindungen ausschlaggebend (s. Abbildung 1).

 

Abbildung 1: Windows Azure AppFabric Preismodell

Abbildung 1: Windows Azure AppFabric Preismodell

Aber wie sind die Betriebskosten im folgenden Fall zu ermitteln: Eine mobile Client Integration soll implementiert werden, indem 1000 Windows Phone 7 Geräte an einen Backend Service das Kunden über die Azure AppFabric angebunden werden. Die Clients verbinden sich mehrfach am Tag mit dem Backend, um gewisse Daten zu beziehen.

Welche Kosten würde dieses Szenario verursachen?

Die Frage nach dem verursachten Datentransfer wäre einfach zu klären und wird in diesem Beitrag nicht behandelt.

Wie sieht es aber mit der Anzahl der benutzten AppFabric Verbindungen aus? Werden in diesem Szenario 1000 oder sogar mehr Verbindungen abgerechnet? 1000 Verbindungen würden laut dem Preismodell  2×500 =1990 $ pro Monat kosten und sollte das der reale Betrag sein, muss dieser dem Auftraggeber gegenüber augmentiert werden.

So einfach, wie dies durch das oben vorgestellte Preismodell suggeriert wird, ist die Berechnung der Betriebskosten von Windows Azure AppFabric nicht.

Um die Frage nach den Betriebskosten beantworten zu können, müsste das Kostenmodell der Windows AppFabric verfeinert werden. Und tatsächlich, gibt es eine genauere Berechnungsvorlage von Microsoft für die Kostenermittlung im Punkt benutzte Verbindungen.  So ist diese durch den Hersteller definiert worden:

1) Es wird pro Tag abgerechnet: Jeder Monat wird in die Anzahl seiner Tage aufgeteilt und für jeden Tag wird die Nutzung der AppFabric bestimmt. Am Ende eines Monats werden die täglichen Nutzungsgebühren zusammen addiert.

2) Berechnung der Nutzung finden auf Basis von Messintervallen der Dauer von 5 Minuten: Die 24 Stunden eines Tages werden in Intervalle von 5 Minuten aufgeteilt und in diesen Intervallen wird gemessen. Somit ergeben sich 288 Messintervalle pro Tag. Die Dauer jeder Verbindung in dem Messintervall wird sekundengenau gemessen. Die gemessene Dauer wird durch 300 (5 Minuten x 60 Sekunden) geteilt. Am Ende eines Messintervalls wird die Summe der Messungen gebildet.

Hier ein Berechnungsbeispiel: Wir nehmen an, in einem Messintervall war eine Verbindung für 120 Sekunden und zwei weitere  für 60 Sekunden geöffnet.

Die Anzahl der Verbindungen ist: (1×120 + 2×60) / 300 = 0.8 für das gestammte Messintervall.

Für den aktuellen Tag wird der maximale Wert aller Messintervalle als Tagesnutzung definiert. 

3) Verbindungspakete und Einzelverbindungen: Nachdem die Nutzung pro Tag festgelegt wurde, wird bestimmt wie die ermittelte Anzahl genau abgerechnet werden soll. Dabei werden an erster Stelle die gebuchten Verbindungpakete in Betracht gezogen.

Wenn die Anzahl der benutzten Verbindungen die Anzahl der Verbindungen in dem jeweiligen Paket nicht übersteigt, dann wird der Paketpreis für den aktuellen Tag abgerechnet.  Wenn z.B. eine Verbindungsanzahl von 1.2 bei einem 5-er Paket ermittelt wurde, dann wird der Preis des 5-er Pakets berechnet.

Wenn die Anzahl der benutzten Verbindungen die Anzahl der Verbindungen in dem jeweiligen Paket übersteigt, dann wird der Paketpreis für die jeweilige Verbindungsanzahl berechnet.  Die restliche Verbindungen werden als einzelne betrachtet und mit dem Preis für einzelne Verbindungen (“pay-as-you-go”) abgerechnet. Wenn z.B. eine Verbindungsanzahl von 6 bei einem 5-er Paket ermittelt wurde, dann werden der Preis des 5-er Pakets und der Preis für eine einzelne Verbindung berechnet.  

Der oben beschriebene Preismodel kann aus unserer Sicht die Basis für Betriebskostenermittlung von Intergrationsszenarien mittels der Windows Azure AppFabric bilden. Zusätzlich sagt der Preismodel deutlich aus, dass der Einsatz der AppFabric in vielen Fällen nicht nur technologisch sondern auch betriebswirtschaftlich interessant sein kann

Wir hoffen mit diesem Beitrag für Sie mehr Klarheit im Bereich Windows Azure AppFabric geschafft zu haben. Wenn Sie sich mehr Unterstützung wünschen, sprechen Sie uns an – die Experten der Sunato GmbH beraten Sie gerne!

Mobile Client Integration im Enterprise Kontext am Beispiel von Windows Phone 7 und Windows Azure AppFabric

In einem Kundenprojekt wurde an uns die Aufgabe gestellt, Teile der im Unternehmen vorhandenen Intranet Services mit Smartphones nutzen zu können. Hier bieten sich klassisch zwei Wege an: Zugriff auf die Services von außen über Portfreigaben und der Zugriff über eine VPN Verbindung. Beide Lösungen sind nicht optimal und wir möchten Ihnen einen kurzen Einblick geben, wie wir eine Lösung implementiert haben und warum wir einen anderen, dritten Weg gegangen sind.

Die Portfreigabe als Lösung für das Szenario wird aus gutem Grunde seitens der Systemadministratoren mit einem kritischen Auge gesehen, schließlich sind all die Sicherheitsmaßnahmen nicht ohne Grund geschaffen worden. Eine weitere Sorge der Systemadministration ist die nachhaltige Pflege der Portfreigaben, die in vielen Fällen zu Sicherheitsrisiken führen kann. Viele Fragen der Sicherheit und Integrität müssen deshalb für jeden Dienst untersucht werden. Aus diesen Überlegungen haben wir schnell die Portfreigabe als Lösung verworfen.

Als zweite Alternative stand die Möglichkeit der VPN-Verbindung zur Verfügung. Diese Methode funktioniert schon seit Jahren, Fragen der Sicherheit und Integrität sind zentral gelöst und liegen nicht mehr in der Verantwortung der einzelnen Services. Nachteil ist, dass der Aufbau einer VPN-Verbindung eine bestimme Software (VPN-Client) auf dem Client voraussetzt. Für PC-Clients ist das heutzutage in der Regel kein Problem, bei mobilen Geräten (wie z.B. Smart Phones) ist oft solche Verbindungssoftware entweder nicht vorhanden oder die Auswahl stark begrenzt. Zusätzlich muss solch eine VPN-Verbindung-Software installiert, konfiguriert und gewartet werden, was einen zusätzlichen Aufwand pro Client bedeutet.

Als Ziel des Projektes wurde definiert, Windows Phone 7 Clients direkt an Intranet-Services anzubinden. Die Mitarbeiter des Unternehmens sollen die Möglichkeit erhalten, über Ihre Windows Phones an bestimmte Unternehmensdaten, welche über Web Services zur Verfügung gestellt werden, zuzugreifen. Der Zugriff soll auch außerhalb des Unternehmens (z.B. im Außendiensteisatz) weltweit möglich sein. Die Anbindung konnte weder per Portfreigabe noch per VPN erfolgen, da mit einer Portfreigabe interne IT-Richtlinien verletzen würden und es neben den bereits aufgeführten Gründen für den VPN Gateway keine entsprechende Verbindungssoftware für Windows Phone 7 Clients gibt.

 

Mobile Client Integration im Enterprise Kontext am Beispiel von Windows Phone 7 und Windows Azure AppFabric

Abbildung 1: Mobile Client Integration im Enterprise Kontext am Beispiel von Windows Phone 7 und Windows Azure AppFabric

 

Gelöst haben wir das Problem durch den Einsatz von Microsofts Cloud Lösung Windows Azure AppFabric. Die Windows Azure AppFabric dient als Cloud-basierter Enterprise Service Bus und bietet eine optimale Integration von WCF basierten Web Services an. Durch den Einsatz der Windows Azure AppFabric als „Biztalk in der Cloud“ konnten wir eine Domain bzw. netzwerkübergreifende Kommunikation implementieren und so völlig neue Integrationsszenarien (s. Abbildung 1) abbilden. Wir konnten so eine Lösung bieten, welche die gestellten Anforderung deckt und sogar perspektivisch den Zugriff von anderen mobilen Geräten (iOS, Android,…) möglich macht.

Haben Sie ähnliche Anforderungen, suchen Sie Unterstützung bei Ihren Projekten? Nehmen Sie mit uns Kontakt auf!