Gabriele Mittica, CEO @Corley Cloud – “Come creare un’azienda “nativa in clou...
Presentazione: Sviluppo di un hub di comunicazione in una applicazione per porti con biztalk server 2010
1. Università degli studi di Trieste Corso di laurea specialistica in Ingegneria Informatica Sviluppo di un Hub di comunicazione in un’applicazione per porti con Biztalk Server 2010 Relatore Prof. Maurizio Fermeglia Laureando Walter Geretto Anno Accademico 2009/2010
2. Obiettivo Realizzazione di un sistema di comunicazione fra moduli software per: Gestire routing di messaggi Analizzare il contenuto dei messaggi e applicare regole di business Eseguire set di operazioni durante il transito dei messaggi Il sistema deve consentire: Monitoraggio dei flussi di informazioni Gestione degli errori di comunicazione Configurazione delle risorse utilizzate dal sistema Sviluppo di un hub con Biztalk Server: prodotto Microsoft per integrazione di applicazioni
3. SlimPORT Progetto innovativo di porto(Sicurezza, Logistica, Intermodalità Portuale) Processi operativi nell’ambito dell’ultimo miglio mare e primo miglio terra Vantaggi attesi Riduzione del tempo di stazionamento e di transito delle merci e dei passeggeri nei nodi del trasporto Velocizzazione operazioni di carico, scarico e trasbordo Cooperazione con sistemi infotelematici di gestione dei processi operativi esistenti Incremento della sicurezza nelle operazioni portuali e salvaguardia delle logiche di business Intermodalità nell’ambito della catena logistica Decongestione dei trasporti e mobilità sostenibile nel territorio
4. SlimTRUCK Sistema di trasferimento container nella tratta porto-retroporto su strada. Garantisce controllo delle merci durante il trasporto
5. Tubo virtuale Sistema formato da un insieme di componenti software e hardware Obiettivi ottimizzare il flusso delle merci decongestionare l’area portuale affidare l’espletamento delle procedure doganali in retroporto Porto e Retro-porto devono essere visti come un'unica entità sono separati da suolo pubblico la merce in transito deve muoversi su strade percorse da traffico urbano Prevede un hub centrale che gestisce il flusso informativo tra le componenti
7. Componente Gateway Centro di controllo: raccoglie informazioni provenienti da computer di bordo Informazioni ricevute dati di localizzazione rilevati dai GPS integrati nei computer di bordo dati di integrità di gruppo dati di integrità dei sigilli elettronici situati sui meccanismi di apertura dei containers Funzionalità Richiesta di vestizione di un gruppo (OBC + Tag1 + Tag2) Richiesta di svestizione di un gruppo arrivato a destinazione Invio di informazioni aggiornate all’hub centrale (periodico, a eventi)
8. Componente Gestione Emergenze Identifica e gestisce le emergenze di processo apertura del container in zona non autorizzata mancata rilevazione del gruppo (motrice/container) deviazione dal percorso stazionamento del veicolo segnalazione di allarme da parte del conducente Prevede due processi rilevazione dell’emergenza: eseguito a evento individuazione delle mancate rilevazioni: eseguito in maniera continuativa
9. Componente Console Strumento a disposizione di un operatore che supervisiona la movimentazione delle merci Preleva informazioni dal database interno all’hub Visualizza segnalazioni di allarme attive Funzionalità: Richiesta di informazioni aggiornate sullo stato dei gruppi Richiesta degli eventi configurati nei computer di bordo Richiesta di identificazione dei gruppi a cui appartengono gli OBC
10. Hub centrale Routing dei messaggi ricevuti dalle applicazioni Orchestrazione dei processi di business Analisi dei messaggi con un motore decisionale Monitoring dei flussi di informazione
23. Standard per la Comunicazione XML Modello per la descrizione di dati secondo una struttura gerarchica Messo a punto e promosso dal consorzio mondiale W3C Fondamento degli scenari Biztalk Flussi dati codificati secondo “XML Schema” Metodo per definire la struttura di documenti XML Utilizza XML (http://www.w3.org/2001/XMLSchema) Fornisce meccanismi per il riuso degli schemi Schemi resi pubblici e condivisi con tutti gli attori del progetto
28. Orchestrazioni Serie ordinate di operazioni o transazioni che implementano un processo di business Servono per Correlare messaggi Eseguire business rules Gestire e definire l’ambito di una transazione Non devono essere usate per Eseguire routing dei messaggi tra le porte Attuare semplici trasformazioni dei messaggi Effettuare chiamate remote a sistema attraverso espressioni Definire complesse regole e policy(per questo esiste il business rules engine)
30. Business rules engine Motore decisionale interno a Biztalk Server Richiamato all’interno di flussi di orchestrazione Fact Xml document .NET class Vocabolario collezione di nomi che identificano Facts Policy collezione di regole
31. Porte di comunicazione Porte logiche: definite all’interno delle orchestrazioni Message type Direction (Send/Receive) Porte fisiche: definite all’interno della console amministrativa Configurazione Adapter Pipeline Mappe di trasformazione in ingresso e in uscita Filtri/Sottoscrizioni Binding: associazione fra porta logica e porta fisica Sono stati usati gli adapter SQL e WCF HUB
32. Web services L’Hub centrale espone gli schemas dei messaggi come operazioni di web services Architettura orientata ai servizi Interoperabilità fra piattaforme Protocolli standard di comunicazione (Html, SOAP) Rappresentazione e meccanismo di scambio dei dati (XML , WSDL) L’Hub espone 5 servizi BasicHttpbinding con gestione emergenze (Basic Profile - necessità di interoperabilità) WSHttpbinding con Gateway e Console (WS-Security, WS-Addressing) L’Hub consuma servizi esposti dalle altre componenti Utilizza gli schemas dei messaggi condivisi Message Contract + XmlSerializer
33. Installazione applicazione Ambiente di sviluppo: Deploy degli assembly dei progetti Biztalk Binding delle porte delle orchestrazioni Deploy delle policy dal Business Rules Composer Esportazione dell’applicazione in un file .msi Ambiente di produzione: Importazione dell’applicazione contenuta in un file .msi Installazione dell’applicazione Inserimento in GAC degli assembly Creazione dei servizi in IIS Enlist e Start dell’applicazione
34. Progetti di supporto Realizzazione di una soluzione di supporto che simula le funzionalità delle componenti mancanti Consumo dei servizi esposti dall’hub (invio di richieste di vestizione, svestizione, segnalazione di allarme, …) Esposizione dei servizi previsti dal Gateway e dalla componente gestione emergenze Simulazione di movimento dei veicoli Persistenza dei dati in un database di supporto Lo scopo è di eseguire il test delle funzionalità previste dall’hub
35. Simulazione di movimento dei convogli Identificazione delle coordinate del percorso Google Earth: coordinate geografiche nel sistema di riferimento WGS84 Meccanismo di generazione di coordinate geografiche Formule trigonometriche per calcolare distanza e direzione fra coppie di coordinate Spostamento calcolato ipotizzando velocità costante del mezzo Simulazione parallela di più veicoli in Thread separati Rappresentazione grafica del percorso Static API di Google Maps
37. Conclusioni L’applicazione realizzata è ad oggi installata in un ambiente di sviluppo. Si tratta di un prototipo che implementa tutte le funzionalità definite in fase di analisi Sviluppi futuri: Analisi e Sviluppo della componenti mancanti (MarketPlace, Sistema di supporto alle decisioni) Aggiunta di funzionalità all’Hub per gestire la comunicazione con le nuove componenti Integrazione con i moduli software sviluppati dagli altri Partner Test del sotto-sistema completo
