AMS is developing its next generation of it’s Procurement Desktop—Defense product, to be called Procurement Desktop—Enterprise (PD ^e ). The former is a PowerBuilder, client/server system. The latter is a Web-based, n-tier, J2EE application. One of the drawbacks to the client/server version of the system is that there is no central place in which the business rules of the application can be found and invoked in order to incorporate the functionality of the procurement application into wider business processes. The business rules are distributed across all the client desktops.

There is a database at the center, but it has only rudimentary business rules in comparison to the rules, guards and controls found in the rich client. As such, it should not be used as an entry point for other applications or systems that wish to incorporate procurement data, as the ability to ensure data integrity is limited, and too great a burden to build in appropriate matching business rules would be placed on applications wishing to implement such incorporation of procurement data.

An n-tier architecture with a clearly defined business logic layer in an application server provides a means to allow access to the functionality and information contained in the next generation version of the application. In addition to the many other benefits of such an architecture—the ability to scale over a wider range of users and network connections, and to provide a thin-client implementation—this approach offers a locus for making a public and open API available for use in integrating PD ^e with other applications and in making PD ^e a part of enterprise-wide distributed business processes involving the numerous applications required to accomplish the complex operations needed for the Department of Defense to execute its mission.

The Procurement Desktop Enterprise (PD ^e ) Public API offers a single, comprehensive and open programmatic interface suitable for integrating PD ^e with customer systems, other AMS products and partner products. This document presents an architectural overview of the PD ^e Public API as a survey to show the considerations on which we based our decisions and the basic parts of the architecture.

The overall goals of the next generation version of PD ^e are to move from a tightly coupled, multi-point integration approach and to meet the market need for integration choice—the power to choose how, and by whom, integration is accomplished. More specifically, when laying out this architecture, we identified a number of individual goals. These require that the application be:

We hope to show that the architecture described here satisfies these goals as we describe it from various aspects in this paper.

From the standpoint of integration with other applications and processes and the Public API presented to the outside world, the architecture of PD ^e is one of layers. A graphical depiction of this architecture is shown in Figure 1 below.

Figure 1. A Layered View of the Integration and API Architecture of PD ^e

The foundation layer is the business object/rules layer, composed of J2EE business objects. These objects provide the functionality of the PD ^e application, and mediate all modifying (create, update, delete) access to the application database, ensuring that data integrity is maintained. That is, all manipulation of the database is governed by a single set of processes, so that there can be no discrepancies in the way data placed in the database is interpreted, as it might be were there to be two different sets of business rule operations running against the database. Maintenance of the application is thereby rationalized and simplified.

Next up in the hierarchy of layers is the internal API of the application. Much of this is provided directly by the business objects. However, there is a need to provide aggregation and service interfaces to other parts of the application, so some of the internal API is provided as a layer on top of the base business objects. There is a facility, for instance, for providing introspection into the functionality and information of the system that is useful in creating EAI adapters for the application.

The Public API layer is a consumer of the private API. It does not directly interact with the database so that database consistency can be ensured. Architectural consistency required that we not create components of the application that violated the principle established for having a single business rules layer that mediates all modifying access to the database. This layer is the focus of this paper, and aspects of the architecture of the Public API are discussed in rest of this paper. Internally, the Public API is itself structured into two layers, a base layer and an application layer. The base layer provides common and reusable technical building blocks that can be used to create API’s for other AMS J2EE applications. The application layer provides application-specific refinements to the base layer to create a specific application’s Public API, as with PD ^e . It is in this layer that the Public API interacts with the PD ^e business rules layer.

The next layer up in the integration architecture of PD ^e is the EAI adapter layer. This layer provides the necessary software adapters that allow PD ^e to play in integrations built using EAI tools. In addition to providing the transformations needed to match specific XML standards or message formats required for integration into existing business processes, this layer also allows PD ^e to participate in complex operations leveraging the message brokering capabilities provided by contemportary EAI tools. AMS includes webMethods adapters and brokers as a part of its application suite, and can integrate with others either by coupling EAI integration environments (integrating integrations) or by supporting the creation of adapters for other EAI tools through the Public API. EAI capabilities are an important complement to the Public API, which provides the potential for integration, but does not include the complex machinery needed to couple many disparate applications with mismatched semantics.

The final layer in this architecture is the consuming application. Such applications can connect to the Public API to accomplish business processes that require tasks to be accomplished by PD ^e in addition to their own capabilities, or to provide services to PD ^e . The use of the Public API can be accomplished by the use of a variety of tools, and does not require that a consuming application commit to any of the tools used by AMS in creating the PD ^e application and its Public API.

The architects of the next generation of the product, in looking for an open and standards based approach to providing a Public API, had looked to the existing distributed technologies: COM/DCOM, CORBA and Java. The decision to move to a cross-platform middle tier and build the application using the Java 2 Enterprise Edition (J2EE) technologies ruled out the use of COM/DCOM and Microsoft-exclusive technologies. Initially, the architecture group settled on CORBA as the foundation, as this would provide the openness desired for the API—developers of other applications would not be required to use Java to talk to PD ^e but would see the application as just another CORBA API. With the rise and maturation of Web Services technologies, and the decision to eliminate a rich Swing client, it became apparent that the earlier distributed technologies like COM/DCOM, CORBA, and Java RMI were not succeeding in creating the kind of large scale, loosely-coupled distributed applications that we wished to make PD ^e a part of.

Web Services, on the other hand, offered the possibility to produce an open API that could participate in such a distributed architecture. The attraction of using Web Services is the growing support across the industry, the ties to the World Wide Web and its success as perhaps the largest distributed application ever, as well as its use in the user interface component of the application, and the simplicity of developing consuming applications. For instance, we can generate Web Services Description Language (WSDL) descriptions of the services and content of the Public API, which facilitates tool-driven development of applications that use the API.

No API of any utility can be used without some sense of the choreography needed to access the API in a coherent sequence in order to accomplish business tasks. For the present, such choreography is provided by the documentation for the API, rather than through any of the emerging facilities for registering such choreographies, such as ebXML or BizTalk. We expect at some point to integrate into such operations, but we plan on providing such integration at the EAI layer, rather than adding this complexity to the Public API. Likewise, we are deferring issues of making the Public API discoverable through UDDI and active XML registries.

An architectural style is an architectural pattern that is applied to the overall organization of a system or subsystem. At its heart, the REST architectural style is founded on a consistent scheme for naming and identifying an indefinitely large number of resources and a very limited set of well-known methods for manipulating and transferring representations of the resources between providers and users of the resources. It is a data-oriented approach to an API, as opposed to a programming-oriented approach. In it there are many things and few operations. This is contrasted with the other major technology being promoted for Web Services, SOAP, which directs an unlimited number of method calls against a single processing resource or end-point.

In the context of Web Services, the REST style means using the URI name space scheme, and the basic methods of the HTTP protocol. The URI namespace provides for many resources, and the HTTP protocol provides a small standardized set of well-known methods.

The REST style using web technologies has other advantages over the SOAP alternative for providing a Web Services API. The SOAP model follows an RPC model, producing a layered client/server pattern. In this pattern, consuming applications identify the endpoint to which calls are directed, the methods to be invoked, and the data involved separately. In the REST style, on the other hand, endpoint and data are identified together through the resource identification scheme, and methods are constrained to those provided by HTTP.

The REST style also produces a more security conscious application. While SOAP also operates over HTTP, and so is said to be firewall friendly, it is actually using HTTP as a tunnel, and its security characteristics are essentially opaque to the firewall. Increasingly, using HTTP this way to get through firewalls is seen to be a misuse, and we see products appearing which act as HTTP firewalls, filtering out traffic that has such opaque security characteristics. Of course, both SOAP and the REST style can make use of HTTPS, SSL and so on to make secure connections between API and consumer.

In addition, the Public API, while being open, does not permit just any connection. As with secured websites, the Public API requires that consuming applications identify themselves and be authenticated before any interaction can be undertaken. In order to be so authenticated, the consuming application is required to be registered with the instance of the PD ^e system with which it intends to interact. When such registration is accomplished, a security profile for the application is built, and the application’s access to PD ^e resources is contolled by Access Control Lists (ACL’s) just as an online interactive user’s access is so controlled.

Finally, by being entirely based on Web standards and protocols used in the specified fashion rather than as a tunnel, the REST style supports the HTTP infrastructure—proxies, caches and so forth—without needing to add anything into the mix or doing anything out of the ordinary for Web operations. This has positive implications for the scalability of a REST style architecture.

A good basic set of references on the REST architectural style may be found in the Bibliography at the end of this paper.

The XML resources provided by means of the API are based on existing AMS DTDs for procurement and contracting related documents. AMS has developed for the Government an EAI adapter to the current version of the Procurement Desktop—Defense application that provides a set of standard procurement and contracting documents in XML format to users of the adapter in integrations with other applications. This XML document set forms the foundation of the XML provided through the Public API. The document set includes:

Note that these documents are described with Government terms, and are the primary ones needed to allow the current application, PD², to participate in wider business processes within the Department of Defense. For the Public API of the next generation application, these are augmented with some other resource types expressed in XML. For each document, we also provide an “identifier” view. This is a short XML document that provides identifying information about a document, and contains the information needed to access the full document. There is also a collection version of the identifier view that provides identifying information about a set of documents. Finally, there is a “count” resource that provides count information on documents or resources of a given type.

The Public API resource specification allows users to make queries against the above resource types in order to obtain information about available resources. The Public API and the XML schemata for its payloads make use of XML standards such as XInclude, XLink, XPath and XPointer. Using these, the Public API provides ways to request fragments of documents, where such document parts are fully identified resources with defined URI’s. Documents can also be complex, including references to other documents and resources.

So far, we have spoken of the XML as though it were delivered bare by the Public API. However, integration with the PKI enablement components of the PD ^e architecture will have us packaging documents, simple and complex, in Secure MIME (S/MIME) envelopes. This has two benefits for our architecture. First, it provides a standard way of packaging complex documents that include not just the base XML, but also the related attachments or inclusions found in such documents, most of which are not XML, but other complex types—Word documents, CAD drawings, images, etc. Second, it provides the system with a standard way to package cryptographically processed documents, whether XML or others, by using the S/MIME facilities. The system can sign, encrypt or both sign and encrypt any type of document and expect that consumers of the Public API or other means of interacting with PD ^e will be able to handle these documents without any requirement to be using a specific tool. This capability provides us with the final elements to give us a complete approach to security in the API.

As noted above, the layered architecture approach to the Public API and the use of EAI adapters for PD ^e allows us to provide a rich delivery of XML-based documents directly from the application, as well as deliver to other applications XML based on one or another standard as needed via transformation in the EAI layer. This gives us with the freedom to create XML structures for the Public API that can do all the various things that we need to do, and to express the full range of the capabilities of the application, while at the same time, maintaining the ability to communicate with industry standard XML formats.

To make the transformation process from the Public API XML to standard XML dialects, we are looking to ensure that our XML ultimately becomes based on an industry standard. This is a long term goal, and needs to be balanced with our goal of keeping the Public API stable while the underlying application and internal APIs evolve. One way to handle this is to provide additional attributes within the framework of the existing XML schema we use for our documents. This way, everything that users of the Public API expect to find in the XML is there, and they can safely ignore the added attributes—nothing changes for them. At the same time, those who choose to use the additional attributes can do so, and gain the benefits of the facilities provided by the additional attributes.

For example, AMS is involved with the Metadata Harmonization Project of the Aerospace Industry Association. This project is building a semantic characterization structure, called the Universal Data Element Framework (UDEF) for the identification of the specific semantics of data elements defined in a metadata schema, such as a standard industry-area ontology, a particular database schema, or an XML schema. The UDEF allows one to analyze the semantics of a given term in a schema, and generate an ID, the UDEF ID, that identifies that specific meaning for the term. In this way, one can match terms semantically across different metadata schemata, an important first step in constructing interoperation between systems and processes based on these different schemata.

The Public API XML schema will evolve to include an attribute on each element that carries the UDEF ID. This attribute can be used by any consumer of the API that understands the semantic tagging of data elements, and ignored safely by all others.

We are also looking at other semantic identification schemes or ontologies which may be incorporated into the Public API XML, offering consumers of the API more choice to use schemes with which they may be familiar.

We have presented here a quick fly-over of the approach AMS is taking to providing a Public API in its next generation government procurement application. We believe there is a great deal of power and flexibility to be found in the REST architectural style and Web Services in creating a web of interoperating applications providing capabilities such as straight-through processing and hands-off automated processing to complement the power of the HTML-based Web applications in reaching users. This approach provides the real possibility of building true large scale, loosely coupled systems across large enterprises. Finally, the approach we have outlined here provides the beginnings of including semantic characterization as well—a small first step toward participating in the Semantic Web.