Erfahrungen beim Einsatz von BPEL 10.1.x

NetworkedAssets GmbH
Erfahrungen beim Einsatz von BPEL 10.1.x
DOAG SIG SOA 29. September 2009
Diese Folien
•  Sind ein nostalgischer Rückblick, vor
dem Umstieg auf 11g
•  Beschreiben 4 Jahre Erfahrungen mit
BPEL im produktiven Einsatz
2
NetworkedAssets GmbH
29. September 2009, Berlin
Kleine Chronologie
„In the Beginning...“
•  12/2000 – Gründung von Collaxa „The Application is the
Orchestration“
•  2003 – Internet bei „Kabel Berlin-Brandenburg“ (3000
Subscriber), Abbildung OSS Prozesse in JAVA, BPEL wird zur
Standardisierung bei OASIS eingereicht
•  06/2004 – Oracle kauft Collaxa, BPEL4WS Orchestration Server
-> BPEL Process Manager
•  2005 – Telefonie bei KDG (ca. 80.000 Internet Subscriber),
September/August Beginn BPEL Projekt
•  01/2006 Umstellung erster Prozesse von Java Klassen auf
BPEL
3
NetworkedAssets GmbH
29. September 2009, Berlin
Warum BPEL
„Zum ersten Mal steht mit BPEL eine standardisierte, ablauffähige
Beschreibungssprache für Prozesse zur Verfügung, die von vielen
Herstellern unterstützt wird. Dies allein lässt einen neuen
Produktivitätsschub in der IT analog zu SQL vor 25 Jahren
erwarten. [...] Damit lässt sich die Komplexität von Projekten der
Prozessintegration besser beherrschen und die Umsetzungs- und
Betriebskosten können dadurch dramatisch reduziert werden“
„BPEL, das SQL der Prozesse“, Michael Stapf (Oracle), JAVASPEKTRUM 01/2005
4
NetworkedAssets GmbH
29. September 2009, Berlin
O-Ton Projekt (02/2006)
• 
Offener Standard und weitgehend Herstellerunabhängig
• 
Kann auf bestehenden Service-Backbone zugreifen
• 
Migration vorhandener Services kann je nach Bedarf erfolgen
• 
Prozessgestaltung auf einer höheren Abstraktionsstufe als Quellcode
• 
Verlagerung der Prozessimplementierung von der Softwareentwicklung zur
modellgetriebener Prozessgestaltung aufbauend auf vorhandenen Services
• 
Skalierbarkeit, Verfügbarkeit und Support von Geschäftsprozessen durch
Standardprodukt besser
• 
Bessere Möglichkeiten für Monitoring von Prozessen
5
NetworkedAssets GmbH
29. September 2009, Berlin
Von Java zu BPEL
Januar 2006
6
NetworkedAssets GmbH
29. September 2009, Berlin
Von Java zu BPEL
Januar 2006
7
NetworkedAssets GmbH
29. September 2009, Berlin
Von Java zu BPEL
Januar 2006
8
NetworkedAssets GmbH
29. September 2009, Berlin
Erste (SOLL) Konfiguration
2006
9
NetworkedAssets GmbH
29. September 2009, Berlin
O-Ton Projekt (02/2006)
Erste Erfahrungen
• 
Stabile und intuitive Umgebung für Erstellung von BPEL-Prozessen
• 
Stabiler Server und Umgebung
• 
Sehr gute Dokumentation seit Sommer 2005
• 
Sehr gute Unterstützung des Oracle-Teams
• 
BPEL-Prozesse gute Grundlage für Diskussionen mit Fachabteilungen
• 
Stellenweise Schwierigkeiten bei der Interoperabilität mit anderen
technischen Abteilungen (Stichwort: RPC-Encoding)
• 
BPEL-Ansatz kann zu generisch sein
• 
Performance-Probleme bei größeren Prozessen
10
NetworkedAssets GmbH
29. September 2009, Berlin
Und noch ein O-TON
Nachtragsposting (Feb. 2006): Die Oracle BPEL Werkzeuge machen alle
einen sehr guten Eindruck. Zum produktiven Einsatz ist allerdings dringend
die Kopplung mit einem ESB nötig. Die Marketing-Aussage dazu ist nicht
schwer zu finden: „Wir haben schon einen ESB.“ Aber was bedeutet das
technisch? Sollte wirklich Interconnect zum ESB umgelabelt werden? Wird
das die zu lösenden Probleme korrekt addressieren?
Torsten Winterberg, Opitz Consulting
http://torstenwinterberg.blogspot.com/2006/07/oracle-bpel-und-oracle-esb.html
11
NetworkedAssets GmbH
29. September 2009, Berlin
Stand heute (09/2009)
• 
1.000.000+ Subscriber (Internet, Telefonie und
Mehrwertdienste)
• 
Millionen Prozessinstanzen am Tag
• 
Schnittstellen zu BSS Systemen (zehntausende Calls am Tag)
• 
Services für Graphische Nutzeroberfläche mit 2000+ Usern
• 
Interfaces für Reseller
• 
SNMP als Endpunkt (Millionen von Events von Kabelmodems und
Netzelementen)
• 
50+ individuelle Endpunke
• 
Re-Design in Progress
12
NetworkedAssets GmbH
29. September 2009, Berlin
GrößteProbleme
• 
Zusammenspiel mit OC4J und ESB (insbesondere in 10.1.2), mangelnder
Linux Support (BAM)
• 
Vorlauf durch Kinderkrankheiten erheblich. Bug Reporting und –Beseitigung
teilweise sehr zäh und aufwändig im Vergleich zum Workaround (trotzdem
sehr ordentliche Bugliste).
• 
Performance ist nach wie vor kritisch, insbesondere bei Event getriebenen
Prozessen
• 
Installation „out of the box“ – auch nach Oracle Anleitung – funktioniert nur
bedingt. Erhebliches Feintuning auf Basis von Erfahrung notwendig,
insbesondere beim Thema Timeouts.
• 
Thread Problematik und Domains, bei komplexen Prozessen, insbesondere
wenn mehrere Prozesse interferieren.
13
NetworkedAssets GmbH
29. September 2009, Berlin
Noch mehr Probleme
• 
Getrennte Konsolen für BPEL Process Manager und andere
Komponenten als Betriebshindernis.
• 
BPEL kaum Werkzeug zur Diskussion mit der
Fachabteilung.
• 
Feintuning der Datenbank unabdingbar
• 
Konsole ab zehntausend Prozessinstanzen sinnlos
• 
Cluster unter OC4J war immer problematisch und im
nachhinein betrachtet wäre Weblogic die bessere Wahl
gewesen.
14
NetworkedAssets GmbH
29. September 2009, Berlin
Und: JDeveloper
• 
Graphik ist nicht nur ein Vorteil: nach dem 1000sten Wizard/Icon würde
man gerne auch mal skripten.
• 
Eclipse Support war seinerzeit versprochen und war ein Grund der
Einführung, Bis heute ein echter Mangel.
• 
Refactoring und Deployment einer der größten Pferdefüsse von JDevloper:
Refactoring by Copy and Paste.
• 
Kein Programmierwerkzeug (für Programmierer)
• 
BPEL alleine reicht oft nicht. Man braucht bei komplexeren technischen
Prozessen Java. Dann entfällt aber die Kompatibilität zum Standard
(sowohl BPEL als auch BPMN), zumindest wird es deutlich holpriger.
15
NetworkedAssets GmbH
29. September 2009, Berlin
Nil nisi bene...
• 
Graphischer Audit vorteilhaft
• 
Sehr schnell zu einer Webservicearchitektur
• 
Ich bin flexibler
• 
Asynchronität für eventbasierte Architekturen sehr spannend, bis ich dann
unter 500.000 den einen fehlgeschlagenen Prozess suchen muß. (Audit
funktioniert dann aufgrund des Datenvolumens nicht mehr).
Fazit: Flexibilität wird teuer erkauft, wenn man sie nicht braucht.
16
NetworkedAssets GmbH
29. September 2009, Berlin
Die Zukunft?
• 
Forward Engineering vom Geschäftsprozess zur Ausführung
ist immer noch eine (ungelöste) Herausforderung
• 
BPMN als Standard für die Modellierung? (So BEA „The
2008 State of the BPM Market“, Whitepaper)
• 
Performance von Composites noch zu prüfen.
17
NetworkedAssets GmbH
29. September 2009, Berlin