Service

Service : public abstract class

Created:	3/12/2005 12:00:00 AM
Modified:	11/22/2006 7:30:02 AM

Project:
Author:	AutoMagic KB LLC
Version:	6.2
Phase:	SID
Status:	Approved
Complexity:	Medium
Advanced:
UUID:	{598CBDD4-8D20-46ef-B58E-3B4D7AC3D080}
Appears In:	ManagedEntity Generalization Tree, Service Generalization Tree, Figure Pr.02 - Product, Service, Resource Domain Relationships, Product-Service-Resource Relationships, Figure C.09 - Resource/Service Usage, 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, Service-Resource-Product Summary, ServiceRole Summary, ServiceSpec-PhysicalSpec Interaction, Simple Service-Spec Diagram, Simplified Service Class Diagram, Fig 4SO-06 - High Level Product-Service-Resource, Fig 4SO-08 - ServiceSpec, Fig 4SO-09, Fig 4SO-10 - ServiceSpec subclasses, Fig 4SO-12 - CFS and RFS, Fig 4SO-14 - ServiceSpecType, Fig 4SO-20 - ServiceRoles, Fig 4SO-22 - ServiceCharacteristic, Fig 4SO-23 - ServiceCharacteristic Values, Fig 4SO-31 - PartyRole - Service Interaction, Fig 4SO-32 - Service - Location, Fig 4SO-40 - Service Biz Model, 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, Figure SO.01 - Service Order Entities, Service Trouble Info, Resource-Service-PartyRole, Fig 5LR-08 - Service concept, Fig 5LR-09 - Product - Resource - Service, Fig 5LR-56 - PartyRole-LogicalResource, Fig 5PR-05 , Fig 5PR-04, Resource Trouble Info, Figure A.6 - Agreement Item Inherited Associations with Product, Service, and Resource, Fig 1P-30 - Policy Management Overview, AMKB-BusinessInteraction, Business Interaction Business Entities, Fig BI.09 - Business Interaction Items Association with Product, Service, and Resource Domain Entities, Fig BI.08 - Relationship Between Business Interaction and Product Domain Entities, Trouble Ticket Detail, Trouble Ticket, Fig 35 - DEN-ng Location, Fig 39 - Service Overview, Fig 40 - Contracts and Services, Fig 41 - Contracts and Products-Resources-Services, Service Inventory Layout

Copyright TM Forum 2005 This class is the base class for the Service hierarchy. A Service represents logical functionality that is packaged as part of a Product. Its two principal subclasses are CustomerFacingService and ResourceFacingService. A Service represents the object that will be instantiated. Each Service instance can be different; therefore, Service is limited to owning just the changeable attributes, methods, relationships, and constraints that can be instantiated. The invariant attributes, methods, relationships, and constraints that can be instantiated are defined by a ServiceSpecification. The purpose of this class is twofold. First, it is used to define attributes, methods, and relationships that are common to all Services. Second, it provides a convenient point to define how Services interact with other parts of the model.

Attributes
Operations
Associations To
Associations From
Other Links

Attribute

Details

public Boolean
isServiceEnabled

Initial: FALSE

Notes:

This is a Boolean attribute that, if TRUE, signifies that this Service has been enabled for use. If the value of this attribute is FALSE, then this means that this particular Service has NOT been enabled for use.

public Boolean
hasStarted

Notes:

This is a Boolean attribute that, if TRUE, signifies that this Service has already been started. If the value of this attribute is FALSE, then this signifies that this Service has NOT been Started.

public Boolean
isMandatory

Notes:

This is a Boolean attribute that, if TRUE, signifies that this Service is mandatory (i.e., this Service must be running when the managed environment is in a non-failed state). If the value of this attribute is FALSE, then this means that this Service is not required to run.

public Integer
startMode

Notes:

This attribute is an enumerated integer that indicates how the Service is started. Values include: 0: Unknown 1: Automatically by the managed environment 2: Automatically by the owning device 3: Manually by the Provider of the Service 4: Manually by a Customer of the Provider 5: Any of the above

public Boolean
isStateful

Notes:

This is a Boolean attribute that, if TRUE, means that this Service can be changed without affecting any other services.

public Integer
availabilityStatus

Notes:

This is an enumerated integer, and defines the current status of this Service Instance. Values include: 0: Unknown 1: Currently available for use 2: Currently unavailable for use

Operation

Details

public
pauseService():Integer

Sequential

public
resumeService():Integer

sequential

public
startService():Integer

sequential

public
stopService():Integer

sequential

Element	Source Role	Target Role	Details
ServiceSpecification Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of Services that can be defined from a particular ServiceSpecification. Bundled sets of Services can be built by combining multiple ServiceSpecifications. This enables the ServiceSpecification to define the invariant attributes, methods, relationships, and constraints of a Service, and the Service to define different variations of the Service that are all built off of the same ServiceSpecification.<br/></p>
Location Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the location(s) that a particular Service can be found at. Note that there can be multiple Locations assigned for a particular Service. Its semantics are defined by the ServiceLocationDetails association class. <br/></p><p><br/></p><p>Please see the DEN-ng Location model for more information.<br/></p>
ValueNetworkRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the set of Services (CustomerFacing and/or ResourceFacing) that a particular Party, playing the role of ValueNetworkRole, administers. From a business perspective, the Owner has to either appoint or give permission to the Administrator to administer the Service that is owned.<br/></p>
PhysicalResourceRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the set of PhysicalResources that a particular Service depends on in order for that Service to be realized. Any specific semantics required by this association are implemented in the ServicePRDependency associationClass.<br/></p><p><br/></p><p>Please see the DEN-ng Service model for more details.<br/></p>
LogicalResourceRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>The serviceRunBy association is used to define the LogicalResource that runs, or executes, a particular Service. There are many different types of LogicalResources. Some examples of a LogicalResource include a LogicalDevice, a (sub-)interface of a device, and a ManagedTransmissionEntity.<br/></p><p><br/></p><p>The multiplicity of the serviceRunBy relationship is zero or more to zero or more, which can be seen by the following simple example. Suppose we have a transit router that accepts traffic from one or more networks and sends traffic to one or more networks, and that a VPN is being carried across this router. One of the router interfaces will be assigned an ingressEdge role, and the other will be assigned an egressEdge role. Thus, the same VPN Service is applied to multiple LogicalResourceRoles. Similarly, if our VPN is a 2547bis-style VPN, then it will communicate with at least 4 routers of three different types - 1 CustomerEdge router, two ProviderEdge routers (ingress and egress of the Provider network), and at least one ProviderCore router. Similarly, the same device interface could host multiple services. For example, the simple act of starting a BGP session means that a TCP session must already be instantiated. Thus, a single device interface must be able to support two different services - TCP and BGP. Clearly, more complicated examples exist.<br/></p>
Device Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>ILLUSTRATIVE USE ONLY - do not use!<br/></p>

Element	Source Role	Target Role	Details
ServiceRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of externally visible (and programmable) roles that a particular Service has. This enables the Service to be managed abstractly using ServiceRoles. It also helps define the Service in terms of the functions that it has or provides.<br/></p>
BusinessInteractionItem Class	Name:	Name:
ServiceUsage Class	Name:	Name:
ServiceCharacteristic Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of characteristic, or distinguishing, features of a particular Service.<br/></p>
Resource Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>DONOTIMPLEMENT<br/></p><p>This is a conceptual relationship that defines the concept of a Service being supported by multiple Resources. DEN-ng defines this in more detail.<br/></p>
BusinessContract Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the set of functions, as specified by a BusinessContract, that apply to this particular Service. Functions include defining how to build a Service, how to manage it, how to operate it, how to invoke its functionality, and other related operations.<br/></p>
PartyRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>The OwnsService association defines the set of Services (CustomerFacing and/or ResourceFacing) that a particular PartyRole owns. Note that this is a very different relationship than the AdministersService association. The OwnsService association defines the PartyRole that is the owner of the Service. Here, "owner" is the person or group that is responsible (e.g., organizational, financial, and so forth) for the Service. Note that the cardinality of the OwnsService association on the PartyRole side is 1 - this means that a Service MUST have at least one PartyRole to manage it. Furthermore, the cardinality of this association on the Resource side is 0..n, which ensures that a PartyRole doesn't have to own a Service.<br/></p>
ServiceCharacteristicValue Class	Name:	Name:

Object	Type	Connection	Notes
ServiceRole	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of externally visible (and programmable) roles that a particular Service has. This enables the Service to be managed abstractly using ServiceRoles. It also helps define the Service in terms of the functions that it has or provides.
ServiceUsage	Class	Weak
ServiceCharacteristic	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of characteristic, or distinguishing, features of a particular Service.
Resource	Class	Weak	Copyright TM Forum 2005 DONOTIMPLEMENT This is a conceptual relationship that defines the concept of a Service being supported by multiple Resources. DEN-ng defines this in more detail.
CustomerFacingService	Class	Tree
BusinessContract	Class	Class	Copyright TM Forum 2005 This association defines the set of functions, as specified by a BusinessContract, that apply to this particular Service. Functions include defining how to build a Service, how to manage it, how to operate it, how to invoke its functionality, and other related operations.
PartyRole	Class	Class	Copyright TM Forum 2005 The OwnsService association defines the set of Services (CustomerFacing and/or ResourceFacing) that a particular PartyRole owns. Note that this is a very different relationship than the AdministersService association. The OwnsService association defines the PartyRole that is the owner of the Service. Here, "owner" is the person or group that is responsible (e.g., organizational, financial, and so forth) for the Service. Note that the cardinality of the OwnsService association on the PartyRole side is 1 - this means that a Service MUST have at least one PartyRole to manage it. Furthermore, the cardinality of this association on the Resource side is 0..n, which ensures that a PartyRole doesn't have to own a Service.
ResourceFacingService	Class	Tree
ServiceSpecification	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of Services that can be defined from a particular ServiceSpecification. Bundled sets of Services can be built by combining multiple ServiceSpecifications. This enables the ServiceSpecification to define the invariant attributes, methods, relationships, and constraints of a Service, and the Service to define different variations of the Service that are all built off of the same ServiceSpecification.
ManagedEntity	Class	Tree
Location	Class	Class	Copyright TM Forum 2005 This association defines the location(s) that a particular Service can be found at. Note that there can be multiple Locations assigned for a particular Service. Its semantics are defined by the ServiceLocationDetails association class. Please see the DEN-ng Location model for more information.
ValueNetworkRole	Class	Class	Copyright TM Forum 2005 This association defines the set of Services (CustomerFacing and/or ResourceFacing) that a particular Party, playing the role of ValueNetworkRole, administers. From a business perspective, the Owner has to either appoint or give permission to the Administrator to administer the Service that is owned.
Device	Class	Weak	Copyright TM Forum 2005 ILLUSTRATIVE USE ONLY - do not use!
ServiceCharacteristicValue	Class	Weak