Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

XML and Java: A potent partnership, Part 1

Find out why XML and Java have captured the minds of enterprise application developers

By Todd Sundsted, JavaWorld.com, 06/09/99

I'm happy to say that I've returned from my brief sabbatical all in one piece. While I was away, I had the opportunity to work on an interesting e-commerce application. On that project, one of my responsibilities involved specifying the interface between the server and a bevy of external systems. One facet of that task involved defining the format of the messages to be exchanged. The client's sole requirement was that the message format utilize XML.

Prior to this opportunity, I had always thought of XML as a "new and improved" HTML. I learned, however, that what began life as a "new and improved" HTML had application in domains far removed from Web publishing.

I intend, over the next several months, to explore these "other" applications of XML, with an eye toward the places where those applications intersect with Java. Of course, my column will remain true to its origin as a source of practical instruction (the "how to" aspect) by providing guidance on how to use Java to facilitate the development of these applications. In the process, I hope to help you gain a deeper understanding of how Java and XML work together.

This month, I'll examine XML's role in the exchange of data.

A brief history of computing in the enterprise

At first glance, it may seem odd that XML, a language designed for document markup, has garnered such attention from the enterprise application development community. It's not so odd, however, once you understand the historical background of computing in the enterprise.

The automation of formerly manual business processes was one of the first important tasks for which computers were employed. Since business processes were typically segmented along departmental lines, the systems that automated those business processes were also segmented by department. The resulting systems were characterized by narrow scope -- they often did little more than automate the same steps and procedures that comprised the manual business process -- and lack of interoperability, as they seldom integrated with other systems. These arrangements became known as stovepipe systems: systems oriented toward the needs of a specific group of people or toward a specific purpose with little or no horizontal integration.

Computing, therefore, looked a lot like the illustration in Figure 1.

Figure 1. Independent islands of computing

A telecommunications company, for example, might have had separate systems for plain-old telephone service (POTS) customers, inter-exchange carrier (IXC) customers, and wireless customers.

This created two significant problems. First, the systems didn't interoperate. Second, they duplicated critical business data. These problems made it difficult to create a single, comprehensive view of customers, their behavior, and their value to the company. The business computing model had to change.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.