How Ria and Rest resolve the disadvantages of Java

Where is the disadvantage of Java? Compared with previous years, it is now clear that the disadvantage of Java is to do the Web presentation layer development. Web performance layer development needs frequent changes, such as Java static type of language is not agile, seriously affecting the efficiency of development.

One of the biggest drawbacks of Java EE is the attempt to get everything done on the server side, which I call the "traditional centralized development approach". The standard Java EE three-tier architecture--web performance layer, business layer, persistence layer, may be appropriate for traditional Web applications based on HTML forms, but it is now outdated. Java EE attempts to fully handle the development of the Web presentation layer on the server side has created a big problem for itself. They are not good at it, either from the language itself or from Sun, IBM, BEA, and Oracle, the main companies that support the language. What are the companies that are good at this? Adobe/macromedia, m$, Borland/codegear.

If the Web presentation layer has to be developed on the server side, the advantages of Ruby on rails are significantly more than Java EE. ROR is more flexible than any mainstream Java EE Web Presentation Layer framework and technology (Struts, WebWork, Spring MVC, JSF, Tapestry, etc), with lower learning costs and higher development efficiency.

Think about it in a different way, what if we no longer assume that the client is a thin of almost no intelligence? Let's assume we can leverage the client's Ajax component library and various RIA technologies to develop the Web presentation layer, either completely or most of the way forward to the client, and communicate with the server through the rest-style API, Then the role of the server becomes similar to that of a Web service provider (note: There is a big difference between this and Web services, because rest is here for the same application, the client and server side of the application), This can greatly simplify the development of server-side Java, let it out of the area of what you are not good at, and focus on doing some of the work you are best at.

This trend is actually more than 3 years ago when I was in the Javaeye forum to promote the development of XMLHttpRequest based on the time has been seen, now this trend has become more and more obvious, the face of the new generation of web development has gradually surfaced. Adobe Air/flex, m$ wpf/silverlight are the same kind of development, of course, Ajax can also be developed in this way. I name this kind of development method called "Ria+rest".

It's also good to have everything on the server, because it gets the best control and the security problem is easier to solve. But the cost is not to get the best interaction design, forcing users to endure the use of degraded experience. If such a user experience is acceptable, there is little to do with design and development problems in this way. But if such a user experience is unacceptable, then you need to seriously consider the way ria+rest is developed. Compared with the traditional centralized development method, this is a new type of distributed development method, in some aspects (interaction design, server-side architecture) is simplified, but also makes some aspects (server-side control, security) complex, so require the architect to make a prudent trade-off. Distributed applications are bound to bring a lot of complexity, but rest is undoubtedly the most ideal architectural style for web-based distributed applications, and rest has a much greater advantage in the Web than architecture styles such as RPC and distributed objects. At the same time rest is concise and practical, can greatly reduce the huge complexity of distributed applications.

According to my experience, in most small and medium-sized projects, the Web performance layer development workload is greater than the sum of the two-tier development effort, which accounts for more than half of the project development effort. When users need a more demanding experience, the traditional centralized approach to development is completely out of the question and must be supplemented by Ajax. However, for applications with complex interactive requirements, the development efficiency of the ROR application will also be dragged down by the development efficiency based on the DHTML, but not the agile advantage can be fully reflected.

If Java is to do the burden of Web performance layer development, let the client's RIA technology to bear, then Java in server development compared to Ruby's disadvantage is not so obvious, and even in many ways there are advantages. Considering the development efficiency of the overall architecture,

RIA + REST + Java

RIA + REST + Ruby

The two schema combinations may reach roughly the same level, and even if Java is still a disadvantage in terms of development efficiency, it will not be as disparate as in the traditional centralized development approach. There are many rumors that projects based on ROR development can be 5-10 times more efficient than Java based projects. Although I am not optimistic about Java, but for ria+rest this new development method, I estimate the development efficiency gap should be reduced to about twice times. However, development efficiency is only one aspect, if the server-side code is well refactored, reusability is very good, not in six months after the need to discard the legacy code, then Ruby's development efficiency in the great advantage may only stay in the initial stage. With the accumulation of code, the advantage of this development efficiency will gradually decrease.

Will Ruby embrace Ria? RoR 2.0 will be a development framework based entirely on rest design, and they now embrace rest in preparation for embracing Ria in the future. For the traditional centralized development approach, there are certainly great benefits to applying rest, but I don't think that's the main purpose of ROR. Ror embraces rest in the hope of making himself in a very advantageous position in the course of future technological change. For future development of web development technology, rest is at the core of the link between client and server, and rest can greatly affect the design and modeling of client and server-side architectures. "Resource-oriented Web applications" will be a technical hotspot in the coming years.

Java is much more sluggish in its support for rest. The JSR 311 specification, which is being developed by the authorities, is primarily geared toward integration between different applications, which is primarily covering the areas covered by soap, rather than a new type of web application development approach such as ria+rest. However, some Java frameworks that support rest are already in existence, and can be designed based on Adobe's Flex framework (open source this year), making it easier to design and develop based on Java. We don't expect Sun to be here for many years. Sun can actually admit: "I have not been the boss for many years."

To sum up, I think that supporting rest is even more meaningful to Java EE than Ror. The ability to embrace future trends in web development technology is critical to the future fate of the Java language.