Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
PubblicatoBeniamino Marino Modificato 8 anni fa
1
La metodologia Insirio a supporto dei processi di migrazione: da Client/Server a SOA … direzione Grid Computing Angelo Zaia Ph.D. Inquadro – Insirio Innovazioni
2
Applicazione Web
3
Applicazione Web 2
4
Applicazione Web 3
5
Funzioni
6
Gestione dei Processi
7
Perché SOA
8
Publish Find Service – Oriented Architecture Service Broker Service Broker Service Consumer Service Consumer Client Interact Service Contract … Service Contract … Service Provider Service Provider Service
9
Business Process Execution Language BPEL è un linguaggio XML-Based utilizzato per la descrizione formale di processi industriali e/o commerciali. La sua struttura permette la suddivisione dei compiti tra vari attori. Un'applicazione BPEL viene invocata come WebSerivice e comunica con le applicazioni esterne invocando altri WebService. BPEL si occupa dunque di coordinare ed organizzare un insieme di WebService.
10
Linguaggio BPEL Un Processo Business viene descritto in linguaggio BPEL attraverso una serie di attività, che possono essere semplici o strutturate. Semplici: rappresentano azioni (invocazione di servizi, attesa di risposte, assegnazione di valori) Strutturare: raggruppano attività semplici per esprimere cicli, condizioni, operazioni sequenziali, operazioni concorrenti, etc…) I processi vengono descritti attraverso un’unica attività strutturata di tipo sequenziale (top-level activity) BPEL permette di raggruppare insieme quelle attività che rappresentano un transazione atomica. Il processo può terminare unicamente con uno stato di abort o di commit senza stati intermedi
11
BPEL Workflow BPEL è adatto alla modellazione di workflow completamente automatizzati.. Con l’utilizzo di strumenti grafici, BPEL consente di descrivere un processo astratto trasformando in codice di programmazione una modellazione grafica che contiene la semantica descrivibile con i costrutti di UML.
12
Il punto di arrivo... Grid Computing Il paradigma Grid possiede il potenziale di cambiare completamente le modalità di calcolo e l'accesso ai dati. Calcolo Distribuito su infrastruttura decentralizzata e disomogenea Gestione dinamica delle risorse Disponibilità delle risorse di calcolo paragonabili a quella della rete di distribuzione elettrica (Power Grid) Nato dalla constatazione che l'utilizzo delle risorse informatiche di una organizzazione è pari a circa il 5% delle sue potenzialità Grid è largamente intesa come il prossimo passo nelle infrastrutture IT. Local Area Grid, Enterprise Grid Metropolitan Area Grid Global Area Grid Nel 2004 è stato emanato WSRF (Web Services Resource Framework), che regolamenta l'accesso alle risorse Grid.
13
'g' La ' g ' sta per Grid
14
Enterprise Grid Computing Grid è ampiamente utilizzata nella comunità scientifica per applicazioni di elaborazione ed immagazzinamento di enormi quantità di dati. La più importante Grid europea è EGEE, coordinata dal CERN Grid, come il World Wide Web negli anni novanta, si sta muovendo verso gli ambiti aziendali. Il concetto di Enterprise Grid Computing non si riferisce alla nozione accademica di Grid. Le Enterprise Grid non sono necessariamente: Non strutturate Non limitate Le Enterprise Grid utilizzano le Grid commodity per: Aumentare la gestibilità Aumentare la capacità di reazione e la flessibilità Ridurre i costi
15
Enterprise Grid Computing secondo Oracle Per 40 anni il mainframe è stato leader indiscusso per prestazioni e affidabilità. Ma ora è arrivato il momento di Oracle Grid. Un gruppo di server a basso costo connessi dal software Oracle. Oracle Grid esegue le applicazioni con una rapidità superiore a quella del più veloce mainframe. In caso di guasto di uno dei server, Oracle Grid rimane in esecuzione mentre il mainframe è costretto all'inattività. Mainstay Partners ha divulgato uno studio secondo cui i clienti Oracle Grid Computing ottengono un ROI del 150% in 5 anni.
16
SOA
17
SOA – Cosa ci spinge ad adottarla (1) Il passaggio dalle applicazioni Client-Server alle applicazioni distribuite e alle architetture a componenti ha mostrato i suoi limiti nelle problematiche complesse, se sommati alle problematiche di integrazione. Sorgono problematiche architetturali legate alla crescente massa di applicazioni, all’accavallarsi delle tecnologie e al crescere delle interazioni tra applicazioni diverse.
18
SOA – Cosa ci spinge ad adottarla (2) Necessità di elaborare nuove “Best-Practice” e fare evolvere i vecchi modelli. Il sistema informativo deve essere agile e facilmente adattabile alle esigenze di business. Apportare Evoluzioni, non Rivoluzioni.
19
SOA – Service Oriented Architecture (1) Definizione di OASIS (Organitation for the Advancement of Structured Information Standards) “Un paradigma per l'organizzazione e l'utilizzazione delle risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili.”
20
SOA – Service Oriented Architecture (2) Obiettivi Preposti Re-ingegnerizzazione dei sistemi attuali mediante l’adozione di un modello strutturale in grado di mettere in primo piano i “servizi”. Virtuale disaccoppiamento dei servizi dall’infrastruttura. Riduzione al minimo dei disagi per l'infrastruttura esistente, in modo da ridurre i rischi e consentire una implementazione scalare. Ogni azienda, adottando tale modello strutturale, può evolversi verso un'architettura flessibile e standardizzata, senza sottoporsi ad onerosi ed invasivi processi di smantellamento e sostituzione.
21
SOA – Service Oriented Architecture (3) Princìpi Cardine Non è legata ad un’architettura specifica. Totale assenza di “business logic” sui client SOA: questi sono totalmente agnostici rispetto alla piattaforma di implementazione. Implementazione mediante l’uso dei Web Service e del linguaggio di definizione dei servizi WSDL.
22
SOA – Service Oriented Architecture (4) Specifiche Architetturali Service Encapsulation: molti Web-Services sono già consolidati per essere utilizzati all’interno di un’architettura SOA. Service Loose Coupling: le relazioni mantenute devono minimizzare le dipendenze tra i servizi. Service contract: le regole per la fornitura di servizi devono essere concordate e definite da uno o più documenti. Service Abstraction: la logica dei servizi deve essere nascosta all’esterno.
23
SOA – Service Oriented Architecture (5) Specifiche Architetturali Service Reusability: i servizi devono essere concepiti in previsione di un riutilizzo. Service Composability: un insieme di servizi possono essere coordinati per creare un servizio composto. Service Autonomy: i servizi sono progettati per essere utilizzati autonomamente. Service Discoverability: i servizi sono progettati per essere reperibili e accessibili attraverso meccanismi di discovery.
24
SOA – Service Oriented Architecture (6) Linguaggio comune XML. I messaggi vengono scambiati mediante SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Calling). Un fornitore di servizi può essere interrogato mediante WSDL (standard di descrizione del Web Service). È possibile implementare servizi conformi all’architettura SOA usando tecnologie service-based come Jini, CORBA o REST.
25
SOA – Service Oriented Architecture (7) SOA, Web 2.0, and mashups Il Web 2.0 si riferisce alla seconda generazione di siti web. Le applicazioni WEB 2.0 tipicamente includono interfacce utente: Ajax Flash JavaFX Blogs Wikis
26
SOA – Service Oriented Architecture (8) Vantaggi e Svantaggi La gestione è centralizzata e l’uso dei servizi è distribuito L’Architettura Orientata ai Servizi consente la convergenza e la comunicazione dei servizi tra loro, permettendo lo sviluppo di nuove applicazioni in un modo più produttivo. Non ci sono sprechi di risorse: tutte le componenti o applicazioni già in uso possono essere riutilizzate e integrate nella nuova architettura. Architettura scalabile che consente l’implementazione più rapida dei nuovi progetti: la tecnologia cambia con la stessa velocità del business.
27
SOA – Service Oriented Architecture (9) Vantaggi e Svantaggi Mancanza di standard affermati per le transazioni distribuite. Potenziale perdita di performance (i dati viaggiano in formato testo con grande overhead). L’assenza di applicazioni (native o in forma binaria) con RPC si traduce in prestazioni più basse in termini di velocità di esecuzione e potenza di calcolo con il conseguente aumento dei costi.
28
SOA e GRID Grid OGSi GT2 GT1 Web HTTP WSDL, SOAP WS-* WSRF Differenti applicazioni e tecnologie XML BPEL WS-I
29
Utilizzo di Oracle Forms Si stima che il 40% delle installazioni di Oracle DB sia per Applicazioni Oracle Forms
30
Timbratura Manuale
31
Bpel Workflow. Timbratura manuale
32
Bpel Workflow. Timbratura manuale. Implementazione con Jdeveloper Le richiesta vengono acquisite tramite flussi di dati in formato XML; Il Task Service si occupa di informare, ad esempio inviando una e-mail, il Project Manager della richiesta di un impiegato; In base alla risposta del proprio superiore, ad esempio rifiutata o accettata, vengono intraprese determinate azioni; Infine l'impiegato viene informato tramite e-mail
33
Richiesta Ferie
34
Bpel Workflow. Richiesta ferie. Implementazione con Jdeveloper
35
Stampa Cedolino
36
Bpel Workflow. Richiesta cedolini. Implementazione con Jdeveloper
37
Configurazione Workflow
38
Q&A
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.