Transcript ^_y_****$* *****| *2**** *x* * ***x* TA*?w G*mK* &E*a*e*} &* =h*B

ARCHITETTURE
• Architetture N-Tier
• COM (Component Object Model) e DCOM
(Distributed COM)
• SOA (Service Oriented Architecture)
• Enterprise Java Beans
• Microsoft .NET
• Web Services
Applicazioni Web-based e non
Elementi di base di un’applicazione
• I dati da trattare (dati sugli utenti, sul servizio offerto,
etc.)
• Logica applicativa (business logic), ovvero le
funzionalità che l’applicazione deve offrire, il tipo di
trattamento dei dati previsto (quali operazioni si
possono fare), etc.
• Interfaccia utente
– interfaccia web (e.g., per browser, o testuale)
– stand-alone (applicazione locale alla macchina su cui gira)
Architetture delle applicazioni
•
•
•
•
Monoliti
Client/server (two-tier)
Three-tier
N-tier
Monoliti (IT stovepipe) - I
• Popolari ai tempi dei mainframe
• Monoliti:
– pezzi di codice indivisibili
– controllavano l’intera logica dell’applicazione, dalla
gestione (e memorizzazione) dei dati, fino all’interfaccia
utente
– gestivano applicazioni stand-alone
• Popolarità dovuta a:
– mainframe adatti ad eseguire pochi processi stand-alone,
anzichè diversi processi comunicanti
– non c’erano ancora i database
Monoliti (IT stovepipe) - II
User interface
Logic
Data Management
Enterprise
Architetture client/server - I
• Dalla fine degli anni ‘70 alla metà degli anni ‘80
– Diffusione di server più piccoli ed economici dei
mainframe, e di workstations e PC
– Diffusione di RDBMS
• Suddivisione delle applicazioni in due parti:
– backend (server): gestione di database (+ o – complessi) e
dei compiti di manipolazione dei dati
– frontend (client): gestione interfaccia utente
 maggiore scalabilità, rispetto a monoliti (carico
computazionale distrbuito sui client)
 sviluppo più veloce di applicazioni che accedono agli
(stessi) dati
Architetture client/server - III
Client
Client
User interface
Logic
Data
Management
Server
Enterprise
Client
Architetture client/server - II
Svantaggi:
• Traffico di messaggi intenso (frontend comunica
continuamente con server dati)
• Logica di business non gestita in componente separata
dell’architettura: suddivisa tra frontend e backend
•  client e server di applicazione dipendono l’uno
dall’altro
– difficile riutilizzare interfaccia in servizio che accede a dati
diversi
– difficile utilizzare DB da frontend diversi
– tendenza a cablare la business logic nell’interfaccia utente
 cambio di logica significa cambiare anche interfaccia
Architetture client/server - IV
• Problema: mancato riconoscimento dell’importanza
della business logic
– Es: servizio accessibile da più device (telefonino, desktop)
 stessa logica, interfaccia diversa
User interface
Client
Nuovo Client
Nuovo Client
Logic
Adapter
Adapter
Data
Management
Enterprise
Server
Architetture three-tier - I
• Introdotte all’inizio degli anni ‘90
• Business logic trattata in modo esplicito:
– livello 1: gestione dei dati (DBMS, file XML, …..)
– livello 2: business logic (processamento dati, …)
– livello 3: interfaccia utente (presentazione dati, servizi)
• Ogni livello ha obiettivi e vincoli di design propri
• Nessun livello fa assunzioni sulla struttura o
implementazione degli altri:
– livello 2 non fa assunzioni su rappresentazione dei dati, né
sull’implementazione dell’interfaccia utente
– livello 3 non fa assunzioni su come opera la business logic ..
Architetture three-tier - II
• Non c’è comunicazione diretta tra livello 1 e livello 3
– Interfaccia utente non riceve, né inserisce direttamente dati
nel livello di data management
– Tutti i passaggi di informazione nei due sensi vengono
filtrati dalla business logic
• I livelli operano senza assumere di essere parte di una
specifica applicazione
–  applicazioni viste come collezioni di componenti
cooperanti
–  ogni componente può essere contemporaneamente parte
di applicazioni diverse (e.g., database, o componente logica
di configurazione di oggetti complessi)
Architetture three-tier - III
User interface
Presentation layer
Motif
Client
Logic
Business layer
Data Management
Data layer
Windows
Client
Telephony
Client
Mac
Client
Business
Rules
Business
Rules
Business
Rules
Data
Service
Data
Service
Data
Service
Enterprise
Architetture three-tier - IV
User Interface
Application Logic
Service
consumer
Service
provider
Data
providers
DB
XML
Documents
Directory
service
Vantaggi di architetture three-tier - I
• Flessibilità e modificabilità di sistemi formati da
componenti separate
– componenti utilizzabili in sistemi diversi
– modifica di una componente non impatta sul resto del
sistema (a meno di cambiamenti negli API)
– ricerca di bug più focalizzata (separazione ed isolamento
delle funzionalità del sistema)
– aggiunta di funzionalità all’applicazione implica estensione
delle sole componenti coinvolte (o aggiunta di nuove
componenti)
Vantaggi di architetture three-tier - II
• Interconnettività
– API delle componenti superano il problema degli adattatori
del modello client server  N interfacce diverse possono
essere connesse allo stesso servizio etc.
– Facilitato l’accesso a dati comuni da parte di applicazioni
diverse (uso dello stesso gestore dei dati da parte di business
logics diverse)
• Gestione di sistemi distribuiti
– Business logic di applicazioni distribuite (e.g., sistemi
informativi con alcuni server replicati e client remoti)
aggiornabile senza richiedere aggiornamento dei client
– Aggiornamento dei client comunque costoso
Vantaggi di architetture three-tier - III
• Applicazioni distribuite geograficamente
– Data server centrale
– Business logic gestita da server logici regionali
– Client remoti (ev. con business logic per maggior
scalabilità)
• Per ridurre traffico di rete e latency del servizio, anche
il data server centrale può essere replicato (ma,
gestione consistenza dati)
Svantaggi di architetture three-tier - I
• Dimensioni delle applicazioni ed efficienza
– Pesante uso della comunicazione in rete  latenza del
servizio
– Comunicazione tra componenti richiede uso di librerie SW
per scambio di informazioni  codice voluminoso
• Legacy software
– Molte imprese usano software vecchio (basato su modello
monolitico) per gestire i propri dati 
• difficile applicare il modello three-tier per nuove
applicazioni
• introduzione di adapters per interfacciare il legacy SW
Three-tier è concettuale, non fisico
Si possono implementare architetture three-tier
su due livelli di macchine, o anche su uno solo...
Data and Logic Server
Data
Components
Logic
Rules
Clients
User
Interface
User
Interface
Architetture n-Tier - I
Permettono configurazioni diverse. Elementi
fondamentali:
• Interfaccia utente (UI)
– gestisce interazione con utente
– può essere un web browser, WAP minibrowser, interfaccia
grafica, …
• Presentation logic
– definisce cosa UI presenta e come gestire le richieste utente
• Business logic
– gestisce regole di business dell’applicazione
Architetture n-Tier - II
• Infrastructure services
– forniscono funzionalità supplementari alle componenti
dell’applicazione (messaging, supporto alle transazioni, …)
• Data layer:
– livello dei dati dell’applicazione
Architetture n-Tier - III
Browser
Firewall
Application client
Presentation Logic
Services
Business Logic
DB
XML
Documents
Applicazione Web-based tipica - I
• Interfaccia utente: gestita sul browser utente
• Logica applicativa: gestita sul server, che si
interfaccia al web attraverso Web Server
• Livello dei dati: su database, eventualmente
localizzato su macchina diversa da quella del Web
Server, per questioni di sicurezza
Browser
utente
HTTP
Web
Server
Business logic
Applicazione Web-based tipica - II
• Richiesta di pagina HTML statica (pagina HTML
memorizzata nel file system dell’applicazione – il
codice della pagina non viene generato eseguendo
programmi applicativi sul server)
Request: http://patzer/hello.html
Local File System
Web
Server
Browser
utente
Response: HTML code
/htdocs/hello.html
Applicazione Web-based tipica - III
• Richiesta di pagina dinamica (pagina HTML generata
dinamicamente, sulla base della richiesta del client –
codice della pagina generato eseguendo programmi
applicativi sul server)
Request:
http://www.di.unito.it/service1.html
Browser
utente
Response: pagina HTML di
risposta, con eventuali link
e bottoni per continuare interazione
Web
Server
Business logic
Browser Web
• Può essere visto come interfaccia utente universale
– Invoca Web Server per richiedere pagine statiche o
dinamiche
– Riceve contenuti web da Web Server invocato e li presenta
sulla macchina dell’utente
• Browser moderni (MS Explorer, Netscape Navigator, …)
interpretano codice HTML
• Alcuni browser interpretano codice XML
– Può eseguire script (e.g., javascript) localmente, per
effettuare semplici computazioni (e.g., controllo correttezza
input utente)
– Può scaricare plug-in da Web Server per eseguire
programmi localmente (e.g., animazioni Flash o altro)
Web Server
• Programma che
– gira su una macchina server accessibile da internet
– resta in ascolto di richieste (da parte di client web)
su porta HTTP. E.g., http://www.di.unito.it:8080
– gestisce le richieste che arrivano (recupera pagina
html richiesta, esegue programmi, invoca
programmi associati a servizi richiesti, etc.)
– restituisce a client una risposta (risultato della
richiesta, messaggio di errore)
La Piattaforma J2EE
• J2SE: Java 2 Platform, Standard Edition.
– Ambiente runtime per esecuzione di applicazioni Java e
insieme di API (Application Programming Interface)
per sviluppare applicazioni di vario tipo (applets,
applicazioni stand-alone, …)
• J2EE: Java 2 Platform, Enterprise Edition:
– framework per lo sviluppo di applicazioni server-side
complesse
• J2ME: Java 2 Platform, Micro Edition:
– framework per lo sviluppo di applicazioni su micro
device (PDA, telefonini Java-enabled, etc.)
Proprietà
• J2EE: adatta allo sviluppo di applicazioni Web-based
a livello di impresa, e.g., per commercio elettronico
• Il suo competitor è Microsoft .net
• Impresa (enterprise): organizzazione di business
• Enterprise software applications: applicazioni SW
che facilitano la gestione delle attività di impresa
– interagire con clienti e partners via Internet
– facilitare l’interazione tra le varie parti di un’impresa,
eventualmente distribuite geograficamente
– gestione del business: resource planning, gestione inventari,
...
Caratteristiche di applicazioni “enterprise”
• Necessità informative: spesso le stesse informazioni
sono utilizzate sotto forma diversa dai consumatori 
attività di business diverse processano le stesse
informazioni, ma utilizzando formati diversi
• Complessità dei processi di business: necessità di
raccogliere, gestire e condividere informazioni,
basandosi su una logica complessa
• Eterogeneità delle applicazioni: un’impresa utilizza
molte applicazioni basate su architetture e tecnologie
diverse (legacy software)
Requisiti di gestione del software d’impresa
• Velocizzazione del processo di sviluppo delle
applicazioni: cambiano gli standard, le tecnologie, le
applicazioni devono entrare in uso velocemente
• Affidabilità e disponibilità: il SW deve essere
sempre accessibile (Web) ed essere affidabile (e.g.,
transazioni)
• Sicurezza: protezione delle informazioni dell’azienda
• Scalabilità: accesso efficiente a risorse, tolleranza al
carico di milioni di utenti (Web)
• Integrazione: le applicazioni vanno integrate nei
sistemi informativi già esistenti
J2EE
• Si sono sviluppate soluzioni diverse per affrontare i
vari problemi
• J2EE: permette di integrare tali soluzioni e facilita lo
sviluppo del SW
– Modello di programmazione con approccio alla costruzione
di applicazioni basato su API
– Infrastruttura che permette di eseguire le applicazioni in
modo efficiente e scalabile
• basato su Java  portabile
• basato sul concetto di Contenitore  servizi di gestione di base
(messaggi, transazioni, ciclo di vita delle componenti, …) forniti
dall’infrastruttura
• Modulare, componenti riusabili
L’evoluzione del Client/Server
HOST
solution
MINI
solution
Enterprise
CLIENT
SERVER
End User
PC
stand alone
PC
networking
Allocazione Delle Componenti
SERVER
Data
Management
Logic/
Control
NETWORK
Presentation
CLIENT
Classificazione delle soluzioni
Client/Server
Timesharing
Server
Client
Presentation
Distributed
Application
Data
Data
Data
Logic
Logic
Logic
Central
Database
Distributed
Database
Data
Data
Presentation
Data
Logic
Logic
Logic
Presentation Presentation Presentation Presentation
Client
Char. Terminal
Centralized
X-Terminal
PC
PC
PC
Decentralized
Le “ere” del Client/Server
Da: Byte Aprile 95
HTML Dinamico?????
Tier 1
Tier 2
Tier 3
Application server
browser
1. richiesta .jsp
Interne
t
(htpp)
4. ritorna html
HTML
Web
Server
2. richiesta dati
servlet
JSP
3. generazione
html
servlet
Business
Objects
DATI
Architetture Two-Tiers e Three-Tiers
Market Share
80
Market Share
60
40
20
80
0
1st Q tr
60
2n d Q tr
40
20
0
1st Q tr
2n d Q tr
minore uso
delle risorse
DB
Market Share
80
DB
Market Share
60
40
20
80
0
60
1st Q tr
2n d Q tr
40
20
0
1st Q tr
Market Share
2n d Q tr
livello
intermedio
DB
80
Market Share
60
DB
40
20
80
0
1st Q tr
60
2n d Q tr
40
20
0
1st Q tr
2n d Q tr
DB
Market Share
80
Market Share
60
40
20
80
0
60
1st Q tr
2n d Q tr
40
20
0
1st Q tr
2n d Q tr
suddivisione
più razionale
dei compiti
DB
Architetture Multi-Tier
Database
Servers Mail/Groupware
Mainframe
Servers
Systems
Dati
Logica Applicativa
NC . NetPC
Interfaccia Utente
PC Client
Mobile
Architetture Three-Tier: molti tipi di interfacce utente, la
stessa applicazione
Web+ActiveX
o applet Java
Web+script lato server
(ASP, JSP o servlet)
Visual Basic, C++, Delphi
Client/Server
Lotus Notes, Exchange
Groupware
Applicazioni real-time
batch, OLTP, M&Q
Logica
Applicativa
Persistenza
dei dati
Componenti
• Possiedono interfacce standard (almeno un per
l’introspezione)
• Applicazioni non complete
• Distribuibili separatamente
• Utilizzabili in combinazioni non predicibili
• Indipendenti dalle caratteristiche tecnologiche del
sistema finale
• Sono oggetti (nel senso canonico)
Componenti (2)
• Gruppi di programmi gestiti come unità di
codice eseguibile, connettibili
dinamicamente e accedibili attraverso
interfacce documentate che possono essere
identificate a run-time
Come realizzare una componente
Data
Proxy / Wrapper
Ext. method
Data
Ext. method
….
Ext. method
Data
Int. Method
...
Code
Traditional
Int. Method
Obj.
Obj.
Obj.
Obj.
OO
Code
Java Beans
• Integrati nel layout grafico che li contiene
• Generano eventi per il mondo esterno
• Possiedono proprietà leggibili e
modificabili
• Supportano l’introspezione
• Sono persistenti
• Sono personalizzabili
COM e DCOM: le origini
Microsoft
OLE = COM
ActiveX
Pre 1996
Post 1996
COM
OLE1
DCOM
(Distributed COM)
OLE2
OLE
COM+
OLE = Object Linking and Embedding
COM = Component Object Model
COM+ = Estensione della tecnologia COM
COM e DCOM
QueryInterface
IUnknown
AddRef
Release
Interfaccia 1
Oggetto COM
Interfaccia n
COM e DCOM
Nello stesso
processo
Client
Client Process
Sulla stessa
macchina
Tra due macchine
(DCOM)
Oggetto
Client
Client Machine
Client
Server Process
COM
Oggetto
Server Machine
DCE
COM RPC COM
“Marshalling”
Oggetto
Ereditarietà in DCOM
• Ereditarietà dell’interfaccia: SI
• Ereditarieta dell’implementazione: NO
• Polimorfismo degli oggetti DCOM: SI
Ereditarietà per Contenimento (o
delegazione)
Ereditarietà per Aggregazione
Service Oriented Architectures (SOA)
Infrastruttura integrazione
SOA: il sistema informativo organizzato a Servizi
Elemental
Services/
Business
Objects
Composite
Services/
Process
Objects
Inventory
Update
Get Inventory
Inventory
Orders
Client
Applications
Browser
Update
Billing
Update
Change
Get Address
Get Orders
Orders
Get Address
ID No.
Inquire
Orders
B2C Retail
Billing
Customer
Enter
Order
B2B Sales
Inquire
Balance
Call Center
A/R
Get
Balance
Open
Account
Batch
Client
Service-oriented or Event-driven
Service-oriented Architecture Interaction
• Uses interface metadata
• One-to-one connections
• Client directs flow
• Linear path of execution
• Closed to unforeseen input once a flow is started
Client
Server
Interface
proxy
Interface
stub
Event-driven Notification
• Uses event descriptor metadata
• Many-to-many connections
• Sink (recipient) determines flow
Source
• Dynamic, parallel, asynchronous flows
• Can react to new external input while process is in flight
Event
Sink
Flussi di esecuzione
Client 1
Service
Oriented
Server 2/Client 2
Server 1
Server 3
Server 4
Module 4
Module 1
Event
Driven
Event
1
Fork
Module 3
Module 2
Event
2
Join
Event
3
Module 5
Java 2 Enterprise Edition (1)
• Standard Sun per le soluzioni “enterprise”,
prevede le seguenti librerie:
– Enterprise Java Beans (EJB): modello delle
componenti sul lato server
– Java Naming and Directory Interface (JNDI)
– Remote Method Invocation (RMI): accesso
distribuito in rete agli oggetti Java
– Servlets: presentazione dinamica e gestione
sessioni per i client web
Java 2 Enterprise Edition (2)
– Java Server Pages (JSP): facilitano la creazione di
pagine HTML, DHTML e XML
– Java Messaging Service (JMS): comunicazione via
message & queuing o publish & subscribe
– Java Transaction Service (JTA): gestione delle
transizioni distribuite (XA o CORBA OTS)
– Java DataBase Connection (JDBC) accesso uniforme
agli RDBMS
– Java Autentication and Authorization Service
– JavaMail: accesso ai server di posta elettronica
 Costruiti “sopra” i servizi CORBA
Enterprise Java Beans
• Entity EJB
– supportano accessi condivisi
– rappresentano dati persistenti su DB
– identificati da una chiave univoca (primary key)
• Session EJB
– eseguono le richieste di un singolo client
– vita per il tempo della connessione
– implementano la logica di business
• Message-Driven EJB (v. 2.0)
– in ricezione di messaggi asincroni (JMS o altri)
– vita breve per l’elaborazione di un singolo messaggio
Applicazioni J2EE
Entity
Bean
Applet
JSP
Servlet
Session
Bean
Browser
Q
JCA
Resource
Manager
J2ME
DBMS
MessageDriven
Bean
ERP
CICS
Desktop
Server
Elementi di un ambiente EJB
EJB Server
EJB Container
Home
Crea, distrugge, cerca
Object (Remote)
Sicurezza - accesso ai dati - transazioni, ...
EJB Server
• Fornisce la Java Virtual Machine e le classi
di supporto agli EJB
• Fornisce le funzioni di base di ORB e TP
monitor
• Fornisce le funzioni di accesso ai DB
• Realizza il bilanciamento del carico e l’alta
disponibilità
EJB Container
• fornisce l’ambiente in cui gli EJB di una classe
vengono eseguiti
• fornisce ai client l’accesso a EJB Home e Object
• realizza, insieme all’EJB server, i servizi di base:
sicurezza, transazioni, naming, persistenza (dello
stato)
• può gestire pool di oggetti della stessa classe
EJB Object (Remote)
• Rappresenta l’interfaccia dell’EJB verso il
mondo esterno
• Filtra ed integra i messaggi verso le istanze
di EJB
• Coordina le transazioni
• Nome: <classe>
EJB Home
• Permette di creare istanze di oggetti di una
classe e di cercarle
• Nome: <classe>Home
• Metodi:
– create ()
– destroy ()
– interfaccia finder (solo per entity EJB)
Sviluppo di un EJB
Si veda ...
Formati di deployment J2EE
– Ogni prodotto richiede file “deployment descriptor” proprietari per
descrivere le caratteristiche non standard (load balancing, gestione guasti,
risorse…)
Interazioni fra le classi J2EE
Architettura Enterprise JavaBeans
lookup interfaccia
home con JNDI
Deployment
Descriptor
Naming
Service
EJB
Jar
ejbActivate(..)
ejbPassivate(..)
EJB Container
findByPrimaryKey(..)
create(..)
EJB
Objects
Pool
EJB
Home
new o activate
Istanza
del bean
Client
isCallerInRole(..)
metodi di business
es. addPrestito(..)
EJB
Object
metodi del bean es.
ejbRemove()
EJB
Context
contesto di esecuzione fornito in automatico dal
container ad ogni chiamata
Persistenza ed EJB
• Bean-managed persistence (BMP)
– i dati sono acceduti direttamente dal codice
attraverso librerie quali JDBC o SQLJ.
• Container-managed persistence (CMP)
– il container gestisce la persistenza in modo
automatico.
– Container-managed relationships (CMR)
– EJB Query Language (EJB QL)
Mapping fra Entity Beans e DB
Evoluzione delle soluzioni
Microsoft
…….
.NET
DNA2000
COM+
DNA
MTS
DCOM
Internet Network
Computing
Loose Coupling
Enterprise Quality of Service
Three-Tier Architecture
Transactional Components
COM
Distributed Components
Components
1990s
2000s
Microsoft .NET (1)
• CLR (Common Language Runtime)
– interprete di IL (Intermediate Language) derivabile da molti
linguaggi di programmazione: VB, C++, C#, Cobol
– tutti i linguaggi supportati diventano object oriented (ereditarietà,
costruttori parametrici) superando i limiti di COM
– garbage collection della memoria
– gestione delle eccezioni
– sicurezza durante l’interpretazione
– compilatore just-in-time
– gestione delle versioni
• Spazi di nomi gerarchici (namespace)
Microsoft .NET (2)
• Intercomunicazione fra oggetti COM e .NET
• ASP.NET:
– sviluppo di pagine HTML dinamiche con gestione degli eventi sui
controlli visuali (Web Forms)
– sviluppo facilitato di Web Services
Il Framework .Net
System.Web
Services
Description
Discovery
Protocols
UI
HtmlControls
WebControls
Caching
Configuration
Security
SessionState
System.Windows.Forms
Design
System.Drawing
Drawing2D
Imaging
System.Data
ADO
Design
ComponentModel
Printing
Text
System.Xml
SQL
SQLTypes
XSLT
XPath
Serialization
System
Collections
Configuration
Diagnostics
Globalization
IO
Net
Reflection
Resources
Security
ServiceProcess
Text
Threading
Runtime
InteropServices
Remoting
Serialization
JVM e CLR
Executing a Managed Application
SomeSources.exe
Metadata
IL
At execution time the IL and
Metadata are JIT compiled
Running Process’ Memory
JIT Compiler
Native
Machine Language
10010100 10110000 10000000 10111010
11011011 11010111 11000010 01110110
The CPU executes the JITcompiled machine code directly
Altre caratteristiche di .NET
• Librerie XML e web services
• Tutti i linguaggi sono completamente OO
(ereditarietà) ed interoperabili (stesso MSIL)
• Assembly (unità autodescrittive di deployment)
• Versioning delle interfacce (fine del “DLL hell”)
• Remoting
• ADO.NET: vista dei dati basata su XML
Enterprise Services
Gli Enterprise Services
forniscono i servizi di
MTS/COM+
(transazioni, pooling
risorse...)
ASP.NET
Enterprise
Services
ADO.NET
{
eXtensible Markup Language
(XML)
• Standard del W3C
• Deriva dallo Standard Generalized Markup
Language (SGML) come l’HTML
• Orientato alla rappresentazione dei dati
• Il formato di un documento XML è definito in un
DTD (Data Type Definition)
• L’eXtensible Stylesheet Language (XSL) descrive
le regole di trasformazione di documenti XML in
altri documenti XML o HTML
Esempio di documento XML
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE RICHIESTA_PAGAMENTO SYSTEM
“http://www.miodtdserv.com/richiesta_pagamenti.dtd")>
<!-- Messaggio relativo ad una richiesta di pagamento a seguito di
fattura -->
<RICHIESTA_PAGAMENTO>
<FATTURA APPROVATA_DA="Mario Rossi" DATA="22-Set1999“
LIVELLO="Urgente" FIRMATA_DA="Mario Rossi">
<CLIENTE>Burlini Costruzioni spa</CLIENTE>
<ORDINE_ACQUISTO>OA1234X99</ORDINE_ACQUISTO>
<IMPORTO>LIT 100.000</IMPORTO>
</FATTURA>
</RICHIESTA_PAGAMENTO>
Esempio di DTD
<?xml version="1.0" encoding="UTF-8" ?>
<!-- Dichiarazione del documento "Richiesta di Pagamento" ->
<!ELEMENT RICHIESTA_PAGAMENTO (FATTURA)+>
<!ELEMENT FATTURA (CLIENTE, ORDINE_ACQUISTO, IMPORTO)>
<!ATTLIST ARTICOLO APPROVATA_DA CDATA #REQUIRED>
<!ATTLIST ARTICOLO FIRMATA_DA CDATA #REQUIRED>
<!ATTLIST ARTICOLO DATA CDATA #IMPLIED>
<!ATTLIST ARTICOLO LIVELLO (Urgente|Normale) "Normale" >
<!ELEMENT CLIENTE (#PCDATA)>
<!ELEMENT ORDINE_ACQUISTO (#PCDATA)>
<!ELEMENT IMPORTO (#PCDATA)>
I Web Services
• Composizione di applicazioni attraverso componenti
distribuite sul WWW
• Standard, tutti basati sull’XML:
– SOAP (Simple Object Access Protocol) il protocollo di
richiamo di procedure remote come web services
– WSDL (Web Services Description Language): il
linguaggio di definizione dei web services
– UDDI (Universal Description, Discovery and Integration)
il protocollo per ricercare i web services, una sorta di
"elenco telefonico" o "pagine gialle" dei web services
Formato dei messaggi SOAP
• SOAP Header
– dati opzionali sulla chiamata stessa
(autenticazione, pagamento, dove sono
dichiarati i tipi usati, …)
• SOAP Body
– contiene i dati delle chiamate e/o i
risultati di ritorno
WSDL
Abstract Implementation
• WSDL allows Web
services to be self-describing.
• A WSDL document includes nine
basic XML elements:
Port Type
Operation
Messages
<types> …
</types>
<parts> …
</parts>
Maps
To
Binding
Associated
With
Protocol
Port
End Point End Point
• Five abstract elements — port
type, operation, message, part and
type
• Three concrete elements —
service, port and binding
• One definition element —
provides definitions relating to
the service.
WSDL Document Elements
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
definitions
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
element
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
types
element
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
message
element
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<portType name="StockQuotePortType">
portType
element
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
<message>
</portType>
elements
<binding name="StockQuoteSoapBinding">
binding
element
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
operation
element
service
element
port
element
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<portType>
<input>
element
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort"
binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
UDDI Registry Data Structures
<businessEntity >
"white pages"
authorizedName="0100003PAJ" operator=www.ibm.com/services/
uddi businessKey="83B31400-7581-11D5-889B 0004AC49CC1E">
......
"yellow pages"
<businessServices>
<businessService serviceKey="7BB589E0-7586-11D5-889B0004AC49CC1E" businessKey=
"83B31400-7581-11D5-889B-0004AC49CC1E">
8890004AC49CC1E"
>
business process, service description, bindings
References
one or more
.....
</bindingTemplate>
</bindingTemplates>
<tModel
authorizedName="Harpo Marx
operator="www.ibm.
com/services/udi tModel key="983d-999a-4567>
.....
</tModel>
</bindingTemplate>
<bindingTemplate
bindingKey="7BBB0820-7586-11D5-889B0004AC49CC1E serviceKey=
"7BB589E0-7586-11D5-889B0004AC49CC1E">
Business categories (NAICS, UN/SPSC,
geographical taxonomies)
"green" pages
.....
<bindingTemplates>
<bindingTemplate
bindingKey="7BB6C260-7586-11D5-889B0004AC49CC1E serviceKey"7BB589E0-7586-11D5-
Name, description, contacts, categories
<tModel
References
one or more
authorizedName="Chico Marx"operator="www.ibm.com/
services/uddi"
tModel key="1234-3456-7da9">
.....
</tModel>
.......
.....
</businessServices>
tModel
Technical information for using the service
</businessEntity>
business
relationship
<publisherAssertions generic = "2.0"
operator="www.ibm.com/services/uddi" authorizedName="Sweeney Todd" xlmns =
urn:sweeneysmeatpies.com:http>">.
</publisherAssertions>
Publisher Assertions
Asserts a relationship between two Business
Entities
Mapping WSDL to UDDI
UDDI
Registration
File
Business Entity
Business Service
BindingTemplate
tModel
Finds
Points To
Points To
Service Implementation
WSDL
File
Import
Service
Port
Imports
Service Interface
Import
Types
Message
PortType
Binding
Soluzione Java per i Web Services
Middle Tier
Front-End Tier
Application
Server Subtier
Firewall
Load
Internet
OS
Web
Servers
Router
Back-End Tier
JVM
Balancer
Application Server
Web
EJB
Container Container
SOAP
Processor
Legacy
Integration
Brokers
Local
UDDI
WSDL
EJBs
JSPs
Connectors
Servlets
RDBMS
Simple API for XML (SAX).
Document Object Model (DOM)
Trasformazioni XSLT
XSLT (eXtensible Stylesheet Language for Transformations)
Service-Client
ASP.Net
Network
Managed Process
SOAP Method
Request
XML Web
Service
objects
SOAP Method
Response
ASP.Net
ISAPI DLL
Hosting the .NET
Framework CLR
Esempio di Web Service con ASP.NET
DateService.asmx
<%@ WebService Language="C#" Class="DateService" %>
using System;
using System.Web.Services;
public class DateService:WebService{
[WebMethod]
public String GetDateString() {
return DateTime.Now.ToString("D");
}
}
• Servizi implementati in file .ASMX
Esempio di richiamo di un Web Service in .NET
DateClient.cs
using System;
class App{
public static void Main(){
DateService webObj = new DateService();
webObj.Url =
"http://www.miaazienda.com/Services/DateService.asmx";
String dateString = webObj.GetDateString();
Console.WriteLine(dateString);
}
}
• Simple model for network communication
– Object Instantiation
– Method Call
• DateService type is a proxy object
Gli standard XML
IBM’s and Microsoft’s “Web Services Architecture”
(as of September 2002)
BPEL (Business Process Automation)
WS-Transaction
TBD
Reliable
Messaging
Proposed
Standards
WS-Security
WS-Coordination
WSDL, UDDI, WS-Introspection
SOAP (WS Routing, WS Attachment, DIME)
Implemented
Standards
XML, XML Schemas, Encoding
Transports
Pre-Web Services
Standards
Dalle procedure ai servizi
Scope
B2B Market,
Global Enterprise
Small Enterprise,
Complex Application
Homogeneous
Application
Web Services
Typical Access
via
HTTP+SOAP
MOM
Services
ORB
Components
Call
Objects
Program
Procedural
Tighter
Granularity
Coupling
Looser
Coarse