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.

20060627 SOA @JavaConference2006 Milano-IT [ITA]

464 views

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
  • Be the first to comment

  • Be the first to like this

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?

×