By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
If you've heard bad things about JSR 168, you'll be relieved to know that the new version of the API is much friendlier to the developer.
Jason Tee, enterprise software architect
Developing collaborative and social components
The topic on everyone's minds right now is definitely portal development. Recent improvement in the functionality of portal technology has opened up fresh opportunities for Java developers to learn new skills and enhance old ones. Enterprises are finding that portals make sense for securely managing a portfolio of applications while presenting customized content to internal and external users. As a result, software engineers are being asked create apps that are based on portlets rather than servlets for this space. If you aren't familiar with the JSR 286 API, now is the time to learn.
If you've heard bad things about JSR 168, you'll be relieved to know that the new version of the API is much more developer-friendly. You even have a wide array of tooling options and technologies that support design and development on the server side or the client side, wherever you feel your greatest coding and scripting talents lie. It's probably a good idea to be involved in the portal development discussion starting at the architecture stage. That way, you can advocate for solutions that use more of the skills you already have...
Modernized UI development for mobile and web
A lot of what you know about JSP and servlets will carry over to portlet development, so you aren't starting from scratch. For example, standard Java APIs like JDBC, JMS and JNDI are still used to access resources and generate dynamic content for the user, just as in the servlet sphere. You'll also have to apply the best practices from servlet development to the portlet. No thread spawning indoors, please!
Revisiting the value of EJBs
Like a southern preacher making it easy for you to remember the points of a sermon, EJB has three alliterative types of bean (stateful, stateless and singleton). Naturally, we've got a whole tutorial on the topic. Here are the quick tips for when to grind each bean into your distributed architecture:
Stateful: Best for stand-alone applications with no internal state-management facilities or mobile devices with very limited client-side memory.
Stateless: Best for delegating work to other components in the backend such as JPA entities, persistent components, file system writers and message queues.
Singleton: Best for creating a singular instance of a given class, such as for utility classes or components that provide access to external resources that can't handle lots of connections.
Databases, big data and data persistence
In a faceoff between Hibernate and the JPA EntityManager, enterprise-class organizations are finding that there's no one solution that reigns supreme. Sticking strictly with the more Java compliant EM might seem like the logical choice. But Hibernate brings some powerful tools to the table – especially in the era when businesses are storing petabytes of data. First, JPA 2.1 isn't all that and a bag of chips when it comes to supporting multi-tenancy. Even in the private cloud-centric arena of big business, that might be a deal breaker if it complicates or restricts adding hybrid or public capabilities later.
The Hibernate Session delivers more flexibility and options for working with multi-tenant architecture. It also blows away the competition when it comes to making data searchable. You just don't get features like full text search when you're using EM alone. There's also something to be said for having a sense of history. Hibernate envers provides versioning functionality that stores information about all changes to your data. It's like having a Wayback Machine for your Big Data.
Do you use these hot tools and technologies as a developer or designer? If not, what do you use instead? Let us know.