I am newbie to EJB's. From all the reading and searching I have done till now, I understood the following:
EJB are the beans in which an applications business logic is written and maintained.
All EJB's are put into something called EJB container.
EJB container is nothing but a server side program written in order to manage EJB's, and to provide basic functionalities which are meant to be provided by EJB(viz, transaction management, security, collision free envt, etc).
1) My doubt is, does the so called EJB component reside in all application servers?
2) When we say EJB 2.1/3.0/3.1, does it mean that the new version of EJB container has been released?
3) Does the EJB container reside in web servers too?
Thank you.
You understood the EJB idea correctly.
Yes and no. Depends on what you understand as "Application server" (ambiguity described below in answer 3.)
When you say EJB 2.x/3.0/3.1 or so on, you're referring to a particular EJB specification which means that you're referring to a set of services this version supports. In other words - yes, it means that the EJB container must be in a given version.
First the specification is released (you can see the draft versions, vote for new features and basically participate in this process). Then, a reference implementation (RI) is written just to show that it's "doable" and you can use it right away. Then, different vendors might provide their own EJB containers which must conform to the particular EJB specification.
There are few different terms you need to be aware of. Just to be sure, we're talking about the same things:
Web server is a HTTP/HTTPS server like Apache HTTP Server which serves clients requests. This term is not only related with Java EE.
Web container is a Java EE term which can mean few things, but usually it refers to Servlet container and, let's say JSP container. Those containers are serving web clients, so that's why it's web container. Generally, web container have a web server within it (like in the case of Tomcat.) However, you can configure it so that the static resources will be server by only pure web server while dynamic content (your Java App, Servlets, JSP, etc.) will be server by your web container.
Application server is a vague name. In Java EE purists world it can mean only such server that provides all the Java EE services. Non-Java EE purists treats Application server just as an arbitrary server which consists of your application. According to this definition, you can call Tomcat (a web container and web server) an application server.
As you see, the vocabulary is not sharp, as one thing might mean few slightly different things. Moreover, since Java EE 6 we have profiles. This means that you can have Java EE Application Server conforming to the Web Profile or Full Profile. In such terms, just the Web Profile server should be treated as an application server.
Just as a summary - you can use EJB Container in Web Container. Take a look at OpenEJB or basically at project TomEE.
To answer your questions
Generally yes. Application server is generally referred to a server with has EJB container like Glassfish, Jboss etc. But you need make sure that the application server has EJB support.
YES
NO. Web servers or Web containers (Tomcat, Jetty etc ) serve a different purpose than EJB container. But all the application servers do have web servers (along with EJB containers. ).
The EJB container and web container (servers) server are different layers in a Java EE application scenario . Check this link for more info.
Related
I know that Tomcat is a web server but why it is not an application server?
Any server needs to follow some specification. What is that spec?
Is it possible for apache to make the tomcat application server?
Also I have read in a blog that the tomcat do not have some lib to act as an application server. What are those libs?
Thanks
I've heard once the following explanation I tend to agree with:
There is a spec of JEE (Java enterprise edition).
Formally you can think about it as a bunch of pdf-s describing the behavior of various technologies that comprise the JEE stack (for example: JMS, EJB, JPA, JPA, JSF, CDI and so on and so forth) as well as deployment models (EARs for example).
Implementors of Application servers have to implement all those technologies and offer interfaces that can be used by the application developers. So teams that stand behind WildFly (former JBoss), Geronimo, WebSphere, WebLogic and so on have read these specs and implemented everything in there.
Now, Tomcat didn't do that, they've only concentrated on (primarily) Servlets/JSPs. These are web technologies, so Tomcat can't be considered as an Application server that implements the whole JEE stack.
In general Tomcat (as well as Jetty, incidentally) should be more lightweight than full JEE compliant Application servers, it should start-up faster and it memory footprint should be smaller. So Tomcat/Jetty call themselves web servers.
I understand that this answer can be considered as speculation, but for me it makes a lot of sense.
Bellow is my perceive:
know that Tomcat is a web server but why it is not an application server?
Here, Application Server is specially for Java EE Server，Java EE is a huge specific collections for Enterprice Application Development，So Application Server should implement most specifics of these, while Tomcat(or Jetty) is only a Web Server(More accurately，Servlet Container)，they only implements the specific about Web(such as Servlet Spec(JSR340), JSP(JSR245)). Therefore，Application Server is stronger than Web Server，but Web Server is more lightweight and enough to satisfy most web applications.
Any server needs to follow some specification. What is that spec?
Of course，it depends on that your Server want to provide what services(functions)，these specifications can view here.
Is it possible for apache to make the tomcat application server?
I don't think apache will make tomcat to be an application server. Now, there are some popular Java EE Server: Jboss，WebLogic, etc. Not all enterprices need a heavyweight Application Server, on the contrary, most only need a lightweight Web Server。
Also I have read in a blog that the tomcat do not have some lib to act as an application server. What are those libs?
Tomcat only need care the specs about Web，and implements them.
Hope for your help.
Can I deploy a Spring java application on all (or at least most) of JavaEE servers ? like Weblogic, JBoss, Webshpere, Tomcat, Jettty etc.
And is there is preferred Java EE server for Spring ?
Yes you can. And no - there isn´t. Errata: you can take a look at the SpringSource dm Server. Be aware that spring is not a java EE implementation. Read this post here.
Yes, you can deploy it on any server, and you can use it on standalone applications and even on mobile applications. It is in no way restricted to web deployment. It is not even restricted to java, there is Spring.NET and even a Python version. However, java and web servers are a common if not the most common use for it.
Currently recommended web server by VMWare/Pivotal (current owner of Spring) is VFabric tcServer, which is a Tomcat fork containing some extra tools and functionality. But server in itself does not matter, Spring is container agnostic.
There is no preferred EE server. VFabric tcServer is a servlet container, not an EE server. It contains "enterprise capabilities" instead, but that's not the same thing. As said however, you can use whichever EE server you want.
I am new to Java EE. Does EJB need a dedicated server in order to be used or can I potentially make a Java EE application simulation on my laptop via only a web server?
EJB need an application server like JBoss, WebSphere, WebLogic, GlassFish, etc.
Pure web servers like Tomcat or Jetty cannot run EJB.
All application servers can also function as a web server.
So the answer to your question is - no, you can't run EJB only via a web server but yes, you can run an application server on your laptop and use it to run web and EJBs.
A more technical explanation is that you need an EJB container to run EJBs and a web container to run servlets and JSPs. A web server has only a web container. An application server has both.
You need an EJB container to run EJB with all the features (i.e. transaction, security etc.). But if you are are using EJB3 you can use something like ejb3unit to unit test the functionality of the EJB classes.
http://ejb3unit.sourceforge.net/
You need a EJB container to run EJB applications. However, it is easy to run one on your computer, just as it is easy to run Apache server for HTML/PHP applications. Glassfish is an example server which contains an EJB container.
If you only want the EntityManager functionality from EJBs, then you can simply use Java SE. See here.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!
As the title suggests, this is in relation to Java EE and Glassfish in particular.
From what i've learned the application client is executed in some application client that has the ability to talk to glassfish. But there seems to be limitations to this regarding annotations.
Can someone give me an example of the difference in connecting to a glassfish application server from the two different application types?
What is the benefit of the application client approach, and what approach is the most commonly used when developing application clients for Java EE?
The code (work you need to do) associated with connecting to the app server in either case is not really all that hard... but it is covered in different docs.
These are the instructions on how to access an EJB from a stand-alone java application.
These are the instructions for using an app client to access an EJB from a Java EE 6 Application Client with GlassFish v3: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=view
Accessing an EJB from an application client gives you access to more of Java EE services 'automagically' than if you were working with the EJB 'directly'. You can cobble together access to some of these services in the stand-alone case, but the burden shifts onto the application developer/deployer to make that access work.
Creating a stand-alone application that accesses an EJB will seem easy, in the short term, and many folks will invest in that strategy. If they deploy their client application onto a large number of machines, the burden associated with a cobbled together service access strategy can become a burden.
Deploying an application client that uses the application client container is not free either. The advantage is the fact that you have the support of your app server vendor to overcome deployment issues.
If you are using GlassFish (v2.1,v2.1.1 or v3), you can also take advantage of Java Web Start support, which simplifies client application deployment a lot.
An application client is actually run in a container and has full access to Java EE resources defined on your server in the same way that a Servlet or EJB does. This would typically be used for some type of admin client, not a user application. Here is one explanation.
In addition to the Java EE Application Client, there is also the concept of a Thin Client, which allows access to some Java EE resources as well, but not as easily as the App Client. It usually involves using JNDI lookup with absolute names as JNDI references are not available. A typical case for this would be a standalone producer/consumer of JMS messages. It is basically a lighter weight option of the full App Client.
If you are simply creating a user application, you will most likely want to either use a Thin Client model, or a plain old application that simply consumes services from your Java EE app via servlet or web service calls.