[Design of JBoss ESB] - Re: The message is important!
by driedtoast
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?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024220#4024220
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024220
17 years, 2 months
[Design of JBoss ESB] - Re: Configuration - normalization
by driedtoast
Not to bring up the whole configuration concepts up again but what about generalizing the providers and listeners?
The reason I say this is that as you start to experiment with different listeners (protocols and transports) the way to configure them should be easy to add. The listeners especially as this could start to become a large set of variations.
For example, currently the configuration is:
| <ftp-provider some-ftp-provider-prop="blah-ftp-prop" ..... >
| <!--
| See how we specify a filter for this FTP bus at the listener level. Look
| for listeners the use the "blah-ftp-bus" jus.
| -->
| <ftp-bus busid="blah-ftp-bus" some-ftp-bus-param="x"/>
| </ftp-provider>
And:
|
| <jms-listener name="Auditing-JMS-Gateway"
| is-gateway="true"
| busidref="y-queue"
| maxThreads="1"/>
Why not just generalize it to be:
| <provider type="ftp" (optionally implementation="com.xyz.MyFTPProvider" )>
| <attribute name="some-ftp-provider" value="22" />
| <bus id="blah-ftp-bus">
| <attribute name="some-ftp-provider" value="22" />
| <message-filter >
| <attribute name="dir" value="Reconcilation" />
| </message-filter>
| </bus>
| </provider>
And:
|
| <listener name="Auditing-FTP-Gateway"
| is-gateway="true"
| busidref="blah-ftp-bus"
| maxThreads="1"/>
Just some thoughts as this would make it consistent across configuring providers and listeners. It also makes the tooling support become easier as you can just have a template of attribtutes for a given provider and listener.
It also cleans up some of the listener/bus code in dealing a little.
Thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024201#4024201
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024201
17 years, 2 months