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. anonymous wrote : | 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. anonymous wrote : | - 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. anonymous wrote : | - ROUTE - Routing of a message based on content or location | Yes, we have a CBR service. anonymous wrote : | - 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. anonymous wrote : | 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. anonymous wrote : | | 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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024228#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...