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 movement
2
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 technology
3
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 Monitoring
4
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 vendors
8
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 entities
9
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 tree
11
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 part
12
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
15. System Architecture
• Regional Administration Accounting System BIL
module
siac
15
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 Monitoring
16
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 system
17 – Need MAXIMUM care to be designed
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à IVA
18
19. Pattern 2: Service Interface Design
• The service messages are containers of Business Objects
• The integration services do translation to/from the Business
Objects
19
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
siac
20
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. Pattern 3:
Materialisation / Dematerialisation (3)
• The BPMN Processes use Dematerialised Entities
22
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
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 run
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à IVA
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 Version
29 – Contains Service Interfaces and Clients
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 Fault
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. Pattern 7: Logging and Monitoring (3)
• Using a log aggregator the logs can be easily read and
composed
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 Monitoring
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.com
35