Os potenciais benefícios de SOA são claros, como a reutilização dos ativos existentes, mas o panorama dos padrões ainda é nebuloso. Em seu estudo mais recente sobre o assunto, a Forrester Research contabilizou cerca de 115 padrões flutuando ao redor de SOA e Web services. Descobriu também que é quase impossível confirmar quais fornecedores suportam quais padrões. Mesmo assim, os CIOs têm que seguir em frente com projetos SOA para satisfazer necessidades do negócio. Há vários anos, Hong Zhang, diretor e arquiteto chefe de Arquiteturas e Padrões de TI da General Motors, tem obtido um equilíbrio entre o dilema dos padrões e a utilização contínua de SOA.
Zhang acha bom que existam muitos padrões relacionados a SOA. “Isso indica que a indústria de software ruma para a ampla adoção de SOA”, diz. “O desafio é não haver um framework arquitetural comum, consistente, para orientar a evolução, a integridade e a integração destes padrões. Muitos deles ainda não atingiram a maturidade.”
Como fazer para navegar por estas águas turbulentas até os padrões amadurecerem realmente? Executivos de tecnologia e especialistas da indústria dão o seguinte conselho: monitore atentamente o cenário dos padrões e não limite suas opções, mas não adie os projetos SOA essenciais. Diversas estratégias podem evitar que você fique preso em uma armadilha de padrões.
Os padrões que importam
Antes de tudo, ao traçar seus planos para SOA elabore uma lista com os principais padrões, não uma lista abrangente demais. Padrões como SOAP e WSDL, por exemplo, já foram amplamente adotados, e outros, incluindo WS-Security, estão prontos para adoção disseminada, diz Randy Heffner, analista da Forrester Research. Mas outras especificações necessárias para criar Web services que operam com alta qualidade de serviço — como os padrões para gerenciamento, transações e segurança avançada – só amadureceram o suficiente para usuários agressivos de tecnologia, segundo Heffner.
Entre os padrões de SOA e Web services emergentes, Heffner sugere que os CIOs enfoquem SOAP 1.1, WSDL 1.1, WS-I Basic Profile 1.0 ou 1.1, UDDI 3.0.2, WS-Security 1.0 ou 1.1, WS-BPEL 2.0, BPMN, WSRP 1.0, XML Schema 1.0, XSLT 1.0, XPath 1.0, XQuery 1.0, XML Signature e XML Encryption.
Os CIOs devem privilegiar SOA baseada em padrões ao invés de protocolos nativos. “Mas não sacrifique a necessária qualidade de serviço (quality of service — QoS) para uma determinada aplicação só para usar padrões”, alerta Heffner. Quando uma aplicação precisar de QoS superior à que Web services podem fornecer, “recorra a expedientes táticos que se aproximem do design de especificações emergentes”, diz. Será que os CIOs têm que saber quais fornecedores estão suportando quais padrões, a esta altura? “Não de uma maneira mais ampla”, explica Heffner. “Mas os CIOs que estão fazendo uma escolha importante de parceria para infra-estrutura de software devem ter um bom panorama do suporte atual e futuro a especificações SOA e Web services dos fornecedores candidatos.” Você também tem que entender os planos dos seus atuais fornecedores, ensina Heffner. Do contrário, corre o risco de investir em uma tecnologia que talvez não cumpra as metas de negócio de longo prazo ou a estratégia de SOA da organização.
++++
Muitas empresas buscam soluções temporárias — middleware, por exemplo — para superar a falta de padrões amadurecidos. “Da perspectiva do CIO, existe muita pressão para adotar uma plataforma middleware onde não existem padrões, mas de uma maneira que não se fique preso a ela”, diz Jim Stogdill, CTO da Gestalt LLC, empresa de consultoria em defesa e energia que ajuda os clientes a implantar projetos SOA.
Mas é desaconselhável se comprometer demais com um fornecedor de middleware “porque depois o processo de mudança será muito mais disruptivo”, orienta Stogdill.
Ele recomenda que as organizações sigam padrões comuns como SOAP e WSDL e também observem onde seus fornecedores de aplicações de linha de negócio estão fornecendo serviços, e integrem aplicações de linha de negócio através destas interfaces de serviço usando middleware não intrusivo.
Estratégia seletiva da GM
Em suas primeiras iniciativas SOA, a General Motors aprendeu a identificar os padrões mais importantes para a meta que a empresa estava tentando alcançar. Em 2000 a GM lançou seu primeiro projeto SOA, uma arquitetura chamada Northstar, para seus serviços globais de showroom de veículos online (GM Global BuyPower). A meta da Northstar era estabelecer um plano de SOA comum global flexível o suficiente para suportar a dinâmica do negócio da GM. Para atingi-la, a GM projetou uma arquitetura que põe de um lado as funções de negócio e do outro o fluxo de processos de negócio (a seqüência das funções de negócio a serem executadas). A empresa também separou a localização física dos dados de negócio da localização física das funções de negócio que usam os dados. Além disso, as interfaces com o usuário foram separadas do fluxo de processos de negócio, das funções de negócio e dos dados de negócio, explica Zhang.
Em 2001, a GM implementou a arquitetura Northstar com êxito em mais de 40 países. A arquitetura ajudou a GM a suprir várias necessidades de negócio rapidamente, obedecer a regulamentações para acomodação de dados, realizar mudanças no fluxo de processos de negócio baseadas em regras de compromisso de negócio e variar a experiência de software do usuário final com base nas diferenças culturais de países individuais.
Como a empresa também usa SOA em outros serviços online voltados ao consumidor, incluindo os serviços GM OnStar, planeja desenvolver um programa corporativo de estratégia e governança para ampla implementação de SOA internamente e com parceiros externos. Como parte da implementação de SOA de próxima geração, a GM está avaliando os mais novos padrões e tecnologias capacitadores.
Para a GM, hoje, as especificações mais importantes são aquelas que ajudam a padronizar as interfaces de serviços através das camadas de serviços bem definidas (apresentação, processo de negócio e assim por diante). Em segundo lugar vêm as especificações que ajudam a padronizar a implementação dos serviços dentro de cada camada de serviço.
Para desenvolver sua estratégia de SOA corporativa, a GM está no processo de identificar padrões SOA levando em conta quais necessidades da empresa estão amadurecidas, quais devem ser monitoradas e quais são obrigatórias. Entre eles, a GM cogita o WS-I Basic Profile 1.1 para interoperabilidade corporativa. Depois disso, a empresa poderá tomar uma decisão embasada sobre quais fornecedores e produtos usar em sua ampla implementação de SOA.
++++
Também usuário de SOA, o TD Banknorth prioriza padrões que são adotados por fornecedores líderes de mercado no espaço SOA (por exemplo, a webMethods) e padrões que são reconhecidos por diversos organismos de padrões importantes. A instituição bancária utiliza uma arquitetura baseada em serviço como framework de desenvolvimento de Web services para integração de aplicações, de acordo com o CIO e vice-presidente executivo John Petrey. O TD Banknorth empregou SOA pela primeira vez em 2004 quando instalou o pacote de software Fabric da webMethods para usar um Web service com o objetivo de simplificar o processo de fazer mudanças em endereços de clientes.
Com o Web service, que está sendo implantado agora, os operadores do call center ou os funcionários de agências do TD Banknorth podem fazer mudanças em endereços, que entram em vigor automaticamente nas contas bancárias dos clientes. O banco também está planejando um projeto SOA que envolve um serviço de originação de empréstimos para pequenas empresas e outro projeto que diz respeito ao sistema de online banking da empresa.
“O principal benefício de SOA que usufruímos é a reutilização significativa de serviços no espaço de soluções de integração”, diz Petrey. O resultado é uma redução substancial do tempo de desenvolvimento do serviço e a criação de serviços de maior qualidade que requerem menos depuração e teste.
Até agora, o TD Banknorth adotou padrões básicos em torno de Web services, incluindo XSD, SOAP e WSDL. “De agora em diante, os padrões mais importantes serão relacionados a WS-I, como os de política, confiabilidade e segurança e, em menor grau, endereçamento”, revela Petrey.
O banco trabalha “apenas com padrões adotados por fornecedores reconhecidos como líderes de mercado no espaço SOA e considerados suficientemente maduros” por empresas de pesquisa como o Gartner, afirma Petrey. “Os padrões que adotamos são reconhecidos por diversos organismos de padrões, entre eles W3C e WS-I.”
O TD Banknorth consultou empresas que tinham adotado padrões como WS-Security e SAML “e descobriu que a maioria estava enfrentando dificuldades”, conta Petrey. “Os padrões, supostamente, estavam prontos para adoção mais de um ano antes, mas ninguém os empregava conforme haviam sido projetados. Não descobrimos nenhuma história de sucesso.”
Em sua incursão na arena de SOA, o banco aprendeu várias lições, entre elas criar uma arquitetura que promova uma implementação modular, flexível e incremental, possibilitando que estes padrões sejam adotados à medida que a funcionalidade assim o exigir, justifica Petrey.
Dominando o middleware
Em empresas menores, alguns CIOs estão implementando SOA sem grande ênfase em padrões. O John F. Kennedy Center for the Performing Arts emprega muitos produtos de software comerciais, e alguns deles estão rumando para SOA, diz o CIO Alan Levine.
A Lawson, fornecedora de enterprise resource planning para o Kennedy Center, está migrando para uma arquitetura de serviços. A Impressario, subsidiária do Metropolitan Opera, também está mudando para SOA a plataforma de customer relationship management –Tessitura — utilizada no centro.
Levine está implementando SOA sem se preocupar excessivamente com padrões. “Enfocamos a criação da ‘cola’ que permite juntar as funcionalidades SOA dos diferentes sistemas comerciais.”
Para isso, o centro está desenvolvendo soluções middle-tier internamente. “Nosso foco, mais do que escolher um padrão, é saber o que fazer para que o back-end interopere”, diz Levine. Obviamente, as estratégias para o middleware dependem do tamanho e dos sistemas da organização. No geral, fique de olho na recompensa: uma organização de TI ágil. Como diz Zhang, da GM, o objetivo final de usar SOA é “estabelecer um ambiente de sistemas e serviços de informação flexível, capaz de re-alinhar rapidamente” à medida que as necessidades do negócio mudam.
