Yves Vandewoude, Peter Ebraert, Y. Berbers, T. D'Hondt
{"title":"宁静的替代品:宁静","authors":"Yves Vandewoude, Peter Ebraert, Y. Berbers, T. D'Hondt","doi":"10.1109/ICSM.2006.11","DOIUrl":null,"url":null,"abstract":"This paper revisits a problem that was identified by Kramer and Magee: placing a system in a consistent state before and after runtime changes (1990). We show that their notion of quiescence as a necessary and sufficient condition for safe runtime changes is too strict and violates the black-box design principle. We introduce a weaker condition, tranquility; easier to obtain, less disruptive for the system and still sufficient to ensure application consistency. We also present an implementation of this concept in a component middleware platform","PeriodicalId":436673,"journal":{"name":"2006 22nd IEEE International Conference on Software Maintenance","volume":"15 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2006-09-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"25","resultStr":"{\"title\":\"An alternative to Quiescence: Tranquility\",\"authors\":\"Yves Vandewoude, Peter Ebraert, Y. Berbers, T. D'Hondt\",\"doi\":\"10.1109/ICSM.2006.11\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"This paper revisits a problem that was identified by Kramer and Magee: placing a system in a consistent state before and after runtime changes (1990). We show that their notion of quiescence as a necessary and sufficient condition for safe runtime changes is too strict and violates the black-box design principle. We introduce a weaker condition, tranquility; easier to obtain, less disruptive for the system and still sufficient to ensure application consistency. We also present an implementation of this concept in a component middleware platform\",\"PeriodicalId\":436673,\"journal\":{\"name\":\"2006 22nd IEEE International Conference on Software Maintenance\",\"volume\":\"15 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2006-09-24\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"25\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"2006 22nd IEEE International Conference on Software Maintenance\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/ICSM.2006.11\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"2006 22nd IEEE International Conference on Software Maintenance","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ICSM.2006.11","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
This paper revisits a problem that was identified by Kramer and Magee: placing a system in a consistent state before and after runtime changes (1990). We show that their notion of quiescence as a necessary and sufficient condition for safe runtime changes is too strict and violates the black-box design principle. We introduce a weaker condition, tranquility; easier to obtain, less disruptive for the system and still sufficient to ensure application consistency. We also present an implementation of this concept in a component middleware platform