JavaOne2006 - Day3

Some of the hottest topics at this year's event were Ajax, scripting languages, JavaServer Faces and the new features in Java EE 5. See what other events made the list.

Day 1 | Day 2 | Day 4

Service Data Objects or Data for Service Objects
Developers Love XML and Wonder about XQuery
Tools, Techniques to Go Beyond SOA Basics
Ajax Smackdown Panel
Ajax - Revolutionary or Rich UI hype?
Vendors show off their Ajax wares
JavaOne News from Day 3

If you happened to overhear attendees lounging around in the bean bag area between sessions, having a few drinks in the lobby of the W hotel, or congregating outside the Moscone, it was apparent that some of the hottest topics at this year's event were Ajax, scripting languages, JavaServer Faces and the new features in Java EE 5. Also, while Java Business Integration (JBI) wasn't covered as heavily this year, certain design and architectural concepts have transcended the SOA hype cycle and have appeared on the radars of enterprise Java architects.

Service Data Objects or Data for Service Objects

Steve Brodsky from IBM and Michael Cary from BEA hosted a well-attended session on JSR 235 and Service Data Objects (SDO.) SDO provides a convenient way to move data from a data source to an SOA-enabled application. SDO is an abstraction over datasource services like SOAP-based Web Services and JDBC access to relational databases. This makes sense for BEA, IBM and the other presenters since they would otherwise have to develop their own datasource abstraction layer to have their platforms (AquaLogic, SAP NetWeaver, and others) communicate with a variety of data-sources.

For instance, Cary told developers the AquaLogic Data Services Platform maps between enterprise data and data services on a logical level. SDO in AquaLogic is a super-sized JDBC-like interface to work with multiple datasource types, including Web Services, relational databases, and other ways of accessing data. Cary told developers that BEA says AquaLogic implements an updated framework that supports XA and non-XA sources, automated change decomposition, automatic SQL generation for RDBMS, hooks for business validations, replacement logic, or compensating transactions, and ADO.NET interoperability. SDO gives BEA a way to move data between client and server, gives them a data model, and gives them a way to think about what to do with the data.

Cary introduced speakers from Oracle, SAP and Apache to talk about their SDO use. Oracle Fusion architecture is a model driven, service-oriented, grid architecture that is information-centric, standards-based, and hot pluggable. Oracle uses SDO to deliver as a Fusion Service Bus and Fusion Service Registry that runs on top of a grid computing layer and below a business process orchestration layer. The Apache Tuscany project intends to deliver an open-source SDO implementation. The project started in January and hopes to complete SDO 2 by the end of this year. Details are found at http://

Developers Love XML and Wonder about XQuery

Jonathan Robie, co-inventor of XQuery, led a JavaOne session to introduce developers to XQuery, show the XQJ interface from Java programs to XQuery, and show a practical example of using XQuery in a Web/SOA setting. Robie used the Stylus Studio XML IDE connecting to DataDirect's XML datastore and also talked about the Eclipse plug-in for XQuery built by the Oxygen company. I'm an XQuery fan so it didn't take much for me to get behind Robie's very smooth explanation of XQuery.

In Mark Reinhold's earlier session of bringing native XML support to Java, Reinhold told developers that he sees XQuery as a language unto itself. This seemed like a seminal moment to me for XQuery in that most people I speak to have an impression that XQuery is just a successor to SQL. It seems like Robie's presentation and Reinhold's remarks put XQuery onto a new stage of its acceptance.

Tools, Techniques to Go Beyond SOA Basics

In a nice complement to Jonathan Robie's introductory XQuery session, Ash Parikh from Raining Data showed the XML-centric tools SOA developers need when they get past their initial SOA projects. Parikh told developers that the keys to long term SOA success are in three areas: how quickly your code will implement data and service models, scalability and performance, and how to achieve governance and retain flexibility.

Parikh told developers the core challenge of SOA governance is to provide an adequate governance infrastructure that scales while still providing the agility and flexibility that SOA architectures require.

He showed examples where metadata management - the information about services and data - became key to corporate visibility, policy management, and governance. While some of the industry thought leaders at JavaOne questioned the details of SOA itself, Parikha talked about the dynamic business environment an enterprise creates when it chooses SOA and how metadata becomes more important in these environments.

Parikh then attacked relational database and file system approaches to storing metadata and SOA payloads. He told developers that SOA payloads are fundamentally hierarchical (XML) data and do not do well in relational stores because SOA uses quickly evolving and often ad-hoc schemas, especially as business requirements change.

Parikh demonstrated sophisticated search of a metadata repository using XQuery and a native XML database. He demonstrated a policy-based service caching system to accelerate SOA performance and a service federation mechanism where multiple services are queried on the backend and the union of the results is presented through a single service interface.

Ajax Smackdown Panel

Everyone it seems wants to bring the rich internet experience to their websites in the same way that Google Maps to the world of online map websites. Nearly every session dealing with Ajax in any way was packed at JavaOne: Introduction to Ajax Frameworks, Ajax and JSF, Java EE Blue Prints for Ajax, etc. What more natural to fit in amongst these technical sessions than a round-table smackdown style shootout between the various rich-client frameworks. Ben Galbraith of assembled a panel of Rich Client Interface experts to do just this. Featured in the panel were:

  • Alex Russell - Dojo Toolkit Lead
  • Ed Burns - JavaServer Faces Technology Co-Lead
  • Chet Haase - Java SE Platform/Java Web Start Software
  • Christophe Coenraets - Adobe Flex 2.0/Flash
  • Joe Walker - DWR

During the opening statements, the panelists each had an opportunity to summarize their frameworks:

  • Dojo: A very powerful framework for building rich browser based applications using Ajax.
  • JSF: A server-side Java framework for assembling WebPages using highly reusable rich UI components. As Ed Burns summarized it during his intro, "JSF is a good approach for Ajax. JSF provides a model to scale complexity as application requirements grow. Ajax doesn't make things easier."
  • Java Swing with Web Start: Java Swing is the incumbent framework for providing rich desktop applications prior to the push to make applications browser based. Web Start provides a means for Desktop clients to install and update automatically through a Web server.
  • Adobe Flex/Flash: A plugin for the browser providing a consistent, browser based, rich client interface which can interface with JMS, Web services and other Java APIs without using any JavaScript.
  • DWR: An Ajax framework for calling Java from JavaScript and JavaScript from Java, and for simplifying many of the most challenging tasks when using the Ajax model.

During the opening statements, the panelists quickly agreed upon one key point: "Ajax Doesn't Make Things Easier." If you take an existing application and attempt to add JavaScript with Asynchronous Callbacks to the server, your complexity is going to increase. Fundamentally, the Ajax model dividends the logic into the Servlet/JSP sending the original context, the JavaScript running in the browser, and the Servlet handling the asynchronous back to the server. This increases complexity. The frameworks seek to reduce this explosion of complexity back to manageable levels.

Ben Galbraith, serving as moderator, asked a series of cutting questions, which resulted in the following key conclusions being suggested by various panelists:

  • JavaScript is the most widely deployed VM in the world.
  • The JavaScript language is VERY different than Java; Java is "class based" where classes are the fundamental programming unit. JavaScript, on the other hand, does not use classes, using "prototypes" instead which allow the meta-data and structure for objects to be dynamically built and customized on the fly. This can make JavaScript very hard to read.
  • One of the major values of JSF+Ajax is that the JSF component model encapsulates all the various artifacts required to make an AJAX enabled UI component.
  • If you want something that is pixel perfect, get out of the browser. (The Adobe Flex guys disagreed, arguing Flex seeks to address this limitation of browser based rich clients.)
  • The 2 JavaScript threads restriction of Internet Explorer makes using "long-lived" background asynchronous requests to the server very difficult. While the frameworks seek to manage the plumbing, this fundamental restriction increases complexity greatly because it means the various asynchronous requests that might result in a page need to collaborate to share these scarce threads wisely. This increases complexity.
  • Dojo is very powerful, but is seriously lacking documentation. The Dojo spec leads are working to create a new model for tracking Documentation for JavaScript frameworks (similar to how JavaDoc became the model for documentation in Java, but with the intent of the Dojo documentation system learning from the lessons of JavaDoc).
  • Flash and Flex are VERY powerful - while the flash plugin for the browser has reached relative "ubiquity," passing what the panelists refer to as the 80% deployment rate, Flash and Flex are still largely resisted by programmers who view it as a very proprietary solution. The natural counter-point to this resistance is, of course "If the solution works and is cost effective and gets the job done quickly, do you really care?"
  • DWR allows you to expose server-side JavaBeans to JavaScript through Ajax. This can create security concerns and the security implications of this model are still being addressed (just as the security implications of Web services are still being addressed six years later).

Leaving the session, the fundamental conclusion an attendee might draw from the session is that while Ajax and rich browser based UIs are the rage, the frameworks are still evolving and innovating at a rapid pace. The approach we use in 2 years to write applications will unquestionably be different than the approach we use today.

Ajax - Revolutionary or Rich UI hype?

At this year's event, all the major Java platform vendors at the show, Sun Microsystems Inc., BEA Systems Inc., IBM, JBoss Inc. and Oracle Corp., were touting new found Ajax capabilities. Three smaller Ajax tool vendors -- BackBase B.V., ICEsoft Technology Inc. and JackBe Corp. -- were hawking their wares on the show floor.

Some of the big vendors may partner or, in the Darwinian world of software, swallow up the little Ajax companies.

Bill Roth, vice president of the BEA Workshop Business Unit, said his company has been impressed with the Ajax development framework from BackBase. He said BEA is working together on some implementations in the Netherlands, where BackBase is based. Roth said the two companies are in preliminary discussions about partnering, so the BackBase Ajax development tools might soon be bundled with BEA Workshop.

Not everyone at JavaOne was wild for Ajax, however.

Tim Bray, XML pioneer and director of Web Technologies for Sun, said Ajax might be wielding a double-edge sword.

"The clamor around Ajax is about the richer user experience," he said. "That's kind of a two-edged sword. We used to have a richer user experience in the days before the Web with Visual Basic and people stampeded into the arms of a simpler user experience with the Web browser as soon as they got a chance."

Bray's concern is that the rich UI could become a techno-bauble heavy UI that might leave end users dazed and confused.

"Ajax does give you the power to develop very bad user interfaces," Bray cautioned.

On the plus side, he said Ajax can make Web applications run faster for the end user by eliminating the back and forth between the Web browser and the server.

"Obviously a user interface that is faster is categorically, unqualifiedly better," Bray said. "If that's the only contribution Ajax makes that would be plenty big enough."

Vendors show off their Ajax wares

Bringing desktop-like speed and responsiveness to Web applications is the selling point for all the Ajax vendors, but approaches vary.

In the relatively new world of Ajax technology, BackBase is one of the older vendors having opened for business in 2003 to create a richer UI with JavaScript, said Jouk Pleiter, co-founder and CEO. Recognizing that JavaScript was not the easiest scripting language to work with, the company developed tools that allow developers to create Ajax interfaces without getting into what he terms the JavaScript "plumbing issues."

"If you look at JavaScript in general, it's a very complicated language to program in. It is difficult to get it consistently behaving across multiple browsers and that is exactly why a company like BackBase exists," Pleiter said. "So, actually what we do is we say, JavaScript is great, you can create a very attractive interface with it. It's a rather complicated programming environment so we've tried to hide the complexity of JavaScript."

While some tools aim at the UI developers who work with scripting languages, ICESoft provides tools aimed at enterprise Java developers who work on the server side. In the ICEsoft booth at JavaOne, Ken Fyten, product manager for its ICEfaces tool, demonstrated its drag-and-drop capabilities working inside Sun's Java Studio Creator. Buttons and calculator objects can be moved into place with the code generated automatically, so there is a minimum of code writing and editing.

With the logic residing on the server, Robert Lepack, vice president, marketing at ICESoft said the ICEfaces approach avoids overloading the browser. "The Web services run on the server and only send snippets to the browser," he said. The server-centric approach extends to a feature ICEsoft calls "Server-Initiated Rendering," which automatically and asynchronously updates the browser when data, such as a stock price or an online auction bid, changes on the server.

The JackBe NQ Suite of tools takes an enterprise SOA approach to Ajax, said John Crupi, CTO, who came to JackBe from Sun where he had been working on SOA technology. The JackBe approach was to take lessons learned in SOA and apply them to extending SOA with Ajax as "an enabling technology."

"One of the problems that SOA had was that initially people were building Web services in SOA architecture from the bottom up," he said. "So they took an inventory of everything they had and said, let's just make this a Web service and we're SOA. But guess what? It was never designed for that level of granularity. So, next round they got smart and started doing them more top-down and basically aligning with the business units and asking what does business need and what are the applications and that drives the definition architecture of your SOA backend."

In its short life Ajax has followed the same trajectory in the developer learning curve, in Crupi's view.

"You can build a page and sprinkle Ajax widgets, but if you're actually going to build a full-blown mission critical application for businesses, you have to think of the end-to-end architecture," he said. "So we just see Ajax as a natural extension and alignment to the backend enterprise, also highly aligned with SOA. It allows you to create applications, but it's purely just an enabling technology, Ajax, it's not a solution in and of itself."

JavaOne News from Day 3

Dig Deeper on JSRs and APIs

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.