Universidade Federal do Rio de Janeiro Escola Politcnica MBA em tecnologia da Informao Executivo (MBTI-e)

Arquitetura Orientada a Servios - SOA

Autor(es): _________________________________________________ Arthur Ribeiro _________________________________________________ Jos Carlos Carvalho _________________________________________________ Victor Manaia

Disciplina: Sistemas de Informao e Banco de Dados Professor: Carlos Henrique

MBTI-e Maio de 2012

Sumrio
CAPTULO 1............................................................................................3 INTRODUO..........................................................................................3 1.1 JUSTIFICATIVA.................................................................................3 1.2 OBJETIVOS......................................................................................3 1.3 DESCRIO.....................................................................................4 CAPTULO 2............................................................................................5 REVISO BIBLIOGRFICA..........................................................................5 2.1 SOA................................................................................................5 2.2 WEB SERVICES................................................................................8 2.3 O MODELO TRIANGULAR...................................................................8 2.4 BARRAMENTO DE SERVIOS............................................................12 2.5 SOA, PROCESSOS E GOVERNANA...................................................14 CAPTULO 3...........................................................................................17 CASOS DE SUCESSO...............................................................................17 3.1 VERIZON.......................................................................................17 3.2 PROFLOWERS................................................................................17 3.3 OI.................................................................................................18 CAPTULO 4...........................................................................................19 CONCLUSO..........................................................................................19 BIBLIOGRAFIA.......................................................................................20

ii

Captulo 1 Introduo
Este trabalho apresenta a Arquitetura Orientada a Servios uma metodologia para prover solues de TI cujo uso tem sido crescente no mercado, seu funcionamento e componentes bsicos, a integrao de solues utilizando barramento de servios e a utilizao de Web Services como meio de comunicao. Alm disso, o trabalho apresenta a relao desta tecnologia com a modelagem de processos de negcio e sua utilizao como ferramenta de suporte para o atendimento dos objetivos estratgicos de uma organizao.

1.1 Justificativa
A orientao para objetos j existe h algumas dcadas as primeiras linguagens datam da dcada de 60 -, mas apesar da evoluo das linguagens, ainda h uma lacuna entre o resultado esperado pelo cliente e o processo de desenvolvimento em si. Soma-se a isso o desenvolvimento de diversas aplicaes ao longo do tempo utilizando diferentes tecnologias e plataformas, e atualmente a maioria das organizaes precisa conviver com um legado diversificado e de difcil comunicao. A industria vm promovendo alternativas, mas uma das que tem tido maior aceitao do mercado a arquitetura orientada a servios, que amparada por suas tecnologias permite a integrao do legado com novas aplicaes construdas baseadas em componentes com funcionalidade especfica e voltados para o reuso. Esta metodologia apresenta uma srie de vantagens no mdio prazo, mas exige o amadurecimento da governana da organizao - sendo necessria a definio e uniformizao dos processos de negcio e dos processos de desenvolvimento, com a consequente reformulao da estrutura de TI.

1.2 Objetivos
Este material realiza uma apresentao bsica da tecnologia, descrevendo a fundamentao terica do modelo, as tecnologias que o suportam, a motivao para sua criao, as vantagens e desvantagens de sua utilizao e casos de sucesso onde foi utilizado. 3

O trabalho no pretende apresentar um grande aprofundamento nas tecnologias envolvidas. Ao contrrio, sua proposta construir uma viso geral da arquitetura e da tecnologia associada.

1.3 Descrio
No captulo 2 realiza uma reviso bibliogrfica, apresentando os conceitos de arquitetura orientada a servios e barramento de servios, a tecnologia e os padres que os apoiam, vantagens e desvantagens da utilizao. O captulo 3 apresenta alguns estudos de caso onde foram utilizados SOA e barramento de servios.

Captulo 2 Reviso Bibliogrfica

2.1 SOA
Arquitetura Orientada Servios SOA, traduo do termo em ingls ServiceOriented Architecture, uma abordagem arquitetural corporativa que permite a criao de servios de negcio interoperveis e reutilizveis, compartilhados entre aplicaes e empresas. Segundo KOCH [1], SOA pode ser definida tambm como uma estratgia para a criao de ativos de software de uma empresa utilizando metodologia de programao orientada a servios. Existe um conjunto de solues que suportam a arquitetura, ilustrados na figura a seguir. O foco deste trabalho est na metodologia SOA e na arquitetura de referncia.

Figura 2.1 Conjunto de solues SOA. Dentre as caractersticas de SOA, destacam-se: um cliente no estar associado a um servidor, mas a um servio; separao dos componentes funcionais e de suas interfaces; e possibilidade de incorporao de servios em aplicaes dinamicamente durante o tempo de execuo.

2.1.1 - Motivao A necessidade cada vez maior das organizaes de aumentar a eficincia de suas atividades ao longo das ltimas dcadas fez com que uma srie de sistemas de informao fossem construdos. Esse desenvolvimento desordenado criou uma espcie de colcha de retalhos, onde os componentes dos sistemas possuem alto acoplamento e redundncia de funcionalidades - resultando em desperdcio de recursos e de trabalho, j que os componentes poderiam ter sido feitos voltados para o reuso. A arquitetura orientada a servios surgiu, assim, como uma evoluo natural da arquitetura de sistemas tradicional - buscando solucionar as necessidades do mercado, cada vez mais exigente em qualidade e agilidade. Neste paradigma, os clientes podem descobrir e usar servios mdulos de software com baixo acoplamento, com funcionalidades definidas e desenvolvidas voltadas ao reuso - de forma dinmica para atender s necessidades de seus processos. Os sistemas so compostos, portanto, da composio de servios. 2.1.2 - Vantagens e desvantagens A utilizao da metodologia sua traz consigo uma srie de vantagens, mas diante da complexa estrutura necessria para sua implantao, acaba por trazer tambm desvantagens. Os benefcios se do em diferentes nveis para o negcio: nota-se vantagens tticas, que atendem aos programadores e funcionrios do nvel operacional da empresa; e vantagens estratgicas, que oferecem suporte aos executivos no atendimento dos objetivos estratgicos. Dentre as vantagens tticas, merecem destaque: a. Reutilizao de Software ou de Servios: o desenvolvimento orientado a servios prega que a programao seja realizado de modo a produzir um pacote de software coeso e que atenda a um objetivo claro. Dessa forma, no desenvolvimento de novos aplicativos que exijam a mesma funcionalidade j disponibilizada por um servio, criado um link para o servio - sem a necessidade de conhecimento da lgica interna do servio, qual sua plataforma ou de onde vem. b. Aumento de Produtividade: o reuso possibilita a reduo de tempo e recursos gastos nas tarefas de desenvolvimento, teste e integrao dos servios que foram reutilizados, agilizando o desenvolvimento de projetos de software e permitindo que a equipe de desenvolvimento possa trabalhar em mais projetos. Alm disso, nota-se a melhora na 6

qualidade de novos aplicativos, considerando que no desenvolvimento orientado a servios os testes passam a ser uma das atividades mais relevantes. c. Maior Agilidade: mesmo que os servios no sejam reutilizados, podem agregar valor se facilitarem a manuteno dos sistemas. d. Escalabilidade: a gerncia de recursos disponveis para os servios podem ser ajustados dinamicamente, transferindo capacidade de processamento para o servio com maior demanda. Desta forma, o sistema torna-se mais previsvel e menos suscetvel interrupes, visto que pode ocorrer escalonamento horizontal e vertical - com a disponibilizao de mais servidores e diviso de servios, respectivamente. Dentre as vantagens estratgicas, destacam-se: a. Alinhamento com o Negcio: a arquitetura orientada permite que a organizao possa visualizar como a empresa construda em termos de tecnologia. Assim, novos projetos de TI podem ser pensados em termos de atividades e processos de negcio que buscam apoiar permitindo que os gestores possam priorizar e apoiar os projetos mais relevantes. b. Uma forma mais fcil de vender TI: padronizar, mapear e controlar ativos de TI no torna o negcio mais flexvel, capaz ou lucrativo; e seu ROI, com frequncia, nebuloso para o negcio. As vantagens de SOA so argumentos convincentes para vender uma iniciativa de arquitetura corporativa para o negcio. Dentre as desvantagens de sua utilizao, destaca-se: a. Necessidade de uniformizao dos processos de negcio: a utilizao de SOA tem como um de seus principais objetivos o alinhamento com os processos de negcio de uma organizao. Dessa forma, de vital importncia que os processos sejam padronizados em toda a organizao, de forma que as solues de TI possam apoiar e melhorar as atividades realizadas por toda a empresa. a. Alto custo de implantao: a implantao da metodologia implica em alto custo financeiro diante da necessidade de treinamento, estruturao de equipe especializada e aquisio de infra-estrutura para apoiar os sistemas. Alm disso, o retorno do investimento realizado, apesar de positivo na maioria dos casos, demora a ser percebido especialmente porque os benefcios de SOA s comeam a ser notados quando possvel a reutilizao dos servios. c. Necessidade de reestruturao da equipe de TI: a mudana no paradigma de programao, no processo de desenvolvimento de software e na arquitetura das solues 7

torna necessria a mudana na organizao da equipe especialmente com a criao de funes relacionadas com a gerncia de servios existentes e com a arquitetura das solues a serem desenvolvidas.

2.2 Web Services

Segundo BARBOSA, um Web Service um servio de aplicao que pode ser acessado usando os protocolos padro da Web, como por exemplo http, https, etc. Web Services podem ser aplicados a qualquer tipo de plataforma de integrao e suportam tanto aplicaes ponto-a-ponto quanto aplicaes distribudas. Diversos autores tratam da diferena entre SOA e Web services. Segundo KOCH, SOA uma arquitetura abrangente para criar aplicaes dentro de uma empresa; Web services so um conjunto de mecanismos-padro de comunicao criados sobre a World Wide Web. Ou seja, os web services so uma metodologia para conectar e comunicar, enquanto SOA uma estratgia de TI. Segundo BARBOSA, os padres WSDL, SOAP e UDDI formaram o que se denominou de primeira gerao web services, ou SOA primitivo. Com estes elementos j era possvel se realizar integrao de servios independentemente de sua tecnologia. No entanto ainda faltavam aspectos de ordem prtica que vieram na segunda gerao web services: os WS-*, ou Web Services Extensions, que so uma srie de padres que conferem controle sobre as transaes entre servios, segurana nas transaes, suporte orquestrao de servios, entre outras capacidades. Apesar de a teoria de web services ser o que h de melhor e a soluo recorrente para a construo de servios, a organizao deve entender que uma arquitetura orientada a servios um modelo conceitual que pode ser representado por diferentes tcnicas e tecnologias. Algumas solues, como uma classe com interfaces bem definidas tambm pode ser uma soluo orientada a servios. A seguir ser apresentado o modelo SOA utilizando web services e os padres utilizados para atender o modelo.

2.3 O modelo triangular

SOA se baseia em modelo operacional triangular atravs do qual os servios so publicados e consumidos. O modelo consiste de um conjunto de papis, que realizam uma srie de operaes. Para isso, so utilizados diversos padres tecnolgicos para descrio 8

dos servios, comunicao entre os papis e representao da informao a ser transmitida.

contrato

Figura 2.2 Modelo triangular SOA A figura acima ilustra os componentes do modelo triangular, que sero apresentados a seguir. 2.3.1 - Servio Segundo ROSA, um servio um componente de software habilitado para uso em rede, que desempenham funcionalidade clara e que pode ser reutilizado sem nenhum conhecimento especfico sobre ele - como em que linguagem foi desenvolvido, sistema operacional, etc. O servio pode ser uma poro de software totalmente nova ou um aplicativo composto, consistindo de cdigo de alguns dos sistemas ou de todos eles. Independente da maneira como foi construdo, criado um invlucro complexo em torno do cdigo, sendo disponibilizada uma interface que descreve o que a poro faz e como conectar a ela atravs de um contrato formal que oculta sua complexidade. Como principais caractersticas de um servio, temos: so reutilizveis e autnomos; podem ser pesquisados e descobertos; possuem baixo acoplamento; permitem composio com outros servios, e; evitam alocao de recursos por longos perodos. Segundo KOOCH, existem diversas maneiras de conectar servios, como links de programao customizados ou mecanismos de comunicao de software conhecido como web services, dentre outros. Para o funcionamento de SOA, imprescindvel um modelo de governana e uma metodologia de desenvolvimento de software nica e centralizada - de modo que reas 9

diferentes no criem o mesmo servio de maneiras diferentes ou usem conectores incompatveis. necessrio tambm a criao de um repositrio centralizado onde os desenvolvedores possam procurar servios e TI saiba por quem eles esto sendo utilizados. Os servios tm de ser bem documentados para que os desenvolvedores saibam para que eles servem, como integr-los e as regras para us-los. 2.3.2 - Papis Segundo MARZULLO, trs papis so identificados de acordo com os comportamentos e responsabilidades prprias de um servio: a. Provedor de Servio: aquele que oferece o servio; responsvel por fornecer toda a infraestrutura de acesso via rede - e capaz de responder a requisies internas e externas. b. Consumidor de Servio: aquele que utiliza o servio, localizando um servio, entendendo o seu protocolo de operao e utilizando-se desse protocolo para execut-lo. c. Registro de Servio: mecanismo que permite ao provedor cadastrar seus servios e ao consumidor encontr-los. Responsvel por gerenciar os repositrios que armazenam informaes sobre os seus servios e organizaes que os fornecem. Possui duas interfaces de acesso, associadas aos seus repositrios: uma de registro e outra de consulta (query). 2.3.3 - Operaes Ainda segundo MARZULLO e ROSA, so trs tambm as operaes realizadas: a. Publicao: operao na qual o provedor publica seus servios em um registro, e este preocupa-se em catalogar estes servios dentro de uma estrutura organizada e disponvel por um mecanismo de busca. Utilizando WSDL, o provedor descreve seu contrato de servio com as operaes e os parmetros que necessita para se comunicar. b. Busca: o consumidor efetua consultas diretamente no registro utilizando UDDI, de forma a obter a localizao de um servio e sua descrio. Pode ser utilizada em tempo de execuo, tornando a aplicao mais dinmica. c. Execuo / Unio - bind: ao encontrar o servio, o consumidor se conecta ao servio e o invoca remotamente, enviando solicitao ao Ponto de Acesso (local de disponibilizao do servio). utilizando um componente de transporte, que representa os formatos e os protocolos usados para conectar com o servio. O formato especifica os tipos de dados transmitido nas mensagens utilizando SOAP e XML. J o protocolo de

transporte que faz transferncia da mensagem de um ponto a outro utilizando um dos formatos da web, como HTTP ou SMTP. 2.3.2 - Padres Os principais padres utilizados que suportam a metodologia SOA, segundo ROSA, so apresentados a seguir: a. Web Services Description Language - WSDL: linguagem baseada em XML utilizada para descrever Web Services funcionando como um contrato do servio. - descrevendo o servio em si e especificando como acess-lo e quais as operaes ou mtodos disponveis. b. Universal Description, Discovery and Integration - UDDI: framework para disponibilizar, utilizar e pesquisar por servios na internet, escrita utilizando WSDL e se comunica utilizando SOAP. Possibilita encontrar o melhor servio dentre os milhares que esto dispostos na rede. A base de registro UDDI contm as seguintes informaes sobre cada servio: (i) pginas brancas, com o endereo, pessoas de contato e outros identificadores relativos ao negcio onde a empresa atua; (ii) pginas amarelas, que incluem categorizaes industriais baseados na organizao do servio, e; (iii) pginas verdes, que contm informaes tcnicas sobre os servios expostos pelo provedor. c. Simple Object Access Protocol - SOAP: protocolo para troca de informaes estruturadas em uma plataforma descentralizada e distribuda, utilizando tecnologias baseadas em XML. Sua especificao define um framework que prov troca de mensagens e comunicao independente de qualquer modelo de programao ou outra implementao especfica. Usualmente as mensagens so documentos XML no padro W3C e a comunicao utilizada HTTP ou SMTP. dos formatos da web, como HTTP ou SMTP. 2.3.5 Contrato de servio Contratos so documentos textuais que descrevem em detalhes a funcionalidade dos servios, para que os clientes possam busc-los e utiliz-los conforme a sua necessidade. Usualmente so utilizados padres de contratos a serem utilizados por toda a corporao, garantindo a uniformizao de informaes tornando-se uma tarefa complexa caso haja a necessidade de migrao de documentos para os padres escolhidos.

Como os servios so projetados para execuo em ambiente web, e diante da natureza dinmica de seu funcionamento e da possvel indisponibilidade de um servio, um contrato de servio pode ser composto tambm por documentos que determinam pontos adicionais como qualidade de servio, comportamento, limitaes e acordo de nvel de servio. Assim, atividades de monitoramento e controle so crticas para um bom funcionamento, garantindo a satisfao do usurio. Um processo eficiente de monitoramento essencial, medindo o desempenho dos servios e garantindo a qualidade da execuo e o atendimento do nvel de servio dentro dos padres determinados no contrato. 2.3.5 Viso Operacional Segundo MARZULLO, o processo bsico de SOA consiste das seguintes etapas: (1) o usurio acessa o registro UDDI e efetua a busca do servio; (2) ao encontrar o servio, o protocolo SOAP utilizado em conjunto com um protocolo de transporte (HTTP ou SMTP) durante o procedimento de invocao (requisio e resposta); (3) o provedor recebe a requisio, que tratada pelo SOAP listener; (4) a mensagem ento validada e ' deserializada' pelo web service de acordo com a especificao do servio; (5) ocorre a negociao de uso, sendo estabelecido um acordo de nvel de servio (SLA); (6) uma mensagem enviada ao servio em questo; (7) o usurio executa o servio.

2.4 Barramento de servios

Segundo REIS, em SOA, o elemento bsico o servio, e portanto, administrar um administrar um ambiente SOA implica em administrar servios. J em um ambiente utilizando arquiteturas tradicionais, o elemento bsico um mdulo de aplicao, que pode conter diversos servios. Dessa forma, gerenciar um ambiente tradicional utilizando um servidor de aplicao tradicional - tende a ser mais simples do que gerenciar um ambiente SOA. Diante disso surgiu a necessidade de uma ferramenta que permita gerenciar os servios de uma forma centralizada, operando como um barramento de controle, dando origem ao modelo denominado barramento de servios, traduo do termo em ingls Enterprise Service Bus ESB. Uma soluo ESB reconhecida como uma ferramenta essencial na implementao de qualquer projeto SOA. 1

O ESB um modelo conceitual tecnolgico que se utiliza de padres e ferramentas de modelagem e desenvolvimento para unir e conectar servios, aplicaes e recursos de TI da organizao. Um ESB interfere no modo como o arquiteto deve projetar sua arquitetura e, normalmente, prov um modelo abstrato de troca de mensagens para integrao e comunicao dos servios. Um ESB no representa uma arquitetura orientada a servios, mas um conceito que viabiliza o uso de SOA como infraestrutura de solues corporativas. A figura abaixo ilustra o modelo bsico de barramento de servios.

Figura 2.3 Modelo de barramento de servios Um dos papeis do ESB mediar a comunicao entre os servios e aplicaes legadas. Alm disso, deve disponibilizar mecanismos de integrao, roteamento de mensagens e ferramentas de controle e gerncia. Um ESB deve ser desenvolvido de maneira a criar um modelo de integrao nico dentro do ambiente de negcios, garantindo que todas as aplicaes, legadas ou no, mas que compem o negcio, estejam interligadas e possam se comunicar dentro de um protocolo padronizado de troca de mensagens. Quando um servio roteado atravs do ESB, alm de reduzirmos o acoplamento, j que a chamada no direta, ainda podemos resolver o problema de mltiplos parmetros para um mesmo servio, pois durante o roteamento podemos fazer transformaes nos dados, utilizando XSLT ou xQuery. Ou seja, durante o roteamento os dados na entrada podem ser transformados em outro formato para a chamada do legado. Algumas solues permitem alm de transformaes muito complexas a composio de servios, ou seja, permitem a criao de outros servios utilizando os j existentes atravs de mediaes e transformaes.

O modelo bsico, apresentado na figura 2.3 denominado inter-mdulo. Nele, existe um nico barramento comunicando com os servios e aplicaes legadas. Entretanto, existem outras formas de construo de barramento, apresentadas na figura 2.4. Barramento intra-mdulo Barramento Full-SOA

Figura 2.4 Modelos de barramento intra-mdulo e full-SOA No barramento intra-mdulo, existem mdulos com barramentos bsicos (intermdulo) que realizam comunicao apenas atravs de troca de mensagens. No barramento full-SOA, os mdulos esto ligados atravs de um barramento de servio, garantindo todas as vantagens da tecnologia na comunicao entre os mdulos, que possuem barramentos internos. A vantagem do ltimo modelo criar um barramento corporativo, que realize comunicao entre as diversas aplicaes de uma organizao mas mantenha cada aplicao restrita mantendo alguns servios disponveis apenas no mdulo e disponibilizando outros para todo a corporao.

2.5 SOA, processos e governana

Uma das premissas para utilizao de SOA o mapeamento de processos da organizao centralizados e unificados. Dessa forma, possvel associar os elementos de um processo de negcio aos servios de TI. Segundo MARZULLO, SOA permite o alinhamento em diferentes nveis: a. Negcio: SOA pode ser usada para organizar e orientar o mapeamento dos diferentes processos de negcio existentes na organizao;

b. Processo: SOA pode ser utilizada para guiar a composio das atividades dos processos de negcio; c. Tecnologia: SOA pode guiar a maneira como as tecnologias sero utilizadas ou desenvolvidas pela organizao; d. Servio: SOA pode ser usada para guiar o projeto e o desenvolvimento de solues de integrao entre as solues existentes, atravs de uma camada de integrao ou barramento de servios, por exemplo. Este alinhamento deve ser conduzido dentro do ambiente organizacional e deve desmembrar processos e subprocessos de negcio at o nvel em que as atividades realizadas pelos colaboradores da organizao so mapeadas. A figura abaixo apresenta um exemplo do resultado de um mapeamento.

Figura 2.5 Mapeamento de processos de negcio e servios de TI Para realizar o mapeamento de processos e servios de TI, ainda segundo MARZULLO, podem ser adotadas duas abordagens:

a. Top-down: a partir de uma viso geral do seu domnio de negcio, a organizao deve identificar os processos que lhe so prioritrios e, a partir dessa enumerao, mape-los em servios de TI. b. Bottom-up: a partir da identificao dos ativos de TI disponveis e, baseando-se na composio e disponibilidade de recursos, a organizao determina os tipos de servios que ser capaz de desenvolver e, s ento, segue com a priorizao dos processos de negcio que se ajustam a essa realidade. Com o mapeamento realizado, possvel priorizar o desenvolvimento de novos sistemas considerando aqueles que suportam processos traro maior retorno sobre investimento. Com isso, so usualmente priorizados processos que envolvem clientes, afetam diretamente a receita.

Captulo 3 Casos de sucesso

Segundo KOCH [1], as empresas que tiveram mais xito na utilizao de SOA so aqueles que tradicionalmente logram xito com tecnologia: grandes empresas, cujo negcio baseado em tecnologia, como servios de telecomunicao e financeiros. Isso porque seus executivos compreendem a importncia estratgica de TI, e destinam quantidade considervel de recursos e apiam projetos tecnolgicos. A seguir so apresentados trs casos de sucesso de utilizao de SOA.

3.1 Verizon
Segundo KOCH, a Verizon uma operadora norte-americana. Uma das principais e recorrentes funcionalidades dos seus sistemas a get CSR - get customer service record, ou obter registro de servio ao cliente um mdulo de software complexo que emprega infra-estrutura de integrao da empresa para acessar mais de 25 sistemas em quatro data centers ao redor do pas. Antes da criao do servio, aplicaes que utilizassem a funcionalidade precisavam criar links para todos os 25 sistemas, mantendo uma estrutura desorganizada, pouco escalar, e de difceis teste e manuteno. Com o servio, situado em um repositrio central na intranet da empresa, as aplicaes passaram a utilizar o protocolo SOAP para criar um nico link para a interface, cuidadosamente elaborada para atender s diversas aplicaes que demandam o servio. Desta forma, a empresa ganhou agilidade no desenvolvimento, considerando que economiza meses ou anos de projeto desta complexa funcionalidade.

3.2 ProFlowers
Segundo KOCH, a empresa americana ProFlowers.com, que trabalha com venda online de flore, no possua aplicativos redundantes ou mltiplas unidades de negcio, mas utilizava um aplicativo monoltico encarregado do processo de forma que uma nica alterao no processo ou um crescimento do volume de transaes em alguma data comemorativa exigia que o sistema inteiro fosse recriado.

Entretanto, com a utilizao de SOA ocorreu a diviso do processo de pedido de flores em servios discretos. Assim, cada componente pde ser isolado em um servio e modificado para lidar com os picos de demanda que acontecem em datas festivas. Nessas ocasies, os servidores reagem aos picos de atividade durante cada fase do processo de pedido, transferindo capacidade para o servio especfico que est precisando mais dela. Com isso, o sistema tornou-se mais previsvel e no houve interrupes desde que o processo foi implantado, no incio de 2002, j que a infra-estrutura pode ser escalada horizontal e verticalmente.

3.3 Oi
Em 2008, a empresa brasileira de telefonia Oi, passou a oferecer aos clientes a possibilidade de pagamento da fatura de seus servios atravs de via Boleto Bancrio, Dbito Automtico ou Dbito Programado Paggo uma soluo da empresa que utilizada o celular como carto de crdito. Entretanto, a empresa no realizava comunicao com as operadoras de carto de crdito, e para disponibilizar o servio deveria realiz-la. A soluo, portanto, deveria permitir ao Cliente realizar o Pagamento de sua Fatura Oi atravs do Carto de Crdito Visa ou Redecard, utilizando a funcionalidade de DACC (dbito automtico em carto de crdito). Por medida de segurana, a nica possibilidade de cadastro de DACC seria atravs do Siebel, uma ferramenta de CRM. O cadastro atravs do portal de vendas, onde o prprio cliente poderia realizar o cadastro, era invivel. Para superar a limitao, foi criada uma soluo tecnolgica utilizando barramento de servios. A grande vantagem de utilizao do barramento, alm da segurana e da portabilidade com as operadoras de carto de crdito, foi a padronizao da funcionalidade de DACC - podendo ser estendida a qualquer instituio financeira que utilizasse esta tecnologia, diminuindo assim o custo no trnsito de informaes.

Captulo 4 Concluso
Este trabalho procurou apresentar a arquitetura orientada a servios, sua implementao atravs de web services e a utilizao do barramento de servios . Foram apresentados tambm alguns casos de sucesso. A arquitetura orientada a servios apresenta uma srie de vantagens, mas o modelo no se aplica necessariamente a todas as empresas. preciso ter bem claro os objetivos e os benefcios estratgicos que se pretendem alcanar atravs de um bom projeto SOA. As empresas que tiveram xito na implantao geralmente so grandes organizaes, que usualmente so pioneiras nas novas tecnologias e cuja atividade depende fortemente de sistemas de informao. Para empresas menores, que construram solues utilizando pacotes de aplicativos integrados, ou que j adotam estratgias slidas de integrao de aplicativos, a utilizao de SOA provavelmente no trar benefcios e no justificar o retorno sobre o investimento. Vale destacar tambm que na utilizao de SOA os elementos desenvolvimento de servio e planejamento de arquitetura so distintos, porm no independentes precisam ser considerados e executados paralelamente. Servios que so criados isoladamente, sem levar em conta as metas de arquitetura e de negcio da empresa, podem apresentar pouco potencial de reutilizao (um dos benefcios mais importantes da SOA) ou fracassar por completo. A viso grandiosa da SOA que, quando TI capacitar plenamente para servios, as equipes de negcio podero assumir o controle sobre alterao na utilizao dos diferentes servios, criando novas combinaes para atender demandas de novos processos. Este cenrio fortalece ainda mais a TI, permitindo que cumpra seu papel de apoiar os objetivos estratgicos da organizao.

Bibliografia
[1] KOCH, R.. ABC da SOA,

http://cio.uol.com.br/tecnologia/2006/07/17/idgnoticia.2006-07-17.3732358054/, (Acesso
em 04/05/2012). [2] ROSA, A., FAQ WEB SERVICES E ARQUITETURA ORIENTADA A SERVIOS (SOA), Apostila Curso Multiplus, (Acesso em 04/05/2012). [3] BARBOSA, R., Porque adotar SOA, 2008, Portal BPM. [4] REIS, G. Acoplamento entre servios SOA, 2009,

http://www.glaucoreis.com.br/acoplamentosoa.pdf, (Acesso em 06/05/2012).

[5] MARZULLO, F., Arquitetura Orientada a Servio, 2009,

http://www.fabio.marzullo.nom.br/recursos/engsoft12/04Service_Oriented_Architecture.pdf, (Acesso em 25/04/2012).