E para não pararmos no tempo, vendo que as novidades do WSO2 Data Services Server 2.5.0 seriam muito bem vindas para nós, resolvemos realizar testes para verificar a possibilidade de atualizarmos nossa versão da 2.2.1 para a 2.5.0, e surgiu aquela alegria quando vimos que não teríamos problemas de incompatibilidade como ocorreu nos testes de migração da 2.0 para WSO2 Data Services Server 2.2.1.

Mas como nem tudo são rosas, um velho bug conhecido nosso na versão 2.0 e discutido no fórum - de não aceitar valores null, tinha sido corrigido na versão 2.2.1; mas resolveu dar as caras na versão 2.5.0. E por necessitarmos das novidades dessa versão, tivemos que correr atrás e corrigir o problema, já corrigido anteriormente.

Como já conhecemos a estrutura, fomos direto ao site do projeto para realizar o download do fonte do WSO2 Data Services Server e fomos atrás do arquivo problemático (SQLQuery.java). Mas para nossa surpresa, o arquivo não estava mais lá, foi centralizado no projeto WSO2 Carbon.

Então com o arquivo de código-fonte do WSO2 Carbon 3.0.0 devidamente baixado, vamos colocar a mão na massa.

Baixando e descompactando o fonte

wget  http://dist.wso2.org/products/carbon/3.0.0/wso2carbon-3.0.0-src.zip
unzip wso2carbon-3.0.0-src.zip

Baixando e aplicando o patch

wget /wp-content/uploads/2010/06/wso2-dataservices-accept-null.txt
cd wso2carbon-3.0.0-src
patch -p1 wso2-dataservices-accept-null.patch

E a mensagem recebida aqui será algo como:

patching file components/data-services/org.wso2.carbon.dataservices.core/3.0.0/src/main/java/org/wso2/carbon/dataservices/dispatch/query/SQLQuery.java

Compilando o componente

Levando em consideração que você tenha as dependências necessárias, vai ser um passo bem demorado. Vai fazer download de alguns pacotes, compilar, testar e gerar uma nova versão do componente, com a correção.

cd components/data-services
mvn install

Corrigindo o Data Services Server

Agora que temos o componente corrigido e devidamente compilado, vamos copiá-lo para a instância do WSO2 Data Services Server (levando em consideração que minha instalação fica em ~/Applications/wso2/wso2dataservices-2.5.0).

cp  org.wso2.carbon.dataservices.core/3.0.0/target/org.wso2.carbon.dataservices.core-3.0.0.jar   ~/Applications/wso2/wso2dataservices-2.5.0/wso2dataservices-2.5.0/repository/components/plugins/org.wso2.carbon.dataservices.core-3.0.0.jar
cp  org.wso2.carbon.dataservices.ui/3.0.0/target/org.wso2.carbon.dataservices.ui-3.0.0.jar    ~/Applications/wso2/wso2dataservices-2.5.0/wso2dataservices-2.5.0/repository/components/plugins/org.wso2.carbon.dataservices.ui-3.0.0.jar

Conclusão

Com o patch criado, testado e aplicado. Abrimos um pedido de correção no JIRA do WSO2, para que eles possam corrigir na próxima release (provavelmente a 2.5.1). Caso você não tenha disponibilidade (de tempo ou paciência), pode baixar os componente do WSO2 Data Services Server corrigido (bastando apenas descompactá-los).

• org.wso2.carbon.dataservices.core-3.0.0.jar
• org.wso2.carbon.dataservices.ui-3.0.0.jar

E tenho que falar, viva o código aberto e o software livre! (;

Posts relacionados

• Utilizando o Array Type do WSO2 Data Services Server 2.5.x
• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• Novidades do próximo WSO2 Data Services Server (2.5.x)
• Consumindo um serviço seguro utilizando PHP
• Compilando o plugin do WSO2 Data Services Server para o Eclipse

Você pode conseguir maiores informações no site do produto WSO2 Stratos (em inglês) e, também, testar tudo funcionando (lembrando que não é uma versão final ainda) fazendo seu cadastro - grátis. Testar o WSO2 Stratos.

Os produtos lançados nesse formato são:

• Governance
• Identity
• Application Server
• Gadgets
• Mashup Server
• Business Activity Monitor
• Enterprise Service Bus

Assim que sobrar um tempo vou ver como ficariam implementações utilizando a versão livre deles e ver até onde ela está liberada para ser utilizada. E também a dificuldade de trabalhar dessa forma.

Posts relacionados

• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• WSO2 Business Activity Monitoring + SQL Server
• WSO2 Enterprise Service Bus – Manipulando erros em Endpoints
• Consumindo um serviço seguro utilizando PHP
• Instalando WSO2 Enterprise Service Bus Eclipse Tools no Ubuntu Karmic Koala (9.10)

Ambas tem seus problemas, muitas requisições invocando várias vezes ou dificuldade de implementação (dependendo do banco de dados) para o caso de realizar o parser na procedure; mas, de uma forma ou outra, resolviam o problema. Só que com a implementação de Array Type resolvemos esse problema de maneira simples, eficiente e elegante!

Colocando a mão na massa

Digamos que temos um serviço onde nosso cliente quer listar vários produtos, nosso cliente tem todos os códigos dos produtos e quer o restante dos dados. Antigamente passaríamos para ele um método productById que recebe um id, algo como abaixo:

Mas agora tudo foi facilitado, vamos a "mágica"! Para alteração do método que aceite a entrada de um Array Type, serão necessários apenas dois passos.

Passo 1: editando a query

Teremos que trocar a query que antigamente aceitava apenas um parâmetro como entrada "id = :id" e colocaremos uma que aceita "N" parâmetros "id in (:id)". Então na tela de edição da query do WSO2 Data Services Server, basta trocarmos, como fiz abaixo:

Passo 2: editando o tipo da entrada

E o segundo passo, editando os Input Mappings, basta trocarmos o tipo scalar para array, novamente, como fiz abaixo:

O resultado

E agora vamos a parte legal: o resultado!

Conclusão

Essa implementação facilitou muito e melhorou a qualidade de nossos serviços. Ainda não foi lançada a versão final, apenas algumas releases candidates, que podem ser acompanhadas pelo repositório de builders do WSO2 Carbon 3.0.0.

Deixo aqui o download dos arquivos utilizados para implementar o Array Type nesse exemplo, contém os arquivos abaixo:

• Data Service antes da implementação do Array Type
• Data Service depois da implementação do Array Type
• Script de criação do banco de dados utilizado (MySQL)

Posts relacionados

• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• Compilando o WSO2 Carbon 3.0.0 e corrigindo o WSO2 Data Services Server 2.5.0
• Novidades do próximo WSO2 Data Services Server (2.5.x)
• WSO2 Business Activity Monitoring + SQL Server
• WSO2 e a quinta-feira agitada: muitos lançamentos

Na página de downloads do WSO2 Web Services Framework for PHP, é possível escolher entre 3 opções de instalação, então exemplificar a fundo apenas uma e colocar uma breve descrição das outras.

Binary Distribution

É o framework já compilado e com a DLL dentro que serve para as pessoas que a utilizarão em ambientes Windows, não terá muito trabalho, apenas colocar a DLL na pasta correta e configurar o seu php.ini. Essa é a opção mais prática - na minha opinião - para Windows (deixarei essa para uma próxima, não tenho ambiente para isso - ainda).

PECL Distribution

Em teoria é a mais fácil de todas. Mas por que "em teoria"? Passei dois dias realizando diversas configurações na minha máquina para que isso funcionasse corretamente, perguntei no fórum se alguém poderia me ajudar a solucionar, mas desisti. Parti para a maneira "clássica", o famoso CMM, que descrevo abaixo.

Source Distribution

Essa versão é o código-fonte do WSO2 Web Services Framework for PHP (aberto, hein!) e aqui temos duas opções de download, com apenas uma diferença mínima: o compactador. Uma foi compactada utilizando ZIP e outra TAR/GZ. E ambas será necessário compilação, com os bons e velhos comandos: ./configure, make && make install.

Mas, chega de papo, vamos por a mão na "massa".

Instalando as dependências

As dependências para funcionamento do framework, não são muitas:

• WSO2 Web Services Framework for C
• PHP 5.1.1 ou superior
• Bibliotecas libxml2 e OpenSSL

WSO2 Web Services Framework for C

Para quem tá acostumado, são os velhos conhecidos, bastando baixar a última versão (no meu caso a 2.0.0):

wget http://dist.wso2.org/products/wsf/c/2.0.0/wso2-wsf-c-src-2.0.0.tar.gz
tar xfvz wso2-wsf-c-src-2.0.0.tar.gz
cd wso2-wsf-c-src-2.0.0
./configure
make
sudo make install

PHP 5.1.1 ou superior

Não vou entrar nos méritos de instalação do PHP, pois imagino que isso esteja mais do que documentado na internet por aí a fora (para os preguiçosos - google: instalação do php no ubuntu).

Bibliotecas libxml2 e OpenSSL

O comando para instalar as dependências é:

sudo apt-get install libxml2 openssl

E com todas as dependências já instaladas e funcionando, podemos utilizar um phpinfo(); para conferir:

Compilação do WSF/PHP

CMM

E agora, a instalação propriamente dita, utilizando novamente os pacotes da versão 2.0.0:

wget http://dist.wso2.org/products/wsf/php/2.0.0/wso2-wsf-php-src-2.0.0.tar.gz
./configure
make
sudo make install

1, 2, 3, testando...

Estamos quase chegando lá...

Vamos copiar dois arquivos do diretório samples (um cliente e um servidor) para o diretório do servidor web (no meu caso: /var/www/samples) e ver se tudo funcionou:

sudo mkdir -p /var/www/samples/
sudo cp samples/math_* /var/www/samples/.

Indo ao navegador, basta abrir o endereço http://localhost/samples/math_client.php e conferir tudo funcionando:

Conclusão

Ainda não consigo avaliar até onde é válido ou interessante utilizar esse framework, não pesquisei a fundo ainda o funcionamento e as vantagens dele sobre as implementações como SOAP (nativa do PHP) NuSOAP.

Mas o fato de ser uma instalação que não pode ser feita em "qualquer" servidor, ainda mais no Brasil onde as empresas de hospedagens normalmente não instalam extensões de terceiros e o preço para ter um servidor próprio não é tão acessível, pode acabar ficando inviável.

Realizarei testes mais profundos para verificar as verdadeiras vantagens dessa abordagem na implementação dos serviços, só que - novamente - ficará para um outro post.

Posts relacionados

• Consumindo um serviço seguro utilizando PHP
• Compilando o WSO2 Carbon 3.0.0 e corrigindo o WSO2 Data Services Server 2.5.0
• Instalando WSO2 Enterprise Service Bus Eclipse Tools no Ubuntu Karmic Koala (9.10)
• Lançamento do WSO2 Stratos (alpha)
• Utilizando o Array Type do WSO2 Data Services Server 2.5.x

Nota de tradução: O artigo original foi escrito em inglês e pode ser lido em: WSO2 Enterprise Service Bus - Endpoint Error Handling

WSO2 Enterprise Service Bus - Manipulando erros em endpoints

Conteúdo

• Terminologia
• Introdução
• Qual a importância da manipulação de erros?
• Conceitos
• Situações de endpoint
  • Active
  • Timeout
  • Suspended
• Configurações do Leaf endpoint
  • Exemplo de configuração
• Fail-Over Endpoint
  • Exemplo de configuração
• Conclusão
• Apêndice A

Terminologia

Service Provider endpoint: WSO2 Enterprise Service Bus atua como uma central de distribuição, entregando as mensagens recebidas dos clientes aos service provider endpoints.

WSO2 Enterprise Service Bus Endpoint: Esta é a representação do service provider endpoint, omitida internamente na configuração do WSO2 Enterprise Service Bus.

Introdução

Corporações são complexamente estruturadas e compostas por centenas de aplicações com semânticas completamente diferentes. Algumas dessas aplicações são desenvolvidas personalizadamente, algumas são adquiridas de terceiros e outras podem ser a combinação de ambas; e podem ser operadas em diferentes ambientes e sistemas. Muitas aplicações rodam em diferentes sistemas, o que faz isso ser muito complexo. E devido a esses fatores, isto é vital a integração entre as diferentes aplicações.

O WSO2 Enterprise Service Bus tem a capacidade de prover a tecnologia para integrar essas aplicações, as quais podem ser definidas como o estado da arte para EAI, baseadas nos princípios do SOA. Com a WSO2 Enterprise Service Bus, o processo completo pode ser alcançado pela realização de várias tarefas na mensagem - transformação (transformation), roteamento (routing) e troca de transporte (transport switching) - antes do envio ao service provider.

A configuração no WSO2 Enterprise Service Bus é feita em etapas, são elas:

• Mediators
• Proxy services
• Endpoints
• Tasks

Os Mediators são componentes funcionais dentro do WSO2 Enterprise Service Bus, eles fazem várias coisas como gravação de log (logging), transformação (XSLT transformation), envia mensagens externas, filtros baseados em XPath, etc. Então os mediators são o núcleo da mensagem processada dentro do WSO2 Enterprise Service Bus. A última etapa da mensagem dentro do WSO2 Enterprise Service Bus é o envio da mensagem de resposta para um services provider. Quanto ao WSO2 Enterprise Service Bus é responsável pelo envio da mensagem para um serviço de escuta de endpoint. As mensagens enviadas do WSO2 Enterprise Service Bus podem ser muito diferentes da mensagem recebida. Por exemplo, as mensagens recebidas podem ser SOAP 1.1 over HTTP. Mas WSO2 Enterprise Service Bus pode enviar a mensagem para o serviço como SOAP 1.2 over JMS. Neste caso o endpoint exposto para o cliente é SOAP 1.1 over HTTP, o atual endpoint é SOAP 1.2 over JMS.

Um Endpoint é uma abstração do services provider. Uma vez que a mensagem é enviada usando um Mediator, ele deve saber qual é o endpoint services provider. O Endpoint é capaz de prover essa informação. No cenário ideal o serviço de endpoint aceita requisições de mesmo tipo, WSO2 ESB pode ser usado para balanceamento de carga (Load Balancer). A principal razão por trás disso tudo é que esses endpoints tem mesmas funcionalidades e é natural vê-las como uma coisa só.

WSO2 Enterprise Service Bus tem o conceito de construção de endpoints para representar endpoint services provider. Seguindo os Endpoints construídos sobre o WSO2 Enterprise Service Bus.

1. Address Endpoint
2. WSDL Endpoint
3. Default Endpoint
4. Load Balancing Endpoint
5. Fail-Over Endpoint

Dos itens mencionados acima, os mais utilizados são o Address e o WSDL Endpoints. Cada Endpoint tem seu próprio XML de configuração, escrito na linguagem Synapse. Synapse é uma linguagem XML usada para configurar a Enterprise Service Bus.

Até o Endpoint enviar a mensagem de resposta, pode encontrar vários erros de transporte. Por exemplo, a conexão pode dar timeout ou pode ser fechada pelo serviço atual.

Qual a importância da manipulação de erros?

WSO2 Enterprise Service Bus é uma aplicação de longa duração e nesse tempo falhas podem ocorrer. Retiring on transient failures enhances the fault tolerance of a system. Para a WSO2 Enterprise Service Bus, essas falhas podem ser falha de conexão entre o services provider e a WSO2 Enterprise Service bus, erro em alguma operação do banco de dados e assim por diante, sendo que as falhas de comunicação são mais frequentes.

Então a manipulação de erros é a chave para o sucesso de qualquer publicação na Enterprise Service Bus. Muitas vezes nós utilizamos TCP, as pessoas podem perguntar, como podem ocorrem erros? O protocolo TCP é muito confiável, não é? Mas não na vida real. Mensagens pode falhar ou se perder devido a diversas razões na rede TCP. Esses erros são muito raros, mas podem ocorrer. Para entender a importância da manipulação de erros vamos considerar o seguinte cenário.

Se a WSO2 Enterprise Service Bus não estiver devidamente configurada para aceitar erros, ocasionalmente, quando eles ocorrerem, o Endpoint será marcado com uma falha. Isto leva para uma mensagem de falha. Por padrão, o Endpoint será marcado como falho por um longo tempo. Os erros encontrados na WSO2 Enterprise Service Bus podem ser um problema intermitente que ocorrem uma vez por semana, mas devido a singularidade do erro, mensagens posteriores poderão ser perdidas. Claro que você pode configurar a WSO2 Enterprise Service Bus para manipular estas situações e este artigo dará a você uma maior compreensão sobre como trabalhar com Endpoints e otimizar as suas configurações.

Conceitos

Nós chamamos Address, Default and WSDL Endpoints como Leaf Endpoints, que enviam a mensagem. A Load Balance ou Fail-Over Endpoints usa um ou vários Leaf Endpoints para enviar a mensagem. Então um Load Balance ou Fail-Over Endpoint é um agrupamento lógico de Leaf Endpoints. Um Load Balance ou Fail-Over Endpoint nunca envia uma mensagem diretamente, ao invés de enviar ela delega aos Leaf Endpoints, dependendo da configuração e da situação (status).

Endpoint é uma abstração do servidor remoto, onde o WSO2 Enterprise Service Bus envia a mensagem de saída. Ela pode especificar quais as propriedades usadas para enviar a mensagem, por exemplo, pode especificar o formato - como SOAP 1.1 - ou pode especificar a necessidade de utilizar uma política de segurança com WS Security para responder a mensagem.

WSO2 Enterprise Service Bus Endpoint tem configurações para especificar o comportamento diante de erros, que podem ocorrer entre a WSO2 Enterprise Service Bus e o atual Endpoint.

Um Endpoint tem uma situação, mas antes vamos para as configurações de Endpoint para vermos como as transições acontecem.

Situações do Endpoint

Em alguns momentos a situação do Endpoint pode ser Active, Timeout, Suspended ou Off. A situação de transição do Endpoint normalmente acontece na base de mensagens. E para colocarmos uma situação de Off num Endpoint (utilizando para issoJMX), então esta situação não é a Situação do Diagrama de Transição. Vamos analisar as diferentes situações do endpoint em detalhes:

• Active: O endpoint está ativo e funcionando.
• Timeout: Foram encontrados erros no endpoint, que passa a ser um candidato a ser suspenso, mas pode continuar enviando mensagens. Se os erros persisterem o endpoint será suspenso.
• Suspended: Foram encontrados erros no endpoint e é enviado para a situação onde não pode enviar requisições. Ele não pode enviar mensagens e mensagens recebidas por ele resultarão em falhas.
• Off: O endpoint não está ativo.

Toda situação de transição acontece na mensagem. Por exemplo, se a duração da suspensão é expirada, na situação Suspended, o endpoint continuará na situação Suspensed até que uma nova mensagem chegue e seja bem sucedida.

Toda situação de transição acontece na mensagem. Por exemplo, se a duração da suspensão é expirada, na situação Suspended, o endpoint continuará na situação Suspensed até que uma nova mensagem chegue e seja bem sucedida.

Active

Quando o WSO2 Enterprise Service Bus inicializa, os endpoints estão ativos (na situação Active) e prontos para enviar mensagens. Se o usuário não desligar os endpoints (situação Off), será Active até que ocorra um erro.

Quando ocorrer um erro, o Endpoint poderá ser configurado como: Active, Timeout ou Suspended. Todo erro tem um código. As configurações de Endpoint possibilitam que você defina os erros que colocarão o Endpoint nos modos Timeout e Suspension. Se um erro não foi definido como Timeout ou Suspended, será ignorado.

Os erros são manipulados de três formas:

• Endpoint na situação SUSPENDED
• Endpoint na situação TIMEOUT
• Ignorado e mantido no ACTIVE

Se um erro específico não possui um timeout configurado, então a conexão será fechada e o erro será tratado como TIMEOUT. Todos os outros erros terão o Endpoint colocado como SUSPENDED.

Quando um erro ocorrer no Endpoint, será visto primeiramente se ele é um erro para colocar na situação TIMEOUT. Caso contrário, será verificado se é para colocar na situação SUSPENDED.

Timeout

Nesta situação o Endpoint pode ter na mensagem encaminhada um número máximo de tentativas. Se as falhas persistirem e o número máximo for excedido, o Endpoint será marcado como SUSPENDED. Mas se alguma mensagem for processada o Endpoint será marcado como ACTIVE.

Por exemplo, vamos dizer que o número de tentativas é 3 para esta situção. Se as próximas três mensagens são enviadas usando este Endpoint, e encontramos um erro, o endpoint é colocado como SUSPENDED. Mas se alguma das mensagens anteriores for bem sucedida neste Endpoint, que estava SUSPENDED, ele então será colocado como ACTIVE.

Suspended

Um endpoint suspended não pode ser usado para enviar mensagens. Depois que o endpoint é colocado nesta situação, pode ser tentado novamente após o tempo configurado. Depois deste de passado o tempo de expiração, o WSO2 Enterprise Service Bus tentará encaminhar as mensagens deste endpoint. Se a mensagem for bem-sucedida, então o WSO2 Enterprise Service Bus marcará este endpoint como ACTIVE. Se a próxima mensagem falhar, o endpoint será colocado como SUSPENDED ou TIMEOUT dependendo do erro que ocorrer.

O próximo período é calculado usando a seguinte fórmula:

Next suspension time period = Max (Initial Suspension duration * (progression factor ^{try count}), Maximum Duration)

Todas as variáveis da fórmula acima são valores configurados usados para calcular o número de tentativas (contabilizadas após o endpoint ser marcado SUSPENDED). Com a incrementação do número de tentativas (try count), o próximo período de suspensão (next suspension time period) também será incrementado. O incremento é vinculado a máxima duração (maximum duration).

Configurações do Leaf Endpoint

Esta é a configuração do endereço do endpoint. Uma vez que estamos interessados apenas nas configurações de erros, as mesmas também podem ser aplicadas aos WSDL Endpoints. As configurações de maninpulação de erros são:

1. timeout
2. markForSuspension
3. suspendOnFailure

Vamos ver as configurações individualmente.

<address uri="endpoint address" [format="soap11|soap12|pox|get"]
[optimize="mtom|swa"] [encoding="charset encoding"]
[statistics="enable|disable"] [trace="enable|disable"]>
<enableRM [policy="key"]/>?
<enableSec [policy="key"]/>?
<enableAddressing [version="final|submission"] [separateListener="true|false"]/>?

<timeout>
<duration>timeout duration in seconds</duration>
<action>discard|fault</action>
</timeout>?

<markForSuspension>
[<errorCodes>xxx,yyy</errorCodes>]
<retriesBeforeSuspension>m</retriesBeforeSuspension>
<retryDelay>d</retryDelay>
</markForSuspension>

<suspendOnFailure>
[<errorCodes>xxx,yyy</errorCodes>]
<initialDuration>n</initialDuration>
<progressionFactor>r</progressionFactor>
<maximumDuration>l</maximumDuration>
</suspendOnFailure>
</address>

Timeout

markForSuspension

suspendOnFailure

Exemplo de configuração

<endpoint name="Sample_First" statistics="enable" >
<address uri="http://localhost/myendpoint" statistics="enable" trace="disable">
<timeout>
<duration>60000</duration>
</timeout>

<markForSuspension>
<errorCodes>101504, 101505</errorCodes>
<retriesBeforeSuspension>3</retriesBeforeSuspension>
<retryDelay>1</retryDelay>
</markForSuspension>

<suspendOnFailure>
<errorCodes>101500, 101501, 101506, 101507, 101508</errorCodes>
<initialDuration>1000</initialDuration>
<progressionFactor>2</progressionFactor>
<maximumDuration>64000</maximumDuration>
</suspendOnFailure>
</address>
</endpoint>

Aqui nós mudamos a situação TIMEOUT do endpoint para os erros 101504 e 101505. Depois desse processo, três requisições podem falhar por um ou desses erros antes de alterar a situação do endpoint para SUSPENDED.

Nós colocamos o endpoint em suspensão para os erros 101500, 101501, 101506, 101507 e 101508. Mas como você pode ver, nós ignoramos o erro 101503. Se o erro 101503 ocorrer, o endpoint será marcado como ACTIVE.

Para mais informações sobre códigos de erro, ver APÊNDICE A.

Fail-Over Endpoint

Com essa configuração, se ocorrer um erro durante o processo de transmissão da mensagem, a mesma será perdida. A mensagem que falhou não terá uma nova tentativa de envio. Esses erros ocorrem raramente, mas falhas em mensagens ainda podem ocorrer. Em algumas aplicações essas falhas nas mensagens perdidas são aceitáveis, mas algumas vezes essas falhas não são aceitáveis e o Fail-Over endpoint é a solução ideal.

Abaixo uma configuração para fail-over endpoints. No nível de configuração, um fail-over é um agrupamento lógico de um ou mais endpoints.

<failover>
<endpoint .../>+
</failover>

Quando uma mensagem chega a situação Fail-Over, será atráves da lista de fail-over endpoints que escolherá a primeira situação entre ACTIVE ou TIMEOUT. Então será enviada a mensagem usando esse endpoint. Se ocorrer um erro enquanto a mensagem é enviada, o fail-over, através da lista de endpoints, irá começar novamente e tentará enviar a mensagem usando o primeiro endpoint.

Alguns erros colocam o endpoint na situação TIMEOUT e outros deixam o endpoint com a situação ACTIVE. Nesses casos as tentativas acontecem usando o mesmo endpoint. Se ocorrer um erro com o primeiro endpoint do grupo fail-over e esse erro não colocar o endpoint como SUSPENDED, as próximas tentativas ocorrerão usando o mesmo endpoint.

O fail-over dá a prioridade para o primeiro endpoint que não esteja como SUSPENDED. Então será enviada a mensagem através do primeiro endpoint do grupo fail-over, enquanto não for marcado como SUSPENDED. Quando o primeiro endpoint é marcado como SUSPENDED as requisições serão enviadas usando o segundo endpoint. Quando o primeiro endpoint estiver pronto para ser utilizado novamente, ele tentará de novo, mesmo que o segundo endpoint ainda esteja ativo.

Se houver apenas um serviço endpoint e falhas não são toleráveis, os fail-overs são possíveis com apenas um endpoint.

Abaixo um exemplo de fail-over com um endpoint.

Exemplo de configuração de Fail-Over Endpoint

<endpoint name="SampleFailover">
<failover>
<endpoint name="Sample_First" statistics="enable" >
<address uri="http://localhost/myendpoint" statistics="enable" trace="disable">
<timeout>
<duration>60000</duration>
</timeout>

<markForSuspension>
<errorCodes>101504, 101505, 101500</errorCodes>
<retriesBeforeSuspension>3</retriesBeforeSuspension>
<retryDelay>1</retryDelay>
</markForSuspension>

<suspendOnFailure>
<initialDuration>1000</initialDuration>
<progressionFactor>2</progressionFactor>
<maximumDuration>64000</maximumDuration>
</suspendOnFailure>

</address>
</endpoint>
</failover>
</endpoint>

Nesse exemplo (Sample_First) o endpoint é marcado como TIMEOUT quando a conexão excede o tempo máximo de duração, a conexão é fechada ou envia erros de IO, respectivamente, os códigos de erro: 101504, 101505 e 101500. Para todos os outros erros, será marcado como SUSPENDED. Quando esse erro ocorrer, o fail-over tentará usando o primeiro endpoint que não estiver SUSPENDED, neste caso é o mesmo endpoint (Sample_First). O número de tentativas inicia com a configuração retriesBeforeSuspension e será reduzida a cada mensagem que falhar, até chegar ao zero. É importante notar que a configuração da contagem de tentativas não é por mensagem, mas sim por endpoint.

Nesta configuração nós assumimos que os erros são raros e quando acontecem, basta tentar novamente. Mas se ocorrem frequentemente e continuamente é necessário atenção imediata para que voltem para a situação normal.

Conclusão

A manipulação de erros é crucial para a publicação de endpoints. Os erros devem ser descobertos nos testes, é recomendado executar muitos testes de carga e melhorar a performance das configurações do endpoint preparando-o para os variados erros que podem ocorrer.

Apêndice A

Códigos de erro

Autor

Supun Kamburugamuva, Software Engineer, WSO2, supun@wso2.com

Posts relacionados

• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• WSO2 e a quinta-feira agitada: muitos lançamentos
• WSO2 Enterprise Service Bus (ESB) 2.1.1 lançada
• Lançamento do WSO2 Stratos (alpha)
• Consumindo um serviço seguro utilizando PHP

• Dashboard
• Carbon Data Sources
• Array type
• Default values in input mappings
• Data Validation Logic
• WIP services
• Contract first
• Batch mode
• Boxcarring
• Eventing
• Binary Input/Output data
• JMX
• Query Properties
• Conclusão

Dashboard

Com a atualização para o WSO2 Carbon 3.0, foi implantando um Dashboard que pode conter informações variadas. Essas informações podem ser personalizadas utilizando gadgets. Aliás, essa atualização pode ser notada em toda a suíte que utilizam o novo Carbon.

Carbon Data Sources

Agora ficará muito mais fácil gerenciar conexões às várias base de dados. Com Carbon Data Sources, será possível apontar no Data Service qual data source utilizar, e cada ambiente (teste, desenvolvimento, homologação ou produção) terão suas próprias configurações, bastará manter o mesmo nome.

Array Type

Poderemos ter entradas do tipo array ou scalar, onde essas entradas podem conter valores de diferentes tipos, como: string, integer, real, double, numeric, tinyint, smallint, bigint, date, time, timestamp, bit, oracle ref cursor ou binary.

Default values in input mappings

No caso do tipo de entrada scalar, poderá ser indicado um valor padrão para a entrada.

Data Validation Logic

Os dados de entrada poderão ser validados utlizando alguns validadores padrões:

• Long Range: com mínimo e máximo de opção;
• Double Range: com mínimo e máximo de opção;
• Length: com mínimo e máximo de opção;
• Pattern: com pattern de opção;
• Custom: com a classe de opção.

WIP Services

Os serviços que ainda não estão finalizados, estão passando por correção ou qualquer outro motivo, poderão ser marcados como: "Work in progress". Isso evitará erros e os clientes não conseguirão consumir o serviço.

Contract first

Com essa funcionalidade, criar data services poderá fica ainda mais simples. Basta adicionar um contrato (WSDL) com todas as definições e ele criará um WIP Service para você, sendo necessário apenas você configurar conexões e preencher as queries.

Batch mode

Um recurso bastante interessante implementado é o Batch Mode, esse recurso implementa automaticamente, em todos os métodos que realizam alguma função de escrita no banco de dados (INSERT, DELETE e UPDATE), o recurso de invocar uma única vez o serviço, mas realizando operações em vários objetos de uma única vez, como - por exemplo - um inserir uma listagem de pessoas.

Boxcarring

Implementação importante para essa nova versão, boxcarring nada mais é que o suporte a transações nos serviços, pelas informações coletadas, essa transação pode ser de dois tipos: SOAP ou Transport.

Eventing

Será um recurso que dará a opção de implementarmos eventos em cima de determinadas operações, funciona basicamente como uma trigger de banco de dados.

Binary Input/Output Data

Será possível utilizar dados binários (tipo Base64) tanto para enviar, quanto para receber.

JMX

O WSO2 Data Services Server proverá informações dos serviços publicados, utilizando Java Management Extensions (JMX).

Query Properties

As queries podem ter algumas propriedades específicas na execução, ajudando na questão de performance e limitações.

Conclusão

Essas novas versões que estão para sair, da suíte WSO2 Carbon (3.0) e WSO2 Data Services Server (2.5.0), evoluíram bastante comparativamente as suas sucessoras. E o que é bem importante, não foi necessária nenhuma alteração para os serviços que rodam na versão 2.2.1 do WSO2 Data Services Server funcionarem nessa release, diferentemente da atualização da versão 2.0.x para a 2.2.x.

Os tópicos que não documentei ainda, provavelmente consiga documentar nas próximas releases, ou quando achar aonde estão esses recursos, a não ser que as alterações sejam internas e não fiquem visuais pra nós. Caso queira ajudar a encontrar e documentar todas as alterações, pode acessar o repositório com os builders (com gerações quase que diárias).

Minha ideia é também exemplificar como utilizar cada uma delas futuramente, para que não fique dúvidas de como utilizar esses novos recursos. Então, fique ligado nas atualizações pelo feed.

Posts relacionados

• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• Compilando o WSO2 Carbon 3.0.0 e corrigindo o WSO2 Data Services Server 2.5.0
• Utilizando o Array Type do WSO2 Data Services Server 2.5.x
• WSO2 e a quinta-feira agitada: muitos lançamentos
• WSO2 Business Activity Monitoring + SQL Server

Mas como migramos toda a suíte para rodar sobre o SQL Server, configurei tudo para apontar para o banco de dados do WSO2 Governance Registry (arquivo conf/registry.xml) e do WSO2 Identity Server (arquivo conf/user-mgt.xml) - maiores explicações ficam para uma outra oportunidade.

Só que ainda ficou uma dúvida no ar! Aonde estavam as configurações de conexão de banco de dados que armazenam as informações do BAM propriamente dito? Pesquisando nos arquivos instalados encontrei um diretório "bam", e para minha não-surpresa, lá estavam mais dois diretórios:

• ./bam/database/: diretório com arquivos da base de dados do H2;
• ./bam/sql/: scripts de criação da base de dados em diferentes bancos (H2, SQL Server, MySQL e Oracle).

Com essa descoberta, o jeito foi partir para o básico, buscar um arquivo de configuração que pudesse conter a conexão apontando para esses arquivos.

leonardo@mcorp:~/Applications/wso2/wso2bam-1.0.1$ grep -r h2:database *
conf/registry.xml:        jdbc:h2:database/WSO2CARBON_DB
conf/user-mgt.xml:		jdbc:h2:database/WSO2CARBON_DB

Ops, não encontrei nada. Nova tentativa:

leonardo@mcorp:~/Applications/wso2/wso2bam-1.0.1$ grep -r h2 *
[milhões de respostas - ocultadas por mim - que não ajudam em nada]

Vamos lá, filtrar um pouco mais para quem sabe ser mais feliz:

leonardo@mcorp:~/Applications/wso2/wso2bam-1.0.1$ grep -r jdbc:h2 *
conf/registry.xml:        jdbc:h2:database/WSO2CARBON_DB
conf/user-mgt.xml:		jdbc:h2:database/WSO2CARBON_DB
repository/dataservices/BAMSummaryGenerationDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMConfigurationDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMStatQueryDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMDataCollectionDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMSummaryQueryDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB

E agora sim! Com isso descobrimos que ele utiliza alguns data services que realizam o trabalho "sujo".

Então, basta alterarmos todos esses serviços para conectarem na base de dados criada no SQL Server (dentro de cada serviço tem exemplos). Os serviços são:

• repository/dataservices/BAMSummaryGenerationDS.dbs
• repository/dataservices/BAMConfigurationDS.dbs
• repository/dataservices/BAMStatQueryDS.dbs
• repository/dataservices/BAMDataCollectionDS.dbs
• repository/dataservices/BAMSummaryQueryDS.dbs

E carregar o arquivo bam/sql/bam_schema_mssql.sql na base de dados e... voilà.

INFO -  Server  :  WSO2 Business Activity Monitor-1.0.1
INFO -  WSO2 Carbon started in 6 sec

Os estudos sobre o WSO2 Business Activity Monitoring continuarão num próximo capítulo, sempre acompanhado de dicas e descobertas. (:

Posts relacionados

• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• Lançamento do WSO2 Stratos (alpha)
• Utilizando o Array Type do WSO2 Data Services Server 2.5.x
• Compilando o plugin do WSO2 Data Services Server para o Eclipse
• WSO2 e a quinta-feira agitada: muitos lançamentos

Só que pouco tempo depois de configurar e entregar ao cliente o serviço, veio o problema: como consumir em PHP o serviço? No artigo a solução entregue por eles para consumo é em Java, como a capacidade do cliente deixa a desejar, fiquei de fazer e enviar um exemplo de consumo do serviço desenvolvido.

Então... mãos na massa!

Configurando a ESB

Nesse ponto não irei escrever passo-a-passo a configuração que deve ser feita, o trabalho realizado pelo pessoal do WSO2 está muito bem feito nessa parte do artigo: Step 4 – Enable User Authentication for the Data Service.

Consumo sem segurança

Um pequeno trecho de PHP que mostra como consumir o serviço sem nenhum tipo de segurança. Código pequeno, limpo e objetivo.

$client = new SoapClient("http://localhost:8280/services/Tutorial?wsdl");
try {
$obj = $client->searchProductsByGroupId(array("group_id" => 1));
print_r($obj);

} catch (Exception $e) {
echo "ERRO: " . $e->getMessage();
}

Mas mesmo com toda essa objetividade, o problema do cliente não estava resolvido e eu recebia o seguinte erro:

ERRO: SOAP header missing

E, para resolver, faltava adicionar o cabeçalho com os dados de segurança.

Consumo com segurança

Agora um não-tão-pequeno trecho em PHP.

// configurações de conexão
$username = "admin";
$password = "admin";
$created = date ("Y-m-d\TH:i:s", mktime (date("H"), date("i"), date("s"), date("m"), date("d"), date("Y")))."Z";

// definição de namespaces
$ns = 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd';
$wsu = 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd';

// criando elemento UsernameToken
$token = new stdClass;
$token->Username = new SOAPVar($username, XSD_STRING, null, null, null, $ns);
$token->Password = new SOAPVar($password, XSD_STRING, null, null, null, $ns);

// criando elemento Timestamp
$timestamp = new stdClass;
$timestamp->Created = new SOAPVar($created, XSD_STRING, null, null, null, $wsu);

// criando elemento Security
$wsec = new stdClass;
$wsec->UsernameToken = new SoapVar($token,     SOAP_ENC_OBJECT, null, null, null, $ns);
$wsec->Timestamp     = new SoapVar($timestamp, SOAP_ENC_OBJECT, null, null, null, $wsu);

// criando header
$headers = new SOAPHeader($ns, 'Security', $wsec);

// construtor do web-service (com cabeçalho) passando o endereço do WSDL
$client = new SoapClient("http://localhost:8280/services/Tutorial?wsdl");
$client->__setSOAPHeaders($headers);

// chamada do método
try {
$obj = $client->searchProductsByGroupId(array("group_id" => 1));
print_r($obj);

} catch (Exception $e) {
echo "ERRO: " . $e->getMessage();
}

E tudo rodou normalmente, sem problemas, o cliente ficou feliz e eu matei um pouco da saudade de programar em PHP.

Na pesquisa por soluções, tentei utilizar o WSO2 Web Services Framework for PHP mas descobri que depende de instalação de módulo no Apache e não servia para meu cliente, mas anotei na pauta para testá-lo em outro momento.

Posts relacionados

• Compilando o WSO2 Carbon 3.0.0 e corrigindo o WSO2 Data Services Server 2.5.0
• Instalando o WSO2 Web Services Framework for PHP (2.0.0)
• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• WSO2 e a quinta-feira agitada: muitos lançamentos
• Lançamento do WSO2 Stratos (alpha)

Free Book: SOA Adoption for Dummies (somente em inglês)

Você pode realizar o download dele por este link: SOA Adoption for Dummies.

Posts relacionados

• Utilizando o Array Type do WSO2 Data Services Server 2.5.x
• SOA está para WSO2 ou WSO2 está para o SOA?
• Promoção: Livro Shell Script
• Compilando o WSO2 Carbon 3.0.0 e corrigindo o WSO2 Data Services Server 2.5.0
• Lançamento do WSO2 Stratos (alpha)

Mas como nem tudo são flores, após eu instalar o plugin e tentar criar um novo endpoint, recebi o erro abaixo:

Unhandled event loop exception
XPCOM error -2147467259

Com isso, passei um certo tempo procurando na internet, até descobrir que o erro é causado por falta da biblioteca libstdc++5, que no Ubuntu Karmic Koala (9.10) foi atualizada para libstdc++6. Versão que é incompátivel com a visualização embarcada do Mozilla que o Eclipse WTP utiliza.

Então, para resolver o problema, primeiro passo que tentei foi:

$ sudo apt-get install libstdc++5
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libstdc++5 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package libstdc++5 has no installation candidate

Só que não resolveu, a maneira que encontrei foi procurar a biblioteca para download, encontrei no site do Debian:

wget http://ftp.br.debian.org/debian/pool/main/g/gcc-3.3/libstdc++5_3.3.6-18_i386.deb

E instalei:

sudo dpkg -i libstdc++5_3.3.6-18_i386.deb

E com esses passos, tudo funciona normalmente...

Posts relacionados

• Compilando o plugin do WSO2 Data Services Server para o Eclipse
• Lançamento do WSO2 Stratos (alpha)
• Instalando o WSO2 Web Services Framework for PHP (2.0.0)
• WSO2 Enterprise Service Bus – Manipulando erros em Endpoints
• Consumindo um serviço seguro utilizando PHP