Issue 16531: Getting rid of the Bootstrap Object (dds-psm-java-ftf) Source: (, ) Nature: Revision Severity: Critical Summary: The boostrap class is a pain for users which is in place only to allow users to run 2 different DDS implementations on the same application. The introduction of the Bootstrap object makes it impossible to use natural constructors for creating DDS types, even for types such as Time and Duration. As one of the main goal of the new DDS PSM was to simplify the user experience and make the API as simple and natural as possible, it seems that the introduction of the Bootstrap object goes exactly on the opposite direction -- all of this to be able to cover the case in which a user wants 2 different DDS implementation on the same application. Considering the wire-protocol interoperability this use case seems marginal and perhaps does not even count for 1% of DDS uses. [Resolution] The bootstrap should be removed and the resulting API should be simplified. Resolution: Revised Text: Actions taken: September 7, 2011: received issue Discussion: The concern for simplicity and usability expressed above is valid and important. The response to this concern will be constrained by requirements, including those below. In particular, the statement above that the Bootstrap class exists only to enable single applications to use two DDS implementations is incorrect. Requirements: The Bootstrap class is designed to avoid the brittle mixing of concrete implementation with abstract specification, which would occur if either the specification mandated implementation or if vendors re-implemented different classes with the “same” names. In addition, it is designed to enable the following deployment scenarios: 1. Standalone deployment of a single application using one or more DDS implementations. (The expected use case for multiple implementations is a DDS-to-DDS bridge.) 2. Deployment within an OSGi container, which may host multiple independent applications. a. More than one of application may use DDS internally, unknown to those applications. b. A given application should allow the injection of a concrete DDS dependency—that is, it should be able to declare, “I depend on DDS” and allow the platform’s administrator to choose the implementation. (This implies that the DDS API itself and the concrete implementation must be deployable as separate bundles, with multiple “application” bundles all depending on a common “specification” bundle.) 3. Deployment within a Java EE container, including one that—like JBOSS Application Server—uses a unified class loader design. (Such a deployment is like [1] above, although it expands the use case for multiple DDS implementations beyond bridges, as in [2a].) (As a point of comparison, the above needs are met by JMS.) Design Implications: The above requirements have two implications: ? They forbid the keeping of any static state or static dependency on any concrete implementation. Specifically, state pertaining to multiple DDS implementations must be able to coexist within a single class loader in order to support OSGI dependency injection, deployment to JBOSS AS, or DDS-to-DDS bridges. ? They forbid the keeping of any thread-local state. Especially in the Java EE environment, container threads (for example, from servlet thread pools) may call into DDS APIs. DDS state attached to these threads constitutes a resource leak that will prevent applications from being properly unloaded from the container. In other words, it is not possible for OMG-provided classes to know by themselves where to delegate their implementation. That knowledge must come from the application. Design Alternatives: There are two ways an application can provide the necessary implementation-specific context: • Indirectly: An (already-created) object can provide it to another object at the time of creation. This boils down to factory methods: if instance X can store implementation-specific state, and X is a factory for Y, then X can provide that state transparently to Y in a “createY()” method. Currently, the specification takes this approach where it is implied by the PIM. Alternatively, it could be extended everywhere: make the Bootstrap class (or another class) an explicit factory for every top-level type in the API. • Directly: The application can pass the calling environment as an argument. Currently, the specification takes this approach when accessing singletons or constructing instances of top-level classes. We can choose the right approach in each instance if we understand how Bootstrap is used today. Background: Bootstrap Occurrences: The class is used in the following places: 1. To access per-DDS-implementation singletons: DomainParticipantFactory and DynamicTypeFactory. 2. To create Entity-independent reference objects: WaitSet, GuardCondition, and TypeSupport. We could reduce the number of occurrences of Bootstrap by making accessors/factory methods for DynamicTypeFactory, WaitSet, GuardCondition, and TypeSupport available as instance methods of DomainParticipantFactory. 3. To create standalone value objects: Time, Duration, and InstanceHandle. These occurrences will be hard to eliminate. 4. To create instances of Status classes. We could eliminate these occurrences of Bootstrap by creating Status objects from factory instance methods on the corresponding Entity interfaces. 5. To create instances of built-in topic data types: ParticipantBuiltinTopicData, BuiltinTopicKey, etc. These occurrences will be hard to eliminate. 6. To access convenience sets of Status Class objects—the equivalent of STATUS_MASK_ALL and STATUS_MASK_NONE. We could eliminate these occurrences by making these accessors instance methods. [Rick] Proposal The fact that this issue came up indicates that the rationale for the Bootstrap class is not sufficiently clear. Add such an expanded rationale to the specification document. Furthermore, rename the class to ServiceEnvironment to make its role clearer. In addition, the method signatures for Bootstrap.createInstance() are incorrect for handling some OSGi deployment scenarios: it must be possible to supply the ClassLoader to be used to load the implementation class in order for dependencies to be resolved properly. Fix these signatures at the same time. With respect to the code, see the following revisions, which address the code changes: • Revision #139: http://code.google.com/p/datadistrib4j/source/detail?r=139 • Revision #151: http://code.google.com/p/datadistrib4j/source/detail?r=151 • Revision #166: http://code.google.com/p/datadistrib4j/source/detail?r=166 In the specification document, replace all occurrences of “getBootstrap” with “getEnvironment” and “Bootstrap” with “ServiceEnvironment”. These occurrences are in these sections: • 7.1.4, “Concurrency and Reentrancy” • 7.2.1, “ServiceEnvironment Class” (previously “Bootstrap Class”) • 7.3.1, “DomainParticipantFactory Interface” • 7.7.1.1, “DynamicTypeFactory Interface” At the end of section 7.2.1, “ServiceEnvironment Class” (previously “Bootstrap Class”), add the following paragraphs: Design Rationale (non-normative) This class is designed to avoid the brittle mixing of concrete implementation with abstract specification that would occur if either the specification mandated implementation or if vendors re-implemented different classes with the “same” names. In addition, it is designed to enable the following deployment scenarios: • Standalone deployment of a single application using one or more DDS implementations. (The expected use case for multiple implementations is a DDS-to-DDS bridge.) • Deployment within a Java EE or OSGi container, which may host multiple independent applications. More than one of application may use DDS internally, unknown to other applications. Each of these should be able to declare, “I depend on DDS” and allow the platform’s administrator to inject the implementation. The requirements above preclude a DDS vendor from reimplementing any OMG-provided type, and they preclude OMG-provided types from keeping any static or thread-local state. Resolution: The task force feels that this issue requires further discussion before it can be resolved. (It was filed after the comment deadline.) It is therefore deferred. Disposition: Deferred End of Annotations:===== m: Angelo Corsaro Subject: [DDS-PSM-JAVA ISSUE]: Getting rid of the Bootstrap Object Date: Wed, 7 Sep 2011 18:53:18 +0200 Cc: Juergen Boldt To: dds-psm-java-ftf@omg.org, issues@omg.org X-Mailer: Apple Mail (2.1084) [Name] Angelo Corsaro [Employer] PrismTech [eMail] angelo@icorsaro.net [Specification] DDS PSM for Java5 (DDS-PSM-Java) [Version] Beta 1 [Title] Getting rid of the Bootstrap object [Nature] Architectural [Severity] Critical [Description] The boostrap class is a pain for users which is in place only to allow users to run 2 different DDS implementations on the same application. The introduction of the Bootstrap object makes it impossible to use natural constructors for creating DDS types, even for types such as Time and Duration. As one of the main goal of the new DDS PSM was to simplify the user experience and make the API as simple and natural as possible, it seems that the introduction of the Bootstrap object goes exactly on the opposite direction -- all of this to be able to cover the case in which a user wants 2 different DDS implementation on the same application. Considering the wire-protocol interoperability this use case seems marginal and perhaps does not even count for 1% of DDS uses. [Resolution] The bootstrap should be removed and the resulting API should be simplified. -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 ------------------------------------------------------------------------------------------------------------------ http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro ------------------------------------------------------------------------------------------------------------------ From: Richard Warren To: Angelo Corsaro CC: "dds-psm-java-ftf@omg.org" Date: Mon, 12 Sep 2011 13:13:32 -0700 Subject: Re: issue 16531 -- Java 5 Language PSM for DDS 1.0 FTF issue Thread-Topic: issue 16531 -- Java 5 Language PSM for DDS 1.0 FTF issue Thread-Index: AcxxiHIQl3/SE3mhQ7Gwky1td4r3Rg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p8CKDXk7030732 Hi Angelo, I strongly disagree with this issue. Run-time portability is a basic requirement. And without the Bootstrap class, there is no way to provide it without having every DDS vendor implement fundamentally different classes with the same namespace and the same operations. Such an approach is very brittle and runs contrary to every Java library I can think of. You don't use the JDBC or JMS libraries from your vendor and hope that they're compatible with another vendor's. Instead, you use the ones provided by the body that specifies those interfaces. The implementations plug in underneath. This "SPI" pattern is used extensively in the JDK, and the Java PSM for DDS uses the same pattern. Allowing multiple DDS implementations to coexist in the same JVM is a second reason for the current design, not the only reason. And it is a real use case; I have seen it with DDS, and I have seen it with JMS, which also provides this capability. Regards, - Rick -- Rick Warren Director of Technology Solutions RTI Tel 626.584.0141 rick.warren@rti.com www.rti.com RTI - The Global Leader in DDS On Sep 7, 2011, at 11:43 AM, Juergen Boldt wrote: > >> From: Angelo Corsaro >> Subject: [DDS-PSM-JAVA ISSUE]: Getting rid of the Bootstrap Object >> Date: Wed, 7 Sep 2011 18:53:18 +0200 >> Cc: Juergen Boldt >> To: dds-psm-java-ftf@omg.org, issues@omg.org >> X-Mailer: Apple Mail (2.1084) >> >> [Name]Angelo Corsaro >> [Employer]PrismTech >> [eMail]angelo@icorsaro.net >> [Specification]DDS PSM for Java5 (DDS-PSM-Java) >> [Version] Beta 1 >> >> [Title]Getting rid of the Bootstrap object >> [Nature]Architectural >> [Severity]Critical >> >> [Description] >> The boostrap class is a pain for users which is in place only to allow >> users to run 2 different DDS implementations on the same application. >> The introduction of the Bootstrap object makes it impossible to use >> natural constructors for creating DDS types, even for types such as >> Time and Duration. >> As one of the main goal of the new DDS PSM was to simplify the >> user experience and make the API as simple and natural as possible, >> it seems that the introduction of the Bootstrap object goes exactly >> on the opposite direction -- all of this to be able to cover the case >> in which a user wants 2 different DDS implementation on the same >> application. Considering the wire-protocol interoperability >> this use case seems marginal and perhaps does not even count for 1% of >> DDS uses. >> >> [Resolution] >> The bootstrap should be removed and the resulting API should be simplified. >> >> >> -- >> Angelo Corsaro, PhD >> Chief Technology Officer >> PrismTech >> 4 rue Angiboust | 91460 Marcoussis | France >> T +33 1 69 01 53 54 | M +33 6 42 30 75 65 >> ------------------------------------------------------------------------------------------------------------------ >> http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro >> ------------------------------------------------------------------------------------------------------------------ >> >> >> > > Juergen Boldt > Director, Member Services > 140 Kendrick Street, Building A Suite 300 > Needham, MA 02494 USA > > Tel: 781 444 0404 x 132 > fax: 781 444 0320 > > www.omg.org > > Subject: Re: issue 16531 -- Java 5 Language PSM for DDS 1.0 FTF issue From: Angelo Corsaro Date: Tue, 13 Sep 2011 00:14:16 +0200 Cc: "dds-psm-java-ftf@omg.org" To: Richard Warren X-Mailer: Apple Mail (2.1084) Hello Rick, The main issue I have is that the Bootstrap class pollutes the whole API. We could decide to hide the delegation to the implementation layer, but I am strongly convinced that the current API is really odd. Let's discuss this matter at the FTF during the next OMG meeting. Cheers, Angelo On 12 Sep, 2011, at 10:13 PM, Richard Warren wrote: Hi Angelo, I strongly disagree with this issue. Run-time portability is a basic requirement. And without the Bootstrap class, there is no way to provide it without having every DDS vendor implement fundamentally different classes with the same namespace and the same operations. Such an approach is very brittle and runs contrary to every Java library I can think of. You don't use the JDBC or JMS libraries from your vendor and hope that they're compatible with another vendor's. Instead, you use the ones provided by the body that specifies those interfaces. The implementations plug in underneath. This "SPI" pattern is used extensively in the JDK, and the Java PSM for DDS uses the same pattern. Allowing multiple DDS implementations to coexist in the same JVM is a second reason for the current design, not the only reason. And it is a real use case; I have seen it with DDS, and I have seen it with JMS, which also provides this capability. Regards, - Rick -- Rick Warren Director of Technology Solutions RTI Tel 626.584.0141 rick.warren@rti.com www.rti.com RTI - The Global Leader in DDS On Sep 7, 2011, at 11:43 AM, Juergen Boldt wrote: From: Angelo Corsaro Subject: [DDS-PSM-JAVA ISSUE]: Getting rid of the Bootstrap Object Date: Wed, 7 Sep 2011 18:53:18 +0200 Cc: Juergen Boldt To: dds-psm-java-ftf@omg.org, issues@omg.org X-Mailer: Apple Mail (2.1084) [Name]Angelo Corsaro [Employer]PrismTech [eMail]angelo@icorsaro.net [Specification]DDS PSM for Java5 (DDS-PSM-Java) [Version] Beta 1 [Title]Getting rid of the Bootstrap object [Nature]Architectural [Severity]Critical [Description] The boostrap class is a pain for users which is in place only to allow users to run 2 different DDS implementations on the same application. The introduction of the Bootstrap object makes it impossible to use natural constructors for creating DDS types, even for types such as Time and Duration. As one of the main goal of the new DDS PSM was to simplify the user experience and make the API as simple and natural as possible, it seems that the introduction of the Bootstrap object goes exactly on the opposite direction -- all of this to be able to cover the case in which a user wants 2 different DDS implementation on the same application. Considering the wire-protocol interoperability this use case seems marginal and perhaps does not even count for 1% of DDS uses. [Resolution] The bootstrap should be removed and the resulting API should be simplified. -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 ------------------------------------------------------------------------------------------------------------------ http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro ------------------------------------------------------------------------------------------------------------------ Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 ------------------------------------------------------------------------------------------------------------------ http://icorsaro.net | http://twitter.com/acorsaro | http://slideshare.net/angelo.corsaro ------------------------------------------------------------------------------------------------------------------