Category Archives: Arquitetura de Softwares

Amf/Rest WebServices com PHP e Zend Framework – Conceitos!

Olá pessoal, faz tempo, mas estou de volta! Esse ano tem TCC e além disso resolví fazer um curso de Java nos finais de semana, é, as coisas estão corridas, mas interessantes. Isso tirando o trabalho, parece que quanto mais fecho jobs mais eles surgem. Por falar em jobs estou precisando de um profissional que tenha programado uma aplicação pra MP4 playes, esses chineses genéricos, estou com um projeto e me liberaram contrar um profissional que desenvolva os firmwares pra esses dispositivos. Bom o convite está feito, quem tiver alguma experiência com esses dispositivos é só mandar email pra [email protected].

Mas vamos falar do assunto do post!

Chega um certo momento em que suas aplicações alcançam uma dimensão na qual é preciso fazer umas conversarem com as outras, nem sempre isso acontece, vai muito das necessidades, mas quando isso acontece, você se depara com ambientes distintos, datacentes distintos, banco de dados distintos, frameworks distintos, tecnologias distintas, arquiteturas distintas, problemas com performance, lógicas sem lógica… E como fazer seus mini-monstros conversarem? Foi essa a minha necessidade nos últimos meses. Como conseguir melhorar a qualidade no desenvolvimento de aplicativos web, e fazer a integração entre eles, se os mesmos não permitem fazer isso? Várias realidades, várias variáveis, que muitas vezes descobrimos somente quando alguma coisa é alterada, um ninho de abelhas.

Vendo esse senário a primeira saída era estudar. Entendi com a realidade na qual estava imerso que as coisas estavam grandes de uma forma, que não podia mais trabalhar com sistemas e sites distintos, tudo estava pulverizado em vários lugares diferentes, se um domínio caía, não impactava somente o mesmo, várias coisas paravam. Muita coisa devia ser refeita, mas refazer da mesma maneira não seria a solução, como fazer então? Só o MVC não estava me ajudando a organizar as coisas, muita coisa não era aproveitada.

As coisas são mais ou menos assim.old-archtecture

A figura ilustra de uma forma resumida como estão estruturadas as aplicações. Aplicações independentes e que em um determinado ponto precisavam consumir informações de outras aplicações. A figura não leva em consideração os datacenters, que em alguns dos casos eram distintos.

Como dá pra perceber na figuram existem n aplicações consumindo os mesmo bancos de dados, essas aplicações muitas vezes executavam processos iguais, por esse motivo mesmos processos precisavam ser reescritos em aplicações direrenres, ou pelo menos portados de um framework para outro quando fosse possível. Sem documentação, como lembrar onde o mesmo processo é executado para efetuar uma manutenção?

Comecei a estudar Ruby on Rails, gostei muito do que aprendí, muito rápido e objetivo, mas minha equipe iria demorar um pouco pra conseguir absorver essa nova linguagem e como as coisas são a 1000 por hora, não seria viável, espero um dia ainda poder trabalhar essa linguagem = Ruby / framework = Rails. Comecei também a ver Java e no momento que escrevo este post ainda estou fazendo um curso aos finais de semana, está me abrindo a mente pra OOP avançada e Design Patterns, o professor é muito bom, trabalha à muitos anos com o Java, a “turma” é de 3 pessoas, estou aproveitando muito, recomendo! Se forem de Curitiba mandem um e-mail que passo o contato. Depois da merchan, e muito estudo, quase espanei os parafusos, e acabei refletindo muito, levei em consideração os seguintes ítems:

  • Equipe de desenvolvimento 100% PHP (limitador);
  • Datacenter terceirizado sem suporte à Ruby on Rails e Java (não limitador, mas burocrático/perda de agilidade);
  • Tempo necessário pra disseminar a metodologia, padrões e conhecimento necessários extremamente curto;
  • Tempo e complexidade do deployment;
  • Infraestrutura contratada, PHP + MySQL + PostgreSQL e DB2;
  • Necessidade em lidar com Flash, Flex e FMS sem traumas (prover serviços para Flash e Flex).
  • Integração com o ERP da Microsiga acessando direto o Database e/ou utilizando WebServices;

Creio que esses foram os principais fatores, a minha infraestrutura é um problema, não gerencio os servidores, é tudo atravéz de chamados, isso deixa tudo muito interativo, no sentido de precisar trocar no mínimo umas 3 mensagem com o pessoal de infraestrutura da empresa pra eles interagirem com o pessoal do Datacenter, e aí o ticket ser executado. Minhas aplicações começaram a apresentar problemas, estão crescendo, e enfrento graves problemas de desempenho. Existem várias aplicações em Flex e Flash consumindo serviços desenvolvidos em PHP, um know-how que já possuímos, não seria interessante ter que reaprender tudo!

Sem alternativas, adivinha qual foi a minha saída? Acertou, PHP!!! É…, mas como nada nessa vida é em vão, como executar e planejar a nova arquitetura de desenvolvimento? Pensei, pensei, quando estava quase tudo meio que alinhado na minha cabeça, chamei os dois melhores programadores de equipe e joguei o desafio – Como desenvolver um webservices utilizando PHP de uma forma simples e direta?

Mas por que WebServices? Você vai entender mais a frente.

Pensaram e logo veio a ideia, trabalhar com rotas e serviços publicados utilizando WSDL e SOAP. Bem lógica a resposta. Fui mais longe, porque não implementar um Rest WS? Seguindo a idéia de – por que complicar se podemos fazer as coisas de uma forma mais simples? Se não me engano foi em um podcast do Fabio Akita onde ele falava de Restful e routes no Ruby on Rails que eu entendi, porque complicar uma coisa se podemos utilizar recursos já consolidados na Internet como o HTTP e suas actions? Isso pra mim iria descomplicar muita coisa, não haveria a necessidade de aprendizado de WSDL, SOAP do PHP ou o nuSOAP, sem serviços de descobertas de serviços e todas essas coisas. Existe cases melhores que o Amazon, Twitter e o Facebook pra entender que o Rest dá conta do recado no que diz respeito à aplicações com milhões de page views e que precisam de segurança?

Resolví o meu problema do WS, mas ainda não tinha terminado. Como mudar o resto da arquitetura a fim de conseguir consumir os serviços disponibilizados pelo WS? Como facilitar a atualização, implementação de novas funcionalidades sem ter que portar pedaços de views de uma aplicação para outra?  Pois as regras de negócios estariam no WS, cada aplicação trabalharia com as suas interfaces com o usuário, caso a funcionalidade fosse a mesma, ainda teria repetições de “pedaços” de processos, nesse caso Views repetidas.

Me deparei com o conceito de portlets, apresentado pela minha amiga Desirre, adaptei pra minha realidade essa idéia. Não montar uma aplicação pra cada portlet (como o Java implementa), mas montar uma aplicação com vários módulos, cada módulo com os comportamentos necessários, por exemplo, módulo de notícias, vou programar ele pra consumir os serviços das notícias necessários para exibição, paginação, busca por exemplo, e eu iria conseguir disponibilizar o mesmo módulo em aplicações distintas sem traumas sem a necessidade de replicar a mesma coisa em lugares diferentes.

A arquitetura como um todo ficou assim.

new-archtecture

Cabia a mim agora decidir entre utilizar um framework ou codificar tudo do zero com PHP “puro”, comecei a estudar alguns frameworks em PHP, não muitos, Code Igniter e Zend. Parei a minha busca por um framework com o Zend, mas por que um framework se possuo na minha equipe bons programadores? Simples! frameworks ajudam o desenvolvimento provendo funcionalidades testadas, em constante manutenção e evolução, mais que isso, eles provém um “conceito” de desenvolvimento, uma forma já pré definida de como codificar, cada framework define formas de como programar, como consumir as funcionalidades disponibilizadas entre outras coisas. Sabendo que no PHP o que se escreve funciona, independente da arquitetura, orientação, formatação, e conhecendo os prazos dos projetos, a idéia de utilizar um framework para o nosso desenvolvimento é obter uma fonte de recursos e funcionalidades de uma forma mais rápida e segura, além disso, ajudar a definir um conjunto de boas práticas.

O que mais me chamou atenção a princípio no Zend foi a quantidade de recursos disponíveis, muita coisa, dei uma olhada na sua documentação e fiquei surpreso, mais ainda por suportar publicação de serviços em Amf  e Rest, a primeira supriria a minha necessidade por prover serviços a aplicativos com tecnologia Flex e Flash a segunda era brinde…. =)

Me deparei então em montar o início de tudo, como trabalhar com o Zend? Um livro me ajudou em entender como as coisas funcionavam no Zend, e como as coisas não funcionavam também, minha preocupação era sempre em escalar, precisava montar um provedor de serviços em Amf/Rest com alto desempenho, já que estaria centralizando tudo, a idéia de fazer um LB (load balance) no Apache teria que ser algo simples e rápido, já que a proposta da empresa é de crescimento. Foi aí que percebí que tinha feito uma boa escolha, vindo de uma experiência com o Code Igniter (CI), Expression Engine e afins, o Zend era totalmente diferente, um novo conceito pra mim, uma lógica diferente em utilizar uma frameworrk, eu teria que montar a aplicação de acordo com as minhas necessidades, fazer o load das bibliotecas necessárias para a minha aplicação na medida que eu fosse precisando, diferente do CI onde já vem tudo estruturado e você só precisa configurar a sua aplicação, o Zend é tudo do zero, ele disponibiliza uma Library e só, você se encarrega de utilizar da forma que precisar, bem coisa do PHP isso….

Depois de idealizado e estruturado e implementado o Web Services ficou como a figura abaixo.

zend-rest-amf-webservices

Vou explicar mais ou menos como fizemos.

Todos as requisições dos módulos aos serviços chegam no WS no Facade, ele é responsável por pegar todas as requisições, ele valida para qual serviço foi feita a requisição e qual sua Action (POST, GET, PUT ou DELETE), em seguida valida o Token, que é um código que os modulos passam para se identificarem, como uma chave pública de criptografia. O token faz parte da camada Security, estudamos a implementação também nessa camada de validação de IP`s, como o sistema roda ditribuído no datacenter, é possível fazer a validação das máquinas que estão consumindo os serviços, melhorando ainda mais a segurança do WS. Seguindo a sequência, após a validação do token e IP, é feito o load do Server requisitado, conseguimos implementar um serviço genérico, o mesmo pode ser “rodado” pelo Zend_Rest_Server ou pelo Zend_Amf_Server sem nenhum problema, creio que essa foi uma característica muito interessante do nosso projeto, com um mesmo conjunto de classes, conseguimos disponibilizar serviços em Rest e Amf escrevendo somente uma vez. Por último um conjunto de DAO`s (Data Access Object), que nos auxiliam com o IO de dados a Bases de Dados, outros Web Services e Envio de e-Mails por exemplo.

No momento que escrevo este post faz mais ou menos um mês que o Amf/Rest está em funcionamento, ainda tem muita coisa pra evoluir…

No próximo post entro em detalhes, de como implementar o Amf e Rest Servers com exemplos e afins. Esse post foi mais a viagem do oriental aqui em como resolver o grande problema enfrentado por mim e pela equipe de desenvolvimento em manter as coisas organizadas e como conseguir um melhor aproveitamento dos funcionalidades implementadas.

Caso tenha alguma idéia ou dúvida fique a vontade de comentar esse post, será muito bem vindo. E caso não tenha entendido nadinha de nada comente também, posso explicar de uma outra forma em um outro post…..

É isso, ótima semana a todos e até mais.