On the business API side, there will be one or more stateless session EJBs. These are not today's custom developed EJBs - instead they are built into the application server. Their primary mission will be to host and execute an XQuery that is embedded as part of their XML descriptor and to return the XML result (or an error message in exceptional situations). On the JSP side, each JSP knows what operation it is responsible for triggering and displaying. A standard tag library will set up the EJB request and direct the resulting XML through an XSLT 2.0 stylesheet for formatting as HTML. That HTML will then be displayed as the complete page. Everything done in this future application is declarative, from the UI to the business API to the database manipulation, and no functionality will be sacrificed to get there.

Follow that basic pattern of JSPs containing tags that call session beans that use XQuery to manipulate data enough times, add in a dash of XACML (XML Access Control Markup Language), XSLT 2.0, and other facilitating declarative infrastructure, and pretty soon you're talking about a real application. Can this exclusively XML-based pattern do everything that might be required of the application the way compiled code does today? For the majority of business intranet applications the answer is "yes." Between the power of XQuery, XPath 2.0, and XSLT 2.0, there isn't much you would need to fall back on Java (or C#) for.

What this means is that in one stroke the new standards knock off a pair of long-standing problems that have repeatedly failed to get full industry consensus in the past: O/R mapping and a common query language.

But wait, XQuery and the others provide an X/R solution, not an O/R one, right? That is basically true. However, if all of the objects you create for your application are generated from XSD or are involved in executing XQueries or XSLT 2.0 stylesheets, you don't really have any significant objects. In that case, they will be pushed down into the application development infrastructure to become a standard part of the application server. Now you don't have that O/R problem anymore - it becomes an X/R issue with a very clear solution, and the infrastructure is already moving in this direction.

What stands between the future and us? Given the way the client sides of so many enterprise Web applications are built today, getting the procedural code out of the picture becomes just a matter of connecting the persistence layer (XQuery) and the client (XSLT-HTML). That is where the declarative deployment descriptors of EJBs and Web services come into play. Add in an XSD-defined domain model, as well as some client-side JavaScript, if you must, and the transformation is virtually complete, at least for the most common ~80 percent of business applications.

With the shift to declarative application development you will see:

• Significantly increased interoperability due to the shift to technology's most open standards, i.e., the W3C's XML recommendations
• Much greater flexibility to adapt and configure applications because they are now boiled down to just the essential logic that can be more easily understood and quickly modified and validated within XMLSpy
• A new way of looking at systems development where coded algorithms are islands within an architectural ocean of infrastructure and declarative data transformation and flow