EJB + number crunching

Discussion in 'Java' started by Martin Ankerl, Aug 18, 2005.

  1. 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 :)

    --
    martinus
     
    Martin Ankerl, Aug 18, 2005
    #1
    1. Advertising

  2. Martin Ankerl wrote:
    > 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

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Aug 18, 2005
    #2
    1. Advertising

  3. Martin Ankerl

    Alvin Ryder Guest

    Martin Ankerl wrote:
    > 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 :)
    >
    > --
    > martinus


    Hope that helps,
    Cheers.
     
    Alvin Ryder, Aug 18, 2005
    #3
  4. Alvin Ryder wrote:
    > Martin Ankerl wrote:
    >
    >>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.


    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

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Aug 18, 2005
    #4
  5. Martin Ankerl

    Alvin Ryder Guest

    Raymond DeCampo wrote:
    > Alvin Ryder wrote:
    > > Martin Ankerl wrote:
    > >
    > >>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.

    >
    > 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.
    ....


    > >
    > > 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
    >
    > --
    > XML is the programmer's duct tape.


    Cheers.
     
    Alvin Ryder, Aug 19, 2005
    #5
  6. Alvin Ryder wrote:
    > Raymond DeCampo wrote:
    >
    >>Alvin Ryder wrote:
    >>
    >>>Martin Ankerl wrote:
    >>>
    >>>
    >>>>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.

    >>
    >>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".


    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.

    >
    >>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.


    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.

    >
    >
    >>>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

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Aug 19, 2005
    #6
  7. Martin Ankerl

    Roedy Green Guest

    On Thu, 18 Aug 2005 14:18:41 GMT, Raymond DeCampo
    <> wrote or quoted :

    >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?
     
    Roedy Green, Aug 21, 2005
    #7
  8. Roedy Green wrote:
    > On Thu, 18 Aug 2005 14:18:41 GMT, Raymond DeCampo
    > <> wrote or quoted :
    >
    >
    >>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?
    >


    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

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Aug 21, 2005
    #8
  9. Martin Ankerl

    Roedy Green Guest

    On Sun, 21 Aug 2005 15:01:42 GMT, Raymond DeCampo
    <> wrote or quoted :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com
     
    Roedy Green, Aug 23, 2005
    #9
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shuo Xiang

    big number crunching in C

    Shuo Xiang, Sep 25, 2003, in forum: C Programming
    Replies:
    3
    Views:
    470
    Glen Herrmannsfeldt
    Sep 26, 2003
  2. Ted
    Replies:
    5
    Views:
    709
  3. Replies:
    21
    Views:
    1,762
    northerntechie
    Mar 26, 2008
  4. Replies:
    40
    Views:
    1,329
    Roedy Green
    Jun 23, 2008
  5. Raymond Schanks
    Replies:
    0
    Views:
    671
    Raymond Schanks
    Aug 3, 2010
Loading...

Share This Page