Developing "in the cloud"

To continue from the last two posts and driven by curiosity, I decided to see if a DropBoxed GlassFish application server (along with its built in JavaDB database) will be able to complement the dropboxed NetBeans IDE I already use on three Linux systems.

As a little detour I must state that these Linux systems are such that I have complete access over them. If I had to work in a more mixed environment (e.g. in Windows or in any system without administrative privileges), I would still use OS independent packages, but I would use a USB flash drive as a carrier. It doesn't seem appropriate for one to utilize the service on a machine that is publicly shared. It comes to my mind that going hardcore, could make you try to install a DropBox on the system in question (whether I doubt it is possible without administrative privileges) and as synchronized folder to use one on a flash drive. But I have the impression that, at least currently, the DropBox service is not intended for such loose usage.

So! GlassFish. OS independent ZIP archive. Extracting it somewhere under the DropBox root folder completes its installation. It takes some minutes (or maybe hour, or two) to propagate, but as usual, this has never been a concern.

Now - configuring and running seem to be more interesting. Adding the server in NetBeans under the "Servers" node is nothing special. You just point to the installation directory, where the ZIP was extracted. If you need to, specify a custom domain different from the default domain1 and that's it. NetBeans knows all the rest. If you start it from its node with the context menu, in a few seconds, you'll be able to access it in a browser. Of course it still needs certain configurations, so that not everybody has access to the administration console on port 4848, etc.

One good way to test the installation is to test it against the Quick Start Guide. If we say that the installation directory for the server is marked GF, the guide in question is the file:

GF/glassfish/docs/quickstart.html

It opens in a browser and explains with examples, what commands can be issued in the command line in order to make the administration tool do the right job for you. The tool is called asadmin and it starts the desired domain (or simply the default) and the database. In Linux the absolute and the relative paths should work the same way.

Another good testing method is to run through some tutorial, and what would be better than this one.

While taking it, it is interesting to observe what's going on in your DropBox. May be the most beautiful part is that the both entities - the syncing service and the development stack - just work. The development stack behaves like it exists in a usual file system, like it actually is. The service rapidly synchronizes the bunch of small files that are created and/or modified during the development process - changing configuration files, writing to log files, deploying the different types of Java archives to the domain sub-folders of the server, etc.

Opening your "Events" page on the DropBox web site you'll see something like this:

This of course is not the full list, but as you can see the more details are easily accessible by clicking the appropriate link:

I read some time ago a question on StackOverflow that someone had trouble running the JavaDB database after installing the GalssFish server in his DropBox folder. All I can say is that it worked in my set of environments from the command line. But just because NetBeans is good enough to manage a development environment on its own, I use it for the same purpose. Registering the application server with the IDE is the only required step - as a consequence it manages the built-in database pretty well. And after running the examples from the FirstCup tutorial on one of my machines, I could very easily review exactly the same data on every other machine registered with the syncing service:

I heard some categorizations that DropBox is a "cloud service". I don't know if this is a fair comparison, because cloud computing although becoming better and better defined every day, still has some vague boundaries. Despite that the feeling when working with my mirrored and aptly synchronized small-project-sized-single-user-development-environment is like I have one computer everywhere I go. I guess at least this is what the Coluds are trying to achieve. So if we're already there, there's nothing left but to wait and see what will be the next challenge.

Another way to be portable - part II

So, NetBeans stack (with servers) portable through DropBox - sounds quite possible. After all PortableApps can be used this way. But what's to consider first? Here's the list (it's not long at all):

• Will the free account's box size suffice? Yes, it will, even for a full install (with the two app servers). And I guess there'll be a little bit more space for some small projects, etc.
• What if utilize multiple platforms (Windows at work, Linux at home, and Mac on the move)? Well fortunately the IDE still has the "OS independent Zip" on the download page, but as you can see there, this option comes without the servers. The servers are completely different story, for another post.
• And should I put the JDK also in the DropBox? If so, should it also be platform independent? Hm, friend, this is Java you know! And I think, we've already been through this :)

Maybe these are all of the preliminary considerations, so I dive in ....

Downloaded the OS independent ZIP for the latest (currently 7.0.1) version (242 MB archived, and around 470 MB extracted to a DropBox sub-folder). With my connection, it uploaded to the central server for around half an hour.

For further examinations lets name the path to the DropBox folder as DB. So if the IDE is extracted to DB/netbeans, the adventure starts from the DB/netbeans/bin folder (I believe you can easily figure out the corresponding Windows paths). In this folder there are only two files - the executables for the two major platforms. Since the IDE is configured by default to search for the java installation existing on the system, if such exists, the IDE will run. If only JRE is installed, it might run, but it surely won't compile your projects and it will complain about it. Of course, the access to a java installation can be configured, but I don't think there is a point in repeating myself. Everything said in that post still applies.

I would only add that if you use a portable JDK, you might tweak it, to make it slimmer. This means that bin, jre and lib folders will suffice. Another detail is that you might have to gather the executable files from different platforms in their corresponding sub-folders in order to be fully portable. Actually it is all a matter of taste and context. All environments that I have DropBox on are Linux, so I don't need portable JDK. In that case I only have to take care that on every environment I use compatible JDKs. For example if on Env1 I have installed JDK 1.7, the Env2 which has by default (from repositories) JDK 1.6 the projects might become in conflicted state. This might not happen for different updates of the same version of the JDK, but for a different versions of used application servers the conflict is certain. So the journey continues.

I don't know how close, but this installment looks to me similar to an IDE on the cloud. I accept every suggestion that might reduce the distance between the reality and the idea.

Another way to be portable

Few months ago I found DropBox. I almost immediately started using it as holder of some sample NetBeans projects. Its seamless integration with the host OS and immediate synchronising of the project files amazed me. These guys have done a wonderful job. I know they are being criticised about security and privacy matters, but if you get to become paranoid about your sensitive data why use Internet at all?

At first I didn't think of it as a variant of portability - actually portable are only your projects, and not the IDE. This in fact is more similar to a very simplified one-user-version-control. And for small projects I guess I would be happy with it. I would call it cloud portability, but it still would be about the projects.

And there's the idea - what if I installed the IDE in my DropBox folder? There are few drawbacks that come into my mind:

• It would take up most of my original 2 GB quota. This is not the greatest concern - I could invite some friends or at some point I even can go for a paid account.
• Performance. May be this is the biggest (as usual) concern. But since the IDE is copied on every HDD I installed DropBox on, it will be ran form a hard drive and not from a flash drive. This leads me to the next concern.
• Synchronised environments. In order for the IDE to work at all I'll have to use the same classpaths for the JVM and the libraries. And may be at some point even for any servers. I know your next question - why not install everything in the DropBox folder? It seems tempting. Something bothers me here. I'm not very sure what exactly it is, but I'll figure it soon. May be the best way to find out is to just do the thing and watch it how it moves.

One thing is certain - installing the IDE will be as slow as your bandwidth. I mean, not installing it on the local hard drive, but sending it to your other PCs. Well this is not a real worry - DropBox does the transfer, not you. And if your remote PC is online, once you get there you'll might already have the IDE on it.

I'm kind of tempted to do it, but may be after some more considerations.

Significant events

I am an occasional blogger. So here is the occasion. A big one. Actually there are three interconnected events:

1. Oracle finally released the latest (7th) version of the standard edition variant of the prominent Java programming language's SDK. The tech related part of the web is all boiling with the fuss. Use it! Don't use it! There are severe bugs in the JVM. There's nothing scary about the bugs - they'll be fixed before the JVM is adopted in production. The new syntax enhancements are great. There's not enough new features to the language. Etc., etc., etc. It's always been and will always be a work in progress - there'll always be hideous bugs lurking in the code invisible, until the rarest never-met-before conditions bring them to the light. It's OK. Bugs, features, fallacies - its' all part of producing software. Any kind of software. Even great meta-software like Java. Since the engine is here, where's the new chassis so we can utilize it for a nice smooth software development drive? Here it comes.
2. Oracle released the 7th version of the NetBeans IDE some time before the official release of the Java SE 7 SDK, so after the first event on the list, they had to release the NetBeans 7.0.1 with the required official support. Game on! The IDE is ready for download you very well know where from. I wish it was available in the Ubuntu repositories also, but I don't think this will be an option soon.
3. A book. You didn't expect this, right? In fact it is a very nice book about how the IDE eases the development of Java 6 Enterprise applications. I won't tell more about it right now, because I'm in process of going through it, in order to make a full review. So, with no more distractions, I'm diving back to Mr. Heffelfinger's thoughtfully organized and narrated set of screen-shots. Here's the cover to just whet your appetite:

All the three events are pretty significant for the NetBeans users. The tool of the trade was upgraded and on the other hand there is a concise source of some background information for the developers.

A review to come. See ya ;)

Enterprise Java 6 with NetBeans 7 narrated

I already published two almost identical reviews at Developer Zone and Amazon. I feel it is clear what are the purpose and the structure of Java EE 6 Development with NetBeans 7. The reasons for why I like it are not just that I needed such reference for a long time and it finally showed up. I liked it because it is straight to the point. Promptly teaches you what you need to do, with further details where possible and reveals the technology gradually and remarkably fully for the given small amount of pages.

So in the sake of diversity, completeness and to give the book the coverage it deserves, I'll pay a bit more attention to its contents.

The introductory chapters

The first three chapters might be considered as legacy. I mean, they are there in favor of the complete beginners. On the other hand most of the functions represented here can be found in the same or similar form through the previous versions of the IDE. Those are the features that define the NetBeans way - the keys for simplicity, speed and robustness during your development process.

First we're introduced with the IDE. From installing it to adding and managing application and database servers - it is all a fundamental knowledge. Even if you only create desktop applications the chances are rather small, that you'll never have to work with database. This knowledge is just a must precondition.

After that a similar thing is done for Java EE and how it is backed by the IDE. If the reader is not a bit more familiar with Servlets, JSPs, configuring the security, etc. this introduction can't be enough. Here you'll see presented the ready templates and configuration-tweaking editors that require such basic knowledge.

Finally we're given the tag palettes. They are organised around the forms in the applications' pages. NetBeans gives us automation for the HTML tags that require most effort when written by hand, and for some of the JSTL tags.

The nicest example I found here is a small tutorial on how to create custom JSP tags - sometimes the wide JSTL extension over HTML still might not be enough functional or flexible.

The basics of the Enterprise Java

In the following two chapters we meet the newer wave in the Java EE history - the Java Sever Faces (JSF) framework over the core Servelt and JSP APIs and a complementary component library - PrimeFaces.

Since every chapter in the book can be taken as a separate tutorial for creating a certain technology-centered throw-away application, these two chapters are visually oriented. In terms of the MVC design pattern here we're shown how to create the View. The JSF API is backed up by lots of wizards - managed beans, facelets, components, etc. Do you think this is enough? Well, NetBeans don't. They provide the PrimeFaces components integration, so with the help of fast code-completion very decently looking pages can be built that could have tabbed layout, or to behave like wizards. Of course I wish there was at least a plugin that could bring the tags in their own palette, but I guess this integration is in an early stage.

The core innovations to Java EE 6

In the previous version of the SDK, the Enterprise Java Beans (EJB) API consisted of three types of Enterprise Beans - entity beans, session beans and message-driven beans. With the API's evolution, the first ones were extracted to their own specification comprising the Java Persistence API (JPA). Another new feature covered is the Contexts and Dependency Injection (CDI) - long awaited, after all it is one of the things that made the Spring framework so famous.

To the Enterprise Beans and CDI's integration are dedicated the next four chapters of the book. The one for JPA is my favorite tutorial, because it shows not only the power of the IDE to automate the creation of data components. It gives a whole MVC application - JSF application extracted from the paired database. The rest of these chapters concentrate on the business tire in an enterprise application. We see how easily can be created modules and clients, message resources, qualifiers and stereotypes. Everything is there after a few clicks in the file wizard, smartly coded templates ready for customization.

Java EE 6 and the Open Web

The web services are left for the last two chapters. The classic SOAP services, using heavy XML for data transfer versus the modern RESTful services that utilize the lighter JSON data format. Both are equally and very well covered. To the point that NetBeans has a nice graphical editor for configuring the parameters of a service.

As examples we can see a SOAP web service created from existing EJB module and from ready WSDL file, and RESTful web service created from existing database. The last one also has a client created for it.

The Appendixes

I cannot imagine developing some application without debugging some of its trickier methods at a point. Doing it for an enterprise application is generally a bit more difficult, regarding the external execution environment - the server. NetBeans proves such difficulty does not exist.

I must admit that the Profiler is the NetBeans's prominent performance tool that I never had a chance to use in working conditions. Yet having it in the IDE for such a long time (if memory doesn't fool me, after version 5.5 it became integrated, instead of being a separate plugin) is a persuasive argument towards its quality.

Like I said in the external reviews, code templates customization and the possibility for adding custom palettes, deserved at least another appendix, but after all this is a Java-EE-6-centric book, and NetBeans is just the tool. Anyway, I personally like very much the way this book gives credit to the IDE, to its grade of integration with the SDK. The plethora of examples might comprise only to throw-away applications, but they are so technology-aware that throwing-away option easily might be transformed to merging-and-extending option. Have fun!