A ServicePackageSpec defines the concept of bundling a set of different CustomerFacingServiceSpecs to meet the functionality specified by one or more ProductSpecifications. This enables the common characteristics of these CustomerFacingServices to be specified, so that multiple Products can be built from their associated ProductSpecification.<br/>Treating this set of CustomerFacingServiceSpecs as a single object is very important for building complex Services, such as a VPN. This enables a single Product to be offered to the Customer (or another type of PartyRole), even though in reality the Product consists of a set of different CustomerFacingServices that must work together to provide the functionality that the Customer needs.<br/>The composite pattern is used to make the ServicePackageSpec object extensible. A ServicePackageSpecAtomic object models different ServicePackageSpecs as a set of different instances of individual, independent CustomerFacingServiceSpecs. This is fundamentally different than the ServicePackageSpecComposite object, which is used to model one ServicePackageSpec as the combination of other existing ServicePackageSpecs (as well as providing its own extensions).<br/><font color="#29313b">For example, GoldPackageSpec is an individual packaging of services, and is therefore an instance of the ServicePackageSpecAtomic class. If there was a service offering that combined the services defined by the GoldPackageSpec with those defined by the PlatinumPackageSpec, then that would be an instance of the ServicePackageSpecComposite class.</font><br/><font color="#29313b">Figure SO.25 shows five exemplary subclasses of the ServicePackageSpecAtomic class – PlatinumPackageSpec, GoldPackageSpec, SilverPackageSpec, BronzePackageSpec, and BestEffortPackageSpec. Ignoring the latter for the moment, each of these classes represents a collection of CustomerFacingServiceSpecs that work together to collectively offer a set of Services. This enables these Services to be compared as a group to (for example) a ServiceLevelAgreement.  Conceptually, this can be represented as shown in Figure SO.26. </font><br/>