Garantia de Entrega – Design Patterns


Quando nos deparamos com cenários de integrações onde não podemos nos dar ao luxo de perdermos alguma mensagem devido a eventuais problemas de conectividade, diponibilidade ou de qualquer outro tipo, dizemos que esta integração deve ter garantia de entrega das mensagens que são trafegadas, e para endereçar esta questão existem alguns design patterns, e 2 dos mais comuns são:

Guaranteed Delivery:

Este pattern está associado muito ao processo de store-and-foward, ou seja para prevenir que a mensagem se perca, persistimos em disco ou em banco a mensagem antes de seguir para um próximo passo do processo que tenha potencial de falha. O código da integração ou serviço pode ter a responsabilidade de persistir as mensagens, mas não é o ideal, pois geralmente as próprias ferramentas de integração ou servidores de mensageira já possuem esta funcionalidade.

No tibco por exemplo, além de usar o checkpoint, onde o próprio BW persiste o estado do processo, e obviamente as mensagens que estão sendo trafegadas, temos uma forma mais elegante de implementarmos este pattern, que é uma funcionalidade do EMS, onde podemos configurá-lo para que todo subscritor e publicador tenham uma fila local e que o ems se encarregue de copiar a mensagem da fila local do publicador para a fila local do subscritor e enquanto não conseguir isto, a mensagem permanece na fila esperando retentativas de envio por parte do EMS até que a mensagem expire (se a expiração tiver configurada). Esta configuração é feita configurando a propriedade Delivery mode da task JMS Queue Sender com o valor Persistent, como sugere a imagem abaixo:

Durable Subscriber:

Quando o cenário de integração envolve vários subscritores, e todos precisam receber todas as mensagens publicadas, preferimos usar tópico ao invés de fila por justamente a diferença entre eles ser a gestão que o servidor de mensageira implementa, relativa a fazer com que a mensagem permaneça no tópico até todos os subscritores conectados ao a ele recebam a mensagem, e então logo depois remove a mensagem do tópico.

Mas esta gestão está baseada nas conexões ativas originadas dos subscritores no momento que a mensagem é publicada, e isto quando pensamos em garantia de entrega é uma brecha para falhas. Imagine um cenário onde os N subscritores tem que ficar conectados ao tópico, esperando mensagens 24/7, mas por uma questão qualquer a conexão é perdida e alguns segundos depois é restabelecida ou até a máquina do subscritor cai e volta depois de um tempo, sendo que uma mensagem é publicada neste mesmo periodo. Se isto ocorrer o subscritor que ficou indisponível perderá as mensagens que foram publicadas neste periodo.

O Pattern Durable Subscriber tem como objetivo tirar esta brecha de falha, fazendo com o servidor de mensageria registre os subscritores e não dependa mais de suas conexões estarem ativas ou não com ele.

No tibco para tornar um subcritor durável é necessário apenas marcar a checkbox de Durable Subscription nas configurações do subscritor, como sugere a imagem abaixo:

SOA Security


Many companies that start walking on the SOA road, end up stumbling upon Security requirements related to the use of the enterprise webservices.

So before choosing security solutions/tecnologies the first 2 things you must ask yourlself are:

  1. What  is critical to buisness and need to be protected?
  2. If i was a bad guy what would i try to exploit and get advantage or create problems for the enteprise?

Probably the awsers to these questions will drive you to choose which of the security concepts you will use on your solution.

Here are the default security concepts you probably will have to address:

Identification : Who receives the message should have a way to identify who sent it

Autentication : Who receives the message needs to check that the sender´s identity  is valid

Authorization: Who receives the message need to know what´s the sender´s acess level.  This can be related with which operations and data are being will be acessable to the sender.

Integrity: The message remains the same during the transmission and arrival to the recipient.

Confidentiality: The message content can not be seen while is being transmitted, with excteption of authorized service.

After selecting which of these concepts you’ll need, its time to choose the best security tecnology that fit your requirements.

The following are some links to examples of such tecnology that can be applied to different architecture layers.

Transport Layer:

  • SSL – Secure Socket Layer
  • TLS – Transport Layer Security
Application layer:
Data layer:
On the next post I will deeply discuss some of these solutions.
Http Request
Get /taas/autor/carlosfilho HTTP/1.1
Http Response
HTTP/1.1 410 Gone

Governança SOA e Kanban


Não é novidade para ninguém que ao seguir uma estratégia de construção de uma Arquitetura Orientada à Serviços em qualquer empresa é necessário endereçar o tema governança soa. Isto acontece devido ao seguinte fato: Não existe mágica!

Toda empresa tem como objetivo aumentar sua margem de lucro e uma das formas de alcançar este objetivo é maximizando o retorno em cima dos investimentos feitos ao comprar ou construir um ativo. E SOA justamente vem para nos ajudar nesta tarefa, com a orientação a serviço começamos a construir diversos serviços atomicos, granulares que ficam disponíveis em um repositório corporativo e que podem atender diversos propósitos diferentes de negócio, por meio da composição do mesmos e outros ativos da empresa. E é neste ponto que as pessoas se iludem e esperam por um truque de mágica, o que acontece é que cada vez mais são feitas ligações entre serviços, dados, aplicações e outros ativos, o que pode sugerir complexidade. Mas isso é bom, pois estamos maximizando o retorno em cima do investimento feito, lembram?

Bom, mas para não criarmos complexidade em demasia, causar confusões e aumentar o custo com operação, precisamos manter este repositório de ativos bem organizado, disponível para toda empresa, e uma parte crucial, que é o foco deste post, os ativos devem estar aderentes aos processos e requisitos de negócio, diretrizes técnicas, de qualidade, segurança, devem ter documentações relativas a implantação, manutenção e uso. E para atender a todos estes pontos é necessário um processo bem definido, com artefatos obrigatórios, papéis, e etapas que endereçem todos os pontos mencionados anteriormente.

O caminho comum de toda a empresa é procurar um software que suporte este processo. Mas existe uma solução alternativa, que está muito aderente ao cenário atual em que várias empresas se encontram, que é o de ter um pensamento Lean e fazer uso de metodos agéis. Esta alternativa é bem mais barata e que dependendo da disciplina do time pode ser bem mais eficaz que um software. Estou falando do Kanban. Para quem não conhece, Kanban segundo Wikipedia

E seguindo na mesma linha em que os sábios do google pregam a muito tempo de experimentar, errar rápido, e baseado nos dados concretos oriundos da experiência evoluir a solução e acertar, criamos em minha empresa uma primeira versão de um quadro Kanban. Ele contempla todo o ciclo de vida de um serviço, desde a análise de uma demanda/projeto e identificação de um serviço até o seu deploy. Cada fase do ciclo de vida vira uma etapa do processo, e consequentemente uma coluna no quadro. Adicionamos também etapas/colunas que são passos de aprovação, QA e acompanhamento pós deploy. Uma ação que está agregando valor,  foi definição de “critérios de pronto” para cada etapa, ou seja, um serviço só sai da fase de modelagem e vai para fase de construção se alguns artefatos forem entregues como por exemplo os cenários de teste e o contrato do serviço.

Um benefício interessante de utilizar o quadro é que temos um “modelo mental coletivo e colaborativo” que fica mais fácil de todos do time seguirem, guardarem e contruibuirem para a evolução do mesmo.Ele ainda  nos ajuda a focar no que é necessário e agrega mais valor para o negócio (Lean) e ainda no momento que é necessário, seguindo a filosofia do just in time.

Se tiverem experiências parecidas com Governança SOA e Kanban ou outras filosofias e metódos ageis, por favor compartilhem!

Http Request
Get /taas/autor/carlosfilho HTTP/1.1
Http Response
HTTP/1.1 410 Gone

Contrato de Serviços REST


Ao longo das últimas semanas venho pesquisado e análisado várias abordagens diferentes sobre como implementar serviços seguindo o estilo REST, e fiquei muito intrigado em como descrever ou não a sua interface e os dados associados a eles.

Pois então, logo que me deparei com REST, tive a impressão de que as pessoas preferiam implementar serviços onde suas mensagens eram Json, pura e simplesmente por não entenderem de fato XML e quererem fugir de qualquer coisa que remeta ao wsdl e XML Schema dos Webservices. Infelizmente para muitos o wsdl é apenas um arquivo que você utiliza passar ao framework de webservices  para poder se comunicar com o serviço, mas de fato não sabem o que ele contém e que de fato ele é um contrato, ou seja, que funcionalidades este serviço te oferece, como interagir com elas, quais as restrições e onde está este serviço.

Mas depois lendo mais relatos e conversando com outros profissionais da área, pude perceber que minha primeira percepção não estava errada mas também que estas pessoas citadas acima são apenas parte das pessoas que apoiam REST e Json.  De fato a combinação dos 2 pode trazer muitos benefícios, como por exemplo simplicidade e performance. O que de fato ainda não me deixa ficar tranquilo são as implementações de serviços que recebem e respondem mensagens em Json mas não tem um contrato de dados. Por exemplo, uma solução para isso seria o uso de JSON Schema, que pode ser usado para garantir que as mensagens estejam formatadas de acordo com o que o serviço se propoe a fazer e ainda pode e deve ajudar o cliente na hora de consumi-lo.  Acredito que quando os validadores de Json ficarem mais maduros esta será uma boa prática. Por em quanto o XML Schema ainda ganha quando nos preocupamos com contrato de dados.

Outra questão que vale a pena comentar é a do uso de WSDL para descrever serviços REST. Então.. depois ler uma parte específica sobre WSDL 2.0 Bindings do livro “Web Service Contract Design & Versioning – Thomas Erl”l, fiquei cada vez mais interessado nesta abordagem e pouco tempo depois um caso específico me chamou muita atenção (Ebay). Eles resolveram que para cada serviço que estava no repositório corporativo, deveria ter um WSDL com a usual definição de dados em XML Schema, mas sempre ter 2 bidings definidos, um para SOAP e outro para HTTP. Ou seja, aquela mesma funcionalidade poderia ser consumida usando mensagens SOAP quanto requests HTTP “puros”, utilizando os métodos/verbos HTTP.

De positivo que me salta aos olhos são a flexibilidade na forma de consumir o serviço, e a oportunidade desta decisão ser tomada caso a caso e não em tempo de definição do serviço. Agora se você ler um pouco sobre o que é REST e refletir sobre este assunto, você se depara com uma questão que incomoda a quem defende REST que inclusive eu mencionei no post anterior. Já que o serviços REST tem uma interface padrão, URI + HTTP Verbs, faz apenas sentido definir os dados que serão recebidos e enviados do serviço.

Bom estes foram alguns pensamentos sobre REST, Json, e Contrato de dados.
Opine! Comente! Compartilhe!

Qual a diferença entre REST e SOAP?


Bom, vamos lá.. Quem é que nunca leu algum artigo, presenciou ou de fato iniciou uma discussão sobre REST e SOAP? Acho que muitos.. certo?!

Então… Logo após de ler o título deste post você deve estar se perguntando “Esse cara vai ser mais um desses que fica defendendo um lado e detonando o outro com argumentos esquerdistas e radicais?” De ante mão te respondo: “Não!”. Minha intenção com este post é apenas explicar um pouco sobre o assunto e tentar desfazer algumas confusões que as pessoas fazem com REST, SOAP e outros assuntos adjacentes.

Antes de mais nada, vamos a definição básica destes dois:

REST – Representational State Transfer é um estilo arquitetural usado no projeto de aplicações da Web que contam com recursos nomeados (URL,URI,URN) e engenhosamente utiliza mais profundamente o protocolo HTTP, seu cabeçalho , seus métodos (GET, POST, PUT, DELETE, HEAD) e toda a infraestrutura web já bem estabelecida, reconhecida e utilizada por todos.

SOAP – Simple Object Access Protocol é um protocolo para troca de informações estruturadas geralmente em uma plataforma descentralizada e distribuída. Ele se baseia em XML para seu formato de mensagem, ou seja, uma mensagem SOAP encapsula o conteúdo e pode ser trafegada via HTTP, JMS ou outro protocolo.

Se você, por um acaso, antes de ler este post achou que SOAP tinha alguma coisa a ver com sabão e REST com descanso.. você precisa ler mais. 😛

Brincadeiras à parte…, vamos a algumas questões que são importantes nesta discussão.

1 – Definição de interfaces

Primeiramente, pensando em serviços que utilizam mensagems no protocolo SOAP, o mais comum é descrevermos a interface do mesmo com WSDL (Web Services Description Language). Basicamente, cada serviço terá um arquivo .wsdl que terá a definição de suas operações, estrutura de dados que são usadas nas requisições e respostas, Endpoints (endereços de rede do serviço). Uma associação que ajuda o entendimento deste ponto é pensarmos nas operações como métodos de uma classe, a assinatura do método como as mensagens definidas, e o tipo de cada campo da assinatura a definição da estrutura de dados que será usadas nas mensagens.

Agora, nos serviços RESTful, se seguirmos de fato o estilo, parte da descrição da interface é desnecessária já que a forma de interagir com os serviços é sempre a mesma , por meio dos métodos http. E ainda mais com o uso do Método Option podemos saber quais outros métodos são permitidos naquele serviço. Agora com relação aos dados continua a ser interessante a definição de que dados vão trafegar e suas restrições.

Agora, tem pessoas que mesmo assim preferem de uma definição tanto dados quanto de operações, e estas podem fazer o seguinte:

a) Criar um documento para ser lido por humanos que pode conter, por exemplo, a estrutura de dados que seu serviço recebe e responde, lista de quais operações HTTP estão sendo suportadas naquele serviço, qual formato de mensagem é suportado, etc.. Na minha opinião, esta abordagem faz mais sentido quando a estrutura de dados da mensagem é simples e/ou utiliza notações simples como JSON por exemplo, devido a facilidade da implementação do código que irá acessar ao serviço.

b) A segunda forma, é utilizar o WADL(Web Application Description Language), ele é similar ao WSDL só que mais simples, com artibutos de configuração que facilitam a compreensão, por exemplo, de qual notação/formato é utilizada nas mensagens de request e response, e o mais importante, é todo orientado aos recursos e ao protocolo HTTP.

Obs:
WSDL e WADL serve para que aplicações clientes/consumidoras possam gerar o código automaticamente a partir destas definições. No entanto, nada impede que trasnformações .XSL sejam aplicadas a estes arquivos e eles fiquem mais “legíveis” para leigos, afinal os dois são XML com schema e com vocabulário bem definido.

2 – SOAP e SOA

Preciso começar este tópico com uma frase clássica, “uma coisa é uma coisa outra coisa é outra coisa”. Nem adianta falar que a diferença entre SOAP e SOA é a letra “P” essa já está velha.

Primeiro, SOAP é um protocolo para troca de informações estruturada, como vimos no início deste post. SOA, por sua vez, é uma arquitetura que se baseia no paradigma de orientação a serviço que molda o desenvolvimento de funcionalidades de negócio, buscando desacoplamento, reutilização, produtividade e alinhamento entre objetivos de negócio e as estratégias de TI. (SOA Manifesto)

Além do nome ser parecido, o que faz com que as pessoas troquem um pelo outro em conversas, e leigos que estão escutando multiplicarem esta confusão por aí…, existe também uma questão relacionada tanto aos big vendors de ferramentas, quanto aos consultores tradicionais atrelados à SOA, que focam muito em Web services, WSDL, WS-* Extensions e SOAP. Ainda tem o fato adicional de que a maioria deles estão engatinhando em REST. Ou seja…, tem muitos profissionais de TI, inclusive que se dizem entendidos de SOA, que acham que para se ter uma Arquitetura Orientada a serviço precisamos de Webservices, WSDLs e SOAP, o que está 100% errado.

3 – Algumas questões que podem desfazer algumas amarras entre estes conceitos

a) Podemos ter uma empresa com uma maturidade elevada em SOA, apenas com serviços RESTful? SIM!

b) Podemos ter serviços RESTful com a interface descrita com WSDL.? SIM! É! com WSDL.. WSDL foi criado para descrever interfaces e tem uma boa flexibilidade, podemos usar SOAP sobre HTTP, ou simplesmente HTTP com mensagens em formato JSON, ou XML. (obs: Apartir do WSDL 2.0 isto ficou mais fácil.)

c) Podemos ter serviços disponíveis em HTTP e não serem serviços REstful? SIM! Formas de utilizar o cabeçalho HTTP, como modelar as URLS, e usar operações GET, POST, PUT, DELETE entre outras coisas vão determinar se o serviço é RESTful ou não.

4 – SOAP ou REST ?

Podemos elencar alguns pontos interessantes:

Rest
– É mais elegante, pois utiliza ao máximo o protocolo HTTP, evitando a construção de protocolos adicionais
– Tem o potencial de ser bem mais simples que uma implementação com WSDL/SOAP
– Tende a ser mais performático
– ~ 80% das integrações utilizam o protocolo HTTP.
– A possibilidade de ter difersças representações de um mesmo recurso, por exemplo, uma dada entidade pode ser representada em diferentes formatos como Json, xml, html e text/plain, dependendo da requisição feita pelo cliente(Content-Negotiation)
– Possibilidade de navegar entre relacionamentos (Links web) de vários recursos de forma dinamica. seguindo a usabilidade de qualquer sistema web. HATEOAS (Hypermedia as the Engine of Application State).

SOAP
– É um padrão que combinado a as especificações WS-* podem garantir questões de QoS(Quality of Service), Segurança, transação e outras questões presentes em integrações mais complexas.
– Uma mensagem SOAP pode ser propagada por diferentes protocolos, o que flexibiliza bastante várias integrações.
– É um padrão que está muito maduro no mercado, qualquer ferramenta de integração e Framework tem várias funcionalidades para manipular as mensagens que seguem este padrão.

Com certeza existem muitos outros pontos a serem levantados, mas de qualquer forma.. Minha resposta para a pergunta tão popular “Qual o melhor?” seria “Depende”.. depende de qual problema você quer resolver.

Particularmente, acredito que cada demanda tem que ser analisada, com calma, por pessoas que conheçam as 2 abordagens e possam chegar a uma solução adequada ao problema em questão. Isto me faz lembrar de um artigo que o Marcelo Fernandes(companheiro de equipe), me encaminhou há algum tempo que falava sobre uma metodolia ágil muito extremista mas que tinha uma frase interessante.. algo como “Tudo aquilo que você considera verdade, está errado em algum contexto” ou seja, achar uma solução antes de entender o problema é algo que pode funcionar algumas vezes, mas tem um risco, e com certeza em algum, ou vários contextos aquilo não irá se aplicar.. então.. analise cada caso e tire proveito de cada um dos dois.

Abraços,

Carlos Alberto Filho