Figure SO.08 - Service Specifications and other Domains

The Product guide book refers to the concept of a ProductSpecification. <br/>As a reminder, ProductOfferings provide tangible or intangible Products that organizations, such as Service Providers and Enterprises, market, sell or lease to Customers. <br/>A ProductSpecification is a detailed description of a tangible or intangible object made available externally in the form of a ProductOffering to Customers or other Parties playing a particular PartyRole. The information described by a ProductSpecification is a set of invariant data that is common to all realizations of that ProductSpecification. A ProductSpecification may exist as a single ProductSpecification, or consist of a set of ProductSpecifications supplied together as a collection.<br/><br/><i>Note that a direct association between Product and Service does not exist. Instead, the ProductSpecRealizedAsCFSSpec association is defined between ProductSpecification and CustomerFacingServiceSpec.</i><br/>Remember that the purpose of a Specification is to serve as a template. This enables specific instances of a desired entity to be more easily and consistently created. <br/>The ProductSpecRealizedAsCFSSpec association enables a given ProductSpecification to specify CustomerFacingServiceSpecs restricted by the ProductSpecification. This relationship is only used when the ProductSpecification corresponds to intangible goods.<br/>Note in particular that there is no association defined between a ProductSpecification and a ServiceSpecification. This is because such an association would include ResourceFacingServiceSpecs, and that violates the effort to separate CustomerFacingServices from ResourceFacingServices. Thus, the ProductSpecRealizedAsCFSSpec is defined to enforce this separation.<br/>The ProductSpecRealizedAs association enables a ProductSpecification to define zero or more ResourceSpecifications. This is analogous to the ProductSpecRealizedAsCFSSpec association for ProductSpecification corresponding to tangible goods.<br/>The ProductSpecRealizedAsCFSSpec and ProductSpecRealizedAs relationships are mutualy exclusives.<br/><br/>A Service may depend on one or more specific PhysicalResources. For example, the Customer connects to the VPN through a PhysicalPort on a Card of a PhysicalDevice. This is represented using the RFServiceConfiguredUsing association, whose purpose is to bind Resources to Services without identifying what type of Service or Resource is being bound. <br/>For example, this enables services to be “reserved” on a PhysicalResource for resource planning and consumption purposes, without specifically identifying the low-level system resources required.<br/>The above discussion has been conducted in terms of “instances” of these objects. For the most part we will talk about these concepts more generically using the concept of a “specification”.<br/><br/>A ResourceSpecification can classify a set of Resources using the SpecifiesResource association, so its subclasses, PhysicalResourceSpec, LogicalResourceSpec and CompoundResourceSpec, inherit this association. <br/>A Product is realized by zero or more CustomerFacingServices through the ProductRealizedAsCFService association. This enables a Product to in effect customize a CustomerFacingService already defined by a CustomerFacingServiceSpec. In other words, the ProductSpecRealizedAsCFSSpec association is used to define the set of CustomerFacingServiceSpecs for a given ProductSpecification, which means that all Products based off of that ProductSpecification will use that set of CustomerFacingServiceSpecs. Different Products have the ability to add their own features to these CustomerFacingServices, and do so through the ProductRealizedAsCFService association.<br/>Similarly, a Product realizes zero or more Resources through the ProductRealizedAsResource association. Note that the cardinality on the Product side of both of these associations is optional, which means that a Product doesn’t have to implement these two associations. This is because not all Products are realized through CustomerFacingServices and Resources.<br/>CustomerFacingServices cannot be implemented without ResourceFacingServices to support them. This is reflected by the CFServiceRequiresRFServices association. This relationship is templatized by the RequiresResourceFacingServiceSpec association, which defines the set of ResourceFacingServiceSpecifications that are required by a particular CustomerFacingServiceSpecification. Again, note that the cardinality on the ResourceFacingServiceSpec side is 1,*, meaning that a CustomerFacingServiceSpec cannot be instantiated unless it is bound to at least one ResourceFacingServiceSpec.<br/>