{"title":"CORBA: from vision to reality","authors":"K. D. Boucher","doi":"10.1145/293376.293384","DOIUrl":"https://doi.org/10.1145/293376.293384","url":null,"abstract":"","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"92 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121895662","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"CORBA and the world of standards","authors":"Henry Lowe","doi":"10.1145/293376.293395","DOIUrl":"https://doi.org/10.1145/293376.293395","url":null,"abstract":"","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"40 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123825341","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Introduction: ten years of consensus","authors":"R. Soley","doi":"10.1145/293376.293380","DOIUrl":"https://doi.org/10.1145/293376.293380","url":null,"abstract":"","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"42 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126098337","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"What does the future hold for distributed object computing","authors":"J. �. Held, Catherine A. T. Susch, Amir Golshan","doi":"10.1145/293376.293387","DOIUrl":"https://doi.org/10.1145/293376.293387","url":null,"abstract":"","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123832417","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
An Object Adapter is an integral part of the Common Object Request Broker Architecture (CORBA). An Object Adapter assists an Object Request Broker (ORB) in delivering client requests to server object implementations (servants). Services provided by an Object Adapter include: (1) generating and interpreting object references, (2) activating and deactivating servants, (3) demultiplexing requests to map object references onto their corresponding servants, and (4) collaborating with automatically-generated IDL skeletons to invoke operations on servants. This paper provides two contributions to the study of Object Adapters. First, it outlines the CORBA Portable Object Adapter (POA) specification, which is a recent addition to the CORBA standard that greatly simplifies the development of portable and extensible servants and server applications. The design goals, architectural components, and semantics of the POA are explained. Second, the paper describes the design choices made to adapt the POA for the TAO Real-time ORB. Key design issues regarding efficient demultiplexing, upcall and collocation optimizations, ORB and POA concurrency configurations, POA synchronization, and predictability are covered.
{"title":"An overview of the CORBA portable object adapter","authors":"Irfan Pyarali, D. Schmidt","doi":"10.1145/293376.293402","DOIUrl":"https://doi.org/10.1145/293376.293402","url":null,"abstract":"An Object Adapter is an integral part of the Common Object Request Broker Architecture (CORBA). An Object Adapter assists an Object Request Broker (ORB) in delivering client requests to server object implementations (servants). Services provided by an Object Adapter include: (1) generating and interpreting object references, (2) activating and deactivating servants, (3) demultiplexing requests to map object references onto their corresponding servants, and (4) collaborating with automatically-generated IDL skeletons to invoke operations on servants. This paper provides two contributions to the study of Object Adapters. First, it outlines the CORBA Portable Object Adapter (POA) specification, which is a recent addition to the CORBA standard that greatly simplifies the development of portable and extensible servants and server applications. The design goals, architectural components, and semantics of the POA are explained. Second, the paper describes the design choices made to adapt the POA for the TAO Real-time ORB. Key design issues regarding efficient demultiplexing, upcall and collocation optimizations, ORB and POA concurrency configurations, POA synchronization, and predictability are covered.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"67 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117017834","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Standards and the USIGS","authors":"S. Sutton","doi":"10.1145/293376.293407","DOIUrl":"https://doi.org/10.1145/293376.293407","url":null,"abstract":"","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"70 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114672566","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Object technology, a necessary but not sufficient condition for software reuse, requires an infrastructure that supports plug compatible Business Object Components for fast and flexible delivery of new or enhanced products to the marketplace. This paper is a retrospective view on key conceptual issues driving the standardization of a Business Object Component Architecture (BOCA) within the Object Management Group (OMG). The seamless integration of BOCA with the Unified Modeling Language (UML), a standardized Meta-Object Facility (MOF), and an emerging CORBA Component specification is essential to design-driven generation of runtime components into heterogeneous distributed object frameworks. BOCA standardization can enhance software productivity with plug compatible, reusable components, the holy grail of object computing.
{"title":"Why I love the OMG: emergence of a business object component architecture","authors":"J. Sutherland","doi":"10.1145/293376.293382","DOIUrl":"https://doi.org/10.1145/293376.293382","url":null,"abstract":"Object technology, a necessary but not sufficient condition for software reuse, requires an infrastructure that supports plug compatible Business Object Components for fast and flexible delivery of new or enhanced products to the marketplace. This paper is a retrospective view on key conceptual issues driving the standardization of a Business Object Component Architecture (BOCA) within the Object Management Group (OMG). The seamless integration of BOCA with the Unified Modeling Language (UML), a standardized Meta-Object Facility (MOF), and an emerging CORBA Component specification is essential to design-driven generation of runtime components into heterogeneous distributed object frameworks. BOCA standardization can enhance software productivity with plug compatible, reusable components, the holy grail of object computing.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121760784","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
only a simple majority to be successful. (This was an administrative policy vote, not a technology vote. A technology vote requires more than a simple majority.) The balloting is interesting for two reasons. The first is the unusual number and intent of the comments by the National Bodies, which showed the ambiguity felt on this issue. The National Bodies wanted the Java technology, but were unsure that the price (acceptance of SMI as a PAS Provider) was correct or fair or even to be paid in the right currency. The second reason is that the vote by the US committee was neither to accept nor deny the SMI application, but on the reconsideration ballot to vote to affirm, or reverse a previous vote. To change a previous negative vote to a positive one needs a super majority (two-thirds of the voting members). On the US ballot, 60% of the members of the US JTC1 TAG voted to change the ballot to " yes. " However, since a two-thirds majority did not vote to change, the US position remained opposed. The issue was contentious, but the lack of understanding of the voting rules by the press further exacerbated the situation and made it substantially worse. Via a majority of the votes cast by JTC1 P-members, Sun Microsystems, Inc. is approved as a Recognized PAS Sub-mitter. Comments received from JTC1 P-members must be addressed by Sun, in consultation with JTC1, prior to submitting a PAS specification for JTC1 letter ballot. This could be done through an early submission of an Explanatory Report and related documentation (ref. Supplement 1 of the Procedures for the technical work of ISO/IEC JTC1 on Information Technology).
{"title":"Section 10. The end of the beginning","authors":"C. Cargill","doi":"10.1145/274348.274358","DOIUrl":"https://doi.org/10.1145/274348.274358","url":null,"abstract":"only a simple majority to be successful. (This was an administrative policy vote, not a technology vote. A technology vote requires more than a simple majority.) The balloting is interesting for two reasons. The first is the unusual number and intent of the comments by the National Bodies, which showed the ambiguity felt on this issue. The National Bodies wanted the Java technology, but were unsure that the price (acceptance of SMI as a PAS Provider) was correct or fair or even to be paid in the right currency. The second reason is that the vote by the US committee was neither to accept nor deny the SMI application, but on the reconsideration ballot to vote to affirm, or reverse a previous vote. To change a previous negative vote to a positive one needs a super majority (two-thirds of the voting members). On the US ballot, 60% of the members of the US JTC1 TAG voted to change the ballot to \" yes. \" However, since a two-thirds majority did not vote to change, the US position remained opposed. The issue was contentious, but the lack of understanding of the voting rules by the press further exacerbated the situation and made it substantially worse. Via a majority of the votes cast by JTC1 P-members, Sun Microsystems, Inc. is approved as a Recognized PAS Sub-mitter. Comments received from JTC1 P-members must be addressed by Sun, in consultation with JTC1, prior to submitting a PAS specification for JTC1 letter ballot. This could be done through an early submission of an Explanatory Report and related documentation (ref. Supplement 1 of the Procedures for the technical work of ISO/IEC JTC1 on Information Technology).","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129163408","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
m Before it initiated the SMI PAS documentation, SMI participated in four major standardization activities—UNIX standardization, the Graphical User Interface (GUI) wars, IEEE 1754 activities, and the Windows Application Programming Interface (APIW) effort. In all of these activities Sun was a major protagonist, battling with or against major players in the IT industry. SMI’s experiences with its standardization initiatives provide a basis for understanding SMI’s dealings with the PAS, and why the PAS represents one organization’s response to the difficulties encountered in the formal (and informal) standardization process. This section of StandardView looks briefly at these four activities and tries to draw a somewhat sympathetic picture of the mindset of SMI management as they struggled with the need to standardize Java. significant player in much of SMI’s standardization history was the Open Software Foundation (OSF). OSF was created to, among other things, counter the Sun–AT&T alliance on SVR4 UNIX. In 1987 and 1988, Sun abandoned its BSD UNIX base and aligned with AT&T’s System 5, Release 4, agreeing to AT&T licensing terms and conditions. Other major vendors, including Digital, found AT&T’s proposed royalty scheme not in their business interests, and opted instead to create their own UNIX-like system, merging the best of BSD, SVR4, and CMU’s Mach systems. To create this software, HP, Dec, and IBM formed the OSF in 1988, with the creation of a competing and “open” operating system, OSF1, as one of its goals. Sun and AT&T immediately responded with the creation of UNIX International (UI), a consortium intended to provide “open development of the real UNIX,” based on SVR4. The UI consortium was to provide an independent arena for the future development of UNIX, away from AT&T’s control. The UNIX Consortia battles caused the spilling of innumerable gallons of printers ink, but did little to make the world safe for UNIX or OSF1. Both sides spent tremendous amounts of money proving that they, and not their competition, were the true “open system” (see the earlier section on “open systems”). This battle continued until 1994. The UNIX battles spawned other arguments, the most notorious the now largely forgotten Graphical User Interface (GUI) war. The war had dual—and innocent—beginnings. The first part of the story unfolds at MIT, where the X Window System was created in the mid-1980s. DEC, IBM, and HP all participated in furthering the X Window Systems technology, and eventually MIT realized that it had a possible gold mine. To capitalize on its relationship with its sponsors, MIT formed (in 1988) a memberfunded consortium (the MIT X Consortium, renamed the X Consortium in 1993). Because the MIT X Consortium was limited in its scope (by design), the three major participants asked their newly created consortium to create a viable windowing scheme using X technology around which they (the big three vendors) could coalesce. The idea was to provide bot
{"title":"Section 2. Sun and standardization wars","authors":"C. Cargill","doi":"10.1145/274348.274350","DOIUrl":"https://doi.org/10.1145/274348.274350","url":null,"abstract":"m Before it initiated the SMI PAS documentation, SMI participated in four major standardization activities—UNIX standardization, the Graphical User Interface (GUI) wars, IEEE 1754 activities, and the Windows Application Programming Interface (APIW) effort. In all of these activities Sun was a major protagonist, battling with or against major players in the IT industry. SMI’s experiences with its standardization initiatives provide a basis for understanding SMI’s dealings with the PAS, and why the PAS represents one organization’s response to the difficulties encountered in the formal (and informal) standardization process. This section of StandardView looks briefly at these four activities and tries to draw a somewhat sympathetic picture of the mindset of SMI management as they struggled with the need to standardize Java. significant player in much of SMI’s standardization history was the Open Software Foundation (OSF). OSF was created to, among other things, counter the Sun–AT&T alliance on SVR4 UNIX. In 1987 and 1988, Sun abandoned its BSD UNIX base and aligned with AT&T’s System 5, Release 4, agreeing to AT&T licensing terms and conditions. Other major vendors, including Digital, found AT&T’s proposed royalty scheme not in their business interests, and opted instead to create their own UNIX-like system, merging the best of BSD, SVR4, and CMU’s Mach systems. To create this software, HP, Dec, and IBM formed the OSF in 1988, with the creation of a competing and “open” operating system, OSF1, as one of its goals. Sun and AT&T immediately responded with the creation of UNIX International (UI), a consortium intended to provide “open development of the real UNIX,” based on SVR4. The UI consortium was to provide an independent arena for the future development of UNIX, away from AT&T’s control. The UNIX Consortia battles caused the spilling of innumerable gallons of printers ink, but did little to make the world safe for UNIX or OSF1. Both sides spent tremendous amounts of money proving that they, and not their competition, were the true “open system” (see the earlier section on “open systems”). This battle continued until 1994. The UNIX battles spawned other arguments, the most notorious the now largely forgotten Graphical User Interface (GUI) war. The war had dual—and innocent—beginnings. The first part of the story unfolds at MIT, where the X Window System was created in the mid-1980s. DEC, IBM, and HP all participated in furthering the X Window Systems technology, and eventually MIT realized that it had a possible gold mine. To capitalize on its relationship with its sponsors, MIT formed (in 1988) a memberfunded consortium (the MIT X Consortium, renamed the X Consortium in 1993). Because the MIT X Consortium was limited in its scope (by design), the three major participants asked their newly created consortium to create a viable windowing scheme using X technology around which they (the big three vendors) could coalesce. The idea was to provide bot","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"80 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124132609","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：