/pub/SOA/davisilva

Novo Blog no Ar!

noreply@blogger.com (Unknown) — Wed, 06 Feb 2008 13:53:00 +0000

"SOA, Simples Assim!" é a nova "casa" deste blog. Manterei este no ar por algum tempo e solicito a todos vocês que atualizem seus leitores de RSS e bookmarks para este novo endereço:

http://soasimples.com/blog

RSS: feed://soasimples.com/blog/?feed=rss2

Apesar de usuário do Blogger desde o início (antes mesmo da aquisição pelo Google), o WordPress tem funcionalidades muito interessantes e "não tive escolha" :-).

O objetivo continua o mesmo: "traduzir" da forma mais simplificada possível (!) os conceitos da arquitetura orientada a serviços (SOA), além de trazer notícias, dicas de livros e sites sobre esta arquitetura e tecnologias relacionadas (BPM, BAM, ESB, Web Services etc.).

Visite o novo Blog, deixe sua opinião, comentários, críticas... ...a "casa" é sua também!

Grande abraço! Davi

WS02 e Soluções para Open-Source SOA

noreply@blogger.com (Unknown) — Tue, 05 Feb 2008 03:49:00 +0000

WSO2 é um companhia baseada no Sri Lanka que desenvolve middleware open-source. Foi fundada a pouco mais de 2 anos atrás por Sanjiva Weerawarana, um ex-IBM que trabalhou (nos EUA) em vários projetos (Apache SOAP, a definição do WSDL, definição do BPEL etc) e decidiu desenvolver soluções abertas a partir deste país da Ásia.

Entre outros produtos e frameworks a empresa desenvolve:

Enterprise Service Bus: ESB "leve" baseado no Apache Synapse
Web Services Application Server: Web services engine powered by Apache AXIS
Mashup Server: plataforma baseada em Javascript que promete deploys rápidos de Web Services mashups

A lista completa de produtos está aqui.

A documentação do WSO2 ESB pode ser acessada neste Wiki que foi desenvolvido para a comunidade.

ESB: Mitos e Principais Funcionalidades

noreply@blogger.com (Unknown) — Mon, 04 Feb 2008 22:03:00 +0000

O Enterprise Service Bus (ESB) é (e será) um tema recorrente neste blog. Neste artigo, Dave Chappell, um dos criadores do conceito de ESB, trata de 10 mitos sobre o Enterprise Service Bus que precisam ser "desmascarados".

Não vou entrar em detalhes sobre cada um deles. Abaixo listo alguns deles:

Mito #1: ESB não é um novo nome para o EAI (Enterprise Application Integration)
Mito #4: ESB não é um pattern e muito menos um produto. ESB é um conceito que pode ser implementado de várias formas. Vide este post sobre a definição de ESB
Mito #5: ESB "compete" com servidores JAVA EE. ESB é complementar e se integra (deve se integrar) a Java Application Servers.
Mito #9: ESB serve apenas para "conectar" sistemas e não possui interface para implementar processos de negócio. Atualmente, qualquer ESB provê uma ferramenta/front-end para "desenhar" os fluxos dos processos. Não confundir com ferramentas de BPEL.

Entender qual o propósito da sua sua ferramenta de ESB é fundamental para "delegar" ao ESB as tarefas às quais ele foi projetado para implementar.

Novamente, da Wikipedia, temos as principais features do ESB:

1. it is an implementation of Service Oriented Architecture
2. it is usually operating system and programming language agnostic; it should work between Java and .Net applications, for example
3. it uses XML (eXtensible Markup Language) as the standard communication language.
4. it supports Web services standards
5. it supports messaging (synchronous, asynchronous, point-to-point, publish-subscribe)
6. it includes standards-based adapters (such as J2C/JCA) for supporting integration with legacy systems
7. it includes support for service orchestration & choreography
8. it includes intelligent, content-based routing services (itenerary routing)
9. it includes a standardized security model to authorize, authenticate, and audit use of the ESB
10. it includes transformation services (often via XSLT) between the format of the sending application and the receiving application, to facilitate the transformation of data formats and values
11. it includes validation against schemas for sending and receiving messages
12. it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
13. it can conditionally route or transform messages based on a non-centralized policy - meaning that no central rules engine needs to be present
14. it is monitored for various SLA (Service-Level Agreement) thresholds message latency and other characteristics described in a Service Level Agreement
15. it (often) facilitates "service classes," responding appropriately to higher and lower priority users
16. it supports queuing, holding messages if applications are temporarily unavailable
17. it is comprised of selectively deployed application adapters in a (geographically) distributed environment

HP e Governança SOA

noreply@blogger.com (Unknown) — Tue, 29 Jan 2008 01:22:00 +0000

HP anunciou hoje um conjunto de software de governança e serviços relacionados que tem por objetivo acelerar a adoção de SOA ao mesmo tempo em que reduz os riscos potenciais na adoção desta arquitetura.

Em 31/12/2007 a HP foi posicionada no "quadrante mágico" do Gartner Group na categoria de empresas que possuem solução de Governança SOA (Magic Quadrant for Integrated SOA Governance Technology Sets, 2007) ao lado da IBM, Software AG, Progress Software, SOA Software e AmberPoint, entre outras.

Todos sabemos que a Governança é fator determinante de sucesso para qualquer iniciativa SOA na sua empresa.

Mas o que é Governança SOA?
Ainda de acordo com o Gartner, "Governança SOA está relacionada com a garantia de que os ativos de software e artefatos da sua arquitetura estão operando como esperado e dentro de um certo nível de qualidade".

Segundo o livro "SOA Compass" (IBM Press, 2005),

Governança provê uma estrutura para priorizar e suportar os objetivos de negócio da empresa nos níveis estratégicos, funcional e operacional. O modelo de governança define"o que fazer", "como fazer", "quem deve fazer" e "de que forma isto deve ser medido". Define também as regras,processos, métricas, e arranjo organizacional necessários para um efetivo planejamento, tomada de decisão, orientação e controle de todo esforço em direção à SOA para atingir as demandas do negócio e os desafioscolocados como alvo.

De quem é a responsabilidade de definir a Governança SOA?
Time de projetos de SOA

Quais as questões-chave que podem auxiliar na definição da estrutura de Governança?

Que mudanças no negócio a empresa espera realizar com SOA? Uso otimizado da estrutura atual a um custo mais baixo, novos negócios...?
Quais papéis, responsabilidades, estruturas e procedimentos são necessários para realizar priorização denegócio e que TI tenha o investimento, planejamento e tomada de decisão necessários para realizar taisimplementações?
Como você pode desenvolver conhecimento e competência na liderança?
Quais princípios e orientações são necessários para otimizar o alinhamento de TI e do negócio?
Qual a forma apropriada para estruturar o relacionamento TI-e-negócio ao mesmo tempo em que mantém aconsistência e flexibilidade que permitirão a organização uma rápida adaptação às mudanças
Qual o nível apropriado de standardization de serviços, a definição de serviços e a descrição dos mesmos?
Como controlar e medir serviçoes e provedores de serviço? Quais processos-chave de negócio nós precisamos monitorar?Quem deverá monitorar, definir e autorizar mudanças para os serviços existentes?
Como você decide qual a estratégia de implementação dos serviços?

O que é ESB?

noreply@blogger.com (Unknown) — Sat, 26 Jan 2008 10:51:00 +0000

Primeiro, ESB é o acrônimo de Enterprise Service Bus (Barramento de Serviços Corporativos, em uma tradução livre). É um componente fundamenta na arquitetura orientada a serviços (SOA) e, por este motivo, é importante conhecermos qual o propósito e qual seu papel no desenho de sua solução SOA.

Hoje, a pesquisa de "ESB Definition"no Google irá apresenta mais de 46,000 links. Apresento aqui apenas 05 (cinco) que, na minha opinião, dão a idéia correta do que seja um ESB.

A primeira definição, claro, vem da Wikipedia.

Um ESB geralmente provê uma camada de abstração acima de um sistema de mensageria corporativa, que permite aos arquitetos de integração explorar todas as possibilidades e benefícios deste messaging system sem a necessidade de escrever código.

Ao contrário da abordagem tradicional da Enterprise Application Integration (EAI), que utiliza a arquitetura monolítica de hub and spoke, os fundamentos do ESB são baseados na decomposição de processos de negócio executando de forma "harmoniosa".

ESB não implmenta service-oriented architecture (SOA) porém oferece as funcionalidades necessárias para implmentar esta arquitetura. ESB não é, necessariamente, baseada apenas em web-services.

David Chappell é simplemente o "guru" e um dos "inventores" do conceito de ESB. Ele é o autor do livro "Enterprise Service Bus" em 2004 (foto ao lado). Atualmente é o líder de SOA na Oracle. De acordo com ele,

Um ESB é "backbone altamente distribuido" no qual a arquitetura orientada a serviços (SOA) é contruida.

A definição de ESB inclui os seguintes pontos:

* Uma arquitetura de serviços distribuidos, que inclui um modelo de container leve para "armazenar" componentes de integração como serviços remotos
* Um backbone de mensageria corporativa que oferece entrega confiável de mensagens entre aplicações e serviços
* Transformação de dados (XML)
* Orquestração de serviços e roteamento inteligente de mensagens baseada em seu contexto
* Framework de segurança flexível
* Infraestrutura gerenciável que permite a configuração, deployment, monitoração e gerência dos serviços remotos.

IBM SOA Foundation - Architecture Overview, whiter paper. Este é um dos melhores papers sobre o básico de SOA.

O Barramento de Serviços Corporativos (ESB) é parte da arquitetura lógica de SOA. Sua presença na arquitetura deve ser transparente para os serviços de suas aplicações SOA. Entretanto, a existência de um ESB é fundamental para simplificar o esforço de "invocar" os serviços. Detalhes como localização e qual o caminho que a requisição de um serviço deve fazer na rede são de responsabilidade do ESB e não precisam mais fazer parte do código do serviço.

Eric Bruno, escreveu um excelente artigo sobre ESB. Já postei aqui no blog. Reproduzo abaixo a tradução livre do trecho em que ele define o ESB.

Um Enterprise Service Bus é um framework que possui várias funcionalidades: escolha e use. Por exemplo, você pode utilizar apenas parte das features e ignorar as demais que não fazem sentido para a solução proposta pela arquitetura que você projetou. De qualquer forma, um "bom ESB" deve ter, pelo menos, estas características:

Ter um insfraestrutura de mensageria robusto e confiável
Possibilitar desenvolvimento de sistemas baseados em em arquitetura orientada a serviços (parece óbvio, mas não é; pergunte aos seus fornecedores como o ESB deles permite este tipo de implementação)
É fortemente baseado em XML
Suporta padrões de Web Service (e.g. SOAP)
É independente de plataforma (muito, muito, muito importante)
Suporta transações e tem features de segurança
E por fim, mas não menos importante, utiliza protocolos padrão e tem integração com "legados"

Cerveja ESB? Sim, ela existe. É uma cerveja tipo Ale da Redhook. Ganhou a medalha de ouro em 2006 no "North American Beers Award".

Não deixa de ser uma excelente "ferramenta" de integração, correto?

Cheers!

Microsoft, SOA e "Oslo"

noreply@blogger.com (Unknown) — Thu, 24 Jan 2008 01:28:00 +0000

Vocês lembram de quando eu postei aqui o site da Microsoft sobre SOA? Pois é, a empresa de Redmond tem sim uma estratégia para SOA. Quão boa ela é eu, sinceramente, não me atrevo a avaliar. Deixo isso por conta dos usuários de soluções da "fabricante" do Windows.

E esta iniciativa de arquitetura orientada a serviços tem um codinome, "Oslo".

O que é "Olso"?

De acordo com este documento (.doc, é claro!),

“Oslo” is the code name for a set of technical investments that aim to
significantly simplify designing, building, managing and scaling
service-oriented and composite applications that can span from the enterprise to
the Internet.

Minha crítica é que, mais uma vez, as iniciativas da Microsoft estão baseadas em ferramentas e a arquitetura fica em 2o. ou 3o. plano. Grande erro! SOA é tudo menos algo que você controi simplesmente comprando a nova versão do "Visual Studio 10". Continuando...

As 5 (cinco) principais áreas de "investimento" da iniciativa "Oslo":

Framework: a versão "4" do .NET Framework terá investimentos em model-driven development como parte do Microsoft Windows Communication Foundation (WCF) e a tecnologia Workflow Foundation (WF) technologies.
Server: a versão "6" do BizTalk Server terá WCF and WF como seu core foundation e estará apto para desenvolver, gerenciar e disponibilizar composite applications.
Services: a versão "1" do BizTalk Services irá disponibilizar serviços (hosted services) que serão utilizados pelas composite application. Exemplo: hosted messaging, identity e implementação de workflow.
Tools: os investimento permitirão que o Visual Studio “10” suportará model-driven design e deployment de aplicações compostas.
Repository: System Center “5,” Visual Studio “10” e BizTalk Server “6” utilizarão um repositório comun para gerenciar, versionar e realizar o deploy.

Vocês localizaram a palavra "arquitetura" nos pontos acima? Nem eu. Isto me preocupa muito.

Toda iniciativa em direção a SOA é válida, não devemos esquecer da Arquitetura e Governança (outra palavra não citada). Boa sorte.

SOA: 10 Erros a Serem Evitados nos Projetos

noreply@blogger.com (Unknown) — Mon, 21 Jan 2008 15:01:00 +0000

Mais um lista do que fazer e do que não fazer nos projetos que utilizam SOA como arquitetura? Sim, esta é uma daquelas listas. Entretanto, todos nós temos a ganhar quando compartilhamos este tipo de experiência (What You should do, What You Should not do).

Desta vez Paul Callahan (diretor da empresa NetManage) escreve esta nota para o site da ZDNet.com com suas opiniões sobre os 10 principais erros que você deve evitar ao implementar projetos utilizando a arquitetura orientada a serviços (meus comentários em azul):

Taking a shotgun approach: segundo o autor, disponibilizar todos os serviços é desnecessário e vai custar muito. O correto é avaliar quais serviços, de fato, precisam ser disponibilizados. Aqui não tem segredo. Os times de TI, com ajuda dos analistas de negócios, devem mapear antes os processos de negócio, candidatos a tornarem-se serviços. O passo seguinte é priorizar e definir quais deles precisar ser adequados, reescritos (se for o caso) e realizar as implementações necessárias para disponibilizar as informações como serviços.
Failing to involve business analysts: sem comentários. Envolva o pessoal de negócios desde o início. Sua prioridade deve ser expor as informações de negócio e não desenvolver Web services.
Spending more time on SOA products than SOA Planning: Planejamento e Governança. Produtos e ferramentas são importantes mas eles não servirão de nada sem o devido planejamento prévio e sem Governança desde o 1o. dia.
Tackling the largest projects first: Não tente "abraçar o mundo". Projetos pequenos diminuem os risco da implantação e trazem resultados mais rápidos. Discodo do autor apenas no quesito "visibilidade". Na minha opinião um projeto que traga visibilidade é importante para você ganhar apoio da alta direção e mostrar para a empresa um retorno rápido do investimento.
Forgetting that SOA is a business Problem: discussões sobre SOA não devem se ater a aspectos técnicos. SOA existe para nos ajudar a resolver problemas de negócio; e o negócio deve ser o mais importante, não os aspectos técnicos.
Treating identity as an afterthought: de acordo com o autor, as empresas tendem a adiar questões de controle de acesso. Bom, isto tem a ver com Governança (vide item 3 acima).
Buying new products when existing investments suffice: este é um velho problema. As empresas esperam implementar SOA comprando hadware e software. SOA é um estilo de arquitetura, não um produto, e está relacionada com uma "vontade política" de resolver alguns dos problemas de integração de sistemas, agilidade e alinhamento com as áreas de negócio. Porém, muitas decisões de arquitetura não envolvem, necessariamente, investimento direto.
Misunderstanding company key players: quem são as áreas afetadas pelos processos? De acordo com o autor, é importante envolver estes departamentos nas discussões, do contrário corremos o risco de ter grandes resistências.
Expecting the SOA project to spread quickly: implantar SOA não é como instalar um novo serviço de e-mail. Leva tempo para a empresa "absorver" e entender os benefícios desta nova abordagem.
Lacking necessary elements: neste ponto o autor alerta que muitas empresas pequenas não tem pessoal qualificado para implementar uma mudança de arquitetura. Esta é uma decisão de cada empresa. O que eu posso garantir a vocês é que não se aprende sobre SOA apenas lendo revistas (ou blogs como este).

SOA + Project Zero= Agilidade

noreply@blogger.com (Unknown) — Sun, 20 Jan 2008 22:43:00 +0000

Vocês irão ler várias vezes sobre o "Project Zero" neste blog.

O que é Project Zero? Projeto "incubado" na IBM, é um ambiente de implementação e execução ágil que simplifica e torna mais rápido o desenvolvimento de aplicações Web dinâmicas.

O Ambiente de Desenvolvimento inclui script runtime para Groovy (linguagem script baseada em Java), PHP (isto mesmo, o bom e velho PHP), otimizado para implementar serviços "à la" REST (Representational State Transfer), mashups, e interfaces Web "ricas".

O que isto tem a ver com SOA? São soluções como esta que dão visibilidade e trazem um benefício "visível" para todo esforço que seu time empreendeu implantando uma arquitetura orientada a serviços. O "Project Zero" é focado em desenvolver aplicações Web 2.0 e segue os princípio de SOA. Algo como Web-extended SOA (WOA).

Um excelente artigo sobre "Project Zero" e SOA pode ser lido aqui.

Nunca esqueça que um desenvolvimento ágil faz toda diferença hoje. E se este desenvolvimento for feito dentro dos princípios da sua arquitetura SOA, extensível, Web-based, com um framework disponível para a comunidade... ...melhor ainda! Esta é a proposta do "Project Zero".

Como prometido, vou postar outros artigos sobre esta iniciativa, é só aguardar e retornar aqui de vez em quando. Abraços!

Oracle compra BEA por US$ 8.5B

noreply@blogger.com (Unknown) — Wed, 16 Jan 2008 15:55:00 +0000

Agora é definitivo. Oracle vai comprar a BEA por US$ 8.5 Bilhões (ou US$ 19.75/ação).

De acordo com Larry Ellison, a arquitetura do seu middleware (Oracle Fusion) tem uma arquitetura aberta que vai permitir o acomplamento com os produtos da BEA.

Após o anúncio, o CEO da Oracle, Charles Phillips, apressou-se em garantir aos clientes da BEA que eles poderão utilizando a solução desta última, sem serem forçadas a migrarem para produtos da Oracle. Literalmente, ele afirmou:

"After the closing, Oracle intends to preserve and enhance customers' investments in BEA products as Oracle has done with its other acquisitions, while Fusion Middleware will continue to be the center of Oracle's current and future middleware and applications strategy,".

O processo deve se encerrar até o meio deste ano.

(fonte ComputerWorld)

Macbook Air

noreply@blogger.com (Unknown) — Wed, 16 Jan 2008 06:04:00 +0000

Simplesmente fantástico. Claro como usuário da Apple era "meu dever" compartilhar com vocês um vídeo (30 seg.) do novíssimo MacbookAir. Aumenta o som e cuidado para não "babar" no teclado. Sem palavras...

COBOL e SOA

noreply@blogger.com (Unknown) — Tue, 15 Jan 2008 13:39:00 +0000

Claro que a imagem aí do lado (tirada de um site sobre COBOL) é apenas para provocar.

COBOL ainda é uma linguagem muito utilizada, principalmente no mundo financeiro. De acordo com este post, existe uma estimativa da IBM/Rational que temos hoje aproximadamente 200 Bilhões (!) de linhas de código em COBOL. Com certeza, é algo que não deve ser ignorado pela industria de software.

E é esta industria, ainda de acordo com a notícia acima, que está empenhada em "modernizar" o COBOL através de SOA. Cada um com sua abordagen, IBM, Oracle, HP e Intel apresentam suas "armas" para desafio.

A IBM acredita (claro) que o mainframe é uma peça importante e vai se encaixar no lego de SOA.

Entretanto, HP, Intel e Oracle, se juntaram em uma iniciativa (AMI*) que, em linhas gerais, propõe substituir a parte "crítica" os sistemas em COBOL por serviços e novas implementações mais aderentes à proposta de arquitetura orientada a serviços.

(*AMI = Application Modernization Initiative)

Claro que o objetivo é trazer para servidores HP, com processadores Intel e utilizando o middleware Oracle Fusion, alguns milhões destas linhas de código escritas em COBOL.

Como diria um amigo meu, quem acha que esta linguagem está morta vai ter a nota fiscal do caixão impressa em um programa COBOL!

SOA é um Projeto?

noreply@blogger.com (Unknown) — Mon, 14 Jan 2008 14:28:00 +0000

Não. Meu conselho é: não coloque a implantação de uma arquiteura orientada a serviços na categoria de "Projeto".

SOA é muito mais do que isto. É uma abordagem de arquitetura, uma nova forma de pensar os novos sistemas e a integração entre eles, uma visão pragmática para alinhar as áreas de negócio e parceiros/fornecedores, uma infraestrutura que permite integrar os sistemas de forma mais eficiente/eficaz, uma implementação de processos de negócio como serviços... ...mas, acima de tudo, SOA é uma jornada, não tem fim. E, definitivamente, SOA não é um projeto.

Em todas as paletras eu sugiro fortemente que os times de TI não tratem SOA como "aquele projeto especial que vai levar boa parte do seu orçamento e que vai demorar a ser concluido".

A definição clássica de Projeto pressupõe algo único, que será desenvolvido em um tempo pré-definido (caráter "temporário" de um Projeto). Sua equipe não irá criar algo único (SOA já existe) e esta adequação não terá fim (a não ser que você decida não alterar e nem desenvolver mais nada).

Uma abordagem inteligente para convencer a alta diretoria a aprovar o budget inicial é, por exemplo:

"Vamos implementar um novo Portal que irá integrar - "agregar" - dados de vários sistemas corporativos, fornecendo à alta direção uma visão unificada dos principais dados e indicadores. Para tanto, precisamos adquirir uma infraestrutura básica para realizar esta integração de forma mais eficiente, preservando o investimento já feito nos nossos legados..."
"Temos uma demanda para integrarmos os dados de nossos sistemas com parceiros e fornecedores e queremos fazer isto de forma padronizada e organizada, evitando trocas de arquivos e implementações específicas para cada um deles. Nossa equipe já está 150% alocada nos projetos atuais e estamos bucando uma forma de disponibilizar os dados com segurança e utilizando as melhores práticas. Será necessário realizar um investimento em alguns softwares e serviços básicos para implementarmos estas integrações de forma mais rápida, atendendo as expectativas dos nossos parceiros de negócio. Este investimento irá gerar outros benefícios tais como: poderemos reutilizar algumas implementações feitas para um fornecedor e utilizar para vários outros; a forma como os nossos sistemas internos irão 'conversar' será otimizada, diminuindo o tempo de manutenção..."

Como vocês viram não utilizei o termo SOA em nenhum momento. Boa sorte!

SOA Magazine de Janeiro "no ar"

noreply@blogger.com (Unknown) — Thu, 10 Jan 2008 11:52:00 +0000

A edição de Janeiro/2008 da SOA Magazine já está disponível. Como sempre, são três artigos de excelente conteúdo e a leitura vale a pena. Este mês temos:

Next-Generation Grid-Enabled SOA: Not Your MOM's Bus : revê os conceitos de SOA Grid e propõe a combinação da utilização atual de MOM (Message-oriented Middleware) com dados em memória para alta performance e QoS no seu ambiente SOA. A conclusão é que "SOA Grid" vem resolver várias quesões relcaionadas a alta disponibilidade, escalabilidade, confiabilidade e performance em um ambiente distribuido.
A Strategic Approach to SOA: Using Pilot Projects and Effective Disciplines to Ensure Successful Adoption and Governance : a importância dos projetos-Piloto e da Governança na implementação e validação da sua arquitetura SOA. Passo-a-passo de um planejamento estratégico para iniciar uma implementação de uma arquitetura orientada a serviços.
Defining Operational Services: How SOA Can Help Realize a Role-Based Organization: artigo voltado para analistas de negócio e como uma visão "corporativa" de SOA pode criar valor para a organização.

Mais um SOA Framework Open-Source

noreply@blogger.com (Unknown) — Wed, 09 Jan 2008 15:48:00 +0000

O Framework é chamado de "SwordFish". De acordo com este artigo da InfoWorld, o projeto está sendo desenvolvido a 6 anos (!) pela Deutch Post (Alemanha), e agora faz parte da Eclipse Foundation. Está fortemente baseado em:

Service Component Architecture (SCA)

Java Business Integration (JBI)

Open Services Gateway initiative (OSGi)

A empresa Sopera, também da Alemanha, já "empactou" este framework e desenvolveu o "SOPERA Advanced Services Framework (ASF)":

De acordo com este post do Joe McKendrick eles tem como alvo as pequenas e médias companhias que não tem "budget" para investimento em plataformas do mercado.

Na minha opinião estas iniciativas são excelentes pois possibilitam às companhias realizarem validações práticas das iniciativas de arquitetura orientada a serviços, sem a necessidade de grandes investimentos.

Outras plataformas SOA open source são: Red hat JBoss, MuleSource, FUSE e Glassfish.

SOA Poster

noreply@blogger.com (Unknown) — Wed, 02 Jan 2008 00:58:00 +0000

O poster acima é parte do livro "SOA: Principles of Service Design", autor Thomas Erl (dica: baixe o PDF e envie para impressão em alguma gráfica).

Larry Ellison: Adoção de SOA será lenta...

noreply@blogger.com (Unknown) — Wed, 26 Dec 2007 11:19:00 +0000

Não chega a ser mais uma "previsão" sobre o futuro da arquitetura orientada a serviços mas, de acordo com o todo-poderoso da Oracle, a adoçao de SOA será lenta, muito lenta.

É o que afirma este post do site CIO.uk. Veja algumas das previsões dele:

"It takes about 10 to 20 years before [you can] rewrite all of your applications,"
"It takes a long time for our customers to have a majority of their applications modernised and we think this is a growth story for a decade for us,"

É fato que leva tempo para que uma empresa reescreva suas aplicações. Ele só esqueceu que um dos grandes benefícios que SOA traz é a manutenção do legado. Esta abordagem faz toda diferença na adoção de uma nova arquitetura e, com certeza, vai acelerar a adoção de SOA (olha eu contrariando Mr. Ellison!).

Espero, sinceramente, que a turma do Oracle Fusion discorde do chefe e liberem novas versões do middleware o quanto antes.

SOA e 10 Previsões para 2008

noreply@blogger.com (Unknown) — Thu, 20 Dec 2007 02:34:00 +0000

Bem, 2008 está chegando e com ele as famosas previsões para o novo ano que se inicia. David Linthicum apresenta as suas:

IBM irá comprar uma grande empresa de SOA (e também uma pequena)
Os projetos de SOA irão provar a falta de profissionais qualificados nesta arquitetura. A demanda por profissionais que, comprovadamente, conhecem arquitetura orientada a serviços irá crescer exponencialmente
SOA e a "tradicional" Enterprise Architecture (EA) tendem a se "fundir": segundo o autor do artigo, a tendência é que as best practices da EA irão, cada vez mais, incorporar abordagens e práticas de SOA
A nova proposta da Web 2.0 irá "forçar" muitas empresas a adotarem SOA: novamente, de acordo com Linthicum, se você quer que sua empresa "surfe na onda" das novas tecnologias da Web, a adoção de SOA é o caminho. "Vamos encarar a realidade, hoje tratatamos muito mais de integração com empresas fora dos nossos firewalls". E neste aspecto, SOA é killer
A imprensa especializada irá dar destaque a projetos de implantação SOA que não deram certo: muitas pessoas estão fazendo coisas "estúpidas" nos projetos de implementação de uma arquitetura orientada a serviços. Segundo o autor, em 2008 virão à tona os cases de projetos que falharam. Empresas que investiram em tecnologia e descuidaram da arquitetura estão entre as "candidatas" a terem um artigo nos jornais e revistas técnicas.
Grandes empresas de consultoria continuarão a não entender de SOA: Linthicum afirma que as grandes empresas de consultoria ainda não terão compreendido SOA em 2008. Serão responsáveis por boa partes dos cases de insucesso de SOA.

Vamos conferir durante todo o ano de 2008.

Pessoas por trás das pesquisas no Google?

noreply@blogger.com (Unknown) — Wed, 19 Dec 2007 16:18:00 +0000

Se alguém me afirmasse que, atrás da tela de pesquisa do Google, existem seres humanos... ...eu diria que isto é mais uma daquelas "lendas urbanas" que ouvimos diariamente.

A primeira vez que li sobre "Google Black Box Seach Engine" foi neste post (NY Times). Se você quer entender um pouco da dinâmica da empresa e quem é o guru por trás do algoritmo de busca (sim, ele é indiano), a leitura do post vale a pena.

Ontem o blog do NY Times retomou o assunto. Desta vez, confirmando que, de fato, existem pessoas "por trás" de algumas pesquisas que você faz, analisando e escolhendo os melhores sites, melhorando o resultado das buscas, enfim, contribuindo para otimizar os algoritmos de busca do site.

Vejam a afirmação do diretor de Pesquisa, Peter Norvig:

Another way we do it [improve the quality of search results] is to randomly select specific queries and hire people to say how good our results are. These are just contractors that we hire who give their judgment. We train them on how to identify spam and other bad sites, and then we record their judgments and track against that. It’s more of a gold standard because it’s someone giving a real opinion, but of course, since there’s a human in the loop, we can’t afford to do as much of it.

Percebeu? Lembre-se disso na próxima vez que utilizar o Google (leia a fonte original da notícia aqui).

SOA Magazine: Edição Dez'2007

noreply@blogger.com (Unknown) — Tue, 18 Dec 2007 23:38:00 +0000

Já está on-line a edição de Dezembro da "SOA Magazine", revista eletrônica mantida pelo evangelista de SOA, Thomas Erl. As edições passadas podem ser acessadas aqui.

Na edição deste mês os artigos são relacionados ao design de serviços e padrões de Web Services. Um dos artigos é um trecho do novo livro de Erl, que detalhamos no post anterior.

Ten Ways to Identify Services: os três autores alertam para o fato de que, uma vez que Web-Services e SOA estão se "popularizando", é fácil cair na tentação de implementar serviços "ad-hoc" ao invés de seguir alguns dos padrões já estabelecidos. O artigo se propõe a apresentar 10 (dez) abordagens para identificar Serviços.
Services as Web Services: Are We There Yet? How Web Service Technology Stacks Alone Cannot Fulfill the Goals of SOA: dentre as diversas formas de combinar padrões de Web Services e suas extensões, em frameworks que prometem tudo o que é necessário para implementar/realizar a verdadeira "Orientação a Serviços", o devemos considerar e o que não devemos levar em conta.
SOA Design Patterns: The International Community Review of SOA Patterns and Pattern Languages: assunto já tratado no meu post anterior. Sessenta (60)! Design Pattern for SOA e Web Services, revisado pela comunidade e que serão tratados no livro que Thomas Erl pretende lançar em Maio'2008. Você pode contribuir submetendo um Pattern ou revisando os atuais.

SOA Pattern: Site e Livro novo "no forno"

noreply@blogger.com (Unknown) — Fri, 14 Dec 2007 16:40:00 +0000

Mais um livro do Thomas Erl, um dos melhores autores de livros e artigos sobre SOA. Desta vez ele está finalizando um livro sobre padrões (patterns): "SOA Design Patterns". Já está em pré-venda na Amazon.com e tem previsão de liberação em 23/Maio/2008.

No site que serve de base para a publicação, temos uma lista dos patterns e uma breve descrição. Ao clicar no nome do pattern, vocês terão uma descrição detalhada do padrão proposto.

Veja alguns exemplos:

How can a technology architecture be designed to remain in alignment
with changing business goals and requirements?

How can services be designed to avoid data model transformation?

How can redundant utility logic be avoided across domain service inventories?

Um trabalho extraordinário do T.Erl que vai ajudar (e muito!) nas implementações de SOA. Acho que já vou garantir o meu exemplar.

noreply@blogger.com (Unknown) — Fri, 14 Dec 2007 01:19:00 +0000

Vocês se recordam do Marc Fleury? Fleury, 39 anos, é o criador do servidor de aplicações JBoss. Pois bem, depois que a Red Hat adquiriu a empresa que Fleury fundou, ele se tornou VP e Gerente Geral da divisão JBoss/Red Hat. Pouco tempo depois (Março, 2007), ele saiu da Red Hat para, supostamente, se dedicar a família e outros hobbies.

Alguns dias atrás (12 Dez'07), Fleury entrou para o Advisory Board da Appcelerator, uma start-up baseada em Atlanta-GA, cidade em que ele mora.

O lema da companhia é "More App. Less Code". Mas o que é e o que faz a Appcelerator?

Appcelerator is an open source software company providing products and solutions for enterprise rich Internet application (RIA) and SOA-based services development. The Appcelerator Platform combines the best of RIA and SOA-based technologies and design principles into one integrated, open and standards-based platform. The result is a fundamentally new - and much faster - way to build Web-based applications with more functionality and less code.

E o produto (open-source!):

Message Oriented Architecture: significa que todo "comportamento" de uma Appcelerator application é governada por messagens leves
AJAX and DHTML without Javascript: apenas standard HTML é utilizado; JavaScript não é exigido
SOA-based services in ANY language: Java, Ruby, PHP ou .NET. Serviços Appcelerators podem ser acessados por qualquer RIA Appcelelator ou não (desde que sejam REST-based)
Universal Clients: RIAs Appcelerator podem ser utilizadas com IE, Firefox, Safari e Opera
Rapid Prototypes - No Throwaway Code: como é baseado em mensagens, você pode, rapidamente, criar RIAs sem escrever um linha de código no lado do servidor.
Platform Extensibility: Appcelerator é uma plataforma que pode ser expandida para necessidades específicas e até mesmo criar serviços em uma linguagem não suportada pela versão atual da plataforma

Java é o novo COBOL?

noreply@blogger.com (Unknown) — Mon, 10 Dec 2007 11:26:00 +0000

Claro que o título é provocativo. Antes de mais nada deixo claro que já fui programador Java (desde as primeiras versões) e sou um defensor da linguagem. Penso porém que vale a pena um pouco de reflexão sobre o futuro desta plataforma.

Sempre argumento com o time de arquitetura da empresa onde trabalho sobre as opções que temos de desenvolvimento ágil. Utilizamos Java em nossos projetos mas sempre tento provocar uma discussão no sentido de avaliarmos as alternativas de linguagens mais "leves" (lightweight frameworks).

Ruby, PHP, JRuby (Java + Ruby, óbvio não?), são opções que devemos sempre considerar partindo da premissa que nenhuma linguagem/plataforma pode solucionar todos os problemas. O mais importante é termos o "fecho" da arquitetura e garantir a interoperabilidade entre os aplicativos. No nosso caso, com a nova arquitetura SOA implantada e a utilização de Web Services, isto fica muito mais fácil.

Bom, voltando ao Java. Esta discussão de que o Java não é mais o mesmo vem e volta sempre. É difícil argumentar quando sabemos que existem mais de 5 milhões de desenvolvedores Java atualmente. Por outro lado, mais e mais "cool kids" estão escolhendo alternativa a Java para implementar seus web sites. É o que argumenta Coach Wei neste artigo no JDJ.

Ele questiona se seria a falta de frameworks? Certamente não. Como ele mesmo cita, "I bet there are more Java frameworks than the population in China". A questão é que muitos web sites são simples, sem muita complexidade; e isto talvez seja uma tendência. Neste ponto, scripts e lógicas lightweight no lado do servidor, que é a "praia" do PHP e Ruby/JRuby etc.

O que está faltando no mundo Java?

Ele aponta três alternativas:

1. JSP/Servlet com um Java Servlet engine (or mesmo um application server): Esta é a arquitetura predominante para aplicações Web-based nas corporações. Mas não tem nenhuma vantagem na contrução de web sites quando comprados com PHP ou Ruby;

2. JavaServer Faces: JSF é "the new kid on the block". Vai facilitar a construção de sites? Provavelmente não! JSF foi desenvolvido para simplificar a contrução de aplicações form-based.

3. Utilização de um Java based content management system (CMS)? Segundo o autor, nenhum Java-base CMS tem o apelo e inovação suficiente para ser um "killer".

A propósito, o título do post vem deste outro artigo: "Java, the Cobol of the 90's?", escrito por Quinton Wall (BEA).

Fornecedores de SOA não conhecem SOA!

noreply@blogger.com (Unknown) — Fri, 07 Dec 2007 01:15:00 +0000

Depois de alguns anos lidando com fornecedores de software, concordo com as observações do Mr. David Linthicum no seu artigo publicado no Java Developers Journal.

Quase que diariamente recebo ligações de consultorias e "empresas de software" que, de uma hora para outra, tem know-how sobre implementação e implatação de arquitetura orientada a serviços.

A maior parte, infelizmente, ainda acha que SOA tem a ver apenas com Web-Services, ou modelagem de processos (BPM) ou mesmo se resume a um broker de integração. Isto quando eles sabem o que é um broker.

A primeira vez que conversei sobre SOA com um alto executivo de uma das maiores empresas de tecnologia do mundo, a reação dele foi: "Não, nunca ouvi falar...". Acreditem!

Como eles não podem discutir arquitetura, eles conversam sobre produtos e apresentam aqueles slides fantásticos, onde tudo funciona. Quem nunca viu o famoso processo de autorização de crédito, em uma demonstração de ferramenta BPM?

Eles tentam "empurar" para sua empresa produtos, apenas isto. David Linthicum chama isto de Arquitetura Conduzida por Vendedores" ou VDA (Vendor-driven Architecture).

Tenha em mente que a arquitetura deve ser definida pelo seu time; claro que consultores e, eventualmente, arquitetos de software dos fornecedores podem (e devem) auxiliar. Mas, em hipótese nenhuma, eles devem ditar a sua arquitetura simplesmente adicionando caixas e mais caixas de software ao seu/nosso, já heterogêneo, conjunto de sistemas e soluções.

Lucro da BEA: US$ 56 Milhões

noreply@blogger.com (Unknown) — Thu, 22 Nov 2007 14:02:00 +0000

O lucro da BEA no 3o. quarter (Q3) de 2007 chegou a US$ 56 Milhões, um (considerável) crescimento de 37%.
Com este lucro, o presidente e CEO, Alfred Chuang, afirma que a companhia vale, de fato, US$ 21,00/share (como ele já tinha avisado ao Mr. Larry Ellison da Oracle).

Aqui estão as palavras dele:

"In spite of significant distractions during the quarter, the team did an outstanding job executing to our revenue plan and generating a strong pipeline of business opportunities as we head into our seasonally strong fourth quarter. These results demonstrate not only significant progress in operating profitability, we also believe they will materially impact how investors value BEA."

Ligando a tecla SAP: "Apesar de algumas significantes distrações, o nosso time fez um trabalho excepcional e atingimos um excelente resultado no (30.) trimestre. Estes resultados não apenas demonstram o aumento da nossa lucratividades mas, principalmente, irão impactar na forma como nossos investidores avaliam o valor de mercado da BEA"

Amazon Kindler Esgota em 5 horas

noreply@blogger.com (Unknown) — Thu, 22 Nov 2007 02:00:00 +0000

Já ouviu falar no Kindler? Este gadget é o fruto de 03 anos de trabalho do pessoal da Amazon e do CEO e fundador Jeff Bezos. Se você é viciado em leitura (como eu), com toda certeza faria o possível para pagar os US$ 399,00 do "bichinho" acima.

Imagine um dispositivo com menos de 300 gramas (10.3 ounces), com conexão wireless (utiliza EVDO) sem conta mensal (!), onde você poderá ler seus jornais, livros (+ 88,000 títulos), blogs (+ 250), Wikipedia... ...um dispositivo de onde você poderá enviar seus e-mails com arquivos e imagens anexos, baixar e ler alguns capítulos de livros e avaliar antes de comprar, sem cabos e sem necessidade de computador para sincronizar... ....pois é, não foi à toa que ele esgotou em 5,5 horas (notícia do Slashdot).

Claro que nós brasileiros ainda não temos acesso mas, por via das dúvidas, já adicionei-o na minha wish list, caso você queirar me presentear neste natal ;-)