25 de Outubro de 2009

Os Princípios do Manifesto SOA

Arquivado sob: Outros, SOA — marco @ 18:51



Os Princípios do Manifesto SOA


Nós seguimos estes princípios:

Respeitar a estrutura social e de poder
de uma organização.

Reconhecer que SOA requer mudança em vários níveis

O escopo da adoção de SOA pode variar.
Devemos manter os seus esforços gerenciáveis e dentro
de limites significativos

Produtos e ferramentas sozinhos não lhe
fornecerão SOA ou aplicarão o paradigma
de orientação de serviços para você

SOA pode ser implantado através de uma gama variada de
tecnologias e padrões

Estabelecer um conjunto uniforme de políticas e
padrões corporativos baseado em padrões da indústria,
padrões de facto e padrões da comunidade.

Buscar uniformidade no exterior a medida que
permita diversidade no interior

Identificar serviços através da colaboração de pessoas
de negócio e tecnologia

Maximizar o uso de serviços considerando o escopo
atual e futuro da organização

Verificar se os serviços satisfazem os objetivos e
requisitos de negócio

Evoluir os serviços da organização em resposta ao seu real uso

Separar os diferentes aspectos do sistema para
mudar em velocidades diferentes

Reduzir as dependências implícitas e
publicar as dependências externas para
aumentar a robustez e reduzir o impacto das mudanças

Em qualquer nível de abstração, organizar
cada serviço em torno de unidades
de funcionalidades coesas e gerenciáveis




Esta é uma tradução pessoal do SOA Manifesto Guiding Principles criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis.

Bons projetos SOA!

O Manifesto SOA

Arquivado sob: Outros, SOA — marco @ 18:03

O Manifesto SOA

A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada e custos eficazes, alinhado às necessidades de mudanças nos seus negócios.

Através do nosso trabalho nós priorizamos:

Valor para o negócio sobre estratégias técnicas.
Objetivos estratégicos sobre benefícios específicos de projetos.
Interoperabilidade intrínseca sobre integrações personalizadas.
Serviços compartilhados sobre implementações com propósitos específicos.
Flexibilidade sobre otimização.
Refinamentos evolucionários sobre a procura da perfeição inicial.

Isto é, embora nós valorizemos os valores da direita, nós valorizamos mais os itens à esquerda.


Esta é uma tradução pessoal do SOA Manifesto criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis. Acredito no manifesto. Também aderi ao manifesto, ao qual me tornei signatário.

Bons projetos SOA!

23 de Outubro de 2009

O complexo caminho da simplicidade do EJB 3.1 e o Java EE 6.0

Arquivado sob: Java EE — marco @ 00:18

Para um novato Java que queira criar um EJB na especificação 3.1, o processo é muito simples. Você cria uma classe Java e com apenas uma anotação você tem um objeto distribuído que responde via protocolo RMI/IIOP.

Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra linha de código, conforme mostrado abaixo.

Entretanto, se olharmos as especificações anteriores do EJB, veremos que esta simplicidade foi alcançada depois de muito trabalho na remoção de complexidades.

Por exemplo, o mesmo código em EJB 3.0 requer uma classe e duas interfaces Java, conforme mostrado abaixo:

Mais impressionante é notar que na especificação EJB 2.1 este mesmo exemplo seria implementado como uma interface local, uma interface remota, uma interface home, uma classe de implementação de negócio, uma classe de implementação da interface home e alguns arquivos XML. Um exemplo arqueológico pode ser encontrado aqui para os mais curiosos. Para criar um único método distribuído, precisamos de várias dezenas de linhas de código.

Se observamos ainda mais atrás no tempo um objeto CORBA, fonte de inspiração dos primeiros EJB, veremos ainda um código mais complexo.

Felizmente temos observado este movimento de simplificação de APIs em vários outros lugares da API Java. O JBOSS Seam inspirou a simplificação do JSF na nova especificação do JSF (JSF 2.0), conforme podemos observar neste artigo em anexo.

O modelo de servlets também foi simplificado. Agora podemos ter Servlets que são configuradas puramente com anotações ao invés de arquivos XML, conforme podemos ver no exemplo abaixo:

Um ambiente que já suporta estas novidades de simplicidade é o NetBeans 6.8. Notavelmente, o NetBeans tem conseguido “roubar” muita audiência dos desenvolvedores Java justamente por ser mais simples do que o poderoso (mas complexo) Eclipse. Para os programadores Java que nos leem, um tutorial é fornecido aqui.

Pensamento do dia: “Tudo deveria ser mantido o mais simples possível, mas não mais simples que isso”, Albert Einstein.

Pensamento do dia seguinte: “Se em tudo o mais forem idênticas as várias explicações de um fenómeno, a mais simples é a melhor””, William de Ockham

14 de Outubro de 2009

A evolução do MPS-BR - Guias para empresas que adquirem software, para fábricas de software e fábricas de testes

Arquivado sob: Gestão da Aquisição — marco @ 11:24

O MPS-BR, modelo Brasileiro de maturidade de software, está evoluindo a pleno vapor. Três novos guias estão disponíveis no portal do MPS-BR.

- Guia de Implementação – Parte 8: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações que adquirem software.

-Guia de Implementação – Parte 9: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Software.

- Guia de Implementação – Parte 10: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Teste.

Estes novos guias mostram a necessidade de personalização de processos para segmentos específicos da indústria e também indicam um caminho de aumento de maturidade para organizações de TI sérias mas que infelizmente não possuíam um modelo de referência para trabalhar.

Pensamento do dia revisitado: “Um longo tempo é necessário para trazer a excelência à maturidade”, Publius Syrus, Séc. I A.C.

9 de Outubro de 2009

Os analistas de sistemas, os “soft skills”, a filosofia estóica e o budismo

Arquivado sob: Gestão de Pessoas — marco @ 19:16

Depois de um longo e pesado Setembro, estamos de volta ao nosso bom hábito de escrever. Desta vez gostaria de falar sobre uma habilidade cada vez mais valorizada pela empresas de TI, que são os “soft skills˜, ou habilidade suaves, em uma tradução literal. Estas habilidades são muito enfatizadas pelos agilistas e escolas ágeis e tem a ver com habilidade de comunicação, compreensão, liderança moral e a capacidade de unir e organizar times de trabalho. Um artigo muito interessante de Gary Pollice, da IBM, está disponível aqui.

Li recentemente trechos da filosofia estóica, que tem similiaridade com o Budismo, e que por incrível que pareça podem nos ajudar na TI a sermos pessoas melhores e ganhar autoridade moral sobre times. Parece que filosofia e TI tem pouco em comum, mas o oposto é verdade. As frases abaixo nos mostram como a nossa atitude correta importa muito na saúde de projetos.

“As coisas que nos afetam estão fora de nós. Mude sua atitude e então, como um navio entrando num porto seguro, você encontrará a calma.”

“Quando contrariado, recue e considere se às vezes você não é culpado exatamente pela mesma coisa.”

“Antes de cada ação pense: eu não teria nenhuma razão para me arrepender depois?”

“A felicidade daqueles que querem ser populares depende dos outros; a felicidade daqueles que buscam prazer flutua com humores fora do seu controle; mas a felicidade do sábio nasce dos seus próprios atos livres.”

A virtude e a maldade existem, não como emoções e pensamentos, mas como ações.”

Frases do imperador romano e filósofo estóico Marcus Aurelius Antoninus

Blog do Marco Mendes | Artigos, Comentários e Opiniões sobre Engenharia de Software, Arquitetura de Software, SOA e Java