Hi,
Francisco Reverbel wrote:
> I would be very interested in your code.
I'll commit my code to a contrib module today or
tomorrow.
> Itens 1) and 3) below are pretty much what I was planning to do. I was not
> thinking about setting up a CORBA IR, though. My impression is that
> IDL-generated stubs are the most common way of writing CORBA clients.
Yes. There are two reasons why I implemented an IR:
1) CORBA says that remote objects should implement get_interface(),
and an IR is needed for that.
2) The IR is really just an alternate representation of the IDL
text. So it should be possible to have the IR generate IDL
for non-Java clients to use for creating stubs.
> Agree with you that a fairly complete CORBA implementation for Java is
> required. More specifically: POA, portable interceptors, and OBV
> support. The ORB in jdk 1.3 has neither of these. JacORB already supports
> POA and portable interceptors, and should be a perfect choice by the
> end of August, when OBV support is expected. Meanwhile, the options are
> commercial products like Orbix or Visibroker, or the ORB in jdk 1.4.
Or ORBacus 4. I used to use ORBacus 3.x, but unfortunately the
new free download conditions on ORBacus are not acceptable to
me, and I am not willing to pay when working for free.
> Did some tests with jdk 1.4 and it seems suitable, at least for
> development. Hacked a very simple CORBA server which implemented RMI/IIOP
> objects using a stream-based dynamic skeleton (without idl or rmic
> compilation at all). Was able to call this server both from a pure
> CORBA client and from an RMI client built with rmic-gererated stubs.
Unfortunately, JBoss currently does not compile under 1.4.
> I think a compile-less approach makes perfect sense on the server side,
> but statically generated stubs would still be preferred for clients.
Looks to me like a compile-less serverside will have a little
overhead compared to a compiled serverside, at least N+1 method
invocations per operation call, where N is the number of
arguments.
> RMI/IIOP Java clients would be mostly built with rmic-generated
> stubs, CORBA clients written in other languages would typically use IDL
> stubs. I also believe it would be important to support code downloading of
> Java stubs (even though this requires rmic compilation at deployment
> time, which otherwise would not be needed).
Yes, some kind of code downloading is needed for Java clients.
While I haven't looked into this yet, it would be nice if we
could somehow create a universal Java CORBA stub that could
get its mapping from a custom operation in the IR.
> Were you able to test IIOP-based container invocations with JacORB?
Not yet.
No IIOP container invoker for JBoss.
Best Regards,
Ole Husgaard.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
