UNIVERSIDADE FEDERAL DE VIOSA CENTRO DE CINCIAS EXATAS E TECNOLCIAS DEPARTAMENTO DE INFORMTICA

ARQUITETURA ORIENTADA A SERVIO: MAIOR INTERAO ENTRE ESTRATGIA DE NEGCIO E A TECNOLOGIA DA INFORMAO.

GEOVANE FRANCISCO CAETANO

VIOSA MINAS GERAIS BRASIL 2008

GEOVANE FRANCISCO CAETANO

ARQUITETURA ORIENTADA A SERVIO: MAIOR INTERAO ENTRE ESTRATGIA DE NEGCIO E A TECNOLOGIA DA INFORMAO.

Monografia

apresentada

ao

Departamento de Informtica, como parte das exigncias do curso de Ps-Graduao Lato Sensu em Cincia da Computao, da Universidade Federal de Viosa.

ORIENTADOR Mauro Nacif Rocha

VIOSA MINAS GERAIS BRASIL 2008 I

GEOVANE FRANCISCO CAETANO

ARQUITETURA ORIENTADA A SERVIO: MAIOR INTERAO ENTRE ESTRATGIA DE NEGCIO E A TECNOLOGIA DA INFORMAO.

APROVADA EM____/____/______

PROF. JOS LUIZ BRAGA PROF. JUGURTA LISBOA FILHO

PROF. MAURO NACIF ROCHA INF/UFV (ORIENTADOR)

VIOSA MINAS GERAIS BRASIL 2008 II

AGRADECIMENTOS

Agradeo primeiramente a Deus pela paz, sade e pela fora concedida nesta caminhada e conquista. E claro que no posso prosseguir sem agradecer minha famlia e amigos que sempre me apoiaram e estenderam suas mos nos momentos necessrios. Sou especialmente grato a minha noiva Nair Alves pela compreenso, carinho e energia positiva que pacientemente aceitou minha ausncia nos ltimos meses enquanto estava ocupado trabalhando neste projeto. Tambm no posso esquecer de agradecer meus colegas de trabalho que diretamente ou indiretamente esto contribuindo para que este projeto seja concludo com xito. E os meus sinceros agradecimentos ao orientador, Mauro Nacif, pelo apoio, dedicao e interesse neste estudo e desenvolvimento deste tema. E a todos os professores do departamento de informtica da UFV, que no mediram esforos para contribuir na minha especializao e formao profissional.

III

SUMRIO LISTA DE FIGURAS....................................................................................................... VI LISTA DE TABELAS..................................................................................................... VII LISTAS DE ACRNIMOS E SIGLAS......................................................................... VIII RESUMO.......................................................................................................................... X 1. INTRODUO............................................................................................................. 1 2. Viso Geral da SOA..................................................................................................... 3 2.1. Definio............................................................................................................... 3 2.2. Conceito de SOA................................................................................................... 4 2.2.1.Viso o que servio...................................................................................... 4 2.2.2.Interoperabilidade........................................................................................... 5 2.2.3.Acoplamento fraco.......................................................................................... 6 2.3. XML........................................................................................................................ 7 2.4. Web services........................................................................................................... 9 2.5. Os passos para adoo da SOA..............................................................................10 2.6. SOA no Brasil, como e quando implantar.............................................................14 2.7. Governana em SOA............................................................................................. 15 3. Tecnologia Base da SOA.............................................................................................. 17 3.1. Padres.................................................................................................................. 17 3.1.1.WS-*.............................................................................................................. 17 3.1.1.1.WSDL....................................................................................................18 3.1.1.2.SOAP.................................................................................................... 24 3.1.1.3.UDDI.................................................................................................... 27 4. Responsabilidade de um ESB (Barramento de servio corporativo) em SOA.............30 4.1. Principais diferenas entre ESBs........................................................................... 33 4.1.1.ESB com conexes ponto-a-ponto e mediao.............................................. 33 4.1.2.ESB com interceptores...................................................................................35 4.1.3.ESB orientado a protocolo e orientado a API................................................ 37 5. Segurana em um ambiente fracamente acoplado........................................................ 39 5.1. Autenticao e autorizao.................................................................................... 39 5.2. Privacidade e integridade....................................................................................... 40 IV

5.3. Inundao...............................................................................................................41 5.4. Auditoria.................................................................................................................42 6. Estudo de caso baseado em grandes empresas que implementaram SOA.................... 43 6.1. Comcast..................................................................................................................43 6.2. Leapfrog Enterprise............................................................................................... 45 6.3. United Arline......................................................................................................... 46 6.4. Thomson Financial................................................................................................ 48 6.5. Jabil Circuit........................................................................................................... 49 7. Concluso..................................................................................................................... 52 Bibliografia......................................................................................................................... 53

LISTA DE FIGURAS Figura 1.1 - Conexes para integrao em um sistema no SOA..........................................1 Figura 2.1 - Processo de Faturamento usando vrios servios.............................................. 4 Figura 2.2 - Interoperabilidade usando interface em EAI..................................................... 6 Figura 2.3 - Exemplo de um arquivo XML...........................................................................8 Figura 2.4 - Comunicao web service entre um consumidor e fornecedor usando o protocolo SOAP...................................................................................................................10 Figura 2.5 - Dependncias entre a infra-estrutura e mltiplos projetos.............................. 13 Figura 3.1 - Estrutura geral de arquivo WSDL 1.1 e 2.0.....................................................19 Figura 3.2 - Estrutura de uma mensagem em SOAP........................................................... 26 Figura 3.3 - Modelo UBR. Broker, fornecedor e consumidor............................................. 28 Figura 4.1 Aplicao chamando servios sem o uso do ESB........................................... 30 Figura 4.2 Aplicao cliente chamando servios pelo ESB............................................. 31 Figura 4.3 Componentes de um ESB................................................................................32 Figura 4.4 Exemplo ESB fornecendo conexes ponto-a-ponto........................................34 Figura 4.5 Exemplo de conexes mediadas por ESB....................................................... 35 Figura 4.6 ESB utilizando um nico interceptador para vrios fornecedores como balanceador de cargas.......................................................................................................... 36 Figura 4.7 ESB utilizando interceptador para cada fornecedor........................................ 36 Figura 4.8 - ESB com conexes orientadas a protocolo...................................................... 37 Figura 4.9 - ESB com conexes orientadas a APIs............................................................. 37 Figura 4.10 Camadas do cdigo de negcio at o cdigo de protocolo............................38 Figura 5.1 Modelo de segurana em uma aplicao tradicional com firewall e web service sem segurana.......................................................................................................... 40 Figura 5.2 Interceptao, roteamento e modificao das mensagens SOAP por um Hacker ou pessoa no autorizada......................................................................................... 41 Figura 5.3 Inundao com requisio ao servio em uma SOA no segura.....................42

VI

LISTA DE TABELAS Tabela 01 Assuntos tpico a ser considerado na implementao do acoplamento fraco em um sistema............................................................................................................................. 7 Tabela 02 Outros itens que fazem parte de uma governana SOA...................................16 Tabela 03 - Descrio de um arquivo WSDL na verso de WSDL 1.1...............................20 Tabela 04 - Descrio de um arquivo WSDL na verso 2.0 com SOAP 1.2...................... 22 Tabela 05 - Requisio SOAP usando protocolo http......................................................... 26 Tabela 06 - Resposta SOAP usando protocolo http.............................................................27

VII

LISTAS DE ACRNIMOS E SIGLAS

API - Application Programming Interface. AS1 - AS1 Applicability Statement 1. AS2 - AS1 Applicability Statement 2. BUS - Biderectional Universal Switch. BT - Business Technology. CIO - Chief Information Officer. DOS - Denial of Service. EAI - Enterprise Application Integration. EDA - Event Driven Architecture. ERP - Enterprise Resource Planning. ESB - Enterprise Service BUS. FTP - File Transfer Protocol. IDC - International Data Corporation. HTTP - Hypertext Transfer Protocol. IDE - Integrated Development Environment. JMS - Java Message Service MEP - Message Exchange Patterns OASIS -Organization for the Advancement of Structured Information Standards. REST - Representational State Transfer. RH - Recursos Humanos. RPC - Remote Procedure Calls. SAP - Systemanalyse and Programmentwicklung. SMTP - Simple Mail Transfer Protocol. SSL - Secure Socket Layer. SOA - Service Oriented Arquitecture. SOAP - Simple Object Acess Protocol TCP - Transfer Control Protoco. TI - Tecnologia da Informao. UBR - UDDI Business Registry. UDDI-Universal Description, Discovery, and Integration. VIII

URL - Uniform Resource Location. XML - EXtensible Markup Language. XP - Extreme Progamming. VANs - Value Added Networks. WSDL - Web Service Description Language. W3C - World Wide Web Consortium. WS-I - Web Services Interoperability Organization. VPN - Virtual Private Network.

IX

Resumo Um dos principais objetivos do departamento de TI alcanar a eficincia em uma corporao, oferecendo maior flexibilidade para adaptar s necessidades de negcios que sempre esto em mudanas. Mas esta tarefa no simples e tem exigido grandes esforos dos lideres e gestores de TI e mesmo assim, na maioria das vezes fica impossvel, em tempo hbil acompanhar a regras impostas pelos analistas de negcios ou at mesmo uma demanda de mercado. Para aliar a TI a estratgia de negcio, permitir uma tomada de deciso precisa e muito mais rpida, ser apresentado neste estudo uma nova metodologia, chamada de SOA, onde a arquitetura dos sistemas de informao baseada em servio orientado, ou seja, todo sistema ser divido em blocos de funcionalidades que podero ser ordenados ou reordenados sem nenhuma restrio e com mnimo de esforo e custo.

Introduo Em busca de maior flexibilidade, o mundo dos negcios em que vivemos cada

vez mais desafiador, e a busca constante por inovao, tornou uma estratgia no s para empresa, mas para paises [TAURION, 2007]. Fundamentado nessa constante busca por inovao, ultimamente o departamento de TI nas empresas esto convivendo com vrias geraes de tecnologia diferentes. E pode-se afirmar que o resultado de uma grande parcela dos esforos, energia e investimento gasto nas atividades de manuteno e integrao das aplicaes. Para criar estas integraes, geralmente as ligaes entre as aplicaes so feitas ponto a ponto e a frmula para integrao n(n-1) de conexes, onde n o nmero de aplicaes existentes, demonstrado na figura 1.1. Sendo assim, uma empresa que tem dez aplicaes ativas, se desejarem fazer uma integrao total sero necessrias 90 conexes e cada uma delas ter que entender as caractersticas das outras aplicaes e conseqentemente quando esta empresa precisar mudar seus processos ou as regras de negcios, a TI responder de forma muito lenta, porque todas as conexes devem ser avaliadas ou modificadas [TAURION, 2007].

Figura 1.1 Conexes para integrao em um sistema no SOA. Fonte Caetano (2008). Paralelamente a esse caminho complexo, sem flexibilidade e rduo, caminha e ganha fora uma metodologia chamada SOA acrnimo de Service Oriented Architecture (Arquitetura orientada a servio). 1

A metodologia SOA prope mudana no contexto de integrao, o princpio dissolver as aplicaes em vrios servios, conhecido pelo termo em ingls Building Blocks, o que possibilita o agrupamento e/ou reagrupamento, quantas vezes for necessrio para construo de novas aplicaes ou readequaes aos novos processos e mudanas nas regras de negcios. Seguindo este princpio pode-se comparar com um brinquedo lego para exemplificar, onde com as mesmas peas podemos montar diversos objetos diferentes. Na metodologia SOA as peas do brinquedo lego seriam os servios e os objetos seriam as aplicaes. Seguindo este conceito, mudar as regras ou processos de negcios, seria apenas uma nova remontagem de blocos de servios. No existindo custo e tempo para desenvolvimento de novas aplicaes [CESAR, 2006]. Seguindo o caminho do SOA a TI daria uma grande salto na evoluo, passando a ser uma BT (Business Techonology) assumindo a parte essencial e estratgia dos negcios da empresa, segundo Taurion (2007). Um dos principais benefcios do SOA a garantia de maior longevidade que ela proporciona aos sistemas e este projeto s valer a pena se houver alinhamento entre tecnologia e os objetivos de negcios da organizao [NEXTGENERATION,2007].

2 Viso Geral da SOA Neste tpico ser abordado um parecer tcnico dos recursos envolvidos em uma implementao SOA, tais como: Definio; Conceito de servios, interoperabilidade e acoplamento fraco; Passos para adoo; SOA no Brasil e governana em SOA. 2.1 Definio Pesquisadores afirmam que definir SOA uma tarefa muito complicada, j que se trata de um conceito abstrato, que pode ser utilizado de diversas formas e se transforma em ferramenta especfica de acordo com o negcio e com a empresa que decide adot-la [NEXTGENERATION, 2007]. Mas como ponto importante que SOA tem como base e componente fundamental o conceito de servio, outra caracterstica muito interessante do SOA a possibilidade do reuso de software, que reduz custo e esforo no desenvolvimento e permite um atendimento aos novos requisitos com maior agilidade. Em um ambiente SOA, os recursos de uma rede so disponibilizados como servios independentes e podem ser alocados ou acessados sem conhecimento da plataforma e linguagem que foram implementados. SOA tambm pode ser conceituada como um estilo de arquitetura de sistemas de informao que possibilita a criao de aplicaes que so construdas ao se combinarem os servios fracamente acoplados e que funcionam em conjunto. Estes servios operam entre si com base em uma definio formal (ou contrato, por exemplo, WSDL) que independente da plataforma e da linguagem de programao. A definio da interface esconde a implementao do servio especifico da linguagem. Os sistemas compatveis com SOA podem, portanto ser independentes das tecnologias de desenvolvimento e plataformas (como Java, .Net, etc)-(Josuttis, 2007) SOA no uma arquitetura concreta, uma ferramenta ou framework com possibilidade de compra e venda, mas sim, um paradigma, conceito, perspectiva, filosofia ou representao e at mesmo uma estratgia metodolgica da TI que decide adot-la e personaliz-la de acordo com cenrios da empresa. Como ponto positivo e para maior estimulo, uma aplicao SOA, normalmente baseada em padres de web services, o que

permite maior interoperabilidade com independncia de padres, conhecidos como especificao dos web services (SOAP ou REST), ambos com amplo apoio da indstria nos dias atuais. Outro ponto positivo que SOA no necessariamente prende nenhuma empresa de software proprietrio. No entanto ela pode ser implementada com uso de qualquer tecnologia baseada em servio. 2.2 Conceito de SOA Segundo Josuttis (2007) em seu livro SOA na prtica os principais conceitos tcnicos que permitem lidar com as caractersticas de sistemas SOA so: Servios, Interoperabilidade e acoplamento fraco. 2.2.1 Viso o que servio. Servio so pores conhecidas como componentes de software, construdos de uma forma que possa facilmente ser utilizada em outro componente para construir outro software ou atender um determinado requisito conforme a figura 2.1, onde o exemplo aborda um sistema de faturamento de uma indstria especfica.

Figura 2.1 Processo de Faturamento usando vrios servios. Fonte [ERL, 2005] 4

A idia de servio definir partes dos cdigos de software em pores significativas o suficiente para serem compartilhadas e utilizadas em diversas reas da empresa. Vejamos o exemplo da figura 2.1 acima, onde o servio busca status produtivo do pedido, que no determinado momento esteja sendo usado pelo servio de faturamento e ao mesmo tempo ele poder ser alocado em outros departamentos para atender outros requisitos como: controle de produo, estimativa de entrega pelo departamento de logstica e at mesmo o sistema do portal disponvel na web. 2.2.2 Interoperabilidade. Interoperabilidade a capacidade de resolver o problema de integrao facilmente entre sistemas heterogneos. A idia de interoperabilidade surgiu com EAI, um conceito de integrao de aplicao corporativa. Diferentemente de SOA em uma aplicao baseada em EAI a interoperabilidade feita criando interfaces, ou seja, softwares que tinham o propsito de traduzir e auxiliar na comunicao entre sistemas ou plataformas diferentes, conforme figura 2.2.

Figura 2.2 Interoperabilidade usando interface em EAI. Fonte [PULIER e TAYLOR,2007]. No entanto, para SOA o conceito de interoperabilidade o comeo para uma implementao SOA, tambm a base a partir da qual comeamos a implementar as funcionalidades de negcios(servios) e espalhada pelos diversos sistemas distribudos existentes[JONES, 2006]. 2.2.3 Acoplamento fraco. Como o SOA aplicado em sistemas distribudos, a escalabilidade e a tolerncia s falhas so as chaves para o sucesso e manutenibilidade dos sistemas envolvidos e tambm possibilita minimizar os impactos das modificaes e das falhas dentro dos sistemas. O objetivo importante minimizar o impacto das modificaes e das falhas dentro do cenrio do sistema como um todo. -(Josuttis, 2007). Para resolver este problema imposto neste cenrio, existe dentro do SOA um conceito chamado de acoplamento fraco, onde o objetivo minimizar as dependncias 6

tipicamente empregadas para lidar com os requisitos de escalabilidade, flexibilidade e tolerncia s falhas. Quando existem poucas dependncias, as modificaes ou as falhas em um sistema tero menos conseqncia em outros sistemas. -(Josuttis, 2007). O acoplamento fraco no uma ferramenta e nem uma lista de verificaes. Portanto para projetar uma SOA necessrio definir quais tipos e qual quantidade de acoplamento fraco sero introduzidos. No entanto, ser apresentado uma tabela a seguir com alguns assuntos tpicos para considerar na implementao do acoplamento fraco no sistema. Tabela 01 Assuntos tpicos a ser considerado na implementao do acoplamento fraco em um sistema. Tipo Conexes fsicas Estilo de comunicao Modelo de dados Sistema de tipagem Padro de integrao Controle de lgica de processos Ligao Plataforma Transaes Deployment Controle de verses 2.3 XML A inspirao para o projeto de XML veio de duas fontes distintas: SGML (Standard Generalized Markup Language) e HTML(Hypertext Markup Language). A verso 1.0 de XML foi disponibilizada pelo W3C(Word Wide Web Consotium) em 10 de fevereiro de 1998, porm o projeto da linguagem foi iniciado em meados de 1996, com o 7 Acoplamento forte Ponto a ponto Sncrona Tipos comuns complexos Forte Navegar atravs de rvores de objetos complexos Controle central Esttica Dependncias de plataformas fortes 2PC(Commit em duas fases) Simultneo Atualizaes explcitas Acoplamento fraco Atravs de mediador Assncrona Apenas tipos comuns simples Fraco Mensagens independentes Controle distribudo Dinmica Independncia de plataforma. Compensao Em tempos diferentes Atualizaes implcitas

Consideraes proposta por Josuttis (2007).

objetivo de produzir um mecanismo simples e extensvel para representao textual de informao estruturada e semi-estruturada. XML o padro que comeou a permitir o to desejado ideal de interoperabilidade aberta. um dos marcos tecnolgico que muitas pessoas discutem e poucas compreendem completamente [Pulier e Taylor,2007]. A XML leva a uma interpretao pessoal de acordo com o local aplicado ou na explorao do tpico, sendo neste contexto apresentado aqui, o mais apropriado afirmar que XML um conjunto de padres que permitem os desenvolvedores alcanarem diversas tarefas [Pulier e Taylor, 2007]. Para ser mais claro, XML apenas um conjunto de padres que especificam como estruturar um documento para ser entendido entre dois computadores ou sistemas, seu uso tem se tornado muito comum nos dias atuais, seja para definir um website, compartilhar dados entre dois bancos, enviar resposta de uma requisio, entre outros. Em geral, o XML o novo formato de dados universal. Um formato de dados uma conveno para se armazenar ou transmitir dados. (Pulier e Taylor, 2007). A figura 2.3 um exemplo de uma transmisso ou armazenamento de um pedido usando XML.

Figura 2.3 - Exemplo de um arquivo XML. Fonte [Caetano, 2008]

2.4 Web services Inicialmente, a internet era constituda de pginas com dados ou informao de forma esttica, e consultada somente por pessoas atravs de programas chamado de navegador web, tambm conhecido como browser. Com a evoluo da internet e por necessidade dos usurios as pginas comearam a ter contedo dinmico, proveniente de banco de dados e outras fontes e tambm ficaram interativas, com possibilidade do usurio inserir, alterar ou at excluir informaes contidas nas pginas [ABINADER e LINS, 2006]. O navegador web tornou-se o cliente universal da internet, para ser usado por seres humanos. Este fato provocou o surgimento de vrias solues, no lado servidor, para a construo de aplicaes que sejam capazes de extrair dados de diversas fontes e disponibilizar para os usurios atravs do navegador web. Mas s as construes dessas aplicaes no permitiriam uma interoperabilidade e escalabilidade entre sistemas. Para atender essa necessidade, surgiu os web services. Um web service um software, que utilizam um conjunto de padres abertos para interoperabilidade, esses padres permitem a interoperao global de computadores, independente de plataforma de hardware, sistema operacional, infra-estrutura de rede ou linguagem de programao. Baseados em XML e em tecnologia abertas como WSDL, UDDI e SOAP, web services apresentam-se como uma das possibilidades para a implementao do compartilhamento de recursos e a integrao entre sistemas corporativos empregando a internet como meio de comunicao. Suas trs principais vantagens esto embasadas no fato de funcionarem sobre padres estabelecidos na internet (XML, HTTP, TCP/IP). ( Abinader e Lins, 2006). Comparando web service com a computao distribuda tradicional de troca de mensagem atravs de interfaces proprietria, os web services empregam uma interface que aceita universalmente, o SOAP, um tipo especifico de XML mostrado na figura 2.4. O computador solicitante envia uma mensagem SOAP para o computador solicitado utilizando um protocolo de transporte de mensagem, geralmente o protocolo HTTP. Tendo em vista que computador solicitante e o computador solicitado entendem SOAP como uma 9

linguagem comum. O computador solicitado consegue entender e processar a requisio e responde com uma mensagem SOAP. Quando um software est pronto para interoperar utilizando web services, diz-se que est exposto como web service.

Figura 2.4 Comunicao web service entre um consumidor e fornecedor usando o protocolo SOAP. Fonte [PULIER e TAYLOR,2007]. 2.5 Os passos para adoo da SOA. Ser apresentado a seguir uma breve viso de dois especialistas em SOA. Como adotar esta nova metodologia com sucesso e no cometer erros na implementao. O especialista em SOA Lheureux1 (2007), apresentou na 5 conferencia anual de integrao empresarial, os passos essenciais para uma implementao bem sucedida de SOA. Segundo ele so quatros passos importantes: introduo, disseminao, explorao de resultados e plat [NEXTGENERATION, 2007]. Introduo - preciso definir um projeto-piloto. A implementao segmentada reduz os investimentos, permite mostrar as melhorias para alta direo sem ter que enfrentar o risco de colocar SOA na empresa inteira. Disseminao - Concluda a primeira fase com sucesso, o desafio espalhar esse conceito para as outras reas, aumentando o escopo de atuao e as pessoas envolvidas.

Benoit Lheureux, vice-presidente e analista do Gartner.

10

Explorao de resultado - Qualquer projeto precisa de bons resultados num prazo razovel. Documentando os benefcios resultantes da implementao, a adoo facilitada e cultura adotada pela empresa. Plat - Momento em que foi atingido o estado da arte sobre o tema, onde o conceito pode ser conferido em sua plenitude e aproveitamento na organizao. Segundo Lheureux (2007) o gestor que pular uma das etapas ter o fracasso garantido. Atualmente a maioria das empresas est entre a introduo e disseminao do conceito. Assim, independente do pas em que empresa se encontra ningum est muito distante em SOA. Em pesquisa realizada pela IDC2, em Londres, durante a conferncia sobre SOA, 60% de um grupo de 140 executivos de TI responderam que ainda esto investigando essa arquitetura. A pesquisa tambm mostrou que SOA ainda no foi completamente assimilado [NEXTGENERATION, 2007]. Segundo Josuttis (2007), em seu livro SOA na prtica, ele apresenta um exemplo tambm baseado em passos, como: entender, definir um projeto piloto em segundo e o terceiro e por fim crescer e tornar-se uma estratgia geral. Entender SOA - O principal objetivo entender, uma empresa no pode comear mudar toda sua arquitetura para SOA porque est moda ou porque seu analista de negcio recomenda ou at mesmo enxergar um beneficio. Segundo ele o benefcio nem sempre fcil de enxergar, aprender sobre as diferenas entre os sistemas grandes e pequenos e entre o controle central e distribudo, isto fundamental. Alm disso, antes de seguir este caminho, totalmente necessrio que o seu gerenciamento aceite que SOA uma estratgia, e no uma soluo pronta, e tambm entender as possveis conseqncias de implementar esta estratgia, e em especial o que significa ter processamento distribudos. No nvel gerencial necessrio ter domnio nos detalhes, controle de verses, e total compreendimento sobre o conceito de acoplamento fraco [JOSUTTIS, 2007]. Um outro ponto importante segundo Josuttis (2007). SOA no a soluo para qualquer tipo de integrao de sistemas, ao contrrio, ela um conceito para lidar com
2

IDC, empresa de consultoria e conferncias nos segmentos de Tecnologia da Informao e Telecomunicaes.

11

processos de negcios distribudos. A replicao de banco de dados e desacoplamento de front-ends3 e back-ends4 so totalmente diferentes, embora elas possam usar os mesmos padres e/ou tecnologias. Projeto piloto Neste ponto o objeto testar SOA, isso significa que a empresa executa um projeto de teste que tem como objetivo colocar em produo alguma funcionalidade que inclui alguns processamentos de negcios atravs de dois ou trs sistemas diferentes. Neste projeto inicial, a empresa concentrar principalmente nas decises tcnicas e arquiteturais. No entanto, isso deve ser guiado pelas necessidades de negcio. Isto significa que a equipe que realiza esse piloto deve ser uma mistura de pessoas de negcio e pessoas de TI [JOSUTTIS, 2007]. No estagio inicial necessrio ter muito cuidado, continua Josuttis (2007), dando algumas orientaes: Use apenas servios bsicos, o que significa iniciar com SOA fundamental; use apenas um ou dois padres MEPs5, recomendado comear com padro requisio/resposta sncrono ou assncrono; defina um conjunto mnimo de tipos de dados fundamentais e construtores de linguagem para agreg-los; escolha uma tecnologia de middleware6 para o seu ESB; decida sobre a quantidade de acoplamento fraco, ser conservador neste ponto e ter cuidado com princpio, isto no ser necessrio; pense sobre a quantidade de segurana e manutenibilidade que quer prover no momento atual e momento futuro e por fim sempre pense grande e comece pequeno. O foco mais importante, alm de executar software, deve estar em prover interfaces excelentes entre o ESB e o negcio. A empresa no tem que decidir aqui sobre os processos. Primeiro necessrio de software funcionando, depois criar, gerar ou implementar, isso em um processo de desenvolvimento de software distribudo. Do ponto de vista de negocio, no se pode comear com um servio composto ou de processos muito complexo. O objetivo desta abordagem fornecer alguma funcionalidade tpica de backend com a nova infra-estrutura de SOA, talvez v substituir algum acesso remoto a banco de dados por um servio. A funcionalidade implementada deve ter algumas relevncias para o negcio. Embora seja provavelmente muito arriscado para ser de misso crtica para

3 4 5 6

Front-ends, a parte do sistema de software que interage diretamente com o usurio [Wikipedia, 2008]. Back-ends, a base de dados e fica por trz de um front-end [Nogueira, 2008]. MEPs Padro de mensagens requerido em um padro de protocolos de comunicao[Wikipedia, 2008]. Middleware Programa que faz mediao entre outros softwares[Wikipedia, 2008]

12

a empresa, implementar alguma funcionalidade til necessria vai ajudar a abordagem SOA a focar em pragmatismo e usabilidade[JOSUTTIS,2007]. O segundo e o terceiro projetos SOA - O segundo e o terceiro projetos so fases muito importantes na introduo de SOA, nesta fase comea-se pensar sobre todas as coisas importantes que levam aos efeitos sinrgicos e considerar a reusabilidade dos servios. Definir processos para equipes diferentes, encontrar o equilbrio certo entre centralizao e descentralizao e encontrar o ponto certo entre a teoria ou conceitos e a prtica se torna importante. Segundo Josuttis (2007) medida que aumenta os nmeros de projetos, o gerenciamento de multiprojetos deve ser pensado, A Figura 2.5 abaixo demonstra isso em relao infra-estrutura comum dos trs pilotos. Primeiro projeto piloto cresce com a infra-estrutura. O segundo e o terceiro projeto pilotos so baseados nas experincias, decises e implementaes anteriores, mas precisam e adicionar novos recursos que tem impactos na infra-estrutura geral, causando uma alterao na infra-estrutura inicial. Estas mudanas no sero apenas adies de novos recursos. A maioria sero atualizaes baseadas em consolidao e generalizaes. Interfaces, processos e polticas teis evoluem medida que voc as usa e convive com elas. Sempre que um mesmo esforo for repetido pela terceira vez, ser necessrio fazer algo para automatizar estes processos conhecido pela comunidade XP como, Trs Strikes, esta automao leva o desenvolvimento orientado a modelos.

Figura 2.5 Dependncias entre a infra-estrutura e mltiplos projetos. Fonte [JOSUTTIS, 2007]. Otimizar para no fazer as funes repetidamente uma boa abordagem para alcanar a excelncia. No entanto, observe que o modelo de programao comum em 13

grandes projetos na abordagem copiar e colar. Na SOA o contrrio, para se beneficiar das melhorias, ter que refatorar os projetos pilotos que j esto em fase terminados, caso contrrio os desenvolvedores iro copiar os cdigos e APIs antigas e depreciadas [JOSUTTIS, 2007]. O padro trs Strikes no se aplica apenas aos aspectos de infra-estrutura. Baseado na figura 2.5 anterior, a palavra infra-estrutura pode ser substituda por processo, ciclo de vida, polticas, arquitetura entre outras. O importante entender que o aspecto SOA sempre est em evoluo, o que significa ter os recursos sempre flexveis para que sempre que seja necessrio modificar as prticas, os cdigos existentes e manutenibilidade para alcanar consistncia melhor. Crescer e tornar-se uma estratgia geral Para que a empresa tenha a possibilidade de detectar mais rpido as oportunidades e desafios de negcios, ser necessrio gerenciar SOA, gerenciar servios, contratos de servios e o monitoramento de atividades de negcios [JOSUTTIS, 2007]. Para que isso ocorra crucial neste estgio que a maneira usual de estabelecer novas funcionalidades de negcios seja completamente descentralizada e automatizada ao mximo, e para alcanar isso s equipes de servios centrais ter que ter domnio em suas funes, isto normalmente requer muitos recursos, mas o importante no parar o suporte estratgico de SOA neste ponto. Embora com o tamanho aumentado os aspectos de sua estratgia SOA se tornem mais e mais estveis, sempre h novos requisitos com que lidar. Eles podem ser tcnicos (Devemos mudar para o novo padro do protocolo?) ou de negcio (Como estabelecemos uma conexo B2B que usa um protocolo ligeiramente diferente?). crucial aqui que as modificaes da plataforma SOA e os processos sejam orientados a negcio. As infra-estruturas de servios devem servir s equipes de negcios. Josuttis (2007). 2.6 SOA no Brasil, como e quando implantar. A SOA no Brasil ainda est em fase embrionria, sua adoo muito discutida por executivos de TI, que precisam entender que possvel comear um projeto dessa dimenso sem antes instaurar uma poltica de governana [NEXTGENERATION, 2007]. Alguns especialistas aconselham a comear a implantao pelos processos mais crticos do negcio e tambm sugerem que as organizaes comecem a implantar SOA aos 14

poucos, orientam que a adoo de novas arquiteturas pode ser feita em etapas, conforme demandas forem surgindo. Segundo eles o ideal que as empresas apliquem SOA inicialmente em processo crticos que exijam mais agilidade, como os sistemas onde a lgica de negcios possa ser facilmente desagregada da parte de apresentao. Uma vez que as organizaes decidam aderir SOA, elas precisam se certificar de que os projetos nascero baseados na arquitetura e quando forem desenhar a arquitetura do sistema, o responsvel pelo projeto deve ter SOA em mente [NEXTGENERATION,2007]. Desde a concepo do sistema, nova arquitetura deve ser levada em considerao. Alguns dos pesquisadores do SOA no Brasil, segundo a Nextgeneration (2007), afirmam que durante a implementao do projeto SOA, as equipes identificaro servios no muitos utilizados, mas dos quais as empresas tambm no devem descartar. Com SOA, algumas funcionalidades sero abstradas e outras integradas. A arquitetura elimina retrabalho. As empresas devem construir um catalogo de servios e utiliz-los para outras aplicaes. J outros especialistas acreditam que o desafio para a adoo de SOA esto muito mais do lado organizacional e cultural da empresa, do que em seu aspecto tcnico [NEXTGENERATION,2007]. 2.7 Governana em SOA. Esse tipo governana focado no ciclo de vida dos processos, servios, metadados e na composio das aplicaes de uma empresa que utiliza SOA. Governana SOA define as mudanas da governana de TI para assegurar os conceitos e princpios de SOA, ou seja, uma especializao de governana de TI. Pela sua funcionalidade, governana SOA tambm prov um framework para examinar diversos itens necessrios para o gerenciamento dos servios em uma TI, segundo Erl (2005) os principais itens so: Maturidade dos servios; Infra-estrutura para a gerencia dos servios (segurana, monitoramento, performance, versionamento e compartilhamento); Granularidade e reuso dos servios; Educao e treinamento; Regras e responsabilidades; Mudanas organizacionais. As atribuies da governana SOA so: 15

Tabela 02 Outros itens que fazem parte de uma governana SOA, segundo Jones (2006). Registro Desenvolvimento Versionamento Modelagem Proprietrio Publicao Juno Discovery Monitoramento Reutilizao Auditoria Acesso Diagnstico Implementao Identificao Segurana Consumo Tabela traduzida do livro Enterprise SOA Adoption Strategies [JONES, 2006]. Um dos principais pesquisadores sobre SOA Josuttis (2007), afirma que governana em SOA um obrigao e o nvel de detalhes e riqueza est totalmente relacionado ao tamanho do projeto em questo. Governana da arquitetura orientada a servio no uma opo, ela uma obrigao. Quanto maior SOA, mais governana ela precisa e mais complexos papis e mecanismos da governana devem ser. Os arranjos da governana levam muito tempo para serem projetados e instalados, mas sem eles, todo projeto SOA fora da fase piloto esta em risco. Josuttis (2007).

16

3 Tecnologia Base da SOA. Como SOA no uma tecnologia especfica a sua implementao, na maioria das vezes baseada em padres existente, ser apresentado neste tpico as mais comuns e mais utilizadas nas empresas atualmente. 3.1 Padres Os principais benefcios de SOA so claros, como a reutilizao dos ativos existentes, mas o panorama dos padres ainda no so totalmentes claro. Em um estudo recente sobre o assunto, segundo Violino (2008), a Forrester Research contabilizou cerca de 120 padres flutuando ao redor de SOA e Web services. Descobriu tambm que quase impossvel confirmar quais fornecedores suportam quais padres. Mesmo assim, os CIOs tm que seguir em frente com projetos SOA para satisfazer as necessidades do negcio [VIOLINO, 2008]. E tambm afirma que vrios CIOs como, Hong Zhang, diretor e arquiteto chefe de arquiteturas e padres de TI da General Motors, tem obtido um equilbrio entre o dilema dos padres e a utilizao contnua de SOA, conforme citao abaixo. bom que existam vrios padres relacionado a SOA, isso indica que a indstria de software ruma para ampla adoo de SOA, o desafio no haver uma framework arquitetural comum, consistente, para orientar a evoluo, a integridade e a intregrao destes padres. Muitos deles ainda no atingiram a maturidade. Citado por Violino (2008). Conforme vrias abordagens trivial afirmar que a maioria das implementaes de SOA nas empresas utilizando web services [WIKIPEDIA, 2008]. Baseando nisto ser apresentado o padro de web services mais comum e adotado pelas empresas, conhecido por pilha de padres WS-*. 3.1.1 WS-*. Os web services WS-* surgiram no final da dcada de 90, quando fabricantes de midleware perceberam a necessidade de padronizar as implementaes de SOA que estavam surgindo [PEREIRA7,2007]. Isto era o ponto chave para garantir a

Bruno Pereira, desenvolvedor Java snior e lder de equipe da Concrete Solutions.

17

interoperabilidade de aplicaes. Sem a viso de interoperabilidade a metodologia SOA no faria nenhum sentido afirma Pereira (2007). O rpido crescimento dos servios WS-* se distinguiram pela velocidade das especificaes muito superior velocidade das aplicaes prticas destes padres. Tais procedimentos cresceram rapidamente e chegou a um ponto no qual ficou praticamente impossvel acompanhar o ritmo da documentao gerada pelo consrcio de empresa envolvidas, e isto certamente elevou a complexidade das implementaes [PEREIRA,2007]. O grupo responsvel a garantir a interoperabilidade de web services desenvolvida em diferentes plataformas o WS-I, este grupo adotou como referncia para todas as implementaes da pilha de padres WS-* da plataforma Java, um conjunto de definies chamado Basic Profile 1.0. Outra parte importante a respeito adoo do Basic Profile que a Microsoft tambm adotou estas definies para pilha de SOA .NET 8. Partindo deste princpio o uso deste padro garanti uma integrao bem sucedida entre as duas plataformas segundo Pereira (2007). Os web services WS-* tem em sua pilha trs padres importantes que necessariamente devem ser considerados so eles: WSDL , SOAP e UDDI [ABINADER e LINS, 2006]. 3.1.1.1 WSDL O WSDL tem a funo de descrever de modo a preencher lacunas principais como: informar o consumidor o que o servio executa como o consumidor pode invocar o servio e como o consumidor pode diferenciar servios similares, oferecidos por diferentes fornecedores. Com esta descrio, o cliente consumidor interessado em utilizar o web service, pode fazer de forma automtica, sem que seja necessria a interveno ou contato como o autor fornecedor do mesmo [PULIER e TAYLOR, 2008]. Partindo para uma viso mais tcnica o WSDL usado para definir as interfaces dos servios. Ele pode descrever dois aspectos diferentes de um servio: Sua assinatura (nome e parmetros) e seus detalhes de ligao e deploy (protocolo e localizao) [JOSUTTIS, 2007].

.NET, Linguagem de programao da Microsoft.

18

Para um melhor entendimento do WSDL ser apresentado na figura 3.1 a estrutura geral dos arquivos na verso 1.1 e a recm lanada 2.0.

Figura 3.1 Estrutura geral de arquivo WSDL 1.1 e 2.0. Fonte Josuttis (2007). Os arquivos WSDL descrevem os servios de baixo para cima, ou seja, eles comeam com os tipos de dados usados e terminam com o endereo do servio e contm trs camadas de descrio [JOSUTTIS,2007]. A primeira camada chamada na verso 1.1 de tipo de porta descreve a interface de um servio e pode consistir uma ou mais operaes com parmetros de entrada e sada que usam os tipos especificados na primeira seo do arquivo. Na verso 1.1 os parmentros de servios so definidos nas sees <message>, enquanto na verso 2.0 eles so definidos como qualquer outro tipo na seo <types>.

19

A segunda camada define a ligao de um web service, ou seja, o protocolo e o formato para quais operaes de web service so oferecidas. J a terceira e ultima camada define a localizao fsica (endereo, URL) onde web service est disponvel. Para um melhor entendimento sero apresentados na tabela 03 a descrio WSDL nas duas verses. O WSDL proposto define um servio de informao de um pedido, onde o consumidor do servio informa a um atributo numero do tipo inteiro e tem uma sada de atributos em formato string: cliente, endereco e float: valorTotalPedido. Tabela 03 - Descrio de um arquivo WSDL na verso de WSDL 1.1:
<?xml version="1.0" encoding="UTF-8"?> <definitions name="PedidoService" targetNamespece="http://www.cristaltemper.com.br/wsdl" xmlns:tns="http://www.cristaltemper.com.br/wsdl" xmlns:wsd1i="http://www.cristaltemper.com.br/xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap" xmlns="http://schemas.xmlsoap.org/wsdl"> <types> <xsd:shema targetNamespace="http://www.cristaltemper.com.br/xsd" xmlns="http://www.cristaltemper.com.br/xsd"> <xsd:complexType name=getDadosPedido> <<xsd:sequence> <xsd:element name="pedidoID" type="xsd:int"/> </xsd:sequence> </xsd:complexType> <xsd:element name="getPedidoResponse" type="DadosPedido"/> <xsd:complexType name="DadosPedido"> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="endereco" type="xsd:string"/> <xsd:element name="totalValor" type="xsd:float"/> </xsd:sequence>

20

</xsd:complexType> </xsd:shema> </types> <message name="getDadosPedidoInput"> <part name="params" element="xsd1:getDadosPedido"/> </message> <message name="getDadosPedidoOutput"> <part name="params" element="xsd1:getDadosPedidoResponce"/> </message> <portType name="PedidoInterface"> <operation name="getDadosPedido"> <input message="tns:getDadosPedidoInput"/> <output message="tns:getDadosPedidoOutput" /> </operation> </portType> <binding name="PedidoSOAPBinding" type="tns:PedidoInterface"> <soap:binding stype="document" transport="http://shemas.xmlsoap.org/soap/http"/> <operation name="getDadosPedido"> <soap:operation soapAction="http://www.cristaltemper.com.br/getDadosPedido" /> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="PedidoService">

21

<port name="PedidoPort" binding="tns:PedidoSOAPBinding"> <soap:address location="http://www.cristaltemper.com.br/pedido11"/> </port> </service> </definitions>

Baseado no livro SOA na prtica [JOSUTTIS, 2007]. Para uma anlise detalhada no arquivo ser apresentado por funcionalidade das sees, percebe-se que os arquivos WSDL descrevem os servios de baixo para cima e assim ser analisado. A seo <service> define um servio chamado de PedidoService na URL http://www.cristaltemper.com.br/pedido11, a qual fornecida com uma ligao chamada
PedidoSOAPBinding. O prefixo tns: o namespace onde podemos encontrar os detalhes sobre esse identificador. Ele definido no inicio do documento e tem o mesmo nome que namespace target. O PedidoSOAPBinding um identificador definido neste arquivo. A seo <binding> define o protocolo e o formato que so utilizados para fornecer os servios. Neste local temos a definio de PedidoSOAPBinding. No seu inicio j especifica para qual tipo de interface a ligao PedidoInterface, sem se preocupar com detalhes, a ligao SOAP utilizando o protocolo http. A seo <portType> define a interface PedidoInterface. Ela versa de uma operao chamada getDadosPedido e especifica as mensagens que sero enviadas atravs ESB quando essa operao chamada. Este servio e baseado em mensagem de requisio e resposta, com requisio em getDadoPedidoInput e resposta em getDadoPedidoOutput. A seo <message> define mensagens individuais, fazendo uso dos identificadores referenciados da seo <portType> Tanto o mtodo de requisio e resposta usam um tipo de dados definido na seo <types>. A seo <types> define os tipos de dados de entrada e sada.

Tabela 04 - Descrio de um arquivo WSDL na verso 2.0 com SOAP 1.2.

<?xml version="1.0" encoding="UTF-8"?> <description name="PedidoService" targetNamespece="http://www.cristaltemper.com.br/wsdl" xmlns:tns="http://www.cristaltemper.com.br/wsdl" xmlns:wsd1="http://www.cristaltemper.com.br/xsd"

22

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsoap="http://www.w3.org/2006/01/wsdl/soap" xmlns:wsdlx="http://www.w3.org/2006/01/wsdl-extensions" xmlns="http://www.w3.org/2006/01/wsdl"> <types> <xsd:shema targetNamespace="http://www.cristaltemper.com.br/xsd" xmlns="http://www.cristaltemper.com.br/xsd"> <xsd:complexType> <<xsd:sequence> <xsd:element name="pedidoID" type="xsd:int"/> </xsd:sequence> </xsd:complexType> <xsd:element name="getPedidoResponse" type="DadosPedido"/> <xsd:complexType name="DadosPedido"> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="endereco" type="xsd:string"/> <xsd:element name="totalValor" type="xsd:float"/> </xsd:sequence> </xsd:complexType> </xsd:shema> </types> <interface name= "PedidoInterface"> <operation name="getDadoPedido" pattern="http://www.w3.org/2006/01/wsdl/in-out" style = "http://www.w3.org/2006/01/wsdl/style/iri" wsdlx:safe = "true"> <input messageLabel="In" element="xsd1:getDadosPedido"/> <output messageLabel="Out" element="xsd1:getDadosPedidoResponse"/> </operation> </interface> <binding name="PedidoSOAPBinding"

23

interface="tns:PedidoInterface" type="http://www.w3.org/2006/01/wsdl/soap" wsoap:protocol="http://www.w3.org/2003/05/soap/binding/HTTP"> <operation ref="tns:getDadosPedido" wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/> </binding> <service name="PedidoService" interface="tns:PedidoInterface"> <endpoint name="PedidoEndpoint" binding ="tns:PedidoSOAPBinding" address="http://www.cristaltemper.com.br/pedido20"/> </service> </escription>

Baseado no livro SOA na prtica [JOSUTTIS, 2007]. Como demonstrado no arquivo anterior existe algumas diferenas entre elas, como: A tag raiz chamada de <description> diferentemente da verso 1.1 a qual chamava de <definitions>; A seo <service> usa endpoint e no <port>; Dentro da seo <binding> definem o protocolo especifico; A seo <portType> substituda por <interface>. Ela usa padres de troca de mensagens mais especficos, que definem a ordem de baixo para cima; Usa namespaces diferentes para identificar WSDL 2.0 e SOAP 1.2; Elimina a seo <message> e as operaes passam a referenciar diretamente aos <types> (tipos de dados). 3.1.1.2 SOAP SOAP um protocolo para troca de informaes estruturadas em uma plataforma descentralizada e distribuda, este protocolo e baseado em XML e possibilita a comunicao efetiva entre sistemas distribudos estabelecidos sobre conjuntos de software e hardware heterogneos. 24

SOAP um protocolo projetado para invocar aplicaes remotas atravs de RPC ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programao. SOAP , portanto um padro normalmente aceito, para utilizar-se com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicao entre diferentes sistemas, atravs da utilizao de uma linguagem (XML) e mecanismo de transporte (HTTP) padres Cunha (2002). Como a tecnologia deste protocolo XML, ento sua especificao define um framework que permite construir mensagem que pode trafegar em diversos protocolos como: http, ftp, smtp, tcp entre outros que foram especificados de forma a ser independente de qualquer modelo de programao ou outra implementao [WIKIPEDIA, 2008]. Uma das caractersticas mais importantes do SOAP a separao do formato de dado a ser transmitido, do protocolo de nvel inferior que ir transportar o dado, produzindo independncia de plataforma e linguagem, pois utilizam XML como metadados e outros protocolos bem definidos, como http, para transportar dados pela internet. Uma mensagem SOAP consiste basicamente em trs elementos, envelope, header (cabealho) e body (corpo), conforme figura 2.7, Envelope: Deve existir em todas as mensagens. o elemento raiz do documento XML. O Envelope pode conter declaraes de namespaces e tambm atributos adicionais como o que define o estilo de codificao. Header: Este elemento opcional. Ele leva informaes adicionais, para ajudar a infra-estrutura a lidar com as mensagens como dica de roteamento, segurana e outros. Se o cabealho header for definido ele deve ser o primeiro elemento do Envelope. Body: Este elemento obrigatrio e contm o payload, ou a informao a ser transportada para o seu destino final. O elemento body pode conter um outro elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos ns ao processarem a mensagem.

25

Figura 3.2 - Estrutura de uma mensagem em SOAP. Fonte Josuttis (2007). O Processo de uma chamada RPC, antes de serem enviadas pela rede, as chamadas so encapsuladas ou serializadas segundo o padro SOAP. O destinatrio servidor, ao receber a mensagem faz o processo contrrio, desencapsulando-a e extraindo as chamadas de mtodo. E na resposta o servidor executa o encapsulamento e encaminha ao cliente e o mesmo faz o desencapsulamento, veja os exemplos na tabela 05 e 06 a seguir de um arquivo SOAP. Tabela 05 - requisio SOAP usando protocolo http. POST /pedido11 HTTP/1.1 Host: www.cristaltemper.com.br Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: http://www.cristaltemper.com.br/getDadosPedido <?xml version=`1.0`?> <soap:Envelope xmlns:soap=schemas.xmlsoap.org/soap/envelope/> <soap:Header> ... </soap:Header> <soap:Body> 26

<getDadosPedido xmlns= http://www.cristaltemper.com.br/xsd> <pedidoID>454512</pedidoID> </getDadosPedido> </soap:Body> <soap:Envelope> Tabela 06 - resposta SOAP usando protocolo http. HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <?xml version=`1.0`?> <soap:Envelope xmlns:soap=schemas.xmlsoap.org/soap/envelope/> <soap:Header> ... </soap:Header> <soap:Body> <dadosPedido> <nome>Geovane Caetano</nome> <endereco>Av. do sucesso garantido, 1</endereco> <totalValor>999.999.999,00</totalValor> <dadosPedido> </soap:Body> <soap:Envelope> 3.1.1.3 UDDI Como visto at aqui, em um web services baseado em WS-* o padro SOAP responsvel pelo transporte das mensagens e o padro WSDL responsvel pela descrio dos servios, ambos so mantidos pela W3C e o padro UDDI uma especificao tcnica que tem como objetivo descrever, descobrir e integrar web services e mantido por um grupo de empresas do mundo dos negcios. Segundo a OASIS o UDDI um elemento central do grupo de padres que compe a pilha de componentes dos servios web [RECKZIEGEL,2006]. 27

Foi inicialmente parte de um termo ainda mais amplo UBR [JOSUTTIS, 2007]. A idia original era introduzir todos os trs papis de um mercado em funcionamento: Fornecedores que oferecem servio a um consumidor que precisa de um servio e brokers que juntam os dois divulgando e localizando os servios, como na figura 2.8.

Figura 3.3 - Modelo UBR. Broker, fornecedor e consumidor. Fonte Josuttis (2007). A inteno por trs de UBR era que isso seria o broker central para um mercado mundial de web services, como se fosse um catlogo telefnico que tem pginas brancas, amarelas e verdes para que os fornecedores pudessem divulgar seus servios e os consumidores localizarem quaisquer servios desejados, onde: As pginas brancas: contm informaes sobre nomes, endereos, nmeros de telefone, alm de outras informaes sobre os fornecedores do servio. As pginas amarelas: contm listagens comerciais baseadas nos tipos desses negcios, de maneira organizada por categoria especfica ou regies demogrficas. As pginas verdes: so usadas para indicar os servios oferecidos por cada negcio, incluindo todas as informaes tcnicas envolvidas na interao com o servio. Resumindo, explica como fazer a comunicao com eles. Porm essa idia inicial no funcionou e foi descartada em 12 de janeiro de 2006, segundo Josuttis (2007) a IBM, Microsoft e SAP informou que os objetivos do projeto UBR foram alcanados e seriam descontinuados na data acima. 28

A falha de UBR no significa necessariamente que UDDI tambm falhou, mas h duvida sobre quo importante UDDI na prtica. Parte da razo que o gerenciamento de servios requer um portiflio de servios significante para ser til. Mas outra parte apenas dever de casa insuficiente. Josuttis (2007).

29

4 Responsabilidade de um ESB (Barramento de servio corporativo) em SOA. Uma das idias da SOA disponibilizar servios que podero ser utilizados por outros servios existentes na empresa. E o service requester (aplicao cliente) no tm a necessidade de ter nenhum conhecimento da linguagem de programao ou tecnologia utilizada para implementar o servio solicitado[MUNDO JAVA, 2007]. Na figura 4.1 mostra uma aplicao, cliente chamando diretamente servios disponibilizados em uma aplicao Java com uma stored procedure. Se forem necessrios a criao de um novo servio em outra linguagem e precisar ser integrado aplicao, ser necessrio escrever mais cdigo para esta integrao.

Figura 4.1 Aplicao chamando servios sem o uso do ESB. Fonte Mundo Java (2007). Se o service requester no sabe ou no quer se preocupar sobre as variaes como os servios do service provider foi implementado e como deve requisit-lo ou em um determinado momento queremos abstrair cada um dos servios existente no service provider como web service, esta seria a soluo. Mas se fossem necessrio criar web services para cada servio, no seria possvel disponibilizar como servios para que pudessem ser acessado de qualquer outro lugar. Neste cenrio o ESB resolveria com pouco esforo, conforme a figura 4.2. Um service requester (aplicao cliente) pode solicitar servio, implementados de forma diferente, atravs de um intermedirio que consegue se comunicar com cada uma das implementaes dos servios necessrios.

30

Figura 4.2 Aplicao cliente chamando servios pelo ESB. Fonte Mundo Java (2007). Existem diversas funcionalidades, como: roteamento, segurana, gerenciamento de transaes, orquestrao de servios, coreografia de processos, processamento de mensagem, mapeamento de servios, transformaes de protocolos, enriquecimento e transformao de mensagens. Podem ser encontradas em um ESB segundo Galdino9(2007). Mas nem todos ESBs disponveis no mercado implementam todas essas funcionalidades. Dentre elas o mnimo necessrio o roteamento, mapeamento de servios e processamento de mensagens [GALDINO,2007], e segundo Silva10 (2008) um ESB deve prover os recursos como: Invocao: Para executar funes em servios assncronos e sncronos; Roteamento automtico: Para independncia de localizao dos servios; Mediao: Para converter e transformar arquivos (XML, CSV, etc) em dados; Coreografia de processos: Para executar processos complexos e manter a integridade das informaes;

10

Fernado Galdino desenvolvedor de projetos J2EE e SOA no Banco JPMorgan Edgar A. Silva Arquiteto da JBoss e desenvolvedor de middleware de misso crtica em SOA.

31

Orquestrao de servios: O que capacidade de organizar ordens ou colaboraes entre os servios em busca de um processamento descentralizado, porm colaborativo para um resultado consolidado e confivel; Suporte a mensageria: O que capacidade de processar mensagens e proporcionar um ambiente reativo a eventos dentro do barramento nico; Servios adicionais e gerenciamento: Transaes, segurana, logging e auditoria. Suporte a eventos das aplicaes: Como uma transao ou um simples envio de byte de um protocolo, podem significar um evento que dispara vrios servios numa corporao. Um ESB formado pelos seguintes componentes, conforme figura 4.3.

Figura 4.3 Componentes de um ESB. Fonte Richard (2008). O mediator responsvel por funes como roteamento, comunicao, transformao e enriquecimento de mensagens, e manipulao de erros. O service registry responsvel por mapear todos os servios que sero disponibilizados. O choreographer responsvel pelo processo de coreografia dos servios, gerenciamento das transaes e segurana.

32

E rules engine: Pode ser usada em alguns outros componentes para auxiliar no roteamento, transformaes e enriquecimento das mensagens. 4.1 Principais diferenas entre ESBs. As diferenas entre os ESBs podem ser tecnicamente e conceitualmente. Uma soluo pode no envolver nenhuma ferramenta ou software especifico, em alguns momentos apenas definir um protocolo pode ser o suficiente. J outras um ESB pode reunir diversas ferramentas e programas que rodam de forma centralizada ou descentralizada e que so utilizadas pelos projetistas, desenvolvedores e operadores dos servios. Para um melhor entendimento sero apresentados diversos tipos de ESB, que podem ser implementados sistemas especficos. 4.1.1 ESB com conexes ponto-a-ponto e mediao. Nos ESBs de conexes ponto-a-ponto conforme figura 4.4, os consumidores devem conhecer previamente o endereo final do fornecedor de servios. Conhecendo os endereos do fornecedor, o consumidor envia requisio diretamente para ele. Principal problema encontrado neste caso quando o fornecedor estiver inoperante ou inacessvel chamada simplesmente falha.

33

Figura 4.4 Exemplo ESB fornecendo conexes ponto-a-ponto. Fonte Josuttis (2008). J nos ESB com conexo mediadas, o consumidor no precisa conhecer o endereo final do fornecedor, ele apenas identifica o servio por uma tag (etiqueta) ou um nome simblico e os ESBs so responsveis pela localizao do fornecedor do servio, conforme mostrado na figura 4.5. Como em alguns casos a prioridade e poltica dos consumidores no so iguais, estes ESBs podem exercer o papel de um mediador ou broker deixando esta infra-estrutura fracamente acoplada.

34

Figura 4.5 Exemplo de conexes mediadas por ESB. Fonte Josuttis (2008). Um ponto importante desta conexo indireta que ela pode ter vrios fornecedores de um mesmo tipo de servio, caso haja necessidade de balancear carga e tolerncia s falhas. 4.1.2 ESB com interceptores. Uma abordagem deste ESB substituir o ponto fsico final que fornece o servio por um hardware ou software para fazer o balanceamento de cargas. Ele tambm baseado no protocolo ponto-a-ponto, porm suporta chamada de servios indireta, oferecendo os chamados atravs de proxies ou interceptores. Os consumidores que desejarem utilizar estes servios utilizam um ponto final oficial, que delega a tarefa oficial real, quando as mensagens chegam, o balanceador de carga demonstrado na figura 4.6, as envia para diferentes forcenedores de servios, de acordo com critrios pr-estabelecidos.

35

Figura 4.6 ESB utilizando um nico interceptador para vrios fornecedores como balanceador de cargas. Fonte Josuttis (2008). Outra abordagem de ESB baseado em interceptadores ou proxy. Diferentemente da anterior que utiliza apenas uma para vrios fornecedores, este utiliza um interceptador para cada fornecedor, o que o torna bem mais complicado e obriga o consumidor a fazer conexes ponto-a-ponto apenas com o seu inteceptor especfico, conforme figura 4.7. O inteceptor ir rotear cada chamada para o fornecedor apropriado. Um ponto positivo desta tcnica que os servios neste ESB podem ser encapsulados do mundo exterior atravs dos interceptores e internamente pode usar diferentes protocolos.

Figura 4.7 ESB utilizando interceptador para cada fornecedor. Fonte Josuttis (2008). 36

4.1.3 ESB orientado a Protocolo e orientado a API. Existem duas abordagens diferentes, considerando que a responsabilidade de uma ESB comea do ponto vista dos consumidores e fornecedores, segundo Josuttis (2008) as diferenas entre essas abordagens tm um impacto importante sobre os processos de desenvolvimentos. Uma das abordagens o ESB define um protocolo. E os fornecedores e consumidores devem utiliz-lo para fazer as comunicaes, conforme figura 4.8. Este tipo de ESB utilizado em web services que requerem o uso do protocolo SOAP.

Figura 4.8 - ESB com conexes orientadas a protocolo. Fonte Josuttis(2008). Outra abordagem orientada a API, neste tipo o ESB define as APIs de uma plataforma ou linguagem de programa, e os fornecedores e consumidores utilizam essas APIs para implementaes e chamada de servios, conforme figura 4.9.

Figura 4.9 - ESB com conexes orientadas a APIs. Fonte Josuttis(2008). 37

Segundo Josuttis (2008), normalmente a abordagem orientada a protocolo leva a uma terceira camada do modelo das comunicaes distribudas, demonstrada na figura 4.10. Na parte inferior do modelo existe um protocolo bastante estvel, j na parte superior existe um API para chamar e implementar os servios. E entre a parte inferior e superior existe uma camada responsvel por fazer a integrao.

Figura 4.10 Camadas do cdigo de negcio at o cdigo de protocolo. Fonte Josuttis(2008). percebido que os protocolos iro mudar ao longo do tempo. Por esta razo, em algum momento todas as empresas que usam web services, adotam uma camada de mapeamento, a qual parte do ESB [JOSUTTIS, 2008].

38

5 Segurana em um ambiente fracamente acoplado. Mesmo que a comunidade de TI esteja aderindo a SOA por causa da sua promessa de gerenciamento de TI eficiente e avanada, o problema de segurana tem contribudo para um avano mais lento ou at mesmo nenhum avano em algumas empresas. Segundo Pulier e Taylor (2008), segurana sempre foi uma preocupao para os gestores de TI em grandes companhias. Atualmente grandes e robustos sistemas so projetados para proteger os dados e informao contra uso no autorizado, intruso e vrus. Os web services que praticamente base de SOA foram desenvolvidos por consenso da indstria, com o foco em cdigo reutilizvel, simplificar o desenvolvimento e integrao entre sistemas. Embora estes objetivos tenham sido alcanados, os padres abertos que surgiram no tratam completamente a segurana. Especificamente o XML, SOAP, WSDL e UDDI so padres abertos que permitem a transmisso e descrio de dados, chamadas de procedimento entre sistemas e nenhum deles contem qualquer aspecto de segurana implementado, sozinhos so totalmente inseguros [PULIER e TAYLOR, 2008]. Partindo de um princpio que os padres sozinhos so totalmente inseguros, como percebida uma tendncia natural para adoo da SOA nas empresas, se torna necessrio uma medida de segurana. E quando se fala sobre segurana em sistemas distribudos, muitos aspectos devem ser considerados. E as principais categorias como autenticao, autorizao, privacidade, integridade, disponibilidade, contabilizao e auditoria devem ser definidas como os primeiros itens do requisito de segurana. 5.1 Autenticao e autorizao. No modelo de segurana tradicional, a utilizao de um firewall ou uma VPN, evita o acesso de usurios ou sistema no autorizado. Porm, uma SOA demanda que a arquitetura seja mais flexvel e aberta para ser acessada por diversos sistemas para facilitar a reutilizao e o desenvolvimento de novas aplicaes, e se o sistema for exposto em web services mais um ponto inseguro aberto, pois um harcker pode configurar uma mquina com servio semelhante para passar como um fornecedor e realizar chamadas de servios errnea e fraudulenta [PULIER e TAYLOR, 2008], conforme exemplificado na figura 5.1.

39

Figura 5.1 Modelo de segurana em uma aplicao tradicional com firewall e web service sem segurana. Fonte Pulier e Taylor(2008). Para resolver este problema imposto necessrio criar uma autenticao para verificar a identidade de quem est chamando o servio, se a identidade for vlida cabe ao mtodo de autorizao verificar quais tipos de servios e resposta o consumidor tem acesso. 5.2 Privacidade e integridade. A privacidade de dados manter os mesmos confidenciais enquanto estiver em trnsito ou em armazenamento. Na tica de servio isso significa garantir que ningum que no seja o consumidor tenha acesso de visualizao aos dados enquanto estiver trafegando entre o fornecedor e o consumidor. J a integridade a garantia de que os dados no sejam manipulados ou falsificados; um dos fatores mais importante em um TI. Uma infraestrutura que no pode garantir um alto nvel de privacidade e integridade no considerada segura. Em uma SOA com um nvel inadequado de privacidade e integridade, um hacker atravs de uma mquina no autorizada poder interceptar mensagem SOAP em trfego e

40

espionar ou alterar com propsito de fraude ou maliciosamente [PULIER e TAYLOR, 2008], como mostrada na figura 5.2.

Figura 5.2 Interceptao, roteamento e modificao das mensagens SOAP por um Hacker ou pessoa no autorizada. Fonte Pulier e Taylor(2008). Este cenrio mostra claramente a necessidade de criptografar s mensagens SOAP entre os sistemas. 5.3 Inundao. Uma SOA no-segura e aberta para todos, usurios mal intencionados ou maliciosos, mesmo sem autorizao para usar o servio, pode usar alguma tcnica para gerar inmeras requisies forando o servio a ficar inoperante. Este ataque conhecido como DoS(negao de servio) o seu principal objetivo de impedir que usurio legtimo utilize um determinado tipo servio, devido a sobrecarga no sistema em atender as requisies falsas, demonstrada na figura 5.3.

41

Figura 5.3 Inundao com requisio ao servio em uma SOA no segura. Fonte. Pulier e Taylor (2008). Um fator que torna o DoS um risco muito srio a falta de capacidade da SOA no-segura de monitorar ou garantir os nveis e desempenhos dos servios de seus web services pois se um hacker atacar, ela no possui nenhuma maneira inerente de dizer que est sobrecarregada e nem permite aos administradores do sistema identificar e responder a problemas de segurana rapidamente [PULIER e TAYLOR, 2008]. 5.4 Auditoria O objetivo avaliar um conceito de segurana de uma aplicao e melhorar a sua confiabilidade. Auditoria pode ser definida em gravar todas as informaes relevantes segurana para que em uma anlise futura possa detectar falhas e possveis ataques, como parte de uma auditoria em sistemas inclui monitorar e guardas logs e rastrear fluxo de dados que so relevantes. Auditoria em algum momento pode ser um componente funcional, quando um permite manipulao e alterao de dados [PULIER e TAYLOR, 2008]. Um log de auditoria uma ferramenta fundamental de segurana de TI. Para examinar o desempenho de segurana de diagnosticar problemas de segurana, os profissionais de ter acesso a logs acurados de comportamentos dos sistemas. Pulier e Taylor (2008). 42

6 Estudo de caso baseado em grandes empresas que implementaram SOA. No incio da SOA a meta de muitas empresas era simplesmente disponibilizar funcionalidade de aplicaes com servios compartilhados. Mas nos ltimos dois anos o lado do negcio adquiriu melhor percepo do valor estratgico de TI, e a TI aprendeu mais sobre as presses competitivas que o negcio tem de suportar, conseqentemente a SOA proporciona uma melhor e um maior alinhamento entre TI e negcio [GRUMAN, 2007]. O negcio precisa de um conjunto de servios que possa ser reagrupado, que resulta um novo processo de negocio que suporta novos produtos ou servios. E SOA permite publicar estes servios e frameworks coerentes para que eles possam ser governados e compostos em aplicaes. Para uma anlise e estudo de caso ser apresentado algumas possveis maneiras de implementar SOA baseando em empresas que aceitaram a divulgao de seus processos e metodologia pelo pesquisador Gruman(2007) na revista CIO, estas empresas so: Comcast; Leapflog Enterprise ; United Airline; Thoman Financial e Jabil Circuit. 6.1 Comcast Quando uma empresa decide adotar a abordagem SOA, tentador comear a comprar uma ESB (Barramento de servio empresarial), registros e outras ferramentas. Mas o principal valor da SOA esquecido ou colocado de lado como: o alinhamento entre as aplicaes que so criadas e implementadas e os processos de negcio que elas executam, segundo Adler11 citado por Gruman(2007). Comear com a arquitetura pode ajudar a garantir que tem o framework certo para isso agora e medida que as necessidades mudam, com o correr do tempo, segundo Gruman(2007). Quando iniciamos esta empreitada, 18 meses atrs, resistimos tentao de trazer fornecedores. Trouxemos especialista em determinados assuntos e descobrimos do que precisamos em primeiro lugar, todos os fornecedores s queriam nos vender um ESB Adler citado por Gruman (2007). Segundo Gruman (2007) a arquitetura SOA vai alm de estabelecer framework, ela tem o papel importante em identificar onde existe redundncia de processos de negcio
11

Tom Adler gerente snior de arquitetura de aplicaes e governana de TI da Comcast.

43

e aplicaes. Isso torna fundamental para explicar o motivo da adeso dessa arquitetura em termos reais e justificar o investimento em infra-estrutura e ferramentas SOA. O primeiro passo da Comcast foi desenvolver a arquitetura, como modelo de domnio comum, o prximo passo foi desenvolver o framework de governana para criao e a implementao de servio. Somente os servios que passam pelos requisitos da governana so acrescentados ao registro de servios e disponibilizados para reutilizao, isto permite mostrar a existncia de um servio e guia para uma adoo certa das polticas e procedimentos. Aps a implantao Adler, citado por Gruman (2007), percebeu e afirma que a Comcast deveria ter desenvolvido um modelo de servio de dados comum depois de definir a arquitetura. Sem servios de dados padres para acessar informao corporativa e gerenciar interaes entre sistemas, os desenvolvedores acabaram projetando seus servios para executar o trabalho de diferentes maneiras. O que geraram inconsistncias, quebrando a promessa de SOA de possibilitar uma mix fcil de componentes de servios. E o preo disso foi, posteriormente, ter que refazer alguns servios para impor este modelo. O foco arquitetural da iniciativa SOA da Comcast ajudou a aplicar o conceito mais amplamente do que se ele fosse visto apenas como uma questo tecnolgica. A Comcast no partiu da viso de que SOA significa usar web servies e aplicou o conceito SOA a todos os seus esforos, no apenas aos que eram claramente capacitado para web. Um web service simplesmente mais uma maneira de expor um servio, um detalhe de implementao. Adler citado por Gruman (2007). Segundo Gruman (2007) a empresa tem que adaptar a necessidade de negcios que mudam e as oportunidades tecnolgicas. importante rever a arquitetura de referncia constantemente para que ela no se transforme em uma camisa-de-fora ou simplesmente em um documento que todos ignoram; em qualquer um dos casos a empresa perderia os benefcios de SOA. Um perodo sugerido uma vistoria mensalmente, mesmo no fazendo nenhuma alterao neste perodo.

44

6.2 Leapfrog Enterprise. O problema das aplicaes desenvolvidas por grupo desenvolvedores de TI diferentes atingiu a Leapfrog Enterprise no incio de 2007 quando tentou trazer para um sistema comum em um portal web, solicitado por um fabricante de brinquedos educativos a disponibilizar suas diversas aplicaes para fornecedores e clientes de uma maneira consistente, com o objetivo de melhor se beneficiar do comrcio e das transaes na internet. A Leapfrog no viu alternativa e decidiu que precisava de uma nova maneira de desenvolver aplicaes, partiu para uma iniciativa SOA que est comeando dar bons frutos, segundo Ciurana12 citado por Gruman (2007). A Leapfrog tinha muitos objetivos comuns a uma tpica iniciativa SOA, queria uma maior reutilizao de cdigo, desenvolvimento mais veloz e integrao mais fcil. Mas a empresa no queria limitar a iniciativa SOA uma mudana da guarda de ferramentas de desenvolvimento e plataformas de integrao. Ao contrrio a Leapfrog queria dispensar seus desenvolvedores de se submeter idia de melhores prticas de uma plataforma, mas queria que os mesmos focassem na funcionalidade das aplicaes e utilizassem a melhor e mais adequada tecnologia para cada trabalho. Atualmente os desenvolvedores da Leapfrog utiliza uma miscelnea de Java 5 e 6 , C# e web service com diversas bibliotecas de terceiros. Segundo Gruman (2007), Ciurana tambm no quis obrigar os desenvolvedores a usar o mesmo transporte, segundo ele o tipo de transporte no importava. Ele optou pelo open source ESB Mule como backbone de mensagem, apoiando-se nele para lidar como interfaces de transporte, Assim os desenvolvedores poderiam enfocar o mnimo possvel a implementao de servios, o foco principal e funcionalidade. Os desenvolvedores tendem a usar http e alguns empregam SOAP como mecanismo de transporte, baseando-se no que funciona melhor ou que mais cmodo. E com uso do ESB Mule, eles no precisam se preocupar como o que h em uma pilha de SOAP especfica e qual IDE esto utilizando. A empresa pde adotar esta abordagem por causa do foco em integrar aplicaes observa, Ciurana.

12

Eugene Ciurana diretor de infra-estrutura de sistemas da Leapfrog

45

A maior parte da integrao est acontecendo no nivel da aplicao, ou seja, aplicaes se comunicando com outras aplicaes, portanto, aplicaes fazem inputs e outputs. Ciurana citado por Gruman (2007). A simplicidade do ESB Mule e o uso com sucesso dele em projetos anteriores na walmart.com foi ponto positivo para adoo na Leapfrog e tambm pelo motivo da nica tarefa neste ESB que gerenciar mensagem [GRUMAN, 2007]. Segudo Ciurana a leapfrog utiliza dois ESBs, uma para gerenciar fluxo de dados e handoffs de aplicaes em sistemas internos com ERP, ActiveDirectory e data warehousing, e outro para aplicaes de contato com o cliente baseadas na web, como a aplicao de autogerenciamento de contas dos clientes e os games on-line que oferece aos clientes [GRUMAN, 2007]. Isso no s traz um limite natural para gerenciamento de segurana e acesso, como tambm prov capacidade mutua de backup, j que cada ESB pode assumir no lugar do outro, se necessrio. A leapfrog teve que criar um esquema comum de nomeao de servio para que os servios pudessem executar em ambos ESBs, mas isso um pequeno preo a pagar pela liberdade do ESB, diz Ciurana [GRUMAN,2007]. 6.3 United Arline As premissas bsicas de SOA requer que as funes transacionais distintas sejam construdas em blocos, para que possam ser recombinadas quantas vezes for necessria. Entretanto, muitas tarefas de negcio no so to passveis de decomposio, apoiando-se em seqncias especificas de eventos. As companhias areas so um exemplo clssico de conjunto de processos baseado em eventos e, normalmente, tm uma arquitetura baseada em eventos(EDA) para lidar com eventos. EDA muita orientada para fluxos, enquanto SOA tem a ver com caixas preta distintas, mas as duas arquiteturas tm seu lugar Cidambi13 citado por Gruman (2007). As companhias areas possuem sistemas de transao, como reservar passagens e marcar assentos, no apenas sistemas baseados em eventos, como despachar caminhes de combustvel quando um avio aterrissa ou atualizar o painel de aviso de chegadas de vos.
13

Ramnath Cidambi gerente de engenharia de middleware da United Airlines

46

A United investiu h tempos em EDA, usando o WebSphere da IBM como barramento de mensagem por sete anos. Em 2006, deu incio a uma implementao SOA para lidar com os web services modernos usados no web site united.com. Entretanto estes dois ambientes so bastantes diferentes e existiam paralelamente [GRUMAN,2007]. Mas isso est comeando a mudar medida que a empresa agrega servios de transaes s suas operaes internas, por exemplo, informar aos representantes de servios ao cliente atravs de mensagens de texto (usando web services) qual o cronograma do dia, empregar sistemas de RH para ver que est agendado e quem avisou que est doente, e assim por diante, de forma a designar os funcionrios para os diversos portes de cada aeroporto. Isso coloca web services nos mesmos ambientes que os processos baseados em eventos, fazendo com que a companhia area inicie uma implementao SOA para alm do programa united.com. Cidambi citado por Gruman (2007). O desafio da United projetar e implementar servios na companhia sabendo que a mesma possui e necessita das duas arquiteturas e podendo tratar como entidade distintas. Exemplo um vo cancelado (um evento) tambm tem implicaes para os sistemas de transao (remarcar vos de passageiros, atualizarem ferramentas de pesquisas de status de vos na web ou emitir vouchers de crditos). Muitos processos tm um componente de evento e um componente de transao: os representantes de servios ao cliente, obtm a programao do dia em sistema de transao, mas mudanas de status de avies devido o cancelamento, atrasos por condies climticas e coisas do gnero tornam essas programaes confusas muito rapidamente, sendo assim o sistema baseado em eventos rastreia os status dos avies e o sistema de transao de programao atualiza as atribuies da equipe ao consultar este status periodicamente e os monitores de exibio dos horrios de vos empregam o mesmo processo [GRUMAN,2007]. J o sistema de mensagem foi o maior desafio, os ESBs no utilizam padres fora dos padres web services, afirma Cidambi citador por Gruman (2007). O modo de lidar com servios baseados em eventos so obscuros e varia conforme o produto ou ferramenta. Mas Cidambi valoriza o uso de ESBs para SOA e EDA porque eles lidam com mensagem, transformaes de dados e outras tarefas criticas de roteamento de dados.

47

Atualmente a United usa dois ESBs, um para EDA e um para SOA, e tambm a companhia decidiu usar um broker de integrao IBM webSphere como plataforma de mensagem orientada para publicao/assinatura para servios baseado em eventos, programando eventos conforme o necessrios e suportando quaisquer transformaes entre servios, essencialmente atuando como um ESB EDA. Para o transporte foram escolhidas as aplicaes J2EE existentes que so bastante orientadas a mensagem. E todas JMS como padro de mensagem ao invs de web services. Para servios SOA, a United est adotando o ESB BEA Aqualogic, por acreditar que uma plataforma mais nova ser mais orientada ao conceito moderno de SOA e mais adequada ao ambiente servidor WebLogic e tambm para evitar esforo com integrao, j que o Aqualogic roda sobre o WebLogic e a IDE eclipse, explica Cidambi. Outra dificuldade que Cidambi enfrenta a falta de esquemas XML padres para EDA, fazendo com que a transferncia de mensagens entre servios EDA e SOA seja mais complexa e demande um nmero maior de desenvolvedores. 6.4 Thomson Financial Muitas empresa pensam em implementar SOA porque ela promete deixar o desenvolvimento mais rpido. Mas alguns desenvolvedores descobriram que um elemento chave da govenana de servio, na realidade pode tornar mais lento o desenvolvimento, tirando a velocidade prometida, segundo Miteski citado por Gruman (2007). Para ser considerado um de produo empresarial, um servio precisa estar em conformidade com diversas metodologias e polticas, muitas so bastante rgidas: os nomes de elementos XML no podem ser abreviados e tm que ser palavras de dicionrios, por exemplo. Alguns itens, como nomes e senhas de usurios, no podem ser hard-coded. Miteski citado por Gruman(2007). A Thomson Financial tem milhares de servios com alta granularidade e baixa granularidade e tudo que pode haver entre os dois e uma pequenas equipe de arquitetura, sentiu o golpe rapidamente, porque no importa a granularidade, todo servio passa por este processo, s ento ele entrado no registro de servios. Da mesma forma, a conformidade de servios alterados tem que ser avaliada antes que a nova verso seja 48

registrada e disponibilizada para uso em produo, sendo assim o departamento de arquitetura da financial esta constantemente em gargalo [GRUMAN,2007]. Reduzir os requitos de compliance no era uma opo, dada natureza critica das aplicaes envolvidas, como os servios de single sign-on, web services que fornecem informaes sobre o mercado financeiro para analistas e empresas, e servios de analises e graficos financeiros baseados na web e acessados atravs do Microsoft Office. Miteski citado por Gruman (2007). A soluo da Thomson para o problema de workload de conformidade era recorrer automao, utilizando ferramentas de avaliao de polticas da weblayer. Segundo Mitevski, as ferramentas so mais eficientes e no deixam passar violaes. Levou algum tempo para criar as polticas nas quais as ferramentas se baseiam para avaliar a conformidade e vital que os arquitetos examinem as analises das ferramentas para ver se determinados problemas surgem repetidamente, indicando falta de entendimento de polticas-chaves por parte dos desenvolvedores ou ambigidade na arquitetura, observa Mitevski, esta metodologia ajuda a mostrar o que pode ser feito melhor, e quais polticas precisam ser ajustada. Mitevski descobriu que a maioria das violaes acontecem porque os desenvolvedores tomam atalhos. Os arquitetos tambm decidem quando abrir excees aos desenvolvedores por qualquer violao conformidade, algo que acontece raramente. As excees so anotadas no registro para conhecimento de outros usurios. Na Thomson Financial, os resultados da automao de conformidade dos servios so surpreendentes. Segundo Mitevski, antes para colocar um servio em atividade, eram necessrias 20 pessoas em um processo altamente orquestrado em vrios grupos. Agora uma pessoa o suficiente, comemora Mitevski [GRUMAN,2007]. 6.5 Jabil Circuit. Uma empresa focada em servios de manufatura tem que enfrentar uma grande empreitada de integrao do cliente, por exemplo, sistemas de billing, previso e entrada de pedidos e os muitos sistemas utilizados por seus clientes. Mas muito difcil gerenciar toda esta comunicao ponto-a-ponto medida que a base de clientes crescem e evoluem os prprios sistemas. Devido a esta evoluo muitos fabricantes migraram para fornecedores de hubs de transaes, conhecido como VANs. Cada fornecedor e cliente se 49

preocupam apenas com uma conexo com a VAN, e para cada dupla cliente-fornecedor Gilvin14 [GRUMAN,2007]. Mas esta abordagem fracassa quando voc tem processos personalizados junto aos seus clientes que no so suportados por VANs padres. A jabil Circuit, fabricante de produtos eletrnicos personalizados, enfrentou este dilema da maneira mais difcil: manter manualmente todas as interfaces e aplicaes personalizadas. Gilvin citado por Gruman (2007). A Jabil tem mais de cinco mil parceiros comerciais e era possvel lidar com a maioria deles atravs da abordagem de VAN. Mas 50 clientes precisam de mecanismos de comunicao ou processo de negcio especial para os quais a Sterling Commerce VAN havia sido projetada. Com freqncia, havia vrias destas conexes personalizadas para cada cliente, aumentando o esforo e algumas precisam mudar, lembra Gilvin. Baseado nestes altos esforos, ento a Jabil adotou o princpio SOA para substituir a maioria destas conexes personalizadas por conexes baseadas em servios que possibilitam a reutilizao de funes comuns. O primeiro passo foi separar os processos de negcio, gerenciamento do pedido at o pagamento, previso e estoque em consignao. Por exemplo: os processos de comunicao. A Jabil agora tem servios padres para a maioria dos mecanismos de comunicao em uso, como AS1, AS2 e FTP, e servios separados de tratamento de dados, para os formatos XML, flat-file, Excel e SAP iDocs [GRUMAN,2007]. A empresa compe o servio de comunicao, o servio de tratamento de dados e o servio de negcio apropriado para cada um destes clientes, usando tabelas e metadados para automatizar a composio na maioria dos casos. Em alguns casos, os clientes utilizam mais de um mecanismo, talvez de acordo com o departamento em questo, e as tabelas do conta destes mltiplos mecanismos, diz Gilvin. Em alguns casos, requisitos especiais no podem ser satisfeitos atravs da combinao de servios. Portanto, a Jabil ainda tem algumas integraes one-off para manter. Ms, portanto, a empresa pode usar a abordagem SOA para parte da integrao. Os certificados para validao de XML e SSL, por exemplo, no podem ser tratados como servios padres, mas a Jabil pode compor os servios de comunicao e negcio apropriados com um servio de tratamento de dados hard-wired, mantendo os benefcios
14

Lowel Gilvin gerente de comrcio eletrnico da empresa Jabil Circuit.

50

de reutilizao e consistncia de SOA em dois dos trs aspectos da integrao, segundo Gilvin. Segundo Gilvin, no gerenciamento das mensagens o ESB foi substitudo por um registro para gerenciar o repositrio de servios ou um ambiente de desenvolvimento orientado a SOA para desenvolver os servios, a Jabil emprega o Gentran Intregation Sute da Sterling Commerce para as trs finalidades. O pacote foi projetado para interaes do supply-chain, justamente o que a empresa esta tentando gerenciar. Este escopo limitado permite que a Jabil se apie na arquitetura embutida do conjunto de ferramentas, ao contrario de criar a sua prpria e com isso diminuiu o conjunto de processos padres. [GRUMAN,2007].

51

7 Concluso. O contedo deste trabalho deixa transparente que SOA no uma inveno, mas sim um paradigma que junta os conceitos e as prticas existentes. possvel dizer que SOA a juno da capacidade intelectual mais o pragmatismo dos sistemas distribudos e que as pessoas claramente tem o papel de grande importncia, pois so elas que fazem o com que os processos de negcios, os investimentos acertados aliado ousadia e coragem, proporcionarem resultados, retorno sobre investimento em uma corporao ou empresa. Sendo assim, muito antes de falar de tecnologia, SOA deve ser visualizado como um processo de modernizao, onde a empresa deve possuir uma base slida para suportar as mudanas exigidas pelo mercado. Como em todas outras mudanas, SOA tambm no diferente. No se pode apenas visualizar os benefcios para sua implementao e adoo, necessrio um bom estudo de caso, um levantamento de requisito preciso e uma boa anlise e escolha do projeto piloto para dar um inicio ao projeto.

52

Bibliografia ABINADER, J.A.; LINS, R. D. Web Services em Java. Rio de Janeiro: Brasport, 2006. CESAR, R. Cresce o Lego do Software. In: Portal Exame. 2006. (http://info.abril.com.br/aberto/infonews/082006/01082006-12.shl), data da ultima consulta mai. 2008. CUNHA, D. Web Services, SOAP e Aplicaes Web. In: Site Netscape Devedge. 2002. (http://devedge-temp.mozilla.org/viewsource/2002/soap -overview/index_pt_br.html) data da ltima consulta mai. 2008. ERL, T. Service Oriented Architecture: concepts, techology and design. California: Pearson Education, 2005. GRUMAN G. Cinco maneiras de implementer SOA. In: Portal UOL. 2007. (http://cio.uol.com.br/estrategias/2007/11/12/idgnoticia.2007-11-12.0220762598/), data da ltima consulta mar. 2008. JAVA MAZINE. Rest vs WS-*. Graja: Devmedia Group, n. 54, p.38-47, 2007. JAVA MAZINE. JBoss ESB, Trazendo SOA com elegncia para as empresas. Graja: Devmedia Group, n. 59, p. 44-53, 2008. JONES, S. Enterprise SOA Adoption Strategies: using SOA to deliver it to the business. Toronto: C4Media, 2006. JOSUTTIS, N. M. SOA na Prtica: a arte da modelagem de sistemas distribudos. Jacar: Alta Books, 2008. MUNDO JAVA. Tendncias em foco. Rio de Janeiro: Editora Mundo, n. 26, p. 74, 2007. NEXTGENERATION. Curso SOA. In: Portal Nextg. 2007. (http://www.nextg.com.br/v3/web/curso.php?curso_id=52&modulo_id=426) data da ltima consulta dez. 2007. NOGUEIRA, K. Back-end. In: Frum Access.2008 (http://forumaccess.com/eve/forums/a/ tpc/f/449606231/m/100609431) data da ltima consulta jun.2008. PULIER, Eric; TAYLOR, Hugh. Compreendendo SOA Corporativa. Rio de Janeiro: Editora Cincia Moderna, 2008. RECKZIEGEL, M. Descrevendo, descobrindo e Integrando Web Services. In: Portal Imaster. (http://www.imasters.com.br/artigo/4474/webservices/descrevendo_descobrindo_e_integra ndo_web_services_-_uddi/) data da ltima consulta abr. 2008. 53

RICHARD, W. M. The Hole of Enterprise Service Bus. In: Portal Infoq. (http://www.infoq.com/resource/presentations/Enterprise-Service-Bus/en/slides/slide0.swf) data da ltima consulta ago. 2008. WIKIPEDIA. Front-end. In: A enciclopdia Livre. 2008. (http://pt.wikipedia.org/wiki/Front-end) data da ltima consulta jun. 2008. WIKIPEDIA. Middleware. In: A enciclopdia Livre. 2008. (http://pt.wikipedia.org/wiki/ middleware) data da ltima consulta jun. 2008. WIKIPEDIA. Message Exchange Pattern. In: Wikipedia the Free Ecyclopedia. 2008 (http://en.wikipedia.org/wiki/Message_Exchange_Pattern) data da ltima consulta jun. 2008. WIKIPEDIA. Service oriented architecture. In: Wikipedia the Free Ecyclopedia. 2008 (http://pt.wikipedia.org/wiki/Service-oriented_architecture) data da ltima consulta jun. 2008. WIKIPEDIA. Soap. In: Wikipedia the Free Ecyclopedia. 2008 (http://pt.wikipedia.org/wiki/SOAP) data da ltima consulta jun. 2008. VIOLINO, B. Como navegar no mar de padres SOA. In: Portal UOL. 2008. (http://cio.uol.com.br/gestao/2008/01/09/idgnoticia.2008-01-09.3145720442/) data da ltima consulta ago. 2008.

54