Num projecto em que estou envolvido, existe uma camada de objectos que faz validações de segurança aplicacionais com base num contexto de segurança específico aquando da invocação. Foram definidos assim uma subclasse de GenericIdentity, MyIdentity; e um Principal a acompanhar, MyPrincipal (subclasse de GenericPrincipal). MyIdentity encapsula um conjunto de atributos extra sobre o utilizador actual. A segunda classe, MyPrincipal, limita-se a fornecer um interface strongly-typed sobre a primeira. Ambas as classes estão marcadas como serializáveis.
Já no BizTalk, as orquestrações iniciam-se criando uma instância de MyIdentity, que é preenchida com os tais atributos extra, e de seguida afecta-se a Thread corrente com um MyPrincipal criado com a identidade. Qualquer coisa como:
myIdentity = new MyIdentityNamespace.MyIdentity(“jota”, “administrator”);
System.Threading.Thread.CurrentPrincipal = new MyIdentityNamespace.MyPrincipal (myIdentity);
Independentemente dos méritos da abordagem, levantou-se logo a questão: o BizTalk persiste esta informação quando se dá, por exemplo, uma desidratação numa orquestração?
A documentação do produto diz o seguinte sobre persistência:
The orchestration engine saves to persistent storage the entire state of a running orchestration instance at various points, so that the instance can later be completely restored in memory. The state includes:
- The internal state of the engine, including its current progress.
- The state of any .NET components that maintain state information and are being used by the orchestration.
- Message and variable values.
A resposta, apesar do que possa eventualmente dar a entender o texto acima, é: não. Fiz uma pequena orquestração para testar esta situação, causando uma desidratação, e se até ela acontecer o MyPrincipal criado parecia estar na CurrentThread, tal como afectado, depois da desidratação já não estava lá. Coisas da vida. 🙂
jota
