5 Replies Latest reply on Aug 3, 2007 8:20 AM by marklittle

    MessageType design

    kurtstam

      It looks like we copied the JMS message types of: BytesMessage, MapMessage, ObjectMessage, StreamMessage and TextMessage


      I see the following issues with the current implementation:

      1. There are no interfaces for them in our implementation, so our Message
      will not actually 'be' one of these types. You'll have to do Message.getPayload() and then figure out what type this it by using getInstanceOf().

      2. We have left the old body implementation, so we have a body and a payload-body as I understand it. This is confusing. I mean I can still do msg.getBody.add("kurt", "Stam") and ignore the new payload stuff.

      3. CommandMessage is listed at the same level as BytesMessage, but I think a CommandMessage is more at the ESB logical level. It has nothing to do with the implementation of the message. Maybe we can simple add
      a Message.property of MESSAGE_TYPE for this? No need to have a different API for this type of message.

      Maybe I'm missing something.

      --Kurt

        • 1. Re: MessageType design
          tcunning

          I think I agree with Kurt on CommandMessage - I'm not sure it really has to be a special type of ObjectMessage.

          For the stats gathering, I think we were planning on excluding all CommandMessages from the counts - basically because there's the potential for them to skew the statistics a great deal.

          We're going to have to check each Message to see if it is a CommandMessage, so whatever allows you to determine that should be pretty lightweight, especially if there are a lot of Messages being processed by the ESB. Is isCommandMessage going to be fast enough?

          • 2. Re: MessageType design
            marklittle

             

            "kurt.stam@jboss.com" wrote:
            It looks like we copied the JMS message types of: BytesMessage, MapMessage, ObjectMessage, StreamMessage and TextMessage


            Not quite. There's no StreamMessage.


            I see the following issues with the current implementation:

            1. There are no interfaces for them in our implementation, so our Message
            will not actually 'be' one of these types. You'll have to do Message.getPayload() and then figure out what type this it by using getInstanceOf().


            There's no such operation Message.getPayload. You mean Payload.getPayload, I think.

            But yes, that's essentially correct. Without changing interfaces to existing infrastructure (and potentially breaking existing deployments), these simply represent different views on to the underlying Message Body contents.


            2. We have left the old body implementation, so we have a body and a payload-body as I understand it. This is confusing. I mean I can still do msg.getBody.add("kurt", "Stam") and ignore the new payload stuff.


            We cannot remove Body because it is the underlying Message structure that supports more than any of these views allow. It's more powerful. These are simplifications for users who know they only want to send text, Serialized objects etc.


            3. CommandMessage is listed at the same level as BytesMessage, but I think a CommandMessage is more at the ESB logical level. It has nothing to do with the implementation of the message. Maybe we can simple add
            a Message.property of MESSAGE_TYPE for this? No need to have a different API for this type of message.


            Possibly. It's just another simplification view. At present it supports type (what type of CommandMessage) and a serialized object. Since we don't have any of these CommandMessage implementations yet, it's hard to argue for or against.

            • 3. Re: MessageType design
              marklittle

               

              "tcunning" wrote:
              I think I agree with Kurt on CommandMessage - I'm not sure it really has to be a special type of ObjectMessage.


              Maybe. It seemed to fit the simplification/view approach.


              For the stats gathering, I think we were planning on excluding all CommandMessages from the counts - basically because there's the potential for them to skew the statistics a great deal.

              We're going to have to check each Message to see if it is a CommandMessage, so whatever allows you to determine that should be pretty lightweight, especially if there are a lot of Messages being processed by the ESB. Is isCommandMessage going to be fast enough?


              It should be fast enough. All it's doing is looking at the presence (or absence) of the command name in the Body.

              • 4. Re: MessageType design
                marklittle

                 

                "kurt.stam@jboss.com" wrote:
                1. There are no interfaces for them in our implementation, so our Message
                will not actually 'be' one of these types. You'll have to do Message.getPayload() and then figure out what type this it by using getInstanceOf().


                BTW, just in case you figured I hadn't thought about the "issue", check this out. What we have now is much less invasive and won't break existing deployments and users. That's why 742 is scheduled for the next major revision.

                • 5. Re: MessageType design
                  marklittle

                  Having spoken with Kurt, I'm going to see if there is a way to make this look easier in the current release.