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
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.
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'm developing a web application in Java EE/Spring/SpringWEB.
A part of the application needs to communicate with mobile devices through TCP/UDP (not HTTP). I want that all infrastructure runs in the Java EE container (Tomcat for instance). I wonder whether there's any standard or part of the Java EE container (Tomcat) I can reuse for having a TCP Server for free?
I mean I do not want to implement my own TCP server which needs to be scalable/reliable and efficent. I want to reuse as much as possible and use standards where applicable.
Well, Tomcat is not a true Java EE server, but rather the web servlet part of the Java EE stack. There is no real official TCP server lib included in Java EE, except the Java SE socket libraries. I suggest you use the open source library Apache MINA for TCP/UDP server features. It should work with Tomcat. A full Java EE stack (glassfish, websphere, weblogic, geronimo..) might disallow setting up TCP listeners, so be careful if you migrate from Tomcat to a full java ee stack.
There isn't anything in Java EE, not sure about Spring. For implementing on your own, I would highly recommend using netty as the main building block for your tcp server.
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.
How can I connect a realtime application which has a totally different life-cycle with WebApp to JBoss or GlassFish?
I need it to create a realtime reporting system. Using Sockets is not possible.
Is it possible to attach an application rather than a web applications to Java application servers so they can work together?
Yes. Java EE defines application clients, that can be any java apps.
With some full Java EE profiles, connections via CORBA should be possible and you could then also use C++ clients.
Another option to hook up any client could be messaging.