What is the clear difference between embedded EJB containers Vs the actual server containers which are used in production.
I can find 2 sceanrios.
For eg. glassfish-embedded-static-shell.jar - which does not have any implementation and depends on the local installation of a glassfish server.
Like OpenEJB - which requires just the jar to be added to the classpath and no installation as such.
AFAIK, both are called embedded containers. So, what is the real meaning of it?
Also, does an embedded container have all the features supported by the EJB specification?
A server EJB container is launched as part of an application server application and usually has deeper integration with other services and technologies included with the application server. An embeddable EJB container is launched by your application when you get control (e.g., because your class has a main method, and you want to have EJBs). For this reason, an embeddable EJB container is convenient for unit testing.
An embeddable EJB container may but is not required to have all the features supported by the EJB specification. Table 27 (section 21.1) of the EJB 3.1 spec lists the features required by an embeddable EJB container. In particular, an embeddable EJB container is not required to support:
Remote EJBs (as a client or as a server).
Webservices
Timers
MDBs and Entity beans
Related
I am trying to understand the implementation difference between creating a local or remote interface for my stateless session bean however I see various solutions and am wondering if there is a certain "standard" or general "preference".
For local interface, I can create everything (servlets, session bean, jsp) within a Java EE Enterprise Application project.
For remote interface, do I need to create the remote interface in a Java Class Library or Java Application or Java Web Application? Then the remaining code is within a Java EE Enterprise Application project...
Also, what is the reason for creating a session bean in a Java EE Enterprise Application Project instead of a Java Web Application Project?
Thank you!
I am trying to understand the implementation difference between
creating a local or remote interface for my stateless session bean
however I see various solutions and am wondering if there is a certain
"standard" or general "preference".
The main difference is that remote interface are coarse grained and the call is by value. While local interface are fine grained and the call is by reference.
For remote interface, do I need to create the remote interface in a
Java Class Library or Java Application or Java Web Application? Then
the remaining code is within a Java EE Enterprise Application
project...
if you have a remote interface, it has to be packed in a separate .jar file. The .jar file has then to be included as a dependency in your main project (on the application server) and distributed to your remote client.
Also, what is the reason for creating a session bean in a Java EE
Enterprise Application Project instead of a Java Web Application
Project?
Since ejb 3.1 specification, an ejb can be packed directly in a .war file.
In the old J2EE days an ejb could only be packed in a .jar to be included in a .ear file.
In my theory spring boot is capable of running java web application stand-alone. It says it has a own embedded servlet container and can use JNDI itself.
I built a war file before (spring-mvc, security, gradle built), but Spring boot assemble jar file and it runs on any machine which has JVM.
So my question is, if I made a spring boot based web app (contained JSP files & JNDI for looking up datasource), although it has own embedded servlet container and packaged jar file for running standalone, do I still need to package it as WAR file and deploy it in WAS (Websphere Application Server) or servlet containers for any reasons such as performance, stability, scaling-out etc?
WAS is an full blown Java Enterprise Application Server, on the other hand you have Spring that only requires a Servlet Container (Servlets are a part of full JEE).
Servlet Containers are for example: Tomcat, Jetty, but also WAS.
Spring Boot is able to package the complete application TOGETHER with the code of Tomcat in an JAR, so that this jar contains the Servlet Container and your Application.
Do I need a additional WAS for performance, stability, scaling-out etc?
Performance: No - There should be no important performance differerence between Tomcat and WAS when you run a Spring-Application. (Only that Tomcat needs less memory for itsself)
Stability: Tomcat and WAS are both very mature products.
Scaling: You can build a cluster of Tomcats by your own.
The main features of WAS over Tomcat are:
- WAS supports EJB and CDI (Tomcat would need TomEE for this), but Spring will not use it, because it is its one Dependency Injection container
- WAS has more Monitoring features, but this does not matter, because Spring Boot has Actuator
#See Difference between an application server and a servlet container? for more details
Simple answer is No. You do not need any Full blown application servers for any of the reasons that you mentioned (for performance, stability, scaling-out). You can just do fine with tomcat
Edit
Looks like you are using only JNDI feature from the Application server. Do you really need JNDI when you pack your servlet container along with your application ? I don't think so. That days are long gone.
JNDI really shines when you have to move an application between
environments: development to integration to test to production. If you
configure each app server to use the same JNDI name, you can have
different databases in each environment and not have to change your
code. You just pick up the WAR file and drop it in the new
environment.https://stackoverflow.com/a/7760768/6785908
(If you still need JNDI to be used to look up your data source refer: https://stackoverflow.com/a/24944671/6785908).
No, still I do not really see a reason for packaging your application as WAR and deploy it to traditional application server. That being said, if you have some existing infrastructure lying around and you are being forced to deploy to existing WAS (or WebLogic or JBoss any application server for that matter) server, then I rest my case :).
I am working on a Server Migration Project from Weblogic to Websphere. The problem is that in Weblogic, we are already using a class specified as Startup-class in Weblogic (and arguments to the class like log4j config file) which is present in a jar which is added to Weblogic classpath by editing the startup script. This jar initializes a global log4j file which is for all the apps deployed on the server and not for any particular app. Each app is distinguished by a category of log4j.
Now I could not find a similar thing in Websphere. So what is the best solution? I can create a new application which would do all initializations like that of the startup classes. I thought of using startup-beans but read in some IBM documentation that they are deprecated due to EJB 3.1 Session Beans. Also how to make sure this app loads first? By giving Websphere xml file startup weight 1 like here?
I am using Weblogic 6.3.2 and Websphere 8.5
The WebSphere migration toolkit suggests to replace the WebLogic T3StartupDef and T3ShutdownDef implementations with either a ServletContextListener implementation, session startup bean (Singleton), or a servlet that is configured to load at startup time. If you haven't used the WebLogic to WebSphere migration toolkit, check it out. It provides a lot of help especially with deployment descriptor extensions.
The #Singleton session bean in EJB 3.1 replaces the proprietary WebSphere startup bean.
The best approach depends on the type of module you need the startup logic.
If you are considering the custom services option, note that the com.ibm.websphere.runtime package is not available in Liberty if you are considering the Liberty server.
It sounds like custom services (or a custom feature on Liberty profile) are the best analog if you need to run logic during server startup. Otherwise, if you just need to add a library to every application, then create a shared library and then either associate it with the server or associate it with specific applications or modules.
I am a newbie to this and read about WABs , but wish to clear the basic difference -
I mean using osgi embedded in tomcat and making a WAR vs making a WAB ?
When should one consider each option ?
1) OSGI embedded in tomcat
2) tomcat in OSGI
3) using a WAB
OSGi embedded in a container (not only Tomcat!) is likely the only option when you are forced to a traditional JavaEE WAR deployment model, i.e. an IT department operates the container and you can only deloy WAR files to it. This bootstraps a whole OSGi framework within the web application and allows modular development within the web application. The web application is then composed as a set of OSGi bundles. It can also be used to migrate/transfer an existing legacy web application into OSGi modules. However, this will be challenging.
I'd like to call the second approach (Tomcat in OSGi) as a pure OSGi approach. Tomcat or any other Servlet container (eg., Jetty) can be deployed as a bundle (or a set of bundles) in an OSGi framework. The OSGi framework is the container. You don't have the full separation of a web application anymore. The can intersect. Some bundles/modules may implement web functionality and others may not. Core functionality (core bundles) can be reused by other web bundles.
The third option is a result of new spec work in OSGi. Basically, it's a web application with an OSGi bundle manifest. Thus, the whole web application can be deployed as a single OSGi bundle on any framework with WAB support. Technically, the bundle may be deployed as a web application to a Servlet container. But it gets access to a BundleContext. This allows the web application to inter-operate with other bundles or web applications running in the same framework.
I would really like to use SpringSource dm Server, but our customer requires us to run our apps on their application server (Websphere). Is there a way to integrate SpringSource dm Server with other application servers? At least dm Server is build on OSGi, and many other application servers (including Websphere) are based on OSGi as well. Is it possible to run a SpringSource dm Server as a websphere component?
SpringSource dm Server is based on the Eclipse Equinox OSGi framework (and should not be confused with the Spring DM technology, included in dm Server, which can run on Equinox, Apache Felix, and Knopflerfish).
However, embedding dm Server in another application server, such as WebSphere Application Server, based on Equinox would be a non-trivial piece of work. It would be necessary to get both products to use the same version of Equinox, which they currently do not, then modify dm Server to support embedding in the server (e.g. to integrate with the host server's application invocation mechanism, thread pools, and class loading scheme).
If you think this support is important, please raise a requirement (which requires a simple registration) against dm Server.
Spring DM is deployed on a Knoplerfish OSGi implementation.
Websphere is deployed on an Equinox OSGi implmentation.
So the question becomes - are the two interchangeable? They both support R4, so I would say, yes, they are.
The next question would be to check dependencies, particularly with respect to things like HttpServices.
I would say this would be ok, but I think the final proof would be try deploying it. Easiest would be to drop the bundles into a Websphere deployment. You'll need your bundles and whatever spring bundles you're using.
I'm also interested in this topic. Another way of looking at this problem is that you want an application depoyable in both Spring dm server and a traditional app server (Websphere, weblogic, JBoss, ...).
The OSGi containers are embeddable inside non-OSGi applications, so it is theoretically possible to deploy an app to both Spring dm server and the same app + OSGi container to a traditional app server.
Now, as usual, the devil's in the details, including such topics of web development and bridging servlets between the outer app server and the OSGi container.
I do not think that this is really the case ...
see the following link for this: http://apsblog.burtongroup.com/2008/11/websphere-7-osgi.html
But it seems on the other side, that the trend is clear ... there will be a time when OSGI based application can be deployed on Java EE application servers