I shall enlist my ideas based on our team's experience in picking up Sling, simultaneously starting to work with it in a Live-Project. This might not be a generic view but would certainly be indicative for a J2EE person planning to learn Sling.
1)A J2EE person primarily feels comfortable in learning/ working in any Web Based Design Framework. Sling being a Web Framework, the initial comfort level for a J2EE person to start off with Sling should be quite good.
2)The next thought that comes into the mind of a J2EE person is where my application will run in the new Framework i.e the container or Server to be used. Sling can be built as a self runnable application inside default jetty server or can be deployed as a war file inside Tomcat servlet container. These properties make it similar to our well known J2EE model.
3)The first point where Sling differs from a normal J2EE Based Framework like Struts is the Request Processing Mechanism it follows. It is here that a J2EE person feels a little uncomfortable or rather difference from what he has learnt so far. Sling is a ‘Content Driven Framework’ unlike a ‘J2EE MVC Framework’ and follows a ‘REST’ based content look-up strategy. This means that, when web-request is made from the Browser to a Sling Framework, Sling first resolves the request to find a resource, and based on that resource it then executes the script/servlet associated with the resource to handle the request.
The initial steep learning curve for a J2EE person becomes gentle to some extent at this stage, however with concepts of request processing already prevailing in him; he gains momentum once the difference becomes clear.
4)The next difference that a J2EE person needs to compromise with is that in Sling content is being stored in nodes inside File-system following a JCR Repository-Node structure within Jackrabbit Content Repository. This is different from a J2EE Web-Application which stores data inside Database. He needs to understand concept of nodes, types of nodes and JCR API to certain extent for starting development in Sling. Here the learning curve is again comparatively gentle.
5)An entirely new Design Pattern or Framework that he comes across while learning Sling is OSGI - ‘Open Service Gateway Initiative’. It is a framework which allows developer to follow Module based development approach with each Core Business Functionality implemented as Service inside these Modules, and packaging them as Bundles. Immediately he tries to co-relate with other Module and Service Oriented Design Approaches in J2EE like EJB, Web-Services or Java-RMI and feels comfortable and enthusiastic in learning this new Framework.
6)In a pure J2EE Design one needs to write JSPs, Front-Controllers, Servlets, various middle-tier Helper classes like Delegates, Service Components, Utils along with Database Access Components. With Sling such J2EE Design efforts have been completely eliminated with SlingPostServlet taking the entire responsibility of modifying the content inside a JCR Repository underlying Sling. The only effort remains is reading content from Repository. This task is simplified and accelerated if we follow an approach of writing reusable Util methods using Java Reflection API (A very strong Java API for modifying application behavior on runtime, a relatively advanced Java feature).
7)A pretty good approach that J2EE developers follow for Server Side validations, or fetching data dynamically from the Data-Store is by using Asynchronous Javascripts (AJAX) with JSON formatted String. This used in combination with simple Form POST action inside JSP to be handled by SlingPostServlet, can be very effective and efficient way of handing Request-Response in Sling.
Really a nice blog and experiences shared by Bhaskar and all of the cases I am agreed with him. A new guy in the Sling development having a J2EE background can get a great help and guideline from this post before migrating from J2EE to Sling.