2013
IRI (OSS) High Level Design Document
Copyright © 2013 CloudBPO –
All rights reserved
IRI (OSS) High Level Design Document
2013
Contents
1. Design View ............................................................................................................................................... 1
2. High Level flow diagram ........................................................................................................................ 2
3. IRI (OSS) Service Layer (Development perspective):............................................................................. 3
4. Application Flow........................................................................................................................................ 4
4. 1 IRI (OSS) High-Level Entity Relationship Diagram / Data Flow Diagram: ........................................... 4
4.2 Customer / Supplier OSS Data: ........................................................................................................... 5
4.3 CDRs Data:........................................................................................................................................... 5
4.4 Rules Data: .......................................................................................................................................... 5
4.5 Intelligent Routing Engine: .................................................................................................................. 6
4.6 Routing / Re-Routing Database: ......................................................................................................... 6
5. Technology Selection: ............................................................................................................................... 7
6. Architecture justification .......................................................................................................................... 7
Copyright © 2013 CloudBPO – All rights reserved |
IRI (OSS) High Level Design Document
2013
1. Design View
We have developed the application on SPRING MVC, so it is a very modular as we have three layers.
1. Presentation layer
2. Business Logic layer
3. Database layer
Model–view–controller (MVC) is a software architecture pattern that separates the representation of
information from the user's interaction with it. The model consists of application data, business rules,
logic, and functions. A view can be any output representation of data, such as a chart or a diagram.
Multiple views of the same data are possible, such as a pie chart for management and a tabular view for
accountants. The controller mediates input, converting it to commands for the model or view. The central
ideas behind MVC are code reusability and separation of concerns.
Copyright © 2013 CloudBPO – All rights reserved
1
IRI (OSS) High Level Design Document
2013
2. High Level flow diagram
Following diagram shows the IRI (OSS) flow at a very high level. This shows different flows across the
main components of IRI (OSS).
Copyright © 2013 CloudBPO – All rights reserved
2
IRI (OSS) High Level Design Document
2013
A package diagram in the Unified Modeling Language depicts the dependencies between the packages
that make up a model.
Following are the 2 package diagram of IRI (OSS) that we have implemented so far, each package has got
a number of classes, which can be accessed via source code.
3. IRI (OSS) Service Layer (Development perspective):
In the below mentioned figure you can get a complete idea. Service package is the core package that uses
lots of other classes. We have followed a typical the tier approach, we have written very modular code so
that it can be used for extension easily.
Data Access Object (DAO) is for data excess, it contains queries and it is the class that plays with
MySQL Database.
Copyright © 2013 CloudBPO – All rights reserved
3
IRI (OSS) High Level Design Document
2013
4. Application Flow
4. 1 IRI (OSS) High-Level Entity Relationship Diagram / Data Flow Diagram:
Following is a diagram that shows the basic entities present in the system at the level of database as
well as it shows the Flow of Data Between these Entities.
The Basic Entities available in the database can be categorized into following major categories:
-
Customer / Supplier OSS Data.
-
CDRs Mediated Data.
-
Rules Data.
-
Intelligent Routing Engine Data.
Copyright © 2013 CloudBPO – All rights reserved
4
IRI (OSS) High Level Design Document
-
2013
Routing / Re-Routing Data.
These entities can be explained as under:
4.2 Customer / Supplier OSS Data:
Customer / Supplier OSS data will contain all the basic entities that we need to analyze and compare the
customer date with that of supplier. The same data will also help us in binding different QoS and Cost
Rules with these entities i.e. Customer and Supplier. This data will contain following basic information:
-
Customer / Supplier Information.
-
Customer / Supplier IPs.
-
Customer / Supplier call sources and End Points.
-
Customer / Supplier Prefixes.
-
Customer / Supplier Rates.
4.3 CDRs Data:
CDRs data will contain all those entities that will be entered into the system via mediated CDRs and will
be used in generation of QoS statistics at different levels.
This will also contain Analytics Data after processing from CDRs at different levels as mentioned below:
-
Country Code specific Statistics.
-
Dial Code Specific Statistics.
-
Supplier Specific Statistics.
-
Routes / Pools specific statistics.
4.4 Rules Data:
This data set will contain both the type of Rules i.e. QoS and Cost Rules available in form of the template
as well as after being applied on different routable entities like Suppliers, Region / Dial codes, Pools etc.
Following will be the basic information contained in this data set:
Copyright © 2013 CloudBPO – All rights reserved
5
IRI (OSS) High Level Design Document
-
-
2013
Cost Based Rules
o
LCR Rules.
o
LLCR Rules.
o
Gross Margin Rules.
QoS Based Rules:
o
ACD.
o
ASR.
o
NER.
o
MOS.
o
PDD
These Rules will be applied at different level and will be used for verification by Routing and Analytics
Engine to Detect Anomalies. Following are the levels where these rules will be bonded:
-
Suppliers.
-
Countries / Dial codes.
-
Routing Stacks / Pools. ( Currently Available and implemented)
-
Routes.
4.5 Intelligent Routing Engine:
This Engine will be containing the rerouting generated as a result of Analytics; it will contain following
data entities:
-
Re-Routing Jobs.
-
Alerts Data.
4.6 Routing / Re-Routing Database:
This will be the final component of the system that will be the replica of actual Routing information on
the switch. This will be used to identify the current routing on the switch and place a Re-Routing job
after analytics in line with the current Routing.
Copyright © 2013 CloudBPO – All rights reserved
6
IRI (OSS) High Level Design Document
2013
5. Technology Selection:
We decided to develop our application on JAVA Enterprise Edition because it is open source and plat
form independent. It follows the principle of “CODE ONCE, RUN EVERYWHERE”. The users of IRI (OSS)
(Intelligent Routing in Inter-carrier (class 4) operation support systems) won’t have to buy license as we
are not developing on DOT NET.
On the back-end we could have used any database but again we did choose open source in order to
keep things simple. We are using, MySQL and HIBERNATE (ORM) in our application so that if any
customer wants to use ORACLE or MSSQL; they can use it anytime with a very small integration effort.
We are using SPRING MVC framework in Java. It actually gives us very modular approach, our services
and data access objects are written independently so that the source code of IRI (OSS) [Intelligent
Routing in Inter-Carrier (Class4), Operation Support Systems (OSS)] can be integrated and re-used
anywhere we want.
6. Architecture justification
We have 12 servers in all. Each server has its own usage.
Production Server: This is the server where our live application is running
Staging Server: This is where we keep the replica of our live system, after testing the build this is
the machine where we deploy the build, check it and then move it on the production server.
Testing Machine: A server where the Quality Assurance Team tests the software.
Development machine: The developers commit the source code and we are using this machine
to keep the source code. This is where we store the source code and we have installed SVN
Server on this machine.
We have a complete back-up of our application on the staging Server, if the system (product server)
goes down anytime we can use the staging server (because it is the replica of live machine). The same
build is working on the staging server so it is safe to use it as the back-up machine.
Copyright © 2013 CloudBPO – All rights reserved
7
IRI (OSS) High Level Design Document
2013
We will create master slave on two of our servers, we will create master on Production machine and
slave on staging machine, so that along with product we can have the data backup as well.
Copyright © 2013 CloudBPO – All rights reserved
8
