Architect's CornerXML—the enterprise infrastructure glue?

IN THIS INSTALLMENT of the "Architect's Corner" we examine XML in the enterprise and provide a taste for various ways to create interesting XML-based architectures.

Panacea or Mass-Marketing Hype
I don't think I've ever seen a technology so overhyped as the panacea for all aspects of computing as XML has been. Granted, it fills that illustrious communication void we have all been hoping to fill donning XML "The Language of Communication." Due to this, it creates a tremendously compelling communication story.

XML is based on three very important features that have an excellent track record:

  • Openness.
  • Standards-Based.
  • Trim and Slim.
Openness is another way of saying free and not proprietary. There seems to be two ways something becomes ubiquitous nowadays: Either it is free or it is a monopoly (I mean, alleged monopoly) that has a gazillion-dollar marketing campaign backing it. I like the first option myself. "Free," has had an excellent following over the past few years—look at Java™ technology, Web browsers, and the hugely popular Linux. Just imagine if any of those were not free. So, let's conclude "free" is good.

Openness has much to do with the rate of acceptance, whereas standards-based is more about an agreed-on format, usually governed by a nonprofit group. Some of the popular standards are, of course, HTML, HTTP, and the reason for this column, XML. Communication standards allow systems to communicate and exchange without having to rely on proprietary formats. They also protect investments by not locking into only one vendor. The only problem with traditional standards setting bodies is that they usually do not move at Internet speed. However, even that is changing.

Trim and slim is the technical term for lightweight and small. This happens to be very, very important in distributed computing, where anything that goes over the wire needs to be compact. XML, just like HTML, is pretty trim mainly because it is text-based and works well as an over-the-wire text data type. Notice, I said data type and not protocol.

Since this column is supposed to be about architecture, let's look at how and why XML can be used in various architectures.

XML in Content Production
Having the Web tier use XML to generate HTML has some very interesting applications, especially in generating dynamic content. Actually, the tremendous rise in dynamic content is causing a trend, which may affect the traditional Web tier as we know it. Essentially, it is beginning to look like there is a demand to break the Web tier into two separate tiers:

  • Content delivery.
  • Content construction.
Today's Web servers are responsible for both content construction and delivery. Originally, Web servers were designed to return static content and be done with it. But, the industry quickly saw the need for extensions and dynamic content, and soon Web servers grew into these sophisticated do-it-all monster servers.

Now we are approaching the third generation of Web services, which has an even greater need for dynamic content construction. Because of this, there exists a need for the Web server to delegate its content construction to another service in the construction tier. Figure 1 shows how the single Web/presentation tier is broken into two content tiers.

Figure 1
Figure 1. Web/presentation tier transformation.

The idea behind this dual partitioning is that we put the demanding content construction burden on the construction tier and let the Web server do what it was originally designed to do, deliver content. Also, the construction tier becomes a real server and can work in the background instead of just being reactive like the traditional Web server. This now gives you the ability to have the construction server working all the time (or as needed) to construct content and have it ready to provide content to the delivery server. Think of the construction server as a Web server on steroids and the delivery server as a smart request router and delivery machine.

The construction tier has three responsibilities:

  • Get the dynamic data.
  • Transform it into content.
  • Return it to the delivery tier.
Because of these responsibilities, the construction tier is a natural home for XML. Figure 2 shows how it may work:

  • Construction service gets a request for content.
  • Construction service makes business calls and transforms data into XML.
  • Construction service transforms XML into HTML using XSL (extensible Style Language).
  • Construction service returns HTML to delivery service.

Figure 2
Figure 2. Web construction service.

A nice side effect of delegating construction to a separate service is that the heavy XML processing burden is put on that service while the delivery service does what it does best.

Infrastructure Management
XML provides an excellent hierarchical data representation, which makes it great for infrastructure management, specifically to:

  • Monitor server metrics.
  • Define load-distribution policies.
Monitor Server Metrics
Monitoring a server is about server metric reporting. Simply put, a server is responsible for returning info about itself. If using CORBA or RMI, you might create a Mgmt-Info object that has a bunch of metrics in it. Unfortunately, CORBA and RMI are not the Internet protocol of choice, HTTP is. Therefore, we use HTTP to get to the server and have the server return a XML document containing the management info. The nice thing about this method is that we can get to any server over HTTP and all we need is an XML parser, as shown in Figure 3.

Figure 3
Figure 3. Management information transport.

Load-Distribution Policies
Management information is purely static information about the server. Load-distribution policies (LDP) on the other hand, are more about behavior or action. An LDP usually states, "If this, that, and the other, then do this." In other words, LDP is a way to define what needs to be done in a given situation. For example, let's say a server reports the number of connections and the transactions per minute (tpm), which looks something like this:


<?xml version="1.0"?>
	<MgmtInfo>
					  <numConnections>1000</numConnections>
					  <tpm>1000</tpm>
	</MgmtInfo>
In addition, the LDP looks like this:

<?xml version="1.0"?>
<LDP>
  <numConnections max="990"> </numConnections>
  <tpm min="1100"> </tpm>
  <action NO_MORE_CONNECTIONS time="3"> </action>
</LDP>
Figure 4 shows how a load-distribution manager (LM) would obtain the XML Management Info and compare it to the LDP. In this instance, the LM would see that the numConnections of 1,000 is greater than the numConnections max of 990, and the tpm of 1,000 is less than the tpm min of 1,100. The action, NO_MORE_CONNECTIONS just tells the LM to disallow connections for 3 minutes (time=3).

Figure 4
Figure 4. Load-distribution manager with XML policy collaboration.

In a more realistic environment there would be multiple servers and the load-distribution manager would examine each server and act appropriately.

XML as a Disparate System Exchange
Notice I emphasized "disparate." Before I talk about how you may want to use XML to exchange info, let's talk about how not to use XML.

Say you have an intranet applet that talks to a set of CORBA services. Each server has a few objects with a few methods, each taking various data types. So, you've been reading about XML everywhere and have to get it on your resume. You change all the CORBA interfaces to have only one method, which takes a single string. Then you write a slick Object-to-XML converter and send XML over the wire. The server then gets the XML string, parses it, and uses your XML-to-Object converter. Sounds cool, huh? Well, using XML in this manner is not only unnecessary but much less efficient than using CORBA and RMI.

Why? First let's get back to the disparate description. Since you "own" both the client and server (because you developed them), there is no compelling reason to introduce as generic a data type as an XML string. By doing this, you create more flexibility but take a huge performance hit each time you convert from native type to an XML string and vice versa. You also take a hit on the server every time you parse the incoming XML. Strongly typed CORBA (or RMI, for that matter) interfaces let you take advantage of all the type checking, optimized over-the-wire packaging, and efficient transport mechanisms. So, let's call this example the Anti-XML use case.

With that being said, the place you do want XML is in an environment where disparate systems need to communicate and the ubiquitous HTTP is the protocol of choice. Furthermore, you want flexibility and openness over strong typing and over-the-wire optimization.

Sounds relatively easy, XML over HTTP. We used to call this integration, but that is too passé for the Internet generation, so we now call it B2B. The problem isn't so much connecting systems together via HTTP—it's in the XML definition and semantics.

Anytime I've had to integrate (I mean B2Bgrate), there were huge political, ego-driven battles about what the exchange data format should look like. Imagine getting a room full of medical-supply company architects together and having them decide how medical supplies are represented in XML. Forget about what should be in the XML; just getting agreement on what tags should be named turns into a slugfest. That's why we have consortiums such as OMG and Oasis to referee.

Ok, let's say we were lucky and all the medical supply architects agreed on the XML format. We would still need an infrastructure to support the exchange. In any integration architecture, there exist two key elements:

  • Integration hub.
  • Connectors and adapters.
Integration Hub
The integration hub is the engine to which all traffic flows. This is a very simplistic view, but for the sake of time, let's keep it pretty high level. Figure 5 shows how the hub accepts HTTP traffic in the form of XML. The XML could have virtually any agreed-on information, including actions. More sophisticated hubs have business rules or processes, which do things (activities) with the XML such as validating, firing events, and forwarding to other participants.

Figure 5
Figure 5. Integration hub.

Connectors and Adapters
Connectors and adapters provide the connectivity to the integration hub. The participants, also known as consumers and producers, use adapters to convert from HTTP/XML to proprietary APIs and protocols (see Figure 6).

Figure 6
Figure 6. Connectors and adapters.

The connector provides the HTTP connectivity from the participant to the hub. The adapter has the following roles:

  • Accept and send HTTP.
  • Parse XML.
  • Convert XML elements to native types and vice versa.
  • Make proprietary calls.
When the integration hub with business processes is introduced into the architecture it creates an enterprise workflow infrastructure.

Summary
I wanted to give an idea of some interesting ways to use XML in the enterprise. XML is here to stay and can serve as a powerful tool to solve many of our traditional integration issues. So, get on the XML bandwagon, create innovative architectures, and keep in touch.

If you would like to know more about enterprise architectures, have comments about those presented, or want to suggest another topic for a future column, please email your thoughts to [email protected]. We will do our best to address as many requests as possible.

Trademarks
Sun, Sun Microsystems, the Sun logo, and Java are trademarks or registered trademarks of Sun Microsystems Inc. in the United States and other countries. Sun Microsystems Inc. may have intellectual property rights relating to implementations of the technology described in this article, and no license of any kind is given here. Please visit www.sun.com/software/communitysource/ for licensing information.

Most   Popular