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!
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.
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
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.
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 have been looking for a solution to create a modular web application, which is modular in the sense that user can provide its own plugin in form of a simple jar which will then provide its own data to my web application and my webapp will be responsible for displaying it.
Now the catch is i want my web app to be as generic as possible without relying on the j2ee web container to support anything . i.e. i cant rely on my web container to provide osgi support and deploy web application as an osgi bundle itself ( which truly makes things very simple for eg. glassfish and WAS).
I am planning to use equinox and only solution i see currently is the servlet bridge they provide on their official site, but to me it is really a pain to delegate everything to a servlet which will in turn interpret the request and find an apropriate bundle Class and then again communicate back somehow only the data to the web application.
To me it would be wonderful if my web app was also a bundle.
Is there anything close to this ideal solution which i can try for? Or any other communication method between the two relams of osgi and web appliction (container)?
The OSGi spec details the WAB (Web Archive Bundle) format.
And Pax Web offers great support for WAB/WAR webapps (PAX Web runs fine on Equinox, Felix, etc)
Using pax web you get the BundleContext via the ServletContext, eg:
BundleContext bundleContext = (BundleContext) getServletContext().getAttribute("osgi-bundlecontext");
For the user driven pluggability you mention, I'd suggested you provide some service interfaces for the plugin bundles to implement and in your webapp use a ServiceTracker to listen for their registration (unless you're using Declarative Services). You also easily be able to install bundles from an upload servlet.
I'm guessing users uploading plugins would have to be logged in and authorized, so security issues will have been met at this point.
EDIT: replying to comment here as not enough space in comment field
Apologies, think I misinterpreted you question - you have an existing webapp container(s) and you want to deploy a WAR with OSGi functionality? If that's the case then either use the ServletBridge as others have mentioned or embed an OSGi framework into your WAR (this is relatively easy, see this for example).
You could even make this optional by attempting to get the BundleContext from the ServletContext and if this returns null then launch your own embedded framework. That way it'll run in a native OSGi container (e.g. Glassfish) or in a Java EE app server.
Otherwise, PaxWeb is an implementation of the HttpService and WebApp OSGi specs, but with lots of extensions to make life easier - but you deploy this to an OSGi container.
You might want to look into Apache Sling. It is a web framework that has an embedded OSGi container. The OSGi container is called Apache Felix and is pretty good.
ServletBridge is for embedding an OSGI contianer within a web container. The other option is to embed a web container (as a bundle) in an OSGI container. The following article has some details on how to achieve this.
http://java.dzone.com/articles/osgi-and-embedded-jetty
You may want to try ChonCMS - http://www.choncms.com
Its architecture is based exactly on what you are asking, it comes with few plugins to enable base CMS functionality, it is modular platform with minor web app container using felix and plugins can be added/removed at run time as well.
Disadvantage might be that it has lack of documentation, but you may ask, it is open source, I'm sure they will be happy to answer questions, and even better you can contribute - it is still in incubation phase.