INFORMATION TECHNOLOGY SERVICES
ESB Operational Requirements
UCLA IT Services Enterprise Service Bus
Operational Requirements
Working Draft 01, June 4, 2012
Document identifier:
draft-itservices-esb-operating-requirements-01
Abstract
This document describes the desired operating capability and characteristics for a scalable and robust UCLA
Enterprise Service Bus infrastructure.
Status of This Document
This is a working draft. The document is under active development and subject to further revision. It is suitable
for IT Services internal circulation only.
1
UNIVERSITY OF CALIFORNIA LOS ANGELES
INFORMATION TECHNOLOGY SERVICES
ESB Operational Requirements
Table of Contents
2
1
INTRODUCTION ................................................................................................................................ 3
2
OPERATIONAL REQUIREMENTS ....................................................................................................... 3
2.1 SCALABILITY........................................................................................................................................ 3
2.2 AVAILABILITY ....................................................................................................................................... 3
2.2.1 Component A-1 .......................................................................... Error! Bookmark not defined.
2.2.2 Component A-2 .......................................................................... Error! Bookmark not defined.
2.3 SYSTEM MAINTENANCE ........................................................................................................................ 3
2.3.1 Component B-1 .......................................................................... Error! Bookmark not defined.
2.3.2 Component B-2 .......................................................................... Error! Bookmark not defined.
2.4 SECURITY ........................................................................................................................................... 4
2.4.1 Minimum Policy Compliance ................................................................................................... 4
2.4.2 Tenant Isolation ........................................................................................................................ 4
2.4.3 Encryption and Signature ........................................................................................................ 4
2.4.4 Authentication and Authorization............................................................................................ 4
2.5 SYSTEM MANAGEMENT ........................................................................................................................ 4
2.6 PERFORMANCE ................................................................................... ERROR! BOOKMARK NOT DEFINED.
3
DOCUMENT HISTORY ....................................................................................................................... 5
UNIVERSITY OF CALIFORNIA LOS ANGELES
INFORMATION TECHNOLOGY SERVICES
ESB Operational Requirements
1 Introduction
TODO: Introduce the document’s purpose.
2 Operational Requirements
2.1 Scalability
In its initialize release, the UCLA ESB must minimally satisfy the performance requirements and transaction
volume demanded by the UCPath interface integration as outlined in the UCPath Integration Business
Requirement document.
However, when architecting the ESB solution, the engineers must note that this is meant to be a campus-wide
infrastructure. As such, the solution must be able to scale its performance and transaction volume to handle to
an annual growth rate of 100% for at least 5 years without requiring substantial re-engineering. In other words,
the architected solution must easily grow-able to accommodate rapid increase in usage.
As a general rule, a loosely coupled, highly modular, and horizontally scaling design is preferred over a tightly
coupled, monolithic, vertical scaling design. The operator of the infrastructure should be able to easily scale
the solution by adding additional instances to the operating pool.
<question>do we have concrete numbers in terms of daily transaction size and count?</question>
2.2 Availability
The UCLA ESB is a mission-critical middleware service. When deployed, it is a foundational component of most
applications at UCLA, similar to the Shibboleth Single Sign-On service. The deployed ESB solution must be fully
redundant and provides continuous 24 hours a day, 7 days a week without interruption. For disaster recovery
purposes, this is a tier 1 service. It must have multiple, redundant configuration such that there is no single
point of failure throughout the entire infrastructure. In addition, it must minimally have a hot standby instance
at an alternate data center outside UCLA. In the event the main instance fails due to a UCLA data center
failure, the ESB must be able to resume service in 30 minutes or less.
Furthermore, when the system fails over to an alternate instance, it must be able to preserve and process all
pending transactions
2.3 System Maintenance
2.3.1 Patching and Upgrades
The UCLA ESB is a mission-critical middleware service and must be able to run uninterrupted. This includes
during system patching and upgrades. The ESB solution must allow for uninterrupted system patching and
maintenance, i.e., the ESB service must remain online during regular back up, patching and maintenance
windows.
2.3.2 Adding and Updating Connections
Similarly, the ESB solution must remain online and available when changing configuration such adding or
3
UNIVERSITY OF CALIFORNIA LOS ANGELES
INFORMATION TECHNOLOGY SERVICES
ESB Operational Requirements
removing a connection or service. Configuration changes should also propagate quickly to all instances of the
bus (if there is more than one) so that the change is transparent to the bus clients.
2.4 Security
2.4.1 Minimum Policy Compliance
Deployed fully, the ESB becomes the central data hub for UCLA. This hub ferries sensitive and protected
information between UCLA and external systems. To ensure information integrity and security, the solution
must conform to security and privacy requirement set in relevant UC policies and government legislations.
Specifically, the ESB must conform to the following policies:







UC IS-2: Inventory, Classification, and Release of University Electronic Information http://www.ucop.edu/ucophome/policies/bfb/is2.pdf
UC IS-3: Electronic Information Security - http://www.ucop.edu/ucophome/policies/bfb/is3.pdf
UC IS-11: Identity and Access Management - http://www.ucop.edu/ucophome/policies/bfb/is11.pdf
UCLA Policy 401: Minimum Security Standards for Network Devices http://www.adminpolicies.ucla.edu/pdf/401.pdf
UCLA Policy 403: UCLA Logon Security Standards - http://www.adminpolicies.ucla.edu/pdf/403.pdf
UCLA Policy 404: Protection of Electronically Stored Personal Information http://www.adminpolicies.ucla.edu/pdf/404.pdf
Family Educational Rights and Privacy Act (FERPA) http://web.registrar.ucla.edu/ferpaquiz/Tutorial.aspx
As of the June 2012 update, we do not have plans to deploy the bus to handle UCLA patient information flow.
Therefore, HIPAA compliance is not a requirement as of June 2012. However, that may change as the system
scales. The engineers to become familiarized with the unique security requirements of a HIPAA-compliant
system, and if possible, design the solution to allow for easy HIPAA compliance in the future.
2.4.2 Tenant Isolation
2.4.3 Encryption and Signature
2.4.4 Authentication and Authorization
2.5 System Management
2.5.1 Monitoring and Fault Detection
The ESB solution must provide the operators the ability to monitor the system’s health via a graphical user
interface (preferably web based). The monitor should expose information such as service availability status,
system load, instantaneous and average transaction time, warning and errors, as well as any
pending/scheduled events.
4
UNIVERSITY OF CALIFORNIA LOS ANGELES
INFORMATION TECHNOLOGY SERVICES
ESB Operational Requirements
The solution must be able alert external systems or individuals of any note-worthy event such as transaction
completion and errors/warnings. The operators should be able to configure these alerts with minimal efforts.
In addition, if at all possible, the monitoring solution should be able to detect pending failures (e.g., a service is
running beyond maximum load, if sustained, a system-wide outage may occur) and notify parties accordingly.
2.5.2 Audits
The ESB solution must be able to record all configuration change and transaction events occurring within its
system boundary. Whether a specific event is recorded, or how long the log is retained, should be configurable
by the operator. The auditing solution must comply with UC IS-2 and IS-3 requirements.
2.5.3 Error Recovery
If an ESB error prevents a transaction from completing, it should be able to recover and complete the pending
transaction on service recovery. If the transaction cannot be completed automatically, the solution must
provide a mean to allow operators to review pending transactions and complete them in a way that the overall
transaction integrity is preserved, i.e., the ESB must not be the cause of unrecoverable transaction errors.
3 Document History
Revision 01 ........ 6/4/2012 ....................................................................................................... initial draft document
5
UNIVERSITY OF CALIFORNIA LOS ANGELES