EJB + number crunching

M

Martin Ankerl

Hi,

I have to write an J2EE application. In this application I have to write
a component that uses a lot of processing power, which runs continuously
and writes and reads data to a database every few minutes when results
are ready.

My question is, is it a good idea to use a stateless session bean for
this calcuations? or a message driven bean? Is it possible that the bean
automatically starts calculation when the container starts?

PS: Please be gentle, I am a newbie :)
 
R

Raymond DeCampo

Martin said:
Hi,

I have to write an J2EE application. In this application I have to write
a component that uses a lot of processing power, which runs continuously
and writes and reads data to a database every few minutes when results
are ready.

My question is, is it a good idea to use a stateless session bean for
this calcuations? or a message driven bean? Is it possible that the bean
automatically starts calculation when the container starts?

PS: Please be gentle, I am a newbie :)

This does not sound like a good application of EJB. (Perhaps EJB 3.0,
where I believe there is a timer added.)

I'm not sure there is a good J2EE component for this type of need; a
continuously running, processor hogging application. You may want to
write a separate application to handle it and coordinate with your J2EE
application (perhaps with a message-driven bean, since the updates can
be asynchronous).

FWIW, J2EE is a large and complex beast. If you truly are a newbie,
allow yourself quite a bit of time to get up to speed. Do not expect
that you can follow your nose and augment that with quick posts to the
usenet.

HTH,
Ray
 
A

Alvin Ryder

Martin said:
Hi,

I have to write an J2EE application. In this application I have to write
a component that uses a lot of processing power, which runs continuously
and writes and reads data to a database every few minutes when results
are ready.

My question is, is it a good idea to use a stateless session bean for
this calcuations? or a message driven bean? Is it possible that the bean
automatically starts calculation when the container starts?

A message been (MDB) consumer processor could run continuously, every
time a new message arrives it processes it. Whereas stateless session
beans (SLSB) do not really run continuously, they just sit there more
or less ready to be called by "someone" else, once called they do their
task and end.

The point is with SLSB you won't have a continuous processor, who will
call the SLSB and when? I'd suggest a closer look at MDB ;-)
PS: Please be gentle, I am a newbie :)

Hope that helps,
Cheers.
 
R

Raymond DeCampo

Alvin said:
A message been (MDB) consumer processor could run continuously, every
time a new message arrives it processes it. Whereas stateless session
beans (SLSB) do not really run continuously, they just sit there more
or less ready to be called by "someone" else, once called they do their
task and end.

I do not see how MDB and SLSB differ here. The MDB still needs to be
"called" by someone else, i.e. the source of the message. The MDB could
theoretically start an infinite process upon receiving a message, but
the initial message must be sent. Also, it is unclear how a container
might react to a MDB that does not return from the processing method.

The only difference between a MDB and a SLSB in this regard is that the
MDB is asynchronous while the SLSB is not.

If the MDB starts an infinite process from the message handler, you will
have to introduce code to ensure that the process does not start again
when a second message is received (for robustness). This is probably
non-trivial to do; the likely method of using static data is a bad idea
inside of a container. The second most likely method of using an
external resource (file system, database) has issues when the J2EE
server is stopped and you want to ensure that the external flag is cleared.

The problem here is trying to shoehorn EJB into doing something it was
not designed to do.
The point is with SLSB you won't have a continuous processor, who will
call the SLSB and when? I'd suggest a closer look at MDB ;-)

Ray
 
A

Alvin Ryder

Raymond said:
I do not see how MDB and SLSB differ here. The MDB still needs to be
"called" by someone else, i.e. the source of the message. The MDB could
theoretically start an infinite process upon receiving a message, but
the initial message must be sent. Also, it is unclear how a container
might react to a MDB that does not return from the processing method.

Hi,

I may have misunderstood the original poster, maybe I confused their
requirements with what I've needed to do in the past?

Rightly or wrongly I reacted to the word "continuously".

All the message consumers I've seen needed to be continuous, as new
messages arrive on a Queue or Topic they are processed ... all day
everyday.
The only difference between a MDB and a SLSB in this regard is that the
MDB is asynchronous while the SLSB is not.

If the MDB starts an infinite process from the message handler, you will
have to introduce code to ensure that the process does not start again
when a second message is received (for robustness). This is probably
non-trivial to do; the likely method of using static data is a bad idea
inside of a container. The second most likely method of using an
external resource (file system, database) has issues when the J2EE
server is stopped and you want to ensure that the external flag is cleared.

The problem here is trying to shoehorn EJB into doing something it was
not designed to do.

I agree shoehorning EJB beyond what it was designed to do is bad but
the scenario I'm talking about is squarely within range.

Message Oriented Middleware (MOM) is designed to be produced and
consumed continuously. MDB are simply Sun's rendition of MOM.
....


Cheers.
 
R

Raymond DeCampo

Alvin said:
Hi,

I may have misunderstood the original poster, maybe I confused their
requirements with what I've needed to do in the past?

Rightly or wrongly I reacted to the word "continuously".

I interpreted the word "continuously" to mean that the component must be
constantly running code regardless of client requests.
All the message consumers I've seen needed to be continuous, as new
messages arrive on a Queue or Topic they are processed ... all day
everyday.

I do not see how this is different from a SLSB, which must also be
available at a client's request. In each case, it is the J2EE container
that does the actual listening for clients.

With a MDB, nothing guarantees that you always have one instantiated or
that the container doesn't create a new instance for each message received.
I agree shoehorning EJB beyond what it was designed to do is bad but
the scenario I'm talking about is squarely within range.

It seems to me that what you are referring to is done by every type of
server; listening for client messages.
Message Oriented Middleware (MOM) is designed to be produced and
consumed continuously. MDB are simply Sun's rendition of MOM.
...

To be more precise, JMS is Sun's version of MOM for Java and MDB are
JMS-enabled EJBs.

Ray
 
R

Roedy Green

FWIW, J2EE is a large and complex beast. If you truly are a newbie,
allow yourself quite a bit of time to get up to speed. Do not expect
that you can

If one goes through the hazing rituals and learns J2EE, what can you
do that you could not before? What is this stuff for REALLY?
 
R

Raymond DeCampo

Roedy said:
If one goes through the hazing rituals and learns J2EE, what can you
do that you could not before? What is this stuff for REALLY?

A quick synopsis:

EJB:

EJBs come in a number of flavors.

1) Entity beans. Entity beans are used to represent data in a database.
There are two flavors of entity beans, bean managed persistence (BMP)
and container managed persistence (CMP). With CMP the container handles
generating all the SQL. With BMP you have to write the SQL. A typical
simple use-case is that a single instance of an entity bean represents a
row in a database. Many people have soured on entity beans and prefer a
simpler approach like Hibernate. In fact, the new EJB specifications
endeavor to make entity beans more like Hibernate.

2) Session beans. Session beans are essentially service providers. A
typical use-case is to encapsulate high-level business logic. For
example, a session bean for a bank might implement an electronic
transfer. Session beans can be stateful or stateless. A stateful
session bean maintains a conversational state between itself and the
client. A stateless session bean does not; a client might get
completely different bean instances from one call to the next, even with
the same handle.

3) Message driven beans (MDB). Message driven beans are capable of
responding to JMS messages. (The other types of beans are not able to
do this do to the restrictions of the bean container.) MDB work
asynchronously, the other bean types are synchronous. MDB can post JMS
messages and that can be used as a "return value" of sorts.

Using EJBs gives you a number of things. The biggest thing is the
server environment. You do not need to implement all the things that go
with a server, like threading, polling, security, etc. (Do not be
fooled -- writing a server is hard. Just ask the guys at Apache HTTPD
or the IIS team.)

Using EJBs also takes away a number of things. You are not allowed to
do certain things within the EJB container. E.g., you should not create
threads, do file IO, listen on a socket, etc.

Web Technologies:

Web technologies come in two flavors, servlets and JSPs. Servlets are
the Java answer to CGI. Servlets are typically used as the controller
portion of a MVC set up.

JSPs allow for the definition of output pages with Java code and JSP
tags interspersed. There are libraries of custom tags for JSP that
allow you to avoid placing any actual Java code in the pages. JSPs are
typically used as the view part of an MVC set up. JSPs are also
suitable for quick and dirty prototyping or demos.

Many applications only require the web technology portion of J2EE and
some servers supply only that. The most prominent example of this is of
course tomcat.

Note that the web container is considerably less strict than the EJB
container.

Web Services:

J2EE allows for the definition of web services. I haven't used this
technology, so I'll refrain from further comment.

Misc Technologies:

J2EE also supplies a family of supporting technologies. These include
JNDI, JDBC extensions (including connection pooling), JAAS, RMI and JMS.
There are also hooks to link in resource adapters, which supply
external resources through a standard interface.

J2EE also provides enough configuration to allow you to avoid hard
coding anything. For example, using JNDI and ENC, you can link a
logical database connection to a physical database connection.


Overall, many people find J2EE too big and unwieldy for their needs.
Others have pared it down to use only the portions they find useful.
The biggest benefit of living inside a J2EE server is that all the
server technologies are implemented for you. So much of the concerns
about security and scalability are taken off the table. If a particular
J2EE server does not perform well for your application, you can try another.

J2EE is not an all-purpose server environment however. It was really
designed and is primarily used for web applications where the EJB layer
provides support to the web layer.

HTH,
Ray
 
R

Roedy Green

J2EE is not an all-purpose server environment however. It was really
designed and is primarily used for web applications where the EJB layer
provides support to the web layer.

I have immortalised your essay, by formatting it and posting it as
part of the Java glossary. You might like to take a look at
http://mindprod.com/jgloss/ejb.html to see if I introduced any errors
in the process.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top