EL Platform Architecture

ESB Architecture description
for
Enhanced Living Platform

Version 1.0
Prepared by:
Members:
03/03/2015
ESB architecture description for the Enhanced Living Platform
Page 1
Table of Contents
1. Introduction ............................................................................................................................. 2
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
Purpose .........................................................................................................................................2
Intended Audience and Reading Suggestions ..............................................................................2
Project Scope ...............................................................................................................................2
Product Perspective ......................................................................................................................3
Product Features...........................................................................................................................3
Unified User management............................................................................................................4
Unified Billing system .................................................................................................................4
Operating Environment ................................................................................................................5
Technical requirements ................................................................................................................6
2. EL Service Delivery Architecture ....................................................................................... 7

2.1
OSS / BSS Layer ..........................................................................................................................7
2.2
Service Management Layer / Subscriber service control ............................................................9
2.3
Content/ Service Layer...............................................................................................................11
2.3.1 Scenario 1 - Service Virtualization ............................................................................................11
2.3.2 Scenario 2 - Service Enablement ...............................................................................................12
3. Message processing/ Message Flows/ Service integration.................................................. 13

3.1
3.2
3.3
Message Processing/ Proxy........................................................................................................13

Message Flow Architecture .......................................................................................................16
Service Integration Module ........................................................................................................18
4. Service Configuration, Composition, Monitoring .............................................................. 21

4.1
4.2
4.3
Service Configuration Module ...................................................................................................21

Service Composition Module.....................................................................................................25
Service Monitoring Module .......................................................................................................28
5. EL Platform - Roles and Profiles ......................................................................................... 30

5.1
5.2
5.3
5.4
5.5
5.6
5.7
End User/ customer - my account Use case ...............................................................................30

Service providers Admin Use case ...........................................................................................31
Provisioning Users Use case ......................................................................................................32
Admin/ Root Users Use case .....................................................................................................33
Dataflow diagrams .....................................................................................................................35
Abstraction Layer diagram.........................................................................................................36
Wireframes for the project .........................................................................................................37
6. External Interface Requirements......................................................................................... 39

6.1
6.2
6.3
6.4
6.5
6.6
User Interface .............................................................................................................................39

Hardware Interfaces ...................................................................................................................39
Software Interfaces ....................................................................................................................39
Communications Interfaces........................................................................................................40
Session Management..................................................................................................................40
Data structures ...........................................................................................................................40
7. Other Nonfunctional Requirements .................................................................................... 42

7.1
7.2
7.3
7.4
7.5
7.6
Performance Requirements ........................................................................................................42

Privacy Requirements ................................................................................................................42
Security Requirements ...............................................................................................................42
Software Quality Attributes .......................................................................................................43
Database Requirements ..............................................................................................................44
Reuse Requirements ...................................................................................................................44
Page 2
1. Introduction
1.1 Purpose
The purpose of this document is to describe the software architecture of the Enhanced Living
platform (based on PHP/ MySQL), i.e. complex ESB/ SOA solution which will provide a vast set of
different services for the End users and Vendors:
-
Provisioning / Self Provisioning / Billing;
Entertainment (IPTV, VOD, MOD, Radio);
Conference Bridge (Video Call);
Home Control (Light, Shadow, Clima);
City Services (Transportation, Ticket ordering, Delivery etc.).
This document will outline all of the necessary information for the platform description.
1.2 Intended Audience and Reading Suggestions

The intended audience for this document is Developers team, the Project sponsor, and the
Team advisor. Throughout the rest of this document - the writing will be broken up into sections
for: Project Description, Global Architecture of EL Platform, Profiles and Roles in the EL platform,
Layers and Modules in the EL platform, Low-level Controller, and Non Functional Requirements
(such as Performance, Safety, Security, Quality of the product).
1.3 Project Scope

This project is to describe Enhanced Living platform, that is a software architecture model
used for designing and implementing communication between mutually interacting software
applications in a service-oriented architecture (SOA). As software architectural model for
distributed computing - it is a specialty prototype of the more general client-server model and
promotes agility and flexibility with regard to communication between applications.
The software environment used for development is the PHP/ MySQL platform and the developed
platform layout & functionality must be Firefox, Chrome, IE, Safari compatible. The platform will
be managed by several Apache-based servers.
Page 3
1.4 Product Perspective

Our Enhanced Living platform is an integration architecture that will allow communication
via a common communication bus that consists of a variety of point-to-point connections between
providers and users of services. It also consist an architecture pattern that enables interoperability
between heterogeneous environments, using service orientation.
As ESB architecture, our platform will be implemented in software that operates between the
business applications, and enables communication among them. Ideally, the EL platform will be
able to replace all direct contact with the applications on the bus, so that all communication takes
place via the ESB. To achieve this objective, the platform must encapsulate the functionality offered
by its component applications in a meaningful way. This typically occurs through the use of
an enterprise message model. The message model defines a standard set of messages that the ESB
transmits and receives. When the ESB receives a message, it routes the message to the appropriate
application. Often, because that application evolved without the same message model, the ESB has
to transform the message into a format that the application can interpret.
As an inspiration for our Enhanced Living platform - we were guided by other ESB
platforms: Open ESB, Mule etc.
1.5 Product Features

This product will allow users to be able to access/ follow the Enhanced Living Platform
Services from their PCs. Any PC with browser (Firefox, Chrome, IE, Safari) will be able to open
and run the content of the platform. This product will offer functionalities based on PHP/ MySQL
technology.
The Enhanced Living platform will allow users-clients to order and obtain different types of
services: Video-on-demand, Music-on-demand, Home security, Delivery, Home control etc. The
different Modules of the EL platform are subject to this Architecture description.
Page 4
1.6 Unified User management

The User management system of the EL platform will be configurable and adjustable
according to the number of customers and can easily work for hundreds of thousands items. The
user management system will be multilaterally convergent, e.g. it will allow management of
different types of customers in one system - tariff as well as pre-paid customers. The system will
support creation of a customer hierarchy. It means that the customer structure will not be flat and
more user accounts can be managed through one customer account. This part of the system will also
support all payment types and their history. Read-outs will be associated to the customer data
together with billed items and service usage history.
Subscriber management function will implement the application logic and the database as
one-to-one connected in the same physical node (co-located database). Thus, there will be unified
and optimized subscriber management for each User access & Service type.
Well allow the subscribers to manage and personalize their experience right from their
mobile devices without the need for costly customer service intervention. Well enable the vendors
(service providers) to offer their subscribers a personalized and interactive on-device experience
while at home or while roaming via Smartphone App, USSD, SMS etc. Our User Interaction and
Self-Care Solution will offer a range of targeted services including balance query, quota sharing,
parental controls, usage tracking, notifications, service discovery, add-on and top-up purchasing.
Benefits will be:
-
Enhanced subscribers' experience through easy service access, greater choice and greater
control - all in real-time.
Increased subscribers' trust with real-time usage notification especially while using video and
data services.
Increased profitability through faster time to revenue for new services through on-device
service discovery, purchase and activation.
Reduced costs by removing the need for customer service intervention.
1.7 Unified Billing system

The billing system of the EL platform will be based on convergent billing system.
Convergent billing includes a billing module for service usage calculation, discount module and the
Page 5
invoice creation module. Even here, a remarkable system convergence can be seen because
everything works independently on the service type used. Services will be always handled according
to one common template whether it is video materials, multimedia services or data. Billing will be
executed either flexibly in real time or in batches. Benefits of real time billing are that it will avoid
mistakes and potential fraud. The system will support parallel execution of transactions; the level of
parallelism can be set.
Therefore, when it comes to convergent invoicing and bill presentment, our solution will
offer maximum flexibility:
-
Present all content services on a single convergent bill.
Supports multi-level customer hierarchies to reflect departments and budget centers with
corporate invoicing schemas.
Flexible invoicing and bill run cycles (per second transaction cycles); daily, weekly, monthly,
yearly, or anniversary.
Support for prepaid and postpaid services on a single convergent bill.
HTML, TXT, PDF, E-mail delivery options.
A/R management with indexed historical invoice archive for payment application.
Invoice detail summarized by tiers (customer account, sub-account, corporate groups).
Customizable invoice templates with tokens to place accounting information anywhere.
Payment and Credit disbursement options for split bills.
Scheduled bill cycles or on-demand invoices.
1.8 Operating Environment

The software will run on the server side as well, particularly on Apache/
Linux or Windows server. IIS will also be supported. Middleware: we need at least PHP version
5.5. Database: MySQL 5.5.
A modern browser is required to use the EL platform. We recommend a current version of
Internet Explorer, Firefox or Chrome. But it can also run smoothly on the current versions of Safari,
Internet Explorer 7 and higher, Opera 10 and higher. There will be mobile app developed as
companion to the EL platform.
Page 6
All components of the software will be PHP/ MySQL-based. The MySQL DBMS offers a
useful suite of methods to ensure data consistency. Primary key constraints forbid duplicate values
in one or more columns of a table. Foreign key constraints (using the InnoDB storage engine) ensure
consistency of tuple (row) references across tables. Table check constraints are not supported, nor
are general SQL assertions.
1.9 Technical requirements

The desktop version should be tested on Windows/ Linux/ Mac OS with multi-browser
support (IE, Firefox, Chrome, Safari etc.), and it should be responsive.
The mobile version should be tested on iOS/ Android/ Windows Mobile with multi-browser
support. There should be responsive + mobile version of the platform.
IP logger should be implemented and it will record each users IP address.
The system is dependent upon the Apache Web Servers. The system will also use an LDAP
authentication server.
The requirement for responsiveness of the platform means that it will adapt its layout on
different screens/ viewing environment (PC, tablet, smartphone) and the developers should use tools
such as proportion-based grids, flexible images, CSS3 media queries and @media rule.
Page 7
2. EL Service Delivery Architecture

This section outlines the (global) service delivery architecture of the Enhanced Living
platform. The main three modules / layers of the service delivery architecture are:
-
OSS / BSS (Operation System Support/ Business System Support).
Service Management Layer / Subscriber service control;
Content/ Services Layer.
CSPR
CWI
CHI
End-Customer
Self-Provision
& Registration
Customer
Web
Interface
Customer
Handling
Interface
SPI
Service
Provider
interface
User Profile / Address / Products..
Service interface
SMS
Service
Monitoring
Statistics
STP
Service Template Provisioning (Product)
Entertai
nment
Home
Control
Living
Service
Free
Service
Network / Content
2.1 OSS / BSS Layer
As the number of connected devices will get higher in our EL platform, the need for
automated and autonomous behavior in processes such as configuration and provisioning will
become more significant. It means to be able to remotely configure, provision and update millions
of devices without impacting the network supports scaling while maintaining control over opex.
As a result of virtualization, we, our service vendors and even our subscribers (in the future)
should be able to create instances of our/ their services and networks on demand. So, to enable fully
functionality of our EL platform, we will need the OSS/BSS layer, to fully address the challenges
Page 8
created by certain aspects of network evolution, including virtualization, big data, M2M and
personalization.
To achieve this layered approach and thereby bridge any gap between business needs and
OSS/BSS capabilities, we will need to adapt our OSS/BSS system to follow three core concepts:
- Abstraction business process logic is expressed generally and once only, so that it can be
reused in many potential business process contexts;
- Componentization software is designed as reusable objects or service components
following service-oriented architecture (SOA) principles;
- Exposure data and information models will be available for use by many different
applications, by means of a catalog or other information exposure framework.
Following these concepts, the bundling of service and product components will be handled
in a unified way. Eligibility rules and restrictions on which service and product combinations will be
available for different user categories will be similarly supported in a unified manner and made
known to all applications needing that information.
In the OSS/ BSS layer we will put these three modules of the EL platform:
Subscriber Management:
-
Creates a subscription plan in the Billing API and create and send a campaign for the
subscription plan in the Send API.
Creates Subscription for each account in the Billing API and send subscription
details to customers via email using the Send API;
Page 9
Master Database Servers:

-
Store the settings, database objects, and data required by the Master Data Services
system.
Contain staging tables that are used to process data from source systems.
Provide a schema and database objects to store master data from source systems.
Support versioning functionality, including business rule validation and e-mail

notifications.
Provide views for subscribing systems that need to retrieve data from the database.
Billing System: handling the payments from Subscribers and payments to Vendors:
-
Retrieve Open Invoices from the Billing API on a daily basis;
Check if the appropriate client exists in Clients DB, if not create the client and then;
Create invoices for the relevant clients in the Clients API.
Retrieve invoice from Clients API and send invoice by email to client using the Send
API.
Retrieve charges for invoices from the Billing API;
Notify charge details to customers using the Send API.
Create payments in the Clients API.
2.2 Service Management Layer / Subscriber service control

Service Logging and Monitoring
EL platform will allow the following capabilities for auditing and monitoring services:
Gather statistics about message invocations, errors, performance characteristics, messages

passed and SLA violations;
Send SLA-based alerts as SNMP traps, enabling integration with third-party ESM solutions;
Support for logging selected parts of messages for both systems operations and business
auditing purposes;
Search capabilities by extracting key information from a message and use as it as a search
index.
Page 10
The EL platform Console will provide a cluster-wide view of service status and statistics. Both
business services and EL platform proxy services will be monitored, as well as response times,
message counts, and error counts.
Monitoring API will be used as a polling interface for the retrieval of metrics. This API will
enable integration with management partners and enables customers who have their own monitoring
consoles to display metrics that can be used for performance analysis.
Custom Operations Console
The EL platform Console will support tasks performed by users in the operator (Integration
Operator) role. It will provide operational functions and settings that allow users to easily search for
resources using the new Smart Search functionality, monitor SLA alerts, pipeline alerts, logs,
reports, turn tracing on and off, and to enable and disable services.
Users can readily distinguish between SLA and pipeline alerts since the metrics reported for
each will be distinguished on the console and via the JMX monitoring APIs. Service-level flags and
global flags help control alerting (SLA & pipeline), reporting, and logging. Operators will have
privileges to edit operational settings, create new SLA alert rules, and create and edit alert
destination resources.
Service Versioning
EL platform will provide the ability to deploy new versions of services and will allow us to
have multiple versions of message resources such as WSDLs and schemas. Versions can include
changes to the WSDL, the message schema, the headers, and the security parameters.
ESB/ Subscriber
Service Control
Middleware/
Stream control
Services/
VOD, MOD,
Service Level Agreements

In the EL platform, monitoring statistics will be gathered locally and aggregated centrally.
SLA rules will be run against aggregated data and the system raises alerts, following which services
can be enabled or disabled. Administrators can set service level agreements (SLAs) on the following
attributes of proxy services:
Average processing time of a service;
Page 11
Processing volume;
Number of errors, security violations, and schema validation errors;
Administrators can configure alerts for SLA rule violations.
2.3 Content/ Service Layer

This module will allow services to be installed and operated directly on the EL platform and
is usually required if the ESB is based on an application server. Service Container provides one or
more containers in which the services are installed and service lifecycles managed. It offers the
service access to technical cross-sectional functions, such as transactions and security.
Household
Network
Devices
Unified
Service
Portal
Services/
Applications
The Component Model can provide an abstract component model, such as Java EJB, Java
Spring Framework, or Microsoft COM+, on the basis on which the services are created.
2.3.1 Scenario 1 - Service Virtualization
Service consumers tend to prefer hard-wiring the actual endpoints of services, particularly in
BPEL processes, because it's easy to perform with the tools that are provided. However, changes to
the address of a server during runtime must not be able to produce changes that require
redeployment at the service consumer side. An elegant solution around this problem can be provided
by the use of an ESB to virtualize endpoints. The Figure below illustrates this scenario with a
service provider that is providing a Web service interface that is no longer being directly used by the
service consumer but by the ESB instead. The ESB can deliver the interface exactly as is to potential
service consumers.
Any
Page 12
changes that need to be made to endpoint addresses can be easily implemented in the configuration
of the EL platform so that service consumers can continue to run as before. However, the EL
platform will need to be able to be incorporated into an existing message flow. The service
virtualization will also allow the use of the EL platform's monitoring functions that extend to service
statistics, so that SLA compliance can be checked and the appropriate actions configured if
noncompliant. Service virtualization can be performed if the service provider makes a change to the
service contract but doesn't want to impact the service consumer. In this case, a simple
transformation of the exchanged messages can resolve the issue.
2.3.2 Scenario 2 - Service Enablement
When services with functional interfaces are incorporated, a situation will arise in which
service consumers and service providers do not speak the same language at the protocol level. The
Figure below depicts two service providers that are technically offering the same service, since one
provides a SQL interface and the other a FTP interface. The EL platform can be used as a protocol
converter to leave the interfaces untouched, since it provides the means to ensure that the defined
interfaces are used.
Similar to Scenario 1, the EL platform can ensure that no subsequent changes need to be made on
either the service consumer or service provider side, if the communication protocol were to change
in the future.
Page 13
3. Message processing/ Message Flows/ Service integration

3.1 Message Processing/ Proxy
The following high-level architecture diagram illustrates the EL platform and its functional
subsystems: service management, message brokering, configuration framework, security and
transport layer, and messaging protocols:
Subscriber Profiles
Billing / Accounting
Service Profiles
Subscriber Services
Controller
Client Access Control
ESB / Middleware Interface
External WEB Server

Access
The EL platform will provide message delivery services, based on standards including
SOAP, HTTP and Java Messaging Service (JMS). It will be designed for high-throughput,
guaranteed message delivery to a variety of service producers and consumers. It will support XML
as a native data type, while also offering alternatives for handling other data types. EL platform will
be policy driven and will enable to establish loose coupling between service clients and business
services, while maintaining a centralized point of security control and monitoring. It will store
persistent policy, proxy service, and related resource configurations in metadata, that can be
customized and propagated from development through staging to production environments required.
The message-brokering engine can access this configuration information from its metadata cache.
EL platform will be an intermediary that processes incoming service request messages,
determines routing logic, and transforms these messages for compatibility with other service
consumers. It receives messages through a transport protocol such as HTTP(S), JMS, File, and FTP,
and sends messages through the same or a different transport protocol. Service response messages
follow the inverse path. The message processing by EL platform will be driven by metadata,
specified in the message flow definition of a proxy service.
The processing of messages can occur in the following sequence of events:
1. Processing of the inbound transport;
Page 14
2. Message flow execution;

3. Processing of the outbound transport.
After a message is sent to an endpoint (either a business service or another proxy service), the EL
platform will process the response message in a similar model as that described in the preceding
sequence of events.
The binding layer: packs and unpacks messages as necessary, handles security for messages,
hands messages off to start the message flows (request and response).
The inbound transport layer will be the communication layer between client services (or
service consumers) and the EL platform. It will be responsible for handling communication with the
service client endpoint and acts as the entry point for messages into the platform. The inbound
transport layer will primarily deal with raw bytes of message data in the form of input/output
streams. It will provide support for compatible transport protocols, including HTTP(S), JMS, FTP,
File, and E-mail. It will not be involved in data processing, but it will be responsible for returning
response messages to service consumers and handling of meta-data for messages, including
endpoint URIs, transport headers, etc.
The outbound transport layer will be responsible for the communication between business
services (or service producers) and the EL platform. It will be responsible for moving messages
from EL platform to the business service or proxy service and for receiving the response from the
services. The message data, at the transport level, will be in raw bytes in the form of input/output
streams. The outbound transport layer will provide support for compatible transport protocols,
Page 15
including HTTP(S), JMS, FTP, File, and E-mail. It will not be involved in data processing, but will
handle meta-data for messages, including endpoint URIs, transport headers, etc.
Proxy services are a fundamental concept in the architecture of the EL platform. They are the
interface that service consumers use to connect with managed back-end services. Proxy services are
definitions of intermediary Web services that the Service Bus implements locally. EL platform will
allow configuration of a proxy service by defining its interface in terms of Web Services
Description Languages (WSDLs) and the type of transport it will use. Message processing logic will
be specified in message flow definitions when defining a proxy service.
A processing strategy determines how EL platform will execute the sequence of message
processors in the application. For example, when the message source is configured for the requestresponse exchange pattern, the platform will set the processing strategy to Synchronous, which
means that the entire flow will get executed on a single processing thread, thus ensuring that the
entire sequence of message processors executes, and the client receives a response, as expected.
By contrast, when the flow is configured for a one-way, non-transactional exchange pattern
(i.e., no response to the original message sender is required, and it isnt necessary to verify that all
steps in the flow have been completed), the EL platform will set the processing strategy to Queued
Asynchronous, which has the potential to raise flow throughput. Under this processing strategy, the
inbound endpoint will place the incoming message into the queue as soon as it is received, then will
close the receiver thread. When the message reaches the top of the queue, it resumes processing, but
this time on a different thread. By implication, this sort of processing does not qualify as
transactional end-to-end, because the transfer from one thread to the next means that the processing
cannot be rolled back if an exception is thrown.
Page 16
3.2 Message Flow Architecture

The implementation of a proxy service is specified by a message flow definition. The
message flow defines the flow of request and response messages through the proxy service. The
following four elements are used to construct a message flow:
A pipeline pair, one for the request and one for the response. The pipelines consist of a
sequence of stages that specify actions to perform during request or response processing.
A branch node to branch based on the values in designated parts of the message or message
context or to branch based on the operation invoked.
A route node used to define the message destination. The default route node is an echo
node that reflects the request as the response.
A start node.
At the simplest level, Flows are sequences of message-processing events. As the following
schematic illustrates, a message that enters a flow may be:
1. Validated (filtered),
2. Enriched (appended),
3. Transformed into a new format,
4. Processed by custom-coded business logic,
5. Logged to a database,
6. Evaluated to determine what sort of response gets returned to party that submitted the
original message.
The units from which Flows are constructed are known generically as Building Blocks. In general,
these correspond to XML elements within the application configuration file.
Page 17
The first building block in EL platform Flows will be a Message Source, which will receive
messages from one or more external sources, thus triggering a Flow instance. Each time it receives
another message, the Message Source will trigger another Flow instance.
Typically an Inbound Endpoint serves as a message source, although a streaming Cloud
Connector can perform this role as well. Sometimes the Message Source immediately places the
incoming message into a queue. This will allow the Message Source to close the receiver thread it
used to accept the message, and immediately open another thread to accept another incoming
message. The message just placed into the queue will wait until it reaches the head of the queue and
can be processed through the rest of the Flow. Since the message will be processed sequentially by
two distinct threads (with an intervening wait inside the queue), start-to-finish transaction
processing will not be possible.
Sometimes, a Message Source can accept incoming messages from multiple transport
channels. For instance, we can embed an HTTP endpoint and a Servlet endpoint into the same
Message Source. Or we can create a Message Source to receive both IMAP and POP3 mail. Either
embedded endpoint (i.e., transport channel) can trigger a Flow instance as soon as it receives an
incoming message.
EL platform flows will be flexible, so we can combine building blocks in many ways, often
to achieve the same result. For many use cases, however, certain message processors tend to fall into
loosely ordered patterns. For example, if we want to create an application that receives product
catalog requests from a Web page then sends a PDF of the catalog back to the client who submitted
the request. In addition, we want this flow to record the clients customer information to a database
and log the transaction so that we can keep track of how many of each kind of catalog have been
sent. Our flow will look something like this:
Page 18
We can embed the filter and the transformers inside the Inbound Endpoint, but placing them in
the main Flow sequence will make the sequence of events easier to read on the Studio
Message Flow canvas and in the XML-based application configuration file.
3.3 Service Integration Module

In the EL platform, service integration relationships will be implemented dynamically by
configuring policies and proxy services. The message brokering is given on the following figure:
Both, proxy services and business services invoked by proxy services, will be modeled as
services that have the following attributes:
Page 19
A set of concrete interfaces called ports (also called an endpoint), each with a transport
address and associated configuration. A set of ports constitutes load balancing and failover
alternatives for a business service. A proxy service has only a single port.
A single optional abstract interface which is the definition of the structure of message parts
in the interface, optionally broken down by operations. Operations are equivalent to methods
of a Java interface.
A single binding that defines the packaging of message parts in the abstract interface to a
concrete message.
Policies on Web Service Security (WS-Security).
The EL platform will support the following service transport protocols: EJB/RMI, E-mail
(POP/SMTP/ IMAP),File, (S)FTP, HTTP(S), JCA, JEJB, JMS (including MQ using JMS, and
JMS/XA), MQ (WebSphere MQ), SB (RMI support), SOA-DIRECT (Oracle SOA Suite), WSRM
(Web Services Reliable Messaging).
The EL platform will rely on WSDLs for the formal description of Web services. For Web
services, a WSDL describes what the Web Service's interface is, where it resides, and how to invoke
it. EL platform will define proxy services and business services in terms of two WSDL entities:
The abstract WSDL interface, which will define the operations in that interface and the types
of message parts in the operation signature.
The binding WSDL interface, which will define the binding of the message parts to the
message (packaging), and the binding of the message to the transport.
WSDLs can be imported into the WSDL repository using the EL platform Console. The EL
platform Console can also be used to resolve the references in the WSDLs, to ensure all schemas
and WSDLs are linked correctly. After WSDLs are stored in the repository, they will available for
use when adding proxy services and business services. The EL platform will use its own
representation of the interface for messaging services.
The EL platform will accommodate multiple messaging paradigms and supports the
following types of communication:
Synchronous request/response;
Asynchronous publish one-one;
Asynchronous publish one-many;
Page 20
Asynchronous request/response (synchronous-to-asynchronous bridging).
In sync/ async bridging, a synchronous client issues a request to an asynchronous provider. For this
pattern, EL platform will provide the capability to publish a message on one JMS queue and
configure a second JMS queue for the response, with a timeout value for listening for the response.
This type of service will appear as a synchronous service to the service consumer. Using
asynchronous request/response messages has these advantages:
No blocking by the request thread, removing thread management issues that can occur when
numerous blocking request/response invocations are made.
More reliable messaging.
The EL platform will use a metadata language called Message Format Language (MFL) to describe
the structure of typed non-XML data. The Format Builder tool will create and maintain metadata as
a data file called an MFL document.
Page 21
4. Service Configuration, Composition, Monitoring

The low-level layers and modules of the EL Platform are:
-
Service Configuration;
Service Composition;
Service Monitoring.
4.1 Service Configuration Module

Resource Organization
EL platform will have a robust resource configuration and organization framework for
creating, organizing and configuring resources and ensuring semantic integrity between resource
dependencies. It will provide features to rapidly test, deploy, and, reverse resource configuration
updates if required. EL platform will have a built-in Project Explorer that allows logical grouping of
platforms entities, allowing developers and administrators to better organize related parts of large
development projects.
EL platform resources can be organized into separate projects. Projects will be nonhierarchical, disjointed, top-level grouping constructs. All resources (such as services, WS-Policies,
WSDLs, XQuery transformations, etc.) can reside in exactly one non-overlapping project. Resources
can be created directly under a project or be further organized into folders. Folders may be created
inside projects or inside other folders and are similar to directories in a file system, with the project
level being the root directory. Descriptions can be added to all projects and folders to further
enhance navigation
Resources can be moved between projects or folders and can be renamed. Any EL platform
resource, project or folder can be cloned to create a copy of that resource with the specified target
identity. Cloning a project or folder copies all artifacts in the project or folder to a different location.
Resources that are located in one project can reference and use resources that are defined in other
projects. Dependencies will be preserved when resources are renamed and moved. All references to
a renamed or moved resource will be automatically adjusted. An additional capability of the Project
Explorer will be the ability to track which resources outside the current folder are referenced by
resources residing in it. Viewing these references will give both the location of the referenced
Page 22
resource (in the format of <project name>/<folder name>/<resource name>) and the type of
resource referenced.
Change Management
One of the most important features of the EL platform will be the Change Center, which will
be a key to making configuration changes inside the service bus. The Change Center has the unique
ability to lock its current configuration while changes are being made. This lets the service bus
continue to receive and process requests for services while configuration changes are being made in
the console. Additionally, changes being made to the configuration will not affect the current
configuration until they are "activated." Once this is done, the changes go live instantly and the
service bus immediately uses the new configuration. This way, ongoing changes can be made
without disrupting services.
If activated changes cause unpredictable, undesirable events, the Change Center will also
provide the capability to undo any changes made for any session. Task Details will provide
information on which resource was changed, who changed it, and when. An entire session or
individual changes within a session can be rolled back, enabling EL platform to roll the affected
configurations back to the prior state. Before we make modifications to resources in EL platform,
we must create a session. All modifications will be made using the EL platform Console in a given
session.
A session can be considered a sandbox environment in which changes are kept private to the user
making those changes. In other words, they are not visible to other concurrent users making
Page 23
modifications. Modifications made in a session are not deployed in the server until the session is
activated. Only one session can be active at any time and should only log into the EL platform
Console through one browser.
To compare a resource modified in a given session against the resource that is already
deployed to run time, we can temporarily exit the session, view the deployed resource, then reenter
the session and view the changed resource. All resources are visible in the session. The view of all
resources in a session is called the session view - it is a merged view of the unmodified deployed
resources and the resources modified in the current session. Therefore, the session view at any point
in time shows the configuration state if the session is activated at that point in time. The view of
resources outside any session is the view of the deployed resources.
All individual session modifications, individual session activations, and undo operations for
a session are performed in transactions to prevent data loss in the event of a failure. Sessions are
persistent and long running - the restart of a server does not result in the loss of active sessions. This
means that we can modify the configuration in a single session over a period of days (during which
time the server can be stopped and restarted) if necessary. Each user has their own session, and can
work in it independently without the need to lock other users out of the system.
We cannot activate a session if another user is already in the process of activating their
session. If another user is activating a session when we try to activate our session, the Activate
button will be disabled and we will have to wait until the other session is activated before we can
activate our session. In certain circumstances, the Activate button may not be disabled if we did not
refresh the page or if we are directly using MBeans. In this case, we will time out after a short while.
Administrators will have permissions to access other user's sessions and view ongoing changes,
make updates in those sessions, or discard them.
Service Discovery / UDDI registry
UDDI registries are used in an enterprise to share Web services. Using UDDI services helps
companies organize and catalog these Web services for sharing and reuse in the enterprise or with
trusted external partners. A UDDI registry service for Web services is defined by the UDDI
specification available (www.oasis-open.org).
UDDI registries are based on this specification, which provides details on how to publish
and locate information about Web services using UDDI. The specification does not define run-time
Page 24
aspects of the services (it is only a directory of the services). UDDI provides a framework in which
to classify vendors business, its services, and the technical details about the services, the user want
to expose.
Publishing a service to a registry requires knowledge of the service type and the data
structure representing that service in the registry. A registry entry has certain properties associated
with it and these property types are defined when the registry is created. Vendors can publish their
service to a registry and make it available for other organizations to discover and use. Proxy services
developed in EL platform can be published to a UDDI registry. EL platform can interact with any
UDDI 3.0 compliant registry including the Service Registry.
UDDI can also provide benefits to developers, including the following:
UDDI improves infrastructure management by publishing information about proxy services

to the registry and categorizes the services for discovery. Thus growing a portfolio of
services making it easier to understand and manage relationships among services,
component versioning, and dependencies.
UDDI services can be imported from a registry to configure the parameters required to
invoke the Web service and the necessary transport and security protocols.
UDDI promotes the use of standards-based Web services and business services development
in business applications and provides a link to a library of resources for Web services
developers. This decreasing the development lifecycle and improves productivity. It also
increases the prospect of interoperability between business applications by sharing
standards-based resources.
UDDI provides a user friendly interface for searching and discovering Web services.
Page 25
4.2 Service Composition Module

Dynamic Content-Based Routing
EL platform will mediate service request and response messages between disparate
heterogeneous service endpoints and will intelligently route messages between them. Content-based
routing is a mediation capability supported by EL platform based on conditional message processing
and transformation capabilities. This routing capability allows loose coupling of SOA endpoints and
is particularly useful and allows service enrichment and reuse by combining transformation and
routing functions.
EL platform will perform dynamic message routing based on a message content, for cases
when services or responses need to be directed to multiple destination service and in scenarios
where different versions of a service have to be provisioned based upon business service requests.
Dynamic routing is useful when business requirements dictate that certain conditions of a request
define where it should be processed. For example, a financial institution's request for a credit report
on a customer may use any of several credit services based on where the customer or organization
resides.
In dynamic routing, a message is analyzed using conditional checks in conditional branching
statements, to retrieve the value of a data element or multiple data elements that determine the
routing logic. Different business service destinations are assigned to different value combinations
resulting from this conditional check. The message is dynamically routed to one of multiple
destination business services based on the data element value. Transformations may be applied to
the response message going to one or more of these destinations depending on business-service
requirements.
Business services are EL platform definitions of the enterprise services that exchange
messages during business processes. A business service and its interface can be defined and
configured using the EL platform Console. A business service will be configured by specifying its
interface, type of transport it uses, its security requirements, and other characteristics. A business
service definition is similar to that of a proxy service, but it does not have a pipeline.
Message Pipelines
Page 26
A pipeline is a named sequence of stages, representing a non-branching one-way processing

path. It is used to specify the message flow for service requests and responses. Pipelines fall into one
of the following three categories:
Request Pipelines: used for processing the request path of the message flow
Response Pipelines: used for processing the response path of the message flow
Error Pipelines: used as error handlers
For one-way operations, the response pipeline is executed with an empty message. This permits a
response to be constructed for the proxy service, enabling bridging between request/response and
one-way operations. The bridging mechanism means that proxy service input can be one-way while
its output is request/response or vice versa. The proxy service either absorbs the response from the
invoked service or generates one for the client. Actions in the response flow may also be used to do
post processing on the message after it has been routed to the business service or the proxy service.
A branch node allows processing to proceed down exactly one of several possible paths.
Branching is driven by a simple lookup table with each branch tagged with a simple but unique
string value. A variable in the message context is designated as the lookup variable for that node,
and its value is used to determine which branch to follow. If no branch matches the value of the
lookup variable, then a default branch is followed. The value of the lookup variable must be set
before reaching the branch node. This approach ensures that exceptions do not occur within the
branch node itself. A branch node may have several descendants in the message flow tree: one for
each branch including the default branch.
The route node is used to perform request and response communication with another service.
It represents the boundary between request and response processing for the proxy service, and
therefore, cannot have any descendants in the message flow tree. When the route node dispatches a
request message, request processing is considered finished. When the route node receives a response
message, response processing begins.
The route node is very flexible in its specification and supports conditional routing as well as
outbound and response transformations. It allows if structures and case structures to be combined
(and nested) to define a single endpoint and operation to route the message.
Page 27
Error Handling
EL platform will provide robust and flexible error handling for configured services. It can
handle errors in the following ways:
Testing whether an assertion is true and sending a reply with failure in the request or
response pipeline.
Configuring the service to catch and handle the error at multiple levels including the stage,
route node, pipeline, or service levels. The level configured to catch the error depends on the
service behavior desired.
Letting the default system error handler handle the error.
EL platform will provide the capability for incoming or outgoing messages to be validated against a
WSDL or XML schema with a validation action. This action can occur at any time within the
Page 28
message flow and ensures that the incoming or outgoing message is in the format expected by the
destination service's consumer or provider. Messages that fail validation can log the failure or create
an error. In the latter case, an error stage can be used to apply alternative actions.
Message validation can be used for service versioning to validate messages against different
versions of a schema or WSDL. This is to ensure the message is routed to the proper version of the
service end point, or to check whether transformation must be applied prior to sending the message.
EL platform will provide a mechanism to handle errors by allowing error handlers to be defined. An
error handler is a pipeline that allows various actions such as logging, transformation, and
publishing to be performed to handle errors appropriately. If an error occurs within a stage a
sequence of steps are executed. This sequence of steps constitutes an error pipeline for that stage.
The error pipeline will allow us to handle the error in the following ways:
Publish the original message to an alternate endpoint;
Formulate an error response message to be returned to the invoker of the proxy service;
Log the message;
Continue processing the message through the pipeline after modifying the context;
Raise an exception. Raising an exception transfers control to the next higher scoped error
pipeline.
Errors can occur during message flow processing for various reasons. For example, security errors
occur if a username is not correctly validated or authorized; transformation errors occur if EL
platform is unable to successfully transform or validate a message; a routing error is raised if a
routing service is unavailable, and so on. Typically, these errors originate from a specific stage, route
node or from the proxy service, as this is where most of the message flow logic is implemented.
4.3 Service Monitoring Module

In addition to delivering enterprise service bus capabilities such as service routing and
transformation, the EL platform will also contain service monitoring and management capabilities
to ensure the successful operations the IT organization expects. The following paragraphs describe
the service management and monitoring capabilities of the EL platform.
EL platform will aggregate run-time statistics and will allow them to be viewed in real-time
on a customizable dashboard, to monitor system operational health and flag problems in messaging
Page 29
services, allowing quick isolation and diagnosis of problems as they occur. EL platform Console can
be used to establish service level agreements (SLAs) for the performance of a system, and configure
rules that trigger alerts to provide automated responses to SLA violations.
EL platform will provide the ability to set service level agreements (SLAs) on business and
proxy services. These SLAs define the precise level and quality of service expected from business
and proxy services. Rules can be configured to trigger alerts based on what the SLA measures.
Multiple levels of severity can be configured for an alert including normal, warning, minor, major,
critical, and fatal. Multiple alert conditions can be combined for each business or proxy service.
Each alert can be based on the following parameters: Success rate, success ratio, failure ratio,
Message count, Error count, Failover/retry count, Validation error count, WSS error count,
Response time, Minimum response time, Maximum response time.
EL platform can report on message data as messages pass through a proxy service. This will
be done via a reporting action which can be placed at any point within a request/response pipeline or
error pipeline stage. Reporting actions can be used to filter message information as it flows through
the proxy. The data that will be captured via the report action, can then be accessed via a reporting
provider. The reporting actions can help determine whether there is a problem with a message preor post-transformation, during routing, etc.
Page 30
5. EL Platform - Roles and Profiles

The main Roles in the system will be: End User/ Customer, Provisioning user, Service
providers admins, and the Admin/ Root of the platform.
5.1 End User/ customer - my account Use case

Use case: Login, register (sign-up), personal info, browse services, subscribe, consume service,
make payment.
Diagram:
Register/ Login
Personal info (profile-category)
Browse Services
End User/
Customer
Ask for Service

Consume service
Make payment
Brief Description
The End User-customer opens the Enhanced Living platform, so he can register, login, enter
personal info, browse services, subscribe for a service, consume the service, pay for the service etc.
Initial Step-By-Step Description
Before this Use case can be initiated, the End User-customer has already started the
Enhanced Living platform.
1. The End user opens the mobile app and connects the Enhanced Living Platform.
2. As it is the first time connection the customer will be identify by a location identifier and the APPID.
Page 31
3. The portal does a lookup on the internal address database and translates the APP-ID to a household
ID and the self-registration process begins. The End user enters name, phone number, email
address etc. and receives login information to the actual customer portal.
4. At the same time the customer data is added to the Enhanced Living Database and the new
customer is created in the CRM system.
5. The End user can now access the unified communication portal and choose between available
service providers and services. Chosen services are usually provided to the customer on the fly.
6. When the End user has chosen a service the EL-Platform provisions all AAA parameters to that
the Service Partner can offer their services to the End User.
7. The End User will start consuming the selected service on his PC/ TV set/ smartphone.
8. On a monthly basis the End User/ client will pay for the subscription through a Unified Billing
System / Payment processor.
5.2 Service providers Admin Use case

Use case: Login, register (sign-up), personal info, connect to EL platform, create/ update services,
get paid.
Diagram:
Register/ Login
Connect with EL Platform
Create/ Update Services

Vendor
Communicate with EL Admin
Get paid/ Unified Billing
Brief Description
The Service providers admin accesses the EL platform, so he can register, login, enter
personal info, connect its Servers with the EL platform, provide services (VOD, MOD, Security,
Control, etc.), and get paid through Unified Billing system.
Page 32

Before this Use case can be initiated, the Service providers admin has already established a
connection with the Enhanced Living platform.
1. The Service providers admin chooses to register (sign-up) on the platform. After registration
hell be able to login.
2. The Service providers admin can enter/edit his contact info, his services description etc. This
info will be used in the Marketing (promotions) section of the EL website.
3. The Service providers admin will create and update services offered. The service content will be
delivered by orchestration of "flows" or "itineraries" of information among the component
services.
4. The Service providers admin will obtain / receive new Customer subscriptions (automatically) by
the EL platform.
5. The Service providers admin will obtain payments for his monthly services (subscriptions).
Payments will be done through the Unified Billing system within the EL platform.
5.3 Provisioning Users Use case

Use case: Provisioning Users functionality.
Diagram:
Manage accounts/ Users
Unified Subscribers management
Provisioning User
Unified Billing
Respond to users questions

Brief Description
The Platform will combine the various modes of operation under a unified, centralized
subscriber management. In this way the service provider can mix and match different access profiles
for all services under a single user profile. The Provisioning user of the system will also manage the
Page 33
database with subscriptions, the payments, and the communication with the users (it can be more
than 1 admin). Some of the admins duties will be automated.
1. The Provisioning Users will manage all (unified) End-users accounts in the system, together with
their personal information, contact data etc.
2. The benefits of a Unified Subscriber management lie in enabling a one-stop shopping experience
with single Sign-on. It provides an integral and simplified support for customer care and converged
billing which will minimize operational cost and complexity. It also eases the migration of legacy
services as 3 Play profiles without having to recreate the full user profile. It minimizes OPEX and
facilitates the Service upgrades.
3. The Provisioning Users will follow all orders (Service subscriptions), and the payments will be
managed through the Unified Billing system of the EL platform (see chapter 1).
4. The Provisioning Users will be responsible for communication with the clients and will serve as
Help desk.
5.4 Admin/ Root Users Use case

Use case: Admin/ Root functionality (manages the Platform, subscriptions, profiles etc.).
Diagram:
Platform maintenance/ upgrade

Service Repository
Service Policy Management
Admin/ Root
Subscriber/ Service State
Brief Description
Within a common repository, the Admin/ Root users will maintain the platform and will
define all information of the services, subscriptions and profiles.
Using a GUI, the admin will create and organize service in catalogues and create subscriber
and service profiles that can be reused for groups of subscribers or individual accounts. These
Page 34
subscriber and service definitions can optionally also be driven through OSS interfaces from a 3rd
Party.
Before this Use case can be initiated, the Admin/ Root user has already started and logged
into the Enhanced Living platform.
1. The Admin/ Root users will perform all the management of the (hardware/ software)
infrastructure of the EL. Platform.
2. Subscriber and Service Repository content:
-
Subscribers and their assigned service profiles;
Consolidation/integration of existing repositories.
3. Perform Service/Policy Management:

-
Using graphical user interface or OSS-I;
Definition of services templates, e.g.: Tiered High Speed Internet, Broadcast TV

standard and HDTV, Voice over IP, Video on Demand, On-line Gaming, Captive
subscriber portals, Wholesale ISP services.
In different service bundles and quantities.
4. Maintain Subscriber and Service State:

-
Information on service sessions status & logs.
On-demand service validation.
Page 35
5.5 Dataflow diagrams

The behavior of any software application is defined by its data-flows and state transition
diagrams. In the following sections we will elaborate these features of our platform.
Some of the most important data-flow diagrams are the following:
a. Ask for Service data-flow diagram
Sign-up
END
USER
Login
User DB
Platform
Choose Service (Subscribe)

Vendor DB
Ask for Content
Service
Management
Layer
Obtain content
(video)
Monthly
Payment
b. Provide Service data-flow diagram

Contract
VENDOR
Access
Offer service
Vendor DB
Service Management Layer

Unified
Service Portal
Provide Service
Get paid
5.6 Abstraction Layer diagram

The global sub-modules of the EL Platform are shown on the following diagram:
BPM Business Process Management
BSS - Business support system
BSM Business Service Management
OSS Operations support system
CRM Customer relationship manager
Page 36
5.7 Wireframes for the project

a. Login wire-frame
b. Settings wire-frame
Page 37
c. Main Menu wire-frame
d. Shopping wire-frame
Page 38
Page 39
6. External Interface Requirements

6.1 User Interface
The main interface that the End Users-clients will interact with the Platform will be mobile
app (Android/ iOS etc.) Other users and admin will access the platform via webpage (browser). The
interface will allow the Users to use Web forms for data entry. This interface will be clear and easy
to use. It will show buttons and text so the user can understand what is going on.
6.2 Hardware Interfaces

The hardware will be accessed indirectly, both from the client side (via a web browser) and
server side via the various program APIs (MySQL, Apache, PHP).
As this is a platform portal, it will be using the computer network to connect to the Internet,
which will allow it to communicate with the platform admin, as well as to database server. This
means that it will be using the infrastructure, be it wireless communication points or physical lines
of the network in order to perform properly. There will have to be some sort of error checking
whether the network is down or inaccessible.
6.3 Software Interfaces

This project will be connecting remotely to a MySQL databases that will be set up and is the
same one that the Apache-based platform connects to. This allows usage by users of both computers
and tablets. The operating system the software runs on will be the operating system the PC runs on,
which comes with a software framework that will be utilized, including many prepackaged
components to do things like create menus, hookup buttons, and other common functions expected
of a mobile device. The only communication will be between the client and the web server, which
will be sending queries or updates and receiving the information back. The logic associated with the
platform will be duplicated on the user, so there will be little in the way of a server side component
performing logic.
Page 40
6.4 Communications Interfaces

This will be a PHP/ MySQL based platform, but may still link to web pages that are not
necessary to duplicate. As described above, this will be communicating with a database server, and
so will be making use of the client-server network and HTTPS in order to communicate. There will
be email registration at the sign-up process. The primary forms of communication will be database
transactions or requests. The system will log the IP address for each users logging in. The system
will need to be able to integrate with the LDAP system in order for users to log in, and these
sessions will need to be kept secure throughout use. The platform will offer synchronization to a
certain extent with the other users of both the client PCs and the web browser, so that the
information displayed to the user is always up to date.
6.5 Session Management

Session is used to store user data outside the application, so that when the next time user
uses the platform, we can easily get back his details and perform accordingly. The platform will
allow users to login for the first time. And then when they exit the site without logging out, they will
be brought back to the same place if they log into portal again. But if the user logout from the
platform, he will be brought back to the main login screen. Session variables solve this problem by
storing user information to be used across multiple pages (e.g. username, favorite color, etc). By
default, session variables last until the user closes the browser. A session is started with the
session_start() function. Session variables are set with the PHP global variable: $_SESSION.
6.6 Data structures

The structure of MySQL is relational DBMS. The first data object is the User-customer.
Users will choose actions by selecting options within the platform. The data Tables in our project
will be:
Data table of Users/ clients personal data, contact data, membership type, payment info, etc.
Data table with Service providers (Vendors) - containing all info (ID, provider name, category of
the service, contact info) etc.
Data table with Users actions - Users orders for different services, browsing history, time spent
on different service (VOD, MOD etc.).
Page 41
Also, other supplementary data tables can be created for the purpose of data analyzing and
platforms promotion.
At the end of each session when a user has finished editing/ importing objects - the status of
the session and all users content can be stored locally. Some of the data during the sessions
(working in modules) will be treated as temporary. Once the session is ended - these data will be
discarded.
Page 42
7. Other Nonfunctional Requirements

7.1 Performance Requirements
After building features, eliminating bugs, and cleaning up the code, we should spend some
time looking at the performance of our platform. The speed and smoothness with which our
application retrieves data and performs operations has a significant impact on the users' experience.
Also the recovery time after break-up will be subject to reduction.
Client-server applications operate within a shared resource environment, and the
performance of the platform can be impacted by how efficiently it interacts with those resources in
the larger system. Applications also operate in a multithreaded environment, competing with other
threaded processes for resources, which can cause performance problems that are hard to diagnose.
7.2 Privacy Requirements

There are safety concerns regarding privacy. To protect users online privacy, well limit
what we collect during the signup process, and what well make public on the platform. We won't
sell or rent account information to anyone. Also there will be Terms of use of the product, that the
user should accept during the Sign-up process.
7.3 Security Requirements

EL platform will support open industry standards for ensuring the integrity and privacy of
communications and will ensure that only authorized users can access resources in the EL domain. It
will use the WebLogic security framework as building blocks for its security services. The
WebLogic security framework divides the work of securing a domain into several components
(providers), such as authentication, authorization, credential mapping, and auditing:
Authentication, encryption and decryption, and digital signatures as defined in the Web
Services Security (WS-Security) specification;
Uses SSL to support traditional transport-level security for HTTP and JMS transport
protocols;
One-way and two-way certificate based authentication;
Page 43
HTTP basic authentication;
Encrypt and export of resources (such as service accounts, service key providers, UDDI
registries, SMTP providers, and JNDI providers) that contain username and passwords;
Create service accounts and service key providers within a session, and add the user name,
password, and credential alias binding within the same session.
Configure a service account to pass through user ID and password credentials or map the
user to a new user ID and password supplied to a business service.
Client-specified custom authentication credentials for both transport- and message-level

inbound requests.
User-granted permissions to restrict access to system features and user data.
Use of trust seals they are images issued by a 3rd party that attest that our site has met a set
of standards and criteria that make us trustworthy.
If we operate the platform from our own network, the site is only as secure as our network
so using penetration testing is important.
Using a managed DNS service can improve your network and web site performance and
provide additional security.
7.4 Software Quality Attributes

The primary attribute of this project will be usability given the large amounts of data and
information that will be processed and presented in the browser. Some content of the site will only
be available to registered users and vendors. The code will be clear and well commented to allow
modification if necessary. All commonly changed settings should provide an administrator interface
to apply the changes. The code should be modular in nature and incremental so that changes and
tweaks are easy.
The webpages within the platform - should provide good error output on forms the clients
will complete. Warning messages should appear when something is incomplete, and Error messages
will appear in the unlikely event that something doesn't work as intended, as well as information on
how to resolve the issue relevant to the user.
Page 44
The requirement for responsiveness of the platform means that it will adapt its layout on
different screens/ viewing environment (PC, tablet, smartphone) and the developers should use tools
such as proportion-based grids, flexible images, CSS3 media queries and @media rule.
Success criteria for the complete platform are - easy to use and easy to navigate.
Accompanied by security assurance, design and reliability, as well as the content (platform set
offered) these are the main contributors to the platform quality.
7.5 Database Requirements

The information used in this PHP project must be stored in the created MySQL databases. IP
logger should be implemented and it will record each users IP address. The data used must be
consistent with the Apache web server so they can be used together.
7.6 Reuse Requirements

The components of the platform project shall be reused when adding additional tools to the
application.
The session management part of the entire solution shall be reused across all platform tools
implemented in the system.

EL Platform Architecture

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EL Platform Architecture

Uploaded by

Copyright:

Available Formats

ESB Architecture description

Enhanced Living Platform

ESB architecture description for the Enhanced Living Platform

2. EL Service Delivery Architecture ....................................................................................... 7

3. Message processing/ Message Flows/ Service integration.................................................. 13

Message Processing/ Proxy........................................................................................................13

4. Service Configuration, Composition, Monitoring .............................................................. 21

Service Configuration Module ...................................................................................................21

5. EL Platform - Roles and Profiles ......................................................................................... 30

End User/ customer - my account Use case ...............................................................................30

6. External Interface Requirements......................................................................................... 39

User Interface .............................................................................................................................39

7. Other Nonfunctional Requirements .................................................................................... 42

Performance Requirements ........................................................................................................42

ESB architecture description for the Enhanced Living Platform

Provisioning / Self Provisioning / Billing;

Entertainment (IPTV, VOD, MOD, Radio);

Conference Bridge (Video Call);

Home Control (Light, Shadow, Clima);

City Services (Transportation, Ticket ordering, Delivery etc.).

1.2 Intended Audience and Reading Suggestions

1.3 Project Scope

ESB architecture description for the Enhanced Living Platform

1.4 Product Perspective

1.5 Product Features

ESB architecture description for the Enhanced Living Platform

1.6 Unified User management

Reduced costs by removing the need for customer service intervention.

1.7 Unified Billing system

ESB architecture description for the Enhanced Living Platform

Present all content services on a single convergent bill.

Support for prepaid and postpaid services on a single convergent bill.

HTML, TXT, PDF, E-mail delivery options.

Invoice detail summarized by tiers (customer account, sub-account, corporate groups).

Customizable invoice templates with tokens to place accounting information anywhere.

Payment and Credit disbursement options for split bills.

Scheduled bill cycles or on-demand invoices.

1.8 Operating Environment

ESB architecture description for the Enhanced Living Platform

1.9 Technical requirements

ESB architecture description for the Enhanced Living Platform

2. EL Service Delivery Architecture

OSS / BSS (Operation System Support/ Business System Support).

Service Management Layer / Subscriber service control;

Content/ Services Layer.

User Profile / Address / Products..

ESB architecture description for the Enhanced Living Platform

ESB architecture description for the Enhanced Living Platform

Master Database Servers:

Support versioning functionality, including business rule validation and e-mail

Retrieve Open Invoices from the Billing API on a daily basis;

Create invoices for the relevant clients in the Clients API.

Retrieve charges for invoices from the Billing API;

Notify charge details to customers using the Send API.

Create payments in the Clients API.

2.2 Service Management Layer / Subscriber service control

Gather statistics about message invocations, errors, performance characteristics, messages

ESB architecture description for the Enhanced Living Platform

Service Level Agreements

Average processing time of a service;

ESB architecture description for the Enhanced Living Platform

Number of errors, security violations, and schema validation errors;

Administrators can configure alerts for SLA rule violations.

2.3 Content/ Service Layer