We had just finished a series of projects where we applied SOA working in an emerging way for both software and hardware. Sun asked us to explain what we had done and why. OK! :-)

1. DESIGN, ARCHITETTURA E PROCESSO
PER REALIZZARE EFFICACI
SERVICE ORIENTED ARCHITECTURE
Francesco Cirillo
CEO
XPLabs SRL

2. Obiettivi:
 Creare Architetture Orientate ai Servizi senza dipendere dalle tecnologie
 Strutturare applicazioni in modo più efficace
 Definire criteri per scegliere il Processo
 Definire criteri per organizzare il Team

3. Il Contesto:
 Business Case -> Use Case
 Capacità di crescita
•Presto e frequentemente sul mercato
•Cambiamento requisiti funzionali
•Flessibilità
•Estensibilità
•Cambiamento requisiti non funzionali
•Scalabilità
•Affidabilità
•Manutenibilità

4. Il Problema – Cosa succede se:
 Si devono integrare nuove tecnologie?
 Dobbiamo aggiungere nuove funzionalità di business?
 Si rompe un nodo della nostra architettura...
 Passiamo da 10 a 10x1.000 utenti concorrenti? ...

5. L'Architettura Narcisista:

6. L'Architettura Narcisista:

7. I Principi:
 Separation of Concern
 Sostituibilità
 Distribuzione delle responsabilità

8. Separare le parti funzionali da quelle non funzionali:

9. Attenti al Super Narcisista:

10. Il Problema – Cosa succede se:
 Si devono integrare nuove tecnologie?
 Dobbiamo aggiungere nuove funzionalità di business?
 Si rompe un nodo della nostra architettura...
 Passiamo da 10 a 10x1.000 utenti concorrenti? ...

11. Arrivare ai Servizi:

12. Il Narcisista dallo psicologo di Jacobson:

13. Arrivare ai Servizi:

14. Arrivare ai Servizi:

15. Il Problema – Cosa succede se:
 Si devono integrare nuove tecnologie?
 Dobbiamo aggiungere nuove funzionalità di business?
 Si rompe un nodo della nostra architettura...
 Passiamo da 10 a 10x1.000 utenti concorrenti? ...

16. Organizzare l'architettura fisica in modo distribuito:

17. Organizzare l'architettura fisica in modo distribuito:

18. Organizzare l'architettura fisica in modo distribuito:
 La filosofia della distribuzione
 Per n servizi...
 Opzioni di architettura
•Costi
•Trade-off tra Quality of Service

19. Il Problema – Cosa succede se:
 Si devono integrare nuove tecnologie?
 Dobbiamo aggiungere nuove funzionalità di business?
 Si rompe un nodo della nostra architettura...
 Passiamo da 10 a 10x1.000 utenti concorrenti?

20. Organizzare il Back-End per la scalabilità:
 Transaction Load
 Transaction Scope
 Read-Write Ratio

21. Scalare i Servizi più usati:

22. Il Problema – Cosa succede se:
 Si devono integrare nuove tecnologie?
 Dobbiamo aggiungere nuove funzionalità di business?
 Si rompe un nodo della nostra architettura...
 Passiamo da 10 a 10x1.000 utenti concorrenti?

23. Il Processo - Costruire in modo Agile:
 Partire da un nucleo
 Simulare i clienti concorrenti
 Aggiungere strati non funzionali
 Integrare funzionalità

24. Il Processo - Costruire in modo Agile:
 Partire da un nucleo
 Simulare i clienti concorrenti
 Aggiungere strati non funzionali
 Integrare funzionalità

25. Il Team – Costruire con responsabilità incrementali:
 Per Servizio
 Per tipo di requisito

26. Conclusioni:
 Creare Architetture Orientate ai Servizi prescinde dalle tecnologie
 Strutturare applicazioni in modo più efficace
•Trade-off -> Equilibrio
 Processi più “Agili”
 Team più “responsabili”

27. Domande?