UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE UMA INFRA-ESTRUTURA PARA COMPOSIÇÃO DINÂMICA E SEGURA DE SERVIÇOS WEB

Área de Sistemas Distribuídos

por

Jorge Roberto Lohn

Michelle Silva Wangham, Dra. Orientadora

São José (SC), novembro de 2008

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE UMA INFRA-ESTRUTURA PARA COMPOSIÇÃO DINÂMICA E SEGURA DE SERVIÇOS WEB

Área de Sistemas Distribuídos

por

Jorge Roberto Lohn

Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Michelle Silva Wangham, Dra.

São José (SC), novembro de 2008

DEDICATÓRIA

Aos meus pais, Vitor Valentin Lohn e Terezinha Lúcia Lohn,

pelo apoio incondicional, amor, carinho e dedicação.

A todos os professores, amigos e colegas, por estarem ao meu lado nesta jornada.

AGRADECIMENTOS

Aos meus pais, Vitor Valentin Lohn e Terezinha Lúcia Lohn, por sempre me incentivarem e

acreditarem na minha capacidade, pelas palavras amigas e de incentivo que sempre recebi de vocês,

principalmente nas horas difíceis, aqui expresso todo o meu amor e gratidão, e afirmo que sou quem

sou por me espelhar em vocês.

À professora Michelle Silva Wangham pela orientação, compreensão, incentivo nas horas

difíceis e pelo apoio recebido no decorrer deste projeto.

A todos os professores que de alguma forma contribuíram para o meu crescimento pessoal e

profissional.

Ao meu filho, que pelos poucos dias vividos, me ensinou a lutar com todas as forças pela

vida. Saibas que, se estou conseguindo realizar este trabalho é por sua causa; eu te amo meu filho.

À minha companheira, Janaína Matias, pelo carinho, incentivo, dedicação e compreensão

durante todo o desenvolvimento deste trabalho.

A todos os meus amigos e colegas, que tive a felicidade de encontrar na minha vida, pelo

carinho, companheirismo, momentos alegres e por toda a força nos momentos de adversidade.

SUMÁRIO

LISTA DE ABREVIATURAS ................................................................. vi LISTA DE FIGURAS ............................................................................ viii RESUMO ................................................................................................... ix ABSTRACT ............................................................................................... x 1 INTRODUÇÃO ................................................................................. 11 1.1 PROBLEMATIZAÇÃO ................................................................... 13 1.1.1 Formulação do Problema ............................................................................... 13 1.1.2 Solução Proposta ............................................................................................. 15 1.2 OBJETIVOS ...................................................................................... 16 1.2.1 Objetivo Geral ................................................................................................. 16 1.2.2 Objetivos Específicos ....................................................................................... 17 1.3 METODOLOGIA ............................................................................. 17 1.4 ESTRUTURA DO TRABALHO ..................................................... 18 2 FUNDAMENTAÇÃO TEÓRICA ................................................... 20 2.1 ARQUITETURA ORIENTADA A SERVIÇOS ............................ 20 2.2 SERVIÇOS WEB .............................................................................. 22 2.2.1 WSDL ............................................................................................................... 25 2.2.2 SOAP ................................................................................................................ 28 2.2.3 UDDI ................................................................................................................. 30 2.3 COMPOSIÇÃO DE SERVIÇOS WEB .......................................... 31 2.3.1 Orquestração de Serviços Web ...................................................................... 33 2.3.2 WS-BPEL ......................................................................................................... 34 2.4 COMPOSIÇÃO DINÂMICA DE SERVIÇOS WEB .................... 38 2.4.1 OWL-S .............................................................................................................. 39 2.5 CONCEITOS DE SEGURANÇA EM SISTEMAS COMPUTACIONAIS .............................................................................. 41 2.6 SEGURANÇA EM SERVIÇOS WEB ............................................ 45 2.6.1 Segurança em XML ........................................................................................ 46 2.6.2 WS-Security ..................................................................................................... 53 2.6.3 WS-Policy ......................................................................................................... 55 2.7 SEGURANÇA DE SERVIÇOS WEB COMPOSTOS ................... 57 3 INFRA-ESTRUTURA PARA COMPOSIÇÃO DINÂMICA DE PROCESSOS DE NEGÓCIOS SEGUROS .......................................... 60 3.1 VISÃO GERAL DA INFRA-ESTRUTURA PROPOSTA ............ 62 3.2 COMPOSITOR DINÂMICO DE PROCESSOS DE NEGÓCIOS SEGUROS ................................................................................................ 64

v

3.2.1 Compositor de Políticas de Qualidade Proteção para Serviços Web Compostos .................................................................................................................. 66 3.2.2 Aplicação da Política Composta de Qualidade de Proteção ....................... 68 3.3 MODELAGEM DA INFRA-ESTRUTURA PROPOSTA ............ 71 3.4 AGÊNCIA DE VIAGENS

ESTUDO DE CASO ......................... 77

3.4.1 Modelagem da Agência de Viagens ............................................................... 80 3.4.2 Implementação e Resultados .......................................................................... 89 3.5 CONSIDERAÇÕES GERAIS ......................................................... 98 4 CONCLUSÃO ................................................................................. 100 4.1 PRODUÇÕES CIENTÍFICAS ...................................................... 102 4.2 TRABALHOS FUTUROS ............................................................. 102 REFERÊNCIAS BIBLIOGRÁFICAS ................................................. 104 A ESTRUTURA DE CLASSES DA ONTOLOGIA DA AGÊNCIA DE VIAGENS ........................................................................................ 111 B ONTOLOGIA DO SERVIÇO WEB DA EMPRESA AÉREA ..... 112 C PROCESSO BPEL DO COMPOSITORPNSEG ........................... 117 D CASOS DE TESTE ........................................................................... 119

LISTA DE ABREVIATURAS

3DES Triple Data Encryption Standard AES Advanced Encryption Standard API Application Programming Interface B2B Business to Business BPEL Business Process Execution Language BPEL4WS Business Process Execution Language for Web Services CORBA Common Object Request Broker Architecture CSS Cascading Style Sheets DAML DARPA Agent Markup Language DCOM Distributed Component Object Model DoS Denial of service FTP File Transfer Protocol HTTP Hypertext Transfer Protocol IDL Interface Definition Language IEC International Electrotechnical Commission IETF Internet Engineering Task Force ISO International Organization for Standardization JSF JavaServer Faces LDAP Lightweight Directory Access Protocol MD5 Message-Digest Algorithm NASSL Network Application Service Specification Language OASIS Organization for the Advancement of Structured Information Standards OIL Ontology Inference Layer OV Organizações Virtuais OWL Web Ontology language PKI Public Key Infrastructure RMI Remote Method Invocation RSA Rivest Shamir Adelman SMTP Simple Mail Transfer Protocol RMI Remote Method Invocation RDF Resource Description Framework RPC Remote Procedure Call SAML Security Assertion Markup Language SDL Service Description Language SHA Secure Hash Algorithms SMTP Simple Mail Transfer Protocol SOA Service Oriented Architecture SSL Secure Sockets Layer SSO Single Sign On TCP Transmission Control Protocol TLS Transport Layer Security UDDI Universal Description, Discovery and Integration UDP User Datagram Protocol UML Unified Modeling Language URI Uniform Resource Identifier URL Uniform Resource Locator

vii

UUID Universally Unique Identifiers XACML eXtensible Access Control Markup Language XKMS XML Key Management Specification XML eXtensible Markup Language XSD XML Schema Definition W3C World Wide Web Consortium WS Web Services WS-I Web Services Interoperability Organization WS-BPEL Web Services Business Process Execution Language WSDL Web Service Description Language WSFL Web Service Flow Language WSCI Web Services Choreography Interface

LISTA DE FIGURAS

Figura 1 - Interação entre as entidades da SOA. ............................................................................... 21 Figura 2 - Colaboração típica na Arquitetura dos Serviços Web. ..................................................... 25 Figura 3 - Estrutura de um documento WSDL .................................................................................. 26 Figura 4 - Mensagem SOAP. ............................................................................................................. 29 Figura 5 - Processamento Multi-Ponto de uma Mensagem SOAP ................................................... 29 Figura 6 - Composição de Serviços Web. ......................................................................................... 32 Figura 7 - Processo definido através da WS-BPEL ........................................................................... 37 Figura 8 - Formas de assinaturas providas pela especificação XML Signature. ............................... 48 Figura 9 - Política expressa com o padrão WS-Policy ....................................................................... 57 Figura 10 - Infra-estrutura de segurança proposta neste trabalho. .................................................... 63 Figura 11 - Compositor de processos dinâmicos ............................................................................... 65 Figura 12 - Visão geral do serviço compositor de políticas .............................................................. 67 Figura 13- Atividades realizadas pelo serviço compositor de políticas ............................................ 67 Figura 14

Aplicando as políticas de segurança ao processo BPEL ................................................ 68 Figura 15 - Diagrama de seqüência que mostra os interceptadores .................................................. 70 Figura 16 - Atividades realizadas pela infra-estrutura de segurança. ................................................ 73 Figura 17 - Casos de uso do compositor de processos dinâmicos. .................................................... 73 Figura 18 - Estrutura do estudo de caso (Agência de Viagens) ......................................................... 79 Figura 19 - Casos de uso da Agência de Viagens............................................................................ 81 Figura 20 - Diagrama de Componentes da Agência de Viagens ....................................................... 86 Figura 21 - Diagrama de Seqüência da agência de Viagens .............................................................. 87 Figura 22

Formulário da aplicação web da Agência de Viagens ................................................... 90 Figura 23 - Parte do Arquivo Service.xml do Serviço Web AereoWS1 ........................................... 92 Figura 24 - Ws-Policy representando as políticas do Serviço AereoWS .......................................... 93 Figura 25 - Anexando a política a WSDL ......................................................................................... 93 Figura 26

Estrutura da ontologia descrita para representar o serviço AereoWS1 .......................... 94 Figura 27

Parte do arquivo AereoWS1Service.owl ........................................................................ 94 Figura 28

Trecho do arquivo AereoWS1Process.owl .................................................................... 95 Figura 29

Parte do arquivo AereoWS1Grounding.owl .................................................................. 96 Figura 30

Processo BPEL CompositorPNSeg ................................................................................ 97

RESUMO

LOHN, Jorge Roberto. Desenvolvimento de uma infra-estrutura para composição dinâmica e segura de Serviços Web. São José, 2008. 124 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, São José, 2008.

Processos de negócios descrevem serviços complexos que transpassam os limites organizacionais e são providos por diferentes parceiros. Os Serviços Web são ferramentas poderosas de integração e são peças fundamentais para a área de processos de negócios baseados em XML. A composição de Serviços Web cria serviços compostos a fim de solucionar determinados problemas, além de criar serviços coesos e reutilizáveis. A composição dinâmica de processos de negócio proporciona uma flexibilidade e fácil adaptação às mudanças nas regras de negócio. Existem trabalhos que tratam da segurança em Serviços Web, porém são poucos os trabalhos que visam proporcionar a segurança em processos de negócio compostos dinamicamente. Foram tais características que motivaram o desenvolvimento do presente trabalho. O objetivo deste trabalho é desenvolver uma infra-estrutura para composição dinâmica e segura de processos de negócios em redes colaborativas orientadas a serviços que promova a aplicação da política de segurança composta nos processos de negócio. A infra-estrutura para composição dinâmica e segura é composta por três partes: (i) o compositor de processos dinâmicos, o qual visa selecionar os parceiros a partir de instâncias de ontologia; (ii) o compositor de políticas de qualidade proteção para Serviços Web compostos, o qual tem por objetivo associar políticas de segurança às trocas de mensagem de um processo de negócio; e (iii) uma camada de segurança que aplique as políticas de segurança, garantindo assim a comunicação segura entre todos os participantes. Uma pesquisa bibliográfica sobre segurança em Serviços Web compostos foi realizada visando consolidar os conceitos envolvidos com o problema e estudar as tecnologias necessárias para o desenvolvimento da infra-estrutura proposta. Um estudo de caso, Agência de Viagens, foi descrito e modelado para avaliar a infra-estrutura proposta neste trabalho. Em seguida, através de diagramas UML, foi feita a modelagem da infra-estrutura proposta e da agência de viagens. Foram desenvolvidos alguns casos de teste para testar a infra-estrutura criada. Como resultado, tem-se o detalhamento da infra-estrutura necessária para prover a segurança nas composições dinâmicas de Serviços Web. A implementação da infra-estrutura não está completa, porém o protótipo implementado, direcionado ao estudo de caso, possibilitou aferir a aplicabilidade da infra-estrutura proposta neste trabalho.

Palavras-chave: Composição Dinâmica de Serviços Web. Segurança em Processos de Negócio. Redes Colaborativas.

ABSTRACT

Business Processes describe complex services that transpose the organizational limits and are provided by different partners. The Web services are powerful tools of integration and are basic parts for the area of business processes based on XML. The composition of Web Services allows services composition in order to resolve certain problems and create cohesive and reusable services. The business processes dynamic composition provides a flexible and easy adaptation to changes in the rules of business. The objective of this work is to develop an infrastructure for safe and dynamic composition of business processes in collaborative networks geared to services that promote the implementation of security policy consists in business processes. The infrastructure for safe and dynamic composition is composed of three parts: (i) the dynamic processes composer, which aims to select partners from instances of ontology, (ii) the policies of quality composer protection for composite Web services, which aims to link security policies, the exchange of messages in a process of business, and (iii) a layer of security to apply the security policies, thus ensuring secure communication between all participants. A literature search on security in composite Web Services was held aimed at consolidating the concepts involved with the problem to be solved, studying the technologies needed for developing of the infrastructure proposal. A case study, travel agency, was described and modeled for assessing the infrastructure proposed in this paper. Then, through UML diagrams, was the modeling of proposed infrastructure and the travel agency. There have been some test cases to test the infrastructure created. As a result, we have the detail of the infrastructure needed to provide security in the dynamic compositions of Web Services Implementation of the infrastructure is not complete, but the prototype implemented, directed to the case study, assess the possible applicability of the infrastructure proposed in this paper.

Keywords: Dynamic Composition of Web Services . Security in business processes. Collaborative Networks.

1 INTRODUÇÃO

Com a evolução da Internet nos últimos anos, principalmente em relação ao aumento da

velocidade de transmissão e do desenvolvimento de tecnologias que permitem a criação de sistemas

robustos, em especial no ambiente web, muitas empresas estão fazendo da Internet o seu escritório.

A Internet fornece uma poderosa infra-estrutura de colaboração e comunicação, estimulando a

criação de redes colaborativas para diversos objetivos. Uma rede colaborativa é constituída por uma

variedade de entidades autônomas, geograficamente distribuídas, que colaboram para alcançar um

objetivo compatível ou comum e cujas interações são suportadas pelas redes de computadores

(CAMARINHA-MATOS & AFSARMANESH, 2005). A utilização de redes colaborativas estão crescendo, principalmente, para atender novas

oportunidades de negócio. Empresas se unem formando uma rede colaborativa, criando desta

maneira processos de negócio complexos, difíceis de serem gerenciados e controlados

(CAMARINHA-MATOS & AFSARMANESH, 2005). Por exemplo, uma determinada empresa

recebe uma boa oportunidade de negócio, porém, apenas com seus recursos e habilidades não é

capaz de efetuar o trabalho. Nesta situação, esta pode unir-se temporariamente, através de uma

organização virtual, a outras empresas que forneçam as habilidades e recursos necessários para que

juntas consigam atender a oportunidade de negócio. Após o encerramento das atividades, esta rede

de colaboração é desmanchada. Dentro do cenário de redes colaborativas, a cooperação na forma de

organizações virtuais representa uma estratégia moderna que vem sendo adotada por muitas

empresas, profissionais e laboratórios espalhados ao redor do mundo, visando atender novas

oportunidades de negócios, ampliar suas participações em novos mercados e/ou alcançar excelência

científica para o desenvolvimento de projetos inovadores (WANGHAM et al., 2005). Devido à necessidade de uma rápida adaptação dos negócios para atender novos

consumidores e novas condições de mercado, cada vez mais as organizações, através das redes

colaborativas, procuram se unir para criar processos de negócios que transpassam os seus limites

organizacionais. Os Serviços Web possibilitam esta composição e combinação de diferentes

provedores de serviços, permitindo a criação de serviços mais complexos e sofisticados. Além

disso, os Serviços Web possibilitam que empresas compartilhem seus sistemas legados, diminuindo

assim os custos da integração entre os parceiros de negócio.

Conforme consta em W3C (2004a), os Serviços Web seguem a Arquitetura Orientada a

Serviços e são componentes de softwares projetados para suportar interações entre aplicações

12

heterogêneas sobre a Internet. A Arquitetura Orientada a Serviço é um paradigma para organização

e utilização de habilidades distribuídas que estão sob controle de diferentes domínios proprietários.

Complementando, a Arquitetura Orientada a Serviço é um meio para organizar as soluções que

promovem o reuso, o crescimento e a interoperabilidade (NEWCOMER & LOMOW, 2004).

As redes colaborativas são, geralmente, caracterizadas como um sistema aberto, que faz uso

da Internet. Devido a isto, as vantagens inerentes dos Serviços Web, tornam esta tecnologia ideal

para compor a camada de infra-estrutura que dará o suporte para as trocas de informações, que

fornecerá as funcionalidades de coordenação e de colaboração e que permitirá que relações de

negócios entre empresas sejam estabelecidas de maneira simples e dinâmica (ECOLEAD, 2005).

De acordo com De Mello et al. (2006) e Carminati, Ferrari e Hung (2005), as principais

características que tornam os Serviços Web uma tecnologia emergente e promissora para a

realização de transações comerciais são: (1) o fato de possuir um modelo fracamente acoplado e

transparente, garantindo a interoperabilidade entre os serviços; (2) utilizar-se de padrões

amplamente difundidos como o HyperText Transfer Protocol (HTTP) e eXtensible Markup

Language (XML); (3) possuir interfaces auto-descritivas e baseadas em XML; e (4) tornam mais

fácil a composição ou a combinação de diferentes provedores, visando formar serviços mais

complexos e sofisticados.

No contexto de uma arquitetura orientada a serviços, compor Serviços Web e assim criar

processos de negócios de alto nível, que transpassem diferentes organizações, requer o uso de

padrões amplamente aceitos para modelar as interações B2B (business to business) e para

possibilitar a integração de aplicações corporativas (EAI- Enterprise Application Integration)

(PELTZ, 2003). Conforme definido em Peltz (2003), a orquestração e a coreografia de Serviços

Web são abordagens baseadas em padrões abertos para conectar os serviços e criar processos de

negócios de alto nível.

A orquestração apresenta um processo de negócio executável que permite executar vários

Serviços Web em uma determinada seqüência lógica para atingir um determinado resultado. Com a

orquestração, o processo é sempre controlado por uma das partes do negócio, o que difere da

coreografia que é mais colaborativa e que permite que cada parte envolvida descreva sua

participação na interação (PELTZ, 2003). A coreografia registra a seqüência de mensagens que

pode envolver múltiplas partes e múltiplos recursos, descreve tipicamente a troca de mensagens

13

públicas que ocorrem entre os Serviços Web, ao invés do processo de negócio específico que uma

única parte executa (PELTZ, 2003).

A composição dinâmica de Serviços Web visa ligar, automaticamente, diferentes serviços

para atingir um objetivo complexo, tendo como base, normalmente, dados semânticos adicionais

que descrevem os Serviços Web (BERNERS-LEE, HENDLER & LASSILA, 2001) e que podem

ser usados para geração dinâmica da seqüência de orquestração (WU et al., 2003). O uso da Web

semântica na composição de Serviços Web é um tópico de pesquisa muito relevante devido ao seu

potencial em alcançar uma integração de aplicações que seja dinâmica, escalável e com custo

efetivo (WU et al. 2003). Com a Web semântica, processos podem fazer interpretações sobre os

recursos disponíveis no ambiente de forma não ambígua. Tais interpretações são possíveis através

do emprego de linguagens de descrições e técnicas de inferências baseadas em ontologias.

1.1 PROBLEMATIZAÇÃO

1.1.1 Formulação do Problema

Em muitos casos, as partes que compõem as redes colaborativas não se conhecem e, mesmo

em empresas que são grandes parceiras, a segurança sempre é uma preocupação. Devido à

necessidade do compartilhamento de informações importantes e até mesmo sigilosas, as redes

colaborativas precisam de uma efetiva infra-estrutura de segurança para impedir que um membro

consiga acesso não autorizado às informações. Uma vez que estas redes exigem que as organizações

tenham relacionamentos com um amplo domínio de parceiros, apesar da tendência para trabalhos

colaborativos, muitas organizações e/ou profissionais ainda têm receios em compartilhar

informações sensíveis, quando há a necessidade de colaboração com parceiros desconhecidos

(WANGHAM et al., 2005). No ambiente de redes colaborativas, deve-se ter uma política de segurança global, além

daquelas utilizadas por cada empresa. Cada empresa que compõem uma rede colaborativa possui

suas próprias políticas, logo neste ambiente colaborativo têm-se várias políticas de segurança. Cada

domínio transposto por um processo de negócio pode prover seu próprio conjunto de credenciais de

segurança, tomando como base suas tecnologias subjacentes de segurança e suas políticas de

segurança e de negócios (DE MELLO et al., 2005). Ou seja, havendo a necessidade de colaboração

há ainda a necessidade de um acordo entre os parceiros envolvidos.

14

A segurança é sempre uma questão importante em sistemas distribuídos. Vários padrões são

utilizados para prover segurança às informações expressas em XML (IMAMURA et al., 2002;

BARTEL et al., 2002) e como conseqüência aos Serviços Web. Entretanto, quando se considera não

mais um serviço único, mas sim uma orquestração de Serviços Web, constata-se que a segurança

dos processos de negócios não foi ainda profundamente investigada e que ainda não existem

soluções concretas e completas (KOSHUTANSKI & MASSACCI, 2003; CHARFI & MEZINI,

2005; CARMINATI, FERRARI & HUNG, 2005). As tecnologias desenvolvidas para prover a

comunicação segura, a autenticação e autorização precisam ser aprimoradas para que a composição

dinâmica seja levada em conta.

Nos ambientes de redes colaborativas, o uso de mecanismos de segurança que garantam

autenticidade, confidencialidade, integridade, disponibilidade e não-repúdio das informações,

conforme especificado na política de segurança da organização virtual, reforça a construção da

confiança entre as organizações (RABELO et al, 2003).

Conforme constatado em (CARMINATI, FERRARI & HUNG, 2005), geralmente, um

provedor de serviços tem preocupações de segurança com relação aos provedores ou serviços com

os quais este coopera durante um processo de negócio. É comum que os Serviços Web estejam

acessíveis apenas para os parceiros de negócios que possuam credenciais de segurança apropriadas.

Isto significa que o compositor do Serviço Web tem que conhecer as políticas de segurança dos

serviços parceiros, antes de escrever o processo executável que invocará o serviço. Neste cenário,

uma política de segurança especifica quais mecanismos de autenticação, algoritmos de cifragem e

de assinatura digital são suportados por um Serviço Web parceiro.

As partes envolvidas necessitam de suporte apropriado para garantir esta qualidade de

proteção. Ou seja, estas necessitam negociar e chegar a um acordo de quais mecanismos,

usualmente, algoritmos de cifragem baseados em chaves e de assinaturas digitais, serão usados,

visando garantir a compatibilidade e a interoperabilidade entre os mecanismos de segurança.

Nas redes colaborativas, para acompanhar as mudanças no mundo dos negócios e para

agilizar a criação de processo de negócios sob demanda, há a necessidade de que a composição de

Serviços Web seja automática, flexível, escalável, auto-gerenciada e segura.

A partir da contextualização apresentada, pôde-se formular as seguintes questões de

pesquisa, indicando os desafios enfrentados nesta pesquisa:

15

como desenvolver processos de negócios, através da composição dinâmica de Serviços

Web, em redes colaborativas orientadas a serviços e abertas?

como estabelecer dinamicamente os parceiros envolvidos em um processo de negócios

baseado em orquestração de Serviços Web?

como promover e aplicar um acordo entre as políticas de segurança dos diversos

modelos administrativos atravessados durante a execução de um processo de negócios?

1.1.2 Solução Proposta

Atualmente, muitas organizações precisam se unir temporariamente para atender uma

oportunidade de negócio, sendo que este fenômeno está cada vez mais freqüente. Existe neste

cenário uma grande necessidade de integrar todos os participantes desta rede de uma forma

automática e segura. Este trabalho está focado nos aspectos de segurança da composição dinâmica

de Serviços Web no ambiente das Organizações Virtuais (OV), um tipo de rede colaborativa.

Para a composição de serviços é utilizada a orquestração e como a WS-BPEL (Web Services

Business Process Execution Language), padronizada pela OASIS, é a linguagem mais popular para

orquestração de Serviços Web, com grande aceitação na academia e na indústria (CHARFI &

MEZINI, 2005) esta foi a linguagem escolhida para a orquestração dos Serviços Web. Este trabalho

não utilizou a coreografia para a composição de Serviços Web.

Para tratar o problema apresentado, o presente trabalho pretende definir uma infra-estrutura

para redes colaborativas, totalmente orientada a serviços, com suporte a composição dinâmica de

processos de negócios. Este protótipo suporta o estabelecimento dinâmico dos parceiros envolvidos,

define e aplica a política de segurança do processo de negócio. Neste trabalho, o foco está em

prover a segurança lógica, garantindo a autenticidade, confidencialidade e a integridade das

informações trocadas. As propriedades da disponibilidade e do não-repúdio das informações não

serão garantidas na infra-estrutura de segurança. Além disso, não foi considerada a segurança física

e ambiental dos sistemas de informação das organizações.

Além dos aspectos funcionais, propriedades não funcionais de qualidade de serviço, tais

como os que expressam relações de confiança ou regras de políticas de segurança, precisam ser

garantidas para que a linguagem de composição WS-BPEL seja amplamente adotada na indústria.

Como esta linguagem de composição não fornece meios para especificar e garantir propriedades de

16

segurança e como os padrões de segurança não tratam diretamente das implicações provenientes da

criação de serviços complexos que atravessam diferentes domínios administrativos, uma infra-

estrutura de segurança que contribua para a construção de processos de negócios seguros em redes

colaborativas se mostra extremamente necessária. Para garantir os requisitos não funcionais,

principalmente de segurança, serão adicionados à descrição dos processos de negócios e no uso de

padrões de segurança já consolidados e aceitos na indústria, o WS-Security (OASIS, 2006b), o WS-

Policy (W3C, 2007b), entre outros.

Com a Web semântica, processos podem fazer interpretações sobre os requisitos e

competências de segurança, definidos em cada domínio administrativo, de forma não ambígua. Tais

interpretações são possíveis através do emprego de linguagens de descrições e de técnicas de

inferências baseadas em ontologias (motores lógicos semânticos). Fez parte deste trabalho, o

desenvolvimento de um processo de negócio modelado e executado em conformidade com o padrão

WS-BPEL sendo que o mesmo foi integrado ao protótipo de segurança. A integração do protótipo

ao processo de negócio foi realizada da forma mais transparente e automática possível.

Ao longo do desenvolvimento deste projeto foram utilizadas apenas ferramentas de código

aberto, já que estas ferramentas proporcionaram maior flexibilidade durante a implementação do

protótipo da infra-estrutura de segurança. Como linguagem de programação foi utilizada a

linguagem Java, que provê um excelente suporte ao desenvolvimento de aplicações distribuídas

orientadas a serviços e que possui bibliotecas e ferramentas para implantação da orquestração e para

o uso de web semântica. Foi utilizado o framework Apache Axis 2 para realizar as implementações

dos Serviços Web e algumas bibliotecas da Apache para prover segurança ao ambiente de rede

colaborativa

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Desenvolver uma infra-estrutura para composição dinâmica e segura de processos de

negócios em redes colaborativas orientadas a serviços que promova a aplicação da política de

segurança composta nos processos de negócio.

17

1.2.2 Objetivos Específicos

De forma a alcançar o objetivo geral definido, os seguintes objetivos específicos serão

perseguidos:

analisar as ameaças e implicações de segurança decorrentes da composição de Serviços

Web dinâmicos;

desenvolver um serviço que possibilite a composição dinâmica dos parceiros de uma

orquestração de Serviços Web;

definir uma infra-estrutura de segurança que promova a aplicação da política de

segurança composta em processos de negócios executáveis;

definir e implementar um processo de negócio exemplo (Agência de Viagens) que utiliza

a web semântica para informar as características dos Serviços Web que serão utilizadas

na escolha dos parceiros durante a composição dinâmica;

implementar um protótipo que engloba o compositor de processos dinâmicos e a infra-

estrutura de segurança proposta para redes colaborativas orientadas a serviço; e

integrar o protótipo desenvolvido ao processo de negócio exemplo para verificar a

aplicabilidade do protótipo desenvolvido.

1.3 Metodologia

Este trabalho pode ser considerado uma pesquisa aplicada, pois teve por objetivo solucionar

um problema específico, possibilitar a composição dinâmica de processos de negócio e garantir as

propriedades de segurança em tal ambiente.

Neste trabalho, foi utilizada a técnica de pesquisa bibliográfica para obter informações sobre

os assuntos relacionados à segurança em Serviços Web compostos. Entre estes assuntos está a

arquitetura de Serviços Web, suas características e benefícios, e a composição de Serviços Web.

Para finalizar este estudo bibliográfico foram apresentados os conceitos de segurança em sistemas

computacionais e como é possível especificar requisitos não funcionais, principalmente de

segurança, na arquitetura de Serviços Web. Este levantamento foi realizado por meio de diversas

fontes, dentre estas, livros, artigos publicados em conferências e em periódicos, sites de Internet,

entre outros.

18

Após a consolidação da fundamentação teórica para a realização do trabalho foi projetado o

protótipo da infra-estrutura para composição dinâmica e segura de Serviços Web. As

funcionalidades da infra-estrutura para composição dinâmica e segura de Serviços Web, os

requisitos funcionais, requisitos não funcionais e regras de negócio da infra-estrutura foram

definidos. Também foram elaborados diagramas de UML para modelar esta infra-estrutura e o

estudo de caso.

Após a modelagem, iniciou-se a etapa de desenvolvimento, onde foram implementadas parte

da infra-estrutura para composição dinâmica e segura de Serviços Web e o estudo de caso.

Finalizando, foram realizados alguns testes para comprovar a aplicabilidade da infra-estrutura

desenvolvida.

1.4 Estrutura do trabalho

O presente trabalho está estruturado em quatro capítulos, conforme descrito a seguir.

O Capítulo 1 apresentou os problemas existentes na criação de processos de negócio de alto

nível, principalmente, para prover segurança em tal ambiente. A partir da identificação dos

problemas a serem enfrentados foram identificados os objetivos do trabalho. Ainda neste capítulo

uma breve descrição da solução proposta e seu escopo foram apresentados, bem como a

metodologia utilizada no desenvolvimento da solução.

O Capítulo 2 apresenta uma revisão bibliográfica sobre a arquitetura orientada a serviços;

arquitetura dos Serviços Web, funcionalidades, benefícios e seus principais elementos;

posteriormente são apresentadas as principais formas de composição de Serviços Web,

aprofundando-se na orquestração de Serviços Web e na linguagem WS-BPEL. Os conceitos de

segurança em sistemas computacionais e os meios para prover segurança em Serviços Web e suas

principais especificações também são apresentados, já que estes são essenciais para fundamentação

teórica do trabalho a ser desenvolvido. Por fim, são apresentados alguns trabalhos relacionados que

visam prover segurança em Serviços Web compostos.

No Capítulo 3 é apresentado o projeto detalhado da infra-estrutura para composição

dinâmica e do estudo de caso (Agência de Viagens) que foram desenvolvidos, incluindo sua

especificação e a sua modelagem em UML (Unified Modeling Language). A implementação da

infra-estrutura para composição dinâmica e da Agência de Viagens, bem como as tecnologias e

19

técnicas utilizadas, também são descritas neste capítulo. Por fim, os resultados obtidos, os

problemas e dificuldades encontrados durante o desenvolvimento deste trabalho são analisados.

Finalizando, no Capítulo 4, são apresentadas as considerações finais, onde são abordadas as

dificuldades encontradas, as contribuições deste trabalho e as sugestões de trabalhos futuros.

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo será apresentada a arquitetura orientada a serviços e os seus principais

benefícios. Os Serviços Web e as suas especificações como WSDL (Web Services Description

Language), SOAP e UDDI (Universal Description, Discovery and Integration) serão apresentados

na Seção 2.2. Em seguida, serão apresentadas as formas de compor os Serviços Web de forma

estática e dinâmica, a fim de fornecer serviços mais complexos e com maior valor agregado,

visando solucionar problemas de alto nível de complexidade.

Ainda neste capítulo serão apresentados os conceitos de segurança e as especificações para

adicionar requisitos não funcionais aos Serviços Web. A análise de segurança em Serviços Web

está subdividida na segurança em arquivos XML e nas especificações WS-Security e WS-Policy. Por

fim, serão apresentados alguns trabalhos relacionados que tratam da segurança em Serviços Web

compostos.

2.1 Arquitetura Orientada a Serviços Conforme a OASIS (2006a), a Arquitetura Orientada a Serviços (Service Oriented Architecture

SOA) é um paradigma para organização e utilização de competências distribuídas que estão sob

controle de diferentes domínios proprietários. Segundo Papazoglou (2003), a arquitetura orientada a

serviços é uma caracterização de sistemas distribuídos, em que as funcionalidades do sistema são

expostas via descrição de uma interface, permitindo a publicação, localização e a invocação por

meio de um formato padronizado.

Segundo Weerawarana et al. (2005) e conforme ilustrado na Figura 1, são necessários três

passos para definir uma arquitetura orientada a serviço. Primeiro, é necessário prover uma definição

abstrata do serviço, a qual deve incluir os detalhes para que o serviço consiga ser invocado (bind) de

maneira correta. No segundo passo, os provedores de serviços precisam publicar (publish) os

detalhes do serviço para que quem for utilizar o serviço possa entender mais precisamente o que

este serviço faz e também para que este possa obter as informações necessárias para invocar

métodos deste serviço. No terceiro passo, os clientes, que precisam de um serviço, devem localizar

(find) os serviços que oferecem o que estão procurando. Para que estas atividades,

invocar/publicar/localizar (bind/publish/find), funcionem corretamente, padrões foram definidos

para gerenciar o que publicar, como localizar uma informação e como se deve especificar os

detalhes a respeito de como invocar o serviço.

21

Figura 1 - Interação entre as entidades da SOA.

Fonte: De Mello et al. (2006).

Os serviços estão baseados em trocas de mensagem entre os clientes e os provedores. Para

que estas trocas de mensagem ocorram, é necessário que as mensagens sigam um formato padrão, o

qual proporciona a neutralidade da tecnologia, propiciando que os clientes e provedores utilizem de

tecnologias diferentes para a implementação das camadas inferiores. Os serviços são definidos

como fracamente acoplados, indicando a transparência de localização (DE MELLO et al., 2006).

Segundo De Mello et al. (2006), o cliente precisa apenas conhecer a interface do serviço,

não sendo necessário conhecer a implementação interna do mesmo.

As interfaces dos serviços são auto-descritivas e baseadas em padrões abertos. Ou seja, a interface de um serviço define um conjunto de métodos públicos, juntamente com seus parâmetros, valores de retorno e meios para tratar possíveis exceções, porém não provê uma implementação. Com isto, pode-se assumir que a interface é um contrato entre o provedor do serviço e o cliente, sendo que o provedor deverá implementar todos os métodos ali descritos e o cliente só poderá invocar tais métodos (DE MELLO et al., 2006, p. 4).

Segundo OASIS (2006a), os principais benefícios da arquitetura baseada em serviços são

facilitar o gerenciamento dos sistemas corporativos de larga escala, facilitar o provisionamento e

uso de serviços na Internet e reduzir custos na cooperação entre as organizações. Esta arquitetura

oferece um paradigma escalável único para organizar grandes sistemas em redes, pois permite a

interoperabilidade entre os componentes individuais. Com SOA, torna-se mais fácil desenvolver

sistemas de larga escala, evolutivos e gerenciáveis.

22

Conforme De Mello et al. (2006), os serviços, por estarem muito vinculados às funções de

negócio, oferecem uma forma de modularidade diferente das oferecidas pelas linguagens de

programação como os módulos, objetos e componentes. Um serviço oferece uma função de negócio

completa, composta por vários componentes, enquanto os componentes representam uma entidade

ou regra de negócio. Os serviços podem ser reutilizáveis e empregados em novas transações, dentro

ou através da organização. Essa modularidade permite as organizações um gerenciamento melhor

de suas regras de negócio.

A arquitetura dos Serviços Web é baseada na arquitetura orientada a serviços e será descrita

em maiores detalhes na seção a seguir.

2.2 Serviços Web

Os Serviços Web (Web Services - WS) surgiram a partir de meados de 2000

(WEERAWARANA et al., 2005). Segundo a W3C (2004a), um Serviço Web é um componente de

software designado para suportar a interoperabilidade entre máquinas através de uma rede. Possui

uma interface descrita em um formato XML, chamada Web Services Description Language

(WSDL), capaz de ser processada por uma aplicação. Outros sistemas ou serviços interagem com

um Serviço Web utilizando mensagens SOAP1, geralmente usando HTTP (Hypertext Transfer

Protocol) e XML (eXtensible Markup Language) serializado, em conjunto com outros padrões web.

Conforme De Mello et al. (2006), os Serviços Web são classificados como um tipo

específico de serviço, sendo este identificado através de um identificador uniforme de recursos

(URI

Uniform Resource Identifier). Estes serviços são independentes de plataforma, de

linguagens de programação e arquitetura de máquina. Os Serviços Web utilizam padrões abertos e

bastante difundidos, tais como o XML e o HTTP. Estes padrões conseguem garantir a

interoperabilidade entre clientes e provedores de serviços, sem que os mesmos necessitem possuir o

conhecimento prévio de quais tecnologias estão presentes em cada lado. Esta facilidade de

comunicação é ideal para que relações de negócios entre empresas (B2B

Business to Business)

sejam estabelecidas de maneira simples e dinâmica. Segundo Coulouris, Dollimore e Kindberg

1 Em sua criação, SOAP era um acrônimo para Simple Object Access Protocol, porém na versão 1.2 tal definição foi descartada pelo W3C, por achar que a mesma era equivocada. Assim, hoje SOAP é simplesmente o nome do protocolo e não mais um acrônimo.

23

(2007), originalmente, o protocolo SOAP era utilizado apenas com o HTTP, porém na versão mais

atual do protocolo SOAP foram adicionados o suporte aos protocolos SMTP, TCP ou UDP.

Conforme Vogels (2003),é comum confundir os Serviços Web com objetos distribuídos

como o CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component

Object Model) e RMI (Remote Method Invocation). Para Vogels (2003), os Serviços Web são

tecnologias de sistemas distribuídos, os quais estão sendo utilizados em áreas nas quais aplicações

com objetos distribuídos falharam no passado.

Conforme De Mello et al. (2006), os Serviços Web e as tecnologias de objetos distribuídos

até possuem características em comum, porém os Serviços Web não são objetos distribuídos.

Ambos possuem uma linguagem para descrição de interfaces, a qual garante interações de rede bem

definidas, além de mecanismos semelhantes para registro e localização de objetos ou serviços.

Porém, Serviços Web não possuem o conceito de referência de objetos, o qual é essencial para os

sistemas de objetos distribuídos. Pelo conceito de referência de objetos é possível manter o estado

do objeto, o que não é possível nos Serviços Web.

Conforme De Mello et al. (2006), a principal diferença entre os Serviços Web e os objetos

distribuídos é o ciclo de vida. O ciclo de vida dos objetos distribuídos é composto pelas seguintes

fases:

diante de um pedido, uma fábrica cria uma instância de um objeto;

o cliente que requisitou o pedido, executa operações no objeto instanciado; e

em algum momento posterior, o cliente remove a instância do objeto.

Os Serviços Web não possuem um ciclo de vida com tais características: objetos, referências

e fábricas. Os Serviços Web não fornecem nenhuma facilidade para manter estado na computação

distribuída. Também não é possível com os Serviços Web definir relações entre as invocações

realizadas a um serviço ou a serviços relacionados (DE MELLO et al., 2006). Segundo Coulouris,

Dollimore e Kindberg (2007), como os Serviços Web não podem ser instanciados torna-se

desnecessário a coleta de lixo e a referência a objetos remotos.

Conforme Coulouris (2007), um Serviço Web é ativado pelo acesso a URL (Uniform

Resource Locator) no qual este se encontra. A URL é uma referência persistente permitindo que o

24

serviço esteja sempre disponível naquela URL enquanto o serviço ou servidor existir. Um Serviço

Web pode funcionar continuamente ou ser ativado sob demanda.

Ambientes como uma rede local são caracterizados pela homogeneidade de plataforma e por

possuírem um tempo de latência conhecido. Segundo Vogels (2003), tal tipo de ambiente é ideal

para a tecnologia de objetos distribuídos, visto que é uma tecnologia madura e, dentro de tal

ambiente, bem robusta. Em ambientes como a Internet, em que a interoperabilidade e o suporte para

plataformas e redes heterogêneas são essenciais, os Serviços Web demonstram ser os mais

adequados.

Segundo Coulouris, Dollimore e Kindberg (2007), para utilizar os Serviços Web, não se faz

necessário qualquer aplicativo adicional no servidor ou no cliente, basta que a linguagem de

programação dê suporte ao XML e ao HTTP. Estas características definem os Serviços Web como

auto-contidos e auto-descritivos, já que tanto cliente quanto servidor só precisam se preocupar com

o formato e com o conteúdo das mensagens. Nos servidores, pode-se aproveitar a estrutura

existente, utilizando os servidores web para gerenciar os Serviços Web.

Para Vogels (2003), os Serviços Web são compostos por quatro elementos:

serviço: é um componente de software capaz de processar um documento XML

recebido através de uma combinação de protocolos de transporte e de aplicação. O

serviço não está preocupado em como o componente está construído, quais técnicas

de orientação a objeto foram utilizadas, se é um processo standalone ou se é parte da

Web ou de um servidor de aplicação. O único requisito necessário para este

componente é o de ser capaz de processar documentos XML bem definidos;

documento XML: este documento é o componente chave para os Serviços Web,

porque contém todas as informações específicas da aplicação que o cliente enviou

para ser processada pelo Serviço Web;

endereço: combinação entre protocolo e endereço de rede que um cliente usa para

acessar o serviço; e

envelope: este componente é considerado opcional, porém este fornece um excelente

mecanismo para gerenciar as mensagens. O envelope pode encapsular a mensagem,

25

possibilitando que o documento XML que será processado fique separado das outras

informações enviadas na mensagem entre as aplicações.

Para descrever um Serviço Web, uma interface WSDL (Web Service Description Language)

(W3C, 2001; W3C, 2007a) deve ser criada. Uma vez criada a interface WSDL, o Serviço Web deve

ser publicado no diretório de registro de serviços, conforme ilustrado no passo 1 da Figura 2. Um

Serviço Web é publicado através de um registro UDDI (Universal Description, Discovery and

Integration) (OASIS, 2004a), o qual define uma forma padronizada para publicação e descoberta de

serviços dentro da arquitetura orientada a serviço (SOA).

Após o serviço ter sido publicado é possível acessá-lo. O cliente primeiramente pesquisa o

Serviço Web que deseja acessar no diretório UDDI, (ver passo 2); é neste diretório que ficam

armazenados todos os serviços publicados, sendo que os registros UDDI são identificados de forma

única. O retorno desta consulta é a WSDL do serviço, conforme passo 3 da Figura 2. De posse da

WSDL do serviço, o cliente consegue invocar as operações desejadas, conforme o passo 4.

Figura 2 - Colaboração típica na Arquitetura dos Serviços Web.

Fonte: De Mello et al. (2006).

Uma descrição mais detalhada da linguagem WSDL, do protocolo SOAP e do UDDI será

apresentada nas seções a seguir.

2.2.1 WSDL

Segundo Weerawarana et al. (2005), a primeira versão da WSDL (Web Services Description

Language) foi lançada em setembro de 2000, a qual era uma combinação de duas linguagens de

descrição, a NASSL (Network Application Service Specification Language) da IBM e a SDL

(Service Description Language) da Microsoft. Posteriormente, a WSDL foi submetida a W3C para

padronização e a versão 1.1 foi publicada em 2001 (W3C, 2001). Atualmente, a W3C já finalizou a

26

versão 2.0 da WSDL (W3C, 2007a), que tornam esta linguagem menos expressiva, contudo mais

fácil de ser utilizada. A versão da WSDL abordada neste trabalho é a versão 1.1, que é o padrão de

fato, amplamente suportado pelas mais diversas ferramentas de desenvolvimento de Serviços Web.

Conforme W3C (2001), a WSDL é uma gramática em XML, extensível, utilizada para

especificar as interfaces de Serviços Web, ou seja, como acessar o serviço. A interface WSDL é

independente de linguagem, plataforma e arquitetura de máquina, pois o mesmo é um documento

XML. A WSDL é utilizada para descrever os Serviços Web; possui todas as operações disponíveis,

o formato da mensagem a ser enviada para o serviço e qual será o retorno para o consumidor do

serviço. Os tipos de dados estão especificados junto ao formato das mensagens. A WSDL necessita

de um poderoso sistema para descrever o formato das mensagens, suportando o XML Schemas

(W3C, 2004b), como sistema padrão.

Segundo a W3C (2001), o elemento é o elemento raiz de um documento

WSDL, este elemento pode ser dividido logicamente em duas partes, conforme a Figura 3:

abstrata: descreve as mensagens trocadas entre o Serviço Web e os clientes, sendo

que as mensagens são descritas independentemente dos formatos; e

concreta: vincula uma mensagem com um protocolo de transporte e os detalhes de

formato.

Figura 3 - Estrutura de um documento WSDL

Fonte: Weerawarana et al. (2005).

27

Uma WSDL é composta pelos seguintes elementos (W3C, 2001):

portType: define, de forma abstrata, as operações e o que cada operação requer, com

suas entradas e saídas para uma determinada mensagem;

o operation: define, abstratamente, uma operação suportada pelo serviço.

Seguem um desses padrões:

one-way: o serviço recebe uma mensagem do cliente, porém o serviço

não produz nenhuma resposta;

request-response: o serviço recebe uma mensagem do cliente e

produz uma mensagem de resposta;

solicit-response: o serviço envia uma mensagem e obtém uma

mensagem de resposta; e

notification: o serviço envia uma mensagem para o cliente e não

recebe nenhuma resposta.

message: define, de forma abstrata, as mensagens que serão trocadas. A mensagem

consiste de partes lógicas, cada uma associada com a definição dos tipos;

types: provê a definição dos tipos de dados, utilizando XML Schemas (XSD), ou

algum outro sistema de definição de tipos, utilizados nas trocas de mensagens;

binding: especifica concretamente o protocolo e o formato dos dados para as

operações e mensagens definidas em um portType particular;

service: declara o endereço das portas para os binding. Ou seja, indica onde

encontrar um serviço usando sua porta; e

o port: especifica uma combinação entre o endereço e o binding, definindo um

endereço único para acessar o serviço.

28

2.2.2 SOAP

Segundo Weerawarana et al. (2005), o protocolo SOAP foi projetado para permitir

interações assíncronas entre cliente e servidor. O SOAP define um esquema XML para representar

as requisições e respostas. Originalmente, era baseado apenas no protocolo HTTP, mas na versão

1.2 foi adicionado o suporte aos protocolos SMTP, TCP ou UDP. Segundo Coulouris, Dollimore e

Kindberg (2007), o protocolo SOAP é uma extensão do XML-RPC da Userland.

Segundo De Mello et al. (2006), a utilização do SOAP sobre o protocolo HTTP se tornou

comum nas implementações de Serviços Web, devido as facilidades proporcionadas pelo HTTP.

Destacam-se: a infra-estrutura já existente dos servidores HTTP e a facilidade em atravessar os

limites de segurança impostos pelos firewalls.

Segundo Coulouris, Dollimore e Kindberg (2007), a especificação do protocolo SOAP

declara:

como o XML deve ser utilizado para representar o conteúdo de mensagens individuais;

como duas mensagens podem ser combinadas a fim de formar um padrão de requisição e

resposta;

define regras de como os destinatários das mensagens devem processar os elementos

XML; e

como os protocolos HTTP e SMTP devem ser usados para comunicar mensagens SOAP.

Conforme De Mello et al. (2006), e como apresenta a Figura 4, a mensagem SOAP é um

documento XML que define um envelope, o qual é o elemento raiz do documento. O envelope

SOAP contém as declarações dos espaços de nome a serem utilizados. O envelope pode ser

composto pelo header (opcional) e pelo body (obrigatório).

29

Figura 4 - Mensagem SOAP.

Fonte: Cerami (2002).

O elemento header é opcional e contém informações de como a mensagem deve ser

processada, definições de roteamento das mensagens, asserções de autenticação e autorização, entre

outras. O elemento header geralmente é utilizado pelos nós intermediários. Por sua vez, o elemento

body é obrigatório e contém a mensagem como um todo. Este elemento pode ser composto por

qualquer tipo de informação representável em XML. O elemento body ainda pode conter um

elemento fault para transportar informações sobre as mensagens de erro que possam ocorrer durante

o processamento da mensagem (DE MELLO et al., 2006).

Segundo Coulouris, Dollimore e Kindberg (2007), as mensagens SOAP são independentes

do tipo de transporte utilizado, pois o envelope não possui nenhuma referência ao endereço de

destino. Além disso, a especificação também define um conjunto de regras para o processamento de

mensagens SOAP por serviços, ou nós intermediários, os quais uma mensagem SOAP passa antes

de ser processada pelo destinatário final, conforme ilustrado na Figura 5. O atributo papel é

utilizado para especificar se todos os nós intermediários, nenhum destes ou se apenas o destinatário

final deve processar o elemento.

Figura 5 - Processamento Multi-Ponto de uma Mensagem SOAP

Fonte: Weerawarana et al. (2005).

30

2.2.3 UDDI

Conforme definido em OASIS (2004a), os Serviços Web são mais significantes apenas se os

potenciais clientes conseguem localizar as informações necessárias para executar o serviço. UDDI é

a definição de um conjunto de serviços, os quais suportam a descrição e descoberta de negócios,

organizações e outros provedores de Serviços Web, disponibilizando os Serviços Web e suas

interfaces, possibilitando assim o acesso a estes serviços. UDDI é baseado em um conjunto de

padrões como: HTTP, XML, XML Schema e SOAP e fornece interoperabilidade e a arquitetura

fundamental para softwares baseados em Serviços Web. Os dados e metadados dos Serviços Web

são armazenados em diretórios UDDI (UDDI registry), associando a cada estrutura de dados, um

identificador único, denominado UDDI key, criado de acordo com regras de classificação

especificadas por cada organização. Tal classificação permite aos consumidores realizarem

consultas mais refinadas, permitindo, por exemplo, buscar por provedores que forneçam

determinado serviço dentro de uma localização geográfica específica.

Conforme OASIS (2004a), os dados são armazenados no diretório UDDI em quatro

estruturas:

businessEntity: descreve uma organização provedora de serviços Web. Contêm informações

não-técnicas, como nomes, informações para contato e informação de classificação;

businessServices: descreve um conjunto de serviços Web relacionados, oferecidos pela

mesma organização;

bingingTemplate: contém o endereço de uma instância do Serviço Web e referência para a

descrição técnica do serviço; e

tModel: descreve um modelo técnico que representam um conceito reutilizável, tais como

tipo do Serviço Web, ou um protocolo utilizado pelos Serviços Web.

A especificação UDDI fornece uma API para pesquisar serviços com base em dois

conjuntos de operações de consulta (WEERAWARANA et al., 2005):

conjunto de operações que recuperam uma entidade a partir de uma chave correspondente

(get_BusinessDetail,get_ServiceDetail, get_bindingDetail e get_tModelDetail); e

31

conjunto de operações que recuperam as entidades que correspondem a um conjunto de

critérios (find_business, find_service, find_binding e find_tModel).

2.3 Composição de Serviços Web

Segundo Weerawarana et al. (2005), embora diversas metodologias de composição de

componentes de software e mesmo de processos de negócio já tenham sido elaborados ao longo dos

anos e o assunto seja relativamente bem compreendido e estudado, a composição de Serviços Web

exige uma nova abordagem que possibilite um fraco acoplamento, mudanças freqüentes, alta

disponibilidade, qualidade de serviço, etc. Neste ambiente, muitos requisitos são identificados para

o modelo de composição (WEERAWARANA et al., 2005 apud CARPES, 2008, p.16):

a) integração flexível: o modelo de composição precisa ser rico suficiente para modelar cenários

de negócios no qual é possível integrar diversos parceiros de forma flexível. Porém, o mais

importante é fornecer uma maneira que permita a rápida adaptação deste processo de negócio;

b) composição recursiva: a fim de prover escalabilidade e o reuso da lógica de negócio é

fundamental tornar o processo de negócio passível de composição. Portanto, é necessário

disponibilizar o processo de negócio como um Serviço Web padrão, ou seja, disponibilizar a sua

interface WSDL, possibilitando que este possa ser agregado em outras composições e assim

sucessivamente;

c) separação dos conceitos ortogonais: em um framework para composição de Serviços Web, a

lógica dos processos de negócio precisa ser desacoplada dos mecanismos de suporte, como a

infra-estrutura de segurança, de qualidade de serviço e de coordenação de transações. Os

detalhes destes aspectos ortogonais à composição devem ser anexados de forma transparente em

diferentes partes da definição do processo, por meio de mecanismos como a WS-Policy (W3C,

2007b);

d) modelo de ciclo de vida baseado em conversações longas: em um processo de negócio deve

existir uma definição clara do gerenciamento do ciclo de vida, a qual deve gerenciar múltiplas

conversações longas com os serviços que este está interagindo; e

e) recuperabilidade: processos de negócio, especialmente os de longa duração, precisam prover

mecanismos para captura e tratamento de falhas quando erros ocorrerem durante a execução do

processo.

32

Uma das principais características dos Serviços Web é a facilidade de composição,

tornando-os uma tecnologia interessante. Conforme Charfi e Mezini (2005), a composição de

Serviços Web visa combinar serviços de diferentes provedores a fim de criar um Serviço Web mais

sofisticado e com maior valor agregado. Segundo Milanovic e Malek (2004), desenvolvedores e

usuários podem solucionar problemas complexos a partir da combinação de serviços básicos, em

uma ordem conveniente à solução do problema. A composição de serviços acelera o

desenvolvimento de aplicações e permite a reutilização de serviços, diminuindo tempo e custo para

o desenvolvimento de processos de negócio (MILANOVIC & MALEK, 2004).

Conforme Peltz (2003), existem duas formas de composição de processos de negócios a

partir dos Serviços Web, a orquestração e a coreografia. A orquestração apresenta um processo de

negócios executável, permitindo invocar vários Serviços Web em uma determinada seqüência

lógica para atingir um determinado resultado. Já a coreografia apresenta uma forma mais

colaborativa e que permite que cada parte envolvida descreva sua participação através das

interações. Na Figura 6, tem-se uma representação gráfica da orquestração e da coreografia.

Figura 6 - Composição de Serviços Web.

Fonte: Peltz (2003).

A orquestração de Serviços Web cria um novo serviço através da composição de dois ou

mais Serviços Web ou até mesmo de outras orquestrações. Os serviços que fazem parte de uma

orquestração podem ser serviços internos ou externos à organização. O serviço resultante de uma

orquestração é conhecido como serviço orquestrado, o qual deve ser executado em um motor de

orquestração (PELTZ, 2003).

33

Segundo Juric (2006), a coreografia não possui um coordenador central. Cada Serviço Web

presente em uma coreografia sabe exatamente quando executar a operação e quem pode interagir

com este. A coreografia é um esforço colaborativo focado nas trocas de mensagens em um processo

de negócio público. Diferentemente da orquestração em que os participantes não precisam saber que

estão fazendo parte de uma orquestração, na coreografia todos os participantes devem estar cientes

do processo de negócio, das operações que executam, das trocas de mensagens e do tempo em que

as trocas de mensagem devem acontecer.

Ao longo dos anos foram desenvolvidas algumas linguagens para representar as

composições de Serviços web. Segundo Milanovic e Malek (2004), fazem parte da primeira geração

de linguagens de composição, a IBM s Web Service Flow Language (WSFL), desenvolvida pela

IBM, e a Web Services Choreography Interface (WSCI), desenvolvida pela BEA Systems. A

segunda geração de linguagem de composição trouxe a linguagem BPEL4WS, ou simplesmente

BPEL, a qual combina as especificações WSCI e WSFL com a especificação XLANG da

Microsoft. A linguagem BPEL4WS foi padronizada pela OASIS e atualmente é conhecida como

WS-BPEL, a qual se encontra na revisão 2.0 (OASIS, 2007).

Neste trabalho, a orquestração de Serviços Web é utilizada para realizar a composição de

processos de negócios executáveis e a WS-BPEL é a linguagem utilizada para descrever os serviços

orquestrados. Uma descrição mais detalhada sobre orquestração de Serviços Web e sobre a

linguagem WS-BPEL será apresentada nas seções a seguir.

2.3.1 Orquestração de Serviços Web

A orquestração é a forma mais simples de composição e a mais bem estudada. Na

orquestração, o controle sobre a composição é realizado pelo ponto de vista de apenas uma parte

envolvida (PELTZ, 2003). As outras partes podem nem sequer sabem que estão participando de

uma composição. O controlador da composição (motor de orquestração) realiza as invocações aos

provedores de serviços e é visto por estes como um cliente qualquer.

Conforme Papazoglou et al. (2006), a orquestração descreve como os serviços interagem

uns com os outros no nível de mensagem, incluindo a lógica de negócio e a ordem de execução das

interações sobre a perspectiva e o controle de um simples endpoint.

34

Conforme consta em Peltz (2003), a orquestração de Serviços Web deve ser dinâmica,

flexível e adaptável para permitir realizar facilmente as mudanças necessárias no processo de

negócio. A separação entre a lógica do processo e os Serviços Web promove esta flexibilidade. Os

projetistas de processos podem compor serviços de alto nível a partir dos processos orquestrados

existentes, bastando expor estes processos através de suas próprias interfaces, ou seja, permitindo a

recursividade em Serviços Web.

2.3.2 WS-BPEL

Conforme Charfi e Menzine (2005), o padrão mais popular e de grande aceitação na

academia e na indústria é a linguagem para execução de processos de negócios de Serviços Web

(WS-BPEL - Web Services Business Process Execution Language) (OASIS, 2007).

A primeira versão da especificação foi publicada em 2002, sendo chamada de BPEL4WS.

Em 2003, foi lançada a versão 1.1 (ANDREWS et al., 2003), a qual posteriormente foi submetida à

OASIS para padronização. Em maio de 2007, a OASIS lançou a especificação do WS-BPEL 2.0

(OASIS, 2007).

A WS-BPEL define o conjunto de atividades participantes da orquestração, especificando

padrões de fluxo de controle e de dados. O resultado de uma composição é sempre uma nova

WSDL, formando desta forma um Serviço Web composto. A WS-BPEL define os pontos de acesso

ao serviço e também define papéis e as interações entre estes papéis. Os papéis podem ser utilizados

como mecanismo de controle de acesso a certos serviços. A WS-BPEL provê suporte aos diversos

gêneros de fluxos (seqüencial, paralelo, condicional, entre outros), os quais permitem a construção

de um processo de negócio, além de fornecer facilidades para o tratamento robusto de exceções,

suporte para transações e conversações de longa duração (OASIS, 2007).

A especificação de um processo WS-BPEL é divida em duas partes: uma parte declara os

serviços envolvidos, as variáveis, tratadores de falhas, tratadores de eventos e outros recursos a

serem usados no contexto do processo; a outra parte declara o workflow por meio de atividades

(OASIS, 2007).

Segundo Weerawarana et al. (2005), na especificação WS-BPEL os processos podem ser

abstratos ou executáveis. Um processo abstrato é utilizado para descrever os padrões observáveis

de troca de mensagem, permitindo fornecer uma visão para os parceiros de negócio sem precisar

35

expor a lógica interna do processo de negócio. Para um parceiro de negócio saber como interagir

com o processo de negócio, basta expor o processo abstrato. Pode-se dizer que um processo abstrato

é uma projeção de um processo executável. Segundo Juric (2006), um processo executável

específica os detalhes exatos do processo de negócio e pode ser executado por um motor BPEL.

Sendo uma linguagem de workflow, no cerne da WS-BPEL, estão as atividades e os fluxos

que as interconectam. As atividades são classificadas em básicas e estruturadas. As atividades

básicas envolvem, de um modo geral, a interação com serviços externos ao processo em si, ou a

manipulação de variáveis do processo. Conforme OASIS (2007), estas são as atividades básicas:

assign: atribui o valor a uma variável;

throw: usada quando um processo precisa informar um erro;

wait: serve para especificar um tempo de espera;

empty: a atividade não faz nada;

extensionActivity: permite especificar novas atividades que não estão na

especificação;

exit: usada para encerrar imediatamente o processo; e

rethrow: utilizada para retornar um erro.

Conforme a OASIS (2007), as atividades estruturadas estabelecem um ordenamento para as

atividades nelas aninhadas, ou seja, são estas que efetivamente gerenciam o fluxo global de um

dado processo. As atividades estruturadas são as seguintes:

sequence: irá executar as atividades seqüencialmente;

if: permite a escolha de opções conforme uma condição;

while: executa uma atividade enquanto uma condição for verdadeira;

repeatUntil: repete as operações enquanto a condição for verdadeira;

36

forEach: irá executar o que estiver dentro de escopo até que a condição final seja

atendida;

pick: cada atividade está associada a um evento; quando o evento ocorre, a atividade

é executada; e

flow: agrupa atividades a serem executadas paralelamente.

Existem ainda as atividades que realizam as trocas de mensagem entre os serviços

participantes da orquestração. Entre estas atividades estão: invoke (invoca um serviço externo),

receive (recebe o pedido de um cliente do Serviço) e reply (retorna os dados para o cliente).

Processos BPEL podem ser executados em qualquer motor de orquestração que esteja em

conformidade com o padrão WS-BPEL. O motor orquestra as invocações dos serviços Web

parceiros, de acordo com a especificação do processo (OASIS, 2007).

Segundo Weerawarana et al. (2005), é possível criar um controle de fluxo a partir da

combinação de atividades estruturadas com pontos de sincronização. Apenas dentro da atividade

é possível definir pontos de sincronização na execução das atividades. Para tanto, dentro de

uma atividade deve ser estabelecidos diversos links, que servirão para conectar atividades

ordenadas entre si. As atividades aninhadas num podem ser definidas como a origem ou

destino de vários links. Adicionalmente, pode-se estabelecer condições de transição (junto às

origens), ou de união (junto aos destinos de mais de um link).

Outros conceitos importantes para a BPEL são as variables e os partnerLinks. Conforme

Juric (2006), as variáveis especificam as informações trocadas nos fluxos de mensagens entre o

processo e seus parceiros, ou ainda as informações manipuladas internamente pelo próprio

processo. É através da manipulação das variáveis que o processo mantém o estado entre as várias

requisições do processo de negócio, efetua a persistência de dados entre as diversas requisições de

serviços participantes da execução de um processo BPEL. Por outro lado, os partnerLinks servem

exatamente para definir as relações de parceria entre o processo BPEL e os diversos Serviços Web.

Cada partnerLink possui um nome e um partnerLinkType. Este descreve a relação entre dois

Serviços Web por meio da definição dos papéis de cada serviço envolvido na relação, cada papel

sendo associado a um portType complementar. A definição de um partnerLinkType pode estar

dentro da WSDL do Serviço Web que provê as operações usadas.

37

Segundo Weerawarana et al. (2005), todo processo tem uma atividade inicial e uma

atividade final explícitas. Cada processo BPEL pode ser instanciado inúmeras vezes, sendo que

cada instância mantêm o estado particular de sua execução com valores particulares para suas

variáveis de estado. Uma atividade é capaz de criar uma instância, ou seja, iniciar a execução de um

processo quando possui o atributo createInstance assinalado. Logo, uma instância pode ser criada

quando um cliente executa uma atividade assinalada para criar uma instância. A Figura 7 apresenta

um esquema de um processo, o qual utiliza-se de vários elementos BPEL. Na Figura 7, passo 1, o

processo de negócio será iniciado quando o cliente invocar o portType do processo

(createInstance). A partir deste momento, o processo irá gerenciar o fluxo de negócio e o controle

de dados e também interagir com outros Serviços Web, através das atividades ,

e , conforme ilustrado na Figura 7, passo 2. Toda interação entre o processo de negócio e

um Serviço Web é realizada através de um portType (do lado do processo de negócio) e um

partnerLink (do lado do Serviço Web) (passo 3, Figura 7). Por fim, o processo enviará uma resposta

para o cliente (passo 4).

Figura 7 - Processo definido através da WS-BPEL

Fonte: Juric (2006).

Visando garantir a robustez da BPEL frente a erros ou a transações mal sucedidas, existem

construções específicas para tratar os erros ocorridos durante a execução do processo BPEL. Para

tanto, adota-se o conceito de escopo como sendo um contexto em que uma ou todas as atividades

são executadas com sucesso, ou fracassam e devem ser compensadas nas partes em que foram bem

38

sucedidas. Assim, para cada escopo deve-se adicionar tratadores de exceções e/ou um compensador

para os escopos aninhados. Um escopo de um tratador de exceção é iniciado no momento em que a

primeira exceção ocorre, a partir deste momento este é quem executa as atividades de compensação

(WEERAWARANA et al., 2005).

Conforme Weerawarana et al. (2005), este recurso é fundamental porque em muitos

processos de negócio não é possível completar todos os trabalhos necessários com apenas uma

transação atômica simples. Em transações de longa duração, comuns em diversos cenários nos quais

são utilizados os Serviços Web, utilizar apenas uma transação atômica implicaria em restrições

extremas de concorrência de acesso aos recursos utilizados por estes serviços. De modo que, caso a

transação não seja bem sucedida, o equivalente ao rollback das transações atômicas é obtido através

da compensação das atividades bem sucedidas já realizadas.

Segundo Charfi e Menzine (2005), a linguagem BPEL não possui recursos para expressar as

capacidades e requisitos de segurança do processo ou de uma atividade. Isto não se caracteriza

como uma limitação da especificação BPEL uma vez que os requisitos não funcionais podem ser

adicionados por outras especificações, possibilitando uma melhor separação de responsabilidades e

permitindo uma composição mais modular. A capacidade de especificar requisitos de segurança na

linguagem BPEL tornaria esta linguagem muito complexa e de difícil aprendizagem.

2.4 Composição Dinâmica de Serviços Web

A composição dinâmica de serviços apresenta desafios interessantes, já que a localização,

seleção e composição de serviços existentes, para satisfazer necessidades específicas de um novo

serviço composto, requerem mecanismos sofisticados de descrição, sincronização, coordenação e

monitoramento (KELLER, 2002). A composição dinâmica de Serviços Web visa ligar,

automaticamente, diferentes serviços para atingir um objetivo complexo, tendo como base,

normalmente, dados semânticos adicionais que descrevem os Serviços Web e que podem ser usados

para geração dinâmica do processo de negócios (BERNERS-LEE, HENDLER & LASSILA, 2001)

e que podem ser usados para geração dinâmica da seqüência de orquestração (WU et al., 2003).

Atualmente, o uso da Web semântica na composição de Serviços Web é um tópico de

pesquisa muito relevante devido ao seu potencial em alcançar uma integração de aplicações que seja

dinâmica, escalável e com custo efetivo (ECOLEAD, 2005; WU et al., 2003). Com a Web

semântica, processos podem fazer interpretações sobre os recursos disponíveis no ambiente de

39

forma não ambígua. Tais interpretações são possíveis através do emprego de linguagens de

descrições e técnicas de inferências baseadas em ontologias.

Durante a fase de identificação dos parceiros que irão contribuir com o processo de

negócios, o papel dos localizadores de serviços é designar um Serviço Web apropriado para cada

atividade. Segundo Carminati, Ferrari e Hung (2005), para que este processo de seleção seja

dinâmico, além de explorar os registros UDDI, este pode ser executado por meio de descritores

semânticos de Serviços Web, como por exemplo, a linguagem OWL (Web Ontology language) que

fornece competências para anotar dados semânticos aos Serviços Web.

Uma tese de mestrado realizada na Universidade Federal do Rio de Janeiro, propõe uma

ferramenta para composição dinâmica de processos de negócio, chamada WebComposer (COSTA,

PIRES & MATTOSO, 2004). Esta ferramenta tem por objetivo compor dinamicamente processos

BPEL e executá-los. Neste trabalho foi utilizada a linguagem OWL-S para descrever os dados

semânticos dos serviços. O WebComposer realiza inferência sobre as ontologias dos serviços para

selecionar os participantes que irão compor o processo BPEL.

2.4.1 OWL-S

Conforme Martin et al. (2004), OWL (Web Ontology language) é uma linguagem para

definição e instanciação de ontologias Web. Foi desenvolvida baseando-se nas linguagens DAML

(DARPA Agent Markup Language) e OIL (Ontology Inference Layer) e construída em cima da

arquitetura XML e RDF. A OWL foi proposta como padrão pelo W3C, agregando diversos pontos

positivos das linguagens anteriores, sendo muito utilizada pela Web Semântica.

Com base na OWL, um grupo de pesquisa composto por pesquisadores de diversas

organizações propôs a OWL-S, originalmente chamada de DAML-S. Esta linguagem é uma

recomendação da W3C e se encontra na sua versão 1.1. OWL-S é uma gramática XML que visa

automatizar algumas tarefas no ambiente dos Serviços Web, como a descoberta automática de

Serviços Web, execução, composição e monitoração de execução. OWL-S é uma linguagem de

ontologia que possibilita especificar dados semânticos nas entradas, nas saídas, nos parâmetros, nas

pré-condições e nos resultados dos Serviços Web (MARTIN et al., 2004).

A especificação OWL-S suporta serviços simples e serviços complexos (compostos),

contudo foram os serviços complexos que motivaram a maior parte dos elementos da ontologia. A

40

seguir é apresentada uma visão geral das tarefas que a linguagem OWL-S possibilita (MARTIN et

al., 2004):

a. descoberta automática de Serviços Web: é um processo automático para localizar os

Serviços Web que provêem uma capacidade particular, a partir de informações do cliente;

b. invocação automática de Serviços Web: permite a invocação automática de um Serviço

Web por um programa computacional ou agente, simplesmente a partir de informações

declarativas do serviço, não sendo necessário pré-estabelecer um serviço; e

c. composição e interoperação automática de Serviços Web: envolve a seleção automática,

composição e interoperação entre os Serviços Web com o objetivo de solucionar tarefas

complexas, a partir de descrições de alto nível do objetivo.

A estrutura da linguagem OWL-S é motivada pela necessidade de prover três tipos essenciais

de conhecimento a respeito dos serviços, cada qual caracterizado por uma pergunta e sua respectiva

resposta (MARTIN et al., 2004):

a. O que o serviço fornece para um cliente potencial?

utilizado para anunciar um serviço

através de um profile; representado pela classe ServiceProfile. Esta classe possui atributos

para descrever o serviço, especificar o nome do serviço, além de atributos atrelados a

execução do serviço, tais como: parâmetros, entradas, saídas, pré-condições e resultados;

b. Como o serviço é utilizado?

expõe meios detalhados de como um cliente consegue

interagir com o serviço, pode ser visto como um processo. Tais informações são

representadas pela classe ServiceModel. Se tratando de um serviço complexo são utilizadas

estruturas de controle para decompor em outros serviços, como: sequence, if-then-else,

repeat-until, repeat-while, etc; e

c. Como alguém interage com o serviço?

através do grouping. Grouping apresenta os

detalhes necessários sobre os protocolos de transporte, formatos das mensagens, serialização

e endereçamento. É representado pela classe ServiceGrouping. Esta classe provê atributos

para especificar a versão da WSDL utilizada, a URI da WSDL que está sendo representada

por este grouping, a operação, bem como informações de entrada e de saída da operação.

41

Cada instância da classe Service, é apresentada por um ServiceProfile, o qual é descrito por

um ServiceModel e suportado por um ServiceGrouping. Cada uma destas três perspectivas provêm

as informações essenciais a respeito de um serviço (MARTIN et al., 2004).

A especificação OWL-S deve ser utilizada em conjunto com a especificação WSDL. Na

interface OWL, deve-se utilizar a classe ServiceGrouping para fazer o vínculo com a interface

WSDL, especificando os seus atributos. Já na WSDL, devem ser utilizados os seguintes atributos:

owl-s-parameter representa o nome do objeto de entrada ou saída no documento OWL-S; o atributo

encodingStyle é utilizado no elemento binding da WSDL quando a mensagem utiliza tipos OWL; e

owl-s-process é utilizado para especificar o nome do processo OWL (MARTIN et al., 2004).

2.5 Conceitos de Segurança em Sistemas Computacionais

O conceito de segurança em um sistema computacional é identificado como a capacidade de

assegurar a prevenção ao acesso e à manipulação ilegítima das informações, ou ainda, de evitar a

interferência indevida na sua operação normal (ISO/IEC, 1999).

Segundo Stallings (2005), a segurança de informação tem sofrido duas importantes

mudanças nas últimas décadas. Antes do uso extensivo de equipamentos de processamento a

segurança das informações era feita por meios físicos e administrativos. Com a introdução do

computador, surgiu a necessidade de ferramentas automatizadas para proteger as informações,

especialmente para sistema