Wednesday, June 7, 2006

BizTalk 2006 R2

Esta informação já deve estar por todo o lado na web, mas também a deixo aqui.

Hoje de manhã ouvi um podcast sobre a utilização do WWF com o BizTalk 2006, e referia-se que talvez numa versão R2 do BizTalk podesse substituir-se o Orchestration Designer pelo Workflow Designer do WWF. À tarde, vejo as notícias sobre o lançamento previsto do BizTalk 2006 R2 no primeiro semestre de 2007. O que se prevê de novo, do que se sabe?

- Investimentos na área do RFID (suponho que para processamento de eventos RFID, eliminar duplicações, facilidades de gestão, etc.)
- Adapters WCF (WsHttp, NetTcp, WCF-NetMsmq, WCF-BasicHttp, WCF-NetNamedPipe, WCF-Custom e WCF-CustomIsolated)
- WinFx Adapter Framework (adapters sobre WCF)
- Maior suporte nativo para EDI (por exemplo, suporte EDIINT AS2, e uma maior quantidade de schemas EDIFACT/X12) [isto é uma boa notícia, dado que o suporte actual deixa algo a desejar]
- Interceptores BAM para WWF e WCF, por forma a manter a possibilidade de ter visibilidade ponta-a-ponta sobre os processos de negócio.

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Tuesday, June 6, 2006

BizTalk 2006: Parallel Shape and Threads

Another question I never before had the time to test has to do with the Parallel Shape. The product documentation states that this shape should be used to handle specific message exchange patterns, namely where several messages are expected, but the order is not previously specified (like in a parallel convoy).


It is generally assumed, however, that the execution is multi-threaded. The excellent post by Scott Colestock about "parallel actions, exceptions, and timeouts..." also seems to assume this, while exploring what happens in parallel shapes, when he describes a work-around to the compile-time validation that doesn't allow the use of a .Net object instance in more than one un-synchronized branch of the parallel shape.


To test this situation, I did the most simple test possible: I created a simple 3 branch parallel, with the following contents in each of the branches:


- An expression shape writing "start" followed by the ThreadId (Thread.CurrentThread.ManagedThreadId) to the Debug
- A delay shape
- An expression shape writing "end" followed by the ThreadId to the Debug


What I found out when I tested it, was that all the branches print out the same thread id. Plus, they are executed left to right.


Apparently, there is a scheduler that executes one shape (segment?) at a time, but all in the same thread. It is more or less obvious that BizTalk can't just spawn more threads at will (and there is a BizTalk MaxWorkerThreads registry setting which defaults to 25), and distributing work for the existing threads would probably be too slow.


I did some additional tests, out of curiosity. I created a parallel shape with 6 branches, each containing 3 expression shapes just printing out information do debug, as shown in the following image:


The result was that the branches where fully executed left to right, and the output in the debug out was:


1 - 11 - 21 - 2 - 12 - 22 -3 - 13 - 23 - etc.


Each of the branches ("tasks") seems to be scheduled together.
After this, I added delay shapes to the branches, as follows:


In this case, the scheduler did something different. Apparently, it schedules all the Expressions in a sequence together, but the Delays are placed at the end. This is the (deterministic) output:


1 - 2 - 3 - 4 - 14 - 5 - 15 - 6 - 16 - 11 - 21 - 12 - 22 - 13 - 23 - 24 - 25 - 26


A lot of things could be happening here. Maybe it is related to MessageBox operations, or maybe it's by shape.
I used Lutz' Reflector to take a quick look at BizTalk's DLL's, and found classes named RunSchedule and SegmentScheduler, which seem to handle some of this behaviour, but I don't really think it's a good idea to count on this, as it might change in future versions.


So, takeaways:


- the parallel shape is not multi-threaded, although it looks like it, and should be used only to handle specific messaging patterns;


- the execution order of the branches is done left-to-right. I don't recommend you base your orchestration design on this information, but it might be useful in some scenarios.

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

BizTalk 2006: Call Orquestration Shape e a Message Box

Apesar de ter ideia de que o Call Orchestration, ao contrário do Start Orchestration, não implica uma passagem pela MessageBox, nunca o tinha tirado a limpo. Para o comprovar, criei um cenário simples, com leitura de um XML de uma pasta e activação de uma orquestração que depois faz um call a uma segunda orquestração. Durante o teste, liguei o "good-old" Sql Profiler para ver o que se passava na base de dados (BizTalkMsgBoxDb). Além de inúmeras chamadas a bts_DeQueueMessages*, inerentes ao mecanismo pub/sub, registei as seguintes chamadas:


- bts_InsertProperty: uma chamada para cada promoted property do Xml, contendo o valor de cada property;
- bts_FindSubscriptions: uma chamada, depois de todos os InsertProperty, para verificar as subscrições;
- bts_InsertMessage: duas chamadas, a primeira para inserir atributos, a seguinda para inserir o binário da mensagem recebida.


Todas estas invocações ocorrem aquando da activação da orquestração inicial. Ao fazer o Call Orchestration... não acontece nada, mesmo quando a sub-orchestration recebe parâmetros.


Dúvida esclarecida, portanto: o Call Orchestration não passa pela MessageBox, daí também a sua rapidez.


[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Saturday, June 3, 2006

Concorrência

No curso de BizTalk 2006, um dos módulos que dei foi sobre Tunning e Boas Práticas. Um dos temas abordados foi a questão do tempo de latência, o tempo de resposta a pedidos. Não terá sido intuitivo para todos que para diminuir a latência se deve parametrizar o sistema para funcionar quase como se fosse single-threaded (e, por exemplo, sem fazer processamentos em batch).


Recentemente tivemos um pedido para procurar aumentar o desempenho de uma aplicação pela implementação de mecanismos de paralelismo. A aplicação não é sobre BizTalk, mas em .Net. Esta aplicação faz um processamento sequencial de pedidos recebidos, e um dos passos desse processamento, um pedido a outro sistema, é bastante demorado, sendo este o candidato para a utilização de multi-threading.


Inicialmente, e sem grande experiência em cenários de concorrência, pensei um cenário do tipo ThreadPool, em que 10 threads competiam pelo processamento de um pedido (Competing Consumers), e o despachavam em paralelo para o tal outro sistema. Uma implementação de teste muito simples funcionou perfeitamente, com o benefício adicional de um mecanismo de prioridades, mas que não testei contra o cenário inicial.


Depois, esta semana, tive a sorte de ouvir o ARCast do Ron Jacobs com o Jeffrey Richter, sobre Threading e I/O Assíncrono, e voltei à prancheta para reanalisar o problema. Olhando para trás, percebi que tinha feito com esta aplicação o inverso do que recomendara no caso do BizTalk.


Implementei então o seguinte cenário de testes:


- Uma classe "worker", que faz cálculos matemáticos intensivos, com cada execução a demorar cerca de 3,5 segundos. Só faz I/O para o ecrã, a indicar quando começou e quando terminou a execução, em milisegundos;
- Uma classe Sequence, que invoca 10x a worker;
- Uma classe Threaded, em que crio 10 threads, e as coloco a executar a worker em paralelo. O tempo de criação da thread não é contabilizado;


Os resultados foram os seguintes:


- A versão threaded, no total, demorou menos ~0,5 segundos a executar (apesar do Task Switching -- não consigo explicar este resultado)
- O tempo por execução do worker, na versão Sequence, é obviamente 3,5 segundos;
- O tempo por execução do worker, na versão threaded, disparou para os 22 segundos.


Apesar de estes resultados não serem no cenário real, e terem sido obtidos numa situação só com um CPU (single core), sem acessos a disco/rede/BD, dá para perceber que se as coisas se mantiverem, com o multithreading conseguiria precisamente o inverso do objectivo pretendido: um aumento do tempo de latência. A versão threaded, quanto muito, seria útil em cenários batch.


Resta fazer testes com os sistemas reais, mas se se mantiverem os resultados, ainda há a hipótese do I/O Assíncrono, como se faz com Web Services (BeginInvoke) ou com Sql Server/Ado.Net 2.0.


Por curiosidade, o Jeffrey Richter tem uma coluna ocasional na MSDN Magazine chamada Concurrent Affairs.


[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Friday, June 2, 2006

BizTalk 2006 Best Practices Analyser

Ficou hoje disponível o BizTalk 2006 Best Practices Analyzer, que procura identificar problemas em instalações e configurações do BizTalk 2006. Ainda não tive oportunidade de testar com tempo a aplicação, mas aqui fica o relatório na minha instalação em XP SP2, praticamente limpa actualmente.



Está disponível para download aqui: http://www.microsoft.com/downloads/details.aspx?FamilyId=DDA047E3-408E-48BA-83F9-F397226CD6D4&displaylang=en .


Curioso o facto de a ferramenta fazer um auto-update quando se executa... faz prever evoluções simplificadas no futuro.


 


 


[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]