I've got a simple problem... I've got an Java applet running on my client machine which needs to communicate with a database at my end. I'm not sure how I go about it. There are numerous problems such as untrusted applet coming up. Please point me in the right direction.
Thanks in advance.
You don't want to give an applet direct access to your database, rather you want a layer of business logic in between to prevent abuse. This is known as an multitier, (aka n-tier) system. Most web apps are designed in 3 tiers:
Presentation (in your case the Java applet)
Logic (business logic handling authentication, authorization, request validation, detailed processing, etc)
Data (your trusty database)
Java applets can communicate with your server in many ways, but you'll find it easier to deal strictly with HTTP requests returning simple data structures (like JSON or simple XML, SOAP was designed to be simple but is often accepted to be anything but). This way clients can easily get through firewalls, and if you redesign your front end using flash or html5 in the future, you're back end won't need to change as much.
You'll need to decide what makes most sense for your Logic tier, as there are many options in many languages. To be consistent in language, Java servlets running on a web server (e.g. Tomcat) can provide your logic layer, and there are many tools (e.g. Spring and Guice as a framework, Hibernate and MyBatis for ORM) to make writing and maintaining servlets easier - each with their own learning curve that you'll need to decide if it has value to you.
Also don't forget to search here on StackOverflow for more explanation and alternatives - this is hardly a comprehensive answer, but hopefully a pointer in the right direction.
Related
I dont know if this question belongs to this site but, I have the following doubt, these last days I saw a lot of job proposals, that consist in Java and Flex, I dont know a thing about Java, but I wonder, is Java used for backend only? (replacing PHP i.e), or it could be used in combination with Flex in the client side?
Thanks.
We have created a fairly large application that uses Java in the server side (with most of the complicated business logic, database handling, etc...) and the client side is written in Flex.
The client side (Flex part) of the application is for presentation-only and we hardly try to keep all the business logic on the server (Java) side. Some of the reasons are:
Knowledge - where I work we are more Java developers more than Flex developers, and Java is something we handle and know better. It is faster and more secure for us to write something in Java than in Flex;
Security - keeping your business logic (and things as security, etc...) on the Java side of things will prevent someone from replacing your Flex client with some custom, malicious code and gaining access to your system when they are not supposed to.
To handle the communication between the server and the client, we use Blaze DS. It is not perfect but it is pretty good, and you can customize it to fit your needs. We have customized it so that it would accept enums, and so that we would automatically evaluate if a user was logged-in or not before invoking a Flex service on the Java side.
With Blaze DS, you can make a Java method call from the Flex side (in rough terms). Blaze DS will find the appropriate service handler for the method call you are making, and will make any data type conversions as required. Some configuration is required but once you get past the basics, it is pretty easy.
We want to write a UI that consists of HTML, Javascript (JQuery) and CSS. Although the initial starting point will be served up by a web server, there won't be any sever side templating. The browser will interact with the server via a restful interface and render its UI.
What are the risks of this approach?
Ideally I'd like a nice, straightforward javascript OO api which underneath makes http calls to the server to get JSON representations of resources. Any suggestions as to how this could be structured?
Anyone have experience with browser side templating?
Is there a framework to make this style of development easier?
We will also be defining the server side resources and my thoughts are to follow ruby on rails conventions. For example, if you define a Users resource in routes.rb, you have 7 uri templates. Any thoughts?
By the way, the server side functionality will be developed in java.
I have plenty of experience with this approach. I can guarantee you that it works - how well in the long run, I don't know yet but I'm extremely happy with it (as a developer).
You do need to make sure that you've mastered Javascript. Read up on the state of the art, at least check Douglas Crockford's work, and most notably JSLint.
As for frameworks, this is where your vision comes in. We've built one from scratch because we need a combination of tools that existing frameworks don't and because we think we have the vision and expertise to carry it through. You have to compare the pro's and con's. If you use an existing framework you have very little control over it's direction or the speed at which bugs are found and fixed. If you build one yourself you could run the risk of making wrong decisions and ending up with a framework that doesn't quite work.
I have noticed that in our applications the custom server side code is only very small. This means the importance of the backend is only very small (validation, sanity, authorization). We use PHP, but simply because we have loads of experience with PHP.
There are definitely risks. In the startup and early transition I have noticed that 'lesser' programmers have trouble catching up. There is a very steep learning curve for anyone not too familiar with Javascript and it's many elegances.
Another risk is performance. We're advising our customers to use Google Chrome, simply because
And then there is compatibility. The idea of a framework is that it's able to hide this complexity. Luckily browsers are increasing in-tune in accordance to standards but backwards compatibility with (for instance) IE6 is incredibly difficult.
I would advise against using jQuery. I find jQuery more of a 'plugin' than an actual framework. jQuery really shines when you have a website and you want to sprinkle on some fanciness. It has some very good general tools (DOM manipulation and all that) but it's very lacking in the business-modeling area.
I would also advise against an OO approach. For some very small number of domains OO is the perfect solution. For most businesses, it's not. And Javascript is capable of so much more than just OO.
The #1 problem (and, perhaps, the only problem) is search engine. It is not sure how well will your content be recognized/crawalble/searchable. The underyling cause is that the search engine is not necessarily going to understand your content (since it is only revealed once Javascript gets executed).
Other than that, it is a great approach. I tried it several times and it works great (assuming you're not intimidated by Javascript). The resulting web-site is usually much more responsive than traditional web-sites since the server -> client traffic is quite small - only the raw data is transmitted. All the UI stuff is generated, by Javascript, on the client side.
Dear Stack Overflow Community,
I am a Java programmer in front of a task of building a complex, data-driven, web application (SaaS) and I'm searching for technologies to use. I have already made some decisions and I believe I'm proficient enough to build the appliaction using just the technologies I have decided for (I'm definitely not saying it would be perfect, just that it would be working). However, I'd like to make my task easier and that's why I need your help.
Brief description of the project
Back-end
The application will be heavily data-driven, meaning that everything will be stored in a self-descripting database. This means the database itself will be entirely described with metadata and the application will not know what data it reads and writes. There won't probably be any regular entities (in terms of JPA #Entity) because the application won't know the structure of the data; it will obtain it from the metadata. Only the metadata will have a pre-determined structure. To put it simply, the metadata is the alpha-omega of the application because it will tell the application WHEN and WHAT to display and HOW to display it.
The application will probably utilize stored procedures to perform some low-level tasks on the data, such as automatical auditing, logging and translating to user's language, thus most likely eliminating any possibility to use ORM frameworks because there won't be just simple CRUD operations. Therefore, JDBC seems like my only option (doesn't it?).
Front-end
The UI will be "dumb" in terms that it will not know what data it is displaying (to some extent, of course). It will just know how to display it based on the metadata which it will obtain from the database. All UI controls (like menu items, buttons, etc) will be created based on current application's state and the UI will NOT know what the controls do. This means that clicking a menu item or a button will just send an identifier of associated action to the back-end and the server will decide what to do.
My goals
My main goal is to have the application as lightweight as possible with as least dependencies as possible. Because the application will be very complex, I'd like to avoid any heavy framework(s) because there is a very high probability that I'd need to customize a lot of its functionality.
What I have already decided for
Please object to the following decisions only if you think they're absolutely non-viable for my application, as I have already implemented some core functionality using these technologies:
Servlets on Tomcat, Guice DI, AOP (AspectJ)
I believe all of these technologies are lightweight enough and I don't need to learn J2EE.
GWT with GIN-jection on the front-end
Seems like the best option for me because I'm very familiar with Java and Swing and don't want to write any Javascript, PHP or learn a new language. GIN is a little brother of Guice and I will be using the same syntax and principles on both the client and server.
MSSQL RDBMS
This is actually a requirement from company management as I'd much rather like to go with an open-source solution. Too bad for me..
Maven 2
I think no-one can object to this :)
What I need help with
DB communication
I think that ORM is ruled out (is it?) so I need to use JDBC. Do you think Spring JDBC is lightweight and flexible enough for my use? I would often need to "blindly" read data from database, mapping it to some generic entity (because I won't assume any pre-determined structure), and then send the data using some generic DTO to the client along with the metadata telling it what data it is and how to display it. Or do you know any alternatives? Or should I do this myself?
Client/Server communication
GWT and its GWT-RPC mechanism seems not very suited for sending the generic data I need. Although I'm convinced that it's doable using GWT-RPC, are there any alternatives? But I definitely want to use GWT.
Security
Do you know any security libraries / frameworks that would help me? I'm aware of the existence of Spring-security; do you think it's flexible enough for my use or I'd be better off implementing that myself? Also, is Spring's IoC an integral part of the Spring framework, or would I be able to continue to use Guice?
Anything else that you think might be useful?
I really appreciate any advice and suggestions because I wouldn't dare to try to make such decisions myself. Please ask me if you need more information.
Thank you in advance!
eQui
I think you are over-engineering the solution. Take a look at
http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx
If everything is driven by the DB, you are going to have immense difficulty making things happen in the UI, and you aren't going to be able to use many of the tools that make UI development easier.
I also suggest you take a look at Spring Roo, if your application is mainly just updating data in a database.
UI framework and implications for client/server communication
You say that any UI action will triger the backend (and potentially the DB). This mean that UI interraction will be somewhat slow anyway, and more than that will require a round trip to the server.
GWT is especially suited to avoid as much as possible round trips to the server and do all UI work on client side. In this model, only information that will transit from client to server is real data, and not UI metadata. GWT will do the job, but you'll be using a somewhat low level tool, needed for advenced optimisation you'll be unable to perform anyway...
Framework like ZK or Vaadin seems more suited to what you want to do. The client side has nice widgets with a rich UI, but you manipulate the UI from the server side. The framework manage client/server communication for you (no need of REST, RPC or javascript). The main limitation of theses framework is scalability, with all theses chatty round trip. But because your requirement impose that chatty behaviour anyway, you could really benefit from the abstraction they provide, are they are at not cost in your case.
I have tried both GWT and Zk to do some proof of concept for my company. We ended choosing GWT, because of it's hability to be embedded nicelly into any existing UI and to fine tune what you do... In particular avoid as much as possible rountrip to server. But ZK is really easier and faster in term of developmeent hours.
The side effect is that would totally solve your client/server communication concern, leting the framework performing it in an optimized way (Zk is able to intelligently regroup several UI event before sending them to server).
DB and ORM
For DB design, i tend to think that using fine granularity things in DB will make it very very slow. If each widget is one or several rows in the database you'll have to perform many lookup to perform the simpliest thing.
Problem is if your UI is just a little complex with a few dozen of elements (a few button, checkboxes, labels and widgets), compositing a screen will require lot of requests to the DB. Rendering just one page might be very slow and scalability would be very very bad.
I know this because i worked on somewhat generic bug tracking system with similar (but simpler) requirements than yours and we had exactly this problem.
So i would try to describe UI in some templating or XML format. Maybe you'll not show this data to the user, providing it with a nice abstraction, but instead of performning many queries for just one screen, you'll save the whole screen as one blob.
A really dumb and basic implementation of this would be to store HTML/CSS/PNG file in your DB and load it as needed, with user being responsible for making theses HTML file by hand. Of course this would be terrible for the user. That's why you need a nice and fancy editor UI editor that would work on an intermediary format of your own. Another dumb implementation would be some sort of wiki templating. This is not what you need, you need more. But you have the idea, I would seek in that direction...
For the maintenance and debugging too, this would be far easier to the whole UI description to a few file, to understand what is really implemented than to read lot of tabuled data in your prefered SQL editor. Users would have they export/import format to easily version, backup or experiment.
Security
I would say by hand... Because you have a generic UI generated by user it seem likely that the security will be generic too and dependant of database content.
Hope it help...
For the backend, i implemented a program which had a similar interaction with the database. the code was database structure oblivious, instead, it read a config file describing the db and could construct complex sql queries based on this information. most of the code is proprietary, but one bit of it got pushed into an open source project called sqlbuilder. may be useful to you on the backend.
I think you're on the right track, with your tool seclection. Your 100% data driven model is going to be hard to maintain. But I understand that's a requirement not an option. Normal source control is going to fail you becuase of the ui application logic all being in the meta-data. You'll need some good test databases and some way to maintain them, such as regularily mysqldump them out and check them in to souce code control to handle all the differences, etc..
You're wise to stay away from various ORM solutions and just use JDBC for this type of app.
Let me give you some warnings about GWT. On the surface it will abstract all the uglyness of html, javascript away and give you clean heirarchy's BUT...
1) If the abstraction fails you how do you easily debug?
2) Do you want any of your site to be visible to Google or other search engines, if yes GWT is not for you
3) Do you want to use any HTML5 technogies or do you want to be stuck in IE 5 compatability mode?
So...
I think you'll be much better off Implementing the UI as simple HTML controls with a small set of jQuery ajax interactions with the server. You can define an input type in your database, your serverlet can generate an input tag and then you have two options you can have some standard event bindings in jquery to tell your server that button1. is clicked, or that select2 has changed, etc.
Your server can send back javascript to change the state of the ui - simply load the javascript inside a div so it runs on the client. or 2) You let the input submit the data to the server and do an old school page refesh and the servlet build the next ui screen based on the database.
Building an interface dynamically in HTML from a database is easy and straight foward compared to doing the same in SWING or Windows Forms. You just have to write out a big text string, been doing that since 1999.
That approach is going to be much more lightweight - simpler to debug, understand and modify in the long run than going with the "GWT automatically compiles to unreadable javascript that doesn't run in my browser for some unknown reason" solution.
As a concluding assignment for the technologies taught in a data management course, we have to write a web application using the technologies taught throughout the course, this mostly includes xhtml, css, JSP, servelets, JDBC, AJAX, webservices. the project will eventually be deployed using tomcat. we are given the option of choosing the technologies that we see fit. since this is my first time developing a web application I am having some uncertainties about where to start, so for example now I am writing the object classes that will be used in the database and implementing the operations that will be performed on the database, but I am not sure about how to make these operations available to a client through the website, I mean I think I have to write a servlet through which I can extract the request parameters and set the response accordingly, but I would still like a more specific overview of what I am going to do, so if someone can link me to a tutorial with an example that makes use of these technologies while illustrating the stages of the design so that I can see how all these things are linked together in a web project.
thanks
Java Enterprise applications typically use a layered architecture as illustrated below:
In short:
The presentation layer provides the application's user interface. In a web application, this typically involves the use of a MVC (Model-View-Controller) framework.
The service layer exposes coarse grained services implementing the business logic of an application. They act as entry point and are typically responsible of transaction demarcation.
The data access layer abstract physical storage systems (e.g. a database) and expose CRUD (Create, Read, Update, Delete) methods and finders.
Domain objects represent the business concepts of your domain (Client, Order, Product, etc) and are typically used across all layers, from the data access layer to the presentation).
I don't want to make things too confusing and to throw in too much technologies or frameworks (are you allowed to use frameworks?) that could fit in this diagram. Just tell me if I should.
Regarding your question about the presentation layer, I already hinted the answer: use the MVC pattern.
Basically, the View is the part that renders the user interface (e.g. JSP). From the view, the user sends input to a controller (a Servlet acting as entry point). The controller communicates and interacts with the model (standard Java classes), set appropriate data in the HTTP request or Session and forwards the request and response to a view. And this restarts the cycle.
If you need more details, let me know.
Baby steps are needed. Get something running and then expand on it.
Start with this tutorial, get it running and then start asking questions http://www.eclipse.org/webtools/community/tutorials/BuildJ2EEWebApp/BuildJ2EEWebApp.html
This will give you a Servlet and a JSP running on Tomcat from Eclipse. From there you can expand.
Sun documentation is pretty good: The Java EE 6 Tutorial, Volume I.
There is also a working sample application released by the Java BluePrints program at Sun called the Pet Store Demo.
I have also put together a string of tutorials aimed at beginners who are wanting to learn how to build Java web applications (within the Eclipse environment). I have tried to keep it as simple as possible.
Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?
Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (for example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?
Thank you in advance.
Denis.
If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)
Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.
If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.
I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.
For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.
There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.
Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.
For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.