-
1. Re: The message is important!
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!
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!
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!
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!
Yes, I'm looking for the distiguishing feature set between JBossESB and JBossAS.
-
6. Re: The message is important!
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!
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!
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!
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?