Saturday, March 11, 2006

BizTalk 2006 Release To Manufacturing (RTM)

Diz-se por aí que a versão RTM do BizTalk 2006 vai sair no dia 23 de Março... que tal um evento BizTalk Days '2006, ou Integration Days 2006? :-)
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Ambiente de desenvolvimento para BizTalk

á me perguntaram várias vezes sobre o ambiente de desenvolvimento necessário para BizTalk. O modelo é exactamente o mesmo que o usado para o ASP.NET, por exemplo: o desenvolvimento é efectuado localmente no PC de cada elemento da equipa, que deverá ter instalados todos os requisitos do produto:
- BizTalk Server 2004 SP1
- Visual Studio 2003 SP1
- Sql Server 2000 SP4
- Sql Server 2000 Analysis Services SP4
- Windows 2003 Server ou Windows XP SP2 (neste último caso, sem funcionalidades BAM).

Caso já se esteja a utilizar o BizTalk 2006, o ambiente deverá ser:
- BizTalk Server 2006
- Visual Studio 2005
- Sql Server 2000 SP4 ou Sql Server 2005
- Sql Server 2000 Analysis Services SP4 ou Sql Server 2005 Analysis Services
- Windows 2003 Server ou Windows XP SP2 (neste caso, sem funcionalidades BAM).

Eventualmente, se pretendido, pode utilizar-se um único Sql Server partilhado entre todas as instalações, mas nesse caso recomendo que se criem conjuntos de bases de dados distintas para cada posto de trabalho (o BizTalk cria várias bases de dados), o que se faz durante o processo de configuração do produto. Ex: "PC1BizTalkMsgBoxDb", "PC2BizTalkMsgBoxDb", etc.

Uma prática muito frequente, e que simplifica o trabalho, consiste em desenvolver integralmente usando máquinas virtuais, mas com atenção caso se queiram colocar várias destas ligadas à rede, uma vez que mudar o nome de uma VM já instalada com BizTalk (por forma a evitar conflitos na rede) é tarefa muito complicada, que não recomendo.

Aqui está a página Microsoft com os requisitos (a indicação de 1Gb mínimo de RAM é para levar muito a sério).

Mais uma vez tal como sucede com o Asp.Net, os projectos BizTalk podem/devem estar no Visual Source Safe.

Em relação ao motor de regras no BizTalk, tanto na versão 2004 como na 2006 ele pode ser usado em .Net, isto é, sem ter de ser necessariamente invocado de dentro de uma orquestração. No entanto, se na versão 2004 o BizTalk tem de ser instalado integralmente, na 2006 o motor de regras pode ser instalado individualmente (nota: não tive oportunidade de confirmar isto). Note-se que o motor de regras não é licenciado em separado, no entanto.

Falando de licenciamento, já está disponível alguma informação sobre o 2006 (bem como o 2004, claro). A comparação é simples: a versão 2006 aumentou um pouco de preço, mas inclui agora um largo conjunto de adaptadores que antes se teriam de adquirir em separado, mas a versão developer baixou de preço, e a partner edition deixou de existir.


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

Friday, March 10, 2006

BizTalk 2004/2006 - Policies e vocabulários

No motor de regras do BizTalk, tanto as Policies/Rulesets como os Vocabulários deixam de se poder alterar a partir do momento que são publicadas. Qualquer correcção pretendida deve ser feita pela criação de uma nova versão. Por vezes, especialmente em desenvolvimento, é conveniente conseguir contornar este comportamento, até para que não se passe para produção uma versão 1.123 que teve N iterações em desenvolvimento.

Uma forma rápida de o fazer  é aceder directamente à BD de regras (geralmente chamada BizTalkRuleEngineDb), e alterar nas tabelas os valores que controlam o estado de policies/vocabulários:
- para policies: abrir a tabela re_ruleset, localizar a policy que queremos "undeployar", e modificar o valor na coluna nStatus de 1 para 0;
- para vocabulários: abrir a tabela re_vocabulary, localizar o vocabulário, e modificar o valor na coluna nStatus de 1 para 0;

Depois de se fazerem as modificações, pode ou fazer-se um novo deploy, no Business Rule Composer, ou simplesmente voltar a modificar o nStatus para o valor 1. Caso o tracking esteja ligado para uma policy que tenhamos alterado, esta é aliás a única alternativa, porque dá um erro ao fazer deploy.

A terminar, note-se que esta solução não é recomendada, de forma alguma, especialmente em ambientes que não desenvolvimento! Utilizar com muito cuidado.
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Friday, March 3, 2006

Model Driven Architecture (MDA) e DSL's no Slashdot

Tem estado a decorrer uma interessante discussão no Slashdot sobre os méritos do MDA, com alguns comentários a abordar as DSL's da Microsoft, bem como os méritos da modelação em geral.


Fica o link.


"Four years ago, Ask Slashdot asked if anyone was using a Model-Driven Architecture. The number of MDA tools are now almost overwhelming, and I strongly believe that comments to the same questions would be rather different nowadays. What are the drawbacks, difficulties and limitations of MDA? What percentage of code can actually be generated? I would like to add a few more: is it realistic to create a custom GUI rather than CRUD operations with these tools? Finally, what about Microsoft, the new competitor on the scene, and their DSL Tools?"