What Should Be XMLized ?

What Should Be "XMLized"?

Even though John Muir lived before the age of computers and thought in terms of the natural world, I don't think he would be too surprised to learn that his observation holds true for the world of business applications. Very few of our business applications are used completely stand-alone; they almost always share data and have interactions with other applications. The data sharing may be crude and the interactions made by humans , but the "hitching" is still there. So, the easy answer to identifying what we should turn into XML is this: Anything that can be consumed by another application or produced by another application for yours to consume is a candidate for representation in an XML format. This is consistent with the basic approach in this book of using XML as an interchange format. In addition to this generalization, you may want to consider XML as the native data storage format for certain types of application information.

Beyond these rather general guidelines, the road ahead has gotten a bit confused over the last year or so due to the introduction of so-called "Web services." I say "so-called" because the term has been loosely applied to many fundamentally different technologies. It is sometimes hard to tell whether someone discussing a Web service is talking about a real architecture or just engaging in a bit of marketing hype by describing old products with the latest buzz words. This situation wasn't helped by the fact that it took the W3C's Web Services Architecture Working Group a long time to achieve an apparent consensus on a concise definition of a Web service that had any real descriptive power (and at the time I proofread this chapter they were still discussing it!). Be that as it may, some real and potentially revolutionary concepts and technologies form the core of what is commonly understood as the Web services architecture. The general consensus is that the Web services architecture involves building distributed applications that run over the Internet (or at least over IP, meaning private subnets instead of just the public Internet). Some of the key technologies commonly included in this model are XML, SOAP (which started out as Simple Object Access Protocol but now is just SOAP), Web Services Description Language ( WSDL ), and Universal Description, Discovery, and Integration ( UDDI ).

I say that the road has become confused because the level at which we integrate applications has become a bit confused. There is a fundamental difference between importing or exporting batches of documents and "exposing" key application functionality as a Web service on the Internet. So, I feel a need to clarify exactly what we're going to cover in this chapter and in Chapter 13. This chapter will basically take the position of traditional application integration, that is, importing and exporting batches of documents (or other data). We'll begin and end at the XML document. Where it came from and where it goes to (at least at the technical level) are issues we'll discuss in Chapter 13.

This doesn't mean that this chapter (or the rest of the book) doesn't apply to your Web services strategy if you choose to develop one. If the Web services approach is about anything, it is about effectively using XML. So is this book. A Web service might provide the XML document to your application or you might hand off the document to a Web service. We're dealing with the XML documents that supply the business content component of a Web service, but any other consideration of Web services architecture is beyond our scope.