O verdadeiro significado do Windows Vista!
(fonte: Blog. MacMagazine)
p.s.: post feito a partir de um iMac! 
Monthly Archives: March 2008
Já tinha postado aqui as algumas previsões para SOA em 2008, de acordo com David Linthicum. Desta vez (com algum atraso, sorry), apresento as apostas de de David Chappell chief technologist para SOA da Oracle.
Vamos verificar as dicas de D.Chappell:
- Event-Driven Architectures (EDA) irá, finalmente, se tornar uma opção real para obter realtime insight nos processos de negócio e métricas de negócio
- Service Component Architecture (SCA) será a nova forma como as aplicações SOA deverão ser definidas para suportar as plataformas dos principais vendors de soluções de arquitetura orientada a negócio
- Container “leves” (lightweight containers) terão uma maior utilização. Spring, OSGI e EJB3 continuarão a ser utilizados.
- Aplicações baseadas em Web 2.0 terão uma maior utilização (desenvolvimento) no mundo corporativo.
- Muitas aplicações Web 2.0 irão ter problemas porque o cara que desenvolveu os mashups não trabalha mais na empresa e ninguém tem a menor idéia de como fazer as aplicações funcionarem novamente.
- Por este e outros problemas, uma necessidade por uma Governança com foco renovado irá surgir
Veja esta e outras previsões neste link.
Com vocês mais uma do Geek & Poke:
Enquanto isto no encontro dos CIOs:
- Agora nós temos um SOA. Vocês tem um também?
- (pensando…)
- Um? Nós temos doze!
Pois é, na falta de um SOA, apenas para garantir, tenha logo 12! Com certeza se um é bom, 12 é muito melhor!
SOA Magazine de Março está “no ar”. Na verdade desde o dia 10/Março (desta vez eu é que demorei a informa-los). Na edição deste mês temos os usuais 03 (três) artigos e mais uma parte do texto sobre “Service-orientation and Object-orientation (part II)“, escrito pelo editor da revistas, Thomas Erl .
Um breve resumo e os respectivos links:
1. “Working with SOA and RUP“: segundo a autora, Solmaz Boroumand, RUP tem se mostrado uma metodologia de sucesso para ser empregada na “jornada” em direção à SOA, entre outras coisas, porque provê uma série de disciplinas e práticas exigidas em um ambiente de arquitetura orientada a serviços, tais como modelagem de processos de negócios além da própria orientação a objetos. Esta última não é pré-requisito para SOA, mas o conceito auxilia na implementação. O artigo tem o foco na customização do RUP aplicado em uma implementação SOA (“MSOAM”).
2. “SOA Engineering Misconceptions“: o autor, Ted Barbusinski, lista 09 (nove) erros de entendimento (misconceptions) sobre SOA:
- Erro #1: “O conjunto de soluções SOA que os fornecedores apresentam é Arquitetura orientada a Serviços“
- Erro #2: “O conjunto de soluções SOA que os fornecedores apresentam é a melhor fundação para a Engenharia de SOA“
- Erro #3: “Um ESB é suficiente para termos a Infraestrutura de Serviços“
- Erro #4: “A [boa] performance do meu ambiente SOA será assegurada pela conjunto de solução que comprei“
- Erro #5: “A [boa] segurança do meu ambiente SOA será assegurada pela conjunto de solução que adquiri“
- Erro #6: “Os próprios desenvolvedores irão definir e contruir serviços reutilizáveis“
- Erro #7: “SOA é uma arquitetura centrada em processos“
- Erro #8: “SSL é suficiente para garantir a segurança de minhas mensagens no meu ambiente SOA“
- Erro #9: “Tudo que eu preciso são Web Services“
3. “Refactoring Considerations for Service-Enabling Applications“: de acordo com o autor, C P Jois, se for confirmada a previsão do Gartner e outros institutos de pesquisa de que SOA será a base de 80% dos novos projetos no final do ano de 2008, se faz importante levantarmos algumas considerações sobre a questão dos padrões. O artigo dele faz menção de um destes issues: o refactoring.
Boa leitura!
Nos vários eventos e discussões sobre SOA que participamos nestes últimos 03 anos, inevitavelmente, éramos apresentados a cases reais de implementação de arquitetura orientada a serviços que não passavam de um conjunto de Web Services.
Este “erro” é tão comum que existe até um termo em inglês para designar esta arquitetura que “pretende” ser SOA: JBOWS (Just a Bunch of Web Services, ou apenas uma porção de Web Services). Este termo foi definido pelo Joe McKendrick ainda em 2005 (!).
Muitos arquitetos de integração estão implementando JBOWS, Web Services Integration (WSI) ou qualquer outra coisa e “juram de pés juntos” que isto é SOA. Não é!
Desde que Ronald Schmelzer escreveu um artigo com o título “Why Service Consumers and Service Providers Should Never Directly Communicate“, esta polêmica aumentou e provocou uma boa discussão na blogosfera.
Afinal, por que Service Consumer não deve ser comunicar diretamente com Service Provider?
Por várias razões mas, basicamente porque seu ambiente SOA deve pressupor um ambiente heterogêneo, sujeito a mudanças e com “baixo acoplamento”:
- Baixo acoplamento na Implementação
- Baixo acoplamento no “Contrato” de Serviço
- Baixo acoplamento na “Política” de Serviço
- Baixo acoplamento no Processo
- Baixo acoplamento no Schema de Dados
- Baixo acoplamento na Infraestrutura
- Baixo acoplamento na “Camada” Semântica
Sobre este assunto recomendo este artigo: “The Seven Layers of Loose Coupling” (também no site Zapthink.com).
Qual a Solução? Resposta: “Late-Biding”!
Late-biding significa basicamente que um cliente não está ciente (aware) do seu endpoint (service ou server). Um cliente faria uma requisição a um IP virtual e um “proxy” (também chamado de application delivery controller) verifica o cabeçalho HTTP para determinar o endpoint apropriado . O termo “late” (atrasado) é utilizado porque a decisão de direcionar ao endpoint só é tomada após a requisição do cliente.
- Cliente envia uma requisição para o application delivery controller
- O application delivery controller verifica a requisição e determina o endpoint (server ou pool)
- O application delivery controller direciona a requisição para o endpoint (server ou pool)
No mundo real uma das formas de implementar o late binding é através do uso do WSDL (Web Services Description Language).
- Cliente requisita o WSDL apropriado, opcionalmente de um registry
- Cliente determina o endpoint através de um parsing no WSDL
- Cliente direciona a requisição para o endpoint definido no passo anterior
Mais detalhes aqui.
Conclusão
O “Late-binding” não é a solução para tudo. Existem outras abordagens e em cada cenário devem ser avaliados os prós e contras. Este é um trabalho do arquiteto de integração mas, certamente você deve, sempre que possível, ter em mente os 7 níveis de abstração em seu ambiente SOA e o bom senso para fazer o trade-off correto.
Uma crítica interessante e cuja leitura também recomendo está neste post do blog da Anne Thomas Manes (Burton Group).
Boa sorte!
Comecemos pelo básico.
O que é Data Integration?
a) Novo nome que os vendors deram para ETL
b) Processo que combina dados de várias fontes e entrega para o usuário uma visão unificada destes dados (by Wikipedia)
c) Organizar e reconciliar dados dispesos em sistemas heterogêneos e disponibilizar os mesmos para análise
d) Todas as opções acima (correto!, opção “d”)
Como fica a Integração de Dados em um ambiente SOA
Em 2006 estávamos na fase final de definição da solução de software que seria a base da nossa arquitetura SOA. Recebemos a visita de alguns fornecedores que afirmavam que tinham produtos de integração de dados “SOA compliant“.
O cenário abaixo ilustra de forma simplificada o nosso dilema. Temos o vários sistemas A, B e C, legados ou não; temos os bancos de dados corporativo, e também várias outras fontes de dados: arquivos texto, bases de dados departamentais, planilhas etc. Como todos estes dados irão se integrar em nosso ambiente SOA?
Este é um ambiente típico de qualquer empresa e, se estiver pensando em SOA (como mostrado na figura acima), você precisa achar uma alternativa para integrar todos estes dados.
Qual o problema com as ferramentas de Integração de Dados?
O maior problema é que é estas ferramentas, diferente de uma solução baseada em SOA, não suportam movimentação de dados em tempo real. Vamos dar um exemplo simples:
- o sistema A é uma aplicação antiga (leia-se “legada”) que o seu call-center utiliza para informar aos clientes (tempo real!), por exemplo, o saldo de seu telefone pré-pago
- Quando o cliente finaliza uma ligação a plataforma de pré-pago (qualquer que seja ela) atualiza automaticamente/imediatamente o saldo
- Em seguida o cliente liga para a central de atendimento e deseja saber o saldo atual
Pergunta: seu cliente pode esperar até que o próximo ETL (que ocorre uma vez por dia, certo?!) ou você deve garantir que no momento da consulta o sistema A “dispare” uma consulta (tempo real!) à plataforma do seu serviço de pré-pago, que retorna o saldo daquele cliente? Tudo isto deve ocorrer neste tempo:
- (cliente) “Gostaria de saber meu saldo!”
- (atendente) “Certamente senhora. Você poderia me informar o número do seu telefone?”
- (cliente) “É 99-9999-9999″
- (atendente) “Um momento senhora…”
- (Sistema A) Consulta base do sistemas, recupera e exibe os dados do cliente, ao mesmo tempo em que dispara um processo/serviço que consulta o saldo na plataforma de pré-pago
- (atendente) “Seu saldo atual é R$ 50,0. Posso ajuda-la em algo mais?”
- (cliente) “Não, muito obrigada”
Conclusão
As ferramentas de Integração tem suas qualidades e podem solucionar outros problemas das empresas que precisam, por exemplo, consolidar e movimentar grandes volumes de dados (entre outras funcionalidades).
Uma excelente alternativa é utilizar Web Services para recuperar os dados à medida que os sistemas requeiram estas informações. Claro que existem várias outras questões que devem ser consideradas e o objetivo deste post não é resolver este grande dilema, porém existem soluções simples para um cenário tão comum quanto o descrito acima. Veja a figura abaixo que ilustra esta alternativa:
Primeiro um esclarecimento importante: uma abordagem ágil não está relacionada com qualquer escolha tecnológica ou arquitetura definidas para um projeto.
Como diria Scott W. Ambler, Agilidade é ortogonal, pode ser utilizada em implementações de COBOL em mainframes, projetos simples utilizando Java ou qualquer outra linguagem, serviços etc. O fato de utilizar uma arquitetura orientada a serviços (SOA) é um “mero detalhe”.
Para ter sucesso na adoção de uma abordagem ágil para os desenvolvimentos em/para um ambiente SOA, é necessário, entretanto, um foco na arquitetura corporativa. É o que chamamos de “big picture“.
Não é necessário ter toda a arquitetura detalhada, documentada, todos os sistemas mapeados… …isto vai contra o que prega a metodologia ágil (vide o Agile Manifesto). Entretanto, quando se trata de SOA, é necessário ter um “norte”, um blueprint de como os processos de negócios serão implementados, dentro da concepção de orientação a serviço, base de SOA.
Eis uma série de estratégias sugeridas por Scott Ambler:
- Dê prioridade para desenhar um modelo básico da arquitetura corporativa. Não tente modelar e detalhar tudo; além de dispender um tempo precisoso, os arquitetos não se atentaram para os detalhes neste momento.
- Ponha em prática em um projeto real. Isto irá demonstrar que sua estratégia funcionará e você construirá a base para montar novos times “ágeis”.
- “Espalhe” arquitetos de serviço nos times de desenvolvimento. Isto irá garantir que as demais equipes estão seguindo a nova abordagem, além de trazer todo mundo para o mesmo barco (importante ter o envolvimento e, melhor, o comprometimento das equipes).
- Trate a questão do reuso de forma diferente. O desenvolvimento ágil às vezes não tem espaço para grandes discussão sobre o reuso; e reuso é um ponto “nelvrágico” e um dos pilares de SOA. Um arquiteto com foco no reuso é uma opção para diminuir os riscos.
Como vivo este dilema na empresa onde trabalho, este blog vai tratar deste assunto várias vezes. Volte sempre! Abraços,
- Davi
p.s.: a imagem que ilustra este post é do filme “Speed Racer“, a mais nova produção dirigida pelos irmão Wachowski (Matrix). Deve estrear em Maio/2008
A Red Hat/JBoss dá mais um passo para consolidar a sua iniciativa “Enterprise Acceleration“, anunciado em 13/Fev/2008.
Desta vez a Red Hat adquiriu a empresa Amentra, uma empresa de 140 funcionários, com vários escritórios nos EUA, e que é especializada em serviços SOA (claro) e gerenciamento de processos de negócio.
Um pouco mais sobre a iniciativa “Enterprise Acceleration“:
- Como o próprio nome diz tem como objetivo acelerar a adoção do middleware e BPM open-source da JBoss nas empresas
- Em 2015 esperar ser um doa maiores players no fornecimento de middleware
- Produtos:
- application server
- enterprise service bus (ESB)
- application development frameworks
- business process management
- rules and workflow processing
- data integration and
- portal capabilities
Processo de Desenvolvimento Ágil na minha opinião é mais do que uma “moda passageira”. É, como SOA, um estilo de vida que decidimos adotar.
Creio que, de fato, os frameworks, ferramentas e idéias propostos pelas metodologias ágeis, imprimem a velocidade necessária para entregarmos boas soluções de software com qualidade e em um prazo menor.
Bill Kennedy é um consultor canadense que atua na área de contabilidade (isto mesmo, contabilidade). Quero compartilhar com vocês algumas vantagens do desenvolvimento ágil que Bill escreveu neste post (meus comentários estão em azul):
- Cliente satisfeito através de liberações de software realizadas de forma mais rápida (qual cliente não quer o software entregue ASAP?)
- Novas versões são entregues com maior frequência: semanas e não meses (lembrem-se das iterações rápidas)
- Software Funcionando é o principal indicador do progresso do seu trabalho (isto é fato!)
- Requisitos que mudam em fases avançadas do projetos não são o “fim do mundo” (claro que depende da mudança; sejamos realistas: todo projeto tem mudança de requisitos; vamos aceitar esta dura realidade e e adotar um processo em que isto não tenha um impacto tão grande)
- Cooperação diária e “de perto” entre o pessoal de negócio e TI (o desenvolvimento ágil incentiva esta maior interação)
- Conversações face-a-face ainda é a melhor forma de comunicação (longos e-mails e documentos detalhados podem ser evitados com uma simples conversa diária de 30 minutos)
- Simplicidade (filosofia KISS, mantenha tudo sempre simples)
- Times que se auto-organizam (as equipes tem maior autonomia, nada de estruturas rígidas; confie na sua equipe!)
- Fácil adaptação às mudanças (novamente, requisitos e ambientes podem mudar a qualquer momento; uma equipe que tem a “agilidade no sangue” pode adaptar-se melhor às estas mudanças)
Uma imagem vale mesmo por mil palavras. Interface da Apple, do Google e dos nossos sistemas.
(fonte: Bits & Pieces)
