LEADER REPLACEMENT SYSTEM

1,558 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,558
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

LEADER REPLACEMENT SYSTEM

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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

×