What is XML Centric Programming?
Many applications work with data formatted in XML. They receive XML from services, over JMS queues, and from various content repositories. The XML data can be unique to a specific enterprise application or designed by an industry consortium (ex. HL7 for Healthcare, Acord for Insurance, and IFX/FpML for Financial). The XML data can be record-oriented data coming from services in a SOA or narrative-oriented data coming from end user content such as human centric forms and documents. The correct and efficient processing of this XML data is critical to the enterprise.
These applications can work with XML in one of three ways. They can work with XML via Java API’s at an event level (using SAX or StAX) where the application is responsible for interpreting the events in a pull or push fashion by writing Java code that handles the XML data at a very low level. They can use higher level imperative API’s that map the XML to either Java Objects (JAXB) or dynamic views (DOM and SDO). Instead of working primarily from Java code, programs can work with the XML natively through languages that are XML centric and declarative including XPath 1.0 (for navigation) and XSLT 1.0 (for transformation).
While the application server has supported all of the above programming models and their associated Java API’s, the application server added support for newer XML centric programming models in the Feature Pack for XML. The feature pack included support for the newer W3C XML centric programming models of XPath 2.0, XSLT 2.0, and XQuery 1.0. With the latest version of the V8.0 beta, this support is now part of the base application server.
If your application works with XML data or is data focused, it is likely that the XML support in this beta will be beneficial. Additionally, by using these XML centric declarative programming models, two benefits are usually seen. First, due to the decreased need to map XML and data to an object oriented view, XML centric applications can be developed and maintained more quickly and lead to higher performance. Second, due to the higher level declarative languages applications can be written with less lines of code leading to more understandable and maintainable applications.
Why XPath 2.0, XSLT 2.0, and XQuery 1.0?
While the support for XPath 1.0 and XSLT 1.0 through Java Standard Edition was sufficient for XML programming for some time, these languages are now over ten years old. The World Wide Web Consortium (W3C) worked with many industries and standards to understand scenarios that couldn’t be achieved with these languages or could be done more easily with changes to the languages of XPath 1.0 and XSLT 1.0. Additionally, the W3C recognized the need for a query language for XML. The family of standards of XPath 2.0, XSLT 2.0 and XQuery 1.0 represent over seven years of open standards work at the W3C to satisfy all of these needs.
A very small subset of examples of changes that make XPath 2.0 and XSLT 2.0 easier are support for dates/times, regular expressions, and grouping. A very small subset of scenarios not possible before includes support for schema validation, multiple output streams, and locale specific collation. XQuery 1.0 represents a major addition to XPath 1.0 and XSLT 2.0 adding the support for complex deep query and joins of XML data sets.
What is included?
In order to run these newer W3C standards, a runtime is needed. The runtime supports the standards plus many of the optional features defined by the specification (including backwards compatibility which allows existing XPath 1.0 and XSLT 1.0 programs to run mostly unchanged on the new runtime and schema awareness that allows XSLT 2.0 and XQuery 1.0 to use schema meta-data important when writing flexible and reliable XML applications). This new XML support in the application server provides clean integration with the security, traceability, and manageability subsystems.
In order to invoke the runtime, a Java API is needed. We have included a consistent API across all three languages that allow you to apply concepts in only language to the other two as well as cascade data from one language to another (ex. XQuery 1.0 joined data re-formatted with XSLT 2.0). The API allows for usage of existing JAXP data sources (DOM, etc.). The API also allows you to augment XPath 1.0, XSLT 2.0, and XQuery 1.0 programs with calls to existing Java business logic and integration with existing Java data. This API was also designed from the ground up to work in server environments, lessening the burden of dealing with multi-threading that was common in standard XPath 1.0 and XSLT 1.0 API’s.
Want to learn more?
Stay tuned to this forum for a video demo later this week that shows how to get up and going. Also, we’ll document some of the scenarios we saw the XML Feature Pack being used for that can now be accomplished with WebSphere Application Server V8.0 beta. If you can’t wait to get started, you can check out the information from the XML Feature Pack.
WebSphere XML Strategist, SOA/Performance Architect
Pinned topic Feature Focus Week: XML Application Programming
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2010-09-27T22:20:13Z at 2010-09-27T22:20:13Z by aspyker