Thursday, May 13, 2004

Persistence in Orchestration 

Just looking at the BizTalk help file (the latest) and was quite interested in how persistence was handled in orchestration in 2004. In 2002 a small change was made (over 2000) to make the persistence of state more efficient by allowing the persistence to be dropped at the start of a transaction. In 2004, it seems the persistence of orchestration state is better thought out with regard to resiliency of an orchestration.

It's one of those things that you know happens, but you're never quite sure exactly in what situations orchestration state is saved to the message box.

Thankfully, the latest BizTalk Server 2004 help addresses this, and can be found here. This is well worth a read if you're like me and want to know a little bit more about what happens under the covers.

# posted by Paul @ 5:27 PM |

About the Author

You may be wondering who I am (or may not!), but I've been in the industry 16+ years working on a variety of systems from IBM mainframes as a CICS systems programmer, to developing on Unix and Windows based systems. At the moment, I'm currently working for a Microsoft Gold Partner in the UK called Solidsoft who specialise in systems integration using BizTalk Server. My position is generally dictated by what I'm doing, but normally as a solutions architect/consultant helping clients with their integration projects involving, yes you guessed it: BizTalk Server.

Disclaimer: all the views expressed here are my own and do not necessarily represent the views of Solidsoft Ltd or indeed any other company.