Many systems work well with rather loose levels of consistency. For
instance, if all systems that use optimistic concurrency were to vanish
it would likely shut down the US :>).
In point 2, I believe you are saying that entity beans can't be used to
wrapper legacy systems because they cannot implement a select, read,
update chain of transactions (a typical optimistic concurrency
scenario). Entities typically only cache within a transaction so they
actually force a stricter consistency model than stateful sessions. Some
containers provide more elaborate caching policies tuned to application
specific strategies. An entity implementation of 2 would typically
result in returning the entity instance to its pool after each
transaction and reloading (possibly lazily) its state at the beginning
of the next.
Entities are, in fact, designed to provide just the lightweight wrapper
you describe in point 3.
The entity caching I was referring to earlier was for the case where
multiple entity method calls are made within a transaction. This
frequently occurs because forcing a one method per transaction interface
overly complicates an entity interface.
Ian McCallion wrote:
>
> IMHO this "advantage" is even more theoretical because:
>
> 1. Direct users of the legacy app can change the data and there is no way
> to notify the EB of the change (similar to the "DbIsShared" situation).
>
> 2. Legacy apps frequently (almost invariably) have the notion of a
> multi-transaction conversation such as run (txn a) to select the business
> entity to work on, (user think time), run (txn b) to read the selected data
> and possibly obtain an application-level lock, (user think time), run (txn
> c) to update the data and free the lock. Session beans provide the
> equivalent of a conversation in EJB so a stateful SB can be used
> straightforwardly to wrapper the legacy app. However the semantics of (txn
> a), (txn b), (txn c) cannot be mapped to the events and methods of an EB.
> (Note that as there is a strong analogy between a legacy "conversation" and
> a session bean, if you are unfamiliar with legacy systems you can get an
> idea of the problems by trying to imagine wrappering a stateful session
> bean with an entity bean. Doesn't really work, does it?)
>
> 3. The legacy wrappering requirement is usually to provide a good OO
> representation of the legacy app's capabilities, not to provide a partial
> and inaccurate representation of the legacy app as something it is not,
> namely a database. Thousands of "legacy" systems are being internet-enabled
> today - in weeks rather than months - by wise reuse of existing legacy
> application logic and wise use of the legacy application development
> capability.
>
> 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".
