Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Alberto lagna soa that works

372 views

Published on

  • Be the first to comment

  • Be the first to like this

Alberto lagna soa that works

  1. 1. SOA that works By Alberto Lagna CTO Biznology srl
  2. 2. >apropos alberto.lagna • Computer Science graduate, Telco master • CTO of Biznology • Working as software architect / team leader • Consulting on design and development of enterprise systems mainly based on JavaEE and mobile • UML, XML, BPM expert • 18 years of working experience in Europe and USA • JUGTorino member • Promoting the use of free software and supporting the open source movement2
  3. 3. >apropos biznology.it Organization • Consulting Company Model and Methodology Training and tools • Defined a SOA at 360° approach: Plans – Methodology and tools Economical Goal and Reference – Reference Architecture Result Architecture measuremen – Communication ts – Integration and Program Management Integration Communicati – Economical Goal and Result Measurement and Program on Management – Organization Model and Training Plans • Because Applying the SOA approach is not ONLY using the right technology3
  4. 4. Agenda • Complex integration system developed – Electronic Health Folder – Regional Administration Accounting System • System requirements • Pattern applied: – Data dictionary – Service Interface Design – Materialisation / Dematerialisation – Business Object Views – Divide et Impera between services – Versioning – Logging and Monitoring4
  5. 5. Warning UML - ACTIVE5
  6. 6. Complex Integration Systems (1) Electronic Health Folder ASO OSP 1 ASO OSP 1 ASO OSP 16
  7. 7. Complex Integration Systems (2) Regional Administration Accounting System !7
  8. 8. System Requirements (1) • Integrate many (existing) systems – Consume eterogeneous interfaces • Exposed even by legacy C, C++, VB, systems – Expose long lasting interfaces • They cannot change too often: consumed by systems developed in different projects, by different vendors8
  9. 9. System Requirements (2a) • Integrate the Service Oriented world (mainly wso2) with the BPMS world (not wso2) – BPMN processes call Service interfaces – Provide a way to decouple the lifecycle of the BPMN processes with the service business entities9
  10. 10. System Requirements (2b)10
  11. 11. System Requirements (3) • Services could exchange Business Object that can be part of a big forest in a selective way – I don’t want to transport the whole Amazonian if I need just to transport a small tree11
  12. 12. System Requirements (4) • Big Bang strategy must be avoided, therefore we need to define: – a way to develop, test and deploy the system in small parts – a roadmap to program when to roll out every part12
  13. 13. System Requirements (5a) • What if something goes wrong? – Need a way to understand • Why a component XYZ did a certain call to a service (that went in error for example) • What were the calls that brought to the error Exception in thread "main" java.lang.NoSuchMethodError: org.apache.commons.httpclient.HttpConnectionManager.getParams()Lorg/apache/commons/httpclient/params /HttpConnectionManagerParams; at org.apache.axis2.transport.http.AbstractHTTPSender.initializeTimeouts(AbstractHTTPSender.java:454) at org.apache.axis2.transport.http.AbstractHTTPSender.getHttpClient(AbstractHTTPSender.java:514) at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:156)13
  14. 14. System Requirements (5b)14
  15. 15. System Architecture • Regional Administration Accounting System BIL module siac15
  16. 16. Patterns Applied • To fulfill all the given requirements, the following patterns were applied: – Business Objects level • Data Dictionary • Service Interface Design • Materialisation / Dematerialisation • Business Object Views – Service Level • Divide et Impera between Services • Versioning • Logging and Monitoring16
  17. 17. Pattern 1: Data Dictionary (1) • To integrate with differents systems, technologies • Divided the whole system into – Functional areas – Integration areas • Every area is responsible of a – Subset of Business Objects – Subset of (homogeneous) services • Business Objects – are the ONLY objects used within the system – They become the Lingua Franca of the system17 – Need MAXIMUM care to be designed
  18. 18. Pattern 1: Data Dictionary (2) SIAC ALI Atti Liquidazione BIL - Bilancio di previsione e pluriennale GSA SocioAssistenziale ATT - Atti Amministrativi GEN - Contabilità Generale APJ - Approvvigionamenti FIN – Contabilità finanziaria PER Gestione Personale SCD - Contabilità Divisionale FPR Formazione Professionale FIS – Adempimenti Fiscali IVA Contabilità IVA18
  19. 19. Pattern 2: Service Interface Design • The service messages are containers of Business Objects • The integration services do translation to/from the Business Objects19
  20. 20. Pattern 3: Materialisation / Dematerialisation (1) • To decouple The BPMN Process lifecycles with the Business Objects lifecicles • The Proxy before the Processes Dematerialise the objects • The Proxy after the Processes Materialise the objects siac20
  21. 21. Pattern 3: Materialisation / Dematerialisation (2) • The BPMN Processes use Dematerialised Entities EntitaDem (instead of VariazioneCapitolo) with the following attributes: • uuid = 1234 • nome = acme • className = “it.csi.siac.siacbilser.interfacews.dd.VariazioneCapitolo” • attributes ={ • {“tipo”, DIFFICULT} }21
  22. 22. Pattern 3: Materialisation / Dematerialisation (3) • The BPMN Processes use Dematerialised Entities22
  23. 23. Pattern 4: Business Object Views (1) • Not to always move the whole Amazonian Forest if only a tree is needed • Data Services also accept the View parameter that tells which part of the forest to carry.23
  24. 24. Pattern 4: Business Object Views (2)24
  25. 25. Pattern 4: Business Object Views (3) • The view object: – name: VariazioneCapitolo4BPM – className: VariazioneCapitolo – attributiVisibili: • descrizione • competenza • provvediamento, Provvedimento4BPM25
  26. 26. Pattern 5: Divide et Impera (1) • To be able to Manage (=Imperare) the whole system every Area provides his Data Dictionary library with – The service interfaces – The service clients – A fake service implementation • Divide – Every service can be tested stand alone, with the fake services of the other areas that it needs – Some real services can be added and a limited integration test can be run27
  27. 27. Pattern 5: Divide et Impera (2) SIAC ALI Atti Liquidazione BIL - Bilancio di previsione e pluriennale GSA SocioAssistenziale ATT - Atti Amministrativi GEN - Contabilità Generale APJ - Approvvigionamenti FIN – Contabilità finanziaria PER Gestione Personale SCD - Contabilità Divisionale FPR Formazione Professionale FIS – Adempimenti Fiscali IVA Contabilità IVA28
  28. 28. Pattern 6: Versioning (1) • Service Versioning options: – use an (optional) attribute at the xs:schema element – denoting the schema version in XML namespaces – keep XML namespace values constant and add a special element for grouping custom extensions @see B. Lublinsky, Versioning in SOA http://msdn.microsoft.com/en-us/library/bb491124.aspx • We choose the namespace level • The Data Dictionary (jar) – Is of a specific Area of a specific Version29 – Contains Service Interfaces and Clients
  29. 29. Pattern 6: Versioning (2) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <definitions targetNamespace="http://siac.it/fin/svc/1.0" name="ImpegnoService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://siac.it/fin/svc/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <types> <xsd:schema> <xsd:import namespace="http://siac.csi.it/fin/svc/1.0" schemaLocation="ImpegnoService-1.0.xsd"/> </xsd:schema> <xsd:schema> <xsd:import namespace="http://siac.it/fin/data/1.0" schemaLocation=fin-1.0.xsd"/> </xsd:schema> <xsd:schema> <xsd:import namespace="http://siac.it/cor/data/1.0" schemaLocation=”cor-1.0.xsd"/> </xsd:schema> </types>30
  30. 30. Pattern 7: Logging and Monitoring (1) • Every request and response contains at least – User, with his profile – Operation Token (TokenOperazione class below) • No SOAP Fault31
  31. 31. Pattern 7: Logging and Monitoring (2) • How does the Operation Token work? siac n+1" n+1.1.1.1.1" n" n+1.1" n+1.1.1" n.1"32
  32. 32. Pattern 7: Logging and Monitoring (3) • Using a log aggregator the logs can be easily read and composed33
  33. 33. The patterns are related together • Business Objects level – Data Dictionary – Service Interface Design – Materialisation / Dematerialisation – Business Object Views • Service Level – Divide et Impera between Services – Versioning – Logging and Monitoring34
  34. 34. Good book to read • Applied SOA, Mike Rosen http://www.amazon.com/Applied-SOA-Service- Oriented-Architecture-Strategies/dp/0470223650 • BPMN Method & Style, Bruce Silver www.bpmessentials.com35
  35. 35. Thank youalberto.lagna@biznology.it

×