Issue 6053: Alternative Locations (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: It should be possible to supply alternative URI locations for artifacts. Here's another issue that I'd like to put on record before it gets forgotten. It goes back to the discussion on HTTP. At the moment, NodeManagers are essentially forced to use HTTP for downloading artifacts from the Repository, since (a) that is the "least common denominator" as defined by the specification and (b) the Repository can offer only a single location. The proposed solution enables the RepositoryManger to supply multiple alternative locations for an artifact, one of which must be a HTTP URI. Other locations could use more optimal (including non-standard) transports that a NodeManager could use if supported. (Otherwise, the NodeManager would fall back to HTTP.) Proposed resolution: In section 6.3, "Model Diagram Conventions," change the text for the standard "location" attribute from location: references an entity outside of the model. The location attribute is of type String, its value must comply to the URI syntax. to location: references an entity outside of the model. The location attribute is of type String, its value(s) must comply to the URI syntax. Multiple alternative locations to the same entity may be supplied (multiplicity 1..*); applications can then choose any of these locations to access the entity (e.g. choosing a local file URI over a http reference). In section 6.4.15.2 (ImplementationArtifactDescription attributes), change the location attribute to location: String [1..*] Alternative locations to the ImplementationArtifact. In section 6.8.2.2 (ArtifactDeploymentDescription attributes), change the location attribute to location: String [1..*] Alternative locations where the artifact can be loaded from. Copied from Implementation- ArtifactDescription. In section 9.3.1 (ComponentInterfaceDescription), change the idlFile attribute from idlFile: String to idlFile: String [*] and change the second sentence from If it is not the empty string, it contains a URL that references an IDL file that contains the definition for this component or home. to The idlFile attribute, if present, contains alternative URIs that reference an IDL file containing the component's (or home's) interface definition. In section 9.7.5, change the fourth (last) paragraph from If a RepositoryManager supports URL schemes in addition to http, it shall offer a configuration parameter that allows user selection of the scheme(s) that will be used in ImplementationArtifactDescription elements. to The RepositoryManager must supply a "http" URI as part of the location attribute in the ImplementationArtifactDescription element. A RepositoryManager may optionally include other alternative locations to provide NodeManger implementations with a choice of transports to use for downloading artifacts. Resolution: Revised Text: Actions taken: August 27, 2003: received issue Discussion: End of Annotations:===== Subject: Alternative Locations Date: Wed, 27 Aug 2003 14:07:45 -0400 Thread-Topic: Alternative Locations Thread-Index: AcNsxh21KCpHkyusQdGzAVTa8gS6aQ== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h7RI79e4018299 It should be possible to supply alternative URI locations for artifacts. Here's another issue that I'd like to put on record before it gets forgotten. It goes back to the discussion on HTTP. At the moment, NodeManagers are essentially forced to use HTTP for downloading artifacts from the Repository, since (a) that is the "least common denominator" as defined by the specification and (b) the Repository can offer only a single location. The proposed solution enables the RepositoryManger to supply multiple alternative locations for an artifact, one of which must be a HTTP URI. Other locations could use more optimal (including non-standard) transports that a NodeManager could use if supported. (Otherwise, the NodeManager would fall back to HTTP.) Proposed resolution: In section 6.3, "Model Diagram Conventions," change the text for the standard "location" attribute from location: references an entity outside of the model. The location attribute is of type String, its value must comply to the URI syntax. to location: references an entity outside of the model. The location attribute is of type String, its value(s) must comply to the URI syntax. Multiple alternative locations to the same entity may be supplied (multiplicity 1..*); applications can then choose any of these locations to access the entity (e.g. choosing a local file URI over a http reference). In section 6.4.15.2 (ImplementationArtifactDescription attributes), change the location attribute to location: String [1..*] Alternative locations to the ImplementationArtifact. In section 6.8.2.2 (ArtifactDeploymentDescription attributes), change the location attribute to location: String [1..*] Alternative locations where the artifact can be loaded from. Copied from Implementation- ArtifactDescription. In section 9.3.1 (ComponentInterfaceDescription), change the idlFile attribute from idlFile: String to idlFile: String [*] and change the second sentence from If it is not the empty string, it contains a URL that references an IDL file that contains the definition for this component or home. to The idlFile attribute, if present, contains alternative URIs that reference an IDL file containing the component's (or home's) interface definition. In section 9.7.5, change the fourth (last) paragraph from If a RepositoryManager supports URL schemes in addition to http, it shall offer a configuration parameter that allows user selection of the scheme(s) that will be used in ImplementationArtifactDescription elements. to The RepositoryManager must supply a "http" URI as part of the location attribute in the ImplementationArtifactDescription element. A RepositoryManager may optionally include other alternative locations to provide NodeManger implementations Subject: Re: Deployment FTF voting (2nd poll), closing 6th Jan 2004 20:00 GMT To: Andreas Hoffmann Cc: Deployment FTF X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 29 Dec 2003 07:49:41 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 12/29/2003 07:46:50 AM Company: Raytheon Voter: Jerry Bickle OMG Issue No: 5967:Yes OMG Issue No: 6027:Yes OMG Issue No: 6045:Yes OMG Issue No: 6053:NO, It appears this change has to do with the use of the artifacts within the system/domain after installment. This appears to be getting into implementation details. OMG Issue No: 6268:Yes OMG Issue No: 6270:Yes OMG Issue No: 6382:Yes OMG Issue No: 6383:Yes OMG Issue No: 6384:Yes OMG Issue No: 6385:Yes OMG Issue No: 6386:Yes OMG Issue No: 6387:Yes OMG Issue No: 6388:Yes Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 Date: Sun, 04 Jan 2004 16:26:32 -0500 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5.1) Gecko/20031120 X-Accept-Language: en,pdf To: Gerald_L_Bickle@raytheon.com CC: Andreas Hoffmann , Deployment FTF Subject: Re: Deployment FTF voting (2nd poll), closing 6th Jan 2004 20:00 GMT Gerald_L_Bickle@raytheon.com wrote: Company: Raytheon Voter: Jerry Bickle OMG Issue No: 5967:Yes OMG Issue No: 6027:Yes OMG Issue No: 6045:Yes OMG Issue No: 6053:NO, It appears this change has to do with the use of the artifacts within the system/domain after installment. This appears to be getting into implementation details. The solution description is indeed pretty thin. To clarify, this is specifically about interoperability between code running on nodes (NodeManager) and the central deployment service (ExecutionManager). It simply provides for component developers, repository managers or planners to provide more than the single default, least-common-denominator, required http access path (URL scheme/protocol) to artifacts (DLLs, executables). This allows the node manager to operate more effectively if it sees something it likes better than http. It might also provide for some fault tolerance by providing more than one place to load from. All for three characters: [*]! This flows from the fact that we have 4 interoperable compliance points, and thus this communication is not "within the system", but rather between different compliant subsystems. OMG Issue No: 6268:Yes OMG Issue No: 6270:Yes OMG Issue No: 6382:Yes OMG Issue No: 6383:Yes OMG Issue No: 6384:Yes OMG Issue No: 6385:Yes OMG Issue No: 6386:Yes OMG Issue No: 6387:Yes OMG Issue No: 6388:Yes Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax with a choice of transports to use for downloading artifacts.