Comento em breve o evento mas os slites já estão disponíveis:
Archive for the ‘soa’ Category
Palestras do ERECOMP-AL
Monday, March 19th, 2007Rumo ao ERECOMP 2007
Thursday, March 15th, 2007Como já falamos aqui, estou indo apra o ERECOMP 2007. Estou bem ansioso para este evento, nunca palestrei no nordeste e não conheço o público.
O keynote será uma apresentação que está na manga há um bom tempo mas nunca tinha a oportunidade de executar. É bem diferente do meue stilo normal de apresentação, pelo menos graficamente. Acho que o livro do Atinkson teve efeito retardado mnas quem viu gostou.
A segunda é uma releitura da palestra de CBD x SOA que foi apresnetada ano passado. Acho que o principal diferencial para esta é estar neste exato momento vivendo os problemas de se implantar uma arquitetura SOA em um ambiente onde já existe um conjunto de sistemas e uma cultura formada.
Bom, que for lá por favor não se acanhe. O melhor destes eventos é a experiência trocada.
Acorda, Maria Bonita…
Tuesday, March 13th, 2007Lendo a revista Mundo .Net deste mês pensei sobre o estado atual das duas maiores plataformas de desenvolvimento modernas, Java e Microsoft .Net. Infelizmente estou tendendo a creditar em uma coisa: A Microsoft aprendeu, a comunidade Java se acomodou. É impressionante como a MSFT tem investido em ferramentas e plataformas interessantes. A estratégia que pude perceber é mais ou menos assim:
- Cria-se uma estrutura fundamental baseada em boas tecnologias e plataformas, geralmente copiadas de casos clássicos de sucesso
- Pessoas com nível técnico alto utilizam esta base para criar coisas muito interessantes
- Pessoas com nível técnico baixo, grande maioria nas duas plataformas, podem utilizar ferramentas burrotizantes que criam apenas o básico que elas acham que precisam
Dado que as pessoas citadas no item (2) são raridade (eu conheço duas, todos vindos de Java/C++),a estratégia de marketing toda foca no povo do item (3). Para o item (2) (para utilizar um termo MSFT: os Elvis e Einsteins) o marketing é baseado em altos salários e oportunidades muito boas em um mercado saturado de arrastadores de componentes (Morts). Com Java foi exatamente o contrário: a linguagem atingiu o jet-set da computação mas logo se banalizou. Einsteins criaram uma plataforma altamente produtiva e de qualidade impressionante, mas logo Mort caíram em cima, fugindo de Delphi e VB 6.0.
Se o programador mediano Java não tivesse tantos problemas no passado com a Microsoft ele facilmente seria seduzido pela plataforma. Ali tem tudo que ele precisa para fazer seus CRUDs (ou seus grudes…). E se Elvis não tivessem tantos problemas com código proprietário e uma plataforma de um vendedor só eles certamente estariam esmagando cabeças dos programadores Java ao comentar como a plataforma .Net está ficando cada vez mais aberta, cada vez mais flexível, cada vez mais… parecida com sistemas em UNIX.
É sério. Não vou nem citar o MS PowerShell, basta olhar como é feito o deployment em .Net e comparar com um sistema UNIX. Ok, eu sei que é muito mais fácil alguém ter visto um deployment .Net que um UNIX então deixe-me tentar explicar com poucas palavras como geralmente é feito um sistema: cada módulo geralmente é implementado como um programa separado (programa mesmo, tipo uma classe com public static void main(String[])), estes programas conversam entre si utilizando diretivas de IPC. O SO (Linux, HP-UX, Solaris, etc.) controla estes programas (feitos em C/C++, PERL, Python, Ruby, Bash, TCL…).
Se você for esperto já fez uma analogia com um servidor de aplicações J2EE. SIM! Os servidores de aplicação vieram solucionar problemas deste modelo, trazendo um nível de padronização (e racionalidade…) para o processamento de transações distribuídas, segurança, persistência, etc. É para isso que Java EE foi criado, infelizmente as pessoas esqueceram ou não tiveram contato com um ambiente não padronizado e não entendem o que é, por exemplo, um EJB. Ok, mas o problema é que o servidor de aplicações é um mundo a parte, e um mundinho bem fechado.
Tem uns dois anos eu trabalhava para uma empresa líder mundial do setor de sistemas para redes de telefonia celular. Esta empresa possui até hoje uns 90% da base de código em C, rodando em Solaris e outros UNIXes. O sistema principal era exatamente como descrevi: um bando de processos em C que se comunicavam via pipes, filas de arquivos e memória compartilhada. parece uma zona, não? Nada de JMS para mensageria, nada de JAAS para segurança, nada de nada.
Pois a grande vantagem deste sistema não era a velocidade, como defendiam os xiitas locais. A vantagem era a flexibilidade. Quando uma correção era implementada o meu colega de baia enviava para o cliente um patch contendo apenas os processos modificados. Quando eu corrigia uma linha de código tinha que mandar um EAR de 10 megabytes. O primeiro nível de suporte era capaz de fazer scripts em PERL e Bash que corrigiam problemas quando aconteciam e automatizavam tarefas para o programa em C. para o programa em java só o próximo release implementaria a mais boba das tarefas, ou uma famosa dedada no banco de dados (um script SQL).
Claro que a culpa é dos programadores (não me excluo) que não se prepararam para sistemas abertos e extensíveis (anos depois eu consegui fazer alguns progressos nesta área e sumarizei em uma palestra), mas o maior problema é na forma que um Application Server é fechado, lacrado. Mesmo os servidores mais modernos ainda contam com abertura precária se comparados aos bons e velhos sistemas UNIX dos anos 70/80/90.
E neste ponto a Microsoft vai na frente, por incrível que pareça. Sua plataforma está baseada em Camadas que são unidas pelo SO, é como se a pessoa pudesse implementar um sistema UNIX utilizando um framework de workflow, persistência, apresentação, comunicação remota, transações e segurança unificado, não importa qual linguagem (e .Net é multilinguagem desde sempre).
Não, eu não estou falando para você migrar para .Net. O que eu estou dizendo é que Java está trilhando caminhos muito perigosos, como desenvolvedores nós temos que ficar de olho. Cuidado com ferramentas milagrosas e,principalmente, cuidado com caixas fechadas (ainda que sejam Open-Source).
E os Einsteins? Eles brincaram com Java mas voltaram para LISP.
RESTa Muito a Debater…
Thursday, February 22nd, 2007O DQO continua com a conversa sobre REST x WS-*.
Na argumetnação do porque-você-não-pode-simplesmente-ignorar-ws-* entram dois pontos centrais:
a) WSDL
b) REST é para HTTP apenas
Quanto a (a), eu também tinha a impressão que uma linguagem de definição de interfaces é fundamental mas mudei de idéia. Essas IDLs geralmente são muito complexas (desde CORBA) e isso está intrínseco ao fato de que devem definir tipos simples, tipos complexos, tipos do usuário, etc. de maneira auto-contida. Uma lignaugem de tipos genérica não tem como ser muito simples.
Quanto a ser editado manualmente, EJBs também foram criados apra serem editados apenas por ferramentas. Assim como eu tenho que editar EJB-Jar.XML todo santo dia eu tenho que editar WSDLs. temos um padrão aqui? Fora que os bindings SOAP para linguagens como PERL são…sofríveis. Na melhor das hipóteses. Enquanto isso qualquer coisa que faça HTTP e trate um formato como XMl está pronto para REST.
O ponto é que se eu tenho um conjunto de primitivas simples como PUT, GET, POST e DELETE eu não rpeciso de muito mais. parsers XML, YAML, JSON existem aos milhares e basta ser bem documentado para saber o que uma estrutura de dados representa.
Quanto ao ’ser HTTP-only’, sim, é uma limitação que pode não permitir o uso de REST out-of-the-box em alguns cenários. Mas SOAP, apesar de não ser dependente de transporte, não possui até onde eu sei especificações formais para o uso de JMS ou qualquer outra coisa que não seja HTTP. O que existe são implementações proprietárias destes transportes, e nada impede a criação de uma bridge JMS-HTTP, até via ESB.
Acho que o único motivo técnico real para o uso de SOAp é a abundância de ferramentas e suporte em diversos produtos. Em termos de integração, REST parece fazer muito mais sentido na maioria dos casos.
REST vs WS-* no InfoQ
Friday, February 16th, 2007Começa um debate com base em uma entrevista publicada no InfoQ. Sanjiva Weerawarana defende as especificações que ajudou a criar, a famosa pilha WS-*.
Do outro lado, um oponente que até pouco tempo atrás pouco se ouvia falar sobre e agora temos até uma JSR. Não que você precise disso para utilizar REST, muito pelo contrário. Para usar REST tudo que você precisa é de algo capaz de fazer uma requisição HTTP e tratar o formato dos dados, seja XML, seja JSON, seja YAML ou o que quer que seja.
Tudo isso sem reinventar protocolos, sem ignorar as características do HTTP, sem criar mil e um consórcios para produzir duas mil especificações redundantes entre si. Mais sobre o tema em breve.
ERECOMP/AL 2007
Monday, February 5th, 2007Boa hora para mencionar que vou palestrar no 1o Encontro Regional de Estudantes de Computação de Alagoas. Os temas são SOA x CBD e Web 2.0.
Além de assuntos em voga são dois temas que estão bem presentes no meu dia a dia atual.
Gerenciando Dependências com Uncle Bob
Monday, February 5th, 2007A melhor coisa desse lance todo de vídeo em flash barato, portais de conteúdo em vídeo, screencasts, etc. é que nós, pobres brasileiros afastados de tudo que é legal em tecnologia, podemos assitir palestras e não apenas pegar os PDFs.
| Nessa onda o InfoQ tem uma apresentação do Uncle Bob simplesmente genial. Robert C. Martin sempre traz a tona a necessidade do gerenciamento de dependências e o bom empacotamento de software. Seu livro mais marcante tem páginas e páginas sobre o assunto que, realmente, é algo complexo. |
Recentemente eu lidava com 3 grandes sistemas legados, fracamente relacionados entre si e construídos em paralelo. O problema é que a relação forma a coisa mais odiosa que se pode ter no gerenciamento de dependências: dependências cíclicas!
A coisa surgiu como um projeto dividido em dois módulos.
Projeto waterfall, na primeira mudança foi ‘dado um jeitinho’ e uma funcionalidade que o backoffice precisava já estava disponível no sistema…
Em breve surgiu o outro projeto no horizonte e o arquiteto resolveu que haviam funcionalidades de um que podiam ser aproveitadas no outro. Pena que ele não olhou para os diagramas UML que desenhou com tanto carinho.
Mas tudo bem. Tudo seria resolvido com a versão 2.0 do projeto. Basta fazer uns ajustes aqui, reutilizar aquilo ali…
Neste ponto o projeto ficou ingerenciável. Simplesmente não se podia tratar um bloco de software isoladamente, era tudo parte de um grande emaranhado de componentes frágeis que compartilhavam código e possuíam nível de acoplamento absurdo. Passar um componente para produção indicava passar e testar todos os componentes. Pior que isso: para subir a versão 2.0 do projeto precisávamos manter a primeira versão porque ela era uma dependência transitiva!
Corrigir este problema não é tarefa simples, mas Uncle Bob nos dá algumas regrinhas muito úteis:
- REP - Reuse-Release Equivalnece Principle: Tudo que é criado apra ser reutilizável deve ser empacotado corretamente. Software criado para reuso deve ser projetado para isso do início, de maneira lógica. Não deve haver código não-reutilizável num pacote reutilizável.
- CRP - The Common Reuse Principle: Classes num pacote são reutilizadas em conjunto, se você reutiliza uma reutiliza todas. Uma pacote deve ser uma unidade atômica, as classes que estão dentro dele devem fazer sentido apenas se usadas em conjunto. Não devem haver classes utilizadas isoladamente num pacote reutilizável, a unidade de reuso é o pacote, não a classe.
- CCP - The Common-Closure Principle: Uma generalização do Single Responsibility Principle (SIP). Para o SIP uma classe deve ter apenas um motivo para ser alterada, se mais de um tipo de mudança no sistema afeta a classe provavelmente ela pode ser dividia em mais de uma, ela representa conceitos demais. O mesmo se aplica para pacotes. Um pacote também deve seguir o Open-Closed Principle (OCP) e se proteger de mudanças ao mesmo tempo que está aberto à extensão.
- SDP - The Stable-Dependencies Principle: Um pacote que se espera ser volátil (mudar facilmente) não pode ser dependência de um pacote que se espera estável (mudar quase nunca). Pacotes estáveis devem depender apenas de pacotes estáveis. Pacotes voláteis podem depender de outros voláteis, mas idealmente devem também depender apenas de pacotes estáveis. Muitos pacotes voláteis em uma corrente de dependências causa um estrago muito grande no ‘efeito dominó’.
- SAP - The Stable-Abstractions Principle: Um pacote deve ser tão abstrato quanto estável. É mais que certo que quanto mais próximo uma abstração chegar da realidade mais facilmente ela muda. Um pacote abstrato (e neste caso isso geralmente significa classes abstratas mesmo) é mais estável porque não se rpende a detalhes de implementação.
Aplicando essas e outras técncias fatalmente chegamos a uma situação ainda ruim, mas ao menos gerenciável.
E finalmente ao que consideramos aceitável.
Tudo ao gasto de alguns meses sem desenvolvimento de coisas novas, só arrumando a bagunça. Note que este sistema não foi originalmente criado por amadores e sim por uma consultoria top top top multinacional.
Acontece que, como um dos envolvidos no projeto original me disse durante o projeto “essas coisas funcionam muito bem na teoria mas a prática é outra”, logo antes de afirmar que nunca lera nada sobre gerenciamento de dependências e “trabalhava muito bem sem isso”.
Será que é mesmo a teoria que possui problemas?
Eric Evans no infoQ
Thursday, January 4th, 2007Ok, notícia velha, me critiquem por ser lerdo, mas não posso deixar de comentar esta excelente entrevista do Eric Evans no infoQ.
|
Com outro trecho mais adiante…
Combine that with the imperative to produce Web UIs mediated by http and html (which were not designed for that purpose) using quite primitive, first-generation tools. During that period, creating and maintaining a decent UI became so difficult that little attention was left for design of complex internal functionality. Ironically, at the very moment that object technology took over, sophisticated modeling and design took a heavy hit.
Sintetizam as desculpas (esfarrapadas) para se produzir aplicações baseadas em objetos burros nos últimos anos.
For example, SOA, when it is used well, provides us a very useful way of isolating the domain.
Este é outro ponto interessante. Muitas vezes vemos SOA sendo utilizado como desculpa para modelos de objetos burros e fracos, ou até mesmo para uma volta ao Dicionário de Dados. Serviços não trocam, ainda, objetos inteligentes e sim estruturas de dados mas dentro do serviço nós temos um sistema OO e, como tal, deve ser construído utilizando objetos!
E lembrem-se: objetos são dados e comportamento num mesmo conceito.
But back when the J2EE frameworks first came out, it utterly buried that basic expressiveness under mountains of framework code. Following the early conventions (such as EJB home, get/set prefixed accessors for all variables, etc.) produced terrible objects.
Isso eu comentei bastante no artigo sobre VO/BO.
Rails has generated a lot of excitement because it finally seems to make creation of Web UIs as easy as UIs were back in the early 1990s, before the Web. Right now, this capability has mostly been applied to building some of the vast number of Web applications which don’t have much domain richness behind them, since even these have been painfully difficult in the past. But my hope is that, as the UI implementation part of the problem is reduced, that people will see this as an opportunity to focus more of their attention on the domain. If Ruby usage ever starts going in that direction, I think it could provide an excellent platform for DDD. (A few infrastructure pieces would probably have to be filled in.)
Este trecho toca na minha crítica #1 com Rails: domínios fracos baseados em Bancos de Dados. A linguagem Ruby é tão cheia de vantagens que a limitação imposta pelo modelo CRUD do Rails me irrita profundamente. Ok, você não precisa ter um modelo fraco em Rails, mas você também não precisa ter um modelo fraco ao usar EJB 2.1, VB 6 ou Delphi e isso nunca evitou este problema.
More out on the cutting-edge are the efforts in the area of domain-specific languages (DSLs), which I have long believed could be the next big step for DDD. To date, we still don’t have a tool that really gives us what we need. But people are experimenting more than ever in this area, and that makes me hopeful.
Outro ponto muito bom. DSLs são iminentes mas as ferramentas simplesmente ainda não chegaram lá. O grande perigo é que o conceito está se tornando popular mas não existem ferramentas. Algo semelhante aconteceu com OOP, as linguagens eram procedurais mas todo mundo falava em OO, gerando a célebre consideração sobre C++ que eu traduzo mal e porcamente abaixo:
C++ é como sexo para adolescentes
- Está na sua cabeça o tempo todo.
- Todo mundo fala disso o tempo todo.
- Todo mundo acha que todo mundo está fazendo o tempo todo.
- Quase ninguém está fazendo de fato.
- Os poucos que fazem:
- estão fazendo mal e porcamente.
- têm certeza que da próxima farão melhor.
- não fazem com segurança.
- Ainda assim todo mundo fala sobre como estão tendo sucesso com isso, ainda que uns poucos tiveram qualquer nível de sucesso
Bom, não percam!
Da Série ‘Mãe Diná’
Friday, December 29th, 2006Ano passado eu postei aqui o que eu acreditava que importaria no mundo da tecnologia em 2006.
Antes de postar a versão 2007 da minha futurologia pessoal vamos, ao contrário do que fazem os videntes de televisão, avaliar as besteiras que eu disse ano passado.
| Ruby on Rails: O framework para aplicações web em Ruby realmente fez sucesso este ano. Sua influência no mundo do desenvolvimento pode ser vista nos novos frameworks para plataformas como Java e .Net e mesmo com tanto preconceito contra o que não é ‘enterprisey’ podemos ver esta plataforma decolando e ocupando espaço de PHP. Vários livros, inclusive brasileiros, lançados. | |
| Ruby: A linguagem Ruby, no entenanto, não decolou como esperava. Parece que realmente o que importa hoje é a velocidade de desenvolvimento e a disponibilidade de bibliotecas e componentes prontos, poucos prestam atenção no que a linguagem consegue fazer quando bem projetada. Talvez ano que vem. | |
| Migrações: Java 5 e EJB 3.0 Tirando quem não tem opção, os novos produtos já estão sendo desenvolvidos para Java 5. Existe um buraco de profissionais que dominem EJB 3.0 que deve ser preenchido em breve. Com o fim do suporte oficial ao Java 1.3 este movimento ficará mais intenso em 2007. | |
| Linguagens de JVM Cada vez mais alardeadas como a maior novidade das novas versões (>6) de Java. Infelizmente Java 6.0 atrasou bastante e a maior parte do hype vai para o próximo ano. | |
| Linguagens de Domínio (DSLs) Quando preparei a minha palestra do Rio Java Summit 2006 sobre linguagens de JVM e DSLs foi muito compkicado encontrar material. Tive que recorrer basicamente à materiais com mais de dez anos de idade e experiência pessoal. Digite Domain Specific Languages no Google e veja que isso mudou bastante hoje, ainda assim ainda não chegou no mercado. A falta de livros continua. | |
| Open Solaris Acho que ninguém mais lembra que o Solaris esté sendo aberto. Péssimo marketing da Sun, infelizmente. | |
| Celulares Apesar do caos entre as operadoras, os aparelhos celulares estão ganhando mais poder de fogo e ficando cada vez mais baratos. | |
| Web 2.0 Ninguém ainda sabe direito o que é Web 2.0 mas já se ganha dinheiro com ela. A recente onde de mashups aposentando interfaces SOA é algo que merece atenção. |
No final das contas acho que não errei por muito. Futurologia nunca funciona mesmo. Em breve os wild guesses para o ano de 2007.
Presente, Passado e SOA
Sunday, December 10th, 2006Bom, semana passada foi dai da minha apresentação no evento sobre SOA do IQPC, como vocês já sabem. Foi muito interessante preparar e ministrar essa palestra principalmente porque fugia do lugar comum que é apresentar uma nova tecnologia ou mostrar uma ferramenta, tão comum em exemplos deste tipo.
Minha palestra teve como foco desmistificar as características do SOA, mostrando que elas já estavam disponíveis, especificadas e documentadas em sua maioria há uma década. Como não há muito material sobre esta comparação (estes slides são provavelmente a coisa mais direta sobre essa comparação que existe hoje na Internet) precisei tirar a poeira dos livros sobre componentes e procurar conceitos comuns na parca literatura que se pode levar em conta sobre SOA (ou seja: nada de papers de fornecedores apresentando sua gloriosa ferramenta gráfica, estes sim abundantes).
|
As conclusões estão nos slides, pena que a palestra é mais um bate-papo e não foi gravada, mas acho que dá pra tirar algo de bom deles.
O mais interessante na verdade foi conversar com as pessoas. A maioria era de gerentes de grandes empresas públicas, bancos e alguns funcionários de grandes empresas de software. As empresas destas pessoas as enviaram para tentar entender o que é SOA e como adotá-lo na empresa. Eu não pude acompanhar o evento todo e não sei se as pessoas conseguiram informações sobre o que queriam: qual o caminho para migrar para SOA? |
Uma das comparações que eu faço entre SOA e CBD é que CBD é, na minha opinião, ingênuo. A impressão que se tem ao ler sobre o uso de componentes é que é possível utilizar a técnica de maneira bem gradual, indo aos poucos transformando seus sistemas em componentes distribuídos. SOA é bem mais agressivo, criando cascas de serviços sobre os sistemas num tempo muito curto.
Ao mesmo tempo, não sinto nos vendors compromisso com isso. A maioria do material que vi neste evento e em qualquer outra fonte é sobre como usar ferramentas e técnicas para gerenciar e orquestrar serviços que já existem, poucas coisas falam do dilema que é transformar sistemas em serviços.
|
Este é um bom tópico para atacar numa próxima oportunidade. Nos últimos meses venho constantemente lidando com a transformação de sistemas legados em serviços ou ainda com a mudança arquitetural de sistemas que estão em desenvolvimento para este modelo.
A impressão que tive é que com a quantidade de dinheiro que se está investindo em SOA hoje não dá mais pra chamar de futuro, mas de presente. Claro que há um problema muito grande aí: Este foi o mesmo cenário, por exemplo, com EJBs. |
Eu espero sinceramente que tenhamos aprendido a lição e que estudemos os conceitos por trás das coisas antes de sair por aí implementando sistemas que não funcionam utilizando ferramentas caríssimas.