The Inflection Point for SOA
After reading many great articles posted on The Code Project, it seems to me that many readers in the community are career-long, ardent practitioners of the object-oriented methodology. In my view, OO may not always be the right tool for the job. The fact that the serialization/de-serialization problem becomes invisible when you approach XML processing from a pure object-oriented perspective tells me that this design approach has practical limitations. In the world of distributed computing, the consensus is that objects don't distribute well across the process boundary (e.g., across the network). Starting from the early '90s, the distributed computing community spent about 10 years attempting to figure out ways to make distributed objects (i.e., CORBA) work as if those objects reside in the same address space. But, the effort was eventually abandoned due to numerous technical issues (please visit the rise and fall of CORBA for further reading). Among those issues are tight-coupling, rigidity, and stifling complexity. It is those painful lessons of CORBA that lead us to SOA, which achieves loose-coupling and simplicity by explicitly exposing the XML messages (the wire format) as the public contract of your services. In other words, when building loosely coupled services, think in messages.

How does "document-centric" XML processing fit in and enhance the technical foundation of SOA? Simply put, by treating XML as documents (instead of the serialization of objects), you gain not just loose-coupling and simplicity, but efficiency as well. It usually doesn't make sense to think of XML as objects. Consider an SOA intermediary application that aggregates multiple services. Pretty much all it does is splice together fragments from multiple documents to compose a single large document and shove it upstream. Where do objects come into the picture? Take the services dissemination point as another example. It is the exact opposite: large XML documents get split into multiple smaller ones, each of which is then forwarded to the respective recipient (downstream services) for further processing (see Figure 2). Do you see the need to allocate a lot of objects? As more and more services come alive, you'll discover that the composite services/applications are mostly about natively slicing, editing, modifying, splicing, and splitting documents. Traditional, object-oriented design patterns are going to be less applicable. The moment you step across the boundary of OO and into a document-centric world, both the problem and solution become obvious. Everything suddenly seems to make sense again. But doing so may not be easy; you first need to have the courage to refuse to go along just to "get along," and do something that nobody around you seems to be doing. The web is undergoing a profound transformation around the concept of SOA. The experience you gained from doing SOA the right way should prove to be both rewarding and valuable in the end.

In short, to prepare for the upcoming wave of service-oriented computing, right now may be a good time to start embracing this "document-centric" view of XML processing.

Code Examples
Listing 2 shows how to use VTD-XML's cutting, splitting, editing, and transcoding capability to manipulate XML content with both flexibility and efficiency. To understand what the code does, each example places the input and output of the application side-by-side.

Recap and Conclusion
I hope that this article has described to you how VTD-XML fundamentally solves the common issue of DOM and SAX. The simplest problem, in my view, is also the biggest problem, not just because it affects everyone, but it is so deep that you have gotten used to it already. This is where VTD-XML again stands out. Be it parsing, indexing, modifying, cutting, splitting, or splicing XML documents, VTD-XML excels in virtually every aspect imaginable, while breaking new ground in others. But, to reap the full benefit of VTD-XML, you first need to step out of the comfort zone of object-oriented thinking and start to think of XML as documents. As the world of IT transitions toward a service-oriented architecture, I am confident that you will discover, in many ways, that the "document-centric" approach to XML processing naturally lends itself to designing and implementing your SOA infrastructure. To me, this is why VTD-XML is the future of XML processing and why the best is to yet to come.

If you have visited VTD-XML's project site, you've probably noticed that VTD-XML has a C version that delivers the exact set of functionalities as its C# counterpart. But unlike C#, C is neither OO nor based on VM. Worse, C doesn't even support exceptions. So, there are interesting challenges to porting VTD-XML from C# to C. In the next part of this series, I will discuss how to overcome those challenges to maximize code reuse and reduce the porting effort to minimum.