We Keep Coding

Architecture Decison: Replacing Fat Java Client with Web Client

I have a Client Server Application which is Java based with Spring for the server.
Now I have to replace the Java client with a web client.
I have three different achitectur concepts for implementing the webserver and linking it to the appliation server. But I'm not sure which I should use. I'm not really firm with web applications, but I think this is not a pure decision by the web client.
Can someone please give me some pros and cons for the different concepts or please tell me if my concepts have mistakes.
These are the concepts:
Useage of an embedded web server in my application server.
Pro: I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests. Cons: The customer must decide if an application server is allowed to start their own web server. And I'm not sure if it is a good style to mix the web ui logic with the business logic of the application server
Embedd the business logic with the web ui in a war for a stand alone web server.
Pro: Basic Security stuf like https handling will be done by the web server. Maybe more accepteable for the customer regarding the deployment. I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests.
Cons: The application server has a lot of memory and cpu useage. The is maybe a problem for the web server.
Embedd the web ui in a web server and link it to the application server via socket connection. Pro: strict separation between ui and business logic. The application server must not be changed, because the socket connection between web server and application server can use the existing socket connection for the fat client. Cons: The handling of user sessions must be handled two time. First the web session and second the session to the application server. Furthermore the web server must set up his own storeages for data and must keep them in sync with the storeages in the application server.
My first thougt was to take the first concept because I have every thing in one application.
But my second thougt to use the third concept because of the strict separation and the benefits of a real web server. But here my problem is the handling of two sessions for each user. Or are there better concepts?
Thank you for giving me input!

Your 3rd approach is better. Keeping application server separate will better serve different clients like Java clients, web clients etc.
It will separate 2 different concerns. If there is a UI related issue , then you can bring down the UI server and fix it. But your other Java clients will work fine. Moreover it will be better from development perspective as well.

Creating MySQL db schema using Hibernate with hosting porvider, pros and cons, practices.

Context: I'm working on Spring MVC project and using Hibernate to generate database schema from my classes using annotations. It uses MySQL server running on my local machine. I'm aiming to get hosting and make my website live.
Do I use mySQL server of a hosting provider in that case to run my database?
What are the pros and cons? Would they normally do db backups or its worth to do that myself and store it on my machine?
Am I going to loose data in case of server reboot?
Thanks in advance. I'm new to this, hence feel free to moderate questions if it sounds unreasonable.

Much of this will depend on how you host your site. I would recommend looking into CloudFoundry which is a free Platform as a Service (PAAS) provided by the folks at VMWare. If your using Spring to setup hibernate, Cloudfoundry can automatically hook your application into a MySql service it provides.
In any case, your database will most likely reside on the hosts server, unless you establish a static ip for your machine and expose the database services. At that point, you might as well host your own site.
Where the data will be stored depends on the type of host. For instance if you use a PAAS, they will choose the location they store your database on the server. It will be transparent to you. If you go with a dedicated server, you will most likely have to install your database software.
Most databases supporting websites should provide persistent storage or be configured to do so. I'm not sure why your MySql database loses data after you restart, but out of the box it should not do so. If your using hibernate to autogenerate your DDL, I could see the data being blown away at each restart. You would want to move away from this configuration.

1 Do I use mySQL server of a hosting provider in that case to run my database?
Yes. In your application you only change the JDBC connection URL and credentials.
There are other details about the level of service that you want for the database: security, backup, up time. But that depends on your hosting provider and your application needs.
2 Is it stored somewhere on the server?
Depends on how your hosting provider hosts the database. The usual approach is to have the web server in one machine and the database in another machine inside the VPN.
From the Hibernate configuration perspective, is just changing the JDBC url. But there are other quality attributes that will be affected by your provider infrastructure, and that depends on the level of service that you contract.
3 Should I declare somehow that data must be stored f.e. in a separate file on server?
Probably not. If your provider gives you a database service, what you choose is the level of service: storage, up-time... they take care of providing the infrastructure. And yes usually they do that using a separate machine for the database.
4 Am I going to loose data in case of server reboot? (As f.e. I do when I restart server on my local machine)
Depends on the kind of hosting that you are using. BTW Why you loose the data on reboot in your local machine? Probably you are re-creating the database each time (check your Hibernate usage). Because the main feature of any database is well... persistent storage :)
If you host your application in a virtual machine and you install MySQL in that VM... yes you are going to loose data on reboot. Because in this kind of hosting (like Amazon EC2) you host a VM for CPU execution, and all the disk data is transient. If you want persistent data you have to use a database located in another machine (this is done in this way for architectural reasons, and cloud providers like Amazon gives you also different storage services).
But if the database is provided, no.. a persistent database is the usual level of service that you should expect from a provider.

Query on protecting passwords in property file in java stand alone applications

We are having website which is hosted in real time server
we have developed a swing application through which we are connecting our remote database of our website .This application also provides feature to upload files to our website from the system like picassa software.Now we are planing to place this application in our website so that others can download and use it.
If I do like that others may extract my .exe file to jar file.May see the property file and can get database and ftp client passwords.So how should I provide security for my property file.
How softwares like picassa is protecting their passwords from us.
Please give an idea about these questions so that we can further proceed.
Thanks in advance ,

Does your website with the remote database have an application server that is serving the web content? If not, what is the database for?
If so, you should write a REST service or web service that the Swing application communicates with, so that all database connections are made from the application server to the database, not from your Swing application directly to the database. This has multiple benefits: apart from security, which you have already outlined, there is much less latency between the application server and the database than between your Swing application and the database. Furthermore, it gives you the opportunity to encapsulate business logic on the server and reuse code from your web application, thus extracting it from the Swing application.
Of course, you then need to secure the service itself. To do that, you can use a user authentication system like Spring Security to ensure that only certain users can access your service. This typically takes the form of a login API that establishes an ephemeral session token, and then all subsequent requests to the service supply that token to the service in a header (SOAP header, HTTP header, whatever).
For the FTP requirement, you could do this on the service side as well, although you would be transferring potentially large files to your server just to upload them to an FTP site. Alternatively, if feasible, you could have different usernames and passwords for your different users, and make then enter their credentials before being able to FTP their content. Then there is no shared FTP password and you do not have to worry about exposing it.

cloud ready software

I have my own application server ( like oracle weblogic ) which handles HTTP request.
Now what changes required in my software to make it cloud ready.I was searching on the net and got one multi tenency documents.
what are other aspects in which i need to look into.

None, EC2 should act like any other web server. You still have the added overhead of maintaining the open ports and the like through Amazon's interface as well as on the server itself, but in terms of actually running a web server, it should be exactly the same.
In terms of multi-tenancy, again this is just down to your database architecture which RDS should take care of (if you have a tenancy key).

Web Service vs TCP/IP Sockets (Java) + SQL Connections

We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez

It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.