Feature

Digg This!

Page 1 of 2   next page »

Moving information from a database into an application may be the most common challenge developers face. How many of us make it through life without meeting object/relational (O/R) mapping in some form? Certainly not too many. Lately it has become equally difficult to avoid XML/relational (X/R) mapping. Because XML, and especially XML Schema (XSD), are object-like paradigms, the mapping difficulty is approximately the same. However, under the ever-expanding influence of XML, the extract, transform, load process that gets data from a database into an application (and vice versa) may be about to get radically more simple and declarative.

Today if you find yourself thing thinking about X/R mapping you have three main options to look at:

1. Bind Data Definition Language (DDL) to XSD (possibly creating the XSD in the process)
2. Use XSD to create or map to DDL
3. Use XQuery to extract and/or declare data bound, at least implicitly, to both XSD and DDL

It is a big field and there may be other approaches, but let's look at how these three options play out in the market for practical solutions and developer mindshare.

In practice, binding DDL to XSD happens regularly. Most often this involves developers using tools such as Altova XMLSpy to generate the XSD from the database structure, and from there using JAXB, Microsoft's Xsd.exe, XMLSpy, or another means to tie the XML structure to objects. This route, however, does not get you away from the need to somehow query the database and iterate through the results, inserting individual values into objects. There are other tools that can automate these steps, but the requirement still exists.

The second option of constructing the XSD first and then deriving both the classes and the DDL from it is very similar, at least in some ways. A main advantage of this approach over using the database as the primary structure is that you have a clearer single source for your data management and code structures, whereas if the database structure takes the lead, you typically have XSD or another type of model working as an intermediary to your classes. Moreover, XSD typically offers something very near to a superset of the typing capabilities of both the database and your programming language. This option is most often performed using XMLSpy to build the XSD and automatically convert it to a database structure, then optionally, using a visual data integration tool like Altova MapForce to map between individual fields, insert data processing rules, and generate customized data conversion code for use in your project.

The third option utilizes XQuery. As you are probably aware, XQuery is still a work in progress, but XQuery has been fairly stable for about a year and it is very near to becoming a formal W3C recommendation, as a peer of XPath 2.0 and XSLT 2.0. Moreover, XMLSpy, and perhaps other tools, now can be used for writing, debugging, and interpreting these new standards, and MapForce can even generate XSLT 2.0 and XQuery code from XML Schemas. If you are an application developer, I suggest you do not wait. Grab an implementation and take a long look at these new standards because they may just complete the enterprise mainstream's shift to declarative development.

What does all this mean? How will these new standards provide the missing link? Declarative development means not programming your application, but rather modeling and describing the processes and links between processes using XML technologies. XSLT and XSD are today's declarative entry points and are in wide use, but XSLT 1.0 has significant limitations as an application platform. XSLT 2.0 (along with XPath 2.0) was designed to address those limitations, however XSLT 2.0 is not intended as a query language. For a complete data access, transformation, delivery, and presentation solution, utilizing XSLT 2.0 (for visualization) plus XQuery (for data access) is the next logical step to take. Keep in mind that the custom-developed part of the typical business application is not algorithmically complex. Rather, that custom-developed core logic is really just a matter of modeling one or more complex processes that have complex data. The benefit of moving to declaring that core part of your application in XML, XQuery, and XSLT 2.0 is that more of the mundane code that still must exist somewhere becomes a commodity part of your application server infrastructure. The result is faster development, fewer quality issues, and greater long-term maintainability.

This revolution has admittedly been a long time coming. The changes responsible for boosting developer productivity will:

• End the need for O/R mapping frameworks
• Eliminate most custom code at the network interface and in the domain model
• Finally result in a universal object query language

Most programming model changes are evolutionary. This shift is revolutionary, not because it has anything to do with a switch to XML technologies, but for one simple reason: it is possible that for many business applications hosted on the typical corporate intranet (e.g., purchase order or personnel management applications) there soon won't be any programming necessary. This will free you up for less tedious tasks that require more creativity and a better understanding of your customer's requirements. The previous, often non-XML-based moves in this direction didn't come close to offering that outcome. Before slicing and dicing the three points above, let's take a look at how it all ties together, and how the new standards will push us past a declarative tipping point.

Imagine a typical server-side, browser-based human resources application for a large firm built in the near future. In one component of the application an HR professional can browse, edit, create, or delete employee information. That information is stored in a database that is used by several other applications and holds other types of related information. Without getting into all of the requirements, let's say that this application has ten main screens, a good number of business rules, and must create, read, update, and delete data from the database.

Suppose the architecture of this application is based on the J2EE frameworks (although the scenario is equally likely in the world of .NET). The presentation side of the equation will be constructed as XML from the standard JSP tags, XHTML, and CSS. Those JSPs will tend to be simple declarative pages that make calls against an EJB business API. The information returned will be in the form of XML. That XML will be transformed using XSLT 2.0 into XHTML. So far this is fairly typical, even for today.

Page 1 of 2   next page »