ResourceFacingService

ResourceFacingService : public abstract class

Created:	3/12/2005 12:00:00 AM
Modified:	11/22/2006 7:31:04 AM

Project:
Author:	AutoMagic KB LLC
Version:	6.2
Phase:	SID
Status:	Approved
Complexity:	Medium
Advanced:
UUID:	{AEF8862F-422B-484b-A4F5-49B7B0CE969E}
Appears In:	ManagedEntity Generalization Tree, Service Generalization Tree, Figure Pr.02 - Product, Service, Resource Domain Relationships, Product-Service-Resource Relationships, Product-ServicePackage-ServiceBundle-QoS, CFS and RFS Summary, NetworkForwardingService Diagram, ProductSpec-ServiceSpec-ResourceSpec, QoS Entities Summary, QoS-Package-Bundle, Service Class Diagram, Service-Location Summary, Service-PhysicalResource Interaction, QoS Summary, Service-Resource-Product Summary, ServiceBundle and ServicePackage, ServiceBundle-QoS, ServiceSpec-PhysicalSpec Interaction, Simple Service-Spec Diagram, Simplified Service Class Diagram, Fig 4SO-06 - High Level Product-Service-Resource, Fig 4SO-07, Fig 4SO-08 - ServiceSpec, Fig 4SO-09, Fig 4SO-10 - ServiceSpec subclasses, Fig 4SO-12 - CFS and RFS, Fig 4SO-20 - ServiceRoles, Fig 4SO-29 - ServiceBundle, Fig 4SO-30 - ServicePackage and ServiceBundle, Fig 4SO-41 - CFS and RFS Biz Model, Fig 4SO-42 - CFS-RFS Atomic-Composite Biz Models, Fig 4SO-43 - ServiceSpec Biz Model, Fig 4SO-47 - ServiceRole Biz Model, Fig 4Q-20 - QoSService, Fig 4Q-27 - QoSService Biz Model, Service Trouble Info, Resource-Service-PartyRole, Fig 5LR-08 - Service concept, Fig 5LR-09 - Product - Resource - Service, Fig 5LR-26 - DeviceInterface Overview, Fig 5LR-28 - DeviceInterface RFSs, Fig 5LR-31 - Protocol Interactions, Fig 5LR-57 - ProductSpec-ResourceSpec Interaction, Fig 5LR-67 - DeviceInterface Biz Model, DeviceInterface starting diagram, Resource Trouble Info, AMKB-BusinessInteraction, Fig 39 - Service Overview, Fig 40 - Contracts and Services, Fig 41 - Contracts and Products-Resources-Services, Service Inventory Layout

Copyright TM Forum 2005 This is the base class for defining ResourceFacingServices in the Service model. A ResourceFacingService is an abstraction that defines the characteristics and behavior of a particular Service that is not directly seen or purchased by the Customer. ResourceFacingServices are "internal" Services that are required to support a CustomerFacingService. The Customer purchases CustomerFacingServices, and is not aware of the ResourceFacingServices which support the CustomerFacingService(s) that is being purchased directly by the Customer. For example, a VPN is an example of a CustomerFacingService. This particular type of VPN may require BGP to support it. Customers don't purchase BGP, and hopefully aren't even aware that BGP is running. Therefore, BGP is an example of a ResourceFacingService.

Attributes
Associations To
Associations From
Other Links

Attribute

Details

public Integer
rfsStatus

Notes:

This is an enumerated integer that defines the status of this particular ResourceFacingService. Values include: 0: Operational and supporting CFS 1: Degraded but supporting CFS 2: In Violation and not supporting CFS 3: Operational but not yet supporting a CFS 4: Being Tested 5: Being Deployed 6: Failed Value 0 means that this ResourceFacingService is acting per specification, and is also currently supporting one or more CustomerFacingServices. Value 1 means that this ResourceFacingService is operational, but is currently in a degraded state. This degraded state indicates congestion or some other problem, but has not yet comprimised the operation of its associated CustomerFacingServices. Value 2 means that this ResourceFacingService is operational, but is currently in violation of its associated specification(s). This in turn means that its associated CustomerFacingServices are violating their contractual specification(s) unless automatic fail-over has been enabled. Value 3 means that this ResourceFacingService is acting per specification, but is not yet currently supporting one or more CustomerFacingServices. Value 4 means that this ResourceFacingService is currently being tested, and is not yet ready to support a CustomerFacingService. Value 5 means that this ResourceFacingService is currently being deployed, and is not yet ready to support a CustomerFacingService. Value 6 means that this ResourceFacingService has currently failed. The set of actions that should be taken, as well as whether this service can still be billed or not, are determined by its associated Policy for handling service violations.

Element	Source Role	Target Role	Details
ResourceFacingServiceSpec Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of ResourceFacingServices that can be defined from a particular ResourceFacingServiceSpecification. Bundled sets of ResourceFacingServices can be built by combining multiple ResourceFacingServiceSpecifications. This enables the ResourceFacingServiceSpecification to define the invariant attributes, methods, relationships, and constraints of a ResourceFacingService, and the ResourceFacingService to define different variations of the Service that are all built off of the same ResourceFacingServiceSpecification.<br/></p>
DeviceInterface Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the particular set of ResourceFacingServices that a DeviceInterface is currently supporting. The semantics of supporting a particular ResourceFacingService are captured by the ServiceDeviceInterfaceDetails aggregation class.<br/></p>
ResourceFacingServiceComposite Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of ResourceFacingServices that form a part of a ResourceFacingServiceComposite, such as a QoSService or a stand-alone ResourceFacingServiceAtomic object, such as a particular type of NetworkForwardingService.<br/></p>
CustomerFacingService Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This defines the set of ResourceFacingServices that are required for a particular CustomerFacingService to operate correctly.<br/></p><p><br/></p><p>Note that the cardinality of the CFServiceRequiresRFServices is 0..n on the CustomerFacingService (aggregate) side and 1..n on the ResourceFacingService (component) side. This is because a ResourceFacingService can exist without being bound into a CustomerFacingService (e.g., in testing the network), but a CustomerFacingService requires at least one ResourceFacingService to function.<br/></p>

Element	Source Role	Target Role	Details
PhysicalResource Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of PhysicalResources that are required for this particular ResourceFacingService to function correctly. This includes as a minimum the set of PhysicalResources that are required to host this particular ResourceFacingService.<br/></p><p><br/></p><p>The PhysicalResourcesHostRFS aggregation describes a hosting relationship, which is essentially passive in nature - the PhysicalResource exists so that the LogicalResource can be hosted on it.<br/></p><p><br/></p><p>The cardinality of the LogicalResourcesImplementRFS and PhysicalResourcesHostRFS aggregations are both 0..1 on the aggregate side, because PhysicalResources can be installed which use LogicalResources before a ResourceFacingService is actually implemented. However, a ResourceFacingService must have at least one PhysicalResource and one LogicalResource for it to be instantiated. Hence, both of the aggregations have a 1..n cardinality on their component ends.<br/></p>
LogicalResource Class	Name:	Name:	<p>Copyright TM Forum 2006<br/></p><p><br/></p><p>This aggregation defines the set of LogicalResources that are required for this particular ResourceFacingService to function correctly. <br/></p><p><br/></p><p>The LogicalResourcesImplementRFS aggregation is active in nature - it signifies an active whole-part relationship between a set of LogicalResources and a ResourceFacingService. Put another way, this latter aggregation is used to identify the LogicalResources that are used so that a ResourceFacingService can function. <br/></p><p><br/></p><p>The cardinality of the LogicalResourcesImplementRFS aggregation is 0..n on the aggregate side, because PhysicalResources can be installed which use LogicalResources before a ResourceFacingService is actually implemented. AResourceFacingService can have zero or more PhysicalResources and LogicalResources for it to be instantiated. Hence, the aggregations has a 1..n cardinality on its component end.<br/></p>
Protocol Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of Protocols that are required by a particular ResourceFacingService. The semantics associated with how a given Protocol is used by a particular ResourceFacingService is defined by the ProtocolServiceDetails aggregation class.<br/></p>
ResourceFacingServiceRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of ResourceFacing ServiceRoles that a particular ResourceFacingService has. This enables the ResourceFacingService to be defined abstractly using Roles instead of specific Services.<br/></p>
CompoundResource Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of CompoundResources that are required for this particular ResourceFacingService to function correctly. <br/></p><p><br/></p><p>The CompoundResourcesImplementRFS aggregation is active in nature - it signifies an active whole-part relationship between a set of CompoundResources and a ResourceFacingService. Put another way, this latter aggregation is used to identify the CompoundResources that are used so that a ResourceFacingService can function. <br/></p><p><br/></p><p>Note that a CompoundResource, by definition, contains at least one or more PhysicalResources and at least one or more LogicalResources. Hence, this relationship defines the set of PhysicalResources and LogicalResources that together are required for a ResourceFacingService to function correctly. <br/></p><p><br/></p><p>The cardinality of the CompoundResourcesImplementRFS aggregation is 0..1 on the aggregate side, because PhysicalResources (which are part of a CompoundResource) can be installed which use LogicalResources (which are part of a CompoundResource) before a ResourceFacingService is actually implemented. <br/></p><p>However, a ResourceFacingService must have at least one PhysicalResource and one LogicalResource for it to be instantiated (which is why this aggregation exists, since the CompoundResource aggregates the required PhysicalResources and LogicalResources for this ResourceFacingService).<br/></p>

Object	Type	Connection	Notes
PhysicalResource	Class	Class	Copyright TM Forum 2005 This aggregation defines the set of PhysicalResources that are required for this particular ResourceFacingService to function correctly. This includes as a minimum the set of PhysicalResources that are required to host this particular ResourceFacingService. The PhysicalResourcesHostRFS aggregation describes a hosting relationship, which is essentially passive in nature - the PhysicalResource exists so that the LogicalResource can be hosted on it. The cardinality of the LogicalResourcesImplementRFS and PhysicalResourcesHostRFS aggregations are both 0..1 on the aggregate side, because PhysicalResources can be installed which use LogicalResources before a ResourceFacingService is actually implemented. However, a ResourceFacingService must have at least one PhysicalResource and one LogicalResource for it to be instantiated. Hence, both of the aggregations have a 1..n cardinality on their component ends.
LogicalResource	Class	Class	Copyright TM Forum 2006 This aggregation defines the set of LogicalResources that are required for this particular ResourceFacingService to function correctly. The LogicalResourcesImplementRFS aggregation is active in nature - it signifies an active whole-part relationship between a set of LogicalResources and a ResourceFacingService. Put another way, this latter aggregation is used to identify the LogicalResources that are used so that a ResourceFacingService can function. The cardinality of the LogicalResourcesImplementRFS aggregation is 0..n on the aggregate side, because PhysicalResources can be installed which use LogicalResources before a ResourceFacingService is actually implemented. AResourceFacingService can have zero or more PhysicalResources and LogicalResources for it to be instantiated. Hence, the aggregations has a 1..n cardinality on its component end.
Protocol	Class	Class	Copyright TM Forum 2005 This aggregation defines the set of Protocols that are required by a particular ResourceFacingService. The semantics associated with how a given Protocol is used by a particular ResourceFacingService is defined by the ProtocolServiceDetails aggregation class.
ResourceFacingServiceRole	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of ResourceFacing ServiceRoles that a particular ResourceFacingService has. This enables the ResourceFacingService to be defined abstractly using Roles instead of specific Services.
CompoundResource	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of CompoundResources that are required for this particular ResourceFacingService to function correctly. The CompoundResourcesImplementRFS aggregation is active in nature - it signifies an active whole-part relationship between a set of CompoundResources and a ResourceFacingService. Put another way, this latter aggregation is used to identify the CompoundResources that are used so that a ResourceFacingService can function. Note that a CompoundResource, by definition, contains at least one or more PhysicalResources and at least one or more LogicalResources. Hence, this relationship defines the set of PhysicalResources and LogicalResources that together are required for a ResourceFacingService to function correctly. The cardinality of the CompoundResourcesImplementRFS aggregation is 0..1 on the aggregate side, because PhysicalResources (which are part of a CompoundResource) can be installed which use LogicalResources (which are part of a CompoundResource) before a ResourceFacingService is actually implemented. However, a ResourceFacingService must have at least one PhysicalResource and one LogicalResource for it to be instantiated (which is why this aggregation exists, since the CompoundResource aggregates the required PhysicalResources and LogicalResources for this ResourceFacingService).
ResourceFacingServiceSpec	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of ResourceFacingServices that can be defined from a particular ResourceFacingServiceSpecification. Bundled sets of ResourceFacingServices can be built by combining multiple ResourceFacingServiceSpecifications. This enables the ResourceFacingServiceSpecification to define the invariant attributes, methods, relationships, and constraints of a ResourceFacingService, and the ResourceFacingService to define different variations of the Service that are all built off of the same ResourceFacingServiceSpecification.
DeviceInterface	Class	Class	Copyright TM Forum 2005 This aggregation defines the particular set of ResourceFacingServices that a DeviceInterface is currently supporting. The semantics of supporting a particular ResourceFacingService are captured by the ServiceDeviceInterfaceDetails aggregation class.
ResourceFacingServiceComposite	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of ResourceFacingServices that form a part of a ResourceFacingServiceComposite, such as a QoSService or a stand-alone ResourceFacingServiceAtomic object, such as a particular type of NetworkForwardingService.
ResourceFacingServiceComposite	Class	Tree
Connectivity	Class	Generalization
ResourceFacingServiceAtomic	Class	Tree
CustomerFacingService	Class	Weak	Copyright TM Forum 2005 This defines the set of ResourceFacingServices that are required for a particular CustomerFacingService to operate correctly. Note that the cardinality of the CFServiceRequiresRFServices is 0..n on the CustomerFacingService (aggregate) side and 1..n on the ResourceFacingService (component) side. This is because a ResourceFacingService can exist without being bound into a CustomerFacingService (e.g., in testing the network), but a CustomerFacingService requires at least one ResourceFacingService to function.
Service	Class	Tree