Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm currently starting a new app development. The app architect insists we use JBoss5 because its "better". Do anyone has a wider definition of "better" (if its the case)?
I have experience using Tomcat5 and 6 in large scale applications with big user loads and it handles pretty well (IMHO). Both would be running over a RedHat6 in identical hardware conditions (in case the implementation matters).
Thanks in advance
To say that any tool or framework is just 'better' is ridiculous. It always depends on the situation, architecture, etc. You don't necessarily want to use a hammer to drive a screw.
I wrote JBoss in Action, so I obviously like the JBoss technology, but I'll be the first to say that JBoss can be overkill in many situations. For example, for the last two sites I've developed, it made more sense to build with Grails and deploy on a standalone Tomcat instance.
Its a bit unfair to say that all you get when using JBoss is EJB and JMS. JBoss offers many services and features, including:
Servlet/JSP container
JNDI
EJB
JTA
clustering
caching
JMS
Datasource / Resource management
JMX integration
OSGi support
web services
portals
Web Beans (Seam)
Some administrative consoles
an IoC container
etc.
The thing that attracts many architects to JBoss is its flexibility. It uses a plugin architecture that allows you to add and remove services. As other have said, in uses Tomcat as its Servlet container, so you can literally whittle JBoss down to where it is practically just a Tomcat server. What is the benefit of doing this? Future proofing if you think that you're going to utilize other features of JBoss.
These services in JBoss come pre-integrated and strive to provide a consistent deployment model that minimizes your effort in writing application logic or configuration to integrate them yourself. That being said, other frameworks like Spring also do a great job of supporting a uniform ways of integrating many popular libraries and frameworks. But since they focus on integrating 3rd party libraries, the interoperability between services is up to you. Because JBoss is building the services and the integration platform, they spend time developing (and providing support) for interoperability.
Some questions to ask when making a choice are:
Are you going to use standard JavaEE architectural components like EJB?
BTW, EJB can be run in standalone Tomcat using the JBoss embedded container, so if EJB is all you're using, then you still don't have to use JBoss
Are you going to utilize Web Services, Portals, JMS?
Are you looking into building with Web Beans or Seam?
What deployment platforms (Tomcat, JBoss, etc) does your IT, support, and development staff currently use? If you are going to use something new, you will incur additional cost to learn the new platform.
If you're selling a product that customers will deploy, what impact will it have on the customers' IT organization.
Are you going to need paid support?
You can find support for Tomcat through many companies (including Red Hat I believe).
You'll need to compare the costs, because I don't think JBoss support is cheap, though I haven't looked up prices lately.
Will you need to do any sophisticated clustering?
JBoss has some wonderful clustering capabilities, and you'll probably get good clustering support through Red Hat. Though, for full disclosure, I've never done any complex clustering with any other frameworks to be able to compare.
Are you going to need advanced transaction management (distributed transactions, 2-phase commits, etc)
Not to sound like a shameless plug, but the first chapter of JBoss in Action is available for free on the Manning website. Though we don't do a direct comparison between JBoss and other applications servers and deployment environments in the chapter, we do talk about the architectural differences a bit, which is relevant to your question.
I'm currently starting a new app
development. The app architect insists
we use JBoss5 because it's "better". Do
anyone has a wider definition of
"better" (if its the case)?
Funny, because JBOSS uses Tomcat as its servlet/JSP engine.
Sounds like "better" means "supports EJBs and JMS", because Tomcat out of the box has neither.
But that's not an issue if your application doesn't use EJBs or JMS.
And if you do need them, you can add them to Tomcat with OpenEJB and RabbitMQ or ActiveMQ.
I'd ask your app arch when the last time they wrote something besides Power Point slides or UML documents. The response might surprise you.
JBoss is an Application Server while Tomcat is a Servlet container
So JBoss may be better than Tomcat in the sense it contains it, plus other components. That's it.
If you're not going to use those other components, you're wasting resources. If you need those other components then Tomcat is not enough.
It depends, probably your Architect has something else in mind.
I wonder what would he say if you ask him directly?
It's not better, it's just more. JBoss includes Tomcat.
As #duffymo points out, JBoss uses Tomcat for its web container so better makes not much sense if we compare equivalent things (i.e. Tomcat and the web container part of JBoss). And if you are not going to use JTA, EJBs, JMS, JMX, etc, there is no real advantage at using JBoss, especially during development (Tomcat is lighter and starts faster, this is often appreciated by development teams).
There are some cases where you could prefer JBoss for production though (I'm still assuming you're not using EJBs, etc):
The production team is trained or used to use JBoss in production, tools (deployment, monitoring, etc) are tailored for JBoss.
The company has a support contract for JBoss (although you can also get support for Tomcat).
But I'm not sure this is what the app architect meant. I would try to discuss this choice with the architect, maybe he has a rationale explanation. And if really JBoss has to be used in production, you can always use Tomcat or Jetty during development.
If you use JBoss, you can pay Jboss.org for support. But it is not the case with Tomcat.
This is true, however RedHat (who bought out Jboss.org) will require you to change to one of their supported versions of JBoss
JBoss is J2EE specification compliant, it supports J2EE specification very well, such as EJB, JTA,JMS, JNDI and etc. Tomcat is only a servlet container, although it also supports a bit J2ee specification. When you want to use J2EE component, you should consider JBoss first.
Forgot a point, JBoss supports JMX very well, especially in version 4.*. I have experienced a project, it doesn't have a web UI, JBoss is used just as a platform and EJB container to integrate all the standalone application on it use MBean.
Related
I'm working in an infrastructure team(Jboss 4.02/Tomcat 5.5/Weblogic 8.1 servers)in my company...some of the weblogic java applications are moving to jboss/tomcat servers.So what are the criterias we need to consider whether we need to go for jboss or tomcat? which is the best option?
Thanks in Advance,
Rakhesh
The main difference is certainly the fact that JBoss is an application server and supports the full Java EE stack, while Tomcat is a servlet engine and supports only a small fraction of the APIs which are defined in Java EE.
So, your main criteria should be: Which APIs (Frontend, Business Logic, Persistence, Third-Party, ...) do you need?
You should not make this an easy decision. The fact that you are asking the question indicates that you probably did not have the chance to play around with both and familiarize yourself with the concepts behind Java Enterprise stacks (Java EE vs. Spring vs. DIY).
My advice would be to take the time to evaluate both system - it looks like you are able to use both.
If you don't need much, you're probably better off with Tomcat, which is small and easy to use, but can be a nightmare to configure if you need advanced functionality.
JBoss AS comes with a full and mature stack. Everything is just right in place and works fine - the price you'll have to pay is that it way bigger and will take longer to start / stop / redeploy.
But again: That's a serious decision with a high impact on pretty much everything...
Both Tomcat and JBoss are very easy to install - simply unzip a file, and start it with a script. Both Tomcat and JBoss have great support for products like IDE's, monitoring tools, and such.
But in your migration case, JBoss is a better choice. Chances are your Web apps need JNDI data sources and JTA transactions - these things come built in to JBoss 4+, whereas you would have to graft them on to Tomcat 5.x, with much effort. You old WAR's will find JTA and JNDI data sources with no trouble on JBoss. Tomcat can indeed add these features, but JBoss packages them nicely into the system nicely. So even if you have no EJBs or JMS, then JBoss is still a good choice because many apps do need JTA and JNDI.
But of course if you find EAR files for your apps, then Tomcat will not work. And then JBoss will deploy the EAR files nicely.
JBOSS uses Tomcat as its servlet/JSP engine, so it's JBOSS and Tomcat or WebLogic.
The answer depends on whether the original apps use EJBs or JMS services. If they do, you have to use JBOSS, because Tomcat doesn't support EJBs (unless you add OpenEJB) or JMS (unless you add something like RabbitMQ or OpenJMS).
If you don't use EJBs, and only have JSPs, JNDI data sources, and JDBC, then you can deploy your apps as WAR files on Tomcat and pass on the full Java EE stack altogether.
I think you should consider starting with different input data:
what are the applications requirements ?
what are the production constraints ?
which product suits well to the administration team?
Just write a matrix with the 2 products and those criteria and your choice will be done!!!
Jboss is far more heavy than Tomcat but could offer some value added while putting the application in place ? Do you have some Nagios/Tivoli or any other SNMP management infrastructure ? in this case you can finnd easily SNMP adaptors providing proprietray MIBs to manage your JBoss server...JMX Beans in old releases are a very conveniant way to administer such tool
HTH
Jerome
I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?
My model application is a solid thing, starting, running and stopping as a whole and solely at the host.
It has a database storage, and communicates to user and other servers, clustering required.
It has web-part. It's just a standard big application.
JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.
Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).
For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.
So, why somebody still choose JBoss - what are benefits?
I favors more standalone application approach, but need more facts to understand better and convince others.
It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.
JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.
Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.
You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.
Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.
I would say the only reason to use JBoss is if you need to access the Java EE services (like Messaging, container-managed transactions and similar).
Keep in mind JBoss is (roughly described) Tomcat plus Java EE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:
If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
If you application requires Java EE services, use JBoss
Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the Java EE services or you were over-engineering the solution.
My manager has asked me to suggest an application server for web application development work.
What are the factors that needs to be considered before we select any application server for web application development in Java J2EE development?
If I select one now and IN future and I want to change to some other application server, is that minimum effort to change?
Apache Tomcat and Jetty are the two most popular web containers. Tomcat is the reference implementation of a Java servlet container, Jetty is a little bit faster and more lightweight. I personally favor Jetty, but you can't go wrong with either of them. A little comparison of the two can be found here.
Generally the migration of an application between web containers is fairly easy - only some configurations needs to be changed, but nothing in the source code(which is not always the case with full blown enterprise application servers).
The answer is that you can make it more or less difficult to change application containers based on your development practices. For example, the Liferay portal includes the custom XML configuration files for many application containers, allowing it to be used on many containers. So, it's certainly possible to switch flexibly, but you have to re-do all the server-specific configuration files and you can't rely on container-specific features.
In some cases, the containers themselves make it difficult. For example, the JBoss classloader has a history of scant support for the actual J2EE and Java EE standards. This makes it easy to rely on non-standard features, and in some cases nearly impossible to use standard ones.
Besides making sure that your application server enforces standards compliance, you do want to make sure you need a full application server, as opposed to just a servlet container as mentioned above. Does your application need EJBs, or just servlets? If you aren't doing EJB development, then an application server is over-kill.
If you are doing EJB development or otherwise using other EE features beyond what a servlet container supplies, consider ease of configuration and administration along side standards compliance, and I think you'll find a server that fits your needs.
A well written Java web application can be deployed on any web container, possibly with a bit of external configuration.
Hence you can choose the one that works the best for you during development, and then do testing on the target deployment server.
For netbeans, Tomcat is enclosed, and is fine. Eclipse does not have an enclosed web container yet, but Tomcat is supported.
In any case, use one that others use, then they can help you, and you them.
For pure development purposes, I would like a server with
Small footprint and very minimal start/stop time.
IDE plugins
So, my vote goes to Jetty for web app.
If you are on Netbeans, Glassfish is not a bad choice either as it shows superb performance via grizzly that uses NIO.
What are the primary reasons for using the Java EE (EJBs) over just a simple Servlet implementation?
I am working on developing a new project that will primarily be a web service that must be very fast and scalable.
Sorry for any confusion, Although I am experienced in Java, I am very new to the Java Web world, and may not be asking this question well.
Servlets are HTTP request listeners; they can't respond to anything else.
If you embed a great deal of logic in servlets it won't be available to any other clients.
Write your app in POJOs. Get it thoroughly tested without an app server involved. Then worry about how you'd like to package and deploy it. Servlet? EJB? Web service? Something else? No problem - those are just packaging and deployment issues. Get the behavior that you want working properly in POJOs first.
Spring can give you a lot of options here. I'd recommend it.
EJB's specification 1.x and 2.x added complexity that for most webapps was not needed.
Due this complexities the new frameworks appeared to simplify the development and the runtime architecture ( Hibernate / Spring / other microcontainers / others ORM frameworks ) .
EJB's 3.x matches this changes ( through JDO and JPA ) and now, using Servlets with these enhanced frameworks or Java EE with EJB 3 + would give you basically the same results.
Using a Java EE Application Server would add you a number of administrative advantages ( GUI to manage pools, logs, monitoring, transactions etc. ) With out them you may have the same result but you would have to do it all by hand ( editing configuration files that is ) Which may not seem too problematic, but if you plan to have an administrator for your webapp It would be better to use the admin tools that come out of the box with this servers.
Is the web service stateless? If so, I don't see any real advantage in using a full blown Java EE server over something lightweight like Tomcat or Jetty. You can deploy a jax-ws implementation with either of those, and do what you need pretty easily. If there's some kind of state involved, and you end up wanting to share that across multiple machines, that is where having Java EE can come in handy.
With that said, I don't think Java EE would decrease performance any at all. The app servers generally take longer to boot, and take more effort to manage, but once they are up and running the performance should be similar.
If your web services are likely to need any degree of "enterprise" features such as per-method security or transactions use EJBs.
With EJB 3 this is not actually very hard at all, a couple of annotations and you're done.
Otherwise simple POJOs behind a servlet are enough.
Alright, the question might be broad. We've been looking at Jboss and a few other similar app. servers.
From the feature list it would be perfect for replacing our soon to be outdated homegrown reporting application on the server side. But at this point, for 2 developers, just grasping all the setup, configuration, administration, tuning,testing not to mention the APIs and programming itself just seems way too much, too big, too complex.
What path does people take to become familiar and productive with such application servers ?
Start with a simple one, and only use a more complex one if you really need the features.
For example, Do you really need the full JBoss stack? Would Tomcat not be sufficient? It's much less of a handful.
I would approach this the same way I approach anything new.
Start with the documentation - read the introduction and basic setup/configuration documents. Then move on to tutorials and maybe some simple apps that I find interesting. In your case, maybe port a few features over to the new system. As time goes on, you should get better with the tools at hand.
From my experience using one is the best way to learn what you like/dislike about it. Once you have a project set up for one application server it should not be too much work to migrate it to another. I am currently working on an application that we develop & test daily using a simple Tomcat v6 server, but which runs in production on both Websphere Application Server and JBoss.
As a side note for your development, I strongly recommend looking into integrating your Eclipse development environment with your chosen application server through server adapters - it will greatly speed up development tasks and simplify the debugging process.
I'd say that the minimum features for using Java EE are:
Servlets and JSPs, written using JSTL (no scriptlets)
JDBC
JNDI for pooling database connections (optional but recommended)
Basic authentication for security
You can accomplish a great deal knowing just those. If you want to minimize the learning curve, I'd recommend starting with those and staying away from EJBs, JMS, Struts, JSF, etc.
Another benefit is that this subset of features is common to both servlet/JSP engines, like Tomcat, Jetty, Resin, etc. and full-blown Java EE app servers like WebLogic, JBOSS, WebSphere, etc. An app that runs on one should be portable to any of the others, as long as you stay away from app engine-specific extensions.
You should realize that there's a trade-off here. You'll have to develop pieces that might be easier if you leverage the app server more. But hopefully you'll start with some simpler problems and work your way up once you're comfortable with the basics.
There's another approach: Hire an experienced guide to help you with training and mentoring for the first project. A six-month gig with a reputable consulting firm might get you started.
Last of all, I'd recommend Spring. It would also have a learning curve, but it's a good alternative to Java EE EJB development.