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.
Related
We're designing two distinct systems which can be simulated by the following typical example.
Web App #1 - Course catalog (allows updating / populating the course catalog)
Professors
Course (courseCode, professorId, list of Prerequisites, grade scale used)
Prerequisites (courseCode and minimum grade required)
GradeScale (i.e. A-F, 1-100, pass/fail)
Web App #2 - Student catalog (handles students registering for new courses, seeing their transcript, etc)
Student
Transcript (what courses did they take and what final grade)
Data that needs to pass between the two systems (there will be more calls and stuff that needs to be handed back and forth, but this gives the idea that it's a 2-way flow of questions and answers):
Does a student have the pre-reqs needed to take a particular course?
Pulling details from the course catalog to create a full transcript
From reading, it seems our options are:
Create EJBs for the underlying data model, then have the web applications use the EJB interface.
Use a REST or Web Service interface between the two applications.
RMI or other Java remoting?
Which way would you cut this up into JARs/WARs/EARs?
This was initially a comment but it's actually too long.
If you got only simple imperative services (set this, do that, is this valid?), then you can go for an AXIS2/SOAP based web services solution. (you probably won't need the whole bloat of SpringWS). If the app logic is not too twisted, I'd follow KISS principle.
I don't know your system scenario, but if you're using a full fledge RDBMS, it's high probable that the database will reside on its own machine, thus having different pools connecting to it, is not much of a burden. (if you're using a local db on each AS, you're probably going to face some scalability problems later on).
In modern Java EE app servers you can actually use connection pools of one server from another (via jnp:// urls), it's just a matter of JNDI lookup.
If the db engine supports it, oracle alike db links are also a good way to share a database between apps.
You can spare code times by having a business/data layer in a simple java project with all the ORM stuffs, shared across the 2 web dinamic projects, so eventual changes in business logic will reflect onto both apps.
You can also tryout the mixed way (simple imperative Web Services and database share), it really depends on what messages are exchanged between the two applications. You can provide a layer of web services API (SOAP or jsonp based), but take into account execution time of the web service itself (it's not so good to have time consuming ws).
Web Services and EJB are good and probably can do what you need, the real question is: do you really need them ? lately I've seen lots of project starting with the full REST thing, and in many cases it was like killing flies with a bazooka.
If the requirements are simple, then keep it simple.
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.
I'm currently in the research phase for a (very) small database application.
It's for a local charity which only has 3 or 4 client machines which will be running the system - however in order to move some extraneous logic away from the clients, I'm leaning toward using a three-tier architecture (there is data that is constantly read-through and updated when appropriate, that the client does not need to know about)
i.e. Client <-> Server logic <-> Database
Whilst I'm competent with Java itself and a few frameworks/libraries, I'm not particularly familiar with what frameworks could help me here. Obviously I'll be using JDBC for the database half, but the communication between client and server is the stumbling block at the moment - I don't really want to go anywhere near raw sockets, for example (overkill, or at least, another solution must exist)
I've asked a few developers I know about their opinions on what APIs to use, and whilst they've been very helpful, I'm still not too sure where to go. So far I've heard about RESTful stuff, SOAP, COBRA and a whole bunch of other technologies. SOAP is the main one that caught my attention (as there are some good examples of using it with normal applications rather than just with the web) but I'm still not sure where to go - it doesn't seem particularly appropriate for a general purpose app like this one (EJB also popped up but I heard a lot of hatred aimed at it - is this deserved?)
It feels as if in order to find out the 'best tool for the job' I actually need to learn each one in its entirety to 'get' them (which is obviously impractical)
Can anyone give me guidance as to how to choose APIs like these (when I haven't used them before) or give me information about a few common ones, or is it really just a case of experimenting with lots of them to see which fits best?
Or maybe I've totally missed the mark and there's a framework which is aimed at this exact situation with no obvious cons?
Thanks very much for any help.
EDIT:
Completely forgot to mention what it actually does: It isn't terribly complex - the charity runs a transport scheme, so it holds details of drivers, clients, driver mileage records etc. for viewing and editing The only real complexity comes with the drives, since drivers can be assigned to repeating (ongoing) drives that could foreseeably continue 'forever'. But each instance of an ongoing drive must be unique because they can be cancelled or edited individually
The main reason I'm angling for 3-tier is because being a charity (with many older volunteer computer users who aren't terribly 'savvy') I may well be updating the UI quite frequently to iron out bugs and bits that aren't very clear to novice users. So my plan is to get the backend between the server and DB absolutely 'bulletproof' first of all, and then pour all my focus onto the UI so I can continue to develop and iterate it without worrying about the backend (also since I will be developing pieces of it remotely, focusing updates on client side is slightly simpler)
All these attributes probably shout out 'do a web based system' - the snag here is that they're after all kinds of tricky integration with some applications they already run, which I'm not confident I can get done (properly) with a web app.
For the server itself, you'll need some sort of JavaEE server.
Common implementations here are GlassFish (the reference implementation) and Apache Tomcat... assuming you don't need anything more advanced than a Servlet container. Chances are you won't if you're just using web services.
For the client, I assume you're going to have a GUI application, presumably that uses Swing or SWF. You could also opt to make a web application, since you're already going to have a web server involved.
For client to server communications, you could use a JAX-WS (SOAP web services) or JAX-RS (RESTful services) implementation.
JAX-WS implementations include Sun's Metro (which ships as part of Java 6 SE) or Apache CXF.
JAX-RS implementations include Jersey and Apache CXF.
As for the database layer, JDBC isn't your only choice. Java also has the Java Persistence API (JPA, currently at version 2.0).
JPA is usually used in J2EE apps (web apps specifically) to simplify the Database layer. Common implementations are EclipseLink JPA (obsoletes Oracle TopLink) and Hibernate's Annotations.
All of these are based on various standards that make up JavaEE: Servlet 2.5, JAX-WS 2.0, JAX-RS 1.1, and JPA 2.0.
EJB also popped up but I heard a lot
of hatred aimed at it - is this
deserved?
It was fully deserved with versions 1 and 2 of the EJB spec. But EJB v3 represents a huge simplification that makes them outright pleasant to use. I can actually in good conscience recommend using entity beans instead of manual JDBC.
As for communications protocol, exposing EJBs as REST or SOAP services is absurdly simple in the newest EJB 3.1 spec - all it takes is adding a few annotations and you're set!
To preface I am new to web development. I am looking at creating a core set of RESTful web services around a valuable document library of sorts (initial CRUD abilities). In doing so I am theoretically creating a perfectly re-usable and scalable back-end to be used by unanticipated applications in the future.
My question centers around the best practice for doing this. My initial requirement has me also creating a unique front end. Would I make the front end and back end completely separate projects to enhance the re-usability. It would increase overhead.
Looking at using GWT, Restlet, and the Java EE technology stack if this influences the setup at all.
Most important is design a clean Java API - independent of REST, RMI, or whatever protocol you want to use. From a clean Java API, you can support any access method.
Unless you have a use case for these other access methods, don't build them now. You can build it when you need it.
The easiest interface to add initially is a web based interface where your web app runs in the same JVM as your core API. I'd do this if this works for your use case. Building a separate console application that accesses your core API via a REST (or whatever) protocol is a lot more work..
Martin Fowler wrote a very nice article about the basics of REST short time ago: Richardson Maturity Model. Found it very helpful to understand the principles of REST.
If you want to use REST based backend services, you should use the RestyGWT project which allows you you to use a GWT-RPC programing style to access your JSON based restful services.
The nice thing about using REST based JSON services over traditional GWT-RPC services is that those services can then be used by other clients or even in mashups more easily.
You may want to consider using GWT-RPC instead of REST if you know you're going to be using GWT for the frontend. More discussion here.
However, if you think you might want to eventually expose your data via a REST API, or use a different technology on the frontend, REST may be a better choice.
The gwt-rest project may also be helpful.
A colleague and I have written a GWT system using separate projects for front and back ends. It has been helpful to keep things quite clear about where the code is executing. But I'm not sure that I would bother separating things in a future system.
Also, given you're new to web development, I don't think you should be expecting to make a perfectly re-usable backend. You will learn lots of things as you go. I think that agile coders would recommend an iterative approach of (a) getting a small aspect working, and then (b) refactoring it to make it beautiful.
I have a project in which my client is asking me to use portlets 1.0 spec and Websphere Portal Server 6.0. I haven't worked with portlets before but what I've heard of them always have been bad critiques. What are the reasons besides the obvious of using them? If not reasons, what arguments could I use to avoid them?
As someone who has had several jobs (including my current one) developing Java portlets, I'd say don't use them.
Here's the problem:
If you just wanted to use the pre-existing functionality of the portal you are choosing, then use a portal.
If your use of portlets is just to construct a small, light, primarily read-only web-based dashboard where you can quickly look at disparate information, then that's fine.
But if you (or more likely someone higher up on the org chart) thinks of portlets as a way to put a bunch of different web apps on a page and have it all "just work", then you are headed for a world of hurt. Portlets are highly-restricted, self-contained islands of functionality, not web apps in tiny squares on a page.
Every one of my portlet-based jobs has made this mistake, and there's no light at the end of the tunnel. As a portlet developer, here's a small list of things you're used to doing in regular web apps, that you can't reliably do in portlets:
Generate URLs to other pages. You'll need a vendor-specific way to do that, since the Portlet API only allows you to generate URLs that target the portlet that generated them.
Read and set HTTP headers or set the HTTP response code (so no redirects or HTTP caching, since you don't own the page your portlet will be placed on)
Having to namespace all identifiers in the generated page. This means HTML id attributes and JavaScript function names. Since the namespace has to be determined at runtime to ensure uniqueness, you can't have these Javascript functions reside in a separate browser-cachable file they have to be in the response body for your portlet.
Portlets feel as if they were designed for the state of web development as it was in the mid to late 90s (pre-AJAX). But they are ill-suited for today's web development environments (AJAX, single-page rich web apps, etc.) that assume you have complete control of the request/response cycle.
The problems I have with portlets remind me of the same problems as EJBs-
portlets require you to write special code that can only be hosted and run in a special server;
every portlet server vendor has custom extensions/configurations/additional abilities so it's not trivial to change server vendors;
portlets seem to be overly complex to cover functionality that 90% of people wanting to use it don't need
I'd suggest something like Google Gadgets as the Hibernate to portlet's EJB -
Javascript framework - server-side pieces can be written in any language, hosted on any server.
simpler to use
lots of portal servers support it, and it's more portable across vendors because it's not as complex, and it's not a spec for vendors to implement (and extend)
Portlets are attractive to a business because of the promise of flexibility, you an allow customers to tweak and rearrange components on the page, and if you are primarily serving content then they are an effective means of doing that.
In my opinion portals are well suited to aggregating portlets that are either pure content, functionally independent or simply related (e.g when you pick an item from a list in one portlet, you update another to show the details).
Portlets can also enable reuse, because you can configure them into multiple pages/locations fairly simply.
Where the problems can start is when you are trying to decompose complex business functions with multiple steps and interactions. In this scenario determining the granularity of the portlets is more of an art than a science, and careful consideration needs to be given to the interactions between the portlets.
You also need to consider the flexibility of the UI. If you have a set of portlet building blocks your business need to be clear that they can rearrange those blocks, but moving items between portlets involves a rewrite. For example moving the submit button from one portlet to the bottom of the page is not trivial.
So in summary, I guess it depends on what you are trying to do and how much reuse you anticipate of the components. It may be simpler to manage the reuse by creating technical components that IT build into servlets, or it may be that portlets are perfect for your business. There's no right answer, you just need to carefully consider what you are trying to achieve. If you do decide on portlets, you need to embrace the full lifecycle, and avoid any temptation to work around them, you can quickly find yourself in a bad place with all the overheads and restrictions of portlets, without being able to realise the advantages.