venerdì 18 febbraio 2011

Sviluppare RIA con Flash, Silverlight o Java: tecnologie a confronto

Mi sono domandato quale fosse la tecnologia migliore da adottare attualmente per realizzare una piccola presentazione grafica su un sito.
Quando navighiamo in internet ormai ci troviamo di fronte a delle vere e proprie applicazioni interattive graficamente accativanti: sono le cosiddette Rich Internet Applications (RIA).
Ho fatto delle ricerche in internet e mi si sono presentate cinque opzioni accettabili:
  • Adobe Flash: è la tecnologia che c'è da più tempo per fare applicazioni grafiche leggere di proprietà di Adobe-Macromedia. Fondamentalmente i sorgenti si basano su un linguaggio di script detto ActionScript. Gli ambienti di sviluppo più usati sono Adobe Flash Builder (versione trial gratuita oppure la "Premium" a pagamento), Adobe Air o Flash Develop (open source, gratuito). Richiede l'installazione di un plugin sul browser dell'utente finale.
  • Microsoft Silverlight: tecnologia Microsoft secondo cui un plugin può essere sviluppato mediante linguaggi XAML (eXtensible Application Markup Language) e C#: si integra perfettamente all'interno del .NET Framework e Visual Studio, essendo XAML il linguaggio usato per decrivere le interfacce grafiche in WPF (Windows Presentation Foundation). Richiede l'installazione di un plugin sul browser dell'utente finale.
  • JavaFX: famiglia di software applicativi, basati sulla Piattaforma Java, creato da Sun Microsystems e divenuto un prodotto Oracle. Lo sviluppo delle applicazioni si basa su un linguaggio che ha alcuni scostamenti da Java detto "JavaFX script", ma pienamente supportato dalla Sun. L'ambiente di sviluppo rimane quello classico di Java: Eclipse o NetBeans. L'applicazione si integra al browser come fosse un'applet, per cui sul client vi deve essere una JRE installata.
  • Javascript: si raggiungono risultati ammirevoli per mezzo di tecnologie AJAX e librerie quali JQuery, Prototype, Ext JS ecc. L'ambiente di sviluppo è quello classico di Java (p.es. NetBeans/Eclipse) anche se il debugging è più laborioso. Il vantaggio consiste nel non dover scaricare alcun plugin o ambiente sul client, ma basta attivare Javascript. Uno svantaggio di questo approccio è che il risultato finale non è indipendente dal browser sul quale girerà la presentazione, ma bisognerà tener conto della piattaforma client.
  • OpenLaszlo: è una piattaforma open source per lo sviluppo di applicazioni web, è basato sui linguaggi Java/LZX e su un OpenLaszlo Server. In pratica l'applicazione web viene rilasciata come una normale servlet che gira sull'OpenLaszlo Server.Il risultato è un DHTML oppure un normale file Flash SWF. Questa tecnologia, dal punto di vista di un browser, in realtà non presenta niente di nuovo rispetto alle altre tecnologie esistenti, mi pare più che altro un modo alternativo per creare file Flash.
Ci sono anche altre tecnologie adottabili, ma queste esulano dagli scopi di creare una semplice presentazione di immagini che sia leggera, economica di risorse e semplice da realizzare (vedi p.es. la piattaforma open source Flex o Java Swing).
Dopo una breve indagine, ho decretato che le opzioni sono abbastanza equivalenti per ciò che riguarda il risultato finale (l'aspetto grafico). Ho trovato interessanti siti in cui le tecnologie vengono messe a confronto (per esempio questo confronta Flash con Silverlight, mentre questo esegue un benchmark tra le diverse tecnologie). Quest'altro link evidenzia la richiesta del mercato delle tre tecnologie Flash, Silverlight e JavaFX. Un punto a favore di Flash lo si ha andando a guardare quale sia la penetrazione attuale nei browser tra Flash, Silverlight e Java. Due interessanti siti sono RIAStats e StatOwl. Nonostante Silverlight stia aumentando la sua popolarità e area di mercato, la sua penetrazione si aggira intorno al 61.11%, ancora Flash risulta il plugin più installato (96.12%), mentre Java rimane costante (78.54%).
Credo che ad oggi la scelta di Adobe Flash, a meno di altri fattori, sia ancora quella più azzeccata.


lunedì 14 febbraio 2011

Un'introduzione alle EAI (Enterprise Application Integration)

Sempre più si sente parlare in ambito IT di integrazione di sistemi informativi: si pensi per esempio a diversi sistemi che devono scambiarsi informazioni tra loro, ma spesso sono completamente eterogenei per tecnologie, funzionalità, ambienti in cui vivono. Lo scenario è quello in cui diverse applicazioni (con scopi, tempistiche e tecnologie eterogenee), sviluppate magari in .NET piuttosto che in Java o C/C++, devono interagire tra loro su macchine differenti (p.es. 32/64 bit) e su SO differenti.
Per ovviare a tali problematiche si ricorre spesso a piattaforme standard di integrazione dette appunto EAI.
Diamo una definizione formale:

Fonte Wikipedia:
"Enterprise Application Integration (EAI) (integrazione d'applicazioni di impresa) si riferisce al processo d'integrazione tra diversi tipi di sistemi informatici attraverso l'utilizzo di software e soluzioni architetturali".

L'integrazione può essere semplice (trasferimento di dati tra due applicazioni, diverso posizionamento "fisico" dei sistemi), o complessa (esigenze di riservatezza nel trasferimento dei dati, garanzia di consegna, sicurezza ecc.). Le piattaforme EAI si occupano di risolvere l'integrazione semplice (solitamente è un integrazione interna all'azienda).
L'esigenza di avere piattaforme EAI è nata proprio dalla complessità di far interagire tra loro sistemi eterogenei: inizialmente l'interazione avveniva con soluzioni punto-punto, ossia i sistemi dialogavano tra loro a due a due con soluzioni più o meno customizzate. Tutto ciò introduceva  un grosso problema architetturale detto "degli spaghetti", ossia una proliferazione di collegamenti diretti tra i sistemi e la perdita di controllo del trasferimento dell'informazione. Una prima risposta a tale "caos" si è avuta introducendo un primo livello di astrazione (Connectors e Data Transport) dello strato "fisico" di trasporto: avere un layer di comunicazione uguale per tutti per mezzo di costrutti informatici detti connectors e adapters. Tali costrutti vengono realizzati mediante framework che implementano i vari connettori alle applicazioni oppure, se l'integrazione avviene tra due prodotti, mediante adattatori ad hoc. La distinzione tra connector e adapter veniva fatta in base al loro impiego per interfacciare tra loro tecnologie diverse, diversi prodotti o diversi database. Questo livello di astrazione introdotto è in pratica uno strato che si occupa di interfacciare tra loro diverse tecnologie e diverse infrastrutture al livello più basso. Un secondo livello di astrazione deve essere introdotto per ovviare al problema dei "dialetti": si pensi ad esempio a due database che girano su DBMS diversi che devono dialogare tra loro, ciascuno col proprio "dialetto" SQL. Lo strato delle "Trasformazioni" serve proprio per cercare di astrarre le comunicazioni tra sistemi che hanno linguaggi o parti del linguaggio differenti.
Le piattaforme EAI di prima generazione solitamente implementano questi due livelli di astrazione.
Le piattaforme di seconda generazione implementano un ulteriore livello di astrazione detto del "flusso dei processi": si può avere non solo un'astrazione del trasferimento di informazioni tra le applicazioni, ma anche delle loro funzionalità e quindi della logica su come vengono integrate.

Livelli di astrazione:
  • Connectors & Data Transport (connectors e adapters)
  • Transformations (conversioni tra dialetti)
  • Process Flows (logica di integrazione)
Ci sono principalmente due tipi di piattaforma EAI:
  • Broker Engine: questo tipo di piattaforme si concentra sul far comunicare applicazioni eterogenee. Esse consistono in un componente detto "broker engine" che si occupa di trasferire i dati da un'applicazione all'altra, ma senza entrare nei dettagli della connettività. In pratica un broker engine utilizza diversi "connector" e "adapter" che si occupano della comunicazione tra il broker e l'applicazione ad un livello di astrazione più basso. In pratica il livello di astrazione (Connectors e Data Transport) introdotto dai connector e dagli adapter permette al broker engine di dedicarsi all'esclusivo instradamento dei flussi di dati.
  • Process Mapper Engine: sono le piattaforme EAI di ultima generazione. Tali EAI si occupano della gestione dei processi. Oltre al livello di astrazione dei connectors e degli adapters viene introdotto un ulteriore livello di astrazione detto Process Flow: in pratica viene astratta la logica di integrazione (composition logic). In tale scenario si può scegliere come integrare i diversi sistemi secondo una logica dei servizi da essi offerti. Da qui alle architetture SOA (Service Oriented Architecture) il passo è breve.

Un esempio di Broker Engine è il Message Broker che si occupa di smistare messaggi tra diverse applicazioni: un Message Broker è in grado di fornire a ciascuna applicazione un adapter ad hoc, inoltre la logica di instradamento dei messaggi può essere comandata tramite una logica programmabile (composition logic). Tale logica può essere implementata tramite un WfMS (Workflow Management System).
Il Message Broker come Broker Engine


    sabato 12 febbraio 2011

    Interfacciare Liferay con LDAP



    Liferay è una applicazione web open source basata sul linguaggio Java per la gestione e la customizzazione di portali.
    Liferay sfrutta la gestione delle portlet (supporta lo standard portlet API JSR-168). Esso permette di creare facilmente da un normale sito web a un complesso portale di servizi. Una caratteristica interessante di Liferay è che esso può essere interfacciato con un preesistente sistema di autenticazione quale LDAP, NTLM ecc.
    Liferay può essere personalizzato per ciascun utente che si logga al portale con una granularità molto fine: per esempio posso decidere per ciascun utente o gruppi di utenti quali portlet, documenti, contenuti ecc. può vedere o con quali può interagire.
    Tutti gli accessi al portale (profilazione utente con i suoi privilegi) saranno pilotati dal nostro sistema di autenticazione centralizzato.

    Vediamo un esempio di integrazione con LDAP: una volta loggati come utente administrator di Liferay (utente Administrator locale), andare nel Pannello di Controllo di Liferay nella sezione Portale -> Configurazione -> Autenticazione -> LDAP. Chekkare il flag "Abilitato", mentre quello "Richiesto" abilitarlo solo nel caso che tutti gli utenti che si dovranno loggare a Liferay siano solo di LDAP. Premere il bottone "Aggiungi" Server LDAP. A questo punto dobbiamo configurare l'autenticazione:
    Configurazione
    Top o

    Nome del server (immettere un nome simbolico del server)
    Valori Predefiniti (selezionare il tipo server LDAP)
    Scegliere il tipo di server tra quelli a disposizione, per esempio se abbiamo in azienda un Active Directory con LDAP selezionare "Microsoft Active Directory Server", introdurre l'IP e la porta del servizio LDAP (ricavabile dal server), di default vale "ldap://localhost:10389".
     
    Apache Directory Server
    Fedora Directory Server
    Microsoft Active Directory Server
    … ecc.
    Connessione - Base Provider URL, Il formato dell'URL del LDAP Base Provider è ldap://host:port.- Base DN specifica il contesto di ricerca iniziale per gli utenti ed è opzionale. Ad esempio, usare ldap://localhost:389 e ou=Users,o=Example come valori - Il formato dell'URL del LDAP Base Provider è ldap://host:port. Il Base DN specifica il contesto di ricerca iniziale per gli utenti ed è opzionale. Ad esempio, usare ldap://localhost:389 e ou=Users,o=Example come valori.- Immetere le credenziali di un amministratore (ad esempio admin,dc=local)
    Utenti

    - Filtro di Ricerca Autenticazione. Inserisci il filtro di ricerca che sarà utilizzato per verificare la validità di un utente. I campi @company_id@, @email_address@ e @user_id@ sono sostituiti a runtime con i valori corretti. Ad esempio (mail=@email_address@)- Importa Filtri di Ricerca: ad esempio (objectClass=person), filtro di ricerca per utente
    Mappatura dell'Utente
    Immetere i valori dei campi che a runtime verranno sostituiti con quelli trovati sul server:
    Nome Utente:  cn
    Password: userPassword
    Indirizzo Email: userPrincipalName
    Nome Completo:
    Nome: givenName
    Secondo Nome:
    Cognome: sn
    Job Title: title
    Gruppo: memberOf
    Gruppi
    Filtro per importare i gruppi:
    Importa Filtri di Ricerca: (objectClass=groupOfUniqueNames)
    Tracciato del Gruppo
    Nome del Gruppo: cn
    Descrizione: description
    Utente: uniqueMember
    Esporta
    Esporta i dati su Liferay
    DN Utenti: ou=users,dc= company_domain,dc=local
    Classi Oggetto Predefinite per l'Utente: top,person,organizationalPerson,inetOrgPerson
    Gruppi DN: ou=groups,dc= company_domain,dc=local
    Codici categoria di oggetto di difetto del gruppo: top,groupOfUniqueNames
    Bottom of Form
    Questo potrebbe essere un esempio di configurazione di Liferay. In pratica Liferay si connetterà al nostro server LDAP e importerà gli utenti e i gruppi che soddisfano i criteri di ricerca indicati nei filtri. Alla fine della procedura tali utenti compariranno come utenti di Liferay veri e propri.
    Dopo aver testato la connessione al server LDAP e testato i vari filtri su gruppi e utenti tramite i relativi bottoni, salviamo la configurazione del server e torniamo alla schermata di LDAP.
    A questo punto possiamo settare le rimanenti opzioni:

    Importa / Esporta

    (importa gli utenti LDAP al primo login)
    (importa tutti gli utenti LDAP all'avvio)
    (esporta gli utenti LDAP)

    Politica per le Password

    (abilita la politica LDAP delle password come per esempio la scadenza ecc.)
    Salviamo le modifiche effettuate, delogghiamo l'utente corrente di Liferay e proviamo ad effettuare un login con utente LDAP: se tutto andrà bene ci verrà chiesta per questo utente la domanda segreta per il ripristino della password. L'utente avrà i permessi indicati per il gruppo LDAP, se si vogliono dare permessi diversi andare in Pannello di Controllo->Portale->Ruoli e dopo aver selezionato un ruolo in Azioni cliccare su Assegna membri -> disponibili. Naturalmente nella sezione Utenti di Liferay (Pannello di Controllo ->Portale ->Utenti), dopo il login dovranno comparire tutti gli utenti LDAP importati e che soddisfano i criteri dei filtri che abbiamo immesso. A questo punto Liferay è stato interfacciato con LDAP ed è pronto all'uso con un sistema di autenticazione centralizzato.

    martedì 8 febbraio 2011

    Dizionari, Lookup e Dizionari Ordinati di oggetti in C#

    Il linguaggio C# supporta una vasta gamma di collezioni di oggetti. Alcune di queste strutture dati sono funzionano come delle mappe hash con chiave valore, ad accesso rapido:

    - Dictionary: struttura del tipo<chiave, valore>, a ciascuna chiave corrisponde un singolo valore
    - Dictionary Lookup: come il Dictionary, ma a ciascuna chiave possono corrispondere più valori
    - Sorted Dictionary: come il Dictionary, ma è ordinato.

    Quando usare un Dictionary? In pratica è conveniente usarlo in tutti in quei casi che si hanno dati nella forma chiave - valore e si vuole un accesso veloce. In pratica a ciascuna chiave viene fatto corrispondere un valore
    univoco (hash), a valori simili corrispondono valori hash molto diversi e la distribuzione dei valori hash deve essere uniforme.

    Non abbiamo particolari restrizioni sugli oggetti usabili come valori di un Dictionary, ma le si hanno invece per gli oggetti che dobbiamo usare come chiavi. Una chiave di un Dictionary deve essere comparabile, o meglio deve derivare dalla interfaccia IEquatable e implementare il metodo
    Equals.

    Questo perchè altrimenti verrebbe usato il metodo Equals della classe Object che restituisce true solo se l'oggetto da comparare è l'oggetto stesso. Un altro metodo fondamentale che si deve implementare per l'oggetto da usare per la chiave è
    GetHashCode() che restituisce il codice hash che come detto deve far corrispondere valori diversi per chiavi diverse.

    Si noti che se usiamo come chiave un oggetto String, non abbiamo bisogno di reimplementare alcun metodo poichè questi sono già implementati nella classe. Anche la classe Int32 sovrascrive Equals() e
    GetHashCode() implementando IEquatable, ma quest'ultimo non soddisfa la proprietà di distribuire uniformemente i valori di hash poichè restituisce il valore stesso (ad es. se Int32 key = 10, key.GetHashCode() restituisce 10).

    Vediamo un esempio d'uso di Dictionary:

    var employees = new Dictionary<EmployeeId,Employee>(100); //Dictionary iniziale di 100 elementi

    dove
    EmployeeId è definita come

    public struct EmployeeId : IEquatable<EmployeeId>{
      ...
      private readonly int number;
      public EmployeeId(string id)
      {
        if (id == null) throw new ArgumentNullException("id");
        number = int.Parse(id);
        ...
      }

      public bool Equals(EmployeeId other) 
     
      {         
         //i due Employee sono uguali se il campo number è uguale
         if (other == null) return false;
           return (number == other.number);
      }
        


      public override int GetHashCode()     
      {        
        //questa funzione è arbitraria ma deve essere di tipo hash
        return ((int)number ^ (int)(number >> 32)); 
      } 

     ...  
    }

    Per aggiungere elementi al Dictionary si può usare il metodo Add(chiave,valore), mentre per cercare un valore si può usare il metodo TryGetValue(chiave, out valore)) che restituisce false se l'elemento non
    è presente, oppure si usa Contains(chiave) (senza farsi restuire il valore). Il metodo
    Remove(chiave) serve invece per eliminare degli elementi.

    Un Dictionary Lookup è simile al Dictionary, ma supporta più valori con la stessa chiave. A differenza del Dictionary non c'è una classe "contenitore ad hoc" ma ne viene sfruttata una già esistente, inoltre gli elementi vengono aggiunti mediante il metodo
    ToLookup()che restituisce un oggetto Lookup < TKey, TElement >. Il metodo ToLookup accetta un delegato che serve per selezionare la chiave.
    Per esempio:

    var racers = new List <Racer > ();
    racers.Add(new Racer("Jacques", "Villeneuve","Canada", 11));
    racers.Add(new Racer("Alan", "Jones","Australia", 12));
    racers.Add(new Racer("Jackie", "Stewart", "United Kingdom", 27));
    racers.Add(new Racer("James", "Hunt", "United Kingdom", 10));
    racers.Add(new Racer("Jack", "Brabham", "Australia", 14));
    var lookupRacers = racers.ToLookup(r = > r.Country);

    Crea una Lookup in cui la chiave risulta il campo Country della classe Racer.
    Si noti come ToLookup venga chiamato come un metodo di List.

    Per selezionare gli elementi usiamo l' accesso alla lista per mezzo della chiave:

    foreach (Racer r in lookupRacers["Australia"])
    {
      Console.WriteLine(r);
    }
      
    Si noti che l'accesso alla lista è di tipo hash! Il metodo ToLookup è disponibile in tutte le classi C# che implementano l'interfaccia
    IEnumerable < T >.

    Infine il
    SortedDictionary < TKey, TValue > non è altro che un albero binario ordinato in cui ciascuna chiave deve implementare IComparable < TKey >.
    SortedDictionary<string, string> dic = 
    new SortedDictionary<string, string>();
    ...
     

    Per approfondimenti vedi:

    Dictionary (classe) : http://msdn.microsoft.com/it-it/library/xfhwa508(v=vs.80).aspx
    Lookup: http://msdn.microsoft.com/en-us/library/bb460184.aspx
    SortedDictionary: http://msdn.microsoft.com/it-it/library/f7fta44c.aspx

    martedì 1 febbraio 2011

    IIS 7.0 su Seven: installazione di ASP.NET

    State sviluppando la vostra applicazione web in ASP.NET e ad un certo punto volete pubblicarla con IIS 7.0, magari sotto Windows Seven o Vista. Vi renderete subito conto che la cosa non è così banale come con le versioni precedenti di IIS magari perchè ASP.NET non è automaticamente installato con IIS. Se trovate un errore del genere: 







    IIS 7.0
    Riepilogo errori
    Errore HTTP 404.3 - Not Found
    La pagina richiesta non può essere servita a causa della configurazione
    estensioni. Se la pagina è uno script, aggiungere un gestore. Se il file
    deve essere scaricato, aggiungere una mappa MIME (Multipurpose Internet
    Mail Extensions).
    Informazioni dettagliate sull'erroreModulo StaticFileModule
    Notifica ExecuteRequestHandler
    Gestore StaticFile
    Codice errore 0x80070032
    URL richiesto http://localhost:80/hello_word.asp
    Percorso fisico C:\inetpub\wwwroot\hello_word.asp
    Metodo di accesso Anonima
    Utente accesso Anonima

    Cause più probabili:
    È possibile che manchi un mapping del gestore. Per impostazione
    predefinita, il gestore di file statici elabora tutti i contenuti.
    La funzionalità che si sta tentando di utilizzare potrebbe non essere
    installata.
    Il mapping MIME appropriato non è abilitato per il sito Web o
    l'applicazione. Avviso: non creare un mapping MIME per contenuti che gli
    utenti non devono scaricare, ad esempio pagine .ASPX o file .config.
    Se ASP.NET non è installato.
     

     
     
     Molto probabilmente si tratta proprio del fatto che ASP.NET non è installato. Lo si può anche vedere tra le opzioni che offre IIS Manager: aprite IIS Manager da Pannello di Controllo -> Strumenti di Amministrazione -> Gestione Internet Information Services (IIS): alla voce IIS (in visualizzazione funzionalità) deve comparire ASP Se così non è allora installare ASP in questo modo:
    - Pannello di controllo->Programmi e funzionalità
    - clicchiamo su Attivazione o disattivazione delle funzionalità di Windows
    - Scorriamo fino a trovare Internet Information Services
    - Abilitiamo le funzionalità che ci interessano (ASP, ASP.NET, CGI, Estensioni ISAPI, Filtri ISAPI, ecc...):
    - Sempre sotto il nodo Internet Information Services espandiamo il nodo Servizi Web, quindi Protezione e spuntiamo cio che ci interessa (solitamente basta Autenticazione di base per poter amministrare il sito web in locale)
     - clicchiamo su OK ed attendiamo che la configurazione di IIS sia portata a termine.

     
    Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | cna certification