Post on 06-Apr-2018
8/3/2019 COM WP CBE Concepts.1.2
1/73
OSS through JavaTM Initiative
Core Business EntitiesModel White Paper
OSS through Java Initiative
COM-WP-CBE_concepts.1.2.doc
Copyright 2004 BEA Systems, Inc., Mahindra-British Telecom, Metasolv
Software Inc., Motorola, Inc., NEC Corporation, Nokia Networks Oy,Nortel Networks Limited, Sonic Software Corporation, Sun Microsystems,
Inc., Telcordia Technologies, Inc. All rights reserved. Use is subject to
license terms.
Edited by John P. Reilly and Pierre Gauthier, MetaSolv Software
Contributors:
Dave Raymer, Motorola; Andreas Ebbert, Nokia; Melody Khair, Digital
Fairways; Maricio Arango, Sun; Colin Ashford, Nortel
TM Forum SID Team John Strassner (Intelliden), Wayne Sigley (Telstra),
Helen Hepburn (British Telecom), Chris Hartley (Telstra), and Cliff Faurer
(TM Forum)
COM-WP-CBE_concepts.1.2.doc page 1 / 73
8/3/2019 COM WP CBE Concepts.1.2
2/73
OSS through JavaTM Initiative
Executive Summary
API developers face the task of defining, modeling, and implementing coreconcepts in the course of almost every project in which they are involved.
Core concepts include individuals (such as employees) & organizations
(such as customers), products, services, & resources, locations & addresses,
along with interactions that involve individuals and organizations. Thesecore concepts represent who, what, when, where, and why that
make up the set of fundamental concepts present in todays world.
Perceptive developers reuse these concepts across the projects on whichthey work, but they still must implement them at least once. As well as
being time-consuming, this effort also breeds inconsistency, a major threat
to interoperability.
The OSS through Java initiative has the opportunity to improve the
efficiency of API developers and maintain consistency by defining,
modeling and implementing these core concepts. This work effort canleverage work already in progress being carried out by the TeleManagement
Forums New Generation OSS (NGOSS) Shared Information/Data (SID)
Model team.
The SID represents a synthesized view of information derived from various
industry models. This enables existing applications and software to beleveraged in building systems. The SID, a federation of models, also forms
a common information language that the industry can use to describe
management information.
The scope of this document is the explanation (based on the TM ForumSID) of these core concepts, their associated information models, and thespecification of the interfaces, which involve these core concepts. The core
concepts are referred to as core business entities in this document. Thesedefinitions, information models, and specifications, which together
represent the OSS/J API core model, can and should be used as the
cornerstone for any subsequent OSS/J API development.
The CBE is a subset of the SID that is based on the needs of the OSS/J APIsin existence. The subset may represent complete portions of the SID model
or partial portions that contain only higher level SID entities. As new APIs
are added or existing APIs are enhanced, the CBE model will expand based
on the scope of the new or enhanced API.
COM-WP-CBE_concepts.1.2.doc page 2 / 73
8/3/2019 COM WP CBE Concepts.1.2
3/73
OSS through JavaTM Initiative
Table of Contents
Executive Summary .......................................................................................................... 2
Table of Contents .............................................................................................................. 3
Table of Figures................................................................................................................. 6
Table of Code Snippets..................................................................................................... 7
1 Preface........................................................................................................................ 8
1.1 Objectives............................................................................................................ 8
1.2 Audience.............................................................................................................. 8
1.3 Approval and Distribution.................................................................................. 8
1.4 Related Information ............................................................................................ 8
1.5 How this document is organized......................................................................... 8
1.6 Revision History for version 2.0 ......................................................................... 9
2 Introduction............................................................................................................. 10
2.1 Opportunity Knocks .......................................................................................... 10
2.2 Core Business Entities ...................................................................................... 10
2.3 A Starting Point for Core Business Entities (CBE) .......................................... 12
3 Concepts................................................................................................................... 14
3.1 Business entity................................................................................................... 14
3.2 Core Business Entity......................................................................................... 14
3.3 Core Model ....................................................................................................... 14
4 Core Business Entity Modeling Concepts............................................................. 15
4.1 Introduction....................................................................................................... 15
4.2 Managed Entities .............................................................................................. 17
4.3 Entities .............................................................................................................. 17
4.4 Entity Specifications.......................................................................................... 17
4.5 Associations ...................................................................................................... 21
4.6 Constraints........................................................................................................ 23
4.7 Generalization................................................................................................... 23
5 SID Model Overview............................................................................................... 24
COM-WP-CBE_concepts.1.2.doc page 3 / 73
8/3/2019 COM WP CBE Concepts.1.2
4/73
OSS through JavaTM Initiative
5.1 The Who - Party................................................................................................ 245.1.1 Overview................................................................................................... 24
5.1.2 Party Fundamentals................................................................................... 24
5.1.3 Contact Medium........................................................................................ 255.1.4 Party Roles................................................................................................ 26
5.1.5 Interactions between Parties ..................................................................... 295.1.6 Associations between Party Roles ............................................................ 295.1.7 Party Names.............................................................................................. 30
5.1.8 Interworking with other business entities ................................................. 31
5.1.9 Example Extension of Party Customer .................................................. 32
5.2 The What Product, Service, and Resource..................................................... 335.2.1 Overview................................................................................................... 33
5.2.2 Product Inventory...................................................................................... 35
5.2.3 Service Inventory...................................................................................... 35
5.2.4 Resource Inventory ................................................................................... 365.2.5 Use Cases.................................................................................................. 37
5.3 The Where - Location........................................................................................ 375.3.1 Disclaimer ................................................................................................. 38
5.3.2 Overview................................................................................................... 385.3.3 Location .................................................................................................... 39
5.4 The When and the Why Business Interaction................................................. 415.4.1 Overview................................................................................................... 41
5.4.2 Sample Business Interaction Use Cases ................................................... 46
6 Core Model and SID Adoption Strategies ............................................................ 50
6.1 Core Model Strategy......................................................................................... 50
6.2 SID Adoption Strategy ...................................................................................... 50
6.3 CBE Scope Defined Using the SID Framework ............................................... 54
6.3.1 Product Domain ........................................................................................ 556.3.2 Customer Domain..................................................................................... 55
6.3.3 Service Domain......................................................................................... 55
6.3.4 Resource Domain...................................................................................... 55
6.3.5 Common Business Entities Domain ......................................................... 56
7 CBE Java Interface Definition Examples ............................................................. 57
7.1 Inventory and Service Activation Interaction Example .................................... 587.1.1 Inventory and Service Activation Collaboration Principals ..................... 58
7.1.2 Use-Case Customer Orders A Product ..................................................... 59
7.1.3 Use-Case: Product Order Decomposition................................................. 617.1.4 Usage of CBE in Service Activation ........................................................ 62
7.1.5 Code examples of Inventory and Service Activation Usage .................... 63
8 Compatibility with Other Industry Models.......................................................... 66
8.1 ebXML Party Information................................................................................. 66
COM-WP-CBE_concepts.1.2.doc page 4 / 73
8/3/2019 COM WP CBE Concepts.1.2
5/73
OSS through JavaTM Initiative
8.1.1 PartyId element......................................................................................... 678.1.2 PartyRef element....................................................................................... 68
8.1.3 CollaborationRole element ....................................................................... 69
8.2 CBE Representation of ebXMLs Party Information Requirements................. 70
Glossary and References ................................................................................................ 72
8.3 Glossary............................................................................................................ 72
8.4 References ......................................................................................................... 72
COM-WP-CBE_concepts.1.2.doc page 5 / 73
8/3/2019 COM WP CBE Concepts.1.2
6/73
OSS through JavaTM Initiative
Table of Figures
Figure 1 - Fundamental Entities........................................................................................ 10Figure 2 - Meta-Layers ..................................................................................................... 16
Figure3 - Example of a Core Business Entity................................................................... 17
Figure 4 - Example of Entity Instance Defined by Entity Specification .......................... 19
Figure 5 - Example of Entities and Entity Specifications................................................. 20Figure 6 - Associations Between Entity and Specification Instances............................... 21
Figure 7 - Example of an Association............................................................................... 22
Figure 8 - Showing How Party Fits In.............................................................................. 24Figure 9 - Basic Party Model (source: TM Forum) .......................................................... 25
Figure 10 - Initial Party Model (source: TM Forum) ....................................................... 26
Figure 11 - Party and the Main eTOM Roles (source: TM Forum).................................. 28Figure 12 - Parties Interact Via Their Roles (source: TM Forum) ................................... 29
Figure 13 - Parties Can Be Associated Via Their Roles (source: TM Forum)................. 30
Figure 14 - Naming For Parties (source: TM Forum)....................................................... 31
Figure 15 - Possible Links to Other Parts of the Core Model (source: TM Forum)......... 32Figure 16 - Customer Shown As An Extension of Party Role (source: TM Forum)........ 33
Figure 17 - Showing How Products, Services, and Resources Fit In ............................... 34
Figure 18 - Inventory Business Entities............................................................................ 37Figure 19 - Showing How Locations Fit In ...................................................................... 38
Figure 20 - Initial Location Model.................................................................................... 40
Figure 21 - Showing How Interactions Fit In................................................................... 41Figure 22 - Types of Business Interactions (source: TM Forum)..................................... 42
Figure 23 - The Relationship Between Business Interactions and Business Participants
(source: TM Forum).................................................................................................. 43Figure 24 - The Relationship Between Business Interaction and Products, Services, and
Resources (source: TM Forum) ................................................................................ 44Figure 25 - The Relationship Between Business Interactions and Locations (source: TM
Forum)....................................................................................................................... 45
Figure 26 Business Interaction Business Entity Model (source: TM Forum) ............... 46
Figure 27 - SID Product Offering ABE ............................................................................ 51Figure 28 - Sample OSS/J API Trouble Ticket Attributes ............................................... 52
Figure 29 - Sample OSS/J Trouble Ticket Methods......................................................... 52
Figure 30 Current CBE Scope ....................................................................................... 54Figure 31 - Interaction Principals between Inventory and Activation Components......... 58
Figure 32 - Customer Interaction: Order a New Product.................................................. 59
Figure 33 - Decomposition of a Product Order into Two Service Orders........................ 61
Figure 34 - Modeling Concepts between Service Activation and CBE............................ 63Figure 35 - CBE Party Model's Compatibility with ebXML Party .................................. 71
COM-WP-CBE_concepts.1.2.doc page 6 / 73
8/3/2019 COM WP CBE Concepts.1.2
7/73
OSS through JavaTM Initiative
Table of Code Snippets
Snippet 1 - Query the Product Catalog ............................................................................. 63Snippet 2 - Use A Specification To Instantiate A Product ............................................... 64
Snippet 3 - Create And Start An Order............................................................................. 64
Snippet 4 - Query Resources............................................................................................. 64
Snippet 5 - ebXML PartyInfo Element............................................................................. 66Snippet 6 - Example of Two URI References .................................................................. 68
Snippet 7 - Example of the PartyRef Element .................................................................. 69
Snippet 8 - Example of the CollaborationRole Element................................................... 69
COM-WP-CBE_concepts.1.2.doc page 7 / 73
8/3/2019 COM WP CBE Concepts.1.2
8/73
OSS through JavaTM Initiative
1 Preface
1.1 Objectives
The intention of this document is to provide definitions and to present
outline models for an initial set of core business entities (also called shared
business entities). A companion Rational Rose model contains the UMLrepresentation of the core business entities. The initial set of objects
includes Party (individual or organization), Product, Service, Resource,
Location and Address, and Interaction (between parties).
1.2 Audience
This guideline is intended for use by various groups specifying APIs within
OSS/J.
1.3 Approval and Distribution
This document has been reviewed and approved by the OSS/J Core
Business Entity (CBE) team as well as the OSS/J Common team.
Subsequent versions will be developed, reviewed, and approved by the CBE
team. Versions will also be reviewed and approved by the OSS/J Common
team. The TeleManagement (TM) Forum Shared Information and Data
Model (SID) team may also provide reviews of subsequent versions.
The documents latest version will be made available for distribution on the
OSS Through Java web site.
1.4 Related Information
Some of the content of this document was extracted from TM Forum SID
documents (GB922 and GB926 series) and the OSS/J Inventory API
(JSR142).
Copies of these documents are available to registered users on the TMForum web site and the OSS Through Java website.
1.5 How this document is organized
This document contains a brief introductory section and a section explaining
core business entity concepts.
COM-WP-CBE_concepts.1.2.doc page 8 / 73
8/3/2019 COM WP CBE Concepts.1.2
9/73
OSS through JavaTM Initiative
Following these two sections are separate sections that present the core
business entities
Party
Product, Service, Resource
Location & Address Interaction
Each of these sections provides examples of how the core business entities
represented in the core model can be used in OSS/J API specifications, such
as the Service Activation and Inventory APIs
1.6 Revision History for version 2.0
Date Version Author State Comments
12 Apr2004
2.0 John Reilly Draft Add CBE coverage ofSID Framework; place
interface definitions into
a separate document
23 Apr
2004
2.1 Andreas
Ebbert
Draft Improved Figure 4
Added chapter 7.1
8 Dec 2004 1.2 John Reilly Final Updated doc name andversion number for
inclusion in 1.2 Design
Guidelines.
COM-WP-CBE_concepts.1.2.doc page 9 / 73
8/3/2019 COM WP CBE Concepts.1.2
10/73
OSS through JavaTM Initiative
2 Introduction
2.1 Opportunity Knocks
Throughout the years, API developers have repeatedly come up with
definitions and implementations of core concepts such as locations,
addresses, individuals, and organizations, products, services, and resources.These attributes represent a core set of objects that should be defined and
implemented once, and then reused again and again.
This represents an opportunity for the OSS through Java initiative todefine a set of core business entities (sometimes referred to as shared
business entities) represented in a core model. The end result would be a
java package for the core business entities, javax.oss.cbe, and its
associated XML schema. Any OSS/J API should use the core model as a
starting point for API development. The use of this model would resolvethe overlaps and inconsistencies already present in some OSS/J APIs. Itwould also eliminate any future inconsistencies and duplication of effort.
Additionally, the core model could be distributed to several repositories to
implement the model with different technologies and/or differentnative
schemas
As new APIs are developed, additional core business entities may be added
to the core model.
2.2 Core Business EntitiesThe first step is to identify a set of core business entities. The things in
which any enterprise is interested can be represented by entities that answer
five fundamental questions as shown in the figure below.
Who (Party)
Why (Reason)
What (Thing)
When (TimePeriod)
Where (Location)
Figure 1 - Fundamental Entities
For example, an SLA Violation Alarm (Notification) about Service is
communicated to SLA Management (Organization). The SLA Violation
COM-WP-CBE_concepts.1.2.doc page 10 / 73
8/3/2019 COM WP CBE Concepts.1.2
11/73
OSS through JavaTM Initiative
Alarm may result in a Billing Credit Notification being sent to a Customer
(Individual or Organization) at the Customers home Address.
The initial scope of the core business entity package would include
The Who Party and Party Roles (Customer, Service Provider and soforth)
The What - Product, Service, and Resource
The Where - Location & Address
The When and Why - Interaction
Parties are individuals and organizations that interact with an enterprise as
the enterprise carries out its day-to-day business. Parties play roles as they
interact with an enterprise. The roles parties play can be customers,employees, suppliers, partners, the enterprise and its organizations, and so
forth. Parties and the roles parties play represent a distillation of all the
attributes, associations and behavior that customers, employees, and so forthhave in common. Examples from an attribute perspective include name,
location and address, and contact medium. From a behavioral perspective,
parties come into existence, their status is tracked during their life of
interest to the business, and they are eventually no longer of business
interest.
Location is a concept representing a place, such as a structure like a
building. An address is not a type of location but is a means of finding alocation. Addresses may have aliases, for instance Cnr Surf and Roban
streets may be an alias for (refers to the same location) as 15 Roban Street.
Unlike parties and interactions, which are distillations of things common toa number of different objects, locations and addresses are not abstractions
but business entities in their own right that are associated to a number of
other business entities, including parties, interactions, resources, services,
products, and so forth.
A Product is an externally facing representation of a service and/or resource
procured by the market. For example, a real-time broadcast of a footballmatch. A Service is an intangible realization of a Product or something
provided in support of a Product. For example, a video streaming
connection used to transmit the football match to a customers PDA; an
installation service provided for a cable modem. A Resource is part of anenterprises infrastructure utilized by a Service or a good procured by the
market. One example of a resource is a wireless network (infrastructure)
utilized by the video streaming connection. Another example is aninventory of cable modems (goods procured by the market) offered to the
market.
Interactions are arrangements, contracts, communications and activities that
involve parties playing a role. For example, a prospective customer may
COM-WP-CBE_concepts.1.2.doc page 11 / 73
8/3/2019 COM WP CBE Concepts.1.2
12/73
OSS through JavaTM Initiative
request information about a real-time football match broadcast productoffering. This request may then become an order for the broadcast to be sent
to the customers PDA. This order is another type of interaction.
Interactions, like parties, represent a distillation of attributes, associations,and behavior common to requests, responses, notifications, and agreements.
For example, in addition to all forms of interactions involving partiesplaying a role, interactions also involve products, services, resources,
product offerings, locations, and addresses from an association perspective.
A number of core business entities, such as Party and Interaction, represent
abstract concepts. As such, their concrete subclasses inherit the behaviors,attributes, and associations of the abstract class. Use Cases associated with
the abstract class can also be inherited. The benefits of Use Case inheritance
will be shown via example in this white paper. With the introduction of
UML 1.3, a new relationship between use cases was introduced-
generalization. A generalization relationship between parent and child use
cases is one in which the child is a more specialized form of the parent usecase. The child inherits the behaviors of its parents and adds new behaviors,
and specializes in behaviors inherited from the parent. Generalized use
cases typically involve abstract actors and abstract classes.
2.3 A Starting Point for Core Business Entities (CBE)
Today the communications and information service industry is awash with
information and data models and model fragments. Organizations andforums such as the OSS through Java Initiative (OSS/J), Object
Management Group (OMG), DMTF (Distributed Management Task Force),
T1M1 committee of the Alliance for Telecommunications IndustrySolutions (ATIS), International Telecommunications Union (ITU), InternetEngineering Task Force (IETF), and Internet Protocol Detail Record
Organization (iPDR.org), TeleManagement Forum and others, havedeveloped models and model fragments. These models have formed the
foundation for fruitful attempts at OSS interoperability.
While it is unfortunate that we have so many models, their existence has
pointed out the pressing need for a shared information model. What wouldbe better than these disparate models is a shared information/data model
that represents a synthesized view of a number of these industry models.
This synthesized model would form a common information/data languagefor the industry along with facilitating interoperability among diverse sets of
applications. This is the focus of a major initiative underway in the
TeleManagement Forums Shared Information and Data Modeling team
(SID)
The SID model is gaining acceptance within the communications and
information services industry. For example, the TM Forums DEN-ng
project is an application representing the practical implementation of the
COM-WP-CBE_concepts.1.2.doc page 12 / 73
8/3/2019 COM WP CBE Concepts.1.2
13/73
OSS through JavaTM Initiative
SID model. TM Forum Catalyst projects are using the SID as aninteroperability model for products, services, and resources. The OMG is
planning to present the SID documents as a OMG white paper that
recommends the use of the SID as the foundation for the OMGs TelecomDomain Task Force configuration independent model. ITU/T1M1 are using
the SID as a source for its Global Telecom Data Dictionary (GTDD).
The SID model contains a set of common business entity definitions andmodels that can be used to form the foundation for the core model of OSS/J
CBEs (shared business entities using TM Forum terminology). This
foundation can be extended as needed by OSS/J APIs, but the foundations
basic structure should not be compromised.
COM-WP-CBE_concepts.1.2.doc page 13 / 73
8/3/2019 COM WP CBE Concepts.1.2
14/73
OSS through JavaTM Initiative
3 Concepts
3.1 Business entity
A business entity is a thing of interest to the business. Business entities are
characterized by attributes. Business entities also possess other properties,
such as involvement in associations with other business entities or entitytypes and exhibition of behavior. These properties (attributes, associations,
and behavior) ofbusiness entities may be inherited by the other entity types
or other business entities.
3.2 Core Business Entity
Core business entities represent five basic concepts present in the day-to-
day running of every enterprise. The concepts are who, what, where, whenand why.
A core business entity may be an object that primarily supports a group of
TM Forum eTOM processes. These business entities support processes inthe Product, Service, and Resource layers of the eTOM. A core business
entity may also be a business entity that is common to a number of eTOM
processes, for example Location and Address.
Core business entities can represent an abstraction, such as a superclass, or
a real world object.
3.3 Core Model
The core model contains the artifacts that fully describe core business
entities. The artifacts include core business entity definitions and UML
models. The UML models contain class diagrams that document the
attributes and operations of the core business entities.
COM-WP-CBE_concepts.1.2.doc page 14 / 73
8/3/2019 COM WP CBE Concepts.1.2
15/73
OSS through JavaTM Initiative
4 Core Business Entity Modeling Concepts
Note: The contents of this chapter are a modified extract from the OSS/JInventory API Specification (JSR 142). The concepts presented in the
Inventory API have been generalized here so that they apply to the Core
Business Entity model.
4.1 Introduction
The framework for meta-modeling data proposed in this document is based
on an architecture composed of three layers. Each of the layers provides
different levels of abstraction. These layers are defined as follows:
The meta-model layer is comprised of the descriptions that define thestructure and semantics of core business entity models (i.e., information
model for meta-data). The model layer is comprised of the meta-data that describes the core
business entity information. This layer is also referred to as meta-data
or core business entity model. Core models could be translated to
specific schema definitions for various repositories (e.g., XML Schema,
SQL DDL, LDAP Schema, etc.)
The instance layer is comprised of the core business entity informationstored in the repository. This information is also referred to as coredata.
The meta-model defines a subset of UML elements to be used for modelingCore Business Entities. The meta-model uses the UML concepts of class,
association and constraint to model the elements managed entity, entity,
entity specification and association. (see Meta Layers Figure).
COM-WP-CBE_concepts.1.2.doc page 15 / 73
8/3/2019 COM WP CBE Concepts.1.2
16/73
OSS through JavaTM Initiative
Meta-model Layer
Model Layer
Instance Layer
Entity Entity Specification Association
Subscriber
VPN_Product
SP1 Inc.
VPN_1
VPN_2
SubscriberSubscribesProduct
0..* 0..*
Managed Entity
Figure 2 - Meta-Layers
The core model defines completely the meta-model layer and partially the
model layer.
Core business entity models are expressed using class diagrams (see the
following chapters). Object diagrams (snapshots), which are the
instantiations of class diagrams, may be used to provide examples and
explore particular situations.
The Core Meta-model extends the UML vocabulary with the following
concepts:
Entity with stereotype Entity Interface ().Entities are value type objects representing for example inventoryconcepts such as Product, Service and Resource.
Entity Specification with stereotype Specification Interface(). Entity Specifications are value type
objects representing for example specifications of inventory entities.
Association with stereotype Association Interface ().
A class diagram representing a Core Business Entity Model could contain
the following elements:
COM-WP-CBE_concepts.1.2.doc page 16 / 73
8/3/2019 COM WP CBE Concepts.1.2
17/73
OSS through JavaTM Initiative
Interfaces with stereotype Entity Interface () andtheir methods to get and set their attributes, leveraging the Entity
concept defined in the Core Business Entity meta model.
Interfaces with stereotype Specification Interface () and their methods to get and set their attributes, leveraging
the Entity Specification concept defined in the Core Business Entitymeta model.
Associations (Aggregation is a special form of association). Someassociations are represented as first class objects with stereotype
Association Interface ()
Constraints
Generalizations
4.2 Managed Entities
A Managed Entity is the root class for all Core Business Entity model
entities and entity specifications.
4.3 Entities
An Entity is used to represent core business entity objects, which share the
same structural and behavioral features.
Entities can be represented as interfaces with stereotype Entity Interface(). The entity contains a list of methods to get and set
its attributes.
Resource
getAttributeValues()setAttributeValues()getAllPopulatedAttributes()
Figure3 - Example of a Core Business Entity
4.4 Entity Specifications
An Entity Specification captures invariant characteristics and constraintsapplicable to all instances of the same business entity. For example, a
GoldBroadbandAccessServiceSpecification may capture the
characteristics, configuration and QoS parameter ranges, specific to a
Gold Broadband Access service offering. Several specification instances
may exist for the same inventory entity type. For example, Gold, Silver
and Bronze specifications may be defined for a
BroadbandAccessService. A Product Specification includes features,
COM-WP-CBE_concepts.1.2.doc page 17 / 73
8/3/2019 COM WP CBE Concepts.1.2
18/73
OSS through JavaTM Initiative
such as height, weight, and so forth, common to all instances of a ProductOffering based on the specification. The use of the Entity
Specification/Entity modeling pattern provides a number of benefits over
using a pattern that models invariant characteristics as attributes of anEntity. First, the attribute values are not duplicated for each instance of an
entity characterized by the same specification. Second, when updating oneor more characteristics, only the specification instance characteristicsrequire updating as opposed to the characteristics embedded in each entity
instance. Third, if the last entity for a specification is deleted, then entity
specification characteristics remain, as opposed to losing the entity
specification characteristics if the characteristics are embedded within each
entity instance.
In some cases, a characteristic, such as color, may take on multiple possible
values. To satisfy this requirement an Entity Characteristic and EntityCharacteristic Value is used. Color would be an instance of Entity
Characteristic. There would be an instance of Entity Characteristic Value
for each possible color, say for a Product, such as red, blue, green, and soforth. This pattern allows new characteristics and their values to be added
or inactivated without impacting the model. Each Entity instance associated
with an Entity Specification would be associated to the characteristic valuechosen for the Entity. For example, Jims cell phone is associated with red;
Joans phone is associated with blue. Adding a new color does not impact
any existing entities, nor does inactivating an existing color.
Catalogs are collections of entity specifications (e.g., service catalog
composed of service specifications, product catalog composed of product
specifications, resource catalog composed of resource specifications, and so
forth.).
An entity instance is defined by a single entity specification. (The same
entity specification may be used to define multiple entity instances.) Note
that some entity instances may refer to no entity specification and still be
valid ones.
Another possible use of entity specifications is in the Customer SLA API.
For example, an SLA specification could be the repository for standard
terms and objectives used to create SLA entity instances. Additionally, thespecifications could contain standard compensation amounts, such as
discounts and rebates, which could be associated to SLA entity instances, ifSLA objectives are not met. Associations among these entity specificationswould define rules as to how the terms, objectives, and compensation
amounts can be used together to define an SLA instance. For example, one
type of objective may only be compensated via a discount, and not a cash
rebate.
A number of other OSS/J APIs including those planned in the API roadmap,
such as Customer Order Management, Workforce Management, Trouble
COM-WP-CBE_concepts.1.2.doc page 18 / 73
8/3/2019 COM WP CBE Concepts.1.2
19/73
OSS through JavaTM Initiative
Ticketing, could take advantages of entity specifications. For example, aspecification list of commonly performed tasks could find a home as
Workforce Management specifications.
I nvent ory Model Inst anc es
BroadbandAccessSpecification
transferVolume
supportType
getTransferVolume()
setTransferVolume()
getSupportType()
setSupportType()
BroadbandAccess
username
password
domain
getUsername()
setUsername()
getPassword()
setPassword()
getDomain()
setDomain()
describes
GoldAccess :
BroadbandAccessSpecification
# supportType = priviledged
# transferVolume = 1000000
BobsAccess :
BroadbandAccess
# domain = java.org
# password = sarah
# username = bob
describes
Figure 4 - Example of Entity Instance Defined by Entity Specification
In order to define the characteristics of complex entities (e.g., servicebundles containing multiple services, devices containing shelves, cards and
ports, etc.) entity specifications could also participate in associations with
other entity specifications. An example of relationships between entities and
entity specifications is presented on the following diagram.1
1 Relationship meaning is discerned as in reading from top to bottom, left to right. For example, in
, the describes relationship is read as
BroadbandAccessSpecification describes BroadbandAccess.
Figure 4
- Example of Entity Instance Defined by Entity Specification
COM-WP-CBE_concepts.1.2.doc page 19 / 73
8/3/2019 COM WP CBE Concepts.1.2
20/73
OSS through JavaTM Initiative
Product
Service
aggregates
aggregates
ProductSpecification
describes
ServiceSpecification
aggregates
aggregates
BroadbandAccess
BroadbandAccessSpecification
describes
E-MailSpecification
describes
Backup
BackupServiceSpecification
describes
Figure 5 - Example of Entities and Entity Specifications
The following instance diagram (corresponding to the information model on
Figure 5 - Example of Entities and Entity Specifications) provides examples
of relationships between entity and specification instances.
COM-WP-CBE_concepts.1.2.doc page 20 / 73
8/3/2019 COM WP CBE Concepts.1.2
21/73
OSS through JavaTM Initiative
goldInternetService :
ProductSpecification
bobsInternetSu
b : Product
goldBAccess :
BroadbandAccessSpecification
goldEmail :
E-MailSpecificationgoldBackup :
BackupServiceSpecification
bobsAccess :
BroadbandAccess
bobsEmail :
bobsBackup :
Backup
: aggregates
: aggregates
: aggregates
: describes
: aggregates
: aggregates
: aggregates
: describes
: describes: describes
Figure 6 - Associations Between Entity and Specification Instances
4.5 Associations
Associations are the means by which binary relationships between entities
and entity specifications are represented.
Associations are characterized by their cardinality and the roles at each
association end.
COM-WP-CBE_concepts.1.2.doc page 21 / 73
8/3/2019 COM WP CBE Concepts.1.2
22/73
OSS through JavaTM Initiative
PartyRole
Resource0..* 0..*
+owner +ownedResource
OwnerOwnsResource
Figure 7 - Example of an Association
No specific implementation is assumed for associations defined in the core
business entity model. However, it is expected that with the OSS/J API inmost cases associations will be implemented as first class objects (that is,
Java classes).
The recommended implementation of the associations could be explicitly
captured in the information model, using a constraint for the association,indicating that first class objects or attributes should be used.
The separation of object structure from associations allows the creation and
removal of associations without affecting the objects themselves.
The following rules apply to core business entity associations:
When creating an association the two entity instances linked by theassociation must exist in the core business entity repository.
When one of the entity instances linked by an association instance isdeleted, the association instance should be deleted as well.
If the association instance is not deleted, then, in order to maintainreferential integrity, references to a deleted entity must be updated to benull.
Containment is a special type of relationship. It is of particular importance
for business entities such as the resource inventory business entities, forexample, representing physical equipment hierarchies. There shouldnt be
COM-WP-CBE_concepts.1.2.doc page 22 / 73
8/3/2019 COM WP CBE Concepts.1.2
23/73
OSS through JavaTM Initiative
any difference in the way containment relationships are managed by theOSS/J APIs. For some functions specific containment based queries may be
defined.
In order to allow validation, association rules are used. Association rules area metadata concept and can be accessed through the APIs, such as the
Inventory API, i.e., the client will not only be able to retrieve the list of
supported association types but also the rules applying to these associations.
Each association rule consists of the following components:
The type of each entity involved in the association;
The role of each entity;
The cardinality constraints;
The constraints on the entities involved in the association.
An association is considered valid if it satisfies all the requirements of thecorresponding association rule.
Although association rules may appear similar to entity specifications, thereare fundamental differences between the two concepts. Entity specifications
are dynamically created while association rules are not. The primary goal of
the entity specifications is to allow specialization according to a predefinedset of parameters, while the primary goal of association rules is to provide
means for validation.
4.6 ConstraintsConstraints are used to attach consistency rules to model components.
Constraints for the Core Business Entity model may be described in
informal language (e.g., English) or could be formally expressed in Object
Constraint Language (OCL) as described in the UML specification.
Note that for instance the association rules are captured in Core Business
Entity information models as constraints attached to the association links.
4.7 Generalization
Generalization represents a classification relationship between classes. The
most important characteristic of this relationship is the substitutability. Thisrequires that wherever a super-class is used in a model, it is possible to
replace it with one of its subclasses with no effect on the properties of the
model. This means that all attributes, associations and constraints of a
super-class should be inherited by its subclasses.
COM-WP-CBE_concepts.1.2.doc page 23 / 73
8/3/2019 COM WP CBE Concepts.1.2
24/73
OSS through JavaTM Initiative
5 SID Model Overview
5.1 The Who - Party
Note: The contents of this chapter are a modified extract from the
TeleManagement Forums Shared Information/Data (SID) Model document
GB922 Addendum 1P.
5.1.1 Overview
This chapter answers the question who? and deals with people and
organizations in the context of the eTOM, which looks at processes from a
Service Providers point of view.
The eTOM is a business process model or framework that provides the
enterprise processes required for a service provider. [eTOM]
Who (Party)
Why (Reason)
What (Thing)
When (TimePeriod)
Where (Location)
Figure 8 - Showing How Party Fits In
Organizations can be internal (department, subsidiary) or external to the
Service Provider (suppliers, customers).
Individuals can be internal (employees, board members) or external to the
Service Provider (customers, organization contacts, shareholders).
5.1.2 Party Fundamentals
Figure 9 - Basic Party Modelshows a Party representing an Individual orOrganization. 2
2 All entities referenced in this chapter are fully described in the SID addenda.
COM-WP-CBE_concepts.1.2.doc page 24 / 73
8/3/2019 COM WP CBE Concepts.1.2
25/73
OSS through JavaTM Initiative
Party
partyId
IndividualgenderplaceOfBirthnationalitymaritalStatusdriversLicenceNrpassportNrskillsdisabilitiesaliveDuring : TimePeriod
Organization
companyNr
isLegalEntity
industrySector
existsDuring : TimePeriod
Figure 9 - Basic Party Model (source: TM Forum)
In this model, both organization and organization unit (e.g. consortium,
parent company, subsidiary, division, department, branch or team) are
represented by the Organization entity, which should be subclassed as
required.
Organization can also represent government agencies, clubs, charities and
educational & religious organizations
While Party is not a term often used in the business, the concept of a
person or a company is often heard, and the Party abstraction makes the
domain model easier to understand.
5.1.3 Contact Medium
A Party can be contacted using a contact medium, which is an abstraction of
the commonly used contact types: eMail, Postal Address, telephone, fax etc.
When there is a need to show that a Business Entity is only valid for a
certain time, this will be shown by an attribute called validFor, of typeTimePeriod. In the design model, temporal support may be implemented in
other ways, but this approach has been chosen for the analysis model as it
shows the requirement without cluttering up the model.
COM-WP-CBE_concepts.1.2.doc page 25 / 73
8/3/2019 COM WP CBE Concepts.1.2
26/73
OSS through JavaTM Initiative
Organization
companyNr
isLegalEntity
industrySector
existsDuring : TimePeriod
PostalContactEmailContact
eMailAddress
eMailProtocol
this will get converted
to Location in a later
version
Country
Individual
gender
placeOfBirth
nationality
maritalStatus
driversLicenceNr
passportNr
skills
disabilities
aliveDuring : TimePeriod
1
0..n+countryOfBirth
1
Contact Medium
validFor : TimePe ri...
Party
partyId
0..n
0..n
PartyContactMedium
0..n
mayBeReachedUsing0..n
0..n
Figure 10 - Initial Party Model (source: TM Forum)
An Organization (unit) can contain other Organization (unit)s in a
hierarchy.
5.1.4 Party Roles
People and Organizations exhibit complex behavior. A lot of the behavior
can be grouped, based on a particular context, or participation in a certaininteraction.
For instance, a child at school will behave as a student and an adult may
behave as a teacher. A person, playing cricket, may behave as a bowler, a
batsman or as a fielder or wicket-keeper.
These behavior groups will change over time and will cause problems if we
model them using inheritance / specialization. Also we need to allow for the
fact that a Party may play many roles at one time (an employee may also be
a customer, a graduate student may also be a tutor)
By modeling PartyRole as a separate concept from Party, we allow for
proper representation of these complex sets of behaviors.
When looking at the eTOM, we see that in the Value Network, Parties play
roles in the context of an interaction to provide Customer value. This
interaction may be per service or per event (e.g. a phone call).
COM-WP-CBE_concepts.1.2.doc page 26 / 73
8/3/2019 COM WP CBE Concepts.1.2
27/73
OSS through JavaTM Initiative
Note that these are roles and that individual organizations (andorganizational entities) can adopt different roles in different value networks.
Roles represent activities that businesses can engage in and, for example, a
service provider may be the customer facing service provider in one valuenetwork and a third party (e.g. wholesale) service provider in another.
Relationships are established between the roles, hence the businessrelationship context model. In todays fast-moving marketplace,relationships can be very short-lived compared with the more static
relationships of the traditional telecommunications market. By focusing on
roles rather than organizations, a more flexible business relationship context
model can be achieved. Organizations can adopt and shed rolesdynamically, but the relationships between the roles are established, so the
adoption of a particular role will also define the relationship of the
organization playing that role towards another role player. [eTOM]
The Value Network roles defined in the eTOM are shown as subclasses of
PartyRole in Figure 11
Note that even though we are modeling from the point of view of the
service provider, we need to model all of the value chain.
In todays marketplace, companies must implement an end-to-end value
stream and have an integrated and customer-centric technology foundation.
It is also necessary to be a part of and to manage eBusiness communities(EBCs), which are networks of relationships linking businesses, customers
and suppliers to create a unique business entity that is re-configurable, to
meet customer needs. In order to develop customer relationship solutions,
companies must extend beyond their own boundaries to encompass the
entire extended enterprise and make this transparent to the customer.[eTOM]
COM-WP-CBE_concepts.1.2.doc page 27 / 73
8/3/2019 COM WP CBE Concepts.1.2
28/73
OSS through JavaTM Initiative
Customer
favouriteColorInterme diary
Vendor
Service Provider
Complementary
Provider
Th ird P arty Se rvi ce
ProviderFunc tio n or Process
Provider
Value Network Role
PartyRole
status
Party
partyId
* 1* 1
Service Provi der Em ployee
employmentStatus
employeeNr
currentSalary : M oney
These are business entities, not
software classes
Figure 11 - Party and the Main eTOM Roles (source: TM Forum)
The role entity represents the common behavior by a Party when acting in
the role.
This model explicitly separates the information held about individuals and
organizations from the roles that they perform and the relationships theService Provider forms with them. for example, a Service Provider may
wish to keep a list of Phone Dealers (including competitors) to help in
determining shop placements. The Organizations are stored, with a role ofPhone Dealer, but there may never be any Interaction between the
dealers and the Service Provider.
An Employment Position or Post is represented by creating an Organization
Role of type POST for the relevant organization unit. e.g. .the Org unit
Western Region has a Post of Western Region Data QualityCoordinator. A Party Role linked to Western Region is created for this
Post and employees can be assigned to the Post using interactions.
Typically, there would only be one person assigned to a Post at any point in
time (using TimePeriods).
Note:
In the value network, roles may not be exclusive, e.g. a customer may also
be a supplier
In a number of cases, we are interested in parties playing a combination of
roles, e.g. staff, who use our services, get staff discount and suppliers who,
use or products, are preferred suppliers.
COM-WP-CBE_concepts.1.2.doc page 28 / 73
8/3/2019 COM WP CBE Concepts.1.2
29/73
OSS through JavaTM Initiative
5.1.5 Interactions between Parties
Combining Figure 9 - Basic Party Modeland Figure 11 - Party and the
Main eTOM Rolesgives us the model shown in Figure 12 - Parties Interact
Via Their Roles.
Sets of Party Specification entities together with Party Specification Policy
entities provide rules, conditions, and allowable actions for Parties and
Party Roles. These entities are not shown in the model.
PartyRoleGroup allows Party Roles to be grouped (e.g. into Customer
Demographics)
An Interaction will involve one or more Parties playing roles participating
in the value network to provide Customer value.
An Interaction may have links to Product & Location.
Individual
gender
placeOfBirth
nationality
maritalStatusdriversLicenceNr
passportNr
skills
disabilities
aliveDuring : TimePeriod
Organization
companyNr
isLegalEntity
industrySectorexistsDuring : T imePeriod
Interaction
PartyRole
Value Network Role
These are business e ntiti es, n ot
software cla sses
Party
partyId
PartyRole
Group
PartyRole
status1* 1*
0..n
0..n
Interaction
validFor : Tim ePeri...1..** 1..**
0..n
0..n
Figure 12 - Parties Interact Via Their Roles (source: TM Forum)
5.1.6 Associations between Party Roles
We need to be able to show associations between Parties playing roles that
are not directly involved in the value network.
Examples of these associations include
Organizational associations in the service providers own business(organization unit employee, organization unit organization unit)
Associations in other Organizations participating in the value network(organization unit employee, organization unit organization unit)
COM-WP-CBE_concepts.1.2.doc page 29 / 73
8/3/2019 COM WP CBE Concepts.1.2
30/73
OSS through JavaTM Initiative
Associations allowing us to determine the make-up of a household(household member household member)
Associations showing family make-up (parent-child)
PartyRoleAssociation and any subclasses must not be linked toLocation, Product or Interaction.
Party Role Association
associationType
validFor : TimePeriod
status
Party
partyId
Interaction
validFor : Tim ePeri...
PartyRole
status
* 1* 1* 1..** 1..*
*
*
+from
*
+to*
Party Role
Organization Assoc
Party Role
Household Assoc
Party Role
Famil y Assoc
Figure 13 - Parties Can Be Associated Via Their Roles (source: TM Forum)
5.1.7 Party Names
An individual is referred to by their name. This name can change over time
(e.g. After marriage, by deed poll) and to allow for this we will model anindividuals name as a separate entity. Similarly, organizations can change
their names (e.g. from Telecom to Telstra) and we will also model
organization names as a separate entity. Note that this model does not allow
for individual name or organization name aliases.
COM-WP-CBE_concepts.1.2.doc page 30 / 73
8/3/2019 COM WP CBE Concepts.1.2
31/73
OSS through JavaTM Initiative
Party
partyId
Individual
gender
placeOfBirth
nationality
maritalStatus
driversLicenceNr
passportNr
skills
disabilities
aliveDuring : TimePeriod
IndividualName
formattedName
aristocraticTitle
salutationgivenName
preferredGivenName
middleName
familyNamePrefix
familyName
familyGeneration
qualifications
1 1..n1..n
Organi zation
companyNr
isLegalEntity
industrySector
existsDuring : TimePe riod
Organization Name
tradingName
1 1..n1..n
Country
Language
alphabetName
dialectNames
1..*
n
1..*
n
PartyName
validFor : T imePeri...
1
0..*
+nameRuleCountry
0..*
10..*0..*
this will get converted to
Location in a later version
These are business entities, not
software classes
1
1
1
1
Figure 14 - Naming For Parties (source: TM Forum)
5.1.8 Interworking with other business entities
Figure 15 - Possible Links to Other Parts of the Core Modelshows the
main Party classes and the expected connections to other parts of the coremodel. This is for information only and is not guaranteed to be complete.Note also that the Location linkages will be refined after the Location model
facet has been defined.
Note that having PartyContactMedium allows us to store a default set ofcontacts for a Party, which can be overridden by PartyRole if there are
any role-based contacts. In most cases, only the one set of contacts would
be required. Contact details for a Post would use a PartyRole
ContactMedium.
COM-WP-CBE_concepts.1.2.doc page 31 / 73
8/3/2019 COM WP CBE Concepts.1.2
32/73
OSS through JavaTM Initiative
Contact Me dium
v alidFor : TimePer...
Interaction Party Role
to be refined
later
Address
Location
Party Role
Location
Interact ion
v alidFor : TimePer...
Party
partyId
0..n
0..n 0..n
0..n
Agreement
Party Location
PartyRole
status
*
1..*
*
1..**1 *1
**
0..n
0..n
mayBeReachedUsing
0..n
0..n
0..n
0..n
0..n
0..n
Figure 15 - Possible Links to Other Parts of the Core Model (source: TM Forum)
Notes:
Note that these entities represent business concepts in a Service Provider
that conforms to the eTOM process model [eTOM].
Entities that are outside the scope of this model facet are shown with a
white fill color.
This is intended as a minimalist model. Subtypes and attributes should be
added as required. The attributes shown should be considered as suggested,
not required.
5.1.9 Example Extension of Party Customer
The figure below shows how a Customer business entity represents an
extension (from an information model perspective) of Party. A number ofattributes (such as name and contact medium) and associations now reside
in the Party core business entity.
COM-WP-CBE_concepts.1.2.doc page 32 / 73
8/3/2019 COM WP CBE Concepts.1.2
33/73
OSS through JavaTM Initiative
0..n
CustomerAccountRelationship
relationshipType
validFor : TimePeriod
IdentityContactMedium(from Party)
CustomerAccountContact
contactType
validFor : TimePeriod
0..n
0..n
0..n
0..n
accessedVia
CustAcctCreditProfileReference
financialInstitutionName
financialInstitutionAccoutNumber
financialInstitutionAccountType
financialInstitutionContactName
financialinstitutionContactMedium
CustomerQuote/Offer(from C ustomer Interaction)
PartyRole(fromParty)
CustomerAccountCreditProfile
creditProfileID
creditProfileDate
validFor : TimePeriod
0..n11
includes
Customer
customerID
customerStatus
customerRank
0..n1
0..n1
requests
CustomerAccountTaxExemption
issuingJurisdiction
certificateNumber
validFor : TimePeriod
CustomerAccountBillCycle
billCycle
validFor : TimePeriod
CustomerAccount
accountID
accountName
accountType
accountStatus
0..n
0..n
0..n
0..n
usedAs
0..n0..n 0..n
references
0..n
0..n
1..n
0..n
1..n
stabilityMeasuredBy
0..n
1..n
0..n
1..n
posseses
0..n
1
0..n
1exemptedFromTaxesVia
0..n1
0..n1
receivesABillDuring
Figure 16 - Customer Shown As An Extension of Party Role (source: TM Forum)
5.2 The What Product, Service, and Resource
5.2.1 Overview
Note: The contents of this chapter are a modified extract from the
TeleManagement Forums Shared Information/Data (SID) Model document
GB922 Addendum 1P and the OSS/J Inventory API (JSR 142).
This chapter answers the question what? and deals with products offered
by an enterprise, the services through with a product is realized or
supported, and the resources utilized by products and services.
COM-WP-CBE_concepts.1.2.doc page 33 / 73
8/3/2019 COM WP CBE Concepts.1.2
34/73
OSS through JavaTM Initiative
Who (Party)
Why (Reason)
What (Thing)
When (TimePeriod)
Where (Location)
Figure 17 - Showing How Products, Services, and Resources Fit In
Product, Services, and Resources are specializations of the Entity
Specification and Entity modeling concepts presented in the Core Business
Entity Modeling Concepts chapter of this paper.
Core what business entities are
Product Specification and Product
Service Specification and Service
Resource Specification and Resource
Each of these three pairs of business entities is described below, followedby a model that depicts how these business entities fit into part of the core
model. The three pairs of business entities are commonly referred to as
Inventory core business entities.
Operation business processes require information on planning, availability,usage and state of various products, services and resources. OSS
components such as Order Management, Service Impact Analysis, Planning
cannot be built without this knowledge. Therefore, inventory informationcannot be local to a specific component, but must be considered as
enterprise data, that although stewarded by specific OSS components, needs
to be shared across the enterprise. In emerging scenarios for e-business,
some information may also be shared across enterprises in a controlled way.
The variety of inventory information can be classified in three groups
defining three Inventory functions focused on products, services or
resources. Each function has its specific set of inventory entities andrelationships, its specific business logic and interacts with different subset
of OSS functions. However, all Inventory functions share commonabstractions (e.g. entities, associations, specifications) and common base
interaction model (e.g. queries based on traversal of relationships, atomic
update procedures etc.).
The Inventory functions are central part of an integrated OSS solution. They
provide storage of physical resources and configurations, network topology,
COM-WP-CBE_concepts.1.2.doc page 34 / 73
8/3/2019 COM WP CBE Concepts.1.2
35/73
OSS through JavaTM Initiative
logical resources, services, customer account information, products, etc.They also provide the business operations required by other OSS
components in order to query, monitor, assign and update the inventory
information.
The Inventory functions are described in the following sections.
5.2.2 Product Inventory
The main responsibility of the Product Inventory is to manage the Product
Catalog and keep track of the of product subscriptions. The Product Catalogdefines the product offering from marketing perspective and consists of
collection of product specifications. Each product specification describes a
product. Several product specifications may be defined for the same product
type. For example, the Product Catalog may define Gold, Silver and BronzeVPN products. Product specifications are associated with service
specifications, stored in the Service Catalog, thus capturing the relationshipbetween a product and the set of services bundled by this product.
Each subscription is captured in the Product Inventory through a product
instance associated with the corresponding specification in the catalog. The
product instance is also associated with the subscriber of the product and the
related subscriber account information.
The information stored in the Product Inventory is used by SLA
management, Trouble Ticketing, Billing and Customer Order Management
OSS/J APIs.
Product Inventory is part of the eTOM Customer Relationship Managementand Operations and Product Lifecycle Management processes.
5.2.3 Service Inventory
The main responsibility of the Service Inventory is to manage the Service
Catalog and keep track of planned, subscribed and provisioned services.
The Service Catalog captures the engineering view of the Service Providers
offering and consists of collection of service specifications. Servicespecifications define the services from an engineering perspective. Several
service specifications may be defined for the same service type. For
example the Service Catalog may define Gold, Silver and Bronze VPNservices. Service specifications are associated with resource specifications,
stored in the Resource Catalog, thus capturing the relationship between a
service and the set of resources supporting this service.
Each subscription is captured in the Service Inventory through a set of
service instances associated with the corresponding specifications in the
Service Catalog, the subscribed product, bundling these services and the
users (recipients) for these services.
COM-WP-CBE_concepts.1.2.doc page 35 / 73
8/3/2019 COM WP CBE Concepts.1.2
36/73
OSS through JavaTM Initiative
The information stored in the Service Inventory is used by SLAmanagement, Trouble Ticketing, Billing Mediation, Service Activation,
Service planning, Process Quality Management, Service Impact Analysis,
Service Problem Resolution, Customer Order Management, Provisioning
Control and Service Quality Management OSS/J APIs.
Service Inventory is part of the eTOM Service Management and Operations
and Product Lifecycle Management processes.
5.2.4 Resource Inventory
The Resource Inventory stores network and computing equipment, logical
resources and topology. This function keeps track of the physical and
geographical configuration of the network, equipment inventory (cards,
ports, etc.), physical connectivity, and logical connectivity of the different
network layers.
Resource Discovery components populate and synchronize the Resource
Inventory.
Data in the Resource Inventory is used by Provisioning Control OSS/J API
to design services and understand where capacity is available. It is also used
for root-cause alarm analysis and network activation.
Resource Inventory is part of the eTOM Resource Management and
Operations and Product Lifecycle Management processes.
The figure below depicts the Inventory core business entities along with
their relationship to Party, another core business entity.
COM-WP-CBE_concepts.1.2.doc page 36 / 73
8/3/2019 COM WP CBE Concepts.1.2
37/73
OSS through JavaTM Initiative
PartyValue...>>
ProductValue
(from product)
* *
+aggregatedProduct
*
productAggregatesProduct
+aggregateProduct
*
PartyRoleValue
1 0..*1 0..*
0..*
0..*
+subscribedProduct
0..*
+subscriber0..*ServiceValue
(from service)
0..*
0..*
+product
0..*
+service
0..*
productAggregatesService
*
*
+aggregatedService
*
serviceAggregatesService
+aggregateService*
0..*
0..* +deliveredService0..*
+recipient0..*
ProductSpecificationValue (from produ...
0..* 0..10..* 0..1
describes
** *
productSpecificationAggregatesProductSpecifiacation
*
ResourceValue
(from resource)
0..*
0..*
+service0..*
+resource
0..*
resourceSupportsService
* *+aggregatedResource *
resourceAggregatesResources
+aggregateResource*
0..*
0..*
+ownedResource
0..*
+owner0..*
ServiceSpecificationValue(from servi...
0..* 0..10..* 0..1describes
0..*
0..*
0..*
0..*
productSpecificationAggregatesServiceSpecification
*
*
*
serviceSpecificationAggregatesServiceSpecification
*
ResourceSpecificationValue (from resour...
0..*
0..1
0..*
0..1
describes
0..*
0..*
0..*
0..*
resourceSpecificationsSupportServiceSpecification
*
* *
resourceSpecificationAggregatesResourceSpecification
*
subscriberSubscribesProduct
ownerOwnsResource
Figure 18 - Inventory Business Entities
5.2.5 Use Cases
Exemplary use cases for Inventory Business Entities can be found in the
OSS/J Inventory API Specification (JSR 142).
5.3 The Where - Location
Note: The contents of this chapter are a modified extract from the
TeleManagement Forums Shared Information/Data (SID) Model document
GB922 Addendum 1L.
This chapter answers the question where? and deals with locations, such
as buildings addresses, geographic locations and so forth, where customers
are found, resources are situated, services are provided, and so forth.
COM-WP-CBE_concepts.1.2.doc page 37 / 73
8/3/2019 COM WP CBE Concepts.1.2
38/73
OSS through JavaTM Initiative
Who (Party)
Why (Reason)
What (Thing)
When (TimePeriod)
Where (Location)
Figure 19 - Showing How Locations Fit In
5.3.1 Disclaimer
This Location model is complex and has a number of subtleties. It providesa high level framework, explains broad concepts and gives illustrative
examples. Actual solutions for particular requirements will be dependantfactors such as
Country address standards
State/ country / province map standards
Service Provider network inventory addressing standards
Equipment vendor equipment naming & addressing conventions
Whether textual only or map based representations will be provided
It is expected that when this model is used in TeleManagement Forum
NGOSS Catalyst projects, the feedback will clarify its application & usage.
5.3.2 Overview
A Service Provider will be interested in the location of many things:
Where is the customer (more on this later)?
Where is our equipment?
Where is the fault and where is the nearest person who could repair theequipment?
Where did the cyclone pass (and what equipment may have been
affected)? Where is growth for this product?
Where can we expand our business operations?
Where are our service vans and the work sites (optimize workdispatch)?
Where (which shops) do we require products to be shipped?
Where do I send the bill for Customer Xs use of product Y?
Where do I need additional employees?
COM-WP-CBE_concepts.1.2.doc page 38 / 73
8/3/2019 COM WP CBE Concepts.1.2
39/73
OSS through JavaTM Initiative
Who owns this property (advise of digging) {note property may berented, i.e. customer living at property may not be owner}
Note that the business requirements will not just be Resource related but
will also be required by marketing, corporate strategic, etc processes.
In some cases, these locations will be well-defined points. In others, they
may be fuzzily defined regions of interest.
The Location model needs to allow us to answer questions like What is the
nearest network access point to the Customers location that can providethis product? Network, Customer and Product Capability should not just be
seen as separate location views.
5.3.3 Location
We will define location as a generic concept that can answer the questionWhere ?
A Location is an area, position, or portion of space that somebody or
something can be in; a location can also be a locality, a dwelling (or someother structure via associations to the Resource Model). In this model an
abstract modeling concept, used to generalize Location Coordinate, Address
and Geographic Area and Structure.
This model provides four options for locating something geographically:
With a defined (named) location {Structure} With an address {Address}
With a (named) area {Geographic Area}
With a survey location (geocode) e.g. a GPS position for an off-shoreoil rig {Location Coordinate}
The way that the Location hierarchy is defined is the key to this model. A
model that represents the high level concepts is shown below.
COM-WP-CBE_concepts.1.2.doc page 39 / 73
8/3/2019 COM WP CBE Concepts.1.2
40/73
OSS through JavaTM Initiative
ManagedEntityPlacement(from Managed Entity Business Entities)
LocationRole
LocationSpecification
Location
0..n
1
0..n
1
playedBy
0..n
0..n
0..n
madeUpOf0..n
0..n
1
0..n
1 definesManagedEntity
(from Managed Entity Business Entities)
0..n
0..n
0..n
0..n
identifiesPlacementOf
Roles include where the
ManagedEntity is located, (one or
more) Places at which the
ManagedEntity terminates (for entities
such as connections), where a
ManagedEntity (such as a
ProductOffering) is available, and so
forth
Address
GeographicArea
0..n0..n 0..n0..n
liesWithin
Structure
(from Resource)
LocationCoordinate
0..n
0..n
0..n
0..ngraphicallyPositions 0..n
0..n
0..n
0..ngraphicallyPositions
0..n0..n
0..n0..n
graphicallyPositions
Figure 20 - Initial Location Model
A location is a location that can be represented graphically. By definition
then, a locations attributes includes some type of coordinates that facilitate
the locations graphical positioning.
An address is a structured textual way of describing how to find a location,geographic area, or structure. It is usually composed of an ordered list of
names based on context specific rules.
A geographic area is a location that has (existing, planned, or former) thingsof interest to an enterprise. Things of interest include products, services, and
resources. Characteristics include associated parties (property owner,
property lessee, and so forth).
A structure is a physical resource that may be considered a location. A
structure is a set of inter-related parts (resources) that function as a whole.
Entity Specifications in the form of Location Specifications are used in thispart of the CBE model also. Location Specifications specify such things as
address formats, such as Australian and European formats, as well as the
way in with geographic areas can be aggregated, such as a city in a state in a
country.
APIs that can employ this CBE include but is not limited to the Customer
Order Management API (the locations where product offerings are to be
installed), Activation API (where is the product, service, or resource that isto be activated), Trouble Ticketing API (where is the trouble), and the Fault
Monitoring API (where did the fault occur).
COM-WP-CBE_concepts.1.2.doc page 40 / 73
8/3/2019 COM WP CBE Concepts.1.2
41/73
OSS through JavaTM Initiative
5.4 The When and the Why Business Interaction
5.4.1 Overview
Note: The contents of this chapter are an extract from the TeleManagement
Forums Shared Information/Data (SID) Model document GB922Addendum 1BI.
This chapter answers the question when and why? and deals withcommunications, activities, and agreements that involve products, services,
and resources found at locations, such as buildings addresses and so forth.
Who (Party)
Why (Reason)
What (Thing)
When (TimePeriod)
Where (Location)
Figure 21 - Showing How Interactions Fit In
In the course of doing business a service provider interacts with individuals
and organizations (or parts of organizations). Interactions also includeactivities and communications between systems and between systems and
parties. These interactions take the form of requests, responses,
notifications, agreements, and commands. The figure below depicts the
various types of business interactions.
COM-WP-CBE_concepts.1.2.doc page 41 / 73
8/3/2019 COM WP CBE Concepts.1.2
42/73
OSS through JavaTM Initiative
Request Response Notification
BusinessInteraction
interactionDate
interactionDescription
interactionDateComplete
interactionStatus
interactionID
name
0..n0..n 0..n
references
0..n
Agreement(from Agreement)
Figure 22 - Types of Business Interactions (source: TM Forum)
Individuals, organizations, and systems, and so forth involved in
interactions are collectively referred to as business participants. In fact, a
business participant may be a party playing a certain role or a resourceplaying a role, such as a system or piece of equipment. During an
interaction, a party can play different roles as a business participant. For
example, Bob Smith, a party playing the role of a customer, requests
information about cable modem service from Joe Jones, a party playing therole of a customer service representative. The figure below depicts the
relationship that business participants have with all types of interactions. In
this example, the type of interaction is an inquiry request. In fact, all types
of interactions participate in the relationships described in this section. Thisis illustrated by the examples used through this section.
A number of APIs can take advantage the Business Interaction CoreBusiness Entity. For example, an alarm is a type of notification created as
the result of an alarm being sensed by a fault monitoring process. The Fault
Monitoring API is used to communicate this to an SLA process. The SLAprocess may recommend a rebate be issued customer base on an SLA in
place with the customer. The recommendation is communicated to a billing
mediation process via a rebate notification type of interaction via the SLA
API.
COM-WP-CBE_concepts.1.2.doc page 42 / 73
8/3/2019 COM WP CBE Concepts.1.2
43/73
OSS through JavaTM Initiative
PartyRole(fromParty)
BusinessInteraction
interactionDate
interactionDescription
interactionDateComplete
interactionStatus
interactionID
name
BusinessParticipant0..n 0..n0..n 0..ninvolves
BusinessParticipantType
PartyRoleType(f rom Party)
classifies
1..1
0..n
ResourceRole(from Resource)
ResourceRoleType(from Resource Specification)
Figure 23 - The Relationship Between Business Interactions and Business Participants
(source: TM Forum)
As described in the example above, the inquiry request type of interaction
from Bob Smith involves a product offering that is made available by a
service provider. The figure below depicts the involvement that products,
services, and resources have with all types of interactions.
COM-WP-CBE_concepts.1.2.doc page 43 / 73
8/3/2019 COM WP CBE Concepts.1.2
44/73
OSS through JavaTM Initiative
BusinessInteraction
interactionDate
interactionDescription
interactionDateComplete
interactionStatus
interactionID
ProductOffering(from Product Specification)
Product(f rom Product )
ProductSpecification(from Product Specification)
Service(from Service)
ServiceSpecification(from Service Specification)
Resource(from Resource)
Res ource Specification(from Resource Specification)
BusinessInteractionItem
quantity
action
1 1..n1 1..n
comprises
0..1
0..n
0..1
0..n
involvedIn
0..n
0..1
0..n
0..1
involvedIn
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
Figure 24 - The Relationship Between Business Interaction and Products, Services,
and Resources (source: TM Forum)
Similarly, if Bob Smith already has cable modem, the request may referencean entity, such as a product, provided to Bob. Product offerings obtained by
a customer are called products.
During the interaction, Bob Smith may also provide information about thelocation, for example address, of his cable modem. Therefore, as shown in
the figure below, an interaction also can involve one or more addresses.
COM-WP-CBE_concepts.1.2.doc page 44 / 73
8/3/2019 COM WP CBE Concepts.1.2
45/73
OSS through JavaTM Initiative
BusinessInteractionLocation(fromBusiness I nteraction)
BusinessInteractionItem
quantity
action
0..n
0..n
0..n
+specifiesTheLocationFor
0..nBusinessInteraction
interactionDate
interactionDescription
interactionDateComplete
interactionStatus
interactionID
name
1 1..n1 1..n
compriseOf
Location(f rom Location)
0..n
0..n
0..n
+specifiesTheLocationFor
0..n
Figure 25 - The Relationship Between Business Interactions and Locations (source:
TM Forum)
In summary, a business interaction involves a number of other business
entities, including product offerings, products, locations, and business
participants.
By using the concept of a business interaction, each of its various types,
such as agreement and notification, can inherit the interactionsrelationships, attributes and behaviors without having to explicitly show
these for each type. For example, it would be quite redundant and unstable
to show an agreement and a notification, and a request, and a response, anda command each participating in relationships to parties, locations, entity
specifications and entities. What would happen if this was done and anothertype of interaction was discovered?
The full Interaction model is shown if the figure below.
COM-WP-CBE_concepts.1.2.doc page 45 / 73
8/3/2019 COM WP CBE Concepts.1.2
46/73
OSS through JavaTM Initiative
BusinessInteractionLocation
Product
(from Product )
ProductOffering
(from Product Offering)
ProductSpecification
(from Product Specification)
ServiceSpecification(from Service Specification)
Service
(from Service)
Resource Specification
(from Resource Specification)
Resource(from Resource)
BusinessInteractionRole
interactionRole
BusinessInteractionType
Location
(from Location)
CustomerAccount(from Customer)
BusinessParticipant
BusinessInteractionItem
quantity
action0..n
0..n
+references
0..n
0..n
0..n
0..n
+specifiesTheLocationFor
0..n
0..n
0..1
0..n
0..1
0..n
involvedIn
0..1
0..n
0..1
0..n
involvedIn
0..n
0..1
0..n
0..1
involvedIn
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
0..n
0..1
involves
0..n0..n 0..n0..n
ofInterestTo
BusinessInteraction
interactionDate
interactionDescription
interactionDateC omplete
interactionStatus
interactionID
na