(I've already blogged about the first and second days.) There were 5 tracks on this (third) day, called "Community Day": GlassFish, NetBeans, Mobility, Solaris and Sun University. I attended 3 sessions each from the GlassFish and Mobility tracks.
Alexis Moussine-Pouchkine provided an introduction to the GlassFish project. GlassFish is almost exactly the same product as the Sun Java Application Server. The latter has a couple of extra proprietary bits added, and also provides more frequent updates.
A few tidbits that I noted:
The admin console looks pretty professional, unlike Tomcat's minimal one, and unlike the ugly raw JMX that I've seen in the past with JBoss (I haven't used JBoss in a while, thanks to Spring and Tomcat). GlassFish's admin console is even better than Geronimo's, which I thought was pretty good at the time. It's task-oriented, so users will find it easier to find what they need.
GlassFish logs to a bundled JavaDB database (Cloudscape/Derby).
Apparently, GlassFish has a third container apart from the web and EJB containers. It's called the ACC (Application Client Container). Developers can build a Swing client and bundle it with the ear file. Java Web Start is used to deliver it. Dependency Injection can be used even with the client.
In cluster mode, GlassFish keeps Applications, Configurations and Resources consistent across the cluster. GlassFish uses a dynamic clustering feature called Shoal that is built on top of JXTA.
There's a project called SailFin which is meant to bridge HTTP and SIP. This is useful not only for the telecom industry but also generally, to provide rich media capabilities to enterprise apps.
I haven't explored Sun's Portal offering before (OpenPortal). That's another thing on my growing to-do list.
GlassFish has a number of components:
The GlassFish App Server itself
OpenPortal (portal server)
OpenESB (Enterprise Service Bus, of which more later)
OpenSSO (single sign-on solution)
OpenDS (directory server)
Jersey (for RESTful services)
Hudson (continuous build)
jMaki (aggregates Ajax widgets and provides a common API wrapper)
jRubyOnRails
OpenMQ (message queue)
WoodStock (JavaServer Faces components)
JavaDB (Apache Derby pure Java database)
Apache Roller (blog software, one of the "Enterprise 2.0" offerings)
Slynkr (social tagging software, another of the "Enterprise 2.0" offerings)
SailFin (SIP-HTTP bridging software)
Here's the GlassFish project wiki that provides ongoing detail about the project.
David Pulkrabek from Sun's labs in Prague spoke about the future of JavaME development tools, and his demos were very impressive.
He showed a demo of how to record and replay a set of actions, that could be used in automated testing. Then he showed a demo of how a Sun SPOT device could be used to capture sensory inputs like orientation and 3-dimensional acceleration to control a game on a mobile device. Could this power the next Wii?
Next he showed how real devices and emulators are treated the same by toolkits. A mobile phone plugged into the laptop with a USB cable is detected by the tools, and the debugger can execute applications on the mobile phone, with breakpoints and variable editing, just as in a local emulator. The output of the mobile phone can be redirected back into the toolkit's console.
Very impressive. I think JavaME developers have a pretty good set of tools at their disposal, thanks to the work done at Sun's Prague labs.
But even JavaME pales into insignificance when compared to JavaFX Mobile. This session was from Noel Poore. JavaFX Mobile is a rather unfortunately named piece of technology, and will continue to cause Sun grief because of the needless confusion with JavaFX Script. Let me clarify. JavaFX Mobile is the name of a mobile device platform that Sun acquired when it took over SavaJe in May 2007. JavaFX Script is a new (as yet unreleased) scripting language for the UI, which essentially reduces Swing programming to a declarative style. Yes, JavaFX Mobile supports JavaFX Script, but that's the only (tenuous) connection. Sun should stop these silly and confusing names (The Java Desktop System was another one. That was just a Linux (or Solaris) desktop that could run Java).
JavaFX Mobile is based on the Linux kernel and Java SE. Note that it's Java Standard Edition, not JavaME, the Mobile Edition that the previous session dealt with. This has two major implications. One is that the full range of Java features is now available to mobile devices, not just the subset that JavaME used to provide. Second, from a market viewpoint, it removes the fragmentation that the various JavaME implementations necessarily suffered on account of their having to be tailored to devices. JavaFX Mobile is now a full-fledged platform that can take on the iPhone or Google's Android. It can still run MIDP Midlets, but Sun would encourage developers to build full-featured JavaFX Script-based UIs and applets rather than the comparatively anaemic Midlets, now that the full capabilities of a JavaSE platform are available.
The platform has three components: Core, Frameworks and User Experience (Applications).
Core: Kernel abstraction, Linux kernel 2.6, Core graphics, Core networking, Media engine, Device drivers, Filesystems and a C library (not glibc)
Frameworks: Content management, Java, Web content, Provisioning, Graphics, Connectivity, Multimedia, Networking, Messaging, Telephony
User Experience (Applications): Calendar, Browser, Phone, Camera, App Selector, Personal Utilities, Media Player, Content Viewer, System Utilities, Contacts, Messaging Apps, Home Screen, Themes and third party apps
Messaging includes IM and Presence (OMA IMPS and Jabber).
Jim Weaver (who has written many books on Java, including J2EE 1.4 and JEE 5) spoke next about JavaFX Script and showed a few demos. I'll just sum up my impressions on JavaFX Script.
First, JavaFX Script is to Swing as Groovy is to Java. It's a lightweight scripting approach to building GUIs, and it uses a declarative style.
Second, although JavaFX script is far less verbose than the equivalent Swing code, it still unfortunately looks like the dog's breakfast (compared to Flex, for example). I think it will only become popular when a graphical editor is layered on top of it.
I always like systems that are based on textual files that can be edited by hand if required, compared to systems that store data in binary format. But that doesn't mean I want to use the text editing approach exclusively. "Build graphically and tweak textually" is my motto for GUI development.
Michael Czapski from Sun's Sydney office spoke about JBI (Java Business Integration) and OpenESB.
Historically, approaches to integration have ranged from file transfer through shared databases and EAI to messaging. Messaging is the model currently in vogue. Models have progressed from point-to-point, through hub-and-spokes (brokered) to the "bus", which is a distributed, logically decoupled, anywhere-to-anywhere model.
ESB's facilitate a messaging-based bus model of integration.
JSR 208 deals with Java Business Integration, another unfortunately-named standard that doesn't immediately explain what it does.
This is a standard that governs how ESB components plug into the bus, allowing integrators to mix and match components from different sources to build up a "bus". I think it's more relevant to those who write components like adapters, BPEL engines, XSL transformation engines and the like rather than end-user organisations (like mine) that want to use a bus to integrate their applications. The latter don't care how the "bus" was put together, whether it is a monolithic piece of technology or a pluggable architecture that has components from different sources. [Well, we should care from a vendor lock-in perspective, but functionally, it makes no difference to us.]
JBI standardises component interfaces, component lifecycle (start, stop, deploy, undeploy, etc.), deployment model, monitoring and management, among other things.
It fosters loose coupling through WSDL interfaces, and implements WSDL 2.0 MEPs (Message Exchange Patterns).
The components that plug into a bus are either Service Engines or Binding Components. Examples of Service Engines are Aspect engines, BPEL engines, mashup processors, encoding, ETL, scripting, XSL transformation engines, etc. Examples of Binding Components are BCs for SAP, Siebel, CICS, CORBA, FTP, HTTP, Queues, etc.
OpenESB is Sun's JBI implementation. It uses NetBeans 6 for development and deploys naturally to GlassFish.
Michael demonstated a BPEL process that used two Binding Components (an input queue and an output file), with a Service Engine written on the spot using an EJB with Web Service annotations. The process read in a string from a queue (which was manually input), called the web service to turn it to uppercase, then wrote it into the file. Sure enough, when the file was opened, the string was there, in uppercase. Though it was a simple enough demo, it was fairly impressive.
NetBeans 6.0 is shaping up to be a good development platform for SOA. It has editors for BPEL and XSLT, among other things.
The last session I attended was by Alexis Moussine-Pouchkine again. This was on "Practical GlassFish". He talked about how GlassFish is built, the release cycles, etc.
There's reportedly a graphical installer from a third party (Izpack) for those who don't want to wrestle with the command line.
Alexis also demonstrated the Update Center, which works like Eclipse's.
He showed us some of the asadmin commands for command-line administration. These can obviously be used in scripts as well, which administrators would like.
From a competitive perspective, Sun has a migration tool that helps users automatically (to a large extent) migrate their current deployments on Tomcat, JBoss, WebLogic, WebSphere and older versions of Sun App Server onto GlassFish/Sun App Server. It's reportedly not foolproof, but it could help.
Documentation can be obtained by typing 'asadmin --help' on the command line or online.
That was the end of the three-day Sun Tech Days event. Very useful and informative.
My main takeaway, ironically, was nothing from Sun. It was Grails. I've started doing the InfoQ tutorial, and I'm mightily impressed. I'll blog more about Grails as I learn more.
Alexis Moussine-Pouchkine provided an introduction to the GlassFish project. GlassFish is almost exactly the same product as the Sun Java Application Server. The latter has a couple of extra proprietary bits added, and also provides more frequent updates.
A few tidbits that I noted:
The admin console looks pretty professional, unlike Tomcat's minimal one, and unlike the ugly raw JMX that I've seen in the past with JBoss (I haven't used JBoss in a while, thanks to Spring and Tomcat). GlassFish's admin console is even better than Geronimo's, which I thought was pretty good at the time. It's task-oriented, so users will find it easier to find what they need.
GlassFish logs to a bundled JavaDB database (Cloudscape/Derby).
Apparently, GlassFish has a third container apart from the web and EJB containers. It's called the ACC (Application Client Container). Developers can build a Swing client and bundle it with the ear file. Java Web Start is used to deliver it. Dependency Injection can be used even with the client.
In cluster mode, GlassFish keeps Applications, Configurations and Resources consistent across the cluster. GlassFish uses a dynamic clustering feature called Shoal that is built on top of JXTA.
There's a project called SailFin which is meant to bridge HTTP and SIP. This is useful not only for the telecom industry but also generally, to provide rich media capabilities to enterprise apps.
I haven't explored Sun's Portal offering before (OpenPortal). That's another thing on my growing to-do list.
GlassFish has a number of components:
The GlassFish App Server itself
OpenPortal (portal server)
OpenESB (Enterprise Service Bus, of which more later)
OpenSSO (single sign-on solution)
OpenDS (directory server)
Jersey (for RESTful services)
Hudson (continuous build)
jMaki (aggregates Ajax widgets and provides a common API wrapper)
jRubyOnRails
OpenMQ (message queue)
WoodStock (JavaServer Faces components)
JavaDB (Apache Derby pure Java database)
Apache Roller (blog software, one of the "Enterprise 2.0" offerings)
Slynkr (social tagging software, another of the "Enterprise 2.0" offerings)
SailFin (SIP-HTTP bridging software)
Here's the GlassFish project wiki that provides ongoing detail about the project.
David Pulkrabek from Sun's labs in Prague spoke about the future of JavaME development tools, and his demos were very impressive.
He showed a demo of how to record and replay a set of actions, that could be used in automated testing. Then he showed a demo of how a Sun SPOT device could be used to capture sensory inputs like orientation and 3-dimensional acceleration to control a game on a mobile device. Could this power the next Wii?
Next he showed how real devices and emulators are treated the same by toolkits. A mobile phone plugged into the laptop with a USB cable is detected by the tools, and the debugger can execute applications on the mobile phone, with breakpoints and variable editing, just as in a local emulator. The output of the mobile phone can be redirected back into the toolkit's console.
Very impressive. I think JavaME developers have a pretty good set of tools at their disposal, thanks to the work done at Sun's Prague labs.
But even JavaME pales into insignificance when compared to JavaFX Mobile. This session was from Noel Poore. JavaFX Mobile is a rather unfortunately named piece of technology, and will continue to cause Sun grief because of the needless confusion with JavaFX Script. Let me clarify. JavaFX Mobile is the name of a mobile device platform that Sun acquired when it took over SavaJe in May 2007. JavaFX Script is a new (as yet unreleased) scripting language for the UI, which essentially reduces Swing programming to a declarative style. Yes, JavaFX Mobile supports JavaFX Script, but that's the only (tenuous) connection. Sun should stop these silly and confusing names (The Java Desktop System was another one. That was just a Linux (or Solaris) desktop that could run Java).
JavaFX Mobile is based on the Linux kernel and Java SE. Note that it's Java Standard Edition, not JavaME, the Mobile Edition that the previous session dealt with. This has two major implications. One is that the full range of Java features is now available to mobile devices, not just the subset that JavaME used to provide. Second, from a market viewpoint, it removes the fragmentation that the various JavaME implementations necessarily suffered on account of their having to be tailored to devices. JavaFX Mobile is now a full-fledged platform that can take on the iPhone or Google's Android. It can still run MIDP Midlets, but Sun would encourage developers to build full-featured JavaFX Script-based UIs and applets rather than the comparatively anaemic Midlets, now that the full capabilities of a JavaSE platform are available.
The platform has three components: Core, Frameworks and User Experience (Applications).
Core: Kernel abstraction, Linux kernel 2.6, Core graphics, Core networking, Media engine, Device drivers, Filesystems and a C library (not glibc)
Frameworks: Content management, Java, Web content, Provisioning, Graphics, Connectivity, Multimedia, Networking, Messaging, Telephony
User Experience (Applications): Calendar, Browser, Phone, Camera, App Selector, Personal Utilities, Media Player, Content Viewer, System Utilities, Contacts, Messaging Apps, Home Screen, Themes and third party apps
Messaging includes IM and Presence (OMA IMPS and Jabber).
Jim Weaver (who has written many books on Java, including J2EE 1.4 and JEE 5) spoke next about JavaFX Script and showed a few demos. I'll just sum up my impressions on JavaFX Script.
First, JavaFX Script is to Swing as Groovy is to Java. It's a lightweight scripting approach to building GUIs, and it uses a declarative style.
Second, although JavaFX script is far less verbose than the equivalent Swing code, it still unfortunately looks like the dog's breakfast (compared to Flex, for example). I think it will only become popular when a graphical editor is layered on top of it.
I always like systems that are based on textual files that can be edited by hand if required, compared to systems that store data in binary format. But that doesn't mean I want to use the text editing approach exclusively. "Build graphically and tweak textually" is my motto for GUI development.
Michael Czapski from Sun's Sydney office spoke about JBI (Java Business Integration) and OpenESB.
Historically, approaches to integration have ranged from file transfer through shared databases and EAI to messaging. Messaging is the model currently in vogue. Models have progressed from point-to-point, through hub-and-spokes (brokered) to the "bus", which is a distributed, logically decoupled, anywhere-to-anywhere model.
ESB's facilitate a messaging-based bus model of integration.
JSR 208 deals with Java Business Integration, another unfortunately-named standard that doesn't immediately explain what it does.
This is a standard that governs how ESB components plug into the bus, allowing integrators to mix and match components from different sources to build up a "bus". I think it's more relevant to those who write components like adapters, BPEL engines, XSL transformation engines and the like rather than end-user organisations (like mine) that want to use a bus to integrate their applications. The latter don't care how the "bus" was put together, whether it is a monolithic piece of technology or a pluggable architecture that has components from different sources. [Well, we should care from a vendor lock-in perspective, but functionally, it makes no difference to us.]
JBI standardises component interfaces, component lifecycle (start, stop, deploy, undeploy, etc.), deployment model, monitoring and management, among other things.
It fosters loose coupling through WSDL interfaces, and implements WSDL 2.0 MEPs (Message Exchange Patterns).
The components that plug into a bus are either Service Engines or Binding Components. Examples of Service Engines are Aspect engines, BPEL engines, mashup processors, encoding, ETL, scripting, XSL transformation engines, etc. Examples of Binding Components are BCs for SAP, Siebel, CICS, CORBA, FTP, HTTP, Queues, etc.
OpenESB is Sun's JBI implementation. It uses NetBeans 6 for development and deploys naturally to GlassFish.
Michael demonstated a BPEL process that used two Binding Components (an input queue and an output file), with a Service Engine written on the spot using an EJB with Web Service annotations. The process read in a string from a queue (which was manually input), called the web service to turn it to uppercase, then wrote it into the file. Sure enough, when the file was opened, the string was there, in uppercase. Though it was a simple enough demo, it was fairly impressive.
NetBeans 6.0 is shaping up to be a good development platform for SOA. It has editors for BPEL and XSLT, among other things.
The last session I attended was by Alexis Moussine-Pouchkine again. This was on "Practical GlassFish". He talked about how GlassFish is built, the release cycles, etc.
There's reportedly a graphical installer from a third party (Izpack) for those who don't want to wrestle with the command line.
Alexis also demonstrated the Update Center, which works like Eclipse's.
He showed us some of the asadmin commands for command-line administration. These can obviously be used in scripts as well, which administrators would like.
From a competitive perspective, Sun has a migration tool that helps users automatically (to a large extent) migrate their current deployments on Tomcat, JBoss, WebLogic, WebSphere and older versions of Sun App Server onto GlassFish/Sun App Server. It's reportedly not foolproof, but it could help.
Documentation can be obtained by typing 'asadmin --help' on the command line or online.
That was the end of the three-day Sun Tech Days event. Very useful and informative.
My main takeaway, ironically, was nothing from Sun. It was Grails. I've started doing the InfoQ tutorial, and I'm mightily impressed. I'll blog more about Grails as I learn more.
2 comments:
That's an interesting opinion and I think it would be very useful for the techies and business professionals on SiliconIndia.Maybe you can upload an article on the site and post a link to your blog so that they can easily find you. Thanks
Jennifer,
Thanks for your suggestion. I've registered on SiliconIndia but couldn't find a way to upload an article even after searching for a long time. Can you help please?
Regards,
Ganesh
Post a Comment