Subversion: O que acontece com o espaço em disco do servidor SVN ao criar Branch, Tag e Revisions?

Hoje comecei o dia batendo um papo sobre como o Subversion trata a questão do armazenamento de espaço em disco ao criar diferentes Revisions, diferentes Tags e diferentes Branches. Então resolvi registrar nesse post as conclusões e comparações que fiz entre o Subversion e o CVS.

Internamente para o Subversion, Branches e Tags são a mesma coisa. Então, o que vou comentar vale para ambos, ok?

Quando um arquivo é incluído em um repositório e sofre modificações, o Subversion armazena apenas o “diff” entre as versões e não 2 vezes o arquivo inteiro. Nesse caso não se gasta espaço desnecessariamente no lado do servidor.

Na criação de Branches e Tags, o Subversion usa “hard links“. Então, não há duplicação de conteúdo no lado do servidor, o que economiza espaço. Esse é o conceito de “Cheap copies” que o Subversion possui.

O mesmo vale para arquivos binários.

Quem trabalha com Scrum e está na dúvida se deve, por exemplo, criar Branches por Sprints ou um bracnh mais genérico de “desenvolvimento”, parece que o genérico não é a melhor escolha. Isso se você estiver pensando em fazer merges (reintegrate) mais de uma vez a partir do mesmo branch para o trunk. Aqui vale a mesma preocupação que usuários do CVS tinham ao fazer múltiplos merges de um mesmo branch para o trunk. Então, embora possível, a gestão fica mais complicada e por isso a documentação do Subversion recomenda evitar fazer isso. É mais simples, após o merge, criar um novo branch ao invés de continuar o trabalho no branch antigo.

Durante os vários anos que trabalhei com o Subversion eu fazia o mais complicado, ou seja, múltiplos merges de um mesmo branch para o trunk. Isso tinha uma razão, que escreverei em um novo post.

Até lá!

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:

• WS – Security Framework
• Http Basic Authentication
• SAML – Security Assertion Markup Language

Data layer:

•  XML Encryption
• XML-Digital Signatures

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

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