I heard that the core product of Java EE is EJB 3.x? Is that true ?
The Java EE specification was intended to specify how vendors would support transactional, distributed components that were called Enterprise Java Beans. The "Enterprise" distinguished them from POJOs, because they were intended to run in a separate application server that would handle all the issues around life cycle, threading, and services.
There are a lot of pieces in the Java EE toolkit: servlets, JSPs, Enterprise Java Beans, services such as messaging, naming, pooling, etc., relational database access, connectors to resources such as mainframes, and more.
Picking something as "core" would be like picking a "favorite" child. Better to consider them as a whole.
UPDATE: If you don't use entity EJBs, you don't need persistence or JDBC. You can write stateless session beans and be perfectly happy.
If you don't use an HTTP client, you don't need servlets or JSPs.
You don't use what you don't need.
The core product of J2EE is their containers.
Sorry, when I look at the Java EE 6 specifications page, I see dozens of technologies. EJB 3.x is one of them, but there are many others:
Related
My task is to make a small a project for start my ee studies. Till now, I learned standard java, but i don't get what ee means exactly, how my project would be an enterprise stuff. Has it a different syntax or different setup in IDE? I know it's not a clever question, but I really don't know where to start. Do you have any idea for start a project?
Java EE is no different language or has no different syntax than Java SE. It's built on top of Java SE and comprises a set of standardized APIs and libraries that are helpful for solving problems in an enterprise context.
To name a few:
Web Applications (Servlets, JSPs, JSF, WAR-packaging)
RESTful- and WebServices (Jax-RS, Jax-WS)
Persistence (EJB, JPA)
Context Dependency Injection (CDI)
Security
Batch
Messaging
...
Further it defines a runtime environment - an Application Server - to run enterprise applications. Nevertheless, the classic application server model has become somewhat obsolet, nowadays you either run a single application in an application server or use only parts of the libraries and APIs and embedd those in your applications.
So basically, all you need is an IDE and the libraries. When you're using maven as build environment, all you need is the java-ee maven dependency, see Maven Central
Usually you don't need to know all the libraries and APIs of Java EE in detail, it's good to know what is available out-of-the-box (so you don't reinvent the wheel), but you hardly will need all of them in all of your projects.
I personally avoid JSF, hardly have to deal with JPA, only occasionally do something with Batch or EJBs. More common are CDI, Restful or WebServices and WebApps, and usually a bit of Security.
And a good example for a Java EE Projects, a simple one with some typical use cases and very little code is Adam Bien's Guestbook2.0, which only requires Docker to run.
This came as an interview question.
The interviewer asked me if you can use spring for all the purposes and get away without using any of the Java EE framework .
I said yes, but he asked me how about if the application is distributed and what is the point of application servers.
I am not sure about the answer.
Does Spring do everything that the Java EE framework does?
Well, Spring is wide. So you can review point by point. I'm not specialist in Java EE but I'm sure Spring can cover a lot (if not all) of Java EE concerns. And I'm pretty sure Spring can handle most of layers/concerns in an application.
First of all, Spring IOC. You can configure an object graph with Spring IOC. It helps at any layer configuring all the components you need to implement a layer.
Spring-MVC-Web: you can configure an MVC web component in order to handle and serve all web application requests. I think you can make something cool with it. Configure web responses and its necesary configuration with other business elements (including IPC - Inter Process Comunication).
Spring Security is heritage from Acegi. It's a web framework for defining role-defined access to web resources.
I'm not sure if Hessian is Spring's too. Anyway it's lightweight and it helps comunicating with components in other processes à la RMI.
Well... I'm not sure about persistence, but I thing Spring has templates for JDBC, Hibernate, and all, so it can help anyway (as suggestions indicate: JmsTemplate and RestTemplate are available for communication with other business components!).
The core thinking here is: you can make an app from scratch, so in all cases, Spring can provide a framework to ease the difficult/repetitive tasks on every layer. Does Spring does it? Yes.
Please check other features to see if Spring has something for it. I'd bet it.
Deep down, Java EE is a set of specifications (some of which have been contributed by Spring team!)
Spring's mission statement is to 'Simplify Java Development'
It does so using the following techniques:
POJO -> facilitates easy testing
DI -> promotes loose coupling
AOP -> promotes separation of concerns, maintainability etc
Templates -> provides a standard programming model which does the heavy lifting for you
Spring and Java EE do not have a "Vs" relationship.
Using the above techniques, the Spring Framework lets you build (Java EE) standards-based applications more efficiently.
>Does spring do everything that the Java EE framework does ?
Based on what I've said above, the question might be rephrased as 'Does Spring have support/implementations for all the technologies that comprise the Java EE specification?' -
Nope, but it does do what it set out to do and that is simplify development on most Java EE technologies.
That said, the trade-off for this simplification of Java development is that you need to now have significant amount of knowledge (of the Spring Framework) at your fingertips... (comes with practice and google :) )
>Can't we use Spring for distributed java applications?
Sure you can. Spring has a whole lot of Exporters/FactoryBeans and Clients(Templates) for most conceivable use cases.
Yes Spring can be used in a distributed application without Java EE. We have used it to send messages to MQ and update a database both within one XA transactions.
According to this article, Spring can definitely be used on its own in a distributed application.
http://www.wrox.com/WileyCDA/Section/Why-Use-the-Spring-Framework-.id-130098.html
http://www.artima.com/forums/flat.jsp?forum=276&thread=204508
Historically, (5 years ago?) Spring was weak in the distributed applications area, in particular database clustering. That is no longer a concern. I would say that Spring is going even further for distributed computing these days as they are vigorously pursuing cloud technologies which Java EE hasn't approached yet.
In my view the main benefit of Spring was that it did away with some of the more heavyweight components of the Java EE framework (Entity Beans, session beans) and replacing them with a lightweight alternative.
On of the main benefits of Spring as I see it, is that it decouples a lot of components and then uses XML or Annotations of wiring them together. That makes it easy to write Unit Tests (by injecting mock components instead of real ones), which wasn't something easily done when using heavyweight Java EE components (couldn't easily unit test EJB 2.1 Entity Beans).
A lot of Spring concepts have since gone into the Java EE standards, so I would argue that Java EE is no longer a heavyweight option, and Spring works will with Java EE components such as application server managed connection pools (via JNDI), transaction managers, queue managers that can very easily be managed using an application server which can provide additional functionality such as clustering, failover, load-balancing, serving web resources...
Having said that, the people behind Spring (VMWare) have their own application server (tcServer) which is based on Apache Tomcat and provides a lot of the glue used by spring, but is not considered as "heavy" as some of the traditional Application servers (Websphere, Weblogic).
I don't think so. Basically Spring is about integration between Java EE frameworks.
Use spring inegration framwork for this .
Use can uss Akka framwork for managing distributed applications with spring integration .
Akka uses the Actor Model together with Software Transactional Memory to raise the abstraction level and provide a better platform to build correct concurrent and scalable applications.
Take a look at the step by step tutorial that gives more information about how to build a distributed application using Akka framework.
In general, distributed applications are built in Java using Java-RMI that internally uses Java's inbuilt serialization to pass the objects between the nodes.
I'm developing java enterprise web application using EJB 3.1 and I wonder which technology to use on which MVC layer. I have ear, ejb(jar) and war projects.
Is it possible to use something other as persistence layer then JPA implementations (e.g. myBatis) and how? I would like to manage some more difficult queries on my own.
What framework to use in web project (war) except JSF or plain servlets?
I'm familiar with Spring, would it be possible to use Spring in web (war) projects and benefit from its controllers?
Can you explain which technologies are used to develop enterprise web applications?
Thanks.
The best combination would be to use what's already there. JSF 2.0 is already one of the best MVC frameworks, so it would often be a first choice anyway.
When using EJB 3.1, this is almost always in combination with a Java EE implementation, so in that case JSF is already there and simply using it is a no-brainer.
The different technologies in the Java EE stack are made to work with each other, so a typical stack consisting of JSF + CDI + EJB + JPA is the most ideal combination and you'll find the most support for this.
I personally don't think there's any place for Spring in an EJB/CDI stack. Those two technologies are direct competitors that solve the same problem in (slightly) different ways. Combining them will most likely only complicate your code.
For a starter like you, stick with what comes out of the box with Java EE 5/6. So in your case JSF+Facelets, EJB 3.1 and JPA.
I suggest you to read the below books and in the order given
Beginning Java™ EE 6 Platform with GlassFish™ 3
Real World Java EE Patterns Rethinking Best Practices
I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?
My model application is a solid thing, starting, running and stopping as a whole and solely at the host.
It has a database storage, and communicates to user and other servers, clustering required.
It has web-part. It's just a standard big application.
JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.
Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).
For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.
So, why somebody still choose JBoss - what are benefits?
I favors more standalone application approach, but need more facts to understand better and convince others.
It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.
JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.
Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.
You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.
Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.
I would say the only reason to use JBoss is if you need to access the Java EE services (like Messaging, container-managed transactions and similar).
Keep in mind JBoss is (roughly described) Tomcat plus Java EE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:
If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
If you application requires Java EE services, use JBoss
Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the Java EE services or you were over-engineering the solution.
What are the primary reasons for using the Java EE (EJBs) over just a simple Servlet implementation?
I am working on developing a new project that will primarily be a web service that must be very fast and scalable.
Sorry for any confusion, Although I am experienced in Java, I am very new to the Java Web world, and may not be asking this question well.
Servlets are HTTP request listeners; they can't respond to anything else.
If you embed a great deal of logic in servlets it won't be available to any other clients.
Write your app in POJOs. Get it thoroughly tested without an app server involved. Then worry about how you'd like to package and deploy it. Servlet? EJB? Web service? Something else? No problem - those are just packaging and deployment issues. Get the behavior that you want working properly in POJOs first.
Spring can give you a lot of options here. I'd recommend it.
EJB's specification 1.x and 2.x added complexity that for most webapps was not needed.
Due this complexities the new frameworks appeared to simplify the development and the runtime architecture ( Hibernate / Spring / other microcontainers / others ORM frameworks ) .
EJB's 3.x matches this changes ( through JDO and JPA ) and now, using Servlets with these enhanced frameworks or Java EE with EJB 3 + would give you basically the same results.
Using a Java EE Application Server would add you a number of administrative advantages ( GUI to manage pools, logs, monitoring, transactions etc. ) With out them you may have the same result but you would have to do it all by hand ( editing configuration files that is ) Which may not seem too problematic, but if you plan to have an administrator for your webapp It would be better to use the admin tools that come out of the box with this servers.
Is the web service stateless? If so, I don't see any real advantage in using a full blown Java EE server over something lightweight like Tomcat or Jetty. You can deploy a jax-ws implementation with either of those, and do what you need pretty easily. If there's some kind of state involved, and you end up wanting to share that across multiple machines, that is where having Java EE can come in handy.
With that said, I don't think Java EE would decrease performance any at all. The app servers generally take longer to boot, and take more effort to manage, but once they are up and running the performance should be similar.
If your web services are likely to need any degree of "enterprise" features such as per-method security or transactions use EJBs.
With EJB 3 this is not actually very hard at all, a couple of annotations and you're done.
Otherwise simple POJOs behind a servlet are enough.