Qpid
  1. Qpid
  2. QPID-2505

WCF project needs to encode/decode all AMQP data types

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: None
    • Fix Version/s: 0.9
    • Component/s: WCF/C++ Client
    • Labels:
      None
    • Environment:

      Windows Server 2008

      Description

      Currently the WCF Interop project encodes/decodes only string and int data types. The project needs to do all the AMQP data types.

      • In directory wcf/src/apache/qpid/interop source files InputLink.cpp and OutputLink.cpp have convenient TODO: markers exposing where the encoder/decoder code might go.
      • The dotnet project seems to have what might be needed in client/transport/codec/*.

      The effort would be to move the code from dotnet into wcf/interop.

        Activity

        Hide
        Gordon Sim added a comment -

        Another option to consider is to provide translation between qpid::type::Variant in c++ and the .net/c# typesystem. You can convert a Variant::Map to/from qpid::framing::FieldTable using qpid::amqp_0_10::translate() (see qpid/amqp_0_10/Codecs.h).

        Show
        Gordon Sim added a comment - Another option to consider is to provide translation between qpid::type::Variant in c++ and the .net/c# typesystem. You can convert a Variant::Map to/from qpid::framing::FieldTable using qpid::amqp_0_10::translate() (see qpid/amqp_0_10/Codecs.h).
        Hide
        Cliff Jansen added a comment -

        Note that there are two levels of translation.

        The AmqpTypes subdirectory is meant to eventually provide traditional
        encoding/serialization from AMQP typed objects to and from binary wire
        representations. This is where the major work will go.

        The translation in InputLink.cpp and OutputLink.cpp is between .NET
        managed objects and C++ native space objects. This happens in the
        context of passing headers, not the message body content. For the
        simple types looked at so far, the approach has been to call the most
        direct managed or native getter/setter/constructor of the type. For
        arbitrarily complex headers, presumably a full encode/decode step will
        be necessary. It will be a judgement call when to use either
        mechanism. But header translation is unlikely to be a performance
        bottleneck, so you should prefer simplicity over performance to start
        with.

        Show
        Cliff Jansen added a comment - Note that there are two levels of translation. The AmqpTypes subdirectory is meant to eventually provide traditional encoding/serialization from AMQP typed objects to and from binary wire representations. This is where the major work will go. The translation in InputLink.cpp and OutputLink.cpp is between .NET managed objects and C++ native space objects. This happens in the context of passing headers, not the message body content. For the simple types looked at so far, the approach has been to call the most direct managed or native getter/setter/constructor of the type. For arbitrarily complex headers, presumably a full encode/decode step will be necessary. It will be a judgement call when to use either mechanism. But header translation is unlikely to be a performance bottleneck, so you should prefer simplicity over performance to start with.
        Hide
        Gordon Sim added a comment -

        My suggestion above was for the second of these, i.e. translation between FieldTable and .Net types which seemed to fit naturally in the sections of InputLink/OutputLink that already make an attempt at this (I suspect using Variant::Map will be simpler and cleaner).

        However for map-message encoding (i.e. of the message body) it may also be possible to use the c++ implementation, see qpid/amqp_0_10/Codecs.h and the encode()/decode() methods in qpid/messaging/Message.cpp. Whether this is better or worse than porting over the full type system into c# (using the 0-10 dotnet clients codec as source) I am not sure however. Merely suggesting an option that may not be obvious.

        Show
        Gordon Sim added a comment - My suggestion above was for the second of these, i.e. translation between FieldTable and .Net types which seemed to fit naturally in the sections of InputLink/OutputLink that already make an attempt at this (I suspect using Variant::Map will be simpler and cleaner). However for map-message encoding (i.e. of the message body) it may also be possible to use the c++ implementation, see qpid/amqp_0_10/Codecs.h and the encode()/decode() methods in qpid/messaging/Message.cpp. Whether this is better or worse than porting over the full type system into c# (using the 0-10 dotnet clients codec as source) I am not sure however. Merely suggesting an option that may not be obvious.
        Hide
        Cliff Jansen added a comment -

        Moving this to next release.

        Show
        Cliff Jansen added a comment - Moving this to next release.
        Hide
        Chuck Rolke added a comment -

        WCF does not need all the data types.

        Show
        Chuck Rolke added a comment - WCF does not need all the data types.

          People

          • Assignee:
            Cliff Jansen
            Reporter:
            Chuck Rolke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 96h
              96h
              Remaining:
              Remaining Estimate - 96h
              96h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development