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)
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.
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="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://www.example.com/webservice" xmlns:tns="http://www.example.com/webservice" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:ws="http://www.example.com/webservice"> <!-- Placeholder for message definitions --> <wsdl:message name="insertMessageName"> <!-- <wsdl:part name="paramName" type="type"/> --> </wsdl:message> <!-- Placeholder for portTypes (operations) --> <wsdl:portType name="portName"> <wsdl:operation name="operationName"> <wsdl:input message="tns:operationRequest"/> <wsdl:output message="tns:operationResponse"/> </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="bindingName" type="tns:portName"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="operationName"> <soap:operation/> </wsdl:operation> </wsdl:binding> <!-- Placeholder for service definition--> <wsdl:service name="HelloWorldService"> <wsdl:port binding="tns:bindingName" name="serviceName"> <soap:address location="http://localhost:8080/serviceName"/> </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.
37.
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