Develop Reference

Best option to lift and shift JBOss and Oracle database to AWS

I have a big application where there are 5 ears deployed in JBOss7.1.1EAP server running in Red hat Linux on-prem connecting to an Oracle Database on-prem.
What is the best approach for lift and shift to AWS
Solution-1 : Create Jboss EAP instance in AWS EC2 and an RDS Oracle instance and deploy the ears and migrate the tables and data via aws DMS
Solution-2 : Dockerize JBoss EAP with ears in a container and also dockerize Oracle instance and create a network link between the two
Oracle DB size = 3847GB
Each ear size = 300MB
Which solution will fit the best and what are the pros and cons for each solution? Are there any other solution?

Quick preface, "best" is going to be subjective depending on how sensitive this project is to the amount of time for refactoring/learning new tools, how much you weigh cost savings, and the wildcard around managing more of the stack yourself. That being said, here are some considerations for the big two parts of your app:
RDS Oracle vs Containerized Oracle
Dockerizing the oracle DB means that you still need to handle security patching, and requires manual crafting of scaling up/out policies, something that RDS abstracts significantly. Amazon DMS makes it extremely easy to migrate your data from your existing on-prem database to RDS. Additionally, the move to RDS enables you to use other valuable co-features, like RDS Performance Insights, a tool that offers introspection into cluster resource impact from queries and operations, and RDS Proxy for handling connection pooling.
JBOss compute options
If you're currently running on-prem and are trying to lift and shift to cloud, the path of least resistance will be a direct migration to a properly sized EC2 instance. I'm not very familiar with the exact architecture here, but it sounds like there's a persistent server with various sub-applications (ears). In the long term, it sounds like a persistent compute layer (EC2, ECS, Fargate depending on your desired level of abstraction) for the core service, with various scaleable components (containers via ECS/Fargate) would make sense. If significant refactoring to a microservice architecture is not something you're looking toward, then keeping things as they are as a monolith on single node/EC2 instance/container would work.

Advice deploying war files vs executable jar with embedded container

There seems to be a current trend in java space to move away from deploying java web applications to a java servlet container (or application server) in the form of a war file (or ear file) and instead package the application as an executable jar with an embedded servlet/HTTP server like jetty. And I mean this more so in the way newer frameworks are influencing how new applications are developed and deployed rather than how applications are delivered to end users (because, for example, I get why Jenkins uses an embedded container, very easy to grab and go). Examples of frameworks adopting the executable jar option:
Dropwizard, Spring Boot, and Play (well it doesn't run on a servlet container but the HTTP server is embedded).
My question is, coming from an environment where we have deployed our (up to this point mostly Struts2) applications to a single tomcat application server, what changes, best practices, or considerations need to be made if we plan on using an embedded container approach? Currently, we have about 10 homegrown applications running on a single tomcat server and for these smallish applications
the ability to share resources and be managed on one server is nice. Our applications are not intended to be distributed to end users to run within their environment. However, moving forward if we decide to leverage a newer java framework, should this approach change? Is the shift to executable jars spurred on by the increasing use of cloud deployments (e.g., Heroku)?
If you've had experience managing multiple applications in the Play style of deployment versus traditional war file deployment on a single application server, please share your insight.

An interesting question. This is just my view on the topic, so take everything with a grain of salt. I have occasionally deployed and managed applications using both servlet containers and embedded servers. I'm sure there are still many good reasons for using servlet containers but I will try to just focus on why they are less popular today.
Short version: Servlet containers are great to manage multiple applications on a single host but don't seem very useful to manage just one single application. With cloud environments, a single application per virtual machine seems preferable and more common. Modern frameworks want to be cloud compatible, therefore the shift to embedded servers.
So I think cloud services are the main reason for abandoning servlet containers. Just like servlet containers let you manage applications, cloud services let you manage virtual machines, instances, data storage and much more. This sounds more complicated, but with cloud environments, there has been a shift to single app machines. This means you can often treat the whole machine like it is the application. Each application runs on a machine with appropriate size. Cloud instances can pop up and vanish at any time which is great for scaling. If an application needs more resources, you create more instances.
Dedicated servers on the other hand usually are powerful but with a fixed size, so you run multiple applications on a single machine to maximize the use of resources. Managing dozens of application - each with their own configurations, web servers, routes and connections etc. - is not fun, so using a servlet container helps you to keep everything manageable and yourself sane. It is harder to scale though. Servlet containers in the cloud don't seem very useful. They would have to be set up for each tiny instance, without providing much value since they only manage a single application.
Also, clouds are cool and non-cloud stuff is boring (if we still believe the hype). Many frameworks try to be scalable by default, so that they can easily be deployed to the clouds. Embedded servers are fast to deploy and run so they seem like a reasonable solution. Servlet containers are usually still supported but require a more complicated set up.
Some other points:
The embedded server could be optimized for the framework or is better integrated with the frameworks tooling (like the play console for example).
Not all cloud environments come with customizable machine images. Instead of writing initialization scripts to download and set up servlet containers, using dedicated software for cloud application deployments is much simpler.
I have yet to find a Tomcat setup that doesn't greet you with a perm gen space error every few redeployments of your app. Taking a bit longer to (re-)start embedded servers is no problem when you can almost instantly switch between staging and production instances without any downtime.
As already mentioned in the question, it's very convenient for the end user to just run the application.
Embedded servers are portable and convenient for development. Today everything is rapid, prototypes and MVPs need to be created and delivered as fast as possible. No one wants to spend too much time setting up an environment for every developer.

Server-Side design options for mobile application

I am new to mobile application development and wanted to know from experts here on how they approach the server-side design. I need to support cross platform clients (iOS, Android, Windows) and require a scalable backend architecture.
What are the widely deployed server-side strategies
Are there any Mobile specific open source server-side technologies available.
What factors people consider for mobile application back-end.

I agree with half the answer above. You should use REST architecture - it is the most straightforward way to go. I use Ruby on Rails for my mobile projects. It is quick to start building the server code and see it working in somewhere like heroku.com almost instantly.
So I'd pick the following:
ruby on rails - worth your time picking up
heroku.com for deploying / or EC2 if you pick the Rubber gem
Google App Engine is another great option if you know some python / java
REST architecture
store all your heavy images etc with Amazon S3. They have some great SDKs to work with.
get yourself some JSON libraries to communicate with your server
on iOS:
use MKNetwokKit (it will save you lots of trouble down the road. it helps you cache and its a nice architecture all around).
if the app is small, try a data model based on NSArchiver instead of CoreData (SLOWWW). Mogenerator is a good start (this isn't server related..)
If you hate writing server side, I'd advice you to checkout Parse.com. Completely mobile only development with all server code handled for you. For big projects, you really should write your own server stuff.
Some extra things I'd consider:
how would the security work? just a session token in the HTTP header?
tier your app -- networking / MVC
what happens when you're offline? - this is currently something we're dealing with after not having thought early - pain.

I've had good success with creating a server using REST web services and XML data, but would recommend JSON instead. You can create this using Java and host it using Tomcat. This is widely deployed and widely consumable by multiple mobile and even non-mobile technologies.
A couple of factors to consider:
* You'll probably want it in a DMZ and being Internet accessible so think about firewalls, reverse proxies, and encryption via SSL.
* Will you host the server or sell the server to customers? Hosting is easy. If selling, there are many more considerations.

Play Framework application deployment

it's been a long time working on a play app & now comes the time to deploye it. that my first time so i'm kind of lost. which hosting compagny is the best & offer good pricing ?

I'll probably post a detailed instruction of what I did, but here's a quick 2-min general idea.
Buy an Amazon Micro Instance Virtual Server (costs around $11/mo) with a debian squeeze (6.0) image
$> sudo apt-get install sun-java6-jdk6
$> sudo apt-get install mysql5
~: wget <playDownloadURL>
~: unzip *.zip
~: set path to java, play
sftp/scp your source code to /var/www/<yourApp>
$> cd /var/www/<yourApp>
$> play start
~: (not actual commands but the concept)
and you are in business.

The creator company of Play Framework, Zenexity, propose a hosting solution dedicated to Play applications: PlayApps
It's probably the best choice since it is native Play hosting.
Otherwise, you can export your Play application as a classic war:
play war yourapp -o yourapp.war
Then, this war can be deployed on every Java server (Tomcat, Glassfish, etc.). For hosting a Java application server, you'll probably need a dedicated or virtualized server.
Another solution is to deploy your app on Google App Engine. But for that, you have to developp your Play application in a specific way. In particular, you can't use classic persistence. You have to use the Siena Play module to manage your entities for Google App Engine.
I don't know if Play apps can easily be deployed on other cloud structures. Maybe on Cloud Foundry since it supports Java application but I did not tested it and there are not deploy plugins yet for this platform.

You can look at this direction Heroku

Cloudbees, http://cloudbees.com, is an excellent choice. There is even a Play Framework Module for it.
http://www.playframework.org/modules/cloudbees-0.1/home

All of my Play! apps are hosted on Google App Engine, which is free for small sites. But you can host Play! apps on any Java web hosting provider.

In this question Experiences on free and low-cost hosting for play framework applications?
there are several cloud options for play framework...

There are a number of cloud hosting solutions supported by Play. There is a module for Stax, and the message boards have mentioned success on several others. A quick search for 'deploy' on the google groups will show a number of options.
I would recommend PlayApps though, It is actually hosted on Ghandi (i think!) and the pricing plan is the same, so the Zenexity guys actually make no money from this. They have set it up to be a convenience to us developers.
GAE is an option, but it restricts what you can do with Play. The WAR file deployment option, allowing to deploy to any java servlet container is also an option, but adds the overhead and resource of the container unnecessarily, so again, not the best option.

You could try Play! Manager. It's a Manager for Play Applications much like the Tomcat Manager. Worth trying:
https://github.com/mbarbieri/playmanager

Lately I've been playing around with openshift for hosting playframework application
It looks really good, you have mysql, phpmyadmin, mongodb, mongorock, jenkins, and what's even more important, you get 5 applications with 500MB op data space for each one... for free...
I'm also using this play module to ease deployment to openshift
https://github.com/opensas/openshift/blob/master/documentation/manual/home.textile
have a look at these articles:
playlatam.wordpress.com
detailed github tutorial
article found at openshift's site

If anyone is interested on uploading on Linode please follow this thread.
Linode 512 and play! framework

I advise you to have a look at http://www.playframework-cloud.com
This PaaS platform can automatically scale up and down your application regarding your traffic. You can also finely customize if you want vertical, horizontal or both types of scalability. The consequence of this scaling is that you pay as you go : you only pay for your real consumption and not the potential one.
Deployment via git.
Non AWS, hosted in tier-4+ datacenters.
Free trial !

For AWS Boxfuse offers a very easy solution.
With Boxfuse's native Play 2 support you can now simply execute
boxfuse run my-play-app-1.0.zip -env=prod
and this will automatically:
create a minimal AMI tailor-made for your Play 2 app
create an elastic IP
create a security group with the correct permissions
launch an instance of your app
All future updates are performed as blue/green deployments with zero downtime.
This also works with Elastic Load Balancers and Auto-Scaling Groups and the Boxfuse free tier is designed to fit the AWS free tier, which effectively means that you can deploy your app at no cost.
You can read more about it here: https://boxfuse.com/blog/playframework-aws
Disclaimer: I'm the founder and CEO of Boxfuse

I would look into cloud hosting.
If you developed your application in .NET, look into Windows Azure.
Otherwise, check out Amazon EC2.
Little confusing to setup if your a firs-timer, but they have guides and stuff to help you through it, and you get 100% scalability going with the cloud.

Java web app as desktop app, which frameworks should I choose?

I need to make a web app that I would be able to install as a desktop application on a client PC (database, jetty+war, firefox/chrome/sth portable).
The application is a quite big search app (I MUST use Lucene). There are only few screens, some dependencies in search queue, etc.
Now I need help in choosing correct components. Application must be:
Light - minimalistic and user friendly frameworks (Java + JavaScript)
Efficient - working on old PCs and working fast
Developer Friendly - I would love to write it with pleasure ;)
So my questions are:
Do you have any suggestions about choosing components?
What frameworks, what obfuscator?
Do you have any comments about making a web application a desktop application?
What are the main risks?

Many Java web apps distributed in this style are done so alongside a lightweight application server or web container such as Jetty or Tomcat.
When you click to start the application, this actually starts the container which internally hosts your application. (You're application can be packaged as a WAR internally.)
For lightweight databases, possibly look at SQLLite, HSQLDB, or Apache Derby. These can also be distributed alongside the application. Or maybe you can just collect database credentials as part of your install process and let the customer maintain their own database.
The arrangement you describe will involve work and custom scripting. You're going to the trouble of creating a thin, multi-user, web application and then throwing away the main benefit - the shared single instance. Customers, eh, who'd have them! :-)

Maybe you could take a look at Google's GWT. You can write Java code and it will then "compile" it to JavaScript. Using it feels like using a desktop app. Gmail, Google Wave,... have been created using this technology.
I think you don't even need a webserver, but the compiled result is pure JavaScript + static HML pages. If you then create a Chrome application shortcut it'll really look like a desktop app ;)
The only thing is that the learning curve will be a bit steep initially but if you're eager to learn, then it's really cool stuff and you can manage it easily.

Ha, I'm in the same boat. But I have many screens like normal web apps.
My suggestions is:
1, take web easy, no framework. Since there's little web pages, html+jquery+css is recommended;
2, lightweight database is not important. Because mysql does cost little memory, and it's user-friendly, large community.
3, So pay your attention on your search engine, and happy coding.