Randy,
Yes, you are a bit more accurate than I was.
In EJB, the developer must define the remote interface, and the developer
must implement the business methods and the EJB callback methods (although
in many cases they can be left empty). The EJB deployment tools
automatically generate the EJB wrapper objects.
In MTS, the developer implements the business methods, but doesn't have to
implement any callback methods. The developer must code transaction commit
and rollback demarcation statements, though: If everything goes right, the
developer must call SetComplete on the transaction context object. If
anything goes wrong, the developer must call SetAbort on the transaction
context object. EJB can automate transactions more fully than MTS because
EJB is language-dependent. Java's exception model allows the container to
accurately determine the success or failure of the transaction. Other
languages don't necessarily use such a tight exception model, so MTS may not
be able to determine the status of the transactions. In EJB, you never have
to code transaction commit or rollback calls. If the method completes
without an exception, the container commits the transaction. If an exception
is thrown, the container aborts the transaction.
It gets slightly more complicated when transactions are propagated across
method calls. The container only commits or aborts the transaction in the
method in which it started the transaction. Let's give an example:
Methods A and B both have the TX_REQUIRED transaction attribute. Client
calls method A with no transaction context. Container starts a transaction.
Method A calls method B. Container enrolls Method B into the transaction.
Method B throws an exception. The container returns the exception to Method
A. If Method A doesn't catch the exception, it gets propagated back to the
client, and the container will abort the transaction. But if Method A
catches the exception, it can attempt to recover the transaction. The
container won't abort the transaction until Method A determines that it
can't fix the problem and returns an exception to the client. You have a
potential rat hole here if Method A gets too tenacious and refuses to give
up. But Method B might be able to determine that the problem is catastrophic
and not worth attempting to recover. Therefore Method B can call
SetRollbackOnly in the context object. This attribute indicates that the
transaction must be aborted.
Anne
-----Original Message-----
From: Mcree, Randy [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 02, 1999 11:38 AM
Subject: Re: EJB, MTS comparison anywhere?
Ann,
The sentence highlighted below seems to be incorrrect. I'm seekinbg
clarification.
I believe the deployment tools automatically generate all EJB wrapper
methods.
Or are you perhaps referring to the callbacks made into the bean code for
activation, passivation, etc.?
If so, the terminology "wrapper method" seems to be incorrect.
Randy
COMPAQ
> -----Original Message-----
> From: Anne Thomas [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, April 02, 1999 6:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB, MTS comparison anywhere?
<snip>
> The MTS and EJB component models are very similar. Both work by
> intercepting
> method calls and inserting services based on a set of attributes defined
> at
> deployment time. MTS uses a common wrapper to intercept the method calls
> (the MTS executive, which is called automatically by the COM runtime). EJB
> requires a different set of wrappers for each component type (EJBHome) and
> each component instance (EJBObject).
> EJB component developers need to implement the wrapper methods,
> MTS component developers do not need to
> implement the wrapper methods. MTS is simpler for simple programs, but
> doesn't give you as many options, as many services, or as much control.
> EJB
> allows you more flexibility and it allows you to more easily build more
> complex application systems.
<snip>
===========================================================================
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".
