Altabel Group's Blog

Archive for the ‘Java’ Category

Today comparing software on a market is a difficult task. Each product comes from a market / technology niche with great specific features developed by passionate people and open source lovers. There is no doubt the most appropriate CMS will depend on what one is trying to use it for, but let us try to have sort of a general comparison and see what definitely should be on our Java CMS shortlist.

There are so many Open Source Java CMS but let me focus on some of them which are considered quite popular now and they are Hippo, Magnolia and Jahia.

Hippo

Hippo contains an optimal combination of enterprise architecture capabilities, fast development possibilities and values of open integration. It enables you to gain the power to be open for integration with any technology that you require to manage, optimize and create high-impact customer experiences.

This CMS is really about managing content for multi-channel publication: web, mobile, social, print, etc. Separation of content from presentation is the cornerstone of the product.

Speaking of analytics systems like Webtrends, Omniture and Google Analytics Hippo CMS makes it possible for you easily embed tracking codes into content to feed analytics systems. You can also observe your content effectiveness, as Hippo exposes data collected by analytics systems in the CMS.

In terms of ecommerce, Hippo has been integrated with many custom eCommerce solutions. Take ATG, Konakart, Magento and IBM WebSphere Commerce as example. Due to the open interfaces of all Hippo components, it works whatever eCommerce system you chose.

Hippo format neutral way of managing content makes it a great source for publishing into portals. So, if your extranet or intranet runs in a portal environment, then it is not necessary to rebuild it with Hippo if you want to increase it with centrally managed content. Hippo plays nicely with all major portals and has been integrated with portals like Liferay, JBoss, SAP and Websphere Portal.

Hippo Pros:
• flexible content structure & faceted navigation
• integration with some external applications
• portal alike functionalities/ integrations
• a lot of sub-sites with sharing content capabilities

Magnolia

Magnolia powers the websites of government as well as leading Fortune 500 enterprises in more than 100 countries on all continents of the world. It is a leading CMS favored for its ease of use and license. The page editing interface enables authors to lay out content exactly as it would appear to the Web site visitor.

Magnolia is similar to Hippo in lots of ways, except that it’s very much focused on managing smaller, “single” websites. Magnolia CMS is not a framework to build web applications, however can be used to manage data. You can for instance manage products and use them as content for web pages.

Authors no longer need to switch between different navigation mechanisms to make a small change, but they can instantly edit any page in their browser.

Magnolia’s inline-editing feature ensures that editors see content paragraphs in their right context at all times, reducing the switching between working modes.

Magnolia has been designed for heavy-load enterprise websites, having a low memory footprint, a smart cache, built-in clustering capabilities, a distributed deployment architecture that decouples authoring from publishing and the possibility to build load-balanced public servers to provide more throughput and availability.

Magnolia Pros:
• good for smaller sites (content related); although, Magnolia can be used on quite big sites as well
• need in page editing/inline editing (this is possible within Hippo CMS but Magnolia is bit easier to setup)
• you only have page(content) based site/navigation. Hippo solution is much more flexible in this regard.

Jahia

Jahia delivers web content integration software by combining enterprise web content management with document and portal management features. Jahia is content centric depending on the type of project you envision, this is a major difference. The granularity of Jahia’s content model offers a deeper control on each content item. This provides greater benefit when it comes to repurposing, reusing content or controlling precisely how your content should behave (roles, workflow, layout, display options, etc.). Of course, these advantages need to be balanced with the specific objectives or your project. For a basic website scenario, this granularity is perhaps not necessary and Magnolia may be an easier choice. For intranet or portal scenarios, complex websites or content based applications, the Jahia model and its widely recognized flexibility may be more appropriate.

Jahia works great with structured content. For instance, Jahia offers options beyond the unique paragraph concept – more suited to create unstructured objects that must be displayed in a page, it offers a variety of additional objects with multiple properties you can manipulate, sort, validate, repurpose, etc. You can obviously decide to only use a simple, unstructured approach in Jahia but the ability to really declare, control and manipulate a wide range of additional object types is very powerful in more complex scenarios. Also important is that all Jahia editing UIs are auto-generated based on simple content definitions: not having to create your own input masks is a huge time saver and cuts development time.

Jahia embeds several frameworks that are very important if you plan to manipulate your content through API and code, and if you want your Jahia instance to interact with other apps / systems, some of the most important ones are) Jboss Drools, Apache Camel, jBPM.

Caching mechanisms in Jahia is based on long experience fine tuning performance for large and high traffic websites: there is a sophisticated and efficient caching solution that deals with both automatic invalidation and expiration. This allows avoiding dependencies and flushing management problems, which is key to complex, large and/or interactive sites scenarios.

Jahia Pros:
• deep control on each content item due to granularity of Jahia’s content model
• good for working with structured content
• good for large and high traffic websites

The CMSs under review have their differences but also have something in common. It might be interesting to note that all three products actually use the same storage technology: Apache Jackrabbit, which is the reference implementation of the Java Content Repository API. This ensures some guarantee as to the possibility to migrate in/out the content relatively easily.

You are welcome to make Java CMS shortlist of your choice longer with other products as well as to share your comments and comparative analysis details on the given ones. It would be really great to learn more on this subject as well as get to know your experience.

Thank you!

Aliona Kavalevich

Aliona Kavalevich
Aliona.Kavalevich@altabel.com
Skype ID: aliona_kavalevich
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Some people will argue that it’s not worthy comparing Tomcat and JBoss, because one of them is a superset of the other. In fact JBoss is bundled with a forked version of Tomcat. So JBoss is Tomcat plus:

* JMS messaging provider
* Web Services engine (JAX-WS and/or JAX-RS)
* Management capabilities like JMX and a scripted administration interface
* A powerful data grid solution (Infinispan)
* Advanced security, e.g. out-of-the-box integration with 3rd party directories
* A dynamic and powerful clustering engine
* Transaction management service

Still many decision makers have to choose between these two, so lets’ take a deeper look at them.

The JBoss AS is an application server based on Java. It is an open source server and is usable in any operating system supported by Java.

Apache Tomcat, or its more widely known name Tomcat, is a servlet container (meaning it is a Java class that operates under the strictures of the Java Servlet API – a protocol by which a Java class responds to an http request). This is an open source server, providing a ‘pure Java’ HTTP web server environment in which code written in Java is capable of running.

Tomcat is only a servlet engine and JBoss offers many more functionalities out of the box. Still JBoss is no longer a heavyweight monolithic container, but a modular application server featuring true classloading isolation, modules loaded on demand, domain management and exceptionally lightweight container. It has a pluggable architecture and if required, you can unplug features from JBoss to make it essentially a Tomcat servlet container.

At the same time the plus going in favour of Tomcat is that it is fairly lightweight, and it means less memory requirement and a faster response. At the same time if you need certain JEE features beyond the Servlet API, you can easily enhance Tomcat. For example, if you need JPA features you can include Hibernate or OpenEJB and JPA works nearly out of the box.

Tomcat is hassle free and might be the right choice when you are not using much of Java features. It is a very good fit if it comes to web centric, user facing applications.

In case backend integration comes into play, a JEE application server should be considered. Last but not least, migrating a WAR developed for Tomcat to JBoss should be a 1 day exercise.

Some people still argue that instead of using application servers, one can still deliver a full stack application using Tomcat + Spring adding the right frameworks and writing the Spring integration layer with these frameworks. That’s for sure true. Still the logical question is what price you will have to pay for that. The JBoss project can be focused around average – to junior developers. Mastering the same complex stack of technologies with Tomcat and Spring requires skilled and well paid developers.

To make it short, Tomcat is merely an HTTP server and Java servlet container. JBoss is a full-blown JEE application servers, including an EJB container and all the other features of that stack. On the other hand, Tomcat has a lighter memory footprint (~60-70 MB), while JBoss weigh in at hundreds of megs. Tomcat is very popular for simple web applications, or applications using frameworks such as Spring that do not require a full JEE server. Administration of a Tomcat server is arguably easier, as there are fewer moving parts.
However, for applications that do require a full JEE stack (or at least more pieces that could easily be bolted-on to Tomcat) JBoss is one of the most popular open source offerings. JBoss has a larger and deeper user community, and a more mature codebase.

So, we should not really care anymore about which is better, but focus on the application requirements. However, you can still use the best of these two worlds in your enterprise applications.

It would be great if your could share your opinions on this topic :) Thanks in advance for your comments!

Aliona Kavalevich

Aliona Kavalevich
Aliona.Kavalevich@altabel.com
Skype ID: aliona_kavalevich
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Scala is a statically typed and multi-paradigm programming language that runs on Java virtual machine and provides Java like syntax with a few improvements.

Being a multi-paradigm programming language, Scala allows for mixing multiple programming styles such as object oriented, imperative and functional programming. Whether it’s good or not, it is not a question that could be answered with a yes or no. Supporters would say that programmers can choose from a variety of styles and stick to the best depending on their needs. The others would argue that putting together some features found in many other programming languages can’t work well, mostly by increasing complexity and making a programming language obscure.

Scala code compiles to a byte code and runs on Java virtual machine, thus it is compatible with other Java applications. If most of your code and libraries are from Java world, this can be nothing but a good thing. At the same time some additional complexity in Scala is dictated by assuring compatibility with Java.

For some developers the Scala code is obscure, for others could be a nice and neat form of solving some specific problems.

One more positive aspect of Scala is its conciseness. We all know how Java verbose is and how many boiler code developers write everyday including constructors, getters, variable initialisation (type and generics), semicolons and many others.

Now let’s see some other aspects of working with Scala:

Performance
At first sight the performance in Scala is very good, comparable to Java. Scala code compiles to the same byte code as Java does and runs on the same Java virtual machine. Still how fast Scala code is may vary from case to case and usually it’s up to the way how the code is written. The awareness of how to write a high performance Scala code is especially important for Java developers who are not very experienced in both Scala and functional programming.

Tools
There are not too many development tools created specifically to serve Scala, but fortunately, thanks to compatibility with Java it doesn’t look so bad. One family of tools hardly usable in Scala are those, which do some sort of code analysis, for instance code coverage and static code analysis. Static code analysis tools are even less usable.

Language extensions
The two worth to mention native Scala extensions are Lift web framework and Akka actors platform.
The majority of libraries and frameworks from a Java world, should be possible to use quite smoothly, which among other things, is thanks to implicit conversions in Scala.

Interoperability
Interoperability between Scala and other programming languages, including Java/C/C++, is very good, mostly because of running on Java virtual machine. What Java may talk to, Scala can do as well. Taking into account support for implicit conversions described above, I would state that Scala is one of the leaders of interoperability among all programming languages.

Testing
Developers are provided with all they need to test Scala applications efficiently. To follow a Test Driven Development methodology, they can use popular in Java world Junit tool. If someone is more keen on Behaviour Driven Development then ScalaTest is a way to go.

Monitoring and maintenance
One of the main monitoring tools to analyze production Scala applications is JMX (Java Management Extensions). This tool does its job well when we want to analyse some predefined statistics, but sometimes we need to investigate some aspects of a production application while it’s running and JMX can’t provide all required data. To deal with such scenarios, Java provides Java Virtual Machine Tool Interface (JVM TI) that allows for inspecting running Java applications but it can be used for Scala too.

Support
Scala community, including forum, mailing list and blogs, is not the biggest in the world, but it’s very energetic. Most people who are part of a Scala community are very passionate developers, which are always happy to help others to solve their problems. Books are also great: Programming in Scala book by Marting Oderski, Lex Spoon and Bill Venners.

Scala skills
No one will argue that it is far behind other programming languages such as Java or C/C++. Still while looking for Scala developers we could search for Java developers with Scala interests as well. The learning curve is not massive as Scala follows Java syntax. In such case, at least on experienced Scala developer would help the team adopting new programming language.

Have you moved from Java to Scala? How do you find this language?

Thanks for sharing your opinion!

Aliona Kavalevich

Aliona Kavalevich
Aliona.Kavalevich@altabel.com
Skype ID: aliona_kavalevich
Business Development Manager (LI page)
Altabel Group – Professional Software Development

JavaScript has been popular with the developers for a number of years and has been more discussed than jQuery. However it seems to me that we should also pay attention to jQuery as, I bet, we could find a number of interesting facts about it.

Let`s start from the brief history of the two.

Initially JavaScript was called LiveScript and was invented by Netscape. In 1996 Netscape decided to change its name to raise the popularity of the language by combining it with Java. At that moment Java was used to prepare individual plug-ins. Despite the fact that JavaScript developers have tried to recreate the same syntax and functionality, as in Java, between the two languages, there are many differences. The most important difference is that the Javascript – client is an interpreted scripting language. It runs in the browser without first compilation, which is a mandatory action for programs written in Java…but it is another story.

So JavaScript is a scripting language that is mainly used for website development and client side validation.

The most common use of JavaScript is to write functions that are included in the HTML to interact with HTML elements. For example:
- Sending HTML page data to server using AJAX;
- Animating HTML element;
- Validating the HTML form;
- Storing user information that may help for Web Analytic, Ad tracking etc.

As for jQuery, when it came out in January 2006, from first sight, it looked like a cute hack and in general jQuery was seen as a passing fad. Because the chaining stuff looked like a bit gimmick and the library didn’t look like it would cover all of the bases. Still over the past months we could see that the first impression was wrong, because jQuery encapsulates an extraordinary range of common functionality, and provides a clever plugin API for any functionality not included by default. And the most important thing is that the using of the library obeys best practices and plays well with other JavaScript code.

Mostly jQuery focuses on designers and inexperienced developers, still it could be of interest to experienced programmers as well. Here I will try to enumerate the reasons why:

1) Element’s selecting. Every jQuery operation starts from selecting one or more nodes from the DOM. jQuery’s selection syntax is an interesting hybrid of CSS 1, 2, bits of CSS 3, some XPath and a few custom extensions as well.

2) Namespace. The main point in creating a good JavaScript-code for further using is carefully managed namespace. There is a single global namespace in JavaScript and many programmers clog it without any needs. More sensible developers minimize their intervention to the space using different methods. jQuery introduces the only object in the global namespace: function or object jQuery. Everything else is either direct property jQuery or a method of the object returned by a call to jQuery.

3) The $ function. You could say it is not true that that jQuery introduces only one object in the global namespace as there is also a $: the $ symbol is also set up as a shortcut for jQuery. This makes enough gently: if you want to back your former function $ (for example, if you have a piece of code based on Prototype), you can call jQuery.noConflict (), to return to his old the $. At the beginning you could considere the widespread using $ in jQuery is no more than a clever trick. But for some reason thinking of it in terms of the jQuery symbol makes everything seem a lot more sensible

4) Chaining. jQuery development team often boast about supporting this library call chains, reaching statements like «jQuery created in order to change your style of programming in JavaScript». Frankly speaking, this technique is a big turn-off than the road to the future but you can make good use of jQuery while avoiding lengthy chains of methods entirely. Briefly speaking, the chain can be used for some interesting tricks. In addition to using a set of DOM-samples you can use jQuery-end () method to move the object on the stack and exit the current context. It’s a bit hard to explain, but when you use a method that changes the current (object) context (for example, children () or filter ()), you can use the end () later to return to the previous sample.

5) Manipulating with DOM. jQuery offers a few smart ways of making large scale manipulations to the DOM. The first is quite surprising: the jQuery function can take a snippet of HTML which it will turn in to a DOM element.

6) The returned beast. Object, which is returned by the selectors jQuery, could be quite interesting. It represents a set of DOM-elements and behaves a bit like an array—it has a length property, items can be accessed by index and (most importantly) Firebug treats it as an array when displaying it in the interactive console. This is a clever illusion; the collection is actually a jQuery object, incorporating a large number of methods which can be used to query, modify and extend the collection of selected elements.

There are three principle categories of jQuery methods: those that manipulate all of the matched elements, those that return a value from the first matched object, and those that modify the selection itself. If you have Firebug you can try these out interactively: use this Insert jQuery bookmarklet first to load the jQuery library in to any page, then paste the code examples in to the Firebug console. I would like to note a convenient symmetry of these methods: they are used for display attributes (taking 2 arguments passed to or from a number of properties of the object), and to read the values of these attributes (if only one argument). This symmetry is used throughout jQuery, which greatly facilitates the storage API.

7) Unostentatious programming. The best web applications are those that can still function in disconnected scenarios, and the best method to achieve this is using JavaScript, when the events are assigned to elements only after all the HTML-page are loaded by the user. In jQuery there is excellent support for this approach. First, the paradigm of the selectors to select a node is fundamental for jQuery, and for the non-intrusive programming in general. Second, jQuery provides solutions for window.onload problems

8) jQuery and Ajax. jQuery has the best API for working with Ajax. The most simple form of an Ajax call looks like jQuery(‘div#intro’).load(‘/some/fragment.html’). This performs a GET request against /some/fragment.html and populates div#intro with the returned HTML fragment. It’s a neat shortcut, but what if you want to do something more advanced like display an Ajax loading indicator? jQuery exposes custom events (ajaxStart, ajaxComplete, ajaxError and more) for you to hook in this kind of code.

9) Extensions. Considering the whole set of features as standard, it is worth noting that uzhaty jQuery version is only 20 KB, and even less if you use archive (. Gz). Additional functionality that extends beyond this delivery can be arranged with the help of extensions that can (and do) to add new methods to an existing jQuery. If you want, you can do something like this: jQuery (‘p’). bounceAroundTheScreenAndTurnGreen(); The extension mechanism in jQuery provides documented methods for adding them to the system. Simplicity and ease of use have attracted a large community of authors such extensions, the extensions directory has more than a hundred examples. Another nice feature is the ability to add your own selectors as well as their own methods. MoreSelectors expansion adds methods like div: color (red), which, for example, selects all div with red text.

10) Several words about leaky abstractions. When studying jQuery with more respect, you could struggle with one philosophical blocker. In certain cases, jQuery uses a truly unique methods to achieve a particular function: some parts (such as source code selectors) of this library look scary. If you do so , it requires an understanding of how the library works. To understand this, you need to know some basic concepts, the differences between browsers and a set of methods, which the library uses to get around them. No library can protect you 100% against weird browser behaviour, but as long as you have a grounding in the underlying theory you should be able to figure out if a problem stems from your own code, your library or the underlying implementation.

11) Conclusion. I hope enough evidence was brought to have a positive conclusion about jQuery: it is not a regular library. It contains a lot of interesting ideas that can surprise even the most experienced JavaScript programmers and teach them something new. Even if you will not use it in the work, it is necessary to devote some time and explore the “ecosystem” jQuery.

Elvira Golyak

Elvira Golyak
Elvira.Golyak@altabel.com
Skype ID: elviragolyak
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Nowadays there are dozens of Java web frameworks. Many of them serve the same purpose and so I have tried to elaborate just on the most popular and typical in functions ones in my post The Best Java Web Framework.

Although I didn’t seek to cover all the frameworks and mentioned that in the post, there were advisory comments to consider Grails framework in my analysis. Having been given that much respect from the developers, this framework is definitely worth to be given a separate attention.

So please find below an overview of the Grails framework, its advantages and why this framework might be the best for some developers.

Grails is an open source Java framework for creating web applications. Grails is actually built off Groovy which gives the immediate benefit of being more productive. The Groovy syntax is much terser than Java, it’s much easier to do things in one line of Groovy code that would take you several in Java. At the same time Groovy has the capability to work with Java seamlessly, but that’s the different story.

The Grails framework attempts to bring some of the lessons from Ruby on Rails into the Java world such as DRY (Don’t Repeat Yourself) and Convention over Configuration:

- Don’t Repeat Yourself (DRY). Grails enables you to write DRY code and in itself is a good example of how to be DRY. If you have any existing Java code reusing it in Grails should be no problem.
- Convention over configuration. If you adhere to the conventions set out by Grails (which are very sensible btw) you can become productive very quickly.

Grails gets most of its magic from Groovy, a scripting language that is targeted to the JVM and features a mix of static and dynamic typing, and a Java like syntax. Groovy scripts are compiled to Java classes and can import regular Java classes (and vice-versa), so you can leverage your existing libraries.

Grails feels a lot like a Rails framework. If you want experience the power of Rails but don’t feel like learning Ruby then try Grails. On the other hand, if you have spent any time with Rails, you will find Grails simple to learn (especially with a Java background).

GORM (Grails Object Relational Mapping) is used in Grails to map domain objects to their corresponding database table. GORM is written in Groovy, but under the hood, it’s using Hibernate 3. GORM objects look and act very much like Rails’ ActiveRecord objects.There is no explicit mapping required, and table associations are simple method calls inside the domain object (belongsTo(), hasMany(), etc).

Another strong point is the choice. The Java community tends to have an overwhelming number of frameworks, application servers, views (JSP, Velocity, Tag Libraries, etc) and libraries to choose from. While there are pros and cons to having so many options, the bottom line is that you get choice with Grails. Here are a few of them:
- Grails projects are wrapped up as ordinary WAR files, allowing you to deploy them into any J2EE compliant web server.
- Grails uses Hibernate 3 for persistence, but will also support JPA compliant technologies such as EJB3.
- Grails supports both GSP (Groovy Server Pages) and JSP as view technologies.

Community: Grails is targeted at Java developers (a very large community indeed). At the same time it is worth of admiring that the Grails developers weren’t afraid to acknowledge that another community/technology has done something really well.

To sum up here are the main advantages of this framework:
1. Grails is built on several popular frameworks, e.g. SiteMesh, Hibernate,Spring.
2. Java programmers will have a flat learn curve, especially for those familiar with Hibernate and Spring.
3. Grails is maintained by SpringSource.com, that means the flexibility and scalability is not just good, it’s great!
4. Grails can be deployed on many popular J2EE servers, e.g. JBoss, Tomcat, WebLogic etc.

Please share your experience of working with this framework. It would be great to hear both positive and negative comments on using it.

Kind regards,
Aliona Kavalevich – Business Development Manager (LI page)
Aliona.Kavalevich@altabel.com
Altabel Group – Professional Software Development


%d bloggers like this: