axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R J Scheuerle Jr" <sc...@us.ibm.com>
Subject Serialization/Deserialization Implementation Evolution
Date Wed, 21 Nov 2001 15:47:23 GMT
I am going to *try* to keep this note short so that I can get some
discussion.

JAX-RPC has some basic requirements on the construction of
serializers/deserializers.
I believe that Doug Davis is doing this initial work.  Doug do you need any
help?

Future versions of JAX-RPC may concentrate on designing <portable>
serializers/deserializers.

We certainly need some documentation in the System Integration Guide to
discuss the
evolution of the encoding...

Please comment on the following:

1) JAX-RPC breaks Serializer, Deserializer, SerializerFactory and
DeserializationFactory
into separate interfaces.  Is it okay to refactor the Axis
Serialization/Deserialization classes so that
they are truly separate classes in separate files?

2) JAX-RPC's TypeMappingRegistry is different than ours.  The JAX-RPC
TypeMappingRegistry
maps a namespace uri to a TypeMapping, and a TypeMapping maps a QName to a
SerializationFactory & DeserializationFactory.
The AXIS TypeMappingRegistry is a hashtable of the QName to the Factories.
Is it okay to refactor the
axis code to use the JAX-RPC TypeMappingRegistry?   Does anyone know of any
beastly problems.

3) If we are going to eventually evolve this code into portable
serializers/deserializers....
    a) Any communication between the Serializers, Deserializers, *Contexts,
*Factory, TypeMappingRegistry
        and the runtime needs to be done through the use of method calls
(preferably through interfaces).  Currently
        a lot of logic takes advantage of public variables, etc.   Even
though we may no know how this code will evolve
       I think we will be in better shape if we can stick to using fully
described interfaces.   Agree??

    b) Can anyone easily explain what should be in Serialization versus
SerializationContext?   My feeling is that
         state information should all be in Context, and the utility
routines should be in the Context?   The same
         issue applies to Deserialization and DeserializationContext.
This is a difficult issue, and I would appreciate comments.

    c) Should we evolve the Serialization and Deserialization interfaces so
that they are not so SAX dependent?

Certainly 1 & 2 take precedence over 3.  I am willing to work on any of
these pieces.   Doug could you send me your thoughts
and indicate where I may help.

Rich Scheuerle
XML & Web Services Development
512-838-5115  (IBM TL 678-5115)


Mime
View raw message