I got an invite to the 2009 edition of JavaOne as a blogger, with a Press Pass and everything ;-).
The conference is at the Moscone Center in SanFrancisco.
June 1 saw the CommunityOne prelude to the actual JavaOne conference that would follow from the 2nd to the 4th.
The General Session opened with Dave Douglas (Senior VP, Cloud Computing and Chief Sustainability Officer at Sun) anchoring the event and introducing other speakers. The major focus of the morning's General Session was Cloud Computing, with a secondary emphasis on OpenSolaris.
Lew Tucker, Sun's Cloud Computing CTO (yes Virginia, there is such a title), came up on stage with Dave and the two had a conversation in which they described the "Sun Cloud" (a meteorological contradiction in terms, but never mind).
I was glad to see that they actually called out an important point that usually tends to be glossed over at events like this - Open Source is not enough, it's open APIs and interoperability that are really important. Hear, hear! Obviously, we're a way away from having interoperable clouds, because most first movers seem to want to lock in users even as they tout the Open Source underpinnings of their solutions.
Lew Tucker demonstrated what I thought was a very cool tool - the Sun Cloud Compute Service, or at least the GUI tool that's used to configure it. Using a drag-and-drop interface, it's possible to set up a complete network, with firewalls, switches and all manner of servers, then have that configuration created in the cloud.
The virtual servers can even have the MAC addresses of their VNICs set during this configuration.
I was glad to see that besides OpenSolaris, some of the other server platforms available were Fedora, Ubuntu and CentOS. I've observed that the Linux support subscriptions from Red Hat and Novell/Suse are generally priced in such a way as to make mainframes look cheap. Since I don't believe that mainframes can be cheap, I'm happy about the CentOS, Fedora and Ubuntu server options. Depending upon the Sun Cloud pricing, we may actually see lower costs associated with cloud computing. [But with Oracle's acquisition of Sun, I'm not holding my breath.]
The Sun Cloud Compute Service doesn't seem to be in General Availability mode yet. Perhaps it's just released to a few partners right now. Some of those partners came up on stage to briefly discuss their wares. These were companies like Moonwalk, Vertica and WebAppVM. I didn't have time to digest what these people were doing with the Sun Cloud, but they did seem to derive some benefit from smooth virtualisation.
Someone mentioned an emerging standard for specifying virtual configuration topologies called OVF or some such. I'll need to keep an eye out for it.
Sun is also reportedly working with the Center for Internet Security to develop standards for securing virtual machines. The servers that Sun Cloud will provide on its drag-and drop palette will all be hardened by default.
Some of the tools being offered for cloud computing are Netbeans (for development), Hudson (for continuous integration) and Kenai (for repositories).
There was a panel hosted by Jon Fowler that delved into what's new and cool in OpenSolaris. There does seem to be a fair bit there. Sun Open Storage is based on ZFS. DTrace is another component that's built into the OS core, so everything that runs on OpenSolaris can be dynamically instrumented with very low performance impact. Project Crossbow is another initiative that deals with network virtualisation. Compared to Linux, OpenSolaris appears to have a few advantages, such as networking efficiency (OpenSolaris can continue to process network traffic in polling mode even when the CPU is maxed out, for example). There was also some discussion about the ground-up support for flash memory. Flash storage ranks between DRAM and disk in both speed and cost and represents a good compromise for certain functions (caching of certain types of data). ZFS can integrate DRAM, flash storage and disk.
My question remains the same as after Sun Developer Day in Sydney - why can't they port these great features to Linux and dump Solaris? We need to move ahead with a single great OS, and Linux is it. Petty sibling rivalry doesn't help.
I then attended two very similar sessions one after the other, that dealt with Metro-based Web Services. The first was by Jonathan Scudder of Identitas, and dealt with securing Web Services using Metro and OpenSSO. The second talk was by Harold Carr of Sun that covered a few other topics such as connecting to Amazon's web services. My takeaway from Scudder's talk was that there are still a number of non-intuitive steps that need to be followed to make Web Services work using Metro and OpenSSO. There were some cool aspects to NetBeans, though. If the developer drags a Web Service operation into the code of a service consumer, it actually expands into a try-catch block with the actual call inside. OpenSSO is configured as an STS (Secure Token Service). I wonder if CAS can be similarly configured. I think I remember hearing that CAS 4 has a lot of such goodies. Also from Scudder's demo, I realise that WireShark is a neat tool to analyse network traffic. Harold Carr's talk convinced me that the time is not yet ripe to try and integrate Amazon's Web Services into one's application. It appears that Amazon does not follow the WS-* standards with respect to specifying WS-Security. There's no use of WS-SecurityPolicy in Amazon's WSDL, and that sucks in my opinion. I'll wait for Amazon to fall in line with industry best practice before I go anywhere near their services.
I then attended a talk on "Developing RESTful Web Services with JAX-RS and Jersey" by Marc Hadley and Paul Sandoz of Sun. I had attended a similar talk before, so there wasn't much that was new. I was just struck by how glacial the pace of development has been. I have been following JSR 311 for the past two years and I'm disappointed that we aren't much further ahead.
A few things Hadley and Sandoz said did strike me as significant, though.
One is that the venerable "web.xml" file will be obsoleted in the Servlet 3.0 spec.
Another is that content negotiation, which is a big part of REST, is coded for very simply with @Produces and @Consumes annotations on methods. Jersey (i.e., the JAX-RS implementation) takes care of the gory details.
There's a difference between "JAX-RS aware" and "non JAX-RS aware" containers. With the latter, the URI must point to a servlet, and an init parameter must point to an Application class. In the former, the URI can directly point to an Application class.
No new technology is complete without its share of horror, and with JAX-RS, the horror seems to be Web Beans (JSR 299). This is of course the hideous combination of JSF and EJB (two monstrosities that have no right to exist independently, and certainly no right to exist as a combination). I'm not quite sure where exactly in JAX-RS these Web Beans are going to raise their ugly heads, but I'm already shuddering.
There are apparently many implementations of JAX-RS in the works, and they are Jersey, RESTlets, JBoss RESTEasy, Apache CXF, Triaxrs and Apache Wink.
In JAX-RS 2.0, which is currently underway, the roadmap includes a client API, "quality of source" (some content formats such as XML are superior to others and should be used if the client is indifferent between them), form data and MIME multipart, declarative hyperlinking and representation templating.
The final session I attended on the first day was a hands-on workshop that dealt with the use of an Eclipse toolset for Glassfish. This was a fairly good session with well thought-out materials (a DVD with all required software and examples, and a printout of the assignments) and helpful instructors. It was a "Bring Your Own Laptop" workshop, and fortunately the lab had power outlets and Ethernet cables for all. I had whinged about the lack of Eclipse tools for Glassfish on some earlier occasion, and my prayers were evidently heard. I didn't find the Eclipse toolkit for Glassfish the most intuitive possible, but it's perhaps a function of learning. I shouldn't criticise it before I learn to use it well.
I look forward to tomorrow, when JavaOne proper begins.
The conference is at the Moscone Center in SanFrancisco.
June 1 saw the CommunityOne prelude to the actual JavaOne conference that would follow from the 2nd to the 4th.
The General Session opened with Dave Douglas (Senior VP, Cloud Computing and Chief Sustainability Officer at Sun) anchoring the event and introducing other speakers. The major focus of the morning's General Session was Cloud Computing, with a secondary emphasis on OpenSolaris.
Lew Tucker, Sun's Cloud Computing CTO (yes Virginia, there is such a title), came up on stage with Dave and the two had a conversation in which they described the "Sun Cloud" (a meteorological contradiction in terms, but never mind).
I was glad to see that they actually called out an important point that usually tends to be glossed over at events like this - Open Source is not enough, it's open APIs and interoperability that are really important. Hear, hear! Obviously, we're a way away from having interoperable clouds, because most first movers seem to want to lock in users even as they tout the Open Source underpinnings of their solutions.
Lew Tucker demonstrated what I thought was a very cool tool - the Sun Cloud Compute Service, or at least the GUI tool that's used to configure it. Using a drag-and-drop interface, it's possible to set up a complete network, with firewalls, switches and all manner of servers, then have that configuration created in the cloud.
The virtual servers can even have the MAC addresses of their VNICs set during this configuration.
I was glad to see that besides OpenSolaris, some of the other server platforms available were Fedora, Ubuntu and CentOS. I've observed that the Linux support subscriptions from Red Hat and Novell/Suse are generally priced in such a way as to make mainframes look cheap. Since I don't believe that mainframes can be cheap, I'm happy about the CentOS, Fedora and Ubuntu server options. Depending upon the Sun Cloud pricing, we may actually see lower costs associated with cloud computing. [But with Oracle's acquisition of Sun, I'm not holding my breath.]
The Sun Cloud Compute Service doesn't seem to be in General Availability mode yet. Perhaps it's just released to a few partners right now. Some of those partners came up on stage to briefly discuss their wares. These were companies like Moonwalk, Vertica and WebAppVM. I didn't have time to digest what these people were doing with the Sun Cloud, but they did seem to derive some benefit from smooth virtualisation.
Someone mentioned an emerging standard for specifying virtual configuration topologies called OVF or some such. I'll need to keep an eye out for it.
Sun is also reportedly working with the Center for Internet Security to develop standards for securing virtual machines. The servers that Sun Cloud will provide on its drag-and drop palette will all be hardened by default.
Some of the tools being offered for cloud computing are Netbeans (for development), Hudson (for continuous integration) and Kenai (for repositories).
There was a panel hosted by Jon Fowler that delved into what's new and cool in OpenSolaris. There does seem to be a fair bit there. Sun Open Storage is based on ZFS. DTrace is another component that's built into the OS core, so everything that runs on OpenSolaris can be dynamically instrumented with very low performance impact. Project Crossbow is another initiative that deals with network virtualisation. Compared to Linux, OpenSolaris appears to have a few advantages, such as networking efficiency (OpenSolaris can continue to process network traffic in polling mode even when the CPU is maxed out, for example). There was also some discussion about the ground-up support for flash memory. Flash storage ranks between DRAM and disk in both speed and cost and represents a good compromise for certain functions (caching of certain types of data). ZFS can integrate DRAM, flash storage and disk.
My question remains the same as after Sun Developer Day in Sydney - why can't they port these great features to Linux and dump Solaris? We need to move ahead with a single great OS, and Linux is it. Petty sibling rivalry doesn't help.
I then attended two very similar sessions one after the other, that dealt with Metro-based Web Services. The first was by Jonathan Scudder of Identitas, and dealt with securing Web Services using Metro and OpenSSO. The second talk was by Harold Carr of Sun that covered a few other topics such as connecting to Amazon's web services. My takeaway from Scudder's talk was that there are still a number of non-intuitive steps that need to be followed to make Web Services work using Metro and OpenSSO. There were some cool aspects to NetBeans, though. If the developer drags a Web Service operation into the code of a service consumer, it actually expands into a try-catch block with the actual call inside. OpenSSO is configured as an STS (Secure Token Service). I wonder if CAS can be similarly configured. I think I remember hearing that CAS 4 has a lot of such goodies. Also from Scudder's demo, I realise that WireShark is a neat tool to analyse network traffic. Harold Carr's talk convinced me that the time is not yet ripe to try and integrate Amazon's Web Services into one's application. It appears that Amazon does not follow the WS-* standards with respect to specifying WS-Security. There's no use of WS-SecurityPolicy in Amazon's WSDL, and that sucks in my opinion. I'll wait for Amazon to fall in line with industry best practice before I go anywhere near their services.
I then attended a talk on "Developing RESTful Web Services with JAX-RS and Jersey" by Marc Hadley and Paul Sandoz of Sun. I had attended a similar talk before, so there wasn't much that was new. I was just struck by how glacial the pace of development has been. I have been following JSR 311 for the past two years and I'm disappointed that we aren't much further ahead.
A few things Hadley and Sandoz said did strike me as significant, though.
One is that the venerable "web.xml" file will be obsoleted in the Servlet 3.0 spec.
Another is that content negotiation, which is a big part of REST, is coded for very simply with @Produces and @Consumes annotations on methods. Jersey (i.e., the JAX-RS implementation) takes care of the gory details.
There's a difference between "JAX-RS aware" and "non JAX-RS aware" containers. With the latter, the URI must point to a servlet, and an init parameter must point to an Application class. In the former, the URI can directly point to an Application class.
No new technology is complete without its share of horror, and with JAX-RS, the horror seems to be Web Beans (JSR 299). This is of course the hideous combination of JSF and EJB (two monstrosities that have no right to exist independently, and certainly no right to exist as a combination). I'm not quite sure where exactly in JAX-RS these Web Beans are going to raise their ugly heads, but I'm already shuddering.
There are apparently many implementations of JAX-RS in the works, and they are Jersey, RESTlets, JBoss RESTEasy, Apache CXF, Triaxrs and Apache Wink.
In JAX-RS 2.0, which is currently underway, the roadmap includes a client API, "quality of source" (some content formats such as XML are superior to others and should be used if the client is indifferent between them), form data and MIME multipart, declarative hyperlinking and representation templating.
The final session I attended on the first day was a hands-on workshop that dealt with the use of an Eclipse toolset for Glassfish. This was a fairly good session with well thought-out materials (a DVD with all required software and examples, and a printout of the assignments) and helpful instructors. It was a "Bring Your Own Laptop" workshop, and fortunately the lab had power outlets and Ethernet cables for all. I had whinged about the lack of Eclipse tools for Glassfish on some earlier occasion, and my prayers were evidently heard. I didn't find the Eclipse toolkit for Glassfish the most intuitive possible, but it's perhaps a function of learning. I shouldn't criticise it before I learn to use it well.
I look forward to tomorrow, when JavaOne proper begins.
No comments:
Post a Comment