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

Advertisements

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):

  1. Ressourcen identifizieren, URIs designen (allerdings URI-Design nich so wichtig)
  2. Formate auswählen (D.h. welche Repräsentation die Ressouce hat (HTML, HTTP))
  3. Methodensemantik beschreiben
  4. 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

Fotos von der JAX

Habe ein Set mit unseren Fotos von der JAX erstellt:

http://www.flickr.com/photos/vland/sets/72157600120944246/

Hier die offizielle Flickr Group:

http://www.flickr.com/groups/jax-conference

vland@jax

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.

Vista Parallels Coherance Mode

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.

« Vorherige SeiteNächste Seite »