LRS_RFP_Att_H_Technical_Exhibits_Addendum_3_02292008 by XZX8QW


        Request for Proposals

  Attachment H - Technical Exhibits

      Addendum Number Three

         February 29, 2008

      Department of Public Social Services
              Los Angeles County
       12860 Crossroads Parkway South
       City of Industry, CA 91746-3411
                                                                       Los Angeles County
                                                        Department of Public Social Services
                                                       LEADER Replacement System (LRS)

                                  NOTICE TO RFP PROPOSERS


LRS RFP - Attachment H (Technical Exhibits)   Page i                          February 29, 2008
                                                                                                         Los Angeles County
                                                                                          Department of Public Social Services
                                                                                         LEADER Replacement System (LRS)

                                                 TABLE OF CONTENTS
EXHIBIT 1 – LRS NETWORK ................................................................................................................. 1

LRS RFP - Attachment H (Technical Exhibits)                   Page ii                                                       February 29, 2008
                                                                                                               Los Angeles County
                                                                                                Department of Public Social Services
                                                                                               LEADER Replacement System (LRS)

1                                                 EXHIBIT 1 – LRS NETWORK
3         The LRS technical infrastructure shall be designed and sized to support an n-tier, Web-services application utilizing a
4         service-oriented architecture (SOA). The diagram below depicts the overall network topology for the LRS and
5         COUNTY’s Enterprise Network (LAnet/EN), including the Eastern Data Center and the Downey Data Center. Note:
6         Downey Data Center may be relocated during Phase 1 (Design/Development/Implementation Phase).

    LRS RFP - Attachment H (Technical Exhibits)                                   Page 1                           February 29, 2008
                                                                                                              Los Angeles County
                                                                                               Department of Public Social Services
                                                                                              LEADER Replacement System (LRS)


 9         The Gateway includes the CONTRACTOR-supplied network access points located in two (2) COUNTY sites
10         approved by COUNTY Project Director, at which the LRS connects to LAnet/EN. COUNTY will provide one (1) HP
11         10842 G2 Rack (42U) Wide rack (or equivalent successor) for the portion of the CONTRACTOR-supplied Gateway
12         that is physically present at each of the two (2) sites. CONTRACTOR shall provide, install, maintain, and own the
13         portion of the CONTRACTOR-supplied Gateway that is physically present at each of the two (2) sites, enclosed
14         within the rack/cabinet described below.

15         COUNTY will provide the following at each of the two (2) COUNTY sites in support of the portion of the
16         CONTRACTOR-supplied Gateway that is physically present at each such site:

17                1. HP 10842 G2 Rack (42U) Wide (or equivalent successor)
18                    Base cabinet without options
20                2. Environmental Infrastructure
21                    Physical security
22                    HVAC
23                    Power (including redundant backup power)
25                3. Physical access to the Gateway
26                    24/7 accessibility
27                    Security clearance and authorization for COUNTY-approved CONTRACTOR staff

28         CONTRACTOR shall provide all goods and services comprising the Gateway, including:

29                1. Cabinet options for the HP 10842 G2 Rack (42U) Wide (or equivalent successor)
30                2. All other goods and services for the Gateway

31         Note: Current COUNTY ISD policy precludes Uninterrupted Power Supply (UPS) at the two (2) COUNTY sites at
32         which the LRS connects to LAnet/EN.

     LRS RFP - Attachment H (Technical Exhibits)                                  Page 2                          February 29, 2008
                                                                                          Los Angeles County
                                                                           Department of Public Social Services
                                                                          LEADER Replacement System (LRS)

34                          STRATEGIES AND INITIATIVES
36   Table 1: DPSS Business Goals
38   The IT strategies and initiatives for fiscal years 2006 through 2009 in support of the
39   DPSS business goals are as follows:
        PROJECT TITLE                              SUMMARY OF PURPOSE                       COMPLETION

      ASH Production             To allow direct notification, exchange of information,    12/31/2007
      Database                   and transmission of electronic documents relative to
                                 the appeals process.

      Audit Software             To automate auditing procedures as required by the        11/01/2007
                                 Fiscal Compliance Section, in order to: track and
                                 review previous audit reports for reference; monitor
                                 and track all audit findings until they are resolved;
                                 track, schedule, and plan future audits and identify
                                 key contact personnel, and attach and manage audit

      Automate TANF              To automate production of the monthly TANF primary        04/30/2007
      Quality Control            and secondary QC universe files.
      Universe Files in
      existing LEADER

      CSBG Report                To automate the report filing/monitoring process of the   07/01/2006
      Management System          103 agencies that provide services to the public
                                 through the Community Service Block Grant program.

      California Child           To replace the interface with the COUNTY’s current        09/01/2008
      Support Automated          ARS system with an interface to the statewide
      System Interface           California Child Support Automated System (CCSAS).

      Case Management            To establish the interface with the State system that     09/30/2008
      Information & Payroll      provides payroll information for those individuals who
      System (CMIPS II)          receive In Home Supportive Services (IHSS) benefits.

      Customer Service           To improve service to DPSS customers by providing         07/16/2007
      Call Center                easy access to quality information and services.

      DPSS Academy               To electronically capture and transfer data regarding     11/01/2007
      Trainee Attendance         DPSS Training Academy activities and attendance for
      for Claiming Process       claiming purpose.

     LRS RFP - Attachment H (Technical Exhibits)                 Page 3                    February 29, 2008
                                                                                     Los Angeles County
                                                                      Department of Public Social Services
                                                                     LEADER Replacement System (LRS)

   PROJECT TITLE                              SUMMARY OF PURPOSE                      COMPLETION

 Departmental Data          To replace an aging and inadequate reporting system      06/30/2007
 Warehousing Project        that extracts over 15,000 data fields from multiple
                            sources with a unified and comprehensive new
                            process that translates data into standardized and
                            internally consistent formats for quicker and more
                            accurate reporting.

 Develop Direct             To offer vendors direct deposit of payments into their   04/30/2007
 Deposit                    bank account.
 Enhancement for
 existing LEADER
 System Vendor

 Document Sharing           To enhance the communication and document                06/30/2007
 GAIN/CalWORKs              exchange between GAIN regional offices and
                            CalWORKs offices.

 Domain                     To consolidate the multiple domain names and file        05/31/2007
 Consolidation              servers located throughout the Department in order to
                            improve manageability and reduce costs.

 Electronic Benefit         To modify the existing LEADER System’s application       10/31/2006
 Transfer (EBT)             in order to support enhanced EBT functionality
 System Modifications       provided by the State system, including online card
                            history inquiry, FS Disaster Services, and the FS
                            Restaurant Meal Program.

 Expand CAST                To allow for the comparison of document images from      07/30/2007
 Document View to           CAST to process IEVS abstracts more effectively.

 Feasibility Study of       To evaluate the feasibility of establishing an           04/30/2007
 One-e-App Interface        automated One-e-App interface with existing LEADER
 Process                    System for the generation Medi-Cal applications.

 GEARS Contract             To complete procurement planning activities for a new    12/01/2006
 Extension and              GEARS Contract.

 Implement existing         To modify the existing LEADER System’s application       04/30/2007
 LEADER System              in order to support direct rent payments to landlords
 Direct Rent for            for CalWORKs participants.

LRS RFP - Attachment H (Technical Exhibits)                Page 4                    February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

   PROJECT TITLE                              SUMMARY OF PURPOSE                      COMPLETION

 Improve existing           To carry out incremental steps toward more flexible      04/30/2007
 LEADER System              existing LEADER System, in order to improve system
 Performance                performance and data integrity, as well as facilitate
                            efficient change management control and quality

 Income and Eligibility     To automate the IFDS & PVS process for abstract          09/30/2006
 Verification System        assignment, prioritization, disposition, benefit
 (IEVS) Recipient           calculation, scheduling appointments, & generating

 Inventory Tracking         To implement a new Equipment Inventory system to         06/30/2008
 Application                replace the current system that is obsolete and no
                            longer supported by the manufacturer.

 LEADER                     To complete reprocurement activities for a LEADER        06/01/2007
 Replacement System         replacement system.

 Existing LEADER            To replace equipment used in the existing LEADER         06/30/2008
 System Technology          System environment that has reached the
 Refresh                    manufacturer’s end-of-life designation and is fully

 Laptop Lifecycle           To purchase 50 laptops in order to replace outdated      06/30/2007
 Refresh                    equipment.

 Lifestyle Printer          To purchase 2,000 printers to replace worn or broken     06/30/2007
 Refresh Project            LaserJet printers.

 Lotus Notes                To migrate the existing Lotus Notes Custom               12/31/2008
 Application Migration      Applications to a standard technological platform that
                            would provide a faster development cycle and reduce
                            the cost of maintenance.

 Lotus Notes E-Mail         To migrate to Microsoft Exchange in order to achieve     12/31/2006
 Migration to               a significant reduction in administrative overhead and
 Exchange                   hardware cost.

 MC QMR                     To modify the existing LEADER System’s application       TBD
                            in order to establish QMB as a program separate from

 MIE QA Auditor             To utilize and enhance the Q5i software program for      07/31/2007
 Enhancement                audit teams.

LRS RFP - Attachment H (Technical Exhibits)                Page 5                    February 29, 2008
                                                                                         Los Angeles County
                                                                          Department of Public Social Services
                                                                         LEADER Replacement System (LRS)

        PROJECT TITLE                              SUMMARY OF PURPOSE                     COMPLETION

      Medi-Cal (MC)              To automated case referrals to the Healthy Families     TBD
      Bridging                   program after the bridging period for children going
                                 from zero share-of-cost (SOC) to a SOC.

      Network Refresh            To replace old switches no longer under equipment       07/31/2007

      Oracle Contract            To automate the current manual system for the           07/31/2007
      Management System          tracking of vendors and contracts.

      PA 2197 - Service          To automate the current PA 2197 manual process for      07/31/2006
      Request Tracking           the procurement of equipment and services.

      Pentium III Desktop        To purchase 250 Workstations for use while broken       06/30/2007
      Lifestyle                  equipment is being repaired or replaced.
42   Table 2: DCFS Business Goals
44   The IT strategies and initiatives for fiscal years 2007 through 2009 in support of the
45   DCFS business goals are as follows:
          PROJECT TITLE                            SUMMARY OF PURPOSE                      COMPLETION
      Adoption Promotion and        To automate the APSS referral management, case       6/30/2008
      Support Services              management, billing, invoice, case and financial
      (APSS)                        report functions.
      Adoptions Public              To provide an automated process for Children’s       6/30/2009
      Website                       Social Workers and the public interested in
                                    adopting to search for children that are available
                                    for adoption based on various criteria.
      Application Express           Application Express (previously know as HTMLDB)      6/30/2008
      Conversion                    is a rapid Web-application development tool. This
                                    project will convert existing standalone
      Automated Eligibility         To automated the manual Foster Care Eligibility      12/31/2009
      Determination (AED)           Determination process.
      California Child Support      To replace the current interfaces between DCFS       8/1/2008
      Automation System             and LA County of Child Support Services
      (CCSAS) Interface             Department (CSSD).
      Child Caregiver               To streamline the process of tracking caregiver      12/1/2008
      Agreement/Performance         information and agreement related data, provide
      Measures System               electronic storage of agreements and track the

     LRS RFP - Attachment H (Technical Exhibits)                Page 6                   February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

     PROJECT TITLE                            SUMMARY OF PURPOSE                      COMPLETION
                               caregiver’s performance measurement information.
 Countywide Court              To expand the Court Reports Document Imaging          6/30/2008
 Report Document               pilot project.
 Imaging Phase II
 DCFS Reporting                To re-structure the Department’s data reporting       6/1/2008
 System                        based on the Director’s Goals and the DCFS
                               Outcome Measures.
 Electronic Suspected          To provide a rapid, secure electronic transmission    6/30/2008
 Child Abuse Report            and receipt of mandated suspected child abuse
 (E-SCARS)                     reports between DCFS, Sheriff, Law Enforcement
                               Agencies and the District Attorney’s office.
 Family Support Services       To automate a billing and invoice system for          6/30/08
                               community-based agencies.
 Foster Care Compliance        To provide an automated Home Compliance               12/31/2007
 Tracking & Alert System       Tracking and Alert system to facilitate the
                               monitoring of Foster Home compliance to DCFS
                               specifications with regards to training,
                               assessments, and certifications.
 Hard Disk Encryption          To ensure that all Tablet PC/laptops that are         12/31/2007
                               purchased and deployed have full hard disk
 ID Management                 To implement an Identity Management solution to       6/30/2008
                               manage, control and track all Department users
                               that access Department systems, implement single
                               sign-on solution, reduce load of user security
                               administration and support auditing of which
                               systems are accessed by which user.
 Incident Tracking             To modify the existing ITrack system, database        6/1/2008
 System (ITrack)               and screens to increase the ability to provide
 Enhancement                   statistical data.
 Infrastructure Upgrade        To upgrade the LAN infrastructure for one site to a   9/1/2007
                               100/1000 MBPS switch network.
 Item Control Tracking         To automate the Item Control tracking system          6/30/2008
 System                        using the Department’s CWTAPPS database and
                               the CWS/CMS datamart.
 Juvenile Court Services       To automate a system to track the number of           6/30/2008
 24.1 Joint Assessment         referrals on youth being serviced by both DCFS
 Tracking System               and the Probation Department.
 Kinship Document              To implement a Kinship electronic document            12/31/2007
 Management                    process flow to track, control and manage all tasks
                               involved in the assessment process of caregiver
 Live Scan Store and           To purchase and install a Live Scan Store and         6/30/2008
 Forward                       Forward device to be used in conjunction with
                               twenty-eight Live Scan terminals.
 Master Roster System -        To acquire a market software product to replace       6/30/2008
 MRS                           the current mainframe Master Roster System.
 Multidisciplinary             To automate a Multidisciplinary Assessment Team       6/30/2008
 Assessment Team               (MAT) tracking system to populate the MAT
 (MAT) System`                 referral, and produce management reports.
LRS RFP - Attachment H (Technical Exhibits)                Page 7                    February 29, 2008
                                                                                   Los Angeles County
                                                                    Department of Public Social Services
                                                                   LEADER Replacement System (LRS)

     PROJECT TITLE                            SUMMARY OF PURPOSE                     COMPLETION
 Network Admission             To implement Cisco Network Admission Control        4/1/2008
 Control                       (NAC) technology to provide network based
                               security policy management of all devices
                               connected to DCFS networks.
 Office 2003                   To upgrade 7000 DCFS PCs to Microsoft Office        11/15/2008
                               2003 Standard with Software Assurance.
 Output Optimization           Purchase and install output devices, printers and   6/30/2008
                               Multi-function Devices.
 Time Study Claiming           Develop a Time Study Claiming System linking the    TBD
 System                        Item Control System and the CWS/CMS datamart
                               to identify CSWs who are case-carrying workers in
                               order to produce accurate and timely State and
                               Federal reports.
 WCMIS Replacement             To replace the current Welfare Case Management      12/1/2008
                               Information System (WCMIS) to allow users an
                               interface with the Statewide Central Index System
                               to obtain CIN numbers and to allow the ability to
                               interface with other county systems.
 Work Order Tracking           To modify the current Work Order Tracking System    3/1/2008
 System Enhancement            to accommodate new requirements and reports.
 Workstation                   Purchase, install and implement Altiris Client      TBD
 Management                    Management Suite to replace Novell ZenWorks
 Workstation Upgrade           Purchase workstations to replace outdated           12/31/2007
                               computers and to accommodate new staff.

LRS RFP - Attachment H (Technical Exhibits)               Page 8                   February 29, 2008
                                                                                Los Angeles County
                                                                 Department of Public Social Services
                                                                LEADER Replacement System (LRS)

53   Guiding Principles for Systems Acquisition and Development
55   Federated Governance Model
56   To ensure that Information Technology (IT) resources deliver maximum business value,
57   the County employs a federated structure to manage information technology. Reflecting
58   the overall business model of decentralized County management, the federated
59   approach balances the benefits of local autonomy with the advantages of enterprise-
60   wide IT coordination and management. It simultaneously allows responsiveness to
61   business issues and accountability to local management, while establishing a
62   convergent IT direction and optimized infrastructure. This approach keeps decision-
63   making as close as possible to the business unit while integrating the fabric of the
64   County technology infrastructure, electronic data, and horizontal processes.
66   The County’s Federated Governance Model recognizes three levels:
67      Enterprise – policy, standards, infrastructure, enterprise systems, security, and
68       telecommunications.
69      Affinity Group – processes, systems, and data shared between multiple
70       departments.
71      Department – systems internal to a specific department or functional area.
73   Each of these three tiers represents varying blends of integration and autonomy. At
74   each level, an IT function is autonomous except as it relates to the tiers(s) above, and
75   complies with information technology policies, standards, conventions and practices for
76   purposes of business processes and systems integration.
78   1.       Guiding Principles for System Acquisition and Development
79            The County’s Chief Information Office has developed the following principles for
80            new system acquisitions and system development.
82               Open Standards. All new system acquisition and development should
83                employ products or solutions that use open industry standards to facilitate
84                interoperability between applications, systems and organizations. Open
85                standards are technology specifications that are publicly available and
86                affirmed by an industry-recognized standards body. The use of open
87                standards that allow for interoperability between applications and vendor-
88                specific products and will ensure their flexibility and adaptability to changing
89                business needs.
     LRS RFP - Attachment H (Technical Exhibits)           Page 9                    February 29, 2008
                                                                                Los Angeles County
                                                                 Department of Public Social Services
                                                                LEADER Replacement System (LRS)

 91               Industry-Proven Technology. All new system acquisition and infrastructure
 92                should use commercially viable, industry-proven, widely-used technology to
 93                the maximum extent possible. Use of industry-proven, widely-used
 94                technology allows for easier access to affordable skills and a large base of
 95                proven software solutions. It can reduce risk, and helps ensure robust product
 96                support. Wherever practical, the County should implement commercial-off-
 97                the-shelf technology as a first preference over completely custom
 98                applications. Open Source software should only be used when a viable set of
 99                commercial vendors have committed to support it.
101               Countywide Network Backbone. The Los Angeles County Enterprise
102                Network (LAnet-EN) will be used as countywide network backbone for
103                applications and services to foster greater collaboration and sharing of data
104                between County departments and agencies. The County uses the TCP/IP
105                family of protocols as the standard network protocol to ensure technical
106                compatibility and efficient use of the available data transport resources.
108               Multi-tier Server Architecture. All new system acquisition and development
109                should employ a multi-tiered architecture that separates presentation,
110                business logic, database and other services into logical components. A multi-
111                tiered architecture provides architectural flexibility from many perspectives
112                including scalability to meet future growth needs, selection of different
113                platforms to meet potential changes to technology standards and directions,
114                and minimization of technology obsolescence.
116               Web Browser Client. All new system acquisition and development should
117                employ server-based thin client solutions requiring only network access and a
118                Web browser for end-user access whenever such solutions are technically
119                appropriate. Through the use of server-based applications, thin client
120                technologies (especially Web-based clients), portals, and gateways, County
121                Departments can reduce the cost and complexity of all IT functions, making it
122                easier to implement, deploy, manage, and monitor applications and
123                information resources. Server-based architecture provides the ability to rollout
124                new applications and upgrades to the entire organization simultaneously.
126               Server Consolidation. To the extent possible, systems should utilize new
127                technologies and architectures that provide for a consolidated server
128                environment. Such consolidated server environment will streamline software
129                licensing, more efficient system administration, better scalability and
130                utilization planning, and provide a more effective management of storage,
131                system capacity and performance, and backup and disaster recovery.
133               Service Oriented Architecture (SOA). This approach requires that County
134                and its Departments take a critical look at their operations and develop a
135                ―service-based‖ business model. Such modularization at the business level
      LRS RFP - Attachment H (Technical Exhibits)           Page 10                  February 29, 2008
                                                                               Los Angeles County
                                                                Department of Public Social Services
                                                               LEADER Replacement System (LRS)

136                allows for the development of a systems architecture that is also modular and
137                flexible for unanticipated changes in business requirements and technology.
138                The SOA implementation shall be based on the following principles as
139                defined under California Enterprise Architecture Program Service-Oriented
140                Architecture (SOA) Master Guide:
141                1. Design for Ease of Use
142                2. Design Web services with appropriate granularity
143                3. Reassemble before Rewrite
144                4. Web services should be loosely coupled and extensible
145                5. Web services must have well-defined interfaces
146                6. Design stateless base Web services
147                7. Implement business processes via orchestrating Web services into a
148                    process flow (BPEL standard)
149                8. A governance structure must be created to manage Web service
150                    development and operational environments
151                9. Implement Web service security and policy enforcement standards
153               Support Event-Based Processing.            All new system design and
154                development should be driven by business events. Event-based processing
155                enables applications to adapt quickly to changes in business processes by
156                only changing the application component related to the changed business
157                event and strengthens linkage to the business by mirroring the actual
158                business environment.
160               Support Workflow Processing. All new system design and development
161                should incorporate workflow functionality. Workflow processing enables
162                applications to incorporate functionality such as approvals within an
163                application and change processing paths through the application without
164                source code programming changes.
166               Support Data Warehousing. All new system acquisition and development
167                should support the capability to develop online transaction processing (OLTP)
168                and/or data warehousing applications. These two classes of applications
169                require very different data models and make very different demands on
170                database systems. Online transaction processing focuses on quick updates of
171                the data. Often, the speed of these updates can be dramatically slowed down
172                by the processing generated by user queries. For this reason, it is best to
173                separate the data warehouse from the OLTP. In so doing, we also provide for
174                a more secure environment for both OLTP and data warehousing.
176               Partitioning and Modularization of Application Components. System
177                solutions should be highly partitioned, modular in design, that are comprised
178                of components that are maximally decoupled, and that use standards-based
179                messaging protocols for communication between external and internal
180                systems. This kind of modular implementation should allow for the upgrade,
      LRS RFP - Attachment H (Technical Exhibits)          Page 11                  February 29, 2008
                                                                               Los Angeles County
                                                                Department of Public Social Services
                                                               LEADER Replacement System (LRS)

181                exchange, and reuse of products with minimal retooling or disruption to the
182                overall environment.
184               Application and/or Network Security.         The County requires that all
185                applications conform to the Information Security Strategic Plan:
186       The County requires
187                that all departments and designated contractors implementing new
188                applications contact Allen Brusewitz, Chief Information Security Officer for
189                assistance in determining security requirements for the network, application
190                and associated database. Mr. Brusewitz may be reached by telephone at
191                (562) 940-3873 or by email at:
193   2.       Development Standards
194            The standards presented below are preferred technologies for products
195            developed for the County. The County will consider alternate proposals that
196            deviate from the standards if an acceptable business case is presented.
198               Unified Modeling Language. The use of the Unified Modeling Language
199                (UML) for system specification and modeling is highly recommended for all
200                enterprise level applications. UML is an open non-proprietary methodology
201                used for business process and organizational structure modeling that
202                promotes object-oriented software development.
204               Database Management Systems (DBMS).                The standard database
205                management system (DBMS) for enterprise or affinity group applications is
206                Oracle.    Microsoft’s SQL Server DBMS is acceptable for department
207                applications and may be offered as an alternative for enterprise or affinity
208                group applications, but must present an acceptable business case.
210               User Interface. All newly developed or acquired applications shall be
211                accessible using a standard HTTP/HTTPS browser. To the extent possible
212                and when cost-effective applications shall be browser neutral. Public Internet
213                access shall be developed to be ―browser neutral‖ and support the latest
214                version of the browser and also be backward compatible by three (3) major
215                releases.
217               Component Based Development Language. Enterprise or affinity group
218                application should utilize Java2 Enterprise Edition (J2EE) to support an open,
219                non-proprietary architecture. Department applications may utilize a .NET
220                platform. New systems should use XML-based data architectures for
221                increased standardization and data sharing, including industry specific XML
222                dictionaries and schemas (e.g., Justice XML, etc.).
224               Open Architecture. All new systems should utilize an open architecture
225                using industry standards such as Web Services and XML, WSDL, SOAP,
      LRS RFP - Attachment H (Technical Exhibits)          Page 12                  February 29, 2008
                                                                                Los Angeles County
                                                                 Department of Public Social Services
                                                                LEADER Replacement System (LRS)

226                UDDI, SAML, and OASIS. Also, functionality such as Transactional Integrity,
227                Monitoring, Auditing, and Security must be supported natively by the product.
229               Integration Brokers and Interfaces. All interfaces and data conversions
230                involving enterprise, affinity group or departmental applications should utilize
231                one of the County’s recommended integration broker technology platforms:
232                WebSphere MQ Integrator, Cloverleaf Integration Services, and SeeBeyond.
234               Web Servers / Application Development Platforms. All Web hosting for
235                enterprise and multi-department applications should utilize Apache-based
236                application servers (e.g., WebSphere, Oracle Application Server, JBOSS,
237                Tomcat, etc.) and Department applications should utilize Microsoft Internet
238                Information Servers.
240               Business Intelligence Reporting Tools. New applications development or
241                acquisitions should utilize the County’s standard reporting tool Cognos suite
242                of business intelligence software. For formatted reporting embedded within
243                applications, Crystal Reports and Oracle Report tools may be used.
245               Database Communication. All direct database communication shall utilize
246                ODBC, JDBC, ADO/OLEDB, or ADO.NET.
248               Geographic Information Systems.         Environmental Systems Research
249                Institute (ESRI) ArcGIS tools for Geographic Information Systems (GIS) and
250                mapping applications may be used.
252               Storage. EMC, HP, and Network Appliance storage products may be used.
254               Enterprise Content Management.              Enterprise content management
255                technologies (i.e. document imaging, document capture, document
256                management, document storage, and workflow) should utilize enterprise-
257                class solution suites that offer multiple technology components (e.g., EMC,
258                Global 360, FileNet P8, and Hyland OnBase).
260               Electronic Forms (eForms). Adobe product suite should be used for
261                eForms solutions to internal and external users. Global 360, FileNet P8, and
262                Hyland OnBase may also be used.
264   3.       Preferred Enterprise IT Standards and Recommendations
266            The following table provides a list of preferred enterprise IT standards and
267            recommendations which COUNTY may revise from time to time:

      LRS RFP - Attachment H (Technical Exhibits)           Page 13                  February 29, 2008
                                                                                       Los Angeles County
                                                                        Department of Public Social Services
                                                                       LEADER Replacement System (LRS)

                                                    Preferred Enterprise IT Standards and
                                                    Recommendations (Current Version)
       Operating Systems
       Client operating system                      Microsoft Windows
       Department Server operating                  Microsoft Windows Server
       Enterprise/Mid-Range                         HP- UNIX, AIX, Linux

       Wide Area Network (WAN)                      Los Angeles County Enterprise Network
       Local Area Network (LAN)                     Microsoft Windows
       WAN/LAN Infrastructure                       Cisco and TCP/IP
       Wireless LAN                                 IEEE 802.11

       Antivirus                                    Symantec, Network Associates (McAfee)
       Patch Management                             PatchLink and Altiris
       Anti-spam                                    BrightMail
       Firewall                                     Cisco PIX Firewalls
       Network Intrusion                            Cisco Network Intrusion
       Host Intrusion Protection                    Cisco CSA and McAfee Entercept
       Internet Filtering                           BlueCoat
       Electronic Signature                         Standard to be established
       Digital Certificates                         Standard to be established

       Remote Access
       Remote Access                                LAnet/EN VPN
       Two factor authentication                    RSA SecurID

       Desktop Management
       Directory Services                           Active Directory
       Desktop Configuration                        Altiris
       Desktop Firewall                             Zone Alarm, Microsoft

       Office Productivity Software
       Desktop Office Suite                         Microsoft Office
       Word Processing                              Microsoft Word
       Spreadsheet                                  Microsoft Excel
       E-mail                                       Microsoft Outlook/Exchange
      LRS RFP - Attachment H (Technical Exhibits)                 Page 14                   February 29, 2008
                                                                                Los Angeles County
                                                                 Department of Public Social Services
                                                                LEADER Replacement System (LRS)

                                              Preferred Enterprise IT Standards and
                                              Recommendations (Current Version)
 Presentation software                        Microsoft PowerPoint
 Adobe pdf                                    Adobe Acrobat Professional

 Web Browser and Content
 Browser                                      Microsoft Internet Explorer 7.0, Firefox 2.0,
                                              Netscape 9.0 and higher versions with 128 bit
 Web content management                       Stellant
 Portal Software                              WebSphere

 Databases and Reporting
 Database Architecture                        SQL compliant
 Database software                            Oracle and Microsoft SQL Server
 Business Intelligence                        Cognos Business Intelligence Product Suite
 Ad hoc Report Writer                         Cognos Business Intelligence Product Suite

 GIS                                          ESRI Arc Tools
 Document Management                          EMC, Global 360, FileNet P8, and Hyland OnBase
 e-Forms                                      Adobe

 File Transfers
 File Transfer Protocols                      FTP, SFTP

LRS RFP - Attachment H (Technical Exhibits)                 Page 15                  February 29, 2008
                                                                         Los Angeles County
                                                          Department of Public Social Services
                                                         LEADER Replacement System (LRS)



274             California Enterprise Architecture
275                         Program

281            Service-Oriented
282           Architecture (SOA)

284                                   Master Guide

288   Revision History
289   06/30/2006 Original Draft
290   09/11/2006 Appendix D – Legacy Integration Patterns, enhanced ESB section.
291   LRS RFP - Attachment H (Technical Exhibits)    Page 16                  February 29, 2008
                                                                                                       Los Angeles County
                                                                                        Department of Public Social Services
                                                                                       LEADER Replacement System (LRS)

292                                              Table of Contents
293   SOA Documents ................................................................................................19

294   The Business Case for SOA Overview ............................................................20

295          A Business-Oriented Foundation for Services ......................................21

296          SOA and Gartner “Hype Cycle” .............................................................. 22

297   SOA Introduction...............................................................................................23

298          The Accidental Architecture .....................................................................23

299          SOA ............................................................................................................23

300          Loosely Coupled Interfaces .....................................................................24

301   SOA Architecture ..............................................................................................26

302          Web Services .............................................................................................26

303               Web Service Patterns ..........................................................................26

304               Web Service Composition ...................................................................26

305               Web Service Orchestration .................................................................27

306               Web Service Types ..............................................................................27

307               Web Service Standards .......................................................................27

308   Enterprise Service Bus (ESB) ..........................................................................27

309          SOA Security .............................................................................................28

310               Identity and Authentication .................................................................28

311               SAML (Security Access Markup Language) ......................................28

312               Security Standards ..............................................................................28

313   Reference SOA Architecture ............................................................................28

314   California SOA Principles .................................................................................30

315   California Service Centers ................................................................................33

      LRS RFP - Attachment H (Technical Exhibits)                                Page 17                            February 29, 2008
                                                                                                     Los Angeles County
                                                                                      Department of Public Social Services
                                                                                     LEADER Replacement System (LRS)

316          Consolidated Service Centers .................................................................33

317          Shared Services ........................................................................................33

318          SOA Infrastructure ....................................................................................34

319          Enterprise Service Bus .............................................................................34

320   California SOA Center of Excellence ...............................................................34

321          Introduction ...............................................................................................34

322          SOA Excellence Model..............................................................................36

323   SOA Tools ..........................................................................................................37

324          Development Tools ...................................................................................37

325          Enterprise Repository ...............................................................................37

326          Business Activity Monitoring (BAM) .......................................................37

327   Appendices ........................................................................................................37

328          Appendix A - Federal SOA........................................................................37

329          Appendix B - SOA Advantages (Patricia Seybold Group) .....................38

330          Appendix C – WSDL Example ..................................................................39

331          Appendix D – Legacy Integration Patterns .............................................40

332               Overview ...............................................................................................40

333               Integrating Existing Mainframe Apps - Unmodified ..........................40

334               Placing Web Service Interfaces on Existing Mainframe Apps .........42

335               Compiling COBOL Code into Web Service Languages ....................42

336          Appendix E – Definitions ..........................................................................42

      LRS RFP - Attachment H (Technical Exhibits)                              Page 18                            February 29, 2008
                                                                                 Los Angeles County
                                                                  Department of Public Social Services
                                                                 LEADER Replacement System (LRS)

338   SOA Documents
340   The service oriented architecture advocated by the California Enterprise Architecture Program is
341   organized into a set of interrelated documents. A master guide serves as the ―jumping off point‖
342   and describes in an overview fashion the key parts of SOA.

347   There are six whitepapers plus a roadmap to address in-depth details of SOA.

      LRS RFP - Attachment H (Technical Exhibits)            Page 19                   February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

349   The Business Case for SOA

351   Overview
352   ―It’s not the strongest of the species that survive, or the most intelligent, but the ones most
353   responsive to change‖. Charles Darwin
355   A service-oriented architecture (SOA) is a good choice for handling the ―how‖ of business
356   services. That is, once business services are appropriately defined, they can be implemented in
357   SOA. This strongly implies that business services must first be defined and categorized which
358   means a different way of thinking about how we deliver services to constituents. Instead of
359   looking at ―the business‖ from an isolated set of requirements and applications perspective, we
360   need to look across individual applications and determine our true business architecture.
362   What are the capabilities for a particular business, how are the capabilities related, and what are
363   the implications for connecting capabilities? Once business services are understood, we can
364   look for candidates for shared services. Business services can also be grouped into ―service
365   centers‖; for example, Health Service Center, Taxes Services Center, or a License Service
366   Center. Shared IT services reduce costs by getting rid of duplication and they also promote
367   consistency.
369   Many business services have multi-level government scope that may span Federal, state,
370   county, and local levels. So interoperability becomes very important. With a variety of
371   government entities involved, standards-based applications are a must.
373   Here is a summary of some of the business benefits of SOA:
375            • Increases Business Agility - SOA can enhance the ability of a business to react to
376            new regulations, policies, or opportunities and deliver innovative services to citizens and
377            businesses in a timely manner. This is possible because an SOA-enabled environment
378            is standards-based, platform neutral, and eventually, a good portion of the new
379            requirements can be met using existing shared services or aggregating existing services
380            to form a new one.
383            SOA opens the door for business and IT to engage in a much richer dialogue. By
384            focusing on what the business wants (not how it work gets done), specific parts of a
385            given business process can be delegated to different parts of the organization as well as
386            external partners.
388            • Reducing Business Risk and Exposure – Regulatory compliance is essentially a
389            business agility issue since legislation changes on a regular basis. Increased business
390            services flexibility in the face of changing laws and regulations is a concrete instance of
391            the business agility benefit of SOA. Specifically, SOA primarily offers a risk-reduction
392            capacity to public sector entities looking for increased operations flexibility.

      LRS RFP - Attachment H (Technical Exhibits)               Page 20                   February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

395            Improved governance, compliance, and general risk reduction is a different quantifiable
396            benefit than increased business agility. Compliance and governance offers a reduction
397            of liability, while business agility offers an increase in business opportunity.
398            Implementing SOA for the purpose of improving business processes, establishing state-
399            wide security, privacy, and implementation policies, and providing auditable information
400            trails, are ways that SOA can reduce several of the risks facing departments today.
402            • Increases Asset Reuse – One of the most important benefits of SOA is that users can
403            create new business processes and composite applications from existing services. In
404            other words, service reuse becomes the mode of operation instead of application
405            integration. Over time, as the state builds and reuses services, the ROI will increase.
408            • Encourages Effective Collaboration – SOA promotes sharing of ideas, business
409            services, solutions, best practices, frameworks, and tools across departments and
410            agencies. This results in lower overall costs, greater ROI for a given service, and a
411            higher degree of consistency from the user’s perspective.
414            • Reduces Integration Expenses – SOA provides an opportunity to migrate away from
415            monolithic, hard to change heavy business applications to light weight, loosely-coupled
416            business services. Loosely-coupled systems can reduce the complexity and hence the
417            cost of integrating and maintaining distributed computing environments. While moving to
418            standards-based interfaces such as Web Services reduces integration and cost
419            somewhat, the real win with SOA is in replacing multiple fine-grained functions with
420            coarse-grained, loosely coupled services that can handle a wider range of business
421            interactions in a more flexible manner. This results in less maintenance and upgrade
422            headaches, fewer customer complaints, and more secure systems.
425            • Reuse of Legacy Systems – By Web service enabling legacy systems, departments
426            can extend the life of and continue to take advantage of their mainframe investments
427            while allowing legacy applications to participate in a services environment. This is a key
428            strategy in moving from a predominately legacy applications environment to an SOA-
429            enabled shared services environment.

432   A Business-Oriented Foundation for Services
433   The following article is a good description of how business and IT can become closer aligned. It
434   advocates that a business architecture is necessary to describe the business capabilities which
435   define ―what‖ a business does, and SOA is a good mechanism for handling ―how‖ the
436   capabilities are implemented.
439   us/dnbda/html/ServOrient.asp .
440   Ulrich Homann - Microsoft Corporation, February 2006.

      LRS RFP - Attachment H (Technical Exhibits)              Page 21                   February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

442   SOA and Gartner “Hype Cycle”
443   Gartner produces ―hype cycle‖ diagrams for a variety of topics. They are intended to show
444   where a given item fits within a maturity curve. They contrast the visibility of an item with a pre-
445   defined set of maturity points identified as Technology Trigger, Peak of Inflated Expectations,
446   Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity which represent
447   the beginning and ending of the maturity curve.
449   Following, is the Gartner ―Hype Cycle for Government, 2005‖. It depicts SOA in the ―Trough of
450   Disillusionment‖ meaning many public sector entities are in the process of figuring out how to
451   capitalize on the benefits of SOA. In contrast, many private industry companies would position
452   SOA in the ―Slope of Enlightenment‖ phase. For example, see The Hartford: Lessons From 3
453   Years of Work On SOA .


      LRS RFP - Attachment H (Technical Exhibits)              Page 22                    February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

458   SOA Introduction

460   The Accidental Architecture
461   Over the past two decades, numerous distributed computing models arrived on the scene,
462   including DCE, CORBA, DCOM, MM, EAI brokers, J2EE, .NET, and Web services. However,
463   indications are that only a small percentage of enterprise applications are connected, regardless
464   of the technology being used. According to a research report from Gartner Inc. ("Integration
465   Brokers, Application Servers and APSs" 10/2002), number less than 10%.
467   Another surprising statistic - of the applications that are connected, only 15% are using formal
468   integration middleware. The rest are using the ETL and batch file transfer techniques, which
469   are largely based on hand-coded scripting and other custom solutions.
471   The Gartner statistics provide sobering data points that illustrates the true state of integration
472   today. How are the other 85% of applications connected? A very common situation that exists
473   in enterprises today is referred to as "the accidental architecture."
475   The accidental architecture is something that nobody sets out to create; instead, it's the result of
476   years of accumulating one-of-a-kind pointed integration solutions. In an accidental architecture,
477   corporate or organizational applications are perpetually locked into an inflexible integration
478   infrastructure. They continue to be treated as "silos" of information because the integration
479   infrastructure can't adapt to new business requirements.
481   Most integration attempts start out with a deliberate design, but over time, other pieces are
482   bolted on and "integrated," and the handcrafted integration code drifts away from the original
483   intent. Through incremental patches and bolt-ons, integrated systems can lose their design
484   integrity, especially if the system is maintained by a large number of people to whom the original
485   design intent may not have been well communicated. It's a fact that individual point-to-point
486   integrations will drift away from consistency, as engineers make "just this one little change"
487   that's expedient at the time. Eventually, it becomes difficult to even identify the points for
488   making changes, and to understand what the side effects would be as a result. In a deployed
489   system this can lead to disastrous results that will negatively affect your business.
491   Above excerpts from – David A. Chappell (Sonic Software) “Enterprise Service Bus” 2004

492   SOA
493   SOA has become a well-known but somewhat elusive acronym. Some describe SOA as an IT
494   infrastructure for business enablement while others look to SOA for increasing the efficiency of
495   IT.
497   Gartner defines SOA as ―an architectural style in which certain discrete functions are packaged
498   into modular, shareable, distributable elements ("services"), which can be invoked by
499   consumers in a loosely coupled manner‖. With SOA, integration becomes forethought rather
500   than afterthought—the end solution is likely to be composed of services developed in different
501   programming languages, hosted on disparate platforms with a variety of security models and
502   business processes. While this concept sounds incredibly complex it is not new—some may
      LRS RFP - Attachment H (Technical Exhibits)              Page 23                    February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

503   argue that SOA evolved out of the experiences associated with designing and developing
504   distributed systems based on previously available technologies.
506   The acronym SOA prompts an obvious question—what, exactly, is a service? Simply put, a
507   service is a program that can be interacted with through well-defined message exchanges.
508   Services must be designed for both availability and stability. Services are built to last while
509   service configurations and aggregations are built for change. Agility is often promoted as one of
510   the biggest benefits of SOA—an organization with business processes implemented on a
511   loosely-coupled infrastructure is much more open to change than an organization constrained
512   by underlying monolithic applications that require weeks to implement the smallest change.
513   Loosely-coupled processes and loosely-coupled information structures result in loosely-coupled
514   systems.
516   Services and their associated interfaces are designed to be re-configured or re-aggregated to
517   meet the ever-changing needs of business. Services remain stable by relying upon standards-
518   based interfaces and well-defined messages—in other words, SOAP and XML schemas for
519   message definition. Services designed to perform simple, granular functions with limited
520   knowledge of how messages are passed to or retrieved from them are much more likely to be
521   reused within a larger SOA infrastructure.
523   SOA and Web Services have recently been used interchangeably. That is because most of the
524   SOA standards work has focused on Web services. New standards are emerging and new
525   vendor products are now available that focus on Enterprise Service Bus concepts. For
526   example, major technology companies are currently working on Service Data Objects. SDOs
527   will enable uniform access to application data and a common programming model for all data
528   sources, wherever and however the data is stored. SDOs leverage the simplicity of XML
529   without introducing the complexity of XML Schema or the performance issues of serialization.
530   Using SDOs and SOA together, systems programming tasks are separated from the business
531   logic and encapsulated in reusable services. They simplify business application programming
532   without getting pulled into technology or implementation details.

533   Loosely Coupled Interfaces
534   Most current applications interact via tightly coupled interfaces. This requires the calling
535   application to know language specific and datatype details of the target application (for example,
536   Java API). This makes maintenance more difficult and the notion of shared services built on
537   tightly coupled interfaces very difficult.
539   Loosely coupled interfaces use industry standard XML messages to communicate. This
540   process uses a messaging broker (or backbone) to handle the delivery details. This is often
541   referred to as an Enterprise Service Bus.
543   SOA Web services are based on loosely coupled interfaces. XML messaging is the core of
544   Web services. There are many WS* standards that define the different types of XML content.
546   The above paragraphs address loose coupling from a technical perspective. It should be noted
547   that business processes and information can (and usually are) designed for only a limited set of
548   consuming applications. Thus, they are tightly-coupled limiting their usefulness.

      LRS RFP - Attachment H (Technical Exhibits)             Page 24                   February 29, 2008
                                                                        Los Angeles County
                                                         Department of Public Social Services
                                                        LEADER Replacement System (LRS)


      LRS RFP - Attachment H (Technical Exhibits)   Page 25                  February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

554   SOA Architecture
557   SOA presents the big picture of what you can do with Web services. Web services
558   specifications define the details needed to implement services and interact with them. However,
559   SOA is an approach to build distributed systems that deliver application functionality as services
560   to end-user applications or to build other services. SOA can be based on Web services, but it
561   may use other technologies instead. In using SOA to design distributed applications, you can
562   expand the use of Web services from simple client-server models to systems of arbitrary
563   complexity.
565   Thus, individual software assets become the building blocks to develop other applications. You
566   can reduce the complexity of systems by using a common style of interaction that works with
567   both new and legacy code. There is a standard way of representing and interacting with these
568   software assets; now the focus shifts to application assembly based on these building blocks.

570   Web Services
571   Web services are a great example of how IT can better support business goals. One way is to
572   consolidate like business functionality which currently is spread across many applications into
573   shared services. This not only saves IT costs, but it makes it much easier to implement a
574   change to a business process. If the shared services are architected correctly, they can be
575   reused and repurposed to fit many business scenarios resulting in a much richer user
576   experience.
578   Web services are a core component of SOA. They are XML message-based, defined by
579   industry standards, and are supported by practically every vendor.
581   Please see Web Services White Paper for a detailed discussion of all the components that
582   make up Web services. Following, are some highlights.
583   Web Service Patterns
584   Shared business services are implemented as atomic, composite, federated, or orchestrated
585   Web services. Each of these patterns has a specific purpose and together, they provide a great
586   deal of service flexibility. Very simple to large, complex business processes can be
587   implemented using the above patterns. By definition, they are designed to be shared,
588   aggregated, and repurposed making it much easier and faster to implement business change.
590   Please see SOA Service Patterns White Paper for all the details.
592   Web Service Composition
593   The lowest level (and therefore, the most simple) Web services are called atomic. In order to
594   achieve maximum reuse, atomic Web services can be aggregated (composed) into larger,
595   broader-purposed services.
597   The capability to combine simpler services into larger more complex ones is a very powerful
598   concept.
      LRS RFP - Attachment H (Technical Exhibits)             Page 26                   February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

600   Web Service Orchestration
601   Atomic, composite, and federated Web services may all be developed using a specification
602   language such as Business Process Execution Language (BPEL) and executed by a workflow
603   engine (usually part of the SOA infrastructure). That is, individual Web services may be
604   executed in a certain order (orchestrated) to fulfill a specific business process.
606   Web Service Types
607   There are two basic types of Web services: SOAP and REST. Currently, SOAP is the more
608   common, but REST is rapidly gaining momentum.
610   SOAP is a standard that defines how XML messages are transmitted over specific protocols.
611   For example, SOAP over HTTP or SOAP over JMS (Java). SOAP acts like an envelope that
612   carries a variety of XML messages each with a particular purpose. For example, there are XML
613   messages (schemas) for handling security. SOAP messages can handle complex data objects,
614   such as customer, payment, or license details.
616   REST typically handles simpler XML messages and therefore, is more efficient because they
617   require little overhead. However, currently REST is limited to the HTTP protocol.
619   Web Service Standards
620   There are two main organizations that define Web service standards:
621   W3C - World Wide Web Consortium .
622   OASIS – Organization for the Advancement of Structured                     Information   Standards
623 .
625   There are many standards for the various parts of Web services. Please refer to the Web
626   Services White Paper for a fairly complete description of the standards as well as links to more
627   detailed information.

628   Enterprise Service Bus (ESB)
629   Connecting systems and automating business processes are strong drivers to reducing costs,
630   improving operational efficiency, and capturing new business opportunities. For these reasons,
631   technologies that facilitate integration are a high priority for many technology executives.
633   Some of the more popular approaches are ETL (Extract, Transform, and Load), Batch, FTP,
634   Information Brokers, and ESB. The latter has emerged as the preferred method to connect
635   Web services as well as provide interoperability among applications, mainframe, and third party
636   systems.
638   ESBs are based on lessons learned from integration brokers and best practices from standards-
639   based infrastructure based on XML, Web services, reliable asynchronous messaging, and
640   distributed components. These collectively form an architecture for a highly distributed, loosely
641   coupled integration fabric to deliver all the key features of an integration broker, but without the
642   barriers.
644   In simple terms, ESBs:
645          • Route messages between services.
646          • Convert transport protocols between requestor and service.
      LRS RFP - Attachment H (Technical Exhibits)              Page 27                    February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

647            • Transform message formats between requestor and service.
648            • Handle business events from disparate sources.
651   Some ESB vendors include additional features:
652         • Service composition
653         • Business process management

655   SOA Security
656   Because SOA is XML message-based, security in the SOA world is handled via specific
657   sections within an XML message. WS-Security from OASIS defines the mechanism for
658   including integrity, confidentiality, and single message authentication features within a SOAP
659   message. WS-Security makes use of the XML Signature and XML Encryption specifications and
660   defines how to include digital signatures, message digests, and encrypted data in a SOAP
661   message.
663   Identity and Authentication
664   Authentication means verifying the identity of a user. The Web service security standards allow
665   for the notion of identity authorities and trusted relationships. That is, an identity service can be
666   federated among departments; however there is only one authority for a given type of identity
667   (for example, a Citizen Authority which would be the single point of authenticating any citizen
668   performing an interaction requiring security). Other citizen-based applications would trust this
669   authentication and not re-authenticate as the user’s interactions invoke different applications.
671   SAML (Security Access Markup Language)
672   Security Assertion Markup Language (SAML) from OASIS provides a means for partner
673   applications to share user authentication and authorization information. This is essentially the
674   single sign-on (SSO) feature being offered by all major vendors in their e-commerce products.
675   In the absence of any standard protocol on sharing authentication information, vendors normally
676   use cookies in HTTP communication to implement SSO. With the advent of SAML, this same
677   data can be wrapped inside XML in a standard way, so that cookies are not needed and
678   interoperable SSO can be achieved.
680   SAML is an XML vocabulary that defines the syntax necessary to exchange identity information
681   between applications.
683   Security Standards
684   There are many Web service security standards. Please see the Security Standards for Web
685   Services section in the SOA Security White Paper for detailed descriptions.

687   Reference SOA Architecture
688   Establishing an Enterprise Reference Architecture is important for the big picture. SOA is a key
689   subset of the enterprise and it is sometimes not obvious where SOA fits into the enterprise.
690   That is, one can get lost in the many details and standards surrounding SOA. So, a Reference
691   SOA Architecture is provided (see following diagram).
      LRS RFP - Attachment H (Technical Exhibits)               Page 28                    February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

693   Note Web services can be either internal or external to an organization. Using services
694   developed and made public by other organizations is highly encouraged to reduce duplication of
695   resources.
697   From a security perspective, it is desirable to put as much in the Internal tier as possible. Only
698   components located in the DMZ are accessible via the Internet. The DMZ could be architected
699   to provide different levels of security based on profile group. Proxy services and security
700   policies could be applied at the Web server level.
702   Traditional API/Batch Based Services are contrasted to SOA Based Services. The traditional
703   environment reflects current ―stove-pipe‖ applications and their complex (and duplicative)
704   infrastructure. It is noted that these applications should have a retirement strategy which
705   includes migration details. In many cases, multiple phased projects will be required.

710   In the SOA Based Services perspective, Web applications manage user interactions, and they
711   invoke services that implement business processes. Web applications invoke Web service APIs

      LRS RFP - Attachment H (Technical Exhibits)             Page 29                   February 29, 2008
                                                                                      Los Angeles County
                                                                       Department of Public Social Services
                                                                      LEADER Replacement System (LRS)

712   via XML interfaces which are message based. A proxy mirrors the actual Web service interface.
713   Web services are defined in a Web Services Description Language (WSDL) document which
714   may be registered in a Universal Description Discovery and Integration (UDDI) repository (which
715   provides location services).
717   Services should be implemented in the Internal tier. The XML messages are processed by the
718   messaging infrastructure when the appropriate service is called by a business process. An
719   XML Firewall could be deployed to look inside SOAP messages and enforce the security
720   section of the message. Web services are implemented as a Business Component in a specific
721   language (.NET/C# or J2EE/Java). Access Services handle formatting and communications
722   among data sources including packaged applications, rules, report, and security servers.
724   This document does not address the complex issue of data management. This is a large topic
725   which needs proper attention to fully realize the potential of an SOA Based Services
726   environment.

728   California SOA Principles
731            1.   Design for Ease of Use: Make it easy for your business solution builders to
732            assemble services into applications and business scenarios. Organize the structure of
733            the California Enterprise Repository so it can be easily searched, learned, and managed.
734            Create a business architecture (categorize and classify business services) and show
735            clearly show how SOA services relate to the business architecture.
738            2. Design Web services with appropriate granularity. The granularity of
739            operations is an important design point. The use of coarse-grained interfaces for
740            external consumption is recommended, whereas fine-grained interfaces might be used
741            inside the enterprise. A coarse-grained interface might be the complete processing for a
742            given service, such as SubmitPurchaseOrder, where the message contains all of the
743            business information needed to define a purchase order. A fine-grained interface might
744            have separate operations for: CreateNewPurchaseOrder, SetShippingAddress, AddItem,
745            and so forth.
748            While the fine-grained interface offers more flexibility to the requester application, it also
749            means that patterns of interaction may vary between different service requesters. This
750            can make support more difficult for the service provider. A coarse-grained interface
751            guarantees that the service requesters will use the service in a consistent manner. SOA
752            does not require the use of coarse-grained interfaces, but recommends their use as a
753            best practice for external integration. Service choreography can be used to create a
754            coarse-grained interface that runs a business process consisting of fine-grained
755            operations.
757            Granularity can be viewed from several perspectives. One perspective is the amount of
758            data sent/received. A second perspective is complexity of the interface. A third
759            perspective is the number of interactions required to complete a session. An example
      LRS RFP - Attachment H (Technical Exhibits)                Page 30                     February 29, 2008
                                                                                      Los Angeles County
                                                                       Department of Public Social Services
                                                                      LEADER Replacement System (LRS)

760            might be a service that provides all registered voters in a county. Should it send one
761            huge list (one interaction, but a huge dataset); or send just the As then the Bs then the
762            Cs (26 interactions for consuming processes that do indeed need ALL names, but
763            smaller data sets); or one by one (eg by citizen; which could lead to thousands of
764            interactions, with very small data sets). The number of interactions required to complete
765            a "session" can also be driven by the number of steps in a composite operation, which is
766            the example used here.
768            Gardner recommends designing services to be as general-purpose as possible. Thus if
769            a large number of consumers would use an "all in one" SubmitPurchaseOrder, then
770            create it. But provide some "override" services so that consumers with specialized needs
771            can override the generic operation.
773            3. Reassemble before Rewrite. Individual Web services can be assembled into
774            composite Web services. Standard web interfaces can also be used to quickly create
775            new services. Consider reassembling existing base Web services before writing new
776            Web services. For example, Federated Jobs Service is a composite of Available Jobs
777            Service and Process Job Application Service.
780            4. Web Services should be loosely coupled and extensible. The binding from
781            the service requester to the service provider should loosely couple the service. This
782            means that the service requester has no knowledge of the technical details of the
783            provider’s implementation, such as the programming language, deployment platform,
784            and so forth. The service requester typically invokes operations by way of messages -- a
785            request message and the response -- rather than through the use of APIs or file formats.
788            ―Extensibility is essential to the rapid and efficient evolution of Web service interfaces. If
789            every enhancement of a provider interface requires the redeployment of a corresponding
790            consumer interface to the thousands of existing consumers, then change management
791            will grind to a halt. The key is to architect Web service interfaces using XML and XSD
792            (XML Schema Definition) extensibility mechanisms to enable both forward and backward
793            compatibility between consumer and provider interfaces to loosely couple consumer
794            versions from provider versions‖. – Gartner 2006
796            5. Web Services must have well-defined interfaces. The service interaction
797            must be well-defined. Web services Description Language (WSDL) is a widely-
798            supported way of describing the details required by a service requester for binding to a
799            service provider. The service descriptions focus on operations used to interact with the
800            following:
801                    a. A service
802                    b. Messages to invoke operations
803                    c. Details of constructing such messages
804                    d. Information on where to send messages for processing details of constructing
805                    such messages

      LRS RFP - Attachment H (Technical Exhibits)                Page 31                     February 29, 2008
                                                                                      Los Angeles County
                                                                       Department of Public Social Services
                                                                      LEADER Replacement System (LRS)

808            WSDL should not include any technology details of the implementation of a service. The
809            service requester neither knows nor cares whether the service is written in Java code,
810            C#, COBOL, or some other programming language. It can describe a SOAP invocation
811            using HTTP. Because of its extension mechanisms, it can also define other styles of
812            interaction such as XML content delivered via JMS, direct method calls, calls handled by
813            an adapter that manages legacy code (CICS), and so forth.
815            The common definition for WSDL allows development tools to create common interfaces
816            for various styles of interaction, while hiding the details of how it invokes the service from
817            the application code. The Web Services Invocation Framework (WSIF), for example,
818            exploits this capability by allowing a run-time determination of the best way to invoke a
819            quality service if the service is exposed in more than one interaction style. See
820   for WSIF details.
822            6. Design stateless base Web services. Services should be independent, self-
823            contained requests, which do not require information or state from one request to
824            another when implemented. Services should not be dependent on the context or state of
825            other services. When dependencies are required, they are best defined in terms of
826            common business processes, functions, and data models, not implementation artifacts
827            (like a session key). Of course, requester applications require persistent state between
828            service invocations, but this should be separate from the base service. Web
829            applications and composite Web services can both handle state.
832            7. Implement business processes via orchestrating Web services into a
833            process flow (BPEL standard). Some business processes can be implemented in a
834            process flow and called from an application (which implements the entire business
835            process). The individual nodes within the process flow can call other Web services, call
836            out to a business rules engine, or call a native API (such as Java or .NET). Process
837            flows also manage state, which means data created by one node is available to other
838            nodes to view, add to, or modify. Additionally, process flow engines (vendor specific)
839            have built in mechanisms to recover a process flow should a system or process failure
840            occur.
843            For example, a Professional License Application might call several Web service process
844            flows (Gather Qualifications, Process Qualifications, Handle Payment, and Create
845            License) to achieve the business process functionality.
847            8. A governance structure must be created to manage Web service
848            development and operational environments. By definition, Web services are
849            created with the enterprise in mind. That implies a strong collaboration environment
850            exists where interested parties agree on how Web services will be defined, built,
851            implemented, deployed, supported, enhanced, and managed in production environment.
852            Additional budgets, people, tools, and equipment resources must be allocated
853            appropriately.
856            9.   Implement Web service security and policy enforcement standards:
      LRS RFP - Attachment H (Technical Exhibits)                Page 32                     February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

857            Liberty Alliance and OASIS have defined a large number of Web service security
858            standards. Eventually, the work of both groups will probably be merged into a single set
859            of standards. WS-Security seems to be the most widely used while many other
860            standards within WS* are still evolving. However, this should not deter security
861            mechanisms from being designed into Web services.

863   California Service Centers
865   The ultimate vision is to consolidate business services provided to constituents into a collection
866   of federated service centers. SOA will play a key part in how these services are implemented.
867   Please see California Service Centers SOA White Paper , for complete details. Following is a
868   brief description of the key components.

869   Consolidated Service Centers
870   Clark Kelso, State CIO on 4/21/2006 authored Government Services on the Web: California In-
871   Touch . This document introduces the notion of providing a better customer experience at
872   reduced cost to the state via moving to consolidated service centers.
874   The new California Service Center (CSC) will lead the way to a more customer-friendly E-
875   government based on a services oriented (SOA) environment. From a strategic perspective,
876   the California Service Center will be the customer-facing site. It will intelligently redirect to the
877   appropriate service centers which will be working together in a federated manner.

878   Shared Services
879   Collectively, the service centers will leverage shared services, such as Identity, Search, Real
880   Simple Syndication (subscriptions, news), Address Verification, and a common Payment
881   engine to name a few. Shared services will be built in a federated manner but deployed and
882   operationally managed centrally. That is, many departments will contribute shared services but
883   they will be hosted in a small number of data centers.

884   SOA Infrastructure
885   Operationally, service centers will utilize an enterprise infrastructure approach. That is, they will
886   be deployed and managed in a small number of SOA-based data centers. Mission critical
887   services will be deployed in a redundant manner across data centers to minimize single point of
888   failures. This implies collaboration in the area of configuration and release management across
889   data centers to achieve a high degree of availability, scalability, and reliability.
891   An SOA infrastructure must support XML message processing and application integration. This
892   functionality is normally handled by an ESB.

      LRS RFP - Attachment H (Technical Exhibits)               Page 33                    February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

894   Enterprise Service Bus
895   Application integration and service interoperability are of paramount importance in a shared
896   services environment. Because applications are located on many different hardware and
897   software platforms, connecting these environments in a manner that meets availability,
898   scalability, and user performance expectations, uniform service interoperability platforms must
899   be carefully chosen.
901   These typically fall into two categories: For Windows-based platforms, Microsoft handles
902   standards-based messaging and application connectivity via incorporating Windows
903   Communication Framework functionality into an upcoming release called Windows Vista. In the
904   Java world, there are quite a few choices. Some of the more popular ones are IBM WebSphere
905   ESB, BEA AquaLogic Service Bus, Oracle Fusion, Cape Clear ESB, Sonic Software ESB, SAP
906   NetWeaver, and others.

908   California SOA Center of Excellence

910   Introduction
911   A successful state-wide SOA program will require both centralized and federated components.
912   Singular vision & goals, governance, enterprise repository management, and several
913   operational functions (certification lab, UDDI repository, maintain service reference model,
914   service help desk, and search taxonomy) should be centralized. Service development (and
915   possibly some SOA operations) should be federated to the producing departments. In some of
916   the above functions, centralized does not mean single instance. For example one would
917   establish at least two UDDI repositories for scalability and accessibility.
919   Because SOA components are designed for enterprise use, there are a number of critical
920   governance and operational issues that need to be addressed. Such as:
922          • How will developers be supported?
923          • How will business architects and technical architects determine which shared services
924          already exist?
925          • How will SOA services be mapped to business services?
926          • How will service versioning and release packaging be controlled?
927          • How will services be certified?
928          • How will services be tested for performance, availability, and scalability?
929          • How will services usage be monitored and reported?
930          • How will developers locate code for an existing service?
931          • How will service contract compliance among data centers be handled?
932          • Will there be a centralized, state-wide help desk?
933          • How will service troubleshooting be handled at an enterprise level?
934                   (A composite service might consist of 4 services, each running in a different data
935                   center.)
936       • Will there be example services and demo applications?
937       • Will there be a state-wide search service utilizing a common language? (a taxonomy)?
      LRS RFP - Attachment H (Technical Exhibits)             Page 34                   February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

939   It is obvious that there is a very important need for an oversight group to act as the center hub
940   for the enterprise. It is recommended that a California SOA Center of Excellence be established
941   to fulfill many of these tasks. This group would lead the SOA effort, be the ―go to‖ experts for
942   departmental business service implementers, facilitate discussion groups, lead collaboration
943   efforts, build a reference architecture based on best practices, and host demos. They could
944   also maintain a performance lab to ensure that critical services will meet performance and
945   availability expectations, manage a centralized help desk, handle compliance escalations via an
946   expert distributed architecture technical staff, and define a state-wide search taxonomy.
948   SOA leadership cannot be static. Rather, it should evolve as standards mature and change,
949   vendors products change based on market dynamics and changing standards, analysts revise
950   their best practices, and government politics and regulations change.
952   So the first set of responsibilities of the California SOA Center of Excellence is shown in the
953   following SOA Excellence diagram.


      LRS RFP - Attachment H (Technical Exhibits)            Page 35                    February 29, 2008
                                                                                      Los Angeles County
                                                                       Department of Public Social Services
                                                                      LEADER Replacement System (LRS)

 958   SOA Excellence Model
 960            1. Standards – SOA is comprised of many standards which are managed by several
 961            standard bodies. It will be very important to stay on top of standard developments since
 962            they will have a large impact on SOA architecture. Attending conferences, monitoring
 963            discussion groups, and regularly checking W2C, OASIS, and WS-I Websites are all key
 964            activities.
 967            2. Vendors & Analysts – Relationships with key vendors is important in order to keep
 968            abreast of product developments and vendor visions for SOA. Subscribing to industry
 969            analysts newsletters is also a good way of staying informed.
 972            3. State & Federal Collaboration – The Federal Enterprise Architecture Group and its
 973            ancillary operations set the standard for states to follow. Additionally, many states are in
 974            the process of implementing SOA-based models. So, ongoing collaboration with other
 975            states makes good sense.
 978            4. Operations Feedback – The SOA vision and goals must be practical. So, feedback
 979            from SOA operations must be factored into the vision and goals must be updated
 980            accordingly.
 983            5. Briefings & Targeted Presentations – SOA means different things to different people.
 984            So, preparing presentations that are targeted to a particular group will be most effective.
 985            For example, executives, business architects, technical architects, and IT developers all
 986            have different priorities within SOA. So, presenting SOA in terms of specific audience
 987            type would be most effective.
 990            1. Demos – An SOA Center of Excellence is a great place to demonstrate the SOA
 991            environment. Demos can be built to support the presentations targeted at specific
 992            audiences. Often, it is easier to understand a point by witnessing a demo. Plus, a demo
 993            proves out an environment and allows ―what if‖ scenarios.
 996            2. Reference Architecture – An SOA environment should exist as the model for
 997            developers. That is, a reference implementation that incorporates key SOA components
 998            would provide developers platform-specific components to measure their services
 999            against. The Reference Architecture would include both J2EE and .NET components.
1002            3. Executive SOA Discussion Group – Sponsoring an SOA discussion group for
1003            executives would be one way of providing executives with an easy mechanism for
1004            exchanging thoughts and ideas.

       LRS RFP - Attachment H (Technical Exhibits)               Page 36                    February 29, 2008
                                                                                   Los Angeles County
                                                                    Department of Public Social Services
                                                                   LEADER Replacement System (LRS)

1005   SOA Tools
1006   Development Tools
1007   A tool to model business services would be of great value. This could include business
1008   process details as well as expected performance metrics. If the tool has the capability
1009   to simulate different business scenarios, it would be of even more value.
1011   Equally important is a tool to model SOA services. Ideally, the output from the business
1012   modeling tool would seamlessly flow into the SOA services tool which, in turn could
1013   generate implementation code.

1014   Enterprise Repository
1015   A single, enterprise repository tool is needed to gather information about enterprise architecture
1016   models, department applications, shared service inventory and usage, as well as pointers to
1017   shared service code packages.            Therefore this repository should be purchased and
1018   implemented as a shared enterprise tool with the capability to establish different types of users,
1019   and appropriate levels of security.
1021   This repository should be configured to hold details of the Business Reference Models (BRM),
1022   Service Reference Models (SRM), Data Reference Models (DRM), and Technical Reference
1023   Models (TRM). For example, the Technical Reference Framework templates would be stored in
1024   this repository. As departments fill out the templates they could also be stored in the
1025   department section.

1026   Business Activity Monitoring (BAM)
1027   BAM enables organizations to leverage business analytics to gain a real-time insight into daily
1028   business operations. This analytical insight helps business users quickly identify operational
1029   inefficiencies and predict potential business problems. BAM integrates business intelligence
1030   (BI) with business transaction processing.
1032   BAM enables organizations to leverage business analytics to gain a real-time insight into daily
1033   business operations. This analytical insight helps business users quickly identify operational
1034   inefficiencies and predict potential business problems. BAM integrates business intelligence
1035   (BI) with business transaction processing.

1036   Appendices

1038   Appendix A - Federal SOA
1039   The Federal Architecture and Infrastructure Committee along with the Federal CIOs Council
1040   produced the Federal Enterprise Architecture which is based on SOA and Web Services.
1042   ―An architecture that provides for reuse of existing business services and rapid deployment of new
1043   business capabilities based on existing capital assets is often referred to as a service-oriented
1044   architecture (SOA). ― -- Federal CIOs Council

       LRS RFP - Attachment H (Technical Exhibits)             Page 37                   February 29, 2008
                                                                                         Los Angeles County
                                                                          Department of Public Social Services
                                                                         LEADER Replacement System (LRS)

1045   For a full description of the Federal Enterprise Architecture program, please see
1046                Component          Based         Architectures
1047   _2.0_FINAL.pdf
1049   For     a    broader    description   of        the     Federal     E-Gov      initiative    please       see
1050 .

1052   Appendix B - SOA Advantages (Patricia Seybold Group)
1053   Brenda M. Michelson, Sr. VP
1055   SOA Business Advantages:
1056        • Consistent Experience. An SOA can provide a consistent experience for customers
1057        and partners across channels and lines of business.
1060            • Business Agility. An SOA can add new functionality, expose functionality to new
1061            channels, and vary functionality based on context (customer, partner, entry point).
1064            • Mix and Match. An SOA can compose business solutions from a reusable service
1065            collection, leveraging internal and external services.
1068            • Optimize Interactions. An SOA can optimize business interactions for customers,
1069            partners, and internal constituents through the implementation of business scenarios
1070            (process, events, and services) versus traditional applications.
1073   SOA IT advantages:
1074         • Reduction of Costs. Reuse of services reduces IT development, deployment, and
1075         maintenance time and costs.
1078            • Leverage Existing IT Investments. Your service providers are existing code (objects,
1079            components, legacy modules, and application package APIs) and information assets
1080            (databases, files, and documents).
1083            • Transition Strategies. An SOA can provide application and portfolio transition
1084            strategies.

       LRS RFP - Attachment H (Technical Exhibits)                   Page 38                       February 29, 2008
                                                                                Los Angeles County
                                                                 Department of Public Social Services
                                                                LEADER Replacement System (LRS)

1087   Appendix C – WSDL Example

1092   This is an abridged version of the WSDL for Amazon’s E-commerce Service (ECS). The
1093   annotations
1094   on the left hand-side describe the WSDL sections. The yellow boxes within the WSDL highlight
1095   key elements, such as data elements, messages and bindings, and their recurrence in the
1096   various sections.
1097                                       - Patricia Seybold Group

       LRS RFP - Attachment H (Technical Exhibits)          Page 39                  February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)


1100   Appendix D – Legacy Integration Patterns
1101   Overview
1102   Mainframe applications will continue to be around for a long time and many departments
1103   depend on the mainframes for their mission critical applications. Therefore, the state must plan
1104   to integrate mainframe applications into the new SOA-based environment. Departments should
1105   take a close look at their application portfolios and devise an application maturity plan which
1106   would should separate them into categories such as don’t modify, wrap with Web service
1107   interfaces, reengineer into Java or .NET applications, or plan to retire. Following are brief
1108   discussion of three popular patterns.

1109   Integrating Existing Mainframe Apps - Unmodified
1110   There are several ESB products that have a broad range of application integration capability.
1111   IBM Websphere ESB, Oracle Fusion, Cape Clear ESB, plus a number of other companies have
1112   products in this area.      Enterprise Service Bus products not only provide messaging
1113   infrastructure for Web services, they also provide a variety of adapters and connectors to
1114   integrate native language interfaces (such as COBOL, CICS, MQ Series, Java, FTP, etc.).

       LRS RFP - Attachment H (Technical Exhibits)            Page 40                   February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

1119   IBM
1122   Oracle
1125   Sonic
1128   Cape Clear

       LRS RFP - Attachment H (Technical Exhibits)            Page 41                  February 29, 2008
                                                                                   Los Angeles County
                                                                    Department of Public Social Services
                                                                   LEADER Replacement System (LRS)

1131   Placing Web Service Interfaces on Existing Mainframe Apps
1132   Makes mainframe applications (particularly Natural and Adabas) look like Web services.
1133   EntireX executes on the mainframe and exposes the service interfaces. ApplinX solution
1134   requires no changes to mainframe code.
1136   SoftwareAG EntireX
1139   SoftwareAG ApplinX

1141   Compiling COBOL Code into Web Service Languages
1142   Fujitsu Consulting provides a COBOL compiler for a variety of platforms and languages. For
1143   example, NetCOBOL for .NET is a COBOL compiler created specifically for Microsoft's .Net
1144   Framework. This means that COBOL is just another .NET scripting language (like VB.NET, C#,
1145   J#, etc.). This allows COBOL code to be mixed with C# or VB.NET code. It compiles to
1146   Microsoft MSIL (language neutral, .NET runtime) code.
1148   NetCOBOL main page
1151   NetCOBOL for .NET

1154   Appendix E - Definitions
1156   AJAX: Asychronous JavaScripting and XML is a Web development technique for creating
1157   interactive Web pages. The intent is to make Web pages feel more responsive by exchanging
1158   small amounts of data with the server behind the scenes, so that the entire Web page does not
1159   have to be reloaded each time the user makes a change AJAX is available for Java, .NET,
1160   PHP, and other languages.
1162   Architecture: Representation of the structure of a system that describes the constituents of the
1163   system and how they interact with each other.
1164   Application Architecture: Representation of an application and its parts, their inter-
1165   relationships and functions.
1166   AVDL: Application Vulnerability Description Language.
1169   BPEL: Business Process Execution Language for Web Services provides a means to formally
1170   specify business processes and interaction protocols. BPEL provides a language for the formal
1171   specification of business processes and business interaction protocols. By doing so, it extends
1172   the Web Services interaction model and enables it to support business transactions. BPEL

       LRS RFP - Attachment H (Technical Exhibits)             Page 42                  February 29, 2008
                                                                                   Los Angeles County
                                                                    Department of Public Social Services
                                                                   LEADER Replacement System (LRS)

1173   defines an interoperable integration model that should facilitate the expansion of automated
1174   process integration in both the intra-corporate and the business-to-business spaces.
1176   Business Component: Represents the implementation of an autonomous business concept,
1177   business service, or business process. It consists of all the technology elements (i.e., software,
1178   hardware, data) necessary to express, implement, and deploy a given business concept as an
1179   autonomous, reusable element of a large information system. It is a unifying concept across the
1180   development lifecycle and the distribution tiers.
1181   Business (Domain) Component: Organizational unit that offers business services operation
1182   based on rules of that business.
1183   Business Component System: Set of cooperating business components assembled together
1184   to deliver a solution to a business problem.
1185   Business Logic Component: Software unit that offers small-grained business logic that has a
1186   large degree of reuse throughout the organization. Sub-components that manage and exe-cute
1187   the set of complex business rules that represent the core business activity supported by the
1188   component.
1189   CAP: Common Alerting Protocol.
1191   Component: Independently deployable unit of software that exposes its functionality through a
1192   set of services accessed via well-defined interfaces. A component is based on a component
1193   standard, is described by a specification, and has an implementation. Components can be
1194   assembled to create applications or larger-grained components.
1195   Component Architecture: Internal structure of a component described in terms of partitioning
1196   and relationships between individual internal units.
1197   Component-Based Architecture: Architecture process that enables the design of enterprise
1198   solutions using large service components. The focus of the architecture may be a specific
1199   project or the entire enterprise. This architecture provides a plan of what needs to be built and
1200   an over-view of what has been built already.
1201   Component Registry: Application designed to provide a directory of available components
1202   based on profile and or specification. Registries usually provide efficient mechanisms for
1203   searching for components in multiple ways, such as by service, price, and/or provider.
1204   Component Repository:         Application designed to store component specifications and
1205   implementations. Often provides facilities to efficiently search for and retrieve components for
1206   evaluation against desired component specifications though the search capabilities may be off-
1207   loaded to a component registry.
1208   CORBA: Common Object Request Broker Architecture, created by the Object Management
1209   Group ( ) vendor-independent architecture and infrastructure that computer
1210   applications use to work together over networks. Using the standard protocol IIOP, a CORBA-
1211   based program from any vendor, on almost any computer, operating system, programming
1212   language, and network, can interoperate with a CORBA-based program from the same or
1213   another vendor, on almost any other computer, operating system, programming language, and
1214   network.

       LRS RFP - Attachment H (Technical Exhibits)             Page 43                   February 29, 2008
                                                                                   Los Angeles County
                                                                    Department of Public Social Services
                                                                   LEADER Replacement System (LRS)

1215   COTS Components: Commercial Off the Shelf (COTS) components that can satisfy business
1216   process and data requirements for large functional domains or lines-of-business. Examples of
1217   COTS components would be Enterprise Resource Planning (ERP) products such as those as
1218   offered by commercial software companies.
1219   Data: Factual or numerical business information of record that is maintained by the service
1220   component. The encapsulated service component is fully responsible for maintaining this
1221   information.
1222   Data-Level Application Programming Interfaces: Services internal to the service component
1223   that support access to the data of record maintained within the service component. These ser-
1224   vices may span numerous distributed data sources.
1225   DCOM: Distributed Common Object Model is an extension of the Component Object Model
1226   (COM) that allows COM components to communicate across network boundaries. DCOM
1227   uses the RPC mechanism to transparently send and receive information between COM
1228   components. Microsoft first introduced it in 1995.
1229   DSML: Directory Services Markup Language.
1231   Distributed Component: Lowest level of component granularity. It is a software element that
1232   can be called at run-time with a clear interface and a clear separation between interface and
1233   implementation. It is autonomously deployable. A distributed component provides low ROI for
1234   capital planning purposes.
1235   E-Business Patterns: Patterns for e-business are a group of proven reusable assets that can
1236   be used to increase the speed of developing and deploying net-centric applications, like Web-
1237   based applications.
1238   ebXML: Electronic Business using eXtensible Markup Language.
1240   Encapsulation: Hiding implementation details within a component so that an implementation is
1241   not dependent on those details.
1242   Enterprise Architecture: Meta-architecture of an organization or the sum of all architectures
1243   within an organization.
1244   Enterprise Component: Large-granularity business component of an organization.
1245   Enterprise Service Bus (ESB): A class of integration software that is intended to support the
1246   deployment of Web services. An ESB combines messaging, basic transformation, and content-
1247   based routing. The inputs and outputs of an ESB are Service Data Objects (SDO).
1248   Extensibility: Ability to extend the capability of a component so that it handles additional needs
1249   of a particular implementation.
1250   Federated Business Component: Set of cooperating system-level components federated to
1251   resolve the business need of multiple end users often belonging to different organizations.
1252   California Enterprise Component: Very coarse-grained business component of California
1253   Government.
1254   Federation: is a collection of realms/domains that have established trust. The level of trust may
1255   vary, but typically includes authentication and may include authorization.

       LRS RFP - Attachment H (Technical Exhibits)             Page 44                   February 29, 2008
                                                                                     Los Angeles County
                                                                      Department of Public Social Services
                                                                     LEADER Replacement System (LRS)

1256   Fit-Gap Analysis: Examination of components within the context of requirements and to make
1257   a determination as to the suitability of the service component.
1258   Component Granularity: The size of the unit of component under consideration in some
1259   context. The term generally refers to the level of detail at which component is considered, e.g.
1260   "You can specify the granularity for this service component".
1261   Identity Mapping: is a method of creating relationships between identity properties. Some
1262   Identity Providers may make use of id mapping.
1263   Identity Provider: is an entity that acts as a peer entity authentication service to end users and
1264   data origin authentication service to service providers (this is typically an extension of a security
1265   token service).
1266   ID-FF: Liberty Identity Federation Framework. ID-FF contains the core specifications that allow
1267   for the creation of a standardized, multi-vendor, identity federation network. The FF consists of
1268   protocols, schema and profiles.
1270   ID-SIS: Liberty Identity Services Interface Specifications. ID-SIS uses the ID-WSF (new window)
1271   and ID-FF (new window) specifications to provide networked identity services, such as contacts,
1272   presence detection, or wallet services that depend on networked identity. The SIS contains two
1273   specifications: Personal Profile (ID-SIS-PP): and Employee Profile (ID-SIS-EP):
1274   ID-WSF: Liberty Identity Web Services Framework. ID-WSF provides a basic framework of
1275   identity services. Such services could be identity service discovery and invocation. The WSF
1276   consists of schema, protocols, and profiles.
1278   Infrastructure Component: Software unit that provides application functionality not related to
1279   business functionality, such as error/message handling, audit trails, or security.
1280   Interface: Mechanism by which a component describes what it does and provides access to its
1281   services. This is important because it represents the ―contract‖ between the supplier of services
1282   and the consumer of the services.
1283   Intellectual Property: A product of the intellect that has commercial value, including
1284   copyrighted property such as literary or artistic works, and ideational property, such as patents,
1285   appellations of origin, business methods, and industrial processes.
1286   Interface Profile: the sub-component that provides the ability to customize the component for
1287   various uses. The profile can be tailored to suit different deployment architectures well as
1288   different sets of business rules across enterprises. The interface profile can specify the business
1289   rules and workflow that are to be executed when the component is initialized. The profile can
1290   specify the architectural pattern that complements the service component.
1291   Java Server Faces: JavaServer Faces technology is a server-side user interface component
1292   framework for Java technology-based Web applications. JSF offers a clean separation between
1293   behavior and presentation.
1296   Language Class: Class in an object-oriented programming language to build distributed
1297   components. This is NOT considered an SRM component. A language class provides very low
1298   ROI for capital planning purposes.

       LRS RFP - Attachment H (Technical Exhibits)               Page 45                    February 29, 2008
                                                                                   Los Angeles County
                                                                    Department of Public Social Services
                                                                   LEADER Replacement System (LRS)

1300   Line of Business: A particular kind of commercial or government enterprise; e.g. "human re-
1301   sources" ―financial management‖ ―wholesale banking‖.
1302   Message Authentication: is the process of verifying that the message received is the same as
1303   the one sent.
1304   Messaging Interface: Linkage from the service component to various external software
1305   modules (component, external systems, gateways, etc.) and other service components.
1306   Notional Component: Set of services packaged into a component, derived from requirements
1307   definition. A ―desired‖ component, prior to implementation.
1308   Process Component: Software unit that implements the logic of a process.
1309   Realm or Domain: represents a single unit of security administration or trust.
1310   Reuse: Any use of a preexisting software artifact (component, specification, etc.) in a context
1311   different from that in which it was created.
1312   SAML: Security Assertion Markup Language.
1314   Security Token Service (STS): A security token service is a Web service that issues security
1315   tokens (see WS-Security and WS-Trust). That is, it makes assertions based on evidence that it
1316   trusts, to whoever trusts it. To communicate trust, a service requires proof, such as a security
1317   token or set of security tokens, and issues a security token with its own trust statement (note
1318   that for some security token formats this can just be a re-issuance or co-signature). This forms
1319   the basis of trust brokering.
1320   Sender Authentication: is corroborated authentication evidence possibly across Web service
1321   actors/roles indicating the sender of a Web service message (and its associated data). Note that
1322   it is possible that a message may have multiple senders if authenticated intermediaries exist.
1323   Also note that it is application-dependent (and out of scope) as to how it is determined who first
1324   created the messages as the message originator might be independent of, or hidden behind an
1325   authenticated sender.
1326   Service: Discrete unit of functionality that can be requested (provided a set of preconditions is
1327   met), performs one or more operations (typically applying business rules and accessing a data-
1328   base), and returns a set of results to the requester. Completion of a service always leaves
1329   business and data integrity intact.
1330   Service-Component: Modularized service-based applications that package and process
1331   together service interfaces with associated business logic into a single cohesive conceptual
1332   module. Aim of a service component is to raise the level of abstraction in software services by
1333   modularizing synthesized service functionality and by facilitating service reuse, service
1334   extension, specialization and service inheritance.
1335   Service-Component Reference Model (SRM): Service component-based framework that can
1336   provide—independent of business function—a ―leverage-able‖ foundation for reuse of
1337   applications, application capabilities, components, and business services.
1338   Service Data Object (SDO): An Enterprise Service Bus concept where all incoming messages
1339   are converted into service data objects.
1340   Service Interface: Set of published services that the component supports. These are aligned
1341   with the business services outlined in the service reference model.
       LRS RFP - Attachment H (Technical Exhibits)             Page 46                   February 29, 2008
                                                                                    Los Angeles County
                                                                     Department of Public Social Services
                                                                    LEADER Replacement System (LRS)

1342   Service-Level Agreement: A contract or memorandum of agreement between a service
1343   provider and a customer that specifies, usually in measurable terms, what services the service
1344   provider will furnish. Information technology departments in major enterprises have adopted the
1345   idea of writing a service level agreement so that services for their customers (users in other
1346   departments within the enterprise) can be measured, justified, and perhaps compared with
1347   those of external (sourcing) service providers.
1348   Service-Oriented Architecture: Architecture that provides for reuse of existing business
1349   services and rapid deployment of new business capabilities based on existing capital assets.
1350   Services Interface: A logical boundary that permits software services to be defined
1351   independent of the service implementation.
1352   SOAP: A simple XML based protocol to let applications exchange information over HTTP.
1353   SOAP is a protocol for accessing a Web Service. Note, SOAP originally stood for Simple
1354   Object Access Protocol, but this has been dropped.
1355   Single Sign On (SSO): is an optimization of the authentication sequence to remove the burden
1356   of repeating actions placed on the end user. To facilitate SSO, an element called an Identity
1357   Provider can act as a proxy on a user's behalf to provide evidence of authentication events to
1358   3rd parties requesting information about the user. These Identity Providers are trusted 3rd
1359   parties and need to be trusted both by the user (to maintain the user's identity information as the
1360   loss of this information can result in the compromise of the users identity) and the Web services
1361   which may grant access to valuable resources and information based upon the integrity of the
1362   identity information provided by the IP.
1363   SPML: Service Provisioning Markup Language.
1365   Solution Assembly: Process of implementing a solution by assembling the necessary
1366   components into a complete solution. This process often involves additional ―glue‖ code to
1367   integrate the assembled components.
1368   Test Harness: Software that automates the software engineering testing process to test the
1369   soft-ware as thoroughly as possible before using it on a real application. Trust Domain: an
1370   administered security space in which the source and target of a request can determine and
1371   agree whether particular sets of credentials from a source satisfy the relevant security policies
1372   of the target. The target may defer the trust decision to a third party thus including the trusted
1373   third party in the Trust Domain.
1375   UBL: Universal Business Language.
1378   UDDI: Universal Description Discovery Integration.
1380   Web Service: Functionality provided by a service, which is exposed using the Internet (SOAP,
1381   HTTP, WSDL, XML, TCP/IP) as the transport mechanism. Can be internally provided as part of
1382   a suite of services or can be offered by external organizations.
1383   Web Service for Remote Portlets: A user-facing Web Service that will provide content,
1384   marked for display, to a portal or other aggregating Web application. This moves Web Services
1385   out from the back-end model layer.

       LRS RFP - Attachment H (Technical Exhibits)              Page 47                   February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

1387   Web Service Flow: The process of combining and orchestrating Web services into a unique
1388   flow. Individual Web methods on multiple Web services can be invoked in a precise order that
1389   meets the specific application flow requirements.
1390   Workflow Manager: Sub-component that enables one component to access services on other
1391   components to complete its own processing. The workflow manager determines which external
1392   component services must be executed and manages the order of service execution.
1393   Wrapping: Creation of an interface around legacy functionality (code) that exposes the
1394   functionality as services via interfaces that conform to a component specification.
1395   WSDL: An XML format for describing network services as a set of endpoints operating
1396   on messages containing either document-oriented or procedure-oriented information.
1397   The operations and messages are described abstractly, and then bound to a concrete
1398   network protocol and message format to define an endpoint. Related concrete
1399   endpoints are combined into abstract endpoints (services).
1400   WSDM: Web Services Data Management.
1401   WSIF: The Web Services Invocation Framework (WSIF) is a simple Java API for invoking Web
1402   services, no matter how or where the services are provided. WSIF allows stubless or
1403   completely dynamic invocation of a Web service, based upon examination of the meta-data
1404   about the service at runtime.
1406   WS-Addressing: describes how to specify identification and addressing information for
1407   messages.
1408   WS-Authorization: will describe how to manage authorization data and authorization policies.
1409   WS-BusinessActivity: This specification provides the definition of the business activity
1410   coordination type that is to be used with the extensible coordination framework described in the
1411   WS-Coordination specification. The specification defines two specific agreement coordination
1412   protocols         for         the       business         activity        coordination      type:
1413   BusinessAgreementWithParticipantCompletion                                                  and
1414   BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these
1415   protocols when building applications that require consistent agreement on the outcome of long-
1416   running distributed activities.
1418   WS-Federation:      describes how to manage and broker the trust relationships in a
1419   heterogeneous federated environment, including support for federated identities, sharing of
1420   attributes, and management of pseudonyms.
1421   Web Services Inspection Language (WSIL): The WS-Inspection specification "defines how
1422   an application can discover an XML Web service description on a Web server, enabling
1423   developers to easily browse Web servers for XML Web services. WS-Inspection complements
1424   the IBM- and Microsoft-pioneered 'Universal Description, Discovery and Integration (UDDI)'
1425   global directory technology by facilitating the discovery of available services on Web sites
1426   unlisted in the UDDI registries, and builds on Microsoft's SOAP Discovery technology built into
1427   Visual Studio .NET.
1428   WS-MetadataExchange: describes how to exchange metadata such as WS-Policy information
1429   and WSDL between services and endpoints.
       LRS RFP - Attachment H (Technical Exhibits)            Page 48                   February 29, 2008
                                                                                       Los Angeles County
                                                                        Department of Public Social Services
                                                                       LEADER Replacement System (LRS)

1430   WS-Policy: represents a set of specifications that describe the capabilities and constraints of
1431   the security (and other business) policies on intermediaries and endpoints (e.g. required
1432   security tokens, supported encryption algorithms, privacy rules) and how to associate policies
1433   with services and endpoints.
1435   us/dnwssecur/html/securitywhitepaper.asp
1436   WS-Privacy: will describe a model for how Web services and requestors state privacy
1437   preferences and organizational privacy practice statements.
1439   us/dnwssecur/html/securitywhitepaper.asp
1440   WS-Referral: WS-Referral is a protocol that enables the routing strategies used by SOAP
1441   nodes in a message path to be dynamically configured. SOAP itself provides a distributed
1442   processing model where SOAP messages can have content destined for specific processing
1443   nodes. WS-Routing adds to SOAP the capability of describing the actual message path. WS-
1444   Referral provides a mechanism to dynamically configure SOAP nodes in a message path to
1445   define how they should handle a SOAP message. It is a configuration protocol that enables
1446   SOAP nodes to delegate part or all of their processing responsibility to other SOAP nodes.
1448   us/dnglobspec/html/wsreferspecindex.asp
1449   WS-Reliability: Web Services Reliability (WS-Reliability) is a SOAP-based protocol for exchanging
1450   SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message
1451   ordering. WS-Reliability is defined as SOAP header extensions, and is independent of
1452   the underlying protocol.
1454   WS-ReliableMessaging: this specification describes a protocol that allows messages to be
1455   delivered reliably between distributed applications in the presence of software component,
1456   system, or network failures. The protocol is described in this specification in an independent
1457   manner, allowing it to be implemented using different network transport technologies. To
1458   support interoperable Web services, a SOAP binding is defined within this specification.
1460   us/dnglobspec/html/wsrmspecindex.asp
1461   WS-Routing: WS-Routing is a simple, stateless, SOAP-based protocol for routing SOAP
1462   messages in an asynchronous manner over a variety of transports like TCP, UDP, and HTTP.
1463   With WS-Routing, the entire message path for a SOAP message (as well as its return path) can
1464   be described directly within the SOAP envelope.
1466   us/dnglobspec/html/wsroutspecindex.asp
1467   WSRP: Web Services for Remote Portlets.
1469   WS-SecureConversation: describes how to manage and authenticate message exchanges
1470   between parties, including security context exchanges and establishing and deriving session
1471   keys.
       LRS RFP - Attachment H (Technical Exhibits)                Page 49                     February 29, 2008
                                                                                  Los Angeles County
                                                                   Department of Public Social Services
                                                                  LEADER Replacement System (LRS)

1473   WS-Security: describes how to attach signature and encryption headers to SOAP messages. In
1474   addition, it describes how to attach security tokens, including binary security tokens such as
1475   X.509 certificates and Kerberos tickets, to messages.
1477   WS-Security SAML Token Profile:
1479   WS-Transactions and WS-Coordination: describes how to enable transacted operations as
1480   part of Web service message exchanges.
1481   WS-Trust: describes a framework for trust models that enables Web services to securely
1482   interoperate by requesting, issuing, and exchanging security tokens.
1484   XACML: Extensible Access Control Markup Language.

       LRS RFP - Attachment H (Technical Exhibits)            Page 50                   February 29, 2008

To top