Mike De Groot is the Oracle representative and the specification lead for JSR-227 . We sat down with Mike for an interview about JSR-227, data-binding and the future of application development.

Tell us a little about your work at Oracle?

I've been working at Oracle for the past 10 years, all in the tools areas. Since 1997 I've been leading the development team for Business Components for Java, currently known as ADF Business Components. I am currently leading the development effort around the Application Development Framework's (ADF) data binding layer, and I'm also functioning as the spec-lead for JSR-227 since its inception a year and a half ago.

What is JSR 227 all about?

In one sentence we say that JSR-227 defines a standard way for tools to implement the interactions between user interfaces and services, doing this in a way that will work for any user interface and any service technology.

In the world of MVC applications the View and Controller layers need to interact with the Model layer. Until this JSR came along, the developer had to learn the specific API for the technology that implemented its Model layer in order to build his View and Controller layers.

With JSR 227 there is a single standard API that works with any implementation of a Model layer - regardless of the implementing technology which can be EJB, SDO, XML, Javabeans, etc - as well as with any implementation of View layer, such as JSP, JSF, Struts, Swing or any new technology that might pop up.

How did JSR 227 come to be?

While we were developing the architecture for the Oracle Application Development Framework for JDeveloper 9.0.5, we were very conscious of making sure we are using standards for each one of the layers. And this was easily done as we had the various J2EE standards to guide us. But one thing that was missing was a standard way to connect different implementations of data-sources and the various view/controller layers.
We realized that there are common methods that you'll be using no matter what is your data-source and how you choose to implement your persistence layer. You'll always need to get and set values of attributes, you'll work with collections going through the instances or rows, you'll do the basic CRUD operations etc.
What was missing is a standard API for all these operations that will enable us to write the parts that connect the various user interfaces we were planning to support and the various data sources - this is how we came up with the idea for JSR-227.

Who will benefit from JSR-227?

We envision two main groups that will benefit from this JSR. One group is providers of tools for building user-interfaces of applications. Tool Vendors will develop data binding facilities that rely on the data-control interfaces. Providing the link between UIs and business services. Once I build support for JSR-227 into my tool, I'm able to use any business service that provides a data-control implementation in the applications that I build . I only have to write my JSR-227 implementation once and I get to use any data source.

The other group is providers of business services. For example I might be a business service provider with an innovative way to implement business service. Now all I need to do is provide a data control implementation to my business service - any tool that supports JSR-227 will be able to use my business services in a transparent way. And I automatically expose my new technology to a lot more developers.

What is the relationship between JSR-227 and ADF?

You might say that ADF is the birth-bed for JSR-227. We had something working in ADF, and we basically refactored the APIs we have developed for ADF and made them the APIs for JSR-227. Once the JSR is finalized we can easily refactor ADF to be compliant with the JSR.

Also for ADF we already developed data-control implementations for TopLink, EJB, Javabeans, Web Services and of course ADF Business Components. And we provided the link to JSP, Swing and JSF with the upcoming ADF Faces components.

How will JSR-227 influence the future of application development?

You can look at JSR-227 as an enabling standard for Service Oriented Architecture (SOA). The concept of SOA is that you can pick up services from anywhere and use them in your application. What JSR-227 will enable you to do is ignore the specific implementation of the service and easily bind user interfaces to this service. This helps create the needed separation between service developers and application developers.

The other thing is that you get an easier experience in developing applications. Developers of user interfaces would no longer have to worry about how to tie back to their data sources, the tools they'll use will do this part for them. The skills they have developed in building user interfaces with a specific technology will carry across to any new project no matter what the back-end of this new system is.

This JSR is part of our focus on the toolability of the Java development space. When you think about it JSR-227 is actually opening the tools market for new innovative ways of building the application interfaces, freeing tool developers from worries about the back-end of the system and letting them focus on delivering better ways to build applications. We think we did the first steps with what we offer in JDeveloper, but we know there is a lot more innovation out there that will show up in the near future.

This interview was first published in the January 2005 Edition of the Oracle Java Newsletter.

Watch a replay of the "Introduction to JSR-227" seminar.