On 8/10/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
If we make no assumptions on the commonality or evolution of interfaces between process versions, then routing should follow the same rules as for routing between different processes. Different process versions would be treated as different processes. Wouldn't we save ourselves some complexity by doing so?
I like the idea that if I deploy a process, change it, deploy it again, the engine is smart enough to automatically retire the old version, yet keep the old definition accessible as long as instances exist, and as audit trail. I could then look back at the history, roll back changes, etc. A good deployment system for long running Java objects, wikis, versioned control file systems and databases all work the same way. New version replaces old one, old references point to old version. There's great convenience in this feature, and great convenience in the consistency. Anything different requires extraordinary justification which I'm not seeing, otherwise it's complex by virtue of surprise. Assaf alex
Maciej Szefler wrote: > The restrictions I proposed are not intended to be a help to the user. > They are intended to ensure that a reasonable implementation is > possible. Requirements 2 and 3 are there because you should know what > the message type of the received message is before you do the version > routing: your communication channel is likely going to be hard-coded to > the same binding for all versions (i.e. you are listening on the same > URL for all versions), and you need to apply correlation logic before > you know what version the message is targeting). So it makes sense that > all version would need to have the same message format. > -mbs >
-- CTO, Intalio http://www.intalio.com
