You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by jhakim <ja...@codestreet.com> on 2006/06/14 22:35:12 UTC
Nested MapMessage
I am curious about ActiveMQ extensions (if any) to the JMS MapMessage
specification. In particular, I would be very interested in knowing whether
or not nested MapMessge payloads are permitted. In other words, is it
possible for a MapMessage to contain another MapMessage as one of its
fields.
--
View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4872274
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by jhakim <ja...@codestreet.com>.
Unfortunately, ObjectMessage does not work across heterogenous environments
- I see lots of systems being built nowdays with C# clients and Java
servers.
--
View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4903443
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by Hiram Chirino <hi...@hiramchirino.com>.
You can get them from:
http://people.apache.org/maven-snapshot-repository/org/apache/activemq/apache-activemq/4.1-incubator-SNAPSHOT/
On 8/2/06, jhakim <ja...@codestreet.com> wrote:
>
> Thanks for adding this feature. I am sure it is going to be heavily used. BTW
> - can you point me to where I can I download ActiveMQ 4.1?
> --
> View this message in context: http://www.nabble.com/Nested-MapMessage-tf1788442.html#a5617829
> Sent from the ActiveMQ - Dev forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Nested MapMessage
Posted by jhakim <ja...@codestreet.com>.
Thanks for adding this feature. I am sure it is going to be heavily used. BTW
- can you point me to where I can I download ActiveMQ 4.1?
--
View this message in context: http://www.nabble.com/Nested-MapMessage-tf1788442.html#a5617829
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by James Strachan <ja...@gmail.com>.
I've implemented support for nested MapMessage; so that they can
contain entires containing arbitrarily deep Map and List objects. This
patch also allows nested Map and List objects on JMS Message
properties as well.
More details of this new feature here...
http://activemq.org/site/structured-message-properties-and-mapmessages.html
On 6/16/06, James Strachan <ja...@gmail.com> wrote:
> On 6/16/06, jhakim <ja...@codestreet.com> wrote:
> >
> > Clearly both setObject(name, map) and setObject(name, mapMsg) work. As you
> > correctly point out, using a hierarchical naming scheme would allow the
> > client to specify nesting and works with any MOM.
> >
> > However, I would argue that forcing clients to write code to create/parse a
> > hierarchical naming scheme defeats the key goal of ease of use.
> >
> > For instance, suppose one wants to create a framework for marshaling
> > arbitrary beans to JMS messages. A logical implmentation would be to use
> > reflection to discover bean properties and create a corresponding
> > MapMessage. Now, suppose that a bean contains other beans as properties. One
> > elegant approach would to marshal each bean property to a nested
> > MapMessage. This exact strategy is used by many systems on Wall Street and
> > by open-source projects (messageforge.sourceforge.net).
> >
> > BTW - the underlying JMS provider can, beneath the covers, use hierarchical
> > naming schemes and strip off properties from nested messages. As far as the
> > client is concerned, this should just be an implementation detail and not
> > the required way for clients to use the MOM.
>
> Agreed. Obviously if you have a nested array of beans you can
> obviously use ObjectMessage too - but I totally understand the
> motivation for having a typesafe hierarchial MapMessage that other
> languages can parse too.
>
> I've created an issue to track this feature request
> http://issues.apache.org/activemq/browse/AMQ-757
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Nested MapMessage
Posted by James Strachan <ja...@gmail.com>.
On 6/16/06, jhakim <ja...@codestreet.com> wrote:
>
> Clearly both setObject(name, map) and setObject(name, mapMsg) work. As you
> correctly point out, using a hierarchical naming scheme would allow the
> client to specify nesting and works with any MOM.
>
> However, I would argue that forcing clients to write code to create/parse a
> hierarchical naming scheme defeats the key goal of ease of use.
>
> For instance, suppose one wants to create a framework for marshaling
> arbitrary beans to JMS messages. A logical implmentation would be to use
> reflection to discover bean properties and create a corresponding
> MapMessage. Now, suppose that a bean contains other beans as properties. One
> elegant approach would to marshal each bean property to a nested
> MapMessage. This exact strategy is used by many systems on Wall Street and
> by open-source projects (messageforge.sourceforge.net).
>
> BTW - the underlying JMS provider can, beneath the covers, use hierarchical
> naming schemes and strip off properties from nested messages. As far as the
> client is concerned, this should just be an implementation detail and not
> the required way for clients to use the MOM.
Agreed. Obviously if you have a nested array of beans you can
obviously use ObjectMessage too - but I totally understand the
motivation for having a typesafe hierarchial MapMessage that other
languages can parse too.
I've created an issue to track this feature request
http://issues.apache.org/activemq/browse/AMQ-757
--
James
-------
http://radio.weblogs.com/0112098/
Re: Nested MapMessage
Posted by jhakim <ja...@codestreet.com>.
Clearly both setObject(name, map) and setObject(name, mapMsg) work. As you
correctly point out, using a hierarchical naming scheme would allow the
client to specify nesting and works with any MOM.
However, I would argue that forcing clients to write code to create/parse a
hierarchical naming scheme defeats the key goal of ease of use.
For instance, suppose one wants to create a framework for marshaling
arbitrary beans to JMS messages. A logical implmentation would be to use
reflection to discover bean properties and create a corresponding
MapMessage. Now, suppose that a bean contains other beans as properties. One
elegant approach would to marshal each bean property to a nested
MapMessage. This exact strategy is used by many systems on Wall Street and
by open-source projects (messageforge.sourceforge.net).
BTW - the underlying JMS provider can, beneath the covers, use hierarchical
naming schemes and strip off properties from nested messages. As far as the
client is concerned, this should just be an implementation detail and not
the required way for clients to use the MOM.
--
View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4902932
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by James Strachan <ja...@gmail.com>.
BTW lots of MOMs in the past have made the appearence of nested
MapMessage instances by just using nested key names.
e.g.
map.setObject("bond.deliverySchedules.123.payment", value);
The advantage of this approach is it'd work with any JMS provider.
But I'm sure we could add an extension that allows nesting of Maps
etc. (BTW nesting of Maps is much easier than nesting of MapMessage as
a MapMessage has a ton of headers to deal with so its really a
doubly-nested Map of Maps)
On 6/15/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On 6/15/06, jhakim <ja...@codestreet.com> wrote:
> >
> > There are a lot of real-world applications that need the ability to send
> > structured data via JMS.
> >
> > For example, take an application that wants to publish a portfolio of bonds
> > (or stocks - take your pick). The logical way to do it would be to have a
> > portfolio container message with zero or more (nested) bond messages. The
> > alternative, breaking a portfolio into a series of bond messages, is VERY
> > cumbersome and requires that the consumer reconstruct the portfolio.
> >
> > This is but one instance of a real-world need to publish arbitrary message
> > structures. Nested MapMessage addresses this need directly and elegantly.
>
> Yes.. but nested Maps also addresses the same issue it seem to me.
> What does nesting MapMessages buy you that nested Maps do not?
>
> >
> >
> > --
> > View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877171
> > Sent from the ActiveMQ - Dev forum at Nabble.com.
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Nested MapMessage
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 6/15/06, jhakim <ja...@codestreet.com> wrote:
>
> There are a lot of real-world applications that need the ability to send
> structured data via JMS.
>
> For example, take an application that wants to publish a portfolio of bonds
> (or stocks - take your pick). The logical way to do it would be to have a
> portfolio container message with zero or more (nested) bond messages. The
> alternative, breaking a portfolio into a series of bond messages, is VERY
> cumbersome and requires that the consumer reconstruct the portfolio.
>
> This is but one instance of a real-world need to publish arbitrary message
> structures. Nested MapMessage addresses this need directly and elegantly.
Yes.. but nested Maps also addresses the same issue it seem to me.
What does nesting MapMessages buy you that nested Maps do not?
>
>
> --
> View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877171
> Sent from the ActiveMQ - Dev forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Nested MapMessage
Posted by jhakim <ja...@codestreet.com>.
There are a lot of real-world applications that need the ability to send
structured data via JMS.
For example, take an application that wants to publish a portfolio of bonds
(or stocks - take your pick). The logical way to do it would be to have a
portfolio container message with zero or more (nested) bond messages. The
alternative, breaking a portfolio into a series of bond messages, is VERY
cumbersome and requires that the consumer reconstruct the portfolio.
This is but one instance of a real-world need to publish arbitrary message
structures. Nested MapMessage addresses this need directly and elegantly.
--
View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877171
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by Hiram Chirino <hi...@hiramchirino.com>.
So is this just to be compatible with EMS or is there another handy
reason that being able to embedd a map message is needed?
On 6/15/06, jhakim <ja...@codestreet.com> wrote:
>
> One could allow Map or MapMessage or both as the second argument. The real
> issue is that nested MapMessage should be allowed. I have no quibble with a
> JMS provider allowing a Map as the second argument - as long as MapMessage
> entries were accepted.
> --
> View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877006
> Sent from the ActiveMQ - Dev forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Nested MapMessage
Posted by jhakim <ja...@codestreet.com>.
One could allow Map or MapMessage or both as the second argument. The real
issue is that nested MapMessage should be allowed. I have no quibble with a
JMS provider allowing a Map as the second argument - as long as MapMessage
entries were accepted.
--
View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4877006
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hum. Wouldn't it be just as useful if a Map as used as the 2nd
argument instead of a MapMessage? I'm just thinking that MapMessage
has alot more overhead than a simple MAP.
On 6/14/06, jhakim <ja...@codestreet.com> wrote:
>
> The JMS MapMessage API already contains the method setObject(name, val). For
> nested MapMessage, the second argument - val - would simply be a MapMessage.
> No need to clutter the API with yet another method. By the way, this is just
> what TIBCO EMS provides.
> --
> View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4875002
> Sent from the ActiveMQ - Dev forum at Nabble.com.
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Nested MapMessage
Posted by jhakim <ja...@codestreet.com>.
The JMS MapMessage API already contains the method setObject(name, val). For
nested MapMessage, the second argument - val - would simply be a MapMessage.
No need to clutter the API with yet another method. By the way, this is just
what TIBCO EMS provides.
--
View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4875002
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Could you provide a few sniplets of code for how you think API should look?
On 6/14/06, jhakim <ja...@codestreet.com> wrote:
>
> Yes.
>
> MapMessage has the same power and flexibility as XML (the universal
> self-describing data structure) as long as arbitrary nesting is allowed.
> Take away nesting and MapMessage becomes a very simplistic structure that
> cannot easily handle real-world application needs.
>
> In recognition of this fact, many vendors allow nesting of MapMessage - e.g.
> TIBCO EMS. Some vendors, such as SonicMQ provide proprietary APIs when it
> comes to nesting. This, in my opinion, is a very poor design strategy
> because it binds clients too closely with the vendor API.
> --
> View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4873966
> Sent from the ActiveMQ - Dev forum at Nabble.com.
>
>
--
Regards,
Hiram
Re: Nested MapMessage
Posted by jhakim <ja...@codestreet.com>.
Yes.
MapMessage has the same power and flexibility as XML (the universal
self-describing data structure) as long as arbitrary nesting is allowed.
Take away nesting and MapMessage becomes a very simplistic structure that
cannot easily handle real-world application needs.
In recognition of this fact, many vendors allow nesting of MapMessage - e.g.
TIBCO EMS. Some vendors, such as SonicMQ provide proprietary APIs when it
comes to nesting. This, in my opinion, is a very poor design strategy
because it binds clients too closely with the vendor API.
--
View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4873966
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Nested MapMessage
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Jhakim,
That's an interesting request. Would allowing nested maps be enough for you?
Regards,
Hiram
On 6/14/06, jhakim <ja...@codestreet.com> wrote:
>
> I am curious about ActiveMQ extensions (if any) to the JMS MapMessage
> specification. In particular, I would be very interested in knowing whether
> or not nested MapMessge payloads are permitted. In other words, is it
> possible for a MapMessage to contain another MapMessage as one of its
> fields.
> --
> View this message in context: http://www.nabble.com/Nested-MapMessage-t1788442.html#a4872274
> Sent from the ActiveMQ - Dev forum at Nabble.com.
>
>
--
Regards,
Hiram