remoting-corba-developer — Developer discussion list

[Remoting-corba-developer] wstring support

[Kristopher J. <kr...@kr...>]

There have been some questions about support for wchar and wstring.  There
are two things that have to be done to support wide characters:

- wchar/wstring requires version 1.1 or 1.2 of GIOP.  Remoting.Corba
currently only supports GIOP 1.0, so some low-level protocol work has to be
done.

- I don't know much about wide character codesets.  Reading the CORBA/IIOP
specification sections on different wide-character codesets, codeset
negotiation, and so on makes my head hurt.

I don't have immediate plans for adding wchar/wstring support--there are
many other tasks that are of higher priority to me.  If somebody else wants
to figure it out, I'll be glad to incorporate whatever patches people can
provide.

--
Kristopher Johnson
kr...@kr...
http://kristopherjohnson.net/

Re: [Remoting-corba-developer] RE: IIOP Server Channel

[Rajbeer <rd...@sd...>]

On Fri, 4 Apr 2003, Kristopher Johnson wrote:

> Regarding how my mapping would go over with the OMG, the only thing that
> really jumps out at me is the use of System.String for the CORBA 'char' and
> 'string' types.  It might make more sense to map .NET's System.String to a
> wstring, as they are natively wide strings.  But Remoting.Corba doesn't
> support wide strings or wide characters yet, and the applications I use
> don't require wide characters, so I plan to stick with single-byte
> characters for a while.

What would be involved in adding wstring support?  I have a remote server
that I'd like to try connecting to but it has some wstring's in their IDL.

It's stupid because I know this remote server is just holding ascii inside
those wstring data types, maybe some type coercion is possible?

--Ricky

[Remoting-corba-developer] RE: IIOP Server Channel

[Kristopher J. <kr...@kr...>]

One of my goals with Remoting.Corba was to provide a "natural" mapping =
of
.NET types to CORBA types.  To every extent possible, I want the =
interfaces
to look like the interfaces one would use with any Remoting server or
client, whether it is using IIOP, SOAP, or the .NET binary format.  The =
goal
is to make the IIOP channel as transparent as possible and prevent any
"CORBA junk" from affecting how people have to implement their =
applications.
Ideally, if somebody already has a .NET Remoting client or server, all =
they
have to do to convert it to a CORBA client or server is add the IIOP =
channel
and maybe add a few custom attributes to the existing interfaces.

For this reason, I have deliberately avoided something like the Java
mapping.  The Java mapping has all those "xxxHelper", "xxxHolder", and
"xxxPackage" classes, and requires various things to inherit or use
org.omg.CORBA.* types.  There is nothing wrong with that, but it does =
make a
CORBA server's interface look nothing at all like a non-CORBA object
interface, and requires some developer training to use it properly.

Many aspects of the Java mapping exist to work around problems with Java =
or
to conform to Java-specific idioms.  For example, the xxxHolder classes =
are
needed because Java can't pass arguments by reference.  The enum mapping =
is
complex because Java doesn't have a natural way of defining enumerated
types.  Its boxed types are not as easy to use as they are in C#.  It =
relies
on inheritance to specify features that might be better represented in =
.NET
using custom attributes.  And so on.

For a full-blown C# ORB designed for CORBA-centric systems, something =
like
the Java mapping might make sense, but I wouldn't want to modify
Remoting.Corba to support it.  I personally feel that a C# mapping based
upon the Java mapping would be really ugly and a step backwards.  But it =
may
be the quickest path to official acceptance, so from a political =
standpoint,
it may be the way to go.

Regarding how my mapping would go over with the OMG, the only thing that
really jumps out at me is the use of System.String for the CORBA 'char' =
and
'string' types.  It might make more sense to map .NET's System.String to =
a
wstring, as they are natively wide strings.  But Remoting.Corba doesn't
support wide strings or wide characters yet, and the applications I use
don't require wide characters, so I plan to stick with single-byte
characters for a while.

I don't define any mapping for IDL 'union', fixed-point, or array =
classes.
For unions, I think some IDL-compiler-generated Java-like class would be
fine, as that is a CORBA-specific thing.  For fixed-point, the .NET
System.Decimal class seems like the most natural mapping.  For IDL =
arrays, a
mapping to .NET arrays makes sense but you need to make sure that they =
don't
get treated as sequences by the reflection-driven marshaling engine.  =
(My
plan has been to implement a CorbaArrayAttribute that can be affixed to
fields, parameters and return types to specify their marshaling =
attributes,
much like the CorbaSequenceAttribute works for IList types.)

I don't have a mapping for Anys or valuetypes yet.  My impression is =
that
CORBA valuetypes exist primarily to support interoperability with =
EJB/J2EE
stuff, so an RMI-to-IDL-like mapping might make sense.  I'm not sure =
what to
do about Anys yet; it would be nice if I could just use the 'object' =
type
and then let servers and clients use the normal .NET reflection,
type-checking and casting operators to determine the specific type of
element.  But I may wimp out and do a DynAny-like mapping.

One issue with OMG compliance is that in addition to mapping all the =
types
and interfaces, they also require a language-specific mapping of the ORB
core API.  Remoting.Corba doesn't have an "ORB", so I can't help you =
there.
You might want to check with the Harmless ORB developer to see what his
thoughts are.

It probably also makes sense to look at the SOAP/CORBA mappings, as it =
would
be annoying if people had to totally rewrite their code if they moved
between using a C# ORB and using a SOAP bridge.  My guess would be that =
the
OMG would favor a mapping consistent with that over Remoting.Corba's
mapping.

So, to sum up what turned out to be a long message, the intent of
Remoting.Corba's mapping probably differs from what the OMG would want.
Remoting.Corba is designed to be as un-CORBA-like as possible while =
still
being interoperable with CORBA systems.

You are welcome to use R.C and anything on the web site as the basis for
proposals.
=20
-- Kris


> -----Original Message-----
> From: Damian ONeill [AePONA] [mailto:Dam...@ae...]=20
> Sent: Friday, April 04, 2003 5:00 PM
> To: Kristopher Johnson
> Cc: dam...@ae...;=20
> rem...@li...; 'Simon=20
> Guest'; 'Marius Rochon'; ta...@mi...
> Subject: RE: IIOP Server Channel
>=20
>=20
> We have a fair bit of sway with Iona, they have in the past=20
> and are currently doing some modifications to the core java=20
> orb for us at the moment.  I will have a chat with them so=20
> see if they would be interested in submitting a joint=20
> proposal.  I imagine that there would not be a lot of work in=20
> taking the current idl to java and modifying it to idl to c#.
>=20
> The mapping that you currently use as defined on the wiki, do=20
> you think that any of these would be controversial? If not=20
> and you dont have an issue with it we could use these as the=20
> basis for the document.
>=20
> D

[Remoting-corba-developer] RE: IIOP Server Channel

[Damian O. [AePONA] <Dam...@ae...>]

We have a fair bit of sway with Iona, they have in the past and are currently
doing some modifications to the core java orb for us at the moment.  I will have
a chat with them so see if they would be interested in submitting a joint
proposal.  I imagine that there would not be a lot of work in taking the current
idl to java and modifying it to idl to c#.

The mapping that you currently use as defined on the wiki, do you think that any
of these would be controversial? If not and you dont have an issue with it we
could use these as the basis for the document.

D

Quoting Kristopher Johnson <kr...@kr...>:

> There is a project in the solution called RemotingCorbaTestServer which is a
> C#-implemented Remoting server that uses the IiopServerChannel.  This is
> what is used for the tests, which are the same test cases that are used for
> the CorbatTestServers implemented with TAO, omniORB, and JacORB.  Currently,
> three of the test cases fail, due to the restrictions on exception handling
> and object-reference marshaling that I described in the announcement.
> 
> I checked into official OMG C# mapping activities.  Apparently, there was an
> OMG committee that started this a while ago, but they stopped and erased all
> history of the effort.  They seem to be more interested in providing a
> SOAP/CORBA bridge standard than in providing mappings for .NET languages.
> 
> I asked about this on the comp.object.corba newsgroup, and got answers
> ranging from "Only a complete idiot would use .NET" to "Microsoft is evil."
> The OMG's efforts seem to be pretty Java-centric these days, so I am not
> hopeful that any officially blessed C# mapping would be considered unless
> Iona or another big vendor pushes it.
> 
> -- Kris
> 
> 
> > -----Original Message-----
> > From: Damian ONeill [AePONA] [mailto:Dam...@ae...] 
> > Sent: Friday, April 04, 2003 4:19 PM
> > To: Kristopher Johnson
> > Cc: rem...@li...; 'Simon 
> > Guest'; 'Damian ONeill [AePONA]'; 'Marius Rochon'; 
> > ta...@mi...
> > Subject: Re: IIOP Server Channel
> > 
> > 
> > Thanks Kris, I will try this with the Iona orb over the next 
> > few days. When completed I will send the jars as before.
> > 
> > Have you implemented the c# server code for the nunit tests?  
> > Is this available in the cvs?
> > 
> > Kris are you aware are the OMG doing a mapping document for 
> > c#?  I can find very little info on this, the only thing I 
> > found was a newsletter item on the OMG website saying that 
> > they were considering doing it by nothing else.
> > 
> > D
> 
> 

[Remoting-corba-developer] RE: IIOP Server Channel

[Kristopher J. <kr...@kr...>]

There is a project in the solution called RemotingCorbaTestServer which =
is a
C#-implemented Remoting server that uses the IiopServerChannel.  This is
what is used for the tests, which are the same test cases that are used =
for
the CorbatTestServers implemented with TAO, omniORB, and JacORB.  =
Currently,
three of the test cases fail, due to the restrictions on exception =
handling
and object-reference marshaling that I described in the announcement.

I checked into official OMG C# mapping activities.  Apparently, there =
was an
OMG committee that started this a while ago, but they stopped and erased =
all
history of the effort.  They seem to be more interested in providing a
SOAP/CORBA bridge standard than in providing mappings for .NET =
languages.

I asked about this on the comp.object.corba newsgroup, and got answers
ranging from "Only a complete idiot would use .NET" to "Microsoft is =
evil."
The OMG's efforts seem to be pretty Java-centric these days, so I am not
hopeful that any officially blessed C# mapping would be considered =
unless
Iona or another big vendor pushes it.

-- Kris


> -----Original Message-----
> From: Damian ONeill [AePONA] [mailto:Dam...@ae...]=20
> Sent: Friday, April 04, 2003 4:19 PM
> To: Kristopher Johnson
> Cc: rem...@li...; 'Simon=20
> Guest'; 'Damian ONeill [AePONA]'; 'Marius Rochon';=20
> ta...@mi...
> Subject: Re: IIOP Server Channel
>=20
>=20
> Thanks Kris, I will try this with the Iona orb over the next=20
> few days. When completed I will send the jars as before.
>=20
> Have you implemented the c# server code for the nunit tests? =20
> Is this available in the cvs?
>=20
> Kris are you aware are the OMG doing a mapping document for=20
> c#?  I can find very little info on this, the only thing I=20
> found was a newsletter item on the OMG website saying that=20
> they were considering doing it by nothing else.
>=20
> D

[Remoting-corba-developer] Re: IIOP Server Channel

[Damian O. [AePONA] <Dam...@ae...>]

Thanks Kris, I will try this with the Iona orb over the next few days. When
completed I will send the jars as before.

Have you implemented the c# server code for the nunit tests?  Is this available
in the cvs?

Kris are you aware are the OMG doing a mapping document for c#?  I can find very
little info on this, the only thing I found was a newsletter item on the OMG
website saying that they were considering doing it by nothing else.

D



Quoting Kristopher Johnson <kr...@kr...>:

> If you get the newest stuff out of the CVS repository, you will
> see that there is now an IiopServerChannel class and a bunch
> of tests for it.
> 
> It mostly works.  There are a couple of things it doesn't handle
> properly yet:
> 
> - All user exceptions get mapped to CORBA::UNKNOWN
> 
> - Object references cannot be returned from the server
> 
> I'll be clearing up these remaining issues over the next couple
> of days, and adding some tutorials and other information to
> the wiki.
> 
> Anyway, this message is just to let you know that the server
> channel is there and that it should be working.  So you now have
> the right to complain when it doesn't work.
> 
> --
> Kristopher Johnson
> kr...@kr...
> http://kristopherjohnson.net/
> 
> 

[Remoting-corba-developer] IIOP Server Channel

[Kristopher J. <kr...@kr...>]

If you get the newest stuff out of the CVS repository, you will
see that there is now an IiopServerChannel class and a bunch
of tests for it.

It mostly works.  There are a couple of things it doesn't handle
properly yet:

- All user exceptions get mapped to CORBA::UNKNOWN

- Object references cannot be returned from the server

I'll be clearing up these remaining issues over the next couple
of days, and adding some tutorials and other information to
the wiki.

Anyway, this message is just to let you know that the server
channel is there and that it should be working.  So you now have
the right to complain when it doesn't work.

--
Kristopher Johnson
kr...@kr...
http://kristopherjohnson.net/

[Remoting-corba-developer] IiopServerChannel

[Kristopher J. <kr...@kr...>]

If you retrieve sources from the CVS repository, you may
notice that there is now an IiopServerChannel class.  This
is what I'll be concentrating on for a while.

The IiopServerChannel is not implemented yet.  The stuff
that is checked in is just the bare minimum implementation
needed for compilation.  I'll be checking new stuff in
pretty often, even when it isn't doing anything useful.

I'll post messages to this list and to the wiki indicating
when the server channel is working.  Until then, just ignore it.

--
Kristopher Johnson
kr...@kr...
http://kristopherjohnson.net/

[Remoting-corba-developer] First Message

[Kristopher J. <kr...@kr...>]

This is the first posted message to the developers' list.  Right now, I
think there is only one other subscriber at the moment, so I don't =
expect a
torrent of replies, but maybe someone will look through the archives.

Here's a summary of the current state of the project, and what I am =
planning
to do:

- Development resources are hosted at
http://sourceforge.net/projects/remoting-corba/.  I plan to make =
extensive
use of the CVS repository, Bug Tracker, and Feature Request Tracker.

- The main source of news, documentation, and other information for the
project is the wiki at http://kristopherjohnson.net/cgi-bin/rc/wiki.pl.  =
I
encourage all developers and users to add content to the wiki.

- I am currently working the version 1.2 release of Remoting.Corba.  The
"themes" of this release is interoperability and support for common =
CORBA
IDL data types.  See
http://kristopherjohnson.net/cgi-bin/rc/wiki.pl?Release_Notes/Version_1.2=

for the things I've already done.  See
http://kristopherjohnson.net/cgi-bin/rc/wiki.pl?Upcoming_Work for the =
things
I plan to finish before releasing 1.2.

- Right now, it would probably be difficult for others to do too much
development on the "core" of Remoting.Corba, as I am making major =
changes to
its internal organization.  However, there are a lot of things that =
others
could do to help out.  See
http://kristopherjohnson.net/cgi-bin/rc/wiki.pl?Help_Wanted for a list =
of
suggestions.

I will be monitoring the mailing lists, the SourceForge project forums, =
and
the wiki.  As time goes on, I expect that one or two of these media will =
be
preferred, and the others will be eliminated.  But until others state =
their
preferences, they are all available.

Thanks for your interest in Remoting.Corba.  I hope you find it useful.

--
Kris Johnson