This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Best way to share an applications databse with other apps?

 
Raymond Holguin
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have a few internal apps that we designed (spring/struts/hibernate) and we are going to be developing a centralized type app that will need to pull data from other apps in order to perform analysis or other types of reporting functionality. So my question is what is the best to allow this to happen. I had a couple ideas and i was hoping to get some feedback or maybe new ideas.

1) Web Service type access. So for each of the "external" apps i would build a web service type interface where i can pass queries from the central app and get some sort of XML formatted data in return which i can process.

Pros - adding new queries is just a matter of modifying the web service
Cons - The relationships are very heavy and trying to translate that into XML format would be messy. Granted not all data needs to be represented in the output I still think think this could make reading/writing the XML a pain. Also I always worry about security issues when passing URL strings.

2) Build a JAR access library. So for this one i would basically be taking a subset of one of the external apps (DAO, Domain java classes, hibernate and sprint config files). Then i would add some public access querying methods and package all that into a JAR file. Then this JAR file could be passed to any other app that needed access to that specific data just be calling the public query methods. I would create a JAR file for any app that has data that needs to be shared.

Pros - All the relationships will be intact and easy to access, all i have to do is call the queries and manipulate the returned data objects however i want.
Cons - Anytime the library changes for whatever reason it will need to be recompiled and redeployed to any app that is using it. Possible overkill having to package everything together for each app, maybe making some large JAR files?


My personal preference is #2, i think that will be much easier to work with and I don't foresee the library actually changing that much to make the Con listed a major issue. any thoughts?
 
Justin Yao
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For the first idea, it costs more budget and effort, but it's easy to maintain later.
For the second one, it costs less money and time now, but it will be a nightmare to maintain the jar if the libraries change a lot in future.

According to what you mentioned "I don't foresee the library actually changing that much", I agree with your preference.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic