That's what we do as well (a bit more complicated in our case, but it's
similar). We plan to use WebLogic. We did some initial prototyping. I was
thinking of a few possible limitations that we plan to test soon, I was
wondering if you have expereinced those limitations:
- Load balancing will not work, since I believe it is done in the RMI client
stubs
- Thread management may not work if it is triggered only when remote RMI
calls are made, since the CORBA wrappers make local calls to the EJB
objects. In that case you may need to manage the threads on your own, but I
don't know if this will not interfere with the rest of the app server
services. In the CORBA world (Orbix in specific) to manage threads you need
to use a filter that is activated only on remote calls. Maybe in EJB it is
does not matter whether the call is local or remote since the remote object
generated by the container interposes every call.
- Distributed transactions can not be initiated by clients using CORBA if
the EJB server is not CORBA-aware and will not examine the CORBA transaction
context
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 17, 1999 8:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ejb-corba mapping
>
>
>
> The way that we handled it was to wrap the Home and Remote
> interfaces with
> CORBA classes. It does work and perform well. There are some
> things you
> want to do to make performance production quality. The ORB we used was
> jBroker and the EJB Server was Ejipt.
>
> -john
>
>
>
>
> Doron Somer <[EMAIL PROTECTED]>@java.sun.com> on 09/17/99 12:18:07 AM
>
> Please respond to [EMAIL PROTECTED]
>
> Sent by: A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
>
>
> To: [EMAIL PROTECTED]
> cc:
>
> Subject: Re: ejb-corba mapping
>
>
> Do you need to keep the same IDL you have right now ? If so,
> the regular
> java2idl may not work for you, as not all IDL interfaces can
> be reverse
> engineered from java (e.g. IDL structs are never generated by
> java2idl). We
> have developed for our internal use, a certain way to provide
> CORBA access
> that allows you to support specific IDLs. This is not the
> standard way of
> providing CORBA access, but it solved our problem. It starts
> from IDL and
> generates the Java remote interface instead of the other way.
> This kind of
> approach does have some limitations (which I can go into in
> more details if
> needed).
>
> If you don't need to keep the exact IDL and only need CORBA
> access, just go
> for one of the EJB servers that support the EJB to CORBA
> mapping, such as
> PowerTier from persistence. Note though that if you need
> interoperability
> between ORBs it is not guaranteed. ORB vendors are having problems
> achieving
> interoperability even before object by value, and many of them don't
> support
> it yet. Even if they do I doubt if they'll interoperate.
>
> Doron
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Nikhil
> > Sent: Monday, August 30, 1999 12:03 AM
> > To: [EMAIL PROTECTED]
> > Subject: ejb-corba mapping
> >
> >
> > Hi,
> >
> > Can anybody tell me how to build server side components in
> java (ejb),
> > which can communicate through corba. I have been trying to
> > find info on
> > this for days, but have not been very successful. Could you also
> > elaborate on the second part of the following statement
> that I read in
> > JAVAPro:
> > "In the java enviornment the EJBObject implements RMI
> > interfaces, and in
> > the Corba enviornment, it implements Corba interfaces."
> >
> > The problem I am facing is that, we have implemented the
> > servers in java
> > and these servers communicate through Corba. Now, we want
> to implement
> > the servers as components using ejb, but want to retain the
> capability
> > of the servers communicating through corba. How do we go about it?
> >
> > Any help is eagerly awaited.
> >
> > Bye!
> >
> > Sawalia Saurabh
> >
> > ==============================================================
> > =============
> > 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".
