Sunday, February 12, 2006

Microsoft DSL Tools Workshop

Na sexta-feira tive a oportunidade de participar numa workshop organizada pela Microsoft sobre DSL Tools, oriendada por Annie Matthewman da Charteris. O objectivo da workshop foi apresentar as Dsl Tools no seu enquadramento geral com o conceito de Software Factories, bem como exercitar "hands-on" como as utilizar, com uma série de exercícios em redor de uma linguagem gráfica para representar expressões regulares.


Na workshop foi utilizada a versão de Fevereiro 2006, em que as Dsl Tools já vêm incluídas no SDK do Visual Studio. Fez-se a construcção dos conceitos (coisas como Literais, Wildcards, representar a multiplicidade e sequenciamento, etc.), depois a criação da linguagem gráfica, e finalmente a geração de artefactos com base em "desenhos" criados. Muito parecido com o que se faz nos walkthroughs que estão incluídos nas DSL Tools, e se não se cobriram todos os temas, foi ocasião de perceber na prática o motivo para alguns dos problemas/erros mais comuns na criação de linguagens, e também de ter algum conhecimento da realidade da equipa que, em Inglaterra, está a desenvolver as tools.


Acho que a questão que mais dificuldades/erros causa nos exercícios é o mapeamento entre o Domain Model (os conceitos da linguagem) e a sua representação gráfica, a Designer Definition. A equipa que está a desenvolver as tools optou claramente por dissociar a representação gráfica da linguagem conceptual, o que se faz algum sentido não deixa de levantar questões. Uma destas, a meu ver, é que a representação gráfica pode não ser correcta perante a definição da linguagem: por exemplo, podemos especificar que um determinado conector só pode ligar quadrados verdes (conceito X) a bolas vermelhas (conceito Y), apesar de na definição da linguagem também se poder ligar o X a Z, um terceiro conceito.
Esta questão assume dimensões mais problemáticas já que não existe nem um editor visual para fazer o mapeamento entre o Domain Model e a Designer Definition, nem qualquer validador que verifique a "completude" da representação visual.


A próxima versão das DSL Tools (em final de Março?) pode ajudar a relativizar estas questões, uma vez que o Modelo e o Designer vão passar a ser definidos num mesmo ficheiro .DSL (em vez dos actuais .DSLDM e .DSLDD), com o designer no Visual Studio a permitir editar os dois.


Aquilo que a V1 das Tools não vai suportar é a possibilidade de ter formas dentro de formas, sendo que esta é talvez a segunda questão mais referida como insuficiência das tools.


Tenho andado a discutir com pessoas e pensar sobre situações em que será vantajoso desenvolver linguagens interessantes e com elevado potencial de reutilização. Parecem-me existir, globalmente, dois grandes tipos de situações: linguagens para utilização técnica e linguagens ao nível do negócio. É muito mais fácil encontrar situações interessantes de modelar no domínio Técnico que no domínio do Negócio: é trivial identificar DSLs para modelar expressões regulares, ou uma Active Directory, ou um FileSystem, ou formatos de configuração das nossas aplicações, etc., e ver as vantagens que essas mini-linguagens poderiam ter. Mais difícil é identificar situações ao nível dos requisitos do negócio, e mesmo se identificadas, perceber o que fazer com elas, que artefactos gerar.


Num Arccast com Ron Jacobs no Channel9, o Steve Cook aborda um pouco esta distinção, referindo dois pontos interessantes: primeiro, que a criação de DSL's se deve iniciar pela análise de desenvolvimentos e situações existentes, e não por um "pensamento criativo" de coisas que podem ser interessantes; o segundo, que uma "killer application" para as DSL Tools parece ser na área dos configuradores, de código de cola entre vários módulos ou elementos das aplicações que desenvolvemos. Parece-me uma visão pouco ambiciosa, mas é claramente melhor que pedir o céu.


jota

Saturday, February 11, 2006

Microsoft Architect Forum 2006 - Lisboa

Ontem à tarde decorreu em Lisboa o Architect Forum da Microsoft, com a presença de Beat Schwegler. O Beat já tinha estado em Portugal o ano passado, numa workshop sobre Web Services, e desta vez veio falar sobre Software Factories. O tema, não sendo novo para mim (ver este post e este post), não deixa de ser interessante, e o evento valeu a pena.


A sessão que o Beat fez em Lisboa foi uma versão resumida da que fez em Inglaterra com o Ingo Rammer, e cujos slides estão disponíveis no site de Arquitectura da MS UK.
(ps: se se interessam por Arquitectura, recomendo a newsletter cujo link aparece no final desta página).


A abordagem seguida na apresentação do Beat dividiu a aposta em "Software Factories" em 4 dimensões (de uma forma até mais clara do que a que está no livro com este nome):
1) Architecture Frameworks
2) Software Product Line
3) Guidance in Context
4) Model Driven Development


O primeiro investimento é auto-explicativo.


O segundo, refere-se a montar estruturas nas organizações que permitam a exploração de "Economias de Âmbito" (em oposição a Economias de Escala), em que se factorizam as semelhanças entre vários projectos realizados em componentes (assets) reutilizáveis e parametrizáveis. O livro de Software Factories entra muito mais em detalhe do que o Beat deu, mas penso que no fundo o que está em causa é apostar de forma sistemática na reutilização, uma vez que esta foi uma das grandes promessas não realizadas da Orientação por Objectos.


O terceiro, refere-se à possibilidade de dar ajuda ao programador em contexto, directamente no IDE. Aqui a aposta da Microsoft é uma coisa chamada GAT, Guidance Automation Toolkit, disponível ainda como Technology Preview. Pode pensar-se nisto (de forma muito simplificada) como um misto das templates do Visual Studio com a possibilidade de associar acções "custom" a artefactos do IDE. Recomendo o Hands-On Lab a quem tiver interesse, uma vez que é muito elucidativo.
O problema do GAT, na versão que eu testei depois do TechEd 2005, é que era complexo definir novos packages. Depois do GAT ter a sua versão definitiva, o que deverá acontecer nos próximos meses, estão previstos vários conjuntos desta guidance, por exemplo, para WCF (o ex-Indigo), o "Service BAT", em que o Beat também está envolvido.


O quarto ponto é outro tema que me interessa bastante, e que está materializado nas DSL Tools e na aposta na modelação usando linguagens para domínios específicos, em níveis de abstracção elevados, com o objectivo de gerar artefactos dos níveis inferiores (como C#). Para mais informações, podem consultar este post, em que está o link para a apresentação que fiz sobre este tema no TechDays, ou então podem ir simplesmente ao site "oficial", aqui.


Em relação a este tema, é sempre feito um paralelo com o UML e as suas insuficiências, sendo o UML e as DSL's colocadas em campos opostos. Não me parece que o Beat tenha fundamentado q.b. o que disse sobre este tema, que em essência parece-me consistir no seguinte: o UML não tem um grau de objectividade que permita a geração de artefactos "vivos", em que se produz um modelo, geram artefactos, se altera o modelo e se volta a gerar, etc. Geralmente o UML é usado para especificação e comunicação, por vezes para efectuar a primeira geração, mas a partir daí fica apenas como documentação, e eternamente desactualizado. Com as DSLs pretende-se que o modelo esteja sempre vivo, e seja efectivamente a "source".
Acredito que esta ideia possa gerar alguma incredulidade e resistência, mas se pensarmos no caso do BizTalk, em que o código C# gerado é removido depois de compilado (ou seja, é impossível alterar à mão), ou até no Windows Workflow, que não deixa de ser uma DSL, vemos que isto é algo a que estar atento.


Foi um evento interessante, e parece-me vamos continuar a ter novidades nesta área nos próximos meses.


A terminar, aproveito para me meter com o João Hugo Miranda relativamente ao post dele sobre o evento, e especificamente sobre a eventual resitência de pessoas no "Agile Camp" relativamente a este tipo de desenvolvimentos.
Na minha opinião, e julgo que qualquer pessoa que leia até ao 4º capítulo do livro "Software Factories" vai ficar convencido do mesmo, algo tem de mudar muito rapidamente no desenvolvimento de software. Somos artesãos, cada um faz as coisas à sua maneira e ninguém faz igual, não reutilizamos como podíamos, temos ~70% do custo dos projectos em manutenção, demasiados projectos a falhar, etc. Temos muito a melhorar, como indústria, e as metodologias ágeis estão lado a lado com este tipo de esforços, independentemente de haver ou não um "Arquitecto Génio" a definir coisas à partida. Afinal, se não houvesse "Arquitectos Génios" na Microsoft ou Sun, não tínhamos a .Net Framework (e o Add Web Reference, que é uma espécie de Recipe do GAT) ou as Java Foundation Classes.


Já agora, aproveito para vos referir para um interessante podcast do Channel9 chamado "Developer 2.0". Este podcast é com o Ron Jacobs e o Harry Pierson (ambos da Microsoft), e levanta questões bastante interessantes relativamente ao presente do desenvolvimento de software. Deixo uma questão como motivação: já pensaram que o que acontece nas fábricas de texteis, por exemplo, que são deslocalizadas para locais onde os custos de produção são mais baixos, é exactamente o mesmo que está a acontecer com o outsourcing do desenvolvimento para a Índia, apesar de serem indústrias totalmente diferentes e as pessoas terem competências completamente distintas? (serão mesmo?)


jota

Thursday, February 9, 2006

BizTalk 2004/2006: Persistência e Performance Counters

Na apresentação de BizTalk 2006 no Evento PontoNetPt referi a grande fiabilidade de um produto como o BizTalk, e descrevi muito brevemente a forma como isto era garantido, pelo menos em termos de orquestrações, mesmo em cenários de "subitamente, faltou a luz".


O princípio essencial que suporta esta potencialidade é o facto de tudo aquilo que é usado nos desenhos das orquestrações ser serializável. Isto aplica-se não só às mensagens, mas também a todas as variáveis: todos os tipos utilizados têm de ser serializáveis. [Nota: há duas excepções: a classe XmlDocument, que não é serializável mas com que o BizTalk consegue lidar, e objectos declarados dentro de transacções atómicas, que não necessitam de ser serializáveis porque o BizTalk não faz serializações dentro dessas transacções].


Tendo isto como base, o BizTalk tem durante a sua execução um conjunto de chamados "Pontos de Persistência", locais em que decide serializar tudo o que tem em memória (todas as mensagens, objectos, contexto de execução, etc.) para uma das base de dados em que está suportado. Estes pontos de persistência ocorrem em locais conhecidos e documentados da execução dos processos:


- quando termina uma transacção;
- quando se chega a um breakpoint;
- sempre que se envia uma mensagem;
(etc.)


A principal vantagem deste mecanismo é possivelmente o sustentar a grande fiabilidade do produto, mas outra de referir é que se todo o estado de um processo pode ser guardado em base de dados para ser restaurando mais tarde, isto quer dizer que a execução até pode ser retomada por um servidor diferente daquele em que foi efectuada a serialização... Por outro lado, no entanto, quando mais pontos de persistência, maior o impacto no desempenho, especialmente se existirem muitos ou objectos muito grandes num processo BizTalk.


Para controlar esta situação, além de algumas optimizações que se podem fazer, a minha recomendação pessoal é utilizarem-se os Performance Counters do produto durante os testes à solução. Note-se que o BizTalk é para ser utilizado principalmente em cenário assíncronos, pelo que ter uma resposta ultra-rápida geralmente não será algo de crítico, mas ainda assim um elevado "throughput" pode ser necessário. De entre os vários PerfCounters, alguns a que presto especial atenção são, na categoria "XLANG/s Orchestations", os seguintes:


- Persistence Points (total acumulado)
- Persistence Points/sec
- Running Orchestrations


Olhar para estes indicadores ao mesmo tempo que se fazem testes, por exemplo usando tools como o LoadGen ou o BizUnit, pode ajudar bastante a fazer "tunning" dos nossos processos.


jota


Ps: conhecer como funciona a serialização é, na minha opinião, essencial para quem programa em .Net, mesmo sem usar BizTalk. Para quem quiser aprender, recomendo por exemplo este tutorial do TopXml (PDF).

SharePoint "12": novidades para o utilizador

Nos últimos dias tenho estado mergulhado no novo SharePoint "12" beta. Depois de inicialmente ter ficado algo surpreendido pelo facto de ainda ter várias arestas por limar, a impressão só tem melhorado.


Talvez a queixa que ouvi mais vezes relativamente ao SharePoint 2003 era o facto de não ter permissões ao nível do item (fosse em items de listas ou num documento numa document library). Essa restrição foi removida nesta versão, podendo ser aplicadas permissões específicas por item. Adicionalmente, agora os conteúdos a que não se tem acesso já não aparecem, em vez de aparecerem e se clicar para aceder a uma mensagem de "Não tem acesso.".


Outro lamento a que já estava habituado tem a ver com os workflows, que agora estão de volta em força. Baseados em WWF, o SharePoint tem de base os tipos mais comuns de Workflow (como aprovação/recolha de feedback em sequência ou paralelo), e se não forem suficientes, pode usar-se o FrontPage (eu disse FrontPage? queria dizer Office "12" SharePoint Designer, o antigo FrontPage is-no-more -- afinal de contas, temos aí o Quartz) para criar outros tipos de Workflows, com um conjunto de actividades já incluídas no produto. E se ISTO ainda não chegar, podem programar-se novos workflows à mão e fazer deploy para o SharePoint.
Estes workflows podem estar associados a listas, a bibliotecas de documentos, ou até a tipos de conteúdo, outro dos conceitos novos.


De certa forma, estas duas evoluções são o repôr de funcionalidades que existiram no SharePoint 2001, mas agora reformuladas e mais flexíveis e eficientes, o que não deixa de ser curioso. :-)


Só para referir mais algumas funcionalidades para o utilizador final:


- os items de listas podem agora ter um número ilimitado de anexos;


- existem novas templates de site, entre as quais uma chamada Official File, que é algo como um Repositório Oficial Formal de Documentos (imagine-se um Arquivo Morto, onde estão documentos como o Relatório e Contas de 1998, e que têm de ser obrigatoriamente guardados durante 10 anos);


- tipos de conteúdo: um tipo de conteúdo é em essência um conjunto de meta-dados que são associados a um documento numa document library. Um exemplo clássico é a Acta de Reunião, ou Fax Recebido. Cada um destes tem atributos diferentes, pode ter associados workflows distintos, datas de expiração ou arquivo automático, etc. E o melhor: podem haver documentos de diferentes Tipos de Conteúdo numa mesma Document Library.


- Recycle Bin: já havia um download da comunidade para esta funcionalidade, agora vem de base no produto.


- Integração com o Word, Excel, etc: existe uma integração muito próxima entre estas ferramentas e o SharePoint, ao ponto de se poder fazer aprovação em workflows no próprio Word, preencher metadados (via formulários InfoPath apresentados embebidos no Word...), etc.


Podia ficar aqui muito mais tempo a falar das novidades, e ainda nem referi a pesquisa, o facto de o SharePoint agora incluir o Content Management Server, o Business Data Catalog, etc. Mas deixo isso para outras oportunidades.


jota


ps: julgo que o beta2 esteja para Março... e a licença go-live também para essa altura (?).

Monday, February 6, 2006

BizTalk 2004: Event Log Adapter

Tive uma solicitação de um cliente a perguntar sobre a melhor forma de copiar erros registados no event log (por acaso gerados pelo BizTalk), para uma base de dados remota que é monitorada por outras ferramentas. A principal opção em cima da mesa era desenvolver um serviço windows para monitorar o event log, e depois fazer essa gravação. A "melhor" solução, no entanto, consegue fazer-se sem escrever código, e usando o próprio BizTalk.


Um dos vários desenvolvimentos nascidos na comunidade BizTalk é um Event Log Adapter, que permite criar uma Receive Location a apontar para um Event Log. Esta receive location faz um "polling" regular e publica na MessageBox os eventos novos que encontrar, devidamente serializados em XML. O link é este: http://www.gotdotnet.com/workspaces/workspace.aspx?id=26102375-6bdf-47f7-ace9-33a2d34fc582


Este adapter, cuja configuração mostro de seguida, permite especificar qual o servidor de onde queremos ler, de que Log (Ex: Application, Security, etc.), com que periodicidade, e até um filtro em XPath.


Usando este adapter, resolve-se rapidamente minutos o problema, recorrendo apenas a componentes de "messaging":


1. Criar um Receive Port, no qual se criam tantas Receive Locations quantos os logs que quisermos monitorar. Um exemplo de XML que o Adapter produz é:


<?xml version="1.0" encoding="utf-8"?>
<EventLogEntry index="837" eventID="12588665" entryType="Error" source="BizTalk Server 2004" categoryNumber="BizTalk Server 2004" timeGenerated="03-02-2006 21:46:07" timeWritten="03-02-2006 21:46:07" userName="" machineName="myserver" eventLogName="Application" eventLogMachine="myserver" xmlns="
http://tempuri.org/EventLogAdapter">
<Message>(detalhe da mensagem)</Message>
<Data></Data>
</EventLogEntry>


2. Criar um Send Port, com um filtro a indicar que queremos apanhar todas as mensagens originadas no Receive Port acima. Este Send Port utiliza o SQL Adapter, incluído "out-of-the-box" no BizTalk 2004, para escrever para a base de dados pretendida.


Voilá. Outro cliente satisfeito. :-)


jota

Evento PontoNetPt: Slide Decks

Boas,


para quem tiver interesse, estão disponíveis os slides das duas apresentações que realizámos (eu e o Raúl Ribeiro) no evento PontoNetPt: BizTalk 2006 e Windows Workflow.


jota


(ps: links corrigidos)

Wednesday, February 1, 2006

BizTalk 2004/2006 (e WWF) Suspend Shape

A shape de Suspend do BizTalk permite suspender a execução de uma orquestração. Esta shape recebe um único parâmetro, uma string que fica registada no HAT, não sendo gerado qualquer erro no Event Log.


Uma das utilizações desta shape prende-se com facto de poder ser usada em cenários de recuperação de erros: imagine-se uma orquestração complexa com diversos scopes transacionais/atómicos em que se escreve para a base de dados, e em que a recuperação de erros é feita com base na compensação. Se a escrita para uma base de dados XPTO falhar, num desses scopes transacionais, é grande a probabilidade de a compensação, que se inicia logo a seguir, também falhar.
Vou fazer outro post, mais detalhado, sobre abordagens possíveis para resolver isto, mas uma delas passa por fazer um Suspend caso a compensação falhar. Um administrador de sistema, alertado para o problema, poderá depois ir ao HAT e fazer "Resume" de todas as instâncias suspensas, sem qualquer perda de informação.


O problema é o seguinte: na documentação do produto, é referido que a única restrição do Suspend é que não pode ser usado em scopes transaccionais atómicos (e o mesmo se diz sobre a Actity de Suspend no Windows Workflow), mas isto não é a história toda: criei um scope transaccional atómico, e adicionei-lhe um bloco de compensação. Dentro deste, posso adicionar livremente a shape de Suspend. No entanto, se adicionar à compensação um scope transaccional Long Running, ou até um simples "group", deixo de conseguir adicionar a Suspend Shape!


Isto resolve-se de forma simples criando uma 2ª orquestração, chamada por exemplo... "Suspender", apenas com uma Suspend Shape, e recebendo por parâmetro a string a usar nessa shape. Depois, na orquestração original, dentro do scope LR/grupo, basta fazer Call a esta orquestração.
É deselegante, mas funciona na perfeição.


Já agora, no Windows Workflow (beta2) é muito mais linear: não se pode usar o Suspend nem dentro da transaction activity, nem sequer da sua compensation.


jota