Un'architettura di riferimento per applicazioni enterprise

Un'architettura di riferimento per applicazioni enterprise Alberto Lagna [email_address] Mario Zannone [email_address] Webb.it – 3 Giugno 2004 Milano

>apropos alberto.lagna
Laureato in informatica, master in telecomunicazioni.
Consulente indipendente, lavora come architetto software.
Fornisce consulenza nel design e lo sviluppo di sistemi enterprise basati su j2ee e XML.
Ha un esperienza di più di 10 anni nella realizzazione di soluzioni ad oggetti distribuiti.
membro del JUGTORINO
Promuove l’uso di software libero e supporta il movimento open source.

Due parole sul JUG
Nasce dall'idea di alcuni appassionati di programmazione e Java nel “lontano” febbraio 2002. Ora siamo circa 200 iscritti
Lo scopo e' quello di favorire l'interscambio di conoscenze informatiche e creare un punto di riferimento nel panorama degli sviluppatori Java in Italia
La partecipazione alle attivita' e del tutto gratuita e libera
Il JUG gestisce, tra le altre, una serie di attivita’ tra cui meeting, scrittura di articoli e review di libri per note case editrici

oggetto della presentazione
In una cucina
il lavandino per preparare i cibi
il fornello per cucinarli
il frigorifero per conservarli.
Questa presentazione:
i componenti fondamentali per realizzare un'applicazione enterprise aperta, portabile scalabile duratura
Architettura di riferimento distillato dell'esperienza di anni di progettazione IT del relatore
Verranno introdotti i principali componenti, le loro responsabilità e le possibili scelte di distribuzione fisica.
Verranno proroposti mapping ed esempi concreti che utilizzano tecnologie XML, Java e C#.

Avvertenza UML exposed

agenda
I parte
La struttura dell’edificio
I Layers
I Tiers
I servizi
L’applicazione
II parte
Esempi
User e workspace tier
MVC pattern
Business Tier
Command pattern
Resource Tier
Adapter pattern
D&R

I parte
I Layers
I Tiers
I servizi
L’applicazione

Layers (piani)
separazione dei tipi di logica
logica di buz
servizi
infrastruttura
è diviso in tier
Tiers (stanze)
distribuzione logica delle funzionalità.
ciascun tier ha ruoli e responsabilità (SoC)
distribuzione fisica
scalabilità
riuso
user business workspace resource services infrastructure application infrastruttura tecnica e di comunicazione comune utilità comuni applicate tra i vari tier Tiers Layers Presentazione e indipendenza dal device sessione utente e filtro dati input processi ed entità di business risorse enterprise condivise logica di business “applicativa”

I Layers
I piani, dalle fondamenta all’alloggio

I Layers (1/3)
Infrastrucure layer
il più vicino al sistema operativo
fornisce le funzionalità comuni
trasporto, la sicurezza, i meccanismi di naming e directory.
l’implementazione è responsabilità della piattaforma middleware (es l’application server j2ee).
infrastructure Layers

I Layers (2/3)
Service layer
è a disposizione di tutti i componenti applicativi
logica non applicativa
autenticazione, autorizzazione, profilazione, logging, gestione delle eccezioni, tracking, configurazione, gestione degli eventi.
modifica su di un servizio immediatamente a disposizione di tutti i componenti applicativi.
services infrastructure Layers utilità comuni applicate tra i vari tier

I Layers (3/3)
Application layer
funzionalità business tipiche di un'applicazione
è ulteriormente suddiviso in tier,
ciascuno con ruoli diversi
sempre nell'ambito della stessa applicazione
ospita tipologie di componenti predefinite.
services infrastructure application Layers logica di business “applicativa”

I Tiers
Le camere dell’alloggio

I Tiers - User Tier
responsabile per tutte le interazioni con l'utente.
gestisce l'input che l'utente inserisce per un particolare business component
lo valida
lo trasferisce al Workspace Tier
è posizionato il più vicino possibile al software che permette l'interazione utente:
x applicazione web è rappresentato da i componenti che la pagina web dinamica fa eseguire sul client (codice html e javascript di input e validazione).
x applicazione a web service i bindings
user Tiers Presentazione e indipendenza dal device

I Tiers – Workspace Tier
mantiene la sessione utente
manipola i dati dell'utente ad essa associato.
fornisce la logica di business locale per la quale non è necessario accedere a risorse enterprise
passa informazioni conservate nel contesto di sessione al Business Tier nel messaggio di richiesta.
è il front end del server
x applicazione web vive nel web server
x applicazione web services è un handler
user workspace Tiers sessione utente e filtro dati input

I Tiers – Business Tier
il punto in cui è implementata la logica di business
controlla le business rule, aggiornamento in modo atomico e consistente delle entità enterprise
garantisce l'integrità dell'informazione enterprise, attraverso il controllo dei constraint sui dati e del contesto delle transazioni.
netta separazione dall’accesso alle risorse (del Resource Tier) x aumentare la riusabilità del codice
La granularità con cui la logica di business è esposta ha conseguenze dirette sulla scalabilità e sulla riusabilità del codice
granularità fine, in cui ogni Business Function realizza una ben precisa e delimitata funzione permette di raggiungere un alto grado di riusabilità
se lo stesso livello di granularità viene esposto verso il Workspace Tier, l'impatto su performance e scalabilità può essere disastroso
L'architettura tecnica indirizza questo problema esponendo da Business Tuer verso Workspace Tier interfacce a granularità grossa
user business workspace Tiers processi ed entità di business

I Tiers – Resource Tier
garantisce la separazione della logica di business
dall'architettura dei dati
dalle applicazioni esterne
sistema più modulare, più facilmente estensibile e mantenibile, limitando l’impatto delle variazioni al solo tier interessato.
comprende la logica necessaria per gestire due tipi fondamentali di risorse:
le informazioni salvate sulla base dati, e cui nessun altro tier ha accesso
i servizi applicativi di applicazioni preesistenti (legacy o COTS).
supporta il Business Tier restituendogli lo stato persistente delle risorse richieste e salvandole, all'atto di un aggiornamento.
le modalità di accesso alla base dati sono gestite internamente al Resource Tier
user business workspace resource Tiers risorse enterprise condivise

Di nuovo tutti insieme user business workspace resource services infrastructure application Tiers Layers processi ed entità di business infrastruttura tecnica e di comunicazione comune utilità comuni applicate tra i vari tier Presentazione e indipendenza dal device sessione utente e filtro dati input risorse enterprise condivise logica di business “applicativa”

I servizi del service layer

L’applicazione

II parte
Esempi
User e workspace tier
MVC pattern
Business Tier
Command pattern
Resource Tier
Adapter pattern

User e Workspace Tier

User e Workspace Tier Model-view-controller pattern V M C

User e Workspace Tier V M MVC: Esempio J2EE: Struts

User e Workspace Tier MVC : Esempio .Net (e J2EE): Maverick (http://mavnet.sourceforge.net/)

Business Tier

Business Tier Command Pattern

Business Tier e XML
I messaggi di richiesta e risposta a/da Use Case Controller possono essere codificati in XML.
Lo Use Case Controller può essere un componente generico e profilabile. La profilazione può essere descritta in uno o più file XML.
L’approccio è valido sia per J2EE che per .Net .

Business Tier Esempio di profilazione XML (UCC) < usecase name=“multiply” > < task > < step type ="com.zzz.debug.TraceBF" xslin="sample.xi" /> <step type="com.zzz.sample.MultiplyBF" xslout="sample.xo"/> </task> <task kind="transaction"> <step type="com.zzz.sample.BF00" /> <step type="com.zzz.sample.BF01" /> <step type="com.zzz.debug.TraceBF"/> </task> <task kind="onerror"> <step type="com.zzz.debug.TraceBF" /> </ task > </ usecase >

Esempio di messaggio XML in ingresso al Business Tier <message> <envelope> <usecase> multiply </usecase> <principal> <identity> momo </identity> <role> ADMIN </role> </principal> <channel> web </channel> </envelope> <payload> <request> <factor> 77 </factor> <factor> 88 </factor> <factor> -1 </factor> </request> </payload> </message>

Business Tier Java vs. C#
Con un’architettura di riferimento comune e con l’uso di XML le differenze sono meno delle attese
Esempio di metodi esposti da un UCC J2EE • String Execute (String message) Esegue una richiesta: riceve la 'pratica' come stringa e ritorna la 'pratica' elaborata come stringa. • Document Execute (Document message) Esegue una richiesta: riceve la 'pratica' come XmlDataDocument e ritorna la 'pratica' elaborata come XmlDataDocument.
Esempio di metodi esposti da un UCC .Net • string Execute (string message) Esegue una richiesta: riceve la 'pratica' come stringa e ritorna la 'pratica' elaborata come stringa. • XmlDocument Execute (XmlDocument message) Esegue una richiesta: riceve la 'pratica' come XmlDataDocument e ritorna la 'pratica' elaborata come XmlDataDocument.

Business Tier – J2EE vs .NET J2EE .NET Use Case Controller Stateless Session EJB Stateless MTS (COM+) Component Business Function Java class C# Class

Resource Tier

Resource Tier - Adapter Pattern

Resource Tier Tecnologie J2EE e .Net J2EE .Net Data Base JDBC Hybernate ADO .Net External Application JMS Web Services MSMQ Web Services

Conclusioni
Un’architettura di riferimento
Aiuta la comprensione di tecnologie nuove e l’individuazione di similitudini e differenze rispetto a tecnologie note
Serve come guida nella scelta di tecnologie e prodotti
Permette di fare scelte di disegno non dettate direttamente dal prodotto e dalla specifica tecnologia e quindi più flessibili e durature
Estende il valore nel tempo ed il campo di applicabilità degli skill dei singoli progettisti e dell’organizzazione nel suo insieme

D&R
Alberto Lagna [email_address] www.whitebox.it
Mario Zannone [email_address]

Un'architettura di riferimento per applicazioni enterprise

by Alberto Lagna on Apr 18, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 13

Statistics

Un’architettura di riferimento per applicazioni enterprise — Presentation Transcript