A agitação dos Gxtips continua seu curso. Conselhos claros e práticos que nos simplificam as tarefas na hora de trabalhar.

Quando falamos de Arquitetura Orientada a Serviços (SOA), estamos falando de uma arquitetura de software que facilita o desenvolvimento de aplicações empresariais, como serviços de negócio com baixo nível de acoplamento. A chave é a autonomia entre os componentes, divididos em módulos com o objetivo que possam ser intercambiáveis. Mas estes têm que estar fortemente comunicados, porque os processos de negócio cruzam os módulos: cada subprocesso deve ocultar toda sua própria lógica do resto, só dispor do cumprimento de uma tarefa comunicando-se através de mensagens, ou seja, utilizar serviços.
 
Estamos falando de módulos que cumprem uma funcionalidade específica do negócio (por exemplo: Vendas, Compras), mas por sua vez, cada módulo também é construído com esta arquitetura (definir até onde trabalhar com esta arquitetura para que não se transforme em contraproducente é a tarefa do arquiteto). Deve-se motivar a construção de serviços - estes se encarregarão de expor uma funcionalidade bem definida para a aplicação que a requeira. Desta maneira, uma aplicação final simplesmente orquestra a execução de um conjunto de serviços, acrescenta sua lógica particular e apresenta uma interface ao usuário final. Expor processos de negócio como serviços é a chave para a flexibilidade da arquitetura. Isto permite que outras peças de funcionalidade (inclusive também implementadas desta maneira) façam uso de outros serviços de maneira natural, sem importar sua localização física. Assim um sistema evolui com a adição de novos serviços e sua melhora, onde cada um evolui de uma maneira independente. A arquitetura (SOA) resultante define os serviços dos quais estará composto o sistema, suas interações e com que tecnologias serão implementadas.
 
O primeiro problema com o qual nos deparamos é que temos duas situações bem diferenciadas: teremos aplicações da velha escola e aplicações da nova escola, ou seja, aquelas aplicações que não foram desenhadas com esta visão (ou com esta arquitetura) e as novas aplicações que nós desenhemos, nas quais deveremos pensar com Orientação a Serviços. Portanto, não só devemos resolver o problema da “minha” aplicação, mas também permitir comunicar-me com aplicações existentes (legacy) que não tenham sido pensadas desta maneira.

Para poder incorporar estas aplicações a uma arquitetura SOA, o melhor é conseguir rodeá-las de uma camada para tornar disponível o que se necessite dela de forma WS. Haverá vezes que não teremos alternativa para acessar diretamente aos dados, a efeitos de construir essa camada de integração. Para isto contamos com DBRET, DataBase Reverse Engineering Tool; o qual nos permite criar Data Views na nossa KB para acessar aos principais DBMS.

Por sua vez, como esta camada irá sendo construída de forma incremental, podemos utilizar a metodologia incremental de GeneXus, que se adapta de forma impossível de ser melhorada à construção desta camada. Assim também a facilidade de construção Web services em GeneXus é boa para dispor depois estas funcionalidades como serviços, assim também como para quando nós construímos nossos sistemas (agora sim pensando-os SOA) dispor de serviços para a rede empresarial e externa. Basta indicar isso nas duas properties do objeto GeneXus que será WS, Main program em True e Call protocol SOAP.

Para consumir funcionalidades de outros Sistemas/módulos/serviços, dispomos de WSDLInspector. Esta é uma ferramenta que automaticamente define no nosso modelo o WebService que devemos consumir e todos os tipos de dados para poder interagir com este. Depois simplesmente definimos variáveis baseadas em tipos de dados e poderemos em qualquer parte do nosso modelo invocar o WS.

Os Business Components são também elementos úteis na hora de construir nossa aplicação, já que nos permite facilmente a disponibilidade de uma transação GeneXus como WS, somente seteando uma property da tm. Habilita-se a possibilidade de dispor de toda a lógica desta e de checar as regras para outra aplicação como um WS.
 
Finalmente, para resolver a camada lógica de User Interfase, dispomos da nossa ferramenta de construção de portais GXportal.

Na nossa próxima versão GeneXus (code name Rocha), na qual já estamos trabalhando, continuaremos redobrando esta aposta, acompanhando a tecnologia e melhorando o que já temos (interagindo com ferramentas que já existem no mercado e resolvem bem problemas específicos, como, por exemplo, motores BPEL).