Google Cloud Vs Amazon Cloud - An architectural perspective - Part 2

Cross Post:
Google Cloud Vs Amazon Cloud - An architectural perspective - Part 2

Google Cloud Vs Amazon Cloud - An architectural perspective - Part 1

Cross Post:
Google Cloud Vs Amazon Cloud - An architectural perspective - Part 1

Building Java Apps on the Google App Engine

Cross Post:
Building Java Apps on the Google App Engine

Portlets are dead. Long live Enterprise OpenSocial !

Early last year, I blogged about why I thought JSR 286 was irrelevant. I also speculated that what makes sense was an enterprise version of OpenSocial, which I called OpenEnterprise.

Today, I am pretty surprised to see that OpenSocial is indeed moving in that direction. Opensocial.org has published a whitepaper titled "Enterprise OpenSocial". I am yet to read the whitepaper, but this seems to be very similar to what I had in mind when I wrote my previous post.

Does this means that we'll finally get to see a decent component platform for enterprise portals ? Of course, OpenSocial is far from being perfect. They still have a lot of technical as well as non-technical issues to fix (I'll take that up in a future blog post). But it's probably better then JSRs that take years to materialize. What I find most interesting is that this spec will extend way beyond the Java world, much like what the Facebook and OpenSocial platforms are today.

Have you read the whitepaper ? What's your take on Enterprise OpenSocial ? What next - Enterprise Facebook :-) ?

Happy 2010

I am back to blogging after a huge break ! Will try to do more justice to this blog this year :-) That said my 2009 predictions have turned out to be fairly accurate, I guess.


Wish you a Happy 2010 !

Portal Zone will now focus on social app development

Portal Zone was launched in 2006 when I was a part of the Sun's Web Portal team (this was the initial blog: The Old Portal Zone). The intent was to share what I learnt as a part of my day job (Portlets, WSRP, Ajax and such) and also, to be honest, provide a little bit for marketing for Sun's Portal product.

In 2007, I moved to another group in Sun and later quit Sun. However, I still continued blogging on the subject (albeit sparingly) on this blog. This was primarily driven by two factors - My interest in the subject + the large readership the blog had attained.

Of late, not only has my interest in this subject been waning, I am no longer actively involved in portlet development. However, there are other related areas that have piqued my interest.

Hence, I have decided to shift the focus of this blog. Portal Zone will no longer be actively covering the Java Portlets/WSRP space. Instead this blog will be focus on the subject of social web app development - viz OpenSocial , Facebook Platform and related topics.

If you have subscribed to this blog and are not interested in social app development, do unsubscribe.

Why JSR-286 is irrelevant and how to fix it

Today I came across an interesting article on java.net :JSR-286: The Edge of Irrelevance. It also seems to have sparked some discussions in the community: In response to JSR-286: The Edge of Irrelevance.

In the java.net article, the author talks about how the Portlet spec is losing it's edge and makes his point by listing the number of organizations supporting the spec (for Portlet 1.0 it was 24 and for Portlet 2.0, it is just 6). He also goes about explaining the "higher than normal learning curve" for portlets and the "monolithic architecture" that portlets dictate. The community discussions around this article also seems to focus on the same lines : bad design, too much of constraints etc.

However, in my opinion, the reason why portlets are getting irrelevant is something different.

Portlets focus on solving one part of the problem, the integration of UI (it doesn't solve this very well either) between the portal and the portlets. However, it has no notion of standardizing on the data it operates on. For example, there is no reliable way for portlet to get the email id of a user who has logged in into the portal and viewing the portlet.

What sort of real-world, portable, business applications would you expect developers to build with such restrictions ? The most important aspect of a Portal is not only it's aggregation abilities but also the data that lies underneath. Yet, the portlet spec does not have any notion of portal data.

Therefore the only portable portlets that you can realistically build is a stock ticker or a weather portlet. Any portlet that is built to actually use data from the portal becomes proprietary.

The "fix" is to come up with a standard that can actually helps portlets (or "applicationlets" as I would like to call it ) to be able to query the portal for it's data. This is not something new. This is how third party developers build applications on Facebook and Myspace (on the enterprise front the Zoho Marketplace is a great example). These applicationlets are provided with an API that can query Facebook/Myspace about the details of the user who is viewing it, get the users friends, message them etc. That is all that is needed for developers to come up with interesting social apps.

So, let us assume that the portal vendors define a standard to akin to OpenSocial. Let's call it OpenEnterprise. All OpenEnterprise applicationlets must have the ability to query the details of an employee who is using the portal (email id, employee number, etc), query the employee's boss, query the employees subordinates if any, message any employee in the organization (via IM, email) and perhaps post documents, spreadsheets etc on behalf of the employee.

This would be enough to provide a platform to build a rich set of portable enterprise applications: Time sheets, Reporting tools, HR tools , you name it. It will also encourage developers to build apps that can integrate deeply with the portal and not just superficially. Portal vendors will start supporting the spec because of the rich set of applications that can be made available to the users. Third party vendors are bound to pop-up, building specialized business applications that can actually be plugged in to your portal and developers will learn the spec even if the programming model is not perfect !

In short, this is actually a business problem, not a technology problem.

Portlet 2.0 on JBoss

Packt Publishing recently published "JBoss Portal Server Development". The books covers Portlet 2.0 on JBoss. Grab the free sample chapter here : "Portals and Ajax" and let me know if you find it useful.

Portal Technology Predictions for 2009

1. Portlets will lose ground. Opensocial gadgets / widgets will catch up.
I blogged about this sometime back. With announcements like Sun's SocialSite and eXo Social, this seems to be already happening.

2. WSRP will die.
WSRP is a web services standard which allows a web portal to aggregate content from externally hosted applications into it's own. To me this is the Facebook platform gone wrong. It will die.

3. Goodbye Sun, IBM - Welcome Google, Yahoo
We will witness the shift of power from large IT vendors like Sun and IBM to large consumer facing Internet companies like Google, Yahoo and Facebook, with respect to defining Web technology.

4. Federated Identity via Google Friend Connect and Facebook Connect
Expect these technologies to take off, in a big way.

Happy New Year !

My Javaworld Article - Portlet 2.0 Quickstart Guide

I just published a new article in Javaworld titled: A quickstart guide to Portlet 2.0. It talks about how get up and running your first portlet on the JBoss Portlet Container.

Makes a good addition to the Portlet 2.0 (JSR 286) Tutorial series.

Make any website a social network ...

... is the theme of the day. Be it Google Friend Connect, Facebook Connect or Myspace Data Availability- everyone wants you to use *their* social data.

What does it mean for developers ? Not sure. None of these platforms are public yet. And it will be interesting to see how open they will be.

OpenSocial & Facebook Developer Meet in Bangalore

We are conducting an OpenSocial/Facebook developer meet in Bangalore. If you are interested in learning more about any of these technologies, please feel free to participate.

The details are available here:
http://upcoming.yahoo.com/event/807031

Don't forget to confirm your participation beforehand.

JSR 286 - Too little , too late

Just noticed that the JSR 286 spec has been finally posted : JSR-286 Now Posted. As you can see, the Expert Group for this spec was formed in Dec 2005. And it has taken 2.5 years for the EG to iterate to the next version. Portlet 1.0 was released in 2003, 5 years back.

My personal opinion is that this technology has been delayed to almost a point of irrelevance. And it would be interesting to see if Portlet 2.0 will succeed to make an impact.

Will OpenSocial replace existing portal standards ?

Going by the current trend it seems that OpenSocial might replace current server side portal standards like Portlets and WSRP for good. OpenSocial gadgets can be considered the Web 2.0 equivalent of portlets

While portlets are server-side components that depend on aggregation at the server, OpenSocial gadgets are lightweight, javascript/DHTML/Ajax components that aggregate on the client (i.e the web browser). Portlets are expected to be deployed and maintained by administrators whereas OpenSocial gadgets can be pulled, on the fly, from just about any given source. And there is nothing much that you can do with portlets that cannot be done with a OpenSocial gadget and a servlet backend.

Time to say goodbye to all Portal Servers out there ?

OpenSoShell - OpenSocial developer tool

OpenSoShell is a tiny open social gadget that can help developers run OpenSocial
Javascript API snippets directly within an opensocial container like Orkut or Hi5.
It is not meant to be a full fledged IDE or development environment. But it can help complement existing gadget development tools like Firebug.

I have released it with an Apache license. Feel free to give it a shot.

http://portalzone.googlecode.com/svn/trunk/opensocial/opensoshell/opensoshell.xml

Update:
Here is how you can get started. Signup for an orkut account and request for sandbox access.Install the gadget by pointing to the URL from the the "My Applications" page.
You can find detailed instructions here: Orkut Developer Guide

You can also check out the video tutorial series.

Portlet Tutorial - Deploying your first portlet to OpenPortal Portlet Container 2.0

This post is a part of the Portlet 2.0 (JSR 286) Tutorial series


At the time of this writing, only Sun seems to have a functional JSR 286 portlet container. Apache Pluto 2.0 is work in progress and I have been unsuccessful in running the Exo Portlet Container.


The OpenPortal portlet container is Sun Microsystem's implementation of the JSR 286 spec. Here is how you would deploy the Hello World portlet to this container.

Step 1 :

Get JDK 5 or greater: http://java.sun.com/javase/downloads/index.jsp

Step 2 :

Get the Glassfish Application Server or Tomcat
If you downloaded Glassfish, set it up first.

Step 3 :

Download the latest stable release of the portlet container.

Step 4 :

Follow the install instructions: Installing the Portlet Container

Step 5:

Start your server and access the portlet container at http://localhost:8080/portletdriver

Step 6:

Once you have the portlet container running, you will notice two tabs. A Portlets tab and an Admin tab.The Portlets tab helps view all the portlets currently deployed. The Admin tab is used to to deploy/undeploy portlets. You are most likely to see a blank page. This is because no portlets are deployed by default.

Click on the Admin tab and proceed to deploy the portlet.


















Once you click on deploy, the portlet is automatically deployed and configured. Click on the Portlets tab to now view the portlet.












You have successfully run your first portlet !

Good Javascript resources

If you are planning to learn javascript or in the process of doing so, here are some pointers.

The best way to start is to watch a series of videos presentations from YUI Theater. These videos are brilliant with absolutely high quality content.

You can watch the videos in this order:

1. The Javascript Programming Language




• Part I


• Part II


• Part III


• Part IV




2. Advanced Javascript




• Part I


• Part II


• Part III




3. The Theory of DOM




• Part I


• Part II


• Part III




4. Javascript: The Goood Stuff


5. High Performance Javascript


6. The State of Ajax


7. High Performance Ajax

The YUI Theater also offers all the content downloadable in an ipod compatible format.

Other good online resources include The w3schools Ajax Tutorial and Sun's Java Ajax Blueprints.

If you are planning to buy a book then you can consider JavaScript: The Definitive Guide or the new book in the Head First series: Head First JavaScript (Head First) .

If you would like to keep updated with the latest in the javascript/ajax world, I would recommend Ajaxian.

Portlet Tutorial - Anatomy of a portlet

This post is a part of the Portlet 2.0 (JSR 286) Tutorial series

Now that we have written and successfully deployed our Hello World portlet, let's understand it's various components.Here is how our portlet would look when deployed in a container.


Notice how the portal has created a distinct boundary or window for our portlet. This is called a Portlet Window. Each portlet is visually contained in a portlet window. In addition to the portlet content (i.e the "Hello Portlet 2.0 World" message that we printed in the render method), the portlet window also contains the portlet title (we mentioned this in the portlet.xml) and some click-able controls called decorations. These decorations help control two different aspects of a portlet - modes and window states.

Portlet Modes and Portlet Window States

At any given point in time, all portlets can defined by in terms of two unique characteristics - what the portlet is currently doing and how much space the portlet is taking up on the page. The Portlet Mode defines what the portlet is currently doing. The Portlet Window State defines how much space a portlet takes up in a particular page.

For example, we could have written a help message for the Hello World Portlet and displayed it when a user clicks on the Help button (the decoration with a "?" symbol). In this case the portlet would be in the "Help" mode. Similarly we could have written different "Hello World" messages based on how much space the portlet occupies on the page. This is possible because in each case, the portlet would be associated with different window states.

Portlet Tutorial - Hello Portlet 2.0 World

This post is a part of the Portlet 2.0 (JSR 286) Tutorial series

As explained in the previous post, a portlet is a pluggable component that can be run inside any compliant portal server. Here is an example of a portlet running inside a portal.


Note how the portlet occupies only a part of the portal page. This is the primary difference between a portlet and a servlet. A portlet is meant to occupy only a part of the web page. And a portal web page consists of multiple, different portlets.

Now, let's learn to write a simple Hello World Portlet. The Portlet API defines an interface called javax.portlet.Portlet. Any portlet you write must implement this interface. One easy way to do so is to extend the javax.portlet.GenericPortlet class. The GenericPortlet already implements the Portlet interface and it is strongly recommended that you always inherit GenericPortlet while writing your own portlets.

Here is our code.

public class HelloWorldPortlet extends GenericPortlet{

  public void render(RenderRequest request, RenderResponse response)
                                 throws PortletException, IOException{

    response.setContentType("text/html");
    response.getWriter().write("Hello Portlet 2.0 World");
 }
}

We have overridden only one method of the GenericPortlet interface called render.We will look into the render method in detail in a subsequent blog post. For the time being you can assume that whenever your portlet is "shown" on the portal page, the render method is called.

Since portlets are extended components of a regular web application, they can also be packaged along with your servlets and JSPs in a war file. However you will need a separate descriptor along your regular web.xml to describe portlets. This descriptor is called the portlet descriptor and the file is called portlet.xml.

Here is the portlet.xml for our Hello World Portlet.

<portlet-app xmlns=\"http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd\"
 xsi=\"http://www.w3.org/2001/XMLSchema-instance\" 
 schemalocation=\"http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
 http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd\">
   <portlet>
       <portlet-name>HelloWorldPortlet</portlet-name>
           <portlet-class>com.portalzone.example1.HelloWorldPortlet</portlet-class>
           <supports>
           <mime-type>text/html</mime-type>
           <portlet-mode>view</portlet-mode>
           <portlet-mode>edit</portlet-mode>
           <portlet-mode>help</portlet-mode>
           </supports>
           <portlet-info>
               <title>Hello World Portlet</title>               
           </portlet-info>
       </portlet>
</portlet-app>

That’s it ! You have written your first portlet application. You can grab the ready to deploy war file from here: example1.war and deploy the application to your container of choice. If you are interested in the source, here it is : example1-src.zip.

Interesting 2008 predictions

Here are some of the interesting 2008 predictions I have come across

• 
  2008 Web Predictions
  


• 
  What wont happen in 2008
  


• 
  Mashable 2008 predictions
  


• 
  PC World Tech Predictions for 2008
  


• 
  Economist's Technology in 2008
  


• 
  Valleywag's 25 predictions
  


• 
  Information Week's predictions
  

Happy 2008 !