For applications developers working on Web-based front ends, JSF and SDO may be two of the most important specifications since—well, since Java itself.

JSF, or JavaServer Faces, is an official J2EE spec for building user interfaces for server-side applications. Service Data Objects, or SDO, is a new concept that simplifies data transfer between the persistence and presentation layers of an application by using disconnected data graphs. That's a mouthful—but it's a powerful method of abstracting data access.

Let's take a look at those two specs, and see what makes them tick, and how they can be useful for rapidly creating data-rich user interfaces for Web applications.

JavaServer Faces
JSF is an official J2EE standard, JSR 127, that defines a set of standard JavaServer Pages tags and Java classes that simplify creating complex HTML forms and other common GUI elements. JavaServer Faces encompassed six core elements:

• Create a standard GUI component framework which can be leveraged by both tools and runtime environments.
• Define a set of simple Java base classes for GUI components, component state, and input events, which address a component's persistent state for the lifetime of its page.
• Provide a set of common GUI components, including the standard HTML form input elements.
• Offer a JavaBeans model for dispatching events from client-side GUI controls back to the server.
• Develop APIs that can handle input validation at both the client and server.
• Handle generating the right code for the client's software configuration, including browser capabilities.

JSF also has features designed to handle internationalization, localization and accessibility requirements of Web applications.

JavaServer Faces has proven to be one of the most successful methods of reducing the complexity of developing J2EE applications.

It has seen incredible adoption by tool makers and by developers. IBM was one of the first to implement JSF, with a pilot implementation first appearing in WebSphere 5.1.1—even before JSR 127 was approved. The JSF implementation lets developers create user interfaces, and map user interactions, using a drag-and-drop metaphor; there's very little coding required. For an excellent tutorial on JSF, see "Developing JSF Application Using WebSphere Studio." Today, of course, JSF is thoroughly baked into WebSphere 6.

Service Data Objects
Now, let's look at Service Data Objects, initially proposed by BEA Systems, now JSR 235. The specification is still in development; IBM and BEA Systems have formed a working group, but haven't yet brought their work to the full Java Community Process. However, both IBM and BEA have implemented SDO in their WebSphere and WebLogic app-server platforms, respectively.

The purpose of SDO is to make it easier to pass data between the persistence and presentation layers of a J2EE application by abstracting and encapsulating them as "by value" Java objects that represent the data independently of the underlying persistent technology.

Presentation layer programming is, of course, what JavaServer Faces aims to simplify. Thus, the combination of JSF and SDO should simplify the design and programming of Web applications that require robust access to persistent storage—regardless of how that data has been persisted. It should also help pass data back and forth between the presentation layer and the underlying business object.

There's already extensive documentation about Service Data Objects, mainly by BEA and IBM at this stage of the technology's development. You can learn more from BEA and from IBM.

In June 2005, BEA and IBM released version 2.0 of the Service Data Objects specification. You can download the actual spec, as well as the appropriate Javadoc files and interface source files from either of the above links.

On-Demand: Easily Build a Web Service Client Using JSF and SDO—View the Demo This demonstration shows how to easily find a Web service from a registry on the Internet, and create a simple client based on SDO and JSF. It's all done without writing any code.

Disconnected Data Graphs
As BEA and IBM describe it, SDO is based on the concept of disconnected data graphs, which is a collection of tree-structured or graph-structured data objects. Under the disconnected data graphs architecture, a client retrieves a data graph from a data source, mutates the data graph, and can then apply the data graph changes back to the data source. The SDO specs include the mechanisms to handle optimistic concurrency, ensuring the integrity of the underlying data sources.

Figure 1. The disconnected data graph architecture used in Service Data Objects. Source: BEA/IBM

Those data graphs can be dynamically created from just about any data source, including XML files, EJBs, XML database and relational databases—or from Web services, Java Connector Architecture resource adapters and Java Message Service packages. As you can see, this represents a robust way to abstract and manipulate data, through the use of a single set of APIs and Java classes.

Applications interact with those service data objects through a class of components called data mediator services. These services query the underlying data sources, and use the data and schemas in those sources to create (and populate) the data graphs, and also to apply changes back to the data source later, if needed. Figure 1 shows the architecture; the circles refer to the Service Data Objects themselves, containing the data graphs. The client, as you can see, doesn't need to know anything about the underlying data sources' implementation.

Simplifying J2EE Application Development
As you can see, the combination of JavaServer Faces and Service Data Objects can have profound benefits for developers creating data-rich Web applications using J2EE. JSF can provide a visual metaphor that speeds the creation of the presentation layer of the application—in many cases, replacing tedious programming with drag-and-drop coding and easy deployment. SDO simplifies and abstracts how those Web applications use data sources, using a single data graph architecture to provide access to heterogeneous data sources, whether those are Web services, XML files, EJBs or relational databases.

You can get more technical detail in the IBM developerWorks story "Introduction to Service Data Objects: Next-generation data programming in the Java environment". But if you want to actually see how it works, IBM has a Developer On-Demand Demo, "Easily build a web service client using JSF and SDO," that shows you how to do it. Without any code, you'll see how to find a Web service from a registry on the Internet, and create a simple client application. Check it out!