Archive for July, 2006

Componentização: Bioengenharia Entende mais que TI

Friday, July 28th, 2006

Tem bastante tempo eu escrevi num dos meus blogs anteriores (não lembro qual deles) sobre como existe um mercado de componentes. O ponto é que ao contrário do que o hype de CBD (Component-Based Design) quis passar, não existem tantos componentes de negócio. Os componentes existentes são quase sempre horizontais, como bibliotecas para envio de e-mails, parsers de XML, implementações de especificações como EJBs… Os tais componentes de negócio, no mundo maravilhoso onde você encontraria seu software de RH na prateleira, ficaram nos livros.

A lembrança sobre este tema me veio a cabeça ontem, lendo a Scientific American Brasil no metrô. A edição de Julho traz uma matéria interessantíssima sobre como a biotecnologia busca industrialização através da componentização de seus produtos.

O diferencial é que eles estão seguindo exatamente o modelo da engenharia eletrônica. Em eletrônica nós temos componentes horizontais que formam sistemas verticais. Por exemplo, uma TV é formada por uma enormidade de pequenos componentezinhos. Cada componente deste possui especificações técnicas que dizem quais entradas eles esperam e que saída esperar deles.

O ponto é que uma TV ou um composto biológico é um artigo de massa. Você não entra na loja e monta uma TV com características que deseja. Um sistema de informação é exatamente o oposto, cada empresa quer características próprias. Neste cenário pensar em componentes verticais de granularidade grossa fica muito complicado.

Então, o que CBDtrouxe foi uma forma de organizar um sistema de informação em componentes, mas o sonho off-the-shelf (componentes de prateleira) não vingou.

Interessante notar que SOA traz uma proposta um pouco mais realista neste sentido. As empresas constroem seus próprios serviços, dispnibilizados para consumidores externos ou internos. Não existe necessidade de serviços de prateleira, se você quer consumir um serviço disponibilizado por alguém tudo que você precisa é se conectar a ele. Estamos aproveitando as características de CBD que se provaram úteis (encapsulamento, contratos, controle de dependências, reuso, separação de artefatos…) e eliminando uma parte que não vingou.

Entrevista com Eric Evans

Thursday, July 27th, 2006

Falando no Eliziário, ele me indicou um excelente podcast: Software Engineering Radio.

Qualidade superior aos podcasts de tecnologia normais e uma ótima entrevista com Eric Evans!

Standard Patterns?

Thursday, July 27th, 2006

Marcos Eliziário reflete sobre a forma como Design Patterns são encarados

Daí o risco da palavra “Padrão” em “Padrões de Projeto” ser entendida como norma, e por isso defendemos, que, para evitar essa ambiguidade, usemos o termo em inglês “Pattern”.

Texto rápido e recomendado!

Arquitectus Etilicus

Thursday, July 27th, 2006

Anteontem eu estava com um grupo de amigos da minha namorada no Devassa (não conhece? deveria…) e entre eles haviam dois franceses. Papo vai, cerveja vem… falamos sobre as ocupações de cada. Após saber que eu era ‘Arquiteto de Sistemas’, o simpático francês cujo nome não me lembro comentou que também estudava arquitetura, mas civil. E ficou surpreso de saber que existe arquitetura no contexto tecnológico.

Eu expliquei que ‘arquitetura’ é uma palavra presente na tecnologia desde muito tempo, com muitos significados, e quase semrpe ligado ao ramo dele apenas por poucos aspectos. E também sobre como as idéias do arquiteto (civil) Christopher Alexander influenciam a tecnologia em diversos níveis.

Uma das comparações que fizemos foi a construção de um prédio. Para engenheiros e arquitetos os cálculos têm que ser perfeitos, as especificações devem ser minuciosas e pode haver necessidade de várias simulações para edifícios mais complexos.

Enquanto isso em tecnologia nós podemos fazer o equivalente a construir o primeiro andar de um prédio e fazer o morador daquele espaço habitar lá por algumas horas e expôr suas impressões. Em tecnologia nós podemos mudar paredes e janelas de lugar facilmente.

A conclusão que chegamos foi que, na verdade, o ramo de engenharia deveria buscar a facilidade que se tem em tecnologia, não a tecnologia buscar a burocratização que existe hoje em engenharia civil. Papo de bar ou não, será que isso faz soar alguns sinos?

Desmitificando Picaretas do SOA: 1 - Qual a Diferença entre Serviços e Componentes Distribuídos?

Tuesday, July 25th, 2006

Já que o post anterior gerou comentários pedindo as respostas das perguntas, vamos tentar elaborar os tópicos. O primeiro é “Qual a Diferença entre Serviços e Componentes Distribuídos?”.

Vamos primeiro tentar entender o que chamamos por Componentes Distribuídos. Componentes são artefatos de software reutilizáveis, baseados nos princípios de engenharia eletrônica. Se você não sabe o que são componentes eletrônicos, abra seu computador (após ler este artigo!) e olhe todos aqueles quadradinhos pretos na placa-mãe.

Os Componentes possuem uma interface bem definida e oferecem operações aos seus clientes. Um Componente pode ser substituído por outro que obedeça a um contrato compatível com o publicado por sua interface. Para substituir um Componente, precisamos alterar o processo de lookup, quando um componente obtêm uma referência para o outro.

Componentes podem ser reaproveitados em outros sistemas que necessitem utilizar as mesmas operações já providas por este. A arquitetura baseada em componentes é chamada CBD - Component-Based Development.

Basicamente, ao criar um Componente você agrupa diversos objetos em um pacote com uma interface definida. os objetos não precisam ter responsabilidade semelhante, o que diferencia Componentes de Camadas, mas você pode usar Camadas para implementar os internos de um Componente. Camadas também não são necessariamente reutilizáveis, aliás é muito raro que o sejam.

A idéia é obter economia de escala, reutilizando um Componente eternamente sem precisar reimplementar aquela funcionalidade. CBD pode ser visto como um OO de maior granularidade, já que classes também são criadas para serem reutilizáveis (apesar de existirem malucos que criam suas próprias java.lang.String).

Componentes Distribuídos expõem suas interfaces numa rede. Eles deixam de ser internos à aplicação que os ‘publica’ (disponibiliza) e passam a oferecer suas operações na rede. EJB, por exemplo, é uma tecnologia criada com foco na criação deste tipo de componente.

Distribuído ou não, um Componente possui seu contrato onde estão publicadas as Operações que este disponibiliza. Qualquer um que saiba trabalhar com este contrato consegue utilizar o Componente.

Um Serviço é algo bem parecido fisicamente. É uma unidade de software que recebe mensagens. A diferença neste nível é na granularidade da mensagem recebida pelo Serviço. Enquanto o Componente recebe pequenas mensagens, o Serviço recebe uma ou pouco mais grandes.

Outra diferença básica é que um Componente possui um contrato que define suas operações, mas num Serviço os contratos são por operação. Isso quer dizer que para usar uma operação disponibilizada por um Serviço você não precisa conhecer as outras operações que este também oferece e, mais ainda, que as operações podem ser movidas de um Serviço para outro e só é necessário modificar os seus consumidores, e geralmente uma arquitetura SOA automatiza este tipo de modificação com indireção criada através de ESBs, por exemplo.

Claro que como quase tudo em tecnologia estes conceitos não são verdades absolutas. Dependendo da bibliografia, do fabricante ou do dia da semana os conceitos mudam bastante. Por enquanto fixe a diferença entre CBD e SOA nestes pontos:

  • CBD tem mensagens com granularidade fina e síncronas
  • SOA Tem granularidade grossa e mensagens geralmente assíncronas
  • Em CBD a unidade atõmica de reusabilidade é o Componente
  • Em SOA a unidade atômica de reusabilidade é cada operação

Ponto interessante sobre DSL e BPEL

Monday, July 10th, 2006

No blog do JBoss. É engraçado o que eu vejo acontecer com SOA, assim como OO tem gente já fazendo palestra sem saber do que se trata.

Sério, tem *muita* gente que até hoje escreve livro, ministra palestras, dá consultoria e tudo mais sem saber nada sobre objetos. Basta checar se a apresentação do cara fala sobre classes, objetos, herança e polimorfismo. Especialmente se for nesta ordem.

Uma pessoa que não fala de objetos como componentes que trocam mensagens, especialmente sem mencionar que classes e troca de mensagens são apenas implementações de OO, que é possível e comum ter OO sem elas, não sabe do que está falando. Apenas repete o que leu em algum tutorial, ou que ouviu outra pessoa que leu em um tutorial palestrar.

Como SOA como conceito e buzzword é algo novo, é muito simples enganar as pessoas. Basta subir ao púlpito e falar sobre serviços e mostrar um exemplo de como BPEL realiza um processod e negócios.

Algumas perguntas para desmascarar cretinos:

  • Qual a diferença entre Serviços e Componentes distribuídos?
  • Qual a relação entre eles?
  • Como eu implemento um Serviço?
  • Um Serviço tem Camadas?
  • Por que serviços possuem lógica de compensação e não simplesmente fazem rollback?

Se depender dessas pessoas, mais uma vez estamos caminhando para um buraco.

Casa Conectada

Thursday, July 6th, 2006

Na iminência de comprar um MacBook e eventual rede wireless doméstica, me deparo com o squeezebox. Quanto tempo até termos eletrodomésticos wireless espalhados pela casa?

http://www.slimdevices.com/images/connectiondiagram.gif

Nova Comunidade Brasileira de Ruby

Monday, July 3rd, 2006

Anunciado no GUJ a criação do RubyOnBr, portal nacional sobre Ruby e Rails.

Muito boa a iniciativa. pelo visto o site usa o javaFree CMS, o que mantêm a velha tradição de sites sobre uma tecnologia feita em outra :D

Já estou no fórum.