Il documento presenta un'architettura di riferimento per applicazioni enterprise, evidenziando i componenti fondamentali e le loro responsabilità. Viene descritta la struttura dell'edificio in layers e tiers, spiegando le funzioni di ciascun componente e fornendo esempi pratici con tecnologie come J2EE e XML. Inoltre, si discute dell'importanza di tale architettura nel facilitare la comprensione delle tecnologie e nella scelta delle soluzioni progettuali.

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

2. >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.

3. 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

4. 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#.

5. Avvertenza UML exposed

6. 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

7. I parte La struttura dell’edificio I Layers I Tiers I servizi L’applicazione

8. La struttura dell’edificio 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”

9. I Layers I piani, dalle fondamenta all’alloggio

10. 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

11. 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

12. 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”

13. I Tiers Le camere dell’alloggio

14. 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

15. 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

16. 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

17. 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

18. 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”

19. I servizi del service layer

20. L’applicazione

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

22. User e Workspace Tier

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

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

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

26. Business Tier

27. Business Tier Command Pattern

28. 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 .

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

30. 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>

31. 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.

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

33. Resource Tier

34. Resource Tier - Adapter Pattern

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

36. 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

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