La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Sistemi Informativi DEE - Politecnico di Bari Tecnologie di implementazione Corso di ingegneria del software.

Presentazioni simili


Presentazione sul tema: "Sistemi Informativi DEE - Politecnico di Bari Tecnologie di implementazione Corso di ingegneria del software."— Transcript della presentazione:

1 Sistemi Informativi DEE - Politecnico di Bari Tecnologie di implementazione Corso di ingegneria del software

2 Sistemi Informativi DEE - Politecnico di Bari Sommario Principali architetture dei sistemi distribuiti Component based software engineering Componenti Comunicazione nei processi distribuiti Middleware Applicazioni distribuite per il web Oggetti distribuiti Servizi distribuiti

3 Sistemi Informativi DEE - Politecnico di Bari Architetture dei sistemi distribuiti Tecnologie per architetture –Client server –A oggetti distribuiti –A servizi distribuiti

4 Sistemi Informativi DEE - Politecnico di Bari Component based software engineering (CBSE) –Definizione [È il processo di definizione, implementazione e integrazione o composizione di componenti indipendenti debolmente accoppiati, nei sistemi] È nata come approccio basato sul riutilizzo per lo sviluppo di sistemi software

5 Sistemi Informativi DEE - Politecnico di Bari Elementi fondamentali Componenti indipendenti Standard dei componenti Middleware Un processo di sviluppo

6 Sistemi Informativi DEE - Politecnico di Bari Componente Definizione : –Una parte modulare, utilizzabile e sostituibile di un sistema che comprende limplementazione es espone una serie di interfacce [OMG] È un elemento costitutivo del software

7 Sistemi Informativi DEE - Politecnico di Bari Altre definizioni Un elemento software che si conforma a un modello di componente, che può essere consegnato indipendentemente e composto senza modifiche secondo uno standard di composizione –[Councill e Heineman, 2001] Ununità di composizione soltanto con interfacce definite per contratto e dipendenze esplicite di contesto. Un componente software può essere consegnato indipendentemente ed è soggetto a composizione da terze parti –[Szyperski,2002]

8 Sistemi Informativi DEE - Politecnico di Bari Caratteristiche dei componenti Standardizzato –Ogni componente deve essere conforme a un modello di componente standardizzato che definisce interfacce, metadata,documentazione, Indipendente –Non deve essere necessario utilizzare altri componenti specifici –Il codice sorgente non è disponibile, quindi il componente non deve essere compilato Componibile –Tutte le interazioni avvengono attraverso interfacce pubbliche –Deve fornire accesso esterno alle sue informazioni Consegnabile –È binario, non deve essere compilato Documentato –Deve essere specifica la sintassi e la semantica di tutte le interfacce del componente

9 Sistemi Informativi DEE - Politecnico di Bari Punti di vista Il significato del termine componente differisce a seconda del punto di vista dellingegnere del software che lo utilizza –Orientato agli oggetti Un componente contiene un insieme di classi che collaborano fra loro –Modulo (vista convenzionale) Ruoli svolti –Componente di controllo –Componente di dominio –Componente dellinfrastuttura –Orientata al processo Catalogo di componenti software esistenti, componenti progettuali o di codice disponibile

10 Sistemi Informativi DEE - Politecnico di Bari Middleware Definizione : –Una classe di tecnologie software progettate per gestire leterogeneità e la complessità nei sistemi distribuiti Si tratta di uno strato software posto tra il sistema operativo ed il software applicativo che fornisce un livello di astrazione di programmazione distribuita –Sostanzialmente si tratta di un meccanismo di comunicazione tra processi (IPC) The classical definition of an operating system is the software that makes the hardware useable. Similarly, middleware can be considered to be the software that makes a distributed system programmable. Just as a bare computer without an operating system could be programmed with great difficulty, programming a distributed system is in general much more difficult without middleware, especially when heterogeneous operation is required. Likewise, it is possible to program an application with an assembler language or even machine code, but most programmers find it far more productive to use high-level languages for this purpose, and the resulting code is of course also portable. [David E. Bakken]

11 Sistemi Informativi DEE - Politecnico di Bari Comunicazione tra processi Tecnologie software che consentono a diversi processi la comunicazione mediante scambio di dati ed informazioni –È supportata dai sistemi operativi multitasking per consentire lo scambio di dati ed informazioni tra processi anche in ambiente distribuito Si tratta di meccanismi disponibili a diversi livelli –pipe –socket –memory mapped file –chiamata di procedura remota –scambio di messaggi –mailbox Può essere realizzata –a basso livello –a livello di linguaggio di programmazione –a livello applicativo –mediante software (middleware: DBMS, Web server application server, ecc.)

12 Sistemi Informativi DEE - Politecnico di Bari Categorie di middleware Remote procedure call (RPC) –Nelle architetture client server Remote data access –Fornisce servizi simili al RPC utilizzato per accedere a basi di dati remote tramite costrutti SQL Message oriented middleware (MOM) –Astrazione del mailbox Transaction Processing monitor –Consente di eseguire transazioni in un sistema distribuito Distributed Object –Invocazione di un oggetto remoto nello spazio di indirizzi delloggetto chiamante

13 Sistemi Informativi DEE - Politecnico di Bari Modelli di componenti È la definizione degli standard per limplementazione, la documentazione e la consegna del componente Sono disponibili molti modelli di componenti, i più noti: –OMG Corba: –Microsoft.NET –Sun Enterprise Java beans

14 Sistemi Informativi DEE - Politecnico di Bari Osservazioni: Strumenti software Il successo o il fallimento del CBSE è legata alla disponibilità di software middleware

15 Sistemi Informativi DEE - Politecnico di Bari Microsoft COM (component object model) e OLE ( object linking and embedding) DCOM (distributed COM) deriva da COM e OLE con laggiunta di Microsoft transaction server e Active directory supporta eterogeneità nelluso dei linguaggi ma non a livello di sistema operativo e di fornitore COM+ generazione successiva di DCOM che semplifica notevolmente la programmazione SOAP framework basato su XML e HTTP, ha specifiche pubbliche e fornisce eterogeneità a livello di linguaggio e fornitore.NET ha eterogeneità di linguaggio e fornitore rispetto ai goal stabiliti

16 Sistemi Informativi DEE - Politecnico di Bari OMG Corba: Common Object Request Broker Architecture –Standard per oggetti distribuiti –Rappresenta il middleware più largamente diffuso –offre eterogeneità di linguaggi di programmazione e implementazioni dei fornitori CCM (corba component model)

17 Sistemi Informativi DEE - Politecnico di Bari Sun RMI: remote method invocation –Permette ad oggetti eseguiti su macchine virtuali diverse (eseguite su computer diversi) di comunicare per mezzo di chiamate a metodi remoti Java beans: –Componenti software riusabili Enterprise javabeans

18 Sistemi Informativi DEE - Politecnico di Bari Implementazione di applicazioni client /server per il web Applicazione web Definizione: Unapplicazione web è un sistema che permette ai propri utenti di eseguire una logica di business con un browser web [Conallen, 2000]

19 Sistemi Informativi DEE - Politecnico di Bari Caratteristiche generali La logica di business può risiedere sul server e/o sul client Unapplicazione web è un tipo di sistema Client/server con un sito web Un browser internet presenta le pagine web fornite dal server web Le pagine web possono essere statiche o dinamiche –Oppure una pagina può essere un modulo che lutente può riempire: form

20 Sistemi Informativi DEE - Politecnico di Bari Application server Unapplicazione web può includere un server applicativo application server per gestire la logica applicativa e monitorare lo stato dellapplicazione Il monitoraggio dello stato è unattività importante che permette di tenere traccia delle azioni dei clienti collegati

21 Sistemi Informativi DEE - Politecnico di Bari Tecniche di monitoraggio Memorizzare nel browser un indicatore cookie: –Una breve stringa di caratteri che rappresenta lo stato di un utente collegato –Timeout di sessione: È possibile imporre un timeout sullattività di un utente collegato: –ad es. se lutente non è attivo per 15 minuti il server si disconnette dal client »(il cookie può essere rimosso dalla macchina client) Permette al server web o applicativo di migliorare il monitoraggio nel caso di un numero elevato si utenti collegati

22 Sistemi Informativi DEE - Politecnico di Bari Script e applet Sono usati per rendere dinamica la pagina client. Uno script è un programma interpretato dal browser Unapplet è una componente compilata che si esegue nel contesto del browser ma ha solo un limitato accesso alle altre risorse del computer client (per ragioni si sicurezza)

23 Sistemi Informativi DEE - Politecnico di Bari Pagine server Definizione: Pagina server –una pagina web che ha script eseguiti dal server Ha accesso a tutte le risorse del server database Gestisce le sessioni con i client Imposta i cookie nel browser Costruiscono le pagine client (ossia i documenti pagina dagli oggetti business del server e li invia al client)

24 Sistemi Informativi DEE - Politecnico di Bari Accesso ai dati Per permettere a script nelle pagine server di accedere al database sono usate librerie standard Tecnologie impiegate: –Open Database Connectivity ODBC –Java Database Connectivity JDBC –Remote Data Objects RDP –ActiveX data Objects ADO

25 Sistemi Informativi DEE - Politecnico di Bari Tecnologie La tecnologie del server –Può basarsi su pagine HTML (HyperText Markup Language) contenenti script –quali ASP Active Server Pages o JSP Java Server Pages La tecnologia delle pagine web –Può essere costruita su script client (JavaScript o VBScript) –Documenti XML (eXtensible markup Language), applet Java, controlli JavaBeans o ActiveX

26 Sistemi Informativi DEE - Politecnico di Bari BCE Pattern BCE 1.suddivide la logica di unapplicazione in 3 categorie mutuamente esclusive: –Boundary –Control –Entity 2.consente una guida allidentificazione e alla rappresentazione: – dei confini tra il sistema e i suoi attori – dellinformazione usata dal sistema – della logica di controllo del sistema

27 Sistemi Informativi DEE - Politecnico di Bari Classi Boundary Identificate mediante lo stereotipo > Le classi Boundary 1.Descrivono gli oggetti che rappresentano linterfaccia tra attore e sistema –ossia delimitano il confine del sistema. 2.Isolano il sistema dai cambiamenti dellambiente esterno consentendo usabilità e interfacciamento con altri sistemi.

28 Sistemi Informativi DEE - Politecnico di Bari Classi Control Identificate mediante lo stereotipo > Le classi Control 1.Descrivono gli oggetti che percepiscono gli eventi generati dallutente e che controllano lesecuzione di un processo di business. 2.Gestiscono le interazioni tra collezioni di oggetti –pertanto coordinano il comportamento delle classi entity e ne usano i contenuti. 3.Sono indipendenti dallambiente esterno, in quanto non subiscono modifiche in seguito al cambiamento di tale ambiente e non sopravvivono allinterazione cui prendono parte.

29 Sistemi Informativi DEE - Politecnico di Bari Classi Entity Identificate mediante lo stereotipo > Le classi Entity 1.descrivono gli oggetti che rappresentano le entità del dominio applicativo. 2.sono classi passive in quanto: –i loro oggetti non avviano mai linterazione –solitamente sopravvive alla singola interazione 3.accedono direttamente al database per la raccolta dei dati da elaborare.

30 Sistemi Informativi DEE - Politecnico di Bari BCDE Lapproccio BCE richiederebbe almeno un punto di accesso al DB per ogni classe Entity il che comporterebbe almeno due svantaggi: scarso Information Hiding in caso di elevato numero di classi Entity Complesità nella comunicazione tra classi Entity e database in caso di database avente struttura differente da quella delle classi Entity (eg. DB Relazionale) Soluzione BCDE (Boundary Control Database Entity) introduce le classi Database che furniscono linterfaccia tra classi entity e database

31 Sistemi Informativi DEE - Politecnico di Bari BCE

32 Sistemi Informativi DEE - Politecnico di Bari Architettura di unApplicazione web a tre strati Tier 1 Tier 2 TCP IP protocollo accesso rete TCP IP protocollo accesso rete pagine HTML HTTP Internet HTTP Web Server Browser Internet TCP IP protocollo accesso rete Applicazione Tier 3 Livello di presentazione Livello della logica di business Livello Dati Servlet pagina HTML

33 Sistemi Informativi DEE - Politecnico di Bari Architettura n-tier Mediante unarchitettura n-Tier la logica dellapplicazione può essere maggiormente differenziata e suddivisa in base alla sua funzionalità. È possibile stratificare la logica di una generica applicazione in 5 aree distinte: User Presentation Business Integrator Data Layer

34 Sistemi Informativi DEE - Politecnico di Bari Architettura n-Tier Application server Thin client applicazioni web browser HTML applet java script rete Web server servlet JSP ASP componenti CORBA componenti DCOM componenti EJB DBMS Servizi comuni connettività a database naming e directory service gestione delle transazioni comunicazione remota CORBA DCOM RMI Database Sistemi legacy http orb rete

35 Sistemi Informativi DEE - Politecnico di Bari Architettura n-tier User Interface costituita da uninterfaccia utente, ad esempio un web browser, che gira attraverso un firewall oppure unapplicazione a finestre per Windows. Presentation Logic definisce ciò che linterfaccia utente deve mostrare e come devono essere soddisfatte le richieste dellutente. Business Logic modella i ruoli dellapplicazione, spesso attraverso linterazione con lo schema dei dati. Infrastructure Service sono funzionalità aggiuntive, necessarie da alcuni componenti dellapplicazione, ad esempio un supporto alle transazioni. Data Layer è la fonte di immagazzinamento dei dati.

36 Sistemi Informativi DEE - Politecnico di Bari Java EE La Java Enterprise Edition 1.deriva dalla piattaforma precedente realizzata dalla Sun –la J2SE (java 2 Standard Edition) –e da java2EE ( java 2 enterprise edition) 2.Aggiunge tra le sue potenzialità la possibilità di unire componenti a livello enterprise mantenendo il sistema stabile e sicuro. 3.Attualmente java EE 6

37 Sistemi Informativi DEE - Politecnico di Bari Enterprise applications Software che fornisce funzionalità di supporto alla business logic di unimpresa, generalmente di tipo commerciale con lo scopo di migliorare produttività ed efficienza I servizi offerti sono generlamente business oriented: shopping online, pagamento online catalogazione interattiva, CRM, ERP, HR management, manufacturing, EAI, Enterprise form automation ecc. Requisiti necessari: scalabilità, robustezza, efficienza Generlamente sono applicazioni con interfacce verso altre applicazioni enterprise gestite in maniera centralizzata

38 Sistemi Informativi DEE - Politecnico di Bari Vantaggi Requisiti derivanti della scelta di una piattaforma legata a Java come sistema di sviluppo. Applicazioni lato-server –affidabilità, –scalabilità, –sicurezza –portabilità. Applicazioni web-based –Efficienza tempi di risposta ad una richiesta http devono essere minimi –Sicurezza maggiore è lutenza che è prevista per il sito maggiore deve essere la sicurezza che regola accessi e logica dellapplicazione. –Integrabilità capacità di combinare tecnologie recenti e vecchie, adattandosi il più possibile ai sistemi già presenti migliorandone le funzionalità;

39 Sistemi Informativi DEE - Politecnico di Bari Architettura java EE La piattaforma Java EE è una piattaforma a componenti che si basa su unarchitettura n-Tier –il sistema è fortemente modulare ed espandibile. suddivisione logica di unapplicazione: 1.Presentation: interfaccia utente 2.Business: la logica applicativa 3.Data Layer: contiene i dati necessari allapplicazione

40 Sistemi Informativi DEE - Politecnico di Bari Container Il concetto fondamentale che sta alla base della piattaforma EE è quello di "container". I container rappresentano ambienti che forniscono servizi aggiuntivi alle applicazioni in esecuzione e che sono standardizzati nelle specifiche EE. Alcuni esempi di servizi offerti dai container sono: gestione delle richieste di un eventuale Client gestione del multi-thread supporto alle transazioni collegamento ad altri componenti in altri tier collegamento a database gestione della sicurezza etc…

41 Sistemi Informativi DEE - Politecnico di Bari Web/EJB container L'architettura Java EE definisce due tipi di container: 1.i Web container: forniscono un ambiente di esecuzione per Servlet e JSP (Java Server Pages) 2.gli EJB container: forniscono un ambiente di esecuzione per Enterprise Java Bean (EJB)

42 Sistemi Informativi DEE - Politecnico di Bari Web container Il Web container rappresenta il front-end sul Web di un'architettura Java EE 1.Gestisce le richieste http provenienti dal Web 1.riceve la richiesta del Client 2.esegue le azioni opportune per soddisfare tale richiesta 3.restituisce la risposta al Client stesso –invocando uno dei componenti che sono al suo interno: Servlet e JSP 2.Gestisce il multithreading, anche a livello di "pool di thread: Garantendo così 1.buone prestazioni 2.facilità di sviluppo 3.Gestisce la politica di sicurezza consente di autenticare gli utenti che accedono al servizio consentendo o meno l'accesso a determinate risorse.

43 Sistemi Informativi DEE - Politecnico di Bari EJB Container L'EJB container fornisce un ambiente di esecuzione per Enterprise Java Bean, che sono i componenti che realizzano la logica applicativa del sito. Le specifiche relative a questi componenti descrivono appunto come questi debbano interfacciarsi con il substrato software fornito dal container.

44 Sistemi Informativi DEE - Politecnico di Bari Pattern BCE e Java secondo il paradigma BCE, la logica di unapplicazione web basata su java2 è divisa in tre livelli logici fondamentali: Client Tier –Application client –Web client Middle Tier –Web container: Jsp/Servlet –EJB container: Enterprise javabean EIS Tier –Enterprise information system (RDBMS,ERP, Legacy systems)

45 Sistemi Informativi DEE - Politecnico di Bari Client tier I componenti client possono essere di due tipi: · Web client · Application client

46 Sistemi Informativi DEE - Politecnico di Bari Web client Un Web client si compone di due parti: 1.una pagina web dinamica scritta in linguaggi come HTML e XML, generata da componenti allinterno del livello Web 2.un browser Web in grado di visualizzare le pagine ricevute dal Server. Allinterno della pagina è possibile che vi sia unapplet, una piccola applicazione scritta in linguaggio Java, eseguita dalla Java Virtual Machine (JVM) installata sul browser.

47 Sistemi Informativi DEE - Politecnico di Bari Application client funziona allinterno di una macchina Client e consente allutilizzatore di gestire lavori che richiedono uninterfaccia utente molto ricca ha un aspetto grafico (GUI) creato tramite le classi di Swing e AWT di Java, è comunque possibile utilizzare una comune interfaccia su linea di comando. ha accesso diretto ai bean del livello Business se i requisiti dellapplicazione lo autorizzano, il client può generare una connessione HTTP ad una servlet che sta girando nel livello Web.

48 Sistemi Informativi DEE - Politecnico di Bari Comunicazione al livello client la comunicazione al livello client avviene con i livelli intermedi racchiusi tutti allinterno del Server. Il client comunica con il livello Business e con quello Web direttamente o, nel caso di un client funzionante in un browser, tramite pagine JSP o applet. Lapplicazione J2EE può essere costruita sulla base di due client diametralmente opposti un browser-based client e un application client la scelta dipende dal compromesso che si vuole seguire: –lasciare molte funzionalità al client, e quindi rimanere più vicino possibile allutente –dare più funzionalità possibili al server per alleggerire il lavoro della macchina Client.

49 Sistemi Informativi DEE - Politecnico di Bari Middle Tier Contiene due elementi distinti : Jsp/Servlet Enterprise javabean

50 Sistemi Informativi DEE - Politecnico di Bari Servlet/jsp Servlet: –è una classe Java che dinamicamente elabora azioni di richiesta informazioni e costruisce delle risposte adeguate. pagina JSP –è un documento di testo che fornisce un approccio più naturale nella creazione di concetti statici. –Allinterno di una pagina JSP possiamo trovare del codice HTML, del codice Java o chiamate a classi Java già compilate e pronte per essere utilizzate. Servlet e jsp sono intercambiabili Vantaggio delle pagine JSP: non è necessario eseguire la loro compilazione, in quanto il Web Browser interpreta il codice Java al suo interno.

51 Sistemi Informativi DEE - Politecnico di Bari JSP È unestensione della tecnologia delle servlet Si usa quando la maggior parte del contenuto inviato al client è testo statico e markup e solo una piccola parte del contenuto viene generata dinamicamente con del codice java

52 Sistemi Informativi DEE - Politecnico di Bari Servlet Si usano quando una piccola parte del contenuto che viene inviato al client è testo statico o markup Alcune servlet non producono contenuto, ma eseguono compiti per conto dle client e invocano altre servlet o JSP per fornire una risposta Implementa linterfaccia Servlet, i cui metodi sono invocati automaticamente ( dal contenitore di servlet)

53 Sistemi Informativi DEE - Politecnico di Bari Enterprise Bean Questa parte del sistema si occupa di risolvere le problematiche vere e proprie di unapplicazione. Tutto ciò è gestito dagli Enterprise JavaBean presenti al suo interno: un Enterprise Bean riceve dati dai programmi client e se necessario li elabora. Si occupano di operazioni complesse quali linterrogazione di un database i dati vengono inviati al database per essere mantenuti, oppure compiono il percorso inverso, tornano cioè al client che li ha richiesti per essere eventualmente presentati allutente. un Enterprise Bean può recuperare dati memorizzati allinterno del database, elaborarli e in seguito inviarli al programma client che li ha richiesti.

54 Sistemi Informativi DEE - Politecnico di Bari Dinamica Come il livello Client anche il livello Web può avere componenti JavaBean in grado di prendere gli input dellutente e indirizzarli poi ad altri JavaBean residenti nel livello Business per essere elaborati Esistono due tipi di collegamento che esistono il livello web allinterno del livello server e il livello Client.

55 Sistemi Informativi DEE - Politecnico di Bari EIS Tier Enterprise Information System Contiene –software per la gestione generale del sistema –infrastrutture di sistema come mainframe per la gestione dei processi di transazione –database per la memorizzazione.

56 Sistemi Informativi DEE - Politecnico di Bari Esempio

57 Sistemi Informativi DEE - Politecnico di Bari Modelli architetturali Lo sviluppo di applicazioni di diversa complessità porta alla definizione di due modelli architetturali: 1.modello per piccole e semplici applicazioni, consigliato per applicazioni statiche. 2.architettura indicata per lo sviluppo di applicazioni che usano componenti come Servlet e Bean

58 Sistemi Informativi DEE - Politecnico di Bari Osservazioni Il passaggio dal primo al secondo modello avviene quando lo sviluppatore si trova in presenza di cambiamenti, aggiornamenti o espansioni dellapplicazione. È meglio non considerare il primo modello se non in caso di applicazioni molto piccole e statiche, ma riferirsi direttamente al secondo in cui: 1.un servlet controlla la comunicazione del cliente 2.i Bean gestiscono la Business logic dellapplicazione 3.nelle pagine JSP risiede la presentazione o visualizzazione dei dati, risiede principalmente in pagine JSP.

59 Sistemi Informativi DEE - Politecnico di Bari microsoft Tecnplogie proprietarie Asp Asp.Net (per applicazioni e servizi web) C# J# (visual basic.NET) Ruby Ecc.

60 Sistemi Informativi DEE - Politecnico di Bari ASP (Active Server Page) ASP è un linguaggio di programmazione per la creazione di pagine web dinamiche che su piattaforma Windows affinché il codice ASP possa essere interpretato, c'è bisogno che il Web server utilizzato sia un server Active X come ad esempio IIS o Personal Web Server (anche se per questultimo ci sono alcune limitazioni di utilizzo). Esistono anche versioni per Netscape Enterprise, Lotus Domino, Solaris. E moduli aggiuntivi, scritti in Java, per server Unix (Linux, Novell, Sun, Macintosh, HPUX, SGI, SCO,Dec Alpha, IBM OS/2, RS/6000, AS/400, S/390, Apache, FastTrack/Enterprise servers, Sun WebServer, Java WebServer,IIS, WebSphere and Lotus Domino). Il linguaggio supporta il concetto di variabile che in questo caso non deve essere necessariamente dichiarata. Active Server Page permette di sfruttare le variabili di tipo, cioè variabili che possono contenere qualsiasi tipo di valore ad eccezione di vettori o matrici. Una variabile può essere globale (dichiarata al di fuori di procedure), locale (dichiarata allinterno di procedure), di sessione (disponibile per tutte le pagine), di applicazione (disponibile per unapplicazione richiesta da un utente). ASP mette a disposizione la possibilità di gestire collezioni di dati, statiche o provenienti da form, eventualmente possono essere definiti array multidimensionali. ASP mette a disposizione del linguaggio di scripting 7 diversi oggetti che, grazie ai loro metodi, consentono il controllo del server e della comunicazione server-client. Questi oggetti, che sono detti oggetti built-in, vengono automaticamente istanziati all'inizio dell'esecuzione di ogni pagina.

61 Sistemi Informativi DEE - Politecnico di Bari Implementazione di unarchitettura a oggetti distribuiti Richiede un middleware per gestire la comunicazione tra gli oggetti distribuiti –il middleware è detto Object Request Broker (ORB) Gli oggetti possono essere implementati utilizzando linguaggi di programmazione diversi, eseguiti su piattaforme diverse e non aver bisogno di conoscere tutti i nomi degli altri oggetti del sistema

62 Sistemi Informativi DEE - Politecnico di Bari CORBA Standard definito da OMG Secondo lo standard unapplicazione distribuita è fornita da una serie di componenti –Oggetti applicativi progettati e implementati per questa applicazione –Oggetti standard definiti da OMG per uno specifico dominio che coprono diversi campi finanza, commercio elettronico, servizio sanitario –Servizi CORBA fondamentali che forniscono servizi distribuiti da base come gestione di directory e di protezione –Funzionalità orizzontali CORBA come interfacce utente, gestione del sistema Si tratta di funzionalità comuni a molti domini di applicazione e le funzionalità sono utilizzate in diverse applicazioni

63 Sistemi Informativi DEE - Politecnico di Bari Elementi dello standard 1.Modello di oggetto per gli oggetti applicativi CORBA è un versione di uninterfaccia incapsulata occorre un linguaggio per la descrizione delle interfacce interface definition language (IDL) 2.Mediatore di richieste degli oggetti, ORB 3.Insieme di servizi generici(directory, transazioni, persistenza) 4.Insieme di componenti comuni

64 Sistemi Informativi DEE - Politecnico di Bari Modello oggetto Corba Come per un qualunque oggetto, il modello considera loggetto come un incapsulamento di attributi e servizi –Gli oggetti Corba devono avere una definizione dellinterfaccia separata che definisce gli attributi e le operazioni pubbliche delloggetto

65 Sistemi Informativi DEE - Politecnico di Bari Comunicazione tra gli oggetti Le interfacce degli oggetti sono definite usando un linguaggio di definizione standard e language independent: –Un oggetto accede ad un servizio offerto da un altro oggetto mediante linterfaccia IDL Gli oggetti corba hanno un identificatore chiamato IOR (Interoperable object reference) Lorb è a conoscenza degli oggetti che richiedono i servizi e delle loro interfacce

66 Sistemi Informativi DEE - Politecnico di Bari Comunicazione tra oggetti Loggetto chiamante ha uno stub IDL associato che definisce linterfaccia delloggetto del fornitore del servizio chiamato loggetto che fornisce il servizio ha uno skeleton IDL che collega linterfaccia allimplementazione dei servizi Quando un servizio è chiamato attraverso linterfaccia, lo skeleton produce una chiamata al servizio qualunque sia il linguaggio di implementazione Quando il metodo è stato eseguito lo skeleton traduce i risultati in IDL in modo che loggetto chiamante possa accedervi. Un oggetto che fornisce servizi e utilizza servizi di altri oggetti ha sia uno skeleton che uno stub IDL per ogni oggetto che li utilizza

67 Sistemi Informativi DEE - Politecnico di Bari Web services Non è una tecnologia specifica per applicazioni web nonostante la presenza del termine web Il termine web sta ad indicare che usa tecnologie per il web, web server e HTTP, per fornire un insieme di servizi che possono essere invocati da altri programmi sulla rete

68 Sistemi Informativi DEE - Politecnico di Bari Cenni storici Il concetto di web service risale agli anni 1990 introdotta da sun con la campagna le rete è il computer Lidea è quella di risolvere i problemi di business distribuendo la soluzione a problemi discreti a componenti specializzate distribuite sulla rete

69 Sistemi Informativi DEE - Politecnico di Bari Vantaggi La decentralizzazione del meccanismo di elaborazione comporta significativi vantaggi quando il sistema evolve poiché occorre apportare poche modifiche quando il sistema cambia

70 Sistemi Informativi DEE - Politecnico di Bari Standard-based web service Web service hanno un ruolo importante nellambito della tecnologia.NET Quando la tecnologia fu rilasciata, web service standard- based acquistarono notevole importanza

71 Sistemi Informativi DEE - Politecnico di Bari Web service e componenti Un web service è una collezione di funzioni impacchettate e pubblicate su una rete per poter essere utilizzate da altri programmi client Da un alto livello di astrazione un web service è semplicemente un altro tipo di RPC La differenza è nei concetti che il web service porta alla RPC: –Così come i modelli a componenti hanno reso praticabile il riuso di componenti, così i web service rendono pratica la RPC fornendo un insieme di standard per individuare e invocare i servizi

72 Sistemi Informativi DEE - Politecnico di Bari Component model /service model I modelli a componenti definiscono le modalità in cui le componenti interagiscono e secondo cui possono essere individuate ed esaminate a livello di programmazione I web service definiscono un meccanismo analogo per il discovery di metadati funzionali

73 Sistemi Informativi DEE - Politecnico di Bari Altre caratteristiche Ogni web service può interagire con qualunque altro web service I web service possono essere aggregati per fornire funzionalità di alto livello I web service sono componenti software e quindi possono invocare altri web service

74 Sistemi Informativi DEE - Politecnico di Bari Tecnologie per web service SOAP: Simple Object Access Protocol –Definisce unorganizzazione per lo scambio di dati strutturati tra i webservice WSDL: Web Service Description Language –Linguaggio di descrizione dei webservice che definisce come possono essere rappresentate le interfacce dei webservice UDDI: Universal Description, Discovery And Integration –Descrizione, scoperta e integrazione universale –Standard di ricerca che definisce come possono essere organizzate le informazioni di descrizione dei servizi utilizzate dai richiedenti dei servizi per trovarli

75 Sistemi Informativi DEE - Politecnico di Bari XML Gli standard per i web service si basano su XML –Linguaggio di markup human and machine understandable (Skonnard e Gudgin, 2002)

76 Sistemi Informativi DEE - Politecnico di Bari Architetture applicative Sono architetture debolmente accoppiate dove i collegamenti ai servizi possono cambiare durante lesecuzione: –Alcuni sistemi possono essere costruiti usando solamente web service altri possono comprendere web service e componenti sviluppati localmente

77 Sistemi Informativi DEE - Politecnico di Bari Il middleware Il middleware deve garantire la comunicazione trasparente tra gli oggetti: È richiesto a due livelli: Comunicazione logica: –fornisce funzionalità che permettono agli oggetti su computer diversi di scambiarsi dati e controllare le informazioni Standard sviluppati sono CORBA, COM per facilitare la comunicazione tra oggetti su piattaforme diverse Componenti: –Il middleware fornisce una base per lo sviluppo di componenti compatibili Standard come EJB, CORBA, ActiveX forniscono una base per limplementazione di componenti con metodi standard che possono essere interrogati e utilizzati da altri componenti


Scaricare ppt "Sistemi Informativi DEE - Politecnico di Bari Tecnologie di implementazione Corso di ingegneria del software."

Presentazioni simili


Annunci Google