.NET Refugee looking at Tomcat, Sun AppServer, Javabeans, servletts,JBoss, Struts...Oh Dear

[dean]

I have come up with an idea for an application that would benefit from
being truly platform independant so I am looking at implementing it
using Java technologies. However I am a little confused about all the
different technologies.

I have downloaded the J2EE SDK and started reading the Doco but I fear
that taking that route will leave me reading doco for the next two years.

The first question is are Appserver and Tomcat competing technologies or
has Sun taken Tomcat and extended it, or is Tomcat a cut dow version of
AppServer?

Can I run other services, such as a PHP Application or a subversion
(through WEBDAV, I think it is) through either of these, I think tomcat
can run on its own or through another apache installaion, Is this correct?

If I write a webservice and test it using AppServer will it run on
Tomcat or Vica-Versa?

Is the main difference in licensing and slick administration interfaces?

Additionally

I understand that servletts are similar to server web controls, but what
exactly are Enterprise Java Beans and where do you use them? What are
JBoss and Struts?

The application that I am looking to create will be pretty strait
forward. There will be a rich client application accessing some web
services, and an "auto-update" function and some web pages that will
have some simple administration functionality. Do I even need J2EE or
will the J2SE be sufficient?

Is there somewhere I can go to get a reasonable overview of all these
technologies quickly?

Thanks for your time.
Dean

 

[Aquila Deus]

I have come up with an idea for an application that would benefit from
being truly platform independant so I am looking at implementing it
using Java technologies. However I am a little confused about all the
different technologies.

I have downloaded the J2EE SDK and started reading the Doco but I fear
that taking that route will leave me reading doco for the next two years.

The first question is are Appserver and Tomcat competing technologies or
has Sun taken Tomcat and extended it, or is Tomcat a cut dow version of
AppServer?

Tomcat is a servlet/jsp container (like ASP.NET host), which is a small
but most-frequently-used part in J2EE. Usually people use app server
only when they need EJB. EJB has no direct alternative in .NET, because
windows takes the job of hosting components.

Can I run other services, such as a PHP Application or a subversion
(through WEBDAV, I think it is) through either of these, I think tomcat
can run on its own or through another apache installaion, Is this correct?

App Server can't host anything other than servlet/jsp and ejb. And
tomcat doesn't depend on apache.

If I write a webservice and test it using AppServer will it run on
Tomcat or Vica-Versa?

There isn't a software called App Server. The biggest three are BEA's
WebLogic, IBM's WebSphere, and Oracle's app server. If you're refering
to the one in J2EE SDK, I must tell you nobody uses it in productivity
environment as far as I know ;-)

Besides, Tomcat isn't the only servlet/jsp container. Resin, Jetty and
the three top app servers also do the job.

Is the main difference in licensing and slick administration interfaces?

I hope so

As I know the top 3 app servers aren't 100% compatible, neither are
resin and tomcat. While most of parts follow J2EE standard, you still
need to change webapp-specific configurations and perhaps modify some
code when you move from one server to another.

Additionally

I understand that servletts are similar to server web controls,

Its concept isn't like ASP.NET's web controls or page. You could think
servlet as something that listens on a url (e.g.
http://dotcom/myServlet) and handles requests to it.

but what exactly are Enterprise Java Beans and where do you use them?

like DCOM components.

What are JBoss and Struts?

JBoss is an open-sourced app server. It uses tomcat for hosting
servlet/jsp contents.

Struts is the most popular but very primitive MVC framework. It lacks
support for UI components and I seriously doubt if it can increase any
productivity at all.... Our main business are developing web-based MSI
system and even ASP.NET is not helpful for that, due to its almost zero
integration with javascript.

PS: I'm using AJAX for new project now.

The application that I am looking to create will be pretty strait
forward. There will be a rich client application accessing some web
services, and an "auto-update" function and some web pages that will
have some simple administration functionality. Do I even need J2EE or
will the J2SE be sufficient?

Would you need to use COM if it's on .NET? If not then you don't need
EJB.

J2SE isn't sufficient - it's just for basic things and GUI. It's the
J2EE that covers servlet, jsp, and ejb etc.

Is there somewhere I can go to get a reasonable overview of all these
technologies quickly?

just here

 

[Jon Martin Solaas]

I have come up with an idea for an application that would benefit from
being truly platform independant so I am looking at implementing it
using Java technologies. However I am a little confused about all the
different technologies.

I have downloaded the J2EE SDK and started reading the Doco but I fear
that taking that route will leave me reading doco for the next two years.

The first question is are Appserver and Tomcat competing technologies or
has Sun taken Tomcat and extended it, or is Tomcat a cut dow version of
AppServer?

Tomcat is a web-container that runs servlets and jsp-pages (and serves
other web content). Sun has included tomcat in their AppServer to make
up a complete J2EE AppServer.

Can I run other services, such as a PHP Application or a subversion
(through WEBDAV, I think it is) through either of these, I think tomcat
can run on its own or through another apache installaion, Is this correct?

You can run tomcat with apache as frontend, just as you would run php
with apache as frontend. I'd be surprised if no-one has come up with a
way to use tomcat as frontend to php too ...

If I write a webservice and test it using AppServer will it run on
Tomcat or Vica-Versa?

That should be pretty much the same thing. But if you'r webservices run
on top of EJB's, tomcat is not enough alone.

Is the main difference in licensing and slick administration interfaces?

Between tomcat and appserver? No. Appserver is a full J2EE-stack. The
most important functionality in addition to what tomcat offers is an
ejb-container.

Additionally

I understand that servletts are similar to server web controls, but what
exactly are Enterprise Java Beans and where do you use them? What are
JBoss and Struts?

JBoss is similar to Sun AppServer, it's a full J2EE stack. Like Sun
Appserver JBoss uses tomcat as it's webcontainer. Struts is a MVC
framework that helps you make web-applications. Most common is to use
JSP as View in Struts applications. There exist literally tons of web
application framework for J2EE/Java, but Struts is most used. Struts is
useful, rock solid and has become an industry standard. Still, if you
come from the .Net world you may find it a little bit old-fashioned and
may want to check out other frameworks as well.

All in all the best-of-breed-philosophy in the java world really
requires you to give some thought to choice of thechnology ...

Enterprise Javabeans are components that live inside an EJB-container
that offers services as distribution and transaction management. Various
types of EJB's exist; Sessionbeans the most common, Entity beans for
database access, Message Driven Beans for asynchronous messaging and
so-forth. Some people complain that EJB's are difficult to use, but it's
not. They might be overkill, though, if you don't need all the services
of the EJB container. Like with .Net it is important to have nice tools,
and in the Java world you have a lot to choose from. Eclipse with
various plugins, Netbeans, Oracle JDeveloper, Borland JBuilder etc. etc.

The application that I am looking to create will be pretty strait
forward. There will be a rich client application accessing some web
services, and an "auto-update" function and some web pages that will
have some simple administration functionality. Do I even need J2EE or
will the J2SE be sufficient?

Well, you'd definitely need *parts of* J2EE. It's impossible to make
webservices and webpages otherwise, because that is per definition part
of J2EE. So is JDBC, which is the technology to access databases in
Java. (JDBC is so commonly used that it's distributed with the J2SE
JDK, even though it's part of the J2EE standard.)

What you don't need is a full J2EE appserver to do what you want, you
may choose to use only tomcat and skip EJB's. For persistence you may
instead use Hibernate, or just plain JDBC-calls (which is what most
other persistence technologies run on top of anyway), and the rich
client gui may be implemented using Swing. If you need transactions, you
really should facilitate EJB's, putting your JDBC code in a stateless
sessionbean and have transactions managed for you really isn't very
difficult compared to have your ordinary POJO JavaBeans scattered with
connection.rollback();

For the auto-update function you should look into WebStart.

Is there somewhere I can go to get a reasonable overview of all these
technologies quickly?

Well, Sun has their J2EE tutorial, and there are free books available at
www.theserverside.com. Sun also has their reference applications to
display all bells and whistles of J2EE. This seems to have made people
believe they really need to use all available J2EE technologies at once,
in every application, making J2EE apps look like mastodonts. A couple of
years ago Microsoft implemented the Petstore reference application in a
"thin" version on top of SQL Server (using lots of stored procedures
which makes sense in the Microsoft world, but not in the multiplatform
Java world), outperforming the bloated original Java version. This seems
to have made java-people realize that it's entirely possible to use J2EE
as a toolbox from which one can pick only selected technologies, instead
of using everything at the same time.

Also you could learn a lot by downloading some nice tools and poke
around. I use JDeveloper from Oracle. I think they've made it completely
free recently, and it's entirely possbible to develop using JDeveloper
and deploy to a free server like JBoss.

 

[dean]

Tomcat is a servlet/jsp container (like ASP.NET host), which is a small
but most-frequently-used part in J2EE. Usually people use app server
only when they need EJB. EJB has no direct alternative in .NET, because
windows takes the job of hosting components.

I have done some (quite alot) more reading and now realise that J2EE is
really a collection of Jave web stuff, different groups implement
different bits.

App Server can't host anything other than servlet/jsp and ejb. And
tomcat doesn't depend on apache.

What I am getting at here is that tomcat does not *need* an apache
installation but if there is one you can configure a module to process
jsp pages for web sites being served from that installation.

There isn't a software called App Server. The biggest three are BEA's
WebLogic, IBM's WebSphere, and Oracle's app server. If you're refering
to the one in J2EE SDK, I must tell you nobody uses it in productivity
environment as far as I know ;-)

Yep that's the AppServer I meant

Besides, Tomcat isn't the only servlet/jsp container. Resin, Jetty and
the three top app servers also do the job.




I hope so

As I know the top 3 app servers aren't 100% compatible, neither are
resin and tomcat. While most of parts follow J2EE standard, you still
need to change webapp-specific configurations and perhaps modify some
code when you move from one server to another.




Its concept isn't like ASP.NET's web controls or page. You could think
servlet as something that listens on a url (e.g.
http://dotcom/myServlet) and handles requests to it.




like DCOM components.




JBoss is an open-sourced app server. It uses tomcat for hosting
servlet/jsp contents.

Struts is the most popular but very primitive MVC framework. It lacks
support for UI components and I seriously doubt if it can increase any
productivity at all.... Our main business are developing web-based MSI
system and even ASP.NET is not helpful for that, due to its almost zero
integration with javascript.

PS: I'm using AJAX for new project now.




Would you need to use COM if it's on .NET? If not then you don't need
EJB.

Nope looks like I do not EJB, pity they look like it could be fun.

J2SE isn't sufficient - it's just for basic things and GUI. It's the
J2EE that covers servlet, jsp, and ejb etc.




just here

Thanks very much, I appreciate that.

 

[dean]

Tomcat is a web-container that runs servlets and jsp-pages (and serves
other web content). Sun has included tomcat in their AppServer to make
up a complete J2EE AppServer.



You can run tomcat with apache as frontend, just as you would run php
with apache as frontend. I'd be surprised if no-one has come up with a
way to use tomcat as frontend to php too ...



That should be pretty much the same thing. But if you'r webservices run
on top of EJB's, tomcat is not enough alone.



Between tomcat and appserver? No. Appserver is a full J2EE-stack. The
most important functionality in addition to what tomcat offers is an
ejb-container.



JBoss is similar to Sun AppServer, it's a full J2EE stack. Like Sun
Appserver JBoss uses tomcat as it's webcontainer. Struts is a MVC
framework that helps you make web-applications. Most common is to use
JSP as View in Struts applications. There exist literally tons of web
application framework for J2EE/Java, but Struts is most used. Struts is
useful, rock solid and has become an industry standard. Still, if you
come from the .Net world you may find it a little bit old-fashioned and
may want to check out other frameworks as well.

All in all the best-of-breed-philosophy in the java world really
requires you to give some thought to choice of thechnology ...

Enterprise Javabeans are components that live inside an EJB-container
that offers services as distribution and transaction management. Various
types of EJB's exist; Sessionbeans the most common, Entity beans for
database access, Message Driven Beans for asynchronous messaging and
so-forth. Some people complain that EJB's are difficult to use, but it's
not. They might be overkill, though, if you don't need all the services
of the EJB container. Like with .Net it is important to have nice tools,
and in the Java world you have a lot to choose from. Eclipse with
various plugins, Netbeans, Oracle JDeveloper, Borland JBuilder etc. etc.

This may appear a little backwards but while I'm learning I like to use
a good old text editor and command lines. When I understand what is
going on a little more I'll move to the tools. I found that when I
stopped using VS I learned alot more about what actually happens and my
programming and understanding improved markedly. It is slower for a
while but I think that the time lost is gained back several times later
through proper application of the technology. With this app there is not
any *commercial* imperative to get to market, so I can take my time.

Well, you'd definitely need *parts of* J2EE. It's impossible to make
webservices and webpages otherwise, because that is per definition part
of J2EE. So is JDBC, which is the technology to access databases in
Java. (JDBC is so commonly used that it's distributed with the J2SE
JDK, even though it's part of the J2EE standard.)

What you don't need is a full J2EE appserver to do what you want, you
may choose to use only tomcat and skip EJB's. For persistence you may
instead use Hibernate, or just plain JDBC-calls (which is what most
other persistence technologies run on top of anyway), and the rich
client gui may be implemented using Swing. If you need transactions, you
really should facilitate EJB's, putting your JDBC code in a stateless
sessionbean and have transactions managed for you really isn't very
difficult compared to have your ordinary POJO JavaBeans scattered with
connection.rollback();

For the auto-update function you should look into WebStart.

That looks promising, I will look into that.

Well, Sun has their J2EE tutorial, and there are free books available at
www.theserverside.com. Sun also has their reference applications to
display all bells and whistles of J2EE. This seems to have made people
believe they really need to use all available J2EE technologies at once,
in every application, making J2EE apps look like mastodonts.

I noted in another reply that after doing some reading I recognise that
j2ee was a collection of java stuff for the web basically. I think that
it may take some discipline to stick only to those technologies that I
need and not to start inventing requirements so I can play with the
stuff that looks fun. (There may be no commercial timeline, but I do
like to get projects finished)


A couple of

years ago Microsoft implemented the Petstore reference application in a
"thin" version on top of SQL Server (using lots of stored procedures
which makes sense in the Microsoft world, but not in the multiplatform
Java world),

Tell me about it, I am actually a SQL Server "specialist" if you like,
and there is a bit of a clash of culture when dealing with those of a
Java background.

outperforming the bloated original Java version. This seems

to have made java-people realize that it's entirely possible to use J2EE
as a toolbox from which one can pick only selected technologies, instead
of using everything at the same time.

Also you could learn a lot by downloading some nice tools and poke
around. I use JDeveloper from Oracle. I think they've made it completely
free recently, and it's entirely possbible to develop using JDeveloper
and deploy to a free server like JBoss.

Thankyou very much for that.

 

[Scott Ellsworth]

I have downloaded the J2EE SDK and started reading the Doco but I fear
that taking that route will leave me reading doco for the next two years.

That is a fair summary. J2EE is a terribly complex beast. Those who
like it claim that the complexity comes because of the complexity of the
problems it can solve. Thus, the complexity is a small price to pay if
your problem ends up complicated.

Those who loath it claim that the complexity is required even for simple
projects, which will never become online banking and transaction
reconciliation systems.

Personally, most of my apps have a relatively small number of users, and
thus I tend to pick simpler technologies, which are both faster to
implement, and faster to turn around.

The first question is are Appserver and Tomcat competing technologies or
has Sun taken Tomcat and extended it, or is Tomcat a cut dow version of
AppServer?

Different technologies, really. Tomcat lets you run JSPs and servlets,
which are sufficient for a great many technologies. Appserver competes
with JBoss, and is a full fledged J2EE stack capable of all sorts of
things.

A common thing to do is pick something that makes JSPs or servlets more
usable for you. Tapestry is one such example, and I believe Spring is
another. With Tapestry, you design HTML templates (much like old school
Web Objects components) that get turned into Java code on the back end.
That java code likely will use a database persistence toolkit like
Hibernate or Cayenne.

Thus, even though Tomcat out of the box does not manage as much state as
appserver, nor does it do a lot of peristence layer stuff, you can still
get that using specific tools that _do_ handle those things.

Why use Tapestry/Hibernate? Because they are more focussed, and are
thus easier to understand. If you read the hibernate docs, you find out
how to get data into and out of a database. If you read the tapestry
docs, you find out how to get an html page out of a template. If you
deploy both to Tomcat, Tomcat handles the web communication, servlet
launching, etc. So, depending on what part of the problem you are
solving, you read the docs for the appropriate tool.

Can I run other services, such as a PHP Application or a subversion
(through WEBDAV, I think it is) through either of these, I think tomcat
can run on its own or through another apache installaion, Is this correct?

Correct - we usually have apache handling mainline web service, and
handing off servlet URLs to Tomcat. This way, static images come from
the web server, as do CGIs, while our JSP-based web applications come
from Tomcat.

I have a paper design for a system with Mason-backed Perl, Tomcat-backed
Java, and Rails-backed Ruby, all talking to the same backing store.
Eventually, I will have just one technology doing this work, but for
now, it is a good way to see how well these interoperate.

Jon answered most of your other questions, but I wanted to comment on:

The application that I am looking to create will be pretty strait
forward. [...] Do I even need J2EE or will the J2SE be sufficient?

As Jon mentioned, a number of technologies are part of the J2EE spec,
but you do not need to understand that whole gigantic spec to use them.
Servlets, for example, are a common topic in a first or second semester
course in Java programming.

I would probably try to stay with J2SE and tools based on it. Pick
tools that deploy to Tomcat, and you have less to figure out and set up.
My current faves in the Java world are Tapestry and Hibernate - Tapestry
for the web side, and Hibernate for db access. Axis lets you write web
services in Java, and it deploys to Tomcat too.

Struts (based on JSP) is very popular with some of my clients right now,
and it seems to be a bit lighter weight, if a bit more tedious (IMO)
than Tapestry. Spring is getting a lot of buzz, but I have not had a
contract in it yet, so I cannot comment intelligently.

If your rich client can reach the database directly, then you might skip
Axis, and talk directly to the db with Hibernate. Depends on who is
running the rich apps, and how much you trust the network between them.

Scott

 

[Jon Martin Solaas]

This may appear a little backwards but while I'm learning I like to use
a good old text editor and command lines. When I understand what is
going on a little more I'll move to the tools. I found that when I
stopped using VS I learned alot more about what actually happens and my
programming and understanding improved markedly. It is slower for a
while but I think that the time lost is gained back several times later
through proper application of the technology. With this app there is not
any *commercial* imperative to get to market, so I can take my time.

No, it makes perfectly sense. But tinkering with a nice development tool
is also good for educational purposes. You can learn a lot from various
kinds of generated deployment descriptors etc.

The most important is to not give up if you have trouble getting
deployment descriptors right by handcoding, building archives correctly
and so on. In such cases it's nice to have the opportunity to cheat and
let JDeveloper or another nice tool lead the way for a short while.

[...]

I noted in another reply that after doing some reading I recognise that
j2ee was a collection of java stuff for the web basically.

Parts of J2EE support web-applications, other parts support other things
that doesn't have anything at all to do with the web.

Tell me about it, I am actually a SQL Server "specialist" if you like,
and there is a bit of a clash of culture when dealing with those of a
Java background.

Sure is. The best-of-breed philosophy of the java world really gives you
the freedom to choose tools and technology that suits your specific
needs. If you are so lucky as to know what those are ... So it really
«makes sense» to build apps that are portable from one database to
another to a java-person, still the chances the application really will
be ported may be very slim. Also Microsoft based projects doesn't have
to make a lot of choices in the inception phase, just go with Win200X
server and .Net. That's what I call a real no-brainer And, even if I
don't like Microsoft software, it sure makes stuff less complicated (But
MS still makes a great effort to add new levels of complexity to their
technology stack, so I forgive them .