Oracle has submitted a new JSR called "A Standard Data Binding & Data Access Facility for J2EE". This proposed spec will define a framework of classes, called Declarative Bindings, that formalize the interactions between typical UI components and values and methods available in your business logic (such as a Session Facade layer).
Check out JSR227: A Standard Data Binding & Data Access Facility for J2EE
If I understand the description correctly, this JSR could eleminate the need for much of the manual logic required to map presentation layer data to the business logic layer, and put this into metadata instead. So its possible that we might not need to write the equivelent of Struts' action classes anymore. Pretty cool!
Interesting because, this paradigm is already used by several Enterprise Application software vendors (Siebel, Peoplesoft etc.), but the implementations are proprietary. I think Oracle is going in the right direction but is a looong road. It will help its Oracle Application configuration. Eagerly waiting for its new Jdeveloper to see the implementation of this JSR.
I really hope that this time the JSR will at least utilize the experience of people who have been doing similar work for years. In the past the JSR EGs have had the practice of walling off people in the open source community who have had a lot of experience in that domain -- JSF comes to mind as a recent example -- it makes a number of mistakes that would have been avoided had people with similar experience been contacted. There are a number of other examples like that in the past as well.
I think _at the very least_ this EG should consult with people like Drew Davidson who is the author of OGNL (http://www.ognl.org
) -- an object navigation system that currently does pretty much what the stated goals of this JSR are (except the last part) and is in wide practical use in frameworks like Tapestry. These people represent a lot of real-world experience in the very same problem domain and have had to resolve a lot of issues that can be encountered only after the designs have been tested in practice. The JSR would be much more powerful with that experience taken into account.
In present times almost everybody who is writing some app unsing J2EE is bouncing the wall with the same problems. Almost every project uses list to browse data - pagable, sortable etc. and e.g. idea of a list notified somehow about the changes to underlying data would just give these people a peaceful sleep :). And this is only one example..
So probably if more peole (like those ones) would get informed about this kind of JSR and what is more about its solution (I wonder how long will it take) the more spectactors and contributors this JSR would have. But how to get all interested people involved when they are so busy doing the same things on their own ;]
It looks to me like Oracle are proposing to standardise what they already supply as part of JDeveloper and its BC4J framework and bindings, so it seems they already have a track-record here.
I don't work for Oracle but I have used their BC4J framework on projects (though I have limited practical experience with the "conceptually separate" bindings) and I think the lack of coverage it receives on theServerSide is fair criminal. I recommend, particularly if what the standard is proposing seems useful to you, that you download and check out JDeveloper (since it's pretty much a pre-existing implementation).
[Unlike most Oracle products, there's no run-time licence cost to the framework either...]
BEA has similar types of extensions available in BEA WebLogic Workshop 8.1. They are called "NetUI". They take a slightly different approach and I know that we are talking with a number of different companies about consolidating different elements into a more consistent Data Binding model.
NetUI leverages an extended version of ECMAScript with a combination of custom tag libraries to "bind" to data that is stored in an HttpSession, Application, URL, request, JSP page. The NetUI tags are very exhaustive, but give you unique abilities to "query" the data stored in an object and then display that data on a JSP based upon other criteria. The data being displayed on the page can be read-only or read-write based upon the type of UI control being used (obviously a label is read-only, but a text field could be read-write).
Data binding tags give enormous possibility. For example, one of the NetUI tags in Workshop is a repeater. If the repeater tag is pointing to an XML document stored in an HttpSession, the repeater is smart enough to provide a set of properties that allow you define how the repeater should display the XML repeating data (list, tabular, raw, etc.). It gets interesting when you apply NetUI within NetUI capabilities.
The NetUI capability we have doesn't bind directly to an EJB or other J2EE component, so what Oracle is doing is unique. NetUI in our contact references a Web-specific object mentioned above. This is necessary because Web applications are done in the context of a user that is managed by the Web application.
This is just cool stuff.
have you folks considered submitting these excellent comments (expert group formation, scope, etc) to the feedback alias for this JSR (jsr-226-comments at jcp dot org)? During the JSR Review ballot these comments go both to the submitter and to the Executive Committee votingg on the JSR.
JCP Program Office.
...is what comes to mind if I read such stuff. "Declarative Data Binding" can of course be very complicated, but most approaches (BEA Oracle) I have seen so far are just scratching the surface of the problem. So my experience is basically that they tend to fail in a lot of "real world" situations. Besides "formalizing" bindings to transactional resources will allow for arbitrarly wasteful, resource-locking applications.
If competetion has - in the past 5 or so years given the J2EE space alone - not been able to produce a decent, flexible and usable approach, it is a bit blue-eyed to believe that "standardization" will do.
What I have seen so far, such approaches only work well, if they act upon a quite "constraint" data/object model, as with SAP etc.