Venezia--Novembre Software per il mondo aperto opportunit à e sfide Carlo Ghezzi Dipartimento di Elettronica e Informazione Politecnico di Milano, Italy

Venezia--Novembre Che cos' è il "mondo aperto? Le metodologie e tecnologie del software sono passate da una situazione di – mondo chiuso – a evoluzione controllata – a mondo aperto Il progresso nel settore può essere analizzato secondo questa visione prospettica Il mondo esterno col quale il sistema interagisce è ben noto e fisso La struttura della soluzione è fissa monolitica, fissa e centralizzata I cambiamenti nel mondo esterno ricdhiedono riprogettazione I cambiamenti nell'implementazione sono localizzati a parti ristretta I cambiamenti si manifestano quando il sistema è in esecuzione L'architettura evolve mentre il sistema è in funzione

Venezia--Novembre Traccia del seminario Breve rassegna dell'evoluzione del software dal punto di vista dei concetti di mondo aperto/chiuso Analisi delle sfide e opportunit à Zoom su due linee di ricerca Un'agenda per la ricerca

Venezia--Novembre Postulati Il mondo aperto richiede di comporre il software dinamicamente…. …. in quanto la struttura del software deve poter cambiare dinamicamente, anche in modo imprevisto Ciò comporta un cambiamento radicale in come si progetta e convalida il software –in particolare, da una convalida off-lie a una convalida "perpetua"

Venezia--Novembre Il punto di vista Mi focalizzo su composizione/struttura –come viene costruito un sistema da sue parti? come/quando si stabiliscono i "binding" tra parti? –quale struttura/architettura? anche a livello di processo –come è strutturata vita di un'applicazione? –quale organizzazione in fasi/attivit à /ruoli/attori? con un occhio al mondo del "business"

Venezia--Novembre Archeologia Nascita nel 1968 dell'ingegneria del software, come risposta a –crescente importanza del software nella societ à –bassa qualit à e costi elevati –assenza di metodi standard iterazione continua codifica/rimozione di errori

Venezia--Novembre Fatti e ipotesi implicite Organizzazioni monolitiche –soluzioni centralizzate L'ipotesi di mondo chiuso –i confini tra il mondo reale e la "macchina" sono chiari e fissi –i requisisti esistono e sono stabili, basta scovarli elicit them right! –le modifiche sono pericolose vanno evitate, sono la causa dei problemi di costo e "schedule"!

Venezia--Novembre Le soluzioni proposte A livello di processo –il modello sequenziale a fasi (waterfall) raffinamenti dai requisiti al codice sviluppi top-down via deduzioni formali A livello di prodotto –linguaggi e metodi per architetture software statiche, centralizzate, verificabili composizioni statiche, congelate a "design time"

Venezia--Novembre Lezioni apprese Impossibile stabilire all'inizio i requisiti I requisiti non possono essere congelati I requisiti sono intrinsecamente decentrati, illusori il loro controllo completo e la pre-pianificazione Quando cambiano, impattano spesso su ogni parte del prodotto/processo L'evoluzione è intrinseca al software –non è un fatto accidentale che capita inatteso dopo il rilascio

Venezia--Novembre Evoluzione controllata Si deve poter prevedere e controllare l'evoluzione –con ciò ci si allontana progressivamente dall'ipotesi di mondo chiuso A livello di processo –modelli evolutivi incrementali, prototipali, a spirale A livello di prodotto –Metodi design for change (Parnas) –information hiding –specification/interface vs. implementation/body –Tecnologia e linguaggi da strutture monolitiche, a modulari e distribuite (client/server)

Venezia--Novembre Evoluzione controllata: linguaggi e metodi OO Consentono alcuni tipi di cambiamenti dinamici Nuove (sotto)classi e oggetti possono essere creati mentre il sistema è in esecuzione –le operazioni chiamate vengono scelte durante l'esecuzione Mondo parzialmente aperto + "type safety" –se si possono prevedere i cambiamenti e li si possono gestire mediante il meccanismo di ereditariet à, l'evoluzione dinamica può coesistere con la verifica statica ("type safety")

Venezia--Novembre body interface Polimorfismo Fax f Binding dinamico f.sendFax(); OO design Fax -body -interface Fax with phone

Venezia--Novembre Binding che attraversa i confini di rete client server RMI code base

Venezia--Novembre Componenti: il processo nel mondo aperto Sistemi sviluppati a partire da componenti Mondo aperto per il processo –sviluppi decentrati –multipli "stakeholder" controllo limitato sul processo –integrazione "bottom up" via middleware

Venezia--Novembre Facciamo il punto La necessit à di adattamento ai cambiamenti esterni –nel mondo del "business" –nel mondo fisico impone cambiamenti al software Siamo stati ragionevolmente capaci di rispondere a questa sfida senza compromettere l'affidabilit à delle soluzioni

Venezia--Novembre Che cosa succede oggi? Mondo aperto –livelli mai prima sperimentati di evoluzione –"perpetual beta"

Venezia--Novembre Dove sono i motivi del cambiamento? (1) Nel mondo del business –organizzazioni agili in rete federazioni dinamiche, opportunistiche, goal-oriented reazioni rapide ai rapidi cambiamenti della domanda reazioni rapide interne all'organizzazione e nella rete dei rapporti

Venezia--Novembre Organizzazioni in rete Le applicazioni appartengono a diversi domini applicativi Interazioni via web con proptocolli standard BOO BOO LOO LOO MOO MOO FOO FOO Funzionalit`a offerte da diversi fornitori che variano nel tempo Esportazione di applicazioni interne

Venezia--Novembre Dove sono i motivi del cambiamento? (2) Mobilit à fisica e ubiquitous/ pervasive computing –richiedono binding dinamici e context-aware invocazione di un servizio di stampa che si lega alla stampante pi ù vicina richiesta di illuminazione che si lega a un attuatore che apre le imposte o all'interruttore della luce elettrica a seconda dellle condizioni di luce esterna

Venezia--Novembre Mondo aperto I requisiti cambiano in continuazione e in modo imprevedibile I confini tra il sistema e il mondo esterno non possono essere congelati –possono cambiare mentre il sistema è in esecuzione non possiamo "spegnere il sistema" e riprogettare/ reinstallare/rieseguire occorre fornire un servizio senza interruzione Le composizioni evolvono perch è possono cambiare sia i components che la loro struttura Non esiste una singola "autorit à " che ha l'intero sistema a carico

Venezia--Novembre Mondo chiuso Nel mondo chiuso esiste una separazione netta tra pre - runtime e runtime I cambiamenti si gestiscono ritornando alla fase di sviluppo, nella quale si effettuano le attivit à di verifica progetto verifica deployment execuzione

Venezia--Novembre Da componenti a servizi Entrambi sono sviluppati da "altri" I componenti sono eseguiti nel dominio dell'applicazione, e ne diventano parte I servizi sono eseguiti nei rispettivi domini Di norma, i componenti vengono scelti e collegati al tempo di progettazione Servizi scelti e collegati a run-time I servizi supportano contratti espliciti per consentire l'uso da parte di terzi –richiedono un SLA che riguarda non solo gli aspetti funzionali I servizi possono essere composti per formare nuovi servizi

Venezia--Novembre Ownership Tradizionalmente le applicazioni sono possedute dalle organizzazioni che lo "eseguono" Componenti e software di supporto non sono posseduti, ma sono amministrati da chi li esegue –che dipende dal proprietario per le evoluzioni I servizi non sono posseduti n è amministrati, ma solo "attivati"

Venezia--Novembre Meccanismi di binding per il mondo aperto Esplicito in due fasi –discovery-based fase 1: pubblicazione delle propriet à funzionali e non fase 2: ricerca, scoperta, selezione, con eventuale ottimizzazione/negoziazione Implicito –via uno spazio logico glocale di coordinamento eventi: publish/subscribe dati persistenti: tuple space by contract?

Venezia--Novembre Discovery Agency Service Provider Service Requestor Requirements Service Specification Publish Discovery-based binding Service Specification Service Interact Query Requirements RequestResponse

Venezia--Novembre C3C4C5C6 C1C2 Event Dispatcher sottoscrizioni notifiche Implicit binding (P/S) 2 sottoscrizioni a "rosso" (C1, C5) 1 sottoscrizione a blu (C6)

Venezia--Novembre Architetture Publish-Subscribe Comunicazione asincrona mediata da un dispatcher –anonima –multipoint –implicit addressing subject vs. contents-based I componenti applicativi –si sottoscrivono a pattern di messaggi a cui sono interessati – pubblicano messaggi Il dispatcher esegue un match tra messaggi pubblicati e sottoscrizioni ed esegue il multicast Supporto all'aggiunta/rimozione/sostituzione dinamica di componenti

Venezia--Novembre Un esempio publish/subscribe service publish/subscribe service want low air fares to Europe want low air fares to Europe want to fly December DEN-MXP want to fly December DEN-MXP want special offers by United want special offers by United subscribe notify United offers DEN-MXP October United offers DEN-MXP October Alitalia offers DEN-MXP Nov-Feb Alitalia offers DEN-MXP Nov-Feb publish subscriber publisher subscription publication notification Dovuto a Carzaniga e Wolf

Venezia--Novembre E-commerce TIBCO, ION-MkView, smartsockets operatori finanziari (compravendita di azioni) gateway verso altri mercati dispatcher componenti applicativi

Venezia--Novembre Spazi di tuple (Linda-like) C3C4C5C6 C1C2 Tuple space invia tupla rimuove tupla via pattern matching legge tupla via pattern matching read e remove nondeterministiche e bloccanti

Venezia--Novembre Binding by contract COMPONENT required interfaceprovided interface interfaccia descritta da una SPECIFICA La specifica descrive signature comportamento funzionale comportamento nonfunzionale Bisogna gestire le violazioni di contratto

Venezia--Novembre Potenziali benefici Chiara separazione tra "what", "how" e "when" –possibili diverse politiche early/late context-aware ottimizzazione di figure di merito –legame al "current best" –"self-organization" –necessaria descrizione semanticamente ricca delle interfacce deve descrivere la QoS

Venezia--Novembre BBC per composizione di servizi La composizione può essere descritta da un workflow, che specifica una orchestrazione astratta –il workflow viene eseguito dal direttore ch fa da coordinatore –i servizi esterni sono definiti tramite specifica che consente BBC –binding a servzi concreti viene fatto dinamicamente

Venezia--Novembre Le sfide del mondo aperto Vanno ripensate tutte le attivit à del ciclo di vita –requisiti –specifica –design&implementazione –verifica&convalida

Venezia--Novembre Zoom-in #1 Dynamic self-adapting service orchestration via BBC collaborazioni con L. Baresi, D. Bianculli,E. Di Nitto, S. Guinea, P. Spoletini

Venezia--Novembre Web service orchestrations L'orchestrazione di Web services con BPEL consente di sviluppare servizi complessi per composizione BPEL viene esteso per consentire di denotare servizi partner astratti Binding a servizi concreti realizzato a run-time, a causa del mondo aperto, poich è –i servizi possono cambiare nel tempo ( in meglio o in peggio ) –nuovi servizi si rendono disponibili ( e si vuol sfruttare la loro disponibilit à, che può dipendere dal contesto )

Venezia--Novembre Verifica&convalida + BBC fornisce flessibilit à e dinamismo - BBC richiede perpetua V&V –late binding+composizione dinamica danno flessibilit à al costo di ridotta affidabilit à –l'intero spettro possibile di regimi di binding uno spettro completo di attivit à di V&V

Venezia--Novembre tipi di convalida 1 linguaggio ALBERT: un linguaggio in logica temporale per processi BPEL –può esprimere propriet à funzionale e non-funzionali –utilizzabile per due tipi di convalida design-time ( model checking ) –si assume che il mondo esterno soddisfi certe propriet à e sulla base di ciò –si garantisce che valgano certe propriet à del servizio composto run-time ( monitoring ) –si verifica il mantenimento delle propriet à Un unico e coerente framework per la convalida

Venezia--Novembre Assume-guarantee Un approccio potente alla progettazione e verifica –definire ciò che il mondo esterno deve garantire si assume che valga e ci si fida che sia cos ì –a ciò che a nostra volta dobbiamo garantire abbiamo naturalmente l'onere della prova che sia davvero cos ì Naturalmente esiste l'onere di prova/check che ciò che si assume riguardo a X sia davvero garantito da X

Venezia--Novembre Che succede se il contratto è violato? Strategie di re-binding Comportamenti autonomici –qui non ne parliamo

Venezia--Novembre Il processo TeleAssistance receive while pick invoke switch invoke "mild" panic button invoke "high"

Venezia--Novembre Qualche propriet à LabServiceTime : la risposta del lab arriva entro 1 ora dall'invio dei dati del paziente FASConfirmHospitalization : se il FAS viene chiamato 3 volte in 1 settimana con severit à High per un certo paziente, si deve notificare il TA, entro 1 giorno, che il paziente è stato ricoverato FASInvokeMildAlarm : dopo la ricezione di un messaggio dal LAB che indica che deve essere mandato un allarme al FAS, TA dve invocare il servizio FAS entro 4 ore, con una severit à Mild dell'allarme MDCheckUp : se un paziente preme pButtonMsg 3 volte in una settimana, il FAS ospedalizza il paziente entro 1 giorno

Venezia--Novembre Specifiche nonfunzionali performance dependability response time throughtputreliabilityavailability richiedono tempo esplicito e una metrica la distanza tra tempi conteggi (negli intervalli di tempo)

Venezia--Novembre ALBERT Un linguaggio temporale che predica su eventi e durate Consente di esprimere statement di QoS Le proprietà sono espresse come invarianti del processo Sintassi:

Venezia--Novembre Stati Semantica espressa con riferimento a sequenze di stati (con time- stamp) del processo BPEL

Venezia--Novembre Becomes and Until Becomes(A) Until(A,B)

Venezia--Novembre Between and Within Between(A,B,6) Within(A,6)

Venezia--Novembre past and elapsed past(A,onEvent(Y),2) elapsed(onEvent(X))

Venezia--Novembre count In i11: – count(Becomes(B), 36) = 1 – Becomes(count(B, 36) = 4) is true – count(B, onEvent(Y), 36) = 2 count(B,36)

Venezia--Novembre Esempi LabServiceTime: MDCheckUp: la risposta del lab arriva entro 1 ora dall'invio dei dati del paziente se un paziente preme pButtonMsg 3 volte in una settimana, il FAS ospedalizza il paziente entro 1 giorno x(Becomes(count($alarmNotif/level=`high x = $alarmNotif/pID, onEvent(pButtonMsg), 10080) = 3) Within(onEvent(patHospitalizedMsg) $patHospitalized/pId=x, 1440)) onEvent(start_analyzeData) Within(onEvent(end_analyzeData), 60)

Venezia--Novembre Esecuzione e monitoring via AOP

Venezia--Novembre Valutazione di ALBERT a run time Per le proprietà che fanno riferimento solo allo stato presente o alla storia passata –la storia è bounded Per le proprietà che fanno riferimento al futuro –si genera un nuovo task parallelo, ma ancora si ha memoria bounded

Venezia--Novembre Zoom-in #2 Design and accurate verification of Publish-Subscribe architectures joint work with L. Baresi, L. Mottola, L. Zanolin

Venezia--Novembre Premise Modern distributed applications for dynamic environments ask for a flexible and reconfigurable software infrastructure Publish-Subscribe provides an answer to these needs –fostering an anonymous, implicit, multi-point communication paradigm Hard to design and verify "global behavior" of composite applications –component interactions change dynamically –focus on each reactive component, "global picture" is missing –real-world Publish-Subscribe systems differ along several dimensions

Venezia--Novembre Enterprise Systems Dynamic Topologies Sensor Networks Variety of approaches (1) From enterprise to embedded systems

Venezia--Novembre Variety of approaches (2) Different guarantees provided GuaranteeChoices Message ReliabilityAbsent, Present Message Ordering Random, Pair-wise FIFO, System- wide FIFO, Causal Order, Total Order FilteringPrecise, Approximate Real-time GuaranteesAbsent, Present Subscription Propagation Delay Absent, Present Repliable MessagesAbsent, Present Message PrioritiesAbsent, Present Queue Drop PolicyNone, Tail Drop, Priority Drop ……

Venezia--Novembre Existing systems Guarantee JMS-compliant [jmsSpec] REDS [cugola07reds] DSWare [li04event] Message ReliabilityPresent Absent Message OrderingPair-wise FIFORandom FilteringPrecisePrecise, ApproximatePrecise Real-time GuaranteesAbsent Present Subscription Propagation DelayAbsentPresent Repliable MessagesPresent Absent Message PrioritiesPresentAbsent Queue Drop PolicyPriority DropTail Drop

Venezia--Novembre Message ordering C2 C1 C3 t1: e1 t2: e2 C2 C1 C3 t1: e1 t2: e2

Venezia--Novembre Ordering of events Hypothesis: C1 generates e1 for C2, C3 C2 generates e2 and then e3 for C3 e3 generated by C2 as a consequence of receipt of e1 C1C2C3 Total ordering e1 e2 e3 C1C2C3 Causal ordering e1 e2 e3 C1C2C3 Ordering relative to sender e1 e2 e3 C1C2C3 None e1 e2 e3

Venezia--Novembre A designer's workbench Provide a model of the architecture The model embodies the amount of detail that the designer wishes to express The model is verified against certain properties The model is changed or details are added as needed GOAL: assess design and detect design flaws prior to moving to implementation

Venezia--Novembre State of the art Model checking proposed to address the verification issue –standard tools (e.g., SPIN) used to model both the application and the PubSub infrastructure (e.g., [garlan03], [baresi ghezzi zanolin03]) – fine-grained models unfeasible due to state space explosion – parametric models difficult due to little support for parameterization in the modeling language A change of perspective: embed the PubSub communication paradigm within the model-checker

Venezia--Novembre Our solution Fine grained parametric models implemented in the model checker –PubSub APIs as primitive constructs of the modeling language easier to specify the application model Domain-specific knowledge can achieve application- specific state abstraction –addresses the state space explosion problem

Venezia--Novembre Performing the verification Specify the application model using the PubSub API Specify the properties to be checker (LTL) Select combination of PubSub guarantees the application relies on Instantiate the parametric dispatcher within Bogor Depending on the verification outcome: –modify the application model –change the guarantees selected Allows one to explore the interplay between application and comm infrastructure

Venezia--Novembre PubSub APIs The PubSub infrastructure is offered as a generic abstract data type –each instance represents a connection to the PubSub dispatcher –customized w.r.t. the type of messages used by the application – operations are used to issue subscriptions, publish messages, … typealias MessagePriority int (0,9); enum DropPolicy {TAIL_DROP, PRIORITY_DROP } extension PubSubConnection for polimi.bogor.bogorps.PubSubModule { typedef type ; expdef PubSubConnection.type register (); expdef PubSubConnection.type registerWithDropping (int, DropPolicy); actiondef subscribe (PubSubConnection.type, 'a -> boolean); actiondef publish (PubSubConnection.type, 'a); actiondef publishWithPriority (PubSubConnection.type, 'a, MessagePriority); expdef boolean waitingMessage (PubSubConnection.type ); actiondef getNextMessage (PubSubConnection.type, lazy 'a); } Subscriptions as boolean functions!

Venezia--Novembre Using PubSub APIs record MyMessage {int value;} MyMessage receivedEvent := new MyMessage; active thread Publisher() { MyMessage publishedEvent = new MyMessage; PubSubConnection.type ps; loc loc0: // Connection setup do { ps := PubSubConnection.register ();} goto loc1; loc loc1: // Publishing a message do { publishedEvent.value := 1; PubSubConnection.publish (ps, publishedEvent);} return; } Publishes a message record MyMessage {int value;} fun isGreaterThanZero(MyMessage event) returns boolean = event.value > 0; active thread Subscriber() { PubSubConnection.type ps; loc loc0: // Connection setup and subscription do { ps := PubSubConnection.register (); PubSubConnection.subscribe (ps, isGreaterThanZero);} goto loc1; loc loc1: // Message receive when PubSubConnection.waitingMessage (ps) do { PubSubConnection.getNextMessage (ps, receivedEvent);} return; } Issues a (matching) subscription Defines a subscription Receives a message

Venezia--Novembre Representing the system state Let the system state be described by a tuple: In turn, let us also define SystemState = i-th thread (application component) state DispatcherState = Subscriptions issued Bookkeeping data to model specific guarantees Messages in transit

Venezia--Novembre Domain-specific model checker state abstraction - Example 1 A message is delivered to an application component if at least one of its subscriptions matches –the order in which subscriptions are examined is immaterial We model the subscription table as a set DispatcherState =

Venezia--Novembre As messages are delivered, bookkeeping information must be stored at the dispatcher to enforce a specific message ordering –from the dispatcher perspective, they change every time a message is published From the application perspective, the state of the incoming queue may be viewed as unchanged even though some messages directed to it have been issued DispatcherState = Domain-specific model checker state abstraction - Example 2

Venezia--Novembre Domain-specific model checker state abstraction - Example 3 Publish-Subscribe often needs to duplicate messages Message duplication does not affect the application state All supporting data structures hidden in our Bogor extension

Venezia--Novembre More on "why Bogor" Multi-point communication feasible also with other tools (e.g., using Promela channels) –cannot model dynamic sender-receiver pairs –cannot be detached to serve a different pair of processes –cannot model fine-grained guarantees

Venezia--Novembre Evaluation A set of synthetic scenarios stressing sample PubSub guarantees –5 threads subscribing to messages coming from another thread Comparing against SPIN/Promela [zanolin03approach] ScenarioPublish Ops. Bogor w/ PubSubSPIN/Promela MemoryTimeMemoryTime Causal Mb103 sec298.3 Mb> 15 min Causal Mb132 sec589.6 Mb> 1 hour Causal Mb158 secOutOfMemNotCompleted Causal Mb189 secOutOfMemNotCompleted Priorities Mb47 sec192 Mb> 10 min Priorities Mb103 sec471.2 Mb> 30 min Priorities Mb134 secOutOfMemNotCompleted Priorities Mb163 secOutOfMemNotCompleted

Venezia--Novembre Case study An application for fire monitoring in a tunnel Communication patterns expressed as subscriptions A set of requirements –R1 - when a truck enters the tunnel, ventilation must increase –R2 - when temperature increases, smoke sensors must be queried –R3 - when temperature increases, notify cs and contact fb to inspect the environment. It reports to cs which checks that control occurred –R4 - messages from the control station to command the traffic lights must be delivered with a maximum delay of five time units Requirements expressed in LTL PubSub guarantees initially set to DSWare

Venezia--Novembre Verification - Step 1 The initial application model took message reliability for granted –R1 ( ventilation must increase when a truck enters the tunnel ) fails immediately Message reliability currently investigated in embedded networked systems –assume it is provided by the communication infrastructure R1 fails Select reliability

Venezia--Novembre Verification - Step 2 R3 (… contact the fire brigade to inspect the environment and report to the control station ) fails without causal ordering CO is key in safety applications Push CO in the PubSub infrastructure R3 fails Select CO

Venezia--Novembre Verification - Step 3 R3 also requires the subscription from the fire brigade to propagate instantaneously Unreasonable to assume in a distributed environment Modify the application R3 fails Repeat publish until ACK

Venezia--Novembre Verification - Step 4 R2 ( when temperature increases, smoke sensors must be queried ) requires a query reply interaction R2 fails because of subscription propagation delays Query-reply provided by embedded system middleware R2 fails Select repliable messages

Venezia--Novembre Verification - Step 5 R4 ( messages … must be delivered with a maximum delay of five time units) requires RT DSWare already provides it R4 succeeds

Venezia--Novembre Conclusions A tool supporting exploration of the design space Enables exploring the interplay between application and communication infrastructure Proposed a change of perspective in the use of model checking –embed domain specific mechanisms and export them as primitive constructs of the modeling language Make fine-grained, parametric models feasible

Venezia--Novembre The end Fundamental problems continue to exist in a new and more difficult form –Process level combine process agility and product quality –harder for distributed and inter-organization developments –Product level requirements and specification architecture/implementation verification

Venezia--Novembre Acknowledgements Projects SeCSE, Cascadas, Plastic, ArtDeco People –L. Baresi, E. Di Nitto, G.P. Picco, G. Cugola, S. Guinea, D. Bianculli, P. Spoletini, L. Mottola … student*

Venezia--Novembre Some papers C. Ghezzi, L. Baresi, E Di Nitto "Towards Open-World Software". Computer, IEEE, Volume 39, Number 10: 36-43, October 2006 L. Baresi, C. Ghezzi, and S. Guinea, "Smart Monitors for Composed Services", 2nd Int.l Conf. on Service Oriented Computing. Nov L. Baresi, C. Ghezzi, and S. Guinea "Towards Self-healing Compositions of Services" In Bernd J. Kraemer and Wolfgang A. Halang (eds.) Contributions to Ubiquitous Computing. Volume 42 of Studies in Computational Intellligence, Springer, 2006 L. Baresi, E. Di Nitto, C. Ghezzi, S. Guinea "A Flexible Framework for the Deployment of Service-Centric Systems", Service Oriented Computing and Applications, 1, 1, 2007 L. Baresi, D. Bianculli, C. Ghezzi, P. Spoletini. Monitoring Web Service Orchestrations Using Timed WSCoL Proc. of Int.l Conference on Web Services (ICWS), 2007 D. Bianculli, C. Ghezzi, Monitoring Conversational Web Services, SOSWE L. Baresi, D. Bianculli, C. Ghezzi, S. Guinea, P. Spoletini. Validation of Web service compositions. To appear on IEE Proceedings Software, 2007 L. Baresi, C. Ghezzi, and L. Mottola "On Accurate Automatic Verification of Publish-Subscribe Architectures", ICSE 2007 D. Bianculli, R. Jurca, W. Binder, C. Ghezzi, B.Faltings. Automated Dynamic Maintenance of Composite Services based on Service Reputation. In Proc. of Int.l Conf. on Service Oriented Computing (ICSOC), 2007 L. Zanolin, C. Ghezzi, and L. Baresi. "An Approach to Model and Validate Publish/Subscribe Architectures". In Proc. of the SAVCBS03 Workshop, 2003 L. Baresi, C. Ghezzi, and L. Mottola. "Towards Fine-Grained Automated Verification of Publish-Subscribe Architectures". In Proc. of the 26 th Int. Conf. on Formal Methods for Networked and Distributed Systems (FORTE06), 2006 L. Baresi, C. Ghezzi, and L. Mottola. "On Accurate Automatic Verification of Publish-Subscribe Architectures". Proc. of the 29 th Int. Conf. on Software Engineering (ICSE07), 2007 L. Baresi, G. Gerosa, C. Ghezzi, and L. Mottola. "Playing with Time in PublishSubscribe using a DomainSpecific Model Checker". In Proc. of the SAVCBS03 Workshop, 2007