integration via #bpm: become friendly to #cloud
DESCRIPTION
TRANSCRIPT
Integration via #BPM:become friendly to #cloud
A. Samarin
BPM for integration, v2 2
1. #bpm for developers: improve #agility of implementations http://improving-bpm-systems.blogspot.com/2013/04/bpm-for-developers-improve-agility-of.html
2. Addressing #security concerns through #BPM at http://improving-bpm-systems.blogspot.com/2013/04/addressing-security-concerns-through-bpm.html
© A. Samarin 2013
Related articles
BPM for integration, v2 3
• Technologist-driven
• Weak connection to the business tempo (famous night batches)
• Not easy to trace, audit, maintain and evolve
© A. Samarin 2013
Integration practices without SOA
Monolithic application 1
Presentation layer
Business logic layer
Persistence layer
Monolithic application 2
Presentation layer
Business logic layer
Persistence layer
Client-base integration
Functional API integration
Data-centric integration
BPM for integration, v2 4© A. Samarin 2013
From monolithic applications to universally interconnected and interdependent services
Monolithic application
GUI screen 2GUI screen 1 GUI screen 3
Business logic
BO1 persistence BO2 persistence
Business logic service
Interactive service 1
Interactive service 2
Interactive service 3
Enterprise Service Bus (ESB)
BO1persistence service
BO2persistence service
SOA solution
BPM for integration, v2 5
• As all applications are constructed in SOA way (services and ESB) then the integration looks like plugging mobile phones to the telephone network
© A. Samarin 2013
ESB-centric integration between services
Service
A1
Former monolithic application AService
A2
Service
A3
Service
A4
Service
A5
ESB
Service
B1
Former monolithic application BService
B2
Service
B3
Service
B4
Service
B5
BPM for integration, v2 6
• Only the flow of data is traceable
• Flow of control is not explicit, althoughthe primary importance is the result of working together, but not individual exchanges (like in the football)
© A. Samarin 2013
Problems with ESB-centric integration (1)
BPM for integration, v2 7
• N-to-N connectivity which has the N*(N-1)/2 complexity
• Where to keep the state for a composite service?
– If in ESB then this makes ESB too complicated
• Is ESB cloud-friendly?
– imaging a re-start of the VM with the ESB
– ZapThink http://www.zapthink.com/2013/05/21/cloud-friendly-bpm-the-power-of-hypermedia-oriented-architecture/
• Only ESB is not enough; what to add?
© A. Samarin 2013
Problems with ESB-centric integration (2)
BPM for integration, v2
• BPM, by revealing the artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services
• SOA provides recommendationsfor the implementation, execution and governance of services
• Recursive relationship
– All processes are services
– Some operations of a service can be implemented as a process
– A process includes services in its implementation
© A. Samarin 2013 8
Using BPM for constructing composite services
BPM for integration, v2 9
• Application services are connected (via ESB) only to the coordination service thus removing N-to-N connectivity
© A. Samarin 2013
Making coordination explicit and arranging services around it
Application services
Coordination service
Resource services
Aggregation services
BPM for integration, v2 10
• Each resource has its own life-cycle
• Many variants of duration process instance vs. resource life-cycle
• REST helps to check the state of a resource
• REST helps to implement idempotency
© A. Samarin 2013
Using REST to access resources
Time
Resource 3Resource 2Resource 1
Resource 4
Process instance 1
BPM for integration, v2 11
• To decouple processes
• See also EPN and BPMN Explicit event processing agents in BPMN? at http://improving-bpm-systems.blogspot.com/2011/01/explicit-event-processing-agents-in.html
• EPN, CEP, BEM are important
© A. Samarin 2013
Using events (1)
BPM for integration, v2 12
• To externalise the flow of control from existing monolith applications
© A. Samarin 2013
Using events (2)
BPM for integration, v2 13
• WHY?
– Use of distributed architecture for scalability and fault-tolerance
– Use of clouds (where any service may be disconnected or failed & VM reloaded)
• HOW?
– See also “BPM for developers: improve agility of implementation”
– Error recovery loop for the invocation of each service with automation
– Idempotency in the design of services and processes
© A. Samarin 2013
Easy recovering from errors by design
BPM for integration, v2 14
• Imagine a process fragment with 3 automation activities (A, B, and C) to be executed as a transaction; each of those activities is an invocation of an external services (not in the run-time as the coordination service); normal execution sequence is E2-A-B-C-E4
• Because those services may fail this fragment contains intermediate exception event E3 and an activity for Error Recovery Procedure (ERP); the latter may be a human activity
© A. Samarin 2013
Idempotency explained (1)
BPM for integration, v2 15
• First pass with the failure of activity B
– E2-A(done)-B(failed)-E3-ERP
• Second pass with failure of activity C
– E2-A(already done)-B(done)-C(failed)-E3-ERP
© A. Samarin 2013
Idempotency explained (2)
❻
❶ ❷
❺
❸
❹
❶ ❷
❺
❸ ❹
BPM for integration, v2 16
• Third pass with no failures
– E2-A(already done)-B(already done)-C(done)-E4
• Activity A was executed 3 times, but it did the real work only at the first time – two other times were ignored because of idempotency
• Example of idempotent service: upload a document; if document’s place, metadata and content are the same then next upload is ignored
© A. Samarin 2013
Idempotency explained (2)
❶ ❷ ❺❸ ❹
BPM for integration, v2 17
• Any service can be in a cloud
• See also Enterprise pattern: #Cloud-Ready Estimation and Evaluation Procedure (CREEP) at http://improving-bpm-systems.blogspot.com/2011/12/enterprise-pattern-cloud-ready.html
• Any service may fail; connectivity to a cloud may fail
• If an application service has failed then the coordination service will recover via error recovery loop
• One type of failure is a timeout (because each activity has its SLA)
© A. Samarin 2013
Become friendly to cloud (1)
BPM for integration, v2 18
• If the coordination service has failed then some of running application services cannot complete their associated activities; after the restart of the coordination service, those activities will fail by timeout
• REST should be used to access resources; if a resource may change its state without the control of the process then the process must interrogate the state of such a resource before its usage
© A. Samarin 2013
Become friendly to cloud (2)
BPM for integration, v2 19
• SOA, ESB, BPM, REST, and EPN/CEP/BEM must be used together to achieve the cloud-friendly integration
• Composite services are made by the explicit coordination between other services (i.e. by processes)
• Majority of services are stateless except process-as-a-service and resource-as-a-service
• Recover from errors must be architected
© A. Samarin 2013
Conclusion
BPM for integration, v2 20© A. Samarin 2013
Thanks
BPM for integration, v2 21© A. Samarin 2013
BACKUP slides
© A. Samarin 2013 BPM for integration, v2 22
A Bx
ERP
C
E3
E2 E4
© A. Samarin 2013 BPM for integration, v2 23
ESB-centric view – only flow of data
ESB
Service 1
Service 3
Service 2
© A. Samarin 2013 BPM for integration, v2 24
Process-centric view – bothflow of control and flow of data
Process
Service 1
Service 3
Service 2
Primary importance – the result of working together, but not individual exchanges (like in the football)