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
Share this post: Email it! | bookmark it! | digg it! | reddit!