Recently I found its direct comeptitor, Titanium made some steps forward and now looks much better than it was an year ago. So, we have installed its latest version for evaluation.

Here is the result:

What can it do?

• It allows developing in javascript.
• It allows debugging with their eclipse-based IDE (debugging is only in paid version).
• It works with android emulator and real devices on windows.
• And with both iphone and android simulators and real devices on Mac.

In order to deploy it compiles javascript to objective c and java (for iphone and for android).

For iphone the result is xCode project, ready to built with standard xCode.

It uses native widgets, providing unified API for both android and iphone.

Even if it uses javascript it does not use built-in browser, neither HTML or HTML5.

Javascript here is just a programming language (I guess they did not choose java because of licensing problems).

What is good about it:

• Ability to have one codebase for 2 platforms
• Ability to develop on windows
• Ability to debug on windows
• Ability to have native, platform-dependent modules if required
• It has rather big sample, which demonstartes usage of different API
• As I have alredy noted, it results in native applications

What is not so good

• Javascript .  It is really tricky to start develop with it as with primary programming language without great experience
• Poor code assist in IDE. In most cases it can’t suggest anything. So, developer needs to apply to documentation
• Debugging is not a part of free edition. It costs 50 usd per month. (Though it worked for me for some reason, I guess it will be disabled in a month or so). Note: they tell I can easy turn the subscription on and off when required. E.g. turn it on for month, then cancel, then turn on again etc.
• Relatively long start (takes about 3 minutes to start on android simulator)

What is really bad

When I realized they transfer javascript code to objective c code, I got one serious question: I can’t understand how they deal with manual memory allocation/deallocation with iOs, as in js you are free from this activity. I wondered if their automatic garbage collector (they should have it, yes?) is good enough to not lead to memory leaks on ios.
So, I started to google for it, and found some proof here: http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/

Here is the cut from this post:

Your app starts to crash, seemingly at random. The reason : memory starvation. You see, although Titanium is supposed to take care of memory management for you, it doesn’t always work correctly. Most of the times, especially if your application is simple and doesn’t use many images and animations, the memory leaks Titanium generates over time will be small enough that you won’t even realise that your application is actually leaking. Problem is, when your application reaches a certain level of complexity, those leaks will become evident – in the form of sudden, unavoidable crashes.

Conclusions

It seems Titanium is yet “raw” technology, which is not suitable to develop big, production quality applications. Probably they will fix their problem with memory management later, but for now we stay with PhoneGap, which it at least stable. BTW, I was suggested to look at Adobe Air. Probably I will add new post devoted to it sometimes.

Appendix : some installations know-how

For those who still plan to play with it there are some installations know-how:

1) Check Compatibility Matrix and get sure you have exactly required versions of everything installed. Especially it relates to Android SDK platform.
Titanium Studio 1.7.2 requires Android Platform 2.1.update. And it will simply not recognize android SDK if you have e.g platform 2.2 or 2.0. Compatibility matrix can be found here: http://wiki.appcelerator.org/display/guides/Titanium+Compatibility+Matrix

2) Get sure you have JDK bin directory in your PATH environment variable. Titanium Studio tries to call “javac” and crashes if it can’t be found

3) Do not forget to delete all the android virtual devices before first run of the Studio (it will create one itself, if there are some existing devices, it will take the first, and will most probably crash)

4) When you configure Android SDK pay attention to choose correct API version. It MUST START WITH “Google” word! e.g. “Google API 2.2″ is correct, while just “2.2″ or “API 2.2″ is not correct, though it is here by default! If you choose incorrect API it will crash.

For those who want to read why Hibernate is not a choice, I wrote a separate article in my personal blog.

Here I want to focus on what makes EclipseLink better than Hibername.

At first, both of them are java ORMs. Both now support JPA specification. Both are production ready. As Hibernate is older, it is even more popular currently.

I would like to define two criteria to compare these ORMs from the business point of view. Then I will go through some technical details to show why EclipseLink is simply better.

The business points are:

• Predictability
• Fragility

Fragility

Let start with more simple thing – fragility. Just some statistical information. If you open issue trackers of both these products and search for all open CRITICAL and BLOCKER bugs you will see following picture (as for July 26, 2011) :

Well, I think it explains itself. However I can only add we have made this short comparison not because we were curious, but because we really had too many problems with Hibernate stability. And now we have approximately 10 times less.

Predictability

By predictability I mean an ability for developer to predict how the code he/she just have wrote will behave. Good library should have high level of predictability. However it is not the case with Hibernate.  Let me repeat my own post from the blog I already noticed:

Just a sample:

User user = loadUser(id);

It is a good old explicit statement which obviously loads user. How many SQL statements this call should execute? Normal answer is “one statement”. Something like

select * from users where id=?

But the true is in Hibernate it can be any number. Thousands or millions. And the most cool feature is this number may be easily (and often unintentionally)  changed in several different places of the code!

It is because of autoloading. When you designed User refers to a collection of Roles you most probably never thought that one of your colleagues will later add ref from Role to let say Permission. And another one (couple of weeks later) from Permission to something else.

As a result, your fast and pretty loadUser now executes 100 times slowly. And even when you accidentally find it you will have to analyze the whole model to understand what happened and then start with huge refactoring to make your code fast again without breaking codes of you colleagues (that relies on Permission collection now!)

Now let me explain why it does not happen to you with EclipseLink. Two facts:

1) This happen only to “eager” links. And does not happen to “lazy” links.

2) With EclipseLink you have no any reason to use eager links at all, while with Hibernate you have the reason for it

Lazy links and Lazy Initialization Exception

The reason is lazy links only works inside transactions in hibernate. It means if you load an object from database and close database connection such links will no longer work. If you try them, they will result in lazy initialization exception. So, standard strategy in hibernate is either to make a lot of links eager or to add a big set of methods like:

• loadUser()
• loadUserWithRoles()
• loadUserWithRolesAndPermissions()
• etc

With EclipseLink it is not the case. Lazy links will work even if you accidentally closed database connection. In such a case, EclipseLink will simply take a read-only connection from connection pool, execute loading and then put the connection back to pool. It will do it hiddenly, without bothering developer.

So, if developers simply make all the links lazy, it will work with EclipseLink and will solve the problem described above.

Conclusions

Even though EclipseLink does not solve all the problems, good ORM should solve in our opinion, it is currently the best java based ORM. And it is definitelly better that Hibernate.

Okay, in this post I will describe the way in general and will list all the components of typical softaria web project, without going into details such as why we prefer one or another component. I plan to add more posts devoted to each component later.

A typical project

So, our typical business project:

• automates some business activity (e.g. activity of marketing department  or of business intelligence department)
• needs 6 months for first version to be completed
• intended to live for at least 5-7 years and have tens of releases during its life cycle (of course upgrading to new release needs to keep existing data)
• needs to be integrated with 2-3 external systems by different means (e.g. web services)
• has up to hundreds of thousands users (not millions)
• uses only free and open source high quality components legally allowed for commercial projects
• has web UI, of course

A technology stack

programming language

At first, we use java. Java is better than Microsoft’s technologies because it has the same quality, but it is free. And because the java component market is high competitive, while Microsoft’s one is almost monopolized. That is why we have a lot of high quality free and open source components in java, which is not the case with Microsoft’s technologies.

The reasons why we do not use PHP are described here.

Of course there are more technologies suitable for web, like e.g. RoR, however I think the described 3 are leading.

database

Our standard choice is PostGRE sql server – free , open source high quality relational database management system. (Here you can read, why not MySQL.)

Application server

Our application server normally has 3 layers: data access layer, business logic layer and user interface layer. Each layer is built as a separate java project. The 4th java project contains data object model.

Everything built with Apache Maven.

Object relational mapping

We use EclipseLink ORM, which is the reference implementation of java persistence API. In our experience it works much better than its closest competitor – Hibernate. I will describe later why. [Update: described here.]

Keeping database schema up to date

Is done with liquibase – a library which allows database schema refactoring in controlled way. I plan to devote separate post to it as well.

User interface layer

We use either Apache Wicket  or Google Web Toolkit for building user interface. First fits better for traditional page-based interface, while the second is ideal for AJAX style, where an application should behave more like desktop one. Sometimes we mix both these technologies.

Layer integration

All the layers are integrated all together via Spring Framework – probably the best integration framework in the market. Besides inversion of control container we intensively use other components of spring framework, such as spring security, transaction management and a lot of other. Spring Framework also used for integration with 3d party systems (e.g. via RESTful services)

Web server

Using Spring Framework as an integration framework has one additional plus: the resulting application can run in any servlet container: Apache Tomcat, Jetty, Resin or even Glassfish or Jboss. Though our normal choice is Tomcat, for some customers other servers are preferable.

Operation system

One good thing about java is it is cross-platform. So, the project can be installed at almost any operation system. However our choice for production environment is Ubuntu Linux. Probably it is because we were Ubuntu Silver Partner in 2007. And though we stopped this partnership, we kept the expertise.

OSGi was born as a technology for desktop applications. The main idea behind it is fighting jar hell. And it works well, allowing plugin writers to not care about different jar versions used by a system core or by other plugins.

That is really good for desktop applications (such as eclipse). But it is not as obvious about using OSGi for client server applications and, in particular, for web applications. Let me explain why.

OSGi at web

About an year ago I was really excited about Eclipse Virgo – a project, which brings OSGi to web. At first sight, it simply adds all the pluses of OSGi to web world: no jar hell, ability to hot deploy, strict contracts between components.

However when we built real world big project with it we found one serious side-effect: it makes development cycle significantly longer. In our experience, it adds about 15-20%! It is because the technology is rather heavy and relatively fragile with debugger. (Re)starting server requires minutes. Hot deploy is not always work as expected in debug mode, so it requires restart relatively often.

Finally even though the technology somehow simplifies a life of plugin writers, they still need to have system core installed to develop a plugin. This last limitation not only makes plugin development harder, in some cases it makes it impossible, as for a lot of  customers system core is not a thing they wish to share with the world.

Alternative solution

So, finally, we have started looking for an alternative solution. And it brings us to a question: What is the main reason for using OSGi at all? The answer was: we use it because it fights jar hell. In other words, we use it because it isolates different parts of application from each other. But wait. Why to not do the same in more straightforward way? When we have web application, why not to replace OSGi bundles with isolated web applications (wars) which speak to each other via web services?

We started to look for similar architecture solution from real world and have found MindTouch. Though it is not written in java, it appears to be based on exactly the same principles! And as it is the number 3 product in its business niche (just after IBM’s one and Microsoft’s one), it means this approach works for it. So, it should work for us as well.

How this works

Now bit more details of the solution itself.

The application is deployed as a set of absolutely separated web applications.

From logical point of view, it has one core and a lot of plugins.

Both, core and plugins each consists of 2 parts: back end and UI.

Back end part has a set of RESTful services as an API. The services use JSON as intercommunication format. Corresponding UI talk to their back-end via these services.

System core provides similar RESTful API to plugins. This API can be used by plugins for both: calling system level functions and registering plugin’s own services as callbacks.

What does it give?

Well, at first it obviously eliminates jar hell problem. As each plugin is isolated web application.

But it is not the only plus. Let me list other benefits:

• Back ends can be tested independently from UI, using any REST client, like e.g. curl. The same for UI – it can be developed independently by using temporary static json files placed within any HTTP server.
• Plugin can be developed independently from core: an API of plugin itself can be tested with curl. When plugin needs to call core, it can do it remotely – no need to download and install core locally.
• Either plugin as a whole or only its part (UI or backend) can use any technology, which supports HTTP! Special benefit is an ability to involve junior developers in buildin UI (even with PHP). They will not be able to destroy the system architecture.

So, this architecture is our current choice for big web applications.

The problem was we needed this forum to be integrated with the system: It had to use the same users as the system does, it had to use complicated business rules to calculate those user’s permissions. E.g. if student’s group gets new teacher, this teacher must immediately get write permission to the forum’s topics corresponding to the group.

So, we were in need of forum which:

1) Can be added to existing system as plugin

2) Defines such concepts as User, Topic or Permission on abstract level and let the existing system implement those concepts

3) Performs fast, as the system serves ~5000 students.

Unfortunately we were not able to find any pluggable forum at the market.

So, we have developed our own.

The forum defines several interfaces such as UserManager, TopicManager or PermissionManager; and expects the system where it is plugged to implement all of them. So, it uses these implementations as “adapters” and really works with the same objects, original system does.

It took us approximately 120 hours to implement this.

So, if you need a pluggable, fast and stable forum in your java project, please contact us. We are ready to sell it for only 250 usd, which is much cheaper than implementing it from scratch.

So, when you ask somebody to change something in a PHP-based project, it depends on his professionalism if he will use these legacy constructions (and therefore will quickly destroy your project’s architecture and will make the project not maintainable) or if he will not do it.

It is probably not a problem when you:

• know your provider  and sure in their professional level
• sure you will never need to change provider and never need to ask somebody “with PHP knowledge” to fix something quickly

However we at Softaria do not mess with PHP if it is possible. Because projects made with PHP can be easily destroyed by 3d party low-class developers. We prefer using java which is initially designed as object oriented language, suitable for building big, long-living systems.

It dramatically changes the whole cassandra-related ecosystem. As now it is probably has no sense to mess with complicated RPC API, at least in most cases. Also it may even make obsolete to use Hector, which was the best Cassandra client so far.

We have plaid with this new API and found it not yet mature, but already usable. Moreover, we were able to port one of our small internal project, called tiny ORM to use cassandra via CQL instead of relational database it was initially designed for.

So, now we have a java ORM which supports such concepts as polymorphism and all kind of relationships (one-to-many, many-to-one and many-to-many) and works above cassandra distributed data storage.

I wonder if anybody interested in it. Now we consider if we should open its sources.

The answer is simple. And it can be found in official MySQL documentation: http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html

The key phrase is: “You can get deadlocks even in the case of transactions that just insert or delete a single row”

And the true is deadlocks really happen to high load systems. And they do it periodically.

The only thing you can do with it is just “be prepared” and “be ready to restart each transaction”. In real world it means – increase development effort and add special “repeat transaction” layer. (In fact, the most developers use another rule:  “ignore it and hope it will not happen to us ”)

One may tell the problem exists only when you use innodb engine. It is true. But other MySQL engines do not support such a basic concept as transactions! Why to use database without transactions at all?

So, during last 4 years we are with PostGRE, which performs much better in large, high load systems (and absolutely the same in average or small systems). If so, why mess with MySQL?

This is not as important, but sounds positive

As this is rather typical question, I have decided to put my (also typical) answer here. (The system we discussed was an average business software with web UI. Development cost was about 3-5k of usd.)

At first, there is no such thing as “absolute protection”.
You see even sites of FBI are hacked sometimes.
However the goal should not be to protect your system from the best hacker in the world – his time costs more than your system
The goal is to make it economically not effective to hack your system: we must make the cost of hacking higher than the cost of profits one gets if hack it.

For this scale of system following measures are reasonable:

1) Use SSL (httpS) protocol for browsers to access the system. It will make impossible to “sniff” user’s passwords
2) Introduce password complexity check to not allow users to enter too simple passwords that are easy to hack
3) Add a “login attemp counter” which does not allow robots to make repeating login attempts: If one enters wrong password fro e.g. 3 times, he now asked to enter a captcha in addition to password.
4) Keep the system up to date. Either manually or by finding a hosting where they warrant applying all the recent security patches on operating system level.
5) Store sensitive information (like credit card numbers) encrypted in the database
6) Disable root account and use sudo access only. Give this sudo access only to those who extremely need it. Ensure they use complex passwords for their account. And that these passwords ARE NOT USED in any other external systems (e.g. they are not known in Internet)
7) Disable all the access to the server, but the SSH (for remote terminal) and httpS for browsers. Use firewall to block all the other ports but these 2.

This should be enough to keep the system secure.

Of course we could do much more, but I do not think it is reasonble to double the development cost by fighting the high level hackers who , indead, have much more profitable job than dealing with systems of this scale.