20060627 SOA @JavaConference2006 Milano-IT [ITA]

323
-1

Published on

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! :-)

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
323
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

20060627 SOA @JavaConference2006 Milano-IT [ITA]

  1. 1. DESIGN, ARCHITETTURA E PROCESSO PER REALIZZARE EFFICACI SERVICE ORIENTED ARCHITECTURE Francesco Cirillo CEO XPLabs SRL
  2. 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. 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. 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. 5. L'Architettura Narcisista:
  6. 6. L'Architettura Narcisista:
  7. 7. I Principi:  Separation of Concern  Sostituibilità  Distribuzione delle responsabilità
  8. 8. Separare le parti funzionali da quelle non funzionali:
  9. 9. Attenti al Super Narcisista:
  10. 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. 11. Arrivare ai Servizi:
  12. 12. Il Narcisista dallo psicologo di Jacobson:
  13. 13. Arrivare ai Servizi:
  14. 14. Arrivare ai Servizi:
  15. 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. 16. Organizzare l'architettura fisica in modo distribuito:
  17. 17. Organizzare l'architettura fisica in modo distribuito:
  18. 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. 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. 20. Organizzare il Back-End per la scalabilità:  Transaction Load  Transaction Scope  Read-Write Ratio
  21. 21. Scalare i Servizi più usati:
  22. 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. 23. Il Processo - Costruire in modo Agile:  Partire da un nucleo  Simulare i clienti concorrenti  Aggiungere strati non funzionali  Integrare funzionalità
  24. 24. Il Processo - Costruire in modo Agile:  Partire da un nucleo  Simulare i clienti concorrenti  Aggiungere strati non funzionali  Integrare funzionalità
  25. 25. Il Team – Costruire con responsabilità incrementali:  Per Servizio  Per tipo di requisito
  26. 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. 27. Domande?

×