Todd Sussman posted a few comments/requests on my Transactional .NET Adapter. One of the things I was asked for several times already is whether it would be hard to make it work in a request/response way. Now, to be honest, I did consider this when implementing. A few random thoughts:
- Since the adapter is transactional, and since .NET remoting does not support transactions: the code called by the adapter would always run in process in the same appdomain. (I would need to do really funky things to do this otherwise.)
- I would advice against doing too much work in the component called by the adapter; remember there’s a transaction in progress! Ideally the component would access some queue, database or other transactional backend system. Don’t start any actions that take a long time and could risk the transaction to time-out.
- Don’t start any new threads in your component unless you don’t really need the transaction. Any new threads would not retain the transaction context… (Widbey would do a better job here.)
- I decided not to promote request reponse too much since I felt that would raise the risk of blocking the worker thread too long. I was convinced that people needing this functionality would better use another transport to correlate response messages with their request. For example: dropping messages from within your .NET component back on a queue which is asynchronously read by the MQSeries or MSMQ adapter…
Was I wrong? Probably… I’d like to hear all comments you have on this. If you feel you need to have request reponse on the transactional .NET adapter in a scenario, please let me know!
Note to myself: a few other enhancements that I could make:
- load each custom client assembly in a separate appdomain, this would allow for:
- separate security settings for each assembly
- configurable .NET config file for each assembly
- unloading of the appdomain, would prevent needing to restart the BizTalk Service to release an assembly handle
- the request response I just discussed
- provide user with multiple interfaces so they can choose to receive an XmlDocument, XmlReader or just the plain bytestream