Re: Avis transport and msg bridges not decoupled to allow use of one without the other


Michael Schonberg <mschonberg@...>
 

David,

I think that you may be able to use the Avis payload as it stands purely through
the payload bridge and MamaMsg interfaces. See the inline commentary for
details.

This hightlights the larger issue: we need a good open source payload!
Ultimately, I would like to see a number of open source payloads, but one decent
one would be a good start. I have been looking at Google Protocol Buffers, and I
think that it might work well. This is a topic for another thread, but worth
mentioning here.

On Tue, 22 May 2012, David Ashburner wrote:

Hi Guys, I have been looking that example payload and bridge code and doing
some test coding around building a different bridge. Initially I was thinking
of just doing the bridge and using the Avis msg payload, however I think the
Avis payload and transport bridges are a little tightly coupled to allow one
to be used without the other. this may be inadvertent or done for optimisation
reasons but given it is the only example is not so good.
I agree that the coupling you describe is not good. I think that it is possible
to use the Avis payload in another transport without using the Attributes
directly. The Avis transport needs the Attributes to specify the topic as I
describe below. Other middlewares should be able simply use the MamaMsg and
msgBridge APIs.

Payloads and transports are intended to be completely independent in OpenMAMA:
transports should pass byte arrays to payloads to decode incoming messages and
rely on the payload implementation to encode messages to byte arrays for
publishing.

The Avis middleware/transport bridge access the Attributes directly in the
following methods from msg.c:
avisBridgeMamaMsg_destroyMiddlewareMsg()
avisBridgeMamaMsg_detach()
avisBridgeMamaMsg_getNativeHandle()
avisBridgeMamaMsgImpl_setAttributesAndSecure()

I think that they could all be replaced to mamaMsg_xxx() and msgBrdige->xxx()
calls, but I need to take a closer look to be certain.

I will reach out to the author of the bridge and try to determine the rational
for accessing the Attributes directly rather than through the bridge.


I am assuming that a transport bridge should be able to function without any
hard coded information about the payload format being used, so in the code
fragment below the passed in mamaMsg could be one of a nunber of payload
implementations. The call mamaMsgImpl_getPayloadBuffer() should return a
packed message buffer ready for passing to the transport for sending.
This is correct; however, the Avis transport can only send Avis "Attribute"
objects and it musg add topic information to the Attributes prior to
publishing and extract them on receipt. This is necessary because Avis/Elvin is
content based rather than topic based. We fake topic based messaging by adding a
field that specifies the topic for the message and subscribe to all messages
that contain the desired topic field value. This code is in publisher.c (the
code you quote below) and sub.c.

Other transports for topic based middlewares should not need to embed the topic
in the payload, and therefore, do not need cast the void pointers to Attributes.

Regards,
-Mike


The Avis transport bridge makes the assumption that it will receive an
Attribute object, tweaks with this object then passes it to the sending
routine. I can see why it is more efficient for the getPayloadBuffer to return
the Attribute object rather than a flattened buffer as the later elvin_send
call takes and Attribute object as a parameter so to avoid serialising and
un-serialising again the assumption is made that a pointer to the Attribute
object will be passed.

Digging upstream inside the getPayloadBuffer() call it is resolved to the avis
payload bridge function avismsgPayload_getByteBuffer(). In this function a
pointer to the Attributes is returned instead of the Attributes being
serialised with avismsgPayload_serialize(). I understand that is not optimal
to serialize, then have to unserialize again only to have the message
serialized again in the send but I'm thinking that ba more flexible solution
would be to do it properly and create a patch to Avis to add a send method for
a pre-serialised buffer.

Interested if anyone else has come across this and if any sees it as a
problem. Regards, David

snip ----bridge/avis/publish.c ----x

 146 /*Send a message.*/
 147 mama_status
 148 avisBridgeMamaPublisher_send (publisherBridge publisher, mamaMsg msg)
 149 {
 150     mama_size_t        dataLen;
 151     mama_status        status
 152     Attributes* attributes = NULL;
 153    
 154     CHECK_PUBLISHER(publisher);
 155
 156     status = mamaMsgImpl_getPayloadBuffer (msg, (const void**)&attributes, &dataLen);
 157     if (attributes == NULL)
 158         return MAMA_STATUS_INVALID_ARG;
 159
 160     mamaMsg_updateString(msg, SUBJECT_FIELD_NAME, 0, avisPublisher(publisher)->mSubject);
 161
 162     if (!elvin_send(avisPublisher(publisher)->mAvis, attributes)) {
 163         mama_log (MAMA_LOG_LEVEL_ERROR, "avisBridgeMamaPublisher_send(): "
 164                   "Could not send message.");
 165         return MAMA_STATUS_PLATFORM;
 166     }


Join Openmama-dev@lists.openmama.org to automatically receive all group messages.