There are many issues to consider when bulletproofing and securing service-oriented architectures (SOA), including today’s most commonly posed problems of security and quality. From architecture, through development, testing, deployment and operational management there are aspects of SOA and Web Service that are unique and challenging. The infrastructure we create to enable SOA should be considered by participants in the SOA development process from architects (“Where can I offload supporting services?”) to developers (“Who is taking care of policy implementation for me including privacy and security?”) through operations and security staff (“What policy settings are implemented in the infrastructure that allow me to make adjustments without involving the development folks?”)

Ignoring security and quality in the development cycle exposes corporations to a multitude of risks that will further hinder them throughout the services lifecycle. Several keys exist in the SOA and Web services lifecycle, but it boils down to a list of five keys to avoid security, reliability and compliance issues.

First and foremost is simulating the production environment in development. One of the most important steps in bulletproofing SOA and Web services is ensuring developers have an environment that simulates the production reality. A service that works well in a development environment can reveal problems once it hits production, resulting in significant time delays and cost overruns. Developing the service in a realistic simulation of a production environment reduces the number of surprises when the service is deployed, reducing time and cost needed to remedy those surprises. For example, as a corporation’s production environment is upgraded to leverage intermediaries (such as XML Gateways), the development environment should functional versions of those intermediaries. Supporting infrastructure such as I&AM systems must be simulated to allow validation of design choices as early as possible.

Second is to articulate policies for consumers and providers and make trade-offs regarding compatibility, security and throughput. A client needs to behave as expected when messages are received from the service. Is SSL going to be used? Are credentials or identities to be mapped? What is the mapping mechanism who executes the logic? What infrastructure components will be trusted – Certificate Authorities, SAML Authorities, Key Distribution Centers? What message fields should be encrypted? What information content is private and what application, organization and geographic boundaries is it allowed to cross? Much more than traditional application development, the reusable, granular of businesses services make these and many other decisions crucial.