{"title":"Design and construction of large-scale components: main insights of OOPSLA'95 workshop 10","authors":"George Brown, Brad Kain","doi":"10.1145/260094.260281","DOIUrl":null,"url":null,"abstract":"The main insights from this workshop centered on the expectations for realizing large-scale systems built of software components. A secondary consideration was that the implementations were compliant with the OMG Architecture. It was generally accepted that a pre-requisite for large-scale components is a common infrastructure for sharing components in a distributed environment. Within this context, a distinction should be made between small and large components. The component model definition was assumed to be distinct from an object model. There was recognition of the need for heterogeneous component interaction and integration. Current IDL was considered insufficient to express both the semantics of components and the configuration syntax associated with components within components as part of a good model. There was general agreement that new cost models are needed. If efforts to promote software component technology are successful, we will be faced with how to do pricing. It was emphasized that bits and atoms are different and our models for selling products may not apply. For example, one possibility is that software components are given away free, and payback of components occurs through integration services. There needs to be better understanding of break-even cost factors of component reuse. Clearly, if you only share a component with one other, then building the component may not be cost justified due to maintenance cost, etc. Because of the uncertainty in cost factors, it was asserted that development organizations should at least consider the cost and risk of not enabling “software components”.","PeriodicalId":286350,"journal":{"name":"Addendum to the proceedings of the 10th annual conference on Object-oriented programming systems, languages, and applications","volume":"1 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1995-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Addendum to the proceedings of the 10th annual conference on Object-oriented programming systems, languages, and applications","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/260094.260281","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0
Abstract
The main insights from this workshop centered on the expectations for realizing large-scale systems built of software components. A secondary consideration was that the implementations were compliant with the OMG Architecture. It was generally accepted that a pre-requisite for large-scale components is a common infrastructure for sharing components in a distributed environment. Within this context, a distinction should be made between small and large components. The component model definition was assumed to be distinct from an object model. There was recognition of the need for heterogeneous component interaction and integration. Current IDL was considered insufficient to express both the semantics of components and the configuration syntax associated with components within components as part of a good model. There was general agreement that new cost models are needed. If efforts to promote software component technology are successful, we will be faced with how to do pricing. It was emphasized that bits and atoms are different and our models for selling products may not apply. For example, one possibility is that software components are given away free, and payback of components occurs through integration services. There needs to be better understanding of break-even cost factors of component reuse. Clearly, if you only share a component with one other, then building the component may not be cost justified due to maintenance cost, etc. Because of the uncertainty in cost factors, it was asserted that development organizations should at least consider the cost and risk of not enabling “software components”.