Your SlideShare is downloading. ×
Cesvip 20110124
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Cesvip 20110124

275
views

Published on

EA, SOA, SLA e cloud computing - Prima lezione corso CESVIP "Tecnico di rete informatico specializzato in sicurezza delle reti"

EA, SOA, SLA e cloud computing - Prima lezione corso CESVIP "Tecnico di rete informatico specializzato in sicurezza delle reti"

Published in: Education, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. TECNICO DI RETI INFORMATICHE SPECIALIZZATO IN SICUREZZA DELLE RETI RIF. P.A. 2010 - 948/RER
  • 2. LEZIONE 1 Modelli EA (Enterprise architecture) SOA, SLA & Cloud computing
  • 3. LEZIONE 1 - Architetture e modelli di EA 1987 - “ A framework for information system architecture” by J.Zachman
  • 4. LEZIONE 1 - Architetture e modelli di EA 1987 - “ A framework for information system architecture” by J.Zachman
    • EA significa IT business-driven
    • 5. EA è una disciplina non-tecnica che studia gli aspetti strategici e architetturali dell'IT
    • 6. L'IT non è più una black-box per soli tecnici, ma un mezzo fondante per la realizzazione dei processi di business
    QUINDI.. L'IT guadagna gli stessi problemi di qualsiasi altro strumento di business:
    • Riduzione dei costi
    • 7. Eliminazione degli sprechi e delle ridondanze
    • 8. Crescita degli ecosistemi
    • 9. Risposta rapida ai cambiamenti nei BP
    • 10. Condivisione verticale delle informazioni
    • 11. BPO
    • 12. Pianificazione
    Cosa ha prodotto ciò fino ad oggi?
  • 13. LEZIONE 1 - Architetture e modelli di EA
  • 14. LEZIONE 1 - Architetture e modelli di EA 1990 – 2005 L'esplosione dei modelli di business basati sui servizi
      Se EA significa IT business-driven, allora è necessario sviluppare un nuovo modello di EA basato sui SERVIZI. Allo stesso tempo è necessario risolvere all'interno dello stesso modello i principali problemi propri di una struttura service-based:
    • Condivisione delle informazioni
    • 15. Interoperabilità
    • 16. Eliminazione delle ridondanze
    • 17. Scalabilità
    Applicando le definizioni di Zachman al nuovo modello di business sui servizi, ne risulta che....
  • 18. LEZIONE 1 - Architetture e modelli di EA Dal punto di vista non-tecnico: L'EA diventa il ponte fra business e IT tramite un insieme di servizi IT business-oriented, usando principi di design, tecniche e pattern riconosciuti, universali e modulari Che dal punto di vista dei prodotti risulta nel: Utilizzare pratiche, policy e framework che consentano alle funzionalità delle applicazioni di essere fornite/richieste con una granuralità rilevante per il richiedente, astraendo dalle implementazioni e fornendo un'unica interfaccia standard In pratica, abbiamo appena definito un modello di EA orientato ai servizi, che da ora in avanti chiameremo semplicemente...
  • 19. LEZIONE 1 - Architetture e modelli di EA SoA (Service-oriented Architecture)
  • 20. LEZIONE 1 - Architetture e modelli di EA Linee guida in SoA
    • Riutilizzo, Modularità, Interoperabilità
    • 21. Compliance degli standard (inter/intra aziendali)
    • 22. Indentificazione, categorizzazione, provisioning, pubblicazione, monitoring e tracking dei servizi
    Il che significa
    • Assoluta non-interdipendenza dei servizi ( servizi “loosely coupled”)
    • 23. Allineamento ai processi di business aziendali
    • 24. Relazioni on-demand fra i componenti
    • 25. Agilità strutturale: riconfigurabilità istantanea dei BP
    • 26. Azzeramento di sprechi/ridondanze
    • 27. Condivisione estrema delle informazioni
  • 28. LEZIONE 1 - Architetture e modelli di EA Modello concettuale di fruizione dei servizi in SoA
  • 29. LEZIONE 1 - Architetture e modelli di EA Ruolo dei servizi in SoA
  • 30. LEZIONE 1 - Architetture e modelli di EA I Web Services, ovvero l'anima della SoA Definizione del W3C:
      “ A Web Service is software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."
  • 31. LEZIONE 1 - Architetture e modelli di EA Architettura di un Web Service E' ancora possibile definire tutto questo come semplice software? La risposta è NO , abbiamo bisogno di una nuova definizione. Perchè ora software e il concetto di servizio sono intimamente legati
  • 32. LEZIONE 1 - Architetture e modelli di EA Esempio WSDL di descrizione di un servizio: <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <wsdl:definitions targetNamespace=&quot;http://www.example.com/webservice&quot; xmlns:tns=&quot;http://www.example.com/webservice&quot; xmlns:http=&quot;http://schemas.xmlsoap.org/wsdl/http/&quot; xmlns:mime=&quot;http://schemas.xmlsoap.org/wsdl/mime/&quot; xmlns:ws=&quot;http://www.example.com/webservice&quot;> <!-- Placeholder for message definitions --> <wsdl:message name=&quot;insertMessageName&quot;> <!-- <wsdl:part name=&quot;paramName&quot; type=&quot;type&quot;/> --> </wsdl:message> <!-- Placeholder for portTypes (operations) --> <wsdl:portType name=&quot;portName&quot;> <wsdl:operation name=&quot;operationName&quot;> <wsdl:input message=&quot;tns:operationRequest&quot;/> <wsdl:output message=&quot;tns:operationResponse&quot;/> </wsdl:operation> </wsdl:portType>
  • 33. LEZIONE 1 - Architetture e modelli di EA <!-- Placeholder for binding. Define operation style(Document) and bind port to messages. --> <!--Document Style --> <wsdl:binding name=&quot;bindingName&quot; type=&quot;tns:portName&quot;> <soap:binding style=&quot;document&quot; transport=&quot;http://schemas.xmlsoap.org/soap/http&quot;/> <wsdl:operation name=&quot;operationName&quot;> <soap:operation/> </wsdl:operation> </wsdl:binding> <!-- Placeholder for service definition--> <wsdl:service name=&quot;HelloWorldService&quot;> <wsdl:port binding=&quot;tns:bindingName&quot; name=&quot;serviceName&quot;> <soap:address location=&quot;http://localhost:8080/serviceName&quot;/> </wsdl:port> </wsdl:service> </wsdl:definitions>
  • 34. LEZIONE 1 - Architetture e modelli di EA SaaS (Software-as-a-service) “ SaaS - Software-as-a-Service is a model of software deployment whereby a provider licenses an application to customers for use as a service on demand.” Ma possiamo estendere questo concetto a tutte le componenti del nostro processo: DaaS - Data as a service SaaS - Sofware as a service PaaS - Platform as a service E se volessi che l'intera infrastruttura fosse “as a service”? Significherebbe dover eliminare i vincoli spaziali, ovvero poter fornire la PaaS in un contesto remoto, senza alcun vincolo legato alla disposizione fisica delle componenti, mantenendo tutti i punti considerati finora (Loose coupling, Interoperabilità, astrazione, ecc...) Ma fermiamoci un secondo a fare il punto della situazione..
  • 35. LEZIONE 1 - Architetture e modelli di EA SLA (Service level agreement) In una architettura orientata ai servizi, l'unico metodo per valutare il mio lavoro è ovviamente.... LA DISPONIBILITA' DEL SERVIZIO Il driver principale nella definizione dei miei processi diventa quindi lo SLA. Che ora in poi diventerà l'unico criterio valido per effettuare la definizione dei processi, e la conseguente scelta di topologie, soluzioni, hardware..
  • 36. LEZIONE 1 - Architetture e modelli di EA Le conseguenze della SoA
      Con l'orientamento ai servizi, 'approccio al design tecnico si trasforma da top-down a bottom-up, con tutti i rischi derivanti
  • 37. LEZIONE 1 - Architetture e modelli di EA Le conseguenze della SoA
      Con servizi “loosely coupled” aumenta la flessibilità ma anche la complessità/eterogeneità del sistema, con l'impossibiltà di prevedere a priori l'interazione fra gli elementi, e di stimarne i risultati
  • 38. Il rischio reale è quindi quello di trovarsi in questa situazione: L'evoluzione della nostra SOA non potrà avvenire se questi gap non saranno curati. Questo perchè il naturale affinamento della SOA, come abbiamo detto prima, prevede esclusivamente livelli di astrazione maggiori, per raggiungere l'obbiettivo di IaaS
  • 39. SoA come IaaS (cloud computing)
  • 40. LEZIONE 1 - Architetture e modelli di EA Cloud computing Cloud computing = IT a a service Insieme di tecnologie che permettono l'utilizzo di risorse hardware e software distribuite senza vincoli rispetto al posizionamento dell'utente. Ciò significa:
    • Estensione delle risorse utilizzabili anche al di fuori del confine fisico del datacenter (“deperimetrizzazione”)
    • 41. Estensione del “loose-coupling” all'infrastruttura fisica
    • 42. Aumento dei requisiti di sicurezza (superamento barriere aziendali)
    • 43. Scomponimento fisico del datacenter ( es: SOA monolitica vs SOA federata)
    • 44. Nuovo metodo di sviluppo delle applicazioni ( utilizzo dei concetti di DaaS e SaaS sin dal design applicativo)
    • 45. Come costruiremo quindi la nostra infrastruttura?.
  • 46. LEZIONE 1 - Architetture e modelli di EA