Escolar Documentos
Profissional Documentos
Cultura Documentos
Apresentação
Me senti muito honrado por ter recebido do Cezar Taurion o convite para escrever a
apresentação de seu livro sobre Arquitetura Orientada a Serviços (SOA), organizado a
partir de uma compilação de informações postadas em seu Blog e que veio a ser
publicado e distribuído gratuitamente em meio exclusivamente eletrônico através da
Internet (eBook).
Antes de começar a escrever me dei conta de que todos esses assuntos (SOA, Blogs,
eBooks) tão comuns hoje em dia, eram praticamente desconhecidos há quatro ou cinco
anos. Isso nos dá uma noção do ritmo acelerado da evolução tecnológica, algo
impressionante e ao mesmo tempo assustador, porque tais novidades, que parecem chegar
em forma de ondas, sempre trazem a reboque um novo conjunto de informações que
tentamos compreender, assimilar e aplicar, até sermos encobertos por uma outra onda.
SOA se apresenta exatamente como uma dessas ondas.
A adoção de SOA muitas vezes gera uma expectativa de que seus alegados benefícios
serão alcançados simplesmente pelo sucesso de sua implantação. Entretanto os resultados
mais significativos e estratégicos de uma transição para o mundo SOA, como por
exemplo o aumento da agilidade nos negócios, só podem ser realmente alcançados (em
seu potencial máximo) através de uma abordagem consistente desde o início, ainda na
fase de design da lógica de automação do negócio aliada a uma flexibilidade para
suportar mudanças.
As mudanças, como bem sabemos, são constantes no mundo dos negócios. Crises, fusões,
aquisições, regulamentações de mercado, globalização, terceirização, etc. No longo prazo,
quase todos os aspectos de um negócio são suscetíveis a mudanças que, por sua vez,
geram novas demandas para o ambiente tecnológico de suporte. As metodologias de
desenvolvimento de sistemas mais pragmáticas (e modernas) acreditam no processo
incremental, no qual a mudança é um aspecto inevitável e pode ocorrer em qualquer
estágio, ou seja, os sistemas estão em constante evolução e a separação entre o
desenvolvimento e a manutenção de um sistema tornou-se cada vez menos significante.
Por essa razão a capacidade de lidar com mudanças significativas no design e no
comportamento de um sistema é algo crítico ao longo do seu ciclo de vida. Esse é o
principal diferenciador da engenharia de software das outras engenharias e, não por acaso,
é um dos grandes apelos do desenvolvimento de software orientado a serviços.
2
serviços, como e quando adotá-la, originárias dos diversos fornecedores de tecnologia,
empresas de consultoria e do mundo acadêmico. Esse livro trará, na forma de
compilações de posts de um Blog, o registro de algumas reflexões sobre SOA, suas
aplicações, implicações, limitações e potenciais, a partir da visão do autor, cuja
experiência de mercado traz dimensões interessantes a essa discussão. Vale a pena
conferí-las.
Marcelo Sávio
Arquiteto de TI da IBM Brasil
http://www.linkedin.com/in/msavio
http://msavio.myplaxo.com/
3
Introdução
A idéia de publicar um livro com a coletânea de posts que já escrevi para o meu blog no
developerWorks (www.ibm.com/developerworks/blogs/page/ctaurion) vinha me
martelando há algum tempo. As minhas observações sobre os acesso ao blog mostravam
que depois de algum tempo os posts eram “esquecidos”, uma vez que o ritmo de inserção
de novos posts tem sido intenso. Gosto de escrever e um blog me dá a liberdade que as
colunas nas revistas especializadas (escrevo para Computerworld Brasil, Mundo Java e
Linux Magazine), por razões editoriais, não permitem. De maneira geral levanto um post
a cada três ou quatro dias. Como escrevo os posts de acordo com o momento, muitas
vezes o texto pode até parecer meio deslocado para quem não esteja acompanhando
sistemáticamente o tema. O volume de material acumulado, acredito, é bem razoável. O
blog começou em janeiro de 2007 e em julho de 2009, quando da preparação deste livro,
já somava mais de 400 posts.
Surgiu a idéia: por que não agrupar os posts por temas e publicá-los para acesso online?
Uma conversa com meu amigo desenvolvedor e escritor, Claudio de Souza Soares,
definiu o projeto. Sim, vou publicar os posts em forma de livro eletrônico.
A primeira etapa foi agrupar os posts por assuntos, identificando as relevâncias entre eles.
As tags me ajudaram nisso. Assim, cada assunto ou conjunto de assuntos se tornará um
livro. Procurei manter os posts, na medida do possivel iguais aos publicados
originalmente. Claro que corrigi alguns erros ortográficos, que passaram em branco
quando os posts foram inicialmente levantados...
Este livro, o quinto da série, aborda um tema que me despertou muita atenção: SOA ou
Services Oriented Architecture. SOA teve seu período de maior procura de 2006 a 2008
(vejam gráfico abaixo, obtido do Google Trends), começando após a ceder lentamente
seu espaço na mídia para outros temas como Cloud Computing. Lembro que naquele
período chegava a fazer palestras sobre SOA ao ritmo de uma por semana.
4
Não que hoje SOA tenha ficado menos importante, mas à medida que um assunto sai da
mídia, é que sua disseminação já começa a ser fato. Deixa então de ser notícia.
SOA já vem sendo adotado de forma crescente e seus conceitos já estão razoavelmente
absorvidos. SOA hoje é mainstream. Seus conceitos já estão embutidos nos aplicativos
escritos pelas empresas usuárias, nos ERPs e nos middlewares dos principais
fornecedores, como o WebSphere da IBM. SOA, segundo o Gartner já está entrando no
ciclo do “Plateau of Productivity”, onde deixa de ser hype e sua utilização torna-se mais
ampla.
Além disso, SOA também é indutor de novos modelos computacionais como Cloud
Computing e Software-as-a-service (SaaS).
Por outro lado, muitos fornecedores de software se dizem aderentes à SOA, embora nem
sempre o sejam. Uma maneira simples e rápida de checar sua afirmação é validar se seu
software é SOA é avaliar seu nível de componentização. Se o delivery de novas
funcionalidades for feita por componentes, sem afetar o sistema em operação é
verdadeiramente SOA. Mas se ainda for necessário todo um ciclo de upgrade que
demanda uma completa instalação da nova versão, nos moldes tradicionais dos softwares
monolíticos, SOA, neste fornecedor, ainda estará restrito ao discurso.
O objetivo deste ebook não é ensinar SOA, pois uma coleção de posts não ensina nada a
ninguém. Mas, estes posts revivem os questionamentos e dúvidas que este conceito, então
novidade, trazia e serve para compararmos o que falávamos há meros dois ou três anos
com os dias de hoje. Muita coisa mudou, principalmente com relação à absorção dos
conceitos, embora muitas empresas ainda estejam nas fases iniciais de sua adoção.
Portanto, estes posts nos resgatam algumas destas discussões sobre o assunto.
Todos os URL que aparecem nos textos foram acessados e checados durante a preparação
original dos posts, mas como a Web é extremamente dinâmica, existe a grande
possibilidade de alguns destes URL já não existirem ou terem sido alterados, pelos quais
pedimos antecipadamente nossas desculpas.
5
E, finalmente, lembro que as opiniões expressas nesta série de livros (como o foram no
blog) são fruto de estudos, análises e experiêncis pessoais, não devendo em absoluto
serem considerdas como opiniões, visões e idéias de meu empregador, a IBM, nem de
seus funcionários. Em nenhum momento, no blog e aqui, falo em nome da IBM, mas
apenas e exclusivamente em meu nome.
Cezar Taurion
Setembro de 2009
6
Conhecendo SOA
Claro que embora cada prédio ou casa seja diferente em seu desenho e arranjo fisico,
utilizam materiais comuns a todos e obedecem a regulamentos, padrões e leis, inclusive
físicas. Por exemplo, não se pode construir um prédio de muitos andares sem uma boa
fundação (lei da gravidade). Ou então, por alguma imposição legal, não se pode construir
prédios de mais de quatro andares na beira de determinada praia.
Embora cada empresa desenhe sua própria arquitetura, deve utilizar tecnologias e padrões
comuns. Entretanto, uma arquitetura tecnológica, embora não seja tão proibitiva quanto à
tradicional (não se pode transformar um andar de 200 metros quadrados em outro de 400
metros quadrados) ou restritiva quanto a mudanças (imagine transformar um prédio
projetado e construído para ser comercial em residencial...quantas paredes terão que ser
derrubadas!), nem sempre é flexível o suficiente para acomodar a volatilidade do negócio.
Um exemplo comum: sua empresa adquiriu outra, que dispõe de uma infraestrutura
tecnológica totalmente diversa. Não será uma tarefa fácil integrar todos estes “novos”
sistemas aos que já estão em operação.
O que SOA propõe é uma mudança nos paradigmas das arquiteturas de TI atuais. Hoje as
arquiteturas são basicamente constituídas de aplicações construídas em cima de padrões
proprietários, com quase proibitivas restrições de interoperabilidade. Uma aplicação
escrita em VisualBasic não consegue utilizar um objeto escrito em Java. O acesso a
determinado ERP só pode ser efetuado através das rotinas de acesso específicas e
proprietárias deste ERP. Um aplicativo escrito para operar em Windows não pode ser
transferido automáticamente para uma máquina que roda Linux...
7
A proposta do SOA pode ser mais facilmente visualizada quando o associamos ao
tradicional brinquedo Lego, onde com as mesmas peças podemos criar rapidamente
objetos distintos, simplesmente combinando os objetos de maneira diferente.
Como funciona na prática este conceito? Imaginemos que você é o CIO de uma empresa
que interopera comercialmente com diversas outras. Você precisa substituir uma
aplicação crítica, trocando a sua tecnologia. Com certeza isto vai gerar muito trabalho de
modificação nos interfaces desta aplicação com as demais, na sua empresa e nas
empresas parceiras.
Agora, visualizemos um cenário (cada vez mais comum) onde dezenas ou mesmo
centenas de empresas interoperam entre si, com constantes evoluções e trocas de
tecnologias. Dá para imaginar o pesadelo?
8
Usando SOA
SOA (Services Oriented Architecture) é um tema cada vez mais quente. Recentemente o
IDC divulgou um relatório chamado “Top 10 Predictions – IDC Latin America
Predictions 2007” onde SOA foi citado como saindo da esfera da teoria e dos debates
para o mundo real (“SOA goes from idea to reality in 2007”). Segundo o IDC, SOA está
na lista de prioridades dos CIOs em todo o mundo.
Como aceleradores para 2007, o IDC destaca que à medida que os modelos de
licenciamento caminham na direção de Software como Serviço, mais ênfase será dada ao
SOA, principalmente pela sua potencialidade de adicionar funcionalidades mais
rapidamente. Também cita a Nota Fiscal Eletrônica em implementação no Brasil como
um impulsionador de SOA, bem como lembra que à medida que caminhemos para
consolidação de servidores e data centers, SOA vai se tornar mais e mais importante
quando passarmos a olhar a consolidação também na camada das aplicações.
Por último o IDC cita a consolidação que já ocorre e deverá continuar ocorrendo entre
empresas de aplicativos, que precisam implementar os conceitos SOA para garantir a
interoperabilidade entre seus pacotes.
Outras recentes pesquisas corroboram este crescente interesse por SOA. Por exemplo um
relatório do Aberdeen Group (“What CIOs Should Know About SOA”) mostrou que os 3
principais drivers para adoção de SOA são o desenvolvimento de novas funcionalidades,
o reuso de aplicações via Web services e o melhor gerenciamento da complexidade do
portfólio das aplicações de TI.
O Gartner Group recentemente disse que “80% of customers will be using SOA for new
product development in 2008”.
Confirmando o grau de satisfação de quem usa SOA, 69% das empresas que já adotaram
este modelo disseram que vão aumentar seus invstimentos SOA. A pesquisa foi mais
além e descobriu também que 83% das empresas que adotam SOA o usam para resolver
problemas de integrações internas, mas que uma parcela significativa (46% das grandes
corporações e 27% das médias) estão usando SOA para transformar seus negócios!
9
Esta é um mudança significativa quando comparamos SOA com o modelo de Orientação
por Objeto (OO), quando dificilmente conseguiu-se correlacionar implementações com
iniciativas de transformações de negócio. As implementações OO foram focadas no
campo técnico.
10
Dando os primeiros passos em SOA
Por que não adotar padrões abertos na interoperabilidade entre aplicações? A idéia é
óbvia, mas implementar e adotar padrões abertos não é uma tarefa fácil. Existem
barreiras tecnológicas e comerciais. Muitos vendedores desenvolvem suas tecnologias e
tentam impor esta tecnologia proprietária como um padrão de fato ao mercado, forçando
sua adoção pelos outros atores da indústria.
Mas, voltando à nossa busca pela interoperabilidade, alguns passos importantes foram
dados nas últimas décadas, que contribuíram em muito para chegarmos ao SOA. Um
deles foi o advento do conceito de orientação a objetos. Infelizmente, embora o conceito
fosse muito interessante, não se conseguiu na prática, obter a desejada interoperabilidade
entre os objetos de diferentes tecnologias. Uma biblioteca de objetos escritos em
VisualBasic não interage com uma biblioteca de objetos escritos em Java e vice versa. E
11
isto apesar dos esforços de organizações voltadas a especificar padrões, como o OMG
(Object Management Group) que desenvolveu a especificação CORBA (Common Object
Request Broker).
Na teoria, CORBA foi uma grande idéia, mas devido a concorrência comercial acabou
não decolando. A Microsoft por exemplo, criou seu próprio “CORBA”, denominado de
DCOM (Distributed Component Object Model), que facilita o processo de uso de objetos
dentro do mundo Microsoft. Entretanto, não é possível usar este padrão fora das
plataformas Microsoft.
Mas as idéias da orientação a objeto ficaram. Porque não identificar as causas de não ter
tido sucesso? Obviamente a falta de padrões abertos era a principal. Com o advento do
padrão XML, que hoje já é uma convenção global, aceita por qualquer empresa ou
usuário da informática, podemos pensar em uma nova solução para o desafio da
interoperabilidade.
12
Ainda existirão aplicações no mundo SOA?
Uma dúvida que surge nos vários debates em que participo: como SOA são componentes
que são aglutinados e coreografados para compor uma aplicação, terá ainda sentido falar
em pacotes como ERP, CRM ou Recursos Humanos?
Os componentes que constituirão estas futuras “aplicações SOA” podem ser divididas em
duas camadas, uma voltada para interação com os usuários e outra para suportar serviços
de negócios. A camada de serviços de negócio é constituída de componentes que
implementam os processos de negócio.
Portanto, ao iniciar nossa jornada em direção ao mundo SOA, começamos a listar alguns
questionamentos que teremos pela frente. Que impactos o SOA acarretará na organização
de TI? Como alocar prazos e budgets para projetos onde muitas vezes teremos apenas que
descobrir e aglutinar componentes que já estão prontos? Qual o perfil do profissional que
fará a coreografia dos componentes? Enfim, teremos belos e desafiadores dias pela
frente!
13
SOA e a modernização das aplicações legadas
Todos as empresas tem centenas de aplicações legadas em seu portifólio. E estas não são
apenas as aplicações Cobol escritas há dez ou quinze anos atrás, mas também os
programas escritos em Perl ou VB há três ou cinco anos, cujos autores já não estão mais
na empresa ou simplesmente mudaram de função. Importante lembrar que nomear uma
aplicação como legada não signfica vê-la de forma pejorativa, uma vez que estas
aplicações geralmente operam o cerne dos negócios das empresas. Por exemplo, mais de
80% de todas as transações eletrônicas globais são processadas pro mainframes.
Um problema que é comum na imensa maioria das empresas é que estas aplicações foram
escritas sob o paradigma do modelo computacional da época, como, por exemplo cliente-
servidor. São aplicações monolíticas e nem sempre fáceis de serem modificadas. Além
disso, muitas vezes as tecnologias usadas para escrevê-las não eram as mais adequadas. É
comum ver aplicações escritas em VisualBasic (VB) ou PowerBuilder (PB) simplesmente
porque a empresa definiu em determinada época que o VB ou o PB seria a tecnologia
para todas as aplicações. É o clássico exemplo que os americanos chamam de “one size
fits all”, onde uma única ferramenta é usada, a despeito de ser ou não a melhor solução
para cada caso.
Estamos diante de um imenso desafio. As empresas precisam ser mais ágeis e flexíveis,
mas as aplicações que as sustentaram até hoje não respondem com a velocidade adequada.
Gasta-se muito tempo e dinheiro nos esforços de integração e manutenção, sobrando
muito pouco para projetos novos e inovadores. Por outro lado, sabemos que as aplicações
legadas devem continuar conosco durante muito tempo. De maneira geral as aplicações
ficam muito mais tempo ativas que o inicialmente planejado.
Uma solução seria desenvolver novamente estas aplicações. Mas algumas estatísticas
como a da Software Productivity Research mostram que pode custar pelo menos 5 vezes
mais desenvolver um novo código que reutilizar o código já existente. Considerando que
pelo menos de 40% a 60% do código existente nas empresas pode ser reusável, por que
não explorar um novo paradigma computacional, o modelo SOA, como solução para
modernização do portifólio de aplicações? Relembrando, SOA é uma arquitetura para
construção de sistemas distribuídos que visualizam a funcionalidade das aplicações como
serviços.
A adoção do modelo SOA, vista por uma ótica pragmática, permite modernizar as
aplicações, reusando o código já existente. Permite transformar ativos legados em
componentes visualizados como serviços. Importante considerar que adoção de SOA tem
um componente tecnológico muito forte, mas transcende a tecnologia, envolvendo
mudanças na organização e no “pensamento” dos desenvolvedores.
14
Entendendo como e onde SOA e Web Services interagem
Tenho observado que muitas vezes as discussões sobre SOA caminham para um viés
totalmente tecnológico. Mas, SOA é mais que tecnologia pura. SOA é uma arquitetura de
software. E, claro, tem um componente tecnológico forte, que são os módulos de
software que implementam os conceitos especificados pela arquitetura. Estes
componentes podem ser os Web Services. Assim, SOA deve ser visto como princípios de
desenho de software enquanto que os Web Services tratam das especificações
tecnológicas.
E o que são Web Services? Podemos chamar de Web Services qualquer software que
utlize os padrões abertos WSDL (Web Services Descrition Language), SOAP (Simple
Object Acesses Protocol) e UDDI (Universal Descrirption, Discovery and Integration).
Para implementar a arquitetura SOA não precisamos de Web Services, mas para garantir
plena interoperabilidade são necessários padrões abertos. Daí a confusão entre os termos
SOA e Web Services, quando muitas vezes SOA é visto como simples implementações
de Web Services.
Vamos imaginar o mercado financeiro, que precisa ser muito rápido em lançamento de
produtos e reações a movimentos da concorrência. Um banco, ao identificar o potencial
de negócios de um novo produto, tem uma janela de oportunidades bem pequena para
colocá-lo no mercado, divulgá-lo e ganhar dinheiro com ele, antes que a concorrência
anuncie também com produtos similares.
Este produto é implementado por processos de negócio e como todo produto financeiro,
deve ser plenamente suportado por tecnologia da informação e aplicações. Se o banco
puder aproveitar partes dos processos (componentização dos processos de negócios) e
dos aplicativos já existentes, sem contorcionismos em modificar códigos de programas
espalhados por dezenas de aplicações, com certeza teria uma vantagem competitiva
significativa.
Claramente vemos que os benefícios com SOA passam por por uma reposta mais rápida
ao mercado (menor time-to-market) e manutenções mais rápidas e menos custosas.
Implementar SOA tem uma abrangência maior que uma simples implementação de
tecnologia. Envolve mudanças no modelo de desenvolvimento e princípios de desenho de
software. Levar o debate SOA apenas para o lado tecnológico não trará os benefícios
esperados.
15
SOA também é tecnologia!
Nos últimos posts sobre SOA enfatizei o fato de precisarmos olhar além da tecnologia.
Mas agora gostaria de voltar a trocar idéias sobre tecnologia.
Falar em tecnologia no mundo SOA é algo mais que colocar uma camada de Web
Services em cima das aplicações atuais ou novas.
Devemos olhar o fator tecnologia sob um ângulo estratégico, definindo uma plataforma
SOA que seja adequada aos objetivos da empresa.
Afinal se nossa entrada no mundo SOA é para conseguirmos que a organização se torne
mais ágil e rápida às mudanças no cenário empresarial, fazendo com que as integrações
entre suas próprias aplicações e do ecossistema em volta seja mais fácil, não podemos
olhar a plataforma tecnológica unicamente pelo simplista viés do “mais barato...”.
A plataforma SOA que você adotar (plataforma é a infra-estrutura de software que você
vai usar para construir, entregar, monitorar e gerenciar serviços) vai influenciar sua
capacidade de alcançar ou não os objetivos a que você se propôs ao entrar no SOA.
Portanto, é um aspecto que deve ser analisado com bastante critério.
SOA não é um produto único que se compra na prateleira (“quero um software SOA...”),
mas um conjunto de produtos de software que você vai aos poucos adicionando e
integrando ao seu portifólio, de acordo com o grau de maturidade de SOA na empresa.
16
Discutindo SOA e comendo pão de queijo em Belo Horizonte
Nesta próxima terça estarei em Belo Horizonte, participando de um Road Show da IBM.
Minha palestra será sobre SOA e será uma boa ocasião para trocar algumas idéias sobre o
tema com nossos clientes e prospects. Aliás, também será uma excelente ocasião para
uma boa cozinha mineira, fechando a tarde com pão de queijo! Voces sabiam que o
Wikipedia já tem uma entrada para pão de queijo?
SOA permite criar um modelo digital dos serviços (unidades de trabalho) da organização
e para isto acontecer é necessário que haja uma profunda interação entre TI e o negócio
em si.
O modelo de orientação a serviços incentiva que tanto TI como negócios falem a mesma
linguagem, pois ambos devem acordar sobre os serviços, suas funcionalidades e níveis de
granularidade. Sem uma mesma linguagem jamais estes serviços poderão ser
implementados adequadamente.
Portanto, concentrar o foco na tecnologia não será suficiente para que a organização
chegar ao modelo orientado a serviços. Na minha opinião, o sucesso na empreitada de
SOA vai além da tecnologia. A área de TI deverá rever seus processos de
desenvolvimento e manutenção bem como o skill dos seus desenvolvedores e arquitetos,
que tem que ser ajustados a um novo e mais intenso modelo de relacionamento TI-
negócios.
Neste contexto surge a figura de um projetista SOA, que deve ter uma profunda
compreensão das características dos processos de negócio e ser o elemento de ligação
entre a visão de TI e de negócios. O projetista SOA é o indivíduo que vai traduzir os
processos de negócio em especificações de serviços, para posterior implementação em
códigos de software.
17
Puxa, mais SOA!
Aí as coisas mudam. De quem é a propriedade do serviço que poderá ser reusado por
diversas aplicações? Quem vai alocar o budget para seu desenvolvimento? Quem dará a
palavra final em questões como prioridade no seu desenvolvimento ou eventual
modificação?
Estes serviços reusáveis serão compartilhados por várias aplicações e pode-se questionar:
que unidade de negócios vai bancar os custos de desenvolvimento e como recuperar estes
custos quando outras áreas da empresa utilizarem este serviço?
Na minha opinião estamos criando com SOA um novo e diferente ativo de TI: serviços
compartilháveis. Estes serviços não pertencem a uma área da empresa, mas à toda a
empresa. Precisamos, portanto, de um novo modelo de governança.
Neste modelo deve-se avaliar se o serviço será reusável e caso seja, seu desenvolvimento
e posterior manutenção não poderá onerar o budget de uma área específica. Os processos
de change management também deverão ser revistos para contemplar a questão do
compartilhamento.
Acredito que SOA vai resultar em grandes benefícios para as organizações. Mas a cada
dia fica mais claro que precisamos pensar SOA indo além da tecnologia, revendo também
os processos, skills e a organização de TI.
18
SOA nos traz de novo a computação centralizada?
O último post sobre SOA gerou um comentário muito interessante, com uma indagação:
“SOA traz de volta a computação centralizada (física e logicamente) em termos de
hardware e software?” .
Na minha opinião SOA é computação distribuída por excelência, pois permite expor e
acessar serviços onde que eles estejam. E um cenário futurista de “Services Network”,
inclusive com serviços prestados por empresas especializadas, pode se tornar presente
muito rapidamente.
SOA tem muita sinergia com o conceito de Grid Computing. O cenário empresarial dos
próximos anos aponta para um contexto de organizações virtuais onde SOA e Grid se
encaixam perfeitamente. Abaixo vou reproduzir um capítulo do meu livro sobre Grid
Computing (Grid Computing: um novo Paradigma Computacional), editado pela
Brasport:
19
e das pranchetas dos desenhistas. Com o surgimento da engenharia concorrente ou
simultânea e com os avanços da computação, desenvolvem-se os projetos de engenharia
por várias equipes, dispersas geograficamente. A engenharia virtual pressupõe que
diversos engenheiros, localizados até mesmo em países diferentes, estarão trabalhando
simultaneamente no mesmo projeto. Com a utilização dos conceitos de simulação e
realidade virtual, os projetistas conseguem visualizar a realidade, facilitando o
desenvolvimento do projeto e a correção de erros.
20
c) Negócios baseados em oportunidades, explorando a velocidade e agilidade típicas
das redes de organizações virtuais;
d) Organização virtual por excelência, adotando o uso de recursos de fora da
empresa. Entre os conceitos podemos citar escritórios virtuais, tele-trabalho, tele-
cooperação e assim por diante;
e) Capacidade de integração, reunindo-se rapidamente a outras empresas para
responder à flutuação da demanda.” .
Para mim fica claro que este contexto de dinamismo da organização virtual, aliado a uma
demanda elevada de recursos computacionais compartilháveis, tendem a ser um incentivo
muito forte para o uso prático dos conceitos de SOA e Grid Computing. Dêem uma
olhada nos conceitos de Open Grid Services Architecture – OGSA – em
www.globus.org/ogsa para maiores informações.
21
SOA e os CIOs
Esta semana estive fazendo palestras em dois eventos com parceiros da IBM. Nos dois o
tema foi SOA. Os participantes eram executivos de TI e de linhas de negócio, e está
ficando bem nítido para mim a importância que eles estão dando ao assunto.
As razões para isso são claras. O mundo de negócios em que vivemos é cada vez mais
desafiador. Os limites de tempo e espaço que restringem nosso dia a dia estão
desaparecendo. Podemos fazer uma compra ou acessar nosso saldo bancário pela Internet
a qualquer hora do dia ou da noite. As mudanças e transformações no cenário empresarial
já são uma constante. Conseguir e manter vantagens competitivas sustentáveis depende
cada vez mais da capacidade da empresa em ser inovadora em seus produtos, processos e
modelos de negócio.
Aliás, inovação é considerada estratégica não só para empresas, mas para países. O
Fórum Econômico Mundial em 2006 deixou claro esta visão: “The obsolescence of many
20th century structures compels leaders to develop fresh concepts, new institutional
models and more-flexible processes for serving diverse populations”. Uma pesquisa que
a IBM fez em 2006, chamado “Global CEO Study” , que pode ser acessada em
http://www-935.ibm.com/services/us/gbs/bus/html/bcs_ceostudy2006.html?re=bcsceo
identificou inovação como o fator que caracterizava as empresas com desempenho acima
da média de suas indústrias.
A proposta do SOA é eliminar este problema (ou elo menos mitigá-lo sensivelmente...).
Daí o interesse dos executivos de negócio e de TI na sua adoção. Algumas pesquisas
mostram claramente que SOA estás sendo usado inicialmente para resolver os imensos
problemas de integração internos, e em um segundo momento as integrações externas,
com parceiros de negocio e clientes.
Bom, o resumo de tudo isso é que os CIOs e os profissionais de TI devem olhar SOA
com atenção. Para maiores informações, além do site DeveloperWorks que vocês já
devem acessar regularmente (se não, deveriam...), sugiro acessar também
22
www.ibm.com/soa e adicionalmente ler o SOA World magazine em http://soa.sys-
con.com/. E recomendo a leitura de um número específico do IBM Systems Journal
dedicado ao assunto, em http://www.research.ibm.com/journal/sj44-4.html .
23
Vamos pensar SOA de forma diferente?
O que SOA nos permite fazer? Decompormos o que chamamos de aplicações em suas
partes mais elementares (serviços), que podem agora ser recombinadas da maneira mais
conveniente. E não devemos nos esquecer que isso só é possível porque temos padrões
abertos! Neste futuro contexto, IT passa a ser um agente que favorece e impulsiona
mudanças.
Como será este cenário de aplicações sendo rearrumadas rapidamente? Primeiro teremos
muito mais condições de criar redes de valor colaborativas, pois as empresas poderão
mais facilmente integrar seus processos, da forma que for mais adequada para cada
oportunidade de negócios. Também veremos uma competição mais acirrada...Pensem:
como não teremos mais serviços fechados dentro de padrões proprietários (e difíceis e
custosos de serem compartilhados), as barreiras de entrada serão mais baixas. Muitos
serviços poderão ser obtidos de fontes externas, o que vai permitir mais empresas
adotarem tais serviços mais rapidamente.
Estamos sonhando alto? Uma utopia? Ao falarmos em Utopia, a primeira coisa que nos
vem em mente é algo irrealizável, inatingível. De fato, se formos buscar o significado da
palavra Utopia encontraremos “Projeto irrealizável; quimera.”. Mas, se pensarmos
diferente, a utopia pode favorecer uma visão crítica da realidade. A utopia também pode
ser uma forma de ação, uma vez que provoca o movimento das pessoas (e das empresas).
Portanto pode ser um instrumento de transformação. E citando uma frase que li algum
tempo atrás: "O presente pertence aos pragmáticos. O futuro é dos utopistas"! .
24
Estamos preparados para SOA?
Há alguns dias um colega meu, CIO de uma grande empresa me perguntou “como
poderei saber se estou ou não preparado para SOA?”. A pergunta gerou um debate
interessante, que gostaria de compartilhá-las com vocês.
Bom, antes de mais nada acordamos em um ponto: SOA tem tudo a ver com processos de
negócios. Processos de negócios são atividades que geram valor para a organização, seus
stakeholders e clientes. Por exemplo, é através dos processos de negócios que a
organização entrega produtos e serviços aos seus clientes. Claro que em mundo cada vez
mais informatizado, estes processos de negócios são suportados por software e, portanto,
o conceito de SOA vai precisar de tecnologia para ser implementado. Mas, a tecnologia é
meio e não fim!
Também concordamos que a estratégia SOA deve estar relacionada com objetivos de
negócio, como possibilitar que a empresa tenha maior agilidade e rapidez às demandas do
mercado, tornando os processos de negócio mais adptáveis à estas mudanças.
Depois analisamos como uma empresa “vê” sua TI. Fizemos uma análise simplista,
classificando as empresas em três níveis de maturidade de TI. No primeiro, TI é vista
como fornecedora de infra-estrutura, atuando basicamente no nível operacional, focada
em custo, sendo “invisível” à organização. Em um nível mais avançado TI é vista como
facilitadora. Neste nível já existe um forte preocupação com governança e há
reconhecimento do papel de TI pelos executivos pares do CIO dentro da organização. E
finalmente, em um estágio mais avançado, TI é vista como agente de inovação,
contribuidora pró-ativa para as estratégias do negócio. O CIO é considerado como o
“consultor” do CEO.
Se a área de TI estiver no terceiro e mais avançado nível, estará, sem sombra de dúvida
preparado para SOA. Se estiver no segundo nível, existirá grande potencial para adoção
de SOA, mas é necessário uma maior preparação da própria organização. E se estiver no
primeiro nível, SOA ainda está meio longe...Tem um trabalho maior pela frente, mas
pode ser um primeiro passo na direção de estar mais afinado com o negócio e menos
encastelado na tecnologia.
Ok, e como posso saber em que nível a empresa estará? Que tal analisar quanto tempo e
energia o CIO gasta com sua equipe, com seus pares e o ecossistema de fornecedores de
tecnologia, e com o CEO e o board da organização? Se ele estiver dedicando a maior
parte do tempo com sua equipe, provavelmente estará focado mais intensamente nas
questões técnicas, preocupado quase que exclusivamente com custo, envolvido no dia a
dia da operação. É uma organização de TI focada na tecnologia e SOA será visto como
mais uma implementação tecnológica descolada do contexto do negócio. Provavelmente
terá pouco apoio e comprometimento dos demais executivos. Poucas chances de sucesso
se continuar focado na tecnologia!
25
Bem, e se o CIO estiver dedicando um tempo maior aos seus pares e ao ecossistema de
fornecedores de tecnologia? Este é o estágio típico das organizações consideradas como
facilitadoras do negócio. São bem avaliadas pelos demais executivos de negócios, são
bem consideradas pelos fornecedores de tecnologia, mas ainda sim os altos executivos
não consideram a área de TI como alavancadora de inovações ou contribuidoras para a
estratégia do negócio. Ela é vista como responsiva às demandas, mas não pró-ativa em
inovações e geração de novas oportunidades de negócio. Neste estágio SOA tem espaço,
mas é necessário um trabalho mais intenso de aproximação com as linhas de negócio para
conseguir seu comprometimento. A estratégia SOA deve estar direcionada à agenda dos
objetivos do negócio, como acelerar as respostas à novas oprtunidades ou riscos/ameaças,
inovação em produtos e serviços, otimização da cadeia logística e assim por diante. SOA
pode ser a passagem de ida para um nível mais avançado.
26
Capacitação em SOA
Portanto SOA ainda é desconhecido. Muita gente confunde SOA com Web Services, mas,
no meu entender, ninguém discorda que a capacitação adequada em SOA é fundamental
para termos sucesso na sua implementação.
SOA apresenta desafios interessantes: não envolve apenas tecnologia, mas demanda
muito de negócios. O objetivo de uma estratégia SOA não é implementar SOA, mas, por
exemplo, melhorar a flexibilidade do negócio. Além disso é um alvo em movimento, com
novos produtos, “best practices” e metodologias aparecendo a cada instante. O resultado
prático é que o que precisaremos saber amanhã não é o que precisamos saber hoje...
Bem, vamos tentar fatiar o elefante. Criar um plano de capacitação em SOA depende de
inúmeros fatores. Um é a maturidade e o “starting point” da organização frente a SOA.
Se o “starting point” for construir Web Services em cima de aplicações desconectadas a
exigência de treinamento será diferente de um “starting point” focado em integração
externa, envolvendo parceiros e clientes A estratégia SOA da organização também é um
fator influenciador na criação do plano de treinamento. Sem uma visão de longo prazo
ficarão faltando peças que mais tarde vão fazer sentir sua ausência.
27
Bell, e “Service-Oriented Architecture (SOA): Concepts, Technology, and Design”, de
Thomas Erl. Na Amazon vão aparecer vários outros livros sobre o assunto.
E depois dos treinamentos? Que tal pensar em workshops que identifiquem e analisem as
oportunidades de implementar SOA na empresa? Como vemos, temos muita coisa a fazer.
O importante é sair da inércia e ir em frente.
28
Apresentando SOA no CIO Executive Day em Curitiba
Julho de 2007: bem no meio de curtas férias fiz uma palestra no CIO Executive Day, em
Curitiba. É um evento bem interessante e que terá sequencia na semana que vem em
Porto Alegre. Caso queiram ver detalhes do evento acessem
www.cioexecutiveday.com.br .
Minha palestra foi “Inovação em TI: criando diferencial competitivo”, onde procurei
mostrar a importância da inovação para o sucesso de qualquer empresa e como é
fundamental que a área de TI esteja sendo vista como contributiva para este processo.
Há uma frase bem emblemática deste contexto, que foi publicada em um artigo da
Harvard Business Review (“The Quest for Resilience”), onde os autores dizem “In the
past, executives had the luxury of assuming that business models were more or less
immortal. Companies always had to work to get better...but they seldom had to get
different, not at their core.”
Hoje está nítido que a preocupação com inovação é cada vez maior, e alguns analistas de
indústria já afirmaram:
O estudo que a IBM realizou com 750 CEOs (“ The Global CEO Study 2006” ) mostrou
que “ 65% expect to radically change their companies during the next 2 years”. Fica claro
que inovação, acompanhada por mudanças fundamentais nos processos e modelos de
negócio é o melhor caminho para o crescimento sustentável.
Um fórum que a IBM organizou no ano passado, “IBM CIO Leadership Forum”, em
Monte Carlo, Mônaco, mostrou que, no entendimento dos CIOs presentes, a globalização,
a complexidade crescente nos negócios e mudanças cada vez mais rápidas no cenário
29
econômico e empresarial estão transformando as bases dos atuais modelos de negócio e
para eles “IT is the lifeblood that enables this transformation” . Este fórum mostrou que
84% dos CIOs presentes acreditam que a tecnologia está transformado substancialmente
suas indústrias e alavancando vantagens competitivas.
78% dos CEOs (pelo “Global CEO Study” da IBM) também acreditam que a integração
entre o business e TI seja fundamental para inovação, mas entendem que há uma brecha
significativa entre o nível desejado e o real quando se fala nesta integração.
E porque TI não tem sido tão inovadora quanto poderia ser? Várias razões contribuem
para isso, como um excessivo foco no dia a dia, manter uma posição mais passiva,
esperando que os executivos de negócio direcionem as ações de TI ou mesmo um viés
tecnológico, considerando a tecnologia como a solução para todos os problemas. Além
disso, em muitas organizações TI ainda é vista como suporte, focada na automação de
tarefas e manutenção da infra-estrutura tecnológica. Não são muitas as empresas que já
olham TI como business, a encarando como fonte geradora de receitas e maximizadora de
oportunidades de negócio.
Bem e um dos pontos altos de qualquer evento é troca de idéias no café ou, no caso deste,
no coquetel de encerramento. E, entre um vinho e outro, me perguntaram, “Ok, gostei do
papo sobre SOA, mas como medir o ROI desta iniciativa?”. Para responder é melhor
mostrar primeiro o que é SOA. É um conceito simples, que é dissolver suas aplicações
em “building blocks”, (serviços) que podem ser infinitamente rearranjados. Imaginem o
conhecido brinquedo Lego, onde com as mesmas peças vocês podem construir diversos
objetos. Cada peça destas é um serviço SOA e os objetos são as novas aplicações. Criar
ou transformar um novo processo de negócios nos leva, no âmbito de TI, a rearrumar os
serviços de TI que suportam as atividades destes processos. Não existem demoras em
escrever novas aplicações ou alterar dezenas ou centenas de programas em linguagens
diferentes.
30
calculando o retorno para as implementações subseqüentes, uma vez que SOA produz
benefícios crescentes à medida que se entranha na organização.
31
Outro CIO Executive Day, agora em Porto Alegre
Um dos temas principais foi SOA. Porque este tema é tão debatido? Está claro para todos
nós que a flexibilidade do negócio depende da flexibilidade de TI. Infelizmente, na
maioria das vezes as arquiteturas de TI das empresas não são flexíveis o suficiente. Por
que? No decorrer de várias décadas os sistemas foram implementados sem uma visão
integrada, ocasionando hoje grandes problemas de integração.
Se a empresa precisar criar ou mudar processos de negócio, vai sentir na pele o problema:
TI responde lentamente, pois para mudar processos, diversas aplicações devem ser
modificadas. Fica fácil de explicar porque em muitas organizações o relacionamento de
TI com as áreas de negócio é tão conturbado.
Daí o grande interesse que SOA vem despertando entre os CIOs. As pesquisas refletem
este quadro. Uma delas, feita pelo Aberdeen Group (What CIOs Should Know About
SOA) mostra que os Top 3 impulsionadores para SOA são Development of new
capabilities (50%), Managing IT complexity (44%).e re-usage of apps via Web services
(43%).
Outra pesquisa, esta efetuada pelo Forrester Research em abril de 2006, para a pergunta
“Como SOA está sendo usada”, teve como resposta integração interna com 83%, seguida
32
de integração externa e já aparecendo, para as grandes corporações, transformação do
negócio com 46%.
33
SOA, Web 2.0 e aplicações mashup
Aplicações mashup estão no cerne do modelo Web 2.0. As primeiras aplicações mashup
que apareceram, muitas delas usando Google Maps, ainda são a ponta do iceberg. Nós
estamos dando os primeiros passos em um novo mundo, onde usuários e parceiros de
negócios desenvolverão aplicações em cima das nossas próprias aplicações.
Mas, para fazer isso, precisamos adotar o conceito de visualizar nossas aplicações como
plataformas, onde o mundo externo poderá acessá-las via APIs abertas e publicadas. Se
olharmos com atenção, veremos, na prática, que estamos falando da junção dos mundos
SOA e Web 2.0. Bem, vou explicar melhor...
Para começar vamos ver alguns casos práticos. Começando com o eBay. Quando o eBay
foi criado, a chave para o sucesso do comércio eletrônico era criar um site na Web. Com
este modelo o eBay tornou-se um dos maiores sucessos da era da Internet. Mas, hoje, a
ação está onde os usuários a criam, ou seja, em páginas de relacionamento MySpace, em
vídeos no YouTube ou em seus blogs. Portanto, para o eBay se manter bem sucedido,
tem que estar em todos estes lugares. Como fazer isso? Abrindo APIs que ofereçam
serviços que permitem às pessoas comprar itens do eBay fora de seu site central. Por
exemplo, permitir acessar o eBay de dentro do Facebook ou MySpace. Nas declarações
de seus executivos, nos recentes eventos para investidores ficou claro a estratégia futura:
o eBay não será apenas um site, mas um provedor de serviços que reforce o comercio
eletrônico em toda a Internet.
Outro exemplo é a Amazon. O seu fundador e CEO, Jeff Bezos, disse recentemente:
“We´re all building this thing together”, ao comentar a estratégia da empresa em
incentivar desenvolvedores externos a acessarem os serviços da Amazon e os embutirem
em outros sites e aplicações. E embora muitas empresas ainda tenham receio de abrir seus
dados proprietários, a Amazon é clara: “The more data that we’re able to put in the hands
of external developers, the more interesting tools, sites, applications will be built, and the
more of those that exist, the greater the return to Amazon. We’re going to see more traffic,
more clicks, and ultimately we’ll see more purchases. So it’s definitely not like a science
experiment”.
Querem um terceiro exemplo? Google! Abrindo APIs para suas aplicações, incentivam a
inovação e novas aplicações. Um executivo do Google disse recentemente: “We expect
new and creative ideas to come out of this that we haven´t thought of yet”. Que estas
empresas estão fazendo? Abrindo seus sistemas via APIs para que parceiros externos
criem novas e inovadoras aplicações, integrando os processos de negócios. O acesso às
34
APIs Google Maps pode ser enncontrado em www.google.com/apis/maps/ .
Mais ainda? Bem, que tal olhar o Zillow.com (www.zillow.com) ou a JetBlue Airways,
onde seus passageiros podem acompanhar a posição do avião, usando GoogleMaps, na
tela de seu assento, sintonizando o canal 13. Aliás a JetBlue permite a cada um
acompanhar a situação de cada vôo em tempo real, acessando seu site
(www.jertblue.com) e clicando nas opções Manage your flights/Track a flight. Que nem
aqui...
Também tem um video interessante no YouTube sobre o uso desta tecnologia, que pode
ser acessado em http://br.youtube.com/watch?v=ckGfhlZW0BY.
Bem, e se quiserem dar uma olhada nas inúmeras APIs para Web 2.0 disponíveis, visitem
//programmableweb.com. Vale a pena.
Qual é a mensagem que estes exemplos estão nos passando? Abram suas plataformas de
negócios para incrementar a velocidade, escopo e ritmo da inovações. Manter as
aplicações fechadas vai restringir a inovação aos limites de criatividade da sua própria
equipe de profissionais. E isto não se aplica apenas ao Google, Amazon ou eBay, mas a
bancos, empresas aéreas, seguradoras, industrias automotivas, órgãos públicos (que tem
imensas bases de dados, muitas vezes subutilizados pela sociedade), etc, etc, etc...
OK, mas como colocar estas idéias em prática? De um lado temos as comunidades com
tecnologias que permitem criar aplicações mashup. Mas do lado da empresa? Como abrir
APIs para a parafernália de aplicações com problemas de integração e diversidades
tecnológicas? A resposta, no meu entender, está na proposta do SOA. Porque não criar
uma camada, que chamaremos de plataforma de negócios, em cima das aplicações da
empresa? Esta plataforma abriria à comunidade de usuários e parceiros de negócios os
serviços que as aplicações internas oferecem (quando falamos em aplicações, falamos em
processos de negócios) via APIs abertas e publicadas.
35
Web 2.0, que são por natureza dinâmicas e baseadas no conceito de serviços, demanda
muitos ajustes nas técnicas e processos de desenvolvimento de software que as empresas
atualmente adotam. Demanda novos skills de programação, com ênfase em Ajax
(www.openajax.org) e scripting languages, como Perl, PHP, Python e Ruby. Exige
técnicas (lightweight ou simplified programming models) e processos de
desenvolvimento mais rápidos (Agile Software Development). Uma introdução
superficial ao assunto pode ser vista em
http://en.wikipedia.org/wiki/Agile_software_development. E demanda também um
cuidado muito maior nos projetos de interfaces com os usuários.
36
SOA e a comunidade Apache
Muitos dos projetos da comunidade Apache estão sendo direcionados para SOA. A sua
arquitetura altamente componentizada, com componentes plugáveis, facilita a construção
de projetos orientados à SOA.Se analisarmos uma plataforma hipotética voltada a SOA,
vamos identificar alguns macro componentes, como uma “core platform” que pode ser
considerado a base para execução e integração dos serviços, um “service delivery bus”
para roteamento de mensagens e transações, “configuration services”, que organiza a
montagem dos componentes em serviços e uma plataforma de comando, para fornecer
serviços de grenciamento e governança.
Mas vale a pena falar de um outro projeto extremamente interessante, que é o Tuscany. O
Tuscany implementa um modelo de implementação SOA chamado de SCA (Service
Component Architecture). A proposta da especificação SCA é simplificar o
desenvolvimento de aplicações SOA, facilitando o desenvolvimento de componentes.
Para isso cria um modelo para construção de componentes independente de linguagens de
programação e facilita a construção de aplicações compostas, que podem ser “montadas”
a partir destes componentes (lembram-se do jogo Lego?).
Para maiores informações sobre SCA acessem o site da Open SOA Collaboration
(http://www.osoa.org/display/Main/Home), grupo formado por diversas empresas, como
IBM, BEA, Sun, RedHat e outras, e como dito em seu site, “The Open SOA
Collaboration represents an informal group of industry leaders that share a common
interest: defining a language-neutral programming model that meets the needs of
37
enterprise developers who are developing software that exploits Service Oriented
Architecture characteristics and benefits.”.
Tem um documento sobre conceitos de SCA que recomendo seja lido: “Introducing
SCA”, que vocês poderão acessar em
http://www.davidchappell.com/articles/Introducing_SCA.pdf
Na minha opinião, todo desenvolvedor que está buscando implementar soluções SOA
deve acompanhar de perto a especificação SCA e os projetos que lhe dão suporte. O
Tuscany é um bom exemplo. Ele pode ser encarado como um indicador do nível de
desenvolvimento prático da especificação.
Bem, e para terem muitas outras informações adicionais sobre SCA e o projeto Tuscany,
acessem o blog de meu colega da IBM, Luciano Resende em http://lresende.blogspot.com
e também em http://www-03.ibm.com/developerworks/blogs/page/lresende.
March 21, 2007 – Eighteen leading technology vendors focused on driving technology
initiatives supporting the creation of industry standards around service oriented
architectures (SOA), today announced that key Service Component Architecture (SCA)
and Service Data Objects (SDO) specifications have completed incubation and will be
formally submitted to OASIS for advancement through its open standards process. The
SCA specifications are designed to help simplify the creation and composition of services,
critical to building applications using services based on an SOA approach. With these
SCA specifications now mature, the partners intend to turn over their standardization
process to OASIS. Additionally, the partners have completed work on the SDO
specifications, designed to enable uniform access to data residing in multiple locations
and formats, and will turn over stewardship of SDO/Java work to the Java Community
Process and non-Java (C++) work to OASIS.
The SCA and SDO specifications can help organizations to more easily create new and
transform existing IT assets, enabling reusable services that may be rapidly assembled to
38
meet changing business requirements. These specifications greatly reduce complexity
associated with developing applications by providing a way to unify services regardless
of programming language and deployment platform. Both are technologies designed to
simplify the representation of business logic and business data. Early customers are
already implementing and gaining value.
“We applaud the Open SOA Collaboration for reaching this milestone and for choosing
to take the next step and advance this important work through an open standards
process,” said Patrick Gannon, president and CEO of OASIS. “We look forward to
furthering the evolution of SCA from specifications to standards and to promoting the
broadest possible industry adoption through education and implementation efforts.”
Since November 2005, 18 companies have joined the effort to work on new industry
specifications aimed at simplifying SOA application development. Partner companies
include BEA Systems, Cape Clear, IBM Corporation, Interface21, IONA, Oracle,
Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG,
Siemens AG, Software AG, Sun Microsystems, Sybase, TIBCO Software, and Xcalia.
Together, these companies have achieved significant progress around SCA and SDO
specifications.
The partners will continue to incubate and drive technology initiatives focused on
simplifying SOA application development. Additionally, the group’s vendor-neutral Web
site (www.OSOA.org) will continue to serve as an information resource for access to
draft specifications and white papers, and provide a forum for industry input and
feedback.
About Open SOAThe Open SOA Collaboration represents an informal group of industry
leaders that share a common interest: defining a language-neutral programming model
that meets the needs of enterprise developers who are developing software that exploits
Service Oriented Architecture characteristics and benefits. The Collaboration is not a
Standards Body; it is a set of vendors who wish to innovate rapidly in the development of
this programming model and to deliver Specifications to the community for
implementation. These specifications are made available to the community on a Royalty
Free basis for the creation of compatible implementations. When mature, the intent is to
hand these specifications over to a suitable Standards Body for future shepherding. For
more information, visit www.osoa.org.”.
39
Um pouco de SCA
Bem, de lá para cá recebi alguns emails, solicitando mais informações sobre SCA. Aqui
vão elas:
Consegui também algumas dicas com um colega da IBM EUA, Doug Tidwell, que vou
compartilhar com vocês. Ele sugere a leitura do livro “SOA for the Business Developer:
Concepts, BPEL and SCA”, de Ben Margolis. Também sugere uma lista de papers
disponíveis no site developerWoks, como:
40
2) Building SOA Solutions with SCA (4 partes),
http://www.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_br
ent.html
3) Java SCA invocation styles: http://www-
128.ibm.com/developerworks/webservices/library/ws-soa-scajava/
4) Using PHP´s SCA and SDO extensions: http://www-
128.ibm.com/developerworks/webservices/library/ws-soa-scasdo/
5) Introduction to Service Data Objects: http://www-
128.ibm.com/developerworks/webservices/library/j-sdo/
Ok, acho que para começar o jogo temos bastante coisa para se ler e desenvolver. Mãos à
obra!
41
Previsões para 2008: Como ficará SOA?
Estamos chegando o final do ano de 2007...É impressão minha ou os anos estão passando
cada vez mais rápido? Bem, de qualquer modo, como muita gente faz, vou também me
atrever a fazer algumas “previsões” para 2008!!! Sim, é hora da chutorologia...
Para mim em poucos anos o termo IT (Information Technology) será substituído por BT
(Business Technology), uma vez que cada vez mais TI estará inserido nos negócios, se
tornando parte integrante dos negócios, gerenciado pelas linhas de negócios e até mesmo
tendo seus budgets definidos e alocados pelas linhas de negócio. Com isso o perfil dos
executivos e profissionais de IT, desculpem BT, penderá mais para business e menos para
expertise em tecnologia. Temos que começar a rever os currículos dos cursos de
graduação...
OK, e em termos de tendências, acredito que devemos prestar mais atenção à SOA/BPM
(SOA sem BPM estará incompleto), Web 2.0 e suas aplicações mash-up, Open Source e
virtualização.
Bem, Web 2.0 e as aplicações mash-up deverão sair do campo da “curiosidade” para
entrar no budget das empresas. Aliás, há um ano pouca gente sabia o que eram aplicações
mash-up...As coisas estão indo bem rápido e vamos começar a ouvir falar mais em
Enterprise 2.0, que poderá ser uma melhor aproximação do uso dos conceitos e
tecnologias da atual Web 2.0 dentro do cenário corporativo. É um tema que merece um
post específico e vou escrevê-lo em breve.
42
mais baratos para compor uma solução mais confiável que a oferecida por um único
dispositivo, mais caro.
E que outros impactos a virtualização nos trará? Segundo o IDC, seu crescente uso
tenderá a reduzir as previsões de venda de servidores baseados em plataforma x86 em até
4,5 milhões de unidades, em um horizonte de tempo até 2011.
Para terminar, que tal olharmos o outro lado? Aqui está uma pequena lista de tecnologias
que não decolaram...Para nos lembrar que nem sempre as previsões funcionam! Vejam
em http://www.news.com/8301-10784_3-9827095-7.html.
43
Janeiro de 2009: nosso último post sobre SOA!
Há algum tempo que não escrevia nenhum post sobre SOA. E eis que surgiu a
oportunidade. Um bate papo com um colega no restaurante da IBM, na sede da Pasteur,
no Rio, que tem uma bela vista para a enseada de Botafogo. Que me desculpem os
colegas de sampa, mas lá eles só tem vista para a avenida 23 de Maio!
Mas o papo surgiu quando debatiamos o efeito da retração econômica nos investimentos
de TI e mais especificamente em SOA. Uma retração econômica afeta ou não
investimentos em SOA?
Bem, qualquer retração econômica faz com que a maioria dos investimentos se
concentrem em redução de custos e em projetos de retorno rápido. Os projetos SOA não
podem ficar descolados do mundo real. Em tempo bicudos, devem entregar soluções de
negócio de resultados rápidos.
Aliás, um erro muito comum é dizer coisas como “este ano minha estratégia é
implementar SOA”. O objetivo não deve ser implementar SOA, mas sim implementar
melhorias nos resultados do negócio e SOA é meio para isso. SOA não pode e nem deve
ser um fim em si mesmo.
Onde conseguir budget para estes projetos? Basicamente existem três tipos de budget
para projetos SOA:
a) Budgets específicos para SOA, que aparecem quando alguma tecnologia como
ESB é necessária e seu custo não pode ser acoplado a nenhum projeto de negócio
específico.
b) Budgets para os projetos de negócios oriundo das LOB (Line of Business)
baseados em SOA. Tende a ser o mais comum.
c) Budgets redirecionados de outros projetos que não trazem valor agregado para o
resultado do negócio e que podem ser postergados ou cancelados em tempos de
retração econômica. Um exemplo? Nem pense em substituir XP por Vista nos
desktops. Porque não trocar as licenças do Office por softwares gratuitos como
Symphony ou OpenOffice?
A nossa conclusão, já na sobremesa, foi que o caminho para SOA é inevitável. A razão é
simples: cada vez mais TI está se transformando em BT (Business Technology), fazendo
parte do próprio negócio, contribuindo de forma decisiva para melhorar resultados da
44
companhia. Ora, sem SOA isto é praticamente impossivel. Como fazer a empresa ser
flexível, responder com rpoidez às mudanças no contexto de negócios, criar redes de
valor temporárias?
Mas, por outro lado a pressão pelo curto prazo existe e não podemos ignorar o mundo
real. Assim, buscando implementar projetos SOA de resultado rápido constrói-se, aos
poucos, uma plataforma SOA. Mas, não esquecendo que esta plataforma precisa que os
componentes sejam coerentes entre si. Ter uma estratégia SOA de longo prazo continua
sendo fundamental. Apenas, em tempos bicudos, implemente “projetos rápidos” como
uma forma de chegar lá.
45
Autor
Cezar Taurion
46