1. Integration via #BPM:
become friendly to #cloud
A. Samarin

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 BPM for integration, v2 2
Related articles

3. • Technologist-driven
• Weak connection to the business tempo (famous night
batches)
• Not easy to trace, audit, maintain and evolve
© A. Samarin 2013 BPM for integration, v2 3
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

4. © A. Samarin 2013 BPM for integration, v2 4
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)
BO1
persistence service
BO2
persistence service
SOA solution

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 BPM for integration, v2 5
ESB-centric integration between
services
Service
A1
Former monolithic application A
Service
A2
Service
A3
Service
A4
Service
A5
ESB
Service
B1
Former monolithic application B
Service
B2
Service
B3
Service
B4
Service
B5

6. • Only the flow of data is traceable
• Flow of control is not explicit, although
the primary importance is the result of
working together, but not individual
exchanges (like in the football)
© A. Samarin 2013 BPM for integration, v2 6
Problems with ESB-centric integration (1)

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 BPM for integration, v2 7
Problems with ESB-centric integration (2)

8. • BPM, by revealing the artefacts and the relationships
between them, provides the necessary context (e.g.
granularity) for the definition of services
• SOA provides
recommendations
for 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 BPM for integration, v2 8
Using BPM for constructing composite
services

9. • Application services are connected (via ESB) only to the
coordination service thus removing N-to-N connectivity
© A. Samarin 2013 BPM for integration, v2 9
Making coordination explicit and
arranging services around it
Application services
Coordination service
Resource services
Aggregation services

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 BPM for integration, v2 10
Using REST to access resources
Time
Resource 3Resource 2Resource 1
Resource 4
Process instance 1

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 BPM for integration, v2 11
Using events (1)

12. • To externalise the flow of control from existing monolith
applications
© A. Samarin 2013 BPM for integration, v2 12
Using events (2)

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 BPM for integration, v2 13
Easy recovering from errors by design

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 BPM for integration, v2 14
Idempotency explained (1)

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 BPM for integration, v2 15
Idempotency explained (2)
❻
❶ ❷
❺
❸
❹
❶ ❷
❺
❸ ❹

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 BPM for integration, v2 16
Idempotency explained (2)
❶ ❷ ❺❸ ❹

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 BPM for integration, v2 17
Become friendly to cloud (1)

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 BPM for integration, v2 18
Become friendly to cloud (2)

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 BPM for integration, v2 19
Conclusion

20. © A. Samarin 2013 BPM for integration, v2 20
Thanks

21. © A. Samarin 2013 BPM for integration, v2 21
BACKUP slides

22. © A. Samarin 2013 BPM for integration, v2 22
A B
x
ERP
C
E3
E2 E4

23. © A. Samarin 2013 BPM for integration, v2 23
ESB-centric view – only flow of data
ESB
Service 1
Service 3
Service 2

24. © A. Samarin 2013 BPM for integration, v2 24
Process-centric view – both
flow 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)