I guess you did let us know :)))))
my goodness I should really read jb-dev more
impressive
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Francisco Reverbel
|Sent: Monday, July 30, 2001 11:12 AM
|To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] IIOP support
|
|
|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
