Java Web Architecture

[Tom Dyess]

Hi,

I've been teaching myself Java for about 5 months or so by converting
one of my "search engine" sites to Java. I just got a project at work in
which I can use Java (instead of Delphi). It's an application that uses one
of our complex business logic COM objects. I'm using Jacob and am impressed.
The application is limited to a Win32 server however I don't want to get
into the habit of writing platform specific code. The COM object is about
65K lines of raw logic (no components) and is very complex, therefore
rewriting it in Java is not an option compatible with the project's scope. I
created a strict Java wrapper that calls the Jacob interfaces to the COM
object. Enough bla bla.

Up to now, I've been treating Java Servlets like an ISAPI object. The
Servlet is the first and only thing called by the browser (not server) and
the servlet does all the work. For HTML, the servlet loads templates parses
them for tags, replaces the tags with business logic results and sends the
parsed template (complete HTML) to the response object. This is done with a
PageProducer object I created based on a successful component I use in
Delphi ISAPI.

This has worked very well so far. I don't care for JSP for more complex
projects because of my ASP days. The JSP pages are much more difficult to
manage IMO, than a single servlet object (with many aggregated objects
ofcourse). What I am curious about are EJB's.

The obvois candidate is the wrapped business COM object. It should have
a session scope. What benefits would creating it (and a database
communication object) using a session and entity bean as oppoised to
creating the business COM in the servlet session scope and the database
communication object in the global scope?

 

[Chris Smith]

This has worked very well so far. I don't care for JSP for more complex
projects because of my ASP days. The JSP pages are much more difficult to
manage IMO, than a single servlet object (with many aggregated objects
ofcourse).

I believe you're making a mistake in equating JSP and ASP. Although JSP
can be used in a manner similar to ASP, there are much better ways of
using JSPs. In fact, I wonder if JSPs might end up being about
equivalent to the templates you maintain for your PageProducer object,
but without your having to maintain that implementation code. I haven't
seen your PageProducer, though, and can't be sure.

What I am curious about are EJB's.

The obvois candidate is the wrapped business COM object. It should have
a session scope. What benefits would creating it (and a database
communication object) using a session and entity bean as oppoised to
creating the business COM in the servlet session scope and the database
communication object in the global scope?

Unfortunately, EJBs don't solve one problem. They provide a hodge-podge
of many pieces of unrelated functionality, and many of the pieces have a
number of alternatives. Here's a general view of the picture.

EJBs provide:

1. Remote method call capabilities. This is irrelevant for your
situation, since COM is already providing you with remote calls. In
fact, EJBs would end up marshalling your method calls through two
separate levels of remote calls, which is a bit excessive.

2. Automatic persistence of data to databases. This seems equally
irrelevant to your project, but at least you don't have to use it.
Incidentally, if this is relevant, EJB entity beans stack up rather
poorly to alternatives like Hibernate.

3. Integration with message queue systems, which is almost certainly
irrelevant to your project.

4. Management of transactions, if the underlying resource provides a
two-level commit protocol. Does your COM interface provide a two-level
commit protocol for transactional access that you need to make use of?
If so, EJBs do this via technologies called JTA and JTS, so you should
make a choice between using those technologies in your project, or using
all of EJBs.

5. Declarative abstract operation-level security. If you plan to
interact with the COM component on behalf of several users and need to
enforce some extremely simplistic security requirements, EJBs can do it
for you. However, if your security requirements can even a little more
sophisticated, into the "instance-level" categgory (for example, if Bob
can look at sales budgets but not engineering budgets) then you have to
write it yourself anyway.

EJBs also prevent you from using some very common and flexible
programming techniques, such as multithreading.

As you can probably tell, I'm not a fan of Enterprise JavaBeans.
Nevertheless, even more than not liking EJBs in general, I really don't
think they are appropriate for interfacing with this COM component.
Instead, just go ahead and write an everyday average Java class that
does that work, and call that from your servlet code.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tom Dyess]

I believe you're making a mistake in equating JSP and ASP. Although JSP
can be used in a manner similar to ASP, there are much better ways of
using JSPs. In fact, I wonder if JSPs might end up being about
equivalent to the templates you maintain for your PageProducer object,
but without your having to maintain that implementation code. I haven't
seen your PageProducer, though, and can't be sure.


Unfortunately, EJBs don't solve one problem. They provide a hodge-podge
of many pieces of unrelated functionality, and many of the pieces have a
number of alternatives. Here's a general view of the picture.

EJBs provide:

1. Remote method call capabilities. This is irrelevant for your
situation, since COM is already providing you with remote calls. In
fact, EJBs would end up marshalling your method calls through two
separate levels of remote calls, which is a bit excessive.

2. Automatic persistence of data to databases. This seems equally
irrelevant to your project, but at least you don't have to use it.
Incidentally, if this is relevant, EJB entity beans stack up rather
poorly to alternatives like Hibernate.

3. Integration with message queue systems, which is almost certainly
irrelevant to your project.

4. Management of transactions, if the underlying resource provides a
two-level commit protocol. Does your COM interface provide a two-level
commit protocol for transactional access that you need to make use of?
If so, EJBs do this via technologies called JTA and JTS, so you should
make a choice between using those technologies in your project, or using
all of EJBs.

5. Declarative abstract operation-level security. If you plan to
interact with the COM component on behalf of several users and need to
enforce some extremely simplistic security requirements, EJBs can do it
for you. However, if your security requirements can even a little more
sophisticated, into the "instance-level" categgory (for example, if Bob
can look at sales budgets but not engineering budgets) then you have to
write it yourself anyway.

EJBs also prevent you from using some very common and flexible
programming techniques, such as multithreading.

As you can probably tell, I'm not a fan of Enterprise JavaBeans.
Nevertheless, even more than not liking EJBs in general, I really don't
think they are appropriate for interfacing with this COM component.
Instead, just go ahead and write an everyday average Java class that
does that work, and call that from your servlet code.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris,

Thank you for the input. Let me wait for a few responses before
replying. In the meantime, if you are interested in the PageProducer code,
you can find it here.

http://www.oraclepower.com/WebPortal/fixed/files/PageProducer.zip

For usage, check PageProducer.main. These have been javadoc'd. I'd like to
hear your input on this vs JSP. I'm always open to new techniques.

Tom Dyess
OraclePower.com

 

[Tom Dyess]

Chris,

Thank you for the input. Let me wait for a few responses before
replying. In the meantime, if you are interested in the PageProducer code,
you can find it here.

http://www.oraclepower.com/WebPortal/fixed/files/PageProducer.zip

For usage, check PageProducer.main. These have been javadoc'd. I'd like to
hear your input on this vs JSP. I'm always open to new techniques.

Tom Dyess
OraclePower.com

Sorry, one thing I forgot to mention about the PageProducer. It allows me to
nest templates as well. For example

main.htm is the main template. This template will appear on all pages of the
application. It includes such things as the logo and menu bar

stats.htm is used when the <#stats> tag is found in the main template. The
servlet then applies tag handler events into the stats.htm template and
returns code which is used in the parsing of the main.htm template.

Some templates and how they are nested:

main.htm (this is always parsed except for redirects)
+--stats.htm (this is parsed when main.htm is parsed and the <#stats> tag
is found)
+--topsearches.htm (parsed when main.htm is parsed and the <#topsearch> tag
is found)
+--search.htm
+--categorylist.htm (parsed when main.html is parsed and the
<#categorylist> tag is found)
+--resourcelist.htm (parsed when categorylist.htm is parsed and the
<#resourcelist> tag is found)
+--resource.htm (prased when resourcelist.htm is parsed and the
<#resource> tag is found)
+--categorynavigator.htm

Another benefit of this is that if I want to completely change the look &
feel of the site, I can change the set of templates. I can even go as far as
to allow the user to determine what template he/she wants to use.

 

[Sudsy]

Tom Dyess wrote:

Another benefit of this is that if I want to completely change the look &
feel of the site, I can change the set of templates. I can even go as far as
to allow the user to determine what template he/she wants to use.

Templates have been around in one for or another for quite some time.
Check out Tiles here:
<http://www.onjava.com/pub/a/onjava/excerpt/progjakstruts_14/index1.html>

 

[John English]

main.htm is the main template. This template will appear on all pages of the
application. It includes such things as the logo and menu bar

stats.htm is used when the <#stats> tag is found in the main template. The
servlet then applies tag handler events into the stats.htm template and
returns code which is used in the parsing of the main.htm template.

Have you considered generating XML instead of your custom tags and
then using an XSTL filter to postprocess your output into HTML?

-----------------------------------------------------------------
John English | mailto:[email protected]
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
School of Computing & MIS | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

 

[anonymous]

Have you considered generating XML instead of your custom tags and
then using an XSTL filter to postprocess your output into HTML?

-----------------------------------------------------------------
John English | mailto:[email protected]
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
School of Computing & MIS | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

FWIW, das ist genau what wir tun. Übrigens geht's auch struts mit XSLT
zu mischen, hauptsache alles ist well formed.
Hinterher Funktionen als Web Services anzubieten ist dann ein Kinderspiel.