Monday, December 13, 2004

Novas do Mundo BizTalk :)

Não é novidade para quem conhece o meio ;), mas diz-se por aí que faltará já muito pouco tempo para sair o SP1 para o BizTalk (será esta semana já?), no seguimento do Rollup Package de há alguns meses atrás. Também se diz que haverá uma nova versão do BizTalk lá para 2006, e pergunto-me se um produto desta natureza e complexidade não deveria ter mais tempo de mercado entre lançamento de novas versões...


Outras novidades de assinalar são as constantes actualizações do Biztalk Explorer, agora na versão 1.30, uma terceira e muito interessante actualização dos mecanismos de deployment usando Nant, a edição de Dezembro do Bloggers Guide to BizTalk, da mesma pessoa que também escreveu um artigo catita chamado The Seven Habits of Highly Effective BizTalkers:



  • One-click deployment (um MUST total)
  • One-click testing
  • Prototype ouside the project
  • Follow the patterns (quem ainda não tem O Livro?)
  • Learn to debug (crucial, dadas as especificidades do desenvolvimento em BizTalk)
  • View the source (que eu juntaria ao anterior)
  • Join the Community (já são uns 25 os blogs sobre o produto, para nem falar dos newgroups e workspaces...)

Finalmente, refiro ainda o primeiro livro de BizTalk 2004, Microsoft BizTalk 2004 Unleashed, escrito pelo Scott Woodgate&amigos, que infelizmente não posso ainda comentar por vicissitudes do serviço postal. :)


PS à posteriori: o TheServerSite.NET tem disponível um PDF com capítulos do livro, sobre Adapters, orchestração de Web Services e coorelação, e desenvolvimento de regras, e a SAMS um capítulo sobre especificações de mensagens. Já são quatro. :)

Thursday, November 18, 2004

24 horas com o SharePoint 2003

O problema: numa configuração Small Server Farm, tal e qual como descrita na documentação, o SPS queixa-se de "topologia não suportada", o que impede - entre outras coisas - a realização de backups.


Depois de algum tempo com este problema, foi aberto um caso com a MS, que recomendou a re-criação da BD de Configuração, e o re-attach das BD's de conteúdo antigas. Decidimos avançar por aí.


15:00 Problema de topologia não suportada num SPS em produção.


15:05 Realização de backup SQL às 4 bases de dados que suportam o SPS.


15:10 Modificação das atribuições de componentes aplicacionais (Web, Search, Index e Job Server), que foram limpas.


15:15 Disconnect da BD de Configuração, e criação de nova BD de configuração.


Entre esta hora e as 17:15, tentativas variadas de ligar o portal às BDs de conteúdo previamente existentes. Telefonemas de utilizadores a queixar-se de indisponibilidade do sistema.


17:15 Já com apoio telefónico da MS, repetição de todos os passos tentados durante as 2h anteriores, sem sucesso.


17:50 Plano de contingência: voltar à BD de configuração anterior, restaurando também as "component assignments" prévias.


18:00 Na página da Central Administration, o erro de topologia... desapareceu (!). O portal parece totalmente funcional, com a excepção da pesquisa: "No results are available due to a network failure. Please contact the portal's administrator."


Dia seguinte


15:00 Análise do Event Log (nada) e dos logs de pesquisa do SharePoint, que numa das suas linha diz: Could not find stored procedure 'dbo.proc_MX_getVersion'.


15:10 Número de resultados por pesquisas por proc_MX_getVersion no Google e Google Groups: 0 (zero). :-)


15:15 Análise às bases de dados do SharePoint. Nenhuma delas tem este Stored Procedure. A BD xxx_SERV, no entanto, tem uma tabela chamada "MX_Version".


15:20 Restauro, para uma nova BD, do backup da xxx_SERV das 15:05 do dia anterior.


15:30 Comparação dos stored procedures existentes nas duas bases de dados. A base de dados restaurada de backup tem vários proc_MX_*, nenhum dos quais existente na versão actual, além de um proc_getPortalBuildVersion e um proc_getPortalSchemaVersion.


16:00 Criação na base de dados nova dos 16 Stored Procedures "Missing In Action".


16:20 Realização de full update ao Portal Content bem sucedido.


16:30 A pesquisa funciona. Sucesso. :-)


Claro que entretanto, o catálogo de non-portal content ficou limpo quando fiz um full update. E descobri um problema que já acontecia há 10 dias, relacionado com o Exchange usado para enviar notificações, na sequência do qual são escritos erros no Event Log de 10 em 10 segundos.


Mas isso são outras 24 horas. :)


jota

Monday, November 1, 2004

SOA: Boundaries are explicit

Na visão da Microsoft/Don Box, a orientação a serviços pode definir-se por 4 tenets:



  1. Boundaries are explicit
  2. Services are autonomous
  3. Services share schema and contract, not class
  4. Compability is based upon policy

O primeiro deste tenet, "Boundaries are explicit", foi descrito por Rich Turner como "Services are expressed at their boundary and there is only ONE way to access the information and/or functionality held within a service - through capabilities exposed at the Service Boundary. Also, assume that calling methods on a Service may take time and may be unreliable.", e pelo próprio Don Box como "Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services." (ver também este artigo, já agora)


Este post, e o foco no 1º tenet (e não só, para falar estritamente verdade), surge a propósito de um artigo que li chamado "A Note On Distributed Computing". Escrito por uns rapazes da Sun em 1994, este artigo tenta demonstrar porque é que se deve lidar com objectos remotos de forma diferente da forma como se lida com objectos locais (i.e., num mesmo espaço de endereçamento). É como que uma defesa do 1º tenet, interessante, actual e rápida de ler, e tem tudo a ver com web services.


Logo a abrir, "In such systems, an object, whether local or remote, is defined in terms of a set of interfaces declared in an interface definition language. The implementation of the object is independent of the interface and hidden from other objects." (can you spell w-s-d-l?)


No artigo identificam-se alguns motivos pelos quais se devem tratar invocações remotas de forma distinta de invocações locais:



  1. Latência: os tempos de espera em invocações remotas são a diferença mais óbvia entre os tipos de acesso (o artigo sugere algo similar a uma optimização que aproxime os objectos usados mais frequentemente, no SOA tende-se para uma visão em que a funcionalidade oferecida por cada serviço é mais rica);
  2. Acesso à memória: esta diferença prende-se especificamente a acesso à memória usando apontadores ou referências. Referem-se duas alternativas: ou todos os acessos à memória devem ser gerido pelo sistema, ou o programador deve estar consciente das diferenças entre acesso a memória local e remota;
  3. Falha parcial e concorrência: a principal classe de diferenças entre os dois modelos, refere-se por exemplo a situações em que o servidor falhe inesperadamente, e ao facto de "In a distributed system, the failure of a network link is indistinguishable from the failure of a processor on the other side of that link". Há muito a dizer sobre este ponto, o artigo fá-lo melhor do que eu.

E quase a concluir: "A better approach is to accept that there are irreconcilable differences between local and distributed computing, and to be conscious of those differences at all stages of the design and implementation of distributed applications. [...] While writing code, engineers will have to know whether they are sending messages to local or remote objects, and access those objects differently. While this might seem to add to the programming difficulty, it will in fact aid the programmer by providing a framework under which he or she can learn what to expect from the different kinds of calls."


Com as devidas adaptações, e talvez lendo "serviços" onde o artigo usa geralmente "objectos [remotos]", o artigo surpreendeu-me pela sua actualidade, e recomendo-o vivamente a quem desenvolva web services hoje, com ou sem o chapéu do SOA.


jota


Ps: isto não é um post "pró-Sun", mas sim de surpresa por uma bela pérola encontrada ao acaso :-)

Wednesday, October 6, 2004

Blogs e BizTalk 2004

Os weblogs têm sido o local de publicação de muita informação interessante sobre BizTalk 2004 desde a sua colocação no mercado. O Bloggers Guide to BizTalk é prova disto, incluindo vários artigos que saíram ao longo dos últimos meses.


"The aim of The Bloggers Guide to BizTalk is to provide the best of the online content produced by the BizTalk blogging community in an easily accessible format. All the content in the guide has been created by BizTalk developers who wish to share their knowledge and ideas with others in the developer community. The subjects of these contributions and the level of their complexity are varied, so there is information available for those who are new to BizTalk, as well as for advanced developers."


Listo abaixo alguns dos que considero mais interessantes, para quem estiver interessado:


Scott Woodgate (BizTalk 2004 Product Manager)
http://blogs.msdn.com/scottwoo
 
Martijn's blog - E-Commerce, EAI, BizTalk and .NET
http://martijnh.blogspot.com


Gilles' WebLog
http://blogs.msdn.com/gzunino


Darren Jefford
http://blogs.msdn.com/darrenj


Suresh Kumar
http://captaink.blogspot.com


Charles Young
http://geekswithblogs.net/cyoung


Mike Holdorf's Blog
http://dallas.sark.com/SarkBlog/mholdorf/


Christof Claessen's Blog
http://weblogs.asp.net/christof_claessens


Trace of Thought (Scott Colestock)
http://www.traceofthought.net/


BizTalk Core Engine's WebLog
http://blogs.msdn.com/biztalk_core_engine


Chanian Raj
http://dotnetjunkies.com/WebLog/rajchaniansbiztalkblog


The Arch Hacker's BizTalk Blog
http://thearchhacker.blogspot.com

jota

Wednesday, September 22, 2004

Salário Médio por Produto Microsoft

O artigo completo está disponível na Microsoft Certified Professional ONLINE, e entre vários pontos interessantes destaco o que se pode também em nesta imagem, um ranking do salário médio pago a pessoal da TI conforme o seu grau de conhecimento de cada tecnologia Microsoft:


#1 Identity Integration Server (USD 81k)
#2 BizTalk Server (USD 79,9k)
#3 Project Server
#4 Live Comunications Server
#5 Windows Server 2003 Data Center
#6 SharePoint Portal Server
#7 Speech Server
#8 Commerce Server
#9 Windows 2004 64-bit
#10 Visual Studio (USD 70,5k)
(a lista continua)

Thursday, September 16, 2004

BizTalk Developer Competition - Resultados

Foram publicados os resultados do BizTalk Developer Competition, e algumas das participações são realmente muito interessantes: http://blogs.msdn.com/scottwoo/archive/2004/09/14/229601.aspx


Daqueles que já vi, agradaram-me especialmente o vencedor, "BizTalk Server 2004 Administration Tool" e o terceiro classificado, "BizTalk Server 2004 Nant deployment".


jota

Wednesday, September 1, 2004

BPI, Architect's Journal, Biztalk Scalabily & High Availability

Boas novas: um renovado Business Process and Integration Developer Center, em grande parte dedicado ao Biztalk 2004; a 3a edição do Architect's Journal, de onde destaco os artigos sobre "Identity and Access Management" e "Messaging Patterns in Service Oriented Architecture"; e o guia "Scalability and High Availability in BizTalk Server 2004":


"The architectural components of BizTalk Server 2004 that facilitate scalability and high-availability are based on robust methodologies and mechanisms embedded and integrated within BizTalk Server, SQL Server and Windows Server 2003. This multi-faceted scalability and high-availability architecture provides numerous options for designing OSS/BSS integration applications that can be expanded to meet any performance and growth contingencies on an incremental or exponential basis without any operational disruption."


Soube-se recentemente que o WinFS não vai estar presente na primeira versão do Longhorn, permanecendo no entando o Avalon e o Indigo. Pessoalmente, lamento esta exclusão, apesar de a compreender.


jota

Friday, August 27, 2004

BPI, Architectect's Journal e dicas Biztalk

 


Entretanto, no campo do Biztalk, tenho-me deparado com alguns problemas desagradáveis


a FAultMessage (na Port Surface) não pode ter espaços


o problema do http://www.traceofthought.net/PermaLink,guid,abdd6ca2-e964-437d-8bee-0188ec5b5afa.aspx


 


Scalability and High Availability in BizTalk Server 2004



The architectural components of BizTalk Server 2004 that facilitate scalability and high-availability are based on robust methodologies and mechanisms embedded and integrated within BizTalk Server, SQL Server and Windows Server 2003. This multi-faceted scalability and high-availability architecture provides numerous options for designing OSS/BSS integration applications that can be expanded to meet any performance and growth contingencies on an incremental or exponential basis without any operational disruption.

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.

Tuesday, June 29, 2004

ESSO, Biztalk 2004 e Win XP SP2

O ESSO já tinha problemas com o Norton Internet Security, tem agora com o SP2 do XP. Para quem desenvolve com Biztalk em cima de XP, este link é de consultar:

 
The Enterprise Single Sign-On Service and associated BizTalk Server 2004 services fail after you install Windows XP Service Pack 2 (SP2)
 

Aproveito para recomendar o site KBAlertz, que não só permite a recepção por email de todos os novos artigos na Knowledge Base da Microsoft, como disponibiliza feeds RSS desses mesmos conteúdos.


jota

MS SOA Architecture Center e PPT's TechEd

A MS lançou um Architecture Center dedicado a Service Oriented Architecture. Podem encontrar lá, entre outros, o artigo do Pat Helland ("Metropolis") que já referi.


Aproveito para deixar o URL dos Powerpoints do Tech Ed:
http://downloads.mseventseurope.com/downloads/teched/


jota


PS- seria injusto não referir os excelentes conteúdos da IBM sobre SOA...

Monday, June 28, 2004

PNP Summit 2004 - Reading, UK

Estive em há duas semanas atrás no PnP Summit, realizado em Reading. Foram 3 dias de conferência (muito menos intensa que o TechEd!), com algumas apresentações bastante interessantes. Destaco as seguintes:


"SOA: Problems, Pitfalls and Pretty Good Practices", apresentada por Arvinda Sehmi da Microsoft EMEA (e responsável pelo Architect's Journal). Aquilo que se sabe no concreto sobre SOA ainda não é muito, mas nesta apresentação falaram-se de algumas das coisas que já se sabem. Ficaram ainda 3 fontes de informação recomendadas: Zapthink, o livro “Service-Oriented Architecture: A Field Guide to Integrating Xml and Web Services”, de Thomas Erl, Prentice Hall, e o (já famoso) artigo “Metropolis”, do Helland, no MS Architects Journal #2. Fica também a informação de que o #3 do Architects Journal sai em início de Julho.

Nas restantes apresentações destaco ainda "Platform Interoperability", do Ted Neward (responsável pelo TheServerSide.Net), muito prática, animada, e com diversos exemplos; e as duas apresentações de Woitek Kozaczynkski do MS Platform and Architecture Group, "P&P In Product Guidance" (entre outras coisas sobre Software Factories e Recipes, uma das novidades do novo VS) e "Application Framework for Development of Distributed Enterprise Applications (Shadowfax)" (sobre o Shawdowfax, agora chamado de Enterprise Development Application Framework, EDAF). Daqui saiu a info de que a MS não planeia investir tanto em código, nos esforços do PAG, como investiu no Shadowfax (e quem já o conhece sabe que é bastante complexo), mas que em termos de documentação (guidance) são de esperar vários novos conteúdos. O argumento é simples e lógico: o Data Access App Block (p.ex.) e o coisas como o Shadowfax estão em extremos opostos. O primeiro muito simples e de utilização ampla, o segundo muito complexo, aplicável em poucas situações, e mais caro de desenvolver.

Os PowerPoints estão disponíveis, durante não sei quanto tempo, em: ftp://ftp.guideddesign.com .

A terminar, duas curiosidades: o documento Improving .Net App Performance & Scalability (com as suas mais de mil páginas) terá custado à MS mais de USD 1 Milhão na produção; o nome de código "Shadowfax" refere-se a um cavalo branco que foi estrela aí num filme sobre aneis -- e curiosamente, outro nome de código recente da MS é "WhiteHorse"... :-)

jota

Deployment's Biztalk

Quem já trabalhou com o Biztalk 2004 sabe que o produto sofreu dois grandes saltos. O primeiro, em funcionalidade. O segundo, sem dúvida, em complexidade. Uma das áreas em que esta é maior é no que respeita a deployments das soluções desenvolvidas. Não é possível carregar no conveniente F5 para fazer Build & Debug, é antes necessário realizar um conjunto de passos independentes, para deployar vários componentes da solução, e depois testar como que em ambiente de pré-produção.


Um post recente no blog do Scott Colestock sugere a utilização do NAnt para fazer estes deployments de desenvolvimento, e  apesar de uma solução muito simples demorar cerca de 50 segundos a ficar disponível (no meu portátil), o ganho é imenso face ao processo manual anterior. Vivamente recomendado.


Aqui estão os links:


NAnt for BizTalk 2004
Update to NAnt for BizTalk


A solução não é perfeita, especificamente no que respeita aos ports e ao binding file, mas é muito interessante.


Relacionado com este assunto está este artigo, que tem dicas na utilização do BTSInstaller para fazer deployments remotos de soluções Biztalk 2004.


Finalmente, aproveito para chamar a atenção para 2 capítulos adicionais (5 e 6) do documento de P&P de Integration Patterns. Recomendo vivamente.


jota


PS- A utilização do NAnt com o Biztalk 2004 tem uma parte chata: para se gerar o binding file é preciso fazer previamente um deployment "manual" da Orquestração, para se poder depois gerar o binding file. O autor dos dois artigos que referi acima postou um terceiro, em que também aborda este assunto.