I have got an architecture to be chosen based on my requirement assignment.
So, the requirement is to build a web application for the common man , similar to book my show application.
Also, the application should be available via intranet for admin users to manage requests.
Also, it is necessary that i use open source technologies to reduce cost, unless absolutely necessary.
Keeping all these points in mind, i would say i would need the following
a) I would go for a n tier architecture.
b) For presentation tier:- can go with JSP/servlets+JSTL or should i go with JSF
c) For business tier:- Spring MVC or EJB3.0?
d) DAO:- Hibernate/JDBC as DAO layer.
e) Database:- SQL server or Oracle 10g.
Could you please pore in your points so that it can guide me further to go with the right technology and architecture?
Thanks for your expert help in advance.
I am not going to tell you what to choose, but give you some advices how.
First of all, Just want to slightly change your considerations:
b) You should include Spring MVC into this point, because it is abstraction layer on top of servlets and can be easily combined with JSP. BTW Spring guys nowadays prefer Thymeleaf templating engine, so maybe something to consider also. You also definitely want to go for security framework like Spring Security (not sure how it cooperates with a Java EE stack)
c) You probably want to consider Spring IoC (Spring Core) vs EJB3.0. There is also Google Guice framework.
I would suggest you to build your decisions on these factors
What is your and your team expertise with certain technologies
What is your OPs team experience with (Full Java EE app servers or lightweight servlet containers like Tomcat or Jetty)
Is your project going to be bigger monolith (look at advantages of full Java EE app servers) or set of micro-services (look at Spring Boot and it's advantages, also look at Microservices architecture pattern advantages and also PITFALLS -> because it is very popular architectural pattern nowadays, but can lead to various problems like performance problems or production environment complexity)
Are you planning to use Spring related projects (e.g. Spring Data family for connection to different Social networks)
Do you think you'll need to use cashing on app server (consider Hibernate with second level cache)
JDBC vs Hibernate is huge architectural decision, so better read about pros and cons deeply. If you choose JDBC, you probably want to go for Spring JDBC and most importantly some querying framework like JOOQ or QueryDSL.
If you'll go for Hibernate / JOOQ / QueryDsl, you should be safe to choose any SQL DB. Because these frameworks abstracts differences if you avoid using custom features of certain vendor. Said that it is also crucial to take a look at your OPs and admins expertise when choosing DB. If you want to save money on licenses you probably want to take a look at PostgreSQL (enterprise grade open-source DB)
Do you have some enterprise level architects around to consult these decisions with. Clarify early if your app needs to be integrated with some wider enterprise environment. In this case you probably want to take a look at Spring Integration or Apache Camel.
Are you going to have some background regular processing that is not triggered by user requests? Take a look at Spring Batch / Java EE 7 Batch spec.
MOST IMPORTANTLY DO SPEAK WITH YOUR TEAM ABOUT THESE DECISIONS TO INVOLVE SENIOR AND PASSIONATE TEAMMATES. You don't want to hear complaints later.
Don't be afraid to make final decisions. Lack of decision is MUCH WORSE than bad decision.
(I am Spring guy, so I apologize if this sound like your direction should be Spring stack. The Java EE stack definitely has alternatives for most Spring modules, so do your own deep research).
My first post here so request your indulgence. Let me try and answer your questions point by point:
n-tiers architecture - definitely - a UI / REST services / Data store
Presentation tier - I would recommend using an open source Javascript library like Prime NG. Gives you the ability to create great UIs coupled with the fact that they can cleanly call the REST services
Business tier - either Spring boot REST services or JEE 7 REST services. I would stay away from EJBs. Using REST will give you the ability to move to micro services tomorrow
DAO - Hands down JDBC or a very thin wrapper over JDBC for me. Hibernate in my opinion will only complicate things and ability to scale. A well designed JDBC implementation will outperform Hibernate plus will also provide you with an ability to separate optimization concerns
Database - if cost is not a concern Oracle 10G. No comparison to Oracle when it comes to RDBMSs. Note that these are not open source. If you want to go open source Postgresql / MySQL could also be considered. Here I would also recommend you to look at noSQL options like MongoDB / Couchbase
The things I would stay away from are too much of annotation based configuration (do what is really required but not just for the heck of it) or a straight jump into micro services carried to the extreme which may lead to a very difficult production environment to run and manage. Do do make sure that your code reads like a story and tells the business logic rather than only looking like a technology specification. All the best.
Related
For the first time (hopefully not the last) in my life I will be developing an application that will have to handle a high number of users (around 5000) and manage lots of data. I have developed an application that manages lots of data (around 100~ GB of data, not so much by many of your standards), but the user count was pretty low (around 50).
Here is the list of tools / frameworks I think I will be using:
Vaadin UI framework
Hibernate
PostgreSQL
Apache Tomcat
Memcached (for session handling)
The application will mainly be run inside a company network. It might be run on a cluster of servers or not, depends on how much money the company wants to spend to make its life easier.
So what do you think of my choices and what should I take caution of?
Cheers
The answer, as with all performance/scaling related issues is: it depends.
There is nothing in your frameworks of choice that would lead me to think it wouldn't be able to handle a large amount of users. But without knowing what exactly you want to do or what your budget is, it's impossible to pick a technology.
To ensure that your application will scale/perform, I would consider the following:
Keep the memory footprint of each session low. For example, caching stuff in the HttpSession may work when you have 50, but not a good idea when you have 5000 sessions.
Do as much work as you can in the database to reduce the amount of data that is being moved around (e.g. when looking at tables with lots of rows, ensure that you've got paging that is done in the database (rather than getting 10,000 rows back to Tomcat and then picking the first 10...)
Try to minimise the state that has to be kept inside the HttpSession, this makes it easier to cluster.
Probably the most important recommendations:
Use load testing tools to simulate your peak load and beyond and test. JMeter is the tool I use for performance/load-testing.
When load testing, ensure:
That you actually use 5000 users (so that 5000 HttpSessions are created) and use a wide range of data (to avoid always hitting the cache).
EDIT:
I don't think 5000 users is not that much and you may find that (performance-wise) you only need a single server (depends on the size of the server and the results of the load testing, of course, and you may consider a clustered solution for failovers anyway...) for handling the load (i.e. not every one of your 5000 users will be hitting a button concurrently, you'll find the load going up in the morning (i.e. everyone logs in).
You might want to consider an Apache HTTP server in front of your Tomcat servers. Apache will provide: compression, static caching, load-balancing and SSL.
Any reason for not using Spring? It has really became an de-facto standard in the enterprise java applications.
Spring provides an incredibly powerful and flexible collection of technologies to improve your enterprise Java application development that is used by millions of developers.
Spring is lightweight and can stay as a middle layer, connecting the vaadin and hibernate, there by creating a clean separation of layers. The spring transaction management is also superior to the one on hibernate. I will suggest you go for it until you have a strong reason stopping you.
Since you asked people to weigh in, I won't hold back my opinion. ORMs in general, and Hibernate in particular, are an anti-pattern. I know, I've worked in shops that use Hibernate over the past 9 years. Knowing what I know now, I will never use it again.
I highly recommend this blog post, as it puts it more succinctly than I can:
ORM is an anti-pattern
But forgive me if I quote the bit from that blog about ORMs and anti-patterns:
The reason I call ORM an anti-pattern is because it matches the two
criteria the author of AntiPatterns used to distinguish anti-patterns
from mere bad habits, specifically:
It initially appears to be beneficial, but in the long term has more
bad consequences than good ones
An alternative solution exists that is proven and repeatable
Your other technology choices seem fine. Personally, I lean more toward Jetty than Tomcat. There's a reason that Google embeds it in a lot of their projects (think GWT and PlayN); it's a younger codebase and I think more actively developed now that Eclipse has taken it over. Just my humble opinion.
[UPDATE] One more link, very long read but when making architectural decisions, reading is good.
Object/Relational Mapping: The Vietnam of Computer Science
I recommend Glassfish for application server because Apache Tomcat can serve simple content. And Glassfish has full implementation of the Java EE specification.
Depending on you specification and future goals I would perhaps leave the normal version of tomcat and go for Apache TomEE or my personal preference of jBoss. As I understand it EJB's are not very well supported in the normal tomcat version and that is probalby something sweet to have when you want to create a couple of services, some clustered singleton service and other stuff. But this is just my personal pref of course and if your specification will not allow a more advanced EE server then you should stick with the slick tomcat.
I'm looking for some advice/feedback about using different languages in a layered architecture. Right now the architecture in question is an all java stack (db, middle tier, and web tier) using Spring to tie everything together. We've been tossing around the idea of using Ruby on Rails for the web tier, but I'd like to know if anyone has done this before (maybe with different languages/technologies). The idea behind switching to RoR is to increase development speed in the web tier, however my initial analysis is that it will also decrease development speed in the middle tier.
Some of the questions I'm trying to get data points on are:
Have any small development teams actually used a hybrid language approach in a similar architecture?
Why did you use that approach? What worked well and what didn't?
How would you handle interfaces and models (maybe use something like Google protocol buffers or Apache Thrift)?
Are there any other benefits or pitfalls to using an approach like this?
While I have no experience of RoR, we have taken a similar approach with Django as a front end layer, where we would use java based services for high volume transaction processing back ends.
We define the DB in a django model, develop the web front end with django views/ jquery and obviously get a for free admin site.
On the java side we run a hibernate reverse engineering task to generate DB access classes for the java code. Where required we use home crafted JSON over AMQP RPC mechanism to communicate between python and java components.
There are ups and downs to this approach. For us as we were not using any big java frameworks, it gave us access to quick / lightweight web front end to our solution as well as the ease of modelling our database using the Django model format (which I like a lot).
On the down side we did encounter some tricky stuff with hibernate reverse engineering configuration (which is complex if you are doing anything that is not bog-standard - especially in relation to some Django ManyToMany relations).
I notice you mention that you already have a Spring based architecture with a web tier. I'm no expert here but that may present you with opportunities worth exploring such as groovy/grails or the SpringMVC which in version 3 claims to be much simplified and faster to develop against. This may give you the wins you need.
A compromise might be to look at some RoR inspired Java tools like Rife.
Bottom line is that you will have to make the call in light of what your own application requirements and team capabilities are. It worked for us and was I think the correct decision for us but if your team is already tooled up with Java & Spring skills then Spring 3 might be the way to go (but ask a Spring expert about that :-) )
Rob
This presentation will probably be interesting to you: Rails on Spring - Using JRuby as the Secret Sauce
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 transfer data from one system to another, through data interface, by web services, we normally get a result set by SQL query, and format them as a web service endpoint, and allow it to be retrieved by another side.
With EJB 3.0, it seems we can replace the result set by stateless session bean. So are there any advantages over the SQL-based web services? And when should we use it?
This is a very broad question on the system architect level. I will try to answer with my best knowledge without starting a flame war (FYI, I have used both ejb and spring).
As you know, building a stable/robust software application requires many building blocks, such as logging, connection pool, etc. Usually, you can find libraries of these building blocks, but not all of them have common api, so they may require integration. In the worst case, you may have to lock into some vendors. The main idea of EJB 3 (or Java EE) is to provide a more complete set of building blocks (via API, annotation or config), so developers can start working on the core business logic right away with an industry standard API/spec/config without training on the proprietary APIs. Additionally, you can change vendor without changing your codes since API/config are really the industry standard (well, your mileage may vary a lot in the real life. hopefully, the new Java EE will fix it).
Your application may already have some of the main elements that EJB 3 already provides. However, EJB 3 promises to provide more such as ORM mapping, RMI, Load balancing, failover, transactions, dynamic redeployment, logging, system management, thread managing, resource pooling (db connection), security, caching.
As you have an working application already, you can really consider if it is worth of your efford to migrate your codes to a standard system to gain more functionality vs integrate new functionality individually. Additionally, EJB 3.0 (or Java EE) is not really the framework that you can pick. You can also look into other framework, such as Spring.
My suggestion is to really figure what your system requirements, and then pick the right technologies instead of picking up the coolest technologies first.
Good luck
My team is developing a new service oriented product with a web front-end. In discussions about what technologies we will use we have settled on running a JBoss application server, and Flex frontend (with possible desktop deployment using Adobe AIR), and web services to interface the client and server.
We've reached an impasse when it comes to which server technology to use for our business logic. The big argument is between EJB3 and Spring, with our biggest concerns being scalability and performance, and also maintainability of the code base.
Here are my questions:
What are the arguments for or against EJB3 vs Spring?
What pitfalls can I expect with each?
Where can I find good benchmark information?
There won't be much difference between EJB3 and Spring based on Performance. We chose Spring for the following reasons (not mentioned in the question):
Spring drives the architecture in a direction that more readily supports unit testing. For example, inject a mock DAO object to unit test your business layer, or utilize Spring's MockHttpRequest object to unit test a servlet. We maintain a separate Spring config for unit tests that allows us to isolate tests to the specific layers.
An overriding driver was compatibility. If you need to support more than one App Server (or eventually want the option to move from JBoss to Glassfish, etc.), you will essentially be carrying your container (Spring) with you, rather than relying on compatibility between different implementations of the EJB3 specification.
Spring allows for technology choices for Persistence, object remoting, etc. For example, we are also using a Flex front end, and are using the Hessian protocol for communications between Flex and Spring.
The gap between EJB3 and Spring is much smaller than it was, clearly. That said, one of the downsides to EJB3 now is that you can only inject into a bean, so you can end up turning components into beans that don't need to be.
The argument about unit testing is fairly irrelevant now - EJB3 is clearly designed to be more easily unit testable.
The compatibility argument above is also kind of irrelevant: whether you use EJB3 or Spring, you're still reliant on 3rd party-provided implementations of transaction managers, JMS, etc.
What would swing it for me, however, is support by the community. Working on an EJB3 project last year, there just weren't a lot of people out there using it and talking about their problems. Spring, rightly or wrongly, is extremely pervasive, particularlty in the enterprise, and that makes it easier to find someone who's got the same problem you're trying to solve.
What are the arguments for or against EJB3 vs Spring?
Spring is always innovating and recognizes real-world constraints. Spring offered simplicity and elegance for the Java 1.4 application servers and didn't require a version of the J2EE specification that no one had access to in 2004 - 2006. At this point it is almost a religious debate that you can get sucked into - Spring + abstraction + open-source versus Java Enterprise Edition (Java EE) 5.0 specifications.
I think Spring complements more than competes with the Java EE specifications. As the features that were once unique to Spring continue to get rolled into the specification, many will argue that EJB 3 offers a 'good enough' feature set for most internal business applications.
What pitfalls can I expect with each?
If your treating this as persistence issue (Spring+JPA) versus EJB3 your really not making that big of a choice.
Where can I find good benchmark information?
I haven't followed the specj benchmark results for sometime, but they were popular for a while. It seems that each vendor (IBM, JBOSS, Oracle, and Sun) get less and less interested in having a compliant server. The lists get Shorter and shorter of certified vendors as you go from 1.3, 1.4. 1.5 Java Enterprise Edition. I think the days of a giant server that is fully compliant with all the specifications are over.
I would definitely recommend EJB3 over spring. We find that it's more streamlined, nicer to code in, and better supported. I have in the past used Spring and found it to be very confusing, and not as well documented as EJB3 (or JPA I guess at the end of the day)
As of EJB3 you no longer have to deal with external config files, and there's only one POJO that you annotate per database table. This POJO can be passed to your web tier without any problems. IDEs like Netbeans can even auto-generate these POJOs for you. We've used EJB3 now as the back end for quite a few large scale applications, and haven't noticed any performance problems.
Your Session Beans can be easily exposed as web services which you could expose to your Flex frontend.
Session beans are easy to lock down at either a method or class level to assign roles and things like that if you need to.
I can't speak that much about spring, as I only tried it out for a few weeks. But my overall impression of it was very poor. That doesn't mean it's bad framework, but our team here has found EJB3 to be the best for the persistence/business layer.
I tend to prefer Spring over EJB3 but my recommendation would be whichever approach you take, try to stick to writing POJOs and use the standard annotations where possible, like the JSR annotations such as #PostConstruct, #PreDestroy and #Resource which work with both EJB3 or Spring so you can pick whichever framework you prefer.
e.g. you could decide on some project to use Guice instead for IoC.
If you want to use pre-request injection such as in a web application you might find Guice is quite a bit faster for dependency injection than Spring.
Session beans mostly boil down to dependency injection and transactions; so EJB3 and Spring are kinda similar really for that. Where Spring has the edge is on better dependency injection and nicer abstractions for things like JMS
i have used a very similar architecture in the past. Spring + Java 1.5 + Actionscript 2/3 when combined with Flex Data Services made it all very easy (and fun!) to code.
though, a Flex front end means you need adequately powerful client machines.
Regarding your question:
What are the arguments for or against EJB3 vs Spring?
I suggest reading the response from the experts: A RESPONSE TO: EJB 3 AND SPRING COMPARATIVE ANALYSIS by Mark Fisher. Read the comments to find Reza Rahman's remarks (EJB 3.0).
Another thing in favor of spring is that most of the other tools / frameworks out there have better support for integration with spring, most of them use spring internally as well (e.g. activemq, camel, CXF etc).
It is also more mature and there are a lot more resources (books, articles, best practices etc) & experienced developers available than for EJB3.
I think EJB is a good component technology but not a good framework.Spring is the best framework available as of today.So i should consider Spring as the best implementation of JEE in the sense of a framework and my recommendation is to use spring in every project which gives us the flexibility to integrate with any component technology easily .