Storing IDL Artifacts

Storing IDL Artifacts

Post by Michael McKnerne » Sun, 29 Jun 2003 07:02:34



Hi,

We have the requirement to store our IDL artifacts (interfaces, structs,
unions, etc) in a text file and then reconstitute them later.  Does
anyone have any tips on how to do this in a generic way, i.e., it would
be too laborious to write streaming operators for all our types
manually, considering the level of type nesting.

Btw- we're using Orbix 2000 now but earlier on we used Visibroker which
had proprietary streaming operators that got generated by the idl
compiler and now we're in a world of hurt without them:-(

thanks for any ideas,
Mike

 
 
 

Storing IDL Artifacts

Post by Boris Kolpacko » Wed, 02 Jul 2003 01:12:43



> We have the requirement to store our IDL artifacts (interfaces, structs,
> unions, etc) in a text file and then reconstitute them later.  Does
> anyone have any tips on how to do this in a generic way, i.e., it would
> be too laborious to write streaming operators for all our types
> manually, considering the level of type nesting.

You may want to look at Dynamic Any (in particular section 9.3.2).

The more subtle question would be whether you want to store the object
reference of an interface or the state of the implementation of this
interface.

hth,
-boris

 
 
 

Storing IDL Artifacts

Post by Bernard Normie » Wed, 02 Jul 2003 23:15:24


Since you're using Orbix 2000 presumably in C++, you could also consider
using the Persistent State Service (PSS) implementation that comes with it.
It allows you to easily store any IDL types in a Berkeley DB database
(these are regular binary files).

Orbix 2000 also provides proprietary streaming classes and functions
(streams and  streamables), but AFAIK they are not fully documented. I'd
recommend you contact IONA support if you want to use them.

Cheers,
Bernard

 
 
 

Storing IDL Artifacts

Post by Steve Vinos » Thu, 24 Jul 2003 22:18:24



> Hi,

> We have the requirement to store our IDL artifacts (interfaces, structs,
> unions, etc) in a text file and then reconstitute them later.  Does
> anyone have any tips on how to do this in a generic way, i.e., it would
> be too laborious to write streaming operators for all our types
> manually, considering the level of type nesting.

> Btw- we're using Orbix 2000 now but earlier on we used Visibroker which
> had proprietary streaming operators that got generated by the idl
> compiler and now we're in a world of hurt without them:-(

My advice is to go portable and use the Codec interfaces in CORBA. See
section 13.8 of CORBA 2.6.1. These do not tie you to internal details
of things like Orbix 2000 Streamables. You use it something like this:

CORBA::Object_var obj =
orb->resolve_initial_references("CodecFactory");
IOP::CodecFactory_var cf = IOP::CodecFactory::_narrow(obj);
IOP::Encoding enc = { IOP::ENCODING_CDR_ENCAPS, 1, 2, };
IOP::Codec_var codec = cf->create_codec(enc);

CORBA::Any any;
any <<= some_value_to_encode;
CORBA::OctetSeq_var octets = codec->encode(any);

// or

CORBA::OctetSeq_var octets = codec->encode_value(any);

The octet sequence will then contain a CDR encapsulation of the any if
you use encode(), or just the value part of the any if you use
encode_value(). To decode, you pass the sequence to code->decode() or
decode_value(). Writing out the CDR encapsulation obtained from
encode() into a file won't give you a readable text representation,
but it will give you the ability to portably store and retrieve your
IDL artifacts.

--steve

--
Steve Vinoski                      vinoski at iona.com
Chief Engineer, Product Innovation
IONA Technologies  http://www.iona.com/hyplan/vinoski/
200 West St.                     Waltham, MA USA 02451

 
 
 

Storing IDL Artifacts

Post by Michi Hennin » Sat, 26 Jul 2003 06:21:36



Quote:

> My advice is to go portable and use the Codec interfaces in CORBA. See
> section 13.8 of CORBA 2.6.1. These do not tie you to internal details
> of things like Orbix 2000 Streamables.

> [...]

> The octet sequence will then contain a CDR encapsulation of the any if
> you use encode(), or just the value part of the any if you use
> encode_value(). To decode, you pass the sequence to code->decode() or
> decode_value().

This works, but make sure that there aren't any wide characters or wide
strings anywhere in the data. For wide characters/strings, to correctly
encode and decode the data, the codeset must be known. The codeset
is negotiated via the GIOP codeset service context in IORs and, therefore,
an attribute of object references. Once negotiated, the codeset is attached
to a connection.

An Any value can be sent over different connections that each have a
different negotiated codeset. This means that, to correctly encode a
wide char/string into CDR, the run time must know over what connection
the value will be sent; if an Any contains wide characters or wide strings,
the same knowledge is required. The Codec interface doesn't have that
information and, hence, cannot know how to encode or decode wide
characters and strings.

The only way I can think of to deal with this is to write the codeset
information as a separate item of data if you have wide chars/strings.
(But there is no standard API that would return what the negotiated
codeset is for a particular IOR.) Maybe the Codec interface could
be modified to also accept a codeset identifier that tells it how to deal
with wide chars/strings, or the spec could be changed to require a
codec to always write use a defined codeset, such as Unicode.

Cheers,

Michi.

--
Michi Henning              Ph: +61 4 1118-2700
ZeroC, Inc.                http://www.zeroc.com