Alta disponibilidade em arquiteturas SOA : uma análise de aplicações críticas através de seus atributos de qualidade de serviços

PAULO HENRIQUE GOMES DA CRUZ JÚNIOR

A

A

D

D

A

A

SO

S

OA

A:

:

U

U

A

A

C

C

A

A

Q

Q

S

S

Dissertação apresentada ao programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e da Tecnologia da informação da Universidade Católica de Brasília como requisito parcial para obtenção do Título de Mestre.

Orientador: Prof. Dr. Hércules Antonio do Prado

Co-orientador: Prof. Dr. Eduardo A. D. Moresi

C955a Cruz Júnior, Paulo Henrique Gomes da

Alta disponibilidade em arquiteturas SOA: uma análise de aplicações críticas através de seus atributos de qualidade de serviços. / Paulo Henrique Gomes da Cruz Júnior – 2008.

161f. : il.; 30 cm

Dissertação (mestrado) – Universidade Católica de Brasília, 2008. Orientação: Hércules Antonio do Prado

Co-Orientação: Eduardo A. D. Moresi

1. Gestão do conhecimento. 2. Arquitetura de computador. 3. Organização. I. Prado, Hércules Antonio do, orient. II. Moresi, Eduardo A. D. co-orient. III. Título.

TERMO DE APROVAÇÃO

PAULO HENRIQUE GOMES DA CRUZ JÚNIOR

ALTA DISPONIBILIDADE EM ARQUITETURAS SOA: UMA

ANÁLISE DE APLICAÇÕES CRÍTICAS ATRAVÉS DE SEUS

ATRIBUTOS DE QUALIDADE DE SERVIÇOS.

Dissertação de autoria de Paulo Henrique Gomes da Cruz Júnior, intitulada “ALTA DISPONIBILIDADE EM ARQUITETURAS SOA: UMA ANÁLISE DE APLICAÇÕES CRÍTICAS ATRAVÉS DE SEUS ATRIBUTOS DE QUALIDADE DE SERVIÇOS” apresentada como requisito parcial para obtenção do grau de Mestre no Programa de Pós-Graduação stricto sensu em Gestão do Conhecimento e da Tecnologia da Informação da Universidade Católica de Brasília, em 08 de dezembro de 2008, defendida e aprovada pela banca examinadora abaixo assinada:

_____________________________________________________________ Prof. Dr. Hércules Antonio do Prado

Orientador MGCTI – UCB

_____________________________________________________________ Prof. Dr. Eduardo A. D. Moresi

Co-orientador MGCTI – UCB

_____________________________________________________________ Prof. Dr. Aluízio Haendchen Filho

UNIASSEVI - FAMESUL

Dedicatório

Dedico este trabalho a minha família:

Minha mãe pelo exemplo de vida e dedicação, Meu Pai pela formação moral e valores, Minha irmã pelo carinho,

Minha esposa e aos meus filhos por me amarem como eu sou,

AGRADECIMENTO

A Deus, pela saúde, força de vontade e oportunidade de enriquecimento humano por meio deste trabalho.

À minha família, em especial a minha esposa, por todo o apoio, confiança, amor, paciência, compreensão e afeto incondicionais, muito obrigado.

Aos meus professores ao longo de minha vida, desde a “Tia Angélica”, minha primeira professora, minha Querida “Dinda”, a qual tenho uma dívida eterna, ao meu Tio Tadeu, com seu saber sempre um degrau acima da minha compreensão. Aos professores da UCB-MGCTI em especial aos meus orientadores e tutores Prof. Dr. Hércules Prado e Prof. Dr. Eduardo Moresi por dedicarem seu tempo, capacidade e competência à execução deste trabalho. Ao meu amigo Wagner (Tuba) pela amizade, colaboração e companheirismo durante todo o curso.

Aos meus amigos Prof. Dr. Rildo Ribeiro, Helder Garcia, Alessandro Quesada, Rodrigo Evangelista e Marcelo Marinho pelas sugestões e paciência em me ouvir nas discussões sobre os modelos de disponibilidade e suas métricas.

Ao meu cunhado Ricardo (Rick) pela boa vontade e paciência em ajudar.

Aos meus primos Paulo César e Cristine pelas discussões, dicas e direcionamentos para melhoria deste trabalho.

Aos demais professores e colegas do MGCTI, pela sempre proveitosa troca de idéias e debates.

Resumo

O desenvolvimento de aplicações fundamentado em arquiteturas orientadas a serviços (SOA) tem se mostrado como uma das principais iniciativas para que as organizações obtenham a agilidade necessária na área de TI. Um projeto fundamentado em arquitetura SOA envolve o uso de informações incompletas quando se utiliza serviços web e aplicações do legado. Este fato pode levar a sérios problemas de execução de aplicações críticas, decorrentes, por exemplo, da indisponibilidade de alguns destes serviços quando solicitados. Na implantação de aplicações críticas baseadas em SOA enfrenta-se um grande desafio relativo à medição da qualidade, maturidade e disponibilidade dos serviços que integram estas aplicações. Métricas de qualidade de serviços têm sido utilizadas para suportar ações de governança em TI com base na qualidade dos mesmos. Como, hoje, as aplicações são parte integrante das principais linhas de negócio das empresas, torna-se necessário um maior formalismo tanto no processo de medição como na tomada de decisões em relação à disponibilidade de aplicativos críticos ao negócio. É comum um aplicativo pertencente ao legado e em produção apresentar um alto grau de confiabilidade e disponibilidade devido a um processo contínuo de utilização e redução de falhas. Por outro lado, devido a informações incompletas de ambiente de execução não se pode garantir que aplicações recentemente construídas a partir de serviços extraídos do legado herdem o mesmo grau de disponibilidade e confiabilidade deste. O gerenciamento de aplicações críticas requer um estudo profundo de sua disponibilidade e confiabilidade, desta forma, foi analisada a inclusão de uma camada de extensão ao framework tradicional de SOA visando fornecer estas características. O presente trabalho apresenta um método para medição da qualidade e disponibilidade de serviços pertencentes a uma aplicação considerada crítica. As medições são feitas com base na norma ISO/IEC 9126-2, de qualidade de produtos, o processo de avaliação e medição da qualidade é também fundamentado em padrões ISO, com base na norma ISO/IEC 14598-5, para análise de impacto de falhas são ainda utilizados conceitos apresentados pelo framework de governança ITIL (2003). Com o método proposto neste trabalho pode-se avaliar de maneira inter-relacionada os serviços pertencentes a uma aplicação, tomando como base os serviços provedores de funcionalidades juntamente com os serviços considerados de infra-estrutura. Com base na identificação dos componentes críticos ou SPOF - Single Point of Failure, pode-se construir a tabela de inter-relacionamento dos serviços ou CFIA - Component Failure Impact Analisys Matrix, e analisar a rastreabilidade do impacto da indisponibilidade de alguns destes componentes na execução das funcionalidades apresentadas pelos serviços de negócio. A partir dos cálculos do índice de disponibilidade dos serviços atômicos, feitos com base na norma ISO/IEC 9126-2, pelo estudo do intervalo entre falhas (MTBF) e tempo médio de reparo de serviços (MTTR), fundamentamos o cálculo do índice de disponibilidade dos serviços de negócio a partir das regras de composição negocial dos serviços atômicos, permitindo uma análise dinâmica da disponibilidade da aplicação de uma forma geral. Conclui-se que a característica dinâmica do processo tem capacidade de fornecer informações precisas quanto ao grau de qualidade, confiabilidade e disponibilidade de aplicações críticas, agregando valor ao processo decisório da área de TI das organizações.

Palavras-chave

Abstract

Keywords

LISTA DE FIGURAS

FIGURA 1- SOEFRAMEWORK ... 17

FIGURA 2–CATÁLOGO E COMPOSIÇÃO DE SERVIÇOS ... 32

FIGURA 3–VISÃO CONCEITUAL DOS ELEMENTOS PRIMÁRIOS DE COMPUTAÇÃO ORIENTADA A SERVIÇOS ... 33

FIGURA 4–CONTÊINER DE IMPLEMENTAÇÃO ARQUITETURAL SOA... 34

FIGURA 5–ELEMENTOS-CHAVE DE SOA... 35

FIGURA 6–ELEMENTOS BÁSICOS DA ARQUITETURA SOA ... 39

FIGURA 7–CAMADAS DE ABSTRAÇÃO DE SERVIÇOS ... 41

FIGURA 8–ARQUITETURA DE REFERENCIA OASIS PARA SOA... 44

FIGURA 9–ARQUITETURA DE REFERENCIA IBM PARA SOA... 44

FIGURA 10–ELEMENTOS DA ARQUITETURA SOAESTENDIDA ... 45

FIGURA 11–INTERFACES DE DISPONIBILIDADE DE SERVIÇOS ... 46

FIGURA 12–CICLO DE VIDA DE GOVERNANÇA EM SOA... 50

FIGURA 13- ARGUMENTOS DE ONTOLOGIA.RATIONALE... 63

FIGURA 14-COMPONENTES (SERVIÇOS) PARTICIPANTES DE UMA TRANSAÇÃO DE NEGÓCIO... 64

FIGURA 15-CONTEXTO DE GERENCIAMENTO DE TRANSAÇÕES DISTRIBUÍDAS UTILIZANDO WEB SERVICES ... 67

FIGURA 16–CONFIGURAÇÃO DE UMA CFIA... 70

FIGURA 17-QUALIDADE NO CICLO DE VIDA ... 80

FIGURA 18-TAXAS DE FALHAS ... 84

FIGURA 19-FATORES DE QUALIDADE ... 85

FIGURA 20-MODELO DE QUALIDADE PARA QUALIDADE EXTERNA E INTERNA ... 86

FIGURA 21-PROCESSOS DE AVALIAÇÃO –ISO/IEC14598... 95

FIGURA 22-ATIVIDADES DO PROCESSO DE AVALIAÇÃO ... 97

FIGURA 23-RELACIONAMENTO ENTRE AS SÉRIES ISO/IEC9126 E ISO/IEC14598 ... 98

FIGURA 24–VISÃO INTEGRADA DA SÉRIE DAS NORMAS ISO/IEC9126 E ISO/IEC14598 ... 99

FIGURA 25-VISÃO DE IMPLEMENTAÇÃO TECNOLÓGICA ... 126

FIGURA 26-DIAGRAMA DE FLUXO DE DADOS DO BARRAMENTO CORPORATIVO DE SERVIÇOS... 127

FIGURA 28-IDENTIFICAÇÃO DOS SISTEMAS LEGADOS COM SERVIÇOS A SEREM REUTILIZADOS... 129

LISTA DE QUADROS

QUADRO 1:RESULTADO DE PESQUISA EM BASES DE DADOS IEEE E ACM... 24

QUADRO 2:MATURIDADE DE ATRIBUTOS DE QUALIDADE NUMA ARQUITETURA SOA. ... 27

QUADRO2:MATURIDADE DE ATRIBUTOS DE QUALIDADE NUMA ARQUITETURA SOA-CONT... 28

QUADRO 3-MATRIZ DE CFIA ILUSTRANDO ASSOCIAÇÃO ENTRE COMPONENTES E POPULAÇÃO DE USUÁRIOS ... 71

QUADRO 4-DEFINIÇÃO DE QUALIDADE... 76

QUADRO 5–NORMA ISO/IEC9126-1-CARACTERÍSTICA FUNCIONALIDADE ... 88

QUADRO 5–NORMA ISO/IEC9126-1-CARACTERÍSTICA FUNCIONALIDADE -CONT. ... 89

QUADRO 6–NORMA ISO/IEC9126-1-CARACTERÍSTICA USABILIDADE ... 90

QUADRO 7–NORMA ISO/IEC9126-1-CARACTERÍSTICA EFICIÊNCIA ... 90

QUADRO 8–NORMA ISO/IEC9126-1-CARACTERÍSTICA MANUTENIBILIDADE ... 91

QUADRO 9–NORMA ISO/IEC9126-1-CARACTERÍSTICA CONFIABILIDADE ... 91

QUADRO 9–NORMA ISO/IEC9126-1-CARACTERÍSTICA CONFIABILIDADE -CONT... 92

QUADRO 10–NORMA ISO/IEC9126-1-CARACTERÍSTICA PORTABILIDADE ... 92

QUADRO 11:QUADRO DE MÉTRICAS DE CONFIABILIDADES ESCOLHIDAS ... 94

QUADRO 13-DOMÍNIO DE SERVIÇOS CRÍTICOS DO BARRAMENTO CORPORATIVO –ABERTURA DE CONTAS... 131

QUADRO 14- MATRIZ DE ANÁLISE DE IMPACTO DE FALHAS DE COMPONENTES –CFIA ... 132

QUADRO 15- DADOS DE DISPONIBILIDADE DE SERVIÇOS ATÔMICOS -BARRAMENTO... 133

QUADRO 16- DADOS DE MTBF SERVIÇOS ATÔMICOS -BARRAMENTO... 135

QUADRO 17- DADOS DE MTTR SERVIÇOS ATÔMICOS -BARRAMENTO... 136

SUMÁRIO

RESUMO ... 6

PALAVRAS-CHAVE... 6

ABSTRACT... 7

KEYWORDS... 8

CAPÍTULO 1 - INTRODUÇÃO ... 15

1.1-MOTIVAÇÃO E CONTEXTO... 15

1.2-TEMA... 22

1.3-REVISÃO DE LITERATURA... 23

1.4-RELEVÂNCIA DO ESTUDO... 26

1.5-FORMULAÇÃO DO PROBLEMA... 29

1.6-OBJETIVOS... 30

1.6.1-OBJETIVO GERAL... 30

1.6.2-OBJETIVOS ESPECÍFICOS... 30

CAPÍTULO 2 – ARQUITETURA ORIENTADA A SERVIÇOS - SOA ... 31

2.1–COMPUTAÇÃO ORIENTADA A SERVIÇOS –UMA BASE CONCEITUAL... 31

2.1.1 - Elementos Fundamentais em SOA... 35

2.1.2 - Conceitos em SOA... 36

2.1.3 - SOA – Aspectos Tecnológicos da Arquitetura... 38

2.1.4 – Arquiteturas de Referência para SOA... 43

2.2-GOVERNANÇA EM SOA ... 48

CAPÍTULO 3 – ALTA DISPONIBILIDADE DE APLICAÇÕES ... 51

3.1–CONCEITOS FUNDAMENTAIS... 51

3.1.1 – Disponibilidade... 51

3.1.2 – Continuidade de Serviço... 53

3.1.3 – Indisponibilidade... 54

3.1.4 – Gestão de Disponibilidade... 54

3.1.5 - Meta de Gerenciamento de Disponibilidade... 55

3.1.7 - Confiabilidade... 57

3.1.8 – Redundância... 58

3.1.9 - Manutenibilidade... 59

3.1.10 - Níveis de Serviço... 59

3.1.11 - Disponibilidade de Sistemas Críticos... 60

3.1.12- Problema transacional em SOA... 66

3.1.13 - Transações Distribuídas e Recuperação de Falhas... 66

3.1.14 - Pontos Únicos de Falha - Single Points of Failure – SPOF... 68

4.1–FUNDAMENTOS DA QUALIDADE DE SOFTWARE... 75

4.2-QUALIDADE DE PRODUTO... 78

4.3-MODELO DE QUALIDADE DE SOFTWARE... 79

4.3.1-DEFINIÇÃO DO MODELO DE QUALIDADE... 80

4.4-QUALIDADE DE PRODUTO E CICLO DE VIDA... 81

4.5-ERROS,FALTAS E FALHAS... 82

4.6-CONFIABILIDADE COMO UM ATRIBUTO DE QUALIDADE... 84

4.7-MODELO DE QUALIDADE... 85

CAPÍTULO 5 – NORMAS DE QUALIDADE ... 87

5.1–VISÃO GERAL DA NORMA ISO/IEC9126 ... 87

5.1.1 - Características de Qualidade de Software e Métricas.... 87

5.1.2 - Descrição da Norma ISO/IEC 9126 – 1... 87

5.1.3 - Escolha das Métricas... 93

5.2–NORMA ISO/IEC14598 ... 95

5.2.1 - Descrição da Norma ISO/IEC 14598... 96

5.2.2 - ISO/IEC 14598 – 5 - Processo para Avaliadores... 96

CAPÍTULO 6 - METODOLOGIA ... 100

6.1-CLASSIFICAÇÃO DA PESQUISA... 100

6.2-COLETA E ANÁLISE DOS DADOS... 102

6.3-DELIMITAÇÃO DO ESTUDO... 103

CAPÍTULO 7 – PROPOSTA DA SOLUÇÃO... 105

7.1–ANÁLISE DA QUALIDADE COM BASE NO CÁLCULO DA DISPONIBILIDADE... 109

7.1.1–MODELO DE PROBABILIDADE DA DISPONIBILIDADE... 111

7.1.2–EQUIVALÊNCIA DE CÁLCULO DO ÍNDICE DE DISPONIBILIDADE... 114

7.1.3–RELAÇÃO ENTRE O ÍNDICE DE DISPONIBILIDADE E A PROBABILIDADE DE DISPONIBILIDADE... 116

7.2–ANÁLISE COM BASE NO TEMPO MÉDIO ENTRE FALHAS... 118

CAPÍTULO 8 – ESTUDO DE CASO ... 124

8.1-INTRODUÇÃO... 124

8.2–VISÃO ESTRATÉGICA DE IMPLEMENTAÇÃO DE UM BARRAMENTO CORPORATIVO... 126

8.3–VISÃO DE REQUISITOS FUNCIONAIS –DIAGRAMA DE CONTEXTO... 127

8.4–VISÃO DE REQUISITOS FUNCIONAIS A PARTIR DOS CASOS DE USO... 128

8.5–VISÃO DE INTEGRAÇÃO COM O LEGADO DE APLICAÇÕES... 129

8.6–DOMÍNIO DE SERVIÇOS CORPORATIVOS... 131

8.7–MATRIZ DE ANÁLISE DE IMPACTO DE FALHAS –CFIA ... 131

8.8–ANÁLISE DA DISPONIBILIDADE DO SERVIÇO DE NEGÓCIO... 132

8.8.1–ANÁLISE COM BASE NO ÍNDICE DE DISPONIBILIDADE... 132

8.8.2–ANÁLISE COM BASE NO INTERVALO MÉDIO ENTRE FALHAS -MTBF ... 134

8.8.3–ANÁLISE COM BASE NO TEMPO MÉDIO DE RECUPERAÇÃO DE SERVIÇO -MTTR... 136

8.8.4–CÁLCULO DA DISPONIBILIDADE EM FUNÇÃO DO MTBF E MTTR ... 137

CAPÍTULO 9 - CONCLUSÃO ... 139

REFERÊNCIAS BIBLIOGRÁFICAS... 141

ANEXOS ... 147

LOG DE EXECUÇÃO DA APLICAÇÃO BARRAMENTO CORPORATIVO DE SERVIÇOS... 147

Capítulo 1 - Introdução

1.1 - Motivação e Contexto

As rápidas mudanças de demanda de mercado associadas à alta competitividade entre as empresas têm levado as organizações a um processo constante de inovação fundamentado na oferta de serviços diferenciados. Fatores anteriormente impactantes no processo de desenvolvimento de novas ofertas levaram as empresas a adotarem técnicas e métodos orientados a velocidade e qualidade de construção de novas soluções. Surge uma demanda onde os gestores de negócio passam a ter um papel mais ativo no ciclo de desenvolvimento, demandando um melhor entendimento do ciclo da solução, partindo da concepção de processos negociais até sua implementação.

Um dos principais objetivos da Arquitetura Orientada a Serviços (SOA) é alinhar necessidades de negócios com o mundo da tecnologia da informação de modo a torná-los mais efetivos. A prática de se modelar sistemas de informação a partir dos processos de negócio fundamentam uma Arquitetura Orientada a Serviços (PAPAZOGLOU, GEORGAKOPOULOS, 2003). Desta forma os processos e as tarefas que os sistemas de informação implementam são definidos como serviços de negócio (HIGH JR., 2005). A fundamentação de uma arquitetura orientada a serviços é também responsável por fornecer uma infra-estrutura técnica que possa ser configurada e customizada de maneira ágil e flexível quando ocorrerem mudanças nos requisitos de negócio. Isso é obtido por meio da separação das interfaces dos serviços de suas implementações.

A computação orientada a serviço é uma solução atrativa para solucionar essa separação na medida em que oferece um bom nível de integração, flexibilidade na criação e gerenciamento de novos serviços. A arquitetura pressupõe que todos os serviços constituintes sejam compatíveis com arquiteturas distribuídas e que a composição destes serviços seja capaz de ser realizada por meio da orquestração e coreografia de serviços (SIM, 2005). A criação de novos serviços consiste basicamente na orquestração, e seu gerenciamento é descrito pela coreografia. A edição de orquestração pode ser auxiliada por ferramentas especializadas, utilizadas diretamente pelos gestores de negócio, tornando a tecnologia bastante próxima do negócio.

De acordo com Tsai (2005), a Computação Orientada a Serviços – SOC representa uma nova abordagem que tem as suas raízes na fundamentação de uma engenharia de software baseada em componentes. Em SOA, existem três tipos de colaboradores no desenvolvimento – construtores de aplicação, barramentos de serviço e desenvolvedores de serviço. Construtores de aplicação realizam seu trabalho por meio da composição de componentes gerando novas aplicações; barramentos de serviço são responsáveis pela publicação dos serviços disponíveis e finalmente os desenvolvedores de serviços são responsáveis pela geração de novos serviços reutilizáveis.

SOC, que é amplamente utilizada no mercado de e-business, está cada vez mais sendo adotada em outras áreas, tais como sistemas críticos de comando e controle. Computação orientada a serviços pode ser aplicada no desenvolvimento de aplicações corporativas, bem como na camada de infra-estrutura. A figura 1 apresenta um diagrama fundamentado por Tsai (2005), segundo o autor um framework de serviços de uma organização inclui as seguintes camadas:

1. Service-oriented infrastructure (SOI) 2. Service-oriented management (SOM)

3. E-Business service-oriented applications (ebSOA)

Figura 1 - SOE Framework (TSAI, 2005)

Segundo Tsai (2005), computação ou engenharia de computação orientada a serviços preocupa-se com a garantia de que software orientado a serviços atenda às necessidades da organização. Seu foco é na especificação, análise, tolerância a falhas, verificação e validação, verificação e controle de modelos e avaliação de interdependência entre componentes de software e hardware.

Muitas das técnicas adotadas pela Engenharia de Software Orientada a Serviços - SOSE estão sendo utilizadas para geração de aplicações de missão-crítica. Um exemplo de uma dessas técnicas envolve ontologias, reconfiguração dinâmica, dinâmica de composição e re-composição. A natureza de projetos colaborativos reflete o fato de que os sistemas podem ser compostos em tempo de execução onde a informação completa sobre o sistema só pode ser disponibilizada imediatamente antes de sua execução.

avançada para localização de serviços além de um melhor entendimento de sua participação no processo de orquestração de serviços corporativos.

Neste contexto a construção de sistemas fundamentados em Arquitetura SOA envolve a descrição de serviços atômicos e compostos, bem como sua orquestração para formação de aplicações distribuídas. Segundo Horrocks (2004) as últimas pesquisas realizadas têm dado foco primariamente em melhorias de serviços web (web-services) por meio do acréscimo de suas descrições ontológicas, tendo apenas iniciado um processo de pesquisa no aprofundamento do entendimento sobre Serviços Web Semânticos (Semantic Web Services), analisando apenas seu comportamento e suas condições de funcionamento. Segundo O’Brien

et al (2005) pesquisas mais avançadas neste tema têm demonstrado uma necessidade de um meta-modelo mais completo contendo um conjunto maior de atributos sobre a descrição de Serviços Web Semânticos.

SOSE envolve a avaliação de confiabilidade fundamentada em um modelo dinâmico após a composição ou construção de um novo serviço. Envolve, também, determinar que medida histórica de dados de falha do sistema devemos utilizar bem como a dinâmica de confiabilidade. No momento da composição de novos serviços, a partir dos serviços registrados no repositório, podemos utilizar automação para geração de código onde a instrumentação pode ser aplicada visando coleta de dados de falha na execução. Estes dados dinâmicos devem ser utilizados para estabelecer o grau de confiabilidade de um serviço. Podemos destacar que a principal diferença entre modelagem dinâmica de avaliação da confiabilidade e as abordagens tradicionais, é que na abordagem dinâmica enfatizamos a coleta de dados integrada ao estabelecimento de um perfil dinâmico da aplicação (composição de serviços), enquanto que em uma abordagem tradicional o estudo é feito basicamente com dados históricos.

Tomando como base estes argumentos torna-se necessária à formalização da análise de confiabilidade dos serviços implementados, sendo estes, atômicos ou compostos . Uma forma de determinarmos a confiabilidade de serviços é utilizarmos normas padronizadas, tal como a norma ISO/IEC 9126, fundamentada pela ISO – International Organization for Standardization na comissão IEC – International Electrotechnical Comission (ISO/IEC), que visa estabelecer os atributos de qualidade aplicáveis a serviços. A norma ISO/IEC 14598 provê um conjunto de guias que orientam o planejamento e a execução de um processo de avaliação da qualidade do produto de software. Após o estabelecimento dos atributos de qualidade podemos construir uma tabela inter-relacionando os índices de disponibilidade dos produtos, de forma que, cada produto deverá ser definido como um serviço computacional de software da organização. Poderemos, então, determinar o grau de qualidade, confiabilidade e disponibilidade de um serviço participante do ambiente, levando em consideração o relacionamento entre todos os fatores componentes destes serviços, tanto fatores puramente computacionais como fatores provenientes de seu ambiente de execução.

Segundo Pressman (2002), qualidade de software é a conformidade dos requisitos funcionais e de desempenho explicitamente declarados, padrões desenvolvidos e totalmente documentados e as características implícitas esperadas de todo o projeto a ser desenvolvido. A norma ISO/IEC 9126-1 (2001) também define qualidade de software como a totalidade de características de um produto de software que lhe confere a capacidade de satisfazer às necessidades implícitas e explícitas (NBR13596, 1996).

Essas características do produto de software podem ser divididas em dois agrupamentos: visão interna e externa. A visão interna define a qualidade interna do produto, ela é medida e avaliada em termos dos requisitos de qualidade interna. A qualidade interna pode ser melhorada durante a implementação com a revisão, testes e reestruturação do código.

Serviços Atômicos: São serviços visíveis diretamente para um consumidor de serviços (ou agente) por meio de uma interface única e descrito por um serviço único que não utilizam ou interagem com outros serviços (OASIS, 2008). São serviços de granularidade-fina, que oferecem um grau de abrangência funcional suficiente para realizar funcionalidades específicas de um processo de negócio (EMIG,2007). Serviços atômicos geralmente são caracterizados por serem pequenas unidades funcionais e trocam pequenas quantidades de dados (SCHMELZER, 2008).

Já a visão externa, define a qualidade externa do produto, ela é medida e avaliada quando o software é executado ou tipicamente com a realização de testes em um ambiente simulado usando métricas pré-definidas. O objetivo dos testes é encontrar e eliminar todas as falhas. No entanto, falhas na arquitetura do software ou em outros aspectos fundamentais permanecem ocultas e podem persistir mesmo após a execução dos testes (ISO/IEC 9126-1, 2001).

A norma ISO/IEC 9126-1 (2001) descreve um modelo para Qualidade de Produtos de Software que pode ser dividido fundamentalmente em duas partes: a) Qualidade Interna e Qualidade Externa e b) Qualidade de Uso. A primeira parte do modelo descreve seis características para qualidade interna e externa e a segunda parte descreve quatro características para qualidade de uso (ISO/IEC 9126-1, 2001), como apresentados na figura 17.

A norma ISO/IEC 9126-1 (2001) prevê suporte a avaliação e a especificação de qualidade de produtos de software em diferentes perspectivas associadas a aspectos como aquisição, requisitos, desenvolvimento, uso, avaliação, suporte, manutenção, garantia da qualidade e auditoria de software. Pode ser utilizada em conjunto com a norma ISO/IEC 14598 (2002) que fornece um conjunto de práticas que orientam o planejamento e a execução de um processo de avaliação da qualidade do produto de software (ISO/IEC 14598, 2002).

A avaliação do produto de software representa um importante fator no processo do ciclo de vida de um software. A qualidade do produto de software, ou serviço, pode ser avaliada pela medição dos atributos internos, pela medição dos atributos externos (tipicamente medidas do comportamento do código quando executado) e, no caso específico deste trabalho pela medição dos atributos de qualidade em uso. O objetivo é que o produto tenha o efeito desejado em um contexto particular de uso.

Para estabelecimento de um processo formal para realização da avaliação da qualidade de produtos de software (Serviços) utilizamos a norma ISO/IEC 14598 (2002). Essa norma provê um conjunto de guias que orientam o planejamento e a execução de um processo de avaliação da qualidade do produto de software. A Norma é dividida em 6 partes, que são: 14598–1: Visão Geral; 14598–2: Planejamento e Gerenciamento; 14598-3: Processo para a Equipe de Desenvolvimento; 14598-4: Processo para o Comprador; 14598-5: Processo para o Avaliador e 14598-6: Módulos de Avaliação (ISO/IEC 14598, 2002).

No contexto deste trabalho utilizamos apenas a ISO/IEC 14598-5 (2002) - Processo para o Avaliador. Esta parte da norma foi utilizada para planejamento e execução das atividades de avaliação da qualidade dos serviços, utilizando como base os atributos apresentados pela norma ISO/IEC 9126-2 (2002) – Métricas Externas. Cabe salientar que a norma ISO/IEC 14598 (2002) pode ser aplicada tanto no contexto de avaliar produtos de software já existentes ou produtos em desenvolvimento. Estes foram fatores importantes na decisão pelo uso da norma em função do alto grau de reusabilidade apresentado por Serviços SOA.

O objetivo final do trabalho é fornecer uma visão integrada, entre os diversos fatores componentes, para uma avaliação de serviços críticos implementados em uma arquitetura SOA. É possível tomar ações corretivas sobre estes serviços no sentido de melhorar o seu grau de disponibilidade atendendo aos requisitos não-funcionais. Para tal avaliação foi utilizada a fundamentação apresentada por padrões ISO.

Com base neste método, procuramos ressaltar a importância da garantia e do controle da qualidade em produtos de software como um fator de melhoria da disponibilidade de sistemas críticos. Mostrou-se que a qualidade dos sistemas em uso é dependente da qualidade de cada produto (serviço), individualmente medida por meio de atributos de qualidade interna, externa e qualidade em uso do software.

As medidas de atributos específicos dos serviços são usadas para o cálculo de métricas que, após análise, resultam em indicadores que orientam ações gerenciais e técnicas, visando aumento de disponibilidade dos sistemas críticos. Finalmente, concluímos que a melhoria da qualidade de produtos de software, no nosso caso específico, serviços SOA, é imprescindível para a continuidade do negócio das organizações que os produzem.

1.2 - Tema

Aborda-se neste trabalho a qualidade e a disponibilidade de serviços em aplicações críticas focalizando, especificamente, aplicações construídas de acordo com as especificações SOA. É apresentada uma abordagem SOA considerando conceitos de SOC – Services Oriented Computing e ESOA – Services Oriented Architecture Extension (PAPAZOGLOU, 2003) bem como fatores relevantes de disponibilidade de aplicações críticas fundamentadas em SOA apresentados por Tsai (2005) e O’Brien et al (2005). Segundo Tsai (2005), SOA ainda não apresenta conceitos maduros suficientes para uma análise da disponibilidade de aplicações críticas orientadas a serviços. SOA ainda apresenta um forte direcionamento conceitual relativo a aspectos estruturais de uma aplicação. Neste trabalho trataremos de um processo para análise da disponibilidade de aplicações críticas construídas com base em arquiteturas SOA, porém, levando-se em consideração aspectos de governança relativos a alta disponibilidade dos serviços críticos destas aplicações.

O processo de avaliação será iniciado por meio da seleção de atributos externos de qualidade de produtos, tomando-se como base a norma de qualidade de produtos ISO/IEC 9126 (ISO/IEC 9126-1, 2001). Fundamentados no conceito de CFIA – Component Failure Impact Analysis ou Análise de Impacto de Falhas de componentes (ITIL, 2003), cada um destes componentes é definido como um ponto único de falha (Single Point of Failure - SPOF ; ITIL, 2003). De acordo com Framework ITIL, em seu capítulo de Service Delivery, um ponto de falha de uma aplicação é qualquer componente que, quando apresenta uma falha ou tem seu funcionamento interrompido, provocando impacto no negócio ou na utilização da aplicação pelos usuários. Considerando que uma aplicação fundamentada em arquitetura SOA é construída com base em serviços, podemos classificar estes serviços como sendo componentes, ou seja, pontos únicos de falha. Com base na elaboração de uma tabela inter-relacionando estes componentes e utilizando os índices de disponibilidade, calculados com base no Framework de Governança de TI - ITIL (ITIL, 2003), poderemos avaliar a qualidade e disponibilidade de serviços considerados críticos derivando, desta forma, um índice de disponibilidade de uma aplicação fundamentada nestes serviços.

1.3 - Revisão de Literatura

BASES DE DADOS

TERMOS IEEE ACM

1 Service Oriented Architecture 100 791

2 SOA 100 899

3 Service High Availability 46 8.476

4 Service Quality 100 2.171

5 (Service Oriented architecture OR SOA) AND _{(ISO 9126)} 3 1

6 (Service Oriented Architecture OR SOA) AND _{(ISO 9126) AND ( Service High Availability)} 0 0

7 (Service Oriented Architecture OR SOA) AND _{(Service High Availability)} 1 1

8 (High Availability) AND (Service Quality) 50 47

9 (Service High Availability) AND (Service Quality) 0 0

10 (Service Oriented Architecture OR SOA) AND

(Service High Availability) AND (Service Quality) 0 0

Quadro 1: Resultado de pesquisa em bases de dados IEEE e ACM.

Percebe-se que quando a consulta é feita com elementos básicos relativos à alta disponibilidade, há uma abundância de material de pesquisa, porém, quando os termos são combinados visando obter um foco maior dentro do campo de pesquisa relativo a qualidade do software ou do serviço implementado, há poucas ocorrências relativas a SOA e Alta disponibilidade de Serviços e, praticamente, não há material relativo a processos de medição formal da qualidade dos produtos a partir de padrões estabelecidos, tais como a norma ISO/IEC 9126, que trata especificamente deste tema.

Os artigos encontrados que tratam do tema SOA juntamente com a norma ISO 9126, descrevem a evolução de sistemas legados no sentido de obter arquiteturas mais flexíveis com características de encapsulamento de serviços, ou mesmo tratando de ontologias para classificação e recuperação de serviços com objetivo de melhorar a disponibilidade, porém sem tratar de forma direta da qualidade destes serviços. Também não há preocupação com a classificação do nível de criticidade destes serviços, tratando serviços atômicos e de negócio no mesmo patamar de criticidade.

A consulta que trata de aspectos de alta disponibilidade de serviços e SOA, apresenta resultados com foco em computação distribuída (Grid Computing), também com foco em tolerância a falhas, a partir da redundância de infra-estrutura combinada com balanceamento automático de carga, da mesma forma, não trata de aspectos relativos à qualidade dos serviços que estão sendo executados.

1.4 - Relevância do Estudo

A relevância deste estudo está fundamentada no fato de uma arquitetura SOA poder ser aplicada na construção e manutenção de sistemas críticos nas organizações. A área de alta disponibilidade tem dedicado muito de seu foco em questões de disponibilidade operacional de hardware e aplicativos ligados à infra-estrutura de TI. Poucos ainda são os estudos sobre disponibilidade de aplicativos “missão-crítica” nas empresas que utilizam SOA como plataforma arquitetural.

Tendo este foco, este trabalho visa colaborar com o desenvolvimento de pesquisas na área de alta disponibilidade de serviços críticos nas organizações utilizando arquitetura SOA.

Serviços “missão-crítica” são elementos fundamentais para continuidade de negócios nas empresas. Arquitetura SOA representa um elemento tecnológico com ganhos efetivos de qualidade e produtividade das organizações. Fundamentadas em serviços, as aplicações se transformam em componentes críticos de disponibilidade de negócio das organizações. O estabelecimento de atributos de qualidade torna-se uma atividade fundamental de continuidade de negócio.

De acordo com estudos apresentados por O’Brien et al (2005) apresentamos no Quadro 2 uma análise do impacto de alguns dos atributos de qualidade de uma arquitetura SOA, demonstrando a necessidade de aprofundamento teórico/prático nas questões relativas a confiabilidade e disponibilidade de serviços numa arquitetura SOA. A coluna “Status” se refere ao nível de maturidade que a arquitetura SOA apresenta para cada um dos atributos: A cor verde significa que existem soluções conhecidas baseadas em padrões e tecnologias relativamente maduros, a cor amarela significa que existem algumas soluções conhecidas, porém necessitam de mais pesquisas provando sua eficácia e utilidade no tratamento dos atributos de qualidade, e finalmente, a cor vermelha indica que padrões e tecnologias existentes ainda se apresentam imaturos ou são necessários esforços significativos para atendimento integral ao atributo de qualidade (O’BRIEN et al, 2005).

Atributo de

Qualidade Descrição Status

Interoperabilidade

Com base na utilização de algumas normas, SOA fornece uma boa interoperabilidade global permitindo serviços e aplicações construídas em diferentes linguagens e implantados em diferentes plataformas de interagir. No entanto a interoperabilidade semântica ainda não está totalmente resolvida. As normas de apoio à interoperabilidade semântica estão imaturas e ainda necessitam desenvolvimento.

Confiabilidade

Podem ainda surgir problemas, mas a utilização das normas tais como: WS-Reliability e WS-ReliableMessaging devem significar que as mensagens são transmitidas de forma confiável. Confiabilidade de Serviço (Service Reliability) é ainda um problema quanto qualquer outro numa arquitetura SOA, ou seja, requer pesquisa e desenvolvimento.

Disponibilidade Cabe aos usuários dos serviços em negociar um nível de serviço

adequado que atenda as necessidades de uma organização.

Quadro 2: Maturidade de Atributos de Qualidade numa arquitetura SOA (O’BRIEN et al, 2005).

Verde

Amarelo

Atributo de

Qualidade Descrição Status

Usabilidade

Usabilidade pode diminuir se os serviços no âmbito da aplicação necessitarem de intervenção humana. Cabe aos usuários e provedores de serviços de construir apoio à usabilidade em seus sistemas.

Segurança

A necessidade de criptografia, autenticação e confiabilidade em uma abordagem SOA exige um alto nível de atenção dentro da arquitetura. Muitas normas com foco em segurança ainda devem ser aprimoradas, pois a maioria, ainda está imatura. Se essas questões não são tratadas adequadamente no âmbito da arquitetura SOA, problemas de segurança ainda podem ser fatores negativos na solução.

Performance

Uma abordagem SOA pode ter um impacto negativo sobre o desempenho de um aplicativo devido a problemas na rede, devido à sobrecarga de serviços, procura de serviços em um catálogo, e da sobrecarga causada por elementos de transmissão de comunicação. O consumidor dos serviços deve projetar e avaliar cuidadosamente a arquitetura, o fornecedor dos serviços deve conceber e avaliar cuidadosamente os seus serviços para se certificar de que os requisitos de desempenho sejam cumpridos.

Escalabilidade

Há maneiras de lidar com um aumento do número de consumidores de serviço e à crescente necessidade de suportar demandas crescentes. No entanto, estas soluções exigem uma análise detalhada por parte dos fornecedores de serviços em se certificarem de que nenhum outro atributo de qualidade está sendo afetado negativamente pelo aumento de demanda.

Extensibilidade

Demonstra a capacidade de expandir uma arquitetura SOA adicionando novos serviços ou integrando serviços adicionais sem causar impacto sobre os serviços já existentes.

Quadro2: Maturidade de Atributos de Qualidade numa arquitetura SOA (O’BRIEN et al, 2005) Cont. Amarelo

Vermelho

Vermelho

Amarelo

1.5 - Formulação do Problema

O custo de uma falha de TI para uma organização poderia simplesmente ser expresso com base no número de transações comprometidas, quer sejam extraídas a partir de uma ferramenta de monitoração (derivados de instrumentação), ou com base em uma estimativa. Quando medido contra as aplicações criticas de uma organização, este custo pode fornecer uma indicação direta da conseqüência de uma falha (ITIL, 2003).

Neste sentido, o problema desta pesquisa é: Como analisar a alta disponibilidade de sistemas críticos, fundamentados em arquiteturas SOA, a partir da fundamentação de atributos de qualidade de produtos e da análise de interdependência entre seus componentes ?

Segundo definições de entrega de serviço do framework ITIL, a vantagem desta abordagem é a relativa facilidade de obtenção de dados para análise de impacto e pela ausência de cálculos complexos para geração de dados numéricos. Desta forma esta abordagem pode ser tornar um elemento de ligação e entendimento entre as áreas de negócio e de infra-estrutura tecnológica, tornando-se um importante elemento para acompanhamento da disponibilidade de serviços de aplicações críticas. Esta abordagem é recomendada como base para o estabelecimento de níveis de serviços para o negócio – SLA (ITIL, 2003).

1.6 - Objetivos

1.6.1 - Objetivo Geral

Definir um método de análise da disponibilidade de serviços de negócio a partir do inter-relacionamento dos índices de disponibilidade de seus serviços atômicos, calculados com base nos atributos de qualidade de produtos, visando avaliar a disponibilidade de sistemas críticos fundamentados em arquiteturas SOA.

1.6.2 - Objetivos Específicos

Identificar atributos externos ISO/IEC 9126-2 (2002), que possam ser aplicados na qualificação de serviços SOA;

Identificar elementos importantes na norma ISO/IEC 14598-5 (2002) visando orientar o processo de medição da qualidade dos serviços;

Definir um instrumento para medição da disponibilidade de uma aplicação “missão-crítica” para uma empresa de grande porte;

Identificar o relacionamento entre CFIA – Component Failure Impact Analysis (ITIL, 2003), regras de composição de serviços de negócio e os atributos fundamentados pela norma ISO/IEC 9126-2 (2002) de qualidade de produtos. Os índices de disponibilidade dos serviços colocados na matriz de análise de impacto de falhas de componentes CFIA, devem ser calculados com base em alguns atributos externos definidos pela norma ISO/IEC 9126-2 – Disponibilidade, Intervalo Médio entre Falhas e Intervalo médio de recuperação de serviço;

Capítulo 2 – Arquitetura Orientada a Serviços - SOA

2.1 – Computação Orientada a Serviços – Uma Base Conceitual

Segundo Thomas Erl (2008) Computação Orientada a Serviços representa uma nova geração de plataforma de computação distribuída. Como tal, ela engloba muitas coisas, incluindo a seu próprio paradigma de concepção. Incorpora princípios de design específicos, padrões de design (Design Patterns) estabelecidos pelo mercado, estabelece padrões de catálogos, bem como, modelos distintos de arquitetura e frameworks de especificação.

De acordo com Thomas Erl (2008) a Computação Orientada a Serviços poderia ser representada por meio de um grande “guarda-chuva” de conceitos. Baseia seus fundamentos nas plataformas de sistemas distribuídos do passado acrescentando novas camadas arquiteturais. Considerações relativas a um processo de governança também estão muito presentes nas soluções orientadas a serviços, além de um vasto conjunto de tecnologias aplicadas em suas implementações. É por isso que se torna crucial o tempo de entendimento dos mecanismos organizacionais e a mecânica subjacente da implementação dos processos de negócio. Após este entendimento é que devemos partir para as fases de concepção e construção do projeto de software.

Para um melhor entendimento de uma plataforma orientada a serviços precisamos, primeiramente descrever seus elementos primários, divididos em (ERL, 2008):

♦ Arquitetura Orientada a Serviços

♦ Orientação a Serviços

♦ Lógica de soluções orientadas a serviços

♦ Serviços

♦ Composição de Serviços

♦ Catálogo (Inventário de Serviços) .

orientada a serviços é o próprio Serviço (ERL, 2008). De acordo com a definição apresentada por Papazoglou (2003), serviços são componentes abertos e padronizados com características de independência e autodescrição que, por meio de sua composição, suportam a construção de aplicações distribuídas (PAPAZOGLOU, 2003).

Pelos princípios fundamentados por Thomas Erl (2008), serviços devem existir como elementos físicos independentes com características arquiteturais distintas que representam funções estratégicas de negócio de forma autocontida. A cada serviço independente é assinalado um contexto distinto e catalogado um conjunto de características negociais relacionado a este contexto. Estas características negociais devem ter a capacidade de serem acionadas a partir de um consumidor externo e são expressas em um catálogo de serviços corporativos.

Composição de serviços pode ser entendida como um agregado coordenado de serviços independentes. Pode ser comparada a uma implementação de hierarquia de processos no desenvolvimento de aplicações, fundamentado por uma modelagem de processos de negócio (ERL, 2008).

Segundo Thomas Erl (2008) o Inventário de Serviços, ou Catálogo de Serviços, se apresenta como uma estrutura independente e padronizada capaz de armazenar e suportar a governança de serviços corporativos. Várias iniciativas têm sido feitas no sentido de fundamentar catálogos de serviços corporativos, porém, alternativamente, algumas soluções podem conter múltiplos catálogos, estes, por sua vez, devem ser padronizados e gerenciados por meio de uma política única corporativa.

A figura 3 apresenta um diagrama de inter-relacionamento entre os elementos primários de uma solução fundamentada em computação orientada a serviços.

Figura 3 – Visão conceitual dos elementos primários de computação orientada a serviços (ERL, 2008)

2.2 – Estrutura e Características de uma Arquitetura Orientada a Serviços

SOA ou arquitetura orientada a serviços pode ser definida como uma evolução da computação distribuída baseada no paradigma requisição/resposta (request/response) para construção de aplicações síncronas ou assíncronas. A lógica negocial ou mesmo funcionalidades especificas podem ser modeladas e representadas como serviços para aplicações fornecedoras e consumidoras de serviços, o ponto importante é a natureza desacoplada destes serviços, ou seja, sua capacidade de execução individualizada com sua interface independente de sua implementação (ERL, 2008).

de suas principais características o apoio à realização dos objetivos estratégicos de negócio associados à realização de serviços de computação.

Fundamentalmente, Computação Orientada a Serviços se fundamenta em conceitos de projeto de software orientado a serviços e de sua relação com a arquitetura orientada a serviços. Na verdade o termo Arquitetura Orientada a serviços – SOA, está sendo tão amplamente utilizada pela mídia, metodologistas, arquitetos e pesquisadores, que se tornou um sinônimo para Computação Orientada a Serviços. Porém, é muito importante fazermos uma distinção clara entre o que realmente é SOA e como isso se relaciona com os elementos primários da computação orientada a serviços, como: Lógica de soluções orientadas a serviços, Composição de serviços e Inventário de Serviços (PAPAZOGLOU, 2003).

Uma implementação de SOA consiste de uma combinação de tecnologias, produtos, APIs, infra-estrutura de apoio e extensões, tal como demonstrado na figura 4.

Figura 4 – Contêiner de Implementação Arquitetural SOA (ERL, 2008)

Neste ambiente um novo serviço pode ser criado a partir da composição de um grupo primitivo de serviços, configurando um Serviço Composto. Serviços atômicos e serviços compostos, podem ainda, ser classificados quanto suas características específicas em: Serviços Entidade, Serviços Utilitários ou Serviços Tarefa (ERL, 2008). (Ver item 2.1.3 - SOA – Aspectos Tecnológicos da Arquitetura – Classificação de Serviços). Esta definição mostra que um serviço mais complexo pode ser construído a partir de um conjunto de serviços pré-existentes. (OASIS, 2008 ; EMIG,2007 ; SCHMELZER, 2008).

2.1.1 - Elementos Fundamentais em SOA

A Arquitetura SOA é composta por entidades ou elementos que mudam no decorrer do tempo, sendo assim, processos, métodos, princípios e ferramentas devem ser colocados à disposição visando facilitar sua constante evolução. A figura 5 demonstra alguns elementos-chave que devem ser levados em consideração quando da utilização da arquitetura orientada a serviços (PAPAZOGLOU, GEORGAKOPOULOS, 2003).

O componente SOA Governance Policies & Processes mostrado na figura 5 corresponde a uma descrição de alto-nível de processos de governança em SOA, incluindo processos de tomada de decisão e resolução de problemas em SOA, definição de papéis e responsabilidades de equipes, processos de desenvolvimento, processos de teste, definição de políticas de certificação de qualidade e definição de processos de registro de serviços. Uma breve descrição dos conceitos relacionados a Governança em SOA está disponível no Item 6.2 deste trabalho.

O componente SOA Principles & Guidelines descreve os princípios que devem guiar arquitetos e desenvolvedores na definição de serviços.

O Componente SOA Methods & Tools define os métodos (análise, projeto e teste) e ferramentas (tais como: ferramentas de desenvolvimento, projeto e testes) que devem ser adotados para desenvolvimento de SOA na organização.

2.1.2 - Conceitos em SOA

SOA é um meio para organizar as soluções que promovem o reuso, crescimento e interoperabilidade. Não sendo, ela própria, uma solução para todos os problemas do domínio. Ao invés disto, SOA apresenta um paradigma de organização de ativos de software que fornece aos desenvolvedores uma maior produtividade a partir do reuso das funcionalidades já existentes e catalogadas nas organizações. A flexibilidade arquitetural apresentada por uma solução SOA, permite expressar serviços negociais de uma maneira que se tornam mais rápidas e flexíveis modificações ou desenvolvimento de novas soluções de negócio (OASIS, 2008).

Segundo Papaioannou et al (2006) a utilização de serviços web em aplicações críticas nos endereça a necessidade de descrevê-los de maneira uniforme e detalhada criando um profile de classificação dos mesmos. Este profile é criado a partir de uma ontologia contendo regras, classes, propriedades de objetos, propriedades sobre os dados e informações do inter-relacionamento funcional entre os serviços. Apesar de serem realizadas muitas pesquisas tentando estabelecer ontologias que classifiquem as propriedades de um serviço web, poucos esforços têm sido realizados para detalhar requisitos não-funcionais de serviços web. Este fato se reflete diretamente na qualidade, confiabilidade e disponibilidade dos serviços. A integração de características de qualidade de serviços nestas ontologias trás benefícios, tanto para consumidores, quanto para provedores de serviços. Manter informações completas e atualizadas sobre as características dos serviços, são cruciais não apenas para a agilização do processo de desenvolvimento como também para o redirecionamento dinâmico e otimização da execução dos serviços críticos ao negócio. O redirecionamento automático de serviços é importante para aumento da disponibilidade e confiabilidade dos serviços, trazendo benefícios nos resultados da organização.

A classificação do serviço não indica apenas características sobre disponibilidade, tratam também de outros requisitos não-funcionais, tais como: performance, confiabilidade, integridade e custo de execução. De acordo com conclusões de Papaioannou et al (2006), manter uma ontologia completa de serviços trás vantagem competitiva para as organizações.

Em geral, uma arquitetura orientada a serviço é composta por entidades que atuam como provedores de serviço e, aqueles que fazem uso dos serviços são referenciados como consumidores de serviço, como demonstrado na figura 6. A descrição do serviço permite que os consumidores prospectivos decidam se o serviço é conveniente para suas necessidades atuais e estabelece quando um consumidor satisfaz todos os requisitos do provedor de serviço (PAPAZOGLOU, GEORGAKOPOULOS, 2003).

Podemos concluir então que um dos principais motivos para o uso da uma arquitetura orientada a serviços é facilitar o gerenciamento da complexidade dos sistemas corporativos de larga escala, facilitar o provisionamento da escalabilidade do uso de serviços e reduzir custos nas organizações. Estes elementos estão fortemente ligados a aspectos relativos a Governança em SOA, principalmente em sistemas críticos, como descrito a seguir neste trabalho. Um dos principais valores relacionados à Arquitetura Orientada a Serviços é oferecer um paradigma escalável único para organizar grandes sistemas em rede que requerem interoperabilidade para realizar o valor inerente aos componentes individuais do negócio. Certamente, SOA é escalável por que faz a menor suposição possível sobre elementos de interoperabilidade e também minimiza qualquer suposição de confiança que são freqüentemente feitas em sistemas de escala menor (OASIS, 2008).

2.1.3 - SOA – Aspectos Tecnológicos da Arquitetura

a) Fundamentos Arquiteturais

Os fundamentos de SOA estão sendo considerados como fatores bastante promissores na área de computação distribuída. As características de interoperabilidade e o fraco acoplamento entre os serviços, com base na definição de interfaces neutras de utilização, definimos serviços como unidades lógicas de software, podendo encapsular uma simples funcionalidade ou mesmo um grande negócio envolvendo múltiplos provedores e consumidores de serviços (PAPAZOGLOU, GEORGAKOPOULOS, 2003).

“Um serviço é um recurso abstrato que possui a capacidade de realizar tarefas que representam uma funcionalidade do ponto de vista de entidades provedoras e entidades requisitoras. Para ser utilizado um serviço deve ser realizado a partir de um provedor concreto”. (BOOTH, 2004)

Uma das primeiras definições relativas à arquitetura SOA foi feita com base em um artigo publicado pela equipe de desenvolvimento de serviços web da IBM no site

developerWorks (http://www.ibm.com/developerworks ; CHAPPELL, 2002 ; IBM Developer Works, 2008). Desde então ela tem sido de grande interesse entre pesquisadores no meio científico e tem recebido uma forte aceitação no mercado de desenvolvimento de software. Apesar da arquitetura ter sido originada em uma equipe de desenvolvimento para aplicações

web o uso dessa tecnologia é bem mais abrangente que a tecnologia distribuída implementada pela Internet.

Figura 6 – Elementos Básicos da Arquitetura SOA (PAPAZOGLOU, GEORGAKOPOULOS, 2003)

• Provedor de serviços: Elemento responsável por prover serviços

acessíveis por um meio de comunicação (rede). É também responsável pelo gerenciamento, manutenção e publicação de serviços.

• Consumidor de serviços: Elemento que usa um serviço fornecido por

um Provedor de Serviços.

• Registro de serviços: Elemento responsável por manter o registro de

serviços disponíveis no repositório. É responsável pela localização dos serviços, bem como, dos protocolos utilizados.

b)Classificação de Serviços (Service Models)

Quando desenvolvemos ou trabalhamos na modelagem de soluções orientadas a serviços torna-se clara a separação dos serviços em três categorias distintas, de acordo com suas características (ERL, 2008):

♦ Análise baseada na lógica negocial encapsulada pelo serviço;

♦ Estudo do potencial de reuso apresentado por estes serviços e;

♦ Análise de como estes serviços se relacionam dentro dos domínios existentes na organização

Tal como definido por Thomas Erl (2008), temos como elemento resultante da classificação dos serviços à criação de três categorias primárias de serviços, organizadas em camadas no Modelo de Serviços. Sua fundamentação foi feita com base em alguns critérios, tais como: análise semântica dos serviços e grau de abstração no modelo utilizado. As classes são as seguintes:

1. Serviços Entidade (Entity Services)

2. Serviços Tarefa (Task Services)

3. Serviços Utilitários (Utility Services)

OTE

Figura 7 – Camadas de Abstração de Serviços (ERL, 2008)

Tomando como base os fundamentos de computação orientada a serviços estes são os três elementos primários na definição e estabelecimento do modelo de serviços. Estes três elementos são utilizados como base para diversos fabricantes no desenvolvimento de soluções que suportam modelos orientados a serviços.

1. Serviços Entidade (Entity Services)

Em diversas organizações que decidiram trabalhar com o paradigma orientado a serviços, temos um documento que define as entidades de negócio, ou seja, elementos que fundamentam o funcionamento da organização, mas que têm independência e comportamento bem definido.

Como exemplo de serviços entidade temos: Cliente, Funcionário, Fatura e Pedido de Suporte ou reclamação. Muitas de suas operações são derivadas de operações

CRUD (Create, Read, Update e Delete) tradicionais. Serviços entidade são considerados altamente reutilizáveis, pois são agnósticos de contexto de negócio, ou seja, podem ser reutilizados na automação de diversos processos de negócio (ERL, 2008). Sob a ótica de classificação de serviços neste estudo, temos neste caso Serviços Atômicos (OASIS, 2008 ; EMIG et al, 2007 ; SCHMELZER, 2008) .

2. Serviços Tarefa (Task Services)

Serviços tarefa são serviços de negócio com uma fronteira funcional bem definida e inseridos em um processo de negócio específico. Este tipo de serviço tende a ter um grau bem menor de reusabilidade, tendo em vista que sua contextualização negocial se apresenta como um fator importante em sua modelagem. São posicionados muitas vezes como serviços de controle, responsáveis por uma composição maior de serviços.

O relacionamento entre serviços entidade e tarefa pode ser definido como uma relação, onde cada serviço entidade encapsula um processo de negócio de escopo fechado e definido, um serviço tarefa pode ser definido como uma seqüência de passos para execução lógica de um processo de negócio (ERL, 2008). Sob a ótica de classificação de serviços neste estudo, temos neste caso Serviços Compostos (OASIS, 2008 ; EMIG et al, 2007) ou Serviços de Negócio.

3. Serviços Utilitários (Utility Services)

Cada um dos serviços previamente definidos, tem um foco bem claro na representação de uma lógica de negócio. Porém existem algumas situações onde não há necessidade de interação entre lógica computacional e processos de negócio, são elementos utilizados para realização de tarefas não associadas ao contexto negocial, mas com fortes características computacional e de automação. São geralmente camadas orientadas a um tipo específico de tecnologia, tais como: tratamento de exceções, rotinas de erro, geração de logs

de eventos. São, também, serviços agnósticos com alto grau de reusabilidade. São também conhecidos como Serviços de Infra-estrutura ou Serviços Tecnológicos (ERL, 2008).

Visando facilitar o entendimento entre estes diversos conceitos e elementos foram criados modelos arquiteturais genéricos fundamentando uma arquitetura de referência para implementação das soluções fundamentadas em serviços. Estes modelos são conhecidos como arquiteturas de referência ou Frameworks (ERL, 2008). Sob a ótica de classificação de serviços neste estudo, temos neste caso Serviços Atômicos.

2.1.4 – Arquiteturas de Referência para SOA

De acordo com a arquitetura de referência descrita pela OASIS – Advancing Open Standards for the Information Society (2008), um modelo de referência é um framework

que visa facilitar o entendimento dos relacionamentos significativos de um ambiente. Ela permite o desenvolvimento de arquiteturas específicas utilizando padrões consistentes ou especificações de suporte para este ambiente. Um modelo de referência é constituído por um conjunto mínimo de conceitos unificados, axiomas e as relações dentro de um domínio de problema particular. É independente de normas, tecnologias, aplicações, ou outros detalhes que sejam específicos de uma plataforma.

Como ilustração do relacionamento entre um modelo de referência e as arquiteturas que podem derivar de um modelo deste tipo, considere o que poderia estar envolvido na modelagem do domínio de “construção de casas”. Sabemos que as áreas de alimentação, de higiene e espaços para descanso são áreas importantes dentro de uma casa. Existem relações entre estes espaços bem como regras que devem ser seguidas para sua construção, por exemplo, pode haver necessidade de separação física entre as áreas de higiene e de alimentação.

De acordo com OASIS (2008), o papel da arquitetura de referência seria identificar soluções abstratas para problemas comuns para um domínio de aplicações. Um padrão geral de construção que atenda às necessidades de harmonização da construção de espaços. Este conceito pode ser utilizado como base para construção de uma arquitetura de referência.

O propósito de um modelo de referência é fornecer um quadro conceitual unificado que possa ser utilizado de forma coerente em diferentes ambientes de implementação, podendo ser de uso particular na modelagem de soluções específicas (OASIS, 2008).

Figura 8 – Arquitetura de Referencia OASIS para SOA

Outro exemplo de arquitetura de referência em SOA é apresentado pela IBM (HIGH Jr., 2005). Na figura 9 segue o diagrama de sua arquitetura de referência SOA onde podemos observar alguns de seus elementos fundamentais. Contempla componentes de serviço necessários para implementação da arquitetura e descreve desde a concepção dos serviços (Development Services) até a estrutura de gerenciamento e governança de serviços (IT Service Management), suportada por uma camada de infra-estrutura com foco em disponibilidade e performance, passando por todos as categorias de serviços integrados a partir de um Barramento de Serviços Corporativo (ESB – Enterprise Service Bus ; IBM Developer Works, disponível em: http://www.ibm.com/developerworks/library/ar-archtemp/).

a) SOA Estendido - Fundamentos

Existem algumas funcionalidades ainda não contempladas na base da definição da arquitetura dentre as quais destacamos o gerenciamento de transações, coordenação de serviços, orquestração de serviços, segurança e alta disponibilidade. Desta forma duas camadas adicionais foram definidas com o amadurecimento da arquitetura, resultando na arquitetura orientada a serviços estendida – ESOA - Extended Service Oriented Architecture

(PAPAZOGLOU, 2003) de acordo com o esquema apresentado pela figura 10:

Figura 10 – Elementos da Arquitetura SOA Estendida (PAPAZOGLOU, 2003)