activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan (JIRA)" <>
Subject [jira] Resolved: (AMQ-20) XmlMessage type support
Date Thu, 06 Mar 2008 14:18:36 GMT


James Strachan resolved AMQ-20.

    Resolution: Won't Fix

Not sure its worth it as we have Camel to do clever XML stuff now.

We might wanna standardise MIME headers in Camel though...

> XmlMessage type support
> -----------------------
>                 Key: AMQ-20
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Wish
>            Reporter: James Strachan
>            Priority: Minor
>             Fix For: 5.2.0
> A real common use case I see is financial systems, sending around lots of XSD documents
over some protocol (HTTP / JMS) - if both ends know the schema formats - then sending / receiving
an efficient binary XSD format (using longs / ints / doubles for numeric / date types on DataInput/Output)
would totally rock - to the end user it'd look like XML beans or text or DOM but on the wire
could be super fast & no xml parsing.
> e.g. if both sides of the wire were using Java & were using XMLBeans on both sides
as a bean / DOM / XPath / XQuery API, then we could take an xmlbeans schema & lazily bytecode
generate a marshaller per schema to use an efficient wire format, assuming the other end knows
the schema. Then the message on the wire looks like
> [lots of bytes]
> so the reader would load the XSD schema from the given universal URI, if its not created
an xmlbeans schema & marshaller for it yet, do so, then it can decipher the bytes.
> Then in those times where you're sending/receiving 100K messages per hour of the same
schema, you don't have all that XML parsing to deal with - it'd use a super fast ASM.1 style
binary format which to the application programmer could be marshalled into a DOM / bean /
XPath / XQuery model, yet have a super-fast wire format.
> We could expose these types of messages to the user via a special Destination which would
accept either Text messages or Object messages - if the ObjectMessage contains an xmlbean
then it'd use the super-efficient binary serialization on the wire & presenting it to
the user as either an ObjectMessage, TextMessage or maybe a new XmlMessage (or all 3)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message