OCIO » SOA Infrastructure

SOA Infrastructure

Last modified by Mike Phillips on 2014/07/01 10:26

Note: If you're wondering what SOA is, try the Service-Oriented Architecture Runtime Governance pages first. 


What is the SOA Infrastructure?


The SOA Infrastructure is in the middle of the diagram above. It sits in front of the protected network(s) maintained by various State agencies, and allows them to offer up their data and processing (as services) without allowing direct access to the internal systems. 



What can it do for me / my project?

By acting as a specialized firewall for data exchanges, the SOA Infrastructure is intended to make integration between systems faster and more secure. Here are the basic uses: 


Service Access Control

Active management of the boundary between the systems exchanging data. The Infrastructure can check credentials and enforce access controls that are managed by the agency providing the service. 


Service Level Management

Agencies can control the volume of requests that they allow, to each consumer of their service, based on whatever agreement is put in place. This feature can make sure that key users of a service have special priority. The Infrastructure can also ensure that a maximum level of traffic be allowed to reach the actual (Agency) servers, to protect against accidental (or malicious) flooding. 


Message Security

The Infrastructure can handle SSL and certificate validation, message validation (using XML, SOAP, WS-I and other standards) and prevent inadvertent or malicious traffic that may adversely impact the target service or the ability of other messages to be processed. All of these security functions are performed before any traffic gets to the service. This allows the service to spend all of its resources performing its specific duties. 


Service Virtualization

The Infrastructure can act as a funnel for service requests. If the address, location or even data format changes on the back-end server, the Infrastructure can be re-configured with no impact to those calling the service.



How is it funded and managed?

DAS operates a Utility Service for SOA Infrastructure, which bills participating Executive-Branch agencies based on their FTE counts. The budget for the Utility is reviewed and approved on a yearly basis by a Customer Council, made up of some of the agencies that pay for the Utility. 

The operational management of the SOA Infrastructure is handled primarily by the existing DHR/CJIS staff, with network and server support from DAS-ITE. 

A Runtime Governance group, made up of the agencies using the Infrastructure, defines the operating rules and oversees the request/change management process. 



How do I get started?

Here are the basic steps to get started offering a web service through the SOA Infrastructure: 

  1. Figure out which service(s) you intend to offer. Run the entire process with one service before starting others, if possible. 
  2. Identify the Use Case(s) that apply to your service. 
  3. Sign up for the SOA Infrastructure Requests mailing list. This is where you'll submit requests to the SOA Runtime Governance group for approval and action. 
  4. After you've signed up, send a note to the mailing list requesting a new app domain in TEST. This is where you'll do your initial setup, configuration and testing with your web service. 
  5. Before getting your first app domain, your agency will need to sign a copy of the Infrastructure SLA, which lays out roles, responsibilities, services and levels for use of the SOA Infrastructure. 
  6. After receiving the SLA, the administrator will set up your domain and send information about the admin website URL and your logon. 
  7. Using the web admin tool, set up the various SOA Infrastructure features for your service, based on the use case(s) identified in step 2, above. 
  8. Test out the configuration with your running (hopefully non-production) web service, and make sure it's working as intended. Testing should cover performance and scalability, functionality, authentication/authorization and any service level limits you've configured. 
  9. When you're ready to use the production SOA Infrastructure, make the same request as in step 4, but indicate it's for production. 
  10. The administrator will promote your configs from test to production. You will need to provide any parameter values that should be different in production (such as server addresses, certificates to load, etc.).
Created by Mike Phillips on 2011/06/07 15:24

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 3.0.36132 - Documentation