Wednesday, July 28, 2004

Mais uma actualização da documentação do Biztalk

Acabou de sair o update de Julho da documentação do Biztalk Server 2004. O Biztalk é um produto enorme, e dizer que "se conhece o Biztalk" é uma afirmação que não se deve fazer de ânimo leve. Este é o segundo update à documentação desde o lançamento do produto, e segundo a página anterior as actualizações ao SDK focam-se no seguinte:


«This SDK update delivers fixes and additions to the BizTalk Server 2004 SDK. Additional samples delivered in this update focus on the following areas: the Adapter Framework, Business Activity Monitoring, Human Workflow Services, BPEL, custom pipeline components and XML tools—including the BizTalk Mapper and Functoids. Fixes included in this rollup will also be available in Service Pack 1 when it is released at a future date.»


Uma vez que têm saido quase diariamente support notes relacionadas com o Biztalk, espera-se o Service Pack 1 com alguma ansiedade. Note-se que tal como nos releases anteriores, só se pode instalar a documentação se se tiver o produto instalado.

Thursday, July 22, 2004

Biztalk 2004 - Debug

Fazer debug de orquestrações Biztalk pode ser uma tarefa morosa (tal como o deployment, mas isso é outra estória). Aqui ficam algumas dicas:

 

1) Usar o Health & Activity Tracking. É a recomendação #1. Apesar de ser uma ferramenta algo lenta, mostra praticamente tudo o que aconteceu no sistema. O problema é que  por vezes nem sempre tudo fica registado. Já tive situações em que se geram excepções (que aparecem no HAT), mas todo o path de invocação das compensações respectivo não ficam registadas. Também pode ser usado para fazer colocar breakpoints nas Shapes.

 

2) Se se puder desenvolver localmente, fazer build&deploy, Attach ao processo Biztalk (BTSNTSvc) no VS.Net, colocar breakpoints no código de componentes .Net que tenhamos desenvolvido, e desencadear o processo normalmente. Cuidado quando se faz Start a outras orquestrações, ou ao desencadear mais de um fluxo de teste em cada momento, porque o VS.Net fica... bom, histérico será uma palavra apropriada? :-)

 

E depois existem os métodos à antiga:

 

1) "À antiga": escrever para um ficheiro. Quando preciso de recorrer a isto, uso a seguinte forma:

 

StreamWriter sw = File.AppendText(@"c:\filename.txt");

sw.WriteLine(....); sw.Flush();

....

 

sw.Close();

 

(importante não esquecer os flush...)

 

2) Usar o DebugView da SysInternals, colocando chamadas a:

 

System.Diagnostics.Debug.WriteLine(...);

 

Isto é muito mais conveniente que a solução anterior, e pode ser facilmente usado dentro das Expression Shapes, mas pode nem sempre ser possível usar ferramentas "alheias" (ainda que gratuitas).

 

jota

Sunday, July 18, 2004

Convenções nomenclatura Biztalk 2004

Um dos aspectos importantes do desenvolvimento com Biztalk, curiosamente pouco referidos na literatura, tem a ver com convenções de nomenclatura. Depoys de "deployado", a organização em project's desaparece por completo, restam apenas os Assemblies, Schemas, Ports, Receive Locations, etc. Não existe o conceito de "virtual dir" de IIS, ou pastas, que nos permitam organizar melhor os vários artefactos Biztalk.


Este weblog apresenta um conjunto de sugestões de nomenclatura, com prefixos, camel-case e utilização de nomes explícitos (isto para resumir).


A isto acrescento uma sugestão adicional: utilizar como nome do projecto Biztalk o namespace dos desenvolvimentos contidos no mesmo. Em cenários multi-empresa em que a funcionalidade não seja partilhável, pode ser interessante ter o nome da empresa como primeiro componente desse namespace. Outra sugestão, esta aliás usada em tutoriais e exemplos, é separar as componentes de orquestração e schemas em projectos diferentes.


Exemplos (de projectos/namespaces):
Cliente.BusinessProcesses.Purchase.Orchestrations
Cliente.BusinessProcesses.Purchase.Schemas
Cliente.BusinessProcesses.Notification

...


jota

Saturday, July 17, 2004

Biztalk e Excesso de Informação

Parece um paradoxo, este título, mas a verdade é que nos dias de hoje é muito, muito difícil mantermo-nos a par de tudo o que vai saindo de novo. Bom, e desta vez é o mesmo Gregor Hohpe do EAI Patterns, com um Hsue-Sen Tham, que escreveram um belo whitepaper de 54 páginas intitulado "Enterprise Integration Patterns with BizTalk Server 2004". Neste, aplicam-se vários pattens de integração a um cenário, efectuando-se depois um mapeamento para conceitos e artefactos do Biztalk 2004.

Os patterns em causa são os seguintes:


  • Service Interface
  • Content Enricher
  • Recipient List
  • Aggregator
  • Message Translator

Está aqui o PDF.

 

Relativamente ao post de há alguns dias atrás, recebi alguns emails a perguntar como encontrar a tal formação online de Biztalk 2004. Fica aqui o URL: http://http://biztalk.msft.demoservers.com .

Tuesday, July 13, 2004

Developing Integrated Applications using BizTalk Server 2004

Começou hoje um curso de e-learning com o título descrito acima, leccionado pela Microsoft, e que dura até dia 16 de Julho. Tem duas turmas (manhã e tarde... GMT-7, isto é, hora programada + 8h), com sessões de 1h30 por dia. O site tem as aulas em versão PDF, animações Flash com áudio, laboratórios hands-on (via ligações a Virtual Machines), bem como chat e fórum de mensagens com alunos e os 2 profs.


É destinado a participantes nos EUA, mas também se pode participar cá fora, prescindindo-se no entanto da componente audio (que não faz parte do curso, e lá dentro é via telefone...).


Não sei se ainda há espaço para participantes adicionais, mas na turma da manhã são apenas 5, pelo que isto se me afigura possível. Adicionalmente, os 3 primeiros módulos são simples (overview, schemas e maps), pelo que começar amanhã (terça-feira) não seria grande perda a quem tivesse tempo de ver os materiais disponíveis antes da... aulinha das 17h locais. :-)


jota

Thursday, July 8, 2004

MSDN Architecture Webcast: p&p live: Integration Patterns

Estive há pouco a ver o webcast que refiro no título. Esperava um resumo do documento novo da MS de Integration Patterns, afinal foi uma sessão apresentada pelo Gregor Hohpe, e referia-se aos "seus próprios" patterns, descritos no site e no livro respectivo (já um clássico). A descrição da sessão era a seguinte:


Today's business applications rarely live in isolation. Users and customers expect instant access to data and functions that may be spread across multiple independent systems. Therefore, these disparate systems have to be integrated to allow a coordinated flow of data and functionality across the enterprise. Despite advances in EAI and Web Services tools, creating robust integration solutions is not without pitfalls. For example, the asynchronous nature of most message-based integration solutions is different from the synchronous world of application development and requires architects and developers to adopt new design, development and testing strategies. This webcast shows how design patterns can help developers build successful integration solutions. The patterns have been harvested from years of actual integration projects using messaging, Web Services and EAI tools.


Todo o webcast foi à volta de trocas assíncronas de mensagens, e dividiram-se os patterns de Enterprise Integration nas seguintes categorias:



  1. Transport messages --> Channel Patterns
  2. Design Messages --> Message Patterns
  3. Route messages to correct destination --> Routing Patterns
  4. Transport messages to the required format --> Transformation Patterns
  5. Produce and consume messages --> EndPoint Patterns
  6. Manage and test system --> Management Patterns

Alguns dos patterns descritos foram:



  • Return Address (enviar numa mensagem o endereço a usar para a notificação de retorno);
  • Correlation Identifier (enviar na mensagem algo que permita correlacionar o pedido efectuado com a sua resposta, como GUIDs, ou identificadores "de negócio");
  • Pipes and Filters (ex: FABRIQ, é tipo pipelines de processamento/filtros);
  • Content-Based Router (decidir destino da mensagem com base no seu conteúdo);
  • Splitter (partir a mensagem do pedido em vários pedaços, encaminhados eventualmente para subsistemas distintos);
  • Aggregator (filtro com estado, que reúne os vários pedaços que podem resultar de respostas de um splitter, decide quanto tempo tudo completo - e usa correlação -, compõe uma mensagem de resposta e devolve ao consumidor);
  • Scatter-Gather (enviar mensagem para um conjunto dinâmico de destinatários, e devolver uma mensagem que inclui as várias respostas; é um patterns composto).

Um dos pontos que reforçou foi a utilidade e possibilidade de fazer composição de patterns (aliás, a linguagem gráfica do livro/site até facilitam isto), e tal como se faz também no Integration Patterns da Microsoft, em cuja produção colaborou "assíncronamente" (como me respondeu :-)). A terminar, e para resumir, fechou com duas chamadas de atenção: o "mensageamento assíncrono", se permite que as coisas sejam mais "loosely coupled" (e hoje é quase impossível ler textos técnicos que não incluam estas duas palavrinhas), também implica mais trabalhinho para os developers de soluções deste tipo. E lembrei-me de algo que ouvi no PnP Summit: "Não é preciso manter código que não se precisou de escrever"...


Aliás, achei curioso que a apresentação abriu com uma frase curiosa: "[Coupling/Dependencies] are not inherently good or bad", salientando que uma das vantagens do [tight] coupling é que o facto de haver mais "assumptions" permite desenvolver de forma mais eficiente e simples, bem como testar mais facilmente. Outra frase da apresentação: "How do you make 2 systems loosely coupled? Don't connect them." (David Orchard, BEA)


Enfim. Uma apresentação de nível introdutório, mas ainda assim interessante.


Deixo uma questãozita para quem quiser pensar: imagine-se que num SOA se implementam vários processos de negócio, que funcionam com "mensageamento assíncrono". Faz sentido, nestes cenários, usar algo como "Return Addresses", ou seja, prender ao Interface do serviço uma indicação (nem que seja lógica) sobre quem/como vai ser notificado do resultado do processo? FFT.


jota

Tuesday, July 6, 2004

Joel On Software, e polémica na Microsoft - the API WAR

Há uns anitos atrás cruzei-me com um site de um programador Nova Iorquino que já tinha estado na Microsoft (no desenvolvimento do Excel 5), e onde descobri uma referência a um livro que vim a considerar um clássico imprescíndível, chamado Peopleware.


No arquivo deste site estão vários artigos muito interessantes, em cuja leitura o tempo não será desperdiçado. Um destes, o mais recente, chama-se How Microsoft Lost the API War, e está suscitar muita discussão on e offline.


A tese do artigo, para resumir, é a seguinte: aquilo que de mais valioso existia na plataforma Microsoft eram as suas API's de desenvolvimento, que permitia o desenvolvimento de aplicações em cima do seu sistema operativo. Com o continuado desenvolvimento de aplicações em Web, isto torna-se em grande medida irrelevante.


Por outro lado, tem-se assistido a várias opções de quebra de compatibilidade entre novas versões e versões anteriores de tecnologias Microsoft (exemplos? VB6/VB.Net, .Net Framework 1.1/2.0, Biztalk200/2004, Sharepoint 2000/2003, etc.), e parece até já dado assente que o modelo de desenvolvimento do Longhorn, quando sair (em 2008?), não vai ser compatível com o modelo actual de desenvolvimento de aplicações. Assim sendo... porquê desenvolver, hoje, aplicações WinForms?


E aqui fecha-se o argumento, porque estas aplicações são as tais que usam e beneficiam das API's.


O artigo, reconhecendo as grande insuficiências do HTML, constata o óbvio: este é omnipresente, aplicável para muitos tipos de aplicações, e tem como uma das suas grandes vantagens o facto de ter um custo de deployment para um novo utilizador nulo. E isto pode estar a ditar, de alguma forma, uma "derrota" da MS neste campo. Isto explicaria em parte o grande investimento a que estamos a assistir em SmartClients (muito nas áreas de baixar o custo de deployment e no funcionamento offline), mas o facto de esses esforços "irem para o lixo" já daqui a 4 anitos não costuma ser mencionado :-). E também explicaria, talvez, o facto de o Internet Explorer estar parado, em termos de novas versões.


Independente de se concordar ou não com o texto do Joel, vale bem a pena ler, está bem escrito e construído de forma muito inteligente. E tenham cuidado com ideias pré-concebidas que possam ter, porque o rapaz é muito convincente, e o texto faz pensar.


... para se avaliar o grau de polémica que textozito causou, basta ir ao google, onde existem quase 9000 resultados sobre o mesmo...


jota


Ps- se por acaso não tens o Peopleware... Compra-o. É um daqueles clássicos absolutos e obrigatórios. A sério.

Webcasts: SOA, WSE, Biztalk

Os webcasts da MS são das formas mais interessantes de ter overviews rápidos de determinada tecnologia ou tema. De entre os webcasts dos próximos dias, seleccionei os seguintes, que recomendo:

 
MSDN Webcast: BizTalk Server 2004: WSE 2.0 and SQL Reporting Services – Level 200 - 6 de Julho [Cancelado]
MSDN Architecture Webcast: patterns & practices Live: Integration Patterns – Level 200 - 8 de Julho


 

Agora só é preciso ter tempo para tudo...

 

Outra curiosidade: os reports que recebi do TechEd relativos a SOA mantiveram a impressão que tinha até aqui, isto é, que continua tudo a ser muito "teoria-ware". No entretanto, dois dos capítulos do documento de Integration Patterns são interessantes por serem um pouco mais concretos, e deixo aqui os links:


E ainda outro, só para fechar :-), uma nota da ZapThink sobre o que significa afinal "Loosely Coupled" no SOA, do qual cito dois pedaços:


  • Getting away from the One Component / One WSDL Mentality: One of the wonderful things about SOAs is that they have contracted interfaces. A software contract is a document that specifies what a particular application or functional component expects of consumers and what those consuming applications can expect of it. [...] The cardinal sin induced in this case is the notion that each component must have only one WSDL description, or that a WSDL file can only map to a single component. In a truly loosely coupled SOA, the opposite is far more desirable. In such an SOA, a single piece of application functionality can map to many different WSDL documents – each specifying how a particular group of consumers can access that functionality.
  • Stop Static Binding! : SOAs are often visually described as a three-legged triangle in which there are three participants: the Service producer, the Service consumer, and the Service registry. Yet, early adopters often make the mistake of forgetting about the third corner of the SOA triangle: namely the dynamic binding aspect.

jota

 

 

Friday, July 2, 2004

Integration Patterns, Biztalk Adapters, e CMAB

1º) Já está terminado o documento de Integration Patterns da Microsoft. É um dos mais documentos mais interessantes, juntando... integração... e patterns. :-) Inclui a descrição de do cenário "Global Bank", concebido em contacto real com clientes, e que tinha também vários pontos de contacto com o Shadowfax (que segundo este post vai ser partido aos pedaços e deixar de existir de forma independente).


2º) Saiu também um whitepaper no GotDotNet intitulado "Biztalk Server 2004 Adapters: A Developer's Guide". Não é um documento simples, pelo contrário, mas nunca se sabe se não vai ser preciso desenvolver adapters... e com a relativa escassez de documentação que existe sobre o Biztalk 2004, tudo ajuda.


3º) Finalmente, depois de batalhar um bocado com o CMAB no sentido de o fazer funcionar dentro de um componente desenvolvido para Biztalk, acabei por deixar a configuração dos meus componentes no BTSNTSvc.exe.Config e não no Machine.Config. Esta configuração aponta para outro ficheiro (podia "apontar" para o registry muito facilmente), este sim numa pasta aplicacional, onde estão os pares atributo-valor, numa HashTable serializada. A solução não é perfeita, infelizmente.


Termino com uma dica sobre a utilização do CMAB para guardar dados no registry: ao contrário daquilo a que estamos habituados, este App.Block (Out-of-the-box) guarda a informação numa longa string XML, e não em pares atributo-valor como é/era convencionar fazer-se. Isto é muito pouco intuitivo, e fez-me perder algum tempo.


jota

Pat Helland, Don Box, David Chappell trálálá

Há uns tempos atrás saiu um artigo polémico na Harvard Business Review chamado "Does IT Matter?". Ora o meu colega Luis Sousa, que está no TechEd neste momento, telefonou-me durante a semana para dar conta de um momento de Entertainment musical a que teve a sorte de assistir, e que foi inspirado no artigo referido acima.


Os protagonistas foram Pat Helland, Don Box (que esteve em Portugal há 2-3 anos, na Culturgest a apresentar o .Net) e David Chappell (que esteve no Estoril na apresentação do Longhorn)


Voz, Guitarra, e Piano. É hilariante.


 


Como nota lateral: na conferência em Reading alguém da Microsoft referiu que 70% dos custos actuais de TI são em manutenção de sistemas existentes, e que a manter-se a taxa actual de crescimento deste valor, dentro de muito pouco tempo (2 ou 3 anos?) já não existirá orçamento para desenvolver novos sistemas e aplicações. A extrapolação pode ser apenas teórica, mas não deixa de ser preocupante...


jota

Thursday, July 1, 2004

Configuration Management Application Block

Uma das limitações do Configuration Management Application Block (CMAB) é o facto de a sua configuração dever ser feita num ficheiro app.config ou web.config . Assumindo que se desenvolveu uma Assembly para usar o CMAB, e que se registou esta Assembly no GAC, onde deve ser colocada a configuração do CMAB?


A resposta trivial é: na pasta onde estiver o .EXE (caso seja uma aplicação), ou na root do site, caso seja um desenvolvimento Web. E se a aplicação que é "host" e vai usar essa Assembly for um Add-In para o Vs.Net , ou o Excel ou o Biztalk? Alguém que teve este problema ao desenvolver uma extensão para o Excel optou por colocar a configuração no Excel.exe.config (sim, na pasta C:\Program Files\Microsoft Office\OFFICENN) ...


A impossibilidade de se especificar a localização do xml de configuração é talvez a grande contrariedade desde App Block (já conhecido, aliás, por a sua configuração ser algo complexa - isto é, o conteúdo dos tais .config que não sabemos onde colocar :-)).


Uma forma possível de tentar resolver isto é colocar as configurações no Machine.Config, apesar de isto ser deselegante (não testei, já encontrei quem diz que funciona e quem diz que não funciona). E outra possibilidade é alterar o próprio CMAB, e sugiro neste caso como ponto de partida o ficheiro ConcreteFactories.cs, onde diz:


 _xmlAppConfigDoc.Load(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);


A sequência AppDomain.CurrentDomain.SetupInformation.ConfigurationFile  devolve-nos o nome e o path da aplicação a ser executada no momento. Por curiosidade, no caso do Biztalk 2004 (ou antes, de um componente .Net invocado pelo Bts), o valor que me foi devolvido foi:


C:\Program Files\Microsoft BizTalk Server 2004\BTSNTSvc.exe.config


(ficheiro que já existe, curiosamente)


Para mais informações, remeto para o Message Board do Workspace GotDotNet do CMAB.


jota


PS- Acabei de verificar, no Workspace acima, que a impossibilidade de configurar o CMAB no Machine.Config está até identificado como Bug, uma vez que até contraria a documentação do Application Block.