Issue 6435: MonolithicImplementationDescription Attributes (deployment-ftf) Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com) Nature: Uncategorized Issue Severity: Summary: 6.4.14 MonolithicImplementationDescription This description should have additional well-defined optional attributes such as entry point name, stack size, and process priority. Keep these elements separate from execParameters. ExecParameters should be parameters that are passed to the main process or entry point and used by the entry point or main process implementation. These should be defined at the PIM level. Resolution: Revised Text: In section 6.4.15.1: Replace the sentence: The author of the implementation may associate some execution parameter properties with the implementation as hints to the target environment about the instantiation of the component (e.g., search path settings, environment variables). Some execution parameters may also relate to primary artifacts (e.g., entry points). Some execution parameters may also relate to primary artifacts (e.g., entry points). with: The author of the implementation may associate some execution parameters with the implementation to be provided to either the execution environment, in the nodeExecParameters list, or the primary artifact (e.g. entry point, business logic) in the componentExecParameters list. In section 6.4.15.3: Rename the execParameter association to be nodeExecParameter. Add this sentence to the description of the nodeExecParameter association: Parameters that are undefined and unknown should generate startLaunch exceptions. Add an association: componentExecParameter: Property[*] Execution parameters that are passed to the primary artifact (implementation code). Parameters that are undefined and unknown should generate startLaunch exceptions. In section 6.9.4.2: Add this sentence to the description of the startLaunch operation: Raises the InvalidNodeExecParameter exception if a parameter in the nodeExecParameter list is not valid for the execution environment. Raises the InvalidComponentExecParameter in the componentExecParameter list is not valid for the primary artifact (implementation code). In section 6.11, add both the above exceptions, inherited from InvalidProperty, with no extra attributes, to allow code to easily distinguish between the three potential parameter errors: configuration property (implementation independent), node execution parameter (possibly specific to the type of execution environment), component execution parameter (possibly specific to the particular implementation). InvalidNodeExecParamater is raised when instantiating a component when one of the supplied parameters is invalid for the execution environment. InvalidComponentExecParameter is raised when instantiating a component when one of the supplied parameters is invalid for the implementation code. Actions taken: November 5, 2003: received issue May 9, 2005: closed issue Discussion: Resolution: The resolution for this issue defines a separate parameter list for the implementation code in addition to the execution parameter list. Whilst the execution parameter list is intended for the node's execution environment, the new parameter list is passed to the component implementation while bootstrapping the component's implementation code. However, it is still unclear which execution parameters associated with a MonolithicImplementationDescription are intended for the execution environment (node) and which are in fact intended for the component implementation itself. This requires all execution parameters to be made available to both, with a reduction in error checking since neither the execution environment (node, container) nor the implementation can know whether parameters it doesn't understand are relevant to it. Thus no errors can be discovered when parameter names are incorrect. 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 1) MonolithicImplementationDescription Attributes 6.4.14 MonolithicImplementationDescription This description should have additional well-defined optional attributes such as entry point name, stack size, and process priority. Keep these elements separate from execParameters. ExecParameters should be parameters that are passed to the main process or entry point and used by the entry point or main process implementation. These should be defined at the PIM level. Date: Mon, 09 Aug 2004 09:20:39 -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.7) Gecko/20040616 X-Accept-Language: en,pdf To: Andreas Hoffmann Cc: Deployment RTF Subject: One of my RTF issue list homework: issue 6435 - separate lists of execution parameters X-Virus-Scanned: by Clam AntiVirus (Note that the issues 6435 and 6436 are somewhat intertwined. However, 6435 is primarily about having a separate list of parameters, and 6436 is more about specifically defining well known parameters. But 6435 mentions some example well-known parameters. The current RTF issues summary document (word doc) has this reversed. Thus I will define issue 6435 here as the one about separate parameter lists, and leave 6436 as the one for the well-known parameters such as name service contexts and stack size etc. Note that well-known parameters will need to be defined as to which parameter list they belong on). Proposed solution to issue 6435: separate parameter lists for execution environment and implementation code. Problem statement: It is unclear which execution parameters associated with a MonolithicImplementationDescription are intended for the execution environment (node) and which are in fact intended for the component implementation itself. This requires all execution parameters to be made available to both, with a reduction in error checking since neither the execution environment (node, container) nor the implementation can know whether parameters it doesn't understand are relevant to it. Thus no errors can be discovered when parameter names are incorrect. Proposed Solution: Replace the current list with two lists, and define exceptions that make it clear where any errors came from. In section 6.4.15.1: Replace the sentence: The author of the implementation may associate some execution parameter properties with the implementation as hints to the target environment about the instantiation of the component (e.g., search path settings, environment variables). Some execution parameters may also relate to primary artifacts (e.g., entry points). Some execution parameters may also relate to primary artifacts (e.g., entry points). with: The author of the implementation may associate some execution parameters with the implementation to be provided to either the execution environment, in the nodeExecParameters list, or the primary artifact (e.g. entry point, business logic) in the componentExecParameters list. In section 6.4.15.3: Rename the execParameter association to be nodeExecParameter. Add this sentence to the description of the nodeExecParameter association: Parameters that are undefined and unknown should generate startLaunch exceptions. Add an association: componentExecParameter: Property[*] Execution parameters that are passed to the primary artifact (implementation code). Parameters that are undefined and unknown should generate startLaunch exceptions. In section 6.9.4.2: Add this sentence to the description of the startLaunch operation: Raises the InvalidNodeExecParameter exception if a parameter in the nodeExecParameter list is not valid for the execution environment. Raises the InvalidComponentExecParameter in the componentExecParameter list is not valid for the primary artifact (implementation code). In section 6.11, add both the above exceptions, inherited from InvalidProperty, with no extra attributes, to allow code to easily distinguish between the three potential parameter errors: configuration property (implementation independent), node execution parameter (possibly specific to the type of execution environment), component execution parameter (possibly specific to the particular implementation). InvalidNodeExecParamater is raised when instantiating a component when one of the supplied parameters is invalid for the execution environment. InvalidComponentExecParameter is raised when instantiating a component when one of the supplied parameters is invalid for the implementation code.