Does anyone know if it's possible to start/stop an EJB within my application code? Eg. I have some MDBs that I wish to selectively start/stop while my application is running? Any ideas? Can this maybe be done via JMX?
Cheers!
The EJB spec has no mechanism to start/stop individual EJBs (or even modules) within an application. It is possible to start/stop applications dynamically using JMX via JSR 77.
(I see you're using the jboss tag. I have no expertise in JBoss, so I don't know if it provides extensions that support what you want to do.)
An EJB is not something that can be "started" or "stopped". Sure, it has a life cycle but that is more concerned with creation, activation, passivation and removal of EJB instances, and it's entirely up to the EJB container to manage the life cycle.
In short: you can't manage an EJB's life cycle programmatically.
Each deployed MDB has a management MBean. The MBean class is org.jboss.ejb3.mdb.MdbDelegateWrapper. The JMX ObjectName varies between versions of JBoss 4, and vary depending on how you deployed them. Assuming you deployed an MDB called MyMDB in a jar called myapp.jar which was in an ear called myapp.ear, the name might be:
jboss.j2ee:ear=myapp.ear,jar=myapp.jar,name=MyMDB,service=EJB3
Older version of JBoss 4 also had a system hashcode in there. And if you're not using EJB3, I think the service will still be there only it will be EJB2.
Anyways, once you find the management bean, you can call the stop and start operations. We use this frequently to pause message delivery.
Related
We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)
First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.
we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.
I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.
When would I choose to deploy as a JBoss SAR instead of an EAR?
This is more of a general question and I'm looking for guidelines that explain the pros and cons of each deployment model and which one is applicable when.
You will build a SAR (service archive) when you want to expand the capabilities of the server. For example, JBoss uses SARs for EJB deployer or messaging. You can create one for your own service monitoring (ie. watch some metrics for one of your custom services). As far as I know SARs are unique to JBoss only.
From my personal experience, I once created a SAR to keep track of a web service. I mainly used the service component to keep track of the length of a list of things that the web service component created. This was one way I could poke in the jmx-console and find out some metrics about the incoming requests to the web service.
SARs are based on JMX specs so it's not difficult to create them. You basically create a standard MBean interface and implement that interface. You will also want to make sure you that you have a jboss-service.xml file in the META-INF directory.
On the other hand WARs and EARs are for standard application packaging where you expect the container to manage and process requests for the application. You don't expect the application to be running as an anonymous service component like you do in case of a SAR packaged application.
Hope this helps!
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.
I ‘m trying to create a small EJB 3.1 application in which I want to use two application servers from two different vendors. (JBoss 6.1.0 Final and Glassfish 3.1). This is just to experience the taste of distributed applications and new features of EJB3.1.
This is the problem I’m having…
I have created a simple EJB (kind of a hello world ejb) and deployed it in GlassFish server which is running in the machine A. Let’s call it GlassFishHelloWorldEjb. This one has business remote and local views.
I have created another EJB project in which I have an EJB called JBossHelloWorldEjb. I have deployed it in the Jboss server which is running in the machine B.
Now I want to inject GlassFishHelloWorldEjb to a reference in the JBossHelloWorldEjb so that I can call it within the JBossHelloWorldEjb. Then I have a web app deployed in the Jboss which calls the JBossHelloWorldEjb.
MyWebApp(Jboss, machine B)-----> JBossHelloWorldEjb (Jboss, machine B)----> GlassFishHelloWorldEjb(GlassFish, Machine A)
I tried many ways to inject the GlassFishHelloWorldEjb in to the JBossHelloWorldEjb but failed. Could some please shed some light to achieve this.
Would greatly appreciate if you could show me the way to do this through both INJECTION and Programmatic JNDI look up.
Cheers
Lekamge
one option might be to use Spring RemoteEJB Proxies
OR. import client required jars for remote and write your own wrapper
Since EJB 3 we have embeddable EJB containers, JPA implementations can be used without an application server, there is Weld for contexts and dependency injection and so on. Since on many systems is only Tomcat available, I wonder, if Java EE could be used without an application server but with a Servlet container like Tomcat.
What would I have to do to set up an Java environment? What drawbacks do you see?
Note that Tomcat is an Application Server. That said, in October we released Apache TomEE which is Tomcat with the missing JavaEE parts added, then Java EE 6 certified using the official TCK from Oracle.
The stack evolved from what used to be simply called "OpenEJB/Tomcat", which was a useful stack with a bad name :) Commonly overlooked because of the "EJB" part, meanwhile it also delivered Transactions, JMS, WebServices and more to Tomcat. The new name is far better and now it's officially certified like JBoss or GlassFish. We're pretty excited about its future.
If I understand well, you want to use EJB3/JPA within a servlet container.
There are not only stand-alone implementations of JPA, but also embeddable EJB3 container, such as OpenEJB or Glassfish embeddable container. So nothing prevents you from starting such an embeddable container from the Servlet container to use EJB3.
(Note: I don't know all the details about transactions. In a full-blown app. server, you have JTA and a distributed transaction manager. You don't have that in a Servlet container such as Tomcat. JPA works with JTA and plain JDBC, but I don't know exactly how an embeddable container work without JTA. Still, I guess that would work given that such embeddable containers are also meant for unit-testing where I guess there is no JTA distributed transaction manager.)
Another approach would be to use Spring. Spring and EJB3 have indeed become very similar. You can start the Spring DI container within the Servlet container and benefit more or less from the same facilities as EJB3 (declarative transactions, etc.). See this post about Spring vs. EJB3.
All these technologies have become pretty modular, especially with Java EE profiles. You can use Sevlets, EJB3, JMS, JPA, even JTA somehow independently of one other. You can also create an environment where you cherry pick the ones you would like, either with Spring or with Java EE. The question is when does it stop to make sense and rather use an app. server with everything available and easily manageable. I think Servlet/EJB3/JPA is the limit, if more is needed go for an app. server.
You will generally require some kind of container, even if that container doesn't provide Java EE-related services. After all, you do need a long-lived JVM process to host the code that you're executing. Tomcat and Jetty will do the job nicely, and in addition to basic servlet services, provide a few useful extras that will be relevant, like connection pooling.
J2EE without application server was introduced years ago by me (Guy Pardon, from Atomikos), with this seminal article: http://www.onjava.com/pub/a/onjava/2006/02/08/j2ee-without-application-server.html - focused on JMS and JDBC at the time.
In general it's easy to setup thanks to Spring and Hibernate. Actually, I got inspired to do this after doing a Java EE project and being confronted with the XML hell associated with app servers and EJBs. Without application server things suddenly became a lot simpler and more testable.
If you need a Tomcat installation then can be a bit more of a hassle to configure, but recently Atomikos has introduced out-of-the-box Tomcat integration as part of its commercial offering at http://www.atomikos.com.
HTH