Developing under a Service Oriented Architecture (SOA) is different from traditional development. A large set of business changes will now be funneled through a relatively small number of enterprise services. An inefficient or bad build system can impact a greater number of business changes. As services are exposed to more consumers and so to more potential threats having a robust and secure development environment is more important than ever. Centralized role-based control of builds and reporting of build activities is critical for incorporating a greater number of changes and managing the security and auditability of Web Services.

Build management is a critical operation for transitioning to an enterprise application environment modeled on SOA. Achieving a repeatable application lifecycle that is efficient and secure is strongly influenced by how well the build management system works. Instead of different client applications all connecting to different data sources to retrieve whatever bits of information they need, client or consumer apps under SOA will simply ask for a customer record from a service designed to provide a full customer record and nothing else.

The Service Model
Different consumer applications that need customer information will all request that information from the same service and that promotes great reusability. In practice, the number of these kinds of enterprise business services-facing consumer apps will be relatively small. And, compared to a single traditional application, developing these enterprise services results in a larger number of changes being made to the smaller number of services. Incorporating changes into the services is where build management comes in, and incorporating larger numbers of changes puts increasing demands on the build system.

The build process takes the application source code and translates it (compiles it) into a form suitable for running on a machine or application server. The build for an application typically involves several hundred source and resource files and dizzyingly complex dependency relationships that require certain steps in the translation process to occur in a certain order. The goals of a successful build process are that it be, in order, repeatable, auditable, standardized across applications, automated, highly performing (usually meaning as fast as possible) and able to produce reports and metrics for organizational performance improvement. A successful build process is highly dependent on good version control and is part of good overall software configuration management.

Loose Coupling
Another goal of a SOA is loose coupling between the consumer applications and the service. This means that the consumers are developed relatively independently from the services. This should drive down operational costs by creating smaller, more manageable application components. While it's everyone's dream to work independently and not be bothered by what others are doing, in an enterprise environment nothing happens in a vacuum and there always has to be coordination between teams at some level. This is very different from the situation of a service exposed over the Internet for anonymous public applications to consume. This shows that implementing an SOA in an enterprise environment will be very different from other types of implementation.

Loose coupling really boils down to not having a direct build dependency between the consumer and the service. This could allow (in theory) each consumer to merrily follow its own release schedule, independent of changes being made to the service. The reality is the consumer still has to know how to talk to the service. In a Web Services implementation of SOA, there's a WSDL file (Web Services Descriptor Language) that tells the consumer how to talk with the service without having a direct build dependency.

Considerations of performance and security have meant that some organizations have not been able to achieve loose coupling with their chosen technologies. This means that the build dependencies can be as complex as traditional apps or even more so. Changing the service could mean that every consumer app that uses it has to be rebuilt. This has an expensive impact on consumer applications' testing and release schedules, introducing risk to the production environment. As the technologies supporting SOA mature, it will be easier for organizations to move to loose coupling and simplify the enterprise build dependencies and other organizational benefits.

Security Concerns
There are a few general security concerns particular to SOA. By virtue of being a new methodology built on new technologies, security holes can easily arise in one of the technology products. One major industry analyst states that 70% of security holes addressed in enterprise environments will be reintroduced when moving to a services-based infrastructure.

One particular concern is that loosely coupling consumers and services means that tight, secure communication between the two can be a challenge. Another is that since services are exposed internally, anyone can theoretically write a consumer for that service in some implementations of SOA. For mission-critical business applications, you don't want just anyone accessing your customer record service however. A big investment in securing a SOA is required not only to thwart malicious use of the services, but to prevent an unintended impact of a legitimate consumer using a service in an innocent but inappropriate way.

Best-Practice Build Management
Before we can embark on a discussion of build and security issues of a SOA we need to cover the fundamentals that make up a good build management system. This was the stuff of articles of four or five years back, so if you're not covered here, your organization is not as competitive as it could be. (see Figure 1)

As mentioned, version control is a critical component of good build management and having a centralized source code repository as part of a version control or full software configuration management toolset is a fundamental requirement. You have to be able to control and identify precisely the application code going into the build. Centralization provides the standardization that reduces the overall number of processes and procedures and allows automation. Besides application code, you also have to manage the versions of third-party library sets that, say, provide database, messaging, and logging functionality.

It's vitally important to separate actively changing code from base-line versions identified by the version control system. The best way to do this is to have an isolated build environment with limited access where the only application code introduced into the environment comes from the version control system and isn't copied over by a person or some external process. This allows tight auditing of the build and you should be able to identify the exact version of every file used in the build and trace it through the version control system to the person, time, and date of the change.

Having a build coordinator responsible for maintaining the security and integrity of the build is a widely accepted best practice. The developers' responsibility is to get coding changes out the door to the test and production environments as quickly as possible and this can be at odds with best-practice build management that provides carefully controlled conditions and precise library use. The challenge is to provide a build system and process that can serve both developer and corporate needs.

Build Considerations for a Secure SOA Environment
Library control in builds is more important than ever. Using the wrong version of a third-party library set can mean incorporating a published security vulnerability in your enterprise application. Because of the exposure of services to multiple consumers, vulnerabilities that previously had no impact in a traditional application may suddenly become important for an enterprise service.

Capitalizing on best-of-breed build management tools can really be a cost-effective way to extend your build management capabilities into detailed reporting and monitoring. These capabilities will help create a more agile and controlled build environment as demanded by the challenges of creating a service-oriented infrastructure. It's important to distinguish between tools that help you manage your existing build system (Cruise Control, AntHill, BuildForge) from tools that only control the translation process (ant, maven), and tools that can do both (Openmake, Serena Change Man Builder).

Detailed dependency reporting and analysis helps developers track down bugs, validates secure development, and provides a watertight audit trail. Dependency reporting should include not only the file use in the build, but associate those files with specific versions of code in the source code repository that can be tied to specific business change requests.

Builds can be done "continuous integration"-style and scheduled for hourly builds or triggered by source code repository change, or simply done on-demand as the situation requires. Branching the code base could put further demands on the build system. Make sure you can handle this since developing enterprise services can involve more branching so consumers can continue to use an existing service while a new version is developed at the same time.

Summary
Having a secure build environment with tight control over the library sets used in the builds and having a full audit trail of what code was used in the build is an important part of secure development. The potentially greater number of vulnerabilities in a SOA makes it more important and starting with a tight build control system will help you avoid vulnerabilities that may be reintroduced. In addition, capitalizing on the state-of-the-art build management tools that are part of a top-line build management system introduces new capabilities for a more agile development environment while maintaining tight, secure control over code use.