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:
- Transport messages –> Channel Patterns
- Design Messages –> Message Patterns
- Route messages to correct destination –> Routing Patterns
- Transport messages to the required format –> Transformation Patterns
- Produce and consume messages –> EndPoint Patterns
- 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
