Sacha,
You raise some very interesting questions. My thoughts are below, although
I want to quickly point out that there are a number of different ways to
answer your questions, and my comments are ... well ... mine ;-)
Sacha Labourey wrote:
>
> Hello,
>
> I have some general EJB questions.
>
> Imagine the case where we use a a CORBA/IIOP client (in C++ for example)
> accessing a IIOP compliant EJB server.
>
> 1) An EJB server speaking to a Java client may provide a quite sophisticated
> dynamic home or remote stub i.e. it could for example provide client
> fail-over algorithm decision in the stub by downloading it to the client.
> But if you use a standard CORBA/IIOP client, the stub is then static (result
> from IDL compilation) and no particular behaviour can be sent from the
> server to the client. Is this right? If yes, it means that all clients are
> not equals regarding EJB access (Java client may be clever). Right?
Absolutely right. If you RMI stub has a lot of smarts, then it is
very likely that those smarts are not going to be preserved when using
an IDL-based client (such as C++). If one anticipates this problem,
then one is inclined to do such fail-over/load-balancing smarts on the
server side, so that any client will see the same behavior, regardless
of implementation language. That is, the AppServer will not rely on
smart stubs, so much as a smart server.
> 2) When a Java client want to persist a reference to an entity bean, it
> calls getHandle on it and serialises the reference. As this behaviour is not
> possible from a non Java client using IIOP (it is? value object?) , how to
> do it? directly using the CORBA object_to_string operation on the entity
> reference? If yes, does something prevent us to do it even from a Java
> client (by using object_to_string) as it is simpler?
I agree that using ORB.object_to_string and ORB.string_to_object as a
way to convert an EJB Object reference to a persistable representation
(and back) is the preferred approach for a system built on IIOP. Note,
however, that such code will not be portable to servers not running on
a CORBA/IIOP sub-system. Obviously, going forward, IIOP is becoming
more and more a required part of J2EE, so over time the number of
AppServer not supporting IIOP will deminish.
> In a more general way, is there any documentation/specification regarding
> differences between accessing an EJB from Java/RMI and from
> WhateverElse/IIOP? The change does not seem trivial (at least some issues
> may be raised).
Again, it depends on the design of the AppServer. <vendor> In Borland
AppServer, there are no behavioral differences between a C++ client and
a Java client, when accessing EJBs. This is due to the fact that we
anticipated the problems you discuss, and as much possible put the smarts
on the server side. (For example, all load-balancing decisions are made
on the server side.) Where this was not possible, we provide the same
client-side smarts in VisiBroker for C++ as we do in VisiBroker for Java,
which means that your Java-based RMI-over-IIOP clients see the exact
same behavior as your C++-based IDL-over-IIOP clients. </vendor>
-jkw
===========================================================================
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".
