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

Benefit of Html+applet+servlet+ tomcat ?

 
AhFai Chan
Ranch Hand
Posts: 81
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.

For a transactional system, I am struggling to list the benefits of an architecture like following: browser(html) + applet + servlet + tomcat container (jdbc) + database engines.

Wouldn't it be simpler to just use browser + Java and access databases directly?

This architecture would not work well with Android and SQLite because of its complexity.

Can the architecture gurus share with me their thoughts on this please?
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65339
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Applets? Dead and buried technology.

With regards to the rest of your question, I don't know what you mean by "access the DB directly". Perhaps you could expand on your requirements?
 
AhFai Chan
Ranch Hand
Posts: 81
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:Applets? Dead and buried technology.

With regards to the rest of your question, I don't know what you mean by "access the DB directly". Perhaps you could expand on your requirements?


Thanks for the advice re applets, but what replaced applets in screen design (its been 10+ years since I last did AWT and SWING) ??

The database engine is most likely one of mySQL or Oracle or SQL Server, I am hoping mySQL will handle the transactional volume, it being more affordable.

On the server side, I'll need to use Java to process the result sets returned by stored procedures and to do that, I'll need to execute my stored procedures from within Java. I'll also need to pass paramters from Java to the sprocs.

Also, I'll have to access "text" files from different sources e.g. json, I am worried about encoding, since they are from different sources.

On the Android side, I'll need to push a much smaller result set onto SQLite for rendering and display on Android.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65339
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
AhFai Chan wrote:
Thanks for the advice re applets, but what replaced applets in screen design (its been 10+ years since I last did AWT and SWING) ??

HTML5, JavaScript and CSS.

The database engine is most likely one of mySQL or Oracle or SQL Server, I am hoping mySQL will handle the transactional volume, it being more affordable.

Are you talking massive access? Just about any modern DB will handle high volume, especially if well tuned.

On the server side, I'll need to use Java to process the result sets returned by stored procedures and to do that, I'll need to execute my stored procedures from within Java. I'll also need to pass paramters from Java to the sprocs.

Also, I'll have to access "text" files from different sources e.g. json, I am worried about encoding, since they are from different sources.

On the Android side, I'll need to push a much smaller result set onto SQLite for rendering and display on Android.


OK, none of that sounds like rocket science, what are your concerns?
 
AhFai Chan
Ranch Hand
Posts: 81
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:
AhFai Chan wrote:
Thanks for the advice re applets, but what replaced applets in screen design (its been 10+ years since I last did AWT and SWING) ??

HTML5, JavaScript and CSS.

The database engine is most likely one of mySQL or Oracle or SQL Server, I am hoping mySQL will handle the transactional volume, it being more affordable.

Are you talking massive access? Just about any modern DB will handle high volume, especially if well tuned.

On the server side, I'll need to use Java to process the result sets returned by stored procedures and to do that, I'll need to execute my stored procedures from within Java. I'll also need to pass paramters from Java to the sprocs.

Also, I'll have to access "text" files from different sources e.g. json, I am worried about encoding, since they are from different sources.

On the Android side, I'll need to push a much smaller result set onto SQLite for rendering and display on Android.


OK, none of that sounds like rocket science, what are your concerns?



My concern is choosing the right architecture from the start, you have already pointed out that applets are deprecated and to use HTML5 or JavaScript
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65339
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are you expecting from the server? I've been very successful at using a RESTful API for the server. Would that satisfy your client needs? (and an Android app is considered a client in this scenario).
 
AhFai Chan
Ranch Hand
Posts: 81
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:What are you expecting from the server? I've been very successful at using a RESTful API for the server. Would that satisfy your client needs? (and an Android app is considered a client in this scenario).
.

Thanks for your input, it will take some days before I can come up with a transactional load for the servers
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic