Insurance Application Architecture

Document Sample
Insurance Application Architecture Powered By Docstoc
					        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

				
DOCUMENT INFO
Description: Insurance Application Architecture document sample