Implications for SOA and Future of Enterprise IT
But there are other practical limitations of the object-oriented development approach. The failure of CORBA showed that the object-oriented approach is fundamentally ill suited for building Internet-scale, loosely-coupled distributed systems. Just as with the XML processing approaches mentioned earlier, CORBA's attempt to achieve interoperability at the API level relegated the wire format (the persistent data) to afterthought status, leading to a distributed system design that is brittle, tightly coupled, and stiflingly complex. Those painful technical lessons of CORBA have ultimately led 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 first in messages.
Document-centric XML processing fits into and enhances the technical foundation of SOA. Simply put, by thinking in messages, you gain not just loose coupling and simplicity, but efficiency as well. It is quite harmful to think of your services in objects. Consider an SOA intermediary/broker application that aggregates multiple services. Pretty much all it does is to splice together fragments from multiple documents to compose a single, large document and shove it upstream. Objects aren't really necessary in that scenario. As another example, consider a service's dissemination point (the exact opposite) where large XML documents get split into several smaller ones, each of which gets forwarded to a downstream recipient for further processing. Again, there's no need to allocate objects to perform that task. As more services become available, you'll discover that composite services/applications are mostly about slicing, editing, modifying, splicing, and splitting documents. In such an environment, traditional, object-oriented design patterns become increasingly less applicable, whereas the simpler, more intuitive way of dealing with documents directly is highly efficient.
In many ways, the programming experience for building SOA applications is a lot like building the Internet itself, requiring you to think of building applications in networking terms, such as Open System Interconnect (OSI). Your services—especially those residing in the middle tier—represent a new breed of networked information devices possessing the following characteristics:
- Application layer devices—These devices behave more or less like routers, switches, and filters sitting in the wiring closet in your datacenter, except that they speak XML, rather than IP. They are services in themselves, and can assume a variety of names, such as XML router/switch, SOA intermediary, message/service broker, etc.
- Integrated native XML databases—From time to time you'll want to persist and index messages in transit natively to serve other requests at a later time.
- XPath and XQuery—Query languages such as XPath and XQuery are used extensively, not just to achieve loose coupling, but also for routing, switching, filtering, querying, and transformation.
XML has finally emerged as the most powerful universal wire format. Not only is it easy to learn, human-readable, interoperable, and enables loose coupling, it also leads CORBA, DCOM, and RMI by a mile, performance-wise (you can read more here
But SOA is only a part of the larger IT transformation of "Copernican" proportion, in which the focal point of enterprise architecture is irreversibly shifting away from "application" toward "data." Increasingly the "smarts" are being moved out of applications and into data, because making data smart helps ensure interoperability with present and future applications, both within and external to your organization. Therefore, it seems to me that the correct model is to let objects (an "application-level" concept as applications consist of interacting objects according to OO design doctrine) revolve around persistent data (which outlives objects and applications) instead of the other way around. In other words, applications and objects come and go, but your smart data lives on forever. Object-centric notions of serialization and de-serialization are the wrong way to think about XML documents, not just in the context of SOA, but in the larger context of IT architecture as well. To design the next-generation, services-oriented, "smart-data" enterprise you'll need to pick up the XML slicer and turn yourselves into "data" artists.
The rest of this article shows you how to combine VTD-XML's slicing, modifying, and editing capabilities to intelligently manipulate XML document content. Each example consists of a brief description, the input XML documents (side-by-side with the output documents so you can see what the application does), and the Java code. You can download the complete code for the examples in Java, C#, or C. There are many more examples in the code download than could fit in this article.