This document discusses using a dependency injection container to configure NHibernate with a SOLID design approach. It introduces patterns like plug-in and optionality to split configuration tasks across assemblies and optionally enable/disable them. Configuration tasks implement interfaces to define their execution order and configuration logic. The container resolves and executes the tasks to configure NHibernate.
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
This document discusses using a dependency injection container to configure NHibernate with a SOLID design approach. It introduces patterns like plug-in and optionality to split configuration tasks across assemblies and optionally enable/disable them. Configuration tasks implement interfaces to define their execution order and configuration logic. The container resolves and executes the tasks to configure NHibernate.
Cos'è la UI Composition e che problemi può risolvere
Perchè MVVM e WPF sono importanti per la UI Composition
Il concetto di 'region' e 'UI Injection'
Analisi del toolkit PRISM di Microsoft e cosa comporta realizzarsene uno in proprio.
TYPESCRIPT, ANGULAR E BOOTSTRAP ASSIEME PER APPLICAZIONI REAL WORLDDotNetCampus
La recente affermazione in ambito web delle applicazioni rich basate su HTML5 e Javascript è diventato sorgente di una serie di librerie innovative e di strumenti che, se usati correttamente, possono semplificare enormemente lo sviluppo. In questa sessione sarà illustrato come sfruttare Typescript, in concomitanza con Angular e Bootstrap per realizzare applicazioni che sfruttino al massimo le possibilità dei browser e diano un feedback il più possibile simile alle applicazioni desktop.
ARCHITETTURA DI UN'APPLICAZIONE SCALABILEDotNetCampus
Questa sessione tratterà delle implementazioni di architetture robuste e scalabili, in scenari di sviluppo applicativi rientranti nella tipologia dei Software as a Service. In particolare vedremo come accopiare le feature e le necessità del SaaS con servizi propri presenti su Azure; con focus su web, servizi mobili, data, e notification.
Slide Tesi di laurea:
Separazione dei ruoli tra Designer e Developer nello sviluppo di applicazioni Desktop: uso di WPF e del pattern Model-View-ViewModel
"Don't call us, we'll call you" - AngularJS meets Event-Driven ArchitectureLuca Milan
Slides del talk del 21 Marzo al 1° AngularJS Day ad Ancona. Come realizzare una dashboard per consultare in tempo reale l'andamento dei piloti in una gara del MotoGP. Tutte le variazioni saranno notificate al client evitando il polling continuo al server. L'architettura dell'applicazione seguirà il paradigma della Command-Query-Responsibility-Segregation (CQRS) in 'salsa' REST.
Demo su: http://angularjsday.azurewebsites.net/
Liferay 7: Come realizzare un client SOAP con Apache CXF in OSGi StyleAntonio Musarra
Non sapete come realizzare un client SOAP in OSGi Style su Liferay 7?La risposta è il framework Apache CXF installato a bundle e poi OSGi Service Pattern.
A pattern language for microservices (#SFMicroservices)Chris Richardson
When architecting an application, you need to choose between the traditional monolithic architecture, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
Developing microservices with aggregates (devnexus2017)Chris Richardson
The document discusses using domain-driven design aggregates and event sourcing to develop microservices architectures. It describes how aggregates partition domain models to allow microservices to own distinct capabilities. Event sourcing is presented as a way to implement event-driven architectures by persisting domain events rather than just the current state. Explicit sagas are proposed to orchestrate transactions across aggregates and microservices to maintain consistency in an eventually consistent way.
TYPESCRIPT, ANGULAR E BOOTSTRAP ASSIEME PER APPLICAZIONI REAL WORLDDotNetCampus
La recente affermazione in ambito web delle applicazioni rich basate su HTML5 e Javascript è diventato sorgente di una serie di librerie innovative e di strumenti che, se usati correttamente, possono semplificare enormemente lo sviluppo. In questa sessione sarà illustrato come sfruttare Typescript, in concomitanza con Angular e Bootstrap per realizzare applicazioni che sfruttino al massimo le possibilità dei browser e diano un feedback il più possibile simile alle applicazioni desktop.
ARCHITETTURA DI UN'APPLICAZIONE SCALABILEDotNetCampus
Questa sessione tratterà delle implementazioni di architetture robuste e scalabili, in scenari di sviluppo applicativi rientranti nella tipologia dei Software as a Service. In particolare vedremo come accopiare le feature e le necessità del SaaS con servizi propri presenti su Azure; con focus su web, servizi mobili, data, e notification.
Slide Tesi di laurea:
Separazione dei ruoli tra Designer e Developer nello sviluppo di applicazioni Desktop: uso di WPF e del pattern Model-View-ViewModel
"Don't call us, we'll call you" - AngularJS meets Event-Driven ArchitectureLuca Milan
Slides del talk del 21 Marzo al 1° AngularJS Day ad Ancona. Come realizzare una dashboard per consultare in tempo reale l'andamento dei piloti in una gara del MotoGP. Tutte le variazioni saranno notificate al client evitando il polling continuo al server. L'architettura dell'applicazione seguirà il paradigma della Command-Query-Responsibility-Segregation (CQRS) in 'salsa' REST.
Demo su: http://angularjsday.azurewebsites.net/
Liferay 7: Come realizzare un client SOAP con Apache CXF in OSGi StyleAntonio Musarra
Non sapete come realizzare un client SOAP in OSGi Style su Liferay 7?La risposta è il framework Apache CXF installato a bundle e poi OSGi Service Pattern.
A pattern language for microservices (#SFMicroservices)Chris Richardson
When architecting an application, you need to choose between the traditional monolithic architecture, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it’s important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
Developing microservices with aggregates (devnexus2017)Chris Richardson
The document discusses using domain-driven design aggregates and event sourcing to develop microservices architectures. It describes how aggregates partition domain models to allow microservices to own distinct capabilities. Event sourcing is presented as a way to implement event-driven architectures by persisting domain events rather than just the current state. Explicit sagas are proposed to orchestrate transactions across aggregates and microservices to maintain consistency in an eventually consistent way.
Il web service e i sistemi embedded - Tesi - cap2pma77
Nel capitolo secondo capitolo della tesi " SVILUPPO E IMPLEMENTAZIONE SU MICROCONTROLLORE DI UN’APPLICAZIONE WEB SERVER PER IL CONTROLLO DI UN SISTEMA EMBEDDED"sono presentati diversi prodotti commerciali impieganti Web Service , in modo particolare dispositivi di tipo embedded. Viene discusso, inoltre, su come le tecnologie Web entrino nel mondo industriale e della domotica e si pone l’attenzione sui fattori che impediscono il pieno sviluppo in questi ambiti. Infine vengono proposti diversi articoli che affrontano tematiche simili a quelle della tesi.
Slide del decimo Meetup di Milano, che si è tenuto il 26 Gennaio dalle ore 10:30 alle ore 12:00 in formato virtuale.
Abbiamo parlato insieme a Davide Bonaciti di come ha realizzato un caso d'uso di automazione e CI/CD. Stefano Bernardini, Serena Galassi e Lorenzo Ornella, invece, ci parleranno di DataGraph e ci mostreranno una demo di implementazione per realizzare un'asta del fantacalcio 2.0.
Presentazione alla Google Dev Fest Mediterranean 2016 di Catania con presentazione sulle metodologie di utilizzo di microservices e sui sistemi per monitorare le infrastrutture
Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamen...Mattia De Bernardi
Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamento al sistema di controllo TANGO, tramite l'ausilio del framework Apache Cordova
Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamen...
PALUZZANO PRELAUREA
1. Università degli studi di Trieste
Dipartimento di Ingegneria ed Architettura
Corso di studi in Ingegneria Informatica
Laureando:
Enrico PALUZZANO
Relatore:
prof. Alberto BARTOLI
2. Introduzione
Il lavoro presentato è stato svolto all’interno
dell’azienda SMS Concast.
SMS Concast sviluppa e produce software per
l’automazione degli impianti siderurgici.
Il software presentato è il sistema di
comunicazione, utilizzato dalle applicazioni, per
controllare il processo produttivo dell’impianto: il suo
nome è GATE.
3. Organizzazione aziendale
L’organizzazione degli impianti viene strutturata
su diversi livelli.
Livello 1: è il livello che gestisce l’automazione
nell’impianto.
Il livello 2: è il livello preposto alla gestione del processo
produttivo.
(livello in cui è stato sviluppato il software prodotto)
Il livello 3: è il livello preposto alla gestione delle
commesse.
4. Livello 2
Il software sviluppato nel livello 2 svolge svariati
compiti:
calcolo dei piani di taglio per gli acciai speciali
controllo della composizione chimica dell’acciaio
…
Le necessità del software di questo livello sono:
Conoscere lo stato dell’impianto
Comandare il processo produttivo
5. PLC
Lo stato dell’impianto viene controllato da specifiche
apparecchiature chiamate PLC (Programmable Logic
Controller)
Al loro interno sono installate le applicazioni di Livello 1
che permettono di:
Scrivere in memoria i dati ricevuti dai rilevatori
Leggere dalla memoria i comandi da inviare alle macchine
tramite gli attuatori
Un’applicazione di livello 2, per controllare il processo
produttivo, deve necessariamente comunicare con i PLC.
Questa comunicazione avviene interagendo con la loro
memoria interna.
6. Definizione del problema (I)
Comunicare con i PLC presenta delle difficoltà in
quanto:
Possono esser prodotti da case produttrici differenti
Utilizzano librerie proprietarie diverse
Necessitano di comunicazioni robuste ed affidabili
Le applicazioni di livello 2 hanno la necessità di
comunicare:
Con più PLC nello stesso momento
In maniera concorrente fra loro
Frequentemente
7. Definizione del problema (II)
Per questo è stato realizzato dall’azienda un software
intermedio tra applicazioni di livello 2 e PLC.
Vantaggi:
Non impegna le applicazioni nella comunicazione
Incorpora l’utilizzo di diversi protocolli
Permette di controllare lo stato delle comunicazioni
Svantaggi:
Deve essere robusto
(capace di gestire correttamente i malfunzionamenti)
Deve essere affidabile
(non può bloccarsi altrimenti le applicazioni non controllano
più il processo produttivo)
8. Specifiche richieste
A fronte di una commessa è stato chiesto al livello 2
dell’azienda di:
Tradurre le applicazioni che già distribuisce, in
linguaggio C#
Ridisegnare le interfacce utilizzando WPF(Windows
Presentation Foundation)
Sviluppare delle nuove applicazioni personalizzate per
alcune necessità specifiche del committente
9. Stato dell’arte
Il software presentato in questa tesi è stato sviluppato
partendo da quello correntemente utilizzato.
Il software precedente:
E’ scritto in linguaggio Pascal
Utilizza tre tipi di librerie
Softnet
AllenBradley
SendReceive
Implementa il controllo da remoto
10. Specifiche del GATE (I)
Il nuovo software, sviluppato nell’ambito del tirocinio,
presenta le seguenti specifiche:
E’ scritto in linguaggio C#
Ha le interfacce disegnate utilizzando WPF
Utilizza la libreria proprietaria Softnet utilizzata per
comunicare con i PLC SIEMENS S7
Implementa il sistema remoto utilizzando WCF
(Windows Comunication Foundation)
11. La comunicazione(I)
Per comunicare con i PLC, le applicazioni, comunicano
con il Gate utilizzando la seguente procedura:
Definiscono una connessione (Link)
Accodano una richiesta (Transazione)
Prelevano l’esito della richiesta
Successivamente il Gate interagisce con i PLC nel
seguente modo:
Carica la libreria proprietaria
Apre il canale di comunicazione
Esegue la richiesta tramite le funzioni della libreria
proprietaria
12. La comunicazione (II)
La comunicazione, all’interno del Gate, avviene
tramite l’intervento di due macro entità:
PlcDriver
PipeObject
GATE
PIPEOBJECT
PLCDRIVER
APPLICAZIONI
SOFTNET
PLC
ALLEN-BRADLEY
LINK
LINK
ALLNBRADLEY
PLC
SENDRECEIVE LINK
SENDRECEIVE
PLC
SOFTNET LINK
TRANSAZIONI
13. Comportamento delle classi
Il PipeObject ha il compito di:
Ricevere le richieste di connessione da parte delle applicazioni
Passarle al corretto driver in esecuzione
Ricevere ed accodare le richieste di lettura o scrittura
Il PlcDriver ha il compito di:
Caricare le librerie proprietarie
Aprire le connessioni passategli dal PipeObject, con i PLC
Prelevare dal PipeObject, se accodata, una Transazione
relativa alla connessione aperta
Eseguire la Transazione e salvarne il risultato all’interno del
PipeObject
Rilasciare le librerie proprietarie
14. Sviluppo di PlcDriver
E’ la classe ancestrale che definisce il comportamento
generale del driver
Incorpora un thread per l’esecuzione ciclica di una
funzione chiamata Execute
Questa funzione è stata completamente
riprogettata e sviluppata
E’ la più rilevante modifica apportata al software
precedente
Si basa sull’applicazione a PlcDriver di un modello a stati
finiti
15. UNUSED
SIMULATION
Entry / Link da servire = 0
Do / Attende e inizial. driver
Exit / Link da servire > 0
INIZIO
ERROR
Entry / Inizial. driver fallita
Do / Aspetta timeout
RESTARTING
Entry / Mod. sim. richiesta
Do / Finalizza il driver e attende
Exit / Mod. live richiesta
ACTIVE
Entry / Link da servire > 0
Do / Apre link, attende transazioni ed esegue
transazioni
Exit / Links da servire = 0 oppure un link è in stato
di errore per più di MaxOveralltime oppure è
stata richiesta la chiusura del driver
Do / Finalizza driver e terimina link
STOPPED
FINE
Do / Finalizza il driver e
rimuove i link.
16. Risultati dello sviluppo:
Il risultato ottenuto da questa implementazione di
PlcDriver si può riassumere in:
Un comportamento più affidabile dei driver
Una miglior chiarezza del codice
Un aumento delle prestazioni in alcune situazioni
18. L’applicazione di test: Board
Il Board è un’applicazione che simula il
comportamento di una normale applicazione del
livello 2
Tramite il Board è possibile:
Definire un Link ad un PLC
Leggere dalla memoria del PLC
Scrivere sulla memoria del PLC
Lanciare delle funzioni di test
Controllare lo stato delle transazioni