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
Related
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.
I was curious about the capabilities of Sessions Beans in EJB 3 and whether they can be replaced in a typical mid-scale enterprise application with Spring.
I found this article:
http://drag0sd0g.blogspot.com/2010/01/session-bean-alternative-spring.html
that states the following: "Because of heavy use of annotations,
you can pretty much avoid “XML Hell” using EJB 3; the same cannot be said of Spring.
Moreover, because it is an integral part of the Java EE standard, the EJB container
is natively integrated with components such as JSF, JSP, servlets, the JTA transaction
manager, JMS providers, and JAAS security providers of your application server. With Spring, you have to worry whether your application server fully supports the framework with these native components and other high-performance features like clustering, load balancing, and failover. If you aren’t worried about such things, then Spring is not a bad choice at all"
Do you agree with this statement? The Stateless Sessions Beans used to be considered a very powerful enterprise technology because of the pooling and management capabilities. My question is: when is it really necessary to use EJB 3 instead of or in addition to Spring (assuming a mission critical enterprise application in a large company)?
Looks like yet another Java EE vs. Spring post...
EJB/Java EE and Spring are now two mature, competitive Java-based technology stacks. Often there's no reason to complicate things and mix them up. EJB actually learned and used many ideas from Spring et al.
Neither of them drives you into the XML/configuration hell. Both are fairly easy to get started with, at least with the very basic stuff.
Spring is more than just IoC/SOA/transactions. It's more like a toolbox - it's ready to integrate with, or directly provides, frameworks for ORM and transactions, web/MVC, security, timers/scheduling etc. You can pick exactly the pieces you need. You're not forced to use a container (you can use it in your standalone "desktop" app).
EJB is part of Java EE stack. It is, well, the standard. It's not as broad, flexible as Spring, but it's by definition supported by all Java EE containers.
I prefer Spring for the freedom and being one step ahead.
I don't think there are many cases when the use of EJB 3 instead of Spring is absolutely necessary, but there are cases when using EJB 3 would be considerably easier. As the article states, the main advantages of EJB is the integration with the various other JEE technologies and, as of EJB 3, Enterprise Beans are much simpler to write than in they were in previous versions of the spec.
The classic reason for using EJB over POJOs or other middleware technologies is transactions. If your business logic needs to be transactional then EJB provides simple, declarative transnational demarcation and seamless integration with JTA via the container. While the article suggests that support for clustering, load balancing and performance management is an advantage, this is very much dependant on your choice of JEE application server.
I'd say the key factor in deciding whether to use Spring or EJB 3 is your container. If your target container is a fully JEE 5+ compliant application server and you need support for services such as transactions or messaging then EJB 3 is the obvious choice. If, however, you don't need to integrate with other JEE technologies or are deploying to a light-weight app server then using EJB would simply add unnecessary overhead.
How can anyone think EJB3's defining a data model using a series of java annotations spread out over several classes is superior to Hibernates simple model definition syntax is beyond me.
Its a maintainability nightmare. Why have you got an intersection table? It may be defined almost anywhere in the code base. Some junior programmer plays with the annotations and now your java classes are out of sync with the actual database.
Got a performance issues (and you will). Not only have you got the classic Hibernate "I don't know what SQL it's using" you also have the "I don't know why the table was built like that" problem.
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!
I wonder how is the best way to integrate Java modules developed as separate J(2)EE applications. Each of those modules exposes Java interfaces. The POJO entities (Hibernate) are being used along with those Java interfaces, there is no DTO objects. What would be the best way to integrate those modules i.e. one module calling the other module interface remotely?
I was thinking about: EJB3, Hessian, SOAP, JMS. there are pros and cons of each of the approaches.
Folks, what is your opinion or your experiences?
Having dabbled with a few of the remoting technologies and found them universally unfun I would now use Spring remoting as an abstraction from the implementation.
It allows you to concentrate on writing your functionality and let Spring handle the remote part with some config. you have the choice of several implementations (RMI, Spring's HTTP invoker, Hessian, Burlap and JMS). The abstraction means you can pick one implementation and simply swap it if your needs change.
See the SpringSource docs for more information.
The standard approach would be to use plain RMI between the various service components but this brings issues of sharing your Java interfaces and versioning changes to your domain model especially if you have lots of components using the same classes.
Are you really running each service in a separate VM? If these EJBs are always talking to each other then you're best off putting them into the same VM and avoiding any remote procedure calls as these services can use their LocalInterfaces.
The other thing that may bite you is using Hibernate POJOs. You may think that these are simple POJOs but behind the scenes Hibernate has been busy with CGLib trying to do things like allow lazy initialization. If these beans are serialzed and passed over remote boundaries then you may end up with odd Hibernate Exception getting thown. Personally I'd prefer to create simple DTOs or write the POJOs out as XML to pass between components. My colleagues would go one step further and write custom wire protocols for transferring the data for performance reasons.
Recently I have been using the MULE ESB to integrate various service components. It's quite nice as you can have a mix of RMI, sockets, web services etc without having to write most of the boiler plate code.
http://www.mulesource.org/display/COMMUNITY/Home
Why would you go with anything other than the simplest thing that works?
In your case that sounds like EJB3 or maybe JMS, depending on whether the communication needs to be synchronous or asynchronous.
EJB3 is by far these easiest being built on top of RMI with the container providing all the additional features you might need - security, transactions, etc. Presumably your POJOs are in a shared jar and therefore can simply be passed between your EJBs, although I tend towards passing value objects myself. The other benefit of EJB is, when done right, that it's the most performant (that's just my opinion btw ;-).
JMS is a little more involved, but not much and a system based on asynchronous communication affords certain niceties in terms of parallelizing tasks, etc.
The performance overhead of web-services, the inevitable extra config and additional points of failure make them, IMHO, not worth the hassle unless you've a requirement that mandates their use - I'm thinking interop with non-Java clients or providing data to external parties here.
If you need network communication between Java-only applications, Java RMI is the way to go. It has the best integration, most transparency and the least overhead.
If, however, some of your clients aren't Java-based, you should probably consider other options (Java RMI actually have an IIOP-dialect, which allows it to interact with CORBA, however - I wouldn't recommend doing this, unless it's for some legacy-code integration). Depending on your needs, webservices are probably your friend. If you are conserned with the networkload, you could go webservices over Hessian.
You literally mean remotely? As in running in a different environment with therefore different availability characteristics? With network overheads?
Assuming "yes" my first step would be to take a service approach, set aside the invocation technology for a moment. Just consider the design and meaning of your services. You know they are comparativley expensive to invoke, hence small busy interfaces tend to be a bad thing. You know that the service system might fail between invocations, so you may favour stateless services. You may need to retry requests after failure, so you may favour idempotent service designs.
Then consider availability relationships. Can your client work without the remote system. In some cases you simply can't progress if the remote system isn't available (eg. can't enable the employee if you can't get to the HR system) in other cases you can adopt a "fire-and-tell-me-later" philosophy; queue up the requests and process responses later.
Where there is an availability depdency, then simply exposing a synchronous interface seems to fit. You can do that with SLSB EJBs, if everything is Java EE, that works. I tend to generalise expecting that if my services are useful then non Java EE clients may want them too. So SOAP (or REST) tends to be useful. These days adding a web service interface to your SLSB is pretty trivial.
But my pet theory is that any sufficiently large IT system ends up needing aynch communications: you need to decouple the availability contraints. So I would tend to look for a JMS-style relationship. An MDB facade in front of your services, or SOAP/JMS is not too hard to do. Such an approach tends to highlight the failure-case design issues that were probably lurking anyway, JMS tends to make you think: "suppose I don't get an answer? suppose my answer comes late?"
I would go for SOAP.
JMS would be more efficient but you would need to code up an message driven bean for each interface.
SOAP on the other hand comes with lots of useful toolkits that will generate your message definition (WSDL) and all the neccesary handlers (client and server) when given an EJB.
With soap you can (but dont have to) deal with certificate security and secure connections over public networks. As the default protocol is HTTP over port 80 you will have minimal pain with firewalls etc. SOAP is also great for hetrogenious clients (in your case anything that isn't J2EE) with good support for most common languages on most common platforms.
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 .