el platform architecture

45
ESB Architecture description for Enhanced Living Platform Version 1.0 Prepared by: Members: 03/03/2015

Upload: zoran-gacovski

Post on 19-Dec-2015

7 views

Category:

Documents


2 download

DESCRIPTION

EL Platform Architecture

TRANSCRIPT

Page 1: EL Platform Architecture

ESB Architecture description

for

Enhanced Living Platform

Version 1.0

Prepared by:

Members:

03/03/2015

Page 2: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 1

Table of Contents

1. Introduction ............................................................................................................................. 2

1.1 Purpose ......................................................................................................................................... 2

1.2 Intended Audience and Reading Suggestions .............................................................................. 2

1.3 Project Scope ............................................................................................................................... 2

1.4 Product Perspective ...................................................................................................................... 3

1.5 Product Features ........................................................................................................................... 3

1.6 Unified User management............................................................................................................ 4

1.7 Unified Billing system ................................................................................................................. 4

1.8 Operating Environment ................................................................................................................ 5

1.9 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 Message Processing/ Proxy ........................................................................................................ 13

3.2 Message Flow Architecture ....................................................................................................... 16

3.3 Service Integration Module ........................................................................................................ 18

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

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

4.2 Service Composition Module..................................................................................................... 25

4.3 Service Monitoring Module ....................................................................................................... 28

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

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

5.2 Service provider’s Admin Use case ........................................................................................... 31

5.3 Provisioning Users Use case ...................................................................................................... 32

5.4 Admin/ Root Users Use case ..................................................................................................... 33

5.5 Dataflow diagrams ..................................................................................................................... 35

5.6 Abstraction Layer diagram ......................................................................................................... 36

5.7 Wireframes for the project ......................................................................................................... 37

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

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

6.2 Hardware Interfaces ................................................................................................................... 39

6.3 Software Interfaces .................................................................................................................... 39

6.4 Communications Interfaces ........................................................................................................ 40

6.5 Session Management .................................................................................................................. 40

6.6 Data structures ........................................................................................................................... 40

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

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

7.2 Privacy Requirements ................................................................................................................ 42

7.3 Security Requirements ............................................................................................................... 42

7.4 Software Quality Attributes ....................................................................................................... 43

7.5 Database Requirements .............................................................................................................. 44

7.6 Reuse Requirements ................................................................................................................... 44

Page 3: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 4: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 5: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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.

We’ll allow the subscribers to manage and personalize their experience right from their

mobile devices without the need for costly customer service intervention. We’ll 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 6: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 7: EL Platform Architecture

ESB architecture description for the Enhanced Living 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 8: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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.

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

CCSSPPRR End-Customer Self-Provision & Registration

CCHHII Customer

Handling Interface SSPPII

Service

Provider

interface User Profile / Address / Products..

CCWWII Customer Web Interface

SSTTPP Service Template Provisioning (Product) Entertai

nment Home

Control Living Service SSMMSS

Service Monitoring Statistics Service interface

Free Service

Network / Content

Page 9: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 10: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 11: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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.

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;

ESB/ Subscriber Service Control

Middleware/ Stream control

Services/ VOD, MOD,…

Page 12: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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.

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

Household

Devices

Network Unified Service Portal

Services/ Applications

Page 13: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 14: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 15: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 16: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 request-

response 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 isn’t 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 17: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 18: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 client’s 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 19: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 20: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 21: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 22: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 non-

hierarchical, 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 23: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 24: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 25: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 26: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 27: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 28: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 29: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 30: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 pre-

or post-transformation, during routing, etc.

Page 31: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 30

5. EL Platform - Roles and Profiles

The main Roles in the system will be: End User/ Customer, Provisioning user, Service

provider’s 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:

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 APP-

ID.

End User/ Customer

Register/ Login

Browse Services

Personal info (profile-category)

Consume service

Ask for Service

Make payment

Page 32: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 provider’s Admin Use case

Use case: Login, register (sign-up), personal info, connect to EL platform, create/ update services,

get paid.

Diagram:

Brief Description

The Service provider’s 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.

Vendor

Register/ Login

Create/ Update Services

Connect with EL Platform

Get paid/ Unified Billing

Communicate with EL Admin

Page 33: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 32

Initial Step-By-Step Description

Before this Use case can be initiated, the Service provider’s admin has already established a

connection with the Enhanced Living platform.

1. The Service provider’s admin chooses to register (sign-up) on the platform. After registration –

he’ll be able to login.

2. The Service provider’s 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 provider’s 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 provider’s admin will obtain / receive new Customer subscriptions (automatically) by

the EL platform.

5. The Service provider’s 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:

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

Provisioning User

Manage accounts/ Users

Unified Subscribers management

Unified Billing

Respond to user’s questions

Page 34: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 33

database with subscriptions, the payments, and the communication with the users (it can be more

than 1 admin). Some of the admin’s duties will be automated.

Initial Step-By-Step Description

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:

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

Admin/ Root

Service Policy Management

Service Repository

Subscriber/ Service State

Platform maintenance/ upgrade

Page 35: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 34

subscriber and service definitions can optionally also be driven through OSS interfaces from a 3rd

Party.

Initial Step-By-Step Description

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 36: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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

b. “Provide Service” data-flow diagram

END

USER

Platform User DB Sign-up

Login

Vendor DB

Ask for Content

Choose Service (Subscribe) Monthly Payment Obtain content

(video)

Service Management

Layer

Service Management Layer Vendor DB Contract

Access

Get paid Provide Service

Unified Service Portal Offer service

VENDOR

Page 37: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 36

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 38: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 37

5.7 Wireframes for the project

a. Login wire-frame

b. Settings wire-frame

Page 39: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform Page 38

c. Main Menu wire-frame

d. Shopping wire-frame

Page 40: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 41: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 user’s 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 User’s actions - User’s orders for different services, browsing history, time spent

on different service (VOD, MOD etc.).

Page 42: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 43: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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, we’ll limit

what we collect during the signup process, and what we’ll 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 44: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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 45: EL Platform Architecture

ESB architecture description for the Enhanced Living Platform 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.