How to install jUDDI on Tomcat by yourself


Hi!

This week I had to install Apache jUDDI for the purpose of the “Knowledge Organization and WEB 3.0” class which is one of my Master’s degree disciplines at PPGI-UFRJ.

When I went to jUDDI‘s web site I discovered that jUDDI have a embeded Apache Tomcat within it. No problem if I hadn’t already installed Tomcat.

Since I wouldn’t like to have 2 running Tomcat installations I decided to install and deploy jUDDI in my existing Tomcat installation. After a few searches in Google I could not find someone who have already done it. That’s why I decided to write this (not so comprehensive) instructions.

Well, since I have already had a running Tomcat installation you will have to install it. It’s very easy. You can find a lot of HOW TOs around. Therefore, I consider the following prerequisites for my step-by-step installation instructions of jUDDI.

Prerequisites:

Having properly installed and configured Java and Tomcat we can now start with the other jUDDI‘s prerequisites.

Step 1 – Install MySQL and create a database for jUDDI
  1. Download and install MySQL Community Server 5.5.14. Choose the MSI installer version;
  2. Now let’s create a user and a database for jUDDI…
  3. Execute the MySQL Command Line Client (It’s in Windows’ Program menu);
  4. Execute these 3 commands: “CREATE USER ‘juddi’@’localhost’ IDENTIFIED BY ‘juddi’;“, “CREATE DATABASE juddi;” and “GRANT ALL PRIVILEGES ON juddi.* TO ‘juddi’@’localhost’;“;
Step 2 – Deploy Apache jUDDI
  1. Download jUDDI portal bundle 3.0.4 and unzip it. Although this zip have an embeded Tomcat installation we won’t use it. We’ll need jus some webapps inside it.
  2. Copy the juddiv3, pluto and juddi-portlets folders (they are located inside the webapps folder in the zip file) to Tomcat‘s webapps folder. Again, just as a reference my webapps folder is in C:\Program Files\apache-tomcat-6.0.29\webapps;
  3. Also copy the following libraries from your zip’s juddi-portal-bundle-3.0.4\lib folder to your existing C:\Program Files\apache-tomcat-6.0.29\webapps folder:
    • castor-1.1.1.jar
    • commons-discovery-0.2.jar
    • commons-logging-1.1.jar
    • pluto-container-1.1.7.jar
    • pluto-descriptor-api-1.1.7.jar
    • pluto-descriptor-impl-1.1.7.jar
    • pluto-taglib-1.1.7.jar
    • portlet-api-1.0.jar
    • log4j-1.2.13.jar
Step 3 – Configure MySQL JNDI Resources in Tomcat
  1. Download MySQL Connector/J 5.1.17 (the official JDBC driver for MySQL) and unzip it. Find the mysql-connector-java-5.1.17-bin.jar file and copy it to the lib folder of your existing Tomcat installation. My Tomcat‘s lib is in C:\Program Files\apache-tomcat-6.0.29\lib;
  2. Open the file C:\Program Files\apache-tomcat-6.0.29\webapps\juddiv3\META-INF\context.xml with any text editor and edit it in order to look like this…
      • <?xml version=”1.0″ encoding=”UTF-8″?>
      • <Context>
      • <WatchedResource>WEB-INF/web.xml</WatchedResource>
      • <Resource
      • name=”jdbc/juddiDB
      • auth=”Container” 
      • type=”javax.sql.DataSource” 
      • username=”juddi” 
      • password=”juddi” 
      • driverClassName=”com.mysql.jdbc.Driver” 
      • url=”jdbc:mysql://localhost:3306/juddi”
      • />
      • </Context>
  3. Now a very important thing. There are 3 other files that must be in synch with the context.xml. The resource name juddiDB must be present in the following files relative to C:\Program Files\apache-tomcat-6.0.29\webapps\juddiv3\WEB-INF\:
    • .\web.xml: Set the value of <res-ref-name> as jdbc/juddiDB;
    • .\classes\juddiv3.properties: Set the property juddi.persistenceunit.name with value juddiDB;
    • .\classes\META-INF\persistence.xml: Set the persistence-unit‘ name to juddiDB, set <non-jta-data-source> value to java:comp/env/jdbc/juddiDB and make sure there is a <property name=”openjpa.jdbc.DBDictionary” value=”mysql“/> element in it.

Step 4 – Add users and roles to Tomcat

  1. Open C:\Arquivos de programas\apache-tomcat-6.0.32\conf\tomcat-users.xml and make sure it looks like this one:

<?xml version=’1.0′ encoding=’utf-8′?>
<tomcat-users>
<role rolename=”pluto“/>
<role rolename=”tomcat”/>
<role rolename=”manager”/>
<user username=”root” password=”root” roles=”pluto,tomcat,manager”/>
<user username=”uddi” password=”uddi” roles=”pluto,tomcat,manager”/>
<user username=”sales” password=”sales” roles=”pluto,tomcat,manager”/>
<user username=”marketing” password=”marketing” roles=”pluto,tomcat,manager”/>
<user username=”tomcat” password=”tomcat” roles=”manager”/>
</tomcat-users>

Step 5 – Enjoy your brand new Registry

Now start Tomcat and open your web browser at http://localhost:8080/juddiv3/. You should see a Apache jUDDI‘s welcome page like this one…
The Apache jUDDI's welcome page
The Apache jUDDI's welcome page

…or like the following one if you click on the jUDDI Portal link

Pluto: The jUDDI portal
Pluto: The jUDDI portal

Now you may for example connect to juddi MySQL database and execute the command “show tables;” just to list all tables created by the jUDDI installation process.

Some very important notes:

  • Of course the instructions on this post are not perfect for a production environment. I installed everything in my windows development sandbox. If you are installing it for a production environment I strongly recommend you not to use the same password as the login name of the MySQL user. Another thing is to change the default jUDDI Authentication.
  • It’s possible to do the same thing for a Linux environment. Just follow the instructions having Linux on your mind;

I’ll talk more about Apache jUDDI Registry on a next post.

Stay away from trouble!

Update at 2011-07-23 23:17

After logging in at Pluto you probably will see that the portlets don’t work. It may print some strack trace errors inside the portlet windows or a javascript alert “erro:null” is shown. To solve this problem you’ll have to do the following:

Make sure the file juddiv3.properties of webapps/juddiv3 and webapps/uddi-portlets have the same configurations. Therefore, copy webapps/juddiv3/WEB-INF/classes/juddiv3.properties to webapps/uddi-portlets/WEB-INF/classes/juddiv3.properties.

Praticando SOA com métodos ágeis: Estória ou História?


Depois de ler o post do Carlos Filho sobre o quadro Kanban para governança SOA que usamos na Infoglobo, lembrei de uma dúvida que sempre pairou sobre mim nos plannings e daily meetings: O correto é usar o termo “estória” ou “história”?

Em algum momento da minha vida lembro de alguém ter me falado ou eu ter lido em algum lugar que o termo “estória” não existia mais e que o termo “história” teria acumulado seu significado. Ao pesquisar no pai dos burros da era do conhecimento (leia-se Google), nunca achei uma fonte confiável que fornecesse uma resposta satisfatória.

Diante da dúvida, na última semana tive a idéia de perguntar ao jornalista e editor de opinião do Jornal O Globo, Aluizio Maranhão, que também é coordenador da revisão gramatical, sintática, semântica e tudo mais que você possa imaginar da Lingua Portuguesa no O Globo.

Meu diálogo com ele foi o seguinte:

– Gostaria de saber se “Estória” foi eliminada do Português ou não? Tempos atrás lembro de ter lido em algum lugar que “História” acumularia o significado de “Estória”. É verdade?


– É. “estória” caiu em desuso… Agora é tudo “história” ou “História”…


– Mas “caiu em desuso” não significa que tenha sido abolido como se fosse parte de uma “reforma gramatical”. Eu posso usar mas não vai estar mais “na moda”. Seria isso?


– Quando você vai no Aurélio é dito que é o mesmo que “história”. Melhor não usar.

Ou seja, ao praticar métodos ágeis e até mesmo no dia a dia, use sempre o termo história (ou História).

Ontologia para SOA


Durante a disciplina Fundamentos da Modelagem no curso de Mestrado do PPGI-UFRJ, fiz uma análise da ontologia de domínio para a Arquitetura Orientada a Serviços, a Ontologia SOA, criada pelo The Open Group. Além disso, apliquei alguns conceitos da UFO – Unified Foundational Ontology propostos por Giancarlo Guizzardi em “Ontological Foundations For Structural Conceptual Models” com o objetivo de criar uma nova modelagem para  Ontologia SOA. A figura abaixo mostra o diagrama que representa parte da modelagem resultante dessa análise e da aplicação da UFO.

Ontologia SOA
Modelagem proposta para a Ontologia SOA do The Open Group

Por diversos motivos a criação de ontologias de domínio, como é o caso da Ontologia SOA, baseadas em ontologias de fundamentação é de extrema importância. Isso por que as ontologias de fundamentação permitem o estabelecimento de ontologias de domínio mais consistentes, expressivas e semanticamente mais ricas.

A modelagem resultante dessa análise atinge o objetivo proposto inicialmente uma vez que ela torna mais explícito uma série de conceitos que na modelagem original da Ontologia SOA, feita pelo The Open Group, estavam implícitos ou apenas descritos em linguagem natural, no caso a língua Inglesa. Dessa forma, os praticantes da Arquitetura Orientada a Serviços poderão se beneficiar dessa nova modelagem já que ela permite um melhor entendimento dos conceitos da Arquitetura Orientada a Serviços e consequentemente um maior alinhamento entre seus praticantes.

Outro aspecto relevante da modelagem proposta é que ela representa um passo a mais em direção à implementação de SOA orientada a modelo (model-driven SOA implementation), o que facilita ainda mais a adoção de SOA.

Leia o meu artigo na íntegra em http://www.slideshare.net/MarceloFernandes3/ontologia-soa. Obs: É necessário um conhecimento mínimo sobre UFO para uma melhor entendimento do artigo.

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

As 3 visões da Arquitetura Orientada a Serviços


Durante a edição brasileira do SOA Symposium, que aconteceu em Brasília em Maio de 2011, tive o privilégio de assistir a apresentação de um dos maiores especialistas de Integração e Arquitetura Orientada a Services (SOA). Trata-se do Paul Brown, que é autor de vários livros e atualmente é o “Principal Architect” da TIBCO.

Nessa palestra, Brown relembrou uma definição de Arquitetura contida no livro Software Architecture in Practice publicado em 2003, onde uma Arquitetura compreende 3 visões que são as seguintes:

  • Modelo de Processo: Descreve o processo de negócio na visão do usuário, ou seja, todas as atividades e conceitos envolvidos;
  • Padrão de Arquitetura: Mostra quais sistemas estão envolvidos no processo de negócio, seja por eles possuírem dados ou regras de negócio necessários ao processo, e como eles e seus canais de comunicação colaboram para a execução do processo;
  • Mapeamento Processo x Arquitetura: Descreve em quais sistemas cada atividade do processo é executada. Naturalmente ao fazer esse mapeamento acabamos “explodindo”, ou seja, detalhando algumas atividades do processo.
Um exemplo de cada uma dessas 3 visões

O exemplo que daremos trata de uma questão inspirada num caso real da indústria de mídia relacionado a um projeto que eu estou participando: A extração de entidades a partir de conteúdos editorias.

Antes de apresentar os diagramas, vamos entender um pouco sobre a estruturação de conteúdos em Tópicos usando Extração de Entidades. Para isso, pedi uma ajuda a minha amiga Giselle P. Maia que é especialista no assunto:

Com o crescente volume de informações produzidas por empresas jornalísticas e disponibilizadas em seus sites, a organização tradicional de conteúdo por editorias se torna insuficiente.

Daí surge a necessidade de criar meios para que as essas empreasa possam publicar conteúdo
estruturadamente em páginas chamadas “tópicos editoriais”.

Estas páginas são agrupamentos do conteúdo previamente indexado de acordo com
um “tema” especificado. Nesta visão, um conteúdo poderá pertencer a um ou mais “temas”
simultaneamente, mesmo que associado a uma única editoria. Não é a toa que a organização de conteúdos em Tópicos é um primeiro passo à publicação automática de páginas semânticas.

Uma das formas de organizar conteúdo por Tópicos é (i) identificando Entidades (Ex: pessoas, lugares, empresas etc) relacionadas aos conteúdos e (ii) associando aos tópicos certas entidades. Dessa forma, por um lado a empresa fica com a responsabilidades de criar Tópicos e definir as Entidades a eles associados e por outro se estabelece um mecanismo automático de extrair Entidades a partir dos conteúdos produzidos. Assim, bpara ter uma página de um “tópico editorial” será necessário apenas fazer uma pesquisa no estilo “exiba todos os conteúdos que tenham as entidades existentes no tópico em questão”.

Um exemplo de páginas de tópico editorais é o do Estadão sobre o Pacote de Ajuda aos Bancos e a página de Tópicos do New York Times que na verdade só exibe Entidades.

Agora que sabemos um pouquinho sobre Tópicos e Entidades, temos condições de estabelecer e apresentar suas 3 visões. Para tal, vamos considerar apenas parte da Extração de Entidades, ok!?!?

A figura abaixo mostra um Modelo de Processo simplificado para Extração de Entidades do projeto que estou participando.

Modelo de Processo simplificado de uma Extração de Entidades
Modelo de Processo simplificado de uma Extração de Entidades

Diagramas de Modelos de Processos são uma fonte muito rica para a identificação de serviços numa Arquitetura Orientada a Serviços (SOA). No caso do modelo de processo acima, sinalizei em tom avermelhado quais seriam os candidatos a serviços de negócio.

O Padrão de Arquitetura poderia ser o mostrado na figura a seguir. Nele temos apenas 3 sistemas envolvidos: O Sistema Editorial, o Barramento de Serviçõs (ESB) e o Sistema que possui toda a lógica de Extração de Entidades.

Padrão de Arquitetura que poderia ser utilizado para a Extração de Entidades
Padrão de Arquitetura que poderia ser utilizado para a Extração de Entidades

Ao fazer o Mapeamento do Processo na Arquitetura definida acima inevitavelmente nos leva a “explodir” algumas atividades do processo, o que é perfeitamente normal.

Mapeamento do Modelo de Processo de Extração de Entidades na Arquitetura definida
Mapeamento do Modelo de Processo de Extração de Entidades na Arquitetura definida

É importante observar que os diagramas de mapeamento podem evoluir em nível de detalhamento ao longo do projeto.  Isso se torna mais evidente principalmente se você estiver participando de um projeto que utilize um método ágil de gestão.

Arquitetos devem se preocupar com todas as 3 visões

O primeiro motivo por que Arquitetos de TI devem se preocupar com essas 3 visões é por que quanto mais complexos forem os modelos processos ou os padrões arquiteturas que estão sendo tratadas, maior será o número de possibilidades de mapeamento. Tais possibilidades envolvem diferentes formas de comunicação e diferentes definições de responsabilidades.

Outro motivo é por que mesmo que seja escolhido o melhor padrão de arquitetura um mapeamento inadequado pode comprometer o processo não só no aspecto técnico mas também no aspecto funcional impactando os usuários.

O terceiro motivo é por que somente diante de um mapeamento teremos condições de validar a solução proposta. Apenas o modelo de processo ou o padrão de arquitetura não são suficientes para comprovar (tecnicamente ou funcionamento) a viabilidade da solução ou para que os usuários possa validar a proposta final de solução. Dessa forma, as 3 visões são necessárias e se complementam.

Até o próximo post!

Nossa apresentação no SOA Symposium edição Brasil


Hoje é o dia da nossa apresentação no 4th International SOA Symposium que esse ano acontece em Brasília.

Estaremos às 10:30 no salão F.

Apresentaremos nossa experiência de adoção de SOA durante os últimos 3 anos na Infoglobo.

Aí vai link para os slides da apresentação:

4th SOASymposium – Service Oriented Architecture at Infoglobo – A Real World Case Study in the Brazilian Media Industry

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

Pode existir SOA com REST?


Essa semana assisti a gravação de uma apresentação de um arquiteto da plataforma de comércio eletrônico da EBay (Sastry Malladi). A apresentação, realizada na QCon de 2010 (San Francisco, USA), fala sobre algumas formas de implementar serviços REST (RESTful services) numa arquitetura orientada a serviços (SOA) que normalmente contem serviços SOAP e os padrões WS-*.

A apresentação é mais uma demonstração prática de que serviços REST podem ser parte integrante de SOA. Na minha opinião poderíamos ir até mais longe. Isso porque eu arriscaria dizer que serviços REST devem ser sempre considerados pois nem sempre é necessário implementar os padrões WS-*.

Um ponto interessante na apresentação foi a utilização de JAXB para gerar representações em formatos JSON, coisa que por coincidência eu venho implementando juntamente com o Jersey. A flexibilidade oferecida pela dobradinha Jersey e JAXB é muito boa e me lembrou um pouco o Ruby on Rails. Pretendo em breve falar mais sobre o assunto aqui no blog.

Um ponto que a demonstração prática deixou a desejar foi mostrar com mais detalhes o uso dos XMLs de mapeamento. Fiquei com a impressão de que muito código deve ser construído e mantido para suportar as integrações, coisa que uma ferramenta de ESB ou EAI tiraria de letra.

A apresentação, sugerida pelo meu amigo e arquiteto de integração Carlos Alberto Filho, está no site da InfoQ em http://www.infoq.com/presentations/RESTful-SOA-in-the-Real-World

Conhecendo o Ruby On Rails


Há mais ou menos uns 10 anos atrás, comecei a perceber o grande e repetitivo trabalho que tinha que fazer toda vez que eu tinha que iniciar o desenvolvimento de um sistema usando as linguagens PHP (Na época chamado de PHP FI) ou ASP.

Ter que criar scripts e tabelas no banco de dados sempre partindo do zero era uma coisa que tornava o trabalho demorado e sem graça, quase que puramente operacional. Foi quando recorri ao “The most powerful and useful guide to the Net” (aka: Altavista), procurando por algo que pudesse agilizar meu trabalho tornando-o mais produtivo e divertido. A busca foi frustrada pois o melhor que eu encontrei naquela época foi o Dreamweaver UltraDev, que simplesmente criava um código impossível de dar manutenção.

Passado todo esse tempo, eis que em 2010 posso dizer encontrei o que procurava naquela época. Depois de escutar vários amigos falando muito bem e usando, resolvi conhecer e praticar o Ruby on Rails.

O primeiro passo foi dado com a leitura do (excelente!) livro “Ruby on Rails – Desenvolvimento rápido e fácil de aplicações web” do Robrigo Urubatan (Editora Novatec).

Já nos primeiros capítulos não resisti e comecei a colocar a mão na massa, ou seja, instalei o Ruby on Rails e comecei a criar algumas aplicações a partir dos exemplos contidos no livro. A experiência não poderia ser melhor!!

Ruby on Rails, também chamado de RoR, é um framework de desenvolvimento de aplicações web baseado na linguagem Ruby e que utiliza o padrão arquitetural Model-View-Controller (MVC).

Uma característica muito interessante desse framework é a utilização nativa de web services REST como forma de comunicação entre o View e o Controller. Sendo assim, ao criar uma aplicação web com o Ruby On Rails você não só está criando a interface humana (HTML) do seu sistema mas também está disponibilizando toda a lógica da sua aplicação para acesso através de uma API REST, o que me interessou muito já que estou atuando como Arquiteto de Integração e participando da implantação de uma Arquitetura Orientada a Serviços (SOA).

Quer ver como é fácil desenvolver aplicações web com o Ruby on Rails?

Desde quando pensei em escrever esse post fiquei pensando o que faria para mostrar brevemente como o Rails funciona. Que exemplo utilizar? Devo, antes de tudo, mostrar como se instala o Ruby e o Rails? Será que o post não vai ficar chato e grande? Nada disso! Foi então que lembrei de um vídeo que me serviu como grande motivador para aprender o framework.

Trata-se de dois vídeos que explicam como trabalhar com formulários html aninhados. No vídeo, a aplicação que é construída permite a criação de Pesquisas (surveys), onde cada pesquisa pode conter várias perguntas, que por sua vez pode conter várias opções de resposta.

Mesmo se você não sabe nada de Ruby ou de Rails vale a pena assistir. Mas assista observando a (pouquíssima) quantidade de código que é escrita para criar a aplicação. Observe também o tempo que leva para fazer. E, principalmente, pense na quantidade de código que você teria que escrever e quanto tempo demoraria para você fazer o mesmo na linguagem de programação que você utiliza atualmente.

Aí vai o link desses dois vídeos que estou me referindo:

A propósito, o http://railscasts.com é uma ótima referência para aprender a como resolver uma série de problemas recorrentes que nos deparamos no dia a dia do desenvolvimento de aplicações web.

O que torna no Ruby on Rails tão simples?

Você já ouviu falar em “Convenção sobre Configuração”? Talvez tenha ouvido falar com o nome de “Codificação por convenção”? Não???????

Bem, o Rails é um framework que segue esse conceito. Na prática, o que tal conceito prega é que o desenvolvedor não precisa dizer, ou melhor, configurar, como o framework irá se comportar toda vez que for construir uma aplicação. Isso quer dizer que o framework assume determinadas premissas de funcionamento e que o desenvolvedor só terá algum trabalho se precisar alterar tais premissas (o que só acontece em casos muito específicos).

Alguns exemplos de tais premissas, ou melhor, convenções, são:

  • A comunicação entre a View e o Controller é feita por REST com os verbos HTTP: GET, POST, PUT e DELETE;
  • Alguns métodos de um Controller são mapeados automaticamente aos verbos HTTP: GET é mapeado ao método show, PUT ao método create, POST ao método edit e DELETE ao método destroy.
  • Toda View já possui uma saída HTML, para consumo humano, e uma XML para consumo por um programa (cliente do web service);
  • Não é necessário criar arquivos de Mapeamento Objeto-Relacional. Isso já está embutido em todo modelo;

Essa lista poderia ir longe. A importante mensagem que espero ter passdo com esse pequeno exemplo é: Poupa-se muito trabalho ao utilizar essa abordagem!

Saiba mais sobre Convenção sobre Configuração.

Quer aprender Ruby on Rails e não sabe por onde começar?

Começar aprendendo a linguagem Ruby é sempre uma boa, a final de contas não dá para aprender direito um framework de desenvolvimento sem saber a linguagem que ele utiliza.

Para aqueles que não dispõem se muito tempo e querem aprender Ruby e Rails colocando a mão na massa desde o início, adquira o livro que eu comentei no começo desse post. Mas atenção!!! Esse livro trata da versão 2 do Rails, que já está na versão 3.

Se o Inglês não for um problema e você quiser iniciar o aprendizado na recente versão mais recente, leia o livro “Agile Development with Ruby on Rails (3rd Edition)“. Nele você construirá uma aplicação completa de e-commerce onde são abordadas situações reais que enfrentamos no dia a dia do desenvolvimento de aplicações web. Eu lí ambos e recomendo.

Outra boa sugestão é seguir as dicas do Akita sobre como aprender Ruby on Rails. A propósito, o blog dele (http://akitaonrails.com/) é uma ótima maneira de manter-se antenado sobre o que rola na comunidade Rails aqui no Brasil.

Abraços e até a próxima!