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

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

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

1. IBM irá comprar uma grande empresa de SOA (e também uma pequena)
2. 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
3. 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
   
4. 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
   
5. 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.
   
6. 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?

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

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"

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.

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?

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!

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.