activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Thu, 01 Jun 2017 15:58:07 GMT
On 06/01/2017 11:50 AM, Michael André Pearce wrote:
> Really this is much more about how an ObjectMessage serializes the Object. As we have
C++ clients etc that obviously won't be able to understand Java serialized object.
> We use Avro and a schema repo for our dto transfer over the wire, it's been a real performance
boost , and removed some core data issues, and really like to use it over the JMS land.
> One can argue that you could manually code this that you serialize the data manually
first and then just manually send a BytesMessage.
> But I think taking some inspiration from other places where a serdes pattern is done
has really helped (Kafka), from a corporation user approach wiring some prebuilt serdes into
a factory is very easy, having duplicated code in many many apps leaves for issues, and implementation
> The one downside of Kafka is it's lack of spec api, this is one big sell of artemis as
it's JMS compliant. Coding against JMS api for Java estate is a huge win, this is suggesting
taking some of the good bits :).
> Does camel expose this as some sort of JMS API wrapper? I thought it was much more an
EAI solution.
> Cheers
> Mike

Camel does JMS transport:
Camel does AVRO:

> Sent from my iPhone
>> On 1 Jun 2017, at 15:18, Martyn Taylor <> wrote:
>>> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish <> wrote:
>>>> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>>>> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish <>
>>>> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>>>>> I get the use case for using JSON/XML, particularly for cross language
>>>>>> communication.
>>>>>> One way users get around this problem right now is just to serialize
>>>>>> to/from XML/JSON at the client application level and just use JMS
>>>>>> TextMessages to send the data. I guess the idea here to remove that
>>>>>> complexity from the client application and into the client via these
>>>>>> pluggable serializer objects?  Removing the serizliation logic out
>>>>>> code
>>>>>> and into configuration.
>>>>>> Providing I've understood this properly, it seems like a good idea
>>>>>> me.
>>>>>>    so +1.
>>>>>> This problem has already been solved via frameworks like Apache Camel,
>>>>> putting such complexity into the JMS client is solving a problem that's
>>>>> already been solved and in much more flexible and configurable ways.
>>>> Thanks Tim.  I am not a Camel expert in any shape or form, how much
>>>> additional complexity/configuration would be required to do something
>>>> similar with Camel?  My understanding of the proposal here is really just
>>>> to give control back to the user in terms of how their objects are
>>>> serialized.  I'd expect this to be pretty light weight, just allow a user
>>>> to configure a class to do the serialization.
>>> Camel offers conversions for a number of data formats
>> Sure.   Though, one of the drivers (mentioned in this thread) for having
>> control over the de/serialization process was for performance.  Converting
>> to another format is going to obviously make this much worse.
>>> as well as routing amongst numerous protocols, have a look at the
>>> supported data formats page: and
>>> the transports
>>> This doesn't seem to be doing much more for the user than moving the work
>>> they need to do around,
>> Well, it abstracts the de/serialization process out of application code.
>>> they still have to implement or configure the mechanics of the
>>> transformation of the data format to the appropriate JMS message type and
>>> back again.  Even if you bake in something to the client to handle some
>>> common formats you will quickly find that it doesn't meet everyone's needs
>>> and you'll end up implementing a poor mans Camel inside a JMS API
>>> restricted client which seems less than ideal.
>> I agree reinventing the wheel (badly) is not a good idea.  So, if Camel is
>> able to provide us with a solution to the problem, that addresses the
>> issues outlined here.  Then, we should certainly look into it.
>> Cheers.
>>>> On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce <
>>>>>>> wrote:
>>>>>> I think i might be getting the problem, use case you want to go for,
>>>>>> which
>>>>>>> is to possible serialise to JSON or XML, because they're supported
>>>>>>> in
>>>>>>> other languages like c++, which won't read a java serialised
>>>>>>> and
>>>>>>> say for XML you generate objects via an XSD which by default
>>>>>>> serialisable, so you cannot simply add Serializable to the object,
>>>>>>> its
>>>>>>> generated at build.
>>>>>>> Is this the problem we need to solve? If so:
>>>>>>> To get around this normally the tools that generate objects for
>>>>>>> serialisation from schema such as XSD do support a way to toggle
>>>>>>> change
>>>>>>> the generation slightly for some common use cases.
>>>>>>> In case of XSD, where using jaxb it would be to add something
like the
>>>>>>> below to jaxb global bindings:
>>>>>>> <xs:annotation>
>>>>>>> <xs:appinfo>
>>>>>>> <jaxb:globalBindings generateIsSetMethod="true">
>>>>>>> <xjc:serializable uid="12343"/>
>>>>>>> </jaxb:globalBindings>
>>>>>>> </xs:appinfo>
>>>>>>> </xs:annotation>
>>>>>>> like wise if you are generating POJO's from a jsonschema using
for say
>>>>>>> the
>>>>>>> tool jsonschema2pojo  there is a toggle in the maven plugin
>>>>>>> serializable
>>>>>>> which you can switch to true.
>>>>>>> Obviously if you hand crank your DTO Pojo's then it's a case
of simply
>>>>>>> add
>>>>>>> implement  Serializable to the class.
>>>>>>> Cheers
>>>>>>> Mike
>>>>>>> Sent from my iPhone
>>>>>>> On 1 Jun 2017, at 06:57, Michael André Pearce <
>>>>>>>> wrote:
>>>>>>> we could but then it wouldn't work via jms api. Typically if
using jms
>>>>>>>> the only custom or specific broker object is the connection
>>>>>>> the
>>>>>>> rest you code to Jms.
>>>>>>>> Sent from my iPhone
>>>>>>>> On 1 Jun 2017, at 04:10, Clebert Suconic <>
>>>>>>>> wrote:
>>>>>>>> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
>>>>>>>>>> wrote:
>>>>>>>>> Jms api dictates class set in object message to be serializable.
>>>>>>>>> We could make an extension. It could be an extra message
>>>>>>>>> actually.
>>>>>>>>> On 31 May 2017, at 22:37, Timothy Nodine <>
>>>>>>>>>> wrote:
>>>>>>>>> Should the interface require the underlying class to
be Serializable?
>>>>>>>>> One use case might be to provide serialization to classes
that aren't
>>>>>>>>>> natively serializable.
>>>>>>>>>>> Michael André Pearce wrote:
>>>>>>>>>>> To help discussion,
>>>>>>>>>>>> A very very basic implementation just to
simulate the idea.
>>>>>>>>>> CustomSerialisation
>>>>>>>> <
>>>>>>>>>> CustomSerialisation
>>>>>>>> n.b. doesn’t fully compile is just pseudo impl, nor doesn’t
>>>>>>>>> bits as discussed below like map/change type to a byte
message for
>>>>>>>>>> compatibility, nor media type idea.
>>>>>>>>>> Cheers
>>>>>>>>>>>> Mike
>>>>>>>>>>>> --
>>>>>>>>>>> Clebert Suconic
>>>>>>>>> --
>>>>> Tim Bish
>>>>> twitter: @tabish121
>>>>> blog:
>>> --
>>> Tim Bish
>>> twitter: @tabish121
>>> blog:

Tim Bish
twitter: @tabish121

View raw message