Java memory leak, isso tem jeito ? 1/4

Olá pessoal,

Gostaria de compartilhar com vocês um dos grandes problemas que a arquitetura java tem dado a quem trabalha com ele, especialmente com aplicativos de alto desempenho e disponibilidade. Ando estudando um pouco sobre isso e achei diversos materiais interessantes e vou tentar compilá-los aqui numa série de 3 ou 4 posts.

Vamos falar um pouco sobre as causas mais comuns para esse famigerado problema, que não tem nada de simples. Porque é tão difícil de ser ser identificado? Qual a parcela de culpa de quem desenvolve, se é que existe culpa? Servidores de aplicação são a solução? Por que eles acontecem ?

Espero descobrir as respostas para esses problemas, postar aqui minhas impressões e dividí-las com quem tiver interesse. Espero receber contribuições também !

Abraços e até a próxima.

 

Versionamento de SOA (Parte 2)

Continuando o assunto sobre versionamento de SOA, é fato que os requisitos de uma aplicação sempre acompanham as mudanças de negócios das empresas como também, as necessidades de novas informações por parte dos gestores. Esse tipo de acontecimento pode gerar uma quantidade enorme de re-trabalho, manutenção e atualização das aplicações, sem falar na necessidade de reinstalações e re-configurações dos aplicativos clientes que, de uma forma ou de outra, se integram com o aplicativo que sofreu atualizações.

O conceito fundamental por trás da arquitetura orientada a serviços está na autonomia; a possibilidade de se distribuir, modificar e manter, independentemente de outros sistemas(consumidores), novas funcionalidades sem causar impactos significativos aos que o utilizam. O versionamento assume a existência simultânea de versões de um serviço, incluindo todas as suas operações e suas diferentes implementações.

Uma consideração importante a respeito de versionamento é definir por quanto tempo é necessário manter as diferentes versões em funcionamento. O ciclo de vida de existência de um serviço ou método versionado, varia significativamente e é definido pela habilidade de uma organização em lidar com as mudanças.

To be continued…

 

Versionamento de SOA

Depois de alguns dias ausente (esse negócio de manter um blog não é fácil!!!), estou de volta com um tema que achei interessante, versionamento de SOA.

Para quem ainda não conhece o que significa mais essa sigla, SOA (Service Oriented Architecture) ou arquitetura orientada a serviços, sugere que todos os aplicativos desenvolvidos em uma corporação sejam implementados de forma que possam prover serviços que permitirão entre outras coisas, a famosa integração independente de plataforma.

Isso só é possível pelo uso de WebServices, que a grosso modo podem ser classificados como métodos remotos publicados na Web, que através do uso do protocolo SOAP (opa outra sigla) e o XML, permite a exposição de métodos de aplicativos diversos na Web(intranet também), para consumo por qualquer outro aplicativo ou dispositivo que utilize o protocolo http(s).

Dentre algumas das preocupações relativas ao assunto, existe a primeira delas, que é não propagar problemas internos de aplicações corporativas (inconsistências de dados) para os clientes dos serviços. Imagine se um Webservice que possui uma consulta a uma disponibilidade de vagas em um hotel qualquer, que ao invés de retornar a informação do valor da diária, de um quarto em um período qualquer, retornasse o valor “V1” de um campo chave de uma tabela de domínio para valores de diária…também existe a não menos importante, preocupação com segurança, os serviços publicados na internet precisam ter o mínimo de requisitos de segurança atendidos, como criptografia dos dados trafegados por exemplo, para garantir a integridade das informações propagadas.

Recentemente li o artigo (Versioning in SOA, do periódico The Architecture Journal, Edição 11, Microsoft Press) que expôs os principais desafios relativos ao uso de SOA. Como manter um serviço ativo e atualizado ao mesmo tempo, sem propagar problemas após a liberação de uma nova versão?

To be continued…