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 User interface Logic Data Management Server Enterprise

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 Nuovo Client Nuovo Client User interface Client Logic Adapter Adapter Data Management Server Enterprise

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 Motif Client Windows Client Telephony Client Mac Client User interface Presentation layer Logic Business layer Business Rules Business Rules Business Rules Data Management Data layer Data Service Data Service Data Service Enterprise

Architetture three-tier - IV User Interface Service consumer Application Logic Service provider Data providers XML Documents DB 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 Clients User Interface Data Components Logic Rules 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 XML Documents DB

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 Web Server Browser utente HTTP 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 Browser utente Web Server /htdocs/hello.html Response: HTML code

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 Web Server Browser utente Business logic Response: pagina HTML di risposta, con eventuali link e bottoni per continuare interazione

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 Enterprise PC stand alone networking End User CLIENT SERVER Le architetture Client/Server nascono all’inizio degli anni ‘90 dall’esigenza di raccordare e coordinare due mondi cresciuti separatamente: Il sistema informativo aziendale, quasi sempre su mainframe, centralizzato e ben organizzato ma anche rigido e con interfacce utente poco amichevoli. Negli anni il sistema informativo si è spesso evoluto integrando, per motivi di risparmio o di decentramento anche minielaboratori (Unix o con sistemi proprietari come VMS o OS/400). I Personal Computer che si sono diffusi negli anni ‘80 e che, soprattutto con l’avvento delle interfacce grafiche e degli strumenti di produttività individuale (database locali, fogli elettronici, word processor) hanno aumentato le aspettative degli utenti in termini di velocità di realizzazione delle applicazioni e di facilità d’uso. L’avvento delle reti di PC ha poi formato isole poco integrate fra loro e, soprattutto, poco integrate con il sistema informativo aziendale.

Allocazione Delle Componenti Data Management Logic/ Control Presentation SERVER CLIENT NETWORK Un’applicazione può essere suddivisa logicamente in tre parti: la presentazione che gestisce l’interfaccia utente (gestione degli eventi grafici, controlli formali sui campi in input, help, …) la logica applicativa vera e propria la gestione dei dati persistenti su database Fisicamente queste componenti dovranno essere allocate su client e server. La scelta della politica di allocazione di queste componenti porta alla classificazione della pagina successiva.

Classificazione delle soluzioni Client/Server Data Logic Presentation Char. Terminal X-Terminal PC Timesharing Client Distributed Application Central Database Server Centralized Decentralized Timesharing: è la soluzione monolitica precedente al client/server, tutto risiede sul server, il terminale è a caratteri, l’interfaccia poco amichevole Client Presentation: solo la logica di gestione dell’interfaccia utente è locale al client, è il caso degli X-Terminal ma anche dei browser (senza applet) Distributed Application: la logica applicativa è distribuita (ad esempio: controlli sul client, elaborazioni più pesanti sui server. A questa categoria appartengono soluzioni quali: stored procedure, architetture three-tier, browser+applet. Central Database (detto anche “fat client” o “two-tier”): sul server rimangono solo i dati, in rete passano comandi SQL. E’ la soluzione più diffusa nella prima stagione del client/server Distributed Database: sui client risiedono anche i dati, la soluzione risolve alcune lentezze del fat client ma con problemi proibitivi di allineamento dati. Ha avuto successo solo in caso di utenti mobili (automazione forza vendita, tecnici di manutenzione impianti…)

Le “ere” del Client/Server Questo schema rappresenta una serie di “ondate” successive che riguardano le architetture: File server (file sharing): i server offrono servizi di file system condiviso Database server (fat client): applicazioni client/server che vedono il server come fornitore di dati, corisponde al modello “Central Database” dello schema precedente Groupware: applicazioni collaborative che vedono i documenti (e non le tabelle relazionali) come principali dati manipolati TP monitors: sono le applicazioni di fascia alta (molti utenti) che le soluzioni database server non possono gestire Distributed objects: applicazioni ad oggetti (componenti) distribuiti - CORBA o DCOM lo schema è datato ma permette di descrivere l’evoluzione tecnologica della seconta metà degli anni 90 Da: Byte Aprile 95

HTML Dinamico????? Tier 1 Tier 2 Tier 3 Web Server HTML DATI JSP Application server Web Server browser HTML 1. richiesta .jsp Internet (htpp) 2. richiesta dati DATI JSP Business Objects servlet 4. ritorna html 3. generazione html servlet

Architetture Two-Tiers e Three-Tiers Market Share Market Share DB minore uso delle risorse suddivisione più razionale dei compiti livello intermedio DB Market Share DB Market Share DB Market Share

Architetture Multi-Tier Mail/Groupware Servers Database Servers Mainframe Systems Dati Logica Applicativa Key point: This is a transition slide. Use to introduce the topic of building 3-tier applications. 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 Strategic Planning Assumption: Through 2002, the majority of IS organizations successfully implementing CBD applications will use non-OO components, especially “wrapped” legacy and package programs/modules, as a major part of their application portfolio (0.8 probability). Come realizzare una componente Data Code Proxy / Wrapper Data Ext. method …. Data Int. Method ... Code Traditional Obj. Obj. Obj. Obj. Source: Gartner Research Components can be created in many ways, but all share some common characteristics. A component will typically expose external methods or services which can be bound dynamically (i.e., at runtime rather than only at compile time). Many components will also have internal methods that are available only to code residing inside the component. Some (but not all) components contain data. Most components encapsulate both data and code, meaning that these cannot be accessed directly and may only be accessed by invoking external methods. Components may be true objects, but this is not a requirement. Components are often not true objects because they do not necessarily support inheritance, where a new class of objects is defined in terms of an existing class using inheritance. Components may be implemented in many ways. One of the most common (and valuable) is when a component on one platform acts as a proxy to access services defined on another. A common example of this approach is wrapping legacy code and data that might be located on a mainframe. Although components may not always be true objects, they may be implemented using objects and will often be a convenient way to package object code for delivery. Action Item: When building new CBD applications or evaluating CBD technologies, enterprises should ensure that legacy-wrapping capabilities and services are part of the solution. OO

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 COM DCOM OLE1 OLE2 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 Sulla stessa macchina Oggetto Client Client Process Server Process Sulla stessa macchina Oggetto COM Client Tra due macchine (DCOM) Client Machine Server Machine Oggetto DCE RPC COM COM Client “Marshalling”

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) Tactical Guideline: The fundamental principle of successful IS city planning (application integration) is to manage the connections between the applications as if each system were in an opaque “black box.” Service Oriented Architectures (SOA) Infrastruttura integrazione Key Issue: How will enterprise architecture best practices evolve to accommodate heterogeneity in the next five years? A systematic attack on the challenge of application integration is based on the principles of modularity and encapsulation. An application system can be said to have two information models: an internal model that applies within the system and an external (or “exchange”) model that describes its relationships with the outside world. Traditional architecture stresses the internal model, but that is not central to the problem of integration. The exchange model is an information architecture that describes the schema formats, semantics and behavior of the interactions with other systems or people outside a logical black box. The enterprisewide message dictionary or interface repository enables reuse of the interface definitions and, sometimes, the actual messages. The exchange repository may include application-level dialog (or protocol — now labeled a type of business process management). A very coarse-grained enterprise data model helps with the design of the exchange model, but a detailed internal data model of the participating systems is unnecessary. The integration competency center must cooperate closely with central data administration, because operational data stores and data warehouses may be fed through the enterprise nervous system and its message warehouses. Action Item: The exchange data model should be developed incrementally as new applications are added or modified, rather than attempting a comprehensive, enterprisewide interface model, before starting any development work.

SOA: il sistema informativo organizzato a Servizi Tactical Guideline: Reusing big things (e.g., services) through messaging is easier than reusing small things (e.g., classes or subroutines) through copying, especially if many different development teams are involved. Customer Billing A/R Inventory Orders Elemental Services/ Business Objects Get Inventory Update Inventory Get Orders Update Orders Get ID No. Get Address Change Address Update Billing Get Balance Composite Services/ Process Objects Inquire Orders Enter Order Inquire Balance Open Account Call Center B2C Retail B2B Sales Batch Client Client Applications Key Issue: What will be the critical success factors for implementing architecture in the next five years? Service-oriented architecture reuse differs from traditional code reuse or object-oriented (OO) class reuse. Services are reused just by sending messages from disparate clients to one shared service through runtime middleware (“delegation”); whereas code or class reuse involves copying or inheriting code through a programming language tool. Elementary services call no other services. Enterprises sometimes use composite services that invoke a sequence of other composite or elementary services. Composite services can be implemented in “process” or “task” business objects, or in business process “orchestration” tools. Developers have many design choices (e.g., whether to use many small services or a few bigger services). The most widely shared functions (e.g., maintaining customer, product and employee information) are often implemented as services because they are the most widely reused kinds of information. It is not necessary, and it is often impractical, to implement all of an application’s work as services. Action Item: New, large-scale applications with long expected life spans should use a service-oriented architecture for all functions that are potentially reusable. Browser

Service-oriented or Event-driven Decision Framework: SOA interactions have interface “contracts” that describe the sequence and contents of a two-way communication process spanning two or more messages. By contrast, event-driven notification is a one-way, non-interactive form of communication that is documented by event descriptors that hold message schema. 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 Dynamic, parallel, asynchronous flows Can react to new external input while process is in flight Source Event Sink SOA and event-driven architecture have many similarities. Both are ways of combining multiple software modules into large, distributed applications. They go beyond conventional application design by separating the interface definition (or event descriptors) from the software implementation. Either may be enabled through Web services, although neither requires Web services. However, they differ in the way they organize the relationships among the modules. At the risk of oversimplification, SOA uses directed, generally bi-directional, request/response communication to delegate work to a subordinate procedure, whereas event-driven architecture uses unidirectional messaging to communicate among two or more, largely independent peer procedures. In a SOA, a client application will find, then bind to and invoke a service. In an event-driven relationship (notification), sources do not find, bind or invoke sinks. The only communication is through the data in a software event. An event source does not need to know who or what is supposed to receive the event or what the sink will do with it. Just as object-oriented developers think about and define objects, event-oriented developers think about and define events as a primary focus of attention. Applications often intermingle service and event relationships in the same set of applications. Action Item: IS architects and developers must understand the local business requirements and process models to determine if SOA, event-driven architecture or some combination of them is the best solution.

Flussi di esecuzione Service Oriented Event Driven Client 1 Server 1 Decision Framework: EDA is decoupled; asynchronous SOA is loosely coupled; synchronous SOA is somewhat coupled; and monolithic (non-SOA) applications generally are tightly coupled. Client 1 Service Oriented Server 1 Server 2/Client 2 Server 3 Server 4 Module 4 Event 1 Module 1 Fork Event 2 Module 3 Event Driven Join Module 5 Event 3 An SOA client (for example, a Web services “consumer”) invokes a service (for example, a Web services “provider”). The client decides when and if to invoke a particular server. A client always holds information about the state of the business process, but an SOA server is often stateless. By contrast, each runtime connection in an EDA is potentially a many-to-many relationship, where the overall processing flow is determined by the event sinks or “subscribers” (modules that receive the event). An event published by one source may be delivered to multiple “sinks” (a one-to-many relationship that forks the flow of control). EDA is more efficient than SOA if there are multiple destinations for the same data because the source sends the event only once, whereas an SOA client would have to make successive calls through multiple interfaces to achieve the same wide distribution. Each sink may receive multiple events before taking any action, enacting a many-to-one relationship that joins the flow of control. Sources do not know anything about the sinks, and vice versa. The event itself contains state information. Event sources and sinks may be added, modified or deleted without affecting any other source or sink. Action Item: Use SOA when the nature of the business problem requires a request/response relationship in which the client module gets some answer (immediate or deferred) from a subordinate procedure before it can complete its work. Use events for applications in which multiple processing streams may execute simultaneously; the timing of events, such as the beginning or end of a step, or the arrival of additional external input, is unpredictable; or there is a need to dynamically add, drop or modify processing steps without changing any running modules in any way. EDA also improves the understanding of what is happening in the business process. Module 2

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 Session 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 Session Servlet Bean Message- Key Issue: What will be the technology evolution and business case for J2EE and .NET? Applicazioni J2EE Entity Bean DBMS Applet JSP Servlet Session Bean Message- Driven Bean Q Browser J2ME JCA Resource Manager ERP J2EE was first introduced in 1998. It was initially designed by Sun with substantial input from IBM and additional influential input from BEA and other enterprise infrastructure vendors. J2EE architecture reflects the advanced enterprise expertise of its designers. The architecture places most of the application on the server (a break from the fat-client architecture of the past). J2EE separates various styles of business logic into separate styles of software. Java Server Pages and Servlets are intended to be used for user-interface logic of the application. Enterprise Java Beans (EJBs) are intended to be used for reusable back-end business logic of the application. Entity EJBs are designed to represent encapsulation of data and sessions and to control the overall process of a transaction. J2EE Connectors Architecture components are intended to be used for building adapters to external applications (packages or legacy). Message-driven Beans are intended for reusable business logic that is designed to operate in an event-driven mode, responding not to synchronous request/reply clients, but to asynchronous posting of events. The rich architecture of J2EE is also complex and requires advanced technical skills to take full advantage of its technical features. The majority of J2EE applications use only a small subset of all available features. Action Item: J2EE is a rich architecture. Evaluate its features and match your project skills and requirements to an appropriate subset of J2EE. 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 J2EE components can be deployed in various types of JAR files, as depicted in figure 1.11. When you roll your components into production, you might archive your EJB JAR files and WAR files into a single Enterprise Application Archive (EAR) file and deploy it. However, there is a large amount of vendor specific configuration to be done for each component before it is deployed. Creating the individual components and then integrating them into an application archive is more complicated than it appears. Current J2EE server implementations require a vendor-specific deployment descriptor file to be included with your EJB and web components. These files handle the deployment specifics that are not addressed by the generic J2EE descriptors. These specifics include nonfunctional characteristics like load balancing and failover information and resource mappings for references made in the standard deployment descriptors. 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 EJB Container Client EJB Jar Deployment Descriptor Istanza del bean Naming Service EJB Home EJB Context EJB Object lookup interfaccia home con JNDI findByPrimaryKey(..) create(..) new o activate EJB Objects Pool ejbActivate(..) ejbPassivate(..) isCallerInRole(..) contesto di esecuzione fornito in automatico dal container ad ogni chiamata metodi del bean es. ejbRemove() metodi di business es. addPrestito(..)

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 Strategic Planning Assumption: By 2007, Microsoft will evolve its enterprise architecture (now .NET) to a new vision of integrated real-time enterprise, substantially altering its initial set of middleware and tools (0.6 probability). Evoluzione delle soluzioni Microsoft ……. .NET DNA2000 Internet Network Computing COM+ DNA Loose Coupling MTS Enterprise Quality of Service DCOM Three-Tier Architecture COM Transactional Components Distributed Components Components Key Issue: What will be the technology evolution and business case for J2EE and .NET? .NET is the latest deliverable in Microsoft’s evolution from a vendor of desktop software to a vendor of distributed enterprise infrastructure. Microsoft has come a long way since the early days of COM and DCOM. .NET is the second time Microsoft has introduced radically new software infrastructure technology. The first was the introduction of Microsoft Transaction Server in 1996. Then a new programming model and much new technology was introduced, but the fundamental COM base was preserved. With .NET, the COM base, initially designed for the desktop and stretched to its limits to support enterprise computing, is now retired and replaced by the infrastructure of common language run-time. .NET represents a fundamental change in Microsoft enterprise computing software. Transition from COM/COM+ to .NET will take many years and will carry major transition costs, for vendors of Microsoft-based tools and for enterprises that own IT. On the other side of this process lie the benefits of Microsoft’s new vision of a loosely coupled distributed enterprise. However, Microsoft’s .NET vision is not yet fully jelled. New ideas and new application styles associated with the emerging integrated real-time enterprise will lead .NET to significant extensions and changes through 2005. Microsoft enterprise infrastructure will not reach maturity or slow down its pace of change until 2006. Action Item: Prepare for a lengthy and expensive transition to the still-evolving .NET. 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 System.Data System.Xml System.Web Globalization Diagnostics Configuration Collections Resources Reflection Net IO Threading Text ServiceProcess Security Design ADO SQLTypes SQL XPath XSLT Runtime InteropServices Remoting Serialization SessionState Caching Services Description Discovery Protocols UI HtmlControls WebControls System.Drawing Imaging Drawing2D Printing System.Windows.Forms ComponentModel

JVM e CLR

Executing a Managed Application At execution time the IL and Metadata are JIT compiled SomeSources.exe IL Metadata Running Process’ Memory JIT Compiler Native Machine Language Sample Dialog: When a user executes a managed application, the system immediately loads the CLR unto the new processes. The CLR then begins JIT compiling the IL from the executable and executing it. It is not necessary for every IL instruction in an executable to be JIT compiled before it is run. This happens as needed, on a method-by-method basis. Once the code is running, it is run directly by the CPU. However, the JIT compiler emits code that insures that your program remains manageable by the CLR. So even though the code is running native, it is always managed code. The notion of managed code running in native machine language can be tough to comprehend. But the point is that it is IL until the point of running. It is the CLR that creates the machine language, so it has all of the control necessary to maintain the managed status of the software. 10010100 10110000 10000000 10111010 11011011 11010111 11000010 01110110 The CPU executes the JIT- compiled 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 ASP.NET Enterprise Services ADO.NET 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-Set-1999“ 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

Abstract Implementation Strategic Planning Assumptions: By 2007, at least 25 percent of all WSDL Web services will be invoked inside the enterprise’s firewall, and the majority of these will not use Internet communications; in other words, at least 25 percent of Web services will not be Web-based (0.7 probability). By 2007, more than 90 percent of enterprises that use Web services will host Web services implementations on two or more Web services provider platforms (0.9 probability). 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> 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. Maps To Binding Associated With Port Protocol Key Issue: What exactly are Web services and how do they work? WSDL is a syntax and vocabulary for creating an XML-based interface to an application. As such, it provides several pieces of information. WSDL specifies a standard format for specifying messages and data passed between a Web service’s client and server, describes the semantics for these messages (i.e., unidirectional or bi-directional, asynchronous or synchronous) and includes directions for accessing a Web service using one or more transport protocols. Many WSDL tools can also create client-side proxies, called stubs, which make it easier to access a Web service. In this sense, WSDL acts like other interface definition languages (IDLs). WSDL allows Web services to be self-describing. Using WSDL, a Web service can describe its location, protocol interfaces and operations in much the same way that Java objects and components use reflection and introspection. This allows humans and computers to dynamically discover and use Web services when needed. Having a standard set of service-oriented messaging facilities and a standardized mechanism for discovering services is of no use if there is no way to describe what a service is and how its facilities can be accessed. Enter WSDL, recently submitted to the W3C XMLP Working Group and expected to be a recommendation by year-end 2003. As communications protocols and message formats are standardized in the Web community, the ability to describe the communications in some structured way becomes increasingly possible and important. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication. Action Item: Evaluate tools that provide support for WSDL. End Point End Point

WSDL Document Elements Key Issue: Where is WSDL heading? Web services publishers — that is, organizations that list Web services on the registry — use the documents to publish and describe their services. Web services consumers — that is, clients who are looking for Web services — download these documents, and use the information to locate and work with the services. The interaction between Web services publishers and consumers is: 1) The consumer gets the WSDL file’s URL, or address, and requests the file. This address can be an individual file, a server or a Web services registry. 2) The publisher processes the consumer’s request (most commonly via HTTP) and sends the WSDL document to the consumer. 3) The consumer’s XML parser reads the file, processes the elements and loads the WSDL file into the Document Object Model (DOM). 4) The consumer uses an appropriate WSDL client to create an XML service invocation request, most frequently via SOAP. This client may accompany or be included in the WSDL file. 5) The consumer’s SOAP service creates the SOAP envelope, adds the request to the payload and sends the SOAP document to the publisher’s URL. 6) The publisher’s Web services proxy parses the message, extracts the payload and calls up the appropriate processing facilities, which return their responses to the proxy. 7) The publisher’s proxy collects the response, translates it to XML, creates a SOAP message and puts the response in the payload, and returns it to the consumer via HTTP.

UDDI Registry Data Structures Key Issue: What is the prognosis for UDDI? In many ways, UDDI is the most complex of the three canonical Web services. The registry itself is populated by five data structures, many of which come directly from WSDL documents. The business entity is the topmost element in a registry file; it describes the publishing organization, and provides contact and querying information. Just below this is the business services element, which offers human-readable, nontechnical information about the service and at least one binding template for binding to the service using a specific protocol. The binding template explains how to locate and connect to the Web service by referencing at least one tModel document. tModels are probably the most important documents in the registry. They are relatively free-form documents that contain details about the service, such as where it is located, or programmatic information for binding to the service. tModels can include additional APIs or specifications, information directed to programmers, or even encapsulate information directly from a Web service’s WSDL document. Canonical tModel files are available from classification organizations such as Dun & Bradstreet. The last data structure, the publisher assertion, declares a business relationship between two or more entities in a UDDI registry. These are most often used to identify subdivisions or departments of a larger organization, or membership in an industry association.

Mapping WSDL to UDDI Business Entity UDDI tModel Registration Strategic Advice: Create a WSDL document for every Web service to be listed in a UDDI registry, because WSDL document elements map directly into UDDI registration files. Business Entity UDDI Registration File tModel Business Service BindingTemplate Finds Points To Points To Service Implementation Service Interface Import Imports Import WSDL File Service Types Port Message PortType Key Issue: What is the prognosis for UDDI? UDDI registries can leverage and aggregate information from WSDL documents to populate Web services registration and tModel documents; however, WSDL documents are not mandatory for UDDI registrations. In general, a UDDI business entity can point to information in a WSDL service implementation (the concrete elements in a WSDL file), and a UDDI tModel can point to any or all information in the WSDL service interface (the abstract elements in the WSDL file). There are also some specific correspondences between UDDI and WSDL elements, with which information from the WSDL can be directly loaded into UDDI; for example, a WSDL service element corresponds to a UDDI business service element, a WSDL port corresponds to a UDDI binding template, and the type, message, port type and binding elements from WSDL can be loaded directly into a UDDI tModel. UDDI is itself a Web service with its own WSDL file. It exposes itself as a Web service to describe the UDDI registry. UDDI models itself in UDDI and — at least in version 2.0 — has two tModels: one representing the publishing API and the other representing the inquiry API. UDDI version 3.0 may add more tModels to correspond to the additional APIs that are furnished with the specification. Binding

Soluzione Java per i Web Services Front-End Tier Middle Tier Back-End Tier Application Server Subtier Firewall Load OS Web Servers Internet Router JVM Application Server Legacy Balancer Web Container EJB Container Integration Brokers SOAP Processor Local UDDI WSDL RDBMS Servlets Connectors EJBs JSPs

Simple API for XML (SAX). Using SAX, the parser reads in the XML data source and makes callbacks to its client application whenever it encounters a distinct section of the XML document. For example, a SAX event is fired whenever the end of an XML element has been encountered. The event includes the name of the element that has just ended. To use SAX, you implement an event handler for the parser to use while parsing an XML document.

Document Object Model (DOM)

Trasformazioni XSLT Performing XSLT transformations requires an XSLT-compliant processor. The most popular open source XSLT engine for Java is the Apache Software Foundation’s Xalan project. Information about Xalan can be found at http://xml.apache.org/xalan-j. XSLT (eXtensible Stylesheet Language for Transformations)

Hosting the .NET Framework CLR ASP.Net Web Server Network Service-Client Managed Process ASP.Net ISAPI DLL Hosting the .NET Framework CLR SOAP Method Request XML Web Service objects Sample Dialog: Here is a birds-eye view of the ASP.Net model. Client software makes a soap request for a web service resource via HTTP sent to the server. [Click] The server notices that the request is for a resource with the .asmx extension, and passes the request to ASP.Net ISAPI DLL. [Click] The DLL hosts the runtime in process and creates managed objects, some built in, some custom, that marshall the request from soap into a method call [Click] and marshal return data from the call back into SOAP ASP.Net then sends the response back to IIS [Click] The web server sends the response back to the client software [click] and the client goes on its way, possibly making more requests, perhaps not. Speaker Instructions: This slide is animated to help tell the story. I have put [click]’s in where you might click the mouse. You should practice animated slides more than non-animated slides, because timing is important. SOAP Method Response

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"); } Sample Dialog: Web services are just C# or VB.Net code stored in a file with a .ASMX extension. The file is then stored in a virtual root where IIS can serve them to clients. The first time that an .ASMX file is served, it is compiled by ASP.Net, and then the binary object is executed. All successive requests skip compilation and just execute the methods in the binary object. ASP.Net manages the marshalling of parameters and return values to SOAP. Speaker Instructions: 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); } Sample Dialog: Meanwhile, if you use managed code top create a client it is similarly simple to creating a web service. This code shows a client that points to a web service on the internet. It simply performs the network communication by instantiating an object and calling a method. In this example, the DateService type is a proxy that was automatically generated from a WSDL description of a web service. . Simple model for network communication Object Instantiation Method Call DateService type is a proxy object

Gli standard XML BPEL (Business Process Automation) WS-Transaction IBM’s and Microsoft’s “Web Services Architecture” (as of September 2002) BPEL (Business Process Automation) Reliable Messaging WS-Security WS-Transaction Proposed Standards TBD WS-Coordination WSDL, UDDI, WS-Introspection Implemented Standards SOAP (WS Routing, WS Attachment, DIME) XML, XML Schemas, Encoding Transports Pre-Web Services Standards

Dalle procedure ai servizi Web Services Services Components Granularity Scope B2B Market, Global Enterprise Coarse Objects HTTP+SOAP MOM ORB Typical Access via Small Enterprise, Complex Application Homogeneous Application Program Tighter Looser Coupling Procedural Call Source: Gartner Research E-business demands continue to be the overriding driver of application change in most enterprises. These demands are often best met with packaged solutions. Yet, the old business expectations continue to exist. AD organizations should not randomly dismiss restructuring existing systems to introduce flexibility — particularly where the quality of service, performance and data volume characteristics are high. Leverage your skills and infrastructure, while you move toward a more-complex mix of platforms, applications and technologies. Training has never been more important than now; recognize that not all your staff can make the transition to some of the new technologies (e.g., Unix servers, Java, OO, modeling, Internet, components, distributed computing). While many organizations first want to hire programmers with the right skills, more should train their skilled programmers in the technologies of tomorrow. The talents of your people do not solely reside in their technology skills. Evolve your development organization to a component/assembly mentality where reuse is rewarded — even on existing mainframe environments! Flexibility is possible, even on mainframe-based, COBOL legacy systems.