Applications: XML, Web services pave the way

HHS' Susan Warshaw says XML is an effective tool for modeling an enterprise architecture.

Olivier Douliery

Computer applications express agencies' missions as code. Missions stem from a blend of policy and the management of implementing policy. Policy makers these days are demanding agencies cut IT costs by sharing applications and data, avoiding redundancy. They want citizens to have one-stop shopping for government services.

For program and technology managers who must pay for and build applications'or pay to have them built'it all means radical change is coming. Change that will redefine the way you think of traditional databases and enterprise applications.

The transition is toward decentralized development and fragmentation of the applications, towards the obsolescence of centralized runtime environments.

Application development is still in flux. But what is emerging is a picture of apps broken apart as developers migrate to building series of remote calls and services, of applications that interact with multiple data resources throughout the government. Such services may live anywhere from your server to some place far outside your network.

For the short term, this technology path leads to use of Extensible Markup Language for information sharing. One example is the Navy's use of XML as it designs its new Navy-Marine Corps Intranet portal.

Longer term, the trend is toward ever broader use of Web services.

Experienced code jockeys will tell you the Web services idea is nothing new. The main concept, a remote-procedure call within an application, has been around for nearly 20 years. There are also more efficient ways to place such requests than the text-based protocols used by Web services.

So what's changed? For the first time, a majority of the tech community has agreed on a unified way to call functions remotely on multiple systems. It's a vendor-neutral approach that can reach across manifold operating systems, databases and apps.

But the transition is complicated enough, and the standards'beyond XML anyway'are hazy enough that the migration will not happen tomorrow or the next day. Talk to federal IT architects, you'll hear that most of them are experimenting a bit with XML and they have Web services on their radar screens. But without a standardized government tag set for marking XML data, or a government- wide approach framing an official way to implement Web services, it's risky for most to jump into the fray too soon. Avoidance of that risk will delay e-government and widespread interagency IT sharing.

Developers also realize a different step is needed before taking their applications in this new direction of fragmentation. The Office of Management and Budget is pressuring agencies to complete their enterprise architectures. Program and technology managers must understand what they already have in place within their agencies'which applications are redundant, which ones need to be grown and extended. For apps that ultimately will be extended across the enterprise and to external partners, Web services will be the likely answer.

Modeling helps

'At the Bureau of Engraving and Printing we had success using an XML repository for enterprise architecture,' said Susan Warshaw, who recently moved from the bureau to become the IT enterprise architect for the Department of Health and Human Services. She said they used Metis, an enterprise architecture modeling tool, from Computas Inc. of Sammamish, Wash.

Warshaw said one of the benefits of modeling the enterprise architecture is to know the extent of your enterprise and to establish communication with the application stakeholders as future plans are made. 'I used it as a way of gaining knowledge of my apps and data.'

Ira Grossman, IT architect at the National Oceanic and Atmospheric Administration, said his organization is taking the same approach, outlining the business model of the enterprise first, and making decisions for the applications infrastructure based on that model.

'For most people, Web services are still on the horizon,' said Bill Wright, president and chief executive officer of Computas. His company is working with several agencies, including the Treasury and Commerce departments and some intelligence offices, to model their current enterprises before pressing ahead.

That might delay the transition, but it should ultimately ensure that efforts are focused in the right place.

For most agencies, the process goes something like this:
    1. Map and understand the enterprise and all of its applications. Often this is done via visualization tools that show how the systems, databases, data warehouses, products and processes interrelate.

    2. Understand where all applications fit into the agency's strategic plan. That means involving the policy folks.

    3. Eliminate redundancies and focus on those applications or parts of applications that you must extend to reach new participants, including those who have traditionally been outside your network.

    4. Use XML as the quickest means to publish and share data.

    5. Develop a long-term plan for using Web services to extend the functionality of an application internally and externally.

Like middleware

At a basic level, Web services can be thought of as middleware that enables application-to-application connections and interactions.

Web service transactions simply run over HTTP and TCP/IP networks, the same as Web pages. Beyond that, the Web service architecture has three main elements: discovery, description and transfer. Each of the three has its own standard developed around an XML foundation.
  • Developers can discover which Web services are available for use by an application via the Universal Description, Discovery and Integration. Think of it as a directory standard where applications and services can be listed and located for transfer over an IP backbone.

  • To describe the services available on your system, and to learn what services are available on other systems, use the Web Services Description Language.

  • Use Simple Object Access Protocol to let applications actually connect and communicate.

  • Think of XML simply as a way of formatting the process and tagging the data sets that will be shared. The radical thing about XML is that data can reside anywhere: in a database, on a spreadsheet, in flat files or Web pages. XML fractures the traditional concept of how applications draw from a database. Tagged data sets can reside wherever they are needed and used, and applications can be reworked to use them.

As agencies move toward e-government, they'll also move toward data sharing and application extension. As they continue building new architectures and cutting costs, they'll find it logical to share services and eliminate some applications entirely.

Shawn P. McCarthy is an Internet consultant and free-lance writer in Marlboro, Mass. E-mail him at mccarthy_s@lycos.com.

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above