Get documents about "Insurance Application Architecture
W
Description
Insurance Application Architecture document sample
Document Sample
OFFICE OF SYSTEMS INTEGRATION
REQUEST FOR PROPOSAL OSI 7100-181 FOR
UNEMPLOYMENT INSURANCE
MODERNIZATION PROJECT
APPENDIX I –ARCHITECTURE DESCRIPTION
March 23, 2007
ISSUED BY:
STATE OF CALIFORNIA
DEPARTMENT OF GENERAL SERVICES
TECHNOLOGY ACQUISITIONS SECTION
707 3RD STREET, 2ND FLOOR
WEST SACRAMENTO, CA 95605
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 2 of 115
Table of Contents
I1.1 VERSION CONTROL INFORMATION .................................................................. 6
I1.2 OVERVIEW OF THIS DOCUMENT ....................................................................... 6
I1.3 OBJECTIVE, SCOPE, INTENDED USERS, APPROACH AND TERMINOLOGY,
AND ORGANIZATION OF THE DOCUMENT ....................................................... 6
I1.3.1 Objective ............................................................................................................. 6
I1.3.2 Scope .................................................................................................................. 7
I1.3.3 Intended Users .................................................................................................... 7
I1.3.4 Approach and Terminology .................................................................................. 7
I1.3.5 Organization of this Document ............................................................................. 9
I1.4 BUSINESS MODEL ............................................................................................. 10
I1.4.1 Overview ........................................................................................................... 10
I1.4.2 Viewpoint Name: Purpose and Mission of the System ....................................... 10
I1.4.2.1 Overview ....................................................................................................... 10
I1.4.2.2 Stakeholders ................................................................................................. 10
I1.4.2.3 Concerns ...................................................................................................... 10
I1.4.2.4 Viewpoint ...................................................................................................... 11
I1.4.2.5 Viewpoint Language...................................................................................... 11
I1.4.2.6 Rationale for the Viewpoint ........................................................................... 11
I1.4.2.7 Views, Models and Descriptions.................................................................... 11
I1.4.2.8 Known Inconsistencies Among Views ........................................................... 11
I1.4.3 Viewpoint Name: Business Processes ............................................................... 12
I1.4.3.1 Overview ....................................................................................................... 12
I1.4.3.2 Stakeholders ................................................................................................. 12
I1.4.3.3 Concerns ...................................................................................................... 12
I1.4.3.4 Viewpoint ...................................................................................................... 12
I1.4.3.5 Viewpoint Language...................................................................................... 12
I1.4.3.6 Rationale for the Viewpoint ........................................................................... 12
I1.4.3.7 Views, Models and Descriptions.................................................................... 12
I1.4.3.8 Known Inconsistencies among Views............................................................ 14
I1.4.4 Viewpoint Name: Use Cases ............................................................................. 15
I1.4.4.1 Overview ....................................................................................................... 15
I1.4.4.2 Stakeholders ................................................................................................. 15
I1.4.4.3 Concerns ...................................................................................................... 15
I1.4.4.4 Viewpoint ...................................................................................................... 15
I1.4.4.5 Viewpoint Language...................................................................................... 15
I1.4.4.6 Rationale for the Viewpoint ........................................................................... 15
I1.4.4.7 Views, Models and Descriptions.................................................................... 15
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 3 of 115
I1.4.4.8 Known Inconsistencies among Views............................................................ 17
I1.4.5 Viewpoint: Business Entity Model ...................................................................... 17
I1.4.5.1 Overview ....................................................................................................... 17
I1.4.5.2 Stakeholders ................................................................................................. 17
I1.4.5.3 Concerns ...................................................................................................... 17
I1.4.5.4 Viewpoint Language...................................................................................... 18
I1.4.5.5 Rationale for the Viewpoint ........................................................................... 18
I1.4.5.6 Views, Models and Descriptions.................................................................... 18
I1.4.5.7 Known Inconsistencies among Views............................................................ 23
I1.5 APPLICATION ARCHITECTURE ........................................................................ 24
I1.5.1 Overview ........................................................................................................... 24
I1.5.2 Viewpoint Name: Conceptual Service-Oriented Architecture ............................. 24
I1.5.2.1 Overview ....................................................................................................... 24
I1.5.2.2 Stakeholders ................................................................................................. 24
I1.5.2.3 Concerns ...................................................................................................... 24
I1.5.2.4 Viewpoint ...................................................................................................... 24
I1.5.2.5 Viewpoint Language...................................................................................... 24
I1.5.2.6 Rationale for the Viewpoint ........................................................................... 25
I1.5.2.7 Views, Models and Descriptions.................................................................... 25
I1.5.2.8 Known Inconsistencies Among Views ........................................................... 43
I1.5.3 Viewpoint Name: Business Intelligence and Reporting Application Architecture 43
I1.5.3.1 Overview ....................................................................................................... 43
I1.5.3.2 Stakeholders ................................................................................................. 43
I1.5.3.3 Concerns ...................................................................................................... 43
I1.5.3.4 Viewpoint ...................................................................................................... 43
I1.5.3.5 Viewpoint Language...................................................................................... 43
I1.5.3.6 Rationale for the Viewpoint ........................................................................... 43
I1.5.3.7 Views, Models and Descriptions.................................................................... 43
I1.5.3.8 Known Inconsistencies Among Views ........................................................... 47
I1.6 TECHNICAL ARCHITECTURE ........................................................................... 48
I1.6.1 Viewpoint Name: Technical Architecture Model ................................................. 48
I1.6.1.1 Overview ....................................................................................................... 48
I1.6.1.2 Stakeholders ................................................................................................. 48
I1.6.1.3 Concerns ...................................................................................................... 48
I1.6.1.4 Viewpoint Language...................................................................................... 48
I1.6.1.5 Rationale for Viewpoint ................................................................................. 49
I1.6.1.6 Views, Models and Descriptions.................................................................... 49
I1.7 GLOSSARY ....................................................................................................... 115
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 4 of 115
Table of Tables
Table 1 Listing of Application and Technical Architecture Viewpoints. ................................... 9
Table 2 Summary of Business Goals and CCR System Design Goals ................................ 11
Table 3 List of Actors and Roles and Use Cases ................................................................ 16
Table 4 Details of Data Elements Derived From the Use Cases ......................................... 20
Table 5 SOA Application Layers ......................................................................................... 30
Table 6 Operational Systems and Data Sources for the CCR System Data
Warehouse...................................................................................................... 45
Table 7 Properties of BusinessEntity Reference Class ....................................................... 81
Table 8 Properties of EntityCollection Interface .................................................................. 82
Table 9 Properties of IValidate Interface............................................................................. 92
Table 10 Methods of IValidate ............................................................................................ 93
Table 11 Properties for ValidationErrorList ......................................................................... 94
Table 12 Methods for ValidationErrorList............................................................................ 94
Table 13 Properties for ValidationError............................................................................... 94
Table 14 Methods for BusinessEntityBase ......................................................................... 95
Table 15 Validation Rules Classes ..................................................................................... 96
Table 16 Methods for BaseValidationFacadeSelect ........................................................... 97
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 5 of 115
Table of Figures
Figure 1 The IEEE 1471 Conceptual Specification Framework ............................................. 8
Figure 2 Overview of the UI Business Processes and Stakeholders.................................... 13
Figure 3 High Level Overview of Continued Claims Processes ........................................... 14
Figure 4 Overview of Data Elements Derived from the Use Cases ...................................... 19
Figure 5 Sample UIMOD High-Level Business Entity Model................................................ 23
Figure 6 Historical Comparison of Architectural Layering .................................................... 26
Figure 7 Overview of the Service Oriented Architecture of CCR Application and
Components.................................................................................................... 29
Figure 8 Business Services Diagram................................................................................... 35
Figure 9 Service Stack Layers ............................................................................................. 38
Figure 10 Meta Model showing Service Component Relationships ..................................... 39
Figure 11 IVR Channel Conceptual Process Architecture ................................................... 41
Figure 12 VoiceXML Components ....................................................................................... 42
Figure 13 Target Architecture for BI and Reporting ............................................................. 44
Figure 14 Sample BusinessMessage Format ...................................................................... 54
Figure 15 UI Network Security / Hardware Overview DMZ Option. ...................................... 61
Figure 16 Validation Schematics ......................................................................................... 91
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 6 of 115
I1.1 Version Control Information
Document Name: Continued Claims System (CCS) Application Architecture
Report
Document Version: V2.1
Release/Revision Date: 5 December, 2005.
Owner: Kathy Ruiz
Approver:
I1.2 Overview of this Document
The American National Standards Institute (ANSI) / Institute of Electrical and
Electronics Engineers (IEEE) Std. 1471-2000 standards define an application
architecture as follows:
"The fundamental organization of a system, embodied in its
components, their relationships to each other and the
environment, and the principles governing its design and
evolution."
The intent of this document is to define the application and the technical
architectures of the CCR System.
I1.3 Objective, Scope, Intended Users, Approach and
Terminology, and Organization of the Document
I1.3.1 Objective
The overall objectives of this document are:
To provide the various stakeholders within the Employment Development
Department (EDD) a common understanding of the Continued Claim
Redesign (CCR) System‘s architecture.
To gain commitment and agreement for the CCR System architecture
from various EDD Stakeholders.
To provide the systems development vendors with the information and
context needed to develop a meaningful proposal that meets the EDD‘s
requirements.
To provide a road map of the enterprise and a ―route planner‖ for the
Continued Claims business and technology change.
To address the architecture concerns of various stakeholders and allows
an objective discussion of alternatives.
To provide technical guidelines for the design, development and
operations of the CCR System. While this document provides the basis for
many system requirements, this is not a requirements document. System
requirements are defined fully in the System Requirements Specification.
Note, this document is not intended to be a design document or reflect that
degree of depth and detail required for actual development.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 7 of 115
I1.3.2 Scope
The scope of the EDD Unemployment Insurance (UI) Modernization (known as
UIMOD) application architecture is comprehensive and covers:
The Business Model (Section 1.4) which provides a high level summary
view of the UI business drivers, business processes, Use Cases and the
business entities required to support Continued Claims.
The Application Architecture (Section 1.5) which documents the
automated services that support the implementation of the functional
requirements (see Systems Requirement Specifications - SyRS), including
interfaces to the business and the integration with both internal and
external applications. It describes the structure of the application in terms
of layers and the functionality of these layers, and how that structure
implements the functional requirements of the organization.
The Technical Architecture (Section 1.6) which documents the technical
infrastructure and services required to support the application architecture.
The Technical Architecture also provides guidelines and standards for
application designers and developers to take full advantage of the
proposed services of the Technical Architecture.
I1.3.3 Intended Users
This document is intended for use by system users, the EDD Management, the
Systems Implementation Vendor/Service Provider and EDD‘s Information
Technology Branch.
I1.3.4 Approach and Terminology
The EDD has adopted IEEE-Std-1471-2000 — Recommended Practice for
Architectural Description of Software-Intensive Systems. The IEEE standards
body recommends that architecture descriptions be organized around views
which address key stakeholders and their concerns. The IEEE‘s conceptual
model of the elements required in an architecture specification is provided in
Figure 1.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 8 of 115
Figure 1 The IEEE 1471 Conceptual Specification Framework
Key terminology and attributes of the IEEE architecture framework include:
Stakeholder: These are the individuals who are the intended audience of
the view.
Concerns: Identification of the system stakeholders‘ concerns judged to be
relevant to the architecture.
Viewpoint: A Viewpoint refers to a single aspect of the systems and refers
to a particular attribute of the systems.
Rationale: The ―rationale‖ addresses the extent to which the stakeholders
and concerns are addressed and covered by the viewpoints and the
models.
Language: The particular language, modeling techniques, or analytical
methods used in constructing a view based on the viewpoint. Note, during
the development of a high level architecture, the language is typically not
based on formal notation and specific models but rather on general
concepts, components, principles, etc. Formal models become more
significant during the actual design phase. Example of formal models
include: Use Cases, interaction diagrams, XML interface specifications,
rule hierarchies, object models, class schemas, etc.
Views: Views are actual architectural description and model of the
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 9 of 115
systems to address the particular viewpoint.
I1.3.5 Organization of this Document
This architecture description is organized into three major models which are:
Business Models.
Application Architecture.
Technical Architecture.
Each architecture model is comprised of one or more Viewpoints which are
selected to represent Stakeholder concerns and ensure that the CCR System
application meets the intent and guidelines established by the EDD. The
architecture models and viewpoints contained in this document are summarized
in Table 1.
Table 1 Listing of Application and Technical Architecture Viewpoints.
Architecture Models Viewpoint Name
Business Model
Purpose and Mission
Business Processes
Use Cases
Business Entities
Application Architecture
Conceptual Service Oriented Architecture
Business Intelligent and Reporting Architecture
Technical Architecture
Technical Architecture Model
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 10 of 115
I1.4 Business Model
I1.4.1 Overview
The Business Model is intended to give the reader a context and an overview of
the system. The Business Model is discussed from four different viewpoints
including:
Purpose and Mission of the System.
Business Process Viewpoint.
Use Case Viewpoint.
Business Entity Viewpoint.
I1.4.2 Viewpoint Name: Purpose and Mission of the System
I1.4.2.1 Overview
The EDD has conducted a significant amount of effort to define the business
case and the objectives of the CCR System which have been documented in
several documents including the original Feasibility Study Report (FSR),
Economic Analysis Worksheets (EAW), SyRS and Special Project Report (SPR).
This section only provides a summary of the purpose and mission of the CCR
System to help the reader establish the proper context.
I1.4.2.2 Stakeholders
Acquirer
Architects
End Users
Integration Vendors
I1.4.2.3 Concerns
What is the purpose and mission of the systems from both a business
perspective and a technical perspective?
What are the business goals?
What are the technical design goals and strategies for achieving the
business goals?
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 11 of 115
I1.4.2.4 Viewpoint
This section provides a high-level summary of the business objectives and the
corresponding technical design objectives of the CCR System.
I1.4.2.5 Viewpoint Language
Business goals and technical design goals.
I1.4.2.6 Rationale for the Viewpoint
This viewpoint provides the context for building the CCR System.
I1.4.2.7 Views, Models and Descriptions
The purpose of the CCR System is to provide the EDD with new capabilities to
process Continued Claims and improve efficiencies. The goals of the CCR
System are summarized in Table 2. For details on the business case and
detailed vision of the CCR System, refer to the SyRS Document.
Table 2 Summary of Business Goals and CCR System Design Goals
Business Goals CCR System Design Goals
Improve efficiencies and reduce customer Provide secure customer self-service capabilities for
service workload. continued claims and continued claims inquiries
using multiple channels, e.g., Internet and IVR.
Automate manual paper based transactions using
workflow, document management and imaging
technology.
Improve customer service and access. Provide customer self service via online and IVR
access 24x7.
Reduce errors and manual processing. Provide real-time rule based decision logic for
Continued Claims processing.
Reduce fraud. Provide enhanced reporting functionality for fraud
prevention and reduce fraud.
Improve employee scheduling and staff Provide reporting capability that enables managers
efficiencies. to analyze and report transaction volume and key
quality metrics (e.g., First Payment Time Lapse -
FPTL).
Improve time to deployment and The architecture and design must meet the EDD‘s
flexibility. operational and support requirements including:
Modularity
Extensibility
Scalability
Availability and Reliability
Performance
Data Integrity
Security
I1.4.2.8 Known Inconsistencies Among Views
There are no known inconsistencies.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 12 of 115
I1.4.3 Viewpoint Name: Business Processes
I1.4.3.1 Overview
The CCR System only addresses a subset of the UI processes. To provide the
key stakeholders with a context, this section provides a high level overview of the
current UI environment including:
A high level overview of internal and external stakeholders, and
A high level overview of the UI business processes.
The overview should be sufficient to explain the major functions of the current UI
business model to an external audience who is not intimately familiar with every
detail of the UI processes. This overview should also provide the reader with a
context of how the CCR System fits within the environment.
I1.4.3.2 Stakeholders
Acquirer
Architects
Integration Vendors
I1.4.3.3 Concerns
The CCR System only addresses a sub-set of the UI Claims processes. How do
we clearly delineate the systems in the context of processes that will be re-
engineered and supported by the CCR System from other (upstream,
downstream and external) processes which are not in scope?
I1.4.3.4 Viewpoint
This section provides high level overview of the EDD stakeholders,
organizations, processes and other artifacts of the unemployment insurance
business as viewed from an external observer.
I1.4.3.5 Viewpoint Language
Process diagrams.
I1.4.3.6 Rationale for the Viewpoint
This viewpoint provides the context for the CCR System in terms of processes
and boundaries. This viewpoint also provides the vendor with a high-level
understanding of the scope of the CCR System. The intent of this view is mainly
to provide the reader with a context to the UI business and not to establish formal
definitions and process descriptions.
I1.4.3.7 Views, Models and Descriptions
The UI business is complex and involves many stakeholders and relationships.
The major stakeholders and their relationships are depicted in The figure below
and provides a context for the Continued Claims environment.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 13 of 115
(1) Initial Claim
Relationship Map (1) Notice of Claim Filed (DE1101CZ)
(2) Notice to Base Period Employers (DE1545)
(2) Continued Claim Certification (DE 4581) (5,6,7,10) Notice of Determination / Ruling
Clients (3) Appeal [D/R (can be together or issued separately)] Employers
(4) Customer Service Inquiry / Transaction* (8) Notification of Appeal
(5) Response to Request for Information** (11) Benefit Audit Form (DE1296B), DE1296 NER
(6,7,9) Request for Information**, DE1296 NER
(1) Handbook Handbook
(1) Notification of Award Benefit Determination
Notification of Award
(7) Amended Notification of Award Notification of Eligibility Interview
Payment (Check)
(1,2,5) Notification of Disqualification Continued Claim Certification (DE 4581)
Next Certification
Notice of Claim Filed (DE1101)
(6,9) Notification of Potential Overpayment Notice of Ruling
(6) Notice of Claim Filed Protest (DE1101CZ)
Benefit Determination
(3,8) Notification of Appeal Appeal
Request for Information**
Payment (Check) (7) Notice to Base Period Employers Protest (DE1545)
(1,2,6,7) Notification of Eligibility Interview Next Certification (8) Notice of Appeal
(2,5) Payment (Check) Request for Information** (9) Benefit Audit Forms (DE1296B)
Continued Claim
(1,2,3) Next Certification Certification (DE4581) (10) Request for Information Response**
(1,7,9) Request for Information** Notice to Base Period Authorization Primary Call Initial Claim (11) Quarterly Wage Report
(4) Inquiry Response Employers (DE1545) Centers Center Customer Service
Copies of Immigration (Initial Claims and Inquiries /
(Continued Claim
Customer Service Transaction*
Forms (to INS) Processing Function)
Function)
Request for Response to
Information** Request for
U nd he
ID Alert Issues (1) Request to
U l i ve u rn
n d R ck
a C
SP ra ed
Information**
e et s
Board Continued Claim Recomp Requests transfer wages
S ble
Other States
Appeals Exceptions (BYB change,
Claim Cancellation,
CUIAB Wages +/-) Recomp
Wages
Board Message Inquiries
s
ue
Appeal (Recomp, 1099)
s
Is
Decision Appeals and Primary Insurance Paid Check
y
ilit
Board Appeal Adjudication Accounting Information
ib
ig
Decisions Center El Division (1) Request for wages
(Determination of (Benefit Recomputation Issued Check Federal Agencies
Eligibility Function) and Reconciliation) Information
(3,8) Appeal Cancelled Check Wages
Notice of Determination / Ruling Information
Office of Appeals D/R (can be together or issued separately)
Appeal Notice of Disqualification Notice to Base Period Employers (DE1545)
Appeal Amended Notification of Award Issued Check
Decisions
Notice of Eligibility Interview Appointment Notice of Potential Overpayment
Information
Overpayment Waiver Form Notice of Determination / Overpayment
Benefit Audit Form (DE1296B) Cancelled Check
Benefit Determination
Request for Information** Information State Treasurer's
Payment (Check)
Next Certification Office
Request for Information** Paid Check
* Customer Service Inquiry / Information
Transaction refers to any request from
the claimant (regardless of method, (1) Request for Alien Claimant Payment
Notice of and Eligibility
Other Entities that EDD Interacts with:
phone, mail, web) and may include: Status (Copies of Federal:
Alien Status Immigration forms) Statistics IRS (VFIT)
Where's my check, certification
correction and payment processing. (1) SSA (via DHS) for SSN Verification
USPS for Finalist (Address update)
USCIS
** Requests for Information are Department of State:
Labor Lottery (Overpayment recovery)
specific to the business process and (Formerly Immigration &
Naturalization Service) FTB (Overpayment recovery)
may include: Request for Eligibility, State Controllers Office (SCO)
Rulings, ID Alert, Wage or Claim Dept. of Child Support Services (DCSS)
Dept. of Motor Vehicles (DMV)
information from any party.
County:
Each county's DA (Child Support Intercept)
Figure 2 Overview of the UI Business Processes and Stakeholders
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 14 of 115
Continued Claims processes, which comprise a subset of the UI processes, are
depicted at a high level in the diagram shown in Figure 3.
.
Intial Claim
Filed
Continued Claims Process
Note: This is a high-level overview, not all continued
Notice of Claim Filed claim processes are not depicted in this diagram.
Continued Claim Form
Out of Scope Processes
Reissued
Certification
Claimant
Continued Claim
Certification Capture Validate
Certification Captured Certification Incomplete
Information Certification Information Certifications
Information
Reissue
Certification
In-pattern Validated
Answers Certifications
Claim Information Verify Claim
Sort Claim
Form
SCDB Corrected Responses
Claim Certifications
Match Reissue Request
Claim
Information No Claim Resolved Adjudications
Claim by Clarification Out-of-pattern (Conduct eligibility
Match
Barriers Answers interview)
UI Scheduling
Unresolved System
Eligibility Schedule Determination
Authorize Appointment
Claim Barriers Issue
Continued
Claim to Payment
Benefit Process Eligibility
Accounting Exceptions Decision
System Resolved
Payable Non-payable
Claim Barriers Request for
Payment/Deduction/ Claimant Employer
Profiling Offset Information
Response Clarification
Record
Calculate Non-
First Payment & Record Payable Request for Claimant
Payment/ Weeks Continued Employer
Information Clarification
Deduction/ Claim Form Response
Offsets Information
Office of Documents, Employer
Warrant Claimant
Publications & Distribution
Information Check & (Issue Benefit Check &
Contiuned Claim Form Continued Claim Form for next
Information certification period.)
November 2005
Figure 3 High Level Overview of Continued Claims Processes
I1.4.3.8 Known Inconsistencies among Views
There are no known inconsistencies.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 15 of 115
I1.4.4 Viewpoint Name: Use Cases
I1.4.4.1 Overview
This section articulates the functional requirements of the system from the
perspective of the users (a.k.a. Actors) of the system. It details how the Actors
will interact with the system to deliver the business services of Continued Claims.
The model for describing the functionality is based on the Use Case, which is the
de-facto industry standard for capturing user requirements.
The Use Case is intended to answer what the actor and the systems must do to
support the services of the business; it is not intended to be a detailed design in
terms of how the system will be structured. However, the design, as it evolves,
should be traceable and linked to the Use Case and the associated
requirements.
I1.4.4.2 Stakeholders
Acquirer
Business User
Architects
Designers
Integration Vendors
I1.4.4.3 Concerns
What is the functionality of the system?
How will the user interact with the system?
What functionality will the system provide to Claimant and Employer via
self-service?
What functionality will be provided to the EDD Continued Claims staff?
I1.4.4.4 Viewpoint
This section provides a summary of Actors, Roles and the functionality of the
system as viewed from a user perspective.
I1.4.4.5 Viewpoint Language
Use Case Models.
I1.4.4.6 Rationale for the Viewpoint
This viewpoint provides an overview of the functionality of the system from a user
perspective. Use Cases are an industry accepted standard for capturing end-
user requirements. Use Cases are designed to show how users interact with the
system and the functionality provided by the system in support of the Use Cases.
I1.4.4.7 Views, Models and Descriptions
A Use Case defines how the system is used by a user (a.k.a. Actor) in
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 16 of 115
accomplishing a well defined function or service. The functionality of the CCR
System is comprised of the Use Cases listed in Table 3. For a detailed
description of Use Cases refer to Section 3.8 of the SyRS.
Table 3 List of Actors and Roles and Use Cases
Actor Roles Primary Use Case
Public Customer
Claimant Manage Claimant Account via the Internet
Update Demographics via the Internet
Online Enrollment
Update Online Account Personal Preferences
Change Password
Forgotten User ID and/or Password
Update Eligibility Information – Self Service
Certify for Benefits
Interactive Voice Response
Request Lost or Stolen Check Forms
Employment Program Representative
Customer Service Customer Service
Representative
Update Eligibility Information — CSR
Cancel or Reschedule Appointment
Reset Customer Password
Claim Filer/Claimant Additional Claim
Adjustor Update Certification Information
Capturing Unscannable Data
Processing Work Queues — Adjustor
Insurance Accounting Division (IAD) Service
Request
Calculate Payment
Initiate Payment Distribution
Replacement Check
Process Decisions
Manager
Workflow Administrator Manage Workflow
Business Rules Administrator Manage Business Rules
Operations Manager Monitor and Assign Workload
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 17 of 115
Actor Roles Primary Use Case
Operations Manager or Program Analyst
Operations Manager Reporting
Reporting Analyst
Account Manager
Employer
Employer Program Setup and Manage Partials and Work Sharing
Administrator
Program Analyst
UI Branch Fraud Analyst Fraud Condition Detected
Web Analyst Publishing Content
Web Correspondence Web Correspondence
Analyst
System Account Administrator
Account Manager Continued Claims Systems Account Management
Public Customer
Training Provider Setup and Manage California Training Benefits
(CTB)
I1.4.4.8 Known Inconsistencies among Views
There are no known inconsistencies.
I1.4.5 Viewpoint: Business Entity Model
I1.4.5.1 Overview
The Business Entity Model addresses architecture, models and guidelines for
building and managing the information required to support the Continued Claims
processes.
I1.4.5.2 Stakeholders
Acquirer
Vendor/Integrator
Data Analysts and Database Designers
I1.4.5.3 Concerns
What are the Business Entities making up the System?
What information (Business Entities) are required for reporting and
Business Intelligence purpose?
What is the magnitude of data?
Which data sets should be replicated into the new CCR System and which
data should be maintained in the legacy environment?
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 18 of 115
I1.4.5.4 Viewpoint Language
High Level Business Entity Model.
Entity attribute size estimates.
Record volume assumptions.
I1.4.5.5 Rationale for the Viewpoint
The Business Entity Model provides the vendor/integrator with an
understanding of the number of tables and business entities that need to
be implemented.
I1.4.5.6 Views, Models and Descriptions
In order to begin to understand the Business Entities of the UIMOD system, it is
important to understand what kinds of data is used in the CC processes, and the
flow of the data through the CC processes. Figure 3 shows the CC processes
described more fully in the Use Cases. Figure 4 and Table 4 show the data used
in these processes, and describe in some detail the data referenced in the Use
Cases. This section finishes with a sample High Level Business Entity Model,
shown in Figure 5.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 19 of 115
State of California Employment Development Department
Last
Claimant
Employer
Account
Information
Information
Claimant Weekly
Address Employment Information For
Demographic Fraud Certification
Information status Notification
Information Information
Account Status
Forms History
(Stub Info)
Eligibility Lost , Stolen, Weekly External Entity Judgement
Appointment Fact Finding
Updates Check Certification Judgement Statements
History Information
(DE238CT) Information History Info History
Partial/ CTB
Certfication Staff Role Agent Profile
WEB Content Worksharing Enrollment
Rules Information Information
Employee List Information
Claimant Fraud Workload
History of WEB ODPD Print Security Audit Scheduling
Publications
Corresponden Information Queue
Information Information Information
ce (Data Mining) Information
Figure 4 Overview of Data Elements Derived from the Use Cases
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 20 of 115
Table 4 Details of Data Elements Derived From the Use Cases
Estimated
number of
Data Object Name Description
properties in
entity.
Claimant Account 10 Contains basic claimant account information, elements such as:
Information Claim Preferences,
Suspense items requiring claimant action,
Recent activity,
e-mail address, and
Latest authentication pattern used.
Demographic 20 Information relating the various statistical studies of the
unemployed with reference to size, density, distribution, and
vital statistics.
Address 15 A chronological record of residence and mailing addresses used
Information by a client (may include worksite address information).
Claimant Fraud 20 Contains information pertaining to an individual‘s account and
Information any association with fraud in the UI or DI systems. This would
include instructions for managing the account (e.g. on-going
investigation, internal/external, continue to pay, stop payment,
activity thresholds, alert mechanisms).
Weekly 10 Summary information on the state and disposition of each week
Certification in a claim‘s benefit year.
Information
Employment 25 Will contain a history of employer/employee relationships,
Conditions separation information, last date worked, work patterns (part vs.
full time), union affiliation and standing, tenure, NAICS, labor
market, work sites.
Information For 5 A summary of information/notices distributed to the claimant
Notification (e.g. DE4581s, DE1101CLMTs, appointment notices, ―stub
messages,‖ address change verifications) and channel of
communication.
Forms History 5 A detailed record of forms distributed to the claimant either on
request or as a result of an action taken by the system. Includes
event time stamp, mail date, suspense period for expected
response.
Account Status 50 A detailed record of information provided to the claimant at the
conclusion of each certification period (e.g. account status,
upcoming events, extended benefit options, Lag information,
claim balance, overpayments, FS weeks).
Last Employer 50 Will contain information pertaining to an employer that has been
Information identified as a last employer. Information would include contacts
for UI business (name & phone number) address(es) for UI
correspondence, partial or Work Sharing participation,
separation policies regarding compensation, trade dispute
details, NAICS, suspense items.
Appointments 15 Will contain information regarding a claimant‘s scheduled
eligibility determination appointments including dates, times,
issues to be covered, contact instructions, attempts and
disposition.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 21 of 115
Estimated
number of
Data Object Name Description
properties in
entity.
Eligibility Updates 50 Will contain a history of changes to the claimant‘s factors that
affect eligibility requirements and how those requirements have
changed.
Lost, Stolen 10 Will contain the history of a check from authorization through
Check Information the lost or stolen check process.
Weekly 150 Detail information on each week in the benefit year of a claim
Certification including paid and unpaid weeks, reductions, deductions, issues
detected, claimant‘s compliance responses, issue resolution,
warrant numbers, warrant disposition.
External Entity 15 Information pertaining to judgments applied to a week from a
Judgment party external to the certification process. Information would
Information include source, date, adjustments applied to he affected week,
reference to decision (e.g. Office of Appeals Decision,
recomputation).
Judgment 5 For each issue associated with any week the determination
Statements interviewer (Adjudicator) may base their decisions on judgments
History made according to the relevant facts. The judgments require an
explanation.
Partial / Work 5 Both the Work Sharing and Partial Claims programs require the
Sharing Employee participating employers to substantiate each claimed week that
List their employees are participating in the program.
California Training 5 All training providers satisfying CTB requirements must provide
Benefits weekly status information for each enrollee for the claimant to
Enrollment satisfy an eligibility requirement.
Information
Certification Rules TBD All of the rules that govern the continued claims certification
process including data validation, establishing eligibility
requirements, eligibility compliance and issue detection.
Staff Role 10 For each staff the access permissions, level of authority, and
Information associated skills that govern the routing of work queues.
Scheduling 10 Detailed information on appointment schedules, including
Information schedule types, language, date, appointment times, schedule
status and openings.
Agent Profile TBD Detailed information about agent‘s skills, language spoken, job
Information assignment, etc.
ODPD Print TBD TBD
Information
Security Audit TBD TBD
Information
Fraud Information TBD TBD
(Data Mining)
Workload Queue TBD TBD
Information
Web Content TBD TBD
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 22 of 115
Estimated
number of
Data Object Name Description
properties in
entity.
History of Web TBD A detailed information of Web publications, including publication
Publications date, revision/deletion dates, subject, author, etc.
Claimant TBD Detailed claimant correspondence information including subject,
Correspondence date received, staff assigned, actions taken, status, etc..
To get an indication of the volume of data that must be stored in the CCR System
data store, the following is a sample of records and the approximate volume
stored in the current UI data store:
Active and Inactive UI Claims 6 million
UI Weekly Actions 105 million
UI Payments 50 million
UI Notes 172 million
Continued Claim Form History 51 million
Client Addresses 27 million
A Business Entity includes both methods and schema. Figure 5 below shows a
sample Business Entity model of the UIMOD system, based on the data used in
the Use Cases, and described in the previous sections. This is presented to aid
the Bidding vendor in understanding, not to guide or dictate design.
The CCR System should also use Core Entities: i.e., Object, Folder, Set, Group,
Grant, Role, XMLDocument, Schema. Entity ―Object‖ has general properties
used by all Business Entities (e.g. Create Date, Update Date, Entity Version).
Business Entity schemas are part of CCR Application Domain Meta-Model and
will be stored in a CCR Repository. Instances of all Business Entities can be
represented as XMLDocuments and serialized as XML streams.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 23 of 115
Figure 5 Sample UIMOD High-Level Business Entity Model
I1.4.5.7 Known Inconsistencies among Views
There are several potential Business Entities yet to be defined including:
Work queue.
Work queue items.
Internal IT Staff and Roles and associated performance metrics.
The EDD Programs (e.g., Partial, Work Sharing).
Various performance metrics and data related to call center processing.
Note, all business entities must be stored in the CCR System data store.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 24 of 115
I1.5 Application Architecture
I1.5.1 Overview
This section documents the conceptual application architecture and addresses
key concerns of the stakeholders.
I1.5.2 Viewpoint Name: Conceptual Service-Oriented Architecture
I1.5.2.1 Overview
The Conceptual Service-Oriented Architecture describes at a high level the
desired architecture and design of the application. The intent of the EDD is to
create a modern flexible design based on service-oriented, object-oriented, and
XML metadata concepts. The objective is to achieve flexibility in terms of simplify
changes, rapid update to business rules, and support for workflow. The
application architecture also provides guidelines for integration with the external
system.
I1.5.2.2 Stakeholders
Architects
Designers
Integration Vendors
I1.5.2.3 Concerns
What is the conceptual structure of the CCR System application?
What are the types of components required to ensure a service-oriented
architecture and how do the components interact?
How do we ensure reusability, extensibility and maintainability?
I1.5.2.4 Viewpoint
This viewpoint examines the CCR System application from an architect
perspective and provides a view of layers, components and component
interactions.
I1.5.2.5 Viewpoint Language
Generic concepts of service-oriented architectures.
High level design guidelines and principles.
Description of key components including Business Services, Messaging,
Data Access Layer, Enterprise Service Bus etc.
Meta-Model for component relationships.
Layered architecture models.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 25 of 115
I1.5.2.6 Rationale for the Viewpoint
This section provides guidelines for how the CCR System application will be
structured to achieve the design goals. This viewpoint also provides additional
guidelines around reusability, modularity, etc.
In addition, the architecture guidelines described herein will also serve as the
foundation for the EDD enterprise architecture, i.e., all new systems at the EDD
will be guided by this architecture.
I1.5.2.7 Views, Models and Descriptions
I1.5.2.7.1 Overarching Design Goals and Principles
The primary goals of this architecture are to design a system that is maintainable,
extensible, reusable and secure. The issue of extensibility and reuse will be
addressed at multiple levels including architecture, common patterns and
practices, infrastructure, source code, business component, and subsystem
reuse. These goals will be achieved through a flexible and extensible architecture
making use of service-oriented and object-oriented design methodologies.
The primary goals related to reuse and extensibility include:
The design of a reusable and extensible software architecture, which
embraces the idea of pluggable components and services.
The implementation of reusable infrastructure components for generic
functions such as exception handling, logging, integration, business entity
creation and management, etc.
The definition and implementation of a reusable development process,
including programming guidelines and best practices.
The definition of class hierarchies to implement business logic, which
capture common functionality and data in base classes and implement
more specific functionality and data in derived classes.
Additional reuse and extensibility considerations include the following.
The potential use of a Portal and/or Web Desktop Container (with
Dashboard Presentation State manager, object space panels, service
menus, tabs, GUI skins with personalization) in the system as a consistent
user interface presentation layer.
Establishment of registries with a common Business Entities and Business
Messages specification, which can be defined and incorporated into the
system over time. These specifications should be used when passing data
between different components in the system.
The use of Business Rules Framework to enable rapid build and change
of business rules to respond to changing business needs.
The use and deployment of general, reusable business workflow
components to simplify the development process of building and
orchestrating workflows.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 26 of 115
I1.5.2.7.1.1 Reusability Design Goals
The CCR System architecture clearly separates the different layers of the
system. Client programs, whether they are user interface programs or other
systems, interact with the business tier through clearly defined public interfaces
(the Business Façade) and have no knowledge of or dependency on the internal
implementation or logic in the business components. Furthermore, the client
programs have no direct access to the back-end database(s) and will have no
knowledge of the database structure. This clear separation of functionality is
intended to provide extensibility and maintainability. That is, to make it easier to
modify various parts of the system while minimizing the impact on other layers.
Figure 6 shows the separation of the application with the goal of allowing the
enterprise to manage each layer as a separate corporate asset.
Figure 6 Historical Comparison of Architectural Layering
The core business functionality of the system will be comprised of a set of
modular Business Services. The modular nature of the Business Services and
the limited dependencies between services will simplify the process for adding
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 27 of 115
Business Services to the system and potentially swap out an existing Business
Service in favor of a newer version or perhaps a different implementation of the
service altogether. This ability to ―plug in‖ Business Services will provide a great
deal of flexibility when adapting the system for future use.
Only the Data Access Layer of each Business Service will have any direct
knowledge of the underlying database structure. This will potentially allow for
changes in the database without affecting either the client programs or the
business process components in the Business Services. This also implies that
the system could be adapted to use a completely different database structure
while limiting the vast majority of the necessary code changes to the Data
Access Layer in the Business Services as long as the database changes did not
affect the business entity structure.
The one common element that ties the various parts of the system together is the
data contained in the Business Entities. This data will be passed between layers
and components of the system and to some extent will create dependencies
between components. The magnitude of these dependencies will be controlled
by defining either base classes or interfaces for the Business Entities, which in
turn will limit the scope of dependencies between system components. This
concept will be discussed further in the Business Services Code Reuse section.
The system can be further extended for broader use by implementing the
interface to external systems (Request Adapters), which will provide the ability to
interoperate with a wide variety of external systems both inside and outside of
the organization.
By employing a modular architecture, the system will be able to adapt to meet
the current and future needs of the organization(s). The system architecture will
function as a high-level framework, which will allow for components (Clients,
Business Services, Databases, etc.) to be swapped in and out as needed.
I1.5.2.7.1.2 Reusable Infrastructure Components
Basic infrastructure components are inherently more generic than business
functionality and therefore tend to be more reusable. One of the primary goals of
the reusability strategy is to obtain or build core infrastructure components, which
can be reused with little or no modification. These core infrastructure
components include, but are not limited to, the following:
Exception management and logging.
Instrumentation.
Low-level database access functions.
Security.
Enterprise Service Bus (ESB).
Business Entity classes.
Service Registry
I1.5.2.7.1.3 Common Data Specification
Since Business Entities, and the data they hold, will be used through multiple
layers of the system, it will greatly enhance the possibilities for code reuse if
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 28 of 115
there is a common set of Business Entities, encapsulating a common set of data,
which will be used by the various layers of the system.
I1.5.2.7.2 Service Oriented Architecture (SOA) Component Layers
Service Oriented Architecture (SOA) is a set of components, design patterns,
guidelines and principles for execution of business processes as a continuously
evolving network of value added services. SOA relies on an integrated
framework that includes a repeatable modeling and development methodology,
open standards, best practices, a reference architecture and a configurable run-
time architecture to provide semantically reconciled model time and run time
environments for a agile enterprise.
SOA is an event driven loosely coupled architecture, that does not require
procedural coding to ―compose‖ applications & transform business objects. All
architectural components are plug-and-play.
The SOA architecture model is consistent with industry best practices for
developing and structuring applications to be scalable and allow the system to be
extensible and maintainable. The architecture style defining a SOA describes a
set of patterns and guidelines for creating loosely coupled, business-aligned
services that, because of the separation of concerns between description,
implementation and binding, provide flexibility in responsiveness to new business
requirements and opportunities. A SOA is an enterprise-scale IT architecture for
linking resources on demand.
In a SOA, resources are made available to participants in a value net, enterprise,
or line of business (spanning multiple applications within an enterprise or across
multiple enterprises). It consists of a set of business-aligned IT services that
collectively fulfill an organization's business processes and goals. A designer can
orchestrate these services into composite applications and invoke them through
standard protocols, as shown in Figure 6 below.
A service is a discoverable software resource with an externalized service
description. This service description is available for searching, binding, and
invocation by a service consumer. The service provider realizes the service
description implementation and also delivers the quality of service requirements
to the service consumer.
The following diagram (Figure 7) depicts the high-level conceptual architecture
for the CCR System. The architecture includes a series of components, which
will be described in greater detail later in this document. This architecture follows
the n-tier SOA model with client programs calling into a business layer, which in
turn manipulates data in the database(s). This architecture also includes an
additional component called the Request Adapter(s), which will field requests
coming from external clients or other systems outside of the organization and
translate these requests into a canonical (see SyRS Glossary) internal XML
format.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 29 of 115
Figure 7 Overview of the Service Oriented Architecture of CCR Application and
Components
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 30 of 115
Table 5 below shows the application layers from the perspective of how end-
users will exercise the application: User Interface components or Incoming
Request Adapter(s) will request business processes/services, which in turn may
consume business services/processes, which in turn will access data through a
data access layer. Each of these layers will share the infrastructure, which
supports the entire application (shown by the vertical bars; an example is the
Enterprise Service Bus Framework).
Table 5 SOA Application Layers
Incoming Request
Façade, MQ, Transformation, Transactions, Routing, Service
User Interface Adapter(s)
Components
Instrumentation Services, QoS, Management & Monitoring
User Interface
Business Entities: (de)serialization; mapping, state mgmt
Process
Components
Business Processes
Business Services
Enterprise Service Bus Framework:
- Composite Services
- Core Services
O/S and .NET Core Services
Business & Application Framework:
- Enterprise Service Components
- .NET Components
Data Access Layer Outgoing request
Security Services
Communication
- Data Service adapters
- Metadata
Registry
External systems
Database & File
System
The following sections provide additional detail about the layers (horizontal and
vertical) of the model.
I1.5.2.7.2.1 Client
Any program that makes service requests to the system would be considered a
Client. This will include User Interface components/process components such as
Windows Forms based Smart Client and ASP.NET ASPX/ASCX
components/process components such as Web Forms applications, which will be
part of a given the CCR System implementation. This may also include Business
Service components or other/external systems, which may ultimately interact with
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 31 of 115
the CCR System to obtain services. Client programs created and maintained
internally will be considered part of the CCR System and will be able to
communicate with the Business Service components directly via the Business
Facade. Clients external to the CCR System will access the system through an
Incoming Request Adapter(s), which will be responsible for translating the
incoming request into an internal canonical XML format and passing it along to
the appropriate Business Façade function.
I1.5.2.7.2.2 Incoming Request Adapter(s)
The Incoming Request Adapter is the doorway into the system from the outside
world. All requests coming from external systems will flow through this
component. Requests coming from external systems may use various formats
and protocols so the Incoming Request Adapter(s) must support these. The
Incoming Request Adapter only deals with requests coming from outside of the
CCR System and acts as Mediation Layer.
The Request Adapter will be responsible for authenticating the caller, verifying
the structural integrity of the request, performing any necessary conversion on
the request so it matches the required internal canonical XML format, and
forwarding the request to the appropriate Business Façade function.
Requests made to the Incoming Request Adapter can be handled online
(synchronously or asynchronously), or via persistent/transactional message
queue or processed as batch.
The Request Adapter will be designed to handle requests using various formats
and protocols. This will allow for a wide variety of other systems to integrate with
the CCR System. Some potential message types and protocols include:
Simple Object Access Protocol (SOAP) Web Services
ACORD XML Business Messages
XML
Excel
DBF
CSV
Other Proprietary Formats
HTTP(S)
TCP/IP
SMTP
MSMQ
WMQ
Network File System
Secure FTP
I1.5.2.7.2.3 Outgoing Request Adapter(s) and Service Agents
The Outgoing Request Adapter and Service Agents will perform any necessary
translation and routing on requests made from any of the internal Business
Services in a CCR System to other services or systems outside of the CCR
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 32 of 115
System environment. The Outgoing Request Adapter only deals with requests
directed outside of the CCR System and acts as Mediation Layer.
Requests made to the Service Agent with Outgoing Request Adapter can be
handled online (synchronously or asynchronously), or via persistent/transactional
message queue or processed as batch.
I1.5.2.7.2.4 Requests/Business Messages
Business Messages are service requests that are passed between components,
layers, and systems of the SOA. A Business Message as defined in this
document is simply an XML formatted request for a service, containing Business
Entity objects as parameters. Calls being made from client to service within a
CCR System will use SOAP formatted Enterprise Service calls and SOAP Web
Service calls and so they are canonical business messages. Business Messages
can also be associated with requests originating from or winding up outside of
the CCR System and may be transformed by Request Adapters to/from
canonical XML format.
If a Business Message is sent via SOAP, then the top-level structure of the
document will be a standard SOAP document with all application specific
information contained inside the SOAP payload.
The application-specific portion of a Business Message should contain all of the
information necessary to execute a particular requested service. This information
will include:
The service to be called.
The function to be invoked.
Information about the calling user/machine.
Contextual information including session/security information.
Simple and complex type input parameters to the function being invoked.
All complex types represent registered CCR Business Entities and are described
by XSD & Resource schemas in the Business Entity Registry. Each Business
Message will include either a Request or a Response, depending on the direction
of the message. Each request must contain an identifier unique to the client
issuing the request, which will be a part of any responses to that request.
I1.5.2.7.2.5 Enterprise Service Bus Layer and Business Façade
ESB is SOA software messaging and integration model for an event-driven and
XML-based messaging engine.
ESB is not necessarily a single software product, but a set of components/design
patterns/products/frameworks/services that together provide the following
foundation capabilities:
Virtualization of Services (eliminates point to point communication model
and virtualizes Service address and transport schema)
Peer-to-peer communication
Events Management
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 33 of 115
Publish/Subscribe model
Transparent interface to Meta-data repository/Services registry to control
Services/Objects
Business Façade Interface
Gateway infrastructure including adapters & mediators
Message Routing, Mapping and Transformation
Message Security including SAML, Kerberos, X509 and custom tokens
Multiple Transports
WS-* compliance
The Business Façade is an abstraction layer between the Clients and Business
Services. The Business Façade provides a public interface for the Integration
Layer used to access the functionality exposed by Business Services.
The Integration layer enables the integration of services through the introduction
of a reliable set of capabilities, such as intelligent routing, protocol mediation, and
other transformation mechanisms, often described as the Enterprise Service Bus
(ESB). The ESB provides two fundamental capabilities:
A Web Services Description Language (WSDL) which specifies how a
requesting component binds with a service component.
A location and transport independent mechanism for integration of the
components. That is, the ESB hides the complexities associated with
location of where the service is provided and transport schema from the
requesting component.
The ESB will be implemented as client proxy library components, server
wrappers library components and Service Broker Servers. This layer also serves
to abstract away some of the details of the underlying Business Services by
providing wrappers to the Business Services functions. These wrappers can be
used to implement an additional level of workflow by calling on multiple Business
Services in different ways. Application-level security authorizations will be
performed in the Business Façade so this layer can also be used to bundle
various Business Services calls together in different ways to expose variations of
features to clients, which can be secured and authorized differently.
The Business Façade will also manage database or Distributed Transaction
Coordinator (DTC) transactions. All database/DTC transactions will begin and
end in the Façade layer. For this reason, the units of work that must be
transactional should be broken down into individual Façade functions. Each
Façade function will have the ability to begin either a local or a distributed
transaction, or no transaction at all. All of the downstream calls from the Façade
function will then be enlisted in the transaction it created.
The Business Façade is also responsible for authenticating the calling client
application to verify that it is a valid CCR System client which is authorized to use
the services of the Façade.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 34 of 115
I1.5.2.7.2.6 Business Services
The functionality of the system will be partitioned at a high level into a set of
Business Services. Business Services provide conceptual and potentially
physical boundaries between different sets of related functionality in the system.
Each Business Service will include business logic, data access logic and
Business Entities for a highly cohesive subset of functionality (See Figure 8
below).
Business Services should exhibit the following characteristics.
The functionality within a Business Service should be closely related and
highly cohesive.
Business Services should be loosely coupled with other Business
Services.
Each Business Service should expose a public interface containing a set
of ―top-level‖ methods, which will be callable from the Business Façade
Layer or from other Business Services. All implementation details of the
Business Service will be hidden behind this public interface.
Business Services should be stateless between top-level method calls.
Business Services should implement any necessary transaction
management and rollback functionality required to perform their tasks
correctly and ensure the integrity of the resources they access.
Any unit of functionality, which is likely to be replaced or significantly
upgraded at a later date, is a potential candidate to become a Business
Service.
A Business Service should be capable of performing work online
synchronously, online asynchronously and offline asynchronously.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 35 of 115
Figure 8 Business Services Diagram
I1.5.2.7.2.7 Business Process Layer
The Business Process Layer exposes top-level functions, which will execute
units of work in the system. This layer contains the code to manage the process
of a request, execute business logic, and make calls to the Data Access Logic
Layer to interact with the database. A Business Process Component may also
call out to another Business Service in the system, or call out to another service
outside the system through the Service Agents with Outgoing Request Adapters.
Classes making up this layer will be stateless. The objects will only stay alive for
the duration of a single top-level method call from the Service Façade layer. It is
possible for Business Process Components to invoke methods on other Business
Process Components via Business Façade.
I1.5.2.7.2.8 Business Entities
Business Entities will map raw data from the database into an internal format to
be used by other parts of the system. There are four commonly used options in
the .NET world for implementing Business Entities and passing data through
tiers.
1. Implement a set of classes that model the data. These would be classes
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 36 of 115
such as Claim, Employer, Person, etc. The main advantage to this
approach is the ability to maintain a great deal of control over how the
data is managed and presented and the ability to implement data
validation code into these classes. Also, this approach will allow greater
use of compile-time type checking and Visual Studio IDE support. The
disadvantage here is that this will involve quite a few classes, it will require
a significant effort to implement and it does not use metadata to handle
Business Entities making it very expensive to maintain.
2. Maintain the data in either typed or un-typed datasets. This will involve
less up front work because it will not be necessary to create all of the
classes mentioned in the previous option. This approach will make the
code that uses this data more complex because instead of working with an
intuitive set of objects it will have to work with complex datasets. It also
does not allow Data Objects to be de-coupled from Data Sources
3. Maintain the data in XML documents. This will involve less up front work
because it will not be necessary to create all of the classes mentioned in
the previous option. This approach will make the code that uses this data
less complex because all Business Entities are logically dynamic
structures, which map to XML documents very well. However, this
approach does not use metadata for Business Entities and makes the
code to save or read Database more complex.
4. Implement XML Data Objects (XDO) as a small set of Object Model
classes as disconnected containers of data objects similar to a Service
Data Object (SDO) and functionally richer than SDO. These classes will
use Business Entity schema meta-objects to maintain and handle all
Business Entities as instances. Business Entity schemas meta-object
includes XSD/Resource schema, XML<=>relational data model
transformation map, Object Template, data validation rules, and Business
Entity links. The Business Entity class may inherit .NET iSerializable class
with SOAP/XML UTF8 formatter for Business Entity automatic serialization
by SOAP requests and state service. The Business Entity class will
encapsulate XML documents to maintain data as a dynamic structure and
enable all XML manipulation functionality to Business Services code and
Presentation code. The Business Entity class will transform automatically
XML document representation of a Business Entity to Relational Model
(tables) using Mediation layer and meta-objects. This will simplify
application Data Base access code. Business Services classes can inherit
Object Model classes to add any custom functionality. Business Entity
container classes (Set, Hash table and Ordered List) will maintain state of
all Business Entities processed by a given session.
Given the volume and complexity of the data required for the various CCR
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 37 of 115
Systems and the overall size and scope of the project, Option 4 is selected as
the best choice. The ease of implementation and maintenance of the application
system as a whole will more than make up for the extra effort required to design
and implement the Business Entity classes.
The system will use XML data Objects (XDO).
XML Data Objects (XDO) definition:
XDO is XML Data Objects model based on the concept of disconnected data
graphs (Object Containers). A data graph is a collection of tree-structured data
objects (e.g. XmlDocuments). Under the disconnected data graphs architecture,
a client retrieves a data graph from a data source, mutates the data graph, and
can then apply the data graph changes back to the data source. Each tree-
structured data object in the data graph must support automatic XML
(de)serialization.
XDO is an advanced SOA Disconnected Data Programming Model based on
optimistic concurrency.
All XDO Data Objects have XDO Schemas, which define Data Objects structure,
constraints, properties, validation rules, states and processing events/actions.
XDO Data Objects are de-coupled from Data Sources.
XDO is not a single software product, but a set of components/design
patterns/products/frameworks/services that together provide these required data
objects foundation capabilities.
All XDO Business Entities will provide a way to view the entity as a human-
readable XML text string to facilitate logging and troubleshooting.
The primary purpose of classes in this layer will be to maintain state so obviously
all XDO Business Entity classes will manage state. The state maintained in these
objects may be passed between layers. It is also possible that this state may be
maintained as Session State on the Web server so it may actually live in the
state service between client requests to the Web server.
I1.5.2.7.2.9 Business Services Communication Model
This SOA concept is based on an architectural style that defines an interaction
model between three primary parties: the service provider, who publishes a
service description and provides the implementation for the service, and a
service consumer. A diagram showing the details of the constructing,
transporting, and fielding of a request as it moves through the application
infrastructure layers of both the service consumer and service provider is shown
below in Figure 9.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 38 of 115
Figure 9 Service Stack Layers
The service consumer can locate the service description in a ―Service Registry (a
directory maintaining the definition and location of all registered services) and
bind and invoke the service. The service broker provides and maintains the
Service Registry in the System Repository.
Each Business Service will have Service Description meta-object stored in the
Service Registry of the System Repository. The Service Description has
execution control properties including: WSDL, transaction control attribute,
transport schema, channel name, location of service, parameters
validation/filtering rules, priority, execution mode (online/offline), schedule for
periodically executed Services, configuration settings, dependencies, etc.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 39 of 115
A meta-model showing these relationships is depicted in Figure 10 below.
Figure 10 Meta Model showing Service Component Relationships
I1.5.2.7.2.10 Data Access Logic Layer
The Data Access Logic Layer is an abstraction layer between the Business
Services Layer and the underlying database(s). The Data Access Logic Layer
provides a public interface for System Objects Repository and exposes a set of
functions to the Business Process Layer, which provide access to the underlying
database(s). Business Entity objects may be passed in and out of these functions
and will contain inputs for database updates and outputs with database results.
All details related to the underlying database(s) will be encapsulated in this layer
so the Business Process Components need not know anything about the
database structure, tables, views, stored procedures, etc.
A single Data Access Logic Component (DALC) function might make multiple
calls to the database retrieving multiple result sets, then combine this data into
one or more Business Entity objects, which will be returned to the caller.
Likewise, a single call to a DALC function might take a complex set of data in one
or more Business Entity objects and use this data to make multiple updates to
the database. Each function exposed by a DALC can participate in a maximum of
one database transaction.
The Data Access Logic Layer will act as mediation layer for the Business Entity
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 40 of 115
classes to transform data objects to/from relational tables using Business Entity
description meta-objects. The Data Access Logic Layer has to use disconnected
data architecture and optimistic concurrency models. In traditional data access
components, you make a connection to the database system and then interact
with it through SQL queries using the connection. The application session stays
connected to the DB system even when it is not using DB services and uses a
pessimistic concurrency model to update the database. This commonly wastes
the valuable and expensive database resources as, most of the time, the
applications session does not use the database. The DAL layer has to manage
database connection pool and optimistic concurrency events and isolate
applications from managing them. When an application needs to pass a request
to the Database it will be provided with an available connection from a database
connection pool and after that request is completed, the connection will be
returned to the pool of available open connections.
Another important aspect of the disconnected architecture is that it maintains the
local container (set) of Business Entities. This set can be transformed
automatically into dataset of tables, their relationship and different constraints.
The application performs operations like update, create, delete to Business
Entities in the session local container and finally this changed container is
transformed to tables and stored in actual database as a batch when needed.
This greatly reduces the network traffic and results in the better performance.
I1.5.2.7.2.11 Generic Data Access Functions
The Data Access Logic Layer will utilize the appropriate set of Generic Data
Access Functions to access the underlying database. The Data Access Logic
layer is a thin layer of generic database functions used to access the database.
This would include functions to execute a database command, stored procedure,
etc. This layer will expose a generic DBMS-independent interface that will sit on
top of various underlying implementations designed to access specific
databases. At a minimum, this layer will support SQL Server and DB2 databases.
I1.5.2.7.2.12 Database & File System
This layer represents the physical data storage for the Relational Database
Management System (RDBMS). The CCR System architecture provides for the
use of multiple back-end data sources of different types.
Switching from one back-end database to another (i.e. SQL Server to DB2), after
the implementation of the CCR System will require minimal updates of elements
within the database (tables, views, triggers, etc.) and using same Generic Data
Access Functions implementation. If the data model changes then the Data
Access Logic Layer will not need to be updated. The only required changes will
be in metadata of Business Entities.
Mutli-channel access to UIMOD system.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 41 of 115
HTTP(S) URI
WS SOAP
WS SOAP
Data Entity
Business Entity
VoiceXML or CCXML
document
Presentation Layer Application Layer
Speech Browser Platform Web VXML/CCXML Business Services or Data Access Layer
Layer Document Server Integration Broker
Figure 11 IVR Channel Conceptual Process Architecture
Figure 11 depicts the IVR Conceptual Process Architecture that has been
adopted by UIMOD. In the adopted architecture, when a call is received, it is
detected by the Speech Browser platform. The platform sends an event to the
CCXML or VoiceXML markup interpreter, which looks in its context for the URI of
the initial document to fetch. The interpreter sends a Request to the Web
VXML/CCXML Document Server for the initial VXML/CCXML document. The
Web VXML/CCXML Document Server is a standard UIMOD Web Server residing
in DMZ as part of UIMOD Web Servers cluster. These UIMOD Web Servers can
run multiple applications concurrently including VXML/IVR channel application
and UIMOD Web Access channel applications.
The Web VXML/CCXML Document Server sends the SOAP request to the
Business Service for the initial Business Entity object(s). The Business Service
sends the SOAP request(s) to the Data Access Services for the initial Data
Entities. The Data Access Services sends Data Entities back to the Business
Service. The Business Service transforms Data Entities into Business Entity
object and sends the Business Entity object back to the Web VXML/CCXML
Document Server.
Business Services run on Application Servers and provide common services for
all applications (including IVR and Web access channels).
The Web VXML/CCXML Document Server then uses Business Entity and meta-
data (VXML/CCXML templates) to dynamically build a VXML/CCXML document
and sends the VXML/CCXML document back to the CCXML or VoiceXML
Markup Interpreter which instructs the Speech Browser Implementation Platform
on the first steps to perform on behalf of the caller. The Markup Interpreter then
interprets the result of an execution in the Speech Browser Platform. The
interpretation may result in the Markup Interpreter making additional document
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 42 of 115
requests to the Web VXML/CCXML Document Server.
Figure 12 shows the components for a VoiceXML system.
This integrated platform receives VoiceXML and CCXML pages from a Web
VXML/CCXML document server.
Phone
Call Control Manager
Dialog Manager
Forms
Voice Interpreter Text
VXML
Rec. Parser Algorithm To
Speech
voice
Process Collect Select Initialize
AudioI Phase Phase Phase Phase Audio
nput
DTMF Output
DTMF audi
Rec.
o
play
Figure 12 VoiceXML Components
The Speech Browser has to execute the CCXML and VoiceXML pages to
provide the speech service to the caller connected over the telephone network
(PSTN or VoIP). The Speech Browser Platform has to logically consist of four
parts:
1. Main process and operations, administration, and maintenance
system: collection of tools responsible for system management and error
reporting.
2. VoiceXML and CCXML engines: interpret the VoiceXML and CCXML
markup and calls into the implementation platform to render the markup.
3. Speech Browser Platform: provides the high-level services necessary
for the system to run, including the recognition engine, prompt engine,
ASR, TTS, Internet fetch library, and ECMAScript engine.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 43 of 115
4. Telephony and base services: base operating system services and
telephony services needed to receive phone calls. It must support VoIP,
T1, PRI, and Analog.
I1.5.2.8 Known Inconsistencies Among Views
There are no known inconsistencies.
I1.5.3 Viewpoint Name: Business Intelligence and Reporting
Application Architecture
I1.5.3.1 Overview
This section discusses the application and technical architecture for
businessIntelligence and reporting.
I1.5.3.2 Stakeholders
Acquirers
Architects
Vendors/Integrators
I1.5.3.3 Concerns
How do we ensure consistent reporting?
How do we support business intelligence, e.g., the use of data to discover
fraud patterns?
How do we integrate different sources of data into our reporting
environment?
How do we ensure modularity and scalability of the CCR System?
How do we maintain historical data for reporting purposes?
I1.5.3.4 Viewpoint
This viewpoint describes the application layers and components comprising the
architecture for reporting and business intelligence.
I1.5.3.5 Viewpoint Language
The description of business intelligence and reporting architecture includes:
Data warehouse architecture and layers.
Definition of subject areas.
I1.5.3.6 Rationale for the Viewpoint
Reporting and Business Intelligence is a key capability of the CCR System. To
ensure scalability and flexibility, the CCR System requires a separate reporting
environment designed for large volumes of data and queries.
I1.5.3.7 Views, Models and Descriptions
The application architecture required for business intelligence and reporting is
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 44 of 115
based on modern data warehouse architecture (Figure 13) which includes 6
components/layers.
I1.5.3.7.1 Operational Systems
Production data sources that contain source data (system of records) for
business intelligence and fraud detection analysis and reporting. Operational
systems may be internal or external systems. Operational systems may also
include reference data. Operational systems which are likely to feed data into the
CCR System data warehouse are shown in Table 5.
Data Warehouse and Business Intelligence/Reporting Design Patterns
Central Constituencies
Operational Warehouse( Marts
Systems s)
Senior
Client EIS Management
Payments History
UI/DI
SCDB
Call Center
Information Metadata Query / Agents
Management
WBCF Data
Access Reporting
Model Layer
Base ETL
Wage Claimants Fraud
Data Analysts
Repository Mining
Supervisors
Analytics Statistics
TAS
Txn History Financial
Multi- Analysts
External
Data OLAP Dimensional
Cal Jobs
Figure 13 Target Architecture for BI and Reporting
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 45 of 115
Table 6 Operational Systems and Data Sources for the CCR System Data
Warehouse.
Name of System Overview of System Functionality
Activity Calendar and Event A scheduling system used by Job Service Staff to schedule
Scheduler (ACES). appointments and workshops, and post attendance results.
Base Wage Database A DB2 database containing employer, employee and used for
(BWDB) calculating Unemployment Insurance and Disability Insurance
benefits. Also contains table to support SSN/name verification.
Benefit Accounting System A collection of applications used to process accounting of
(BAS). Unemployment Insurance and Disability Insurance benefit
payments and overpayments. The BAS provides for tracking of
disbursement of funds to other entities, reconciliation of bank
accounts, posting payment transactions to Claimant
overpayments, etc. The BAS uses the SCDB as its primary
data store.
California Job Opening A Web-based system where job seekers can enter their
Browser System (CalJOBS). resumes and employers enter job opening information. The
system matches job seekers to suitable job openings based on
skills and job requirements. Unemployment Insurance
Claimants may be required to enter a resume in CalJOBS as
part of their job search requirements.
CCR System. The new proposed systems for Continued Claims.
UI Demographics Systems. The UI Demographics system is a new (sub) system for
maintaining UI demographics. While this systems is part of the
CCR System project, it will be maintained as a separate
component (sub-system) maintaining the demographics
systems of record.
Disability Insurance System A collection of applications used to process and maintain
(DIS). Disability Insurance claims. The DIS uses the SCDB as its
primary store and shares some data and processes with the
Unemployment Insurance System.
Program Activity Support A system used by Job Service staff to record services provided
System (PASS). to clients.
Single Client Data Base An IDMS database designed to maintain claim and payment
(SCDB) information for the Unemployment and Disability Insurance
benefit programs. The term is also used loosely to refer to the
CICS/COBOL applications that form the automated
Unemployment Insurance, Disability Insurance, Benefit
Accounting and related systems.
Tax Accounting System The TAS is used to account for monies (taxes and
(TAS). withholdings) sent in by employers. It contains employer
information such as employer name, employer account number
(tax ID number), and address. The TAS utilizes an IDMS
database.
Unemployment Insurance A system used to create, allocate and maintain schedules for
Scheduling System (UISS). determination of eligibility appointments. The system also
generates an appointment notice to the Claimant and various
reports used to manage workload. The UISS is an
MVS/CICS/COBOL application running on a DB2 database.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 46 of 115
Name of System Overview of System Functionality
Unemployment Insurance A collection of applications used to process and maintain
System (UIS) Unemployment Insurance claims. The UIS uses the SCDB as
its primary store. The continued claim process is currently part
of UIS.
Web Based Claim Filing An intranet system currently under development that will
(WBCF) provide UI staff with Web-based tools for filing initial UI claims.
The CCR System will utilize data collected by WBCF.
Worker Profiling and An automated system used to identify Unemployment
Reemployment Services Insurance Claimants who are likely to exhaust their UI benefits
(Profiling) and provide them with job search assistance. Claimants
selected to participate are referred to various workshops and
may be required to complete additional activities. A Claimant
may be disqualified from receiving UI benefits for failure to
participate in Profiling activities. The Profiling system utilizes a
DB2 database.
I1.5.3.7.2 Extraction, transformation and loading (ETL)
The ETL tools support the acquisition and integration of data from multiple
source databases, facilitate changing the structure and content of that data, and
then deliver it to the central warehouse. The ETL tools support the movement of
data for batch-oriented data integration processes that will feed data warehouses
or data marts. The EDD intends to use the extensible ETL tools available from
the ETL tool vendor that allows development of custom adapters and
transformation rules using standard XSL, XML, and .NET Framework and Bulk
Loaders to the central warehouse. Note: in case data needs to be moved in real-
time, it may require the use of application server or integration broker/server
technologies.
I1.5.3.7.3 Central Warehouse(s) and Data Marts
The Central warehouse(s) includes information repositories that are non-
transactional in nature and optimized for reporting. The information repositories
for the central warehouse(s) are enterprise in scope and include highly detailed
data. Typically the data in the data warehouse is normalized to provide high
degree of flexibility for reporting and analysis purposes.
The central warehouse(s) also includes administration tools that support data
usage auditing, business model maintenance, directory management, summary
table building, security control, metadata management, query cataloging,
maintenance of reference data, managing production data extracts and
performing backups.
Data marts are decentralized subsets of data from the data warehouse(s) or
other sources designed to provide efficient reports and analysis around a specific
topic and /or for a specific business unit. Data marts are typically oriented
towards a specific group or set of users. Data in the Data Marts are typically de-
normalized and often structured using star-schemas or cubes.
I1.5.3.7.4 Metadata Layer
Metadata is data about data. Metadata provides information not explicitly present
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 47 of 115
in data, but necessary for storage, retrieval or processing. Organizing content by
metadata can enable information retrieval through references that are based on
common knowledge. Metadata has been employed in publishing ever since the
first library contained references to publication attributes in a separate
information directory (e.g., date of publication acquisition or a summarization of
publication content).
To maximize the flexibility and use of data, the data warehouse information must
have metadata and a simple mechanism for a user to read the metadata. The
metadata architecture must support the following:
BI/Reporting tool independent navigation of data.
Time stamping of all data.
Allow user to navigate the metadata to create reports and queries.
Allow open access to third party reporting and BI tools for navigation of
data.
Allow user to view and retrieve metadata in an XML format.
I1.5.3.7.5 Business Intelligence Tools
Business intelligence (BI) tools include BI suites, BI platforms and data mining
tools. The BI suite is a thin client end-user tool, supporting common BI usage
through ad hoc database query, basic report generation, online analytical
processing (OLAP) viewing and light analysis. The BI platform is a development
platform for creating custom BI applications.
I1.5.3.7.6 Data Management and Data Quality
The data warehouse is assumed to be built around a normalized information
model comprised of several business entities. For more detailed information on
the business entities in the data warehouse, refer to the Business Entities
Architecture in the Technical Architecture Section of this document.
Since the data in the data warehouse is used for reporting it must meet certain
quality criteria including:
Data in the data warehouse should be time stamped using common time
dimensions to allow correlation across all data.
There should be minimal redundancy of data in the data warehouse.
The data warehouse needs to maintain a historical view of data.
If changes to data occur in the operational systems as a result of errors,
these changes must be propagated to the data warehouse.
Metadata using XML standards should be used to describe all data in the
data warehouse.
Metadata is required to track changes to data.
I1.5.3.8 Known Inconsistencies Among Views
There are no known inconsistencies.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 48 of 115
I1.6 Technical Architecture
I1.6.1 Viewpoint Name: Technical Architecture Model
I1.6.1.1 Overview
The Technical Architecture addresses the technology infrastructure and
associated requirements. The Technical Architecture provides guidelines and
recommendation for application developers for how to best leverage reusable
infrastructure services to simplify development and ensure reusability and
extensibility. The Technical Architecture also provides strong guidelines for
implementing information security.
I1.6.1.2 Stakeholders
Acquirers
EDD Architects
Vendors/Integrators
Developers
Security Architects
I1.6.1.3 Concerns
Ensure standard implementation of core Enterprise Services.
Ensure standard implementation of Information security (e.g.
authentication, authorization, confidentiality, integrity, and availability ).
Provide application development guidelines to ensure that application
developers are taking advantage of core infrastructure services.
Provide supportability and maintainability of application infrastructure.
Provide application developers and architects with common standards and
frameworks for implementation of key components including, Business
Façade, Business Functions, and Business Entities.
Ensure common standards for data validation.
Provide guidelines around software extensibility.
Provide guidelines and standards for Data Connection Pooling.
Provide guidelines and standards for State Management.
Provide guidelines and standards for Data Access Management.
Provide guidelines and standards for the Application Development
Infrastructure and Architecture.
Provide guidelines and standards for Error Handling.
Provide guidelines and standards for Logging and Auditing.
Provide guidelines and standards for Instrumentation.
I1.6.1.4 Viewpoint Language
Standards, guidelines and principles for application development.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 49 of 115
Description of class definitions.
.NET Enterprise Services.
COM + Services.
I1.6.1.5 Rationale for Viewpoint
This viewpoint provide guidelines and recommendations to address many of the
very complex issues of application architecture issues which are not always
addressed and as a result typically create complex problems in the later phases
of development.
By establishing these guidelines, the EDD will increase opportunities for
standardization and reuse.
I1.6.1.6 Views, Models and Descriptions
I1.6.1.6.1 Enterprise Services (.NET and COM+ Services)
I1.6.1.6.1.1 Overview
To build robust and scalable enterprise class applications the System
Infrastructure has to provide Business Services with a set of system-level
services such as distributed transaction management, object pooling, thread
pooling, loosely coupled events, role-based security, etc. Microsoft (MS)
Windows and .NET provide a set of system-level services called .NET Enterprise
Services. Enterprise Services in .NET provide an enterprise class container for
Business Services Components similar to Enterprise Java Beans (EJB) in the
Java2 Enterprise Edition (J2EE) environment.
Prior to .NET these services were collectively called COM+ Services. The .NET
Framework contains the EnterpriseServices namespace, which provides access
to COM+ services for .NET applications. Some of these enterprise services have
relatively simple alternatives such as thread pooling offered by Internet
Information Services (IIS).
The following sections describe many of the available enterprise services along
with four options for accessing these services from a .NET application. Typical
clients of enterprise services are ASP.NET Web pages, ASP.NET Web Services
or Background Windows Services.
I1.6.1.6.1.2 COM+ Services Available Through EnterpriseServices
I1.6.1.6.1.2.1 Transaction Management
Transaction management is probably the most significant feature of COM+
Services as they relate to the UIMOD project. COM+ transactions offer the
following key benefits:
Automatic management of distributed (two-phase commit) transactions.
Simplified programming model using declarative transactions.
The ability to easily change the transactional behavior of an object depending
on where and how it is being used. This is done by setting the transactional
attribute (Requires New, Required, Supported, etc.).
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 50 of 115
COM+ transactions used to suffer from the problem that under COM+ 1.0
(Windows 2000 Server), all COM+ transactions run at an isolation level setting of
Serializable, which can have a significant negative impact on database
concurrency. The isolation level is adjustable in COM+ 1.5 (Windows XP or
Windows Server 2003) and allows setting of low isolation level to achieve best
performance with Optimistic Concurrency model.
The likely alternative to COM+ managed transactions would be to manage local
transactions directly, using the facilities of ADO.NET. This may add to the
complexity of the code.
I1.6.1.6.1.2.2 Thread Pooling
When components run in the COM+ environment they are able to take
advantage of the automatic thread pooling services provided by COM+. This
frees the developer from the need to be concerned with thread pooling while still
enjoying the scalability and performance benefits.
I1.6.1.6.1.2.3 Just-In-Time Activation
Through Just-In-Time Activation (JIT), COM+ creates and destroys objects for
individual method calls in a way that is transparent to the caller. The JIT is a
required feature when using some other COM+ services such as transaction
management, but would not provide any usefulness by itself to the design. This
functionality is also provided automatically when using Web Services with the
SingleCall option.
I1.6.1.6.1.2.4 COM+ Events (Loosely Coupled Events)
COM+ Events provide a way for event publishers and event subscribers to
operate independently of each other with the COM+ event infrastructure
intervening to route published events to the appropriate subscribers. The
advantage of COM + Events over native .NET events/delegates is the support
for non-running subscriber objects – that is, COM + Events provide the capability
to handle situations where the subscriber objects are not running. COM + Events
provide the capability to restart subscriber objects if they are not running when
the request is made.
I1.6.1.6.1.2.5 Object Construction
COM+ Object Construction provides a way to construct objects using information
stored in the COM+ catalogue. This behavior can be simulated by allowing object
constructors to read information from configuration objects during construction.
I1.6.1.6.1.2.6 Object Pooling
The COM+ object pooling mechanism offers a simple way to create a pool of re-
usable objects, which are not actually torn down between method calls. To utilize
object pooling, objects should be completely stateless between method calls and
they must be free-threaded. COM+ object pooling could offer significant
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 51 of 115
performance and scalability enhancements as creating and tearing down objects
could be a fairly expensive operation due to memory allocations and de-
allocations.
I1.6.1.6.1.2.7 Private Components
COM+ allows a component to be marked as private and thus only accessible by
other components within the same application. This is conceptually similar to, but
more flexible than marking a .NET class so it is only accessible to other classes
within the same assembly. The COM+ feature is more flexible because it can be
set declaratively and it can be changed after deployment.
I1.6.1.6.1.2.8 Queued Components
COM+ allows components to use Microsoft Message Queue (MSMQ) to
communicate. This feature provides a very simple way to expose asynchronous
methods from a component and to take advantage of other benefits offered by
message queuing such as guaranteed delivery and participation in transactions.
The Queued Components feature also offers message retry and dead message
handling capabilities.
Some of these features such as asynchronous method calls can now be
achieved fairly easily using .NET framework capabilities. To achieve high
performance, the CCR System architecture solution will use only asynchronous
invocation of Enterprise Services (mostly via .NET asynchronous calls and in
cases require reliable transport to the Enterprise Service as it will invoke via
MSMQ).
I1.6.1.6.1.2.9 Role-Based Security
COM+ Role-Based Security adds an additional abstraction to the typical
Windows security model allowing users and groups to be added to roles, which
can then be granted various permissions in the system. Using COM+ Role-Based
Security will simplify the design and programming when it is necessary to run
middle-tier components under a specific user account, or, when it is necessary to
control middle-tier (system level) security administratively at runtime.
I1.6.1.6.1.2.10 Synchronization (Activities)
COM+ provides a synchronization abstraction called an Activity, which can be
thought of as a logical thread of execution. COM+ serializes access to objects in
an activity. This is conceptually similar to the older usage of components in single
threaded application but more efficient because objects executing in activities
need not be bound to a single physical thread.
I1.6.1.6.1.3 Options and Recommendations for Accessing Enterprise Services
The following four options outline the ways to access Enterprise Services from a
.NET application along with the major benefits and problems associated with
each one.
Option1: ServicedComponents usage in Business Classes
Derive business classes from System.EnterpriseServices.ServiceComponent,
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 52 of 115
which will provide access to the full suite of Enterprise Services.
Benefits
Provides the highest degree of flexibility for the architecture.
Provides the greatest support for writing reusable components without
requiring code changes.
Makes all COM+ services available, including Transactions, Object
Pooling, Queued Components, Low Memory Activation Gates, etc.
Provides automatic support for transactions across process boundaries.
Provides full declarative model for services.
Supported on Windows 2000 Professional and Server, Windows XP, and
Windows 2003 Server.
Problems
This option has the most complicated deployment of the four.
Option 2: Services without Components usage in Business Classes
The CCR System can use the ServiceDomain class (.NET Framework) to enlist
specific blocks of code into a distributed transaction without the need to derive a
class from ServicedComponent.
Benefits
Eliminates the need for ServicedComponents and their associated
deployment concerns.
Provides the highest degree of control over transaction management. Any
block of code can be enlisted in a transaction.
The higher degree of control will offer opportunities to improve
performance at the expense of more complex design and code and
potentially hindering reuse.
Problems
Will only run on Windows Server 2003. This may have a serious impact on
the ability to write and debug code on development Windows XP
workstations.
This option only provides support for Transactions. Other services like
Object Pooling and Queued Components are not supported.
This option will require additional code and potentially more complex code.
This option does not use the declarative model, which probably means a
negative impact on component reuse.
No automatic support for transactions across process boundaries.
Option 3: Web Service/ASP.NET Page Transactions
Mark an ASP.NET Page or a Web Service WebMethod with a TransactionOption
attribute, which will enlist the Page or the WebMethod in a new distributed
transaction.
Benefits
Eliminates the need for ServicedComponents and their associated
deployment concerns.
Transactional behavior can be defined at the method level.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 53 of 115
Overall, this is probably the simplest way to take advantage of the COM+
Transaction Management services, but it is also the most limiting.
Provides a quasi-declarative model, allowing transactional behavior to be
set with an attribute on the WebMethod.
Supported on Windows 2000 Professional and Server, Windows XP, and
Windows 2003 Server.
Problems
This option only provides support for Transactions. Other services like
Object Pooling and Queued Components are not supported.
This option does not use a true declarative model, which means a
negative impact on component reuse.
No automatic support for transactions across process boundaries.
Only works with Web Services, which may have a performance impact.
This option has highest overhead, because it has a longest duration
transactions
Option 4: ServicedComponents usage in Business Façade
Derive Business Façade from System.EnterpriseServices.ServiceComponent,
which will provide access to the full suite of Enterprise Services. All other
Business Classes will not derive from System.EnterpriseServices.
ServiceComponent. All Business Services can communicate with each other only
via Business Façade.
Benefits
Provides the highest degree of flexibility for the architecture.
Provides the greatest support for writing reusable components without
requiring code changes.
Makes all COM+ services available, including Transactions, Object
Pooling, Queued Components, Low Memory Activation Gates, etc.
Provides automatic support for transactions across process boundaries.
Provides full declarative model for services.
Supported on Windows 2000 Professional and Server, Windows XP, and
Windows 2003 Server.
This option has the simple deployment, because only Business Façade
requires COM+ registration.
Problems
Of the four options, this may be the most complicated to implement.
EDD UI Strategy and Approach - The CCR System chooses to use Option 4,
―ServicedComponents usage in Business Façade.‖
I1.6.1.6.2 Business Message Format
Business Services will handle requests in the form of a Business Message. The
EDD will, as part of the detailed design, develop a formal messaging standard for
requesting a Business Service. The following format is an example of what an
XML-based Business Message might look like. Standard formats such as
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 54 of 115
ACORD may also be used.
(Note, the sample message format (Figure 14) is only meant to illustrate the
possible elements that might appear in a Business Message. This is not meant
to be a complete representation and it is not a design from which to implement
an actual Business Message.)
BusinessMessage
o UserInfo
─ UserName
─ Password
o ClientInfo
─ Client Program Name
─ Client Program Version
─ IP Address of Client Machine
o SessionInfo
─ SessionKey
o Request
─ RequestID
─ Service
─ Function
─ SynchronousFlag
─ InputData
» Various
o Response
─ Request
─ RequestID
─ ResponseID
─ OutputData
» Various
Exceptions
Exception(s)
Figure 14 Sample BusinessMessage Format
I1.6.1.6.3 Security
I1.6.1.6.3.1 Security Overview
The security overview describes the various security services and protected
resources of the system at a high level. Each section or layer of the system will
be examined and security related issues are discussed.
CCR System Security Services:
Trust & Identity Management
Threat Defense & Infrastructure Protection
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 55 of 115
Secure Connectivity
Secure Business Processing
Secure Data Storage & Management
Business Continuity
Auditing and Forensics
CCR System Protected Resources:
Web servers
Application servers
Database servers
Service Broker servers
Call Manager servers
Voice Mail servers
Voice gateway servers
Business Services
Business Processes
Business Entities
Data Access Logic Layer (Repository of Business Entities)
PC(s)
IP Phone
I1.6.1.6.3.2 Core Security Services
The CCR System framework solution has to provide delivery of core security
services in the areas of Authentication, Entitlements, Authorization,
Accountability and Cryptography:
Implement integrated core security services infrastructure
Implement End-to-End Trust model
The distributed CCR System framework has to provide common Core Security
services for all the EDD applications and support all classes of users
(employees, employers, claimants, and partners), all types of clients (Intranet
Smart Client, Intranet Thin Client, Internet Thin Client, and Extranet clients), all
message transports (HTTP(S), TCP and Reliable Message Queuing), and all
platforms (.NET on Windows and OS/390).
It will be accomplished by abstracting applications from message transports,
platform, Directory access, Services discovery, availability, cryptography, and
O/S dependent authentication/authorization functions.
The CCR System Security Infrastructure will be based on Federated Systems
Security Model, XRI technology and include three or more federated security
systems:
MS Windows Security based on Kerberos.
RACF for OS/390.
Custom Security of Web Portal/Application.
TAMe Security for Web Portal/Applications.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 56 of 115
CCR System Security Infrastructure has to implement full delegation of security
principal credentials and trusted Proxy accounts between federated systems.
There are multiple security technologies available for securing distributed
infrastructure.
I1.6.1.6.3.2.1 SSL/TLS for Secure Communication
SSL/TLS is a transport protocol based option, used to secure communication by
securing the underlying transport. SSL supports authentication, encryption, and
integrity. With client certificates, mutual two-way authentication can also be done
using SSL. However, in intranet scenarios, the costs of setting up the certificate
infrastructure and maintaining it can outweigh the benefits.
SSL cannot provide an end-to-end security context for Web services with
intermediate nodes (ESB gateway router as the intermediate node).
A limitation of SSL is lack of support for non-repudiation and authorization.
Because of its point-to-point security architecture, SSL is not a good choice for
Web services that need to be exposed on multiple transports or where
intermediate nodes are involved. SSL supports complete message encryption,
but there is no support for partial encryption. Hence, intermediate nodes have to
decrypt everything before routing it to the next node. This poses a threat to
confidentiality of data that must be seen only by a specific receiver. Performance
can be another issue when using SSL, specifically during the handshake
process.
The CCR System distributed infrastructure will use SSL only for HTTP
connections which have to use Basic Authentication or send clear-text
confidential data due to some limitations of the currently used infrastructure
products (like TAMe and CWS) or which are used for special security
management (like keys exchanges).
I1.6.1.6.3.2.2 Web Services (WS)-Security
The WS-Security is the security specification of Global XML Web Services
Architecture (GXA), jointly developed by IBM, Microsoft, and VeriSign. The WS-
Security specifications describe how to attach security tokens to SOAP
messages and how to transport them from client to server. The WS-Security
proposes to send security information by adding security tokens that flow in
SOAP headers. No specific type of token is required by WS-Security. The
security tokens may include Kerberos tickets, X.509 certificates, SAML tokens, or
custom binary tokens. The WS-Security is based on existing security standards
like XML Signature and XML Encryption. Message integrity and non-repudiation
are provided.
Since the CCR System Web Services need to be exposed on multiple message
transports in a heterogeneous environment and intermediate nodes may be
involved, the WS-Security is the best option to secure Web Services based
distributed infrastructure. It supports partial encryption. Its transport-neutral
nature makes it ideal for instances where a Web service needs to be exposed on
multiple transports like HTTP, TCP, WMQ and MSMQ (Reliable Message Queue
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 57 of 115
Transport).
The WS-Security provides an end-to-end security context for Web services with
intermediate nodes, and ensures that these nodes can read only those parts of a
message that is meant for them, and not something that is meant for the ultimate
receiver. It is based on existing security technologies such as X509 certificates
and Kerberos. The EDD can leverage the existing security infrastructure to
secure their Web services.
The WS-Security is not a complete security solution. There are other issues such
as exchange of security tokens, key management, authorization, trust,
federation, and privacy that are not answered by WS-Security.
I1.6.1.6.3.2.3 WS-Security Toolkits
Implementation of WS-Security specifications is available in the form of toolkits
from Microsoft's Web Services Enhancements 2.0 and IBM's Web Services
ToolKit. These toolkits provide Application Program Interfaces (API) to implement
security in Web services as per WS-Security specifications. With these toolkits,
the CCR System Core Security services can attach security tokens to messages.
In addition, Core Security services can encrypt and sign messages using these
tokens.
Microsoft and IBM have together conducted successful interoperability tests
between their toolkits.
I1.6.1.6.3.2.4 Distributed Framework Security Model
Distributed Framework Security model will be based on Security Tokens
(standard and custom).
I1.6.1.6.3.2.5 Authentication for Different Clients
1.6.1.6.3.2.5.1 Internet Browser to Web Server Connection Authentication
When the user logs into the system, Web Access Proxy Server or Web
Presentation Server will authenticate the user against the LDAP or Active
Directory using Basic Authentication. The user will be prompted to enter a
username and password in a login form and optionally use multi-factor
authentication without need for any hardware/software token. The Basic
Authentication method will send the password over the Internet in clear text so
the connection must be secured using HTTPS (TLS/ SSL). Since Web Access
Proxy Server or Web Server is in the DMZ then the authentication should not be
performed against the main corporate LDAP/Active Directory, instead it should
use a secondary LDAP/Active Directory or UIMOD Identity Registry database.
Web Access Proxy Server or Web Server should not directly connect to
LDAP/Active Directory/Identity Database. Web Access Proxy Server or Web
Server should call Web Services located in trusted VLAN to perform user
authentication against LDAP/Secondary Active Directory/Identity Database.
1.6.1.6.3.2.5.2 Intranet Browser to Web Server Connection Authentication
When the user logs into the system, the IIS Web Server will use Windows
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 58 of 115
Integrated authentication to transparently authenticate the user against the Active
Directory using Kerberos. The user may be prompted to enter a username and
password in a popup login dialog box by MS Internet Explorer (IE) when his
Windows Credentials are not delegated to IIS. The Windows Integrated
Authentication method uses Kerberos token so the connection is secured.
1.6.1.6.3.2.5.3 Smart Internet Client to Web Services Façade Connection
Authentication
When the user logs into the system Smart Client will prompt user to login and
pass credentials as username token to Web Services Façade (Security Proxy
Server), which will authenticate the user against the LDAP or Active Directory
using Basic Authentication. Smart Client may optionally use multi-factor
authentication without the need for any hardware/software token. The Basic
Authentication User Name token method sends passwords over the Internet in
clear text so the connection must be secured using HTTPS (TLS/ SSL). Since
Web Services Façade (Security Proxy Server) is in the DMZ, the authentication
should not be performed against the main corporate LDAP/Active Directory;
instead it should use a secondary LDAP/Active Directory or UIMOD Identity
Registry database. The Web Services Façade Server should not directly connect
to the LDAP/Active Directory/Identity Database. The Web Services Facade
Server should call Web Services located in a trusted VLAN to perform user
authentication against LDAP/Secondary Active Directory/Identity Database.
1.6.1.6.3.2.5.4 Smart Intranet Client to Business Services Façade Connection
Authentication
When the user logs into the system, Windows PC will use Windows Integrated
authentication to transparently authenticate the user against the Active Directory
using Kerberos. Windows Credentials will be delegated to IIS. The Windows
Integrated Authentication method uses Kerberos token so the connection is
secured.
1.6.1.6.3.2.5.5 ASP.NET Web Application Authentication
If Active Directory is not being used to store the user list then the web application
will perform a custom authentication on the supplied username and password.
Once a user has been authenticated, the web application will maintain an open
session for that user. The session will expire after a certain configurable period
of inactivity. This timeout period may be different depending on whether the user
is inside or outside of the EDD network. The system may maintain the state of
currently open ―transactions‖ allowing the user to resume where they left off
when they log back in.
The web application should run on a secure (SSL) server if it will communicate
with clients outside of the trusted EDD network environment. Either SSL or
IPSec can be used to protect data transferred within the corporate network.
1.6.1.6.3.2.5.6 Web Server to Application Server Connection Authentication
The web server may run inside the trusted corporate network (behind the main
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 59 of 115
switch) or it may run in the DMZ (behind the external firewall). If the web server
is running inside the trusted corporate network, then SOAP communications
between the web server and the application server will be secured by Kerberos.
If the web server is running in the DMZ the communications with the application
server should be protected by Kerberos or by SSL or IPSec. The web server and
the application server may actually run on the same physical machine, in which
case the issue of communication between the two is of little concern since the
machine will be running in a trusted environment.
1.6.1.6.3.2.5.7 Incoming Request Adapter Authentication
The Incoming Request Adapter will be responsible for authenticating the caller
before allowing access to the system.
I1.6.1.6.3.2.6 Business Façade Authentication
The primary application-level security checks will be implemented at this level.
Each time a request is received by the Business Facade, an authorization check
should be made to determine if the user making the call has the right to execute
the specified request. If the request is authorized it will be passed along to the
appropriate Business Service(s). If not, an authorization exception will be
thrown.
Requests coming into the Business Façade should only come from trusted
sources. This means that user authentication will occur prior to the Business
Façade being called and the Façade will authenticate the calling client
application/request. When a security principal object (described later) is passed
into the Business Façade it is assumed to be valid. To achieve the necessary
level of trust, the Business Façade component will be secured so it will only be
accessible by trusted client applications or Incoming Request Adapters.
I1.6.1.6.3.2.7 Business Process Components Authentication
Business Process Components will run in the same processes as the Façade so
no additional authentication is performed at this level.
I1.6.1.6.3.2.8 Data Access Logic (Repository Components) Authentication
Data Access Logic Components may run in the same separate Enterprise
Service process, so additional authentication is performed at this level.
I1.6.1.6.3.2.9 Generic Data Access Functions Authentication
The Generic Data Access Functions will run in the same process as the Data
Access logic Component, so no additional authentication is performed at this
level.
I1.6.1.6.3.2.10 Database Access Account Authentication
All database access will be performed using a dedicated service account so
database-level security will be based on the service account and not on
individual user accounts.
Data Access Logic Component will access the database using its own special
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 60 of 115
service account. The database will be locked down and the service account will
be granted the access they require for their associated services or components
to do their work. This will allow connection pooling.
I1.6.1.6.3.3 Network/Hardware Security Configuration
I1.6.1.6.3.3.1 DMZ Security
The network will be configured with a typical DMZ at the periphery. There will be
an external firewall guarding the outside of the DMZ and an internal switch
guarding the internal network. All external Internet traffic will come through the
external firewall to one or more web-servers in the DMZ. These requests will be
processed as necessary then forwarded as Kerberos secured SOAP requests
through the internal switch to the appropriate internal server. The DMZ web
server(s) may be clustered to provide load balancing and failover support.
The internal network (behind the main switch) will contain two or more dual-
purpose Application servers. These servers will be clustered to provide load
balancing and failover support. These servers will run the Web Services. The
internal network will also contain one or more database servers. All servers will
be running Windows 2003 or later and they will all participate in Active Directory.
I1.6.1.6.3.3.2 Web Services Façade and Web Access Manager (Proxy -
Security Gateway Servers)
The Security Gateway Server is a specially configured web server running
Reverse Proxy in the DMZ. The purpose of this server is to forward incoming
Internet requests to an internal web server. The use of Security Gateway Server
has been considered in this architecture to address the following issues.
1. To perform authentication of Internet users.
2. To run Web Services/Web Application Firewall as a threat defense,
protecting the infrastructure from hackers.
I1.6.1.6.3.3.3 Secure Connectivity: Data Privacy and Integrity
All communications between the web server(s) in the DMZ and the user‘s
web browser will be encrypted using SSL. This will protect the privacy
and integrity of all sensitive information (including passwords, SSN) being
sent across the Internet.
All communications between the web server(s) in the DMZ and the
internal application servers will be protected using either Kerberos and
optionally SSL or IPSec. This will protect the privacy and integrity of all
sensitive information being sent between the semi-trusted and highly
trusted parts of the network.
All communications between the web servers and internal users will be
protected by SSL/IPSec.
Communication must be secured. Clear text password or key can be sent
only via SSL or encrypted by Kerberos ticket. Client to Service
communication must use XML encryption for confidential data based on
Kerberos tickets (AES, RC4 or 3DES).
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 61 of 115
Access via any
Internet Connection.
Firewall configured to
establish DMZ via
port forwarding. Firewall
w/ SSL Tunnel WS Facade Servers used
for validating and securely
routing requests to internal
Application Servers.
NLB cluster of
IDC
IIS Web Servers used
for Access & Presentation
CISCO SYSTEMS
Switch DMZ
IDC
VLAN 1
IDC IDC IDC
Cluster of IIS Application
and Integration Servers
VLAN 2
Redundant clustered
servers for load balancing
and failover.
CISCO SYSTEMS
Switch
Browser
Local
User
Firewall Smart Client
w/ SSL Tunnel Local User
VLAN 4
Cluster of
Database
Servers
VLAN 3
Figure 15 UI Network Security / Hardware Overview DMZ Option.
I1.6.1.6.3.4 Identity Management
The solution will provision the right users with the right access at the right time to
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 62 of 115
the right information systems and assets. The following are key characteristics of
the Identity Management sub-system:
The CCR System security will provide a UI Identity Registry which will be
used as authoritative source of identity data to provision Internet users via
self-registration. The CCR System will use specific interfaces/adapters
such as TAMe/LDAP and AD to synchronize user identities among the
CCR System Identity Registry and TAMe/LDAP and /or AD.
To facilitate identity management, the CCR System security will support
Single Sign-On and dynamic provisioning via self-service.
The CCR System security will provide a self-service facility for Internet
user identity management.
The CCR System security will provide user self-registration via the Web.
Web Access Manager (WAM), which is part of the CCR System security,
has to allow non-authenticated access to specific Web applications
running on the same Web server with Web applications, which require
authentication for access.
The WAM has to allow new users to self-register in the EDD Web
Application and for the EDD to provision users in WAM (EDD to add users
to LDAP or invoke WAM provisioning process and get feedback). This
includes facility to allow the EDD to create WAM user with specific
password generated by the EDD.
An alternative is to have WAM own the self-registration Web form, which
provisions new users in LDAP and then invokes a specific EDD Web
Application to register users in EDD Registry. In this case, WAM must
protect itself from self-registration by programs by using Challenge-
Response image display (See Yahoo) and SMS/e-mail delivery of part of
password (see Google).
The CCR System security will provide multi-factor authentication option
(without hardware/software keys/tokens).
o The WAM must have the capability to handle multiple consecutive
failed logins for the same username without locking user account. It
must switch to multi-factor authentication mode (send temporary
secondary password to SMS/e-mail, set state that that user must enter
primary credentials and temporary secondary credentials and answer
challenge/response questions to perform login).
o If WAM does not provide multi-factor authentication as described
above, then it has to have the configurable option to set special
authentication states for users and always forward this user‘s login
Web request to a special EDD Login Web Form behind the WAM
Proxy. The EDD Login will use a multi-factor authentication method
(send temporary secondary password to SMS/email and use it with
challenge/response questions to perform login). The WAM must
provide an API to allow the EDD login to notify WAM to switch back to
a normal authentication state for a specific user.
The CCR System security will provide self-service password reset.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 63 of 115
o The WAM has to have the capability to allow a user to reset his/her
password when he/she has forgotten their password. The WAM must
switch to a multi-factor authentication mode (send temporary
secondary password to SMS/email, set state that the user must enter
their temporary secondary credentials and answer challenge/response
questions to successfully perform the login).
o If WAM does not provide multi-factor authentication as described
above, then it has to have the configurable option to set special
authentication states for users and always forward this user reset
password Web request to a special EDD reset Web Form behind the
WAM Proxy. The EDD Reset will use a multi-factor authentication
method (send temporary secondary password to SMS/email and use it
with challenge/response questions to authenticate user). The WAM
must provide an API to reset the password or to allow the EDD to reset
the password in LDAP.
o Notification of the CCR System about a password reset or change. The
WAM must provide configurable event notification functions to notify
the EDD application about password change/reset in WAM/LDAP. It is
desirable to use reliable Message Queue for event notification.
o Synchronization of WAM LDAP and the CCR System Identity Registry
(Database) has to be supported.
o Cluster of load balanced ―N‖ WAM reverse HTTP Proxy servers must
support load balancing for ―X‖ protected EDD Web servers (where ―N‖
not equal ―X‖). The WAM must maintain a pool of SSL connections to
the protected EDD Web Servers.
o The WAM has to enable access to the WAM Audit Log by the CCR
System application.
o The WAM has to allow access to certain EDD Web Applications and to
Web Services without login form.
I1.6.1.6.3.5 User Authentication
When a user attempts to access the system they must supply an appropriate set
of credentials in order to be authenticated and given access. In the CCR
System, these credentials will consist of a username and password. The
authentication process will ensure that the user is identifiable and the security
administrator has granted them access to the system.
The Core Security services have to provide strong authentication (one time
passwords and/or multi-factor authentication without/with software
tokens/optional hardware tokens/fingerprint reader; challenge/response
questions/answers, one time generated passwords sent to email/mobile phone).
To facilitate Web Services authentication and integrity and improve custom token
security, every business service has to have WSDL defined and published.
Therefore, each resource (Business Service, user, etc) has to have
XRIDescriptor. The XRIDescriptor for Business Services can be Authority
Repository. The XRIDescriptor should have Service Security Profiles to define
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 64 of 115
multiple types of tokens and Identities required by that Service (Service is
processed by multiple Federated Systems). Each Service profile will specify a list
of Identity types to be authenticated and the token types used for each identity.
Each Identity may have multiple token types concurrently.
Each SOAP message may have as many Tokens attached as Identity types
specified in the profile (as many as Federated systems involved in the Service
processing).
I1.6.1.6.3.5.1 Internet User (Active Directory)
The CCR System will authenticate Internet users against an alternate Active
Directory for external users using Basic Authentication. The user will enter a
username and password into the login form and this will be sent in clear text to
the web server, thus requiring a SSL/TLS link between server and browser. If
authentication succeeds, the user will be granted the access to the web
application. As a result of a successful authentication, ASP .NET will create a
WindowsPrincipal object containing security information about the logged on
user.
I1.6.1.6.3.5.2 Intranet users (MS Windows smart clients)
MS Windows authentication:
o Identity:
─ Each user has to have a unique identity in Active Directory and
must be uniquely authenticated by MS Windows Domain Controller
to enable granular access control to Domain resources.
o Login:
─ Each user has to perform MS Windows Domain Login at MS
Windows session startup. Password is not available to smart client.
o Authentication protocol:
─ Authentication to Windows Domain Controller has to be Kerberos &
NTLM compliant.
I1.6.1.6.3.5.3 Non-Active Directory User
For situations where the user list is not being stored in Active Directory, IIS will
not be able to perform a Windows Authentication against Active Directory. In
these cases, the user will log into IIS using an anonymous login and the web
application will retrieve username and roles from the HTTP header sent by Web
Access Manager (i.e. TAMe). The web application will trust Web Access
Manager to authenticate against the user against LDAP. If authentication is
successful then the web application will create a GenericPrincipal object
(described later) containing security information about the logged on user.
Alternatively, .ASP Forms Authentication may be used.
I1.6.1.6.3.5.4 Other Internal Clients
Authentication in other internal client applications will be performed in a client-
specific manner but should adhere to the following rules.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 65 of 115
The supplied username and password or Windows identity should be
authenticated against the Active Directory.
A successful authentication should produce a WindowsPrincipal object
containing security information about the logged on user.
I1.6.1.6.3.5.5 External Clients
External (non-CCR System) application clients will access system services
through the Incoming Request Adapter. It will be the responsibility of the
Incoming Request Adapter to authenticate the calling user or application. The
Request Adapter will require a username and password or certificate, which it will
authenticate against the main Active Directory, and alternate Active Directory, or
some other user database. A successful authentication should produce a
WindowsPrincipal object containing security information about the external client.
I1.6.1.6.3.5.6 Session Timeout
When the user logs into the system, this will result in the creation of a user
session. This session will remain open as long as the user remains active. After
a certain configurable period of inactivity the session will expire after which point
the user must log in again to continue using the system. The timeout period may
be different depending on how the user is accessing the system. Internal users
will likely have a significantly longer timeout period than Internet users.
I1.6.1.6.3.5.7 Security Principal Objects
The .NET Framework contains a standard interface called IPrincipal. Classes
that implement this interface can be treated as security principal classes. A
security principal object contains information about a specific user, including the
username and the list of Roles to which the user belongs. The .NET Framework
supplied classes, WindowsPrincipal and GenericPrincipal, both implement the
IPrincipal interface. The list of roles held by the security principal object can be
used to perform role-based authorization to system functionality.
I1.6.1.6.3.6 Roles and Authorization
Authorization will use role based access control model. The following are key
requirements for the authorization sub-system:
Authorization is to be implemented via multiple Access control layers with
externalized security policies (grants and rules):
o Code Access Security (Program Signatures and Call Path Policies).
o DB Stored Business Entities Access Security.
o Web Forms/Windows Controls Access Security.
o Web Services Access Security.
o Enterprise Service Access Security.
To facilitate Web Services authorization and strongly typed parameter
validation and to improve custom token security, each WSDL has to have
matching XRIDescriptors (with Service Security Profiles) in an XRI
Authority Repository. The Service Security Profile must define the multiple
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 66 of 115
types of tokens and Identities required by that Service.
Each Service profile will specify a list of Identity types to be authenticated
and the token types used for each identity. Each Identity may have
multiple token types concurrently. Each SOAP message will have as many
Tokens attached as Identity types specified in the profile.
.NET Code Access Security has to be used for all client and server side
components (including strong name assemblies and policies).
The WS Security Token and multiple custom tokens must be passed in
every Service request. A Kerberos token is a master token and will be
used to encrypt all custom tokens.
The CCR System users need access to business entities and application
services located on distributed application servers.
The ESB has to provide Role-based authorization for Business Services
and Business Entities stored in the Repository.
Access Control to Logical Resources (Application Services/Transactions
and Business Objects) has to work for all Intranet, Internet and Extranet
users.
I1.6.1.6.3.6.1 User Information Store
If Active Directory is used as the user database, a set of Active Directory groups
will be created to represent user roles in the CCR System. Users will be added
to these groups as necessary to give them membership in their corresponding
Roles.
It will be possible to create an alternate user data store and integrate it with the
system as described in the User Authentication section and other parts of this
section.
I1.6.1.6.3.6.2 System Features
System services will be accessed through a set of public functions exposed by
the Business Façade. These functions will be grouped together into Features.
Features will be individually secured and access to each Feature will be granted
to one or more Roles as well as to individual users where appropriate. Each
function will be a part of only one Feature so it has only one set of security
characteristics. The decision to secure Features is meant to ease security
administration.
I1.6.1.6.3.6.3 Security Database
Information defining users, Roles and Features, as well as the access granted to
each user or Role will be stored in the Repository (Security Database). The
information in this database will be used by a security component running in the
Façade to perform security authorization checks on service requests.
I1.6.1.6.3.6.4 BusPrincipal Class
During the authentication process a security principal object is produced which
contains a list of Roles to which the authenticated user belongs. If Windows
authentication was used then a WindowsPrincipal object will be created. If a
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 67 of 115
custom authentication method is used then a GenericPrincipal object will be
created. This list of Roles will be used in the Business Façade to perform
authorization on each request.
A new BusPrincipal class will be defined and it will implement the IPrincipal
interface. The information in the security principal object created during
authorization will be used to construct a new BusPrincipal object with a list of
user roles that are related to the CCR System. This BusPrincipal object will then
be passed into the Business Façade for use in authorization. This approach will
ensure that the Business Façade will always receive uniform data and it will be
possible to add additional functionality to the BusPrincipal class, making it easier
for the system to use the data it holds.
I1.6.1.6.3.6.5 Security Tokens: Authorization in the Business Façade
At the beginning of each service request, the Business Façade will call the
security component to perform an authorization check on the requested service.
The BusPrincipal object will be passed into the security component where it will
be used to perform the authorization. If the user or any roles they belong to have
been granted access to the requested function then the request is authorized,
otherwise the request is denied and an authorization exception will be thrown.
I1.6.1.6.3.6.6 Security Tokens: Authorization in the Client (Secure View)
It will be common for the client application to show or hide certain user interface
options depending on the privileges of the current user. This can be
accomplished by allowing the client application to retrieve a list of features
available to each user or Role to which the user belongs. The client will call a
function in the Business Façade, which will return this information. The client will
not have direct access to the Security Database.
I1.6.1.6.3.7 Internal Process Protection
The section addresses the protection and access to internal resources and
processes.
I1.6.1.6.3.7.1 Middle-Tier
The middle-tier layers (Façade, Business Process, Data Access Logic) will run in
multiple processes with Enterprise Services providing security services for inter-
process communication and SOAP Kerberos Token providing security delegation
between servers.
Only recognized client applications or Incoming Request Adapters will be allowed
to access the Business Façade processes.
I1.6.1.6.3.7.2 Database
The primary database will be secured so it will only be accessible from trusted
internal network locations like VLAN of Application Servers.
The Data Access Logic Layer will run in the separate process under a special
service account that will be granted access to the database to perform all
necessary functions. Using a single service account will allow the system to
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 68 of 115
utilize connection pooling when accessing the database.
Additional database accounts may be set up for specific IT users or
administrative or backup applications.
I1.6.1.6.3.7.3 Secure Data Storage & Management: Confidentiality, Security
and Privacy
Application components using passwords and keys must erase memory after use
of confidential data
Smart client and servers must store session keys and passwords in protected
non-persistent memory (DPAPI).
Application components shall not have access to session key and password.
Infrastructure Security components have to perform specific Services using
confidential data (Login service, Registration, etc).
I1.6.1.6.3.7.4 Encryption of confidential data stored in the CCR System
Repository/Application Databases
The CCR System infrastructure servers have a need to store sensitive
information in a database and/or a file system. The sensitive information includes
user‘s passwords, keys, account information (SSN, etc), or other confidential
documents. To protect stored sensitive information applications use encryption
techniques.
The important architectural decision regarding claimant‘s privacy is to use the
CCR System ID for each claimant as a primary identifier for account access
instead of SSN. The SSN will be stored as confidential attribute in encrypted form
and as SSN SHA1/MD5 (a standard hashing algorithm) hash.
While encryption has become relatively easy to use, developers frequently make
mistakes while integrating it into an application.
A few areas where mistakes are commonly made include:
Insecure storage of keys, certificates, and passwords.
Improper storage of secrets in memory.
Poor source of randomness.
Poor choice of algorithm.
Failure to encrypt critical data.
Attempt to invent a new encryption algorithm.
Failure to include support for encryption keys changes (keys rotation) and
other required maintenance procedures.
The impact of these weaknesses can be devastating to the security of a
distributed infrastructure.
Encryption is used to protect most sensitive assets, which may be totally
compromised by a weakness.
To avoid common weaknesses the Gramm-Leach Bliley Act (GLBA) and Federal
Security regulations include specific requirements for the implementation of
encryption technology:
Encryption quality.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 69 of 115
The size of the key used.
Key management.
Standard encryption algorithms which satisfy these requirements are AES, 3DES
and RC4. These algorithms have sufficient quality and key size and can be used
in an EDD distributed infrastructure to encrypt confidential data in a database,
files and messages.
Key Management & Encryption strategy requires selecting the implementation
options which includes defining the following:
Architecture for secure application processing of confidential data.
Where to perform the encryption.
Where to store encryption keys.
How to rotate keys.
Who gets access to those keys and how.
The following sections address these issues.
I1.6.1.6.3.7.5 Architecture of Secure Application Processing ofConfidential
Data
To prevent an exposure of confidential information (SSN, passwords) by a
compromised application or due to a disk copy, unsecured application
components/services shall not have access to crypto keys or confidential data in
clear text format.
The application system should have only one trusted secure component, which
works with confidential information in clear text format. This secure component
should use protected memory to prevent a confidential information exposure due
to memory paging to disk.
This secure service shall not have functions, which return to calling application
components clear-text keys or clear text confidential information.
The acceptable mode of operation of such secure service is Security Proxy
mode.
In such mode it acts as a security proxy to a fixed number of trusted functions,
which use confidential information to perform some specific predefined
processing.
To protect Security Proxy from Trojan tampering attacks, where trusted functions
are substituted, all components must have strong name and user code access
security policy.
In the EDD distributed system such trusted predefined functions to process
confidential information are password processing functions.
An additional function of Security Proxy is the re-encrypting of encrypted account
data due to key rotation/expiration or algorithm change.
I1.6.1.6.3.7.6 Location of the Encryption and Keys
There are several options for the location of encryption and key which are
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 70 of 115
discussed below.
Option 1 - The encryption and key management can be done inside the
database (some Database management systems platforms include
encryption features).
Performance:
o The encryption process can add computational overhead to the
database server.
o Also, since data is encrypted and decrypted only inside the database
server, it is sent over the network in clear text. To provide end-to-end
security, a separate encryption technology would have to be used to
protect these communications.
Secure Application processing of confidential data:
o Since confidential data exists in Application Servers in clear text, un-
trusted non-secured business services/business entities can have
access to it and this would make an entire system potentially non-
secure.
Separation of Duties:
o Best security practice requires that secure systems provide for dual-
control procedures and separation of duties.
o Since keys used by DBMS-based encryption are likely to be stored in a
database, the encrypted content is not separated from the means to
decrypt it, this may result in a violation of the best security practice.
o Since Database administrators and users with access rights to the
database data can potentially get the access rights to keys used to
encrypt data, this may result in a violation of the best security practice.
Option 2 - The encryption can be done in the data protection component of
Application Server(s)/Client(s) and key management can be done in the
separate key management service.
Performance:
o Since data is encrypted and decrypted for each account only inside the
data protection component, it does not require an additional
encryption and communication with key management service. This
architecture has smallest overhead.
Secure Application processing of confidential data:
o Since confidential data is available in Application Servers for un-trusted
non-secured business services/business entities in encrypted format,
and clear text confidential data and keys exists only in data protection
components, the application processing can be made secure.
Additional efforts are required to protect Application servers, which will
have clear-text keys in data protection components.
Separation of duties:
o This architecture complies with the requirement for a separation of
duties.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 71 of 115
Of the two options mentioned above, Option 2 is the more secure, with less risk
of the encrypted data being compromised. Some of the benefits of option 2
include not exposing the keys over the network on clear text form, lower
performance overhead, and a separation of duties which lowers the risk of key
values being compromised. Because these benefits, it is recommended that the
CCR System use Option 2 as the encryption and key management solution.
I1.6.1.6.3.7.7 How to rotate keys (lazy rotation scheme)
To have strong encryption of account data stored in the CCR System database
has to use multiple encryption keys and change them periodically. The following
are key requirements for key rotation:
Each encrypted field in the database will have an additional field
containing a key ID.
Key ID has GUID type and generated by Key Management Service using
GUID class. GUID value is globally unique and does not display key
sequence number.
Key Management service saves every key with its Key ID, active use
expiration date, passive use expiration date, and encryption algorithm ID.
When a data protection component performs confidential data decryption
it uses a key ID (i.e. GUID) as a Primary search key to find the
corresponding crypto key, its expiration dates, and algorithm ID. If crypto
key passive use has expired, data protection component performs
processing, then encrypts confidential data using the currently active key,
and returns newly encrypted confidential data and a key ID to an
application with a flag indicating the key change was performed and that
the database has to be updated.
When a new account is created or confidential data is changed by a client,
data protection component uses a currently active key from Key Storage.
New active keys, expiration dates and IDs are generated by Key
Management Service at initialization time or at the request of data
protection component, when it does not have an active key.
I1.6.1.6.3.7.8 Randomizing keys values
To have good crypto keys Key Management Service has to generate keys using
random numbers. The simplest process is to use Windows Form control on Key
Management Service console, which allows the security administrator to type any
data while it measures time intervals between keystrokes with different keys. This
will generate a collection of real random numbers, which can be used together
with a time stamp, and pseudo-random sequence to generate crypto keys.
There are two acceptable algorithms for generating random keys:
The Key management service can use one random key and time stamp as
an argument to find the starting point in a pseudo-random sequence.
Another random number can be concatenated with a time stamp and
pseudo-random number and used as an input to the SHA512 hashing
function, which will generate a key. At every initialization Key management
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 72 of 115
service will attempt to use this algorithm to get random numbers from the
security administrator and generate additional crypto keys and add them
to encrypted keys storage. A form for generation of random numbers can
be integrated into the security administrator sign-in procedure for Key
Management service.
I1.6.1.6.3.8 Availability
The following are requirements for the CCR System‘s infrastructure to ensure
high availability and continued business operations:
The distributed infrastructure must support 24/7 non-stop operations.
The system must not have a single point of failure.
o Every Service must reside on a Load Balanced cluster.
o Database Server is a failover cluster.
Failure/restart/recovery/failover/shutdown of any distributed
server/service/component shall not interrupt active client‘s sessions.
o All Services have to be load balanced in clusters.
o Unavailability of a database should not impact active user sessions.
─ Business Services shall be stateless.
Web Servers session states have to be maintained out-of-process.
I1.6.1.6.3.8.1 Reliability and Error Recovery of the Enterprise Service Bus
(ESB)
In order to recover from transient failures, the ESB infrastructure will provide
automatic retry of every failed Service request (retry operations have to be
controlled by configuration stored in the Repository).
All errors must be logged to an event log and trace file.
Pacing/Throttling has to be implemented to prevent overrun of
memory/queues.
Programming for reliability. The TRY/CATCH facility must be used throughout the
CCR System. In general, extensive use will improve the reliability of the
application. Specifically, adding logic in the CATCH block that implements
debugging "levels" can aid in the run-time debugging of the production
application.
Specific recommendations include:
All exceptions must be handled as near to their occurrence as practical.
CATCH must be specified explicitly for each expected exception, as well
as unexpected exceptions.
Every CATCH must have an Instrumentation Framework TRACE sink to
record error information for debugging and Error event logging for
Operation Management (stack, exception, etc).
Every component/class must have an Instrumentation Framework TRACE
sink at the lowest practical entry/exit point to record error information for
debugging.
The level of tracing has to be controlled externally for each
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 73 of 115
server/service/application via a configuration file.
In all cases, each CATCH must gather information for logging and tracing,
and add relevant information to the exception. Additionally, in some cases
CATCH blocks must execute cleanup code and attempt to recover.
I1.6.1.6.3.9 Core Infrastructure Services
I1.6.1.6.3.9.1 Enterprise Service Bus
The CCR System and other applications will use SOAP as standard
message format for service requests.
SOAP messages can be sent via HTTP(S), TCP, WMQ, MSMQ, other
transports).
o The message transport has to be transparent to applications.
o Client applications call functions of remote objects, which are
represented by WSE custom proxy or by SOAP client using ESB to
process, send & receive SOAP messages.
The ESB components can be invoked from a WSE stack as filters and as
pluggable transport.
The ESB includes Message Transport Manager to transparently use
multiple message transports (HTTP, WMQ, TCP, etc). It will also include
custom message transport adapters (WMQ series, etc).
The ESB includes Security token objects and Custom Security Principal to
implement security context delegation and switching. This will provide for
transparent and automatic authentication and authorization of Service
requests without any changes to client or broker applications.
High Availability is supported by ESB via automatic ―Retry of Service
requests‖ (retry interval and limit are controlled by Policy for each Service.
Such Policy is stored in the CCR System repository). Retry should handle
requests timeouts and errors.
The ESB can perform transparent optional compression/decompression of
SOAP requests/responses (SOAP header, SOAP Body, SOAP DIME
attachment).
The ESB performs transparent optional encryption/decryption of SOAP
requests/responses using security tokens (Kerberos, X509, custom).
The ESB performs transparent logging and tracing of SOAP messaging.
The ESB performs transparent Host selection for services using
XRIDescriptors.
I1.6.1.6.3.9.2 Distributed Security Infrastructure Threat Protection
The solution has to recognize and respond, ―Protect & Defend‖ the security
infrastructure.
The arrival of the internet has led hackers to concentrate on the most widely
used products searching for weaknesses, and scores of flaws have surfaced in
MS Windows, Microsoft's IIS web server software and MS Internet Explorer.
Beyond IIS and IE, all software products will continue to have vulnerabilities,
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 74 of 115
weaknesses and bugs.
To protect the EDD distributed security infrastructure from hackers and
disgruntled employees, the security infrastructure has to implement application
and state integrity, system integrity, data integrity, service and message content
and protocol validation by security policies enforcers, network segmentation,
external and internal subnet perimeter protection, and anti-virus/anti-spy-ware
software.
All Security Infrastructure protection layers must be isolated from application
layers and components in such way that compromised application components
may not bypass or compromise security infrastructure protection layers or other
application layers. This will protect system from a cascading domino effect.
Web Service HTTP input content and protocol validation (XSD and
complex security/business policy rules).
Input content and protocol validation has to use XSD and
security/business policy rules for preventing buffer overflow and malicious
content from compromising applications or application states.
Web Service HTTP response validation (XSD and security/business policy
rules).
Message Queuing SOAP Request/Response message validation (XSD
and security/business policy rules).
Request/Response message content and protocol validation has to use
XSD and security/business policy rules for preventing buffer overflow and
malicious content from compromising applications or application states.
Implement network segmentation, external and internal subnet perimeters
protection, server, and network connection security enhancements
Network access to database servers has to be allowed only for Application
Servers. Network firewall will restrict network access to database servers
by IP addresses, protocols and ports and will restrict outbound requests to
authorized database servers.
Implement Protect and Defend processes:
o implement server O/S hardening,
o IIS hardening and rules based Web Application Firewall,
o files protection from contamination,
o .NET code access security.
Infrastructure has to have facility for monitoring, recognition of attacks &
contaminations and response processes.
o Middleware framework has to support ―Drain‖ and ―Shutdown‖ service
for any/all servers.
o Middleware framework has to support dynamic ―Enable‖ and ―Disable‖
services for any business service.
o Firewalls and Middleware framework have to recognize and stop
(distributed) denial of service attacks ((D)DOS).
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 75 of 115
I1.6.1.6.3.9.3 Security Event Management
The solution has to provide the ability to recognize security events to facilitate
appropriate early analysis and action:
Implement security events logging.
Implement security event aggregation/correlation mechanisms for
sessions and transactions orchestration.
I1.6.1.6.3.9.4 Audit and Forensics
The ESB, Services and Clients have to record Security and Activity Logs
(Audit Trails).
Activity auditing capability has to be from end to end (the CCR System
client to backend transaction).
Business Façade will not execute any service when Security or Activity
Audit fails to write a record.
Activity Logging Facility has to support levels of logging (error, warning,
and information) and applies to all Services or specific Services. Logging
configuration for each Service and system has to be stored in the CCR
System Repository and provided to clients as a response to the Service
request.
To allow correlation of different Logs, all log records must include Session
ID, Business Transaction ID, User Identity, Timestamp (MsgID), Session
originator‘s IP address and computer name, Service name/id, current
computer name.
Security and Activity logging has to use MS Event Log to enable
Operations Management systems (e.g. MOM, CA Unicenter) to monitor
the CCR System events, and perform archival process.
The ESB has to support batch consolidation of Activity/Security Logs from
each Server/Client to central Audit database, which performs aggregation
functions.
The CCR System has to guarantee authenticity of logs to prevent
tampering. It can be done by signing batches of log records when they are
uploaded to the central archive/aggregation database.
I1.6.1.6.4 Business Function Architecture
I1.6.1.6.4.1 Overview
Serious thought must be given to how business functionality will be broken down
and implemented. A distinction can be drawn between generic business
functions that can handle different variations of the same basic operation such as
saving a policy, and highly specific functions that would implement one specific
type and variation of operation. This issue may have a significant impact on the
size and complexity of the code as well as the ability to reuse and extend
components.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 76 of 115
I1.6.1.6.4.2 Generic Functions
One approach would be to attempt to write more generic functions that tend to
treat Business Entity objects as a complete package and operate on them as a
whole. For instance, an UpdateDiary function could be written to accept a Diary
object as an input parameter and it would then use the Diary object to update the
database. All fields in the Diary object would be used in the update, which means
all changes made to the Diary object since it was created would then be
propagated to the database. This approach would allow a single function to be
used for various types of updates to a Diary Entry thus cutting down on the
number of required functions.
Benefits:
Fewer functions are required so there is less code to write, test and
maintain.
Different layers can be more loosely coupled; several business process
functions could make use of the same update function in the data access
logic layer.
Using generic functions will probably allow for greater code reuse.
It may be easier to write more generic functions for core components
since it is not yet known what all of the requirements will be for every
implementation of the system.
Problems:
It may be more difficult to write generic functions because they will have to
handle multiple scenarios. This may result in more complex code that
could be more difficult to maintain.
Generic functions will require fully populated business entity objects
and/or the ability to distinguish ―NotSet‖ values.
Generic functions may introduce a slight negative performance impact.
I1.6.1.6.4.3 Highly Specific Functions
Another approach would be to break down all business functionality into a well-
defined set of transactions and write highly specific functions to implement each
type of transaction. These specific functions would take either Business Entities
or primitive (simple) data types as parameters. If a Business Entity is used, only
the data relevant to the specific function needs to be present in the entity. Using
this approach will probably require that specific functions are written in each layer
of the architecture (Façade, Business Process, Data Access Logic) for each
transaction to be implemented.
Benefits:
Specific functions should be easier to write because they do not have to
deal with as many possibilities.
This approach may provide a performance benefit.
Business Entity objects would only have to contain the data relevant to the
function rather than being full all the time.
Problems:
Many more functions and stored procedures would be required.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 77 of 115
The different layers of the architecture (Façade, Business Process, Data
Access Logic) would be more tightly coupled.
The potential for code reuse may be diminished somewhat.
It may be more difficult to write specific functions in the core components
since it is not yet known what all of the requirements will be for every
implementation of the system.
I1.6.1.6.4.4 Hybrid Approach
It is clear that the use of highly specific functions will be desirable in certain
circumstances. For instance, if a simple update (i.e., a status change) must be
made to a database record and no Business Entity object currently exists for that
record; then a simple, specific function which does not require a fully populated
Business Entity object would probably be the best implementation choice. There
may be other circumstances where it may be desirable to perform operations
without having to create and populate a Business Entity object in order to
improve performance.
There will also be situations, primarily data-centric functions, where the use of
generic functions and fully populated Business Entities will provide a substantial
benefit by reducing the amount of required code and enhancing reuse and
extensibility potential.
I1.6.1.6.5 Business Entities Architecture
I1.6.1.6.5.1 Overview
Business Entities are data structures used to hold data as it is transported
between layers of the system and as it is operated on by different parts of the
system. Business Entities will be complex objects that provide a significant
amount of generic functionality related to the data they hold. Applications and
business components that use the Business Entity objects will be able to take
advantage of these capabilities, thereby simplifying many aspects of the code
throughout the system. The following sections discuss basic features and
functionality, which will be implemented for all Business Entities.
All Business Entities will have a Unique ObjectID GUID property that will be used
to uniquely identify each instance of any Business Entity. The Unique ID should
be unique throughout the system, not just for a specific type of entity. The Unique
ID will help decouple the Business Entity model from the underlying data model
by reducing the dependency on the key structure used in the database. The
Unique ID can also be used as a Hash table key anywhere in the system. Entity
instances created from data in a data store will retrieve the Unique ID from the
data store. The data store will use GUID that is guaranteed to be unique
worldwide. System would generate a new GUID for each new instance of a
Business Entity.
This section discusses guidelines and infrastructure services in support of
Business Entities.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 78 of 115
I1.6.1.6.5.2 Default Data Values
When a new Business Entity object is created there must be a way to set default
values for the properties of the Business Entity. It is reasonable to expect these
defaults can be changed without modifying source code, which implies the
default values must be stored in some external data store such as a text file or a
database. Since Business Entity objects may be created almost anywhere in the
system, including in the client applications, the data store must be widely
available or the default values must be cached within each process that needs
them. Since Business Entity objects will be created with great frequency,
performance is a key issue so the in-process caching approach will be
implemented.
The default values will be stored in a repository that is accessible from the
Façade. As each AppDomain in the system starts up, a copy of the default
values will be retrieved and stored in a shared variable, which will be accessible
to all Business Entity constructors that need default values.
A constructor in the Business Entity base class will retrieve the necessary default
values from the shared variable and populate the internal fields. It should be
possible to write one generic function for this purpose by using the .NET
Reflection features. It will be possible to define multiple sets of default values for
each Business Entity class with some sort of status value used to determine
which set to use in a given situation.
Business Entity constructors will provide a parameter indicating whether or not
default values should be used during construction.
I1.6.1.6.5.3 Data Validation
The system must provide a mechanism for validating the data stored in Business
Entities. This could be done by hard-coding all of the validation rules directly into
the Business Entity classes or by allowing the Business Entity to use a set of
externally defined rules to validate its data. To provide for maximum flexibility the
system will use externally defined rules.
All simple validation rules will be defined in an external XML metadata (schemas)
stored in the Repository, which will be accessed by the Business Entity objects at
runtime, and the appropriate schemas with rules will be retrieved and processed.
Simple rules will include (required field, ranges, pick-lists, comparisons, regular
expressions, etc.) Each Business Entity type will have own schema with
appropriate validation rules. All complex multi-fields validation rules will be
defined in schema as embedded scripts. All complex MultiObject rules will be
defined outside of Business Entity schemas using Business Rules. This
approach will eliminate the necessity of large amounts of repetitive coding of
simple rules into numerous classes and it will allow system users to modify
simple validation rules in XML schemas without changing code or recompiling.
It will be possible to define multiple sets of MultiObject business validation rules
for each Business Entity class. This will allow each business unit/department to
define its own rules. A generic function will be added to the Business Unit base
class, which will provide the capability for any Business Unit object to validate
itself against the rules set retrieved from the rules data store. It should be
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 79 of 115
possible to use a generic function by making use of the .NET Reflection features.
Along with the generic validation using the dynamic (simple) rules, any custom
validation code in the Business Entity class will execute as well.
Business Entity validation will be a very frequent occurrence so access to the
rules data store must be very efficient. The security of the rules data is also a
critical factor. If the rules data were compromised important financial limits could
be set to arbitrary values and other undesirable situations could occur. With this
in mind, the decision has been made to store the rules data in a repository, which
will reside only on highly trusted parts of the network. The same in-process
caching mechanism described in the Default Values section will be employed for
the Data Validation rules as well.
This topic is discussed in greater detail in the Data Validation Architecture
Section.
I1.6.1.6.5.4 Retrieving Object State
Business Entity class(es) will implement a special interface (IToXml or derive
from iSerializable) containing a function used to retrieve an XML representation
of a Business Entity object state. This function will be used extensively by the
logging/auditing system. It may also be necessary to override the serialization
functionality provided by the .NET Framework for the Business Entity classes. If
this is necessary then it will be advisable to combine these two features into one
set of code.
I1.6.1.6.5.5 Creating and Saving Business Entities
There will be many Business Entity Objects modeling data in the system. Some
of these objects will be related in such a way as to form aggregate tree structures
with parent and child objects (i.e. person, claim, payment). These relationships
will manifest themselves as objects that maintain references to other objects or
collections of objects. The object model should be broken up into a set of clusters
of related objects. These clusters should have no strong relationships
(references) to one another. This will allow a set of related objects to be created
with some clear boundary. If there were no boundaries between object clusters
then when instantiating a set of objects it would be difficult to determine where to
stop without creating the entire interrelated structure.
The semantics involved in creating objects and object trees will be a very
important issue relating to performance and the design of the actual Business
Entity class(es). The following questions must be addressed:
Will it always be necessary to create and populate objects completely, or
will it be permissible to populate only those fields that will be used in a
given situation?
Will it be necessary to create the entire object tree when a single object in
the tree is required?
If a parent object is required, will it be necessary to create the required
object and all of its children?
If a child object is required, will it be necessary to create the parent in
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 80 of 115
order to access the child?
While it is difficult to define a comprehensive answer to this issue that will be
used universally throughout all of the CCR System, the following rules should be
used as guidelines when designing and working with Business Entity objects.
When creating a Business Entity object all fields should be populated.
There does not appear to be any significant performance benefit in
creating partially populated objects.
For the most part, Business Entity objects will be individually creatable,
independent of their parent objects or child objects. This implies that
Business Entity Objects need to be designed with independent
instantiation in mind. For example, a child object would have to contain all
necessary identifying information including the identifying fields (keys) of
its parent.
I1.6.1.6.5.5.1 Creating Business Entity Objects
Business Entity objects will be created from existing data entities, usually in the
Data Access Logic layer using data from a database, or, they will be created to
reflect brand new data entities, which have yet to be stored in a permanent data
store. Although Business Entities will exist as a set of related classes, in order to
improve performance it will be possible to create Business Entity objects
individually or in their related hierarchies.
In general, there will be three ways to create a Business Entity.
1. Object Only — Instantiate a single Business Entity object and populate it
with its primitive data elements. This method would leave any references
to other objects at their default Not Set values and it would leave any
collections of other objects empty.
2. Object with Immediate References — Instantiate a Business Entity
object and populate it with its primitive data elements. In addition, any
other Business Entities directly referenced by the instantiated object
should be created as Object Only, and all relevant references should be
set to point to these objects. This includes collections of objects as well.
3. Entire Tree — Instantiate a Business Entity object, and populate it with its
primitive data elements. In addition, any other Business Entities directly
referenced by the instantiated object should be created, as well as any
children of those objects, and so on down the tree until all objects have
been created. This method will create an entire object tree with the first
instantiated object as the root. This scenario will require special care in the
case of circular references.
I1.6.1.6.5.5.2 References to Other Objects
When a Business Entity has a relationship with another Business Entity this will
be manifested in the form of two additional fields. One field will be the Unique ID
of the related entity and the other field will be an object reference to the related
entity. To simplify the management of these two fields, a new class, the
BusinessEntityReference class will be defined to encapsulate the two. Actually, a
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 81 of 115
―Reference‖ class will have to be defined for each Business Entity Type so the
proper type can be returned when accessing the EntityReference. The following
table describes the properties of the BusinessEntityReference class.
Table 7 Properties of BusinessEntity Reference Class
Name Type Description
UniqueID String This is the UniqueID of the associated
Business Entity. This value may be present
even if the full Business Entity object is not.
Reference BusinessEntityBase This is a reference to the associated
Business Entity object.
State EntityStateEnum This represents the current state of the
Business Entity Reference. Possible values
are:
DoesNotExist — There is no related
Business Entity.
NotSet — The Business Entity has not been
set and it is unknown whether it exists.
NotPresent — The Business Entity exists
but neither the ID nor the actual object are
present in the BE Reference object.
IDOnly — The Business Entity exists but
only ID is present. The actual object
reference is not.
LiveReference — The Business Entity
exists and both the ID and the live object
reference are present.
The BusinessEntityReference classes will be immutable, which is to say that
objects created from these classes cannot be changed after they have been
created. This implies that all of the properties will be read-only and the only way
to set these values will be through the constructors. The reason for this is to
make the use of these reference objects a bit simpler and reduce the chance of
inadvertently corrupting a reference.
The following constructors will be supported:
New(ByVal enuState As EntityStateEnum)
New(ByVal enuState As EntityStateEnum, ByVal strUniqueID As String)
New(ByVal enuState As EntityStateEnum, ByVal strUniqueID As String,
busEntityReference As BusinessEntityBase)
I1.6.1.6.5.5.3 Collections of Other Objects
It is possible for a Business Entity to ―contain‖ a collection of other Business
Entity objects. For example, a Policy may have multiple coverages. In this case,
the Policy object would have a field containing a collection of Coverage objects.
Two new collection classes will be created, EntityHashtable and EntityArrayList,
which will serve as strongly typed collections of Business Entity objects. These
two classes will be derived from Hashtable and ArrayList respectively. These
classes will also implement a common interface, IEntityCollection, which will
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 82 of 115
expose common functionality required for Business Entity Collections.
The IEntityCollection interface will support the following properties:
Table 8 Properties of EntityCollection Interface
Name Type Description
EntityCount Integer The number of entities that belong in the
collection. If the collection has been
populated then this should be equal to the
Count of the collection. If the collection has
not been populated then this number
indicates how many objects would be there
if it were populated.
State EntityCollectionStateEnum This represents the current state of the
Business Entity Collection. Possible values
are:
NotSet — The collection has not been
populated and no entity count is present. It
is unknown how many, if any, entities
belong in the collection.
CountOnly — The number of entities in the
collection is present but the actual objects
are not.
FullyPopulated — The collection is fully
populated with all relevant entity objects.
I1.6.1.6.5.5.4 Acquiring Related Objects
Each Business Service will be responsible for retrieving and saving Business
Entities that it owns. For instance, suppose there is a Claim entity that belongs to
the ClaimData Business Service and this entity has a related Submission entity,
which belongs to the Submission Business Service. Now suppose the
Submission field in our Claim Entity is in the NotSet state but we need to access
the Submission object. The following steps must be followed to get the
Submission object.
1. Make a call to the ClaimData Business Service to retrieve the Submission
UniqueID related to the specified Policy.
2. Make a call to the Submission Business Service to retrieve the
Submission entity related to the specified Submission UniqueID.
This two-step process is necessary because only the ClaimData Business
Service knows how to retrieve information related to a Claim UniqueID, such as
the related Submission UniqueID, and only the Submission Business Service
knows how to retrieve a Submission entity given a UniqueID.
I1.6.1.6.5.5.5 Saving Business Entity Objects
Business Entity objects will be saved back to the database in order to persist
their data. This will be done in the Data Access Logic Layer. Since the Business
Entity Object model will be complex, and there will be ways to create Business
Entity objects individually, with sub-objects, and as the root of larger object
structures, it will also be necessary to have flexible ways to save these Business
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 83 of 115
Entities back to a data store.
In general, there will be three ways to save Business Entities back to the
database.
1. Object Only — Save the primitive data in the specified entity. Do not save
data for any referenced entities or collections of entities.
2. Object with Immediate References — Save the primitive data in the
specified entity. Also, save the primitive data for any referenced entities or
collections of entities.
3. Entire Tree — Save the primitive data in the specified entity as well as all
referenced entities. Continue saving data for referenced entities until the
entire tree has been traversed. This scenario should be rarely used. This
scenario will require special care in the case of circular references.
When saving referenced entities, if the UniqueID of a related entity is present but
the actual entity object is not then the data for the related entity will not be saved.
I1.6.1.6.5.6 Partially Populated Business Entity Objects
An important question related to Business Entities is whether or not they can
ever exist in a partially populated state. The general rule will be to always create
fully populated Business Entity objects but it seems likely there will be some
circumstances where it will be desirable or essential to create partially populated
Business Entity objects.
The use of partially populated entities has significant implications for database
updates.
A class method or stored procedure defined to accept parameters from a
Business Entity object and update a table has a fixed number of
parameters but the number of parameters that will be passed in might vary
because the object supplying the data may be partially populated.
If a partially populated object contains a Null value in the non-populated
fields then these Null values may be passed into a data access class or
stored procedure and unintentionally used to overwrite existing data in the
related column in the database.
If Business Entity objects are always fully populated these issues will not be
important.
I1.6.1.6.5.7 Supporting Partially Populated Business Entities
In general, Business Entity objects will be fully populated with data. One notable
exception to this will be the case of integrating with an external client in a
scenario where the external partner controls the message format for data
exchange and there is no assurance that all data in a Business Entity will be
included in messages sent between systems. In this case it is possible that the
system will receive an incomplete set of information from an external client and
use this information to construct partially populated Business Entity objects.
The following example describes the external client scenario.
1. A request comes into the system from the external client system.
2. The system creates a Business Entity object (fully populated) and returns
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 84 of 115
the data to the external client in the designated XML format agreed upon
by the two cooperating partners, but, this XML format will not permit the
system to include all of the fields from the Business Entity, only the ones
required by the external client system are included.
3. The external client performs some sort of operation on the data, then
makes another call into the system and passes the modified data in a new
XML message.
4. Since only a partial set of fields was originally passed out to the external
client, the same partial set of fields will be passed back into the system on
the subsequent request. The system will reconstruct the Business Entity
using the partial set of data and the system will now have to deal with a
partially populated Business Entity.
Several possible approaches can be implemented to deal with this scenario of a
partially populated Business Entity object. ―NotSet Capability‖ is described as
designing the system to gracefully handle partially populated Business Entity
objects by providing a way to indicate that certain fields are ―NotSet.‖ These
fields could be identified when the database is being updated and the appropriate
action can be taken to only update the database with fields that have been set.
This approach will require some additional effort in the data access class or
stored procedures to handle the possibility of ―NotSet‖ fields. In order for this
approach to work, the Business Entity object must, at a minimum, maintain its
optimistic concurrency identifier (timestamp) so it can be compared against the
current state of the database in an update.
I1.6.1.6.5.7.1 Caching
The full Business Entity objects should be cached prior to sending their data out
to the external client. When the external client passes the data back to the
system, the Business Entity object should be reconstructed from the cache then
updated using the data passed in from the external client. This approach would
allow the system to maintain a fully populated Business Entity object even when
the external client and its associated message format only use part of the
Business Entity data.
The problem with this approach is that it may be difficult to reliably cache and
retrieve the Business Entity data without any knowledge of how the external
client works and what kinds of navigation it might use. For example, if the
external client provides ―back button‖ functionality then it might be possible for a
user to back up a couple of steps in a process then retrieve Business Entity state
from the cache which was related to a different path through the process and
thus corrupt the state of the data. In order for this approach to work reliably,
some sort of protocol would have to be developed to deal with the process of
caching and retrieving data and discarding data from the cache when
appropriate. This would almost certainly be a non-trivial task.
I1.6.1.6.5.7.2 Re-Populating
If a series of interactions with an external client result in a partially populated
Business Entity object, the Request Adapter interfacing with the client can call
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 85 of 115
down to the database and retrieve a new fully populated copy of the Business
Entity object then update this new copy with the fields in the partially populated
object. This will result in a fully populated object very similar to the caching
option.
The problem with this approach is that if the database record was updated after
the Business Entity data was initially read and the original data was not cached
there will be no way to put a fully populated Business Entity object together with
a consistent set of data. This scenario would usually raise an optimistic
concurrency error but it might be possible in some circumstances to allow the
user to save over the existing changes in the database. Since it would not be
possible to reconstruct a consistent fully populated Business Entity object in the
scenario described here, the operation would have to fail with no option of saving
the results.
I1.6.1.6.5.7.3 Specific Functions
It would be possible to write a separate set of functions in the Façade/Business
Process/Data Access layers to handle partially populated Business Entities with
the specific sets of data expected from interaction with a known external client.
This approach may involve writing significant amounts of new code to support a
new type of external client, which is undesirable. This approach may also have a
negative impact on the potential for code reuse.
I1.6.1.6.5.7.4 Supporting NotSet, Empty/Null, Default Value
The design choice described in the Partially Populated Business Entity Objects
section (I1.6.1.6.5.6) put forth the requirement that it is possible to designate
Business Entity data elements as NotSet, thereby preventing them from
participating in processing and database updates. It appears that it will also be
advantageous to be able to designate Business Entity fields as Empty/Null.
There may also be some benefit in being able to determine if an entity field is
currently set to its Default Value although this does not appear to be a
requirement at the current time.
Two options have been considered to provide this capability to Business Entities.
Store a set of flags inside the Business Entity that indicate whether each
field is NotSet, Empty/Null, or at its Default Value.
Redefine each of the Primitive .NET data types as a new Structure or
Class, which contains internal flags to indicate whether the element is
NotSet, Empty/Null, or a Default Value. All internal data fields within the
Business Entities will then be defined using these structures.
The second option is more flexible because the new ―Primitive Data Structures‖
could be used to represent data elements inside or outside of Business Entity
objects, and would also eliminate the need for Business Entities, of which there
will be many, to maintain and manage the flags. With this in mind, the Primitive
Data Structures solution will be the design choice. The primary disadvantage of
this approach is the required change in coding style. To access the actual data
value the code would have to access the Value property of the class/structure
variable rather than accessing a simple data type.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 86 of 115
The details of the Primitive Data Structures are explained in detail in the Primitive
Data Type Classes section.
I1.6.1.6.5.8 Primitive Data Type Classes
A new class will be defined for each of the primitive data types.. These classes
will wrap the underlying primitive data types and provide additional functionality
that is needed by the system but is not provided by the basic data types. This
functionality includes the ability to indicate that a data value is NotSet, Null, or a
Default Value. These wrapper classes will be used for fields and properties for all
primitive data elements in all Business Entities.
Interfaces
o Three basic interfaces will be defined (INullable, INotSettable,
IDefaultable) allowing the wrapper classes to indicate that they support
each of these pieces of functionality. Each of these interfaces will
implement a single read-only property (IsNull, IsNotSet, IsDefault).
These interfaces will be implemented by the base class for the wrapper
classes and will not need to be overridden in the child wrapper classes.
Base Class
o An abstract base class will be defined for all of the wrapper classes.
The base class will contain and manage a set of flags that define the
state of the class. These flags will be implemented as a set of bit flags
in an enumeration value and they will support the IsNull, IsNotSet and
IsDefault properties.
I1.6.1.6.5.8.1 Creating and Using Objects
Objects of the wrapper classes can be created in one of two ways. A set of public
constructors will be defined in each wrapper class allowing applications to
instantiate instances of the wrapper class by passing in a value of the
appropriate underlying data type, and optionally a parameter indicating that the
IsDefault flag should be turned on, indicating the object is populated with its
default value. The following constructors will be defined.
.NET Data Type — Pass in a value of the underlying .NET data type to
populate the object.
.NET Data Type as Default — Pass in a value of the underlying .NET data
type as well as a Default flag to populate the object and set to the
IsDefault state.
DBNull.Value — Pass is the DBNull.Value object defined in
System.Data.SqlTypes to indicate a Null value for the object and set it to
the IsNull state.
DBNull.Value as Default — Pass is the DBNull.Value object defined in
System.Data.as well as a Default flag to create an object set to the IsNull
and IsDefault state.
Database Data Type — Pass in a value in the DB data type from
System.Data.SqlTypes that corresponds to the underlying .NET data type.
This value will be used to populate the object if it contains a real value, or
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 87 of 115
to set the object to the IsNull state if the SQL value is Null.
Database Data Type as Default — Pass in a value in the SQL data type
from System.Data.SqlTypes that corresponds to the underlying .NET data
type and a Default flag. This value will be used to populate the object if it
contains a real value, or to set the object to the IsNull state if the SQL
value is Null, and the object will also be set to the IsDefault state.
It is possible that other constructors could be defined to handle Oracle-
specific data types in the future.
To create an object without passing in a value in the IsNull state or the
IsNotSet state, two shared properties will be exposed by the class. These
properties (NullObject, NotSet Object) will return a new instance of the
class in either the IsNull state or the IsNotSet state.
All of the objects created from the wrapper classes will be immutable. Once they
are created either through a constructor or a shared property, they cannot be
changed in any way. To make a change to a wrapper object, a new one must be
created with the desired settings and used to replace the old one. Immutability is
required for these objects to prevent an object reference held outside of the
Business Entity from changing a data element held by the Business Entity.
The internal value of a wrapper object will be exposed via two separate read-only
properties.
Value — This will be a strongly typed property that will return the
underlying value in the native .NET data type (Integer, Long, String, etc.)
This will be the most efficient way to retrieve the underlying data value.
This property will throw an exception if accessed when the object is in the
IsNull or IsNotSet state.
DbValue — This will be a weakly typed property that will return a value as
type Object. If the object is in the IsNull state this property will return
DBNull.Value. If the object is in the IsNotSet state this property will throw
an exception. Otherwise, this property will return the underlying data
value.
By using a combination of the constructor overloads and the DbValue property,
application code will be able to transfer data between a Business Entity and the
database without regard to the Null state of the data. The wrapper class will
handle the Nulls internally and eliminate the need to check for Null in the calling
code before getting or setting the values.
I1.6.1.6.5.8.2 Business Entity Responsibilities
All data elements within Business Entities will use the wrapper classes described
in this section. As such, the Business Entity will be responsible for maintaining
the integrity of all of its internal data elements by controlling access to them using
property procedures. The Business Entity must maintain a valid object reference
for each of its internal data elements at all times. None of the data element‘s
object references should be Null (Nothing). This should not be confused with a
data element object having an IsNull state internally. Rather than having a Null
(Nothing) reference, the Business Entity should instead maintain a data element
object in the IsNotSet state. This will ensure that a valid object reference is
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 88 of 115
always returned to a caller through a Business Entity property Get procedure. To
accomplish this all Business Entities must follow two rules.
1. The Business Entity must initialize all of its internal data elements to data
element objects in the IsNotSet state at construction time. These objects
may then be set to default values depending on the constructor that was
called.
2. All property Set procedures that relate to internal data elements must
check the input parameter to make sure it is not a Null (Nothing)
reference. If a caller attempts to set a data element property to a Null
(Nothing) reference the Business Entity should throw an exception.
I1.6.1.6.5.9 Database Update for Partially Populated Business Entity
Performing database updates using partially populated Business Entity objects
presents a special challenge when using generic database update functions
and/or stored procedures. Care must be taken so that NotSet fields in the
Business Entity are not used to overwrite data in the database with Null values.
This is the main reason the system needs the ability to indicate that a Business
Entity field is NotSet so the field can be treated properly and not used to update
existing data. The mechanism for implementing and identifying NotSet values is
described in the Primitive Data Type Classes section (I1.6.1.6.5.8). The question
then arises, how to perform the update when the combination of Set vs. NotSet
fields may vary. The solution to this problem is described below.
1. In the Data Access Logic Layer the data from one or more Business Entity
objects may be used to call one or more stored procedures. The code
here will create an array of stored procedure parameter objects as usual,
but instead of setting the parameter Value property to the actual data
value, the Value property will be set using the primitive data type wrapper
object, which includes the Null, Default, and NotSet flags.
2. The array of parameters will then be passed into a generic function, which
will examine each parameter and determine if any of the values are
NotSet. As each parameter is examined, the Value property of the
Parameter object will be updated to hold the actual primitive data value
rather than the wrapper object. If a parameter is NotSet, a new Flag
parameter, related to the primary parameter, will be created and set to
False, and added to the parameter array. This flag parameter will indicate
to the stored procedure that the primary parameter should not be used in
the update.
3. The array of parameters will be passed back to the Data Access Logic
layer, which will then call the stored procedure as usual.
4. The stored procedure will then process the parameters and perform the
update. If the stored procedure supports conditional updates using NotSet
parameters then it will use the Flag parameters to determine which
primary parameters should participate in the update. If the stored
procedure does not support the conditional updates then the Flag
parameters will not be recognized and the procedure will fail and return an
error.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 89 of 115
The approach described here will allow the system to be built assuming all
Business Entities will be fully populated, thus requiring minimal extra code and
overhead. Only the generic function to process the parameter objects must be
added at the beginning. Then, when and if the need arises, the system can be
upgraded to support conditional updating and partially populated Business Entity
objects where necessary. Only the stored procedure needs to be modified to
support the conditional updating. The code in the Data Access Logic layer will not
have to change.
I1.6.1.6.5.10 Supporting Optimistic Concurrency
To support concurrent access to the database the system must be able to
determine whether a record being updated has changed since it was first read.
This can be accomplished by adding a timestamp column to each table in the
database and a corresponding timestamp field to each Business Entity. The
timestamp values could then be used to determine if a record has been changed
since it was first read.
I1.6.1.6.6 Data Validation
I1.6.1.6.6.1 Overview
Data validation as it relates to the CCR System .NET/Business Entity
architecture can be broken down into three types. Any update to the database,
which does not use the Business Process Layer/Business Entity paradigm will be
addressed separately.
Simple — Simple data validation describes simple rules, see examples
listed below, which can be implemented in a generic way within the
Business Entity base class. Simple validation will apply a rule to a specific
data property within the Business Entity or a simple comparison against
another field in the same entity.
o Required Field
o Range
o Max Length
o Regular expression
o List
o other
Complex — A non-simple validation rule applied to one or more data
properties of a Business Entity object.
MultiObject — MultiObject data validation describes any type of data
validation rule applied to one or more data properties in a Business Entity
object, which required additional data from outside the Business Entity
object in order to be evaluated and applied. This type of rule would be
implemented outside of the Business Entity class in the Business Process
Layer. MultiObject validation may include data constraints such as a
foreign key constraint typically found in a database. A MultiObject
validation could also be described as a business rule.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 90 of 115
A discussion of how and where data validation will be implemented in the CCR
System architecture begins with the requirement that all data must be fully
validated before it makes its way into the database. The data validation strategy
must ensure this requirement is met.
I1.6.1.6.6.2 General Validation Guidelines
The following Figure indicates the system layers where each type of validation
will occur.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 91 of 115
Internet/Extranet Internet/Extranet
External Client
WS Client Browser
Validation:
Validation: Validation:
Unknown
Unknown Simple
Web Services Facade Web Presentation
Incoming Request Adapter Intranet Smart Client
(Gateway) Server
Validation: Validation:
Validation: Validation:
Simple, Complex Simple, Complex
Simple, Complex Simple, Complex
Business Facade
Validation:
None
Business Process
Validation:
Simple, Complex, MultiObject
Data Access Logic
Validation:
Simple, Complex
Database
Validation:
Implementation Specific
Figure 16 Validation Schematics
Each public method in the Business Process Layer and the Data Access Logic
Layer will check the validation flag on every Business Entity passed in as a
parameter. If the flag indicates that the object has not yet been validated then the
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 92 of 115
validation process will be executed for the object. If the object has already been
validated then the validation process will not be executed. When the data in a
Business Entity is changed, the validation flag will be unset, thus indicating that
the object must be revalidated. This will ensure that all Business Entity objects
are valid as they enter each layer of the system prior to being used without
having to revalidate unnecessarily.
I1.6.1.6.6.3 Other Types of Validation
The data validation mechanism described in this section is based on the process
flow through the layers of the system including Client, Façade, Business Process
and Data Access Logic, as well as the premise that all data will reside in
Business Entity objects. If the system provides additional paths to update the
database then additional methods of data validation may be required. For
instance, if a ETL Package is used to import a data feed directly into the
database, then the data must be validated in the ETL Package or in the database
script or stored procedures used to insert the data.
I1.6.1.6.6.4 Data Validation Interface (IValidate)
Classes implementing this IValidate Interface will be capable of applying both
Simple and Complex types of validation to their internal state. MultiObject type
validation must be implemented outside of the data object; therefore, it is not
handled by this interface. Properties, methods and error handling of the IValidate
Class are shown in tables 9 and 10, respectively.
Table 9 Properties of IValidate Interface
Name Type Description
SimpleValidation Boolean This flag indicates whether the simple
Completed validation rules have been run on the object
since the object was last updated. Each time
the object state is changed this flag should be
reset to False. Each time the simple validation
rules are run this flag should be set to True.
ComplexValidation Boolean This flag indicates whether the complex
Completed validation rules have been run on the object
since the object was last updated. Each time
the object state is changed this flag should be
reset to False. Each time the complex
validation rules are run this flag should be set
to True.
FullValidation Boolean This flag indicates whether the simple and
Completed complex validation rules have been run on the
object since the object was last updated. This
flag should be True if both ValidatedSimple
and ValidatedComplex are True.
EntityTreeHasErrors Boolean This flag indicates whether the object or its
sub-tree has any validation errors.
ValidationErrors ValidationErrorList A strongly typed collection of ValidationError
objects.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 93 of 115
Name Type Description
UniqueID String A string, which uniquely identifies an instance
of a type implementing IValidate within the
entire problem space. This value will be used
to associate ValidationError objects with the
objects that generated the errors.
Note: Should the UniqueID property in this
interface have a different name from the one
implemented in the BusinessEntity base class?
Table 10 Methods of IValidate
Name Type Description
ValidateEntitySimple Boolean Execute all of the simple (generic) validation
rules on the object but not on any sub-objects.
ValidateEntityComplex Boolean Execute all of the complex (custom) validation
rules on the object but not on any sub-objects.
ValidateEntityComplete Boolean Execute all of the simple and complex
validation rules on the object but not on any
sub-objects.
ValidateEntityTreeSimple Boolean Execute all of the simple (generic) validation
rules on the object, its sub-objects, and all
descendent objects.
ValidateEntityTree Boolean Execute all of the complex (custom) validation
Complex rules on the object, its sub-objects, and all
descendent objects.
ValidateEntityTree Boolean Execute all of the simple and complex
Complete validation rules on the object, its sub-objects,
and all descendent objects.
ResetValidationState None Clear the error list of the object, its sub-
objects, and all descendent objects. Also
resets the validation flags.
Note: This could be a problem if a client clears
the error list of a sub-object directly because
the flags will not be updated properly in the
parent object.
I1.6.1.6.6.5 Validation Error Handling
Because of the complexity of error handling, The CCR System will leverage a
separate class, ValidationErrorList, for handling of errors associated with
validation of data. The calls are defined below together with its properties (Table
10) and methods (Table 11).
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 94 of 115
ValidationErrorList
Class ValidationErrorList
Inherits System.Object
Implements IEnumerable
Table 11 Properties for ValidationErrorList
Name Type Description
Count Integer The number of items in the collection.
Returns the ValidationError object at the
Item ValidationError
specified Index.
Table 12 Methods for ValidationErrorList
Name Type Description
Gets an enumerator of all ValidationErrors in
GetEnumerator
the list.
The ValidationError Class has the following type definition:
Structure ValidationError
Inherits System.ValueType
The properties are described in Table 13.
Table 13 Properties for ValidationError
Name Type Description
The full type name of the entity that
EntityType String
generated the validation error.
The unique ID of the entity instance that
EntityUniqueID String
generated the validation error.
The name of the offending data field that
FieldName String failed a validation rule and thus generated
the error.
ErrorType ValidationErrorTypeEnum The type of validation rule that was violated.
A text message describing the error meant
SystemMessage String
for system administrators and/or developers.
A text message describing the error meant
UserMessage String
for end users.
I1.6.1.6.6.6 Data Validation Implementation
This section summarizes the implementation of the data validation system. Refer
to the detailed design documents for this sub-system for more details.
The Business Entity base class will implement the IValidate interface. Its
implementation will rely on two additional methods to provide the actual simple
and complex validations.
Validation rules will be configurable. An administration tool will allow rules to be
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 95 of 115
configured and stored in a repository. A utility function in the Façade will allow
the business entity implementation to retrieve the validation rules. Validation
rules will only need to be read once from the repository for each instance of the
Façade process at the time the process is started. The validation rules will be
maintained in a set of classes that will be marshaled once into any .NET
AppDomain that requires them via the Business Entity implementation.
I1.6.1.6.6.6.1 BusinessEntityBase Validation
Class BusinessEntityBase
Implements IToXml, IConfig, IValidate
Table 14 Methods for BusinessEntityBase
Name Type Description
This function will obtain the validation rules from the
ValidationHelper class. It will invoke the Validate
method on each simple rule associated with the
business entity. It will invoke the overridable
ValidateComplex method for the derived business
Private ValidateEntity entity class. It will also set the appropriate properties in
the IValidate interface as well as add errors to the
ValidationErrors property. If performing a tree
validation, only entities, which implement the IValidate,
will have their appropriate validation method invoke
when validating the entities members.
Any business entity may override this method to
provide appropriate complex validation for the business
Protected Overridable entity. It is up to the implementer to invoke the base
ValidationError
ValidateComplex class‘ ValidateComplex method, if appropriate. The
default implementation in the base class will return
Nothing.
A rule-repository database will be created to house simple validation rules
associated with a business entity. This database will reside with other
configuration information associated with application configuration.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 96 of 115
The following classes (Table 15) will be created to manage and implement
simple validation rules.
Table 15 Validation Rules Classes
Class Description
ValidationHelper This class will use the Façade utility function to retrieve the
validation instances if they are not local to the AppDomain. It will
support the Façade by retrieving the entire configuration from the
rule repository and instantiating the appropriate validation classes at
AppDomain startup.
EntityValidator This class will hold a collection of rules associated with a given
(Serializable) named business entity class. It will implement one method, Validate,
which will invoke the Validate method of each validation rule
instance in its rule collection.
ValidationConfiguration This class will hold all EntityValidator instances in a collection
(Serializable) indexed by business entity name.
MemberValidatorBase This is a MustInherit class from which all simple validation rule
(Serializable) classes must inherit. All inheritors must implement the Validate
method to invoke their validation on a business entity object.
MemberRequiredValidator This class will implement a required validation. It will determine
(Serializable) whether or not a member of an object instance is different from its
―unvalued‖ value. The member must be of a type that implements
IComparable.
MemberCompareValidator This class will implement compare validation. A member of an
(Serializable) object instance will be compared with either a value or another
member of the same object instance depending on how the rule is
defined. The member must be of a type that implements
IComparable. The following operations will be supported – equal,
not equal, greater than, less than, less than or equal, greater than or
equal.
MemberRangeValidator This class will implement range validation. A member of an object
(Serializable) instance will be compare with a minimum and maximum value
(inclusive). The member‘s type must implement IComparable.
MemberRegExprValidator This class will implement regular expression validations against a
(Serializable) member of an object instance. If the member is not a string, the
ToString method will be called to convert the member to a string for
regular expression validation.
MemberDomainValidator This class will implement domain validation against a member of an
(Serializable) object. The member will be compared to a list of values, which
comprise the domain. If the member is not equal to one of the
values in the list, the validation will fail. The member‘s type must
implement IComparable.
MemberLengthValidator This class will implement length validations against a member of an
(Serializable) object instance. This length validation will only be executed against
members of type String.
A utility service will be implemented in the Façade, which will be responsible to
force the retrieval of the validation rules via the ValidationHelper class when its
AppDomain is started. It will do this using a Shared constructor.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 97 of 115
A Business Entity performing validation will retrieve its validation rules via the
ValidationHelper class. The ValidationHelper class will store the rules in a
Shared member of type ValidationConfiguration. If the rules haven‘t been loaded
in that AppDomain, the ValidationHelper will call the Façade to retrieve the rules
one time. These rules will be marshaled once from the middle tier into the
AppDomain where they are needed and stored in the Shared
ValidationConfiguration member of the ValidationHelper.
I1.6.1.6.6.6.2 Validation in the Facade
BaseValidationFacadeSelect
Class BaseValidationFacadeSelect
Inherits BusinessFacadeBase
Table 16 Methods for BaseValidationFacadeSelect
Name Type Description
GetValidationRules ValidationConfiguration This method will return a ValidationConfiguration
object instance, which contains all of the
validation rules. The rules will be retrieved from
the ValidationHelper class, which will house a
copy of the rules in a Shared property.
I1.6.1.6.7 Software Extensibility Architecture
As noted earlier, there are many facets to providing a software architecture that
facilitates reusability and adaptability. Some of those facets revolve around the
software development process and some revolve around the technical aspects of
the architecture. This section will focus on the technical aspects of the CCR
System architecture that will facilitate software maintainability and reuse through
extensibility. This reuse will be accomplished by providing a mechanism to
extend and adapt developed software components to meet varying needs of
individual business units and allow for the enhancement and adaptation of
software components to meet changing needs within a single business unit.
I1.6.1.6.7.1 Extensibility Architecture
The CCR System architecture will employ multiple OOP and SOA patterns for
developing software components that will be integrated to provide software
extensibility. Each pattern will be used in specific situations and for specific types
of software components.
I1.6.1.6.7.2 OOP Patterns
Inheritance
o Straight Inheritance:
This pattern employs the traditional usage of class inheritance. If a class
needs to have extended or altered data and functionality, the new class is
derived from a base class providing the base functionality; the changes
are then added to the new derived class. Thus, if a business unit has
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 98 of 115
additional functional or data needs that exceed the capabilities of a core
implementation, they extend a class and modify as needed to create the
desired functionality.
This pattern provides a simple and familiar mechanism to create extended
classes. It is simple and will work well for those situations where the
extended classes are instantiated outside the core CCR System .NET
code and passed between core functions as parameters but does not
work well in situations when the extended classes would need to be
created within core code that is intended to be reusable.
o Shell Inheritance:
The ―Shell Inheritance‖ pattern defines that all core classes (or any other
class that may eventually need to be extended or adapted) actually be
represented by a base class, with all the implementation details, and then
an empty shell class that is derived from the base class and is the
exposed class that is utilized by all other code. The base class will contain
the core functionality and will not be able to be directly instantiated. Any
business unit functional extensions then will be implemented in the shell
class and when the shell class is deployed by the business unit (no longer
empty), the new functionality will automatically be utilized by any existing
code.
Object Composition
o Aggregation: Enabling the outer object to expose another object's
implementation of an interface without modification.
o Containment: Enabling the outer object to modify the behavior of the
inner object. Containment is used when the outer object needs to
modify the behavior of the inner object. To accomplish this, the outer
object creates an instance of the inner object in its constructor, and
delegates calls to the inner object as necessary. The outer object can
choose which calls to delegate and which calls to handle directly. The
runtime has no special requirements for objects to support containment
Encapsulation – standard for all objects
Polymorphism
Polymorphism allows different kinds of objects that are all able to process a
common set of messages to be used interchangeably, and to process those
messages in their own ways.
I1.6.1.6.7.3 SOA Patterns
Plug-ins/Filters
o Plug-ins and Filters are dynamically loaded assemblies with classes to
handle events and perform transformation of messages to Business
Services
XML Meta-data engines
o Meta-data engine classes interpret XML schemas, maps, templates
and perform objects construction, data validation,
mapping/transformation, object nodes updates, tables/GRIDs
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 99 of 115
construction/mapping, objects serialization/de-serialization.
XSL/Scripts engines for XML Transforms
o XSL Transformer engine and Script host engine to perform XML
objects transformation, validation, presentation formatting
XML Business Rules engines
o XML Business Rules engine to construct Business Services with
Business Logic, MultiObject validation, User Interface Process
management, Dynamic Sequencing of Business Process
XML configurations
o Each component processing can be configurable via Web.Config
Generic Hosts and dynamic components via Reflection
o All application processes can be very generic and all components to be
dynamically loaded as managed assemblies
Class attributes as aspect programming pattern
I1.6.1.6.7.4 Architecture
The software extensibility architecture for the CCR System will utilize a
combination of different patterns for dealing with business entities, custom GUI
controls, and business services. The reason for utilizing different patterns is that
business entities, GUI custom controls and business services have different
requirements and we have chosen the best pattern for handling extensibility for
each of the these categories of software objects. The utilization of patterns will be
described below.
I1.6.1.6.7.5 Business Entity Extension Architecture
Business entity objects will be implemented and extended using the Aggregation,
―Straight Inheritance‖, & Polymorphism OOP patterns. Business entity objects will
use XML metadata (schema, templates, maps) & XSL transform SOA patterns,
These patterns provides for the core system defining the core business entities
and that when business units need to extend the definition of a business entity,
they will create a new class that derives directly (or indirectly) from the core
business entity.
Because of the way that business entities will be utilized within the architecture,
we will be able to reap the benefits of the simplicity of this approach and
minimize the drawbacks. Most of the drawbacks of the ―Straight inheritance‖
approach are introduced when we attempt to have core, unmodified code
instantiate classes of objects that may be extended by business unit
enhancements. Since the core code is unmodified, it will not be aware of the
extended classes and thus would not instantiate those extended classes. This
issue is minimized within this architecture because business entity objects will
primarily be created in the user interface and data access layers and if the
business unit has the need to extend business entities, they will also need to
modify the user interface and data access layers to handle the new business
entity. At that point, they will be able to instantiate the new extended business
entity classes. Most of the façade layer and business services layer software will
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 100 of 115
then be able to receive the extended business entity classes as function
parameters, treating them as the base class until they are eventually passed to a
business unit extended function that is aware of the extended business entity and
can process it appropriately.
Here are a few keys to this implementation:
The vast majority of the instantiation of business entities will be done in
the code that the user interface and data access layers will already have
extended to meet differing business needs and thus will be able to
instantiate the correct extended classes.
The façade and business service layers of the architecture will have little
or no need to directly instantiate business entities. They will primarily
process business entities that were passed to them.
All business entities will have to implement the interface INewInstance to
create a default business entity of the same type as the business entity
implementing the interface. This method will be used by the façade and
business service layer software in those rare situations when a new
extended object is needed and it has to be the same class type as a
known object. It is expected that this will be the primary way that the
façade and business services layers will instantiate business entities if
needed.
Core façade and business service layer classes and function will declare
business entity parameters to be the base business entity class type but
will accept extended classes derived from those base classes.
I1.6.1.6.7.6 Custom UI Controls Extension Architecture
Custom UI control objects will be implemented and extended using the
Aggregation, ―Straight Inheritance‖, & Polymorphism OOP patterns. Custom UI
control objects will use XML metadata (schema, templates, maps), XSL
transform, Business Rules for UI process management SOA patterns.
I1.6.1.6.7.7 Business Services Extension Architecture
Business services classes will utilize the Aggregation, ―Shell Inheritance‖ &
polymorphism OOP patterns. Business services classes will use Plug-ins/Filters,
XML metadata (schema, templates, maps), Business Rules for business process
management, XML configurations, Generic hosts with dynamic components &
class attributes SOA patterns. The core base class will initially contain all of the
functionality and will not be able to be directly instantiated. This implies that for
every core base class, there will also be an associated ―shell‖ class. The shell
class will inherit from the core base class and initially have no implementation.
This ―shell‖ class provides two functions:
1. It will be the class where all business unit extensions and modifications
will be placed.
2. It allows the core base classes to be written to reference the shell classes
but utilize all of the core functionality. This allows core classes to
reference shell classes and automatically incorporate the extended
behavior as it is implemented in those shell classes.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 101 of 115
The features of this implementation include:
Core classes will be created in pairs – one base class that cannot be
directly instantiated and then an empty inherited shell class. The shell
class will inherit all of its behavior from the base class.
All public functions in the base class should include the Overridable
keyword in the function declaration. Business unit extensions will be
accomplished by overriding the base class functions or adding additional
functions to the shell class.
All core base classes need to include the MustInherit keyword in the
declaration to prevent the direct instantiation of the class. This will
minimize usage errors and ensure that the shell classes are always
instantiated instead of the core base class.
If a base class function must directly create a business entity class (not
using the CreateInstance method), the implementer of the base class
function should include the MustOverride keyword on the function
declaration and also override that function in the associated shell class.
The implementation in the shell class will just call the base class function
and will include documentation indicating that the base class function
contains direct instantiation of business entity classes that could be
impacted by business entity extensions. This will be the convention that
will let a Business Unit implementer know that they must scrutinize the
base class code to determine if any business entity extensions will affect
the function implementation.
Base class functions will declare business entity object parameters as the
base business entity class type, but the actual objects passed may be
extended business entity classes derived from that class. This will allow
the base classes to compile correctly and ultimately handle the base
business entity and all derived classes. It should be noted that although it
will accept objects of all derived classes of the base business entity class,
the core functionality will not directly process any of the data or functions
that may be present in the extended business entity classes. If any
extended processing is required, the shell classes will need to implement
those extensions.
All derived classes should check the class type of any parameter objects
passed to determine if they are of the correct type that they expect. Since
the function signatures will be defined by the base implementation, they
will be declared as a base class type but indeed could reference a derived
class. It will be responsibility of the derived class implementer to ensure
they have the correct class type before processing it. If an incorrect class
was passed, an exception should be thrown.
I1.6.1.6.7.8 Extensibility Summary
The CCR System extensibility architecture provides the ability to extend and alter
software to meet changing needs while limiting the complexity of the architecture
that provides those benefits yet remain relatively simple.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 102 of 115
I1.6.1.6.8 Data Connection Pooling
I1.6.1.6.8.1 Connection Pooling in .NET
Database connection pooling is a critical issue when building highly scalable
systems. In .NET, connection pooling is managed automatically by the .NET
Data Provider. The following data providers ship in the .NET Framework v1.1.
SQL Server
OLEDB
ODBC
Each of these data providers will automatically pool database connections with
matching connection strings. If two connections are opened with different
connection strings, they will go into separate pools. All of these providers allow
the application to control the minimum and maximum pool size.
The SQL Server, OLEDB, and ODBC providers all have a
ConnectionTimeout property. The ConnectionTimeout property specifies
the number of seconds to wait for a connection to be opened before
returning an error. If a connection request comes in, no available
connections are in the pool, and the pool is already at its maximum size,
the request is queued by the pool manager. The queued requests will be
serviced as connections become available. If a request is not serviced
within its timeout period then the Connection object will return an error.
The control over the connection pooling and the ConnectionTimeout
property offered by these data providers should enable effective
management of throughput and load spikes in the system. It will not be
necessary to implement any additional retry mechanism in the Generic
Data Access Functions layer or any other layers of the system. The
system must be able to handle a ConnectionTimeout failure and react
appropriately.
I1.6.1.6.8.2 Implementation Issues
For each connection string that will be used by the system to access a
database, a MaxPoolSize value, a MinPoolSize value, and a
ConnectionTimeout value will be stored in the configuration settings.
These values will be used each time a connection object is created.
Connections strings may be logically different even if the same exact
string is used. If Windows Authentication is being used to access the
database and two calling processes are running under different Windows
Identities then their connection strings will be logically different and will be
managed in separate pools.
The MaxPoolSize, MinPoolSize, and ConnectionTimeout values will be
part of the connection string (if applicable for the data provider in question)
and will either be passed into the generic data access functions or used to
open connections, which are passed into generic data access functions.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 103 of 115
I1.6.1.6.9 State Management
I1.6.1.6.9.1 Standard Interface
A standard interface will be defined and used throughout the system to access
session state information. This interface will provide a uniform way to save and
retrieve any type of data related to a user session. The interface will closely
resemble the public interface of the HttpSessionState class used in ASP.NET.
Various implementations of this interface may appear in the system, including the
standard ASP.NET session state management system, a potential
implementation for Windows Forms clients, and a potential implementation to
maintain session state in middle-tier components if this becomes necessary.
I1.6.1.6.9.2 Global State
The question arises whether it will be necessary to maintain global state across
the entire application. This leads to additional questions such as whether this
global state should span multiple processes or servers. Any global state
mechanism will require some sort of locking mechanism to control access to
values from multiple threads. One possibility for this might be the solution offered
by the ASP.NET Application State mechanism which provides a Lock and Unlock
methods which should wrap any update to global state values.
The architecture team does not currently anticipate a need to maintain global
state information so the State Management Interface will not address this issue
at the current time. The issue will be addressed in the future if the need arises.
I1.6.1.6.9.3 ASP.NET Implementation
The interface proposed in this section will be very similar to the public interface of
the HttpSessionState class used to access and manage session state in
ASP.NET applications. This will make it very easy to incorporate this interface
into Web applications developed on top of the .NET framework.
To use this interface in a Web application a new class will be defined
which implements the interface. This class will act as a pass-through
wrapper to the underlying ASP.NET session state object. A base class will
also be defined from which all ASP.NET pages will be derived and this
base class will provide an instance of the session state wrapper class.
This will allow code in any page to access session state through the
standard interface implemented by the wrapper class in exactly the same
way one would access session state through the built-in Page.Session
object.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 104 of 115
I1.6.1.6.10 Data Access Management
I1.6.1.6.10.1 Overview
A core component of the CCR System .NET infrastructure framework will be a
set of generic data access functions to perform common operations such as
executing a command or stored procedure. This component will consist of two
parts, a generic, DBMS-independent interface that will be exposed to the Data
Access Logic Layer, and an implementation of the basic functions for each .NET
data provider that will be used by the system.
I1.6.1.6.10.2 Data Access Application Blocks
Microsoft has provided a robust implementation of a set of generic data access
functions collectively known as the Microsoft Data Access Application Blocks.
This implementation is known as the Microsoft Data Access Application Block.
The Data Access Application Blocks provide a thin data access layer, which
hides many of the lower level ADO.NET details required for database access.
They expose a set of public methods which allow applications to execute queries
and stored procedures against the database, returning a Dataset, DataReader,
XmlReader, a simple scalar value, or nothing at all. Each of these methods has
multiple overloads to allow for a significant amount of flexibility, including how the
connection is opened and managed, how query parameters are handled, and
whether the query participates in a database transaction.
Each of these data access application blocks targets a specific .NET data
provider. For this reason, in order to write database neutral code a standard,
provider-neutral interface must be defined.
I1.6.1.6.10.3 Standard Data Access interface
A standard data access interface will be defined to expose the functionality of the
UI Data Access Application Blocks. This interface will mimic the public interface
of the Microsoft Data Access Application Block for SQL Server but all provider-
specific types such as SqlConnection and SqlCommand will be replaced with the
corresponding ADO.NET generic interfaces such as IDbConnection and
IDbCommand. This generic interface will be implemented by each of the CCR
System Data Access Application Blocks.
Interface: IDataAccess.
I1.6.1.6.10.3.1 Methods
The interface will expose several overrides of each of the following data access
methods:
ExecuteNonQuery — Executes a command that does not return rows.
ExecuteDataset — Executes a command that returns rows as a DataSet.
ExecuteDataReader — Executes a command that returns rows as a
DataReader.
ExecuteScalar — Executes a command that returns a single value as an object.
ExecuteXmlReader — Executes a command that returns XML in an XmlReader.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 105 of 115
I1.6.1.6.10.3.2 Data Access Method Overrides
With few exceptions each of the methods are defined with nine overrides taking
various combinations of parameters. This model provides a simple way for
application code to invoke database functions using a connection string, a live
connection, or a transaction object.
I1.6.1.6.10.4 Implementation of the Data Access Functions
To create Data Access Logic Components that are database neutral, the
database access must be performed using the standard data access interface
IDataAccess. This interface is database/provider neutral, and will abstract away
the provider specific details of individual data access application blocks.
To use IDataAccess effectively, a new data access wrapper class will be defined
to implement the interface. The wrapper class will be instantiated with a value
indicating which type of database provider it will be using. Each of the methods
on the wrapper class will then call the corresponding method on the appropriate
data access application block. The wrapper class will also provide a function to
create database parameter objects in a provider independent way using the
IDataParameter interface. This will allow all of the code in the data access logic
component to be database-independent except for the initial call to instantiate the
wrapper class, which will need to specify which data provider to target. The
actual value can be stored in a configuration file so the code would not need to
change to target a different data provider.
I1.6.1.6.11 .NET Solution Architecture
I1.6.1.6.11.1 Naming, Name Space and Directory Services
Naming of component and the registration of component names and associated
services is of critical importance in a service oriented architecture.
Significant thought has been directed at the issue of namespaces and it is
realized that to completely define the namespace layout at this time for the
complete line of the CCR System .NET framework, business services, and
developed applications would be extremely difficult. Therefore, the following
description will define guiding principles and define an initial namespace layout. It
is expected that the namespace issue will be revisited and revised during the
detailed design of the framework, business services, and initial application.
I1.6.1.6.11.1.1 .NET Namespaces
To assist with allowing the namespace hierarchy to be easy to comprehend yet
provide a logical organization to the system components, we will rely on a
relatively small set of namespaces. Those namespaces will fit into four major
categories:
I1.6.1.6.11.1.2 UI.Framework
This is the root namespace for all of the generalized, non-business directed,
reusable classes. This namespace will contain common components such as
utility functions, logging functions, security functions, etc. that are not specific to
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 106 of 115
any application. Example sub namespaces include:
UI.Framework — contains logging classes, generalized exception
handling classes, security classes, etc.
UI.Framework.Utility — contains string manipulation and other extremely
general classes and functionality.
UI.Framework.Webapp — contains general Web user interface general
classes.
I1.6.1.6.11.1.3 UI.Business.Core
This is the root namespace containing all of the middle-tier base classes that
implement common functionality and form the basis of the inheritance and
extension model for the CCR System .NET. This will include classes in the
Business Façade layer as well as Business Process, and Data Access Logic.
Most of the classes in this namespace will be abstract or should not be directly
instantiated. Classes in this namespace should not be directly altered by
business unit application teams.
UI.Business.Core — Contains business function classes that are more
general than a single system or area.
UI.Business.Core.Certification — Contains business function classes
primarily provided or utilized by a certification process.
UI.Business.Core.Claims — Contains business function classes primarily
provided or utilized by a claims system.
UI.Business.Core.Admin — Contains business function classes primarily
provided or utilized by an administration system.
I1.6.1.6.11.1.4 UI.Business
This is the root namespace containing all of the middle-tier base classes
that implement common functionality and form the basis of the inheritance
and extension model for UI .NET. This will include classes in the Business
Façade layer as well as Business Process, Data Access Logic, and
Business Entity classes in the Business Services layer. The primary
difference between this namespace and UI.Business.Core is that this
namespace will have classes that are to be instantiated and
UI.Business.Core contains the analogous classes that are to be inherited.
This namespace will also contain all of the business entity classes as well
as contain the classes that business units will modify and extend to
provide the extension capabilities of UI .NET.
UI. Business — Contains business function classes that are more general
than a single system or area.
UI.Business.Certification — Contains business function classes primarily
provided or utilized by a certification process.
UI.Business.Claims — Contains business function classes primarily
provided or utilized by claims system.
UI.Business.Core.Admin — Contains business function classes primarily
provided or utilized by an administration system.
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 107 of 115
I1.6.1.6.11.1.5 UI.Application
This is the root namespace for all of the application specific user interface client
classes and code. This is the least well defined namespace due to its inherent
close ties to the individual application clients and thus the close ties to business
unit specific needs.
UI.Application.BUS.Webapp.Certification
UI.Application.BUS.Winform.Certification
I1.6.1.6.11.2 .NET Solutions and Projects
The organization of .NET solutions and projects will focus on providing a logical
and simple organization to the managed software, facilitate easy team
development and deployment, minimize administrative activities, and support the
extensibility and maintenance activities associated with the CCR System. The
general guidelines for the layout for solutions and projects will include:
There will be several categories of projects including business service
oriented, utility functionality, and user interface focused projects.
Business service focused projects will revolve around supporting a single
business service. This organization will separate the business entity
classes from the functional classes and also separate the core
functionality from the extended, shell, functionality. This generally means
that each business service will consist of 4 projects:
1. Core business entity classes
2. Extended/shell business entity classes
3. Core façade, business service, and data access classes
4. Extended/shell façade, business service, and data access classes
Projects that organize general functionality classes will be organized
according to functionality. This will evolve over time as those general
functionality components are identified.
The organization of user interface projects will be largely left to the
individual business units since the user interfaces will be largely business
unit specific
I1.6.1.6.12 Application Development Architecture
I1.6.1.6.12.1 Overview
A definable and repeatable development process is a key to success on any
large software development project. The definition and implementation of a
software development process can be a significant undertaking by itself, even
without consideration of the actual project at hand. As Microsoft.NET is a
relatively new technology at the EDD, it is understood that most software
developers have little or no experience on .NET projects and therefore, a well-
defined process becomes even more important. As a result, it is a goal of the
reusability strategy to define and document a software development process that
will be used to design, construct, deploy and maintain the EDD enterprise
systems. This process will then be shared with other groups and other .NET
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 108 of 115
development initiatives.
It is quite likely this process will make use of many commonly used techniques
from the realms of project management, object-oriented analysis and design, and
various approaches to software construction. This process will also incorporate
Microsoft best practices and recommendations. The definition of the process will
include the following areas:
Requirements gathering and Use Case development.
Detailed design and class/entity modeling.
o Creating .NET projects and solutions.
Design and coding guidelines and best practices.
Source code control and configuration management.
Testing and quality assurance.
Deployment and versioning.
I1.6.1.6.12.2 Business Services Code Reuse
Perhaps the most challenging objective of the reusability strategy will be to
achieve a substantial level of code reuse in the Business Services
implementation yet not exceeding a reasonable level of complexity and keeping
in mind the impact on implementation schedules. Achieving high levels of code
reuse in business logic components presents a unique challenge because these
components, by their nature, tend to be very specific to the business needs and
the different business units can often have differing business requirements. Also,
due to the expected schedule for adoption of this architecture within business
units, it is expected that it will be difficult the get complete and detailed
requirements from all business units during the inception phase of the project.
Therefore, designing initial components that meet the needs of all business units
may not be possible and that they will have to be able to adapt over time as the
requirements become available and/or evolve.
At the heart of the Business Services code reuse strategy will be the use of the
service-oriented and object-oriented features offered by .NET. Each Business
Service will be comprised of a set of classes. There will be business process
classes containing process, workflow, and business logic code, and there will be
data access classes, which will contain data access logic. The implementation of
each Business Service will contain a set of base classes, which contain code
believed to be common and potentially reusable by multiple EDD business units,
and a set of child classes, which contain code unique to a particular business
unit. In this way, common functionality can be leveraged when possible,
extended when practical, and overridden when necessary.
As mentioned earlier, the data contained in the Business Entities will serve to tie
the system together and thus, achieving a high level of code reuse in the
Business Entities will be essential. The proposed solution in this document calls
for Business Entities to be implemented as framework classes with metadata—
the metadata is a model that describes the required data. The Business Entities
will model data objects such as Claim, Employer, Claimant, Address, etc. This
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 109 of 115
will allow the business process classes to operate on the common Business
Entity classes.
By adopting a service-oriented and object-oriented approach the system will take
advantage of code reuse where possible without having to provide a complete
implementation of every requirement at the outset. In addition to code reuse, this
approach will improve the overall maintainability of the system by allowing for the
incremental upgrade and addition of functionality over time.
I1.6.1.6.13 Error Handling and Logging of Errors
Error handling within the CCR System will utilize the .NET Exceptions
infrastructure. Each Business Service will define any unique exceptions it
requires and general system-wide exceptions will also be defined. All custom
exceptions defined in any of the CCR System should inherit from a common
Application Exception base class.
Exceptions will be logged using the Microsoft supplied Exception Management
Application Block. This component provides a flexible, robust, and extensible way
to log exceptions. Custom publishers will be written to log exception information
to the required locations in the required formats.
Part of the detailed design stage of each component should be to identify all
possible error conditions that may occur in each function and choose the
appropriate exception to handle each. This will provide a good way to identify the
necessary custom exceptions early on.
I1.6.1.6.13.1 Logging and Auditing
General Purpose Logging
General purpose logging in the system will be accomplished with features built
on the .NET Trace functionality. This will allow logging code to be embedded into
the release build. The actual logging can be turned on and off, as the situation
requires it. This will aid in troubleshooting after release. The Trace functionality
will also be useful to support more vigorous logging during the development
cycle.
One or more Trace Listeners will be defined in the application configuration file,
or perhaps the machine configuration file and a master Trace Switch will also be
defined to allow the trace level to be set higher or lower after deployment. Any
logging code compiled into the release build will use this Trace Switch to
determine whether or not that particular logging operation should be carried out.
Any logging code, which should not be compiled into the release build, should
use the Debug object. The trace listener defined in the configuration file can be
associated with the Debug object so all of the development-time logging will go to
the desired logs and locations.
Activity Logging/Auditing
Activity logging and auditing services will be provided as a core capability of the
architecture but the utilization of these capabilities will be primarily deferred to the
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 110 of 115
individual business unit and system implementations. Auditing features will be
available that will allow the logging of system relevant events. Although the
definition of a ‗relevant event‘ will be allowed to have some fluidity, it is generally
intended to represent several categories system activity that includes:
Events that should be retained for permanency and that don‘t have
corresponding information tracked as part of the business data. This might
include logging when a user logs in and logs out of the system, security
related events, or system startup and shutdown events.
System monitoring and tuning events. These might include logging calls to
individual façade functions to track frequency and duration of the function
calls.
The primary thing that differentiates audit logging from regular logging will be the
detail of the information captured and its intended analysis. Auditing will capture
detailed context information, event specific information, and allow for the capture
of flexible auxiliary information. It will also be possible to turn on and off the
logging of individual events. It is also expected that audit logging information will
be stored to a database (and possibly other output media) to allow for easy
analysis.
Although the CCR System architecture will provide very general audit and
logging capabilities, the architecture team and individual implementation teams
will define ‗Best Practices‘ for the utilization of auditing and logging to allow for
individual components to be implemented by different teams but still provide a
consistent audit and logging environment. This will better allow for the integration
of software designed and implemented by different teams and within the
enterprise. Although the ‗Best Practices‘ have not been fully defined at this time,
the following are the current guidelines.
1. Audit logging will be centralized in the Service Façade Layer.
2. All Service Façade functions will log the entry and exit from the function to
assist with diagnosis, tuning, and analysis. In addition to the context
information, logged information may include:
a. Time request began.
b. Time request completed.
c. The function being requested.
d. The result of the request (success or failure).
e. Request Specific Information (e.g., Address, ClaimNumber).
I1.6.1.6.14 CCR System Instrumentation and Measurement
I1.6.1.6.14.1 Overview
To determine whether the CCR System meets its performance objectives and to
identify bottlenecks, the EDD needs to measure the application's performance
and collect metrics.
Required metrics are response time, throughput, and resource utilization (how
much CPU, memory, disk I/O, and network bandwidth the CCR System
applications consume while performing its tasks).
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 111 of 115
Objectives include:
Instrument the CCR System
Measure system resource utilization.
Measure code performance.
Measure Web application performance.
Measure Web service performance.
Measure Enterprise Services performance.
Measure ESB/Integration Broker performance.
Measure Interfaces/Adapters/Gateway performance.
Measure Data Access performance.
I1.6.1.6.14.2 Goals of Measuring
Defining metrics (what to measure), and defining the objectives for each metric is
a critical part of the CCR System monitoring and testing.
Performance objectives include the following:
Response time or latency
Throughput
Resource utilization
Response time is the amount of time taken to respond to a request. A response
time can measured at the server or client as follows:
Latency measured at the server. This is the time taken by the server to
complete the execution of a request. This does not take into account the client-
to-server latency, which includes additional time for the request and response to
cross the network.
Latency measured at the client. The latency measured at the client includes
the request queue, the time taken by the server to complete the execution of the
request, and the network latency. Two common approaches are to measure the
time taken by the first byte to reach the client (time to first byte, or TTFB) or the
time taken by the last byte of the response to reach the client (time to last byte,
or TTLB).
I1.6.1.6.14.3 Throughput
Throughput is the number of requests that can be successfully served by the
application per unit of time. It can vary depending on the load (number of users)
applied to the server. Throughput is measured in terms of requests per second.
In some systems, throughput may go down when there are many concurrent
users. In other systems, throughput remains constant under pressure but latency
begins to suffer, usually due to queuing. Other systems have some balance
between maximum throughput and overall latency under stress.
Resource Utilization
The resource utilization costs are identified in terms of server and network
resources. The primary resources are the following:
CPU
Memory and objects
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 112 of 115
Disk I/O
Network I/O
The resource cost can be identified on a per-operation basis. Resource costs can
be measured for a given user load or an average resource costs can be
measured when the application is tested using a given workload profile.
I1.6.1.6.14.4 Metrics
Metrics provide information about how close the CCR System application is to
the EDD performance goals. In addition, they also help to identify problem areas
and bottlenecks within the system. Various metric types can be grouped under
the following categories:
Network: Network metrics are related to network bandwidth usage.
System: System metrics are related to processor, memory, disk I/O, and network
I/O.
Platform: Platform metrics are related to middleware (ASP.NET, .NET, common
language runtime (CLR), Database server, Integration Broker, etc).
Application: Application metrics include custom performance counters.
Service level: Service level metrics are related to business operations per
second.
The measuring should be a continual process and the EDD should start to
measure as soon as first prototype of the application is released and it defined a
set of performance objectives for the application.
The EDD has to continue to measure application performance throughout the life
cycle to determine whether the CCR System application is trending toward or
away from its performance objectives.
I1.6.1.6.14.5 Tools and Techniques
The following tools and techniques should be used to collect data:
System and platform metrics
Network monitoring tools
Profiling tools
Tools for analyzing log/trace files
Application instrumentation
I1.6.1.6.14.5.1 System and Platform Metrics
The tools to collect system and platform metrics are listed below:
System Monitor: This is a standard component of the Windows operating
system. It can be used to monitor performance objects and counters and
instances of various hardware and software components.
Systems Management Server (SMS): This tool helps with asset management,
as well as change and configuration management for the Microsoft platform.
Microsoft Operations Manager (MOM): MOM agents can be installed on
individual servers that collect data and send it a centralized MOM server. The
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 113 of 115
data is stored in the MOM database,
Stress tools. These tools have to simulate clients and collect data during the
duration of a test.
Sysinternals or Winternals Process Explorer: This is an extended System
Monitor. It can be used to monitor performance objects and counters and
instances of various hardware and software components.
I1.6.1.6.14.5.2 Network Monitoring Tools
The tools below can be used to monitor network performance:
Internet Protocol Security (IPSec) monitor: The EDD can use IPSec monitor
to confirm whether the CCR System secured communications are successful. In
this way the EDD can monitor any possible pattern of security-related or
authentication-related failures.
Network Monitor (NetMon): The EDD can use NetMon to monitor the network
traffic. The EDD can use it to capture packets sent between client and server
computers. It provides valuable timing information as well as packet size,
network utilization, addressing, and routing information and many other statistics
that the CCR System can use to analyze system performance.
HTTP(S) Reverse Proxy (Web Access Manager): can be used to monitor
HTTP(S) messages.
WSE 2.0 SOAP Tracing: can be used for SOAP tracing.
I1.6.1.6.14.5.3 Profiling Tools
The following tools (or equivalent) have to be used to profile UIS applications and
databases.
Intel VTune Performance Analyzer, Thread Checker and Thread Profiler:
These tools profile .NET applications by using sampling to gain an accurate
representation of software's actual performance. It gathers CPU snapshots to
identify problems such as cache misses. The tools can drill to the exact operating
system process, thread, module executable, function/method, individual line of
source code, or individual machine/assembly language instruction to identify
specific bottlenecks.
CLR Profiler: This allows the CCR System to create a memory allocation profile
for the application so the EDD can see how much allocation occurs, where it
occurs, and how efficient the garbage collector is within the CCR System
application. By using the various profile views, the EDD can obtain many useful
details about the execution, allocation, and memory consumption of the CCR
System application.
SQL Profiler: This profiling tool is installed with SQL Server. The EDD can use it
to identify slow and inefficient queries, deadlocks, timeouts, recompilations,
errors, and exceptions for any database interactions.
Omegamon: This is a DB2 monitoring tool. The EDD can use it to identify slow
and inefficient queries, deadlocks, timeouts, recompilations, errors, and
exceptions for any database interactions.
Quest Central: This tool performs workload analysis, real-time and historical
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 114 of 115
monitoring of SQL Server and DB2 Databases.
Xtremesoft Appmetrics: This tool profiles and monitors Application Layer
(Business Services implemented as COM+ Enterprise Services).
I1.6.1.6.14.5.4 Tools for Analyzing Log Files
Analyzing log files is an important activity when tuning or troubleshooting the
CCR System live application. Log files can provide usage statistics for various
modules of the application, profiles of the users accessing the CCR System
application, errors and exceptions, and together with other diagnostics, can help
identify performance issues and their possible cause.
The EDD can analyze various logs including: IIS logs, database logs, Windows
event logs, and custom application logs. The EDD can use various third-party
tools to analyze and extract details from these log files.
I1.6.1.6.14.6 Application Instrumentation
In addition to the preceding tools, the CCR System code must be instrumented
for capturing application-specific information. This form of information is much
more fine-grained than that provided by standard system performance counters.
It is also a great way to capture metrics around specific application scenarios.
There are a number of ways to instrument the CCR System code. These are
summarized in the next section, and each approach is expanded upon in
subsequent sections.
Instrumentation is the process of adding code to an application to generate
events to allow the EDD to monitor an application health and performance. The
events are generally logged to an appropriate event source and can be
monitored by standard monitoring tools. An event is a notification of some action.
Instrumentation allows the EDD to perform the following tasks:
Profile applications: Profiling enables to identify how long a particular method
or operation takes to run and how efficient it is in terms of CPU and memory
resource usage.
Collect custom data: This might include custom performance counters that the
EDD uses to monitor application-specific activity, such as how long it takes to file
a claim.
Trace code: This allows the EDD to understand the application code path and all
the methods run for a particular Use Case.
I1.6.1.6.14.6.1 Event Tracing for Windows (ETW)
The ETW is suitable for logging high-frequency events such as errors, warnings
or audits. The frequency of logging can be in hundred of thousands of events
each second in a running application. This is ideal for server applications that log
the business actions performed by the users. The amount of logging done may
be high, depending on the number of concurrent users connected to the server.
I1.6.1.6.14.6.2 Windows Management Instrumentation (WMI)
Windows Management Instrumentation is the core management technology built
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION RFP OSI 7100-181
UIMOD PROJECT APPENDIX I— PAGE 115 of 115
into the Windows operating system. The WMI supports a very wide range of
management tools that lets the EDD analyze the data collected for the CCR
System application.
Logging to a WMI sink is more expensive than other sinks, so the CCR System
should generally do so only for critical and high-visibility events such as a system
driver failure.
I1.6.1.6.14.6.3 Custom Performance Counters
The EDD can use custom counters to time key scenarios within the CCR System
application.
I1.6.1.6.14.6.4 Enterprise Instrumentation Framework (EIF)
The CCR System applications have to be instrumented using Enterprise
Instrumentation Framework (EIF) or a functionally comparable product to publish
errors, warnings, audits, diagnostic events, performance counters and business-
specific events. The CCR System administrators will configure which events to
generate and where the events go and what to record.
The EIF also has an important feature of request tracing that enables the CCR
System to trace business processes or application services by following an
execution path for an application spanning multiple physical tiers.
I1.6.1.6.14.7 System Resources
When the EDD needs to measure how many system resources the CCR System
application consumes, it needs to pay particular attention to the following:
Processor: Processor utilization, context switches, interrupts etc.
Memory: Amount of available memory, virtual memory, and cache utilization.
Network: Percent of the available bandwidth being utilized, network bottlenecks.
Disk I/O: Amount of read and write disk activity. Disk I/O bottlenecks occur if
read and write operations begin to queue.
I1.7 Glossary
See UIMOD RFP Appendix L
cd8cd603-7473-459d-8ea1-927da6f1efd4.doc MARCH 23, 2007
Related docs
Other docs by dsf17373
Tennessee Family Literacy Even Start Programs Family Enrollment Intake Form 2008 2009
Views: 29 | Downloads: 0
Information Literacy Assessment Post Test Information Literacy Initiative Information Competence
Views: 104 | Downloads: 0
