9 Replies Latest reply on Mar 1, 2007 7:31 AM by Mark Little

    The message is important!

    Mark Little Master

      At the core of JBossESB is a MOM, but this MOM must itself be abstract, in that it will not force us into just JMS or SOAP styles. For example, a pure-play Web Services deployment within the ESB must be supported and, in which case, if reliability is a requirement as well then something like WS-RX (Web Services Reliable Exchange) will be needed from the underlying MOM abstraction . As such, the ESB will assume a single MOM abstraction, but the capabilities may be provided by multiple different implementations. This is further support for the notion of having multiple buses within the ESB (each bus may be controlled by a separate MOM implementation).

      Note, I use the term MOM here simply as a TLA (three-letter acronym), to save time. MOMs typically provide more than we require: which is message driven interactions.

        • 1. Re: The message is important!
          Adrian Brock Master

          When you say MOM are you implying a broker?

          Or do you envisage something more distributed/reliable.
          e.g. replicated dns and ip (DNS isn't reliable because it is slow to update)
          e.g.2. a generic discovery service + "rpc" call

          • 2. Re: The message is important!
            Mark Little Master

            As it said in the note, I'm using the term MOM as a convenient shorthand. However, in longhand notation, I'm talking aboutt a component that is purely responsible for sending and receiving messages. How that is implemented, whether it is by JMS, SOAP-over-HTTP, REST, RMI, IIOP, or something else, should be immaterial to the requirements of the model and architecture.

            I actually don't much like the term MOM, because, like ESB, it's heavily overloaded. "Messaging infrastructure" is a fair term, but takes more key strokes (but much less than having to explain the caveats associated with using MOM).

            In terms of brokers and mediation, I intend to add a separate discussion topic .

            • 3. Re: The message is important!
              Scott Stark Master

              Somewhat related to the "SOA internally as well as externally" thread, is exactly how close to the object are messages going to go? If we allow call by reference between pojos as a form of message passing, we need very tight control of the type system which will tend toward having an all jboss core.

              If a defining characteristic of the ESB/MOM architecture is messages flow between type systems, that is a different kernel than the jboss pojo micrcontainer. This still does not preclude every service domain using the jboss microcontainer at its core.

              Given the complete lack of definition around ESB/SOA, one thing I would like to quickly define is what exactly we mean in terms of an API by our ESB core.

              • 4. Re: The message is important!
                Mark Little Master

                Tight control between objects? SOA? Doesn't go together: loose coupling is the intention of the ESB/SOA - if you want tight coupling, then you'd use CORBA or RMI.

                There's also not a complete lack of definition around SOA: it's quite well defined. However, if you mean in the context of what we should accomplish in JBossESB, then hold on little longer. Such a document exists and I'm in the process of uploading it to the new JBossESB Labs page. Hopefully tomorrow if I get a chance.

                • 5. Re: The message is important!
                  Scott Stark Master

                  Yes, I'm looking for the distiguishing feature set between JBossESB and JBossAS.

                  • 6. Re: The message is important!
                    Ronald van Kuijk Master

                    I spoke with a license-fee-required company that has a workflow system (human interaction) and a kind of 'business works system' (kind of esb) and according to them, their 'esb' is the next generation AS... mainly because they do not have a 'real' AS like (other?) major commercial companies (JBoss, Oracle, IBM, Bea, even SAP), so I see a nice marketing battle comming up.

                    • 7. Re: The message is important!
                      Daniel Marchant Newbie

                      I do like the concept of breaking out the translation of the model from the model. In this approach you can start to imagine the bus taking on a whole service approach internally.

                      For example,


                      Utility Services:

                      - TRANSPORT - protocol that is used to connect to services
                      - JMS
                      - SMTP
                      - TCP/IP
                      - HTTP
                      - JNDI/Local invocations

                      - FORMAT - format of the resulting or incoming information to the bus
                      - XML
                      - JSON
                      - SOAP
                      - etc...

                      - ROUTE - Routing of a message based on content or location

                      - CACHE - responds to messages that are flagged cacheable?

                      Auditing and Monitoring Services:

                      - NOTIFY - Notifications of the messages within the system

                      - AUDITING - Storing the message
                      - DB
                      - LOG
                      - Etc..


                      Business Services:

                      - Actions - Services that are put into the bus for business logic


                      The whole thing could be tied together with a BPM strategy.
                      For example,

                      Transport -> Starts process XYZ
                      Process starts to run
                      XYZ -> FORMAT/TRANFORMATION to MODEL
                      XYZ -> ROUTE
                      XYZ -> CACHE
                      NO CACHE: XYZ -> ACTION XYZ
                      XYZ -> FORMAT
                      XYZ -> TRANSPORT


                      Or alternatively

                      TRANSPORT - > XYZ
                      XYZ -> FORMAT/TRANFORMATION to MODEL
                      XYZ -> ROUTE
                      XYZ -> FORMAT
                      XYZ -> TRANSPORT (External service)
                      XYZ -> AUDIT
                      XYZ -> FORMAT
                      XYZ -> TRANSPORT


                      The idea would be that when a message comes in, the process starts based on the message/service. The service really being a process.

                      Thoughts?

                      • 8. Re: The message is important!
                        Daniel Marchant Newbie

                        Also in reference to a broker approach.
                        I think the concept should be that a bus instance could connect to an existing bus. This allows for the main bus to understand what buses are available without having to know about them originally.

                        It also allows for scaling as you can throw up a bus pointed to the main bus in minutes and the main bus routes work to the other buses based on what they can handle.

                        • 9. Re: The message is important!
                          Mark Little Master

                          Wow, this topic hasn't been active for over a year ;-)

                          "driedtoast" wrote:
                          I do like the concept of breaking out the translation of the model from the model. In this approach you can start to imagine the bus taking on a whole service approach internally.


                          Yes, we've been saying from the start that we want to use SOA internally as well as externally to the ESB.


                          For example,


                          Utility Services:

                          - TRANSPORT - protocol that is used to connect to services
                          - JMS
                          - SMTP
                          - TCP/IP
                          - HTTP
                          - JNDI/Local invocations


                          If you take a look at the original architectural requirements I think you'll see this concept in the dispatchers, which are services to all intents and purposes. They receive messages and then do something with them. That "something" may be to augment the message (e.g., add a security context), or it may be to send them to a transport level service for transmission between endpoints.


                          - FORMAT - format of the resulting or incoming information to the bus
                          - XML
                          - JSON
                          - SOAP
                          - etc...


                          Within the bus we have a normalized message format (actually we support a range and provide implementations of a couple). Other formats make sense when going outside of the ESB, or coming into the ESB, to/from ESB-unaware components. We call the facilitators of those kinds of interactions Gateways.


                          - ROUTE - Routing of a message based on content or location


                          Yes, we have a CBR service.


                          - CACHE - responds to messages that are flagged cacheable?


                          Yes, you could have a cache service through which all interactions for certain endpoints go, exactly like HTTP caches. You could even tie this into CBR.


                          Auditing and Monitoring Services:

                          - NOTIFY - Notifications of the messages within the system

                          - AUDITING - Storing the message
                          - DB
                          - LOG
                          - Etc..


                          Business Services:

                          - Actions - Services that are put into the bus for business logic


                          The whole thing could be tied together with a BPM strategy.
                          For example,

                          Transport -> Starts process XYZ
                          Process starts to run
                          XYZ -> FORMAT/TRANFORMATION to MODEL
                          XYZ -> ROUTE
                          XYZ -> CACHE
                          NO CACHE: XYZ -> ACTION XYZ
                          XYZ -> FORMAT
                          XYZ -> TRANSPORT


                          Or alternatively

                          TRANSPORT - > XYZ
                          XYZ -> FORMAT/TRANFORMATION to MODEL
                          XYZ -> ROUTE
                          XYZ -> FORMAT
                          XYZ -> TRANSPORT (External service)
                          XYZ -> AUDIT
                          XYZ -> FORMAT
                          XYZ -> TRANSPORT


                          And that's precisely what we're aiming for. We're looking at closer integration with the likes of jBPM or BPEL to drive this kind of flow.



                          The idea would be that when a message comes in, the process starts based on the message/service. The service really being a process.

                          Thoughts?