Practical Guide to Federal SOA: Infrastructure (3FUZ)
What is a SOA Infrastructure? (3FV0)
Most of this guide uses "service" to mean a business capability that might or might not involve the computer-based infrastructures we'll be concerned with here. For example, the U.S. Postal Service provides the business capability of moving mail and packages via road, rail and air systems. These infrastructures are managed elsewhere so there is little to be gained by focusing on them here. (3ERP)
This section uses "service" with the original technical meaning of a capability that organizations provide to others via computer networks such as the Internet, NIPRNet or SIPRNet. In particular, we'll focus on the common technical meaning of Service Oriented Architecture (SOA) in which services are computer programs that can be invoked via the network by programs such as web browsers and other computer applications. (3ERQ)
We also exclude computer networking hardware. Although such hardware is certainly an important part of any computing infrastructure, hardware is so thoroughly governed by standards that the interoperability issues we'll primarily be concerned with rarely surface as major issues. (3ERS)
That leaves computer software, and much of this is already ubiquitous in the World Wide Web. Browsers and web servers are governed by robust standards, with a few notable exceptions arising from persistent "embrace and extend" lock-in strategies of some vendors. (3FV1)
Although a SOA infrastructure includes such mature elements, they won't concern us here because they are mature technologies governed by mature standards. We will focus primarily on government requirements for which no standard implementations currently exist, typically because: (3FV2)
- robust standards not yet been defined (3FV3)
- the same requirements are addressed by competing standards (3FV4)
- standards exist but implementations have not yet been developed or deployed (3FV5)
- implementations are deployed but the organizational and people issues of operating them are unresolved. (3FV6)
The parts of a SOA infrastructure that we'll primarily be concerned fall in the gap between what government policy requires and what mature off-the-shelf technologies and standards can provide today. These gap technologies include: (3FV7)
- Single sign-on (federated identity) (3F01)
- Fine-grained security (message-level, field-level) (3F02)
- Interoperability (esp. for asynchronous messaging) (3F03)
- Disadvantaged enclaves: ships at sea, foxholes, etc (3ESB)
The practical guidance sections to follow are primarily concerned with cost-effective ways of bridging the gaps. (3FV8)
What is an Enterprise Service Bus? (3EZQ)
In more concrete terms, a SOA infrastructure is the collection of software libraries, operating systems and hardware that computer services in one computer use to access services in the same or other computers. The foundation is often called an Enterprise Service Bus (ESB) because it is the foundation that SOA services rely on to communicate enterprise-wide. (3ERU)
They can be thought of as a "stack", with the oldest and most mature capabilities at the bottom, the newer and least mature in the middle, and the services (applications) at the top as shown here: (3FVA)
What is Enterprise Space versus Project Space (3FVC)
Both of these figures demonstrate the separation of responsibilities that form the foundation of the recommended approach, maintaining a sharp separation between infrastructures and services; between enterprise space and project space. Failing to make this distinction leads to systems that look more like this example from a time before the hardware industry discovered the same principle: (3FVD)
