This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
In the past I've created more-or-less boilerplate web apps using seam-gen and then did some basic enhancement. I did not have to figure out how to structure the project. I am not a well-eduated developer (former sys admin and mostly self-taught) and there are some gaps in my knowledge.
I now want to create a simple batch job in java that would use a specific vendor API to get data from a proprietary database and plop it into mysql so the general public has access to it. How do I structure and run it? I have this idea to use EJB3 entity beans as an interface to the database, but I have no idea how to incorporate it into a simple project like this or even if it is possible to use it in this context.
Hope I've provided enough information. I can't figure out how to get started.
I think for an application as simple as this you might want to avoid any frameworks. It seems to me you need the following small code areas:
1. MySQL Connectivity.
2. Proprietary API Connectivity.
3. Central Logic.
In number 1 you implement code (could be just a class) which configures access to the MySQL database and provides the ability to interact with it (you'll need a JDBC Driver and some SQL).
Number 2 will provide connectivity to the proprietary API and the ability to interact with it to extract the data (you'll need whatever the API is and write some methods which invoke its methods to get what you need).
Number 3 will provide the intermediary logic, calling number 2 to get the data and number 1 to store it in MySQL.
The reason why I think "EJB" is that I want to use an ORM framework to interface with database tables.
I was originally going write this script in perl and using the RoseDB ORM framework makes putting the data into the database SO much easier than using SQL queries. Is that not also true in Java? I assumed it would be, but maybe not. I think my head is stuck in the perl paradigm and I'm missing something fundamental about the java paradigm. I don't know.
I don't understand why EJB is more appropriate for a web application than a batch job. Isn't the bottom line that you use EJB when you want to solve the problem of classes interfacing with database tables?
Hope someone has more to add, because I'm still confused.
Oh got it. Just plain POJOs with Hibernate.
That makes sense.
(I think I was conflating hibernate with ejb)
Joined: Mar 24, 2005
ORM is not a silver bullet - it does have cost - complexity, understanding its implications and nuances, creating all the mappings, etc. It is definitely worth the while if it helps reduce the complexity elsewhere. But for a small project, especially what sounds like a one-of type of thing (I assume you will port the data once from the proprietary database into MySQL and that's it), you will end up creating a lot of unnecessary classes, annotations and/or xml files, deal with all kinds of ORM related issues, etc. just to avoid writing some INSERT statements.
In fact, I think your original sentiment about using PERL may well be correct. If you're not going to reuse this thing much, and want just a straight data port, you're probably better off with a script than using Java.
Joined: Jun 22, 2009
Once this script is written it will be run daily, but a script _like it_ will not have to written again.
The thought of writing those mapping files is a bit daunting as there are relationships that have to be maintained etc.
Still trying to figure out what to do -- I may use hibernate anyway just for the experience.
Joined: Jun 22, 2009
Here's what I ended up learning and doing.
1) I learned that you don't need hbm.xml files to use hibernate -- that was a relief. You can use the hibernate annotations on a pojo to map a class and its attributes to a table and its columns. Because I had never used plain hibernate before, I had confused hibernate with EJB. (I guess I'm still mystified as to what EJB adds or even is, but that's another discussion).