leader replacement system - Department of Public Social Services ...

LEADER REPLACEMENT SYSTEM 

Request for Proposals 

Attachment H - Technical Exhibits 

November 30, 2007 

Department of Public Social Services 

Los Angeles County 

12860 Crossroads Parkway South 

City of Industry, CA 91746-3411



LEADER Replacement System (LRS) 

NOTICE TO RFP PROPOSERS 

THIS DOCUMENT DOES NOT STAND ALONE AND MUST BE READ 

AND REVIEWED IN CONNECTION WITH ALL OTHER PARTS OF THIS 

RFP. 

LRS RFP - Attachment H (Technical Exhibits) Page i November 30, 2007




TABLE OF CONTENTS 

EXHIBIT 1 – LRS NETWORK.................................................................................................................1 

EXHIBIT 2 – COUNTY INFORMATION TECHNOLOGY (IT) STRATEGIES AND INITIATIVES ..........3 

EXHIBIT 3 – COUNTY’S CHIEF INFORMATION OFFICE (CIO) GUIDING PRINCIPLES ...................9 

EXHIBIT 4 – CALIFORNIA SERVICE-ORIENTED ARCHITECTURE (SOA) MASTER GUIDE..........16 

LRS RFP - Attachment H (Technical Exhibits) Page ii November 30, 2007




1 

2 

3 

4 

5 

6 

7 

EXHIBIT 1 – LRS NETWORK 

1.1 LRS NETWORK TOPOLOGY 

The LRS technical infrastructure shall be designed and sized to support an n-tier, Web-services application utilizing a 

service-oriented architecture (SOA). The diagram below depicts the overall network topology for the LRS and 

COUNTY’s Enterprise Network (LAnet/EN), including the Eastern Data Center and the Downey Data Center. Note: 

Downey Data Center may be relocated during Phase 1 (Design/Development/Implementation Phase). 

COUNTY-specified User 

(LAnet/EN via 

Local Office Sites) 

COUNTY-specified User 

(LAnet/EN via VPN) 

Eastern 

Data Center 

Network 

Access 

Point 

Internet Users 

(Applicants and Participants) 

Internet Users 

(General Public) 

COUNTY 

Enterprise Network 

(LAnet/EN) 

EAVEX-1 

DOWEX-1 

Network 

Access 

Point 

CONTRACTOR 

Supplied 

Connections/ 

Circuits 

POP 

POP 

Central Print Facility & 

Backup Central Print Facility 

Interface Systems 

Existing LEADER System during Phase 1 

(Design/Development/Implementation Phase) 

Downey 

Data Center 

COUNTY.Systems 

(LAnet/EN Based) 

COUNTY RESPONSIBILITY 

GATEWAY 

(CONTRACTOR 

RESPONSIBILITY) 

Interface Systems 

CONTRACTOR/ 

Internet 

Network 

Project Office 

CONTRACTOR RESPONSIBILITY 

Primary Central Site & 

Backup Central Site 

LRS RFP - Attachment H (Technical Exhibits) Page 1 November 30, 2007




8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

1.2 GATEWAY RACK 

The Gateway includes the CONTRACTOR-supplied network access points located in two (2) COUNTY sites 

approved by COUNTY Project Director, at which the LRS connects to LAnet/EN. COUNTY will provide one (1) HP 

10842 G2 Rack (42U) Wide rack (or equivalent successor) for the portion of the CONTRACTOR-supplied Gateway 

that is physically present at each of the two (2) sites. CONTRACTOR shall provide, install, maintain, and own the 

portion of the CONTRACTOR-supplied Gateway that is physically present at each of the two (2) sites, enclosed 

within the rack/cabinet described below. 

COUNTY will provide the following at each of the two (2) COUNTY sites in support of the portion of the 

CONTRACTOR-supplied Gateway that is physically present at each such site: 

1. HP 10842 G2 Rack (42U) Wide (or equivalent successor) 

• Base cabinet without options 

2. Environmental Infrastructure 

• Physical security 

• HVAC 

• Power (including redundant backup power) 

3. Physical access to the Gateway 

• 24/7 accessibility 

• Security clearance and authorization for COUNTY-approved CONTRACTOR staff 

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

1. Cabinet options for the HP 10842 G2 Rack (42U) Wide (or equivalent successor) 

2. All other goods and services for the Gateway 

Note: Current COUNTY ISD policy precludes Uninterrupted Power Supply (UPS) at the two (2) COUNTY sites at 

which the LRS connects to LAnet/EN. 





33 

34 

35 

36 

37 

38 

39 

EXHIBIT 2 – COUNTY INFORMATION TECHNOLOGY (IT) 

STRATEGIES AND INITIATIVES 

Table 1: DPSS Business Goals 

The IT strategies and initiatives for fiscal years 2006 through 2009 in support of the 

DPSS business goals are as follows: 

PROJECT TITLE 

SUMMARY OF PURPOSE 

TARGETED 

COMPLETION 

DATE 

ASH Production 

Database 

Audit Software 

Automate TANF 

Quality Control 

Universe Files in 

existing LEADER 

System 

CSBG Report 

Management System 

California Child 

Support Automated 

System Interface 

Case Management 

Information & Payroll 

System (CMIPS II) 

Customer Service 

Call Center 

DPSS Academy 

Trainee Attendance 

for Claiming Process 

System 

To allow direct notification, exchange of information, 

and transmission of electronic documents relative to 

the appeals process. 

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. 

To automate production of the monthly TANF primary 

and secondary QC universe files. 

To automate the report filing/monitoring process of the 

103 agencies that provide services to the public 

through the Community Service Block Grant program. 

To replace the interface with the COUNTY’s current 

ARS system with an interface to the statewide 

California Child Support Automated System (CCSAS). 

To establish the interface with the State system that 

provides payroll information for those individuals who 

receive In Home Supportive Services (IHSS) benefits. 

To improve service to DPSS customers by providing 

easy access to quality information and services. 

To electronically capture and transfer data regarding 

DPSS Training Academy activities and attendance for 

claiming purpose. 

12/31/2007 

11/01/2007 

04/30/2007 

07/01/2006 

09/01/2008 

09/30/2008 

07/16/2007 

11/01/2007 





PROJECT TITLE 

Departmental Data 

Warehousing Project 

Develop Direct 

Deposit 

Enhancement for 

existing LEADER 

System Vendor 

Payments 

Document Sharing 

GAIN/CalWORKs 

Domain 

Consolidation 

Electronic Benefit 

Transfer (EBT) 

System Modifications 

Expand CAST 

Document View to 

IEVS 

Feasibility Study of 

One-e-App Interface 

Process 

GEARS Contract 

Extension and 

Procurement 

Implement existing 

LEADER System 

Direct Rent for 

Participants 


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. 

To offer vendors direct deposit of payments into their 

bank account. 

To enhance the communication and document 

exchange between GAIN regional offices and 

CalWORKs offices. 

To consolidate the multiple domain names and file 

servers located throughout the Department in order to 

improve manageability and reduce costs. 

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. 

To allow for the comparison of document images from 

CAST to process IEVS abstracts more effectively. 

To evaluate the feasibility of establishing an 

automated One-e-App interface with existing LEADER 

System for the generation Medi-Cal applications. 

To complete procurement planning activities for a new 

GEARS Contract. 


in order to support direct rent payments to landlords 

for CalWORKs participants. 

TARGETED 

COMPLETION 

DATE 

06/30/2007 

04/30/2007 

06/30/2007 

05/31/2007 

10/31/2006 

07/30/2007 

04/30/2007 

12/01/2006 

04/30/2007 





PROJECT TITLE 

Improve existing 

LEADER System 

Performance 

Income and Eligibility 

Verification System 

(IEVS) Recipient 

Inventory Tracking 

Application 

LEADER 

Replacement System 

Existing LEADER 

System Technology 

Refresh 

Laptop Lifecycle 

Refresh 

Lifestyle Printer 

Refresh Project 

Lotus Notes 

Application Migration 

Lotus Notes E-Mail 

Migration to 

Exchange 

MC QMR 

MIE QA Auditor 

Enhancement 


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. 

To automate the IFDS & PVS process for abstract 

assignment, prioritization, disposition, benefit 

calculation, scheduling appointments, & generating 

reports. 

To implement a new Equipment Inventory system to 

replace the current system that is obsolete and no 

longer supported by the manufacturer. 

To complete reprocurement activities for a LEADER 

replacement system. 

To replace equipment used in the existing LEADER 

System environment that has reached the 

manufacturer’s end-of-life designation and is fully 

depreciated. 

To purchase 50 laptops in order to replace outdated 

equipment. 

To purchase 2,000 printers to replace worn or broken 

LaserJet printers. 

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. 

To migrate to Microsoft Exchange in order to achieve 

a significant reduction in administrative overhead and 

hardware cost. 


in order to establish QMB as a program separate from 

Medi-Cal. 

To utilize and enhance the Q5i software program for 

audit teams. 

TARGETED 

COMPLETION 

DATE 

04/30/2007 

09/30/2006 

06/30/2008 

06/01/2007 

06/30/2008 

06/30/2007 

06/30/2007 

12/31/2008 

12/31/2006 

TBD 

07/31/2007 





PROJECT TITLE 

Medi-Cal (MC) 

Bridging 

Network Refresh 

Oracle Contract 

Management System 

PA 2197 - Service 

Request Tracking 

Application 


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. 

To replace old switches no longer under equipment 

warranty. 

To automate the current manual system for the 

tracking of vendors and contracts. 

To automate the current PA 2197 manual process for 

the procurement of equipment and services. 

TARGETED 

COMPLETION 

DATE 

TBD 

07/31/2007 

07/31/2007 

07/31/2006 

40 

41 

42 

43 

44 

45 

46 

Pentium III Desktop 

Lifestyle 

Table 2: DCFS Business Goals 

To purchase 250 Workstations for use while broken 

equipment is being repaired or replaced. 

06/30/2007 

The IT strategies and initiatives for fiscal years 2007 through 2009 in support of the 

DCFS business goals are as follows: 

PROJECT TITLE 

Adoption Promotion and 

Support Services 

(APSS) 

Adoptions Public 

Website 

Application Express 

Conversion 

Automated Eligibility 

Determination (AED) 

California Child Support 

Automation System 

(CCSAS) Interface 

Project 

Child Caregiver 

Agreement/Performance 

Measures System 


To automate the APSS referral management, case 

management, billing, invoice, case and financial 

report functions. 

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. 

Application Express (previously know as HTMLDB) 

is a rapid Web-application development tool. This 

project will convert existing standalone 

applications. 

To automated the manual Foster Care Eligibility 

Determination process. 

To replace the current interfaces between DCFS 

and LA County of Child Support Services 

Department (CSSD). 

To streamline the process of tracking caregiver 

information and agreement related data, provide 

electronic storage of agreements and track the 

TARGETED 

COMPLETION 

DATE 

6/30/2008 

6/30/2009 

6/30/2008 

12/31/2009 

8/1/2008 

12/1/2008 


PROJECT TITLE 

Countywide Court 

Report Document 

Imaging Phase II 

DCFS Reporting 

System 

Electronic Suspected 

Child Abuse Report 

(E-SCARS) 

Family Support Services 

Foster Care Compliance 

Tracking & Alert System 

Hard Disk Encryption 

ID Management 

Incident Tracking 

System (ITrack) 

Enhancement 

Infrastructure Upgrade 

Item Control Tracking 

System 

Juvenile Court Services 

24.1 Joint Assessment 

Tracking System 

Kinship Document 

Management 

Live Scan Store and 

Forward 


caregiver’s performance measurement information. 

To expand the Court Reports Document Imaging 

pilot project. 

To re-structure the Department’s data reporting 

based on the Director’s Goals and the DCFS 

Outcome Measures. 

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. 

To automate a billing and invoice system for 

community-based agencies. 

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. 

To ensure that all Tablet PC/laptops that are 

purchased and deployed have full hard disk 

encryption. 

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. 

To modify the existing ITrack system, database 

and screens to increase the ability to provide 

statistical data. 

To upgrade the LAN infrastructure for one site to a 

100/1000 MBPS switch network. 

To automate the Item Control tracking system 

using the Department’s CWTAPPS database and 

the CWS/CMS datamart. 

To automate a system to track the number of 

referrals on youth being serviced by both DCFS 

and the Probation Department. 

To implement a Kinship electronic document 

process flow to track, control and manage all tasks 

involved in the assessment process of caregiver 

homes. 

To purchase and install a Live Scan Store and 

Forward device to be used in conjunction with 

twenty-eight Live Scan terminals. 




TARGETED 

COMPLETION 

DATE 

6/30/2008 

6/1/2008 

6/30/2008 

6/30/08 

12/31/2007 

12/31/2007 

6/30/2008 

6/1/2008 

9/1/2007 

6/30/2008 

6/30/2008 

12/31/2007 

6/30/2008 

Master Roster System - To acquire a market software product to replace 6/30/2008 

MRS 

the current mainframe Master Roster System. 

Multidisciplinary To automate a Multidisciplinary Assessment Team 6/30/2008 

Assessment Team (MAT) tracking system to populate the MAT 

(MAT) System` 

referral, and produce management reports. 





PROJECT TITLE 

Network Admission 

Control 

Office 2003 

Output Optimization 

Time Study Claiming 

System 

WCMIS Replacement 

Work Order Tracking 

System Enhancement 

Workstation 

Management 

Workstation Upgrade 


To implement Cisco Network Admission Control 

(NAC) technology to provide network based 

security policy management of all devices 

connected to DCFS networks. 

To upgrade 7000 DCFS PCs to Microsoft Office 

2003 Standard with Software Assurance. 

Purchase and install output devices, printers and 

Multi-function Devices. 

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. 

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. 

To modify the current Work Order Tracking System 

to accommodate new requirements and reports. 

Purchase, install and implement Altiris Client 

Management Suite to replace Novell ZenWorks 

software. 

Purchase workstations to replace outdated 

computers and to accommodate new staff. 

TARGETED 

COMPLETION 

DATE 

4/1/2008 

11/15/2008 

6/30/2008 

TBD 

12/1/2008 

3/1/2008 

TBD 

12/31/2007 





47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

EXHIBIT 3 – COUNTY’S CHIEF INFORMATION OFFICE (CIO) GUIDING 

PRINCIPLES 

LOS ANGELES COUNTY 

CHIEF INFORMATION OFFICE 

Guiding Principles for Systems Acquisition and Development 

Federated Governance Model 

To ensure that Information Technology (IT) resources deliver maximum business value, 

the County employs a federated structure to manage information technology. Reflecting 

the overall business model of decentralized County management, the federated 

approach balances the benefits of local autonomy with the advantages of enterprisewide 

IT coordination and management. It simultaneously allows responsiveness to 

business issues and accountability to local management, while establishing a 

convergent IT direction and optimized infrastructure. This approach keeps decisionmaking 

as close as possible to the business unit while integrating the fabric of the 

County technology infrastructure, electronic data, and horizontal processes. 

The County’s Federated Governance Model recognizes three levels: 

• Enterprise – policy, standards, infrastructure, enterprise systems, security, and 

telecommunications. 

• Affinity Group – processes, systems, and data shared between multiple 

departments. 

• Department – systems internal to a specific department or functional area. 

Each of these three tiers represents varying blends of integration and autonomy. At 

each level, an IT function is autonomous except as it relates to the tiers(s) above, and 

complies with information technology policies, standards, conventions and practices for 

purposes of business processes and systems integration. 

1. Guiding Principles for System Acquisition and Development 

The County’s Chief Information Office has developed the following principles for 

new system acquisitions and system development. 

• Open Standards. All new system acquisition and development should 

employ products or solutions that use open industry standards to facilitate 

interoperability between applications, systems and organizations. Open 

standards are technology specifications that are publicly available and 

affirmed by an industry-recognized standards body. The use of open 

standards that allow for interoperability between applications and vendorspecific 

products and will ensure their flexibility and adaptability to changing 

business needs. 





91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

110 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 

121 

122 

123 

124 

125 

126 

127 

128 

129 

130 

131 

132 

133 

134 

135 

• Industry-Proven Technology. All new system acquisition and infrastructure 

should use commercially viable, industry-proven, widely-used technology to 

the maximum extent possible. Use of industry-proven, widely-used 

technology allows for easier access to affordable skills and a large base of 

proven software solutions. It can reduce risk, and helps ensure robust product 

support. Wherever practical, the County should implement commercial-offthe-shelf 

technology as a first preference over completely custom 

applications. Open Source software should only be used when a viable set of 

commercial vendors have committed to support it. 

• Countywide Network Backbone. The Los Angeles County Enterprise 

Network (LAnet-EN) will be used as countywide network backbone for 

applications and services to foster greater collaboration and sharing of data 

between County departments and agencies. The County uses the TCP/IP 

family of protocols as the standard network protocol to ensure technical 

compatibility and efficient use of the available data transport resources. 

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

should employ a multi-tiered architecture that separates presentation, 

business logic, database and other services into logical components. A multitiered 

architecture provides architectural flexibility from many perspectives 

including scalability to meet future growth needs, selection of different 

platforms to meet potential changes to technology standards and directions, 

and minimization of technology obsolescence. 

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

employ server-based thin client solutions requiring only network access and a 

Web browser for end-user access whenever such solutions are technically 

appropriate. Through the use of server-based applications, thin client 

technologies (especially Web-based clients), portals, and gateways, County 

Departments can reduce the cost and complexity of all IT functions, making it 

easier to implement, deploy, manage, and monitor applications and 

information resources. Server-based architecture provides the ability to rollout 

new applications and upgrades to the entire organization simultaneously. 

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

technologies and architectures that provide for a consolidated server 

environment. Such consolidated server environment will streamline software 

licensing, more efficient system administration, better scalability and 

utilization planning, and provide a more effective management of storage, 

system capacity and performance, and backup and disaster recovery. 

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

and its Departments take a critical look at their operations and develop a 

“service-based” business model. Such modularization at the business level 





136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 

161 

162 

163 

164 

165 

166 

167 

168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

allows for the development of a systems architecture that is also modular and 

flexible for unanticipated changes in business requirements and technology. 

The SOA implementation shall be based on the following principles as 

defined under California Enterprise Architecture Program Service-Oriented 

Architecture (SOA) Master Guide: 

1. Design for Ease of Use 

2. Design Web services with appropriate granularity 

3. Reassemble before Rewrite 

4. Web services should be loosely coupled and extensible 

5. Web services must have well-defined interfaces 

6. Design stateless base Web services 

7. Implement business processes via orchestrating Web services into a 

process flow (BPEL standard) 

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

development and operational environments 

9. Implement Web service security and policy enforcement standards 

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

development should be driven by business events. Event-based processing 

enables applications to adapt quickly to changes in business processes by 

only changing the application component related to the changed business 

event and strengthens linkage to the business by mirroring the actual 

business environment. 

• Support Workflow Processing. All new system design and development 

should incorporate workflow functionality. Workflow processing enables 

applications to incorporate functionality such as approvals within an 

application and change processing paths through the application without 

source code programming changes. 

• Support Data Warehousing. All new system acquisition and development 

should support the capability to develop online transaction processing (OLTP) 

and/or data warehousing applications. These two classes of applications 

require very different data models and make very different demands on 

database systems. Online transaction processing focuses on quick updates of 

the data. Often, the speed of these updates can be dramatically slowed down 

by the processing generated by user queries. For this reason, it is best to 

separate the data warehouse from the OLTP. In so doing, we also provide for 

a more secure environment for both OLTP and data warehousing. 

• Partitioning and Modularization of Application Components. System 

solutions should be highly partitioned, modular in design, that are comprised 

of components that are maximally decoupled, and that use standards-based 

messaging protocols for communication between external and internal 

systems. This kind of modular implementation should allow for the upgrade, 





181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 

217 

218 

219 

220 

221 

222 

223 

224 

225 

exchange, and reuse of products with minimal retooling or disruption to the 

overall environment. 

• Application and/or Network Security. The County requests that 

departments implementing new applications contact Allen Brusewitz, Chief 

Information Security Officer for assistance in determining security 

requirements for the network, application and associated database. Mr. 

Brusewitz may be reached by telephone at (562) 940-3873 or by email at: 

ABrusewitz@cio.lacounty.gov. 

2. Development Standards 

The standards presented below are preferred technologies for products 

developed for the County. The County will consider alternate proposals that 

deviate from the standards if an acceptable business case is presented. 

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

(UML) for system specification and modeling is highly recommended for all 

enterprise level applications. UML is an open non-proprietary methodology 

used for business process and organizational structure modeling that 

promotes object-oriented software development. 

• Database Management Systems (DBMS). The standard database 

management system (DBMS) for enterprise or affinity group applications is 

Oracle. Microsoft’s SQL Server DBMS is acceptable for department 

applications and may be offered as an alternative for enterprise or affinity 

group applications, but must present an acceptable business case. 

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

accessible using a standard HTTP/HTTPS browser. To the extent possible 

and when cost-effective applications shall be browser neutral. Public Internet 

access shall be developed to be “browser neutral” and support the latest 

version of the browser and also be backward compatible by three (3) major 

releases. 

• Component Based Development Language. Enterprise or affinity group 

application should utilize Java2 Enterprise Edition (J2EE) to support an open, 

non-proprietary architecture. Department applications may utilize a .NET 

platform. New systems should use XML-based data architectures for 

increased standardization and data sharing, including industry specific XML 

dictionaries and schemas (e.g., Justice XML, etc.). 

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

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

UDDI, SAML, and OASIS. Also, functionality such as Transactional Integrity, 

Monitoring, Auditing, and Security must be supported natively by the product. 





226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 

261 

262 

263 

264 

265 

• Integration Brokers and Interfaces. All interfaces and data conversions 

involving enterprise, affinity group or departmental applications should utilize 

one of the County’s recommended integration broker technology platforms: 

WebSphere MQ Integrator, Cloverleaf Integration Services, and SeeBeyond. 

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

enterprise and multi-department applications should utilize Apache-based 

application servers (e.g., WebSphere, Oracle Application Server, JBOSS, 

Tomcat, etc.) and Department applications should utilize Microsoft Internet 

Information Servers. 

• Business Intelligence Reporting Tools. New applications development or 

acquisitions should utilize the County’s standard reporting tool Cognos suite 

of business intelligence software. For formatted reporting embedded within 

applications, Crystal Reports and Oracle Report tools may be used. 

• Database Communication. All direct database communication shall utilize 

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

• Geographic Information Systems. Environmental Systems Research 

Institute (ESRI) ArcGIS tools for Geographic Information Systems (GIS) and 

mapping applications may be used. 

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

• Enterprise Content Management. Enterprise content management 

technologies (i.e. document imaging, document capture, document 

management, document storage, and workflow) should utilize enterpriseclass 

solution suites that offer multiple technology components (e.g., EMC, 

Global 360, FileNet P8, and Hyland OnBase). 

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

eForms solutions to internal and external users. Global 360, FileNet P8, and 

Hyland OnBase may also be used. 

3. Preferred Enterprise IT Standards and Recommendations 

The following table provides a list of preferred enterprise IT standards and 

recommendations: 


266 

Function 

Operating Systems 

Client operating system 

Department Server operating 

system 

Enterprise/Mid-Range 




Preferred Enterprise IT Standards and 

Recommendations (Current Version) 

Microsoft Windows 

Microsoft Windows Server 

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 

Patch Management 

Anti-spam 

Firewall 

Network Intrusion 

Detection/Prevention 

Host Intrusion Protection 

Internet Filtering 

Electronic Signature 

Digital Certificates 

Remote Access 

Remote Access 

Two factor authentication 

Desktop Management 

Directory Services 

Desktop Configuration 

Management 

Desktop Firewall 

Office Productivity Software 

Desktop Office Suite 

Word Processing 

Spreadsheet 

E-mail 

Symantec, Network Associates (McAfee) 

PatchLink and Altiris 

BrightMail 

Cisco PIX Firewalls 

Cisco Network Intrusion 

Cisco CSA and McAfee Entercept 

BlueCoat 

Standard to be established 

Standard to be established 

LAnet/EN VPN 

RSA SecurID 

Active Directory 

Altiris 

Zone Alarm, Microsoft 

Microsoft Office 

Microsoft Word 

Microsoft Excel 

Microsoft Outlook/Exchange 





Function 

Presentation software 

Adobe pdf 

Preferred Enterprise IT Standards and 

Recommendations (Current Version) 

Microsoft PowerPoint 

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 

Database software 

Business Intelligence 

Ad hoc Report Writer 

Applications 

GIS 

Document Management 

e-Forms 

File Transfers 

File Transfer Protocols 

SQL compliant 

Oracle and Microsoft SQL Server 

Cognos Business Intelligence Product Suite 

Cognos Business Intelligence Product Suite 

ESRI Arc Tools 

EMC, Global 360, FileNet P8, and Hyland OnBase 

Adobe 

FTP, SFTP 





267 

268 

269 

EXHIBIT 4 – CALIFORNIA SERVICE-ORIENTED ARCHITECTURE 

(SOA) MASTER GUIDE 

270 

271 

272 

273 

274 

275 

276 

277 

278 

279 

California Enterprise Architecture 

Program 

Service-Oriented 

Architecture (SOA) 

280 

281 

282 

283 

Master Guide 

284 

285 

286 

287 

Revision History 

06/30/2006 Original Draft 

09/11/2006 Appendix D – Legacy Integration Patterns, enhanced ESB section. 





288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

Table of Contents 

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

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

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

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

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

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

SOA ............................................................................................................23 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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





312 

313 

314 

315 

316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

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

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

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

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

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

Introduction ...............................................................................................34 

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

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

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

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

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

Appendices........................................................................................................37 

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

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

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

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

Overview...............................................................................................40 

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

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

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

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





333 

334 

335 

336 

337 

338 

SOA Documents 

The service oriented architecture advocated by the California Enterprise Architecture Program is 

organized into a set of interrelated documents. A master guide serves as the “jumping off point” 

and describes in an overview fashion the key parts of SOA. 

339 

340 

341 

342 

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





343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 

382 

383 

384 

385 

386 

387 

388 

The Business Case for SOA 

Overview 

“It’s not the strongest of the species that survive, or the most intelligent, but the ones most 

responsive to change”. Charles Darwin 

A service-oriented architecture (SOA) is a good choice for handling the “how” of business 

services. That is, once business services are appropriately defined, they can be implemented in 

SOA. This strongly implies that business services must first be defined and categorized which 

means a different way of thinking about how we deliver services to constituents. Instead of 

looking at “the business” from an isolated set of requirements and applications perspective, we 

need to look across individual applications and determine our true business architecture. 

What are the capabilities for a particular business, how are the capabilities related, and what are 

the implications for connecting capabilities? Once business services are understood, we can 

look for candidates for shared services. Business services can also be grouped into “service 

centers”; for example, Health Service Center, Taxes Services Center, or a License Service 

Center. Shared IT services reduce costs by getting rid of duplication and they also promote 

consistency. 

Many business services have multi-level government scope that may span Federal, state, 

county, and local levels. So interoperability becomes very important. With a variety of 

government entities involved, standards-based applications are a must. 

Here is a summary of some of the business benefits of SOA: 

• Increases Business Agility - SOA can enhance the ability of a business to react to 

new regulations, policies, or opportunities and deliver innovative services to citizens and 

businesses in a timely manner. This is possible because an SOA-enabled environment 

is standards-based, platform neutral, and eventually, a good portion of the new 

requirements can be met using existing shared services or aggregating existing services 

to form a new one. 

SOA opens the door for business and IT to engage in a much richer dialogue. By 

focusing on what the business wants (not how it work gets done), specific parts of a 

given business process can be delegated to different parts of the organization as well as 

external partners. 

• Reducing Business Risk and Exposure – Regulatory compliance is essentially a 

business agility issue since legislation changes on a regular basis. Increased business 

services flexibility in the face of changing laws and regulations is a concrete instance of 

the business agility benefit of SOA. Specifically, SOA primarily offers a risk-reduction 

capacity to public sector entities looking for increased operations flexibility. 





389 

390 

391 

392 

393 

394 

395 

396 

397 

398 

399 

400 

401 

402 

403 

404 

405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 

422 

423 

424 

425 

426 

427 

428 

429 

430 

431 

432 

433 

434 

435 

A Business-Oriented Foundation for Services 

Improved governance, compliance, and general risk reduction is a different quantifiable 

benefit than increased business agility. Compliance and governance offers a reduction 

of liability, while business agility offers an increase in business opportunity. 

Implementing SOA for the purpose of improving business processes, establishing statewide 

security, privacy, and implementation policies, and providing auditable information 

trails, are ways that SOA can reduce several of the risks facing departments today. 

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

create new business processes and composite applications from existing services. In 

other words, service reuse becomes the mode of operation instead of application 

integration. Over time, as the state builds and reuses services, the ROI will increase. 

• Encourages Effective Collaboration – SOA promotes sharing of ideas, business 

services, solutions, best practices, frameworks, and tools across departments and 

agencies. This results in lower overall costs, greater ROI for a given service, and a 

higher degree of consistency from the user’s perspective. 

• Reduces Integration Expenses – SOA provides an opportunity to migrate away from 

monolithic, hard to change heavy business applications to light weight, loosely-coupled 

business services. Loosely-coupled systems can reduce the complexity and hence the 

cost of integrating and maintaining distributed computing environments. While moving to 

standards-based interfaces such as Web Services reduces integration and cost 

somewhat, the real win with SOA is in replacing multiple fine-grained functions with 

coarse-grained, loosely coupled services that can handle a wider range of business 

interactions in a more flexible manner. This results in less maintenance and upgrade 

headaches, fewer customer complaints, and more secure systems. 

• Reuse of Legacy Systems – By Web service enabling legacy systems, departments 

can extend the life of and continue to take advantage of their mainframe investments 

while allowing legacy applications to participate in a services environment. This is a key 

strategy in moving from a predominately legacy applications environment to an SOAenabled 

shared services environment. 

The following article is a good description of how business and IT can become closer aligned. It 

advocates that a business architecture is necessary to describe the business capabilities which 

define “what” a business does, and SOA is a good mechanism for handling “how” the 

capabilities are implemented. 

http://msdn.microsoft.com/architecture/default.aspx?pull=/library/enus/dnbda/html/ServOrient.asp 

. 

Ulrich Homann - Microsoft Corporation, February 2006. 





436 

437 

438 

439 

440 

441 

442 

443 

444 

445 

446 

447 

448 

449 

SOA and Gartner “Hype Cycle” 

Gartner produces “hype cycle” diagrams for a variety of topics. They are intended to show 

where a given item fits within a maturity curve. They contrast the visibility of an item with a predefined 

set of maturity points identified as Technology Trigger, Peak of Inflated Expectations, 

Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity which represent 

the beginning and ending of the maturity curve. 

Following, is the Gartner “Hype Cycle for Government, 2005”. It depicts SOA in the “Trough of 

Disillusionment” meaning many public sector entities are in the process of figuring out how to 

capitalize on the benefits of SOA. In contrast, many private industry companies would position 

SOA in the “Slope of Enlightenment” phase. For example, see The Hartford: Lessons From 3 

Years of Work On SOA . 

450 





451 

452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 

464 

465 

466 

467 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 

478 

479 

480 

481 

482 

483 

484 

485 

486 

487 

488 

489 

490 

491 

492 

493 

494 

495 

SOA Introduction 

The Accidental Architecture 

Over the past two decades, numerous distributed computing models arrived on the scene, 

including DCE, CORBA, DCOM, MM, EAI brokers, J2EE, .NET, and Web services. However, 

indications are that only a small percentage of enterprise applications are connected, regardless 

of the technology being used. According to a research report from Gartner Inc. ("Integration 

Brokers, Application Servers and APSs" 10/2002), number less than 10%. 

Another surprising statistic - of the applications that are connected, only 15% are using formal 

integration middleware. The rest are using the ETL and batch file transfer techniques, which 

are largely based on hand-coded scripting and other custom solutions. 

The Gartner statistics provide sobering data points that illustrates the true state of integration 

today. How are the other 85% of applications connected? A very common situation that exists 

in enterprises today is referred to as "the accidental architecture." 

The accidental architecture is something that nobody sets out to create; instead, it's the result of 

years of accumulating one-of-a-kind pointed integration solutions. In an accidental architecture, 

corporate or organizational applications are perpetually locked into an inflexible integration 

infrastructure. They continue to be treated as "silos" of information because the integration 

infrastructure can't adapt to new business requirements. 

Most integration attempts start out with a deliberate design, but over time, other pieces are 

bolted on and "integrated," and the handcrafted integration code drifts away from the original 

intent. Through incremental patches and bolt-ons, integrated systems can lose their design 

integrity, especially if the system is maintained by a large number of people to whom the original 

design intent may not have been well communicated. It's a fact that individual point-to-point 

integrations will drift away from consistency, as engineers make "just this one little change" 

that's expedient at the time. Eventually, it becomes difficult to even identify the points for 

making changes, and to understand what the side effects would be as a result. In a deployed 

system this can lead to disastrous results that will negatively affect your business. 

Above excerpts from – David A. Chappell (Sonic Software) “Enterprise Service Bus” 2004 

SOA 

SOA has become a well-known but somewhat elusive acronym. Some describe SOA as an IT 

infrastructure for business enablement while others look to SOA for increasing the efficiency of 

IT. 

Gartner defines SOA as “an architectural style in which certain discrete functions are packaged 

into modular, shareable, distributable elements ("services"), which can be invoked by 

consumers in a loosely coupled manner”. With SOA, integration becomes forethought rather 

than afterthought—the end solution is likely to be composed of services developed in different 

programming languages, hosted on disparate platforms with a variety of security models and 

business processes. While this concept sounds incredibly complex it is not new—some may 





496 

497 

498 

499 

500 

501 

502 

503 

504 

505 

506 

507 

508 

509 

510 

511 

512 

513 

514 

515 

516 

517 

518 

519 

520 

521 

522 

523 

524 

525 

526 

527 

528 

529 

530 

531 

532 

533 

534 

535 

536 

537 

538 

539 

540 

541 

542 

argue that SOA evolved out of the experiences associated with designing and developing 

distributed systems based on previously available technologies. 

The acronym SOA prompts an obvious question—what, exactly, is a service? Simply put, a 

service is a program that can be interacted with through well-defined message exchanges. 

Services must be designed for both availability and stability. Services are built to last while 

service configurations and aggregations are built for change. Agility is often promoted as one of 

the biggest benefits of SOA—an organization with business processes implemented on a 

loosely-coupled infrastructure is much more open to change than an organization constrained 

by underlying monolithic applications that require weeks to implement the smallest change. 

Loosely-coupled processes and loosely-coupled information structures result in loosely-coupled 

systems. 

Services and their associated interfaces are designed to be re-configured or re-aggregated to 

meet the ever-changing needs of business. Services remain stable by relying upon standardsbased 

interfaces and well-defined messages—in other words, SOAP and XML schemas for 

message definition. Services designed to perform simple, granular functions with limited 

knowledge of how messages are passed to or retrieved from them are much more likely to be 

reused within a larger SOA infrastructure. 

SOA and Web Services have recently been used interchangeably. That is because most of the 

SOA standards work has focused on Web services. New standards are emerging and new 

vendor products are now available that focus on Enterprise Service Bus concepts. For 

example, major technology companies are currently working on Service Data Objects. SDOs 

will enable uniform access to application data and a common programming model for all data 

sources, wherever and however the data is stored. SDOs leverage the simplicity of XML 

without introducing the complexity of XML Schema or the performance issues of serialization. 

Using SDOs and SOA together, systems programming tasks are separated from the business 

logic and encapsulated in reusable services. They simplify business application programming 

without getting pulled into technology or implementation details. 

Loosely Coupled Interfaces 

Most current applications interact via tightly coupled interfaces. This requires the calling 

application to know language specific and datatype details of the target application (for example, 

Java API). This makes maintenance more difficult and the notion of shared services built on 

tightly coupled interfaces very difficult. 

Loosely coupled interfaces use industry standard XML messages to communicate. This 

process uses a messaging broker (or backbone) to handle the delivery details. This is often 

referred to as an Enterprise Service Bus. 

SOA Web services are based on loosely coupled interfaces. XML messaging is the core of 

Web services. There are many WS* standards that define the different types of XML content. 

The above paragraphs address loose coupling from a technical perspective. It should be noted 

that business processes and information can (and usually are) designed for only a limited set of 

consuming applications. Thus, they are tightly-coupled limiting their usefulness. 





543 

544 

545 





546 

547 

548 

549 

550 

551 

552 

553 

554 

555 

556 

557 

558 

559 

560 

561 

562 

563 

564 

565 

566 

567 

568 

569 

570 

571 

572 

573 

574 

575 

576 

577 

578 

579 

580 

581 

582 

583 

584 

585 

586 

587 

588 

589 

590 

591 

SOA Architecture 

SOA presents the big picture of what you can do with Web services. Web services 

specifications define the details needed to implement services and interact with them. However, 

SOA is an approach to build distributed systems that deliver application functionality as services 

to end-user applications or to build other services. SOA can be based on Web services, but it 

may use other technologies instead. In using SOA to design distributed applications, you can 

expand the use of Web services from simple client-server models to systems of arbitrary 

complexity. 

Thus, individual software assets become the building blocks to develop other applications. You 

can reduce the complexity of systems by using a common style of interaction that works with 

both new and legacy code. There is a standard way of representing and interacting with these 

software assets; now the focus shifts to application assembly based on these building blocks. 

Web Services 

Web services are a great example of how IT can better support business goals. One way is to 

consolidate like business functionality which currently is spread across many applications into 

shared services. This not only saves IT costs, but it makes it much easier to implement a 

change to a business process. If the shared services are architected correctly, they can be 

reused and repurposed to fit many business scenarios resulting in a much richer user 

experience. 

Web services are a core component of SOA. They are XML message-based, defined by 

industry standards, and are supported by practically every vendor. 

Please see Web Services White Paper for a detailed discussion of all the components that 

make up Web services. Following, are some highlights. 

Web Service Patterns 

Shared business services are implemented as atomic, composite, federated, or orchestrated 

Web services. Each of these patterns has a specific purpose and together, they provide a great 

deal of service flexibility. Very simple to large, complex business processes can be 

implemented using the above patterns. By definition, they are designed to be shared, 

aggregated, and repurposed making it much easier and faster to implement business change. 

Please see SOA Service Patterns White Paper for all the details. 

Web Service Composition 

The lowest level (and therefore, the most simple) Web services are called atomic. In order to 

achieve maximum reuse, atomic Web services can be aggregated (composed) into larger, 

broader-purposed services. 

The capability to combine simpler services into larger more complex ones is a very powerful 

concept. 





592 

593 

594 

595 

596 

597 

598 

599 

600 

601 

602 

603 

604 

605 

606 

607 

608 

609 

610 

611 

612 

613 

614 

615 

616 

617 

618 

619 

620 

621 

622 

623 

624 

625 

626 

627 

628 

629 

630 

631 

632 

633 

634 

635 

636 

637 

638 

Web Service Orchestration 

Atomic, composite, and federated Web services may all be developed using a specification 

language such as Business Process Execution Language (BPEL) and executed by a workflow 

engine (usually part of the SOA infrastructure). That is, individual Web services may be 

executed in a certain order (orchestrated) to fulfill a specific business process. 

Web Service Types 

There are two basic types of Web services: SOAP and REST. Currently, SOAP is the more 

common, but REST is rapidly gaining momentum. 

SOAP is a standard that defines how XML messages are transmitted over specific protocols. 

For example, SOAP over HTTP or SOAP over JMS (Java). SOAP acts like an envelope that 

carries a variety of XML messages each with a particular purpose. For example, there are XML 

messages (schemas) for handling security. SOAP messages can handle complex data objects, 

such as customer, payment, or license details. 

REST typically handles simpler XML messages and therefore, is more efficient because they 

require little overhead. However, currently REST is limited to the HTTP protocol. 

Web Service Standards 

There are two main organizations that define Web service standards: 

W3C - World Wide Web Consortium http://www.w3.org/ . 

OASIS – Organization for the Advancement of Structured Information Standards 

http://www.oasis-open.org/home/index.php . 

There are many standards for the various parts of Web services. Please refer to the Web 

Services White Paper for a fairly complete description of the standards as well as links to more 

detailed information. 

Enterprise Service Bus (ESB) 

Connecting systems and automating business processes are strong drivers to reducing costs, 

improving operational efficiency, and capturing new business opportunities. For these reasons, 

technologies that facilitate integration are a high priority for many technology executives. 

Some of the more popular approaches are ETL (Extract, Transform, and Load), Batch, FTP, 

Information Brokers, and ESB. The latter has emerged as the preferred method to connect 

Web services as well as provide interoperability among applications, mainframe, and third party 

systems. 

ESBs are based on lessons learned from integration brokers and best practices from standardsbased 

infrastructure based on XML, Web services, reliable asynchronous messaging, and 

distributed components. These collectively form an architecture for a highly distributed, loosely 

coupled integration fabric to deliver all the key features of an integration broker, but without the 

barriers. 

In simple terms, ESBs: 

• Route messages between services. 

• Convert transport protocols between requestor and service. 





639 

640 

641 

642 

643 

644 

645 

646 

647 

648 

649 

650 

651 

652 

653 

654 

655 

656 

657 

658 

659 

660 

661 

662 

663 

664 

665 

666 

667 

668 

669 

670 

671 

672 

673 

674 

675 

676 

677 

678 

679 

680 

681 

682 

683 

• Transform message formats between requestor and service. 

• Handle business events from disparate sources. 

Some ESB vendors include additional features: 

• Service composition 

• Business process management 

SOA Security 

Because SOA is XML message-based, security in the SOA world is handled via specific 

sections within an XML message. WS-Security from OASIS defines the mechanism for 

including integrity, confidentiality, and single message authentication features within a SOAP 

message. WS-Security makes use of the XML Signature and XML Encryption specifications and 

defines how to include digital signatures, message digests, and encrypted data in a SOAP 

message. 

Identity and Authentication 

Authentication means verifying the identity of a user. The Web service security standards allow 

for the notion of identity authorities and trusted relationships. That is, an identity service can be 

federated among departments; however there is only one authority for a given type of identity 

(for example, a Citizen Authority which would be the single point of authenticating any citizen 

performing an interaction requiring security). Other citizen-based applications would trust this 

authentication and not re-authenticate as the user’s interactions invoke different applications. 

SAML (Security Access Markup Language) 

Security Assertion Markup Language (SAML) from OASIS provides a means for partner 

applications to share user authentication and authorization information. This is essentially the 

single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. 

In the absence of any standard protocol on sharing authentication information, vendors normally 

use cookies in HTTP communication to implement SSO. With the advent of SAML, this same 

data can be wrapped inside XML in a standard way, so that cookies are not needed and 

interoperable SSO can be achieved. 

SAML is an XML vocabulary that defines the syntax necessary to exchange identity information 

between applications. 

Security Standards 

There are many Web service security standards. Please see the Security Standards for Web 

Services section in the SOA Security White Paper for detailed descriptions. 

Reference SOA Architecture 

Establishing an Enterprise Reference Architecture is important for the big picture. SOA is a key 

subset of the enterprise and it is sometimes not obvious where SOA fits into the enterprise. 

That is, one can get lost in the many details and standards surrounding SOA. So, a Reference 

SOA Architecture is provided (see following diagram). 





684 

685 

686 

687 

688 

689 

690 

691 

692 

693 

694 

695 

696 

697 

698 

Note Web services can be either internal or external to an organization. Using services 

developed and made public by other organizations is highly encouraged to reduce duplication of 

resources. 

From a security perspective, it is desirable to put as much in the Internal tier as possible. Only 

components located in the DMZ are accessible via the Internet. The DMZ could be architected 

to provide different levels of security based on profile group. Proxy services and security 

policies could be applied at the Web server level. 

Traditional API/Batch Based Services are contrasted to SOA Based Services. The traditional 

environment reflects current “stove-pipe” applications and their complex (and duplicative) 

infrastructure. It is noted that these applications should have a retirement strategy which 

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 

invoke services that implement business processes. Web applications invoke Web service APIs 





704 

705 

706 

707 

708 

709 

710 

711 

712 

713 

714 

715 

716 

717 

718 

719 

720 

721 

722 

723 

724 

725 

726 

727 

728 

729 

730 

731 

732 

733 

734 

735 

736 

737 

738 

739 

740 

741 

742 

743 

744 

745 

746 

747 

748 

749 

750 

751 

via XML interfaces which are message based. A proxy mirrors the actual Web service interface. 

Web services are defined in a Web Services Description Language (WSDL) document which 

may be registered in a Universal Description Discovery and Integration (UDDI) repository (which 

provides location services). 

Services should be implemented in the Internal tier. The XML messages are processed by the 

messaging infrastructure when the appropriate service is called by a business process. An 

XML Firewall could be deployed to look inside SOAP messages and enforce the security 

section of the message. Web services are implemented as a Business Component in a specific 

language (.NET/C# or J2EE/Java). Access Services handle formatting and communications 

among data sources including packaged applications, rules, report, and security servers. 

This document does not address the complex issue of data management. This is a large topic 

which needs proper attention to fully realize the potential of an SOA Based Services 

environment. 

California SOA Principles 

1. Design for Ease of Use: Make it easy for your business solution builders to 

assemble services into applications and business scenarios. Organize the structure of 

the California Enterprise Repository so it can be easily searched, learned, and managed. 

Create a business architecture (categorize and classify business services) and show 

clearly show how SOA services relate to the business architecture. 

2. Design Web services with appropriate granularity. The granularity of 

operations is an important design point. The use of coarse-grained interfaces for 

external consumption is recommended, whereas fine-grained interfaces might be used 

inside the enterprise. A coarse-grained interface might be the complete processing for a 

given service, such as SubmitPurchaseOrder, where the message contains all of the 

business information needed to define a purchase order. A fine-grained interface might 

have separate operations for: CreateNewPurchaseOrder, SetShippingAddress, AddItem, 

and so forth. 

While the fine-grained interface offers more flexibility to the requester application, it also 

means that patterns of interaction may vary between different service requesters. This 

can make support more difficult for the service provider. A coarse-grained interface 

guarantees that the service requesters will use the service in a consistent manner. SOA 

does not require the use of coarse-grained interfaces, but recommends their use as a 

best practice for external integration. Service choreography can be used to create a 

coarse-grained interface that runs a business process consisting of fine-grained 

operations. 

Granularity can be viewed from several perspectives. One perspective is the amount of 

data sent/received. A second perspective is complexity of the interface. A third 

perspective is the number of interactions required to complete a session. An example 





752 

753 

754 

755 

756 

757 

758 

759 

760 

761 

762 

763 

764 

765 

766 

767 

768 

769 

770 

771 

772 

773 

774 

775 

776 

777 

778 

779 

780 

781 

782 

783 

784 

785 

786 

787 

788 

789 

790 

791 

792 

793 

794 

795 

796 

797 

798 

799 

might be a service that provides all registered voters in a county. Should it send one 

huge list (one interaction, but a huge dataset); or send just the As then the Bs then the 

Cs (26 interactions for consuming processes that do indeed need ALL names, but 

smaller data sets); or one by one (eg by citizen; which could lead to thousands of 

interactions, with very small data sets). The number of interactions required to complete 

a "session" can also be driven by the number of steps in a composite operation, which is 

the example used here. 

Gardner recommends designing services to be as general-purpose as possible. Thus if 

a large number of consumers would use an "all in one" SubmitPurchaseOrder, then 

create it. But provide some "override" services so that consumers with specialized needs 

can override the generic operation. 

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

composite Web services. Standard web interfaces can also be used to quickly create 

new services. Consider reassembling existing base Web services before writing new 

Web services. For example, Federated Jobs Service is a composite of Available Jobs 

Service and Process Job Application Service. 

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

the service requester to the service provider should loosely couple the service. This 

means that the service requester has no knowledge of the technical details of the 

provider’s implementation, such as the programming language, deployment platform, 

and so forth. The service requester typically invokes operations by way of messages -- a 

request message and the response -- rather than through the use of APIs or file formats. 

“Extensibility is essential to the rapid and efficient evolution of Web service interfaces. If 

every enhancement of a provider interface requires the redeployment of a corresponding 

consumer interface to the thousands of existing consumers, then change management 

will grind to a halt. The key is to architect Web service interfaces using XML and XSD 

(XML Schema Definition) extensibility mechanisms to enable both forward and backward 

compatibility between consumer and provider interfaces to loosely couple consumer 

versions from provider versions”. – Gartner 2006 

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

must be well-defined. Web services Description Language (WSDL) is a widelysupported 

way of describing the details required by a service requester for binding to a 

service provider. The service descriptions focus on operations used to interact with the 

following: 

a. A service 

b. Messages to invoke operations 

c. Details of constructing such messages 

d. Information on where to send messages for processing details of constructing 

such messages 





800 

801 

802 

803 

804 

805 

806 

807 

808 

809 

810 

811 

812 

813 

814 

815 

816 

817 

818 

819 

820 

821 

822 

823 

824 

825 

826 

827 

828 

829 

830 

831 

832 

833 

834 

835 

836 

837 

838 

839 

840 

841 

842 

843 

844 

845 

846 

847 

848 

WSDL should not include any technology details of the implementation of a service. The 

service requester neither knows nor cares whether the service is written in Java code, 

C#, COBOL, or some other programming language. It can describe a SOAP invocation 

using HTTP. Because of its extension mechanisms, it can also define other styles of 

interaction such as XML content delivered via JMS, direct method calls, calls handled by 

an adapter that manages legacy code (CICS), and so forth. 

The common definition for WSDL allows development tools to create common interfaces 

for various styles of interaction, while hiding the details of how it invokes the service from 

the application code. The Web Services Invocation Framework (WSIF), for example, 

exploits this capability by allowing a run-time determination of the best way to invoke a 

quality service if the service is exposed in more than one interaction style. See 

http://ws.apache.org/wsif/ for WSIF details. 

6. Design stateless base Web services. Services should be independent, selfcontained 

requests, which do not require information or state from one request to 

another when implemented. Services should not be dependent on the context or state of 

other services. When dependencies are required, they are best defined in terms of 

common business processes, functions, and data models, not implementation artifacts 

(like a session key). Of course, requester applications require persistent state between 

service invocations, but this should be separate from the base service. Web 

applications and composite Web services can both handle state. 

7. Implement business processes via orchestrating Web services into a 

process flow (BPEL standard). Some business processes can be implemented in a 

process flow and called from an application (which implements the entire business 

process). The individual nodes within the process flow can call other Web services, call 

out to a business rules engine, or call a native API (such as Java or .NET). Process 

flows also manage state, which means data created by one node is available to other 

nodes to view, add to, or modify. Additionally, process flow engines (vendor specific) 

have built in mechanisms to recover a process flow should a system or process failure 

occur. 

For example, a Professional License Application might call several Web service process 

flows (Gather Qualifications, Process Qualifications, Handle Payment, and Create 

License) to achieve the business process functionality. 

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

development and operational environments. By definition, Web services are 

created with the enterprise in mind. That implies a strong collaboration environment 

exists where interested parties agree on how Web services will be defined, built, 

implemented, deployed, supported, enhanced, and managed in production environment. 

Additional budgets, people, tools, and equipment resources must be allocated 

appropriately. 

9. Implement Web service security and policy enforcement standards: 





849 

850 

851 

852 

853 

854 

855 

856 

857 

858 

859 

860 

861 

862 

863 

864 

865 

866 

867 

868 

869 

870 

871 

872 

873 

874 

875 

876 

877 

878 

879 

880 

881 

882 

883 

884 

Liberty Alliance and OASIS have defined a large number of Web service security 

standards. Eventually, the work of both groups will probably be merged into a single set 

of standards. WS-Security seems to be the most widely used while many other 

standards within WS* are still evolving. However, this should not deter security 

mechanisms from being designed into Web services. 

California Service Centers 

The ultimate vision is to consolidate business services provided to constituents into a collection 

of federated service centers. SOA will play a key part in how these services are implemented. 

Please see California Service Centers SOA White Paper , for complete details. Following is a 

brief description of the key components. 

Consolidated Service Centers 

Clark Kelso, State CIO on 4/21/2006 authored Government Services on the Web: California In- 

Touch . This document introduces the notion of providing a better customer experience at 

reduced cost to the state via moving to consolidated service centers. 

The new California Service Center (CSC) will lead the way to a more customer-friendly E- 

government based on a services oriented (SOA) environment. From a strategic perspective, 

the California Service Center will be the customer-facing site. It will intelligently redirect to the 

appropriate service centers which will be working together in a federated manner. 

Shared Services 

Collectively, the service centers will leverage shared services, such as Identity, Search, Real 

Simple Syndication (subscriptions, news), Address Verification, and a common Payment 

engine to name a few. Shared services will be built in a federated manner but deployed and 

operationally managed centrally. That is, many departments will contribute shared services but 

they will be hosted in a small number of data centers. 

SOA Infrastructure 

Operationally, service centers will utilize an enterprise infrastructure approach. That is, they will 

be deployed and managed in a small number of SOA-based data centers. Mission critical 

services will be deployed in a redundant manner across data centers to minimize single point of 

failures. This implies collaboration in the area of configuration and release management across 

data centers to achieve a high degree of availability, scalability, and reliability. 

An SOA infrastructure must support XML message processing and application integration. This 

functionality is normally handled by an ESB. 





885 

886 

887 

888 

889 

890 

891 

892 

893 

894 

895 

896 

897 

898 

899 

900 

901 

902 

903 

904 

905 

906 

907 

908 

909 

910 

911 

912 

913 

914 

915 

916 

917 

918 

919 

920 

921 

922 

923 

924 

925 

926 

927 

928 

929 

Enterprise Service Bus 

Application integration and service interoperability are of paramount importance in a shared 

services environment. Because applications are located on many different hardware and 

software platforms, connecting these environments in a manner that meets availability, 

scalability, and user performance expectations, uniform service interoperability platforms must 

be carefully chosen. 

These typically fall into two categories: For Windows-based platforms, Microsoft handles 

standards-based messaging and application connectivity via incorporating Windows 

Communication Framework functionality into an upcoming release called Windows Vista. In the 

Java world, there are quite a few choices. Some of the more popular ones are IBM WebSphere 

ESB, BEA AquaLogic Service Bus, Oracle Fusion, Cape Clear ESB, Sonic Software ESB, SAP 

NetWeaver, and others. 

California SOA Center of Excellence 

Introduction 

A successful state-wide SOA program will require both centralized and federated components. 

Singular vision & goals, governance, enterprise repository management, and several 

operational functions (certification lab, UDDI repository, maintain service reference model, 

service help desk, and search taxonomy) should be centralized. Service development (and 

possibly some SOA operations) should be federated to the producing departments. In some of 

the above functions, centralized does not mean single instance. For example one would 

establish at least two UDDI repositories for scalability and accessibility. 

Because SOA components are designed for enterprise use, there are a number of critical 

governance and operational issues that need to be addressed. Such as: 

• How will developers be supported? 

• How will business architects and technical architects determine which shared services 

already exist? 

• How will SOA services be mapped to business services? 

• How will service versioning and release packaging be controlled? 

• How will services be certified? 

• How will services be tested for performance, availability, and scalability? 

• How will services usage be monitored and reported? 

• How will developers locate code for an existing service? 

• How will service contract compliance among data centers be handled? 

• Will there be a centralized, state-wide help desk? 

• How will service troubleshooting be handled at an enterprise level? 

(A composite service might consist of 4 services, each running in a different data 

center.) 

• Will there be example services and demo applications? 

• Will there be a state-wide search service utilizing a common language? (a taxonomy)? 





930 

931 

932 

933 

934 

935 

936 

937 

938 

939 

940 

941 

942 

943 

944 

It is obvious that there is a very important need for an oversight group to act as the center hub 

for the enterprise. It is recommended that a California SOA Center of Excellence be established 

to fulfill many of these tasks. This group would lead the SOA effort, be the “go to” experts for 

departmental business service implementers, facilitate discussion groups, lead collaboration 

efforts, build a reference architecture based on best practices, and host demos. They could 

also maintain a performance lab to ensure that critical services will meet performance and 

availability expectations, manage a centralized help desk, handle compliance escalations via an 

expert distributed architecture technical staff, and define a state-wide search taxonomy. 

SOA leadership cannot be static. Rather, it should evolve as standards mature and change, 

vendors products change based on market dynamics and changing standards, analysts revise 

their best practices, and government politics and regulations change. 

So the first set of responsibilities of the California SOA Center of Excellence is shown in the 

following SOA Excellence diagram. 

945 

946 

947 





948 

949 

950 

951 

952 

953 

954 

955 

956 

957 

958 

959 

960 

961 

962 

963 

964 

965 

966 

967 

968 

969 

970 

971 

972 

973 

974 

975 

976 

977 

978 

979 

980 

981 

982 

983 

984 

985 

986 

987 

988 

989 

990 

991 

992 

993 

994 

SOA Excellence Model 

1. Standards – SOA is comprised of many standards which are managed by several 

standard bodies. It will be very important to stay on top of standard developments since 

they will have a large impact on SOA architecture. Attending conferences, monitoring 

discussion groups, and regularly checking W2C, OASIS, and WS-I Websites are all key 

activities. 

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

abreast of product developments and vendor visions for SOA. Subscribing to industry 

analysts newsletters is also a good way of staying informed. 

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

ancillary operations set the standard for states to follow. Additionally, many states are in 

the process of implementing SOA-based models. So, ongoing collaboration with other 

states makes good sense. 

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

from SOA operations must be factored into the vision and goals must be updated 

accordingly. 

5. Briefings & Targeted Presentations – SOA means different things to different people. 

So, preparing presentations that are targeted to a particular group will be most effective. 

For example, executives, business architects, technical architects, and IT developers all 

have different priorities within SOA. So, presenting SOA in terms of specific audience 

type would be most effective. 

1. Demos – An SOA Center of Excellence is a great place to demonstrate the SOA 

environment. Demos can be built to support the presentations targeted at specific 

audiences. Often, it is easier to understand a point by witnessing a demo. Plus, a demo 

proves out an environment and allows “what if” scenarios. 

2. Reference Architecture – An SOA environment should exist as the model for 

developers. That is, a reference implementation that incorporates key SOA components 

would provide developers platform-specific components to measure their services 

against. The Reference Architecture would include both J2EE and .NET components. 

3. Executive SOA Discussion Group – Sponsoring an SOA discussion group for 

executives would be one way of providing executives with an easy mechanism for 

exchanging thoughts and ideas. 





995 

996 

997 

998 

999 

1000 

1001 

1002 

1003 

1004 

1005 

1006 

1007 

1008 

1009 

1010 

1011 

1012 

1013 

1014 

1015 

1016 

1017 

1018 

1019 

1020 

1021 

1022 

1023 

1024 

1025 

1026 

1027 

1028 

1029 

1030 

1031 

1032 

1033 

1034 

SOA Tools 

Development Tools 

A tool to model business services would be of great value. This could include business 

process details as well as expected performance metrics. If the tool has the capability 

to simulate different business scenarios, it would be of even more value. 

Equally important is a tool to model SOA services. Ideally, the output from the business 

modeling tool would seamlessly flow into the SOA services tool which, in turn could 

generate implementation code. 

Enterprise Repository 

A single, enterprise repository tool is needed to gather information about enterprise architecture 

models, department applications, shared service inventory and usage, as well as pointers to 

shared service code packages. Therefore this repository should be purchased and 

implemented as a shared enterprise tool with the capability to establish different types of users, 

and appropriate levels of security. 

This repository should be configured to hold details of the Business Reference Models (BRM), 

Service Reference Models (SRM), Data Reference Models (DRM), and Technical Reference 

Models (TRM). For example, the Technical Reference Framework templates would be stored in 

this repository. As departments fill out the templates they could also be stored in the 

department section. 

Business Activity Monitoring (BAM) 

BAM enables organizations to leverage business analytics to gain a real-time insight into daily 

business operations. This analytical insight helps business users quickly identify operational 

inefficiencies and predict potential business problems. BAM integrates business intelligence 

(BI) with business transaction processing. 

BAM enables organizations to leverage business analytics to gain a real-time insight into daily 

business operations. This analytical insight helps business users quickly identify operational 

inefficiencies and predict potential business problems. BAM integrates business intelligence 

(BI) with business transaction processing. 

Appendices 

Appendix A - Federal SOA 

The Federal Architecture and Infrastructure Committee along with the Federal CIOs Council 

produced the Federal Enterprise Architecture which is based on SOA and Web Services. 

“An architecture that provides for reuse of existing business services and rapid deployment of new 

business capabilities based on existing capital assets is often referred to as a service-oriented 

architecture (SOA). “ -- Federal CIOs Council 





1035 

1036 

1037 

1038 

1039 

1040 

1041 

1042 

1043 

1044 

1045 

1046 

1047 

1048 

1049 

1050 

1051 

1052 

1053 

1054 

1055 

1056 

1057 

1058 

1059 

1060 

1061 

1062 

1063 

1064 

1065 

1066 

1067 

1068 

1069 

1070 

1071 

1072 

1073 

1074 

1075 

For a full description of the Federal Enterprise Architecture program, please see 

http://www.cio.gov/documents/CIOC_AIC_Service Component Based Architectures 

_2.0_FINAL.pdf 

For a broader description of the Federal E-Gov initiative please see 

http://www.whitehouse.gov/omb/egov/ . 

Appendix B - SOA Advantages (Patricia Seybold Group) 

Brenda M. Michelson, Sr. VP 

SOA Business Advantages: 

• Consistent Experience. An SOA can provide a consistent experience for customers 

and partners across channels and lines of business. 

• Business Agility. An SOA can add new functionality, expose functionality to new 

channels, and vary functionality based on context (customer, partner, entry point). 

• Mix and Match. An SOA can compose business solutions from a reusable service 

collection, leveraging internal and external services. 

• Optimize Interactions. An SOA can optimize business interactions for customers, 

partners, and internal constituents through the implementation of business scenarios 

(process, events, and services) versus traditional applications. 

SOA IT advantages: 

• Reduction of Costs. Reuse of services reduces IT development, deployment, and 

maintenance time and costs. 

• Leverage Existing IT Investments. Your service providers are existing code (objects, 

components, legacy modules, and application package APIs) and information assets 

(databases, files, and documents). 

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

strategies. 





1076 

1077 

Appendix C – WSDL Example 

1078 

1079 

1080 

1081 

1082 

1083 

1084 

1085 

1086 

This is an abridged version of the WSDL for Amazon’s E-commerce Service (ECS). The 

annotations 

on the left hand-side describe the WSDL sections. The yellow boxes within the WSDL highlight 

key elements, such as data elements, messages and bindings, and their recurrence in the 

various sections. 

- Patricia Seybold Group 





1087 

1088 

1089 

1090 

1091 

1092 

1093 

1094 

1095 

1096 

1097 

1098 

1099 

1100 

1101 

1102 

1103 

Appendix D – Legacy Integration Patterns 

Overview 

Mainframe applications will continue to be around for a long time and many departments 

depend on the mainframes for their mission critical applications. Therefore, the state must plan 

to integrate mainframe applications into the new SOA-based environment. Departments should 

take a close look at their application portfolios and devise an application maturity plan which 

would should separate them into categories such as don’t modify, wrap with Web service 

interfaces, reengineer into Java or .NET applications, or plan to retire. Following are brief 

discussion of three popular patterns. 

Integrating Existing Mainframe Apps - Unmodified 

There are several ESB products that have a broad range of application integration capability. 

IBM Websphere ESB, Oracle Fusion, Cape Clear ESB, plus a number of other companies have 

products in this area. Enterprise Service Bus products not only provide messaging 

infrastructure for Web services, they also provide a variety of adapters and connectors to 

integrate native language interfaces (such as COBOL, CICS, MQ Series, Java, FTP, etc.). 





1104 

1105 

1106 

1107 

1108 

1109 

1110 

1111 

1112 

1113 

1114 

1115 

1116 

1117 

IBM 

http://www-306.ibm.com/software/info1/Websphere/index.jsp?tab=landings/esb 

Oracle 

http://www.oracle.com/products/middleware/index.html 

Sonic 

http://www.sonicsoftware.com/index.ssp 

Cape Clear 

http://www.capeclear.com/products/cc6.shtml 





1118 

1119 

1120 

1121 

1122 

1123 

1124 

1125 

1126 

1127 

1128 

1129 

1130 

1131 

1132 

1133 

1134 

1135 

1136 

1137 

1138 

1139 

1140 

1141 

1142 

1143 

1144 

1145 

1146 

1147 

1148 

1149 

1150 

1151 

1152 

1153 

1154 

1155 

1156 

1157 

1158 

1159 

Placing Web Service Interfaces on Existing Mainframe Apps 

Makes mainframe applications (particularly Natural and Adabas) look like Web services. 

EntireX executes on the mainframe and exposes the service interfaces. ApplinX solution 

requires no changes to mainframe code. 

SoftwareAG EntireX 

http://www.softwareag.com/Corporate/products/entirex/default.asp 

SoftwareAG ApplinX 

http://www.softwareag.com/Corporate/products/applinx/default.asp 

Compiling COBOL Code into Web Service Languages 

Fujitsu Consulting provides a COBOL compiler for a variety of platforms and languages. For 

example, NetCOBOL for .NET is a COBOL compiler created specifically for Microsoft's .Net 

Framework. This means that COBOL is just another .NET scripting language (like VB.NET, C#, 

J#, etc.). This allows COBOL code to be mixed with C# or VB.NET code. It compiles to 

Microsoft MSIL (language neutral, .NET runtime) code. 

NetCOBOL main page 

http://www.netcobol.com/products/ 

NetCOBOL for .NET 

http://www.netcobol.com/products/windows/netcobol.html 

Appendix E - Definitions 

AJAX: Asychronous JavaScripting and XML is a Web development technique for creating 

interactive Web pages. The intent is to make Web pages feel more responsive by exchanging 

small amounts of data with the server behind the scenes, so that the entire Web page does not 

have to be reloaded each time the user makes a change AJAX is available for Java, .NET, 

PHP, and other languages. 

http://en.wikipedia.org/wiki/AJAX 

Architecture: Representation of the structure of a system that describes the constituents of the 

system and how they interact with each other. 

Application Architecture: Representation of an application and its parts, their interrelationships 

and functions. 

AVDL: Application Vulnerability Description Language. 

http://www.oasis-open.org/specs/index.php#avdlv1.0 

BPEL: Business Process Execution Language for Web Services provides a means to formally 

specify business processes and interaction protocols. BPEL provides a language for the formal 

specification of business processes and business interaction protocols. By doing so, it extends 

the Web Services interaction model and enables it to support business transactions. BPEL 





1160 

1161 

1162 

1163 

1164 

1165 

1166 

1167 

1168 

1169 

1170 

1171 

1172 

1173 

1174 

1175 

1176 

1177 

1178 

1179 

1180 

1181 

1182 

1183 

1184 

1185 

1186 

1187 

1188 

1189 

1190 

1191 

1192 

1193 

1194 

1195 

1196 

1197 

1198 

1199 

1200 

1201 

defines an interoperable integration model that should facilitate the expansion of automated 

process integration in both the intra-corporate and the business-to-business spaces. 

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ 

Business Component: Represents the implementation of an autonomous business concept, 

business service, or business process. It consists of all the technology elements (i.e., software, 

hardware, data) necessary to express, implement, and deploy a given business concept as an 

autonomous, reusable element of a large information system. It is a unifying concept across the 

development lifecycle and the distribution tiers. 

Business (Domain) Component: Organizational unit that offers business services operation 

based on rules of that business. 

Business Component System: Set of cooperating business components assembled together 

to deliver a solution to a business problem. 

Business Logic Component: Software unit that offers small-grained business logic that has a 

large degree of reuse throughout the organization. Sub-components that manage and exe-cute 

the set of complex business rules that represent the core business activity supported by the 

component. 

CAP: Common Alerting Protocol. 

http://www.oasis-open.org/specs/index.php#capv1.0 

Component: Independently deployable unit of software that exposes its functionality through a 

set of services accessed via well-defined interfaces. A component is based on a component 

standard, is described by a specification, and has an implementation. Components can be 

assembled to create applications or larger-grained components. 

Component Architecture: Internal structure of a component described in terms of partitioning 

and relationships between individual internal units. 

Component-Based Architecture: Architecture process that enables the design of enterprise 

solutions using large service components. The focus of the architecture may be a specific 

project or the entire enterprise. This architecture provides a plan of what needs to be built and 

an over-view of what has been built already. 

Component Registry: Application designed to provide a directory of available components 

based on profile and or specification. Registries usually provide efficient mechanisms for 

searching for components in multiple ways, such as by service, price, and/or provider. 

Component Repository: Application designed to store component specifications and 

implementations. Often provides facilities to efficiently search for and retrieve components for 

evaluation against desired component specifications though the search capabilities may be offloaded 

to a component registry. 

CORBA: Common Object Request Broker Architecture, created by the Object Management 

Group (http://www.omg.org/ ) vendor-independent architecture and infrastructure that computer 

applications use to work together over networks. Using the standard protocol IIOP, a CORBAbased 

program from any vendor, on almost any computer, operating system, programming 

language, and network, can interoperate with a CORBA-based program from the same or 

another vendor, on almost any other computer, operating system, programming language, and 

network. 





1202 

1203 

1204 

1205 

1206 

1207 

1208 

1209 

1210 

1211 

1212 

1213 

1214 

1215 

1216 

1217 

1218 

1219 

1220 

1221 

1222 

1223 

1224 

1225 

1226 

1227 

1228 

1229 

1230 

1231 

1232 

1233 

1234 

1235 

1236 

1237 

1238 

1239 

1240 

1241 

1242 

COTS Components: Commercial Off the Shelf (COTS) components that can satisfy business 

process and data requirements for large functional domains or lines-of-business. Examples of 

COTS components would be Enterprise Resource Planning (ERP) products such as those as 

offered by commercial software companies. 

Data: Factual or numerical business information of record that is maintained by the service 

component. The encapsulated service component is fully responsible for maintaining this 

information. 

Data-Level Application Programming Interfaces: Services internal to the service component 

that support access to the data of record maintained within the service component. These services 

may span numerous distributed data sources. 

DCOM: Distributed Common Object Model is an extension of the Component Object Model 

(COM) that allows COM components to communicate across network boundaries. DCOM 

uses the RPC mechanism to transparently send and receive information between COM 

components. Microsoft first introduced it in 1995. 

DSML: Directory Services Markup Language. 


Distributed Component: Lowest level of component granularity. It is a software element that 

can be called at run-time with a clear interface and a clear separation between interface and 

implementation. It is autonomously deployable. A distributed component provides low ROI for 

capital planning purposes. 

E-Business Patterns: Patterns for e-business are a group of proven reusable assets that can 

be used to increase the speed of developing and deploying net-centric applications, like Webbased 

applications. 

ebXML: Electronic Business using eXtensible Markup Language. 

http://www.ebxml.org/ 

Encapsulation: Hiding implementation details within a component so that an implementation is 

not dependent on those details. 

Enterprise Architecture: Meta-architecture of an organization or the sum of all architectures 

within an organization. 

Enterprise Component: Large-granularity business component of an organization. 

Enterprise Service Bus (ESB): A class of integration software that is intended to support the 

deployment of Web services. An ESB combines messaging, basic transformation, and contentbased 

routing. The inputs and outputs of an ESB are Service Data Objects (SDO). 

Extensibility: Ability to extend the capability of a component so that it handles additional needs 

of a particular implementation. 

Federated Business Component: Set of cooperating system-level components federated to 

resolve the business need of multiple end users often belonging to different organizations. 

California Enterprise Component: Very coarse-grained business component of California 

Government. 

Federation: is a collection of realms/domains that have established trust. The level of trust may 

vary, but typically includes authentication and may include authorization. 





1243 

1244 

1245 

1246 

1247 

1248 

1249 

1250 

1251 

1252 

1253 

1254 

1255 

1256 

1257 

1258 

1259 

1260 

1261 

1262 

1263 

1264 

1265 

1266 

1267 

1268 

1269 

1270 

1271 

1272 

1273 

1274 

1275 

1276 

1277 

1278 

1279 

1280 

1281 

1282 

1283 

1284 

1285 

Fit-Gap Analysis: Examination of components within the context of requirements and to make 

a determination as to the suitability of the service component. 

Component Granularity: The size of the unit of component under consideration in some 

context. The term generally refers to the level of detail at which component is considered, e.g. 

"You can specify the granularity for this service component". 

Identity Mapping: is a method of creating relationships between identity properties. Some 

Identity Providers may make use of id mapping. 

Identity Provider: is an entity that acts as a peer entity authentication service to end users and 

data origin authentication service to service providers (this is typically an extension of a security 

token service). 

ID-FF: Liberty Identity Federation Framework. ID-FF contains the core specifications that allow 

for the creation of a standardized, multi-vendor, identity federation network. The FF consists of 

protocols, schema and profiles. 

https://www.projectliberty.org/resources/specifications.php 

ID-SIS: Liberty Identity Services Interface Specifications. ID-SIS uses the ID-WSF (new window) 

and ID-FF (new window) specifications to provide networked identity services, such as contacts, 

presence detection, or wallet services that depend on networked identity. The SIS contains two 

specifications: Personal Profile (ID-SIS-PP): and Employee Profile (ID-SIS-EP): 

ID-WSF: Liberty Identity Web Services Framework. ID-WSF provides a basic framework of 

identity services. Such services could be identity service discovery and invocation. The WSF 

consists of schema, protocols, and profiles. 

http://www.projectliberty.org/resources/specifications.php 

Infrastructure Component: Software unit that provides application functionality not related to 

business functionality, such as error/message handling, audit trails, or security. 

Interface: Mechanism by which a component describes what it does and provides access to its 

services. This is important because it represents the “contract” between the supplier of services 

and the consumer of the services. 

Intellectual Property: A product of the intellect that has commercial value, including 

copyrighted property such as literary or artistic works, and ideational property, such as patents, 

appellations of origin, business methods, and industrial processes. 

Interface Profile: the sub-component that provides the ability to customize the component for 

various uses. The profile can be tailored to suit different deployment architectures well as 

different sets of business rules across enterprises. The interface profile can specify the business 

rules and workflow that are to be executed when the component is initialized. The profile can 

specify the architectural pattern that complements the service component. 

Java Server Faces: JavaServer Faces technology is a server-side user interface component 

framework for Java technology-based Web applications. JSF offers a clean separation between 

behavior and presentation. 

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/ 

Language Class: Class in an object-oriented programming language to build distributed 

components. This is NOT considered an SRM component. A language class provides very low 

ROI for capital planning purposes. 





1286 

1287 

1288 

1289 

1290 

1291 

1292 

1293 

1294 

1295 

1296 

1297 

1298 

1299 

1300 

1301 

1302 

1303 

1304 

1305 

1306 

1307 

1308 

1309 

1310 

1311 

1312 

1313 

1314 

1315 

1316 

1317 

1318 

1319 

1320 

1321 

1322 

1323 

1324 

1325 

1326 

1327 

1328 

Line of Business: A particular kind of commercial or government enterprise; e.g. "human resources" 

“financial management” “wholesale banking”. 

Message Authentication: is the process of verifying that the message received is the same as 

the one sent. 

Messaging Interface: Linkage from the service component to various external software 

modules (component, external systems, gateways, etc.) and other service components. 

Notional Component: Set of services packaged into a component, derived from requirements 

definition. A “desired” component, prior to implementation. 

Process Component: Software unit that implements the logic of a process. 

Realm or Domain: represents a single unit of security administration or trust. 

Reuse: Any use of a preexisting software artifact (component, specification, etc.) in a context 

different from that in which it was created. 

SAML: Security Assertion Markup Language. 

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 

Security Token Service (STS): A security token service is a Web service that issues security 

tokens (see WS-Security and WS-Trust). That is, it makes assertions based on evidence that it 

trusts, to whoever trusts it. To communicate trust, a service requires proof, such as a security 

token or set of security tokens, and issues a security token with its own trust statement (note 

that for some security token formats this can just be a re-issuance or co-signature). This forms 

the basis of trust brokering. 

Sender Authentication: is corroborated authentication evidence possibly across Web service 

actors/roles indicating the sender of a Web service message (and its associated data). Note that 

it is possible that a message may have multiple senders if authenticated intermediaries exist. 

Also note that it is application-dependent (and out of scope) as to how it is determined who first 

created the messages as the message originator might be independent of, or hidden behind an 

authenticated sender. 

Service: Discrete unit of functionality that can be requested (provided a set of preconditions is 

met), performs one or more operations (typically applying business rules and accessing a database), 

and returns a set of results to the requester. Completion of a service always leaves 

business and data integrity intact. 

Service-Component: Modularized service-based applications that package and process 

together service interfaces with associated business logic into a single cohesive conceptual 

module. Aim of a service component is to raise the level of abstraction in software services by 

modularizing synthesized service functionality and by facilitating service reuse, service 

extension, specialization and service inheritance. 

Service-Component Reference Model (SRM): Service component-based framework that can 

provide—independent of business function—a “leverage-able” foundation for reuse of 

applications, application capabilities, components, and business services. 

Service Data Object (SDO): An Enterprise Service Bus concept where all incoming messages 

are converted into service data objects. 

Service Interface: Set of published services that the component supports. These are aligned 

with the business services outlined in the service reference model. 





1329 

1330 

1331 

1332 

1333 

1334 

1335 

1336 

1337 

1338 

1339 

1340 

1341 

1342 

1343 

1344 

1345 

1346 

1347 

1348 

1349 

1350 

1351 

1352 

1353 

1354 

1355 

1356 

1357 

1358 

1359 

1360 

1361 

1362 

1363 

1364 

1365 

1366 

1367 

1368 

1369 

1370 

1371 

1372 

Service-Level Agreement: A contract or memorandum of agreement between a service 

provider and a customer that specifies, usually in measurable terms, what services the service 

provider will furnish. Information technology departments in major enterprises have adopted the 

idea of writing a service level agreement so that services for their customers (users in other 

departments within the enterprise) can be measured, justified, and perhaps compared with 

those of external (sourcing) service providers. 

Service-Oriented Architecture: Architecture that provides for reuse of existing business 

services and rapid deployment of new business capabilities based on existing capital assets. 

Services Interface: A logical boundary that permits software services to be defined 

independent of the service implementation. 

SOAP: A simple XML based protocol to let applications exchange information over HTTP. 

SOAP is a protocol for accessing a Web Service. Note, SOAP originally stood for Simple 

Object Access Protocol, but this has been dropped. 

Single Sign On (SSO): is an optimization of the authentication sequence to remove the burden 

of repeating actions placed on the end user. To facilitate SSO, an element called an Identity 

Provider can act as a proxy on a user's behalf to provide evidence of authentication events to 

3rd parties requesting information about the user. These Identity Providers are trusted 3rd 

parties and need to be trusted both by the user (to maintain the user's identity information as the 

loss of this information can result in the compromise of the users identity) and the Web services 

which may grant access to valuable resources and information based upon the integrity of the 

identity information provided by the IP. 

SPML: Service Provisioning Markup Language. 


Solution Assembly: Process of implementing a solution by assembling the necessary 

components into a complete solution. This process often involves additional “glue” code to 

integrate the assembled components. 

Test Harness: Software that automates the software engineering testing process to test the 

soft-ware as thoroughly as possible before using it on a real application. Trust Domain: an 

administered security space in which the source and target of a request can determine and 

agree whether particular sets of credentials from a source satisfy the relevant security policies 

of the target. The target may defer the trust decision to a third party thus including the trusted 

third party in the Trust Domain. 

UBL: Universal Business Language. 


UDDI: Universal Description Discovery Integration. 

http://www.uddi.org/ 

Web Service: Functionality provided by a service, which is exposed using the Internet (SOAP, 

HTTP, WSDL, XML, TCP/IP) as the transport mechanism. Can be internally provided as part of 

a suite of services or can be offered by external organizations. 

Web Service for Remote Portlets: A user-facing Web Service that will provide content, 

marked for display, to a portal or other aggregating Web application. This moves Web Services 

out from the back-end model layer. 





1373 

1374 

1375 

1376 

1377 

1378 

1379 

1380 

1381 

1382 

1383 

1384 

1385 

1386 

1387 

1388 

1389 

1390 

1391 

1392 

1393 

1394 

1395 

1396 

1397 

1398 

1399 

1400 

1401 

1402 

1403 

1404 

1405 

1406 

1407 

1408 

1409 

1410 

1411 

1412 

1413 

1414 

1415 

1416 

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp 

Web Service Flow: The process of combining and orchestrating Web services into a unique 

flow. Individual Web methods on multiple Web services can be invoked in a precise order that 

meets the specific application flow requirements. 

Workflow Manager: Sub-component that enables one component to access services on other 

components to complete its own processing. The workflow manager determines which external 

component services must be executed and manages the order of service execution. 

Wrapping: Creation of an interface around legacy functionality (code) that exposes the 

functionality as services via interfaces that conform to a component specification. 

WSDL: An XML format for describing network services as a set of endpoints operating 

on messages containing either document-oriented or procedure-oriented information. 

The operations and messages are described abstractly, and then bound to a concrete 

network protocol and message format to define an endpoint. Related concrete 

endpoints are combined into abstract endpoints (services). 

WSDM: Web Services Data Management. 

WSIF: The Web Services Invocation Framework (WSIF) is a simple Java API for invoking Web 

services, no matter how or where the services are provided. WSIF allows stubless or 

completely dynamic invocation of a Web service, based upon examination of the meta-data 

about the service at runtime. 

http://ws.apache.org/wsif/ 

WS-Addressing: describes how to specify identification and addressing information for 

messages. 

WS-Authorization: will describe how to manage authorization data and authorization policies. 

WS-BusinessActivity: This specification provides the definition of the business activity 

coordination type that is to be used with the extensible coordination framework described in the 

WS-Coordination specification. The specification defines two specific agreement coordination 

protocols for the business activity coordination type: 

BusinessAgreementWithParticipantCompletion 

and 

BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these 

protocols when building applications that require consistent agreement on the outcome of longrunning 

distributed activities. 

http://www-128.ibm.com/developerworks/library/specification/ws-tx/ 

WS-Federation: describes how to manage and broker the trust relationships in a 

heterogeneous federated environment, including support for federated identities, sharing of 

attributes, and management of pseudonyms. 

Web Services Inspection Language (WSIL): The WS-Inspection specification "defines how 

an application can discover an XML Web service description on a Web server, enabling 

developers to easily browse Web servers for XML Web services. WS-Inspection complements 

the IBM- and Microsoft-pioneered 'Universal Description, Discovery and Integration (UDDI)' 

global directory technology by facilitating the discovery of available services on Web sites 

unlisted in the UDDI registries, and builds on Microsoft's SOAP Discovery technology built into 

Visual Studio .NET. 

WS-MetadataExchange: describes how to exchange metadata such as WS-Policy information 

and WSDL between services and endpoints. 





1417 

1418 

1419 

1420 

1421 

1422 

1423 

1424 

1425 

1426 

1427 

1428 

1429 

1430 

1431 

1432 

1433 

1434 

1435 

1436 

1437 

1438 

1439 

1440 

1441 

1442 

1443 

1444 

1445 

1446 

1447 

1448 

1449 

1450 

1451 

1452 

1453 

1454 

1455 

1456 

1457 

1458 

1459 

WS-Policy: represents a set of specifications that describe the capabilities and constraints of 

the security (and other business) policies on intermediaries and endpoints (e.g. required 

security tokens, supported encryption algorithms, privacy rules) and how to associate policies 

with services and endpoints. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwssecur/html/securitywhitepaper.asp 

WS-Privacy: will describe a model for how Web services and requestors state privacy 

preferences and organizational privacy practice statements. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwssecur/html/securitywhitepaper.asp 

WS-Referral: WS-Referral is a protocol that enables the routing strategies used by SOAP 

nodes in a message path to be dynamically configured. SOAP itself provides a distributed 

processing model where SOAP messages can have content destined for specific processing 

nodes. WS-Routing adds to SOAP the capability of describing the actual message path. WS- 

Referral provides a mechanism to dynamically configure SOAP nodes in a message path to 

define how they should handle a SOAP message. It is a configuration protocol that enables 

SOAP nodes to delegate part or all of their processing responsibility to other SOAP nodes. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnglobspec/html/wsreferspecindex.asp 

WS-Reliability: Web Services Reliability (WS-Reliability) is a SOAP-based protocol for exchanging 

SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message 

ordering. WS-Reliability is defined as SOAP header extensions, and is independent of 

the underlying protocol. 

http://developers.sun.com/sw/platform/technologies/ws-reliability.html 

WS-ReliableMessaging: this specification describes a protocol that allows messages to be 

delivered reliably between distributed applications in the presence of software component, 

system, or network failures. The protocol is described in this specification in an independent 

manner, allowing it to be implemented using different network transport technologies. To 

support interoperable Web services, a SOAP binding is defined within this specification. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnglobspec/html/wsrmspecindex.asp 

WS-Routing: WS-Routing is a simple, stateless, SOAP-based protocol for routing SOAP 

messages in an asynchronous manner over a variety of transports like TCP, UDP, and HTTP. 

With WS-Routing, the entire message path for a SOAP message (as well as its return path) can 

be described directly within the SOAP envelope. 

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnglobspec/html/wsroutspecindex.asp 

WSRP: Web Services for Remote Portlets. 

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp 

WS-SecureConversation: describes how to manage and authenticate message exchanges 

between parties, including security context exchanges and establishing and deriving session 

keys. 

http://www-128.ibm.com/developerworks/library/specification/ws-secon/ 





1460 

1461 

1462 

1463 

1464 

1465 

1466 

1467 

1468 

1469 

1470 

1471 

1472 

WS-Security: describes how to attach signature and encryption headers to SOAP messages. In 

addition, it describes how to attach security tokens, including binary security tokens such as 

X.509 certificates and Kerberos tickets, to messages. 

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp 

WS-Security SAML Token Profile: 

http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf 

WS-Transactions and WS-Coordination: describes how to enable transacted operations as 

part of Web service message exchanges. 

WS-Trust: describes a framework for trust models that enables Web services to securely 

interoperate by requesting, issuing, and exchanging security tokens. 

http://Webservices.xml.com/lpt/a/ws/2003/06/24/ws-trust.html 

XACML: Extensible Access Control Markup Language.

leader replacement system - Department of Public Social Services ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?