 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2008Is it bad to connect to a database via an applet?
I was trying to figure out how to connect an applet to a mysql database. I only found very old articles on it. It seems no one does this. So, now I am stuck. I want to write a game in an applet that utilizes a database. I don't want to use Flash and php, which I keep reading folks use. I want use Java. I just don't know the proper design. Do I have a middle page, a servlet, that sits on the server the applet talks to and that middle page talks to the server and selects/updates the database? Thanks. > I was trying to figure out how to connect an applet to a mysql > database. I only found very old articles on it. It seems no one does [quoted text clipped - 4 lines] > the applet talks to and that middle page talks to the server and > selects/updates the database? Yes. It is bad to let the applet talk directly to the database. applet----(HTTP)----web app----(JDBC)----database is better. See my reply to your other post for details. Arne > > I was trying to figure out how to connect an applet to a mysql > > database. I only found very old articles on it. It seems no one does [quoted text clipped - 14 lines] > > Arne Does the same go for using webstart? Any Java application (not just applet) that connects over the Internet? >>> I was trying to figure out how to connect an applet to a mysql >>> database. I only found very old articles on it. It seems no one does [quoted text clipped - 14 lines] > Does the same go for using webstart? Any Java application (not just > applet) that connects over the Internet? Yes. The only half safe way is to have end user specific accounts on the database. And that is not good. And it is still not good to have direct access from the internet to the database server. Arne > >>> I was trying to figure out how to connect an applet to a mysql > >>> database. I only found very old articles on it. It seems no one does [quoted text clipped - 26 lines] > > Arne Is that middleware piece a "servlet"? Arne Vajhøj wrote: >>>> Yes. It is bad to let the applet talk directly to the database. >>>> applet----(HTTP)----web app----(JDBC)----database >>>> is better. >>>> See my reply to your other post for details. > Is that middleware piece a "servlet"? A best practice is to use a layered architecture. Arne illustrated one with three basic layers: front end, middleware logic and back end data system. Refinements of the scheme might split middleware into control logic ("Controller"), presentation logic ("View") and business logic ("Model"), for example. The business logic might communicate to the data system via a connection layer, such as a Java Persistence API (JPA) framework (TopLink, Hibernate, OpenJPA). How many layers you architect, and how thick or thin each one is, depends on the needs of the particular project. Three layers seems the minimum, more than seven would be suspect. The separation of model, view and controller (the "Model-View-Controller" or "MVC" architecture) has many advantages for robustness, correctness, stability, maintainability and expandability. This is a case of the principle of separation of concerns - each layer has a narrow focus of responsibility and clean, simple ways of communication with its nearest neighbor layers (and no others). A Java Enterprise architecture would use JSPs or XHTML pages for the presentation artifacts, quite likely script enhanced. A framework like Java Server Faces (JSF) provides the interface components, also controller and presentation logic components. A custom or framework-provided servlet (or small set of servlets) provides the glue that ties those front-end components to the business logic components. There might be specialized communication libraries to carry messages between layers, such as web-services frameworks or message queues. The business logic comprises Java components variously realized as POJO (likely JavaBean-ish) classes or Enterprise JavaBeans (EJBs), which are not the same as non-Enterprise JavaBeans. They handle things like coordination of authentication, stitching together requested data into meaningful structures and so on. Business logic can represent entities, the nouns of the application domain, or processes, the verbs of the domain. Business logic connects to the data layer, data layer talks to the datastore, oh, oh, dem bones. I just made it sound complex, and it can be if the requirements are big enough. It doesn't need to be. Simple web apps use XHTML/JSPs/JSF/scripting for the front end, a little bit of servlet controlling things, Java objects handling business logic, JPA framework, PostgreSQL or Derby (JavaDB) on the back end and you're good to go.  SignatureLew > A best practice is to use a layered architecture. Arne illustrated one > with three basic layers: front end, middleware logic and back end data [quoted text clipped - 40 lines] > controlling things, Java objects handling business logic, JPA framework, > PostgreSQL or Derby (JavaDB) on the back end and you're good to go. All very correct. If it is for a human interface. An interface for an applet would be different. No XHTML/JSP/JSF. Either a servlet per interaction type. Or a single servlet that forwards to different classes. Anyway it will not be MVC - only 100% M + 0% V + 50% C. Arne > An interface for an applet would be different. No XHTML/JSP/JSF. > > Either a servlet per interaction type. Or a single servlet that > forwards to different classes. > > Anyway it will not be MVC - only 100% M + 0% V + 50% C. I think of applets as subsuming V. MVC can be spiraled fractally. The applet may have an internal MVC structure, and function as the front end in a larger MVC pattern. SignatureLew >> An interface for an applet would be different. No XHTML/JSP/JSF. >> [quoted text clipped - 4 lines] > > I think of applets as subsuming V. Yep. The applet has the 0% M + 100% V + 50% C missing. Arne >> The only half safe way is to have end user specific accounts on the >> database. > Is that middleware piece a "servlet"? I was kinda confused by Arne first comment too, but "user specific accounts" in his second reply makes it plain what he is getting at here. If your applet or JWS program can access a database, so can anyone else. Your database is "bare" on the 'net and anyone at all can connect to it anytime he or she wants. It's a security hole. So, with that in mind: servlets can be one way to implement the protection needed on your server to prevent unauthorized access your database. However, especially in the case of JWS, the answer might even be "probably not" with respect to using servlets as middleware. Certainly it possible to write your own protection layer in Java, deamonize it, and then let it listen for connections and provide the level of security desired. Servlets do have some built-in advantages. The networking code is done for you already. Port 80 is almost always allowed on client system. And SSL provides encryption, which will be necessary for any real form of security. But using servlets should be weight against all other options. It's not a given and definitely not the only choice. Well I hope this was at least partly clear.... > >> The only half safe way is to have end user specific accounts on the > >> database. [quoted text clipped - 25 lines] > > Well I hope this was at least partly clear.... Yes and thank you to everyone. I only need the applet because I need a richer graphical environment than a regular webpage, and I don't want to use Flash, Flex, or Silverlight. I thought about JavaFX, but not sure and the tools are all there yet. Plus I just want to use Java (and associated variations, jsp, etc.) Hi jm, Yes and thank you to everyone. I only need the applet because I need a richer graphical environment than a regular webpage, and I don't want to use Flash, Flex, or Silverlight. I thought about JavaFX, but not sure and the tools are all there yet. Plus I just want to use Java (and associated variations, jsp, etc.) <<<<<<<< Look, this is gonna be one of those really annoying posts that tells you what you explicitly didn't ask for; sorry about that. But for the benefit of others who may read this later and are wondering whether some combination of Java Applets and Flex/Flash may be possible, let me please offer the example (and pointer to source code) below. To me RIA is a broad church; not a case of either/or but rather a case of best tool for the job. (In my example, I found Flex Socket support to be not up to scratch and therefore wanted to stick with my Java Applet for network comms to the DB, but still use Flex for what it's brilliant at!) Cheers Richard Maher PS. Scanning through NASDAQ.COM recently, I see they're starting to do similar things with stock charts no longer being static. (If only Adobe fixed their FABridge example link then NASDAQ may discover the wonders of the FABridge (or external interface direct) rather the Web1.5 "chartHolder.innerHTML=showChart(blah)". PPS. Let me point out a *HUGE* problem with Silverlight. It not only restricts you to Ajax as a datasource; it restricts you to *Microsoft's* version of Ajax! Adobe says "Do whatever you like!". PPPS. Is there not a Socket or BufferedInputStream flag I can toggle that says don't return until "N" bytes or Error? Arne, if you're reading, similar to ucx$c_msg_blockall. No real hardship to loop till full or error, but this is a pretty common TCP/IP stream requirement. PPPPS. Aparently it *doesn't* work on Safari (but does on the same box OS-X, JVM, FlashPlayer with FireFox), if someone knows why please tell me. EXAMPLE: Anyway, here 'tis : - If you'd like to see an example of a browser-based Flex/HTML/Javascript GUI client talking to a VMS 3GL server, please click on: - http://manson.vistech.net/t3$examples/demo_client_flex.html and have a gander. Username: TIER3_DEMO Password: QUEUE You *must* be running: - . The *latest* version of Adobe's Flash Player (Adobe and FlexBuilder generate the code for version checking and auto-download but I left it out of the example for brevity) . JVM 1.4-2 or later (Java 6 has been out for over a year; what's wrong with ya :-) . If you are behind a firewall that disables outgoing connections then you must open up to destination port 5255. . You must have Javascript and Applets enabled for your browser . Apart from that I've tested it with IE6/7 and Firefox and others have it working on Safari and Opera Now, sadly, I was unable to obtain any sort of Rdb Hobbyists license for the Deathrow Cluster so I've had to provide a fudge in that the data is hard-coded in DEMO_UARS.COB :-( But if you want to see what the Rdb code on our machines looks like then peruse: - http://manson.vistech.net/t3$examples/ For all of the source code: - Server: - demo_flex.cob (Cobol server code) build_flex_demo.com (Creates the UAR shareable) demo_flex_sql.sqlmod (SQL you guessed it) Client: - demo_client_flex.html } employee_lookup.html } All the Application-specific html avoidpatent.js } bridgetest.mxml } The Flex driving logic (I can't believe it's that small!) Those who are familiar with demo_client_web.html are already familiar with the example Java classes and CornuCopiae.html. NB: *NO* new Java was created for the new application! Code reuse and modularity set to maximum! Cheers Richard Maher ps. If you'd like to see this on HP's TestDrive Cluster *with* Rdb then tell me (or better still tell your HP rep!) Maybe it's just me, but surely you'd be forgiven for wondering why Oracle/Rdb or HP/VMS would not seize on this opportunity to promote and support their wares? pps. If you haven't worked it out yet :-) hover over the pie charts and click for data drill-down. On May 16, 3:22 pm, Mark Space <marksp...@sbc.global.net> wrote: > jmDesktop wrote: > > On May 15, 11:06 pm, Arne Vajhøj <a...@vajhoej.dk> wrote: [quoted text clipped - 28 lines] > > Well I hope this was at least partly clear.... Yes and thank you to everyone. I only need the applet because I need a richer graphical environment than a regular webpage, and I don't want to use Flash, Flex, or Silverlight. I thought about JavaFX, but not sure and the tools are all there yet. Plus I just want to use Java (and associated variations, jsp, etc.) >>>>> I was trying to figure out how to connect an applet to a mysql >>>>> database. I only found very old articles on it. It seems no one does [quoted text clipped - 21 lines] > > Is that middleware piece a "servlet"? That web app can be anything. If it is Java server side, then it will be a servlet (JSP is not suitable). But it could also be a PHP web app or anything else. Arne > I was trying to figure out how to connect an applet to a mysql > database. I only found very old articles on it. It seems no one does [quoted text clipped - 4 lines] > the applet talks to and that middle page talks to the server and > selects/updates the database? Thanks. There is no play in Arnie's advice about not having your client side code talk directly to the DB - there is no way to do that without shooting yourself in the head. The simplest safe way to get the data from the db on the server to your applet on the client is to build a servlet as your middleware. MySQL has an easy to use jdbc driver available here: http://dev.mysql.com/downloads/connector/j/3.1.html Both applet and servlet have built in methods for http communication. Applet and servlet connect via http, servlet and db connect via jdbc and you're good to go. SignatureDave Miller Java Web Hosting at: http://www.cheap-jsp-hosting.com/ > I was trying to figure out how to connect an applet to a mysql > database. I only found very old articles on it. It seems no one does [quoted text clipped - 4 lines] > the applet talks to and that middle page talks to the server and > selects/updates the database? Thanks. Other than the security aspects that have already been addressed, there is another advantage to having a server side servlet sitting between your applet and database. An applet can only talk to the server from which it was loaded which means that your database must sit on your web server. There is no such restriction on a servlet which means you can put/move your database wherever you want it. ... > ...An applet can only talk to the server from which it > was loaded .. Unless it is digitally signed by the developer, and accepted as 'trusted' by the user, then it can do (almost) anything. And to the OP, once you have the other details on the server sorted, I would recommend a JWS based app. over an applet. It will lower maintenance costs. -- Andrew T. PhySci.org > And to the OP, once you have the other details > on the server sorted, I would recommend a JWS > based app. over an applet. It will lower > maintenance costs. Yup. Applets are almost never used anymore. Look into Dojo, AJAX, GWT and JSF too. These are all web app tools, that only run on the server and in the browser. However they are the popular choices now-a-days. >> And to the OP, once you have the other details >> on the server sorted, I would recommend a JWS [quoted text clipped - 4 lines] > and JSF too. These are all web app tools, that only run on the server > and in the browser. However they are the popular choices now-a-days. JWS is not used much either. The fact that Windows does not ship with Java has effectively stopped client side Java. Arne >>> And to the OP, once you have the other details >>> on the server sorted, I would recommend a JWS [quoted text clipped - 10 lines] > The fact that Windows does not ship with Java has effectively > stopped client side Java. The combination of AJAX and JSF looks especially promising, although I haven't yet the skills in either to judge. SignatureLew >>>> And to the OP, once you have the other details >>>> on the server sorted, I would recommend a JWS [quoted text clipped - 13 lines] > The combination of AJAX and JSF looks especially promising, although I > haven't yet the skills in either to judge. It is a very cool combo. Get the smooth AJAX user experience without manually writing JavaScript code. But it is server side Java. The closest to a recent client side Java success is probably GWT that translates Java code to JavaScript. So the developers code in Java and the browsers run JavaScript. That is somewhat client side Java. Arne > ... > [quoted text clipped - 13 lines] > Andrew T. > PhySci.org If something is JWS based. Is that a regular java app, just launched on the client via Java Web Start? > If something is JWS based. Is that a regular java app, just launched > on the client via Java Web Start? I think yes, it's a regular app. If it's not signed, the user still has to say "OK" if the app needs to write the local file system or access the network (aside from the download server), etc. But from the program's point of view it can be a plain old Java program. > > ...I would recommend aJWS > > based app. over an applet. ... > If something is JWS based. Is that a regular java app, just launched > on the client via Java Web Start? JWS apps are usually (J)Frame based, though they can also be a (J)Applet. They are generally launched directly from a link on the web, and are automatically updated when the jar's on the web are (next time the user launches the app.). Yes, they /run/ on the clientside and are rich clients with all the trimmings (including desktop integration, claiming interest in file types, + other things). As far as there being 'no Java' on the client side, I disagree. At least 60%* of machines on the client side would already have Java, perhaps as many as 90%* of gaming or business oriented machines have it. For those that have not got it, Sun devised the deployJava.js script. It is intended to check and install a minimum Java from a web page. And besides - thin clients suck, unless they blow. * Statistics courtesy of Andrew's WAGs. -- Andrew T. PhySci.org > ... >> ...An applet can only talk to the server from which it [quoted text clipped - 12 lines] > Andrew T. > PhySci.org Interesting comment - where do you see the advantage in maintenance costs? SignatureDave Miller Java Web Hosting at: http://www.cheap-jsp-hosting.com/ ... > > And to the OP, once you have the other details > > on the server sorted, I would recommend aJWS > > based app. over an applet. It will lower > > maintenance costs. ... > Interesting comment - where do you see the advantage in maintenance costs? I meant to mention this on my first REply on this thread. Folks - please trim posts! ..now Start here Applets <http://www.google.com/search?as_q=applet&as_sitesearch=bugs.sun.com> 3217 JWS based apps <http://www.google.com/search? as_q=webstart&as_sitesearch=bugs.sun.com> 699 <http://www.google.com/search?as_q=jws&as_sitesearch=bugs.sun.com> 618 <http://www.google.com/search?as_q=jaws&as_sitesearch=bugs.sun.com> 195 All the bugs mentioning JWS add up to somewhat less than the 3217 hits for applets. This number merely reflects my experience with both applets and JWS launched apps or applets. The real problem lies in the wild and wacky interaction of applet/JRE/browser/JS engine (the JavaScript engine is not often relevant - but when it comes into play, it can cause memory leaks and all sorts of trouble). While there was one problem involving IE 7 on Vista that affected both applets and JWS apps *launched using IE*, the JWS apps. generally avoid any 'browser interaction' problems, and never suffer from interference from the JS side of things. -- Andrew T. PhySci.org \ > Applets > <http://www.google.com/search?as_q=applet&as_sitesearch=bugs.sun.com> [quoted text clipped - 26 lines] > Andrew T. > PhySci.org A bugs to maintenance cost ratio? http://ocw.mit.edu/OcwWeb/Mathematics/18-05Spring-2005/CourseHome/ The original post was concerning web delivery of a game. The simplicity or complexity of the game would probably be more meaningful in determining whether to use JWS or an applet. SignatureDave Miller Java Web Hosting at: http://www.cheap-jsp-hosting.com/ bug hits.. > > Applets ... 3217 > > > JWS based apps ... 699 ... > A bugs to maintenance cost ratio? Not really. Or perhaps rather 'that is only the tip of the iceberg'. The devil lay in the details of some of those hits. Follow a few of the applet hits to find things like "..this week in the latest release of Mozilla the entire applet reloads when the user scrolls 'up'". The 'write once, test everywhere' principal hits with a vengeance when it comes to applets, and even after they are released and in production, you had best keep an eye on the bug database for the latest nasty little surprise. > The original post was concerning web delivery of a game. The simplicity > or complexity of the game would probably be more meaningful in > determining whether to use JWS or an applet. JWS can launch applets. A complex applet can be developed as a hybrid. So, either I do not see your point, or if I *do* see your point, I disagree with it. But then, it sounds ..vaguely, like you are trying to convince yourself that it is 'still OK to deploy applets embedded in web pages'. It never was, they are a kludgy mix of thin and rich client, and the deployment situation only gets worse with time, not better. OTOH - If you are really wedded to the idea of embedding applets - don't let me stop you. -- Andrew T. PhySci.org > But then, it sounds ..vaguely, like you are trying to > convince yourself that it is 'still OK to deploy > applets embedded in web pages'. > It never was, they are a kludgy mix of thin and rich > client, and the deployment situation only gets worse > with time, not better. It was and is "OK" to use the technology that works best for s particular situation. http://www.w3.org/TR/html401/struct/objects.html > OTOH - If you are really wedded to the idea of > embedding applets - don't let me stop you. On the contrary, you seem to want to deprecate perfectly workable solutions. If it's the latest and greatest that you seek, lose Applets and JWS and move to Flash. SignatureDave Miller Java Web Hosting at: http://www.cheap-jsp-hosting.com/ > > But then, it sounds ..vaguely, like you are trying to > > convince yourself that it is 'still OK to deploy [quoted text clipped - 7 lines] > > http://www.w3.org/TR/html401/struct/objects.html What is 'some W3C *recommendation*' of HTML elements intended to support? Note that Mozilla based browsers do not even *recognise* the 'object' element*. To get a common element supported by browsers to embed applets, you need to use the (HTML 3.2 based) <applet> element. (Ignoring that horrid, unmaintainable, invalid - according to W3C recommendations - nested object/embed element hat Sun recommended for far too long). * There was bizarre circumstance in which I got one version of a Mozilla browser to recognise the object element, but only if the element lacked any versioning information - and then you may as well use HTML 3.2 and the APPLET** element. ** *Which is just what Sun uses in its deployJava.js., after the scirpt has ensured minimum version is available* So, what exactly was pointing to the W3C HTML definition of an object element supposed to ..prove, exactly? That you know the W3C exists? Hurrah.. > > OTOH - If you are really wedded to the idea of > > embedding applets - don't let me stop you. > > On the contrary, you seem to want to deprecate perfectly workable > solutions. Applets? Live and learn. > If it's the latest and greatest .. Your the first to mention that. JWS has existed since Java 1.2.2, BTW. -- Andrew T. >>> But then, it sounds ..vaguely, like you are trying to >>> convince yourself that it is 'still OK to deploy [quoted text clipped - 49 lines] > -- > Andrew T. operor non nutritor... SignatureDave Miller Java Web Hosting at: http://www.cheap-jsp-hosting.com/ ... > operor non nutritor... "When all else fails - revert to a dead language, and pretend you know what your talking about." -- Andrew T. > Your the first to mention that. JWS has existed > since Java 1.2.2, BTW. JWS runs with Java 1.2.2+. JWS has been bundled with Java 1.4+. JWS was first released (as standalone download) 2 months before Java 1.3.1. Arne > Note that Mozilla based browsers do not even > *recognise* the 'object' element*. To get a [quoted text clipped - 10 lines] > lacked any versioning information - and then you > may as well use HTML 3.2 and the APPLET** element. How many of the tests on: http://www.mozilla.org/quality/browser/front-end/testcases/oji/objecttests.html does your FF fail on ? Arne > > Note that Mozilla based browsers do not even > > *recognise* the 'object' element*. ... > > * There was bizarre circumstance in which I > > got one version of a Mozilla browser to recognise > > the object element, ... > How many of the tests on:http://www.mozilla.org/quality/browser/front-end/testcases/oji/object... > does your FF fail on ? Unfortunately I no longer have access to that version of Mozilla. It was a *long* time ago.. -- Andrew T. PhySci.org >>> Note that Mozilla based browsers do not even >>> *recognise* the 'object' element*. [quoted text clipped - 8 lines] > Unfortunately I no longer have access to that > version of Mozilla. It was a *long* time ago.. I am talking about a standard FF 2. Arne > >>> Note that Mozilla based browsers do not even > >>> *recognise* the 'object' element*. [quoted text clipped - 10 lines] > > I am talking about a standard FF 2. Oh, OK. I am guessing your point is that Mozilla has since added support for the Object element. Since I have no FF immediatley handy, and not enough bandwidth to download even a 5 Meg 'minimalist' version - I'll trust you/them that it now works. When was the decision to support the object element made? -- Andrew T. PhySci.org >>>>> Note that Mozilla based browsers do not even >>>>> *recognise* the 'object' element*. [quoted text clipped - 17 lines] > Meg 'minimalist' version - I'll trust you/them > that it now works. It seemed to work fine for me with a FF 2.0.0.14/Win32 for all the tests. > When was the decision to support the object > element made? I don't know. Arne > I was trying to figure out how to connect an applet to a mysql > database. I only found very old articles on it. It seems no one does [quoted text clipped - 4 lines] > the applet talks to and that middle page talks to the server and > selects/updates the database? Thanks. Apart from statements made by other posters there is an additional thing to consider. Typically many users who reach your applet will be using some kind of proxy that only allows traffic targeted at certain ports like 80/HTTP, 25/SMTP, 110/POP3 etc. Direct database access from your applet will not only be limited to using the same host as the one that served the applet but also to using non-blocked ports. Most proxies will not allow traffic to the port your DBMS flavor prefers to use. On Thu, 15 May 2008 19:22:23 -0700 (PDT), jmDesktop <needin4mation@gmail.com> wrote, quoted or indirectly quoted someone who said : >I was trying to figure out how to connect an applet to a mysql >database. I only found very old articles on it. It seems no one does >this. So, now I am stuck. normally you would do it with a Servlet intermediary that actually does the database calls. Having the Applet do it directly exposes the JDBC API to the wicked. The servlet can also intelligently sift through the information provided by JDBC to keep the traffic to a minimum. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Thu, 15 May 2008 19:22:23 -0700 (PDT), jmDesktop <needin4mation@gmail.com> wrote, quoted or indirectly quoted someone who said : > Do I have a middle page, a servlet, that sits on the server >the applet talks to and that middle page talks to the server and >selects/updates the database? see http://mindprod.com/jgloss/jdbc.html#APPLETS SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.