BPEL 2.0
(Torsten Winterberg, Sven Bernhardt, OPITZ Consulting)
Warum BPEL, was ist BPEL?
Fachlich definierte Prozesse in die IT übernehmen
BPEL als Abstraktionslayer zwischen Geschäftsprozess und Services
Process Layer zur Orchestrierung der Services
BPEL4WS KEIN STANDARD, nur eine Spezification…
Fragen:
BPEL 1.1 Interaktion mit „Menschen“
BPEL gut für langlaufende, zustandsbehaftete Prozesse
BPEL2.0 Erweiterung von WSDL 1.1
WSIF anschauen, damit kann man Java Classen wsdls zuweisen und somit lokale methoden aufrufen, wenn die Engine WSIF unterstützt.
Änderungen in BPEL 2.0
Neu:
Compensate -> Compensation Handler?
Unterscheidung von Fehlern einfacher möglich! Erweitertes Fault-Handling
Neue Elemente (Basic Activities)
– Rethrow (Fehler weiterreichen)
Compensate Scope, d.h. man kann nur einen Scope zurücknehmen
Validate (XSD Validierung?)
Extension Activity (Erweiterbarkeit durch Benutzer)
Structured Activities
Switch wird zu if
repeat until
for each (serielle und auch parallele ausführung)
Sonstiges:
<documentation>
<import>
<extensions>
PartnerLinks direkt im WSL File!
Data Handling:
– assign:
Validerung möglich
keepSourceElement, ignoremissingfromdata
bpel:doXslTransform()
– vereinfachter Variablenzugriff:
<variable messageType=“a:foo“ name=“FooVar“
<from>$FooVar.bar</from>
<fromParts>/<toParts>
Feinere Kontrolle der <catch> Konstrukte
terminationHandler
exitOnStandardFault
Abstrakte Prozesse?
Im Gegensatz zu ausführbaren Prozesse gibt es hier eine öffentliche Sichtweise (keine Blackbox). Prozesse sind nicht ausführbar! Somit kann die Geschäftslogik verborgen bleiben. Templates
Stand Workflow Erweiterung
BPEL 1.1 keine menschliche Benutzerapplikation!
In BPEL 2.0 immer noch nicht berücksichtigt…
BPEL4People
Machen es aber mit dem Arbeitsliste Pattern, also genauso wie ich
Tools für BPEL 2.0
Active Endpoints ist zertifiziert für BPEl 2.0
Active BPEL Designer ist kostenlos für Eclipse 3.2 (Unbedingt mal reinschauen! Evtl. die Prozesse im AT neu designen und erweitertes Faulthandling einbauen)
BPELets (Häufig gebrauchte Aktiviätskombinationen)
WebReferences (WSDL Files, XSDs)
Kein WSIF Support!
Aber Java Klassen können angesteuert werden!!
Migration von 1.1 auf 2.0
Im BPEL Designer automatisiert:
Syntaxkonvertierung
Konvertierung von Variablenzugriffen
Modifizierung von catch aktivitäten
konvertierung event handler
Bewertung:
Neuerungen:
Abstrakte Prozesse (Best Practices definieren)
Bessere Dokumentationsmöglichkeiten
Variablen: Übersichtlicherer Sourcecode durch XPath und XSLT
Exceptionhandling einfacher
Feinschliff von BPEL 1.1
Business Activity Monitoring (BAM)
Benutzerinteraktion:
Eigener Workflow Service (so wie ich)
Transaktionen über Web-Services -> Compensation Handler sehr kompliziert
WS-Transaction von Oracle unterstützt.
REST: Java Call gegen den REST Service
Referent:
dierk.koenig@canoo.com
Autor von Groovy in Action
Sehr großes Interesse, Umzug in Halle 1
Groovy ist „feature rich“ und Java-friendly
Problem bei anderen Skriptsprachen:
statische typisierung notwendig um Java friendly zu sein
feature-rich meistens nur dynamische Typisierung
Groovy „optionale Typisierung“
Scripting patterns:
Weiches Herz, Alleskleber
Groovy verknüpft Infrastruktur und Anwendungslogik
Dynanische Programmierung:
Zur Laufzeit Eigenschaften und Fähigkeiten zur Laufzeit dynamisch hinzufügen und ändern
Bsp.: Neue Funktionalität (regex) zu java.land.String dynamisch hinzufügen
Methodenaufrufe abgreifen
Hello World ohne Klasse!
Bsp:
System.out.println(„Hello World“);
->?.size()
println“Hello World“
Typ optional
def vorname=“Christian“
println „$vorname, Wieland“ GString
„““ hallo
„““ String über mehrere Zeilen
assert 0.5 == 1/2 BigDecimal.equals
optionales duck typing
print obj?.size() sage dereferencing (== null)
Regex
if („Hello World!“ =~ /Hello/)
Listen, Maps, Ranges
voll = [1,2,’JAX‘]
voll[0..1] = [0,1,2,3]
Maps
del voll = [a: 1. b: 2]
Closures
Anonyme Inner Classes
3.times{println ‚Hi‘}
new File(‚/data.txt‘).eachLine{print it}
def Houston(Closure machwas){
…
}
class Dir{
String name
List dirs
}
-> alle getter setter und konstruktoren
werden „automatisch erzeugt“
->Dir.methods.name.gret(/(g/s)/)
assert root.dirs[0].name == ‚a‘
assert root.dirs.name == [‚a‘,’b‘]
Builder Pattern
Kontrollstrukturen
Live Demo
Groovy Flickr client
swing = new groovy.swing.Swingbuilder()
dynamisch variablen hinzufügen Beispiel count++ , später count mit 0 initialisieren
Integrationsoptionen:
Groovy Objekte sind Java Objekte
GroovyClassLoader
GRAILs anschauen
Tools: unterstützung von Groovy in Eclipse vorhanden
http://www.infoq.com -> frei verfügbares Buch : getting started with grails
Groovy ist wegen dem Konzept immer langsamer als Java
Links:
groovy.codehaus.org
grails.org
svenhaiges.de
Groovy hat den JAX-Innovation Award gewonnen!
Bedeutung von Bedeutung
Semiotisches Dreieck
Bedeutung eines sprachlichen Zeichen ist das was man sich im Kopf vorstellt?
Alles kann man sich allerdings nicht vorstellen
Kontexttheorien:
Ein sprachliches Zeichen erhält seine Bedeutung erst im Kontext
Chomsky: Urgrammatik
Bedeutung eines Satzes läßt sich nicht aus der Grammatik ableiten
Theorie:Spracherwerb ein Spielin einer Sprachgemeinschaft?
Ordinary Language Philosophy
Ontologie:Lehre des Seins
Meta: Zwischen, nicht über!
Kant: Erst der menschliche Verstand erzeugt ein „Ding“.
Systemtheorie: Dinge und Eigenschaften unzertrennbar miteinander verbunden.
Dinge haben Wechselwirkungen -> Systemtheorie
Beschreibungslogik:
Wie kann man Wissen beschreiben?
Konzepte und Rollen zwischen den Konzepten
Schlussfolgerung möglich
Wissensbasis
Beschreibungslogik Attributive Language
RDFs
OWL
Concepts:
- Not a single line of xml.
- Convention over Configuration
- Instant feedback
- Scaffolding (Gerüst)
- Testing right in the Framework
- DRY (Don’t repeat yourself) (e.g. Database->Models)
- AJAX, REST Support
- Opinionated Software
- Parts
- „ActiveRecord“
DRY O/R mapping framework - ActionPack
View via templates
Controller (Routing, Caching, manages helper modules, sessions)
Building a rails application:
- Scaffolding
- Generate a model
Every Object has a method „methodMissing“ and Active Record uses this to support DRY
Rails URI
/product/show
/controller/action
„Scaffolding just holds the other stuff up until you can replace it.“
DB Changes are instantly picked up, even if you change those in sql explorer or other tools
Rails is a DSL (Domain specific language)
I18N not really available yet
Scaffolding dynamic or static(user customizable)
View Temmplates (Mix of HTML and Ruby)
ActiveRecord Realtionsships
ActiveRecord is the largest part of Rails
Tests:
unit, functional, integration
on db or fixtures(db is setup like the fixture sets before every test)
JRuby
Rails integration plugin in ruby installieren
ActiveRecord Bridge
Book:
Rails for Java Developers
Referent:
nealford.com
memeagora.blogspot.com
OpenSource
http://glassfish.dev.java.net
http://glassfishwiki.org
http://blogs.sun.com/theaquarium
Features:
100% JEE5
IDE Integration mit Netbeans und Eclipse WTP
Möglichkeiten für (Installations-)Profile Bsp: Entwickler, AppServer
Umfangreicher Web-Services-Stack
Eigener HTTP Connector, sehr performant, asynchrone Request Verarbeitung usw.
- JBI
- JMX
- CallFlow Monitoring-Performance Analyse
Für Admins:
Web GUI (mit Woodstock GUI Framework programmiert)
asadmin: Kommandozeilen Tool
Clustering Möglichkeiten
Domäne:
Gruppierung von Instanzen, die logisch zusammneghören
Domain Administration Server : Nur für Administration. Instanzen laufen eigenständig
Hochverfügbarkeit:
Load Balancing: Skalierung und Erkennen von Ausfällen einzelner Server
Failover Logik
Session Persistenz und Verteilung im Cluster
Glassfish bietet
Load Balancing: HTTP, RMI/IIOP, KMS/MQ
Failover Szenarien: Instanz Failover, Session Failover
HTTPS Loadbalancing:
HW Loadbalancer
Einsatz von Web Server Plugins
Plugins für Apache 2 MS IIS und Sun Web Server
LB Plugin von Glassfish sehr featurreich
mit asadmin kann man cluster konfigurieren und durch einen befehl hochfahren
Session Replication im Speicher oder in DB möglich
Web Services Stack
JAX-WS FastInfoSet (Binärdatenübertragung)
http://wsit-docs.dev.java.net/releases
Umfangreiches Monitoring (Performance Daten)
WS-Interoperability Kit mit M$
FastInfoSet binär Encoding von XML Daten
5x schneller als reine XML ÜBertragung
Ressource Management Bsp. wieviel Prozent der Workerthreads darf eine Anwendung haben
Managment Rules
Bsp.: Nachrichten bei bestimmten Server Events (deployte MBeans) evtl. auch für Watchdogs
Call Flow Monitoring
Analyse von Client Request…wo hängt mein Request momentan? In welcher Schicht?
Comet Support:
Web 2.0 Server Push Applikationen
-> Asynchrones Request Processing
Portal Projekt von Glassfish
http://portal.dev.java.net
Portlet Container
Nicht als Portalserver gedacht, nur zum Testen
SSO Support -> openSSO
http://opensso.dev.java.net
SSO mit anderen Systemen über Agenten!
OPEN-ESB
BPEL 2 Engine integriert!
JBI
PHOBOS
http://phobos.dev.java.net
ServerSideScripting für Java
Referent
http://blogs.sun.com/dadelhardt
Neue Konzepte in AXIS 2:
Flows, Phasen, Module
WS-* Standards sehr unübersichtlich
Axis bringt nur eigentlich nur die Grundfunktionalitäten mit.
Läßt sich aber sehr einfach erweitern durch Plugins(Module) usw. (Baukastenprinzip)
WS-Framework der 3. Generation?
ca. 2006 wurden sehr viele Standards verabschiedet, daher auch die Notwendigkeit, neue Frameworks zu entwickeln
Wichtigste Änderungen:
MEP (Message Exchange Pattern, bsp. 3 mal request, dann erst ein response), echte asynchronität
Dynamische Handlerketten
FLOWS
Axis Engine -> Pipeline
Handlerkette werden seriell aufgerugen. Kette unterteilt in Phasen.
4 Flows:
InFlow
OutFlow
InFaultFlow (Definition, was passieren soll, wenn ein Fehler aufgetreten ist)
OutFaultFlow
Interne Verarbeitung:
AxisServlet
AxisEngine (Inflow – Handler)
Neu: MessageReceiver -> WebService
AxisEngine (Outflow)
ES MUSS gar keine Antwort mehr geben, sehr fexible, bsp. 3 inflows, 2 outflow
WebService muss nicht in Java geschrieben werden!
Auf Client Seite genau die gleichen Möglichkeiten , inkl. handlerketten usw.
OperationKontext solange „am Leben“ bis die Response da ist.
Einwegkommunikation: HTTP Protokoll, keine Response, wird ein HTTP 202 gesendet
Unterscheidung zwischen Global Flows und Service Flows
In Axis 1.x nur statische Handlerketten.
PHASEN
Menge logisch zusammengehöriger Handler
Reihenfolge der vordefinierten Phasen festgelegt, die Handlerreihenfolge innerhalb den Phasen kann jedoch angepasst werden.
Standard Phasen: Transport, Security, PreDispatch, Dispatch
Benutzerdefinierte Phasen:
Können beim InFlow nur ans Ende gesetzt werden
Beim Outflow am anfang
Definition eines Handlers
<handler name=“testHandler“ class=“net.bla.axishandler“><order/></handler>
Interface Handler ableiten von AbstractHandler
init(HandlerDescription) – vor dem Handler
cleanup() – wenn der Handler fertig ist (Wird aber nicht aufgerufen!!)
invoke(MessageContext mc)
-> Kann AxisFault werfen
AxisFault viel flexibler-> selbst wenn ein Fehler geworfen wird kann weitergearbeitet werden. Außerdem könnte man auch die Verarbeitung abbrechen.
MODULE
Modul gruppiert eine Menge von Handlern (Bsp. WS-Security, WS-Adressing, Logger) ((m)jar-Dateien)
Module können bis auf eine Operation herunter ein und ausgeschaltet werden.
Konfigurierbar über
Axis2 HTML Frontend! axis2-admin -> Konfiguration flüchtig!
Service Archive hochladen
Zur Laufzeit Module verknüpfen
Bsp.: WS-Policy (welche Features unterstützt der Service (nicht funktionale Aspekte eines Services, z.b. Verschlüsselung))
Vorteil Services können aushandeln, welche Module benötigt werden zur Kommunikation…
Module implementieren
Interface Module
Deployment: Kopieren der mar Datei in den Module Ordner der Web-Anwendung
!Versionierungkonzept für Module! Durch Classloader
Handler müssen ThreadSafe programmiert sein!
services.xml (neues wsdd)
Module können auch anderen Services beliebige Operationen hinzufügen
D.h. alle WebServices können dann automatisch Standardoperationen erhalten
Fazit:
Handlerkonzept sehr stark erweitert
Phasen, Module sehr mächtig
Bestehende Anwenungen sehr einfach erweiterbar
Zukunft: JAX-WS, Annotations
REST steht für REpresentational State Transfer. Der Referent (Stefan Tilkov – Blog) meint, dieser komplizierte Name könnte einer der Gründe sein, warum sich REST bis jetzt noch nicht durchgestetzt hat. Dem kann ich nicht unbedingt zustimmen. Je komplizierter die Abkürzung, desto größer ist ja normalerweise der Hype, der um eine Technologie gemacht wird.
REST beschreibt eigentlich einfach nur das HTTP, d.h. HTTP ist eine Implementierung von REST.
Das Prinzip wurde in der Dissertation von Roy Fielding, einem der HTTP-Väter, beschrieben. Man solle sich diese Mal durchlesen, weil sie für eine Dissertation sehr verständlich geschrieben sei.
Die Kernprinzipien von Rest sind folgende:
- Identifizierbare Ressourcen
Als Beispiel wäre hier eine URI zu nennen. Ziel ist es durch RESTful Applications, so viele URIs wie möglich zu erzeugen, weil:
„Jede URI steigert den „Wert“ des Internets“ - Uniforme Schnittstellte
Die Interaktion im REST-Modell funktioniert über eine feste Schnittstelle. Eine Beispiel Methode wäre die GET-Funktion von HTTP - Ressource-Repräsentationen
Von einer Ressource kann es verschiedene Repräsentationen geben. Z.B. HTML, PDF, XML, JSON. HTTP unterstützt von Haus aus die bekannten Content Types und das weniger bekannte Content Negotiation! D.h. vor der eigentlichen Datenübertragung kann „ausgehandelt“ werden, welche Repräsentation der Ressource ausgetauscht werden soll. - Statuslose Kommunikation
Einfach ausgedrückt bedeutet das, dass ein Request für sich alleine wiederholbar sein muss. Das heißt nicht, dass die ganze Anwendung stateless sein soll. Das würde natürlich keinen Sinn machen. - Hypermedia
Statusübergänge über Links
Unterstüzt Evolution von Schnittstellen
REST vs. Web-Services
Eine Unterscheidung zwischen normalen „Web“-Services und RESTful Services kann folgendermaßen vorgenommen werden:
Web-Services haben nur wenig Endpoints, jedes Web-Service-Interface hat jedoch viele Methoden, die nicht uniform sind, sondern sich von Service zu Service unterscheiden. Diese Herangehensweise schafft wenig „Mehrwert“ für das Web, weil nur sehr wenige URIs benötigt werden.
REST hingegen hat eine uniforme Schnittstelle (GET, POST, PUT, DELETE) und viele Enpoints(URIs), weil quasi jeder Datensatz eine eigene URI besitzt (GET customer/id).
Zum Designen einer REST-Applikation solle man nach folgendem Schema vorgehen (http://bitworking.org/news/How_to_create_a_REST_Protocol):
- Ressourcen identifizieren, URIs designen (allerdings URI-Design nich so wichtig)
- Formate auswählen (D.h. welche Repräsentation die Ressouce hat (HTML, HTTP))
- Methodensemantik beschreiben
- Response-Codes abbilden (404, 403, 500…), von denen es in HTML schon für eigentlich jeden denkbaren Anwendungsfall einen gibt. Bspw. „Methode ist nicht mehr unter dieser URI erreichbar“
Die Vorteile von REST gegenüber „alten“ WS leigen laut dem Referenten auf der Hand:
- Wirklich universelle Unterstützung (da nur HTTP und das kann wirklich „jeder“)
- Mit Web-Services sind die Vorteile von HTTP eigentlich nicht zu nutzen, da sie protokollunabhängig sein müssen.
- WS-Protokollunabhängigkeit ist ein Bug, kein Feature, weil sowieso (fast) jeder Web-Services über HTTP nutzt.
Fortgeschrittene Technologien
Für viele fortgeschrittene Technologien der Web-Services bietet REST auch bereits (teilweise von Haus aus) Unterstützung.
- Asynchrone Kommunikation
Wird unterstützt durch Code 202 Accepted + URI für Ergebnis, wenn bei einem Aufruf der URI das Ergebnis noch nicht vorliegt, wird einfach ein 404 geschickt - Reliable Messaging
- 2-Phase-Commit Transaktionen
- WS-Transfer, für was? HTTP-over-SOAP-over-HTTP???
- UDDI
Diese Technologie lässt sich relativ einfach über Atom realisierten
Zur Beschreibung der Web-Services schlägt der Referent vor, auf WSDLs zu verzichten und die Formate der Nachrichten einfach in XSD oder RelaxNG zu beschreiben. Nur zur Beschreibung der Operation und Datentypen sei WSDL zu kompliziert.
Mein Fazit:
Nachdem ich den Vortrag gehört hatte war ich zunächst extrem beeindruckt von den Prinzipien von REST. So einfach hätten Web-Services schon immer sein sollen! Nach einiger Reflektion darüber, vor allem im weiteren Verlauf der JAX, musste ich allerdings feststellen, dass es noch einer großen Kraftanstrengung bedarf, um REST auch bei Enterprise Applications durchzusetzen, denn die „alten“ Web-Services sind einfach viel zu präsent und haben einige weitere Technolgien nach sich gezogen, wie BPEL, das REST zum Beispiel überhaupt nicht berücksichtigt. Ohne WSDLs geht hier gar nichts.
Aber trotzdem hoffe ich, in Zukunft REST einsetzen zu können, vor allem wenn es darum geht „mal kurz“ eine Remote-Schnittstelle in eine Anwendung einzubauen.
Links:
Blog des Referenten: http://www.innoq.com/blog/st / Beitrag zum Vortrag
RESTlet(Java REST Framework): http://restlet.org
Habe ein Set mit unseren Fotos von der JAX erstellt:
http://www.flickr.com/photos/vland/sets/72157600120944246/
Hier die offizielle Flickr Group:
Ich bin diese Woche in Wiesbaden auf der „No.1-Konferenz für Java, Enterprise Architekturen und SOA“ – der JAX. Werde des öfteren meine Erfahrungsberichte hier in dieses Blog einstellen. Momentan folge ich dem JSF@Work-Workshop, morgen beginnen dann die Sessions.
Windows Vista läuft ohne Problem unter OS X im Hintergrund. Parallels macht’s möglich. Besonders geil: der „Coherance Mode“ durch den den Windows Desktop verschwindet und die Windows Programme sich in OS X „einfügen“. Sehr praktisch.
My Tumbler- Photo
- pleatedjeans: 19 Images That Prove Husbands Just Can’t Follow...
- pleatedjeans: via
- obviousplant: iPhone 6s comparison
- Photo
- digg: IT’S FRIIIIIDAAYYYYYYYYY this video is great w/o sound...
- obviousplant: I AM SO MAD RIGHT NOW
- pleatedjeans: 20 Nappers Who Just Couldn’t Make it Through the...
- pleatedjeans: via
- pleatedjeans: via
vland 