Issue 6436: MonolithicImplementationDescription Execute Parameters PSM (deployment-ftf) Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com) Nature: Uncategorized Issue Severity: Summary: Add another subsection to 9.7 miscellaneous and call it Execute Parameters The specification should make a recommendation and state some well-defined execparameters that are passed to a process or entry when a component is manifest by a process. The deployment machinery needs to be able to obtain the object reference for this component. The execparameters that need to be specified are: 1. NamingContext of where the component's object reference is to be placed. 2. Naming Service IOR to be used for this registration 3. Component instance identifier Resolution: Revised Text: Actions taken: November 5, 2003: received issue Discussion: During the RTF meetings and telephone conferences the RTF agreed that a concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF. End of Annotations:===== ubject: Deployment & Configuration issues To: issues@omg.org Cc: deployment-ftf@omg.org, swradio@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Wed, 5 Nov 2003 08:10:10 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 11/05/2003 08:10:11 AM X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id hA5D5qAq003931 Technical Issues 2) MonolithicImplementationDescription Execute Parameters PSM Add another subsection to 9.7 miscellaneous and call it Execute Parameters The specification should make a recommendation and state some well-defined execparameters that are passed to a process or entry when a component is manifest by a process. The deployment machinery needs to be able to obtain the object reference for this component. The execparameters that need to be specified are: 1. NamingContext of where the component's object reference is to be placed. 2. Naming Service IOR to be used for this registration 3. Component instance identifier Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax Date: Tue, 06 Apr 2004 23:21:45 -0400 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: Andreas Hoffmann CC: Deployment FTF Subject: Re: Deployment FTF work assignments - issue 6436 Andreas Hoffmann wrote: Hi FTF members, I tried to collect the currently open work assignments for resolving open FTF issues: - issue 6040 and 6043: assigned to Francis - issue 6266: assigned to Manfred - issue 5969: assigned to Jim - issue 6265, 6269, 6435, 6599 further explanation needed from Jerry - issue 6436: Jim is asked to raise an issue about an improved interface covering a solution for this issue This issue states that the "The deployment machinery needs to be able to obtain the object reference for this component", and then suggests this be accomplished by requiring the component to register itself with the name service. The centralized deployment system (the ApplicationManager object created by the ExecutionManager), receives the port object references it needs, as output arguments to the startLaunch operation on the NodeApplicationManager class, in order to make the necessary internode connections, which may include references at the top level by the applications external provider ports. Thus the deployment system already has all the required references. However the NodeApplicationManager is responsible for creating and destroying local component instances and there is indeed no specified way for the component implementation (artifact) to communicate the reference to the NodeApplicationManager. Such a mechanism was proposed as non-normative context in the adopted solution to issue 6047, namely: The function returned by the "entry point" of the implementation artifact conforms to the following local IDL to provide portability of implementations. This interface povides the implementation with resources allocated to it as well as providing the caller with the reference to the actual component instance.: // Base class used by all artifacts whether "primary" or not. local interface ImplementationArtifact { void initialize(// from ImplementationArtifactDescription: execParams in Strings execParams, // from ArtificatDeploymentDescription: deployedResources in ResourceDeploymentDescriptions artifactResources // from plan ); } // Class implemented by primary artifacts (constructors). local interface PrimaryImplementationArtifact : ImplementationArtifact { Object create(// from ComponentInterfaceDescription: specificType in String interfaceName, // from MonolithicImplementationDescription: execParams in Strings execParams, // from various in Properties configProperties, // from InstanceDeploymentDescription: deployedResources in InstanceResourceDeploymentDescriptions instanceResources // for each resource with kind ResourceUsesInstance out Objects providedReferences ); void destroy(in Object); ); Thus with these artifacts with entry points, the object references are clearly provided by the constructor of the component instance, with no overhead (code size or latency) or infrastructure requirements to register components with any external service. The startLaunch operation requires no internode communication to instantiate all component instances required for the application on that node. Note: component implementations that are actually executables (as opposed to libraries) can be easily created by using a generic "launcher" which communicates with the executable to implement the constructor interface. As in CCM, there is no need to formalize such implementations, but one way they might work is to use a centralized name service. Another might be a simple shared memory object between parent and child process. Thus the proposed solution to this issue is to plug the basic "missing link" with this entry point definition. - issue 6597: assigned to Jim (modifying the interface between nodes and target manager) (This issue is a larger issue that is still a work in progress for the next concall or meeting). Jim - issue 6598: assigned to all, David and Jerry are encouraged to provide further details of the problem I'd like to ask all to think about the open issues. In particular, it would be nice of those who had accepted work assignments could prepare a solution outline for the upcoming telecon at next Wednesday. Thanks in advance. Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ====================================================================