Vorstellung HPI-BPT Harald Meyer

harald.meyer@hpi.uni-potsdam.de

Das HPI

• Praxis-nahe Ausbildung von Software-Ingenieuren

2

Business Process Technology

3

Business Process Technology - Partner

• SAP Research

• Software AG

• T-Systems

• AOK

4

Semantic Web Services

• Finden von Diensten

• Wie beschreibe ich Dienste?

• Dienstmanagement, Impact-Analysen

• Komposition von Diensten

5

Komposition von Diensten

• Unsere Arbeiten

• (semi-)automatische Komposition

• Replanning im Fehlerfall

• Offene Fragestellungen

• Machbarkeit im großen Stile

• Beschreibung der Dienste

6

Dienstbeschreibung

• Fragen

• Woher kommen die Beschreibungen?

• Wie passen sie zusammen?

• Unsere Arbeiten

• Tagging

• Automatische Ableitung von Dienstbeschreibungen

7

Prozessmodellierung

• Oryx

• Web-basierte Prozessmodellierung

• Verteilte Modellierung, voller BPMN 1.0-Support

• Einfache Integration existierender Arbeiten

• Formale Grundlagen

• Pi-Calculus, Petrinetze

• Transformation von BPMN in Petrinetze

8

Choreography

• Conformance, Realizability?

9

Domain check

ISP DR

Process payment

ISP PP 1

Process payment

ISP PP 2

Domain registration

ISP DR

Let‘s DanceThe Business Process Modeling Notation (BPMN,

[13]) is a graphical modeling language for intra- or inter-organizational business processes. It allows to inter-connect processes using message flows and therefore toexpress choreographies. BPMN lacks formal semanticsand is not executable, however mappings from BPMNto BPEL are available (e.g. [14]).

4 BPEL4Chor

In the choreography space there are two di!erentmodeling approaches: interaction models and intercon-nected interface behavior models. In case of interactionmodels (e.g. defined using WS-CDL and Let’s Dance), el-ementary interactions, i.e. request and request-responsemessage exchanges, are the basic building blocks. Be-havioral dependencies are specified between these inter-actions and combinations of interactions are groupedinto complex interactions. Due to the fact that thesemodels capture the dependencies from a truly globalperspective, the modeler is able to define dependenciesthat cannot be enforced. E.g., she might specify thata shipper can only send the delivery details to a buyerafter the supplier has notified the insurance about thedelivery. In this case it is left unexplained how theshipper can learn about whether the notification hasbeen sent. Additional synchronization messages wouldbe necessary to turn such a locally unenforceable inter-action model into an enforceable one [16]. In the case ofinterconnected interface behavior models (e.g. expressedin BPMN) such unenforceability issues cannot arisesince control flow is defined per participant. However,on the other hand, interface behavior models mightbe incompatible, i.e. the di!erent participant cannotinteract successfully with each other. Deadlocks aretypical outcomes of such incompatibility. For instance,imagine a participant expecting a notification of anotherparticipant before being able to proceed and the otherparticipant never sends such a notification.

It has not been investigated yet which approachis more suitable for the human modeler. We adoptinterconnected interface behavior descriptions for spec-ifying choreographies since this approach is closer tothe history of BPEL. More precise, we use the AbstractProcess Profile for Observable Behavior of BPEL ([1])and add an interconnection layer on top of that leadingto interconnected interface behavior descriptions.

In addition, unlike WS-CDL, BPEL4Chor decouplesthe “heart” of choreographies, i.e. the communicationactivities, their behavioral dependencies and their inter-connection, from technical configuration, e.g. the defini-tion of WSDL port types. That way, higher reusabilityof the choreography models is achieved.

!"#$%&'()*+'(),(-)./'0

".)12+2/.31

1(/(4(-0

51)6+16).4*.7/,+17

".)12+2/.31*8,'.92()*

:,7+)2/12(37*;"!<7=

>87,)9.84,*+(31)(4*?*:.1.*@4(A

".)12+2/.31*-)(63:23-7

B,+'32+.4*+(3@2-6).12(3

".)12+2/.31*<,+4.).12(3

$271*(@*1',*/.)12+2/.317

C,77.-,*$23D7

&(33,+123-*"!<7

Figure 2. BPEL4Chor artifacts

BPEL4Chor is a collection of three di!erent arti-fact types (cf. Figure 2): (i) Participant behavior de-scriptions define the control flow dependencies betweenactivities, in particular between communication activ-ities, at a given participant. (ii) A Participant topol-ogy defines the structural aspects of a choreographyby specifying participant types, participant references,and message links. Participants of the same type haveto provide the same set of communication activities.The communication activities of di!erent participantsare connected through message links. (iii) Participantgroundings define the actual technical configurationof the choreography. Here, the choreography becomesweb-service-specific and the link to WSDL definitionsand XSD types is established.

The following subsections are going to introducethese artifact types. Corresponding code snippets willbe given for the example from section 2.

4.1 Participant Behavior Descriptions

Communication activities, i.e. message send and re-ceive activities, together with their control and dataflow dependencies are at the center of attention in chore-ographies. BPEL comes with a rich set of constructsfor control flow and data manipulation, which are usedunchanged in BPEL4Chor. Therefore, existing BPELtools can also be reused for choreographies.

In abstract processes, some language constructsneeded to specify executable BPEL processes maybe omitted. Such constructs are for example thepartnerLink and the operation attribute of a messageactivity. A profile can force or forbid the usage of cer-tain attributes. We will introduce the Abstract ProcessProfile for Participant Behavior Descriptions statingthe requirements for defining the behavior of one par-ticipant. This profile inherits all constraints of theAbstract Process Profile for Observable Behavior speci-fied by BPEL. We have to uniquely reference activities

3

Quelle: Decker et al.: BPEL4Chor: Extending BPEL for Modeling Choreographies

BPEL4ChorSeller

Auctioning Service

Auction

creation

request

Account

creation

request

Regis-

tration

info

Auction

creation

confir-

mation

Already

registered?

yes

no

iBPMN

Erwartungen & Wünsche

• Gründe für Agilität?

• Ad-hoc Prozesse

• Veränderungen der Dienstlandschaft

• Exception Handling

• Anpassung an (neue) Märkte

• Industrie-Input

10

Fokus des Arbeitskreises?

• Modellierung vs. Ausführung

• modellierter Prozess

• ausführbare Service Composition

• Methodische oder technische Aspekte?

• Semantic Web Services?

11

Danke für Ihre Aufmerksamkeit

Harald MeyerHasso-Plattner-Institut, Universität PotsdamCampus Griebnitzsee14440 Potsdamharald.meyer@hpi.uni-potsdam.de

12