Develop Reference

What's the procedure of upload a java spring based web application to the real server, and how to use load balance to the server?

I am creating a simple web project with mysql database using Java Spring-MVC. Now I want to understand the full workflow of the web system development cycle.
How to upload a project to a real server?.
How to sync the database to a real server?.
How DC and DRC is sync with each other?.
Why and how to use "Load balancer" to the server?.
Apologize, if I said something non-technical.

I'll not go into too much details but here is the gist of it.
Before anything, the first thing to get sorted is the operating system of the server be it Linux, Windows Server and so on. The choice of operating system will depend on the constraints and requirements.
How to upload a project to a real server?
Any files which needs to be served should be hosted and served by a web application server such as Apache Tomcat, IIS, Websphere and many more.
The choice of web application server depends on a few things, such as the server operating system, the web application implementation and so on. For your case, which is a Spring MVC implemented in Java, you'll need to use a web application server that supports that, such as Apache Tomcat for example.
Once the choice is made, install the web application server on the server. After that, install your web application on the web application server.
How to sync the database to a real server?
I infer that you're referring about the connectivity between the Java web application to the database? Do comment if its not.
The Spring MVC web application can connect directly to the database via JDBC or JNDI (provided that the necessary configuration is configured on the web application server).
Of course, the database can be connected locally (if installed on the same server) or remotely.
How DC and DRC is sync with each other?
This is too broad to cover and the recovery strategy differs for every Data Center providers. But broadly, they employ redundancy and replication strategy to ensure the data is always backed up and available. Check with the providers individually for a better picture.
Why and how to use "Load balancer" to the server?
The load balancer primary purpose is to distribute the work load across multiple servers to achieve better TTFB. To do so, it sits in front of the servers and routes the request accordingly. Some of the load balancing solutions such as f5 explains about load balancing in greater detail.

Step 1: Install Application Server on your machine.
Step 2: Install JDK, Database server which are dependent on your application.
Step 3: Export your war from Eclipse/Netbeans
Step 4: Paste your war file on app server's deployment folder (webapps incase of tomcat)
Step 5: your application deployed

How to call a web service inside another webservice

I need to consume a secure webservice deployed in WSO2 AS from another web service develop in axis2 and deployed in apache tomcat.
I create a java project to test the secure webservice client and I work OK.
But when I move the client code inside the axis2 service I cannot access to some resources like in this cases:
System.setProperty("javax.net.ssl.trustStore", "keys\\store.jks");
in this case I have the keys folder in the root of the wb services
sc.engageModule("rampart");
and in this case I leave the code idem
Any idea about this?

Well getting a resource path from an archieve file whether it is a jar ,war or aar is a tedious problem. There are two options two choose from:
1- Since client application runs on a servers put jks file somewhere on the server path, its path retrieved dynamically via property. (Either system property, servers context etc.)
2- A customSSLFactory handling loading keystore from resources.
This SO thread mentions such solution, which i used it too to connect to server via SSL from a web service without touching system properties.

Process of webserver starting

This question is kind of related to our web application and it is bugging me from last few months. So we use linux server for database, application and we have our custom built java web server. If we do any change in source code of application, we build a new jar file and replace the existing jar file with new jar file. Now update to take place in live application, we just execute a HTML file which contains this kind of code :
<frameset rows="100%"?
<frame src="http://mydomain.com:8001/RESTART">
</frameset>
How does this opening of port make the application to use new jar file?

The webserver is instructed to give the /RESTART URL special treatment. This can either be through a mapping to a deployed servlet, or through a hardcoded binding to a web container action.
It is very common to have URLs with special meaning (usually protected by a password) allowing for remote maintainance, but there is no common rule set. You can see snapshots of the Tomcat Administration console at http://linux-sxs.org/internet_serving/c516.html
EDIT: I noticed you mentioned a "custom built web server". If this web server does not provide servlets or JSP's - in other words conforms to the Servlet API - you may consider raising the flag about switching to a web server which do.
The Servlet API is a de-facto industry standard which allows you to cherry-pick from a wide array of web servers from the smallest for embedded devices to the largest enterprise servers spreading over multiple physical machines, without changing your code. This means that the hard work of making your application scale has been done by others. In addition they probably even made the web server as fast as possible, and if not, you can pick another where they did.

You're sending an HTTP GET to whatever's listening on that port (presumably your web server). The servlet spec supports pre- and post-request filters, so the server may have one set up to capture this particular request and handle it in a special fashion.

Functionality of a web application to handle user's request to download files from SFTP Server

In our Java web application, customer wants to upload some large files to a SFTP server and download directly from there. The customers do not want to use any third party tool rather they want this functionality in the application itself.
The file upload part has been taken care of by the JFileUpload applet component & libraries. Once the file gets uploaded I could figure out the exact location of the stored file. And that uploaded file will be shown to the users as a link which they will click to download (like an HTTP or FTP file link).
So I've to decide the strategy for downloading the file from the SFTP servers.
One option is to parse the request, then connect with the SFTP server and stream the file via HTTP server. But here the file will be downloaded over HTTP rather SFTP and moreover it will not serve the purpose of using SFTP.
Another option which I could think of is via an applet, again like upload. As soon as the request for the SFTP file comes to the HTTP server, it will launch a page containing an applet having a directory browser for users to decide the save path. Once the user selects the save location, the file will automatically start downloading to that location from the SFTP server. In this way the connection will be completely SFTP.
I want to know how much feasible the second approach is and if there are any important things I'll have to take care of. Which SFTP libraries are the best to use for this type of operations?
Moreover, please let me know if there are other better options to do mentioned activity.
Edit
It seems this post looks like a request for suggestion on ways to download from SFTP server (may be from the heading but I could not think of any other heading!!). Thank you for the suggestions on the APIs to do that but the more important issue for us is to figure out a way where a user's request to download a file from SFTP server is done over secure SSH rather than over HTTP. Now using the mentioned APIs we could very well download the files from the SFTP server to the HTTP server's filesystem but after that if we have to redirect the same file to the user's machine we have to use HTTP and that is what we want to avoid.
Our second thought approach of using a page with an applet which will initiate a SFTP session between user's client and SFTP server is to address the above concern.
How difficult will it be to implement and what should be our approach in this regard?
And if there is any other better & easier way to do the same task then please suggest.

I favor Commons-VFS for this kind of thing. It abstracts out the actual file system type and lets you work with a standard interface regardless of the underlying implementation. It in turn depends on other libraries for the actual systems, in particular JScsh for SFTP.

I recommend using JSch, Java Secure Channel. It is a pure Java implementation of SSH2. It has good examples for doing SFTP in addition to pretty much every other SSH2 option (XForwarding, port forwarding, etc.). We use it in a number of our projects, and have not had any issues. I have even tied it's GSS-API (Kerberos) support into a native Kerberos implementation and it worked well. It is BSD licensed, so commercial or not, you shouldn't have much issues with licensing.
I see building an applet using JSch to be pretty simple. Biggest issue will be to make sure your applet is signed and has permissions to write/read local files and connect to the SSH servers in question.

The customer is always right, so while the requirement screams bad architecture to me, I'll just extend my sympathy on that and try to help you with the problem.
The applet approach is OK, but seems kind of clunky for a web app. There are javascript sftp libraries out there. This one supports sftp and will give a much more natural feel to a web application than poping up an applet just for the sake of providing a file transfer. It isn't free, but it isn't that pricy either. It still uses an applet under the hood to effect the file transfer, it just doesn't present a java screen to the user.

Did you mean SFTP or FTPS (FTP over SSL)?
If you realy ment SFTP, have a look here: http://www.spindriftpages.net/blog/dave/2007/11/27/sshtools-j2ssh-java-sshsftp-library/comment-page-1/

Separating web server and app server, do both need java?

If we are to separate our web server and app server, would we need java on both machines? I've had one coworker say to install jboss on both machines (seems to defeat the purpose if both machines have app server installed) and another says just install jboss on one and apache on the other (app server/web server).
I have the web project setup already and it uses servlets and JSPs. The JSPs display the content while the servlets do the action. The servlets receive requests and forward responses to the JSP. My question is how do I do this if the web server only has apache and therefore displays static content? I understand how to forward the requests from the web server to the app server but what about maintaining session state, is that done on the web server and if so how would it be done?
If the login page is html and the content after the login is html then how could I stop people from accessing the content if they haven't logged in?

The latter setup you describe, with Apache serving static content and forwarding requests for JSP/servlets onto the app server is the standard setup.
Session state is maintained as normal, your Java webapp on the app server sends the user back a cookie containing a JSESSIONID and when the user makes subsequent requests, Apache includes all request info (including cookies) in what it forwards to the app server.
The setup becomes a bit more complicated if you want to have Apache sit in front of and load balance requests to multiple JBoss instances, but it's still pretty easy to set up with mod_proxy_balancer.
Some links that might help you:
http://help.shadocms.com/blog/2009/how-to-setup-apache-with-jboss-on-a-shado-site.cfm
http://redlumxn.blogspot.com/2008/01/configure-apache2-and-jboss-422ga.html

There are many possibilities.
On web machine install just apache with mod_jk to redirect the requests to tomcat/jboss.
In this case you don't need java on this machine.
You can also separate your jsp container (e.g. tomcat/jboss) and your app server in this case you you will need to install java where you have your web container.
Generally where there is a need of higher security people combine the above mentioned possibilities. Thin web layer (apache + no java) + Web container (e.g. tomcat) + app layer (jboss/glassfish)
The first solution is normally the standard one.

Your scenario reminds me of SiteMinder. It was used to access control into our application. It has built in HTTP forwarding so from the user's perspective the browser talks to siteminder and siteminder talks to the real application. They both use session cookies and siteminder's called SMSESSION while the app's called JSESSIONID so there is no conflict.

A common deployment is to use Apache fronting servers to serve static content and forwarding requests for dynamic content to the JSP server. This is mainly for performance reasons, Apache being both faster at serving content and reducing the load on the JSP server.
I don't see any reason why you couldn't, for example, use IIS as the fronting server (removing Java from the equation), although with the wealth Apache modules and accompanying information about the configuration I think you might be making life difficult for yourself if you did.

Short answer - No.
Long answer -
It depends on the needs of your application. There are a few reasons why you would want to have the web server on a different physical machine:
You want to have the web server serve
the static content, and leave the app
server free to only process
servlet/jsp content
You wish to implement software based
load balancing. You would have the
apache server proxy requests to
multiple backing app servers
In your login example, the html page is served by apache, and the action of the html form points to your servlet for processing - so JBoss/java will still manage the session. Keep in mind that any static content you want apache to server will need to be present on the web server.