Master components promote component reuse. They provide an easy way to create new components by reusing existing component definitions and the underlying process definitions. Master components are components that can be created and managed independent of any application. A master component consists of a component definition and one or more component processes. Master components are then leveraged to create application components either by referencing or copying them.
You can use master components to create a library of standardized reusable components which can help to promote best practices across the enterprise (such as a standard WebSphere component, standard IIS component, and so on). When deployments have large numbers of similar components, this can be used to speed up application authoring by leveraging prebuilt component and component-process logic.
A component has two parts:
Component details describe the artifact on which the component is based. It can include where the artifacts are stored (the source or repository server), artifact name, artifact version, the directory where the artifact can be retrieved, and so on. You can parameterize part of the artifact definition to account for variations in the artifact details every time you deploy the application. This allows you to reuse the master component in multiple deployment scenarios. For example, you can create a master component that has a standard process to deploy and undeploy, and the only thing that changes is which specific artifact to use based on parameters.
Component processes are used to define the automation steps to perform on the artifact defined in the component details. These processes can be used to deploy, undeploy, or do any other action. Each master component can have one or more component processes, and each process can have specific automation steps. These steps can describe how to perform specific tasks such as publish or retrieve an artifact, stop a server process, copy files, restart the server, and so on. A master component must have at least one component process. You can parameterize the master component processes so that certain behaviors can be achieved when master components are used in an application definition. For example, you can have port number as a component process parameter for a master component, and have different values for the port number in different application models where this master component is used.
/myComponent property alias maps the master component definition. You can use the
/myReferenceComponent property alias to access the component that is based on a master component.
You can reference a master component when authoring an application. The new application component will have the same properties as the master component. Any changes made to the master component will affect all the application components that reference it.
Use the reference method when you want to maintain lineage with the master component so that the application component continues to inherit definitions from the master component. Before making a change to a master component, check how many applications reference it and determine the impact of changing it.
You can also copy a master component when authoring an application. The new application component will have the same properties as the master or existing application component when it is created.
Use the copy method when you want to use a master component just as a baseline for your application component. After an application component is created from a master component, any subsequent changes to the master component will not affect the application component. To get the latest changes in the application component, you delete and recreate the application component, and copy the latest master component to create a new application component.
You can also take an existing component that was originally copied from a master component, modify it, and then save it as a new master component that can be reused and shared by other users.