On Sun, 29 Jul 2001, Ole Husgaard wrote:
> I'll commit my code to a contrib module today or
> tomorrow.
Great, thanks!
> > 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.
Right, full CORBA compliance requires an IR. It certanly will be very nice
to have an IR available for JBoss.
There is actually an user/admin decision here. Many (most?) users/admins
choose not to set up an IR, even if they are using an ORB with IR
support. In this case, _get_interface_def() simply returns nil.
> 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.
Yes, this would be quite useful.
> > 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.
I've tried ORBacus 4.0.5 beta. Its OBV support appears to be incomplete.
JOB-4.0.5 does not handle arbitrary java.io.Serializable instances
(valuetypes with repository ids starting with "RMI:").
> > 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.
With one change, it does (the jboss module, at least):
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/DeploymentException.java,v
retrieving revision 1.6
diff -r1.6 DeploymentException.java
43c43
< public Exception getCause() {
---
> public Throwable getCause() {
> > 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.
Anything (even a compiled skeleton) will require N+1 method invocations
per operation call. N method invocations to unmarshal the arguments, plus
one to marshal the return value, right? My compile-less serverside does
_exactly_ this. The only extra overhead is to wrap basic data types
into objects, so that method arguments are passed on as an Object array.
There is also the overhead of an additional method mapping. JBoss already
has a mapping between home/remote interface methods and container/bean
methods. I have an additional map between CORBA operation names and
home/remote interface methods. This map should eventually handle the name
mangling stuff specified by the Java to IDL mapping, most of which I am
leaving to write later on. One could avoid this overhead by setting up a
map from CORBA operation names straight to container/bean methods, but I
would leave this sort of optimization for a second round.
> > 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.
This sounds very interesting. Might not be easy, though.
> > Were you able to test IIOP-based container invocations with JacORB?
>
> Not yet.
> No IIOP container invoker for JBoss.
I have some container invoker code compiled with jdk 1.4, but it is not
functional yet. Should be able to test it very soon.
Best regards,
Francisco
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
