• Save
20060627 SOA @JavaConference2006 Milano-IT [ITA]
Upcoming SlideShare
Loading in...5
×
 

20060627 SOA @JavaConference2006 Milano-IT [ITA]

on

  • 377 views

We had just finished a series of projects where we applied SOA working in an emerging way for both software and hardware.

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

Statistics

Views

Total Views
377
Views on SlideShare
373
Embed Views
4

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

20060627 SOA @JavaConference2006 Milano-IT [ITA] 20060627 SOA @JavaConference2006 Milano-IT [ITA] Presentation Transcript

  • DESIGN, ARCHITETTURA E PROCESSO PER REALIZZARE EFFICACI SERVICE ORIENTED ARCHITECTURE Francesco Cirillo CEO XPLabs SRL
  • 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
  • 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à
  • 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? ...
  • L'Architettura Narcisista:
  • L'Architettura Narcisista:
  • I Principi:  Separation of Concern  Sostituibilità  Distribuzione delle responsabilità
  • Separare le parti funzionali da quelle non funzionali:
  • Attenti al Super Narcisista:
  • 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? ...
  • Arrivare ai Servizi:
  • Il Narcisista dallo psicologo di Jacobson:
  • Arrivare ai Servizi:
  • Arrivare ai Servizi:
  • 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? ...
  • Organizzare l'architettura fisica in modo distribuito:
  • Organizzare l'architettura fisica in modo distribuito:
  • Organizzare l'architettura fisica in modo distribuito:  La filosofia della distribuzione  Per n servizi...  Opzioni di architettura •Costi •Trade-off tra Quality of Service
  • 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?
  • Organizzare il Back-End per la scalabilità:  Transaction Load  Transaction Scope  Read-Write Ratio
  • Scalare i Servizi più usati:
  • 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?
  • Il Processo - Costruire in modo Agile:  Partire da un nucleo  Simulare i clienti concorrenti  Aggiungere strati non funzionali  Integrare funzionalità
  • Il Processo - Costruire in modo Agile:  Partire da un nucleo  Simulare i clienti concorrenti  Aggiungere strati non funzionali  Integrare funzionalità
  • Il Team – Costruire con responsabilità incrementali:  Per Servizio  Per tipo di requisito
  • Conclusioni:  Creare Architetture Orientate ai Servizi prescinde dalle tecnologie  Strutturare applicazioni in modo più efficace •Trade-off -> Equilibrio  Processi più “Agili”  Team più “responsabili”
  • Domande?