<concept xml:lang="en" id="GUID-75132B6C-2305-57B1-B969-B4F639B29852"><title>What are Factories and Factory Containers</title><shortdesc>This section describes Factories and Factory Containers in the Communications Architecture. Factories create Nodes. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>The Communications Framework uses <i>Factories</i> to create Nodes. Each type of Node has a Factory that is specific to that Node. A Factory is an instance of a class and is implemented as an ECOM plug-in. The plug-in DLL can contain a number of factories. The implementation of a Factory as an ECOM plug-in allows device creators to add new Factories to the Communications Framework. </p> <p>The Communications Framework creates containers for Factory objects called <i>Factory Containers</i>. The Communications Framework uses Factory Containers to create and store Factory objects. Each type of Node has a Factory Container that is specific to that Node.When the Communications Framework receives the first request to create a Node of a given type the Factory Container creates that Factory first. The Factory exists in the same thread as the Factory Container and is available to create more Nodes. When a thread terminates, the Factory Container closes the Nodes created by the Factories managed by that Factory Container. </p> <p>Factory Containers are Nodes and have the same behaviour as Nodes. Factory Containers can manage creation requests from other Nodes. Note that there is no Factopry to create a Factory Container. </p> <p>A Node can ask the Communications Framework to create a new Node. A Node gets the UID that identifies the required type of Node from the <xref href="GUID-BD971173-E009-58DA-AF9C-F4AAFF77B138.dita">Comms Database</xref>. A Node asks the Communications Framework to return the correct Factory Container. The Node then asks that Factory Container to supply the Factory that can create the required type of Node. </p> <p>The implementation of the Communications Framework provides a Factory Container for each type of Node in each <xref href="GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita">Plane</xref> in each thread. For example, if the Communications Framework uses two threads to implement the Control Plane, then the Communications Framework creates two Factory Containers for <xref href="GUID-CF890168-0FCA-5BFD-AC86-E355B611A6B0.dita#GUID-CF890168-0FCA-5BFD-AC86-E355B611A6B0/GUID-0B0B61DE-AABC-5F87-8205-30F818F79C0A">Connection Provider (CPR) Nodes</xref> and two Factory Containers for <xref href="GUID-CF890168-0FCA-5BFD-AC86-E355B611A6B0.dita#GUID-CF890168-0FCA-5BFD-AC86-E355B611A6B0/GUID-0B0B61DE-AABC-5F87-8205-30F818F79C0A">SubConnection Provider (SCPR) Nodes</xref>. Code in a thread can make a call to a static function to access a Factory Container. The Communications Framework makes sure that Factory Containers are available in a thread. After a Node is created, the thread ID forms part of the Node ID. </p> <p>Tools and applications do not create or destroy Factory Containers. </p> </conbody><related-links><link href="GUID-E3E4E9A1-359E-5475-A355-1DA446FE7170.dita"><linktext>Nodes</linktext> </link> </related-links></concept>