Your "Connector" to the legacy system does not need to support JTA and
XA coordination if you configure the using Bean to suspend the current
transaction and resume it after the Bean method which calls into the
backend is
finished. This has consequences - you will likely have to program some
compensation if your backend transaction actually changes something
and then you decide to roll back the transaction that was suspended
because the separate transaction that ran in the backend has already
committed.
You can program whatever login information you need by way of
the Environment properties.
You would be advised to provide "Connector" pooling so that when the
Bean asks for a "Connector" with a particular login and session identity,
the pool can provide a warm one. Generating new "connectors" on demand
is expensive and you are likely to lose session state (e.g. stuff in the
CICS transient queues).
If you take this apporach, and suddenly IBM or someone else decides to
provide XA based external coordination of CICS, for example, you just have
to add the JTA support to your connector.
Jim
Jim Rhyne, STSM, Component Broker Tool Architect
[EMAIL PROTECTED], 416 448 4383
IBM Canada Ltd. 2G/846/1150/TOR
1150 Eglinton Ave. E., Toronto, Ont. M3C 1H7 CANADA
Chip Wilson <[EMAIL PROTECTED]> on 04/23/99 11:48:36 AM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Jim Rhyne/Somers/IBM)
Subject: Re: EJB and native methods; also, restrictions in spec
I can't speak for Jim, but I have come to the same conclusion as you. I
think EJB needs a way to easily integrate Legacy systems, and BMP seems
like
the right way to do it, but requiring that the Legacy system interface with
JTA is definitely a burden.
I don't know anything about moscone, but the 1.0 spec does not require that
the EJB server's transaction service be an implementation of JTA, so even
if
you have a Legacy system that integrates with JTA, it is not guaranteed to
work with all 1.0 compliant servers.
> -----Original Message-----
> From: Tom Valesky [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, April 23, 1999 10:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB and native methods; also, restrictions in spec
>
> Really, I was just wondering if it's _possible_ to invoke
> native methods from an EJBean. But...
>
> You're saying that the only safe way to communicate with
> a legacy system from an EJB is to build an XAResource
> architecture around the legacy system in question? Since
> _vendors_ can't seem to do this in a timely fashion,
> I'd say it will effectively be impossible for 99.9% of MIS
> shops, and probably not worth the time for the other 0.1%.
> So, to integrate a legacy system with a new EJB system,
> your choices are:
> 1) Wait for the vendor of the legacy system to build an JTA-compliant
> interface around their product.
> 2) Build your own JTA-compliant interface around their product.
> 3) Replace their product with one whose vendor provides a
> JTA-compliant interface.
>
> Would you say that this is a fair statement?
>
>
==========================================================================
> =
> Tom Valesky -- [EMAIL PROTECTED]
> http://www.patriot.net/users/tvalesky
>
> -----Original Message-----
> From: Jim Rhyne <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Friday, April 23, 1999 10:17 AM
> Subject: Re: EJB and native methods; also, restrictions in spec
>
>
> >Tom,
> >I can't tell what you have in mind, but I would urge you to look at how
> >JDBC works in conjunction with the EJB container to provide
> >connectivity. I am not talking about the JDBC APIs or SQL, but
> >rather how connection pools are managed in the server environment
> >and how things like security and transactions are handled.
> >Calling out to a backend directly from an EJB is generally not a good
> idea.
> >Jim
> >
> >Jim Rhyne, STSM, Component Broker Tool Architect
> >[EMAIL PROTECTED], 416 448 4383
> >IBM Canada Ltd. 2G/846/1150/TOR
> >1150 Eglinton Ave. E., Toronto, Ont. M3C 1H7 CANADA
> >
> >
> >
> >Tom Valesky <[EMAIL PROTECTED]> on 04/23/99 03:16:53 AM
> >
> >Please respond to A mailing list for Enterprise JavaBeans development
> > <[EMAIL PROTECTED]>
> >
> >To: [EMAIL PROTECTED]
> >cc: (bcc: Jim Rhyne/Somers/IBM)
> >Subject: EJB and native methods; also, restrictions in spec
> >
> >
> >
> >
> >
> >Can an EJBean have native methods?
> >
> >I can't find an explicit prohibition in the spec, but it seems like
> >allowing
> >a bean to call native methods would open a rather large can of worms.
> >On the other hand, I can see a couple of situations where it'd be handy
> >to have this option (mainly in the MIS development environment, where
> >you sometimes have to build interfaces to _truly_ oddball legacy
> >systems).
> >
> >PS re: restrictions -- Section 16.4 says "this is only a partial list of
> >restrictions that the enterprise developer must observe." Are there
> >plans to release a canonical, complete, and exhaustive list of
> restrictions
> >that EJB developers must observe?
> >
>
>=========================================================================
> ==
> > Tom Valesky -- [EMAIL PROTECTED]
> > http://www.patriot.net/users/tvalesky
> >
>
>=========================================================================
> ==
> >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".
>
>
==========================================================================
> =
> 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".
===========================================================================
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".
