Sistemi Informativi

Sistemi Informativi
DEE - Politecnico di Bari
Tecnologie di implementazione
Corso di ingegneria del software
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
Sistemi Informativi
DEE - Politecnico di Bari
Architetture dei sistemi distribuiti
• Tecnologie per architetture
– Client server
– A oggetti distribuiti
– A servizi distribuiti
Sistemi Informativi
DEE - Politecnico di Bari
Component based software engineering
(CBSE)
• 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
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
Elementi fondamentali
Componenti indipendenti
Standard dei componenti
Middleware
Un processo di sviluppo
Sistemi Informativi
DEE - Politecnico di Bari
Componente
• Definizione :
– Una parte modulare, utilizzabile e sostituibile di un sistema che
comprende l’implementazione es espone una serie di interfacce”
[OMG]
È un elemento costitutivo del software
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]
• Un’unità 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]
Sistemi Informativi
DEE - Politecnico di Bari
•
Standardizzato
•
Indipendente
•
Componibile
•
Consegnabile
•
Documentato
–
Caratteristiche dei componenti
Ogni componente deve essere conforme a un modello di componente standardizzato che
definisce interfacce, metadata,documentazione,
–
–
Non deve essere necessario utilizzare altri componenti specifici
Il codice sorgente non è disponibile, quindi il componente non deve essere compilato
–
–
Tutte le interazioni avvengono attraverso interfacce pubbliche
Deve fornire accesso esterno alle sue informazioni
–
È binario, non deve essere compilato
–
Deve essere specifica la sintassi e la semantica di tutte le interfacce del componente
Sistemi Informativi
DEE - Politecnico di Bari
Punti di vista
• Il significato del termine componente differisce a seconda del punto
di vista dell’ingegnere 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 dell’infrastuttura
– Orientata al processo
• Catalogo di componenti software esistenti, componenti progettuali o di
codice disponibile
Sistemi Informativi
DEE - Politecnico di Bari
•
Definizione :
–
•
Middleware
“Una classe di tecnologie software progettate per gestire l’eterogeneità 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]
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
•
Può essere realizzata
–
–
–
–
–
–
pipe
socket
memory mapped file
chiamata di procedura remota
scambio di messaggi
mailbox
–
–
–
–
a basso livello
a livello di linguaggio di programmazione
a livello applicativo
mediante software (middleware: DBMS, Web server application server, ecc.)
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 dell’oggetto chiamante
Sistemi Informativi
DEE - Politecnico di Bari
Modelli di componenti
• È la definizione degli standard per l’implementazione, la
documentazione e la consegna del componente
• Sono disponibili molti modelli di componenti, i più noti:
– OMG Corba: http://www.corba.org
– Microsoft .NET http://www.msdn
– Sun Enterprise Java beans http://java.sun.com/products
Sistemi Informativi
DEE - Politecnico di Bari
Osservazioni: Strumenti software
• Il successo o il fallimento del CBSE è legata alla
disponibilità di software middleware
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 l’aggiunta di Microsoft
transaction server e Active directory supporta eterogeneità nell’uso 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
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)
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
Sistemi Informativi
DEE - Politecnico di Bari
Implementazione di applicazioni client
/server per il web
Applicazione web
Definizione:
• Un’applicazione web è un sistema che permette ai propri
utenti di eseguire una logica di business con un browser
web
[Conallen, 2000]
Sistemi Informativi
DEE - Politecnico di Bari
Caratteristiche generali
• La logica di business può risiedere sul server e/o sul client
• Un’applicazione 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 l’utente può riempire:
form
Sistemi Informativi
DEE - Politecnico di Bari
Application server
• Un’applicazione web può includere un server applicativo
application server per gestire la logica applicativa e
monitorare lo stato dell’applicazione
• Il monitoraggio dello stato è un’attività importante che
permette di tenere traccia delle azioni dei clienti collegati
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 sull’attività di un utente collegato:
–
ad es. se l’utente 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
Sistemi Informativi
DEE - Politecnico di Bari
Script e applet
• Sono usati per rendere dinamica la pagina client.
• Uno script è un programma interpretato dal browser
• Un’applet è 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)
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)
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
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
Sistemi Informativi
DEE - Politecnico di Bari
BCE
Pattern BCE
1. suddivide la logica di un’applicazione in 3 categorie mutuamente esclusive:
–
–
–
Boundary
Control
Entity
2. consente una guida all’identificazione e alla rappresentazione:
–
–
–
dei confini tra il sistema e i suoi attori
dell’informazione usata dal sistema
della logica di controllo del sistema
Sistemi Informativi
DEE - Politecnico di Bari
•
•
Classi Boundary
Identificate mediante lo stereotipo<<Boundary>>
Le classi Boundary
1. Descrivono gli oggetti che rappresentano l’interfaccia tra attore
e sistema
–
ossia delimitano il confine del sistema.
2. Isolano il sistema dai cambiamenti dell’ambiente esterno
consentendo usabilità e interfacciamento con altri sistemi.
Sistemi Informativi
DEE - Politecnico di Bari
•
•
Classi Control
Identificate mediante lo stereotipo <<Control>>
Le classi Control
1. Descrivono gli oggetti che percepiscono gli eventi generati dall’utente e
che controllano l’esecuzione 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 dall’ambiente esterno, in quanto non subiscono
modifiche in seguito al cambiamento di tale ambiente e non
sopravvivono all’interazione cui prendono parte.
Sistemi Informativi
DEE - Politecnico di Bari
•
•
Classi Entity
Identificate mediante lo stereotipo <<Entity>>
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 l’interazione
solitamente sopravvive alla singola interazione
3. accedono direttamente al database per la raccolta dei dati da
elaborare.
Sistemi Informativi
DEE - Politecnico di Bari
BCDE
L’approccio 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 l’interfaccia tra classi entity e database
Sistemi Informativi
DEE - Politecnico di Bari
BCE
Sistemi Informativi
Architettura
di un’Applicazione web a tre strati
DEE - Politecnico di Bari
Tier 2
Tier 1
Tier 3
193.204.59.75
pagine
HTML
http://193.204.59.227:80
Browser
TCP
Servlet
Internet
Internet
TCP
193.204.59.227
IP
IP
protocollo
accesso
rete
protocollo
accesso
rete
Livello di
presentazione
Applicazione
HTTP
HTTP
193.204.59.86
Web
Server
pagina
HTML
Livello della
logica di business
TCP
IP
protocollo
accesso
rete
Livello Dati
Sistemi Informativi
DEE - Politecnico di Bari
Architettura n-tier
Mediante un’architettura n-Tier la logica dell’applicazione 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
Sistemi Informativi
DEE - Politecnico di Bari
Architettura n-Tier
http
http
• Database
• Sistemi
legacy
Application
server
http
http
rete
orb
orb
Web
server
• servlet
• JSP
• ASP
Thin client
• applicazioni
• web browser
• HTML
• applet
• java
script
• componenti
CORBA
• componenti
DCOM
• componenti
EJB
DBMS
Servizi comuni
rete
•
•
•
•
connettività a database
naming e directory service
gestione delle transazioni
comunicazione remota
• CORBA
• DCOM
• RMI
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
•
Architettura n-tier
User Interface costituita da un’interfaccia utente, ad esempio un web
browser, che gira attraverso un firewall oppure un’applicazione a finestre
per Windows.
Presentation Logic definisce ciò che l’interfaccia utente deve mostrare e
come devono essere soddisfatte le richieste dell’utente.
Business Logic modella i ruoli dell’applicazione, spesso attraverso
l’interazione con lo schema dei dati.
Infrastructure Service sono funzionalità aggiuntive, necessarie da alcuni
componenti dell’applicazione, ad esempio un supporto alle transazioni.
Data Layer è la fonte di immagazzinamento dei dati.
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
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
Enterprise applications
Software che fornisce funzionalità di supporto alla business logic di
un’impresa, 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
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
•
maggiore è l’utenza che è prevista per il sito maggiore deve essere la sicurezza che regola accessi e logica
dell’applicazione.
Sicurezza
Integrabilità
•
capacità di combinare tecnologie recenti e vecchie, adattandosi il più possibile ai sistemi già presenti migliorandone le
funzionalità;
Sistemi Informativi
DEE - Politecnico di Bari
Architettura java EE
La piattaforma Java EE è una piattaforma a componenti che si basa su
un’architettura n-Tier
– il sistema è fortemente modulare ed espandibile.
suddivisione logica di un’applicazione:
1. Presentation: interfaccia utente
2. Business: la logica applicativa
3. Data Layer: contiene i dati necessari all’applicazione
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…
Sistemi Informativi
DEE - Politecnico di Bari
Web/EJB container
L'architettura Java EE definisce due tipi di container:
1. i Web container:
•
2.
forniscono un ambiente di esecuzione per Servlet e JSP (Java
Server Pages)
gli EJB container:
•
forniscono un ambiente di esecuzione per Enterprise Java
Bean (EJB)
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
2.
3.
–
1.
2.
3.
riceve la richiesta del Client
esegue le azioni opportune per soddisfare tale richiesta
restituisce la risposta al Client stesso
invocando uno dei componenti che sono al suo interno: Servlet e JSP
Gestisce il multithreading, anche a livello di "pool di thread:
•
Garantendo così
1.
2.
buone prestazioni
facilità di sviluppo
Gestisce la politica di sicurezza
•
consente di autenticare gli utenti che accedono al servizio consentendo o meno l'accesso a
determinate risorse.
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.
Sistemi Informativi
DEE - Politecnico di Bari
Pattern BCE e Java
secondo il paradigma BCE, la logica di un’applicazione 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)
Sistemi Informativi
DEE - Politecnico di Bari
Client tier
I componenti client possono essere di due tipi:
· Web client
· Application client
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 all’interno del livello Web
2. un browser Web in grado di visualizzare le pagine ricevute dal
Server.
All’interno della pagina è possibile che vi sia un’applet, una piccola
applicazione scritta in linguaggio Java, eseguita dalla Java Virtual
Machine (JVM) installata sul browser.
Sistemi Informativi
DEE - Politecnico di Bari
Application client
• funziona all’interno di una macchina Client e consente all’utilizzatore
di gestire lavori che richiedono un’interfaccia 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 dell’applicazione lo autorizzano, il client può generare
una connessione HTTP ad una servlet che sta girando nel livello
Web.
Sistemi Informativi
DEE - Politecnico di Bari
Comunicazione al livello client
la comunicazione al livello client avviene con i livelli intermedi racchiusi tutti
all’interno 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.
L’applicazione 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
all’utente
– dare più funzionalità possibili al server per alleggerire il lavoro della macchina
Client.
Sistemi Informativi
DEE - Politecnico di Bari
Middle Tier
Contiene due elementi distinti :
• Jsp/Servlet
• Enterprise javabean
Sistemi Informativi
DEE - Politecnico di Bari
•
Servlet:
•
pagina JSP
–
–
–
Servlet/jsp
è una classe Java che dinamicamente elabora azioni di richiesta informazioni e costruisce
delle risposte adeguate.
è un documento di testo che fornisce un approccio più naturale nella creazione di concetti
statici.
All’interno 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.
Sistemi Informativi
DEE - Politecnico di Bari
JSP
• È un’estensione 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
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 l’interfaccia Servlet, i cui metodi sono invocati
automaticamente ( dal contenitore di servlet)
Sistemi Informativi
DEE - Politecnico di Bari
Enterprise Bean
Questa parte del sistema si occupa di risolvere le problematiche vere e proprie di
un’applicazione. 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 l’interrogazione 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
all’utente.
un Enterprise Bean può recuperare dati memorizzati all’interno del database, elaborarli e
in seguito inviarli al programma client che li ha richiesti.
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
dell’utente e indirizzarli poi ad altri JavaBean residenti
nel livello Business per essere elaborati
Esistono due tipi di collegamento che esistono il livello web
all’interno del livello server e il livello Client.
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.
Sistemi Informativi
DEE - Politecnico di Bari
Esempio
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
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
dell’applicazione.
È meglio non considerare il primo modello se non in caso di applicazioni
molto piccole e statiche, ma riferirsi direttamente al secondo in cui:
1.
2.
3.
un servlet controlla la comunicazione del cliente
i Bean gestiscono la Business logic dell’applicazione
nelle pagine JSP risiede la presentazione o visualizzazione dei dati, risiede
principalmente in pagine JSP.
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
•
•
•
•
microsoft
Tecnplogie proprietarie
Asp
Asp .Net (per applicazioni e servizi web)
C#
J#
(visual basic .NET)
Ruby
Ecc.
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 quest’ultimo 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 all’interno di procedure), di sessione (disponibile
per tutte le pagine), di applicazione (disponibile per un’applicazione 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.
Sistemi Informativi
DEE - Politecnico di Bari
Implementazione di un’architettura 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
Sistemi Informativi
DEE - Politecnico di Bari
•
•
CORBA
Standard definito da OMG
Secondo lo standard un’applicazione 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
Sistemi Informativi
DEE - Politecnico di Bari
1.
Modello di oggetto per gli oggetti applicativi CORBA è un versione
di un’interfaccia incapsulata
•
2.
3.
4.
Elementi dello standard
occorre un linguaggio per la descrizione delle interfacce interface
definition language (IDL)
Mediatore di richieste degli oggetti, ORB
Insieme di servizi generici(directory, transazioni, persistenza)
Insieme di componenti comuni
Sistemi Informativi
DEE - Politecnico di Bari
Modello oggetto Corba
• Come per un qualunque oggetto, il modello considera
l’oggetto come un incapsulamento di attributi e servizi
– Gli oggetti Corba devono avere una definizione dell’interfaccia
separata che definisce gli attributi e le operazioni pubbliche
dell’oggetto
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
l’interfaccia IDL
• Gli oggetti corba hanno un identificatore chiamato IOR
(Interoperable object reference)
• L’orb è a conoscenza degli oggetti che richiedono i servizi e delle
loro interfacce
Sistemi Informativi
DEE - Politecnico di Bari
•
•
•
•
•
Comunicazione tra oggetti
L’oggetto chiamante ha uno stub IDL associato che definisce l’interfaccia
dell’oggetto del fornitore del servizio chiamato
l’oggetto che fornisce il servizio ha uno skeleton IDL che collega
l’interfaccia all’implementazione dei servizi
Quando un servizio è chiamato attraverso l’interfaccia, 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 l’oggetto 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
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
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”
• L’idea è quella di risolvere i problemi di business
distribuendo la soluzione a problemi discreti a
componenti specializzate distribuite sulla rete
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
Sistemi Informativi
DEE - Politecnico di Bari
Standard-based web service
• Web service hanno un ruolo importante nell’ambito della
tecnologia .NET
• Quando la tecnologia fu rilasciata, web service standardbased acquistarono notevole importanza
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
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
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
Sistemi Informativi
DEE - Politecnico di Bari
•
Tecnologie per web service
SOAP: Simple Object Access Protocol
– Definisce un’organizzazione 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
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)
Sistemi Informativi
DEE - Politecnico di Bari
Architetture applicative
• Sono architetture debolmente accoppiate dove i
collegamenti ai servizi possono cambiare durante
l’esecuzione:
– Alcuni sistemi possono essere costruiti usando solamente web
service altri possono comprendere web service e componenti
sviluppati localmente
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 l’implementazione di
componenti con metodi standard che possono essere interrogati e utilizzati da altri
componenti