Can the web container and EJB container be in different Java EE servers for the same web application?
Like the web container is Tomcat and the EJB Container is JBoss?
Is this possible if the Web server and App server are on different machines?
Yes, all of this is possible and such setups are not at all uncommon in enterprise settings. After all, EJBs were desigend as business services to be used by multiple clients, not necessarily web applications.
Yes they can.
EJBs was initially a distributed architecture based on CORBA. Later (in EJB 2.0) local interfaces were introduced to avoid the expensive cost of distributed communication, but still you can provide remote interfaces to your EJBs to enable access from a remote Java VM.
From the JavaEE CORBA overview:
EJBs use the RMI/IDL CORBA subset for their distributed object model,
and use the Java Transaction Service (JTS) for their distributed
transaction model. When Enterprise JavaBeans are implemented using the
RMI-IIOP protocol for EJB interoperability in heterogeneous server
environments, the standard mapping of the EJB architecture to CORBA
enables the following interoperability:
A client using an ORB from one vendor can access enterprise beans residing on an EJB server provided by another vendor.
Enterprise beans in one EJB server can access enterprise beans in another EJB server.
A non-Java platform CORBA client can access any enterprise bean object.
Related
We are required to build some Java JAX-RS web services that will connect to some other external web services to retrieve data. Logically, we should host these new JAX-RS web services on a container like WebLogic. Due to cost saving measures by management, we are told to use IIS to host these JAX-RS web services as it is supposedly cheaper than WebLogic. They want the services to be written in Java because it is OS independent, so using .NET is out of the question.
(1) Is using IIS to host Java JAX-RS web services instead of a fully J2EE compliant container like WebLogic to save cost a good idea?
(2) How do we host Java JAX-RS web services on IIS 7.5? What are the required add ons?
Thanks in advance.
First of all, IIS does not support Java. See this old post in MSDN (2005)
IIS can never directly support the use of JSP because it requires an add-on to run Java code in a JVM to Load,
Therefore you always require a J2EE server to execute J2EE services, and the IIS add-on isapi_redirect (see the link). The add-on will capture the requests and forward them to the J2EE server (in the example is used tomcat)
So the answer to your question
(1) Is using IIS to host Java JAX-RS web services instead of a fully J2EE compliant container like WebLogic to save cost a good idea?
No, because you allways need a J2EE server., so the cost parameter is non applicable (without considering other aspects). I suggest also to consider some free of charge servers like Jboss, Tomcat or Jetty
Note also you do not need a fully compliant J2EE server to use JAX-RS. Latest versions of JVM are shipped with an implementation of JAX-RS.
I found this bit of information about the ACC (Application Client Container):
The ACC uses the IIOP ORB to contact the server during injection. The
default port for the ORB is 3700. The Java Web Start support
automatically sets the ORB-related properties to point to the correct
ORB address. If you are running a cluster then this includes all
currently-active cluster members' ORBs.
https://www.java.net/node/679235
However, the documention, in general, seems light. While it is mentioned in the Development Guide:
Introducing the Application Client Container
The Application Client Container (ACC) includes a set of Java classes,
libraries, and other files that are required for and distributed with
Java client programs that execute in their own Java Virtual Machine
(JVM). The ACC manages the execution of Java EE application client
components (application clients), which are used to access a variety
of Java EE services (such as JMS resources, EJB components, web
services, security, and so on.) from a JVM outside the Oracle
GlassFish Server. The ACC communicates with the GlassFish Server using
RMI-IIOP protocol and manages the details of RMI-IIOP communication
using the client ORB that is bundled with it. Compared to other Java
EE containers, the ACC is lightweight. For information about debugging
application clients, see Application Client Debugging.
GlassFish Server Open Source Edition Application Development Guide Release 4.0
also:
The Application Client Container.
Although accessing an EJB from a client using JNDI is simpler than in
EJB 2.x, it is still rather awkward. The good news is that we can
dispense with JNDI altogether if the client runs from within an
application client container (ACC). The EJB 3 specification does not
mandate that an EJB-compliant application server provides an ACC but
makes its inclusion optional. Consequently not all EJB-compliant
application servers provide an ACC, however GlassFish does.
http://www.developer.am/ejb3/?page=application-client-container
it's more of a general description. There's no official documentation on the ACC and its usage specifically?
The Application Development Guide contains some sections (only available as PDF?):
https://glassfish.java.net/docs/4.0/application-development-guide.pdf
https://glassfish.java.net/documentation.html
Is the "Application Client Container" (see here) the same as the "Embedded Enterprise Bean Container" (see here)?
The two descriptions sound like the same thing to me, but I was wondering whether I am missing something. Or why are two different terms used? How are these two terms related?
Though it's not immediately apparent, they're quite different.
Application Client Container (ACC)
...The ACC manages the execution of Java EE application client components (application clients), which are used to access a variety of Java EE services...outside the Oracle GlassFish Server. ACC communicates with the GlassFish Server using RMI-IIOP
Embedded Enterprise Bean Container
... The container and the client code are executed within the same virtual machine
The difference
ACC only enables connectivity between a client application (a consumer of Java EE components) in a remote JVM. That is, you'll have a Client A running in JVM A1, connecting to Glassfish Server, running in JVM B1. By itself, ACC doesn't have ability to support the goodies of JavaEE (EJBs, Security, Interceptors Transactions etc).
The EEC on the other hand is basically an API that will provide all that functionality within a single JVM. That is you can develop a small Java class with a main method and provide all those goodies within that single main method.
Have a look at the code sample from Oracle
//Adding this line to a main method effectively puts a Java EE container within that JVM, without having to install anything
EJBContainer ec = EJBContainer.createEJBContainer();
In summary, ACC - Connect to JavaEE container in a remote JVM, EEC, provide JavaEE container functionality within a local JVM
I am trying to understand the difference between a full fledged application server (e.g. Weblogic, JBoss etc.) and a servlet container (Tomcat, Jetty etc.).
How do they differ and when to use which?
Thanks,
A servlet-container supports only the servlet API (including JSP, JSTL).
An application server supports the whole JavaEE - EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.
It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology.
Broadly speaking, a servlet container restricts itself more or less to the implementation of the J2EE Servlet specification. Also, it's focus is on the runtime environment and not so much on providing additional tools.
In contrast, a full fledged application server implements the whole J2EE stack; plus it comes with all the enterprisey tools and integration possibilities. An application server usually has advanced administration interfaces, it supports clustering and other features used mostly in high-end systems development.
For a beginner, it's probably better to stay with a simple servlet container, since the learning curve there is much less steep.
Edit
#Apache Fan: It depends on the specifics of your situation like existing systems and future plans among other things. I don't think a generic flowchart approach is applicable here.
Platform selection is usually done by weighing specific requirements against first-hand knowledge of systems under consideration.
However the question gives no clues as to what the evaluation criteria are. Should it be open source? Is around-the-clock vendor support necessary? What kind of an enterprise environment should the system integrate with? Are licencing fees an issue? Any must-have technologies or tools? Etc.
Without knowing the above it's pretty much shooting in the dark.
Basically an application server in Java EE context is a software installed on a server and that implements one Java EE specification (Java EE 7 for example). That means such software (application server) must be able to run Java EE application.
Java EE defines 4 domains, the so called containers:
Applet container,
Application client container,
Web container, and
EJB container.
Two containers are part of the application server (EJB and Web container) and two others are part of the client-computer.
JBoss and Weblogic are application servers, Tomcat and Jetty are web container. That's why JBoss and Weblogic can deal with more technologies than a Web container. Application server can manage EJB.
Servlet container is not the appropriate expression to qualified Tomcat and Jetty because it is more restrictive. Tomcat can also execute JSP and JSF, not only Servlets.
afaik, websphere and jboss are fully compliant j2ee-server that can run beyond servlets, like EJB, whereas Tomcat is just a servlet container and you can't run EJBs on it.
In Layman terms :
A web Server means: Handling HTTP requests (usually from browsers).
A Servlet Container (e.g. Tomcat) means: It can handle servlets & JSP.
An Application Server (e.g. GlassFish) means: *It can manage Java EE applications (usually both servlet/JSP and EJBs).
For a beginner, it's probably better to stay with a simple servlet container.
I have a stand-alone, Swing application that uses Hibernate for its persistence layer. I need to extend this to a three-tier system, so that there will be multiple instances of the Swing application and a central server. The client is a stock trading platform, so it will contain a lot of business logic. The server will be responsible for mostly persistence operations and some business logic.
What would be the best way to implement the server for my needs? EJB3 or Spring? What is the best practice for Swing applications to interact with a server? I don't want to go with RMI since not only is it becoming obsolete but also there is no guarantee that the clients and the server will be on the same network.
If the client is a Java client, I don't see the point of using web services (and thus having the overhead of the object to XML serialization) and I would go for EJB 3.x.
For me, the major benefits (beyond performance and scalability) that you get with a good container are fault-tolerance and fail-over (both on the server side and client side, especially with Stateless Session Beans if they are idempotent). For a stock trading platform, this matters.
Also note that using EJB3 doesn't necessarily exclude using Spring for the glue (on the client side and/or the server side).
And if the need to expose your services as web services should arise (e.g. for another non Java client), just annotate them with JAX-WS annotations.
I don't want to go with RMI since not
only is it becoming obsolete
This isn't true at all. As long as Java is around, you'll have RMI.
And what do you think EJBs are using to communicate? It's RMI.
but also there is no guarantee that
the clients and the server will be on
the same network.
Personally, I'd prefer Spring. You can expose your service layer using web services or HTTP remoting.
Go with Spring and RMI. If your client and server are both Java it is the best solution with best performance and productivity.
Note that EJBs don't necessarily use RMI as the transport protocol. OpenEJB for example uses its own custom protocol. We get about 7300 TPS over the wire which is pretty good. There is a Spring integration as well so if you wanted, you could build the server with Spring and inject Spring beans into EJBs and vice versa:
http://openejb.apache.org/3.0/spring.html