Die letzte Festung : Transaktionen Agenda Einführung Grundlagen Transaktionen Zwei Welten: web...

Die letzte Die letzte Festung :Festung :

TransaktionenTransaktionen

nsakti

Agenda

Einführung

Grundlagen Transaktionen

Zwei Welten: web services / ACID

Business Transaction Protocol (BTP)

SOAP, ebXML, usw.

Zusammenfassung

nsakti

Eine starke Festung ...

nsakti

... ein neuer Herausforderer

nsakti

Web Services 101

Web Services sind hip!

Breites Angebot von Services.

Aggregation dieser Komponenten ist der neue Weg, Anwendungen zu bauen.

SOAP als Basis für die Kommunikation bietet ein Reihe von Vorteilen.

nsakti

Trouble in Paradise Löst Port 80 alle Probleme ?

Waren alle Probleme ungelöst ?

Fremde Komponenten verhalten sich nicht immer so wie erwünscht.

Verfügbarkeit und Latenzzeit können Problem werden.

Behandlung der möglichen Fehlerszenarien ist sehr komplex.

nsakti

Fault (In)Tolerance

Grosse Systeme sind fehleranfällig. OO macht Systeme robuster.

Verteilte Systeme sind fehleranfälliger. Programmiermodell kann helfen.

Heterogene Systeme sind eine echte Herausforderung !

Muss der Gesetzgeber muss her ?

nsakti

Agenda

Einführung

SOAP, ebXML, usw.

Zusammenfassung

nsakti

Eine klassische Transaktion ( TA ) ist ein ‘unit of work’, die entweder erfolgreich abgeschlossen wird, oder vollkommen ohne Auswirkung bleibt.

Die wichtigen Eigenschaften von TA werden markant ‘ACID’ abgekürzt:

Atomic: unteilbar, ganz oder gar nicht. Consistent: ein gültiger Zustand wird in eine

anderen, gültigen Zustand überführt. Isolated: Jede TA scheint ‘Highlander’ zu

sein. Durable: Der Ausgang der TA bleibt

dauerhaft gespeichert.

nsakti

Transaktionen 1. Generation

Tx.begin();

UPDATE amount = amount + 100 FROM account

WHERE id = 1000;

UPDATE amount = amount - 100 FROM account

WHERE id = 1001;

Tx.commit();

nsakti

Verteilte Transaktionen (1)

Verteilte Transaktionen basieren auf dem Two-Phase Commit (2PC) Protokoll.

Eine Transaktion beginnt und es werden modifizierende Operationen durchgeführt.

Teilnehmende Resourcen erfahren (irgendwie) von der Transaktion

Fertig, das 2PC Protokoll beginnt :

nsakti

Der Coordinator befragt jede Resource nach ihrem ‘Befinden’ :

VoteReadOnly VoteCommit VoteRollBack

nsakti

Nachdem alle Resources positiv abgestimmt haben veranlasst der Coordinator die dauerhafte Speicherung (meist unter Nutzung einer DB).

Das ‘Rollback’-Veto einer Resource reicht aus, um die ganze Transaktion zu invalidieren.

Der Coordinator und die Resourcen muessen sich um das Recovery kümmern.

nsakti

Verteilte Transaktionen !

Einfaches Programmiermodell für den Nutzer. Bewährter Industriestandard. Black-Boxing :

Komposition zur Laufzeit. konsequentes ‘information hiding’. Jede Resource entscheidet nur für sich.

Optimierungspotentiale : Lokale Sub-Coordinatoren. Asynchrones 2PC-Protokoll. Minimierung des Context-Overheads.

nsakti

Agenda

Einführung

SOAP, ebXML, usw.

Zusammenfassung

nsakti

ApplikationslogikApplikationslogik 2PC2PC

TransaktionTransaktion

Lokale Transaktion

1 Sek.

prepare commit

nsakti

OTS TransaktionOTS Transaktion

Qualitativer Vergleich

Business TransaktionBusiness Transaktion

nsakti

Quantitativer Vergleich

100 Sek.

Business TransaktionBusiness Transaktion

nsakti

Probleme…

Um die ACID-Eigenschaften sicherzustellen müssen zumindest für die Dauer des 2PC Locks auf wertvollen Resourcen gehalten werden.

Eine kontrollierte / zuverlässige Umgebung ist Voraussetzung ( typisches Einsatzfeld von CORBA / RMI / DCOM-Anwendungen ).

Unbrauchbar bei unvorhersagbarer Latenzzeit. unbekannter Verfügbarkeit. unkontrollierter Nutzermenge.

Deshalb : OTS über SOAP reicht nicht !

nsakti

Mehr Probleme…

Längere Dauer -> erhöhtes Fehlerrisiko. SOAP ist nicht das schnellste Protokoll ! Physikalische Entfernung der Teilnehmer. Mehr Komplexität -> längere Bearbeitung.

Mehr Teilnehmer -> höheres Rollback-Risiko.

Ablehnungswahrscheinlichkeiten summieren sich. ( 0,93 10 < 0,5 )

Time Outs werden wahrscheinlicher. Der Recovery-Fall wird Standard !

nsakti

Episode IV: A New Hope

Der Bedarf an Transaktionen bei Web Services ist unumstritten !

Glücklicherweise haben Forscher schon lange darüber nachgedacht.

Es gab Versuche, einen anerkannten Standard für ‘extended Transactions’ zu schaffen.

Z.B. OMG : ‘Activity Service Specification’

OASIS BTP passt am Besten !

nsakti

ACID korrodiert !

Aufgabe zumindest der ACI-Eigenschaften.

Atomicity: Die TA überlebt trotz einzelner Fehler / Rollbacks.

Consistency: Durch Verzicht auf langlebige Locks kann die Konsistenz nicht garantiert werden.

Isolation: Teile einer TA können schon vor ihrem Gesamt-Abschluss sichtbar werden.

nsakti

Problem- / Lösungsbereiche

Persistenz ACI

nsakti

Persistenz

Verteilung

XA / OTS

nsakti

Persistenz

Verteilung

DifferenzierterAusgang

Multi-Protokoll

MinimalesLocking

XA / OTS

nsakti

Agenda

Einführung

SOAP, ebXML, usw.

Zusammenfassung

nsakti

OASIS BTP Spec

Business Transaction Protocolwww.oasis-open.org/committees/business-

transactions

Kick Off : 13. 03. 2001

Termin 1.0 : Ende Dezember ?

nsakti

OASIS BTP Technical Committee

– BEA Systems, Inc.

– Bowstreet, Inc.

– Choreology Ltd.

– Entrust, Inc.

– Hewlett-Packard Co.

– Interwoven Inc.

– IONA Technologies PLC

– SeeBeyond Inc.

– Sun Microsystems Computer Corp.

– Talking Blocks Inc.

nsakti

Business Transaction Protocol

BTP ist ein Inter-Operation Protokoll, das definiert, wie sich transaktionale (Web) Services zu verhalten haben.

Und es wird festgelegt, welche Nachrichten während einer Transaktion ausgetauscht werden.

Basis ist das 2PC für kleine ( lokale ) Teile, die zu größeren, nicht-ACID Transaktion zusammengefügt werden.

Die Spezifikation definiert keine API !( siehe aber JSR 156 )

Einige Firmen haben Implementierungen zugesagt, bzw. haben Demos fertig:

HP Choreology/Bowstreet TalkingBlocks BEA ...

nsakti

BTP – Anforderungen

Mehrere erfolgreiche Ausgänge einer Transaktion sind zulässig.

Auswirkungen von Operationen müssen nicht isoliert / dauerhaft sein.

Transaktionsteilnehmer können zeitweise unerreichbar sein.

Kommunikation basierend auf XML. Verschiedene Transportprotokolle sind

zulässig.

nsakti

ISO / OSI Schichten

AnwendungAnwendung

SessionSession

Low LevelLow Level

TransportTransport

PräsentationPräsentation

Layer 3, 2, 1

Layer 4

Layer 7

Layer 6

Layer 5

nsakti

ISO / OSI Schichten

AnwendungAnwendung

SessionSession

Low LevelLow Level

TransportTransport

PräsentationPräsentation

Layer 3, 2, 1

Layer 4

Layer 7

Layer 6

Layer 5BTPBTP

nsakti

Transaktionale Schichtung

AnwendungAnwendung

Cohesion Cohesion ComposerComposer

Atom Atom CoordinatorCoordinator

ACID Resource ACID Resource

BTP BTP spezifischspezifisch

nsakti

Begriffe : Atom / Cohesion

Ein Atom ist die BTP Bezeichnung für eine ‘Standard’ -Transaktion ( atomar ).

Innerhalb eines Atoms gelten die Regeln des bekannten 2PC. Der Ausgang eines Atoms ist Alles-Oder-Nichts.

Atome können zu Cohesions aggregiert werden.

Business-Regeln bestimmen den Ausgang einer Cohesion in Bezug auf den Ausgang der zugrundeliegenden Atoms.

nsakti

Coordinator Atome werden von einem Coordinator gesteuert.

‘In Process’ : die Applikation steuert selbst. ‘Out of Process’ : ein spezieller Dienst

übernimmt die Coordinator-Aufgabe.

Im Inter-Enterprise-Bereich bietet sich eine ‘Trusted-Coordinator’-Dienstleistung an.

Der Coordinator muss fehler-tolerant sein: Das Ergebnis muss im Stable Storage gesichert

sein, bevor es an die einzelnen Teilnehmer propagiert wird.

Im Recovery-Fall dient das Log als Basis für das ‘replay completion’ der koordinierten Transaktion.

nsakti

Atom Example

Client Application

CoordinatorCredit CardClearance

Book Shop

nsakti

Coordinator Hierarchien

Coordinator 1

Atom2Atom1

Atom5Atom4

Atom7Atom6

nsakti

Coordinator Hierarchien

Coordinator 2

Coordinator 1

Coordinator 3

Coordinator 4

Atom5Atom4

Atom7Atom6

nsakti

Atomare Gesetzmäßigkeiten

Der Atom Coordinator ist reaktiv Prepare und Commit des Coordinators ( damit

des Atoms ) werden von ‘aussen’ gesteuert. Beliebige Blockierung von Resourcen möglich.

Die Atoms können ihr Vote ‘qualifizieren’ : Zeitangabe, wie lange ein Atom bereit ist, auf

das Commit zu warten. Danach : Einseitige Annahme über den

AusgangUnilateral confirm / cancel.

Mehrfaches Prepare pro Atom ist zulässig. Rücksetzen der Time-Outs.

nsakti

Composer = Cohesion Manager

Der Composer übernimmt die Steuerung der Cohesions ( nicht-atomaren Business TA ).

In-Process / Out-Of-Process. Make Or Buy ( / Use ). Der Composer entscheidet über den Ausgang

der nicht-atomaren TA anhand des Ausgangs der zugeh. Atoms und der Business Logik.

Durch Composer als Teilnehmer an einer Cohesion kann ein Baumstruktur erzeugt werden.

Ein subordinate Composer verhält sich nach aussen wie ein Atom.

nsakti

Cohesion = Businesslogik

Cohesion

Composer

Application

Atom A1 Atom A2 Atom AN

ConfirmCancelCancel

(A1=Cancel, A2=Cancel, AN=Confirm)

nsakti

Cohesion Hierarchien

Cohesion 2

Cohesion 1

Cohesion 3

Cohesion 4

Atom5Atom4

Atom7Atom6

nsakti

Superior - Inferior - Beziehungen

Cohesion 2

Cohesion 1

Cohesion 3

Cohesion 4

Atom5Atom4

Atom7Atom6

Superior

Inferior

InferiorInferior

nsakti

Superior - Inferior - Beziehungen

Cohesion 2

Cohesion 1

Cohesion 3

Cohesion 4

Atom5Atom4

Atom7Atom6

Superior

Inferior

Superior

Inferior

nsakti

Inferiors

Inferior

Participant Sub-coordinator Sub-composer

Quelle : Sanjay Dalal, BEA

nsakti

Superiors

Superior

Sub-composerDecider Sub-coordinator

ComposerCoordinator

nsakti

Atom Demo: Organising a Night Out

Application Message

BTP Message

Client Application

SOAP server

BTP ServiceBTP Service

SOAP server

WebTaxi Participant

WebTheatre Participant

SOAP server

WebRestaurant Participant

SOAPSOAP

Quelle : Jim Webber, HP

nsakti

Client Application

SOAP server

WebTaxi Participant

SOAP server

Create Atom

Atom ID

Create AtomAtom ID

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

Book Taxi

Application Message !

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

Book Table

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

Book Seats

EnrolBook Seats

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

PreparePrepare

Prepare

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

Vote confirmVote confirm

Vote confirm

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

ConfirmConfirm

Confirm Confirm

nsakti

Oder…

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

PreparePrepare

Prepare

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

Vote cancel

Vote confirm

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

CancelCancel

Cancel

nsakti

Atom ID

Client Application

SOAP server

WebTaxi Participant

SOAP server

Atom cancelled

nsakti

Weniger ‘Kultur’ ...

Cohesions erlauben die ‘Aufweichung’ der ACID-Anforderung.

Die Buchung der Theaterkarten wird als ‘nice to have’ eingestuft.

Die Transaktion kann trotzdem zu einem erfolgreichen Abschluss kommen.

Ohne Abendessen geht es aber nicht !

nsakti

Cohesion

Cohesion Demo: Organising a Night Out

Client Application

SOAP server

WebTaxi Participant

SOAP server

Create Cohesion

Cohesion ID

Create CohesionCohesion ID

nsakti

Cohesion

Client Application

SOAP server

WebTaxi Participant

SOAP server

Create Atom, associate withCohesion

Atom 1

Create Atom,associate withCohesion

Atom 1

nsakti

Cohesion

Atom 1

Client Application

SOAP server

WebTaxi Participant

SOAP server

Book Taxi

Enrol(Atom 1)

Book Taxi

Enrol(Atom 1)

nsakti

Atom 1

Cohesion

Client Application

SOAP server

WebTaxi Participant

SOAP server

Book Table

Enrol(Atom 1)

Book Table

nsakti

Client Application

SOAP server

WebTaxi Participant

SOAP server

Create Atom, associate withCohesion

Atom 2

Create Atom,associate withCohesion

Atom 2

Cohesion

nsakti

Atom 2

Client Application

SOAP server

WebTaxi Participant

SOAP server

Book Seats

Enrol(Atom 2)

Book Seats

Cohesion

nsakti

Client Application

SOAP server

WebTaxi Participant

SOAP server

Prepare

Cohesion

nsakti

Atom 1

Client Application

SOAP server

WebTaxi Participant

SOAP server

PreparePrepare

Prepare

Cohesion

nsakti

Atom 1

Client Application

SOAP server

WebTaxi Participant

SOAP server

Voteconfirm

Cohesion

Voteconfirm

nsakti

Atom 2

Client Application

SOAP server

WebTaxi Participant

SOAP server

Prepare

Cohesion

nsakti

Atom 2

Client Application

SOAP server

WebTaxi Participant

SOAP server

Vote cancel

Cohesion

nsakti

Client Application

SOAP server

WebTaxi Participant

SOAP server

PrepareAtom 1: confirmAtom 2: cancel

Cohesion

PrepareAtom 1: confirmAtom 2: cancel

nsakti

Client Application

SOAP server

WebTaxi Participant

SOAP server

Confirm

Cohesion

Confirm

nsakti

Atom 1

Client Application

SOAP server

WebTaxi Participant

SOAP server

ConfirmConfirm

Confirm

Cohesion

nsakti

Night Out Beispiel : Ergebnisse

Atom 1

Cohesion

Restaurant Theatre

Atom 2

nsakti

Ausgang der Transaktion

‚Commited‘ ‚Rollbacked‘

Klassisches 2 PC

nsakti

Ausgang der Transaktion

‚Commited‘ ‚Rollbacked‘

Klassisches 2 PC

BTP Outcome

nsakti

Agenda

Einführung

SOAP, ebXML, usw.

Zusammenfassung

nsakti

BTP Messaging

BTP SOAP Binding hat höchste Priorität.

BTP messages basieren nicht auf SOAP-RPC.

Das BTP SOAP Binding nutzt kein WSDL.

Die Umfang der BTP Messages ist beachtlich gross.

nsakti

BTP Messaging :‘Prepare’

PREPARE

<btp:prepare id?> <btp:target-additional-information> ...additional address information... </btp:target-additional-information> <btp:inferior-identifier>...hexstring...</btp:inferior-identifier> ? <btp:reply-address> ? ...address... </btp:reply-address> <btp:transaction-identifier>...hexstring...</btp:transaction-identifier> ? <btp:inferiors-list> ?

<btp:inferior-handle>...hexstring...</btp:inferior-handle> + </btp:inferiors-list> <btp:qualifiers> ? ...qualifiers... </btp:qualifiers></btp:prepare>

nsakti

BTP Messaging : SOAP<soap:Envelope xmlns:soap=... > <soap:Header> <btp:messages xmlns:btp="urn:oasis:names:tc:BTP:xml"> <btp:context superior-type="atom"> <btp:superior-address> <btp:binding>soap-http-1</btp:binding> <btp:binding-address>http://example.com/soaphandler</btp:binding-address> <btp:additional-information>btpengine</btp:additional-information> </btp:superior-address> <btp:superior-identifier>1001</btp:superior-identifier> <btp:qualifiers> ... </btp:qualifiers> </btp:context> </btp:messages> </soap:Header>

<soap:Body> <ns1:orderGoods xmlns:ns1=...> <custID>ABC8329045</custID> <itemID>224352</itemID> <quantity>5</quantity> </ns1:orderGoods> </soap:Body></soap:Envelope>

nsakti

BTP Messaging : SOAP<soap:Envelope xmlns:soap=... > <soap:Header> <btp:messages xmlns:btp="urn:oasis:names:tc:BTP:xml"> <btp:context superior-type="atom"> <btp:superior-address> <btp:binding>soap-http-1</btp:binding> <btp:binding-address>http://example.com/soaphandler</btp:binding-address> <btp:additional-information>btpengine</btp:additional-information> </btp:superior-address> <btp:superior-identifier>1001</btp:superior-identifier> <btp:qualifiers> ... </btp:qualifiers> </btp:context> </btp:messages> </soap:Header>

<soap:Body> <ns1:orderGoods xmlns:ns1=...> <custID>ABC8329045</custID> <itemID>224352</itemID> <quantity>5</quantity> </ns1:orderGoods> </soap:Body></soap:Envelope>

nsakti

XA State Table

nsakti

Table z@z : Superior state table – normal forward progression

I1 A1 B1 C1 D1 E1 E2 F1 F2receive ENROL/rsp-req A1receive ENROL/no-rsp-req B1receive RESIGN/rsp-req Y1 C1 C1 C1receive RESIGN/no-rsp-req Z Z Z Zreceive PREPARED Y1 E1 E1 E1 F1receive PREPARED/cancel Y1 E2 E2 E2 F1receive CONFIRMED/auto Q1 H1 H1 H1 F1receive CONFIRMED/response F2 F2receive CANCELLED Y1 Z Z J1 J1 K1receive HAZARD P1 P1 P1 P1 P1 P1 P3receive INF_STATE/active/y Y1 A1 B1 D1receive INF_STATE/active B1 D1receive INF_STATE/unknown Z Z Zsend ENROLLED B1send RESIGNED Zsend PREPARE D1 E1 E2send REQUEST_CONFIRMsend CONFIRM F1send CANCELsend CONTRADICTIONsend SUP_STATE/active/y B1send SUP_STATE/active B1send SUP_STATE/preparedin/y E1 E2send SUP_STATE/preparedin E1 E2send SUP_STATE/unknowndecide to request confirm S1 S1 S1decide to prepare D1decide to confirm F1 F1decide to cancel G1 G1 G1 Zremove persistent information Zrecord contradictiondisruption I Z Z Z Z Z Z Z F1disruption II D1 D1disruption III B1 B1disruption IV

State Table ( Auszug )

Table z@z : Superior state table – query after completion and completed states

Y1 Zreceive ENROL/rsp-req Y1receive ENROL/no-rsp-req Y1receive RESIGN/rsp-req Y1 Y1receive RESIGN/no-rsp-req Z Zreceive PREPARED Y1 Y1receive PREPARED/cancel Y1 Y1receive CONFIRMED/auto Q1 Q1receive CONFIRMED/response Z Zreceive CANCELLED Y1 Y1receive HAZARD P2 P2receive INF_STATE/active/y Y1 Y1receive INF_STATE/active Y1 Zreceive INF_STATE/unknown Z Zsend ENROLLED send RESIGNED send PREPARE send REQUEST_CONFIRM send CONFIRM send CANCEL send CONTRADICTION

Table z@z : Superior state table – cancellation and contradiction

G1 G2 G3 G4 H1 J1 K1 L1receive ENROL/rsp-req receive ENROL/no-rsp-req receive RESIGN/rsp-req G3 Z G3 receive RESIGN/no-rsp-req Z Z Z receive PREPARED G1 G2 receive PREPARED/cancel G1 G2 receive CONFIRMED/auto L1 L1 H1 L1receive CONFIRMED/response receive CANCELLED G4 Z G4 J1 K1 receive HAZARD P4 P4 receive INF_STATE/active/y G1 G2 receive INF_STATE/active G1 G2 receive INF_STATE/unknown Z Z Z Z send ENROLLED send RESIGNED send PREPARE send REQUEST_CONFIRM send CONFIRM send CANCEL G2 G2 Z Z send CONTRADICTION send SUP_STATE/active/y send SUP_STATE/active send SUP_STATE/preparedin/y send SUP_STATE/preparedin send SUP_STATE/unknown decide to request confirm decide to prepare decide to confirm F1 K1 decide to cancel L1 G4 remove persistent information record contradiction R1 R1disruption I Z Z Z Z Z Z F1 Zdisruption II G2 G2 E1 E1 G2disruption III D1 D1 disruption IV B1 B1

Table z@z : Superior state table – hazard and request confirm

P1 P2 P3 P4 Q1 R1 R2 S1receive ENROL/rsp-req receive ENROL/no-rsp-req receive RESIGN/rsp-req C1receive RESIGN/no-rsp-req Zreceive PREPARED S1receive PREPARED/cancel S1receive CONFIRMED/auto Q1 R1 R1 S1receive CONFIRMED/response Z R2 Zreceive CANCELLED R1 R1 Zreceive HAZARD P1 P2 P3 P4 R1 R1 Zreceive INF_STATE/active/y S1receive INF_STATE/active S1receive INF_STATE/unknown P1 P2 P4 R2 R2 Zsend ENROLLED send RESIGNED send PREPARE send REQUEST_CONFIRM S1send CONFIRM send CANCEL send CONTRADICTION R2 send SUP_STATE/active/y send SUP_STATE/active send SUP_STATE/preparedin/y send SUP_STATE/preparedin send SUP_STATE/unknown decide to request confirm decide to prepare decide to confirm decide to cancel remove persistent information Z record contradiction R1 R1 R1 R1 R1 disruption I Z Z Z Z Z R1 Zdisruption II D1 F1 G2 disruption III B1 disruption IV

nsakti

Java Binding

JSR 156XML Transactioning API for Java ‚JAXTX‘

Initiiert von HP ( Mark Little ), IBM, IONA,und Choreology.

Abstimmung über den Specification Request am 5.11.2001.

Erwartete Fertigstellung : Sommer 2002

nsakti

Related ...

XAML Transaction Authority Markup Language deprecated

ebXML High Level, Ebene Geschäftslogik. Nicht Fehlertolerant.

WSFL Skript-basierte Steuerung von Web Services. Nicht Transaktional.

nsakti

Agenda

Einführung

SOAP, ebXML, usw.

Zusammenfassung

nsakti

Zusammenfassung

Transaktionen sind ein entscheidender Baustein für das zuverlässige Durchführen von nicht-trivialen Prozessen.

BTP ist die Lösung für transaktionale Web Services.

Freiheit zur Komposition von Prozessen aus ACID- und nicht-ACID Teilnehmern

Die Geschäftslogik entscheidet über den Ausgang der Transaktion, nicht die starre Infrastruktur.

Die Spezifikation ist ( fast ) fertig, der Weg ist frei für Implementierungen.

nsakti

Die ‚BTP‘ Festungsanlage

nsakti

Resourcen

OASIS BTP:http://www.oasis-open.org/committees/business-transactions

OMG OTS Spec:http://www.omg.org/technology/documents/formal/transaction_service

JAXTX JSR 156:http://www.jcp.org/jsr/detail/156.jsp

HP XTS Software:http://www.arjuna.com/xts/

Choreology :http://www.choreology.com/~btp/

KLuPhttp://www.klup.de

nsakti

Fragen ...

... jetzt ...

...später :

kuehne@klup.de

Die letzte Festung : Transaktionen Agenda Einführung Grundlagen Transaktionen Zwei Welten: web...

Documents

Transcript of Die letzte Festung : Transaktionen Agenda Einführung Grundlagen Transaktionen Zwei Welten: web...

Festung Königstein

Jahresrückblick EY Deutschland · Transaction Advisory Services: Kaufen und Verkaufen in einer sich wandelnden Welt Investieren, Sichern, Optimieren und Beschaffen von Kapital: Transaction

Quelle: Würzburg - Festung Marienberg (um 1200)

Festung – Planstadt – Residenz Migration – Toleranz – … · 2019. 5. 15. · Festung – Planstadt – Residenz Migration – Toleranz – Verfolgung Bürgertum - Handel

Vertrauenswürdige digitale Transaktionen Records ...€¦ · .consulting .solutions .partnership Vertrauenswürdige digitale Transaktionen – Records Management und Beweiswerterhaltung

Financial Transaction Services (FinTS) · 2014. 1. 27. · Financial Transaction Services (FinTS) Dokument: Messages - Finanzdatenformate Version: V3.0, Final Version Kapitel: Kapitel:

Teil IX Transaktionen, Integrität und TriggerI/ws2016/vorl… · Transaktionen, Integrität und Trigger Transaktionen, Integrität und Trigger 1 Grundbegriffe 2 Transaktionsbegriff

SQL Server Transaction Log Deep Dive Session - PASS Hamburg

Transaction Consulting Zürich "Studie Mobile Business"

Kapital 4 Management von Translation und Transaction Exposure

Erfolgsfaktoren und Erfolgsmessung bei M&A-Transaktionen ...

Festung - germersheim.eu · Erkunden und erleben Sie unsere Festung 20er Jahre Teile der Festung abgetragen wurden und nur die beiden Stadttore und eine Reihe weiterer Bauwerke erhalten

Financial Transaction Taxes - PwC · Financial Transaction Taxes . Basic Materials on the Italian, the French and the European Model of a Financial Transaction Tax . 07.01.2014 …

RLP, Buga, Festung

Festung Dömitz AUSGABE 2 - gku-se.de · Festung Busbahnhof Kulturhaus Sportboot-hafen Schleuse Hafen Fahrgastschiff-anleger Stadtwall Wasserstraße Werderstra ße Fritz- Reute r-

Bain-Studie_Renaissance Des Transaction Bankings

Financial Transaction Services (FinTS) - hbci-zka.de · PDF fileFinancial Transaction Services (FinTS) Dokument: Messages - Multibankfähige Geschäftsvorfälle Version: 3.0 Rel 2018,

Google Analytics Measurement Protocol: Einführung, Transaktionen & Stornos

Dr. Heidrun BethgeDatenbanken II1 Transaktionen. Dr. Heidrun BethgeDatenbanken II2 Bsp. für Notwendigkeit von Transaktionen INSERT INTO auftrag (aufnr,

Abenteuerurlaub auf der Festung Kronach - jufa.eu · Abenteuerurlaub auf der Festung Kronach Aktivitäten den ganzen Sommer lang ferien DIENSTAG MITTWOCH DONNERSTAG FREITAG SAMSTAG