Bruno Pereira

Hoje o Sacha Labourey (CTO da JBoss) publicou um post interessante sobre as dificuldades que a Sun vem encontrando, em especial com seu modelo de negócios open source. Como eu já pensei um bocado sobre isso e conversei com algumas pessoas, vou deixar aqui algumas opiniões.

Na minha opinião, a Sun fez e vem fazendo um excepcional trabalho mantendo a plataforma Java como um todo. O problema todo está no contexto que girou em torno disso.

Em um determinado momento a Sun lutava bastante contra a Microsoft e suas soluções Windows/.NET, e de fato parecia que as empresas seriam adversárias. O que ocorre é que a Sun gastou tantas energias combatendo a Microsoft que não dedicou o esforço necessário para conquistar espaço dentro do próprio mercado Java.

O Glassfish V2 foi o primeiro bom servidor de aplicações da Sun, mas ele chegou bem tarde. Muito antes a BEA e a IBM já tinham um vasto portfólio de produtos Java Enterprise, e servidores de aplicação bem melhores do que o antigo Sun Application Server. Com isso, mesmo com o enorme sucesso da plataforma Java, a Sun não estava muito bem posicionada no mercado de software.

Creio que em decorrência deste primeiro problema (a falta de um bom app server), veio o problema que eu acho o mais grave. Na minha opinião o que fez mais falta à Sun é um bom modelo de serviços em torno da plataforma que ela desenvolveu tão bem. A Sun tem muitos grandes engenheiros, mas não conseguiu traduzir isso em muito lucro com Java. Penso que um modelo de serviços semelhante ao da IBM teria sido adequado à Sun, mas para isso eles precisariam de um portfólio de produtos melhor.

O grande (e bem-sucedido) esforço no desenvolvimento da plataforma Java consumiu energias que poderiam ter sido aplicadas na construção de uma linha de produtos mais rica, e com isso o sucesso do Java acabou drenando muito da saúde da Sun.

Mais recentemente a Sun tentou mudar a sua estratégia, e passou a abraçar ainda mais o modelo open-source. Embora isso tenha sido muito bem recebido pela comunidade de desenvolvedores, não podemos dizer que essa mudança tenha trazido mais sucesso para a empresa.

Eu tenho a clara impressão de que a Sun abraçou este modelo sem ter muita noção do que a esperava, mas talvez a sensação fosse de que não havia uma outra alternativa óbvia. A verdade é que a Sun está há anos lutando, mas sem encontrar a estratégia correta. O modelo de negócios em torno de open source foi mais uma tentativa da empresa, mas não estou vendo muitas perspectivas da Sun conseguir deste modelo as receitas necessárias para cobrir seus custos.

Eu fico triste por essas dificuldades da Sun, pois eles fizeram um excelente trabalho desenvolvendo a plataforma Java, mas isso custou a própria saúde da empresa.

E o que poderá vir em conseqüência? Difícil dizer, mas me parece inevitável que a Sun seja comprada por um player de maior porte, como a HP ou a SAP.

Como a Oracle agora é um concorrente direto da SAP em várias linhas, e a SAP começou a investir em Java, talvez faça sentido que a gigante alemã compre a Sun.

Quanto à HP, seria um movimento muito mais coerente do que a compra da EDS, que ocorreu esse ano. Comprando a Sun, a HP teria a stack completa, com hardware HP, sistema operacional e middleware da Sun, e serviços provenientes da EDS. Isto a deixaria em situação semelhante à da IBM, e acho que faria sentido nesse contexto atual.

Não sei qual será o futuro da Sun, mas sinceramente torço muito para que seja próspero, pois seu legado de contribuições ao cenário mundial de software é valioso demais para que a empresa tenha um final agonizante.

Eu considero a Microsoft bem fraca em termos de atuação na Web, mas achei bem legal uma iniciativa recente deles.

Foi anunciado recentemente o Microsoft Office Web. Embora não seja nada inovador, pois o Google Docs já existe há algum tempo, eu gostei dessa novidade. O serviço ainda não está disponível, mas um FAQ sobre ele já foi publicado.

Achei interessante que o Office Web suportará o Firefox e o Safari além do IE. Além disso, usuários de qualquer sistema operacional poderão usar o serviço, contanto que tenham um dos browsers suportados. Quando eu soube que lançariam o Office Web, a primeira coisa que veio à minha cabeça foi que só funcionaria com o IE e que seria necessário instalar algum add-on que só funcionasse no Windows. Saber que isso não é verdade foi uma ótima surpresa.

Eu utilizo com freqüência o Google Docs, e gosto muito da praticidade do serviço. A facilidade de compartilhar documentos e editá-los de forma simultânea é ótima. Desde que comecei a usar o Google Docs, eu raramente uso o Open Office ou Word. Praticamente só uso um dos 2 quando eu tenho que escrever alguma coisa com preocupações em relação a estilos e formatação. O Google Docs é bem limitado neste sentido, infelizmente.

Com o Office Web, provavelmente o suporte a estilos e formatação será melhor que no Google Docs, e isto pode me estimular bastante a usá-lo e aposentar o OpenOffice e Word, e viver ainda mais na Web.

Algumas conseqüências bacanas podem surgir deste novo serviço. A competição entre o Office Web e o Google Docs provavelmente trará muitos benefícios aos usuários finais, que deverão ter serviços web gratuitos e de ótima qualidade.

Além disso, o Office Web fará a Microsoft sofrer um pouco com as incompatibilidades entre os browsers. Suportar as mesmas funcionalidades no IE, Firefox e Safari dará um certo trabalho. Talvez isso desperte uma iniciativa da Microsoft de consertar o IE, e fazer com que os desenvolvedores web em geral tenham menos trabalho com essas incompatibilidades.

Se o Office Web trouxer essas 2 mudanças, terá sido uma das melhores iniciativas que a Microsoft já teve. Torço para que esse projeto ganhe força e que todos possamos usufruir dos benefícios

O Antônio Carlos publicou um post muito interessante. Eu já venho há algum tempo acompanhando as dificuldades da Microsoft nos últimos anos, e é impressionante como eles estão com um caminho espinhoso pela frente.

Já há fortes sinais de que a Microsoft lançará o Windows 7 ano que vem, após sérias dificuldades com o Vista. É verdade que o Vista está conseguindo vender alguma coisa, mas é bem menos do que a Microsoft esperava. Além disso, recentemente li que o market share do Windows XP se manteve praticamente constante, e quem caiu na verdade foi o Windows 2000.

Depois que o Antônio e o Azamba me falaram no Tech Talk da situação sofrível do Silverlight, fiquei com a impressão de que a Microsoft está mesmo em apuros sérios. O IE aos poucos está cedendo mais espaço pro FF, Windows Media já está numa situação crítica perante o Flash Video e em praticamente todas as frentes da Microsoft eles estão com dificuldades.

A Gartner durante muito tempo era conhecida por previsões sempre favoráveis à Microsoft (até mais do que deveria), mas isso já está mudando. Recentemente eles disseram que o Windows está entrando em colapso, e que a situação está insustentável. Até o Office que sempre foi a estrela do sucesso da empresa está tendo algumas complicações. A Microsoft investiu nesse formato XML “aberto” em vez de apoiar as iniciativas do Open Document. Pois recentemente foram feitos testes dos arquivos do Office 2007 contra o formato “XML aberto” da MS e milhares de incompatibilidades foram detectadas.

A nova febre do momento na internet é o crescimento das redes sociais, e a Microsoft está tendo um papel pífio nisso. Diversos serviços enormes de redes sociais estão surgindo, e a saída pra Microsoft provavelmente será comprar algumas dessas iniciativas.

Antônio, seu questionamento foi muito feliz. Acredito que a resposta para a real descida da Microsoft como um todo está na pergunta que você fez. Por quanto tempo o desktop ainda será tão relevante como é hoje? A Microsoft certamente reza para que seja para sempre

Em uma nota divulgada publicamente ontem, a Microsoft anunciou que desistiu da idéia de comprar o Yahoo.

As duas empresas não chegaram a um consenso financeiro, mesmo após a Microsoft aumentar sua oferta inicial em cerca de US$ 5 bi. Aparentemente a diferença de cultura entre as empresas é tão grande que o Yahoo exigiu um valor muito alto pela compra, para recompensar seus acionistas.

O Yahoo chegou até mesmo a flertar com uma possível parceria com o Google para serviços de busca, na qual o Yahoo retornaria links patrocinados pelo Google em uma parcela pequena de resultados. Isto valeria apenas nos Estados Unidos e seria um teste para ver o quão interessante isso poderia ser para as duas empresas.

Fazendo parceria ou não com o Google, o fato é que o Yahoo recusou as propostas da Microsoft. Os acionistas certamente temiam pela perda da identidade da companhia, e preferiram arriscar e continuar tendo competir de forma individual.

Depois dessa decisão, ficará muito difícil para a gigante de Redmond a disputa com o Google, considerando a enorme penetração que este está conquistando. A briga por receitas de propaganda ficará muito difícil para a gigante de Redmond, e acredito que a única forma de lutar contra isso seja a oferta de serviços web mais interessantes, para conquistar audiência. O ponto positivo para nós é que certamente esta competição trará mais e mais novidades interessantes para usarmos na internet.

Fiquei sabendo pelo post do Antônio Carlos que o Google lançou recentemente o TV Ads. Esta é uma ferramenta muito interessante e flexível de fazer propaganda na TV.

Eles disponibilizam uma aplicação no “self-service” que permite que pessoas interessadas em veicular propaganda na TV façam isso de forma ágil e prática. Você consegue criar uma campanha, definir seu público-alvo, especificar canais e programas e horários durante os quais a campanha será exibida e dizer o quanto você pretende gastar com isso. A aplicação trará várias sugestões e permitirá que você envie a mídia da propaganda para iniciar a veiculação rapidamente nestes vários canais.

Esta é uma iniciativa inovadora e potencialmente muito poderosa para o Google. Além disso, eles também lançaram o Google Audio Ads e o Print Ads. É isso mesmo: eles já dominam a propaganda na internet, e agora lançam ferramentas inovadoras para tentar ganhar espaço na propaganda feita na TV, rádio e na mídia impressa. Fiquei curioso e fui ver a lista de canais e jornais que já participam disso. A maioria dos canais de TV americanos já permite propaganda através do Google TV Ads e a maioria dos jornais também. Entre os jornais estão por exemplo o New York Times, Los Angeles Times, Washington Post e muitos outros. Além disso, inúmeros jornais pequenos (porém com público muito mais específico, direcionado) já fazem parte do programa também. Muito interessante isso.

Já sabíamos previamente da iniciativa do Google de entrar firme no mercado de dispositivos móveis. Agora eles aumentam drasticamente o alcance das ferramentas de propaganda deles. Para completar, também está nos planos do Google a entrada nos set-top boxes de TV digital. Se essas iniciativas forem bem-sucedidas (e certamente tem boas chances), o Google conseguirá uma impressionante penetração no mercado. Será mais poder do que a Microsoft já teve um dia. E tudo isso com um modelo de negócios que traz muito mais simpatia do que a Microsoft.

Difícil saber qual (e se existirá) o limite para eles. Realmente impressionante. Quando será que isso chegará ao Brasil??

Recently I’ve had several conversations regarding the Atom Syndication Format. This format is gaining more and more adopters and several big players in the industry are using it. Just to name the big boys, Google AND Microsoft are using it to implement RESTful APIs. When was the last time you heard Google and Microsoft agreed on something? This should hint that Atom is indeed a nice thing happening in our field.

Web services using the Atom format for data exchange encapsulate information using Atom’s standard elements and also define some extension points where needed. Some very useful elements are present in the specification. There are standard ways of publishing individual entries and collections, pagination support, links between resources, among other things useful for RESTful web services.

Depending on your domain model, the amount of data you would put in Atom extension points varies a lot. Some domains such as Google Apps can produce a RESTful model that uses a lot of Atom’s standard elements without needing to define too much extension points. However, if you use Atom to exchange billing information between ISP applications, you’ll probably have to define a lot of extension points. I’m saying this to show that some domains match much better to Atom structures than others.

While talking to Silvano (a very clever working mate of mine) a couple of weeks ago, he asked me if encapsulating everything inside Atom elements was not the same as encapsulating everything inside SOAP. This is a very very good question.

When you’re choosing a format for you data exchange in web services, it’s very important to analyse what you gain and what you lose by picking any given format.

For example, a good rule of thumb about SOAP services is: “WS-* is just overhead unless you have something meaningful in your SOAP Headers” (quoting Sanjiva Weerawarana at ApacheCon 2007).

Atom was designed in a RESTful manner by a very talented group of professionals. Many applications are making use of it to exchange data, and the adoption is growing fast. Could it be a silver bullet then?

That’s where I shall leave my observations. If you consider my example of billing information, you’ll see that most of the data there doesn’t mesh well with Atom’s standard elements. Thus, we’d need to define a lot of extension points, and wouldn’t make much use of Atom’s resources. Putting billing data inside Atom entries would represent an overhead without giving us much in return. In this case, I’d rather use my own XMLs directly over HTTP.

Am I saying that Google and Microsoft made a bad decision choosing Atom? No, absolutely not! Their decision was very good. Microsoft is using Atom for Windows Live API and Google’s using it for most of their applications. What do these have in common? They all manipulate web content. They have a domain where many things are accessible on the web, with lots of URIs, different media types, pagination, categories, tags, etc. Atom makes a lot of sense with web content.

I don’t think Atom is a Silver Bullet for RESTful web services in general. Of course you can choose to always use it, and benefit from the standards and the avaiable tools. But isn’t this true for SOAP as well?

What I do think is that Atom is very close to a Silver Bullet when you’re dealing with web content. Whenever you’re developing web services, choosing the right format for your data exchange is one of the most important decisions. To know well the avaiable options is very helpful, and certainly the Atom format brings a lot to the table when your domain meshes well with it. As long as you don’t think it’s the best choice for every application, go ahead and use it wisely

Depois de o Google passar a usar APIs RESTful com o formato Atom, agora é a vez da Microsoft começar a usar este formato. Ontem a empresa anunciou que as APIs do Windows Live serão RESTful e farão uso do formato Atom.

Após alguns anos investindo pesadamente em web services WS-*, parece que a gigante de Redmond está lentamente mudando sua forma de pensar em serviços web. É claro que durante um bom tempo eles ainda vão defender ferrenhamente o uso da pilha WS-*, pois eles não querem jogar fora os investimentos nessa área para a plataforma .NET. Contudo, é sem dúvida interessante ver que talvez o maior defensor de WS-* está mudando de direção, embora ainda não de forma integral.

Como eu já havia comentado algumas vezes, parece que a adoção de web services REST para diversos fins vai mesmo crescer rapidamente e ocupar um bom pedaço do espaço anteriormente ocupado por WS-*. E mais, eu acredito que os serviços REST vão crescer muito como mecanismo de integração de sistemas e plataformas. É bastante provável que o uso de integrações com EJBs e outras tecnologias que te prendem a uma plataforma específica caia de adoção. Especialmente em aplicações de internet, tenho convicção de que veremos um espaço cada vez maior sendo ocupado pelos serviços RESTful e que esta passe a ser a forma número 1 de comunicação entre diferentes aplicações.

O formato Atom tem muito a ver com esse crescimento, pois além do formato ser excelente para manipular conteúdo web, o protocolo AtomPub é um belo blueprint de implementação REST. Sempre que eu estou tentando definir um protocolo de comunicação REST e fico um pouco em dúvida sobre a melhor forma de fazer alguma coisa, minha primeira referência é o AtomPub. Estudar como eles resolvem problemas comuns no desenvolvimento REST te dá uma visão muito boa das opções disponíveis. Você já começa de um ponto de partida muito bom, e fica bem mais fácil elaborar um protocolo conciso e coerente depois que você conhece o AtomPub.

A propósito, quem quiser conhecer mais sobre implementação de serviços REST, recomendo fortemente a Java Magazine de Abril. Um certo sujeito vai publicar um artigo prático bem interessante sobre implementação destes serviços