The problem with the current specification is that who is going to handle
the receiver part. This has to be a separate program/legacy system etc.
etc.. I am told that EJB2.0 will solve this.
Frequent usage of lightweight parallel processing is to do things like SQL
queries in parallel, access different legacy systems to get disparate data
etc.
For all this it would be nice if the spec provides some method of doing
lightweight parallel processing. On a current system we go out to 3 legacy
systems. Fortunately, 2 of them are queue based, but one is synchronous and
thus the response time is always tied to the synchronous one in the absence
of threading. I could do it using queues, but then it falls out of the EJB
Server/CTM boundary at the current level of specification.
Doing in JMS is ok, but with the incomplete spec. and also that means that
there is one more moving cog in the wheel to look after...
We have an application that has to be moved to EJB, that does some very
complicated calculations, some of which for speed purposes where done in
parallel in an older TP monitor based architecture. We are stuck with doing
threading in the client or inventing a convoluted queue based architecture
to what is simple lightweight parallel processing.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Sunday, 19 March 2000 03:27
> To: [EMAIL PROTECTED]
> Subject: Re: jms & ejb
>
>
> > <rant target="not at all chris personally">Oh good grief, if every time
> > I want to do three or four quick tasks in parallel I have to drag out a
> > workflow engine, I would go batty.</rant>
>
> I'm confused by this. Can you please explain to me what is so bad with
> using JMS to solve this?
>
> Here's some pseudocode I would use to do it (shamelessly copied from Don
> Fergusons/BEA session at their User Conference. Thanks Don!):
> InitialContext ctx = new InitialContext(env);
>
> Topic topic = (Topic) ctx.lookup("sometopic");
> TopicConnectionFactory connectionFactory =
> (TopicConnectionFactory)
> ctx.lookup("javax.jms.TopicConnectionFactory");
>
> TopicConnection connection =
> connectionFactory.createTopicConnection();
> TopicSession session = connection.createTopicSession(false,
> Session.AUTO_ACKNOWLEDGE);
> TopicPublisher publisher = session.createPublisher(topic);
>
> TextMessage message = session.createTextMessage();
> message.setText(�hello world�);
> publisher.publish(message);
>
> publisher.close();
> // Message sent; wait for response
> TopicSubscriber subscriber = session.createSubscriber(topic);
> connection.start();
>
> Message m = subscriber.receive();
>
> subscriber.close();
> session.close();
> connection.close();
> -----
> That wasn't so bad, was it? And you could easily abstract this away with
> a helper class to:
> ----
> Message m = jmsHelper.sendReceive("hello world", "sometopic"); // Send
> "hello world" to "sometopic" and receive reply
> ----
> Now, you've gotta explain to me what's so bad with the above, 'cause I
> aint getting it.
>
> Of course you could expand the above to send to several queues and
> receive from several queues in order to do parallel processing.
>
> What am I missing?
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.dreambean.com
> Question reality
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
