I am dealing with quite an interesting challenge, we have an integration project that needs to interconnect the "in development" application with legacy applications. We developed a proxy that calls the legacy application from the new application and now we need to test or development against the code of a third company. I order to do that we setup a server with the same setup as the productive server and we will connect the client application to this server for testing purposes.
Application rough involved technologies: Java EE 6, Postgresql, java 7, JPA 2, Hibernate, Jboss 7
My issue is that we need to populate the DB with pseudo-real data. Meaning data that can be generated and is appropriate from the point of view of the application. The data must be somehow real as it reacts to different notifications sent by the legacy applications suite via JMS. The concerns are that it should be simple, quick to implement and somehow to create a mechanism for easy reusage - whenever I need new data, just run it once (maybe with parameters?!) and the magic is done.
Currently I try to find the best approach, I considered the following up to know:
plain SQL script
java application that inserts the needed things in DB
somehow exciting idea - use a scripting language to have the job done (which one - python, groovy)
Any idea, suggestion, question would be more than welcomed.
Maybe you should use DBUnit it has an XLSImporter. So you can maintain your test data in an Excel file.
I order to populate the DB I built a tool on top of the application's public API that creates the needed entities. To make it easier for our customer to add the needed data I exposed appropriate methods as WS that can be called as wanted by the client.
I wrote the application in java, for subjective reasons, even if I consider that a scripting language - I suppose groovy - would've been the best choice.
Related
I am making an inventory management program which has a Swing GUI as front end, with multiple users on LAN sharing a database.
I have successfully made my GUI components and a local DB and run the program as per my requirements on a standalone pc(without networking).
Now, I need some insight as to how to scale my application to a network environment. I have already tried the following and it fails:
Having MSACCESS on one of the computers, I make a connection to the db with DriverManager.getConnection("jdbc:ucanaccess:////COMPUTER-PC/admin/DB.accdb");
All works well, however when 2 users are simultaneously connecting to the database, after certain update queries from both users, the data does not remain consistent. I am stuck here. How to manage the data and maintain consistency.
You're describing a 2-tier architecture (client-db).
In most cases you want to have the business logic, consistency check etc. on the backend and thus a 3-tier architecture (client-backend-db).
You can e.g. use Spring Boot to create a simple backend.
Spring Initializr can get you started e.g. with Spring Web (MVC), Spring Data JPA and H2 Database (if you don't need to use MS Access) module selected.
The downsides are:
you need a server to run the Spring Boot JAR. But you can also run it on the machine currently running MS Access.
you need to think about client-backend communication, e.g. using REST. But there are many samples on the Internet, e.g. using Spring RestTemplate or Spring WebClient.
Your question seems little basic to me .
This book by Martin Fowler is little old but It will give you a solid foundation .
Patterns of Enterprise Application Architecture Hardcover
by Martin Fowler
After one year i have finished the development of my application.
Now when searching the internet i got a new knowledge about the 3tiers applications.
My Application running on 2tier Architecture (Standalone application connecting directly to database server).
My Application Developed using:
- Java SE (Swing).
- MySQL Server as database server.
I want to reconstruct my application to be 3tier application. (Client-Server)
- What technology i have to use?
- What I have to change within my current code?
- The application will run on network, there will be Many concurrent users who will use the application accessing the database (Insert,Update,Delete ... etc).
There are two main approaches. The first involves rewriting the client in HTML/JavaScript with help from one of the many available frameworks (Struts, Spring, Java Server Faces, etc.) Unless you specifically prefer a web application to a Swing application, or your user interface is a very thin layer on top of your business logic, then this is a costly approach.
The second approach involves inserting a server between your user interface and your database. Open source Java-based servers include Jetty, Tomcat, Spring, JBoss/WildFly and GlassFish.
If your code is structured in layers so that the user interface, the business logic and the data access code belong to separate layers, then converting from a two-tier system to a three-tier system should be straightforward once you understand the capabilities of your chosen mid-tier server and how to use them.
The basic technique is:
All user interface/Swing code remains on the client.
All business logic moves to the middle-tier server. The client talks to the business logic using a remote protocol.
All data access code is moved to the server.
Dependency Injection is useful to perform this refactoring step-by-step and also allow you to choose between working in two-tier or three-tier mode if that is needed.
The three main differences between a two-tier and three-tier application are:
Security - there is a new access point into your system. You need to be careful about the access rights it has to the database - do you have one server user that can do everything, or does each user need to use their own connection credentials. You also need to secure the server correctly and be careful not to add security holes in your mid-tier API.
Remote access - some method calls that were previously made within the same process are now made across the network. Server APIs generally need to support less fine-grained operations than local APIs, and the amount of data shipped as arguments and return values may also need to be managed.
The structure of your application becomes more important. The code isn't necessarily very different, but it will need to be organised into different layers.
Java EE is your answer.You could choose a framework like Hibernate/Spring/Struts to build a 3 tier architecture (MVC).You would also need to make a choice for a servlet container.Apache Tomcat should be a good choice.
It would be nice if you could post little more details like complexity , purpose etc. of your application.
I have a project this year. It is about developing a Java application with a database for sharing and validating documents between the manager, secretary and head of finance.
My question is: How to make the database accessible by all, since the application will be installed on computers that I mentioned above, do I have to install it (the database) on these computers? The constraints of consistency and integrity of the database will be violated. The users will not have the same copy after each update!
Is there a possibility (or technology in Java) to put the database on the web and there will be accessible by all, or make it accessible from a computer that I realize as a server (client-server).
I would be grateful for your help or giving links for Tutorials.
How to make the database accessible by all, since the application will be installed on computers that I mentioned above, do I have to install it (the database) on these computers? The constraints of consistency and integrity of the database will be violated. The users will not have the same copy after each update!
Your question suggests that you will need one database on one computer. Let's call it a DB computer. I'd suggest this be a server, that no one from regular staff, such as secretary, manager, etc... can access.
Having one central database will eliminate your worries about integrity violation.
Now, you have two options. You can make a web application that your users will use to interact with your system. This is a more modern approach, since you'll have a 3 tier system:
users will access your application via a browser
the web application itself is stored on an application server, and it is accessing the database
the database is the backend part
The second option is making a desktop application and deploying it to everybody's computer that will use it; and afterwards making it connect to the database for interacting with it.
The first option is easier when you want to expose your application to a large number of users (and to the web), but know what you're doing when doing stuff like this, since you have to take security very seriously.
If you go the first route, you will need a few things:
First, a database. Use what you can, but if you need free and high quality databases, use PostgreSQL or MySQL.
Second, an application server. I suggest using Tomcat or GlassFish.
Now, you need to develop your application using JavaEE. There is a wealth of information about this, so I hope this will help you in the beginning and point you in the right direction.
Note that Tomcat doesn't support Java EE fully, but a subset of it. And this subset is surely more than enough for what you need to accomplish.
If I understand you correctly, you are looking for ways to implement a client-server system, where several clients on distinct computers each connect to a central server (or cluster of servers) hosting a DB. In Java, usually (but not necessarily) the DB is inside a web application, and the clients are lightweight web clients - in this case it is usually called an enterprise application.
Java has a whole dedicated SDK for this, called Java Enterprise Edition. You may find many questions dealing with this on SO, here are a few which I think may be especially helpful:
Is the offical Sun Java EE tutorial the best way to learn how to make Java web apps?
What to learn for making Java web applications in Java EE 6?
We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.
However, we still have a number of short and long term goals:
Pick a technology stack for a new front-end
This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.
Stacks on my list are:
Eclipse RCP, Netbeans RCP
Flex/Flash, Silverlight, JavaFX
Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
Java-based Web frameworks (Wicket, JSF, ...)
Find a way of making the current application perform acceptably in a remote situation
We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.
To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.
As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.
If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.
Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.
Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.
We've just gone through a very similar evaluation process as we're migrating a legacy application.
For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.
In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.
As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.
If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)
Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.
The reasons I like this approach, you're already migrating code into Java middle tier, so
Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
Already have Java expertise, can be leveraged with DWR
Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)
I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.
I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.
We are occasionally in a position to take over PHP based projects, but as we are a Java-house we are searching for ways to turn a PHP-project (or codebase) into a Java-project.
The approaches we came up to work in a mixed Java/PHP context are :
PHP in frontend and Java in backend with separate front (PHP+JavaScript) and back (Java+SQL) teams
using both technologies in a Java webapp, for example via Quercus with one or multiple teams
migrating everything to Java
We haven't tried any of these approaches as we've been lucky enough to have enough Java-only projects to work on.
Do you see other approaches, or have you tried any of the described approaches?
I've used Quercus. I think that if it supports something like Drupal then it's probably fairly mature. If your PHP app works out of the box, then it offers you a very gradual upgrade path to Java since you can write your own plugins in Java and expose them to the PHP layer, such as using a JDBC back-end.
How easy it is all depends on how well separated the layers are in the PHP application. For example, if the view layer is well separated, you might be able to replace both controller and model logic with a Spring MVC application that uses a 'QuercusView' for the view - you may be able to re-use a lot of the PHP view logic.
You should also consider how you can make a survey of the PHP code - maybe a script that extracts all the function calls, imports etc. so you can quickly test the Quercus support for them.
Sorry, I haven't used the PHP-Java bridge, but I think the Quercus library is pretty mature these days, so that would be my first choice for a staged migration.
My experiences with Querces are not so good. Maybe it has improved, but when I tried it something like two years ago (a long time, I know) it was far from complete and did not support all functions yet. Also, if your application is using some extensions (e.g. from PECL) you will experience difficulties getting this up and running under Querces.
We're currently in the process of migrating a web application from PHP to Java. We're designing a SOA and we'll probably replace some data access objects in the PHP application with a version that talks to internal webservices. Currently we're using Thrift as protocol for our internal webservices, a framework that also has a client available for PHP. We expect this to increase flexibility during migration (allowing us to do step-by-step migration, rather than all-at-once)
PHP/Java Bridge may be of your interest:
The PHP/Java Bridge is an
implementation of a streaming,
XML-based network protocol, which can
be used to connect a native script
engine, for example PHP, Scheme or
Python, with a Java virtual machine.
It is up to 50 times faster than local
RPC via SOAP, requires less resources
on the web-server side. It is faster
and more reliable than direct
communication via the Java Native
Interface, and it requires no
additional components to invoke Java
procedures from PHP or PHP procedures
from Java.
NUMITON may be useful for you:
http://java.dzone.com/announcements/automated-translations-php-jav
The shortest route from PHP to Java
Numiton offers an automated alternative to migrating PHP codebase. This way,
established applications can benefit from the advantages offered by Java in its
enterprise-level capacity.
Some of the risks inherent to any software migration are avoided by using an automated
translation tool. Our PHPtoJava product performs variable type inference,
objectualization and other operations in a uniform manner, the resulting appearance and
behavior being identical to what the users already know.
Of course, the human factor still plays an important role in the post-translation
phases: application fine-tuning and functional testing. The speed and accuracy of the
entire process surpass however those of a manual translation.
One of the applications we have migrated this way is the well-known forum engine
phpBB. The translation result, nBB2, powers our own forum and was recently donated to the
open-source community as a SourceForge project.
PHP in frontend and Java in backend
with separate front (PHP+JavaScript)
and back (Java+SQL) teams
This is technically feasible using SOAP.
using both technologies in a Java
webapp, for example via Quercus with
one or multiple teams
I have no idea about this
migrating everything to Java
This is better option, but it will take time depending on the size & complexity of your project.
I do not have any experience running PHP inside a JVM, but I am betting that IBM does. :)
You might consider Project Zero.
http://www.projectzero.org/php/
Seems similar to Querces or that other thing someone linked. The only other thing that you didn't mention that I can think of is to refactor the PHP code because I'm assuming that its an older codebase written in a PHP 4 manner.
I know this is 2 years old question but i still want to contribute. We are migrating from full java portal to php+java. We have 14 million users. This design doesn't need web services because we use java as json provider for php and js. We will see the result soon...
PHP in frontend and Java in backend with separate front
(PHP+JavaScript) and back (Java+SQL) teams