activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tabish...@gmail.com>
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
divergence.
>
> 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: http://camel.apache.org/sjms.html
Camel does AVRO: http://camel.apache.org/avro.html


>
> Sent from my iPhone
>
>> On 1 Jun 2017, at 15:18, Martyn Taylor <mtaylor@redhat.com> wrote:
>>
>>> On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish <tabish121@gmail.com> wrote:
>>>
>>>> On 06/01/2017 09:34 AM, Martyn Taylor wrote:
>>>>
>>>> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish <tabish121@gmail.com>
wrote:
>>>>
>>>> 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
of
>>>>>> code
>>>>>> and into configuration.
>>>>>>
>>>>>> Providing I've understood this properly, it seems like a good idea
to
>>>>>> 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: http://camel.apache.org/data-format.html and
>>> the transports http://camel.apache.org/transport.html
>>
>>> 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 <
>>>>>> michael.andre.pearce@me.com> 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
well
>>>>>>> in
>>>>>>> other languages like c++, which won't read a java serialised
object,
>>>>>>> and
>>>>>>> say for XML you generate objects via an XSD which by default
aren't
>>>>>>> serialisable, so you cannot simply add Serializable to the object,
as
>>>>>>> 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
or
>>>>>>> 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 <
>>>>>>> michael.andre.pearce@me.com> 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
factory
>>>>>>> the
>>>>>>> rest you code to Jms.
>>>>>>>
>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 1 Jun 2017, at 04:10, Clebert Suconic <clebert.suconic@gmail.com>
>>>>>>>> wrote:
>>>>>>>> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce <
>>>>>>>>
>>>>>>>>> michael.andre.pearce@me.com> wrote:
>>>>>>>>>
>>>>>>>>> Jms api dictates class set in object message to be serializable.
>>>>>>>>> We could make an extension. It could be an extra message
this
>>>>>>>>> actually.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 31 May 2017, at 22:37, Timothy Nodine <timgnodine@gmail.com>
>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/michaelandrepearce/activemq-artemis/tree/
>>>>>>>>>> CustomSerialisation
>>>>>>>> <
>>>>>>>>
>>>>>>>>> https://github.com/michaelandrepearce/activemq-artemis/tree/
>>>>>>>>>> CustomSerialisation
>>>>>>>> n.b. doesn’t fully compile is just pseudo impl, nor doesn’t
include
>>>>>>>>
>>>>>>>>> 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: http://timbish.blogspot.com/
>>>>>
>>>>>
>>>>>
>>> --
>>> Tim Bish
>>> twitter: @tabish121
>>> blog: http://timbish.blogspot.com/
>>>
>>>

-- 
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


Mime
View raw message