1 2 Previous Next

wiverson

24 posts

Over the last few years, I've been watching the various cloud computing initiatives with great interest - at the most basic level, I love the idea of being able to abstract the hardware purchase and spool up new virtual instances (or even just pay by the CPU cycle).

There are a number of interesting packages out there that offer cloud computing - for your reference, here are a couple I'm tracking:

http://aws.amazon.com/ec2/
http://www.mor.ph/
http://www.stax.net/
http://code.google.com/appengine/
http://mediatemple.net/
http://www.3tera.com/Get-A-Grid/
http://www.mosso.com/

Flipping through the documentation for these different sites, one thing that you'll notice is there are no consistent standards for what is and what is not allowed, how the apps should be packaged, etc. Some assume a complete virtual machine, with your own app server, others assume a WAR, others customize the deployment even more (perhaps with their own added descriptors). Most interestingly, all support different chunks and extensions of the JDK.

Even if you don't like picking and choosing interfaces, the simple fact is that there are no good standards for Java-based web application hosting. All of the specs for Java pretty much assume that you are running your own web server on your own private host - which means that everyone pursing Java in the cloud basically has to make it up as they go along. It's not meaningful or appropriate to require a hosting provider to provide support for every last bit of cruft in the JDK (e.g. CORBA), but there also is no good mechanism for sorting out how this works. It's also considered good practice to not allow web apps to do things like System.exit(). The examples go on and on - and this is part of the reason why it's hard to find inexpensive entry-level Java hosting (certainly as compared to ubiquitous cheap PHP hosting).

So, in no particular order, here are a two basic questions that should be informing the debate:

- How should a cloud service vendor indicate and choose what is supported by their platform?

- How should developers expect to package their Java application for the cloud?

A long time ago, the notion that you could reasonably expect to drop a WAR file into an app server and have it work was a pretty big deal. It was never perfect, but it did give you something to shoot for (and as a side note, that plus persistence via Hibernate always did work a lot better than EJB 1.x-2.x). That positive, simple vision is what drove Java.

I don't know precisely what combination of specifications, standards, and marketing is needed (Cloud Application Resource files, Java Cloud Edition, Certified Cloud Platforms... oh my!), but that's a more constructive conversation - and one more likely to produce results - than arguing over interpretations of specs never designed to support cloud computing.

I would certainly hate to have to point to any other competitive offerings as a possible source of the angst over interpretations of "pure" Java...

BeanView is library for automatically generating user interface forms directly from JavaBeans, with built-in support for validation and complex data models. For more information about BeanView, seehttp://www.beanview.com/. BeanView 1.0.1 has been posted. The main feature change is support for render IDs in the Echo 2 implementation, thereby adding support for Selenium. Download BeanView 1.0.1 (18MB, includes all BeanView source, the required Echo 2 distribution, and pre-built binaries & WARs - just add Java 5 and Tomcat 5.5) Documentation Online Javadoc Screenshots Selenium screenshot
I've been working on an open source framework for some time now, which I have now released as BeanView 1.0. It can be downloaded from: http://www.beanview.com/ http://sourceforge.net/projects/beanview/Briefly, BeanView allows you to create forms from your POJO + JDK 1.5 Annotations models. It supports generating forms for both Swing and Echo 2 user interfaces. No code generation is required - the form is generated entirely via reflection. For example, let's say that you want a form for an Order, which is based on a com.example.Order JavaBean ("POJO"). Simply add the BeanView Swing panel to your app, pass in an instance of the Order, and you will automatically get a user interface form (complete with validation) based on the Order class properties and annotations. Supported features include: * Per visual widget error reporting * Support for validation (both a variety of built-in validation types and an easy customization system) * Support for a wide range of built-in data types * Support for complex data models, such a mapping a collection to multiple selection list box, with custom factory methods via annotations * Automatic configuration based on JavaBean meta-data (for example, if a JavaBean declares a get/setFoo(int input) method, will by default generate a text field with integer validation). BeanView is intended to serve as a natural complement to the EJB 3.0 Persistence model and/or Hibernate or other "POJO"-based persistence frameworks. The release notes include the following information: 1.0 What Is Beanview? 2.0 Requirements 3.0 Trying Beanview Out 4.0 Getting Started Programming With Beanview 5.0 For More Information 6.0 License This release includes the source, built javadoc, and binaries (JAR files). You can drop pre-built WAR files into your application server to try out the Echo 2 implementation, or quickly launch the Swing demos. I'd be very curious to get feedback from java.net folks. I have experimented by dropping the Swing implementation into the NetBeans form designer as well as the Eclipse form designer, and it seems to work well. What other features would you need? I've looked at JSF + Creator support, but so far I've been happy with Echo 2. In any event, take a look, play around with the demos, let me know what you think. Cheers, -Will  
My previous article on web frameworks and the impact of Ajax got a lot of interesting comments. In no particular order, here are some of the general themes... - An abstraction for Ajax/JavaScript would be very, very helpful. I got several emails supporting this general view as well, not just the posts. Between HTML, JavaScript, CSS, the profusion of browsers, not to mention multi-language issues... clearly this is a pain point. - There will always be a role for custom JavaScripts for particular effects. This may be true, but the bar is also set awfully low for when you need to start using JavaScript to achieve results. As the frameworks mature, this will get better - but this also means that we are looking at yet another generation of web frameworks. - The correct way to view the solution is more along the lines of a component framework, not a single web monolithic app. Let's be clear - the JSF framework, and the profusion of third party components, are a very Good Thing(tm). There are an awful lot of web frameworks for Java right now, thanks to the efforts of a lot of passionate developers, but (especially for people new to the platform) it can be a bit overwhelming. My point is that if you are writing JavaScript by hand right now, you are likely to wind up in the same spot as all of the folks who had hand-rolled assembly in their apps a decade ago. The thing that was a useful optimization or a neat hack at the time is really likely to be an albatross in just a few years. Unfortunately, the waters are a bit choppy right now, so it's not clear that there is much else to be done - especially if you hav a client that is asking for Ajax-style features today. - There isn't really a good industry term yet for a hard-core JavaScript + OO-oriented server-side developer focused on these things yet. "Web presentation developer" was suggested, but that seems awfully close to "web developer." Maybe something like "Ajax Java developer"? As a final note, there is a java.net project called facelets that builds on Hans Bergsten's thoughts regarding JSF without JSP. I haven't had a chance to play with it in depth yet, but it looks interesting. Oh, and BTW, we still have a couple of job openings. Tell 'em Will sent you.  
I remember when I first started doing Java development, and the first time I saw a servlet in action - I thought it was awfully cool that the HTTP protocols were so seamlessly wrapped up. Wow. A lot of folks noticed that writing HTML by hand in servlets was pretty nasty, and so the idea of "flipping the code" was born. Instead of writing nasty HTML in Java code, we would write nasty bits of Java in our now even nastier HTML. This more or less worked pretty well for a long time. I had to teach a lot of newbie web designers how to find generated Java source files and figure out how line numbers mapped to the originating JSP files. Tools like Dreamweaver MX were helpful for wrangling the HTML, and this model seems to be the inspiration behind Java Studio Creator. But... and this is a big but... all of this has gotten a bit out of hand, and it's well on the way toward turning into an absolute nightmare with Ajax. The underlying theory here is that there is a "web designer" who does a bit of futzing with JavaScript, and there is a server-side developer that does the "hard stuff." Let's conduct a little experiment. Go to http://maps.google.com/ and view the source. Now, let's check out the Ajax examples for J2EE from the Blueprints group. There is a lot of JavaScript code there, stuff that needs to work on multiple browsers, on multiple platforms. Portability across browser platforms is still a bit of nightmare. How do you think they test Google Maps? Is the newbie web designer supposed to be the guy writing and/or tweaking all of this complexity? All of the JavaScript? All of the custom JSP and JSF tags in the monstrous XHTML file? The answer, I think, is to stop viewing web applications as "tweakable" lumps of DHTML or XHTML, the same way that we don't really view class files as "tweakable" lumps of bytes to be edited by hand. If I handed you a class file and told you that you could "tweak it" if you had any problems, only the very, very, very geeky among you would think that was a good idea. Instead, think of a web application as an application like any other, but it happens to render (under the scenes) to DHTML & JavaScript, instead of a native graphics toolkit. For the vast majority of applications, it's a much, much more efficient model for building an application (it also happens to be much easier to debug). For a very interesting example of this, check out the programming model underlying Echo. That's all for now, but I do want to follow up with one last thing - we are looking to hire good Java developers here at work. If you live in the Seattle, WA area (on the Eastside, for those of you keeping track), and are interested in working in an agile environment with a really, really great team of Java developers on a long term basis, please drop me a line at wiverson AT gmail DOT com. We're doing a mix of web applications, web services, Swing... all sorts of interesting things.  
wiverson

Catching Up Blog

Posted by wiverson Jun 29, 2005
Monday 
First, a couple of quick hits - EJB 3.0 support seems to clocking along - TopLink will support EJB 3.0 (sept/oct final?). Other vendors seem to be moving in the same direction. Based on the EJB 3.0 talks so far, it looks like some of the concerns from last year (e.g. annotations aren't the end-all-be-all, splitting the spec up to be more manageable) are now folded in. Still feels like a long wait, though. As many of you are no doubt aware, JDeveloper is now officially free (as opposed to the previous free-to-download-and-use-forever-but-feel-guilty model). I talked to one of the JDeveloper devs, he's got a nice blog. In other news, it's very strange and quite nice to see so many old friends at the show. People move, get married, change jobs and lives. You don't really plan running into someone you haven't seen in five years, but these opportunities to catch up truly are the gems of the show.Tuesday 
Tuesday turned out to be web framework day for me. I went to a session on Ajax integration with JSF, which provided a bit more details than the Blueprints article. For me, the key takeaway was that while the rich interactivity of Ajax is great, and the current generation browsers are more or less up to the task, without support from a component framework, it's a long, hard slog through the guts of ECMAScript/JavaScript hell to build Ajax apps. For example, during the demo, a very seamless integration of server-supplied web form autocompletion was shown. A JSF component was dragged onto the page, and all of the nasty JavaScript is auto-generated (with browser-specific functionality handled). Just write a simple method that takes the user-entered string, and return an array of strings for the auto-complete entries. Very clean, very simple, and much easier than writing the JavaScript from scratch. It reminds me of another abstraction layer - most people don't bother writing assembly - compilers take on the hard work. Similarly, I doubt most OO developers find hacking JavaScript for multiple crossplatform browsers with different object models very enjoyable. Greg made several references during the talk to the JavaScript taking 90% of the time required for developing the demo components. There are lots of details that may be obvious for an experienced JavaScripter that may not be obvious for a Java developer (e.g. the script should be broken into another file so the browser can cache the IR). Becoming a first-class JavaScripter can take years, but most Java developers don't have the time or inclination. Therein lies the rub - the simple yet-odd-bug filled world of DHTML & JavaScript has become the new nonstandard platform. A demo of autocomplete was shown as a component extension, which is very compelling example of the abstraction provided by a solid interface. For things like google maps, you're still likely to have to write code or buy a component - one could imagine a component for rendering graphics to an arbitrarly large pane, with server requests. So, I guess it comes back to sorting out the JavaScript target model (the binary interface?) for the web frameworks. Speaking of web frameworks, I've been thinking more about the JSF/JSP issue, and looking at the JSPs generated by the tools at the show I'm increasingly skeptical that anyone will ever want to deal with it. After I get back, I'll post examples of the generated JSP and a stack trace from an error and compare this to a similar situation from a Swing builder to drive and drive the point home. Many folks have already figured out that programming in XML is no fun (and indeed rather dangerous), but the mainstream web frameworks still seem to be sorting this out. Wednesday 
As a final note, the JSR 273 expert group will have a BOF session at JavaOne Wednesday evening at 10:30pm in the Mariott Hotel (Golden Gate C1). Needless to say, a 10:30 PM session will probably not exactly get a huge crowd, but I (and the rest of the expert group) would be delighted to get your feedback (esp. if you are a component developer). It's been a busy week, and it's not over yet - if you're here, hope to see you around!  
wiverson

Day 0: NetBeans Day Blog

Posted by wiverson Jun 26, 2005
Today was day zero of the show - tutorials and NetBeans Day. In keeping with my ongoing interest in IDEs, I went to NetBeans Day. There was a good deal of overview and introductions, but there was one big announcement - Sun is open-sourcing their collaboration tools. During the demo, an integrated chat window was shown hooked into NetBeans, with support for both text and audio chat. Simply dragging and dropping a project to an initiated chat session made all of the source assets visible to all parties. The remote user was able to take control and make changes and edits. The collaboration tools shown are very powerful, both for remote users and even two users across the table from each other. True, this kind of capability has been demonstrated before (on the Mac, SubEthaEdit), but I'm not aware of such a cleanly integrated package, or anything like this for Windows (certainly not open-sourced). Folks use instant messaging software all of the time to collaborate, but it's a clunky affair compared to this. Oh, and I just checked - they just posted the new Swing form designer,Matisse. There's also an early access of Creator 2. That's a lot of bits to check out, and the show hasn't even officially started yet. Nice.  
wiverson

Planning for A Decade Blog

Posted by wiverson Jun 25, 2005
Tomorrow marks the start of the tenth JavaOne. Having attended every single JavaOne, it's a little disorienting (disturbing?) to think that it's now a decade old. It looks like the advice for this period includes such pearls of wisdom as "the 10-year-old is very social," and "this may be a relatively calm period," and that the ten-year-old "is concerned about rules." At first blush, the question seems to be: is there going to be anything interesting at this year's show? I've heard some folks wondering if Java is still interesting, but I think things are just getting started. On my short list for the show: - Keep a scorecard in the NetBeans vs. Eclipse debate. Personally, I like both IDEs quite a bit, generally using Eclipse for more server-side work and using NetBeans/Creator for front-end development. It may sound a bit insane at first to use two IDEs, but I find that by splitting my time between the two for different projects, I feel a bit less reliant on a particular way of thinking. Things change, and we all win by having these two duke it out. - See how the EJB 3.0 stuff is going along. I did write a book on Hibernate (blatant plug), and so I'm very interested in how (and when) EJB 3.0 material comes along. A beta of Hibernate annotations is a nice start, but not quite enough. - I'm particularly interested in anything related to components at the show, as I'm on the expert group for JSR 273: Design-Time API for JavaBeans (JBDT). - I'm very interested in the various presentation tier web frameworks at the show. I've seen people in forums referring to YAWF (yet another web framework), and there certain is no shortage of entries. I love the idea of the rich JSF component framework, but I'll confess that I'm increasingly sick of the reliance on JSP (as described in Hans Bergsten's Improving JSF by Dumping JSP, dated June 2004). The Echo Framework seems a lot closer to my hopes. Between the ongoing developments of the last year, the next version of Creator, the addition of Ajax to virtually every framework... it's going to be an interesting show for a presentation tier fellow. ...so, even after a decade, I'm finding there's still a lot to look forward to this year. Viva Java!  

I'd like to preface this entry with a brief comment: do NOT schedule your out-of-state move the same week as JavaOne. More on that in a moment.

I managed to hit (and tremendously enjoy) the first few days of JavaOne this year. Here were the key walk-aways for me:

1. JSF is clearly the future for Java-based web UI development. The model is much richer and coherent that most of the other frameworks I've seen, and the adoption is going to be huge. In particular, I'm looking forward to seeing a robust tool market around JSF. I heard a lot of concerns about missing features from other frameworks, but reading both JavaServer Faces (O'Reilly) and Core JavaServer Faces put my fears to rest.

2. EJB 3.0 is looking good. If you want to get a head-start on a lot of the concepts, check out Hibernate.

3. There is a ton of great new stuff in J2SE 5. Only question, of course, is the usual adoption curve problem...

4. Client-side Java is getting attention again. JDNC, JDIC, and a host of other projects (including many Java desktop projects hosted on java.net) are finally pulling things together.

On the web services front, I'd like to mention that I was on a panel at the eBay developer conference the week before JavaOne. I've posted a whitepaper I put together on eBay's web services, interesting stuff if you are trying to evaluate web services for your own company.

Shortly before JavaOne I had a chance to talk with Hideya Kawahara about Project Looking Glass. If you are a client side developer interested in building the generation of rich, interactive, 3D apps, you should check the Project Looking Glass Q&A out.

Oh, and about that move: I've relocated from the California Bay Area to Seattle, WA. Moving over the 4th of July weekend was quite exciting, let me assure you - apparently, half the country moves that weekend. In any event, if you are located in the Seattle area, feel free to drop me a line. I expect to make occasional appearances at the excellent SeaJUG, and also will be pulling together the SeaBUGover the next month or two.

More fun today with JSF, including some discussion of integration with the new POJO persistence systems, and some musings on web services.

JSF & JDO

I’ve had a chance to play around a bit with Creator, and it looks like plain old Java objects (or POJO) will play nicely. One nice thing about JSF – it knows about collections, which means that Creator can work with them easily as well.

One session today focused on integrating JSF and JDO. Unfortunately (or fortunately, depending on your point of view), there was little in the way of JDO/JSF integration that wouldn't be just as applicable for a user of Hibernate and (presumably) EJB 3.0. Between investigating Creator last night, the session today, and conversations with Creator staff, it looks like the use of Creator and any of the POJO-based persistence mechanisms should be very clean. Specifically, you can build your model and then bind the resulting POJO-based objects to your application forms quite easily, allowing a model/persistence developer and a presentation developer to work naturally.

Web Services

Having written a nice white paper on eBay web services (a billion web service requests a month!), and having a book on Real World Web Services coming out soon, I’ve spent some time working with deployed web services lately (in particular, SOAP, WSDL, and a variety of other XML/HTTPS systems). As of right now, SOAP and WSDL together seem to work reasonably well, with a number of vendors providing support for the two in conjunction with Apache Axis (among other language/platform toolkits). Point a tool at a WSDL, and get automatic bindings for your preferred development language. Great stuff.

It's far less clear when (or if) the various other "standards" for web service security, business processes, choreography, etc. are going to be significantly adopted. A huge number of problems loom, from questions about debugging and overall complexity to a timeframe for any sort of realistic adoption. The mind hurts just thinking about it...

Tomorrow, I'll likely indulge in a session covering the OpenGL bindings for Java -- while I may not be writing the next killer game anytime soon, it's certainly fun to contemplate...

JavaOne this year is proving to be an exciting and interesting event. Between Hibernate and EJB 3.0, there is a sense that the persistence world is moving toward a more rational, coherent model. Initial skepticism over JavaServer Faces (JSF) is waning in the face of the broad tool and component vendor support. Many developers are warming up to the new features (and understanding the implications) of Tiger. All this interesting technology combined with a noticeably better economic outlook make for a pleasantly positive show.

In no particular order, here are some of the interesting personal highlights as of Monday:

- JSF is looking like a compelling component model for building web applications by assembly. In particular, there is a good chance we'll see a rich third party market for JSF components - one session I attended today showed sophisticated JSF components for charting and GIS. JSF components (and implicitly Creator) are going to have a huge impact on how we build Java web applications. There is some grousing about favorite pet features from other frameworks not appearing in JSF, but the writing seems to be on the wall.

- Sun appears to be reinvesting in 3D and entertainment technologies. This includes reinvesting in Java 3D, building game-centric OpenGL Java bindings, and the development of a server for massively multiplayer games. 3D technology plays a significant role in Project Looking Glass. It'll be interesting to see how this strategy unfolds over the course of the next few years.

- Tools, tools, tools. There are a huge variety of tools at the show, in addition to the JSF web/presentation tier Creator. Many vendors are demonstrating development tools integrated with Eclipse. Oracle's JDeveloper, available for a free trial (no timebomb, no restrictions) includes an astonishing array of functionality including Java/UML synchronized modeling and visual JSP design. NetBeans continues to advance, with a number of events planned for later in the week. Perhaps the most brutal thing for the various tool vendors is the sheer variety of frameworks in use. If you are attending the show, be sure to let the vendors know what frameworks you use now, and what you expect to be using over the course of the next year.

A good vibe, fun technology, new and interesting tools - a great start to the show.

wiverson

Still Lots To Be Done... Blog

Posted by wiverson Mar 12, 2004

So, I've posted a brief list of significant things that the technology business really ought to get working on.

I wrote this list up on the plane after reading several articles about how the technology business was in the doldrums, more or less arguing that we already had pretty much everything we need. The idea is so laughable... it reminds one of that infamous 1899 USPTO quote, "everything that can be invented already has been invented."

Take a look at the list - network aware UIs, security, and more. As a by-the-way, I do believe that Java could (or is) be a major force in virtually every one of these areas - or needs the innovation described (e.g. portable point energy sources).

As a brief disclaimer - I actually wrote this list a few months ago, but didn't bother posting it... like we need another coffeehouse pundit... but a friend told me I was to blame if the tech business collapsed because I didn't post it. Too much pressure for me...

Oh, and that USPTO quote...? Apparently, it's a myth. Go figure.

Feel free to either email me or post comments here...

So, I started playing around with a tool called Fujaba (a reasonable free Java/UML modeling tool). I needed something that would export UML class diagrams as vector graphics, and Fujaba seems to work fine (hint: increase the memory allocation from 128MB to something more reasonable, like 512MB).

Unfortunately, the only vector format that Fujaba supports is SVG. I'd like to have an EPS instead, as that's the preferred format for print. Unfortunately, as near as I can tell, there is no support for converting SVG to EPS. I can use Batikto convert to a raster format (such as TIFF), but obviously that's a lot less efficient.

I did a bunch of Googling. Lots of hits for announcements of SVG support from a variety of vendors, but a lot leaner when it comes to actual products and projects (commercial and open source). I found some stuff that indicated some folks were pushing SVG as a Flash replacement. The support I did find, however, was mostly in the SVG as EPS or static vector alternative. The final kicker - I could find plugins that supported SVG, but none of them worked as an inline object.

 

So... wither SVG? Are people still building and investing in it?

wiverson

Great Looking Swing Blog

Posted by wiverson Jan 29, 2004
Take a look at the demos (WebStart-enabled) at jgoodies.com. Some very nice looking Swing apps - and you can grab the look & feel libraries for your own apps. Looks good, and demos well. Anyone tried building anything interesting with them, or have any other suggestions for those interested in good ol' fashion desktop development?  

So, I'm working on some material related to web services right now, and I'm pondering what at first seemed like some straight-forward questions.

"What's going on with web services nowadays? Where do you think it's going?"

So, this led to some investigations into the state of SOAP, REST, RSS, UDDI, BPEL & BPEL4WS, XML-RPC, and all of that. Looking at the current state of affairs (and downloading and playing with the SDKs) of several vendors that have published web services.

I've managed to develop a few opinions so far about where things are (more on that later), but right now I want to hear from you - what do you think about web services? Which technologies and specifications are you using, and why? Equally important, what does the business side of web services look like for you? Have web services solved any technical problems for you, or made (or saved) you money?

If you asked your boss about web services right now, what would s/he say?

Trying to cut through the politics and the hype...

Filter Blog

By date: