Continuing our discussion of Service Oriented Architecture, let’s look at some of the chief benefits.

SOA is designed to eliminate dependencies on a particular implementation technology. When services are accessed through a common interface, the underlying implementation can change without changing the systems that build upon them. The implementation of the service can change for many reasons, such as:

  • Replacement of aging hardware
  • Changes to operating systems or application servers driven by security policy or cost considerations
  • Selection of a more productive software development platform

One or more of these components can change without impacting any of the dependent processes if implemented within a proper architecture.

This is valuable when trying to leverage legacy systems for new applications. Perhaps there are many potential clients for the legacy system, but the respective clients might use different software development platforms. Hand-writing the software necessary to integrate with a system of moderate complexity can take several weeks.

Rather than asking each client to duplicate this effort, the legacy system can provide a web service adapter with a machine-readable description. Then, each client or business process can automatically integrate with the service—skipping the time-consuming, expensive, and error-prone process of manual integration.

Reliability is enhanced as well, since there is only one piece of software to be tested (the web service adaptation layer) rather than an integration layer within each client.

There are cases when an entirely new system is being designed, and an architect might have the power to mandate a particular implementation technology. Even then, accessing the constituent services through a standard interface is a wise choice for two reasons:

1)       It provides a measure of “future-proofing” to the system. As new implementation technologies emerge, they can be adopted piece-meal by different services and their dependent processes.

2)     As unforeseen service applications arise—perhaps to meet a need in some outside organization—the service can easily be made available without exposing implementation details and complexity, or requiring a particular implementation technology that may not be available to the new client.

So how does SOA affect a real web application like DOD EMALL?  The following provides a few examples of how Partnet has used SOA to interface with existing DOD systems and their dependent services and processes to provide critical web services.

  • DLA Enterprise Business System suite
    • EBS Pre-order query—for real-time item pricing availability.
    • DLA Orders—EBS order status look-up on existing orders.
  • DLA Transaction Service Center
    • WebLots—online requisition tracking system
    • DODAAC validation query
  • DLA Data Fusion System
    • Supportability Analysis—Stock Out Report (SA-SOR)
    • Weapon System Designator Code queries
    • NSN/NIIN queries
    • Critical Item List management
  • Central Contractor Registration (CCR)—vendor information query
  • Defense Security Cooperation Agency (DSCA), Security Cooperation Information Portal (SCIP)—FMS sales interface

SOA on the DOD EMALL has resulted in lower implementation and development cost to the government.