Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment


    • LEADER REPLACEMENT SYSTEM 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 THIS DOCUMENT DOES NOT STAND ALONE AND MUST BE READ AND REVIEWED IN CONNECTION WITH ALL OTHER PARTS OF THIS RFP. 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 EXHIBIT 2 – COUNTY INFORMATION TECHNOLOGY (IT) STRATEGIES AND INITIATIVES ..........3 EXHIBIT 3 – COUNTY’S CHIEF INFORMATION OFFICE (CIO) GUIDING PRINCIPLES ...................9 EXHIBIT 4 – CALIFORNIA SERVICE-ORIENTED ARCHITECTURE (SOA) MASTER GUIDE..........16 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 2 1.1 LRS NETWORK TOPOLOGY 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). 7 Eastern Data Center COUNTY-specified User (LAnet/EN via VPN) Internet Users (General Public) Internet Users COUNTY-specified User Network (Applicants and Participants) (LAnet/EN via Access Local Office Sites) Point EAVEX-1 COUNTY Network Enterprise Network Access CONTRACTOR POP Point Supplied (LAnet/EN) Connections/ Circuits DOW EX-1 POP Central Print Facility & Backup Central Print Facility CONTRACTOR/ Internet Interface Systems Network Downey Data Center COUNTY.Systems RESPONSIBILITY) (LAnet/EN Based) GATEWAY (CONTRACTOR Existing LEADER System during Phase 1 Interface Systems (Design/Development/Implementation Phase) Primary Central Site & Project Office Backup Central Site COUNTY RESPONSIBILITY CONTRACTOR RESPONSIBILITY LRS RFP - Attachment H (Technical Exhibits) Page 1 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 8 1.2 GATEWAY RACK 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 19 20 2. Environmental Infrastructure 21 • Physical security 22 • HVAC 23 • Power (including redundant backup power) 24 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) 33 EXHIBIT 2 – COUNTY INFORMATION TECHNOLOGY (IT) 34 STRATEGIES AND INITIATIVES 35 36 Table 1: DPSS Business Goals 37 38 The IT strategies and initiatives for fiscal years 2006 through 2009 in support of the 39 DPSS business goals are as follows: TARGETED PROJECT TITLE SUMMARY OF PURPOSE COMPLETION DATE 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 documentation. 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 System 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. System LRS RFP - Attachment H (Technical Exhibits) Page 3 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) TARGETED PROJECT TITLE SUMMARY OF PURPOSE COMPLETION DATE 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 Payments 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. IEVS 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. Procurement 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. Participants LRS RFP - Attachment H (Technical Exhibits) Page 4 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) TARGETED PROJECT TITLE SUMMARY OF PURPOSE COMPLETION DATE 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 assurance. 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 reports. 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 depreciated. 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 Medi-Cal. 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) TARGETED PROJECT TITLE SUMMARY OF PURPOSE COMPLETION DATE 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 warranty. 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. Application Pentium III Desktop To purchase 250 Workstations for use while broken 06/30/2007 Lifestyle equipment is being repaired or replaced. 40 41 42 Table 2: DCFS Business Goals 43 44 The IT strategies and initiatives for fiscal years 2007 through 2009 in support of the 45 DCFS business goals are as follows: 46 TARGETED PROJECT TITLE SUMMARY OF PURPOSE COMPLETION DATE 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 applications. 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). Project 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) TARGETED PROJECT TITLE SUMMARY OF PURPOSE COMPLETION DATE 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 encryption. 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 homes. 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) TARGETED PROJECT TITLE SUMMARY OF PURPOSE COMPLETION DATE 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 software. 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) 47 EXHIBIT 3 – COUNTY’S CHIEF INFORMATION OFFICE (CIO) GUIDING 48 PRINCIPLES 49 50 LOS ANGELES COUNTY 51 CHIEF INFORMATION OFFICE 52 53 Guiding Principles for Systems Acquisition and Development 54 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. 65 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. 72 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. 77 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. 81 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. 90 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. 100 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. 107 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. 115 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. 125 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. 132 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 152 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. 159 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. 165 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. 175 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. 183 184 • Application and/or Network Security. The County requires that all 185 applications conform to the Information Security Strategic Plan: 186 http://lacounty.info/omd/q1_2007/cms1_055410.pdf. 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: ABrusewitz@cio.lacounty.gov. 192 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. 197 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. 203 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. 209 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. 216 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.). 223 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. 228 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. 233 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. 239 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. 244 245 • Database Communication. All direct database communication shall utilize 246 ODBC, JDBC, ADO/OLEDB, or ADO.NET. 247 248 • Geographic Information Systems. Environmental Systems Research 249 Institute (ESRI) ArcGIS tools for Geographic Information Systems (GIS) and 250 mapping applications may be used. 251 252 • Storage. EMC, HP, and Network Appliance storage products may be used. 253 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). 259 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. 263 264 3. Preferred Enterprise IT Standards and Recommendations 265 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) 268 Preferred Enterprise IT Standards and Function Recommendations (Current Version) Operating Systems Client operating system Microsoft Windows Department Server operating Microsoft Windows Server system Enterprise/Mid-Range HP- UNIX, AIX, Linux Networks Wide Area Network (WAN) Los Angeles County Enterprise Network (LAnet/EN) Local Area Network (LAN) Microsoft Windows WAN/LAN Infrastructure Cisco and TCP/IP Wireless LAN IEEE 802.11 Security Antivirus Symantec, Network Associates (McAfee) Patch Management PatchLink and Altiris Anti-spam BrightMail Firewall Cisco PIX Firewalls Network Intrusion Cisco Network Intrusion Detection/Prevention 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 Management 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 Function 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 encryption 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 Applications 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) 269 EXHIBIT 4 – CALIFORNIA SERVICE-ORIENTED ARCHITECTURE 270 (SOA) MASTER GUIDE 271 272 273 California Enterprise Architecture 274 Program 275 276 277 278 279 280 Service-Oriented 281 Architecture (SOA) 282 283 Master Guide 284 285 286 287 Revision History 288 06/30/2006 Original Draft 289 09/11/2006 Appendix D – Legacy Integration Patterns, enhanced ESB section. LRS RFP - Attachment H (Technical Exhibits) Page 16 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 290 Table of Contents 291 SOA Documents ................................................................................................19 292 The Business Case for SOA Overview ............................................................20 293 A Business-Oriented Foundation for Services ......................................21 294 SOA and Gartner “Hype Cycle” .............................................................. 22 295 SOA Introduction...............................................................................................23 296 The Accidental Architecture.....................................................................23 297 SOA ............................................................................................................23 298 Loosely Coupled Interfaces .....................................................................24 299 SOA Architecture ..............................................................................................26 300 Web Services.............................................................................................26 301 Web Service Patterns ..........................................................................26 302 Web Service Composition...................................................................26 303 Web Service Orchestration .................................................................27 304 Web Service Types ..............................................................................27 305 Web Service Standards .......................................................................27 306 Enterprise Service Bus (ESB) ..........................................................................27 307 SOA Security .............................................................................................28 308 Identity and Authentication.................................................................28 309 SAML (Security Access Markup Language) ......................................28 310 Security Standards ..............................................................................28 311 Reference SOA Architecture ............................................................................28 312 California SOA Principles.................................................................................30 313 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) 314 Consolidated Service Centers .................................................................33 315 Shared Services ........................................................................................33 316 SOA Infrastructure ....................................................................................34 317 Enterprise Service Bus .............................................................................34 318 California SOA Center of Excellence...............................................................34 319 Introduction ...............................................................................................34 320 SOA Excellence Model..............................................................................36 321 SOA Tools..........................................................................................................37 322 Development Tools ...................................................................................37 323 Enterprise Repository...............................................................................37 324 Business Activity Monitoring (BAM) .......................................................37 325 Appendices........................................................................................................37 326 Appendix A - Federal SOA........................................................................37 327 Appendix B - SOA Advantages (Patricia Seybold Group) .....................38 328 Appendix C – WSDL Example ..................................................................39 329 Appendix D – Legacy Integration Patterns .............................................40 330 Overview...............................................................................................40 331 Integrating Existing Mainframe Apps - Unmodified..........................40 332 Placing Web Service Interfaces on Existing Mainframe Apps .........42 333 Compiling COBOL Code into Web Service Languages....................42 334 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) 335 SOA Documents 336 337 The service oriented architecture advocated by the California Enterprise Architecture Program is 338 organized into a set of interrelated documents. A master guide serves as the “jumping off point” 339 and describes in an overview fashion the key parts of SOA. 340 341 342 343 344 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) 345 The Business Case for SOA 346 347 Overview 348 “It’s not the strongest of the species that survive, or the most intelligent, but the ones most 349 responsive to change”. Charles Darwin 350 351 A service-oriented architecture (SOA) is a good choice for handling the “how” of business 352 services. That is, once business services are appropriately defined, they can be implemented in 353 SOA. This strongly implies that business services must first be defined and categorized which 354 means a different way of thinking about how we deliver services to constituents. Instead of 355 looking at “the business” from an isolated set of requirements and applications perspective, we 356 need to look across individual applications and determine our true business architecture. 357 358 What are the capabilities for a particular business, how are the capabilities related, and what are 359 the implications for connecting capabilities? Once business services are understood, we can 360 look for candidates for shared services. Business services can also be grouped into “service 361 centers”; for example, Health Service Center, Taxes Services Center, or a License Service 362 Center. Shared IT services reduce costs by getting rid of duplication and they also promote 363 consistency. 364 365 Many business services have multi-level government scope that may span Federal, state, 366 county, and local levels. So interoperability becomes very important. With a variety of 367 government entities involved, standards-based applications are a must. 368 369 Here is a summary of some of the business benefits of SOA: 370 371 • Increases Business Agility - SOA can enhance the ability of a business to react to 372 new regulations, policies, or opportunities and deliver innovative services to citizens and 373 businesses in a timely manner. This is possible because an SOA-enabled environment 374 is standards-based, platform neutral, and eventually, a good portion of the new 375 requirements can be met using existing shared services or aggregating existing services 376 to form a new one. 377 378 379 SOA opens the door for business and IT to engage in a much richer dialogue. By 380 focusing on what the business wants (not how it work gets done), specific parts of a 381 given business process can be delegated to different parts of the organization as well as 382 external partners. 383 384 • Reducing Business Risk and Exposure – Regulatory compliance is essentially a 385 business agility issue since legislation changes on a regular basis. Increased business 386 services flexibility in the face of changing laws and regulations is a concrete instance of 387 the business agility benefit of SOA. Specifically, SOA primarily offers a risk-reduction 388 capacity to public sector entities looking for increased operations flexibility. 389 390 LRS RFP - Attachment H (Technical Exhibits) Page 20 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 391 Improved governance, compliance, and general risk reduction is a different quantifiable 392 benefit than increased business agility. Compliance and governance offers a reduction 393 of liability, while business agility offers an increase in business opportunity. 394 Implementing SOA for the purpose of improving business processes, establishing state- 395 wide security, privacy, and implementation policies, and providing auditable information 396 trails, are ways that SOA can reduce several of the risks facing departments today. 397 398 • Increases Asset Reuse – One of the most important benefits of SOA is that users can 399 create new business processes and composite applications from existing services. In 400 other words, service reuse becomes the mode of operation instead of application 401 integration. Over time, as the state builds and reuses services, the ROI will increase. 402 403 404 • Encourages Effective Collaboration – SOA promotes sharing of ideas, business 405 services, solutions, best practices, frameworks, and tools across departments and 406 agencies. This results in lower overall costs, greater ROI for a given service, and a 407 higher degree of consistency from the user’s perspective. 408 409 410 • Reduces Integration Expenses – SOA provides an opportunity to migrate away from 411 monolithic, hard to change heavy business applications to light weight, loosely-coupled 412 business services. Loosely-coupled systems can reduce the complexity and hence the 413 cost of integrating and maintaining distributed computing environments. While moving to 414 standards-based interfaces such as Web Services reduces integration and cost 415 somewhat, the real win with SOA is in replacing multiple fine-grained functions with 416 coarse-grained, loosely coupled services that can handle a wider range of business 417 interactions in a more flexible manner. This results in less maintenance and upgrade 418 headaches, fewer customer complaints, and more secure systems. 419 420 421 • Reuse of Legacy Systems – By Web service enabling legacy systems, departments 422 can extend the life of and continue to take advantage of their mainframe investments 423 while allowing legacy applications to participate in a services environment. This is a key 424 strategy in moving from a predominately legacy applications environment to an SOA- 425 enabled shared services environment. 426 427 428 A Business-Oriented Foundation for Services 429 The following article is a good description of how business and IT can become closer aligned. It 430 advocates that a business architecture is necessary to describe the business capabilities which 431 define “what” a business does, and SOA is a good mechanism for handling “how” the 432 capabilities are implemented. 433 434 http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en- 435 us/dnbda/html/ServOrient.asp . 436 Ulrich Homann - Microsoft Corporation, February 2006. 437 LRS RFP - Attachment H (Technical Exhibits) Page 21 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 438 SOA and Gartner “Hype Cycle” 439 Gartner produces “hype cycle” diagrams for a variety of topics. They are intended to show 440 where a given item fits within a maturity curve. They contrast the visibility of an item with a pre- 441 defined set of maturity points identified as Technology Trigger, Peak of Inflated Expectations, 442 Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity which represent 443 the beginning and ending of the maturity curve. 444 445 Following, is the Gartner “Hype Cycle for Government, 2005”. It depicts SOA in the “Trough of 446 Disillusionment” meaning many public sector entities are in the process of figuring out how to 447 capitalize on the benefits of SOA. In contrast, many private industry companies would position 448 SOA in the “Slope of Enlightenment” phase. For example, see The Hartford: Lessons From 3 449 Years of Work On SOA . 450 451 452 LRS RFP - Attachment H (Technical Exhibits) Page 22 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 453 SOA Introduction 454 455 The Accidental Architecture 456 Over the past two decades, numerous distributed computing models arrived on the scene, 457 including DCE, CORBA, DCOM, MM, EAI brokers, J2EE, .NET, and Web services. However, 458 indications are that only a small percentage of enterprise applications are connected, regardless 459 of the technology being used. According to a research report from Gartner Inc. ("Integration 460 Brokers, Application Servers and APSs" 10/2002), number less than 10%. 461 462 Another surprising statistic - of the applications that are connected, only 15% are using formal 463 integration middleware. The rest are using the ETL and batch file transfer techniques, which 464 are largely based on hand-coded scripting and other custom solutions. 465 466 The Gartner statistics provide sobering data points that illustrates the true state of integration 467 today. How are the other 85% of applications connected? A very common situation that exists 468 in enterprises today is referred to as "the accidental architecture." 469 470 The accidental architecture is something that nobody sets out to create; instead, it's the result of 471 years of accumulating one-of-a-kind pointed integration solutions. In an accidental architecture, 472 corporate or organizational applications are perpetually locked into an inflexible integration 473 infrastructure. They continue to be treated as "silos" of information because the integration 474 infrastructure can't adapt to new business requirements. 475 476 Most integration attempts start out with a deliberate design, but over time, other pieces are 477 bolted on and "integrated," and the handcrafted integration code drifts away from the original 478 intent. Through incremental patches and bolt-ons, integrated systems can lose their design 479 integrity, especially if the system is maintained by a large number of people to whom the original 480 design intent may not have been well communicated. It's a fact that individual point-to-point 481 integrations will drift away from consistency, as engineers make "just this one little change" 482 that's expedient at the time. Eventually, it becomes difficult to even identify the points for 483 making changes, and to understand what the side effects would be as a result. In a deployed 484 system this can lead to disastrous results that will negatively affect your business. 485 486 Above excerpts from – David A. Chappell (Sonic Software) “Enterprise Service Bus” 2004 487 SOA 488 SOA has become a well-known but somewhat elusive acronym. Some describe SOA as an IT 489 infrastructure for business enablement while others look to SOA for increasing the efficiency of 490 IT. 491 492 Gartner defines SOA as “an architectural style in which certain discrete functions are packaged 493 into modular, shareable, distributable elements ("services"), which can be invoked by 494 consumers in a loosely coupled manner”. With SOA, integration becomes forethought rather 495 than afterthought—the end solution is likely to be composed of services developed in different 496 programming languages, hosted on disparate platforms with a variety of security models and 497 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) 498 argue that SOA evolved out of the experiences associated with designing and developing 499 distributed systems based on previously available technologies. 500 501 The acronym SOA prompts an obvious question—what, exactly, is a service? Simply put, a 502 service is a program that can be interacted with through well-defined message exchanges. 503 Services must be designed for both availability and stability. Services are built to last while 504 service configurations and aggregations are built for change. Agility is often promoted as one of 505 the biggest benefits of SOA—an organization with business processes implemented on a 506 loosely-coupled infrastructure is much more open to change than an organization constrained 507 by underlying monolithic applications that require weeks to implement the smallest change. 508 Loosely-coupled processes and loosely-coupled information structures result in loosely-coupled 509 systems. 510 511 Services and their associated interfaces are designed to be re-configured or re-aggregated to 512 meet the ever-changing needs of business. Services remain stable by relying upon standards- 513 based interfaces and well-defined messages—in other words, SOAP and XML schemas for 514 message definition. Services designed to perform simple, granular functions with limited 515 knowledge of how messages are passed to or retrieved from them are much more likely to be 516 reused within a larger SOA infrastructure. 517 518 SOA and Web Services have recently been used interchangeably. That is because most of the 519 SOA standards work has focused on Web services. New standards are emerging and new 520 vendor products are now available that focus on Enterprise Service Bus concepts. For 521 example, major technology companies are currently working on Service Data Objects. SDOs 522 will enable uniform access to application data and a common programming model for all data 523 sources, wherever and however the data is stored. SDOs leverage the simplicity of XML 524 without introducing the complexity of XML Schema or the performance issues of serialization. 525 Using SDOs and SOA together, systems programming tasks are separated from the business 526 logic and encapsulated in reusable services. They simplify business application programming 527 without getting pulled into technology or implementation details. 528 Loosely Coupled Interfaces 529 Most current applications interact via tightly coupled interfaces. This requires the calling 530 application to know language specific and datatype details of the target application (for example, 531 Java API). This makes maintenance more difficult and the notion of shared services built on 532 tightly coupled interfaces very difficult. 533 534 Loosely coupled interfaces use industry standard XML messages to communicate. This 535 process uses a messaging broker (or backbone) to handle the delivery details. This is often 536 referred to as an Enterprise Service Bus. 537 538 SOA Web services are based on loosely coupled interfaces. XML messaging is the core of 539 Web services. There are many WS* standards that define the different types of XML content. 540 541 The above paragraphs address loose coupling from a technical perspective. It should be noted 542 that business processes and information can (and usually are) designed for only a limited set of 543 consuming applications. Thus, they are tightly-coupled limiting their usefulness. 544 LRS RFP - Attachment H (Technical Exhibits) Page 24 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 545 546 547 LRS RFP - Attachment H (Technical Exhibits) Page 25 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 548 SOA Architecture 549 550 551 SOA presents the big picture of what you can do with Web services. Web services 552 specifications define the details needed to implement services and interact with them. However, 553 SOA is an approach to build distributed systems that deliver application functionality as services 554 to end-user applications or to build other services. SOA can be based on Web services, but it 555 may use other technologies instead. In using SOA to design distributed applications, you can 556 expand the use of Web services from simple client-server models to systems of arbitrary 557 complexity. 558 559 Thus, individual software assets become the building blocks to develop other applications. You 560 can reduce the complexity of systems by using a common style of interaction that works with 561 both new and legacy code. There is a standard way of representing and interacting with these 562 software assets; now the focus shifts to application assembly based on these building blocks. 563 564 Web Services 565 Web services are a great example of how IT can better support business goals. One way is to 566 consolidate like business functionality which currently is spread across many applications into 567 shared services. This not only saves IT costs, but it makes it much easier to implement a 568 change to a business process. If the shared services are architected correctly, they can be 569 reused and repurposed to fit many business scenarios resulting in a much richer user 570 experience. 571 572 Web services are a core component of SOA. They are XML message-based, defined by 573 industry standards, and are supported by practically every vendor. 574 575 Please see Web Services White Paper for a detailed discussion of all the components that 576 make up Web services. Following, are some highlights. 577 Web Service Patterns 578 Shared business services are implemented as atomic, composite, federated, or orchestrated 579 Web services. Each of these patterns has a specific purpose and together, they provide a great 580 deal of service flexibility. Very simple to large, complex business processes can be 581 implemented using the above patterns. By definition, they are designed to be shared, 582 aggregated, and repurposed making it much easier and faster to implement business change. 583 584 Please see SOA Service Patterns White Paper for all the details. 585 586 Web Service Composition 587 The lowest level (and therefore, the most simple) Web services are called atomic. In order to 588 achieve maximum reuse, atomic Web services can be aggregated (composed) into larger, 589 broader-purposed services. 590 591 The capability to combine simpler services into larger more complex ones is a very powerful 592 concept. 593 LRS RFP - Attachment H (Technical Exhibits) Page 26 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 594 Web Service Orchestration 595 Atomic, composite, and federated Web services may all be developed using a specification 596 language such as Business Process Execution Language (BPEL) and executed by a workflow 597 engine (usually part of the SOA infrastructure). That is, individual Web services may be 598 executed in a certain order (orchestrated) to fulfill a specific business process. 599 600 Web Service Types 601 There are two basic types of Web services: SOAP and REST. Currently, SOAP is the more 602 common, but REST is rapidly gaining momentum. 603 604 SOAP is a standard that defines how XML messages are transmitted over specific protocols. 605 For example, SOAP over HTTP or SOAP over JMS (Java). SOAP acts like an envelope that 606 carries a variety of XML messages each with a particular purpose. For example, there are XML 607 messages (schemas) for handling security. SOAP messages can handle complex data objects, 608 such as customer, payment, or license details. 609 610 REST typically handles simpler XML messages and therefore, is more efficient because they 611 require little overhead. However, currently REST is limited to the HTTP protocol. 612 613 Web Service Standards 614 There are two main organizations that define Web service standards: 615 W3C - World Wide Web Consortium http://www.w3.org/ . 616 OASIS – Organization for the Advancement of Structured Information Standards 617 http://www.oasis-open.org/home/index.php . 618 619 There are many standards for the various parts of Web services. Please refer to the Web 620 Services White Paper for a fairly complete description of the standards as well as links to more 621 detailed information. 622 Enterprise Service Bus (ESB) 623 Connecting systems and automating business processes are strong drivers to reducing costs, 624 improving operational efficiency, and capturing new business opportunities. For these reasons, 625 technologies that facilitate integration are a high priority for many technology executives. 626 627 Some of the more popular approaches are ETL (Extract, Transform, and Load), Batch, FTP, 628 Information Brokers, and ESB. The latter has emerged as the preferred method to connect 629 Web services as well as provide interoperability among applications, mainframe, and third party 630 systems. 631 632 ESBs are based on lessons learned from integration brokers and best practices from standards- 633 based infrastructure based on XML, Web services, reliable asynchronous messaging, and 634 distributed components. These collectively form an architecture for a highly distributed, loosely 635 coupled integration fabric to deliver all the key features of an integration broker, but without the 636 barriers. 637 638 In simple terms, ESBs: 639 • Route messages between services. 640 • 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) 641 • Transform message formats between requestor and service. 642 • Handle business events from disparate sources. 643 644 645 Some ESB vendors include additional features: 646 • Service composition 647 • Business process management 648 649 SOA Security 650 Because SOA is XML message-based, security in the SOA world is handled via specific 651 sections within an XML message. WS-Security from OASIS defines the mechanism for 652 including integrity, confidentiality, and single message authentication features within a SOAP 653 message. WS-Security makes use of the XML Signature and XML Encryption specifications and 654 defines how to include digital signatures, message digests, and encrypted data in a SOAP 655 message. 656 657 Identity and Authentication 658 Authentication means verifying the identity of a user. The Web service security standards allow 659 for the notion of identity authorities and trusted relationships. That is, an identity service can be 660 federated among departments; however there is only one authority for a given type of identity 661 (for example, a Citizen Authority which would be the single point of authenticating any citizen 662 performing an interaction requiring security). Other citizen-based applications would trust this 663 authentication and not re-authenticate as the user’s interactions invoke different applications. 664 665 SAML (Security Access Markup Language) 666 Security Assertion Markup Language (SAML) from OASIS provides a means for partner 667 applications to share user authentication and authorization information. This is essentially the 668 single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. 669 In the absence of any standard protocol on sharing authentication information, vendors normally 670 use cookies in HTTP communication to implement SSO. With the advent of SAML, this same 671 data can be wrapped inside XML in a standard way, so that cookies are not needed and 672 interoperable SSO can be achieved. 673 674 SAML is an XML vocabulary that defines the syntax necessary to exchange identity information 675 between applications. 676 677 Security Standards 678 There are many Web service security standards. Please see the Security Standards for Web 679 Services section in the SOA Security White Paper for detailed descriptions. 680 681 Reference SOA Architecture 682 Establishing an Enterprise Reference Architecture is important for the big picture. SOA is a key 683 subset of the enterprise and it is sometimes not obvious where SOA fits into the enterprise. 684 That is, one can get lost in the many details and standards surrounding SOA. So, a Reference 685 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) 686 687 Note Web services can be either internal or external to an organization. Using services 688 developed and made public by other organizations is highly encouraged to reduce duplication of 689 resources. 690 691 From a security perspective, it is desirable to put as much in the Internal tier as possible. Only 692 components located in the DMZ are accessible via the Internet. The DMZ could be architected 693 to provide different levels of security based on profile group. Proxy services and security 694 policies could be applied at the Web server level. 695 696 Traditional API/Batch Based Services are contrasted to SOA Based Services. The traditional 697 environment reflects current “stove-pipe” applications and their complex (and duplicative) 698 infrastructure. It is noted that these applications should have a retirement strategy which 699 includes migration details. In many cases, multiple phased projects will be required. 700 701 702 703 704 In the SOA Based Services perspective, Web applications manage user interactions, and they 705 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) 706 via XML interfaces which are message based. A proxy mirrors the actual Web service interface. 707 Web services are defined in a Web Services Description Language (WSDL) document which 708 may be registered in a Universal Description Discovery and Integration (UDDI) repository (which 709 provides location services). 710 711 Services should be implemented in the Internal tier. The XML messages are processed by the 712 messaging infrastructure when the appropriate service is called by a business process. An 713 XML Firewall could be deployed to look inside SOAP messages and enforce the security 714 section of the message. Web services are implemented as a Business Component in a specific 715 language (.NET/C# or J2EE/Java). Access Services handle formatting and communications 716 among data sources including packaged applications, rules, report, and security servers. 717 718 This document does not address the complex issue of data management. This is a large topic 719 which needs proper attention to fully realize the potential of an SOA Based Services 720 environment. 721 722 California SOA Principles 723 724 725 1. Design for Ease of Use: Make it easy for your business solution builders to 726 assemble services into applications and business scenarios. Organize the structure of 727 the California Enterprise Repository so it can be easily searched, learned, and managed. 728 Create a business architecture (categorize and classify business services) and show 729 clearly show how SOA services relate to the business architecture. 730 731 732 2. Design Web services with appropriate granularity. The granularity of 733 operations is an important design point. The use of coarse-grained interfaces for 734 external consumption is recommended, whereas fine-grained interfaces might be used 735 inside the enterprise. A coarse-grained interface might be the complete processing for a 736 given service, such as SubmitPurchaseOrder, where the message contains all of the 737 business information needed to define a purchase order. A fine-grained interface might 738 have separate operations for: CreateNewPurchaseOrder, SetShippingAddress, AddItem, 739 and so forth. 740 741 742 While the fine-grained interface offers more flexibility to the requester application, it also 743 means that patterns of interaction may vary between different service requesters. This 744 can make support more difficult for the service provider. A coarse-grained interface 745 guarantees that the service requesters will use the service in a consistent manner. SOA 746 does not require the use of coarse-grained interfaces, but recommends their use as a 747 best practice for external integration. Service choreography can be used to create a 748 coarse-grained interface that runs a business process consisting of fine-grained 749 operations. 750 751 Granularity can be viewed from several perspectives. One perspective is the amount of 752 data sent/received. A second perspective is complexity of the interface. A third 753 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) 754 might be a service that provides all registered voters in a county. Should it send one 755 huge list (one interaction, but a huge dataset); or send just the As then the Bs then the 756 Cs (26 interactions for consuming processes that do indeed need ALL names, but 757 smaller data sets); or one by one (eg by citizen; which could lead to thousands of 758 interactions, with very small data sets). The number of interactions required to complete 759 a "session" can also be driven by the number of steps in a composite operation, which is 760 the example used here. 761 762 Gardner recommends designing services to be as general-purpose as possible. Thus if 763 a large number of consumers would use an "all in one" SubmitPurchaseOrder, then 764 create it. But provide some "override" services so that consumers with specialized needs 765 can override the generic operation. 766 767 3. Reassemble before Rewrite. Individual Web services can be assembled into 768 composite Web services. Standard web interfaces can also be used to quickly create 769 new services. Consider reassembling existing base Web services before writing new 770 Web services. For example, Federated Jobs Service is a composite of Available Jobs 771 Service and Process Job Application Service. 772 773 774 4. Web Services should be loosely coupled and extensible. The binding from 775 the service requester to the service provider should loosely couple the service. This 776 means that the service requester has no knowledge of the technical details of the 777 provider’s implementation, such as the programming language, deployment platform, 778 and so forth. The service requester typically invokes operations by way of messages -- a 779 request message and the response -- rather than through the use of APIs or file formats. 780 781 782 “Extensibility is essential to the rapid and efficient evolution of Web service interfaces. If 783 every enhancement of a provider interface requires the redeployment of a corresponding 784 consumer interface to the thousands of existing consumers, then change management 785 will grind to a halt. The key is to architect Web service interfaces using XML and XSD 786 (XML Schema Definition) extensibility mechanisms to enable both forward and backward 787 compatibility between consumer and provider interfaces to loosely couple consumer 788 versions from provider versions”. – Gartner 2006 789 790 5. Web Services must have well-defined interfaces. The service interaction 791 must be well-defined. Web services Description Language (WSDL) is a widely- 792 supported way of describing the details required by a service requester for binding to a 793 service provider. The service descriptions focus on operations used to interact with the 794 following: 795 a. A service 796 b. Messages to invoke operations 797 c. Details of constructing such messages 798 d. Information on where to send messages for processing details of constructing 799 such messages 800 801 LRS RFP - Attachment H (Technical Exhibits) Page 31 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 802 WSDL should not include any technology details of the implementation of a service. The 803 service requester neither knows nor cares whether the service is written in Java code, 804 C#, COBOL, or some other programming language. It can describe a SOAP invocation 805 using HTTP. Because of its extension mechanisms, it can also define other styles of 806 interaction such as XML content delivered via JMS, direct method calls, calls handled by 807 an adapter that manages legacy code (CICS), and so forth. 808 809 The common definition for WSDL allows development tools to create common interfaces 810 for various styles of interaction, while hiding the details of how it invokes the service from 811 the application code. The Web Services Invocation Framework (WSIF), for example, 812 exploits this capability by allowing a run-time determination of the best way to invoke a 813 quality service if the service is exposed in more than one interaction style. See 814 http://ws.apache.org/wsif/ for WSIF details. 815 816 6. Design stateless base Web services. Services should be independent, self- 817 contained requests, which do not require information or state from one request to 818 another when implemented. Services should not be dependent on the context or state of 819 other services. When dependencies are required, they are best defined in terms of 820 common business processes, functions, and data models, not implementation artifacts 821 (like a session key). Of course, requester applications require persistent state between 822 service invocations, but this should be separate from the base service. Web 823 applications and composite Web services can both handle state. 824 825 826 7. Implement business processes via orchestrating Web services into a 827 process flow (BPEL standard). Some business processes can be implemented in a 828 process flow and called from an application (which implements the entire business 829 process). The individual nodes within the process flow can call other Web services, call 830 out to a business rules engine, or call a native API (such as Java or .NET). Process 831 flows also manage state, which means data created by one node is available to other 832 nodes to view, add to, or modify. Additionally, process flow engines (vendor specific) 833 have built in mechanisms to recover a process flow should a system or process failure 834 occur. 835 836 837 For example, a Professional License Application might call several Web service process 838 flows (Gather Qualifications, Process Qualifications, Handle Payment, and Create 839 License) to achieve the business process functionality. 840 841 8. A governance structure must be created to manage Web service 842 development and operational environments. By definition, Web services are 843 created with the enterprise in mind. That implies a strong collaboration environment 844 exists where interested parties agree on how Web services will be defined, built, 845 implemented, deployed, supported, enhanced, and managed in production environment. 846 Additional budgets, people, tools, and equipment resources must be allocated 847 appropriately. 848 849 850 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) 851 Liberty Alliance and OASIS have defined a large number of Web service security 852 standards. Eventually, the work of both groups will probably be merged into a single set 853 of standards. WS-Security seems to be the most widely used while many other 854 standards within WS* are still evolving. However, this should not deter security 855 mechanisms from being designed into Web services. 856 857 California Service Centers 858 859 The ultimate vision is to consolidate business services provided to constituents into a collection 860 of federated service centers. SOA will play a key part in how these services are implemented. 861 Please see California Service Centers SOA White Paper , for complete details. Following is a 862 brief description of the key components. 863 Consolidated Service Centers 864 Clark Kelso, State CIO on 4/21/2006 authored Government Services on the Web: California In- 865 Touch . This document introduces the notion of providing a better customer experience at 866 reduced cost to the state via moving to consolidated service centers. 867 868 The new California Service Center (CSC) will lead the way to a more customer-friendly E- 869 government based on a services oriented (SOA) environment. From a strategic perspective, 870 the California Service Center will be the customer-facing site. It will intelligently redirect to the 871 appropriate service centers which will be working together in a federated manner. 872 Shared Services 873 Collectively, the service centers will leverage shared services, such as Identity, Search, Real 874 Simple Syndication (subscriptions, news), Address Verification, and a common Payment 875 engine to name a few. Shared services will be built in a federated manner but deployed and 876 operationally managed centrally. That is, many departments will contribute shared services but 877 they will be hosted in a small number of data centers. 878 SOA Infrastructure 879 Operationally, service centers will utilize an enterprise infrastructure approach. That is, they will 880 be deployed and managed in a small number of SOA-based data centers. Mission critical 881 services will be deployed in a redundant manner across data centers to minimize single point of 882 failures. This implies collaboration in the area of configuration and release management across 883 data centers to achieve a high degree of availability, scalability, and reliability. 884 885 An SOA infrastructure must support XML message processing and application integration. This 886 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) 887 Enterprise Service Bus 888 Application integration and service interoperability are of paramount importance in a shared 889 services environment. Because applications are located on many different hardware and 890 software platforms, connecting these environments in a manner that meets availability, 891 scalability, and user performance expectations, uniform service interoperability platforms must 892 be carefully chosen. 893 894 These typically fall into two categories: For Windows-based platforms, Microsoft handles 895 standards-based messaging and application connectivity via incorporating Windows 896 Communication Framework functionality into an upcoming release called Windows Vista. In the 897 Java world, there are quite a few choices. Some of the more popular ones are IBM WebSphere 898 ESB, BEA AquaLogic Service Bus, Oracle Fusion, Cape Clear ESB, Sonic Software ESB, SAP 899 NetWeaver, and others. 900 901 California SOA Center of Excellence 902 903 Introduction 904 A successful state-wide SOA program will require both centralized and federated components. 905 Singular vision & goals, governance, enterprise repository management, and several 906 operational functions (certification lab, UDDI repository, maintain service reference model, 907 service help desk, and search taxonomy) should be centralized. Service development (and 908 possibly some SOA operations) should be federated to the producing departments. In some of 909 the above functions, centralized does not mean single instance. For example one would 910 establish at least two UDDI repositories for scalability and accessibility. 911 912 Because SOA components are designed for enterprise use, there are a number of critical 913 governance and operational issues that need to be addressed. Such as: 914 915 • How will developers be supported? 916 • How will business architects and technical architects determine which shared services 917 already exist? 918 • How will SOA services be mapped to business services? 919 • How will service versioning and release packaging be controlled? 920 • How will services be certified? 921 • How will services be tested for performance, availability, and scalability? 922 • How will services usage be monitored and reported? 923 • How will developers locate code for an existing service? 924 • How will service contract compliance among data centers be handled? 925 • Will there be a centralized, state-wide help desk? 926 • How will service troubleshooting be handled at an enterprise level? 927 (A composite service might consist of 4 services, each running in a different data 928 center.) 929 • Will there be example services and demo applications? 930 • Will there be a state-wide search service utilizing a common language? (a taxonomy)? 931 LRS RFP - Attachment H (Technical Exhibits) Page 34 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 932 It is obvious that there is a very important need for an oversight group to act as the center hub 933 for the enterprise. It is recommended that a California SOA Center of Excellence be established 934 to fulfill many of these tasks. This group would lead the SOA effort, be the “go to” experts for 935 departmental business service implementers, facilitate discussion groups, lead collaboration 936 efforts, build a reference architecture based on best practices, and host demos. They could 937 also maintain a performance lab to ensure that critical services will meet performance and 938 availability expectations, manage a centralized help desk, handle compliance escalations via an 939 expert distributed architecture technical staff, and define a state-wide search taxonomy. 940 941 SOA leadership cannot be static. Rather, it should evolve as standards mature and change, 942 vendors products change based on market dynamics and changing standards, analysts revise 943 their best practices, and government politics and regulations change. 944 945 So the first set of responsibilities of the California SOA Center of Excellence is shown in the 946 following SOA Excellence diagram. 947 948 949 LRS RFP - Attachment H (Technical Exhibits) Page 35 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 950 SOA Excellence Model 951 952 1. Standards – SOA is comprised of many standards which are managed by several 953 standard bodies. It will be very important to stay on top of standard developments since 954 they will have a large impact on SOA architecture. Attending conferences, monitoring 955 discussion groups, and regularly checking W2C, OASIS, and WS-I Websites are all key 956 activities. 957 958 959 2. Vendors & Analysts – Relationships with key vendors is important in order to keep 960 abreast of product developments and vendor visions for SOA. Subscribing to industry 961 analysts newsletters is also a good way of staying informed. 962 963 964 3. State & Federal Collaboration – The Federal Enterprise Architecture Group and its 965 ancillary operations set the standard for states to follow. Additionally, many states are in 966 the process of implementing SOA-based models. So, ongoing collaboration with other 967 states makes good sense. 968 969 970 4. Operations Feedback – The SOA vision and goals must be practical. So, feedback 971 from SOA operations must be factored into the vision and goals must be updated 972 accordingly. 973 974 975 5. Briefings & Targeted Presentations – SOA means different things to different people. 976 So, preparing presentations that are targeted to a particular group will be most effective. 977 For example, executives, business architects, technical architects, and IT developers all 978 have different priorities within SOA. So, presenting SOA in terms of specific audience 979 type would be most effective. 980 981 982 1. Demos – An SOA Center of Excellence is a great place to demonstrate the SOA 983 environment. Demos can be built to support the presentations targeted at specific 984 audiences. Often, it is easier to understand a point by witnessing a demo. Plus, a demo 985 proves out an environment and allows “what if” scenarios. 986 987 988 2. Reference Architecture – An SOA environment should exist as the model for 989 developers. That is, a reference implementation that incorporates key SOA components 990 would provide developers platform-specific components to measure their services 991 against. The Reference Architecture would include both J2EE and .NET components. 992 993 994 3. Executive SOA Discussion Group – Sponsoring an SOA discussion group for 995 executives would be one way of providing executives with an easy mechanism for 996 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) 997 SOA Tools 998 Development Tools 999 A tool to model business services would be of great value. This could include business 1000 process details as well as expected performance metrics. If the tool has the capability 1001 to simulate different business scenarios, it would be of even more value. 1002 1003 Equally important is a tool to model SOA services. Ideally, the output from the business 1004 modeling tool would seamlessly flow into the SOA services tool which, in turn could 1005 generate implementation code. 1006 Enterprise Repository 1007 A single, enterprise repository tool is needed to gather information about enterprise architecture 1008 models, department applications, shared service inventory and usage, as well as pointers to 1009 shared service code packages. Therefore this repository should be purchased and 1010 implemented as a shared enterprise tool with the capability to establish different types of users, 1011 and appropriate levels of security. 1012 1013 This repository should be configured to hold details of the Business Reference Models (BRM), 1014 Service Reference Models (SRM), Data Reference Models (DRM), and Technical Reference 1015 Models (TRM). For example, the Technical Reference Framework templates would be stored in 1016 this repository. As departments fill out the templates they could also be stored in the 1017 department section. 1018 Business Activity Monitoring (BAM) 1019 BAM enables organizations to leverage business analytics to gain a real-time insight into daily 1020 business operations. This analytical insight helps business users quickly identify operational 1021 inefficiencies and predict potential business problems. BAM integrates business intelligence 1022 (BI) with business transaction processing. 1023 1024 BAM enables organizations to leverage business analytics to gain a real-time insight into daily 1025 business operations. This analytical insight helps business users quickly identify operational 1026 inefficiencies and predict potential business problems. BAM integrates business intelligence 1027 (BI) with business transaction processing. 1028 Appendices 1029 1030 Appendix A - Federal SOA 1031 The Federal Architecture and Infrastructure Committee along with the Federal CIOs Council 1032 produced the Federal Enterprise Architecture which is based on SOA and Web Services. 1033 1034 “An architecture that provides for reuse of existing business services and rapid deployment of new 1035 business capabilities based on existing capital assets is often referred to as a service-oriented 1036 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) 1037 For a full description of the Federal Enterprise Architecture program, please see 1038 http://www.cio.gov/documents/CIOC_AIC_Service Component Based Architectures 1039 _2.0_FINAL.pdf 1040 1041 For a broader description of the Federal E-Gov initiative please see 1042 http://www.whitehouse.gov/omb/egov/ . 1043 1044 Appendix B - SOA Advantages (Patricia Seybold Group) 1045 Brenda M. Michelson, Sr. VP 1046 1047 SOA Business Advantages: 1048 • Consistent Experience. An SOA can provide a consistent experience for customers 1049 and partners across channels and lines of business. 1050 1051 1052 • Business Agility. An SOA can add new functionality, expose functionality to new 1053 channels, and vary functionality based on context (customer, partner, entry point). 1054 1055 1056 • Mix and Match. An SOA can compose business solutions from a reusable service 1057 collection, leveraging internal and external services. 1058 1059 1060 • Optimize Interactions. An SOA can optimize business interactions for customers, 1061 partners, and internal constituents through the implementation of business scenarios 1062 (process, events, and services) versus traditional applications. 1063 1064 1065 SOA IT advantages: 1066 • Reduction of Costs. Reuse of services reduces IT development, deployment, and 1067 maintenance time and costs. 1068 1069 1070 • Leverage Existing IT Investments. Your service providers are existing code (objects, 1071 components, legacy modules, and application package APIs) and information assets 1072 (databases, files, and documents). 1073 1074 1075 • Transition Strategies. An SOA can provide application and portfolio transition 1076 strategies. 1077 LRS RFP - Attachment H (Technical Exhibits) Page 38 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 1078 Appendix C – WSDL Example 1079 1080 1081 1082 1083 This is an abridged version of the WSDL for Amazon’s E-commerce Service (ECS). The 1084 annotations 1085 on the left hand-side describe the WSDL sections. The yellow boxes within the WSDL highlight 1086 key elements, such as data elements, messages and bindings, and their recurrence in the 1087 various sections. 1088 - 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) 1089 1090 Appendix D – Legacy Integration Patterns 1091 Overview 1092 Mainframe applications will continue to be around for a long time and many departments 1093 depend on the mainframes for their mission critical applications. Therefore, the state must plan 1094 to integrate mainframe applications into the new SOA-based environment. Departments should 1095 take a close look at their application portfolios and devise an application maturity plan which 1096 would should separate them into categories such as don’t modify, wrap with Web service 1097 interfaces, reengineer into Java or .NET applications, or plan to retire. Following are brief 1098 discussion of three popular patterns. 1099 Integrating Existing Mainframe Apps - Unmodified 1100 There are several ESB products that have a broad range of application integration capability. 1101 IBM Websphere ESB, Oracle Fusion, Cape Clear ESB, plus a number of other companies have 1102 products in this area. Enterprise Service Bus products not only provide messaging 1103 infrastructure for Web services, they also provide a variety of adapters and connectors to 1104 integrate native language interfaces (such as COBOL, CICS, MQ Series, Java, FTP, etc.). 1105 LRS RFP - Attachment H (Technical Exhibits) Page 40 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 1106 1107 1108 1109 IBM 1110 http://www-306.ibm.com/software/info1/Websphere/index.jsp?tab=landings/esb 1111 1112 Oracle 1113 http://www.oracle.com/products/middleware/index.html 1114 1115 Sonic 1116 http://www.sonicsoftware.com/index.ssp 1117 1118 Cape Clear 1119 http://www.capeclear.com/products/cc6.shtml LRS RFP - Attachment H (Technical Exhibits) Page 41 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 1120 Placing Web Service Interfaces on Existing Mainframe Apps 1121 Makes mainframe applications (particularly Natural and Adabas) look like Web services. 1122 EntireX executes on the mainframe and exposes the service interfaces. ApplinX solution 1123 requires no changes to mainframe code. 1124 1125 SoftwareAG EntireX 1126 http://www.softwareag.com/Corporate/products/entirex/default.asp 1127 1128 SoftwareAG ApplinX 1129 http://www.softwareag.com/Corporate/products/applinx/default.asp 1130 Compiling COBOL Code into Web Service Languages 1131 Fujitsu Consulting provides a COBOL compiler for a variety of platforms and languages. For 1132 example, NetCOBOL for .NET is a COBOL compiler created specifically for Microsoft's .Net 1133 Framework. This means that COBOL is just another .NET scripting language (like VB.NET, C#, 1134 J#, etc.). This allows COBOL code to be mixed with C# or VB.NET code. It compiles to 1135 Microsoft MSIL (language neutral, .NET runtime) code. 1136 1137 NetCOBOL main page 1138 http://www.netcobol.com/products/ 1139 1140 NetCOBOL for .NET 1141 http://www.netcobol.com/products/windows/netcobol.html 1142 1143 Appendix E - Definitions 1144 1145 AJAX: Asychronous JavaScripting and XML is a Web development technique for creating 1146 interactive Web pages. The intent is to make Web pages feel more responsive by exchanging 1147 small amounts of data with the server behind the scenes, so that the entire Web page does not 1148 have to be reloaded each time the user makes a change AJAX is available for Java, .NET, 1149 PHP, and other languages. 1150 http://en.wikipedia.org/wiki/AJAX 1151 Architecture: Representation of the structure of a system that describes the constituents of the 1152 system and how they interact with each other. 1153 Application Architecture: Representation of an application and its parts, their inter- 1154 relationships and functions. 1155 AVDL: Application Vulnerability Description Language. 1156 http://www.oasis-open.org/specs/index.php#avdlv1.0 1157 1158 BPEL: Business Process Execution Language for Web Services provides a means to formally 1159 specify business processes and interaction protocols. BPEL provides a language for the formal 1160 specification of business processes and business interaction protocols. By doing so, it extends 1161 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) 1162 defines an interoperable integration model that should facilitate the expansion of automated 1163 process integration in both the intra-corporate and the business-to-business spaces. 1164 http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ 1165 Business Component: Represents the implementation of an autonomous business concept, 1166 business service, or business process. It consists of all the technology elements (i.e., software, 1167 hardware, data) necessary to express, implement, and deploy a given business concept as an 1168 autonomous, reusable element of a large information system. It is a unifying concept across the 1169 development lifecycle and the distribution tiers. 1170 Business (Domain) Component: Organizational unit that offers business services operation 1171 based on rules of that business. 1172 Business Component System: Set of cooperating business components assembled together 1173 to deliver a solution to a business problem. 1174 Business Logic Component: Software unit that offers small-grained business logic that has a 1175 large degree of reuse throughout the organization. Sub-components that manage and exe-cute 1176 the set of complex business rules that represent the core business activity supported by the 1177 component. 1178 CAP: Common Alerting Protocol. 1179 http://www.oasis-open.org/specs/index.php#capv1.0 1180 Component: Independently deployable unit of software that exposes its functionality through a 1181 set of services accessed via well-defined interfaces. A component is based on a component 1182 standard, is described by a specification, and has an implementation. Components can be 1183 assembled to create applications or larger-grained components. 1184 Component Architecture: Internal structure of a component described in terms of partitioning 1185 and relationships between individual internal units. 1186 Component-Based Architecture: Architecture process that enables the design of enterprise 1187 solutions using large service components. The focus of the architecture may be a specific 1188 project or the entire enterprise. This architecture provides a plan of what needs to be built and 1189 an over-view of what has been built already. 1190 Component Registry: Application designed to provide a directory of available components 1191 based on profile and or specification. Registries usually provide efficient mechanisms for 1192 searching for components in multiple ways, such as by service, price, and/or provider. 1193 Component Repository: Application designed to store component specifications and 1194 implementations. Often provides facilities to efficiently search for and retrieve components for 1195 evaluation against desired component specifications though the search capabilities may be off- 1196 loaded to a component registry. 1197 CORBA: Common Object Request Broker Architecture, created by the Object Management 1198 Group (http://www.omg.org/ ) vendor-independent architecture and infrastructure that computer 1199 applications use to work together over networks. Using the standard protocol IIOP, a CORBA- 1200 based program from any vendor, on almost any computer, operating system, programming 1201 language, and network, can interoperate with a CORBA-based program from the same or 1202 another vendor, on almost any other computer, operating system, programming language, and 1203 network. LRS RFP - Attachment H (Technical Exhibits) Page 43 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 1204 COTS Components: Commercial Off the Shelf (COTS) components that can satisfy business 1205 process and data requirements for large functional domains or lines-of-business. Examples of 1206 COTS components would be Enterprise Resource Planning (ERP) products such as those as 1207 offered by commercial software companies. 1208 Data: Factual or numerical business information of record that is maintained by the service 1209 component. The encapsulated service component is fully responsible for maintaining this 1210 information. 1211 Data-Level Application Programming Interfaces: Services internal to the service component 1212 that support access to the data of record maintained within the service component. These ser- 1213 vices may span numerous distributed data sources. 1214 DCOM: Distributed Common Object Model is an extension of the Component Object Model 1215 (COM) that allows COM components to communicate across network boundaries. DCOM 1216 uses the RPC mechanism to transparently send and receive information between COM 1217 components. Microsoft first introduced it in 1995. 1218 DSML: Directory Services Markup Language. 1219 http://www.oasis-open.org/specs/index.php#capv1.0 1220 Distributed Component: Lowest level of component granularity. It is a software element that 1221 can be called at run-time with a clear interface and a clear separation between interface and 1222 implementation. It is autonomously deployable. A distributed component provides low ROI for 1223 capital planning purposes. 1224 E-Business Patterns: Patterns for e-business are a group of proven reusable assets that can 1225 be used to increase the speed of developing and deploying net-centric applications, like Web- 1226 based applications. 1227 ebXML: Electronic Business using eXtensible Markup Language. 1228 http://www.ebxml.org/ 1229 Encapsulation: Hiding implementation details within a component so that an implementation is 1230 not dependent on those details. 1231 Enterprise Architecture: Meta-architecture of an organization or the sum of all architectures 1232 within an organization. 1233 Enterprise Component: Large-granularity business component of an organization. 1234 Enterprise Service Bus (ESB): A class of integration software that is intended to support the 1235 deployment of Web services. An ESB combines messaging, basic transformation, and content- 1236 based routing. The inputs and outputs of an ESB are Service Data Objects (SDO). 1237 Extensibility: Ability to extend the capability of a component so that it handles additional needs 1238 of a particular implementation. 1239 Federated Business Component: Set of cooperating system-level components federated to 1240 resolve the business need of multiple end users often belonging to different organizations. 1241 California Enterprise Component: Very coarse-grained business component of California 1242 Government. 1243 Federation: is a collection of realms/domains that have established trust. The level of trust may 1244 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) 1245 Fit-Gap Analysis: Examination of components within the context of requirements and to make 1246 a determination as to the suitability of the service component. 1247 Component Granularity: The size of the unit of component under consideration in some 1248 context. The term generally refers to the level of detail at which component is considered, e.g. 1249 "You can specify the granularity for this service component". 1250 Identity Mapping: is a method of creating relationships between identity properties. Some 1251 Identity Providers may make use of id mapping. 1252 Identity Provider: is an entity that acts as a peer entity authentication service to end users and 1253 data origin authentication service to service providers (this is typically an extension of a security 1254 token service). 1255 ID-FF: Liberty Identity Federation Framework. ID-FF contains the core specifications that allow 1256 for the creation of a standardized, multi-vendor, identity federation network. The FF consists of 1257 protocols, schema and profiles. 1258 https://www.projectliberty.org/resources/specifications.php 1259 ID-SIS: Liberty Identity Services Interface Specifications. ID-SIS uses the ID-WSF (new window) 1260 and ID-FF (new window) specifications to provide networked identity services, such as contacts, 1261 presence detection, or wallet services that depend on networked identity. The SIS contains two 1262 specifications: Personal Profile (ID-SIS-PP): and Employee Profile (ID-SIS-EP): 1263 ID-WSF: Liberty Identity Web Services Framework. ID-WSF provides a basic framework of 1264 identity services. Such services could be identity service discovery and invocation. The WSF 1265 consists of schema, protocols, and profiles. 1266 http://www.projectliberty.org/resources/specifications.php 1267 Infrastructure Component: Software unit that provides application functionality not related to 1268 business functionality, such as error/message handling, audit trails, or security. 1269 Interface: Mechanism by which a component describes what it does and provides access to its 1270 services. This is important because it represents the “contract” between the supplier of services 1271 and the consumer of the services. 1272 Intellectual Property: A product of the intellect that has commercial value, including 1273 copyrighted property such as literary or artistic works, and ideational property, such as patents, 1274 appellations of origin, business methods, and industrial processes. 1275 Interface Profile: the sub-component that provides the ability to customize the component for 1276 various uses. The profile can be tailored to suit different deployment architectures well as 1277 different sets of business rules across enterprises. The interface profile can specify the business 1278 rules and workflow that are to be executed when the component is initialized. The profile can 1279 specify the architectural pattern that complements the service component. 1280 Java Server Faces: JavaServer Faces technology is a server-side user interface component 1281 framework for Java technology-based Web applications. JSF offers a clean separation between 1282 behavior and presentation. 1283 http://java.sun.com/j2ee/1.4/docs/tutorial/doc/ 1284 1285 Language Class: Class in an object-oriented programming language to build distributed 1286 components. This is NOT considered an SRM component. A language class provides very low 1287 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) 1288 1289 Line of Business: A particular kind of commercial or government enterprise; e.g. "human re- 1290 sources" “financial management” “wholesale banking”. 1291 Message Authentication: is the process of verifying that the message received is the same as 1292 the one sent. 1293 Messaging Interface: Linkage from the service component to various external software 1294 modules (component, external systems, gateways, etc.) and other service components. 1295 Notional Component: Set of services packaged into a component, derived from requirements 1296 definition. A “desired” component, prior to implementation. 1297 Process Component: Software unit that implements the logic of a process. 1298 Realm or Domain: represents a single unit of security administration or trust. 1299 Reuse: Any use of a preexisting software artifact (component, specification, etc.) in a context 1300 different from that in which it was created. 1301 SAML: Security Assertion Markup Language. 1302 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 1303 Security Token Service (STS): A security token service is a Web service that issues security 1304 tokens (see WS-Security and WS-Trust). That is, it makes assertions based on evidence that it 1305 trusts, to whoever trusts it. To communicate trust, a service requires proof, such as a security 1306 token or set of security tokens, and issues a security token with its own trust statement (note 1307 that for some security token formats this can just be a re-issuance or co-signature). This forms 1308 the basis of trust brokering. 1309 Sender Authentication: is corroborated authentication evidence possibly across Web service 1310 actors/roles indicating the sender of a Web service message (and its associated data). Note that 1311 it is possible that a message may have multiple senders if authenticated intermediaries exist. 1312 Also note that it is application-dependent (and out of scope) as to how it is determined who first 1313 created the messages as the message originator might be independent of, or hidden behind an 1314 authenticated sender. 1315 Service: Discrete unit of functionality that can be requested (provided a set of preconditions is 1316 met), performs one or more operations (typically applying business rules and accessing a data- 1317 base), and returns a set of results to the requester. Completion of a service always leaves 1318 business and data integrity intact. 1319 Service-Component: Modularized service-based applications that package and process 1320 together service interfaces with associated business logic into a single cohesive conceptual 1321 module. Aim of a service component is to raise the level of abstraction in software services by 1322 modularizing synthesized service functionality and by facilitating service reuse, service 1323 extension, specialization and service inheritance. 1324 Service-Component Reference Model (SRM): Service component-based framework that can 1325 provide—independent of business function—a “leverage-able” foundation for reuse of 1326 applications, application capabilities, components, and business services. 1327 Service Data Object (SDO): An Enterprise Service Bus concept where all incoming messages 1328 are converted into service data objects. 1329 Service Interface: Set of published services that the component supports. These are aligned 1330 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) 1331 Service-Level Agreement: A contract or memorandum of agreement between a service 1332 provider and a customer that specifies, usually in measurable terms, what services the service 1333 provider will furnish. Information technology departments in major enterprises have adopted the 1334 idea of writing a service level agreement so that services for their customers (users in other 1335 departments within the enterprise) can be measured, justified, and perhaps compared with 1336 those of external (sourcing) service providers. 1337 Service-Oriented Architecture: Architecture that provides for reuse of existing business 1338 services and rapid deployment of new business capabilities based on existing capital assets. 1339 Services Interface: A logical boundary that permits software services to be defined 1340 independent of the service implementation. 1341 SOAP: A simple XML based protocol to let applications exchange information over HTTP. 1342 SOAP is a protocol for accessing a Web Service. Note, SOAP originally stood for Simple 1343 Object Access Protocol, but this has been dropped. 1344 Single Sign On (SSO): is an optimization of the authentication sequence to remove the burden 1345 of repeating actions placed on the end user. To facilitate SSO, an element called an Identity 1346 Provider can act as a proxy on a user's behalf to provide evidence of authentication events to 1347 3rd parties requesting information about the user. These Identity Providers are trusted 3rd 1348 parties and need to be trusted both by the user (to maintain the user's identity information as the 1349 loss of this information can result in the compromise of the users identity) and the Web services 1350 which may grant access to valuable resources and information based upon the integrity of the 1351 identity information provided by the IP. 1352 SPML: Service Provisioning Markup Language. 1353 http://www.oasis-open.org/specs/index.php#capv1.0 1354 Solution Assembly: Process of implementing a solution by assembling the necessary 1355 components into a complete solution. This process often involves additional “glue” code to 1356 integrate the assembled components. 1357 Test Harness: Software that automates the software engineering testing process to test the 1358 soft-ware as thoroughly as possible before using it on a real application. Trust Domain: an 1359 administered security space in which the source and target of a request can determine and 1360 agree whether particular sets of credentials from a source satisfy the relevant security policies 1361 of the target. The target may defer the trust decision to a third party thus including the trusted 1362 third party in the Trust Domain. 1363 1364 UBL: Universal Business Language. 1365 http://www.oasis-open.org/specs/index.php#capv1.0 1366 1367 UDDI: Universal Description Discovery Integration. 1368 http://www.uddi.org/ 1369 Web Service: Functionality provided by a service, which is exposed using the Internet (SOAP, 1370 HTTP, WSDL, XML, TCP/IP) as the transport mechanism. Can be internally provided as part of 1371 a suite of services or can be offered by external organizations. 1372 Web Service for Remote Portlets: A user-facing Web Service that will provide content, 1373 marked for display, to a portal or other aggregating Web application. This moves Web Services 1374 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) 1375 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp 1376 Web Service Flow: The process of combining and orchestrating Web services into a unique 1377 flow. Individual Web methods on multiple Web services can be invoked in a precise order that 1378 meets the specific application flow requirements. 1379 Workflow Manager: Sub-component that enables one component to access services on other 1380 components to complete its own processing. The workflow manager determines which external 1381 component services must be executed and manages the order of service execution. 1382 Wrapping: Creation of an interface around legacy functionality (code) that exposes the 1383 functionality as services via interfaces that conform to a component specification. 1384 WSDL: An XML format for describing network services as a set of endpoints operating 1385 on messages containing either document-oriented or procedure-oriented information. 1386 The operations and messages are described abstractly, and then bound to a concrete 1387 network protocol and message format to define an endpoint. Related concrete 1388 endpoints are combined into abstract endpoints (services). 1389 WSDM: Web Services Data Management. 1390 WSIF: The Web Services Invocation Framework (WSIF) is a simple Java API for invoking Web 1391 services, no matter how or where the services are provided. WSIF allows stubless or 1392 completely dynamic invocation of a Web service, based upon examination of the meta-data 1393 about the service at runtime. 1394 http://ws.apache.org/wsif/ 1395 WS-Addressing: describes how to specify identification and addressing information for 1396 messages. 1397 WS-Authorization: will describe how to manage authorization data and authorization policies. 1398 WS-BusinessActivity: This specification provides the definition of the business activity 1399 coordination type that is to be used with the extensible coordination framework described in the 1400 WS-Coordination specification. The specification defines two specific agreement coordination 1401 protocols for the business activity coordination type: 1402 BusinessAgreementWithParticipantCompletion and 1403 BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these 1404 protocols when building applications that require consistent agreement on the outcome of long- 1405 running distributed activities. 1406 http://www-128.ibm.com/developerworks/library/specification/ws-tx/ 1407 WS-Federation: describes how to manage and broker the trust relationships in a 1408 heterogeneous federated environment, including support for federated identities, sharing of 1409 attributes, and management of pseudonyms. 1410 Web Services Inspection Language (WSIL): The WS-Inspection specification "defines how 1411 an application can discover an XML Web service description on a Web server, enabling 1412 developers to easily browse Web servers for XML Web services. WS-Inspection complements 1413 the IBM- and Microsoft-pioneered 'Universal Description, Discovery and Integration (UDDI)' 1414 global directory technology by facilitating the discovery of available services on Web sites 1415 unlisted in the UDDI registries, and builds on Microsoft's SOAP Discovery technology built into 1416 Visual Studio .NET. 1417 WS-MetadataExchange: describes how to exchange metadata such as WS-Policy information 1418 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) 1419 WS-Policy: represents a set of specifications that describe the capabilities and constraints of 1420 the security (and other business) policies on intermediaries and endpoints (e.g. required 1421 security tokens, supported encryption algorithms, privacy rules) and how to associate policies 1422 with services and endpoints. 1423 http://msdn.microsoft.com/library/default.asp?url=/library/en- 1424 us/dnwssecur/html/securitywhitepaper.asp 1425 WS-Privacy: will describe a model for how Web services and requestors state privacy 1426 preferences and organizational privacy practice statements. 1427 http://msdn.microsoft.com/library/default.asp?url=/library/en- 1428 us/dnwssecur/html/securitywhitepaper.asp 1429 WS-Referral: WS-Referral is a protocol that enables the routing strategies used by SOAP 1430 nodes in a message path to be dynamically configured. SOAP itself provides a distributed 1431 processing model where SOAP messages can have content destined for specific processing 1432 nodes. WS-Routing adds to SOAP the capability of describing the actual message path. WS- 1433 Referral provides a mechanism to dynamically configure SOAP nodes in a message path to 1434 define how they should handle a SOAP message. It is a configuration protocol that enables 1435 SOAP nodes to delegate part or all of their processing responsibility to other SOAP nodes. 1436 http://msdn.microsoft.com/library/default.asp?url=/library/en- 1437 us/dnglobspec/html/wsreferspecindex.asp 1438 WS-Reliability: Web Services Reliability (WS-Reliability) is a SOAP-based protocol for exchanging 1439 SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message 1440 ordering. WS-Reliability is defined as SOAP header extensions, and is independent of 1441 the underlying protocol. 1442 http://developers.sun.com/sw/platform/technologies/ws-reliability.html 1443 WS-ReliableMessaging: this specification describes a protocol that allows messages to be 1444 delivered reliably between distributed applications in the presence of software component, 1445 system, or network failures. The protocol is described in this specification in an independent 1446 manner, allowing it to be implemented using different network transport technologies. To 1447 support interoperable Web services, a SOAP binding is defined within this specification. 1448 http://msdn.microsoft.com/library/default.asp?url=/library/en- 1449 us/dnglobspec/html/wsrmspecindex.asp 1450 WS-Routing: WS-Routing is a simple, stateless, SOAP-based protocol for routing SOAP 1451 messages in an asynchronous manner over a variety of transports like TCP, UDP, and HTTP. 1452 With WS-Routing, the entire message path for a SOAP message (as well as its return path) can 1453 be described directly within the SOAP envelope. 1454 http://msdn.microsoft.com/library/default.asp?url=/library/en- 1455 us/dnglobspec/html/wsroutspecindex.asp 1456 WSRP: Web Services for Remote Portlets. 1457 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp 1458 WS-SecureConversation: describes how to manage and authenticate message exchanges 1459 between parties, including security context exchanges and establishing and deriving session 1460 keys. 1461 http://www-128.ibm.com/developerworks/library/specification/ws-secon/ LRS RFP - Attachment H (Technical Exhibits) Page 49 February 29, 2008
    • Los Angeles County Department of Public Social Services LEADER Replacement System (LRS) 1462 WS-Security: describes how to attach signature and encryption headers to SOAP messages. In 1463 addition, it describes how to attach security tokens, including binary security tokens such as 1464 X.509 certificates and Kerberos tickets, to messages. 1465 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp 1466 WS-Security SAML Token Profile: 1467 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf 1468 WS-Transactions and WS-Coordination: describes how to enable transacted operations as 1469 part of Web service message exchanges. 1470 WS-Trust: describes a framework for trust models that enables Web services to securely 1471 interoperate by requesting, issuing, and exchanging security tokens. 1472 http://Webservices.xml.com/lpt/a/ws/2003/06/24/ws-trust.html 1473 XACML: Extensible Access Control Markup Language. 1474 http://www.oasis-open.org/specs/index.php#capv1.0 LRS RFP - Attachment H (Technical Exhibits) Page 50 February 29, 2008