RESTful Business Process Management

Cesare Pautasso
http://www.pautasso.info
[email protected]
@pautasso

University of Lugano (USI)

Decoupled Sharing

Hypermedia

Discovery by Referral

Software Connectors

BP

RESTful Process Engine API

Remote Process Call

POST /process/name HTTP/1.1

...after some time...

HTTP/1.1 200

Process Completed

Processes as Resources

• Bookmark a process instance
• Ask a process instance for links to its pending tasks
• Drive the execution of tasks with PUT/POST/DELETE
• Monitor processes using an RSS/ATOM feed
• Fetch links to active, completed, failed process instances
• Control which subset of tasks is actually exposed as resources

Resources as Processes

Publish resources from processes that drive their internal state transitions

• Activate process control flow on requests routed to resources managed by processes
• Produce responses from process data flow
• Control the lifecycle of resources from the process model
• Mint resource identifiers from process instances
• Map resource identifiers to process instances

RESTful Process Engine API

• Processes can be published as resources
• Only the visible part of processes should be published as resources
• Resource state transitions can be driven by process models

REST Architectural Elements

• User Agent
• Proxy
• Gateway
• Origin Server
• Gateway
• HTTP
• Cache

Composing Representations with Hypermedia

The Context

The Problem

Constraints

• Interoperability
  • No changes/extensions to HTTP
  • No additional verbs
  • No special/custom headers
• Loose Coupling
  • REST services should remain unaware they are participating in a transaction
• Simplicity
  • Transactions will not be adopted in practice unless they can be made simple enough

Try-Confirm/Cancel

TCC Participant's view

• Try: Insert into reservation db
• Confirm: Update reservation,
  set status = confirmed
• Cancel: Invalidate reservation
• Timeout: Invalidate reservation

Try

POST /booking HTTP/1.1
Host: api.swiss.com

HTTP/1.1 201 Created
Location: /booking/{id}

Confirm

PUT /booking/{id} HTTP/1.1
Host: api.swiss.com
Accept: application/tcc

HTTP/1.1 204 No Content

Cancel

DELETE /booking/{id} HTTP/1.1

HTTP/1.1 204 No Content

TCC Example

Failure before Confirm

Failure after Confirm

Failure during Confirm

Timeout during Confirm

Timeout?

POST /booking/ HTTP/1.1
Host: api.swiss.com

HTTP/1.1 200 OK
Content-Type: application/json

{"participantLink": 
  { "uri":"http://api.swiss.com/booking/{id}",
    "expires":"2014-04-07T10:15:54.261+01:00", 
    "rel":"tcc" }
}

After a Timeout

PUT /booking/{id} HTTP/1.1
Host: api.swiss.com
Accept: application/tcc

HTTP/1.1 404 Not Found

Workflow

Try to reserve multiple resources

POST /telephone HTTP/1.1
Host: api.swisscom.ch

HTTP/1.1 201 Created
Location: /telephone/0586664302

POST /bill HTTP/1.1
Host: api.post.ch

HTTP/1.1 201 Created
Location: /bill/42

If everything is successful, confirm the bookings

PUT /telephone/0586664302 HTTP/1.1
Host: api.swisscom.ch
Accept: application/tcc

HTTP/1.1 204 No Content

PUT /bill/42 HTTP/1.1
Host: api.post.ch
Accept: application/tcc

HTTP/1.1 204 No Content

Workflow

Try to reserve multiple resources

POST /booking HTTP/1.1
Host: api.swisscom.ch

HTTP/1.1 201 Created
Location: /telephone/0586664302

POST /bill HTTP/1.1
Host: api.post.ch

HTTP/1.1 500 Internal Server Error

Incorrect billing address

If something fails, do nothing.
The reserved resources will eventually timeout.

If something fails, a polite workflow would explicitly cancel the successful reservations

DELETE /telephone/0586664302 HTTP/1.1
Host: api.swisscom.ch

HTTP/1.1 200 OK

Conclusion: REST/TCC

• Multi-party RESTful Conversation Pattern
• Try-Confirm/Cancel applicable to reservation-based business models
• Fits really well with REST design constraints (Hypermedia, Uniform Interface, Statelessness)
• We are looking for early adopters that need transactions across their RESTful APIs