Filipe Madeira da Silva

Trabalho de Conclus ao de Curso: SOA - Arquitetura Orientada a Servi cos

Este texto apresenta um estudo a respeito da Arquitetura Orientada a Servi cos, ou SOA, como ela e conhecida.

Orientador:

Prof. Dr. F abio Kon

o Paulo Universidade de Sa tica e Estat Instituto de Matema stica o Departamento de Ci encia da Computac a

S ao Paulo, SP - Brasil 2006

Sum ario

Resumo

p. 4

I Fundamentos
1 Introdu c ao 1.1 Fundo hist orico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Orienta c ao a Servi cos . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6
p. 7 p. 7 p. 8

II A Arquitetura
2 Caracter sticas de uma arquitetura orientada a servi cos 2.1 Baixo acoplamento (loose coupling) . . . . . . . . . . . . . . . . . . . . 2.2 Neutralidade de implementa c ao . . . . . . . . . . . . . . . . . . . . . . 2.3 Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Exemplo de arquitetura orientada a servi cos 4 Benef cios da orienta c ao a servi cos 4.1 Re uso de c odigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Redu c ao de redund ancias de funcionalidades . . . . . . . . . . . . . . . 4.3 Redu c ao do custo de manuten c ao . . . . . . . . . . . . . . . . . . . . . 4.4 Conclus ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Padr oes utilizados

9
p. 10 p. 10 p. 11 p. 11 p. 12 p. 15 p. 15 p. 16 p. 16 p. 16 p. 18

5.1 eXtensible Markup Language (XML) . . . . . . . . . . . . . . . . . . . 5.1.1 Exemplo de arquivo XSD . . . . . . . . . . . . . . . . . . . . .

p. 18 p. 19 p. 24 p. 24 p. 25 p. 27 p. 28 p. 28

5.2 Simple Object Acess Protocol (SOAP) . . . . . . . . . . . . . . . . . . 5.3 HyperText Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . 5.4 Web Services Description Language (WSDL) . . . . . . . . . . . . . . . 5.5 Universal Description, Discovery and Integration (UDDI) . . . . . . . . 5.6 Mensageria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 5.6.2 WS-Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . SOAP Message Transmission Optimization Mechanism (MTOM) . . . . . . . . . . . . . . . . . . . . . . . . 5.6.3 WS-Reliable Messaging . . . . . . . . . . . . . . . . . . . . . . .

p. 29 p. 29 p. 29 p. 29 p. 29

5.7 Seguran ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 5.7.2 WS-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XML-Encryption . . . . . . . . . . . . . . . . . . . . . . . . . .

III Conclus ao
6 Vis ao geral sobre SOA

31
p. 32

IV Parte subjetiva
7 O projeto 8 A gradua c ao 8.1 MAC110 Introdu c ao ` a Computa c ao MAC122 Princ pios de Desenvolvimento de Algoritmos . . . . . . . . . 8.2 MAC426 Sistemas de Bancos de Dados . . . . . . . . . . . . . . . . . . 8.3 PCS210 Redes de Computadores MAC448 Programa c ao para Redes de Computadores . . . . . . . . . .

34
p. 35 p. 36

p. 36 p. 37

p. 37

8.4 MAC340 Laborat orio de Engenharia de Software . . . . . . . . . . . . . Refer encias

p. 37 p. 38

Resumo
Nas u ltimas d ecadas, a tecnologia da informa c ao apresentou inova c oes marcantes. No in cio, t nhamos computadores que utilizavam v alvulas, ocupando uma sala inteira, e programados com o aux lio de cart oes perfurados. Agora, temos computadores que cabem na palma da m ao e conceitos cada vez mais avan cados para o desenvolvimento de software. Podemos perceber que a tecnologia da informa c ao apresenta fases bem denidas e a fase atual e marcada, sem d uvidas, pelo surgimento e populariza c ao da Internet. O conceito chave no momento e a comunica c ao dos sistemas, utilizando, principalmente, a Internet e v amos, at e h a pouco tempo, muitos dizendo que a orienta c ao a objetos havia surgido para ser a solu c ao denitiva para a programa c ao voltada ` a Internet. Certamente, a orienta c ao a objetos e um conceito muito poderoso e que facilita a resolu c ao de in umeros problemas, no entanto, n ao podemos assumir que ela e suciente para solucionar qualquer caso de desenvolvimento de software. No momento, muito tem-se falado a respeito de um novo conceito, a orienta c ao a servi cos. Da mesma forma que ocorreu com a orienta c ao a objetos, h a aqueles que apostam neste conceito como sendo algo denitivo. Certamente, vemos que a orienta c ao a servi cos oferece alguns conceitos interessantes e extremamente u teis, mas, a qualquer momento, poderemos nos deparar com um paradigma com mais recursos que surja para completar ou mesmo substituir a orienta c ao a servi cos Aqueles que apoiam com entusiasmo a orienta c ao a servi cos encontram-se, principalmente, no mundo corporativo, onde um n umero cada vez maior de empresas passa a dedicar maiores recursos ` a orienta c ao a servi cos e, mais especicamente, ` a Arquitetura Orientada a Servi cos (ou SOA, do acr onimo em ingl es). Este estudo se prop oe a analisar esta nova vertente da Engenharia de Software e o impacto que o desenvolvimento e populariza c ao deste paradigma trar a ao desenvolvimento de software. Espera-se que, ao nal do texto, o leitor seja capaz de compreender exatamente o que e a arquitetura e o que ela prop oe, assim como as suas vantagens e poss veis desvantagens. O estudo e baseado principalmente na minha experi encia de um ano de est agio na Accenture do Brasil que, como muitas outras grandes companhias de tecnologia da informa c ao, tem dedicado recursos crescentes ` a orienta c ao a servi cos. Durante o est agio, pude compreender no dia-a-dia como e feita a implementa c ao de uma solu c ao utilizando a orienta c ao a servi cos e pude participar de treinamentos que

auxiliaram enormemente neste entendimento. O projeto do qual eu participo e respons avel por implantar uma solu c ao de grande porte para a integra c ao de neg ocios da empresa de telefonia Telef onica, de S ao Paulo. um pouco desta experi E encia, adquirida durante este ano, que eu tento passar atrav es deste texto que foi escrito como Trabalho de Conclus ao de Curso da minha gradua c ao em Ci encia da Computa c ao pelo Instituto de Matem atica e Estat stica da Univesidade de S ao Paulo.

Parte I Fundamentos

Introdu ca o

1.1

Fundo hist orico

A medida que o tempo passa, nos deparamos com uma presen ca cada vez maior de sistemas de computa c ao no nosso dia-a-dia. Sistemas de computa c ao simples, como um editor de textos, e sistemas complexos, como o sistema de cobran ca de uma empresa de cart ao de cr edito est ao sendo utilizados a todo momento e tornam-se cada vez mais presentes no nosso dia-a-dia. No entanto, independente da complexidade do sistema, o ponto chave atualmente ea intera c ao entre sistemas. Com o crescente uso da Internet, presenciamos uma necessidade tamb em crescente de comunica c ao e intera c ao entre as partes envolvidas. A utiliza c ao dos sistemas de computa c ao tornou-se simples. Agora, precisamos tornar estes sistemas mais aut onomos para facilitar o uso destes no dia-a-dia. Basta ver que, se nos propusermos a analisar o que e a Rede (Web ) atualmente, concluiremos que ela e uma fonte imensa de informa c ao. Entretanto, tal informa c ao est a muito mal organizada. Uma pessoa mais alheia ao mundo da computa c ao poderia discordar de tal arma c ao j a que, comparado h a alguns anos, encontramos informa co es e not cias muito mais facilmente. Entretanto, a quest ao e que cada vez menos estaremos dispostos a catalogar informa c oes na Rede e tais informa c oes ser ao utilizadas de forma automatizada por processos, e n ao por humanos1 . A id eia e que a Rede deixe de fornecer apenas informa c ao pura e simples e passe a
1

O conceito envolvido refere-se ` a ideia de Rede Pragm atica (Pragmatic Web ).

fornecer servi cos (Web Services ) que sejam u teis aos humanos e aos sistemas que a est ao utilizando.

1.2

Orienta c ao a Servi cos

A orienta c ao a servi cos surgiu para suprir tal necessidade, unindo diversos conceitos e pr aticas sob um u nico paradigma. Tal paradigma e conhecido como Arquitetura Orientada a Servi cos ou SOA (do acr onimo em ingl es) e, em ess encia, trate-se de uma paradigma criado com o objetivo desenvolver sistemas modularizados, o que traz diversos benef cios ao produto nal. Ao inv es de desenvolvermos grandes aplica c oes como um u nico bloco, podemos encapsular algumas fun c oes importantes e disponibiliz a-las na forma de servi cos em uma rede. A arquitetura prop oe padr oes e pr aticas de desenvolvimento para possibilitar que os servi cos (web services ) possam interagir adequadamente em um ambiente t ao heterog eneo quanto a Internet, por exemplo, ou em outra rede qualquer. Como qualquer arquitetura baseada em componentes, SOA mant em a independ encia de cada um deles e dene, apenas, como ser a feita a comunica c ao entre eles. Os padr oes que t em sido utilizados para coordenar esta comunica c ao t em surgido sob orienta c ao do W3C e denem desde a linguagem padr ao de comunica c ao (XML) at eo modo como um servi co deve ser publicado para tornar-se acess vel atrav es da rede (UDDI). Estes e outros padr oes importantes para a compreens ao do funcionamento da arquitetura, como SOAP e WSDL, ser ao abordados com o decorrer do texto.

Parte II A Arquitetura

10

Caracter sticas de uma arquitetura orientada a servi cos

Segundo a Accenture, SOA e: Uma arquitetura que dene como fun c oes de neg ocios distintas, implementadas por sistemas aut onomos, devem operar conjuntamente para executar um processo de neg ocio. Assim, SOA e um paradigma de desenvolvimento de software que visa permitir que os componentes de um processo de neg ocio sejam integrados mais facilmente. Um componente de um processo de neg ocio e uma atividade comum, algo que e realizado frequentemente naquele processo de neg ocio espec co. Denimos esta atividade como fun c ao de neg ocio. Assim, o objetivo e implementar um sistema que represente o neg ocio do cliente, dividindo este neg ocio em processos e estes em atividades (fun c oes de neg ocio). Algumas caracter sticas importantes da arquitetura ser ao detalhadas nas se c oes a seguir.

2.1

Baixo acoplamento (loose coupling)

Cada atividade (fun c ao de neg ocio) e implementada como um servi co, ou seja, um componente independente que poder a ser utilizado quantas vezes forem necess arias em partes diversas do sistema. Assim, vemos que SOA e, essencialmente, uma arquitetura baseada em componentes, onde cada componente preserva a sua independ encia e interage, apenas, atrav es de interfaces bem denidas.

11

Este e o conceito conhecido como baixo acoplamento e que esta presente na orienta c ao a servi cos.

2.2

Neutralidade de implementa c ao

Outro ponto importante a se ressaltar e que n ao h a limita c oes pr evias em rela c ao ao modo de implementar um servi co. N ao h a limita c oes em rela c ao ` as tecnologias, linguagens ou plataformas a serem utilizadas, por exemplo. O desenvolvedor deve, apenas, especicar adequadamente o que o seu servi co faz e informa c oes como tipos de dados de entrada e sa da. Assim, outros desenvolvedores poder ao fazer o uso adequado deste servi co baseado nesta interface que foi especicada e que ser aau nica parte realmente vis vel do servi co. Detalhes de implementa c ao espec cos de um componente (servi co) n ao s ao importantes para o restantes do sistema e, por isso, n ao devem estar dispon veis.

2.3

Interoperabilidade

Para comp or a especica c ao citada na se c ao anterior, e que servir a de interface para o servi co, um conjunto de regras e padr oes devem ser seguidos. Tais padr oes e regras foram desenvolvidos para especicar tudo que e importante para que um servi co torne-se acess vel e utiliz avel atrav es de uma rede. Sendo assim, vemos que a arquitetura prop oe uma quase completa liberdade de desenvolvimento e, com isso, alcan ca-se a interoperabilidade, que e a possibilidade de sistemas coexistirem e comunicarem-se independente de fabricantes ou tecnologias. A interoperabilidade e uma caracter stica muito importante pois permite produzir solu c oes muito mais ex veis e de melhor qualidade j a que n ao encontramos diculdades de comunica c ao entre sistemas diversos, implementados de acordo com necessidades e limita c oes igualmente diversas.

12

Exemplo de arquitetura orientada a servi cos

Figura 1: Exemplo de uma arquitetura baseada em servi cos para o caso de um sistema gerenciador de planos de sa ude.

Na gura acima, temos um exemplo simplicado do modo como um sistema gerenciador de planos de sa ude poderia ser implementado utilizando os conceitos relacionados ` a orienta c ao a servi cos. No n vel inferior, temos todos os sistemas que o cliente atualmente utiliza. Estes sistemas s ao comumente chamados de legado e representam solu c oes desenvolvidas h a algum tempo e que n ao est ao, necessariamente, de acordo com a realidade atual do neg ocio do cliente.

13

Um neg ocio e algo extremamente din amico, que muda frequentemente ao longo do tempo. J a os sistemas n ao apresentam este dinamismo devido ` a forma extremamente r gida com que costumas ser desenvolvidos. Sendo assim, n ao h a como os sistemas evoluirem de modo a acompanhar a evolu c ao do neg ocio que eles se prop oe a atender. Contudo, geralmente, tais sistemas s ao vitais para a opera c ao atual do neg ocio e o cliente, simplesmente, n ao tem como desfazer-se deles. neste contexto que aplicamos a orienta E c ao a servi cos. Cada fun c ao de neg ocio que pretendemos disponibilizar no novo sistema ser a implementada como um servi co independente baseado nos sistemas j a existentes. Criamos servi cos para acessarem tais sistemas e retirarem todas as informa c oes que necessitamos. Tamb em e comum o novo sistema passar a operar os sistemas antigos de uma forma camuada, automatizando opera c oes que costumavam ser feitas manualmente. Neste exemplo, vemos que o legado e representado por estes sistemas: sistema de gerenciamento de benef cios; sistemas de aquisi c ao e vendas; sistema de riscos; sistemas corporativos; banco de dados de clientes; unidades de neg ocios e parceiros de neg ocios. Ap os analisar os sistemas existentes, podemos implementar as fun c oes de neg ocios desejadas, que est ao representadas no n vel imediatamente superior ao n vel do legado na gura. Neste caso, tais fun c oes s ao: adquirir informa c oes do cliente; congurar benef cios; criar perl de riscos; contratar resseguros e

14

ativar conta e cobran ca. Tendo implementado estes servi cos, o pr oximo passo e fazer uso das fun c oes de neg ocio que, agora, est ao dispon veis. Tais fun c oes s ao organizadas de forma a construirmos os processos de neg ocio desejados. Podemos denir esta fase com uma etapa de montagem. A maior parte do trabalho j a foi realizada e, agora, estamos, apenas, juntando as pe cas dispon veis para construirmos o conjunto esperado. A solu c ao nal, por vezes chamada de aplica c ao composta e representada no n vel superior da gura, e composta por um conjunto de processos de neg ocio. Cada processo de neg ocio e montado de acordo com o metodo descrito a pouco e, no exemplo, temos dois processos, que est ao representados imediatamente abaixo do n vel da aplica c ao nal. Tais processos s ao: renovar contas e processar seguro de vida.

15

Benef cios da orienta ca o a servi cos

Mesmo em um exemplo t ao simples como o anterior pode-se notar diversos benef cios de uma arquitetura que segue o modelo proposto pela orienta c ao a servi cos. O servi co que representa a fun c ao congurar benef cio, por exemplo, foi utilizado em ambos os processos desenvolvidos. Apesar de n ao podermos determinar o processo espec co para o qual este servi co foi inicialmente desenvolvido, ou mesmo se ele foi idealizado para ser utilizado em ambos os processos, presenciamos, em qualquer caso, a reutiliza c ao de um servi co em partes diversas do sistema. Em geral, a cria c ao de servi cos resulta em um bom ndice de reaproveitamento, o que possibilita a redu c ao de custos de projeto e desenvolvimento, e diminui o tempo total do projeto. SOA possibilita isto, apenas, porque este e um paradigma focado, atrav es dos servi cos, nos valores e processos de neg ocio. A aplica c ao torna-se, assim, t ao agil quanto o neg ocio em si e qualquer mudan ca no neg ocio e facilmente transmitida para o sistema, rearranjando as funcionalidades que j a est ao dispon veis atrav es dos servi cos e desenvolvendo a l ogica restante. A seguir, temos o detalhamento de alguns benef cios importantes que s ao, geralmente, perseguidos pelas pesquisas na area de Engenharia de Software e que s ao alcan cados quando implantamos uma solu c ao baseada em SOA.

4.1

Re uso de c odigo

O re uso de c odigo e um tema recorrente no campo de pesquisa de Engenharia de Software. No entanto, o pleno re uso e dif cil de ser atingido principalmente devido a

16

incompatibilidades de plataformas e linguagens. Com a orienta c ao a servi cos, como vimos, n ao nos deparamos com tal diculdade pois h a plena interoperabilidade entre os sistemas. Para reutilizar um servi co, precisamos, apenas, encontr a-lo (o que e feito atrav es de um diret orio de servi cos, como ser a posteriormente explicado) e utiliz a-lo.

4.2

Redu c ao de redund ancias de funcionalidades

comum vermos uma fun E c ao de neg ocio importante ser implementada em um sistema e ter que ser replicada em diversos outros sistemas. Isto ocorre, principalmente, devido a incompatibilidades de plataforma e linguagens j a que cada sistema foi implementado de forma aut onoma em rela c ao aos outros. Utilizando SOA, podemos eliminar tais redund ancias pois uma u nica atividade implementada como um servi co poder a ser compartilhada com qualquer sistema. A atividade n ao e inerente a nenhum sistema e, sim, ` a rede na qual o servi co foi disponibilizado.

4.3

Redu c ao do custo de manuten c ao

A redu c ao do custo de manuten c ao se d a ` a mesma medida que a redu c ao de redund ancias de funcionalidades. Antes, se uma falha na l ogica de uma fun c ao fosse detectada ou se tal fun c ao tivesse que ser alterada devido a mudan cas no neg ocio em si, ter amos que realizar tal altera c ao em todos os sistemas nos quais a fun c ao estivesse presente. Agora, com SOA, precisamos mudar, apenas, o u nico servi co que todas as aplica c oes utilizam, reduzindo, assim, o custo e o tempo de manuten c ao.

4.4

Conclus ao

Os itens enumerados acima s ao apenas algumas das vantagens alcan cadas ao utilizarmos uma arquitetura de componentes, mais especicamente, a arquitetura orientada a servi cos, para desenvolver uma aplica c ao complexa. Um projeto de integra c ao de um neg ocio de grande porte e algo muito complexo

17

e demorado. Sendo assim, se pudermos desenvolver o sistema com um alto ndice de reaproveitamento, baixa redund ancia de funcionalidades e conseq uentes redu c oes de custo de produ c ao e de tempo de desenvolvimento, teremos uma solu c ao que atender a melhor ao cliente. E isto e alcan cado com a utiliza c ao de SOA. Al em disso, temos como vantagens importantes a possibilidade de adeq uar de o aplicativo de forma f acil ` as mudan cas no neg ocio do cliente, e as redu c oes do tempo e do custo de manuten c ao da aplica c ao, citadas anteriormente. Certamente, SOA est a mostrando-se como um paradigma que pode ser muito vantajoso tanto aos desenvolvedores quanto aos clientes.

18

Padr oes utilizados

Como dito anteriormente, diversas regras e padr oes devem ser seguidos para montarmos um sistema baseado em SOA. O ciclo de vida de um servi co envolve diversas fases e cada uma destas fases tem um padr ao a ser adotado para que o servi co seja corretamente especicado. Um servi co deve seguir padr oes com rela c ao ao formato do protocolo de mensagens, assim como com rela c ao ` a forma de descrev e-lo ou torn a-lo dispon vel em um servi co de diret orios. Apesar de algumas fases admitirem uma s erie de padr oes, alguns desses padr oes assumiram um posto de destaque e tornaram-se padr oes de facto para a implementa c ao de uma arquitetura orientada a servi cos. Assim, o mais comum e encontrarmos servi cos implementados utilizando XML como a linguagem respons avel por representar tipos de dados e comp or as mensagens, SOAP como o protocolo de troca de mensagens XML, HTTP como o protocolo respons avel pelo envio das mensagens, WSDL para descrever o servi co e UDDI para listar os servi cos na rede. Os protocolos citados, assim como alguns outros que s ao respons aveis por fun c oes auxiliares, ser ao descritos a seguir.

5.1

eXtensible Markup Language (XML)

XML ou Linguagem de Marcadores Extens veis e uma linguagem muito utilizada atualmente em diversas aplica c oes pois, devido ao fato de ser poss vel criar marcadores de acordo com a necessidade corrente, permite que representemos muitos tipo de dados. A facilidade disponibilizada pela extensibilidade dos marcadores torna poss vel criarmos marcadores que realmente trazem um valor sem antico ` a mensagem e, assim, facilitam imensamente o tratamento dos dados.

19

XML e uma linguagem baseada em texto e e totalmente independente de plataforma. Deste modo, esta linguagem e ideal para a troca de mensagens entre plataformas, que e algo muito comum de ocorrer entre servi cos, que, provalvelmente, est ao em plataformas distintas. Com XML, a informa c ao e organizada de uma forma hier arquica, parecida com uma arvore, onde os marcadores mais internos s ao imediatamente dependentes do marcador que est a no n vel superior a estes. Este tipo de estrutura, aliada aos marcadores com valor sem antico, permite que os algoritmos respons aveis por analisar a mensagem sejam simples e ecientes. Al em disso, utilizando XML, criamos mensagens que s ao facilmente interpretadas tanto por humanos quanto por computadores, como explicado anteriormente, e podemos incluir praticamente qualquer informa c ao em qualquer linguagem, devido ao suporte a Unicode, que e um formato de representa c ao de caracteres que permite incluirmos os caracteres ocidentais comuns, caracteres n ao-romanos, s mbolos matem aticos, entre outros. A seguir temos um exemplo de representa c ao de tipos de dados utilizando XML. O exemplo segue o esquema de esquemas sugerido pelo W3C e conhecido como XSD.

5.1.1

Exemplo de arquivo XSD

XSD (XML Schema Denition) e um esquema baseado em XML utilizado para descrever tipos de dados, assim como as rela c oes entre tipo de dados distintos. Al em disso, atrav es do XSD tamb em e feita a valida c ao da representa c ao do dado. O documento a seguir e uma amostra de um pedido que transita ao longo do uxo de um processo de baixa de um acesso de uma rede de servi cos, como o presenciado por mim durante a implanta c ao do processo de baixa de acessos para a Telef onica.
1 2 3 4 5 6 7 8

<?xml version="1.0" encoding="ISO-8859-1"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://Businessitems"> <xsd:element name="Pedido" type="tns:Pedido"/> <xsd:complexType name="Pedido"> <xsd:sequence> <xsd:element name="Id" type="xsd:string"/>

20 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

<xsd:element name="Posicao" type="xsd:string"/> <xsd:element name="Header" type="tns:Header"/> <xsd:element name="AcessoA" type="tns:Acesso_A"/> <xsd:element name="AcessoZ" type="tns:Acesso_Z"/> <xsd:element name="FlagsPedido" type="tns:FlagsPedido"/> <xsd:element name="DadosAlocacao" type="tns:DadosAlocacao" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Header"> <xsd:sequence> <xsd:element name="TipoPedido" type="xsd:string"/> <xsd:element name="Operacao" type="xsd:string"/> <xsd:element name="Status" type="xsd:string"/> <xsd:element name="ProjetoEspecial" type="xsd:string"/> <xsd:element name="SequencialCircuito" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Acesso_A"> <xsd:complexContent> <xsd:extension base="tns:Acesso"/> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="Acesso" abstract="true"> <xsd:sequence> . . . </xsd:sequence> </xsd:complexType> <xsd:complexType name="Cliente" abstract="true"> <xsd:sequence> . .

21 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

. </xsd:sequence> </xsd:complexType> <xsd:complexType name="DadosInstalacao" abstract="true"> <xsd:sequence> . . . </xsd:sequence> </xsd:complexType> <xsd:complexType name="Comp" abstract="true"> <xsd:sequence> <xsd:element name="DadosTec" type="tns:DadosTec" maxOccurs="20"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="DadosTec" abstract="true"> <xsd:sequence> <xsd:element name="NomeAtributo" type="xsd:string"/> <xsd:element name="ValorAtributo" type="xsd:string"/> <xsd:element name="UnidadeAtributo" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Roteador" abstract="true"> <xsd:sequence> <xsd:element name="NomeRoteador" type="xsd:string"/> <xsd:element name="TipoRoteador" type="xsd:string"/> <xsd:element name="DadosRoteador" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="DadosConsultaInventario"> <xsd:sequence> <xsd:element name="Circuito" type="tns:Circuito"

22 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113

maxOccurs="20"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Circuito"> <xsd:sequence> <xsd:element name="Elemento" type="tns:Elemento"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Elemento"> <xsd:sequence> . . . </xsd:sequence> </xsd:complexType> . . . <xsd:complexType name="CPE"> <xsd:sequence> <xsd:element name="FlagCPE" type="xsd:string"/> <xsd:element name="FlagCPETelefonica" type="xsd:string"/> <xsd:element name="SenhaFornecida" type="xsd:string"/> <xsd:element name="NIP" type="xsd:string"/> <xsd:element name="NecessarioGerencia" type="xsd:string"/> <xsd:element name="Item" type="tns:Item" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="DadosTeste" type="tns:DadosTeste"/> </xsd:sequence> </xsd:complexType>

23 114 115 116 117 118 119 120 121 122 123 124 125

. . . <xsd:complexType name="AcessosBalanceamento"> <xsd:sequence> <xsd:element name="IdAcesso" type="xsd:string" maxOccurs="6"/> </xsd:sequence> </xsd:complexType> </xsd:schema> A linha 1 do documento representa a declara c ao. Nesta linha temos os atributos version, que informa que o documento segue a especica c ao 1.0, e encoding, que dene o tipo de codica c ao de caracteres utilizado, no caso ISO-8859-1 (Latin-1/West European ). Na linha 2, temos a deni c ao do esquema. O atributo xmlns:xsd dene que os elementos e tipos de dados usados v em do namespace http://www.w3.org/2001/XMLSchema. Namespace e um ambiente onde o nome das vari aveis eu nico. Na linha 5, vemos a deni c ao do primeiro elemento do documento. Este e o elemento principal utilizado em todo o sistema mencionado e os atributos name e type informam o nome e o tipo do elemento, respectivamente. Neste caso, o elemento pedido e um tipo complexo e ser a denido na linha 6. Nas linhas 7 e 17, temos o marcador sequence. Isto signica que todos os elementos internos a estes marcadores dever ao manter a ordem em que eles aparecem no XML. Nas linhas 8 a 16, temos os elementos que comp oe este tipo complexo. Eles s ao denidos da mesma forma que foi descrita anteriormente. Na linha 106, podemos notar alguns atributos importantes de um elemento: minOccurs, que dene a ocorr encia m nima do elemento, no caso zero, o que signica que ele n ao precisa estar presente no XML; e maxOccurs, que dene a ocorr encia m axima, no caso unbounded (ilimitado), que signica que n ao h a um limite de vezes que o elemento Item pode aparecer na mensagem.

24

5.2

Simple Object Acess Protocol (SOAP)

SOAP e um protocolo baseado em XML que e utilizado para denir um modo uniforme de transmitir dados representados no formato XML. Ele e um protocolo para troca de mensagens de via u nica e que n ao guarda informa c oes um paradigma bastante simples, no entanto, as sobre intera c oes anteriores (stateless ). E aplica c oes podem implementar intera c oes mais complexas, tais como requisi c ao/resposta e requisi c ao/m ultiplas respostas. Este protocolo n ao e respons avel pelo envio em si da mensagem mas, sim, por um conceito conhecido como envelope. O protocolo SOAP encapsula a mensagem e agrega informa c oes tais como a quem se destina a mensagem, exatamente como um envelope de uma carta. Um uso comum para o protocolo SOAP e na chamada de fun c oes remotas (RPC ou Remote Procedure Call ), onde precisamos informar, junto com a requisi c ao para execu c ao desta fun c ao, o local onde a fun c ao ser a encontrada, o nome da fun c ao, os argumentos e o valor de retorno. A principal desvantagem do protocolo reside no fato dele ser baseado em texto. Por n ao ser um protocolo bin ario, o seu uso ca empedido em diversos casos.

5.3

HyperText Transfer Protocol (HTTP)

HTTP e um protocolo da camada de aplica c ao que tornou-se o protocolo padr ao de transfer encia de dados na Internet (World-Wide Web ). Originalmente, o protocolo foi desenvolvido para o interc ambio de p aginas HTML mas, por ser um protocolo do tipo requisi c ao-resposta, tem sido utilizado em diversas outras ocasi oes. Uma requisi c ao utilizando HTTP consiste em um cliente iniciando uma conex ao TCP (Transfer Control Protocol ), protocolo da camada de transporte respons avel por dividir as mensagens em pacotes e envi a-las atrav es de uma rede, com um servidor em um ponto distinto da rede. A requisi c ao e enviada a uma porta espec ca onde o servidor j a monitora a entrada de requisi c oes e, ap os processar a requisi c ao, o servidor envia uma mensagem de resposta que ser a a informa c ao requisitada ou alguma mensagem de erro.

25

Uma varia c ao comum do HTTP e o HTTPS (HTTP over Secure Socket Layer ). Neste caso, a camada de seguran ca (SSL) criptografa a mensagem antes do envio.

5.4

Web Services Description Language (WSDL)

WSDL e um protocolo tamb em baseado em XML e respons avel por descrever um servi co, ou seja, por descrever a interface do servi co, que eau nica parte vis vel do mesmo. Atrav es da descri c ao no formato determinado pelo protocolo WSDL, temos acesso a todas as informa c oes necess arias para realizar a comunica c ao com um certo servi co. As informa c oes importantes para a comunica c ao s ao os formatos das mensagens de entrada e sa da a serem trocadas nas intera c oes com o servi co, as opera c oes suportadas pelo mesmo, os tipos de dados utilizados nestas intera c oes, o endere co onde o servi co pode ser encontrado e as interfaces de liga c ao (binding ). Quando os tipos de dados utilizados pelo servi co s ao tipos complexos, estes s ao descritos atrav es do esquema XML (XSD) citado anteriormente. Resumidamente, WSDL e respons avel por revelar o que um servi co pode fazer, onde ele est a, como invoc a-lo e quais tipos de dados enviar ao servi co. Ele descreve completamente a interface de um servi co. O documento a seguir e um exemplo da interface de um servi co utilizado no projeto para a Telef onica. Trata-se de um servi co bem simples e a sua descri c ao, atrav es do documento wsdl, reete isto.
1 2 3 4 5 6 7 8 9 10 11 12

<?xml version="1.0" encoding="ISO-8859-1"?> <wsdl:definitions xmlns:bons1="http://Businessitems" xmlns:tns="http://Utilitario/interfaces/InterfacePedido" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="InterfacePedido" targetNamespace="http://Utilitario/interfaces/InterfacePedido"> <wsdl:types> <xsd:schema targetNamespace="http://Utilitario/interfaces/InterfacePedido" xmlns:bons1="http://Businessitems"

26 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

xmlns:tns="http://Utilitario/interfaces/InterfacePedido" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:import namespace="http://Businessitems" schemaLocation="../xsd-includes/http.Businessitems.xsd"/> <xsd:element name="operation1"> <xsd:complexType> <xsd:sequence> <xsd:element name="Input" nillable="true" type="bons1:Pedido"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="operation1Response"> <xsd:complexType> <xsd:sequence> <xsd:element name="Output" nillable="true" type="bons1:Pedido"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="operation1RequestMsg"> <wsdl:part element="tns:operation1" name="operation1Parameters"/> </wsdl:message> <wsdl:message name="operation1ResponseMsg"> <wsdl:part

27 48 49 50 51 52 53 54 55 56 57 58 59 60 61

element="tns:operation1Response" name="operation1Result"/> </wsdl:message> <wsdl:portType name="InterfacePedido"> <wsdl:operation name="operation1"> <wsdl:input message="tns:operation1RequestMsg" name="operation1Request"/> <wsdl:output message="tns:operation1ResponseMsg" name="operation1Response"/> </wsdl:operation> </wsdl:portType> </wsdl:definitions> interessante destacar neste documento a presen E ca dos elementos operation1 e operation1Response nas linhas 18 e 28, respectivamente. Estes elementos s ao os que denem os tipos de dados de entrada e sa da. Neste caso, o tipo de dado utilizado tanto como entrada quanto como sa da e o tipo pedido, descrito anteriormente. Nas linhas 51 a 60, temos o marcador portType, que dene a opera c ao realizada pelo servi co, que consiste nos tipos de mensagens de entrada e sa da, basicamente.

5.5

Universal Description, Discovery and Integration (UDDI)

UDDI tamb em e um protocolo baseado em XML e e utilizado para descrever, descobrir e gerenciar os servi cos na rede. Atrav es deste protocolo, existe uma maneira padronizada dos servi cos descreverem a si pr oprios e, assim, tornarem-se dispon veis a quem possa utiliz a-los. UDDI prov e um diret orio de servi cos, algo que pode ser comparado com uma lista telef onica de servi costanto pela utilidade quanto pela forma como as informa c oes est ao organizadas. Ao publicarmos um servi co, temos que disponibilizar diversas informa c oes para que

28

um prov avel usu ario deste servi co possa encontr a-lo de forma mais f acil. Sendo assim, h a tr es componentes b asicos de registro de um servi co que est ao explicitados abaixo: P aginas brancas: aqui, h a informa c oes relacionadas com os desenvolvedores tais como informa c oes de contato, por exemplo; P aginas amarelas: aqui, as informa c oes est ao relacionadas ` as categorias de atua c ao do servi co, como numa lista de p aginas amarelas cl assica; e P aginas verdes: informa c oes t ecnicas sobre o servi co. Disponibilizando tais informa c oes quando um servi co e publicado, ele ca muito mais acess vel pois um potencial usu ario deste servi co poder a encontr a-lo fazendo buscas pelos desenvolvedores ou pela categoria de ind ustria a qual se destina, por exemplo.

Deste modo, as principais normas utilizadas numa arquitetura foram descritas. No entanto, estas n ao s ao as u nicas normas seguidas e, sim, as mais comumente utilizadas. Como exemplo, podemos citar outros protocolos de rede respons aveis pelo transporte de mensagens, al em do HTTP e do HTTPS, como FTP (File Transfer Protocol ) e SMTP (Simple Mail Transfer Protocol ). Com objetivos similares ao UDDI, temos WS-Inspection, WS-Metadata Exchange e WS-Resource FrameWork, por exemplo. A seguir, temos alguns outros padr oes relacionados com camadas auxiliares da arquitetura de um servi co.

5.6

Mensageria

A camada de mensageria e respons avel pela conabilidade da mensagem, ou seja, por assegurar que a mensagem chegue ao destinat ario e retorne adequadamente. Algumas especica c oes relacionadas a esta camada est ao nas se c oes a seguintes.

5.6.1

WS-Addressing

Especica c ao que permite que sistemas de mensagens suportem transmiss oes de mensagens de uma maneira neutra atrav es de redes que incluem pontos de processamento

29

como rewalls e gateways, por exemplo. Anteriormente, esta especica c ao j a foi conhecida por WS-Routing, WS-Referral e SOAP Routing Protocol (SOAP-RP).

5.6.2

SOAP Message Transmission Optimization Mechanism (MTOM)

MTOM descreve um mecanismo de otimiza c ao da transmiss ao da mensagem SOAP atrav es de uma re-codica c ao seletiva de por c oes da mensagem para otimizar o tratamento.

5.6.3

WS-Reliable Messaging

Especica c ao criada com o prop osito de criar um modelo gen erico de assegurar a entrega de uma mensagem para um servi co.

5.7

Seguran ca

Seguran ca e, sem d uvidas, um fator relevante para a utiliza c ao de servi cos. Sendo assim, cada camada da arquitetura necessita ser segura para manter a seguran ca do sistema todo. Os requisitos de seguran ca variam desde privacidade, conabilidade at e integridade de dados, para assegurar a realiza c ao de um neg ocio virtualmente na rede. A seguir, temos especica c oes relacionadas a seguran ca.

5.7.1

WS-Security

Este e um protocolo de comunica c ao que prov e meio de aplicar seguran ca aos servi cos. O protocolo foi, originalmente, desenvolvido pela IBM, Microsoft e VeriSign, e cont em especica c oes para refor car a integridade e a condencialidade na troca de mensagens entre os servi cos.

5.7.2

XML-Encryption

Criptografar mensagens XML e essencial para manter a condencialidade da informa c ao, como dados banc arios e de cart ao de cr edito, tanto durante o envio quanto

30

ao armazenar os dados. Em geral, o esquema de chave p ublica e utilizado para criptografar as mensagens. Neste esquema, existe um par de chaves: uma para criptografar e outra para decriptografar.

31

Parte III Conclus ao

32

Vis ao geral sobre SOA

SOA e um paradigma recente mas que aplica conceitos difundidos h a bastante tempo. Como vimos ao longo do texto, SOA tem in umeras vantagens, assim como qualquer arquitetura baseada em componentes. Quando dividimos o sistema que pretendemos implantar em fun c oes de neg ocios, e implementamos estas fun c oes como servi cos, temos um ganho consider avel de tempo e uma sens vel redu c ao de custos pois o n vel de reutiliza c ao de c odigo aumenta. Al em disso, centralizar a l ogica de uma fun c ao de neg ocio em um u nico servi co, propicia um ambiente muito mais din amico, onde mudan cas podem ser implantadas rapidamente j a que estas precisam ser realizadas em apenas um lugar do sistema. Vimos, tamb em, que SOA e uma solu c ao interessante para lidar com sistemas antigos (sistemas de legado) que, geralmente, s ao sistemas pouco adaptados ` a realidade atual do neg ocio do cliente. Isso porque podemos encapsular fun co es realizadas por estes sistemas em novos servi cos que podem ser criados para melhorar o modo como o neg ocio e operado. Um exemplo concreto e o vivenciado por mim durante implanta c ao do sistema de aprovisionamento de acessos da Telef onica. Antes, haviam in umeros sistemas de legado que j a estavam defasados e eram operados manualmente, o que causava grande quantidade de inconsist encias no sistema. Agora, apesar de n ao termos implantado uma solu c ao completa, pudemos camuar o acesso a estes sistemas, que agora s ao realizados de forma quase que totalmente autom atica pelo nosso sistema. Apenas algumas intera c oes tipicamente humanas foram mantidas sendo que o principal da l ogica de neg ocio relacionada com um aprovisionamento de acesso foi encapsulado e automatizado. Unindo as vantagens citadas ` a for ca das empresas que est ao patrocinando a ado c ao deste novo paradigma, e poss vel concluir que SOA ter a um espa co cada vez maior no dia-a-dia das empresas que implantam sistemas de integra c ao. Realmente, SOA e um dos temas mais comentados atualmente no mercado de tecnologia e as empresas est ao

33

destinando recursos crescentes a este paradigma.

34

Parte IV Parte subjetiva

35

O projeto

A id eia de realizar o trabalho de formatura a respeito de orienta c ao a servi cos surgiu a medida que o projeto do qual eu participava na Telef onica se desenvolvia. Eu percebi que SOA era um termo recorrente e que orienta c ao a servi cos era algo muito discutido, no entanto, este n ao e um conceito que e amplamente conhecido atualmente. Sendo assim, resolvi desenvolver um trabalho de pesquisa a respeito e pude ancor a-lo na minha experi encia adquirida no dia-a-dia junto com o restante da equipe e em um curso ministrado pela IBM a respeito de SOA e da ferramenta que utilizamos para implantar a solu c ao baseada em SOA. A Accenture possui, tamb em, um material extensivo a respeito de SOA na intranet da empresa e pude consultar tais cursos para orientar a minha pesquisa.

36

A gradua ca o

Durante toda a gradua c ao, pude desenvolver a minha capacidade de aprendizado e pesquisa e isto foi muito u til neste momento. Apesar deste texto tratar-se uma monograa de conclus ao de curso, a pesquisa realizada para desenvolv e-la tem sido extremamente u til no dia-a-dia do trabalho na Accenture. Isto prova que o curso prepara, sim, o aluno para o mercado de trabalho, onde pude constatar que capacidades como as citadas acima s ao muito mais valorizadas (e realmente s ao mais u teis) do que conhecimentos espec cos relacionados a linguagens ou frameworks. Algumas mat erias tiveram destaque nesta forma c ao e eu irei cit a-las nas se c oes a seguir.

8.1

MAC110 Introdu c ao ` a Computa c ao MAC122 Princ pios de Desenvolvimento de Algoritmos

Apesar de serem mat eria iniciais do curso e que, por isso, n ao cobravam tanto conhecimento te orico, estas mat erias foram essenciais para desenvolver a capacidade de aprendizado individual que foi t ao u til ao longo do curso e eu til no mercado de trabalho. Mais do que ensinar a sint axe das linguagens utilizadas (JAVA e C), estas mat erias ensinaram como entender um problema e, ent ao, pensar em uma forma de resolv e-lo (algoritmo). De posse disto, a tarefa de desenvolver o c odigo, independente da linguagem, torna-se simples.

37

8.2

MAC426 Sistemas de Bancos de Dados

Esta e uma mat eria muito importante, sem d uvidas, pois praticamente qualquer aplica c ao, por mais simples que seja, utiliza um sistema de banco de dados. Da mesma forma que a orienta c ao geral do curso, nesta mat eria n ao e ensinada uma linguagem espec ca, como PL/SQL, mas, sim, como entender um sistema de banco de dados para utiliz a-lo. Apesar de n ao irmos muito fundo na implanta c ao de um sistema de banco de dados nesta mat eria, o conte udo ensinado e extremamente importante e utilizado a todo momento no mercado de trabalho.

8.3

PCS210 Redes de Computadores MAC448 Programa c ao para Redes de Computadores

Atualmente, as redes de computadores est ao presentes em todos os lugares. Assim, entender bem os conceitos envolvidos e essencial para compreender os sistemas que utilizamos e mesmo os que iremos implantar. Estas mat erias propiciaram este entendimento que s ao extremamente u teis. Na implanta c ao do sistema citado nesta monograa, por exemplo, o aprovisionamento de acessos envolve diversas tecnologias como ATM e FRAME RELAY, as quais eu j a conhecia e compreendia devido a estas duas mat erias.

8.4

MAC340 Laborat orio de Engenharia de Software

Nesta mat eria, realizada neste u ltimo ano do curso, pude entender e implantar um sistema baseado em componentes. Tendo em vista que SOA trata-se, acima de tudo, de um paradigma relacionado com componenetes, esta mat eria foi de extrema import ancia para a compreens ao de grande parte dos conceitos envolvidos nesta monograa.

38

Refer encias
1 SERVICE-ORIENTED Computing: Semantics, Processes, Agents. [S.l.]: Chichester: John Wiley and Sons Ltd., 2005. 2 INTRODUCTION to Service Oriented Architecture (SOA). [S.l.], 2005.