LEADER REPLACEMENT SYSTEM

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)

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

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 ii February 29, 2008

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 1 February 29, 2008

EXHIBIT 1 – LRS NETWORK 1

1.1 LRS NETWORK TOPOLOGY 2

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

7

COUNTYEnterprise Network

(LAnet/EN)

CONTRACTOR/Internet

Network

POP

NetworkAccessPoint

Downey Data Center

EAVEX-1

DOWEX-1

CONTRACTOR Supplied

Connections/ Circuits

COUNTY-specified User (LAnet/EN via VPN)

Interface Systems

COUNTY.Systems (LAnet/EN Based)

POP

Internet Users (General Public)

Eastern Data Center

Internet Users (Applicants and Participants)

GA

TEW

AY

(CO

NTR

AC

TOR

RES

PON

SIB

ILIT

Y)

COUNTY-specified User(LAnet/EN via

Local Office Sites)

Existing LEADER System during Phase 1(Design/Development/Implementation Phase)

Central Print Facility &Backup Central Print Facility

Primary Central Site &Backup Central SiteProject Office

NetworkAccessPoint

COUNTY RESPONSIBILITY CONTRACTOR RESPONSIBILITY

Interface Systems



1.2 GATEWAY RACK 8

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

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

1. HP 10842 G2 Rack (42U) Wide (or equivalent successor) 17 • Base cabinet without options 18 19

2. Environmental Infrastructure 20 • Physical security 21 • HVAC 22 • Power (including redundant backup power) 23 24

3. Physical access to the Gateway 25 • 24/7 accessibility 26 • Security clearance and authorization for COUNTY-approved CONTRACTOR staff 27

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

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

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

Los Angeles County Department of Public Social Services

LEADER Replacement System (LRS)


EXHIBIT 2 – COUNTY INFORMATION TECHNOLOGY (IT) 33 STRATEGIES AND INITIATIVES 34

35 Table 1: DPSS Business Goals 36 37 The IT strategies and initiatives for fiscal years 2006 through 2009 in support of the 38 DPSS business goals are as follows: 39

PROJECT TITLE SUMMARY OF PURPOSE TARGETED

COMPLETION DATE

ASH Production Database

To allow direct notification, exchange of information, and transmission of electronic documents relative to the appeals process.

12/31/2007

Audit Software To automate auditing procedures as required by the 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.

11/01/2007

Automate TANF Quality Control Universe Files in existing LEADER System

To automate production of the monthly TANF primary and secondary QC universe files.

04/30/2007

CSBG Report Management System

To automate the report filing/monitoring process of the 103 agencies that provide services to the public through the Community Service Block Grant program.

07/01/2006

California Child Support Automated System Interface

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

09/01/2008

Case Management Information & Payroll System (CMIPS II)

To establish the interface with the State system that provides payroll information for those individuals who receive In Home Supportive Services (IHSS) benefits.

09/30/2008

Customer Service Call Center

To improve service to DPSS customers by providing easy access to quality information and services.

07/16/2007

DPSS Academy Trainee Attendance for Claiming Process System

To electronically capture and transfer data regarding DPSS Training Academy activities and attendance for claiming purpose.

11/01/2007





COMPLETION DATE

Departmental Data Warehousing Project

To replace an aging and inadequate reporting system 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.

06/30/2007

Develop Direct Deposit Enhancement for existing LEADER System Vendor Payments

To offer vendors direct deposit of payments into their bank account.

04/30/2007

Document Sharing GAIN/CalWORKs

To enhance the communication and document exchange between GAIN regional offices and CalWORKs offices.

06/30/2007

Domain Consolidation

To consolidate the multiple domain names and file servers located throughout the Department in order to improve manageability and reduce costs.

05/31/2007

Electronic Benefit Transfer (EBT) System Modifications

To modify the existing LEADER System’s application in order to support enhanced EBT functionality provided by the State system, including online card history inquiry, FS Disaster Services, and the FS Restaurant Meal Program.

10/31/2006

Expand CAST Document View to IEVS

To allow for the comparison of document images from CAST to process IEVS abstracts more effectively.

07/30/2007

Feasibility Study of One-e-App Interface Process

To evaluate the feasibility of establishing an automated One-e-App interface with existing LEADER System for the generation Medi-Cal applications.

04/30/2007

GEARS Contract Extension and Procurement

To complete procurement planning activities for a new GEARS Contract.

12/01/2006

Implement existing LEADER System Direct Rent for Participants

To modify the existing LEADER System’s application in order to support direct rent payments to landlords for CalWORKs participants.

04/30/2007





COMPLETION DATE

Improve existing LEADER System Performance

To carry out incremental steps toward more flexible existing LEADER System, in order to improve system performance and data integrity, as well as facilitate efficient change management control and quality assurance.

04/30/2007

Income and Eligibility Verification System (IEVS) Recipient

To automate the IFDS & PVS process for abstract assignment, prioritization, disposition, benefit calculation, scheduling appointments, & generating reports.

09/30/2006

Inventory Tracking Application

To implement a new Equipment Inventory system to replace the current system that is obsolete and no longer supported by the manufacturer.

06/30/2008

LEADER Replacement System

To complete reprocurement activities for a LEADER replacement system.

06/01/2007

Existing LEADER System Technology Refresh

To replace equipment used in the existing LEADER System environment that has reached the manufacturer’s end-of-life designation and is fully depreciated.

06/30/2008

Laptop Lifecycle Refresh

To purchase 50 laptops in order to replace outdated equipment.

06/30/2007

Lifestyle Printer Refresh Project

To purchase 2,000 printers to replace worn or broken LaserJet printers.

06/30/2007

Lotus Notes Application Migration

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

12/31/2008

Lotus Notes E-Mail Migration to Exchange

To migrate to Microsoft Exchange in order to achieve a significant reduction in administrative overhead and hardware cost.

12/31/2006

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

TBD

MIE QA Auditor Enhancement

To utilize and enhance the Q5i software program for audit teams.

07/31/2007





COMPLETION DATE

Medi-Cal (MC) Bridging

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

TBD

Network Refresh To replace old switches no longer under equipment warranty.

07/31/2007

Oracle Contract Management System

To automate the current manual system for the tracking of vendors and contracts.

07/31/2007

PA 2197 - Service Request Tracking Application

To automate the current PA 2197 manual process for the procurement of equipment and services.

07/31/2006

Pentium III Desktop Lifestyle

To purchase 250 Workstations for use while broken equipment is being repaired or replaced.

06/30/2007

40 41 Table 2: DCFS Business Goals 42 43 The IT strategies and initiatives for fiscal years 2007 through 2009 in support of the 44 DCFS business goals are as follows: 45 46


COMPLETION DATE

Adoption Promotion and Support Services (APSS)

To automate the APSS referral management, case management, billing, invoice, case and financial report functions.

6/30/2008

Adoptions Public Website

To provide an automated process for Children’s Social Workers and the public interested in adopting to search for children that are available for adoption based on various criteria.

6/30/2009

Application Express Conversion

Application Express (previously know as HTMLDB) is a rapid Web-application development tool. This project will convert existing standalone applications.

6/30/2008

Automated Eligibility Determination (AED)

To automated the manual Foster Care Eligibility Determination process.

12/31/2009

California Child Support Automation System (CCSAS) Interface Project

To replace the current interfaces between DCFS and LA County of Child Support Services Department (CSSD).

8/1/2008

Child Caregiver Agreement/Performance Measures System

To streamline the process of tracking caregiver information and agreement related data, provide electronic storage of agreements and track the

12/1/2008





COMPLETION DATE

caregiver’s performance measurement information. Countywide Court Report Document Imaging Phase II

To expand the Court Reports Document Imaging pilot project.

6/30/2008

DCFS Reporting System

To re-structure the Department’s data reporting based on the Director’s Goals and the DCFS Outcome Measures.

6/1/2008

Electronic Suspected Child Abuse Report (E-SCARS)

To provide a rapid, secure electronic transmission and receipt of mandated suspected child abuse reports between DCFS, Sheriff, Law Enforcement Agencies and the District Attorney’s office.

6/30/2008

Family Support Services To automate a billing and invoice system for community-based agencies.

6/30/08

Foster Care Compliance Tracking & Alert System

To provide an automated Home Compliance Tracking and Alert system to facilitate the monitoring of Foster Home compliance to DCFS specifications with regards to training, assessments, and certifications.

12/31/2007

Hard Disk Encryption To ensure that all Tablet PC/laptops that are purchased and deployed have full hard disk encryption.

12/31/2007

ID Management To implement an Identity Management solution to 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.

6/30/2008

Incident Tracking System (ITrack) Enhancement

To modify the existing ITrack system, database and screens to increase the ability to provide statistical data.

6/1/2008

Infrastructure Upgrade To upgrade the LAN infrastructure for one site to a 100/1000 MBPS switch network.

9/1/2007

Item Control Tracking System

To automate the Item Control tracking system using the Department’s CWTAPPS database and the CWS/CMS datamart.

6/30/2008

Juvenile Court Services 24.1 Joint Assessment Tracking System

To automate a system to track the number of referrals on youth being serviced by both DCFS and the Probation Department.

6/30/2008

Kinship Document Management

To implement a Kinship electronic document process flow to track, control and manage all tasks involved in the assessment process of caregiver homes.

12/31/2007

Live Scan Store and Forward

To purchase and install a Live Scan Store and Forward device to be used in conjunction with twenty-eight Live Scan terminals.

6/30/2008

Master Roster System - MRS

To acquire a market software product to replace the current mainframe Master Roster System.

6/30/2008

Multidisciplinary Assessment Team (MAT) System`

To automate a Multidisciplinary Assessment Team (MAT) tracking system to populate the MAT referral, and produce management reports.

6/30/2008





COMPLETION DATE

Network Admission Control

To implement Cisco Network Admission Control (NAC) technology to provide network based security policy management of all devices connected to DCFS networks.

4/1/2008

Office 2003 To upgrade 7000 DCFS PCs to Microsoft Office 2003 Standard with Software Assurance.

11/15/2008

Output Optimization Purchase and install output devices, printers and Multi-function Devices.

6/30/2008

Time Study Claiming System

Develop a Time Study Claiming System linking the 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.

TBD

WCMIS Replacement To replace the current Welfare Case Management 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.

12/1/2008

Work Order Tracking System Enhancement

To modify the current Work Order Tracking System to accommodate new requirements and reports.

3/1/2008

Workstation Management

Purchase, install and implement Altiris Client Management Suite to replace Novell ZenWorks software.

TBD

Workstation Upgrade Purchase workstations to replace outdated computers and to accommodate new staff.

12/31/2007




EXHIBIT 3 – COUNTY’S CHIEF INFORMATION OFFICE (CIO) GUIDING 47 PRINCIPLES 48 49 LOS ANGELES COUNTY 50 CHIEF INFORMATION OFFICE 51 52 Guiding Principles for Systems Acquisition and Development 53 54 Federated Governance Model 55 To ensure that Information Technology (IT) resources deliver maximum business value, 56 the County employs a federated structure to manage information technology. Reflecting 57 the overall business model of decentralized County management, the federated 58 approach balances the benefits of local autonomy with the advantages of enterprise-59 wide IT coordination and management. It simultaneously allows responsiveness to 60 business issues and accountability to local management, while establishing a 61 convergent IT direction and optimized infrastructure. This approach keeps decision-62 making as close as possible to the business unit while integrating the fabric of the 63 County technology infrastructure, electronic data, and horizontal processes. 64 65 The County’s Federated Governance Model recognizes three levels: 66 • Enterprise – policy, standards, infrastructure, enterprise systems, security, and 67

telecommunications. 68 • Affinity Group – processes, systems, and data shared between multiple 69

departments. 70 • Department – systems internal to a specific department or functional area. 71 72 Each of these three tiers represents varying blends of integration and autonomy. At 73 each level, an IT function is autonomous except as it relates to the tiers(s) above, and 74 complies with information technology policies, standards, conventions and practices for 75 purposes of business processes and systems integration. 76 77 1. Guiding Principles for System Acquisition and Development 78

The County’s Chief Information Office has developed the following principles for 79 new system acquisitions and system development. 80

81 • Open Standards. All new system acquisition and development should 82

employ products or solutions that use open industry standards to facilitate 83 interoperability between applications, systems and organizations. Open 84 standards are technology specifications that are publicly available and 85 affirmed by an industry-recognized standards body. The use of open 86 standards that allow for interoperability between applications and vendor-87 specific products and will ensure their flexibility and adaptability to changing 88 business needs. 89

90




• Industry-Proven Technology. All new system acquisition and infrastructure 91 should use commercially viable, industry-proven, widely-used technology to 92 the maximum extent possible. Use of industry-proven, widely-used 93 technology allows for easier access to affordable skills and a large base of 94 proven software solutions. It can reduce risk, and helps ensure robust product 95 support. Wherever practical, the County should implement commercial-off-96 the-shelf technology as a first preference over completely custom 97 applications. Open Source software should only be used when a viable set of 98 commercial vendors have committed to support it. 99

100 • Countywide Network Backbone. The Los Angeles County Enterprise 101

Network (LAnet-EN) will be used as countywide network backbone for 102 applications and services to foster greater collaboration and sharing of data 103 between County departments and agencies. The County uses the TCP/IP 104 family of protocols as the standard network protocol to ensure technical 105 compatibility and efficient use of the available data transport resources. 106

107 • Multi-tier Server Architecture. All new system acquisition and development 108

should employ a multi-tiered architecture that separates presentation, 109 business logic, database and other services into logical components. A multi-110 tiered architecture provides architectural flexibility from many perspectives 111 including scalability to meet future growth needs, selection of different 112 platforms to meet potential changes to technology standards and directions, 113 and minimization of technology obsolescence. 114

115 • Web Browser Client. All new system acquisition and development should 116

employ server-based thin client solutions requiring only network access and a 117 Web browser for end-user access whenever such solutions are technically 118 appropriate. Through the use of server-based applications, thin client 119 technologies (especially Web-based clients), portals, and gateways, County 120 Departments can reduce the cost and complexity of all IT functions, making it 121 easier to implement, deploy, manage, and monitor applications and 122 information resources. Server-based architecture provides the ability to rollout 123 new applications and upgrades to the entire organization simultaneously. 124

125 • Server Consolidation. To the extent possible, systems should utilize new 126

technologies and architectures that provide for a consolidated server 127 environment. Such consolidated server environment will streamline software 128 licensing, more efficient system administration, better scalability and 129 utilization planning, and provide a more effective management of storage, 130 system capacity and performance, and backup and disaster recovery. 131

132 • Service Oriented Architecture (SOA). This approach requires that County 133

and its Departments take a critical look at their operations and develop a 134 “service-based” business model. Such modularization at the business level 135




allows for the development of a systems architecture that is also modular and 136 flexible for unanticipated changes in business requirements and technology. 137 The SOA implementation shall be based on the following principles as 138 defined under California Enterprise Architecture Program Service-Oriented 139 Architecture (SOA) Master Guide: 140 1. Design for Ease of Use 141 2. Design Web services with appropriate granularity 142 3. Reassemble before Rewrite 143 4. Web services should be loosely coupled and extensible 144 5. Web services must have well-defined interfaces 145 6. Design stateless base Web services 146 7. Implement business processes via orchestrating Web services into a 147

process flow (BPEL standard) 148 8. A governance structure must be created to manage Web service 149

development and operational environments 150 9. Implement Web service security and policy enforcement standards 151

152 • Support Event-Based Processing. All new system design and 153

development should be driven by business events. Event-based processing 154 enables applications to adapt quickly to changes in business processes by 155 only changing the application component related to the changed business 156 event and strengthens linkage to the business by mirroring the actual 157 business environment. 158

159 • Support Workflow Processing. All new system design and development 160

should incorporate workflow functionality. Workflow processing enables 161 applications to incorporate functionality such as approvals within an 162 application and change processing paths through the application without 163 source code programming changes. 164

165 • Support Data Warehousing. All new system acquisition and development 166

should support the capability to develop online transaction processing (OLTP) 167 and/or data warehousing applications. These two classes of applications 168 require very different data models and make very different demands on 169 database systems. Online transaction processing focuses on quick updates of 170 the data. Often, the speed of these updates can be dramatically slowed down 171 by the processing generated by user queries. For this reason, it is best to 172 separate the data warehouse from the OLTP. In so doing, we also provide for 173 a more secure environment for both OLTP and data warehousing. 174

175 • Partitioning and Modularization of Application Components. System 176

solutions should be highly partitioned, modular in design, that are comprised 177 of components that are maximally decoupled, and that use standards-based 178 messaging protocols for communication between external and internal 179 systems. This kind of modular implementation should allow for the upgrade, 180




exchange, and reuse of products with minimal retooling or disruption to the 181 overall environment. 182

183 • Application and/or Network Security. The County requires that all 184

applications conform to the Information Security Strategic Plan: 185 http://lacounty.info/omd/q1_2007/cms1_055410.pdf. The County requires 186 that all departments and designated contractors implementing new 187 applications contact Allen Brusewitz, Chief Information Security Officer for 188 assistance in determining security requirements for the network, application 189 and associated database. Mr. Brusewitz may be reached by telephone at 190 (562) 940-3873 or by email at: [email protected]. 191

192 2. Development Standards 193

The standards presented below are preferred technologies for products 194 developed for the County. The County will consider alternate proposals that 195 deviate from the standards if an acceptable business case is presented. 196

197 • Unified Modeling Language. The use of the Unified Modeling Language 198

(UML) for system specification and modeling is highly recommended for all 199 enterprise level applications. UML is an open non-proprietary methodology 200 used for business process and organizational structure modeling that 201 promotes object-oriented software development. 202

203 • Database Management Systems (DBMS). The standard database 204

management system (DBMS) for enterprise or affinity group applications is 205 Oracle. Microsoft’s SQL Server DBMS is acceptable for department 206 applications and may be offered as an alternative for enterprise or affinity 207 group applications, but must present an acceptable business case. 208

209 • User Interface. All newly developed or acquired applications shall be 210

accessible using a standard HTTP/HTTPS browser. To the extent possible 211 and when cost-effective applications shall be browser neutral. Public Internet 212 access shall be developed to be “browser neutral” and support the latest 213 version of the browser and also be backward compatible by three (3) major 214 releases. 215

216 • Component Based Development Language. Enterprise or affinity group 217

application should utilize Java2 Enterprise Edition (J2EE) to support an open, 218 non-proprietary architecture. Department applications may utilize a .NET 219 platform. New systems should use XML-based data architectures for 220 increased standardization and data sharing, including industry specific XML 221 dictionaries and schemas (e.g., Justice XML, etc.). 222

223 • Open Architecture. All new systems should utilize an open architecture 224

using industry standards such as Web Services and XML, WSDL, SOAP, 225




UDDI, SAML, and OASIS. Also, functionality such as Transactional Integrity, 226 Monitoring, Auditing, and Security must be supported natively by the product. 227

228 • Integration Brokers and Interfaces. All interfaces and data conversions 229

involving enterprise, affinity group or departmental applications should utilize 230 one of the County’s recommended integration broker technology platforms: 231 WebSphere MQ Integrator, Cloverleaf Integration Services, and SeeBeyond. 232

233 • Web Servers / Application Development Platforms. All Web hosting for 234

enterprise and multi-department applications should utilize Apache-based 235 application servers (e.g., WebSphere, Oracle Application Server, JBOSS, 236 Tomcat, etc.) and Department applications should utilize Microsoft Internet 237 Information Servers. 238

239 • Business Intelligence Reporting Tools. New applications development or 240

acquisitions should utilize the County’s standard reporting tool Cognos suite 241 of business intelligence software. For formatted reporting embedded within 242 applications, Crystal Reports and Oracle Report tools may be used. 243

244 • Database Communication. All direct database communication shall utilize 245

ODBC, JDBC, ADO/OLEDB, or ADO.NET. 246 247

• Geographic Information Systems. Environmental Systems Research 248 Institute (ESRI) ArcGIS tools for Geographic Information Systems (GIS) and 249 mapping applications may be used. 250

251 • Storage. EMC, HP, and Network Appliance storage products may be used. 252

253 • Enterprise Content Management. Enterprise content management 254

technologies (i.e. document imaging, document capture, document 255 management, document storage, and workflow) should utilize enterprise-256 class solution suites that offer multiple technology components (e.g., EMC, 257 Global 360, FileNet P8, and Hyland OnBase). 258

259 • Electronic Forms (eForms). Adobe product suite should be used for 260

eForms solutions to internal and external users. Global 360, FileNet P8, and 261 Hyland OnBase may also be used. 262

263 3. Preferred Enterprise IT Standards and Recommendations 264 265

The following table provides a list of preferred enterprise IT standards and 266 recommendations which COUNTY may revise from time to time: 267




268

Function Preferred Enterprise IT Standards and Recommendations (Current Version)

Operating Systems Client operating system Microsoft Windows Department Server operating system

Microsoft Windows Server

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 Detection/Prevention

Cisco Network Intrusion

Host Intrusion Protection Cisco CSA and McAfee Entercept Internet Filtering BlueCoat Electronic Signature Standard to be established Digital Certificates Standard to be established Remote Access Remote Access LAnet/EN VPN Two factor authentication RSA SecurID Desktop Management Directory Services Active Directory Desktop Configuration Management

Altiris

Desktop Firewall Zone Alarm, Microsoft Office Productivity Software Desktop Office Suite Microsoft Office Word Processing Microsoft Word Spreadsheet Microsoft Excel E-mail Microsoft Outlook/Exchange




Function Preferred Enterprise IT Standards and Recommendations (Current Version)

Presentation software Microsoft PowerPoint Adobe pdf Adobe Acrobat Professional Web Browser and Content Browser Microsoft Internet Explorer 7.0, Firefox 2.0,

Netscape 9.0 and higher versions with 128 bit 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 OnBasee-Forms Adobe File Transfers File Transfer Protocols FTP, SFTP




EXHIBIT 4 – CALIFORNIA SERVICE-ORIENTED ARCHITECTURE 269 (SOA) MASTER GUIDE 270 271

272

California Enterprise Architecture 273

Program 274 275 276 277 278 279

Service-Oriented 280

Architecture (SOA) 281

282

Master Guide 283

284 285

286 Revision History 287 06/30/2006 Original Draft 288 09/11/2006 Appendix D – Legacy Integration Patterns, enhanced ESB section. 289




Table of Contents 290

SOA Documents................................................................................................19 291

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

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

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

SOA Introduction...............................................................................................23 295

The Accidental Architecture.....................................................................23 296

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

Loosely Coupled Interfaces .....................................................................24 298

SOA Architecture ..............................................................................................26 299

Web Services.............................................................................................26 300

Web Service Patterns ..........................................................................26 301

Web Service Composition...................................................................26 302

Web Service Orchestration .................................................................27 303

Web Service Types ..............................................................................27 304

Web Service Standards .......................................................................27 305

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

SOA Security .............................................................................................28 307

Identity and Authentication.................................................................28 308

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

Security Standards ..............................................................................28 310

Reference SOA Architecture ............................................................................28 311

California SOA Principles.................................................................................30 312

California Service Centers................................................................................33 313




Consolidated Service Centers .................................................................33 314

Shared Services ........................................................................................33 315

SOA Infrastructure ....................................................................................34 316

Enterprise Service Bus.............................................................................34 317

California SOA Center of Excellence...............................................................34 318

Introduction ...............................................................................................34 319

SOA Excellence Model..............................................................................36 320

SOA Tools..........................................................................................................37 321

Development Tools ...................................................................................37 322

Enterprise Repository...............................................................................37 323

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

Appendices........................................................................................................37 325

Appendix A - Federal SOA........................................................................37 326

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

Appendix C – WSDL Example ..................................................................39 328

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

Overview...............................................................................................40 330

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

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

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

Appendix E – Definitions ..........................................................................42 334




SOA Documents 335 336

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

341 342 343 There are six whitepapers plus a roadmap to address in-depth details of SOA. 344




The Business Case for SOA 345 346

Overview 347 “It’s not the strongest of the species that survive, or the most intelligent, but the ones most 348 responsive to change”. Charles Darwin 349 350 A service-oriented architecture (SOA) is a good choice for handling the “how” of business 351 services. That is, once business services are appropriately defined, they can be implemented in 352 SOA. This strongly implies that business services must first be defined and categorized which 353 means a different way of thinking about how we deliver services to constituents. Instead of 354 looking at “the business” from an isolated set of requirements and applications perspective, we 355 need to look across individual applications and determine our true business architecture. 356 357 What are the capabilities for a particular business, how are the capabilities related, and what are 358 the implications for connecting capabilities? Once business services are understood, we can 359 look for candidates for shared services. Business services can also be grouped into “service 360 centers”; for example, Health Service Center, Taxes Services Center, or a License Service 361 Center. Shared IT services reduce costs by getting rid of duplication and they also promote 362 consistency. 363 364 Many business services have multi-level government scope that may span Federal, state, 365 county, and local levels. So interoperability becomes very important. With a variety of 366 government entities involved, standards-based applications are a must. 367 368 Here is a summary of some of the business benefits of SOA: 369 370

• Increases Business Agility - SOA can enhance the ability of a business to react to 371 new regulations, policies, or opportunities and deliver innovative services to citizens and 372 businesses in a timely manner. This is possible because an SOA-enabled environment 373 is standards-based, platform neutral, and eventually, a good portion of the new 374 requirements can be met using existing shared services or aggregating existing services 375 to form a new one. 376

377 378

SOA opens the door for business and IT to engage in a much richer dialogue. By 379 focusing on what the business wants (not how it work gets done), specific parts of a 380 given business process can be delegated to different parts of the organization as well as 381 external partners. 382 383

• Reducing Business Risk and Exposure – Regulatory compliance is essentially a 384 business agility issue since legislation changes on a regular basis. Increased business 385 services flexibility in the face of changing laws and regulations is a concrete instance of 386 the business agility benefit of SOA. Specifically, SOA primarily offers a risk-reduction 387 capacity to public sector entities looking for increased operations flexibility. 388

389 390




Improved governance, compliance, and general risk reduction is a different quantifiable 391 benefit than increased business agility. Compliance and governance offers a reduction 392 of liability, while business agility offers an increase in business opportunity. 393 Implementing SOA for the purpose of improving business processes, establishing state-394 wide security, privacy, and implementation policies, and providing auditable information 395 trails, are ways that SOA can reduce several of the risks facing departments today. 396

397 • Increases Asset Reuse – One of the most important benefits of SOA is that users can 398

create new business processes and composite applications from existing services. In 399 other words, service reuse becomes the mode of operation instead of application 400 integration. Over time, as the state builds and reuses services, the ROI will increase. 401

402 403

• Encourages Effective Collaboration – SOA promotes sharing of ideas, business 404 services, solutions, best practices, frameworks, and tools across departments and 405 agencies. This results in lower overall costs, greater ROI for a given service, and a 406 higher degree of consistency from the user’s perspective. 407

408 409

• Reduces Integration Expenses – SOA provides an opportunity to migrate away from 410 monolithic, hard to change heavy business applications to light weight, loosely-coupled 411 business services. Loosely-coupled systems can reduce the complexity and hence the 412 cost of integrating and maintaining distributed computing environments. While moving to 413 standards-based interfaces such as Web Services reduces integration and cost 414 somewhat, the real win with SOA is in replacing multiple fine-grained functions with 415 coarse-grained, loosely coupled services that can handle a wider range of business 416 interactions in a more flexible manner. This results in less maintenance and upgrade 417 headaches, fewer customer complaints, and more secure systems. 418

419 420

• Reuse of Legacy Systems – By Web service enabling legacy systems, departments 421 can extend the life of and continue to take advantage of their mainframe investments 422 while allowing legacy applications to participate in a services environment. This is a key 423 strategy in moving from a predominately legacy applications environment to an SOA-424 enabled shared services environment. 425

426 427

A Business-Oriented Foundation for Services 428 The following article is a good description of how business and IT can become closer aligned. It 429 advocates that a business architecture is necessary to describe the business capabilities which 430 define “what” a business does, and SOA is a good mechanism for handling “how” the 431 capabilities are implemented. 432 433 http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-434 us/dnbda/html/ServOrient.asp . 435 Ulrich Homann - Microsoft Corporation, February 2006. 436 437




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

452




SOA Introduction 453

454

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

SOA 487 SOA has become a well-known but somewhat elusive acronym. Some describe SOA as an IT 488 infrastructure for business enablement while others look to SOA for increasing the efficiency of 489 IT. 490 491 Gartner defines SOA as “an architectural style in which certain discrete functions are packaged 492 into modular, shareable, distributable elements ("services"), which can be invoked by 493 consumers in a loosely coupled manner”. With SOA, integration becomes forethought rather 494 than afterthought—the end solution is likely to be composed of services developed in different 495 programming languages, hosted on disparate platforms with a variety of security models and 496 business processes. While this concept sounds incredibly complex it is not new—some may 497




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

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




545 546 547




SOA Architecture 548 549

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

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




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

Enterprise Service Bus (ESB) 622 Connecting systems and automating business processes are strong drivers to reducing costs, 623 improving operational efficiency, and capturing new business opportunities. For these reasons, 624 technologies that facilitate integration are a high priority for many technology executives. 625 626 Some of the more popular approaches are ETL (Extract, Transform, and Load), Batch, FTP, 627 Information Brokers, and ESB. The latter has emerged as the preferred method to connect 628 Web services as well as provide interoperability among applications, mainframe, and third party 629 systems. 630 631 ESBs are based on lessons learned from integration brokers and best practices from standards-632 based infrastructure based on XML, Web services, reliable asynchronous messaging, and 633 distributed components. These collectively form an architecture for a highly distributed, loosely 634 coupled integration fabric to deliver all the key features of an integration broker, but without the 635 barriers. 636

637 In simple terms, ESBs: 638

• Route messages between services. 639 • Convert transport protocols between requestor and service. 640




• Transform message formats between requestor and service. 641 • Handle business events from disparate sources. 642

643 644 Some ESB vendors include additional features: 645

• Service composition 646 • Business process management 647

648

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

Reference SOA Architecture 681 Establishing an Enterprise Reference Architecture is important for the big picture. SOA is a key 682 subset of the enterprise and it is sometimes not obvious where SOA fits into the enterprise. 683 That is, one can get lost in the many details and standards surrounding SOA. So, a Reference 684 SOA Architecture is provided (see following diagram). 685




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

701 702 703 In the SOA Based Services perspective, Web applications manage user interactions, and they 704 invoke services that implement business processes. Web applications invoke Web service APIs 705




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

California SOA Principles 722

723 724

1. Design for Ease of Use: Make it easy for your business solution builders to 725 assemble services into applications and business scenarios. Organize the structure of 726 the California Enterprise Repository so it can be easily searched, learned, and managed. 727 Create a business architecture (categorize and classify business services) and show 728 clearly show how SOA services relate to the business architecture. 729

730 731 2. Design Web services with appropriate granularity. The granularity of 732

operations is an important design point. The use of coarse-grained interfaces for 733 external consumption is recommended, whereas fine-grained interfaces might be used 734 inside the enterprise. A coarse-grained interface might be the complete processing for a 735 given service, such as SubmitPurchaseOrder, where the message contains all of the 736 business information needed to define a purchase order. A fine-grained interface might 737 have separate operations for: CreateNewPurchaseOrder, SetShippingAddress, AddItem, 738 and so forth. 739

740 741

While the fine-grained interface offers more flexibility to the requester application, it also 742 means that patterns of interaction may vary between different service requesters. This 743 can make support more difficult for the service provider. A coarse-grained interface 744 guarantees that the service requesters will use the service in a consistent manner. SOA 745 does not require the use of coarse-grained interfaces, but recommends their use as a 746 best practice for external integration. Service choreography can be used to create a 747 coarse-grained interface that runs a business process consisting of fine-grained 748 operations. 749 750 Granularity can be viewed from several perspectives. One perspective is the amount of 751 data sent/received. A second perspective is complexity of the interface. A third 752 perspective is the number of interactions required to complete a session. An example 753




might be a service that provides all registered voters in a county. Should it send one 754 huge list (one interaction, but a huge dataset); or send just the As then the Bs then the 755 Cs (26 interactions for consuming processes that do indeed need ALL names, but 756 smaller data sets); or one by one (eg by citizen; which could lead to thousands of 757 interactions, with very small data sets). The number of interactions required to complete 758 a "session" can also be driven by the number of steps in a composite operation, which is 759 the example used here. 760 761 Gardner recommends designing services to be as general-purpose as possible. Thus if 762 a large number of consumers would use an "all in one" SubmitPurchaseOrder, then 763 create it. But provide some "override" services so that consumers with specialized needs 764 can override the generic operation. 765

766 3. Reassemble before Rewrite. Individual Web services can be assembled into 767

composite Web services. Standard web interfaces can also be used to quickly create 768 new services. Consider reassembling existing base Web services before writing new 769 Web services. For example, Federated Jobs Service is a composite of Available Jobs 770 Service and Process Job Application Service. 771

772 773 4. Web Services should be loosely coupled and extensible. The binding from 774

the service requester to the service provider should loosely couple the service. This 775 means that the service requester has no knowledge of the technical details of the 776 provider’s implementation, such as the programming language, deployment platform, 777 and so forth. The service requester typically invokes operations by way of messages -- a 778 request message and the response -- rather than through the use of APIs or file formats. 779

780 781

“Extensibility is essential to the rapid and efficient evolution of Web service interfaces. If 782 every enhancement of a provider interface requires the redeployment of a corresponding 783 consumer interface to the thousands of existing consumers, then change management 784 will grind to a halt. The key is to architect Web service interfaces using XML and XSD 785 (XML Schema Definition) extensibility mechanisms to enable both forward and backward 786 compatibility between consumer and provider interfaces to loosely couple consumer 787 versions from provider versions”. – Gartner 2006 788

789 5. Web Services must have well-defined interfaces. The service interaction 790

must be well-defined. Web services Description Language (WSDL) is a widely-791 supported way of describing the details required by a service requester for binding to a 792 service provider. The service descriptions focus on operations used to interact with the 793 following: 794

a. A service 795 b. Messages to invoke operations 796 c. Details of constructing such messages 797 d. Information on where to send messages for processing details of constructing 798

such messages 799 800 801




WSDL should not include any technology details of the implementation of a service. The 802 service requester neither knows nor cares whether the service is written in Java code, 803 C#, COBOL, or some other programming language. It can describe a SOAP invocation 804 using HTTP. Because of its extension mechanisms, it can also define other styles of 805 interaction such as XML content delivered via JMS, direct method calls, calls handled by 806 an adapter that manages legacy code (CICS), and so forth. 807 808 The common definition for WSDL allows development tools to create common interfaces 809 for various styles of interaction, while hiding the details of how it invokes the service from 810 the application code. The Web Services Invocation Framework (WSIF), for example, 811 exploits this capability by allowing a run-time determination of the best way to invoke a 812 quality service if the service is exposed in more than one interaction style. See 813 http://ws.apache.org/wsif/ for WSIF details. 814 815

6. Design stateless base Web services. Services should be independent, self-816 contained requests, which do not require information or state from one request to 817 another when implemented. Services should not be dependent on the context or state of 818 other services. When dependencies are required, they are best defined in terms of 819 common business processes, functions, and data models, not implementation artifacts 820 (like a session key). Of course, requester applications require persistent state between 821 service invocations, but this should be separate from the base service. Web 822 applications and composite Web services can both handle state. 823

824 825

7. Implement business processes via orchestrating Web services into a 826 process flow (BPEL standard). Some business processes can be implemented in a 827 process flow and called from an application (which implements the entire business 828 process). The individual nodes within the process flow can call other Web services, call 829 out to a business rules engine, or call a native API (such as Java or .NET). Process 830 flows also manage state, which means data created by one node is available to other 831 nodes to view, add to, or modify. Additionally, process flow engines (vendor specific) 832 have built in mechanisms to recover a process flow should a system or process failure 833 occur. 834

835 836

For example, a Professional License Application might call several Web service process 837 flows (Gather Qualifications, Process Qualifications, Handle Payment, and Create 838 License) to achieve the business process functionality. 839

840 8. A governance structure must be created to manage Web service 841

development and operational environments. By definition, Web services are 842 created with the enterprise in mind. That implies a strong collaboration environment 843 exists where interested parties agree on how Web services will be defined, built, 844 implemented, deployed, supported, enhanced, and managed in production environment. 845 Additional budgets, people, tools, and equipment resources must be allocated 846 appropriately. 847

848 849

9. Implement Web service security and policy enforcement standards: 850




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

856

California Service Centers 857 858

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

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

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

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




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

California SOA Center of Excellence 901

902

Introduction 903 A successful state-wide SOA program will require both centralized and federated components. 904 Singular vision & goals, governance, enterprise repository management, and several 905 operational functions (certification lab, UDDI repository, maintain service reference model, 906 service help desk, and search taxonomy) should be centralized. Service development (and 907 possibly some SOA operations) should be federated to the producing departments. In some of 908 the above functions, centralized does not mean single instance. For example one would 909 establish at least two UDDI repositories for scalability and accessibility. 910 911 Because SOA components are designed for enterprise use, there are a number of critical 912 governance and operational issues that need to be addressed. Such as: 913 914

• How will developers be supported? 915 • How will business architects and technical architects determine which shared services 916

already exist? 917 • How will SOA services be mapped to business services? 918 • How will service versioning and release packaging be controlled? 919 • How will services be certified? 920 • How will services be tested for performance, availability, and scalability? 921 • How will services usage be monitored and reported? 922 • How will developers locate code for an existing service? 923 • How will service contract compliance among data centers be handled? 924 • Will there be a centralized, state-wide help desk? 925 • How will service troubleshooting be handled at an enterprise level? 926

(A composite service might consist of 4 services, each running in a different data 927 center.) 928

• Will there be example services and demo applications? 929 • Will there be a state-wide search service utilizing a common language? (a taxonomy)? 930

931




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

947 948 949




SOA Excellence Model 950 951

1. Standards – SOA is comprised of many standards which are managed by several 952 standard bodies. It will be very important to stay on top of standard developments since 953 they will have a large impact on SOA architecture. Attending conferences, monitoring 954 discussion groups, and regularly checking W2C, OASIS, and WS-I Websites are all key 955 activities. 956

957 958 2. Vendors & Analysts – Relationships with key vendors is important in order to keep 959

abreast of product developments and vendor visions for SOA. Subscribing to industry 960 analysts newsletters is also a good way of staying informed. 961

962 963 3. State & Federal Collaboration – The Federal Enterprise Architecture Group and its 964

ancillary operations set the standard for states to follow. Additionally, many states are in 965 the process of implementing SOA-based models. So, ongoing collaboration with other 966 states makes good sense. 967

968 969 4. Operations Feedback – The SOA vision and goals must be practical. So, feedback 970

from SOA operations must be factored into the vision and goals must be updated 971 accordingly. 972

973 974

5. Briefings & Targeted Presentations – SOA means different things to different people. 975 So, preparing presentations that are targeted to a particular group will be most effective. 976 For example, executives, business architects, technical architects, and IT developers all 977 have different priorities within SOA. So, presenting SOA in terms of specific audience 978 type would be most effective. 979

980 981

1. Demos – An SOA Center of Excellence is a great place to demonstrate the SOA 982 environment. Demos can be built to support the presentations targeted at specific 983 audiences. Often, it is easier to understand a point by witnessing a demo. Plus, a demo 984 proves out an environment and allows “what if” scenarios. 985

986 987

2. Reference Architecture – An SOA environment should exist as the model for 988 developers. That is, a reference implementation that incorporates key SOA components 989 would provide developers platform-specific components to measure their services 990 against. The Reference Architecture would include both J2EE and .NET components. 991

992 993

3. Executive SOA Discussion Group – Sponsoring an SOA discussion group for 994 executives would be one way of providing executives with an easy mechanism for 995 exchanging thoughts and ideas. 996




SOA Tools 997

Development Tools 998 A tool to model business services would be of great value. This could include business 999 process details as well as expected performance metrics. If the tool has the capability 1000 to simulate different business scenarios, it would be of even more value. 1001 1002 Equally important is a tool to model SOA services. Ideally, the output from the business 1003 modeling tool would seamlessly flow into the SOA services tool which, in turn could 1004 generate implementation code. 1005

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

Business Activity Monitoring (BAM) 1018 BAM enables organizations to leverage business analytics to gain a real-time insight into daily 1019 business operations. This analytical insight helps business users quickly identify operational 1020 inefficiencies and predict potential business problems. BAM integrates business intelligence 1021 (BI) with business transaction processing. 1022 1023 BAM enables organizations to leverage business analytics to gain a real-time insight into daily 1024 business operations. This analytical insight helps business users quickly identify operational 1025 inefficiencies and predict potential business problems. BAM integrates business intelligence 1026 (BI) with business transaction processing. 1027

Appendices 1028

1029

Appendix A - Federal SOA 1030 The Federal Architecture and Infrastructure Committee along with the Federal CIOs Council 1031 produced the Federal Enterprise Architecture which is based on SOA and Web Services. 1032 1033 “An architecture that provides for reuse of existing business services and rapid deployment of new 1034 business capabilities based on existing capital assets is often referred to as a service-oriented 1035 architecture (SOA). “ -- Federal CIOs Council 1036




For a full description of the Federal Enterprise Architecture program, please see 1037 http://www.cio.gov/documents/CIOC_AIC_Service Component Based Architectures 1038 _2.0_FINAL.pdf 1039 1040 For a broader description of the Federal E-Gov initiative please see 1041 http://www.whitehouse.gov/omb/egov/ . 1042 1043

Appendix B - SOA Advantages (Patricia Seybold Group) 1044 Brenda M. Michelson, Sr. VP 1045 1046 SOA Business Advantages: 1047

• Consistent Experience. An SOA can provide a consistent experience for customers 1048 and partners across channels and lines of business. 1049

1050 1051

• Business Agility. An SOA can add new functionality, expose functionality to new 1052 channels, and vary functionality based on context (customer, partner, entry point). 1053

1054 1055

• Mix and Match. An SOA can compose business solutions from a reusable service 1056 collection, leveraging internal and external services. 1057

1058 1059

• Optimize Interactions. An SOA can optimize business interactions for customers, 1060 partners, and internal constituents through the implementation of business scenarios 1061 (process, events, and services) versus traditional applications. 1062

1063 1064 SOA IT advantages: 1065

• Reduction of Costs. Reuse of services reduces IT development, deployment, and 1066 maintenance time and costs. 1067

1068 1069

• Leverage Existing IT Investments. Your service providers are existing code (objects, 1070 components, legacy modules, and application package APIs) and information assets 1071 (databases, files, and documents). 1072

1073 1074

• Transition Strategies. An SOA can provide application and portfolio transition 1075 strategies. 1076

1077




Appendix C – WSDL Example 1078 1079

1080 1081 1082 This is an abridged version of the WSDL for Amazon’s E-commerce Service (ECS). The 1083 annotations 1084 on the left hand-side describe the WSDL sections. The yellow boxes within the WSDL highlight 1085 key elements, such as data elements, messages and bindings, and their recurrence in the 1086 various sections. 1087

- Patricia Seybold Group 1088




1089

Appendix D – Legacy Integration Patterns 1090

Overview 1091 Mainframe applications will continue to be around for a long time and many departments 1092 depend on the mainframes for their mission critical applications. Therefore, the state must plan 1093 to integrate mainframe applications into the new SOA-based environment. Departments should 1094 take a close look at their application portfolios and devise an application maturity plan which 1095 would should separate them into categories such as don’t modify, wrap with Web service 1096 interfaces, reengineer into Java or .NET applications, or plan to retire. Following are brief 1097 discussion of three popular patterns. 1098

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




1106 1107 1108 IBM 1109 http://www-306.ibm.com/software/info1/Websphere/index.jsp?tab=landings/esb 1110 1111 Oracle 1112 http://www.oracle.com/products/middleware/index.html 1113 1114 Sonic 1115 http://www.sonicsoftware.com/index.ssp 1116 1117 Cape Clear 1118 http://www.capeclear.com/products/cc6.shtml 1119




Placing Web Service Interfaces on Existing Mainframe Apps 1120 Makes mainframe applications (particularly Natural and Adabas) look like Web services. 1121 EntireX executes on the mainframe and exposes the service interfaces. ApplinX solution 1122 requires no changes to mainframe code. 1123 1124 SoftwareAG EntireX 1125 http://www.softwareag.com/Corporate/products/entirex/default.asp 1126 1127 SoftwareAG ApplinX 1128 http://www.softwareag.com/Corporate/products/applinx/default.asp 1129

Compiling COBOL Code into Web Service Languages 1130 Fujitsu Consulting provides a COBOL compiler for a variety of platforms and languages. For 1131 example, NetCOBOL for .NET is a COBOL compiler created specifically for Microsoft's .Net 1132 Framework. This means that COBOL is just another .NET scripting language (like VB.NET, C#, 1133 J#, etc.). This allows COBOL code to be mixed with C# or VB.NET code. It compiles to 1134 Microsoft MSIL (language neutral, .NET runtime) code. 1135 1136 NetCOBOL main page 1137 http://www.netcobol.com/products/ 1138 1139 NetCOBOL for .NET 1140 http://www.netcobol.com/products/windows/netcobol.html 1141 1142

Appendix E - Definitions 1143 1144 AJAX: Asychronous JavaScripting and XML is a Web development technique for creating 1145 interactive Web pages. The intent is to make Web pages feel more responsive by exchanging 1146 small amounts of data with the server behind the scenes, so that the entire Web page does not 1147 have to be reloaded each time the user makes a change AJAX is available for Java, .NET, 1148 PHP, and other languages. 1149 http://en.wikipedia.org/wiki/AJAX 1150 Architecture: Representation of the structure of a system that describes the constituents of the 1151 system and how they interact with each other. 1152 Application Architecture: Representation of an application and its parts, their inter-1153 relationships and functions. 1154 AVDL: Application Vulnerability Description Language. 1155 http://www.oasis-open.org/specs/index.php#avdlv1.0 1156 1157 BPEL: Business Process Execution Language for Web Services provides a means to formally 1158 specify business processes and interaction protocols. BPEL provides a language for the formal 1159 specification of business processes and business interaction protocols. By doing so, it extends 1160 the Web Services interaction model and enables it to support business transactions. BPEL 1161




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




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




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




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




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




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




WS-Policy: represents a set of specifications that describe the capabilities and constraints of 1419 the security (and other business) policies on intermediaries and endpoints (e.g. required 1420 security tokens, supported encryption algorithms, privacy rules) and how to associate policies 1421 with services and endpoints. 1422 http://msdn.microsoft.com/library/default.asp?url=/library/en-1423 us/dnwssecur/html/securitywhitepaper.asp 1424 WS-Privacy: will describe a model for how Web services and requestors state privacy 1425 preferences and organizational privacy practice statements. 1426 http://msdn.microsoft.com/library/default.asp?url=/library/en-1427 us/dnwssecur/html/securitywhitepaper.asp 1428 WS-Referral: WS-Referral is a protocol that enables the routing strategies used by SOAP 1429 nodes in a message path to be dynamically configured. SOAP itself provides a distributed 1430 processing model where SOAP messages can have content destined for specific processing 1431 nodes. WS-Routing adds to SOAP the capability of describing the actual message path. WS-1432 Referral provides a mechanism to dynamically configure SOAP nodes in a message path to 1433 define how they should handle a SOAP message. It is a configuration protocol that enables 1434 SOAP nodes to delegate part or all of their processing responsibility to other SOAP nodes. 1435 http://msdn.microsoft.com/library/default.asp?url=/library/en-1436 us/dnglobspec/html/wsreferspecindex.asp 1437 WS-Reliability: Web Services Reliability (WS-Reliability) is a SOAP-based protocol for exchanging 1438 SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message 1439 ordering. WS-Reliability is defined as SOAP header extensions, and is independent of 1440 the underlying protocol. 1441 http://developers.sun.com/sw/platform/technologies/ws-reliability.html 1442 WS-ReliableMessaging: this specification describes a protocol that allows messages to be 1443 delivered reliably between distributed applications in the presence of software component, 1444 system, or network failures. The protocol is described in this specification in an independent 1445 manner, allowing it to be implemented using different network transport technologies. To 1446 support interoperable Web services, a SOAP binding is defined within this specification. 1447 http://msdn.microsoft.com/library/default.asp?url=/library/en-1448 us/dnglobspec/html/wsrmspecindex.asp 1449 WS-Routing: WS-Routing is a simple, stateless, SOAP-based protocol for routing SOAP 1450 messages in an asynchronous manner over a variety of transports like TCP, UDP, and HTTP. 1451 With WS-Routing, the entire message path for a SOAP message (as well as its return path) can 1452 be described directly within the SOAP envelope. 1453 http://msdn.microsoft.com/library/default.asp?url=/library/en-1454 us/dnglobspec/html/wsroutspecindex.asp 1455 WSRP: Web Services for Remote Portlets. 1456 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp 1457 WS-SecureConversation: describes how to manage and authenticate message exchanges 1458 between parties, including security context exchanges and establishing and deriving session 1459 keys. 1460 http://www-128.ibm.com/developerworks/library/specification/ws-secon/ 1461




WS-Security: describes how to attach signature and encryption headers to SOAP messages. In 1462 addition, it describes how to attach security tokens, including binary security tokens such as 1463 X.509 certificates and Kerberos tickets, to messages. 1464 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp 1465 WS-Security SAML Token Profile: 1466 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf 1467 WS-Transactions and WS-Coordination: describes how to enable transacted operations as 1468 part of Web service message exchanges. 1469 WS-Trust: describes a framework for trust models that enables Web services to securely 1470 interoperate by requesting, issuing, and exchanging security tokens. 1471 http://Webservices.xml.com/lpt/a/ws/2003/06/24/ws-trust.html 1472 XACML: Extensible Access Control Markup Language. 1473 http://www.oasis-open.org/specs/index.php#capv1.0 1474

Date post:	26-Jun-2015
Category:	Documents
Upload:	zubin67
View:	1,191 times
Download:	2 times