In the past, network-based applications were pretty simple. A networked server ran a monolithic application that users accessed via a basic GUI (graphical user interface). Today, organizations struggle to develop feature-rich, network-based applications while also facing business pressure to minimize timescales, maximize quality, and work with legacy systems hosted on different platforms.

To address these challenges and meet business needs, organizations are simplifying application development through reuse supported by Service-Oriented Architecture (SOA). SOA describes an architecture that provides access to, and reuses services transparently across a network. With SOA, services are developed once and accessed by future development via the network across what is known as an Enterprise Service Bus (ESB).

Reuse with SOA reduces cost, simplifies application development, increases business agility, and improves quality. For example, many different applications within an organization can access a central directory system through a single service, eliminating the effort of building point-to-point connections between every application and the directory back end. Over time, the services develop into a complex architecture of interconnected components working together to satisfy many different business needs.

While SOA has been realized in many ways, today Web services are the most compelling way to deploy applications. Web services are based upon open standards (so they are vendor-neutral) and are firewall friendly.

Some Brief History

Figure 1. An example of Tau automatically marking (with a red underline on the diagram) a mistyped reference to the AccountRecord data structure definition.
In the early days of software development, a single monolithic software application delivered the needed functionality. Later, dynamic link libraries (DLLs) or shared libraries could be loaded once and shared (i.e. reused) while the application was still running; reuse was limited to the same processor. To retrieve data at near-real-time speeds and to avoid enforced centralization of this data, technologies such as CORBA and DCOM were developed to allow access to information and services across a network. Applications could be developed in different languages (e.g. one in C++ and another in Java) with these technologies serving as a common protocol to bind the applications. Software applications had to conform to each specific network’s data protocol and format. However, these were largely proprietary to the technology owner, and usually were not easily shared with other applications or organizations.

The U.S. Government does not endorse any commercial product, process, or activity identified on this web site.