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
Related
I want to access to remote EJB running on Liberty Server from a swing Client like this :
Object found = new InitialContext().lookup(
"corbaloc:iiop:localhost:2809#ejb/ear/ejb.jar/package/Bean#com.package.BeanRemote);
I'm getting that error :
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or in an application resource file: java.naming.factory.initial
at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:691)
at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
at java.naming/javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:342)
at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
at com.package.ClassMain.main(ClassMain.java:43)
How is a connection to Liberty established?
Need help please
I'd strongly recommend you to re-architect your app to use JAX-RS (rest over http) instead of remote EJB. Just use Facade pattern and wrap your EJB as REST endpoints, and use Rest client on the Swing side.
There are several reasons:
remote EJB is almost dead technology now
http/rest is more firewall/network/container friendly
http/rest is more client agnostic - if you would later like to change your client from Swing to web/JS it will be much easier
But if you really insist, setting up remote EJB is not very simple.
The easiest would be to use Liberty Application client and run your Swing app from there.
If you cannot use that you will need to get traditional WebSphere Application Server Client, and use the client jar provided with that com.ibm.ws.ejb.thinclient_8.5.0.jar. If the client is running with a non-IBM java you will also need to add the orb jar onto the class path (com.ibm.ws.orb_8.5.0.jar).
See theses links:
how-to-set-up-thin-client-to-call-remote-ejb-on-liberty
Running the IBM Thin Client for Enterprise JavaBeans (EJB)
Using enterprise JavaBeans with remote interfaces on Liberty
So all in all, rewrite will be usually simpler and more beneficial.
If I have two java ee applications (Application A and B) in the same domain of web-logic cluster server with two managed servers, is it possible to call Application B running in a specific managed server(Can I choose the managed server?) from application A?
If I have just one java ee application deployed in a domain of web-logic cluster server with two managed servers(MS A and B), is it possible to call or start the application in the managed server B from application in the managed server A?
For #1, please provide more information on how Application A is going to call Application B. Is it EJB or REST or something else?
For #2, yes. Managed servers can be started using WLST scripting so you should be able to incorporate that logic into the other managed server, for example by having it invoke a script from its shell that contains the required WLST logic.
As the title mentions, what is the purpose of an Application Server Application-Client?
Scouring the web, there really isn't much explanation of what an Application Client for an Application Server is and what its' purpose is for.
From what information I can glean, an application client is like a browser in that they both access an application hosted on an application server, but the application client provides a better (graphical?) interactivity? Also it creates a container that allows access to an application server's resources, or it's Java EE resources?
But I still really don't understand how it all fits together or what it is exactly.
Simplify this, the client of some a A element, is some other element, that uses the A element to do something (e.g. one class object use other to do something)
Application Client is simply other application, class or component that uses, invokes or executes methods. If you wrote some class with some methods you can use this class as a part of other class. And then the second class will be a client of the first one.
You can develop some EJB component on application server in JavaEE and you can create standalone JavaSE application which will invoke methods from your component deployed on server. And then this standalone JavaSE application is your client for your component.
... an application client is like a browser in that they both access an application hosted on an application server, but the application client provides a better (graphical?) interactivity?
Not only browsers can be client applications. In JavaEE (Enterprise Edition) you can develop components and deploy them to the application server. Components contains special classes with only business methods (i.e methods that do something concrete). You provide some interface for your developed components on application server. Thanks to this interface client applications can invoke methods in components. Your client application that can use this component through provided interface can be JavaSE application, Web Servlet, JSP or other components.
You can read section 1.3.3 Java EE Clients to get further details from below tutorial:
https://docs.oracle.com/javaee/7/JEETT.pdf
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
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.