<vendor>
Ejipt 2.0 provides seamless integration between JMS and EJB. It allows you
to create producers, consumers and JMS sessions directly in your beans for
synchronous messaging. It also allows you to use your beans as message
listeners for asynchronous messaging. For the latter you simply have to
include the javax.jms.MessageListener interface into your remote interface's
extends and implement the onMessage() method in your bean's implementation.
Ejipt JMS uses standard UDP multicast for non-local JMS connections and
implements all the acknowledgment options required by the JMS spec.
Ejipt JMS is fully transacted and is based on the scalable Ejipt entity
architecture supporting local entity beans. Message queues/subscription
topics are implemented as entity beans that can be easily customized by
overriding the default bean implementation. This approach allows developers
to use already well understood BMP or CMP persistence mechanisms for message
persistence/logging.
Ejipt 2.0 betas will be publicly available shortly. Check our web site at
www.valto.com for availability.
</vendor>
Imre Kifor
Valto Systems
-----Original Message-----
From: Ian McCallion <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, October 01, 1999 10:51 AM
Subject: Re: Designing an enterprise architecture w/ Java and Linux
>Jason Carreira wrote:
>
>>OK, so I've been asked to do some research for a project here to develop
an
>>architecture for a client.
>>
>>The idea is that we're developing a replacement for a legacy system that
>>sits between the clients internal systems (ordering, support tracking,
etc)
>>using IBM's MQSeries messaging software to talk to the tier that we're
>>architecting, which talks on the other side with an EDI mapping software
to
>>map the messages sent from this tier to EDI docs to send out to the
>>customers/suppliers/etc on the outside. The tier we're building and the
EDI
>>mapper tier currently send EDI docs back and forth, but this is very
>>flexible and open to change.
>
>The problem with using any EJB server for the requirement you describe is
that
>none of them have support for driving EJBs from MQSeries, or even from JMS,
so
>you will need to design your own piece of "middleware" to do this. It is
>impossible to write this middleware as a set of portable EJBs.
>
>One theoretical option would be to develop a "message monitor" running
outside
>of the EJB server which acted as the EJB client on behalf of the incoming
>messages. I know from experience that writing a message monitor is a big
job,
>and I personally would not recommend my clients to do it.
>
>Sun tell us that the next version of EJB will include some form of
integration
>with JMS, which I think means that the EJB server will become a message
monitor.
>Maybe that will address your requirement.
>
>Ian McCallion
>CICS Business Unit
>IBM Hursley
>[EMAIL PROTECTED]
>Tel: ++44-1962-818065
>Fax: ++44-1962-818069
>
>===========================================================================
>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".
