Re: Weblogic VS. Tomcat

2007-10-16 Thread Johnny Kewl


---
HARBOR: http://coolharbor.100free.com/index.htm
Now Tomcat is also a cool application server
---
- Original Message - 
From: Johnny Kewl [EMAIL PROTECTED]

To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, October 16, 2007 7:10 AM
Subject: Re: Weblogic VS. Tomcat




---
HARBOR: http://coolharbor.100free.com/index.htm
Now Tomcat is also a cool application server
---
- Original Message - 
From: minky arora [EMAIL PROTECTED]

To: users@tomcat.apache.org
Sent: Monday, October 15, 2007 5:25 PM
Subject: Weblogic VS. Tomcat



Hi List,

I need some advice regarding Tomcat Vs. Weblogic.

I am building a  website that has an Oracle DB as a back end.I am
running scripts on the DB and displaying the results on the
website.Users can log in and query the DB as well to get the desired
results which could be info about anything in the DB.

My question is: Do I require a server side Datasource for this? FIrst
of all, I am not sure what this means.For my organization,only
Weblogic has external access as Ive been told.SO if I do not need
server side Datasource and connection pooling, I can go with Tomcat.

I am very new to J2EE.could you please tell me a bit more about server
side datasource:what it is and examples of how it is used.Do you think
my application needs one??


If you google for Servlet versus Application Server, you will see many 
other people ask the question and you'll get the views of both camps.
If you making a web site, you really dont need more than a Servlet 
container. Tomcat will let you set up a Datasource with connection 
pooling, in fact every container allows for that.
I think its more about where you want to store the biz logic. People that 
havnt learnt the MVC model and that work mainly from JSP pages will tend 
to go for something like struts, or an application server for the biz 
logic. They use another framework for the biz logic.
People that understand the MVC model will use servlets and JSP and make 
their own biz logic beans in the servlet container... that to me seems to 
be the tendency.


I believe that for a web site a well designed web-app which houses the biz 
logic is faster and easier to understand, and easier to maintain, than 
redirecting requests to EJB's in another container, but it does depend 
very much on the context of the project. If for example there are also 
desktop apps that use that same biz logic, then the tendency will be to go 
for application server... ie the web server is a client and the desktops 
apps are a client to the EJB's.


EJB (Application servers) like GlassFish, Geronimo, Weblogic, Spring, 
JBoss are complex technologies with a large learning curve and will 
require a great deal of effort on your part, they are also all different. 
Servlet based web solutions are easier to learn, and much more portable.
If its a web solution... I would tend to say to you, keep it as simple as 
possible... but then again EJB on your CV may look nice as well ;)
If its a critical job... I would tend to say, keep it a pure web based 
solution, because as a newbie the complexity of EJB may bite you.
Tomcat is inside most of these other containers, so if it ever has to go 
EJB... conversion wont be too bad, but moving from say a Spring type 
solution to a Glassfish type solution would require a major effort.
Keep it simple if you can. the more I play with these technologies the 
more I think that the ability to make simple solutions is the most 
desirable characteristic on any cv. Only people that really understand the 
technologies can keep it simple... simple is a skill.


I would suggest you google for Tomcat and the MVC model... and then read 
as much about EJB as you can. You will start to see the overlap.
In TC its very much more a traditional application, in EJB its very much a 
bean that needs to be controlled through IOC, (xml) configuration.
That means in TC things like persisting beans to a dB is still very much 
an option, in EJB its almost a necessity because of the different 
architecture.

EJB is a massive learning curve... good luck.


AFTER THOUGHT...

Actually when I reread your question... I think what you have been told is 
more policy than technology. I think what your IT guys are saying to you is 
that THEY want to control the biz logic, and ONLY they can access the dB.


So if you try setup a dB pool on TC, they probably not going to give you the 
passwords to the dB ;)


So I guess it means you have to ask them to make the biz logic EJB modules, 
and then you will call those from Tomcat... which only the WebLogic server 
can deduce from the dB.


Perhaps good policy, or perhaps one way of protecting their jobs

Weblogic VS. Tomcat

2007-10-15 Thread minky arora
Hi List,

I need some advice regarding Tomcat Vs. Weblogic.

I am building a  website that has an Oracle DB as a back end.I am
running scripts on the DB and displaying the results on the
website.Users can log in and query the DB as well to get the desired
results which could be info about anything in the DB.

My question is: Do I require a server side Datasource for this? FIrst
of all, I am not sure what this means.For my organization,only
Weblogic has external access as Ive been told.SO if I do not need
server side Datasource and connection pooling, I can go with Tomcat.

I am very new to J2EE.could you please tell me a bit more about server
side datasource:what it is and examples of how it is used.Do you think
my application needs one??

Thanks so much,
-M

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weblogic VS. Tomcat

2007-10-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Minky,

minky arora wrote:
 My question is: Do I require a server side Datasource for this?

Probably. I mean, you could get your data from some service instead of
directly from the database. Otherwise, you're going to need a
server-side datasource.

 First
 of all, I am not sure what this means.For my organization,only
 Weblogic has external access as Ive been told.

Can you explain this in more detail? Do you mean that, if you were to
get Tomcat setup, that nobody from the Internet could access it? That is
eitehr good or bad depending in who you are trying to serve (remote
users on an intranet: good; remote users on the Internet: bad).

 So if I do not need
 server side Datasource and connection pooling, I can go with Tomcat.

If you already have Weblogic, why not stick with it? I think you'll find
that your network ops team will like it better if you play by existing
rules rather than asking them to support Tomcat in addition to what
they're already doing.

 I am very new to J2EE.could you please tell me a bit more about server
 side datasource:what it is and examples of how it is used.Do you think
 my application needs one??

Basically, a server-side data source is a connection to the database.
When you're using Java, this is a JDBC connection. Most DataSources do
nice things like connection pooling. The server-side moniker refers to
where the code/data are stored. For web applications, unless you are
using AJAX or pure javscript (or shiver jscript or double shiver
vbscript), nothing you do will be considered anything other than
server-side.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFHE4iP9CaO5/Lv0PARAhJ8AJ9UhAtOHybRrTH53jhVbbuy5lR8DACVH4Qe
HqvLlmNvfc3mfAduEv10cQ==
=zbC6
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weblogic VS. Tomcat

2007-10-15 Thread Johnny Kewl


---
HARBOR: http://coolharbor.100free.com/index.htm
Now Tomcat is also a cool application server
---
- Original Message - 
From: minky arora [EMAIL PROTECTED]

To: users@tomcat.apache.org
Sent: Monday, October 15, 2007 5:25 PM
Subject: Weblogic VS. Tomcat



Hi List,

I need some advice regarding Tomcat Vs. Weblogic.

I am building a  website that has an Oracle DB as a back end.I am
running scripts on the DB and displaying the results on the
website.Users can log in and query the DB as well to get the desired
results which could be info about anything in the DB.

My question is: Do I require a server side Datasource for this? FIrst
of all, I am not sure what this means.For my organization,only
Weblogic has external access as Ive been told.SO if I do not need
server side Datasource and connection pooling, I can go with Tomcat.

I am very new to J2EE.could you please tell me a bit more about server
side datasource:what it is and examples of how it is used.Do you think
my application needs one??


If you google for Servlet versus Application Server, you will see many other 
people ask the question and you'll get the views of both camps.
If you making a web site, you really dont need more than a Servlet 
container. Tomcat will let you set up a Datasource with connection pooling, 
in fact every container allows for that.
I think its more about where you want to store the biz logic. People that 
havnt learnt the MVC model and that work mainly from JSP pages will tend to 
go for something like struts, or an application server for the biz logic. 
They use another framework for the biz logic.
People that understand the MVC model will use servlets and JSP and make 
their own biz logic beans in the servlet container... that to me seems to be 
the tendency.


I believe that for a web site a well designed web-app which houses the biz 
logic is faster and easier to understand, and easier to maintain, than 
redirecting requests to EJB's in another container, but it does depend very 
much on the context of the project. If for example there are also desktop 
apps that use that same biz logic, then the tendency will be to go for 
application server... ie the web server is a client and the desktops apps 
are a client to the EJB's.


EJB (Application servers) like GlassFish, Geronimo, Weblogic, Spring, JBoss 
are complex technologies with a large learning curve and will require a 
great deal of effort on your part, they are also all different. Servlet 
based web solutions are easier to learn, and much more portable.
If its a web solution... I would tend to say to you, keep it as simple as 
possible... but then again EJB on your CV may look nice as well ;)
If its a critical job... I would tend to say, keep it a pure web based 
solution, because as a newbie the complexity of EJB may bite you.
Tomcat is inside most of these other containers, so if it ever has to go 
EJB... conversion wont be too bad, but moving from say a Spring type 
solution to a Glassfish type solution would require a major effort.
Keep it simple if you can. the more I play with these technologies the 
more I think that the ability to make simple solutions is the most desirable 
characteristic on any cv. Only people that really understand the 
technologies can keep it simple... simple is a skill.


I would suggest you google for Tomcat and the MVC model... and then read as 
much about EJB as you can. You will start to see the overlap.
In TC its very much more a traditional application, in EJB its very much a 
bean that needs to be controlled through IOC, (xml) configuration.
That means in TC things like persisting beans to a dB is still very much an 
option, in EJB its almost a necessity because of the different architecture.

EJB is a massive learning curve... good luck.






-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]