In actually, the NBF buffers is xml format on the wire.

We use XSD to validate these buffers, and get type information of every element from schema which will been used in btXattribute functions.

Yes, it must be very carefully to handle with the buffer string.

Anyway, this xml buffer could be integrated with others, such as content based routing.

Now, I'm working on using JBossESB to do CBR with NBF buffer.

If you are interest , you can find a cbr example on blacktie trunk.

Amos

Hi Francis,

Which tool do you use to convert the FML buffer into the C struct?

Out of interest, can you explain why you needed to use FML and could not get away with using say X_C_TYPE as your buffer type instead? X_C_TYPE allows you to interact with structs by default.

Tom

I'm trying to understand your application,

in Java client you use FML buffer with JOLT, such as:

...

fmlbuf.setString("NAME", "zhfeng");

fmlbuf.setINT("ID", "1234");

session.tpcall(...);

in Server use C, such as:

struct employee {

     char name[32];

     int id;

};

// this struct from view file such as

VIEW Employee

$

#type     cname          fbname     count     flag     size     null

string     name            -               1            -          32        -

long       id                  -               1            -          -          -

END

void service(TPSVCINFO* rqst) {

     FBFR* fml = (FBFR*) rqst->data;

     struct employee buf;

     Fvftos(fml, &buf, "employee");

     ...

     do something with buf

}

you do not want to use fml function in server code as performance is key for your applications.

Is this clear ?

1. convert FML views to our buffer XSD

2. we have a tool to convert XSD schema to JavaBean, you can see example under

    <BLACKTIE_SRC>/jatmibroker-xatmi/src/test/java/org/jboss/narayana/blacktie/jatmibroker/nbf/TestNBFToJavaBean.java

    you can run mvn test -Dtest=TestNBFToJavaBean to see the generate JavaBean code in target/test-classes/EmployeeBuffer.java

    you can consider this as a java fields mapping from the views

3. On the C server, you can only use btXattribute functions to access NBF buffer currently.

In terms of performance, XML maybe not a good choice. I have some interest in google protoc buffer. If you think it is OK, we can work together to support this buffer in blacktie.

Amos Feng wrote:

 

3. On the C server, you can only use btXattribute functions to access NBF buffer currently.

 

It is our plan to support mapping structs to the XML wire format though. We plan to support this for X_COMMON, X_C_TYPE and NBF buffers.

This means the programmer interacts with a struct, but on the wire it is XML so that it can be routed by ESB.

Thanks Tom,

I'm working on this issue Support transcoding of message payload to XML

Hi Francis,

Thanks for reviewing the google buffer. It would be great to work with you on providing a suitably performant wire protocol implementation for BlackTie.

Currently we support a binary wire format with zero compression (this could work faster than a compressed buffer format for certain classes of message as the compression algorithm is omitted).

We also have the XML format which is more useful when you wish to take advantage of routing services for tpcall invocations as the ESB can easily parse the XML. This is what we are finishing off now.

We could introduce a third protocol which deals with larger buffers and compresses them for efficient transfer.

If you would like to work with us on this and have some ideas on what you believe would be the most appropriate wire protocol, that would be excellent. BlackTie has a pluggable transport layer so the replacement of the buffer encoder is a relatively painless operation.

Tom

Hi Francis,

Have you take a look at protobuf-c (c binding for Google's Protocol Buffers) ?

Amos

Hi Francis,

We have raised a Jira for this https://issues.jboss.org/browse/BLACKTIE-379