avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pankaj Shroff <shro...@gmail.com>
Subject Re: Bypassing "handshake" in Responder
Date Mon, 25 Feb 2013 19:15:23 GMT
Doug - thanks. I think I see what you are saying - but I was trying to
leverage Avro a bit more than perhaps currently designed.

There is a lot of great code in  SpecificResponder that uses JsonDecoder
(for example) to do the data binding between a SpecificData derived object
and its Json representation. The great thing about this is that it
validates against the protocol schema specified (or installed upon
construction of a SpecificResponder object). To be clear, here is an
example:

1) I define Avro protocol file to describe my protocol (.avpr)
2) In the generate-sources phase, avro-maven plugin helps me to generate
Class types for my protocol objects and the interface for the message
exchange (my protocol API). These extend the SpecificRecord object in Avro
IO

3) I write an implementation of the protocol API by implementing the
interface generated by Avro

-- so far everything's great ----

4) Now I want to use the avro-ipc package to create client and server
classes (Requestor and Responder in avro-ipc)

5) My protocol does not "REQUIRE" Avro RPC framing - surely it CANNOT -
otherwise I would be forcing every client and server implementation to have
a dependency on Avro. They might just want to use direct Jackson or direct
Protobuf or direct Thrift support for encoding/decoding - or they may have
legacy code already in place which they would rather not refactor - just
because of the dependency I created.

6) I therefore need hooks to provide my own implementation of
SpecificDecoder and SpecificEncoder.

There is no way to do this.


If, as you suggest, I extend from the DatumReader/Writer classes directly,
I have to write all the code for codehaus.jackson's ObjectMapper and
JsonParser usage, which is currently nicely encapsulated in SpecificData. I
also have to write the invocation logic (that invokes the method
"respond()" in my implementation instance of my protocol API) which I would
have been just loved to reuse.

Also the hooks mentioned in (6) above would have allowed me to leverage in
the future any other encoder/decoder support Avro may provide (if at all) -
such as Protobuf, Thrift, etc.

In general what I was looking for is an "option" really - to tell Avro's
IPC API whether I am using Avro RPC framing or not! If not, it should just
let me handle the framing bits in a derived class or something and bypass
the handshake.

What do you think? :)

Cheers
Pankaj

--







On Mon, Feb 25, 2013 at 1:38 PM, Doug Cutting <cutting@apache.org> wrote:

> This sounds like a different RPC wire format than Avro's.  Avro's
> Requestor and Responder implement Avro's RPC wire format.  Avro's
> Encode/Decoder and DatumReader/DatumWriter APIs should facilitate
> implementation of other RPC wire formats that include Avro data.
> Avro's Transceiver API may or may not be reusable, since it assumes
> Avro-style framing.  Parts of Requestor and Responder *might* be
> reusable and some refactoring of those classes *might* make such reuse
> easier, but there's not that much logic there that's not specific to
> Avro's wire format, so it might be just as easy to reimplement this
> layer for a different wire format.  It's hard for me to say without
> seeing a patch with a proposed refactoring.  Does that make sense?
>
> Doug
>
> On Mon, Feb 25, 2013 at 9:08 AM, Pankaj Shroff <shroffg@gmail.com> wrote:
> > Hi
> >
> > We are using Avro for implementing an open source reference
> implementation
> > of the OpenRTB protocol.
> >
> > We have made a design goal to model the protocol using Avro protocol
> files
> > (.avpr) and generate types defined in the protocol schema using Avro .
> The
> > challenge is that the protocol does not necessarily require the use of
> Avro/
> > Binary wire encoding - or even the use of Avro/ RPC context. In fact many
> > counter parties have proprietary implementations supporting either
> Protobuf
> > or Json encoding.
> >
> > Now, there is a Json encoder/decoder in the Avro package but it seems
> that
> > the approach is a "schema-first" approach. The JsonEncoder assumes that
> the
> > encoding on the wire still follows the Avro Json encoding - which
> includes a
> > handshake followed by schema confirmation on both sides (client and
> server).
> >
> > For the protocol we are implementing - this presents 2 problems if Avro/
> > binary is not the chose encoding type for both sides - and if instead,
> lets
> > say, raw Json encoding is being used
> >
> > 1) the handshake is rather Avro specific - and we would like to
> completely
> > skip it if both sides have agreed on using raw json encoding - there may
> be
> > a separate info-exchange phase in the protocol that is protocol specific
> and
> > does not need to use Avro handshake. Is it possible to use Avro RPC
> without
> > the handshake?
> >
> > 2) we would like to use the data binding and schema resolution as
> > implemented by the SpecificResponder class in Avro - but extend it to use
> > raw JSON - not Avro JSON - encodings.
> >
> > 3) We would prefer not to have to override the "respond(List<buffers>)"
> > method of the base class Responder. This implementation always performs
> > handshake and always uses BinaryEncoder/Decoder which removes any
> > flexibility of using a different encoder /decoder in a derived class. We
> > would prefer if the Responder or some derived class saves the chosen
> > Decoder/ encoder as a protected property of the Responder object.
> Instead of
> > instantiating BinaryEncoder/ Decoder objects on the fly within the
> respond
> > method, it would be great if this was made more extensible and if the
> > Encoder/Decoder can be specified during construction.
> >
> > 4) For future flexibility it would be great to have the handshake
> > functionality available in sub-classes of Responder as an inherited
> method
> > (instead of private scope right now).
> >
> > I would welcome any suggestions/corrections.
> >
> > Pankaj
> >
> > --
> > Pankaj Shroff
> > twitter: @chompi
> > http://github.com/chompi
> > http://github.com/openrtb/openrtb2x
> >
>



-- 
Pankaj Shroff
shroffG@Gmail.com

Mime
View raw message