Integration via #BPM: become friendly to #cloud


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Integration via #BPM: become friendly to #cloud

  1. 1. Integration via #BPM:become friendly to #cloudA. Samarin
  2. 2. 1. #bpm for developers: improve #agility ofimplementations Addressing #security concerns through #BPM at© A. Samarin 2013 BPM for integration, v2 2Related articles
  3. 3. • Technologist-driven• Weak connection to the business tempo (famous nightbatches)• Not easy to trace, audit, maintain and evolve© A. Samarin 2013 BPM for integration, v2 3Integration practices without SOAMonolithic application 1Presentation layerBusiness logic layerPersistence layerMonolithic application 2Presentation layerBusiness logic layerPersistence layerClient-base integrationFunctional API integrationData-centric integration
  4. 4. © A. Samarin 2013 BPM for integration, v2 4From monolithic applications to universallyinterconnected and interdependent servicesMonolithic applicationGUI screen 2GUI screen 1 GUI screen 3Business logicBO1 persistence BO2 persistenceBusinesslogic serviceInteractiveservice 1Interactiveservice 2Interactiveservice 3Enterprise Service Bus (ESB)BO1persistence serviceBO2persistence serviceSOA solution
  5. 5. • As all applications are constructed in SOA way (servicesand ESB) then the integration looks like plugging mobilephones to the telephone network© A. Samarin 2013 BPM for integration, v2 5ESB-centric integration betweenservicesServiceA1Former monolithic application AServiceA2ServiceA3ServiceA4ServiceA5ESBServiceB1Former monolithic application BServiceB2ServiceB3ServiceB4ServiceB5
  6. 6. • Only the flow of data is traceable• Flow of control is not explicit, althoughthe primary importance is the result ofworking together, but not individualexchanges (like in the football)© A. Samarin 2013 BPM for integration, v2 6Problems with ESB-centric integration (1)
  7. 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• Only ESB is not enough; what to add?© A. Samarin 2013 BPM for integration, v2 7Problems with ESB-centric integration (2)
  8. 8. • BPM, by revealing the artefacts and the relationshipsbetween them, provides the necessary context (e.g.granularity) for the definition of services• SOA providesrecommendationsfor the implementation,execution and governanceof 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 8Using BPM for constructing compositeservices
  9. 9. • Application services are connected (via ESB) only to thecoordination service thus removing N-to-N connectivity© A. Samarin 2013 BPM for integration, v2 9Making coordination explicit andarranging services around itApplication servicesCoordination serviceResource servicesAggregation services
  10. 10. • Each resource has its own life-cycle• Many variants of duration process instance vs. resourcelife-cycle• REST helps to check the state of a resource• REST helps to implement idempotency© A. Samarin 2013 BPM for integration, v2 10Using REST to access resourcesTimeResource 3Resource 2Resource 1Resource 4Process instance 1
  11. 11. • To decouple processes• See also EPN and BPMN Explicit event processingagents in BPMN? at• EPN, CEP, BEM are important© A. Samarin 2013 BPM for integration, v2 11Using events (1)
  12. 12. • To externalise the flow of control from existing monolithapplications© A. Samarin 2013 BPM for integration, v2 12Using events (2)
  13. 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 withautomation– Idempotency in the design of services and processes© A. Samarin 2013 BPM for integration, v2 13Easy recovering from errors by design
  14. 14. • Imagine a process fragment with 3 automation activities(A, B, and C) to be executed as a transaction; each ofthose activities is an invocation of an external services(not in the run-time as the coordination service); normalexecution sequence is E2-A-B-C-E4• Because those services may fail this fragment containsintermediate exception event E3 and an activity for ErrorRecovery Procedure (ERP); the latter may be a humanactivity© A. Samarin 2013 BPM for integration, v2 14Idempotency explained (1)
  15. 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 15Idempotency explained (2)❻❶ ❷❺❸❹❶ ❷❺❸ ❹
  16. 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 workonly at the first time – two other times were ignoredbecause of idempotency• Example of idempotent service: upload a document; ifdocument’s place, metadata and content are the samethen next upload is ignored© A. Samarin 2013 BPM for integration, v2 16Idempotency explained (2)❶ ❷ ❺❸ ❹
  17. 17. • Any service can be in a cloud• See also Enterprise pattern: #Cloud-ReadyEstimation and Evaluation Procedure (CREEP) at• Any service may fail; connectivity to a cloud may fail• If an application service has failed then the coordinationservice will recover via error recovery loop• One type of failure is a timeout (because each activity hasits SLA)© A. Samarin 2013 BPM for integration, v2 17Become friendly to cloud (1)
  18. 18. • If the coordination service has failed then some ofrunning application services cannot complete theirassociated activities; after the restart of the coordinationservice, those activities will fail by timeout• REST should be used to access resources; if a resourcemay change its state without the control of the processthen the process must interrogate the state of such aresource before its usage© A. Samarin 2013 BPM for integration, v2 18Become friendly to cloud (2)
  19. 19. • SOA, ESB, BPM, REST, and EPN/CEP/BEM must be usedtogether to achieve the cloud-friendly integration• Composite services are made by the explicit coordinationbetween 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 19Conclusion
  20. 20. © A. Samarin 2013 BPM for integration, v2 20Thanks
  21. 21. © A. Samarin 2013 BPM for integration, v2 21BACKUP slides
  22. 22. © A. Samarin 2013 BPM for integration, v2 22A BxERPCE3E2 E4
  23. 23. © A. Samarin 2013 BPM for integration, v2 23ESB-centric view – only flow of dataESBService 1Service 3Service 2
  24. 24. © A. Samarin 2013 BPM for integration, v2 24Process-centric view – bothflow of control and flow of dataProcessService 1Service 3Service 2Primary importance – the result of working together, but notindividual exchanges (like in the football)