Develop Reference

Web application, offline mod & synchronisation

We are a group of 6 students in the last year of our studies.
We have to add new features on an existing web application. One of the most important feature and in our opinion the hardest one to implement is the following : the web application has to be functional even when offline.
As for, you must be able to consult data, make changes to the data, and when your device will be able to connect again, the app must try and synchronize with the online database. The current application use the following technologies : apache tomcat / mySQL / Hibernate / JavaEE / JavaScript / Ajax / xHTML & HTML5.
Considering that the main devices that will use the application are mainly digital tablet, smartphones (windows and android, not iOS for now), and windows PC ; my main question is the following one :
How can you do this kind of thing ?
I've done some research and it seems like you have to do a 'second' application, which will use mainly HTML5 to consult data while offline and JavaScript to control what the user is doing and what he can do. But we have no idea about the synchronization. It seems like SQLite could be of use as well
I know this is a general question but we are in the phase where we try and make sure everyone understands what the next steps will be. Thanks for your help and explanations.

Solution-1 : custom solution
There are api available to store data locally called indexDb in javascript which may help to store data.
For synchronisation i found that service workers may help.
Solution-2 : ready made tool
You can also try pouchdb but for this i think at server side you have to take apache couchdb database. I have not used it but would like to try this once.

Take a look at the Service-Worker API. Service worker is a programmable network proxy, allowing you to control how network requests from your page are handled. It's the next generation of giving users an offline experience after the App Cache.
The Service worker - in combination with local storage or even better WebSQL or a polyfill like localforage could be a way to realize that kind of application.
Downside: Service-Worker require SSL, no way around that. Second, only latest chrome and firefox support these technologies.
You might lookup PWA Progressive Web Application as a keyword, which describes / and uses exactly that kind of technologies.

Converting desktop application into server + browser application

I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo

If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf

SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.

Java Backend/Server design setup

This is a very beginner question. I have tried to search for advice but am overwhelmed by the amount of information and would like some help with ideas on approaches to server design or what to search for!
What I would like to set up is a backend server that provides search capabilities and business logic and validation across some fairly basic data. It wont get too large.
I would then like to be able to plug in a website as a front end or a mobile app or a facebook app or even a desktop app..
My question is what is the best way for front ends to hook into the backend? I would like to have various user accounts with permission levels so authorisation would be important.
I generally only code as a hobby so whilst technically I have built a spring based website before the exact semantics of the client server relationship weren't clear to me. Now I want to separate the backend so that is is agnostic of how the data is displayed or entered completely and can run on a separate machine.
Thanks,
Rob

There is a ton on options. I had good expirience with apache CXF rest services (logic encapsulated in java beans, spring configuration) and pico web remoting ( more exotic,
but also rest service and plain java objects providing business logic)
if you ar already using spring, I would recommend to stick with CXF - it integtrates seamlesly ( and is spring configured itself )

What's the best modern way of developing open web apps with a rich JavaScript API for data access?

The company I work for has a powerful Java based server component framework for interacting with special control systems.
We have a UI framework but this is also Java based. A customer can use a Java Applet to access control information etc.
I've recently started working on a rich JavaScript API to access this control system information remotely. It's currently a prototype. It's nice because anyone who's familiar with JavaScript can access our Components remotely. So far it works really well. I've written some prototype applications that use this API. This gave me an introduction to jQuery - great! I've also added the ability for the JavaScript API to make RPC calls to Java as well as a session based Component architecture for when you really need something held on the server.
So far so good. I have to admit though that I'm not really a 'web developer'. I've never used Structs, Spring or any of the MVC based architectures for serious Enterprise based web development (I AM very familiar with design patterns though). My background is application development.
I'd like to know from the pros whether this is the right approach or whether I'm missing anything. Someone I work with has created a really neat Server Side Include architecture. However, I'm wondering now whether this is really necessary? After, I think I can create just about anything using my JS API and jQuery. Should I consider any other 'server' based architectures in this new age of open web apps?
As far as browser support goes, I'm not concerned about the older generation of browsers (please no lectures here, the old technologies we've got will do for IE6 and alike).
By using this open client side technologies, I'll be able to write sophisticated open web apps. Very little server side code will be needed in reality because of my API. I'll be able to take advantage of HTML 5 features etc. But am I missing anything? Should I be considering other server side based Java technologies like Server Side Includes? Am I too client focused?

Well there are four ways to create modern RIAs: HTML5/Javascript, Java Applets, Flash/Flex and Silverlight. Only the first two are open.
Applets are a nuisance and not really liked by people. Personally I'd go with HTML/Javascript.
Since you are a Java shop I'd recommend going with GWT for the following reasons:
It's open source with business-friendly license.
It creates minimum-size browser-optimized javascript.
It's actively developed and used by Google. This is a guarantee that it'll be supported for some time.
There are a lot of developers with knowledge of it.
It has good documentation and very active user group.

I'm sure there are many opinions on this, but my take is that with HTML5, faster Javascript interpreters, client side persistent storage, etc. it makes it pretty compelling to put all the UI application login in the client (browser), and just use some form of RPC (with JSON serialization) to the server. Therefore templating engines, SSI, or any server side generated markup is no longer required for interactive applications. It's still fine for semi-static documents. For that I use sphinx document generator.

Fast-forward two years, and you now have TodoMVC at your disposal to help answer this question. GWT is still mentioned, though as far as server-side technologies go, The Holy Grail is probably what you're looking for to maximize code reuse on client and server.

Would you use Laszlo to develop a Flash-based front end to a Java web app?

If you have a Java based web application (J2EE webapp - never mind which other underlying frameworks are being used), and you wanted to introduce a Flash based front-end, would you use Laszlo or would you rather expose a ReST-like XML interface and build and deploy a Flash application that uses that?
On one hand, Laszlo is quite amazing - doing for Flash what JSP does for HTML. It is easy to work with. It fits in very well with the rest of the web application (which is JSP based).
On the other hand it might be better to develop a complete Flash app decoupled from the server and use an XML-over-HTTP mechanism to bind the two. This would have the added advantage of being able to use the same XML interface for an AJAX front end if needed.
What would you do, and why?

I would create the contract-first services, deploy them separately, and then write the RIA client to access them.
Coming up with the schema first has the added benefit of completely decoupling the two during development. The RIA developer can create some synthetic XML streams to use for data while waiting for the services to come on-line.

I might have considered Laszlo in the past, but today, I'd stay within the Java stack and use JavaFX.

Laszlo is the product that never made it, there isn't a big enough ecosystem of developers around it.
I'd use Adobe Flex for the front end. The same benefits of using a markup language for doing flash, but it has a much larger developer base and open source projects to draw upon. For the data communication, use either REST or if you want to get clever, use BlazeDS.

OpenLaszlo is a complete RIA framework, so I'm pretty sure that you can 'compile' it to a completely standalone app that communicates with the server over HTTP. It's really very similar to Flex. The advantage Flex has is a much bigger community, a full-blown IDE, and more resources (Adobe), while OpenLaszlo is a little more innovative in that you can deploy to Flash or AJAX from one codebase.

I've actually spent some time working on a implementation similar to what you're suggesting. I had a complied Open Laszlo front end embedded in a web page with a Django (a python MVC library) REST interface on the backend and no Open Laszlo server. It works reasonably well, but there are a couple of things to watch out for. Open Laszlo only supports calls to GET and POST, so you won't be able to easily use the DELETE and PUT methods in your REST API. The other is the lack of community around Laszlo (as mentioned elsewhere). I can sometimes be frustratingly difficult to answer some basic questions when using Laszlo, particularly around the XML HTTP API and XML replication features in the framework. I personally never really looked at the Laszlo back end server seriously as I wanted an open API that could be consumed easily by other clients.
All this being said, the implementation does work and can be effective if you're willing to work around the limitations mentioned above. Plus Open Laszlo is free, which can be a really big plus if your working on a budget.