clebertsuconic
added a comment - 17/May/11 1:23 PM I don't think that would be a good idea.
you still have the body of the message to store anything you like (Object Message, TextMessage.. maybe we could extend other types of messages).
Properties are usually meant for filters and other controls. So this is most likely a won't fix IMO.
Allowing multi-value on properties would only complicate understanding of the spec and I believe should actually simplify it.

fribeiro
added a comment - 17/May/11 1:44 PM I think it would make it easier to transform between technologies that support having multiple values with the same key (e.g HTTP) and JMS, and that is a good thing to have there, don't you agree?

clebertsuconic
added a comment - 17/May/11 2:34 PM I'm not sure about others on the group, but I don't agree.
Message systems are not meant to be cache systems. In my experience using any messaging system as a database will create issues.
Besides you have the message body to store data.
You add something like this, how would you make a filter clause on a message?

I think the use of JMS in ESBs like Progress Sonic ESB is a better use case. JMS is used there to transfer messages across services and, if any of them uses HTTP, you end up with a message that you can't transform to JMS without resorting to Property-1, Property-2, ...

SIP is another big protocol that can't be mapped for that reason, will think of others to mention here.

fribeiro
added a comment - 17/May/11 2:53 PM - edited I think the use of JMS in ESBs like Progress Sonic ESB is a better use case. JMS is used there to transfer messages across services and, if any of them uses HTTP, you end up with a message that you can't transform to JMS without resorting to Property-1, Property-2, ...
SIP is another big protocol that can't be mapped for that reason, will think of others to mention here.

clebertsuconic
added a comment - 17/May/11 3:09 PM You won't be able to use selection clauses if you add something like that.
IMO that's because you're using properties to add plain data.
I will let other to comment on this

I have mixed feelings about this. I don't believe that supporting multi-value properties will exclude the idea of having filters on them, as you should be able to do in/contains checks as well. However, they should still continue to be treated as metadata. One recent case I saw in richfaces included using properties to set sub-topics within the topics, and this would enable setting multiple sub-topics in that case.

John D. Ament
added a comment - 17/May/11 4:17 PM I have mixed feelings about this. I don't believe that supporting multi-value properties will exclude the idea of having filters on them, as you should be able to do in/contains checks as well. However, they should still continue to be treated as metadata. One recent case I saw in richfaces included using properties to set sub-topics within the topics, and this would enable setting multiple sub-topics in that case.

This is a common issue for integration scenarios either with or without an ESB to translate a message from one protocol to another. Were I to solve this problem manually, I would develop some sort of reusable adapter class. This is not a core problem with the JMS spec, therefore, IMO the JMS spec should not be changed. I do, however, see value in providing some convenience classes to ease the task of message conversation. But this is a matter of implementation, not specification.

That being said, the topic of integration is something that is not addressed by Java EE as a whole and I'd like to see that change. There are many other languages and technologies out there that have a need to integrate with Java EE, and messaging is typically a common place people look when such integration needs arise.

bsnyder
added a comment - 18/May/11 3:44 PM - edited This is a common issue for integration scenarios either with or without an ESB to translate a message from one protocol to another. Were I to solve this problem manually, I would develop some sort of reusable adapter class. This is not a core problem with the JMS spec, therefore, IMO the JMS spec should not be changed. I do, however, see value in providing some convenience classes to ease the task of message conversation. But this is a matter of implementation, not specification.
That being said, the topic of integration is something that is not addressed by Java EE as a whole and I'd like to see that change. There are many other languages and technologies out there that have a need to integrate with Java EE, and messaging is typically a common place people look when such integration needs arise.

clebertsuconic
added a comment - 18/May/11 4:03 PM We could create a new message type, and leave properties alone. I'm concerned about moving semantics of the property methods. Currently they mean replace and there are application using that semantic.
If we add a new message type for cases like this, you would have scnearios like this covered.
Some providers have HTTPMessages as a common extension I think. I'm not 100% sure but I think I have seen things like this.

I think it is a specification spec when no adapter class can convert multi-valued properties in other technologies commonly used with JMS in a standard way and resort to things like Property-1, Property-2, etc.., which are hard to use in message selection, for example, as Clebert pointed out.

fribeiro
added a comment - 18/May/11 4:03 PM I think it is a specification spec when no adapter class can convert multi-valued properties in other technologies commonly used with JMS in a standard way and resort to things like Property-1, Property-2, etc.., which are hard to use in message selection, for example, as Clebert pointed out.

fribeiro
added a comment - 18/May/11 4:09 PM I think that adding a new message type or changing the current methods to return the first occurrence wouldn't quite cut it, and this is really a breaking change.
That said, I also think it would fit in a major release that updates a standard after 9 years.

Repeating keys in order to store multiple values is not very elegant, agreed. But maybe you also want to structure your keys, e.g. you want to store the start and end timestamp of two phases A and B. You'd then too have to resort to some naming convention like "A/start", "A/end", "B/start", and "B/end". Maybe you even would then like to filter your messages with a certain timestamp within phase A or phase B. There are lots of things that could be expressed more easily.

If went down that road, maybe we better represented the properties as an xml document. E.g.

This would allow us to have arbitrarily structured properties as well as to validate them against an xml schema. One could think of an XPath mapping to access these parameters with the "old" syntax, so you'd get value-2 with the key "my-property(2)" or the end of phase A with "phase-A/end".

Cool stuff, but I'd personally rather stick to the simple parameters that already exist. I generally find it good enough to put more complex things into the body. The example you describe seem a little bit esoteric in the context we use JMS for. I believe that complex filtering and routing at an ESB level often leads to difficult to maintain system. I prefer a controlling process manager instead. But maybe you can find a real use case that helps to better understand your idea.

rdohna
added a comment - 19/May/11 5:30 AM Repeating keys in order to store multiple values is not very elegant, agreed. But maybe you also want to structure your keys, e.g. you want to store the start and end timestamp of two phases A and B. You'd then too have to resort to some naming convention like "A/start", "A/end", "B/start", and "B/end". Maybe you even would then like to filter your messages with a certain timestamp within phase A or phase B. There are lots of things that could be expressed more easily.
If went down that road, maybe we better represented the properties as an xml document. E.g.
<properties>
<my-property> value-1 </my-property>
<my-property> value-2 </my-property>
<phase-A>
<begin> ... </begin>
<end> ... </end>
</phase-A>
</properties>
This would allow us to have arbitrarily structured properties as well as to validate them against an xml schema. One could think of an XPath mapping to access these parameters with the "old" syntax, so you'd get value-2 with the key "my-property(2)" or the end of phase A with "phase-A/end".
Cool stuff, but I'd personally rather stick to the simple parameters that already exist. I generally find it good enough to put more complex things into the body. The example you describe seem a little bit esoteric in the context we use JMS for. I believe that complex filtering and routing at an ESB level often leads to difficult to maintain system. I prefer a controlling process manager instead. But maybe you can find a real use case that helps to better understand your idea.

This issue really comes from experience in projects where messages previously transported over protocols that support multi-valued properties are sent to JMS endpoints - there is a mismatch there that pushes you to do the wrong thing.

It is usual in the integration space to take that data that doesn't actually belong to the information being transported shouldn't be mixed with it, but rather stored in message properties, which are often carried across several services before they are consumed.

Let me take an example from one of my projects:

1) A client sends an order to an ESB in a SOAP request with a username in a WS-Security header
2) A service extracts the username
3) A service transforms the body of the SOAP request to the format required by a JMS connector to an ERP. The username is transformed to a JMS message property
...

If it wasn't a string, but a list, I would end up resorting to the Property-1, Property-2, etc... idiom or worse.

fribeiro
added a comment - 19/May/11 8:08 AM This issue really comes from experience in projects where messages previously transported over protocols that support multi-valued properties are sent to JMS endpoints - there is a mismatch there that pushes you to do the wrong thing.
It is usual in the integration space to take that data that doesn't actually belong to the information being transported shouldn't be mixed with it, but rather stored in message properties, which are often carried across several services before they are consumed.
Let me take an example from one of my projects:
1) A client sends an order to an ESB in a SOAP request with a username in a WS-Security header
2) A service extracts the username
3) A service transforms the body of the SOAP request to the format required by a JMS connector to an ERP. The username is transformed to a JMS message property
...
If it wasn't a string, but a list, I would end up resorting to the Property-1, Property-2, etc... idiom or worse.

rdohna
added a comment - 19/May/11 9:20 AM Which HTTP header do you want to split into separate values. Typical headers like the Accept headers or cookies could be split, but they are strings, so you could simply leave them in one property.
Only for cookies I can think of a reasonable use case: That you want to route/select all messages with one cookie to one service instance. But wouldn't it be enough to route according to a substring?

fribeiro
added a comment - 19/May/11 9:36 AM - edited It is not only about HTTP, really, only used it as an example, but about any technologies that support multi-valued properties that may need to be transformed to JMS in an integration context.
Anyway, I think message selection is generally superior to substrings, and would like to use it instead.

I agree that using substrings for message selection is inferior to direct matching. But I'm still looking for a use case, where you need a message selector with a "contained in a list" semantics. Even if you are interested only in one of your cookies (or other tokens), wouldn't it be better to store them in dedicated properties like "user-id", "session-id", "country-id", etc.? Then they would be easy to select.

I try to stick to very simple message selectors, e.g. the version of the message format. For more complex things I use dedicated Destinations. If you don't want the sender (or adapter in your case) to know about these Destinations, you'll need something like an ESB with a Content Based Router. I think that this issue requests support for advanced message selection mechanisms. I see those mainly in the context of complex message routing, where simple message selection is not good enough.

That line is definitely difficult to draw, but I would like to have the JMS spec stay clear of that complexity. KISS and contain the complexity to where you can't avoid it.

rdohna
added a comment - 20/May/11 1:43 AM I agree that using substrings for message selection is inferior to direct matching. But I'm still looking for a use case, where you need a message selector with a "contained in a list" semantics. Even if you are interested only in one of your cookies (or other tokens), wouldn't it be better to store them in dedicated properties like "user-id", "session-id", "country-id", etc.? Then they would be easy to select.
I try to stick to very simple message selectors, e.g. the version of the message format. For more complex things I use dedicated Destinations. If you don't want the sender (or adapter in your case) to know about these Destinations, you'll need something like an ESB with a Content Based Router. I think that this issue requests support for advanced message selection mechanisms. I see those mainly in the context of complex message routing, where simple message selection is not good enough.
That line is definitely difficult to draw, but I would like to have the JMS spec stay clear of that complexity. KISS and contain the complexity to where you can't avoid it.

I think the real argument here is that it should be easy to map to/from as many technologies as possible given that JMS has been so widely used in integration solutions in the last years.

HTTP and SIP were the first examples that came to mind, but LDAP also uses multi-valued properties that can't be transformed to/from JMS messages today without the same Property-1, Property-2, etc idiom or something like it. Adding new message types wouldn't quite cut it.

I understand the impact, but don't you think it should fit in this next update?

fribeiro
added a comment - 20/May/11 11:42 AM I think the real argument here is that it should be easy to map to/from as many technologies as possible given that JMS has been so widely used in integration solutions in the last years.
HTTP and SIP were the first examples that came to mind, but LDAP also uses multi-valued properties that can't be transformed to/from JMS messages today without the same Property-1, Property-2, etc idiom or something like it. Adding new message types wouldn't quite cut it.
I understand the impact, but don't you think it should fit in this next update?

If you just want to transport these meta fields, you can wrap them around the body. If you want to use it for message selection, I'd suggest to use something more feature complete for such a job: An ESB.

No, I don't think it should go into the spec... but maybe I just miss a realistic use case.

rdohna
added a comment - 20/May/11 1:26 PM If you just want to transport these meta fields, you can wrap them around the body. If you want to use it for message selection, I'd suggest to use something more feature complete for such a job: An ESB.
No, I don't think it should go into the spec... but maybe I just miss a realistic use case.

I don't really think it is a good practice to store information usually in headers with the content of the body, do you?

I wouldn't mind extracting a few "realistic" use cases from work, glad to help.

Also, let me try to improve the argument first, though: "JMS is commonly used in integration solutions where one or more endpoints based on technologies like HTTP, SIP, LDAP and others can produce messages with multi-valued headers that can't be properly stored in Message objects" – how about that instead?

fribeiro
added a comment - 20/May/11 1:40 PM I don't really think it is a good practice to store information usually in headers with the content of the body, do you?
I wouldn't mind extracting a few "realistic" use cases from work, glad to help.
Also, let me try to improve the argument first, though: "JMS is commonly used in integration solutions where one or more endpoints based on technologies like HTTP, SIP, LDAP and others can produce messages with multi-valued headers that can't be properly stored in Message objects" – how about that instead?

clebertsuconic
added a comment - 20/May/11 1:53 PM Yes..Properties on JMS are meant for Meta-data, and information that is used for routing (filters.. etc). That's been a common sense on the discussions here.
For the real data, you have to place them at the body somehow. MapMessage maybe? (Maybe we could add Array support on MapMessage what would give what you want).

fribeiro
added a comment - 20/May/11 2:02 PM If some protocol takes a multi-valued header as metadata, shouldn't it continue to be taken as so when transformed to JMS? I think so, and that is the support that we are currently missing.

clebertsuconic
added a comment - 20/May/11 2:12 PM just add the data to the body of the message (or to one of the sub-messages that will encapsulate the body into some form of data, like MapMessage, etc).
as I said, using message properties to store data is a common anti-pattern on JMS.

I guess we are saying the very same thing with different words: body is not for metadata, metadata in HTTP, SIP, LDAP transformed to JMS is still metadata, and those protocols support multi-valued properties that JMS doesn't – is the point clear?

fribeiro
added a comment - 20/May/11 2:29 PM I guess we are saying the very same thing with different words: body is not for metadata, metadata in HTTP, SIP, LDAP transformed to JMS is still metadata, and those protocols support multi-valued properties that JMS doesn't – is the point clear?

clebertsuconic
added a comment - 20/May/11 6:59 PM - edited Realistically nobody will change any of the methods on properties. You can't change semantics on the method calls as you have applications out there using the current API.
If you change the proposal to add array properties on MappedMessage you would get some attraction and people talking about it and considering it.
I don't think this would pass a group of people who implement JMS systems otherwise (Expert Group).

I don't think the semantics of HTTP headers and JMS is any different, really, they are both used to carry metadata that doesn't belong in the body of the message.

Anyways, I see your point about how breaking of a change it would be to the API, but think it is a separate issue than opposing to multi-valued properties.

As long as the API goes, I think we could just add get<Type>PropertyValues / set<Type>PropertyValues, just like in the Servlet API. Instead of returning arrays, though, we could use lists, which would probably be used in the Servlet API as well if it was designed today – how about that?

fribeiro
added a comment - 20/May/11 7:18 PM I don't think the semantics of HTTP headers and JMS is any different, really, they are both used to carry metadata that doesn't belong in the body of the message.
Anyways, I see your point about how breaking of a change it would be to the API, but think it is a separate issue than opposing to multi-valued properties.
As long as the API goes, I think we could just add get<Type>PropertyValues / set<Type>PropertyValues, just like in the Servlet API. Instead of returning arrays, though, we could use lists, which would probably be used in the Servlet API as well if it was designed today – how about that?

I'd say that there can be an arbitrary number of nested metadata levels. Take an xml message: It contains an xml header, which itself is metadata, too. So it's normal to nest metadata, isn't it?

I think we should stick to the use cases that arise from the messaging domain itself, i.e. message selectors. If the only use case for multi-value properties is mapping other protocols, then I'd say that's not worth the added complexity.

rdohna
added a comment - 23/May/11 11:03 AM I'd say that there can be an arbitrary number of nested metadata levels. Take an xml message: It contains an xml header, which itself is metadata, too. So it's normal to nest metadata, isn't it?
I think we should stick to the use cases that arise from the messaging domain itself, i.e. message selectors. If the only use case for multi-value properties is mapping other protocols, then I'd say that's not worth the added complexity.

+1
HTTP-protocol interoperability (because of REST and JAX-RS), becomes more and more important. Although the two paradigms (HTTP / REST and JMS) do not follow the same idea, interoperability becomes crucial in the "clouds"

abien
added a comment - 18/Jun/11 12:47 AM +1
HTTP-protocol interoperability (because of REST and JAX-RS), becomes more and more important. Although the two paradigms (HTTP / REST and JMS) do not follow the same idea, interoperability becomes crucial in the "clouds"

(Comment copied from JMS_SPEC-13, which has been closed as a duplicate of this)

As a JMS client I would like to populate a set in the message header and have it take part in selectors. The set would be generic somehow and the filter expressions available would "contains" and "not contains"

I cannot come up with a good looking API change to the Message interface to allow this set to be manipulated cleanly other than getStringHeaderSet, getDoubleHeaderSet etc. There must be a better way, perhaps via a builder pattern.

What I really would find useful is the selector:

"MyProperty contains 'AAA' or MyProperty contains 'BBB'"

Use Case:

Consider a multi national orgianisation with many offices (legal entities) and therefore many back office systems and they are all connected via messaging. A single "deal" can span many offices and many clients. When the deal has been agreed a notification would be sent with a "header set" containing all the offices involved in the deal with each back office subscribing to deals where it is a participant and therefore its identifier is in the header set.

Topics and wild carding do not work in this scenario as the number of participating offices is variable.

Nigel Deakin
added a comment - 07/Mar/12 3:54 PM - edited (Comment copied from JMS_SPEC-13 , which has been closed as a duplicate of this)
As a JMS client I would like to populate a set in the message header and have it take part in selectors. The set would be generic somehow and the filter expressions available would "contains" and "not contains"
I cannot come up with a good looking API change to the Message interface to allow this set to be manipulated cleanly other than getStringHeaderSet, getDoubleHeaderSet etc. There must be a better way, perhaps via a builder pattern.
What I really would find useful is the selector:
"MyProperty contains 'AAA' or MyProperty contains 'BBB'"
Use Case:
Consider a multi national orgianisation with many offices (legal entities) and therefore many back office systems and they are all connected via messaging. A single "deal" can span many offices and many clients. When the deal has been agreed a notification would be sent with a "header set" containing all the offices involved in the deal with each back office subscribing to deals where it is a participant and therefore its identifier is in the header set.
Topics and wild carding do not work in this scenario as the number of participating offices is variable.

@Nigel: In your use-case, you could also use one boolean property for each office or client involved. "la-office" = true, "ny-office" = true, etc. The selector would also be quite simple (e.g., fast). You can always map any multi-value property to a set of single-value properties... but when you have sets, you also may want to have lists... and maps... and lists of sets of maps, etc. If you can't limit this to what's in http headers, you will always have to argue about the next step... I'd leave it out.

rdohna
added a comment - 19/Mar/12 3:17 PM @Nigel: In your use-case, you could also use one boolean property for each office or client involved. "la-office" = true, "ny-office" = true, etc. The selector would also be quite simple (e.g., fast). You can always map any multi-value property to a set of single-value properties... but when you have sets, you also may want to have lists... and maps... and lists of sets of maps, etc. If you can't limit this to what's in http headers, you will always have to argue about the next step... I'd leave it out.