We are starting the port of our asp/jscript product to a j2ee solution (finally). Since moving to this company three years ago as the product architect, I have been somewhat out of the java scene. We have a pretty standard web-based product, lists, forms, ... I am looking for some guidance on what I should be looking at to develop a nice, clean, simple j2ee product that will run on any j2ee compliant app server.
- should I be looking at struts, turbine, oracle adf, other...?
- javaserver faces for the front end?
- jaxb, when and why?
- ejbs, when and why?
- rmi, when and why?
- what server-side components should be used for development?
- what developer tools? JDeveloper? Eclipse?
I see about 4-5 bigger decisions that will need to be made from an architectural point of view:
1. front-end (jsp+taglib, jsf, xml/xsml, ...)
2. distribution and remote communication (rmi vs. web services vs. ???)
3. use of ejbs???
4. use of xsd/xml in actual development of product
5. generic data layer as we support multiple rdbms vendors
I need to look at this with a product focus. This is not for a one-off and, this generation of the product will probably have a 4-5 year shelf life. Therefore, requires all the desired elements of a good architecture: maintainability, scalability, ... with easy deployment and enterprise features.
Any direction would be appreciated.
We recently developed a similarly clean, simple J2EE product that is in production now. Here's advice based on that experience:
We went with Tapestry after looking at the potential presentation frameworks, including JSF. We have not been dissapointed, to say the least. Tapestry is a joy to develop with, has tool support with Spindle, is rich in features and mature. This is one framework we will definitely be using again.
We didn't have this requirement in our first release, though it does touch on general application architecture we followed so I'll take a crack at it. It's a better choice to arhitect the application with a service layer that contains individual loosely coupled services in the first place. You can tie them however you want, most likely through simple method invocation and domain model objects to represent data in the simplest case where everything is local and there is no remoting. Using an infrastructure framework such as Spring or HiveMind makes a world of difference at this point by giving you the ability to expose these services through SOAP, RMI or other remoting technologies such has Hessian/Burlap. We did take care in the design of these service interfaces to make them coarse grained and loosely coupled, so the second release will be relatively easier for us.
I would ideally consider EJB's a deployment and not a design choice. What this means is that the business logic should be independent of whether you are using EJB's or not, developed as POJO's. Wrapping them with EJB's for additional scalability or external integration is an alternative but should not be an intrinsic part of the design. Having said this, Spring handling infrastructure and Hibernate/JDO handling persistence is most likely what you need for a simple application. EJB's have their value when scalability under high loads become important, or you really need stateful business logic. The highly manageable and scalable container implementations and stateful session beans along with all the EJB functionality for remote references start delivering value at this point. You will notice that I don't even consider entity beans an alternative for persistence as they are just too clunky to use and to develop, not the mention the current flux in specifications due to EJB 3.0 and standardized persistence in Java through JSR-220.
In our product, any "naked" data going in or out of the system is in XML. JAXB was too heavyweight and didn't play well with the POJO-based persistence and domain model deisgn we had in mind. We used a two-pronged approach, dividing data integration into representation of data in XML and interchange of XML between different schemas. We used XStream internally to go from our domain model to a "native XML" representation. For XML interchange, we developed and published public XSD schemas with agreement from our customers. We used XSLT transformation between the native XML from XStream and public schemas. The implementation easily handles the interchange of thousands of invoices, line items and related tax information and required minimal amount of coding.
- Data layer
We went with Hibernate, and I consider it a successful choice, though with less enthusiasm than I have for Tapestry. Data persistence is a complex issue, so don't go thinking that Hibernate and any other O/R persistence solution will absolve you of thinking about correct relational design. These frameworks merely automate the mechanics and enforce your constraints. Be prepared to invest a lot of time in Hibernate if this is your first use or you have inexperienced developers, you may be better off with a commercial vendor that provides good tools, support and training. Overall, I find Hibernate a very good deal in experienced hands.
- Developer tools
We used Eclipse with Spindle for Tapestry support, Dreamweaver for HTML design, Ant for automated builds and XMLSpy for XML and XSLT development. I had some opportunity to compare Visual Studio's latest version since the project also required some JNI development for some third-party integration and can say without doubt that the Java toolset is head and shoulders above Visual Studio, even when parts of it are provided by different vendors. Eclipse is generations further than VS (and a lot of other Java IDE's) in providing a smart environment that understands your code deeply and makes hard things easy. IDEA is a similarly advanced and useful IDE I heard good things about, and it may be a better choice for an inexperienced team that needs more hand holding in making the switch to J2EE.
- Serverside components
The only experience we had with a third-party server-side component was for reporting. We used Crystal Reports 10 Java Reporting Component. This was an unmitigated disaster. Crystal Reports' Java reporting is very slow, incredibly bloated (15MB of JAR's in total that need to be deployed along with your application) and a bitch to develop for given its horrible, broken API. We had to track down bug after bug and download 200MB of updates before we could get a decent PDF output, and even then there were limitations. Go with an open source component such as Jasper reports or a commercial one such as Actuate (I hear this is good but have not used it). Another possiblity is to use XSLT to generate reports, using FOP as PDF output or by itself for HTML. XMLSpy even has a WYSIWYG designer for FOP stylesheets, though we have not used it in this project.
Hope this helps.
I am interested in knowing more about this layer.
- On the way in, how did the POJOs get created from the XMLs?
- What were the XSLT technologies used? Any specific jars/tools?
- Were the XSLs handcoded/automated/generated by a tool?
In short, if you could elaborate this as much as possible, that would be awesome.
Thanx for all your help
Thanks a bunch for the reply. Was looking for that been-there-done-that type response. Will put some time into looking at the tools and other items you mentioned.