APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)

FACULDADE DE TECNOLOGIA SENAI FLORIANÓPOLIS

ISRAEL KRAISCH RODRIGO TOMASELLI

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA

A SERVIÇOS (SOA).

Florianópolis 2009

TC

C

AP

LICA

ÇÃ

O D

E T

ES

TE

S D

E S

OF

TW

AR

E U

TILIZ

AN

DO

A

AR

QU

ITE

TU

RA

OR

IEN

TA

DA

A S

ER

VIÇ

OS

(SO

A).

2009

Israel Kraisch – Rodrigo Tomaselli

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)

Florianópolis (SC)

Julho, 2009


APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA).

Trabalho de Conclusão de Curso apresentado à

Banca Examinadora do Curso de Pós-Graduação em

Engenharia de Software com UML da Faculdade de

Tecnologia do SENAI/Florianópolis como requisito

parcial para obtenção do título de especialista em

Engenharia de Software sob a orientação do

Professor MSc. Sergio Akio Tanaka.

Florianópolis (SC)

Julho, 2009


APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)

Trabalho de Conclusão de Curso apresentado à Banca Examinadora do Curso Engenharia de

Software com UML da Faculdade de Tecnologia SENAI Florianópolis em cumprimento a

requisito parcial para obtenção do título de especialista em Engenharia de Software.

APROVADA PELA COMISSÃO EXAMINADORA

EM FLORIANÓPOLIS, 15 DE NOVEMBRO DE 2009.

Prof. Carlos Martins, Dr., (SENAI/SC)

Coordenador(a) de TCC

Prof. Sergio Akio Tanaka, MSc., (SENAI/Florianópolis)

Orientador(a)

Prof. Ruy Tsutomu Nishimura, MSc., (SENAI/Florianópolis)

Examinador

DEDICATÓRIA

Para nossas esposas Anelise e Taís.

Obrigado por seu amor e apoio.

AGRADECIMENTOS

Agradecemos a Deus por nos ter dado a vida, inteligência e saúde para termos

condições de realizar mais esta etapa de nossas vidas.

Aos nossos pais e familiares e, principalmente, as nossas esposas e filhos pelo apoio

nos momentos de dificuldade, pela compreensão nos momentos de nervosismo e nas

horas em que estivemos ausentes para a dedicação ao estudo e pelo interesse em

nossa formação.

Aos mestres que contribuíram para nossa formação.

Aos colegas de classe pelas contribuições e troca de experiências.

A Autus Informática Ltda, empresa onde trabalhamos e que nos incentivou a realizar

este curso, e pelo constante incentivo ao desenvolvimento pessoal e profissional aos

seus colaboradores.

EPÍGRAFE

“O futuro tem muitos nomes. Para os fracos é o inalcançável.

Para os temerosos, o desconhecido. Para os valentes é a oportunidade.”

Victor Hugo

Kraisch, Israel – Tomaselli, Rodrigo. Aplicação de Testes de Software utilizando a arquitetura orientada a serviços (SOA). Florianópolis, 2009. 78f. Trabalho de Conclusão de Curso de Pós Graduação Latu Sensu - Curso Engenharia de Software com UML. Faculdade de Tecnologia do SENAI, Florianópolis, 2009.

RESUMO

Este trabalho apresenta a aplicação de testes sobre programas componentizados, utilizando a

arquitetura orientada a serviços (SOA). Através de um estudo de caso apresenta-se neste, os

conceitos da tecnologia SOA, e de testes de software. As ferramentas utilizadas na aplicação

dos testes foram SOAP-UI devido a sua documentação que é de fácil entendimento e sua

disponibilidade gratuita; e as normas IEEE 829 e IEEE 730 - 1998, por conter as regras

básicas para direcionar os testes de software, bem como os artigos e publicações que

compõem a bibliografia, e auxiliaram no entendimento do escopo do trabalho realizado. O

ensaio foi aplicado ao conjunto de programas que compõem um produto de CRM de uma

empresa da região de Joinville, que no momento da realização deste trabalho, não possuía

documentações técnicas sobre seus componentes, e nem procedimentos ou documentos de

teste, a não ser procedimentos empíricos realizados de forma manual. Os métodos utilizados

para o ensaio foram baseados no entendimento da tecnologia SOA, das técnicas de teste e das

ferramentas pesquisadas. Como resultado, da pesquisa, o teste foi realizado aplicando-se

principalmente a técnica de caixa branca, onde foi necessário recorrer ao fonte dos programas

para realizar os procedimentos de teste, e utilizamos a ferramenta SOAP-UI para criar os

cenários e a execução dos testes, bem como a documentação técnica necessária para o

entendimento dos componentes do aplicativo de CRM. Com a realização deste trabalho, foi

possível entender melhor os conceitos de SOA e de testes, e identificar que “testar SOA”

exige planejamento, muito conhecimento técnico, principalmente das linguagens de

programação utilizadas, e das regras de negócio que compõem cada componente do conjunto

de programas. Com este trabalho identificou-se que a ferramenta utilizada não seria a ideal, e

instigou-se a busca e a análise de novas ferramentas para testes não só para o aplicativo de

CRM, mas para os demais programas que a empresa onde este trabalho foi realizado.

Palavras-chave: SOA; Integração; WebService.

Kraisch, Israel – Tomaselli, Rodrigo. Aplicação de Testes de Software utilizando a arquitetura orientada a serviços (SOA). Florianópolis, 2009. 78f. Trabalho de Conclusão de Curso de Pós Graduação Latu Sensu - Curso Engenharia de Software com UML. Faculdade de Tecnologia do SENAI, Florianópolis, 2009.

ABSTRACT

This paper presents the application of testing on component based programs using the service-oriented architecture (SOA). The concepts of SOA technology, and software testing are presented through a case study . The tools used on the tests were: SOAP-UI because of its easy to understand and free documentation; the IEEE standards 829 e IEEE 730 - 1998 because they contain the basic rules to guide the software testing; were also used articles and publications that make up the blibliografy and assisted in understanding of the scope of work. The test was applied to the set of programs that make up a CRM product, which, at the time of this work, did not have technical documentation on components and documents or procedures on testing, except for empirical procedures performed manually. The methods used for the test were based on the understanding of SOA technology the testing techniques and tools surveyed. As a result of the research, the test was performed mainly by applying the white box technique, where it was necessary to supply the programs to perform the testing procedures,and use the tool SOAP-UI to create scenarios and run tests, and the documentation necessary for the technical understanding of CRM application components. With this work, we are able to better understand the concepts of SOA and testing, and identify that "SOA testing " requires planning, much technical knowledge, especially of the programming languages used and the business rules that make up each component of all programs. This study identified that the tool used was not ideal, and urged for a search and analysis of new tools for testing not only for the CRM application, but for other programs on the company where this work was performed.

Key words: SOA; Integration; WebServices.

LISTAS DE ABREVIATURAS E SIGLAS

BPO – Business Process Outsourcing

HTML – HyperText Markup Language

OO – Orientado a Objeto

QA – Quality Assurance

SSL – Secure Sockets Layer

SOAP – Simple Object Access Protocol

UML – Unified Model Language

XML – Extensible Markup Language

W3C – World Wide Web Consortium

WSDL – WebServices Description Language

UDDI – Universal Discovery, Description and Integration

TI – Tecnologia da Informação

DDT – Test-Driven Development

LISTAS DE ILUSTRAÇÕES (FIGURAS, TABELAS E QUADRO) Figura 1 – Esquema demonstrativo adaptado, do paradigma de FIND-BIND-EXECUTE – Fonte: Dos Autores (2007) .......................................................................................................24 Figura 2 – Camadas de abstração do SOA - Fonte: Dos Autores (2009).................................25 Figura 3 – Modelo de abstração de SOA para equipes de TI – Fonte: Dos Autores (2009) ....28 Figura 4 – Interação tradicional entre browser e servidor web. Fonte: Dos Autores (2007) ...30 Figura 5 - Interação entre browser e um WebService – Fonte: Dos Autores (2007) ...............31 Figura 6 – Ambiente de execução dos testes – Fonte: Dos Autores (2009).............................45 Figura 7 – Ambiente de execução dos testes II – Fonte: Dos Autores (2009). ........................48 Quadro 1 – Requisição SOAP Com parâmetros incorretos......................................................40 Quadro 2 – Resposta de Requisição SOAP Incorreta..............................................................41 Quadro 3 – Requisição correta ao método verifyAccountAcces.............................................42 Quadro 4 – Resposta a requisição ao método verifyAccountAcces, permitindo o acesso.......43

SUMÁRIO

1 INTRODUÇÃO ..........................................................................................................12 1.1 DELIMITAÇÃO DO TEMA ...................................................................................13 1.2 OBJETIVOS.............................................................................................................13 ESTA SEÇÃO APRESENTA OS OBJETIVOS GERAIS E ESPECÍFICOS DO TRABALHO ........................................................................................................................13 1.3 JUSTIFICATIVA .....................................................................................................14 1.4 METODOLOGIA.....................................................................................................15 1.5 TIPO DA PESQUISA ..............................................................................................16

2 REVISÃO DE LITERATURA..................................................................................17 2.1 DESAFIOS EMPRESARIAIS NO CENÁRIO ATUAL.........................................17 2.2 A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)......................................20 2.3 SOA E MUNDO DOS NEGÓCIOS.........................................................................33 2.4 TESTES DE SOFTWARE.......................................................................................34 2.5 DESENVOLVIMENTO ORIENTADO POR TESTES ..........................................40 2.6 CONSIDERAÇÕES SOBRE O CAPÍTULO ..........................................................41

3 RESULTADOS E DISCUSSÕES .............................................................................43 3.1 EXPERIMENTOS....................................................................................................44 3.2 CONSIDERAÇÕES SOBRE O CAPÍTULO ..........................................................49

4 CONCLUSÕES E RECOMENDAÇÕES ................................................................51 4.1 CONSIDERAÇÕES FINAIS ...................................................................................52

REFERÊNCIAS .....................................................................................................................53 APÊNDICES...........................................................................................................................56 ANEXOS .................................................................................................................................75

1 INTRODUÇÃO

A demanda por programas, cada vez mais integrados e cujos processos sejam os

melhores possíveis, tem tornado a área de Tecnologia da Informação (TI) das empresas cada

vez mais complexa, ou seja, são muitos conjuntos de programas envolvidos em processos

sistêmicos, além dos recursos de hardware que demandam cada vez mais infra-estrutura para

executá-los.

Nos dias atuais, um produto ou serviço deve ser o máximo possível flexível e adaptável

às necessidades de cada cliente, ou seja, feito sob medida. Tal demanda traz consigo, o

desafio de integração entre produtos e serviços oferecidos, bem como a integração dos

processos e sistemas internos.

Como proposta de solução, para resolver este cenário caótico em que se busca a

integração de diversos conjuntos heterogêneos de programas, para as mais diversas áreas de

negócio, surge à arquitetura baseada em serviços services oriented architecture (SOA). A

tecnologia tem como objetivo facilitar a integração destas aplicações através da exposição de

serviços, que podem ser acessados diretamente por qualquer outro aplicativo, desde que este

tenha o acesso e respeite a padronização necessária.

Conhecer SOA e o que a tecnologia propõe, permitirá às empresas fornecedoras de

sistemas de informação, bem como aos seus clientes, a descoberta de novas maneiras para

diferenciar suas empresas na atual economia globalizada, e instigar as mesmas a buscarem

novas estratégias de concorrência.

Com o tempo de ciclo de vida dos produtos cada vez menor, dado às demandas cada

vez mais crescentes pela personalização as empresas têm que estar preparadas para criar,

dispor e conseguir o retorno do investimento de modo rápido sob pena de perder

oportunidades, deixando a concorrência livre para absorver esta demanda.

A necessidade de velocidade e eficiência nestas adaptações traz desafios para as áreas

de TI das empresas e seus fornecedores de software, principalmente o de entregar programas

cada vez mais confiáveis, estáveis e com o nível de qualidade ditado pelo cliente, tanto dos

produtos como do atendimento das necessidades e seus anseios.

O destaque crescente do software como elemento de sistema e os “custos” envolvidos

associados às falhas destes são forças propulsoras para uma atividade de teste cuidadosa e

bem planejada. É comum uma empresa fabricante deste tipo de produto, gastar até 50% do

esforço de projeto total em teste.

O presente trabalho versa sobre a aplicação de metodologias de testes sobre aplicações

construídas, integradas ou que estejam expostas na forma usual da tecnologia SOA, bem

como gera uma pesquisa das metodologias de teste e ferramentas existentes, e que sejam

aplicáveis à tecnologia.

Esta pesquisa irá apresentar os conceitos de SOA, testes, a importância destes dois

conceitos no âmbito das empresas, bem como trará informações sobre as ferramentas,

métodos e a própria tecnologia.

1.1 DELIMITAÇÃO DO TEMA

Testes unitários de programas componentizados, baseados em SOA.

1.2 OBJETIVOS

Esta seção apresenta os objetivos gerais e específicos do trabalho

1.2.1 Objetivo Geral

Este trabalho tem como principal objetivo “Compreender como pode ser testado um

componente de software desenvolvido utilizando SOA”. Para atingí-lo, espera-se antes

alcançar os objetivos específicos listados no tópico seguinte.

1.2.2 Objetivos Específicos

a) identificar a diferença da arquitetura SOA de outras arquiteturas de software;

b) pesquisar metodologias de auditoria e testes aplicáveis a SOA;

c) pesquisar e estudar as ferramentas que podem ser utilizadas para aplicar os testes.

1.3 Justificativa

Em uma empresa da região de Joinville, existe um conjunto de programas que contém

uma camada SOA chamado de CRM, na qual já se tentaram aplicar testes de verificação das

unidades, regras de negócios e do sistema integrado de componentes. Porém, as ferramentas

empregadas exigiram um alto custo e mão de obra que necessitou ser treinada durante a

aplicação dos testes. Isto acabou por não apresentar o resultado esperado e a concepção

original do projeto abandonada. É válido ressaltar que fatores externos, como a complexidade

do ambiente devido à componentização, a instabilidade devido ao volume de manutenções e

retrabalhos, demandas de implementação por parte dos stakeholders para a evolução do

produto, também contribuíram para a inviabilização do projeto.

O principal motivo da realização deste trabalho é que atualmente, a aplicação é testada

manualmente, e não há a assertividade e qualidade esperadas, não existem também técnicas

bem como processos definidos para a realização dos testes. O que existe é um procedimento

empírico e sem garantia satisfatória, baseado em cenários predefinidos.

O resultado deste trabalho poderá servir de base para a aplicabilidade de testes unitários

utilizando ferramentas que possibilitem assertividade e qualidade no processo de manutenção

do conjunto de programas, bem como para a definição de procedimentos e técnicas que

possam auxiliar a equipe de auditoria na difícil tarefa de testar e recolher resultados que

possam identificar as falhas para a tomada de ações buscando a garantia da qualidade do

produto, além de sugerir mudanças na metodologia de desenvolvimento demonstrando o

processo de desenvolvimento orientado por testes.

No intuito de facilitar os testes e aplicar uma melhor qualidade a este software propõe-

se o estudo de ferramentas para verificar a possibilidade de uso.

O entendimento de SOA em si é uma das maiores dificuldades, pois ela não é um

simples código de programa que se possa classificar (como pode ser feito com programação

estruturada e orientada a objeto), mas sim, todo um conjunto de regras para o

desenvolvimento de uma aplicação.

O capítulo 2 apresenta os principais conceitos utilizados neste trabalho, tais como, a

arquitetura SOA, onde se abordou o impacto do uso de sofware baseado nesta arquitetura,

suas vantagens e desvantagens, os principais desafios no uso de SOA, o cenário atual das

empresas e das equipes de TI com relação ao uso de programas componentizados bem como

métodos de teste aplicáveis a tecnologia, como testar e porque testes são importantes para as

empresas na atualidade.

O capítulo 3 apresenta os resultados e discussões, a pesquisa e a escolha de ferramentas

para o uso como ensaio de testes de componentes de software baseados em WebService

utilizando-se da arquitetura SOA, também neste capítulo é demonstrado um teste unitário

utilizando a ferramenta escolhida.

Finalmente no capítulo 4, apresenta-se a conclusão e recomendações, onde apesar do

estudo para a busca de soluções em que se pudessem testar a camada SOA do aplicativo de

CRM de maneira mais assertiva, concluiu-se que as dificuldades que se apresentaram foram

as mesmas já enfrentadas e justificadas, e que a ferramenta utilizada também não seria a ideal,

onde recomenda-se um novo estudo da aplicabilidade de testes de software com uma nova

proposta apresentada pela equipe de testes e auditoria da empresa onde este trabalho fora

realizado.

1.4 METODOLOGIA

Esse capítulo tem como objetivo apresentar as técnicas de pesquisas para o

desenvolvimento do presente trabalho. Para a seqüência desta pesquisa, pretende-se cumprir

as etapas relacionadas abaixo:

a) Entender o que significa o conceito de “orientação a serviço”

b) Compreender a arquitetura SOA

c) Entender os protocolos envolvidos

d) Conhecer metodologias de auditoria e testes

e) Pesquisar ferramentas que podem ser utilizadas para aplicar os testes

f) Verificar a aplicabilidade das metodologias de auditoria e testes estudadas, a

arquitetura SOA utilizando as ferramentas pesquisadas

g) Verificar possibilidade de automação dos testes utilizando as ferramentas

estudadas.

1.5 Tipo da Pesquisa

A pesquisa foi desenvolvida seguindo os procedimentos técnicos relativos à pesquisa

bibliográfica e experimental. Bibliográfica, visto que se baseia na leitura e estudo de livros,

artigos, e internet. E experimental, onde para o desenvolvimento das etapas relacionadas,

selecionam-se as variáveis que seriam capazes de influenciá-lo, definem-se as formas de

controle e de observação dos efeitos que a variável produz no objeto.

Para Lakatos e Marconi (2003), pesquisa de campo é "aquela utilizada com o objetivo

de conseguir informações e/ou conhecimentos acerca de um problema, para o qual se procura

uma resposta, ou uma hipótese, que se queira comprovar, ou, ainda, descobrir novos

fenômenos ou as relações entre eles".

Segundo Gil (1999) as pesquisas de campo exploratórias e descritivas visam

proporcionar maior familiaridade com o problema em questão, tornando público o objetivo de

descrever as características de determinada população se torna mais objetivo, envolvendo o

uso de técnicas padronizadas de coleta de dados, questionários e observação sistemática.

Quanto a sua natureza, essa pesquisa será de caráter básico, pois objetiva gerar

conhecimentos novos úteis para o avanço da ciência sem aplicação prática prevista,

envolvendo verdades e interesses universais.

Como forma de abordagem do problema, a pesquisa será do tipo qualitativa pois,

segundo Gil(2002), a interpretação dos fenômenos e a atribuição de significados são básicas

no processo de pesquisa qualitativa e não requer o uso de métodos e técnicas estatísticas.

Os passos para a obtenção dos resultados podem ser definidos de maneira relativamente

simples. A análise qualitativa depende de muitos fatores, como a natureza dos dados

coletados, a extensão da amostra, os instrumentos de pesquisa e os pressupostos teóricos que

nortearam a investigação.

Do ponto de vista de seus objetivos, esta pesquisa é, em sua essência, descritiva,

tratando-se da observação sistemática e da realização de levantamentos necessários para o

entendimento de suas etapas.

2 REVISÃO DE LITERATURA

Este capítulo visa contextualizar o leitor quanto aos desafios, tanto técnicos como de

negócio, enfrentados pelas empresas e suas equipes de Tecnologia da Informação (TI);

aborda a proposta de SOA como sugestão para minimizar estes desafios, e apresenta os

principais conceitos sobre testes de software.

2.1 Desafios Empresariais no cenário atual

No cenário atual, em que as empresas estão sob forte competitividade, o sucesso de uma

empresa depende da agilidade, de como são realizadas suas atividades, principalmente as

ligadas à tecnologia da informação (TI). A demanda por aplicativos, cada vez mais integrados

e cujos processos sejam os melhores possíveis, tem tornado a área de TI das empresas cada

vez mais complexa, ou seja, são muitos conjuntos de programas envolvidos em processos

sistêmicos, além dos recursos de hardware que demandam cada vez mais infra-estrutura para

executá-los.

Segundo Benedete Junior (2007), para a evolução, e em muitos casos para a própria

sobrevivência, as empresas enfrentam cada vez mais desafios, dentre eles citados:

a) concorrência – novas empresas trazem novas idéias, produtos concorrentes

geralmente com estruturas menores, obrigando as empresas já estabelecidas a

se renovarem;

b) globalização – a concorrência já não é apenas local, empresas de porte

internacional podem fazer frente, comprar antigos concorrentes, o contrário

também é válido, ou seja, empresas locais expandindo seus negócios para

novos mercados, adaptando-se a culturas e leis onde se fizerem presentes;

c) aquisições e incorporações – para enfrentar a concorrência, as empresas

utilizam estratégias de modo a aumentar seu porte adquirindo concorrentes, ou

produtos e serviços complementares. Trazem, com isso, desafio de integração

entre produtos e serviços oferecidos, bem como a integração dos processos e

sistemas internos;

d) clientes mais exigentes – nos dias atuais, um produto ou serviço deve ser o

máximo possível flexível e adaptável às necessidades especificas de cada

cliente, ou seja, feito sob medida, une-se a esta condição o alto nível de

qualidade tanto dos produtos como do atendimento das necessidades e anseios

do cliente, para estes casos, as empresas se utilizam de mecanismos e

estratégias de gerenciamento do relacionamento com o cliente – CRM;

e) menor tempo de vida dos produtos e serviços – com o tempo de ciclo de vida

dos produtos cada vez menor, dado às demandas cada vez mais crescentes pela

personalização citada no item anterior (d), as empresas têm que estar

preparadas para criar, dispor e conseguir o retorno do investimento de modo

rápido sob pena de perder oportunidades, deixando a concorrência livre para

absorver esta demanda;

f) integração com clientes, parceiros e fornecedores – A cadeia produtiva da

empresa depende de insumos, produtos e serviços que devem estar integrados e

de forma confiável. Uma empresa pode fazer parte da cadeia produtiva de seu

cliente ou até de seu fornecedor, sendo fundamental a capacidade de se integrar

rapidamente, para aproveitar oportunidades de negócio;

g) normas, regulamentos, inspeções – os processos internos e resultados devem

ser transparentes, confiáveis e conformes com as leis, regras e melhores

práticas de mercado para que a empresa possa acessar a novos mercados.

Esses fatores fazem com que as empresas estejam em constante processo de evolução e

adaptação às novas realidades do negócio. A necessidade de velocidade e eficiência nestas

adaptações traz mais um desafio:

O relacionamento interno das áreas de negócio da empresa com a sua

equipe de TI.

As empresas dependem de suas áreas de tecnologia para projetarem seus novos

produtos, produzí-los, para se relacionar com seus clientes e fornecedores, e para conduzir e

evoluir seus processos internos.

Uma área de TI ágil pode contribuir significativamente para que o negócio possa fazer

frente aos desafios do mercado. Entretanto, o que normalmente se vê é uma TI não

suficientemente alinhada ao negócio, o que pode limitar a evolução da empresa e fazê-la

perder oportunidades.(BENEDETE, 2007).

2.1.1 Desafios no âmbito da Tecnologia da Informação

A maioria das empresas que constroem, e mesmo as que solicitam novos programas,

não conseguem ainda separar os processos (regras de negócio) das demais funções do

aplicativo, construindo assim aplicativos que não podem ser componentizados e reutilizáveis.

De acordo com (NEXTG, 2007) as equipes de TI são constantemente desafiadas a

atender as necessidades de negócio e tecnologia das empresas, estes desafios são causados

por:

a) aumento da demanda – o negócio sempre precisa de novos sistemas, novas

funcionalidades. As equipes de TI das empresas geralmente, não conseguem

dar vazão aos projetos, criando “filas” de atendimento. O que gera

oportunidades como a BPO. Apesar dos esforços em novas metodologias e

ferramentas de desenvolvimento, a produtividade baseada nas tecnologias

atuais ainda não é suficiente;

b) prazos curtos – outrora, sistemas costumavam levar anos para serem

entregues. Com o advento da Internet e ferramentas colaborativas, os prazos

têm se reduzido, chegando a ocorrer necessidades que devem ser atendidas em

poucos dias;

c) qualidade – sistemas que são executados em modo “batch” (envolvendo

grandes lotes de registros, sem interação com o cliente, geralmente executados

no período noturno) já não são aceitáveis, não há espaço nem tempo para erros,

ou re-processamentos, em caso de falhas. Hoje, praticamente todos os sistemas

estão “on-line”, com clientes aguardando o resultado, em tempo real. Uma

falha pode resultar em grande perda monetária e de imagem para a empresa;

d) disponibilidade – com foco em atendimento local, os sistemas normalmente

tinham um intervalo de tempo em que ficavam “fora do ar” (a janela “batch”).

A equipe de TI utilizava este intervalo para gerar cópia das bases de dados,

disponibilizar alterações e manutenções nas aplicações, sem causar impacto

para os clientes. Hoje, os sistemas são acessados de qualquer lugar do mundo e

os clientes trabalham a qualquer hora e não mais limitados ao “horário

comercial”, ou seja, os sistemas devem estar onipresentes e disponíveis. A

disponibilidade destas aplicações e da infra-estrutura de base é constantemente

monitorada e medida em frações, entre 99,97% e 99,99%;

e) integração – aqui o desafio é integrar sistemas construídos em épocas, com

tecnologias, padrões e plataformas diferentes entre si, o que costuma consumir

grande parte dos investimentos, para que conjuntos sistemas construídos pela

TI das empresas, pacotes adquiridos do mercado, aplicações incorporadas na

aquisição/fusão com outras empresas e sistemas externos (de clientes,

parceiros ou fornecedores) funcionem de modo integrado;

f) novas tecnologias – ferramentas e tecnologias se tornam obsoletas em pouco

tempo, e geram grande impacto em capacitação e atualizações de hardware,

software e mesmo das aplicações, obrigando as equipes de TI à atualização

constante;

g) custos – para manter a empresa competitiva, as equipes de TI, devem procurar

aumentar a produtividade e diminuir os custos, sempre analisando o mercado

em busca de ferramentas que possam auxiliar os usuários dos sistemas e

automatizar tarefas;

h) controles – mecanismos de controle e monitoração são necessários para aferir

e garantir atributos como segurança, qualidade e conformidade com normas do

mercado e com acordos de nível de serviço (SLA), que cada vez mais regem o

relacionamento (prestação de serviços) entre a empresa e seus clientes e

parceiros.

O conceito de SOA vem justamente ao encontro destas necessidades, ou seja,

flexibilizar a arquitetura para que não seja necessário descartar um aplicativo e seu legado,

bastando que se construa um serviço que possa acessá-lo, aproveitando assim, senão o todo,

pelo menos partes deste sistema, com SOA é possível fazer o re-uso de software, o que reduz

o esforço de desenvolvimento de novas aplicações, diminuindo custos, atendendo com mais

agilidade novos requisitos de negócios (NEXTG, 2007).

2.2 A Arquitetura Orientada a Serviços (SOA)

Quando se ouve falar em SOA (“Service Oriented Architecture” ou “Arquitetura

Orientada a Serviços”), normalmente o termo é associado à tecnologia WebService (esta será

descrita mais adiante).

2.2.1 Conceituando SOA

A Arquitetura Orientada a Serviços, como o próprio nome diz é uma “arquitetura”, ou

seja, um conjunto de princípios, padrões e orientações que englobam desde a visão de negócio

até suas possíveis alternativas tecnológicas(BENEDETE, 2007).

SOA reuniu os esforços dos principais provedores de tecnologia (como a IBM®,

Microsoft®, SAP®, Oracle®) em torno de um conjunto de padrões e tecnologias que tornam

possíveis a interoperabilidade e re-uso de aplicações, independentemente de linguagens e

plataformas de hardware ou software(BIEBERSTEIN, 2006).

A arquitetura descreve uma categoria de aplicativos compostos cujo princípio

fundamental é que suas funcionalidades sejam implementadas e disponibilizadas na forma de

serviços, fracamente acoplados, orquestrados e organizados em um “barramento de serviços”

formados pelos componentes: provedor de serviços, que disponibiliza contratos; interfaces

acessíveis através de WebService (ou outra forma de comunicação baseada em computação

distribuída utilizando o paradigma de request/reply) e o consumidor de serviço, separando a

lógica comercial e oferecendo transparência de local para provedores e consumidores de

serviços.

A definição de SOA deve ser ajustada ao público alvo, ou seja, para as equipes de

negócio, deve-se enfatizar a flexibilidade na adaptação e disponibilização de novos negócios,

baseados em processos e serviços bem definidos, já para o pessoal de tecnologia, devem-se

detalhar os aspectos tecnológicos, para não tornar a definição abstrata ou abrangente demais.

2.2.2 Algumas definições, e termos de SOA:

• Arquitetura – “A arquitetura de software de um programa ou sistema

computacional é a estrutura ou estruturas do sistema, as quais compreendem

elementos de software, as propriedades externamente visíveis desses

elementos, e o relacionamento entre eles” (BASS, CLEMENTS, KAZMAN.,

2003). “Ou seja, arquitetura são modelos e padrões que permitem documentar,

facilitar o entendimento e direcionar as diversas dimensões da construção das

aplicações, como exemplos, a localização e armazenamento dos dados, os

mecanismos com que os usuários interagem com os sistemas e como os

programas se conversam ”(BENEDETE, 2007).

• WebService – “É uma família de tecnologias que consistem de especificações,

protocolos e padrões da indústria, cujo objetivo é permitir que aplicações

(mesmo baseadas em diferentes plataformas de hardware e software ou

linguagens) possam se comunicar de uma maneira segura e consistente.

WebService é uma implementação tecnológica dos conceitos de SOA e, por

isso, normalmente se confunde com a mesma ”(BENEDETE, 2007).

• Processos de negócio – “É um conjunto de tarefas logicamente relacionadas

para se obter um resultado de negócio definido”(BIEBERSTEIN, 2006). A

Gartner define processo de negócio, como “Um conjunto de atividades e

tarefas executadas por recursos (pessoas e sistemas) usando uma variedade de

informações (documentos, imagens, conhecimento), interagindo de várias

maneiras (seqüencialmente ou de maneira não prevista), guiadas por políticas e

princípios (objetivos, regras de negócio)”.(AREVOLO, 2006).

• Serviços – Do ponto de vista do negócio, são as funcionalidades providas pela

empresa para seus clientes e parceiros, por exemplo, um serviço de saque, um

serviço de abertura de contas. Do ponto de vista de TI, trata-se de um

componente de aplicação cujas funcionalidades estão disponíveis para outros

sistemas ou usuários.(BENEDETE, 2007).

• Componentes – “São pedaços de software que podem ser reutilizados, pois

foram desenvolvidos com esta preocupação (interface padrão e outras regras)

”(BENEDETE, 2007).

• Reutilização – “O re-uso é um dos pilares da SOA, pois é ele que possibilita o

ganho de velocidade na construção de novas aplicações, a redução dos custos e

aumento da qualidade, através do reaproveitamento de componentes prontos,

testados e confiáveis” (BENEDETE, 2007).

• Caixa-preta – São componentes que podem ser utilizados por outras

aplicações, sem que haja preocupação de como foram construídos (tecnologias,

linguagens) (BENEDETE, 2007).

• Fracamente acoplados – É uma abordagem para construção de aplicações que

foca na simplicidade e autonomia entre os componentes. Os programas

interagem (trocam dados) de uma maneira que a dependência entre eles é

minimizada, facilitando a alteração ou mesmo a troca de um deles

(BENEDETE, 2007).

• Orquestrados – As ferramentas que compõe a infra-estrutura SOA provêm

componentes para gerenciar (orquestrar) as interações (fluxo) entre os serviços

dentro de um processo de negócio.(BENEDETE,2007).

• Nível de serviço – “São acordos que definem características de como o serviço

deve ser provido, por exemplo: tempo de resposta, disponibilidade e

quantidade de falhas. A definição dos níveis de serviço está diretamente ligada

às melhores práticas da gestão de processos de negócio ”(BENEDETE,2007).

• Framework – É uma estrutura básica de software e padrões, construída para

auxiliar e organizar o modo de desenvolver outras aplicações

(BENEDETE,2007).

• Uso de padrões – Embora conceitualmente SOA possa ser implementado com

qualquer tecnologia, o uso das tecnologias como WebService é fator que difere

e pode garantir o sucesso da SOA frente a outras abordagens e arquiteturas

orientadas à comunicação distribuída. SOA está baseada no uso de padrões que

são amplamente aceitos pela indústria de TI, e a maioria dos grandes

fornecedores de software e ferramentas para desenvolvimento está

gradativamente migrando suas ofertas de produtos não só para suportar SOA,

mas também utilizá-la como solução interna para construção de seu software

(BENEDETE,2007).

Uma das mais importantes características sobre SOA é que ela libera o negócio das

restrições da tecnologia, ou seja, "SOA permite aos responsáveis pela empresa a tomar

decisões de negócio suportadas pela tecnologia ao invés de tomar decisões

DETERMINADAS ou LIMITADAS pela tecnologia" (HURWITZ,2007).

SOA pode ser bem representada a partir do processo, chamado de "find-bind-execute

paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Tal

conceito é análogo a "Ciclo de Deming" (PDCA) aplicado aos serviços, que define o ciclo que

envolve o planejamento, a execução, o monitoramento e a tomada de ação pró-ativa para a

melhoria da qualidade, exemplificado pela Figura 1:

Figura 1 – Esquema demonstrativo adaptado, do paradigma de FIND-BIND-EXECUTE – Fonte: Dos Autores (2007)

a) O usuário do serviço é a aplicação que solicita um serviço. A aplicação solicita

através dos registros de serviço (contratos) as informações referentes à

localização do serviço. O registro de serviço é uma aplicação que retorna as

informações para uso de um serviço;

b) O provedor de serviços funciona de forma semelhante a um sistema de

páginas amarelas de uma lista telefônica, oferecendo os serviços para que

possam ser encontrados de forma fácil.

Como exemplo a arquitetura tem-se um E-commerce qualquer. A requisição é realizada

através de um cliente. O cliente que pode ser um navegador internet qualquer, este solicita o

preço de um determinado produto, o WebService recebe e processa o pedido e retorna uma

resposta contendo o preço do produto.

A abordagem SOA permite substituir ou atualizar componentes individuais no

aplicativo sem afetar outros componentes ou o processo como um todo. Além disso, podem-se

especificar independentemente caminhos alternativos através dos quais os componentes do

aplicativo trocam mensagens (NETBEANS, 2009).

2.2.3 Camadas de abstração da SOA

Modelos de abstração facilitam o entendimento de conceitos por organizarem idéias,

funcionalidades e documentações no nível de detalhe mais adequado para cada tipo de

necessidade. A Figura 2 mostra as diversas camadas que compõe a SOA e pode ser utilizada

para descrever o conceito para as equipes de negócio de maneira a propor o claro

entendimento de como funciona a arquitetura, facilitando a apresentação da arquitetura a

equipes de negócio.

Figura 2 – Camadas de abstração do SOA - Fonte: Dos Autores (2009)

a) camada corporativa – descreve o negócio da empresa, identifica os processos

de negócio chave da empresa - que são essenciais para sua vantagem

competitiva - e que, portanto, devem ser controlados da maneira mais próxima

possível; e os processos de suporte, que podem até ser delegados para

parceiros. Há diversos frameworks, a exemplo do framework de Zachman

disponível no Anexo I (ZACHMAN,2008)

...“publicado no livro “A Framework for Information Systems Architecture” em 1987 de autoria de Zachman, em que o autor, introduzia o conceito de arquitetura de sistemas de informação. As idéias propostas resultaram de conhecimentos e experiências de outras disciplinas mais antigas (arquitetura, engenharia da produção) e rapidamente se tornaram numa referência para todos aqueles que têm algum interesse no tema da arquitetura de sistemas de informação. Infelizmente, e apesar da relevância do tema, muitos destes conceitos continuam desconhecidos entre as equipes de TI. De acordo com autor, a arquitetura é o “conjunto de representações descritivas (modelos) relevantes para a descrição de um objeto, de forma a que este possa ser construído de acordo com os requisitos (de qualidade) e mantido ao longo da sua vida útil”. Esta definição é consideravelmente genérica e informal e não indica o âmbito do termo arquitetura; de fato, no caso da abordagem proposta por Zachman, ela refere-se quer aos sistemas de informação quer à empresa, uma vez que o mesmo modelo apresenta relativamente a cada conceito a perspectiva do negócio e dos sistemas de informação. O Framework de Zachman é uma estrutura lógica de classificação e apresentação dos modelos de uma organização relevantes para a respectiva gestão, bem como para o desenvolvimento dos seus sistemas...”...” Nesta perspectiva, modelar um sistema significa determinar e representar um conjunto de informação, sobre vários tópicos (colunas da matriz), relevante para vários intervenientes (linhas da matriz).”... (SILVA, A. M. R.; VIDEIRA C. A. E., 2001)

e metodologias que se aplicam a camada corporativa, mas SOA introduz novos

artefatos e considerações de arquitetura, principalmente por habilitar o

estabelecimento de parcerias (clientes, fornecedores) nas camadas de processo

e serviço;

b) camada de processos – nesta camada é que os processos de negócio são

identificados e caracterizados. Cada processo é único no atendimento de uma

determinada área funcional e pode ser composto de diversos sub-processos. Os

sub-processos podem ser decompostos para expor suas dependências da

camada de serviço. Como se podem confundir os conceitos de serviço e de

processo de negócio, considera-se que os processos são definidos uma única

vez e usados dentro de um contexto único, já os serviços podem ser

reaproveitados em diversos contextos com diferentes processos de negócio,

departamentos ou linhas de negócio;

c) camada de serviços – é responsável por mapear os serviços que provêm às

funcionalidades básicas, técnicas e de negócio. O negócio identifica as funções

críticas para atender o negócio, como identificação do cliente ou cálculo de

taxas, enquanto os especialistas de TI criam funções técnicas para suportar os

requisitos do negócio, como serviços de segurança;

d) camada de componentes – é a camada onde são mapeados os componentes

que têm potencial para se transformarem em serviços, normalmente através de

técnicas “bottom-up” (análise das aplicações e identificação de funções que

devem ser promovidas a serviços, por terem o potencial de servirem a mais

sistemas). Componentes são os blocos de construção de serviços na arquitetura

SOA e embora vários sejam construídos com esta finalidade, a maioria será

reaproveitada a partir de aplicações já existentes, através de técnicas de

encapsulamento;

e) camada de objetos – esta camada identifica e caracteriza uma larga

quantidade de classes de objetos, seus atributos e relacionamentos. Embora

SOA reaproveite os conceitos de interface originados na orientação a objetos,

ela o estende, pois tem-se que identificar que a classe não apenas é pública, ou

seja, que pode ser utilizada por outras aplicações através de chamadas nativas

da plataforma, mas sim que ela é importante o suficiente para ser promovida a

componente/serviço, e assim pode ser chamada por mecanismos de maior

poder de abstração, como WebService. Esta decisão muitas vezes envolve os

cenários de uso da função, para balancear requisitos não funcionais como

desempenho e desacoplamento.

Em contrapartida a Figura 3, provê as equipes de TI, uma demonstração da interação

entre as camadas como um exemplo prático, aqui se abstrai ainda mais as camadas.

Demonstra-se a interação entre as camadas de processos com a camada de serviços, seus

componentes de serviço, a interação da camada de serviços com a camada de integração, seus

sistemas legados e componentes.

Camada de

Integração

Camada de

Serviços

Camada de

Negócios

B1

B2B3

B4

B5 B6

B1

B2B3

B4

B5 B6

B7 B8 B9

B7 B8 B9

Figura 3 – Modelo de abstração de SOA para equipes de TI – Fonte: Dos Autores (2009)

2.2.4 O modelo WebService

Os WebServices representam um novo modelo de arquitetura representando um grande

avanço tecnológico. Propõem a comunicação por protocolos padrões como o HTTP e XML

promovendo a evolução de serviços, onde às lógicas de negócio são expostas através de regras

de programáticas (SOA-RM, 2009).

Por definição, WebServices são serviços distribuídos na WEB que processam

mensagens SOAP codificadas em XML enviadas através do protocolo HTTP.

O principal motivo do crescimento desta tecnologia é devido ao SOA, que consiste em

uma coleção de serviços autônomos identificados por URLs, com interfaces criadas através de

WSDL e processamento de mensagens XML.

2.2.4.1 Vantagens do uso de WebServices

Existem inúmeras vantagens no uso de sistemas baseados em WebService,

principalmente por proporcionar de forma simples e rápida oportunidades que seriam

impossíveis de serem concretizadas devido à alta complexidade e custo em outras tecnologias

equivalentes. O sucesso de uso dependerá de uma boa avaliação e estudo para a aplicação

desta tecnologia. Nem tudo pode ser resolvido através de WebService, mas em geral

consegue-se:

• integrar sistemas legados com baixo custo;

• diminuir custos operacionais;

• diminuir custo/tempo no desenvolvimento de sistemas;

• aproximar-se mais com seus clientes e parceiros comerciais;

• prospecção de novos mercados e negócios.

O que vai ao encontro da maioria das necessidades já expostas como desafios para as

equipes de TI e para as empresas no cenário atual dos negócios.

A arquitetura orientada a serviços difere de sistemas orientados a objetos (OO) e

sistemas procedurais no que diz respeito à ligação entre os componentes.

Em geral sistemas OO e procedurais são conectados através de chamadas baseadas em

tipos e nomes e, em uma SOA, a ligação consiste na troca de mensagens - o que permite

estabelecer restrições para o envio/recebimento de informações separando de forma clara a

estrutura comportamental da estrutura de descrição.

Como visto anteriormente, um WebService e uma aplicação de software que pode ser

acessada remotamente através de diferentes linguagens e protocolos. Normalmente, um

WebService e identificado através de urls como qualquer outra página web. Na maioria dos

sistemas web a resposta a requisições na Internet é feita através de chamadas efetuadas por um

navegador web, resultando no retorno de conteúdo em texto no formato HTML. A Figura 4

ilustra melhor esta interação:

Figura 4 – Interação tradicional entre browser e servidor web. Fonte: Dos Autores (2007)

Webservices e consumidores de WebService são geralmente associados a negócios do

tipo B2B. Isto acontece quando a empresa que provê o serviço também é cliente de outro

serviço. Os WebServices são projetados para suportar interação e interoperabilidade podendo

ser, ou não, de arquiteturas diferentes.

O acesso ao WebService é semelhante na forma de acesso tradicional à internet, a

diferença encontra-se no conteúdo que é enviado na requisição do cliente e o retorno do

servidor. Os clientes de um WebService enviam mensagens SOAP contendo chamadas a um

método e parâmetros que por ventura sejam necessários. O servidor por sua vez interpreta esta

chamada e retorna a informação XML resultante do processamento, conforme demonstrado

na Figura 5. Por ser uma troca de dados em formato amigável pode ser transferida de um

computador para outro não importando:

• O tipo ou modelo de computador e/ou sistema operacional usado.

• O lugar no mundo em que o servidor ou cliente se encontra.

• A linguagem em que foi implementado o software cliente/servidor.

• A necessidade de o cliente conhecer as versões de protocolos e software que

estão sendo utilizadas no servidor.

Figura 5 - Interação entre browser e um WebService – Fonte: Dos Autores (2007)

2.2.4.2 Desvantagens do uso de WebServices

Os WebServices resolveram importantes questões que eram, até então, de difícil solução

na comunicação entre sistemas, porém, não é uma “solução mágica” e deve ser analisada

quanto ao atendimento dos requisitos da aplicação a ser construída ou acoplada.

Existem ainda questões polêmicas e não previstas pelo protocolo SOAP, dentre as quais

a segurança, o suporte e as transações, a exemplo do artigo “SOA is dead; Log life Services“

em que a autora, apresenta o artigo como um obituário, indicando que SOA morreu no dia

01/01/2009, devido à recessão econômica mundial, e que apenas sobrevive, através dos

diversos produtos gerados a partir da tecnologia, e que dependem de serviços, indicando

inclusive que SOA fracassou e que não entregou, exceto em raras exceções, os benefícios que

prometia, e que embora o termo que define SOA esteja morto, a exigência de arquitetura

orientada a serviços é mais forte do que nunca. Esta mesma autora, dentre outros especialistas

da área, estará presente no 2º Simpósio Internacional de SOA que realizar-se-á na Holanda,

nos dias 22 a 30 de Outubro deste ano para defender seu ponto de vista abordando o que

chama de “A ressurreição de SOA”. (Manes, 2009)

Como os serviços funcionam sobre o protocolo HTTP que por sua vez não é seguro, a

única opção atualmente e agregar ao seu serviço o uso do SSL (secure socket layer). O SSL

protege com boa segurança o envio de informações, porém, torna as transações mais lentas

sendo, muitas vezes, inadequado a grandes volumes de transferência de dados.

Não há garantia que determinada transação será completada em dependência de outras,

principalmente se os provedores de serviços forem web services de fornecedores distintos.

A falta de padrões também prejudica o desenvolvimento dos serviços, a autenticação, a

comunicação de feedback dos resultados são itens que não estão totalmente padronizados e

dependem das implementações de cada desenvolvedor.

Desempenho é uma questão que também deve ser observada, visto que todo serviço

trafega através da Internet. Como a velocidade de transmissão na Internet é variável e não se

podem controlar, sistemas onde desempenho seja vital não são candidatos a adotarem esta

tecnologia.

O processamento envolvido é outro ponto crucial. Como os dados são trocados em

formato XML, o que na pratica é um formato de texto, há grande consumo de processamento

para a conversão dos dados. Se os dados forem complexos (como binários e imagens) a

codificação e decodificação destes dados podem levar tempo, o que pode causar a impressão

ao usuário de que o programa está “travado” ou ainda provocar a desconexão do serviço por

limite de tempo de execução.

Os web services herdam, por sua vez, as deficiências inerentes à implementação de

SOA.

2.2.4.3 Itens básicos de uma implementação de Web services

Basicamente, hoje, é possível implementar web service utilizando componentes prontos

de grupos conhecidos no mercado, como o Apache Group que implementa componentes de

código aberto, ou de fornecedores comerciais como Microsoft ou IBM, entre outros.

Em geral, podem ser desenvolvidos por qualquer linguagem de programação baseadas

em sockets.

Duas organizações importantes, O World Wilde Web Consortium (W3C) e a

Organization for the Advancement of Structured Information Standards (OASIS) controlam e

desenvolvem especificações e padronização para a arquitetura SOA e dos web services (entre

outros), assim, se um software for construído dentro dos padrões recomendados por estas

organizações, a troca de um fornecedor de software que utilize os padrões estabelecidos não

deve causar impacto na operação do cliente, já que a estrutura base de provimento e

utilização do serviços será a mesma.

Existem cinco itens básicos nesta arquitetura:

• HTTP : Hipertext Transport Protocol usado para transportar as informações

pela rede ou internet.

• XML: Extensible Markup Language é utilizada na de definição e semântica

dos dados.

• SOAP: Simple Object Access Protocol é o formato de mensagens para

chamada de métodos remotos.

• WSDL: Web services Description Language descreve as características

oferecidas pelo serviço.

• UDDI : Universal Discovery, Description and Integration descreve um tipo

especial de registro que lista os web services na Internet.

• Não se abordará cada item da implementação básica, até porque estão em

constante adaptação sendo possível verificar cada tópico através das

referências definidas pela W3C e pela OASIS, no Anexo II, encontra-se um

mapa descrevendo como pode ser feita a implementação de web service

explanado de forma abrangente.

2.3 SOA e mundo dos negócios

Existente apenas acerca de seis anos (NEXTG, 2007), SOA ainda não é aplicada em sua

essência. Apenas poucas empresas de grande porte estão realizando um movimento de

conversão e ou adaptação, de suas aplicações para este novo conceito.

Uma recente previsão da Gartner diz que: “SOA será utilizada parcialmente em mais de

50% das novas aplicações de missão crítica e processos de negócio criados em 2007, e mais

de 80% até 2010 (70% de probabilidade)” (NATIS, 2006).

Também segundo a Gartner, “Organizações que comecem sua transformação para BPM

durante 2006 e 2007 serão recompensadas pelo domínio de suas indústrias por volta de 2010.

Ter uma arquitetura de processos (parte de uma arquitetura de negócios) e alinhar as

iniciativas de BPM com as iniciativas de SOA são atividades chaves a serem realizadas em

2007”.

Utilizando a abordagem SOA estão surgindo movimentos de terceirização da regras de

negócio, originando os chamados Business Process Outsourcing – BPO, empresas

especializadas em mapear, integrar, automatizar e aperfeiçoar programas e processos de

negócio, e que executam os mais variados serviços, que uma organização não deseja ou não

precisa executar com recursos próprios, para que estas organizações, possam concentrar seus

investimentos no que realmente faz parte de seu core business.

2.4 Testes de Software

Esta seção aborda a conceituação de Testes de Software buscando identificar maneiras e

ferramentas para realizar testes em SOA, onde descreve-se os principais conceitos e termos

relacionados ao processo de teste de software. Serão apresentados termos usuais apenas para

conceituar o leitor e não serão discutidos em profundidade cada tópico apresentado. Em

trabalho relacionado (PERES, R.; NOGUEIRA, A. R., 2004), os autores apresentam

individualmente cada tópico conceituando testes de software com maior profundidade, os

conceitos abordado também podem ser encontrados na normas IEEE 829 -1998 e IEEE 730 –

1998 (IEEE, 2009). A seguir apresentamos uma sintese baseada no trabalho relacionado e na

norma de referencia citada, para a implementação de testes de software.

2.4.1 Nivelamento conceitual

Teste é um conjunto de atividades que podem ser planejadas antecipadamente e

conduzidas sistematicamente. Por essa razão, um gabarito para teste de software - um

conjunto de passos no qual se podem alocar técnicas de projeto de casos de teste e métodos de

teste específico - deve ser definido para o processo de engenharia de software

(PRESSMAN,1995; NEMETZ,1997).

A atividade de teste de software é um elemento crítico da garantia de qualidade de

software e representa a última revisão de especificação, projeto e codificação.

O destaque crescente do software como elemento de sistema e os “custos” envolvidos

associados às falhas de software são forças propulsoras para uma atividade de teste cuidadosa

e bem planejada. É comum uma organização de software gastar até 50% do esforço de projeto

total em teste. Esta é a razão que leva a maioria das pessoas a acreditar que o software não é

bem testado antes de ser fornecido ao cliente.

A seguir são citados alguns objetivos do teste de software de acordo com

(BEIZER,1990; LINNENKUGEL,1990; MYERS,1979):

a) a atividade de teste é um processo, de executar um programa com a intenção de

descobrir um ou vários erros;

b) um bom caso de teste é aquele que tem uma elevada probabilidade de revelar

um erro ou um conjunto de erros ainda não descoberto;

c) para que um teste seja considerado bem-sucedido este deverá revelar um erro

ainda não descoberto.

Dentre as citações de (MYERS,1979) pode-se dizer que a atividade de teste de software

é o processo de revisar especificações, projetos e programas com a intenção de descobrir

erros. Alguns dos principais itens que são comuns aos autores e pesquisadores, referenciados

neste trabalho, do assunto teste de software e que descrevem os fundamentos e princípios

desta atividade estão relacionados abaixo (PRESSMAN,1995; CHANG,1999; ROCHA,2001;

NIELSEN,1993; NEMETZ,1997):

a) a atividade de teste não prova a ausência de erros, apenas a existência dos

mesmos;

b) bons casos de teste são aqueles que encontram falhas no sistema até então não

descobertas;

c) bons casos de teste são projetados levando em conta os requisitos do projeto;

d) um critério que pode ser adotado para determinação do esforço a ser gasto na

atividade de teste de software é verificar qual o grau de severidade das

conseqüências ocasionadas pelo seu mau funcionamento;

e) a probabilidade de encontrar um erro numa determinada parte do sistema é

proporcional ao número de erros já encontrados nesta parte;

f) o nível de esforço previsto para testes deve levar em consideração a

integridade e criticidade do projeto, o custo por mau funcionamento, os

requisitos de qualidade e acurácia especificados.

g) os autores estudados em sua maioria, concordam que os programas devem,

preferencialmente, ser testados por pessoas que não estão envolvidas no

processo de desenvolvimento, mas sim por uma equipe independente. Pode

ocorrer também a interação dos desenvolvedores com a equipe independente,

justificando as decisões tomadas durante o projeto, ajudando também na

revisão do projeto.

Testes desafiam as suposições, riscos e as incertezas e trata-as por meio de

demonstrações concretas e avaliações imparciais, evitando abordagens que não avaliem o

software de forma adequada e efetiva, expondo os problemas e pontos fracos e, não

abordagens negativas ou destrutivas (PERES, R.; NOGUEIRA, A. R., 2004).

Para que testes de software possam ser aplicados, na busca de atingir os objetivos e

princípios da atividade conforme já descritos acima, foram ao longo do tempo criadas e

aperfeiçoadas metodologias que descrevem as melhores práticas para “testar software”, como

se analisará.

2.4.1.1 Termos usuais:

COQ - Cost of Quality, custo gasto em atividades relacionados ao processo de garantia

de qualidade. O COQ inclui o custo de prevenção, medição, correção, materiais,

equipamentos, etc.

Caso de Teste - conjunto de passos que descrevem um cenário de teste cuja principal

função é comparar as respostas aos estímulos gerados por esses passos com um resultado

esperado.

Plano de Testes - documento que descreve o escopo das atividades de teste, a

abordagem, os recursos humanos envolvidos, os componentes a serem testados, os prazos

para a execução, riscos, a mitigação dos riscos, etc.

Suite de Testes - indica um conjunto de casos de testes que são agrupados para um

objetivo comum.

Automação de Testes - testes podem ser automatizados por meio da utilização de

ferramentas e frameworks especializados para os tipos de testes a serem realizados.

Bug - representa qualquer tipo de defeito de software.

Debug - processo onde o desenvolvedor depura o programa a fim identificar a causa de

um defeito. Veja Também Bug.

2.4.2 Estratégias de teste

2.4.2.1 Estratégia de testes Bottom-up

Nesse tipo de teste cada módulo ou componente é testado individualmente e, pouco a

pouco, os demais componentes são combinados e testados. Em alguns casos simuladores ou

mocks, são utilizados no lugar dos componentes reais para substituírem componentes que são

necessários, porém ainda não disponíveis.

2.4.2.2 Estratégia de testes Top-Down

Nesta estratégia de teste, a aplicação é testada como um todo do início ao fim do ponto

de vista do usuário final. Ou seja, o sistema é gerado por completo, instalado em um ambiente

pré-determinado e o testador executa os casos de teste, simulando situações de uso reais.

2.4.3 Tipos de Testes

2.4.3.1 Testes Funcionais (Caixa Preta)

Nessa estratégia, os testes são executados por meio do fornecimento de dados de

entrada ao componente ou ao conjunto de programas, que está sendo testado e pela análise do

resultado produzido, porém, sem entendimento ou verificação do processo que produziu o

resultado, utilizado geralmente para verificar uma função completa encontra-se de acordo

com os requisitos especificados.

2.4.3.2 Testes de Configuração, instalação e suportabilidade

Nessa categoria de testes, os testes são executados contra todos os ambientes (hardware

e software) suportados. Para manter uma matriz contendo as plataformas/ambientes

suportadas e o estado da execução dos testes contra essas plataformas/ambientes, ao surgir um

novo sistema operacional ou equipamento de hardware, esta matriz pode ser atualizada, e os

testes aplicados ao novo ambiente operacional.

2.4.3.3 Testes de Integração ou Subsistemas

Nesta estratégia de testes, os diversos sistemas que compõem uma solução de software

são combinados e configurados num ambiente semelhante ao ambiente onde serão usados na

situação real. Dessa maneira é possivel testar o fluxo das operações do começo ao fim do

ponto de vista do usuário final. Também conhecido como Testes de Sistema

2.4.3.4 Testes de Carga, Volume, demanda e contenção

Essa categoria de teste tem a função de aplicar uma carga de operações ou transações

simultâneas contra a aplicação a fim de conferir se a aplicação atende os requisitos de

performance ou resposta.

2.4.3.5 Testes de recuperação de falhas

Classe de testes cuja principal função é avaliar como a aplicação lida com problemas

inesperados e desastres.

2.4.3.6 Testes de Regressão

Essa abordagem tem a função de garantir que os módulos ou componentes da aplicação

que não foram modificadas ainda funcionam corretamente após o programador modificar

alguma outra parte da aplicação.

2.4.3.7 Teste de valores limites

Técnica de teste utilizada para selecionar os dados que farão parte da execução de um

teste por meio dos limites (máximo e mínimos) das entradas e saídas (procedimentos ou

funções) de um componente de software.

2.4.3.8 Teste de unidade ou componente

Os testes de unidade ou de componentes envolvem algumas combinações de testes

estruturais e funcionais, verificando a menor unidade do projeto de software, neste teste os

caminhos mais importantes são testados para descobrirem erros nos fontes dos programas.

2.4.3.9 Testes de Cobertura

São testes realizados para verificar o percentual de abrangencia da qualidade minima

exigida, previamente determinada, usualmente este indice é de 75% a 85% de falhas

descoberta e seneadas antes da entrega ao usuário final, o que depende de muitos fatores,

dentre ele o nível de segurança exigido.

2.4.3.10 Testes de Aceitação

São testes conduzidos de forma que garantam que o programa atinja as necessidades do

usuário final por meio da execução de cenários e dados de testes reais. Veja também Testes

Integrados.

2.4.3.11 Criterios de Aceitação e Falha

Comparação com o resultado esperado de um caso de testes a fim de determinar se o

teste passou ou falhou.

2.4.3.12 Processo de Verificação

Garante que o software está sendo desenvolvido conforme os padrões e processos

definidos pela organização.

2.4.3.13 Processo de Validação (Alfa e Beta)

Garante que o sistema está sendo desenvolvido conforme as definições dos requisitos a

buscando o atendimento das necessidades do cliente.

2.5 Desenvolvimento Orientado por Testes

Com o surgimento de metodologias de desenvolvimento orientadas a objeto, houve a

promoção de uma importante prática de testes: escrevê-los primeiro. O que também promoveu

a refatoração contínua dos programas, isso para que os códigos destes programas sejam

escritos com maior qualidade, com maior clareza e menos duplicidade.

Muitas obras atuais de literatura sobre a programação orientada a objetos, sejam para

qual for à metodologia aplicada, apóiam a abordagem de Test-Driven Development

(Desenvolvimento Orientado por Testes ou DDT).

Na abordagem DDT para programas orientados a objetos, os códigos de testes são

escritos antes de a classe ser testada e o desenvolvedor escreve os códigos de teste para cobrir

a maior parte possível do código de produção (LARMAN, 2007).

2.5.1 Vantagens da abordagem DDT:

• Testes de unidade são realmente escritos - Geralmente os programadores

evitam escrever testes unitários, deixando a atividade em segundo plano, nesta

abordagem, o teste unitário é o ponto de partida para o programador realizar o

desenvolvimento.

• Satisfação do programador que conduz à escrita de testes mais

consistentes – O programador se sente desafiado “psicologicamente” a

escrever o código de programas para que estes “passem nos testes” , deixando a

sensação de meta alcançada,

• Clareza de interface e comportamento detalhado – A prática de detalhar o

comportamento de uma classe (unidade de programa) sem que a mesma exista,

ou partes ainda não existam, força ao programador ou analista que ele pense

em cada detalhe do código que esta para construir, e esse raciocínio promove

melhoras e esclarece detalhes de projeto, que podem inclusive originar

solicitações de mudança de projeto por prever detalhes que poderiam ser pegos

apenas em fases mais tardias de testes, o que comumente acontece em projetos

em que a abordagem não é utilizada.

• Verificação provável, repetível e automatizada – À medida que se vão

construindo códigos de testes, estes vão sendo acumulados e podem ser

utilizados para verificação e correções de uma forma significativa. Podem-se

aplicar os testes construídos de forma que seja possível a regressão, e

verificação da evolução de um componente ou até do programa em seu estágio

atual de programação e a aplicação pode ser realizada de forma automatizada,

o que justifica o investimento inicialmente penoso em escrever os testes

antecipadamente.

• Assertividade e Confiança – Ao modificar um código de programa existente,

pode-se aplicar os testes preexistentes, para verificar se a manutenção do

código, causou impacto ou erro, fornecendo uma resposta mais rápida para

ajustar o programa (LARMAN, 2007).

2.6 Considerações sobre o capítulo

Nesse capítulo foram apresentados os principais conceitos e padrões utilizados por

serviços web na concepção de sistemas. Esses padrões são caracterizados pela independência

de plataforma de hardware e software, proporcionando maior abertura aos sistemas que

utilizem SOA. Além dos padrões e especificações tais como SOAP, WSDL e UDDI, que

formam a base dos serviços web, foram apresentados também os principais desafios

encontrados pelas empresas e por suas equipes de TI no que tange a utilização de sistemas

baseados em SOA, bem como os principais conceitos de teste de software de maneira a

produzir o entendimento básico para que se possa testar um sistema produzido utilizando a

abordagem SOA.

Para as empresas que produzam baseados em SOA que, como se demonstrou nos

capítulos anteriores, é muito recente, sugere-se que se definam estratégias para a padronização

de procedimentos principalmente de desenvolvimento dos programas e de sua documentação,

bem como de testes que sejam aplicáveis a estes programas ou sistemas, para a promoção de

melhorias tanto do produto final como do ambiente de trabalho conforme apresentou-se no

tópico “Desenvolvimento Orientado por Testes”.

Desta forma, obtém-se um ganho na redução da manutenção, e conseqüentemente

redução nos custos com testes e retrabalhos, pois através das técnicas abordadas nos capítulos

anteriores, ao se reutilizar os cenários de teste e verificar os erros que um conjunto de

programas integrados através de SOA possa apresentar logo na sua fase inicial de construção,

obtendo-se então um número maior de programas a se manter funcionando durante o processo

de construção, sendo que a cada nova iteração no processo de desenvolvimento, ou

manutenção, os testes já aplicados podem ser reaplicados, para a melhoria e refinamento,

contínuos dos programas gerados.

As empresas que utilizam sistemas baseados em SOA também podem se beneficiar de

igual maneira, visto que suas equipes de TI, podem produzir cenários de testes a partir das

técnicas de testes apresentadas e antes de colocar um sistema em produção, verificar se o

mesmo atende as necessidades de determinado departamento ou negócio.

A seguir, será apresentado um caso pratico da aplicação de procedimentos de testes,

planejados e de uma ferramenta de testes a um sistema que utilizam componentes SOA em

sua infra-estrutura.

3 RESULTADOS E DISCUSSÕES

Na maioria das bibliografias pesquisadas não foi abordado o assunto “como testar

SOA”, as bibliografias pesquisadas mostram que basicamente a forma de testar depende da

ferramenta utilizado para o teste e reportam apenas os conceitos básicos de testes ou de SOA,

não há uma referência conclusiva a qual se possam apoiar e embasar práticas de teste de

software nesta tecnologia.

Foram pesquisadas ferramentas que pudessem auxiliar na tarefa de testar a arquitetura

orientada a serviços, porém muito poucas referências foram obtidas.

Durante a pesquisa encontraram-se as seguintes ferramentas: Compuware DevPartner

Studio, SoapUI (Eviware), TestMaker 5.0 (PushToTest), Peta (Verit), LiSA (iTKO), SoapTest

(ParaSoft), Fault Factory (ExtraData), SOAPSonar (Crosscheck Networks), TestComplete

(AutomatedQA).

Para a prática e aplicação dos testes de software sobre o software componentizado,

utilizando a tecnologia SOA (CRM), foram seguidas metodologias de teste conforme as

sugeridas e verificadas na revisão bibliográfica deste trabalho.

Utilizou-se dos artefatos de plano de testes, casos e cenários de testes, e o relatório de

aprovação da execução dos testes.

Para a execução dos procedimentos utilizou-se a seguinte técnica:

Observaram-se os requisitos de testes presentes no banco de requisitos, a partir destes

foi gerado o plano de testes (vide Apêndice I), com o objetivo de registrar a estratégia de

testes a ser adotada, para a coordenação e condução dos testes, os níveis de teste a serem

abordados, os tipos de teste a serem executados, o escopo de requisitos a ser testado, as

ferramentas e ambientes empregados nos testes e os critérios de conclusão e aceitação dos

testes.

No projeto de teste também definiu-se os requisitos a serem testados, as categorias de

testes, os tipos de testes bem com a priorização dos mesmos onde delimitou-se o escopo de

testes para definir com precisão o que será coberto pelo teste e também o que não será

coberto, bem como as ferramentas utilizadas para a realização dos cenários de teste.

Os defeitos da solução encontrados pelos testes foram registrados em planilha de testes

e medição de qualidade dos testes realizada através dos indicadores: densidade de falha e

eficácia de testes, no decorrer do trabalho.

Outro artefato utilizado para a execução de testes é o documento de projeto de testes

(vide Apêndice II) que contém as orientações de validação e ambiente devem ser atendidas na

execução dos requisitos de testes do projeto. Um requisito de teste contém informações gerais

que determinam como testes anteriormente especificados pelo plano de testes devem ser

conduzidos.

A execução dos testes realizou-se aplicando-se os testes descritos no plano e projeto de

testes sobre produto CRM na versão 2.7 Release 24 que na sua infra-estrutura utiliza o

produto Microsoft® Soap Toolkit e o servidor de aplicações Jboss™ 4.0.4 com o modulo Axis

1.1 para as transações web service de SOA utilizando o protocolo SOAP.

Como ferramenta de testes dentre as pesquisadas para o estudo optou-se por utilizar o

“SOAPUI” na versão 3.0.1 Open Source, da empresa Eviware, os critérios de escolha para se

chegar à opção se deram pela leitura dos descritivos das ferramentas, onde estavam

informadas a cobertura e os processos que poderiam ser verificados, foram levados em

consideração a adequação da ferramenta a linguagem de programação, pois algumas das

escolhidas se aplicavam apenas a determinadas linguagens e deste modo foram descartadas; a

portabilidade, ou seja, possibilidade de execução em diversos sistemas operacionais; e

principalmente pelo fator preço, já que a maioria das ferramentas pesquisadas é proprietária e

exige licenciamento para o uso, cujo tempo para uso é limitado entre 15 a 30 dias tempo

insuficiente para a pesquisa.

3.1 Experimentos

Esta seção apresenta a descrição de alguns experimentos realizados com o objetivo de

avaliar as funcionalidades da implementação da camada SOA de um software de CRM, sendo

que o serviço utilizado tem a característica de devolver mensagens SOAP com a resposta de

desafio, verificando se o usuário tem a permissão para acessar determinado registro de um

cliente.

A Figura 6 demonstra o ambiente de execução dos testes.

Figura 6 – Ambiente de execução dos testes – Fonte: Dos Autores (2009).

O teste foi realizado, de maneira a importar os arquivos descritores dos serviços a serem

testados. Para a amostra, utilizou-se o serviço Team_OpportunityTeam cujo descritor e a

documentação do serviço foram utilizados para a realização dos testes mencionados.

A partir da importação do arquivo e os métodos do serviço exposto como demonstra a

Figura 6, pôde-se criar requisições com o intuito de obter as respostas dos métodos, a

ferramenta por si cria requisições de exemplo, porém de difícil entendimento, foi necessário

recorrer à documentação e ao monitor HTTP da ferramenta para que fosse possível entender

como as requisições e respostas eram trocadas no uso do aplicativo CRM.

Após a compreensão mínima do uso dos métodos, puderam-se criar requisições HTTP

que obtivessem os retornos. Durante os ensaios, aplicaram-se aos métodos parâmetros

incorretos e ou vazios, como demonstra o Quadro 1.

Quadro 1 – Requisição SOAP Com paramentos incorretos.

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:opp="http://opportunityteam.team.xxcrm.crm.xxxx.com">

<soapenv:Header/>

<soapenv:Body>

<opp:verifyHierarchyTeamAccess

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<in0 xsi:type="dat:valueObject" xmlns:dat="http://www.xxxx.com">

<Map xsi:type="x-:Map" xmlns:x-="http://xml.apache.org/xml-soap">



<item xsi:type="x-:mapItem">

<key xsi:type="xsd:string">?</key>

<value xsi:type="xsd:string">?</value>

</item>

</Map>

</in0>

<in1 xsi:type="xsd:int">?</in1>

<in2 xsi:type="xsd:int">?</in2>

</opp:verifyHierarchyTeamAccess>

</soapenv:Body>

</soapenv:Envelope>

“Cujos parâmetros incorretos, ou em branco, causaram respostas de falha A falha

apresentada no Quadro 2, tem como causa a passagem de uma string “?” onde se espera um

inteiro, identificada na resposta da requisição pela ferramenta de testes:

Quadro 2 – Resposta de Requisição SOAP Incorreta.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<soapenv:Fault>

<faultcode>soapenv:Server.userException</faultcode>

<faultstring>java.lang.NumberFormatException: For input string:

"?"</faultstring>

<detail/>

</soapenv:Fault>

</soapenv:Body>

</soapenv:Envelope>

Aplicou-se também, parâmetros que apresentavam a resposta da requisição como

correta, como a requisição conforme o demonstrado no Quadro 3, realizada para o método

verifyAccountAcces que realiza a verificação ao perguntar ao servidor se determinado usuário

cujo código é “1” possui acesso a determinado cliente cujo seu código é “19410” além da

localização do usuário para identificar seu idioma.

Quadro 3 – Requisição correta ao método verifyAccountAcces.

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"


xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:opp="http://opportunitycrud.opportunity.xxcrm.crm.xxxx.com">

<soapenv:Header/>

<soapenv:Body>

<opp:verifyAccountAccess

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<in0 xsi:type="dat:valueObject" xmlns:dat="http://www.xxxx.com">

<Map xsi:type="x-:Map" xmlns:x-="http://xml.apache.org/xml-soap">




<key xsi:type="xsd:string">resourceId</key>



<value xsi:type="xsd:int">1</value>

</item>




<key xsi:type="xsd:string">resourceType</key>



<value xsi:type="xsd:string">1</value>

</item>




<key xsi:type="xsd:string">locale</key>



<value xsi:type="xsd:string">"pt"</value>

</item>

</Map>

</in0>



<in1 xsi:type="xsd:int">1</in1>

<in2 xsi:type="xsd:int">19410</in2>

</opp:verifyAccountAccess>

</soapenv:Body>

</soapenv:Envelope>

Como resposta apresentada no Quadro 4, a requisição do serviço obteve a expressão

“true” o que identifica que o usuário tem acesso a conta solicitada e pode verificar suas

oportunidades.

Quadro 4 – Resposta a requisição ao método verifyAccountAcces, permitindo o acesso.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<ns1:verifyAccountAccessResponse

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:ns1="http://opportunitycrud.opportunity.xxcrm.crm.xxxx.com">

<ns1:verifyAccountAccessReturn href="#id0"/>

</ns1:verifyAccountAccessResponse>

<multiRef id="id0" soapenc:root="0"

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xsi:type="ns2:return" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:ns2="http://www.xxxx.com">

<data xsi:type="xsd:boolean">true</data>

</multiRef>

</soapenv:Body>

</soapenv:Envelope>

A Figura 7 exemplifica o uso da ferramenta SOAPUI para a realização do teste acima

descrito.

Figura 7 – Ambiente de execução dos testes II – Fonte: Dos Autores (2009).

3.2 Considerações sobre o capítulo

A ferramenta de testes que utilizou-se na aplicação dos testes SoapUI, como já

abordamos, é uma ferramenta open source escrita em Java cuja principal função é consumir e

testar web service. Neste contexto, o SoapUI facilita todo o processo de criação e depuração

dos testes por meio de uma interface gráfica visual e intuitiva. Dentre as suas principais

características, podemos destacar as seguintes:

a) instalação simples e fácil;

b) ampla documentação (no site);

c) importação e geração automática das requisições descritas no WSDL;

d) capacidade de gerenciar um número ilimitado de requisições para cada operação;

e) gerenciamento de múltiplo endpoints reference (uma entidade, recurso ou processador

para onde as mensagens dos Web services são encaminhadas) para cada web service;

f) validação das requisições e respostas contra as suas definições no WSDL;

g) possibilita testes funcionais, de carga e stress;

h) execução de diversos procedimentos de testes em paralelo;

i) editores com realce de sintaxe e formatação automática;

Identificamos como ponto fraco da ferramenta, a manutenção dos cenários de testes

devido a atualização da ferramenta durante a fase de experimentação (iniciamos com a versão

1.9 e concluímos com a 3.0.1) , que não mais eram executados em razão da troca dos padrões

de protocolo imposta pela evolução do mesmo pelo W3C, a ferramenta deveria prever este

tipo de situação e validar as tags dos arquivos informando a restrição, fato que não ocorreu,

provocando erros de análise do resultado esperado.

A ferramenta atendeu-nos no processo de teste unitário e funcional de web services, que

tinnhamos como objetivo nesta pesquisa.

Ainda, para a execução de outros tipos de teste, caso se deseje aplica-los, faz-se necessária a

análise de outras ferramentas para a montagem de um framework para os demais tipos de

testes que possam ser aplicados.

4 CONCLUSÕES E RECOMENDAÇÕES

Os testes com a ferramenta indicada, apresentaram as mesmas dificuldades do processo

de testes anteriormente aplicado ao CRM, e de como testar melhor uma aplicação, ou seja,

tempo para aprendizagem, capacitação, e complexidade, porém serviram para um melhor

entendimento do conceito de SOA.

A principal dificuldade enfrentada foi que a documentação dos serviços expostos não

existia. Este fato deve-se a forma de implementação do aplicativo CRM, que foi construído de

modo a que o seu código fonte fosse fechado, ou seja, aplicação proprietária, com a exposição

de web service, porém sem a documentação técnica de sua implementação de tal modo que na

tentativa de obter o entendimento, utilizou-se da extração de documentos da ferramenta

SoapUI, como indicado no tópico “Resultados e Discussões”, diferentemente de outros

serviços em que foi possível contato durante a execução do trabalho como “Google SOAP

Search API” cujo uma ampla documentação de implementação e uso esta disponível

(GOOGLE, 2009) e Flickr, sendo esta, disponível em português (FLICKR, 2009).

Chegou-se a conclusão, portanto, de que a ferramenta SoapUI não seria a mais indicada

no momento para a execução dos testes unitários que foram propostos.

Ainda durante a pesquisa, verificou-se a descontinuidade do aplicativo CRM, devido à

mudança de modelo de produção de software adotado pelo contratante, para a construção de

um novo aplicativo em nova arquitetura.

Portanto concluiu-se que os testes sugeridos, bem como a ferramenta e o modelo não

seriam mais aplicáveis.

Durante a execução deste trabalho, e em paralelo a ele, houveram discussões e

pesquisas por parte de outros integrantes da equipe de auditoria e testes da empresa onde este

trabalho estava sendo aplicado, e nestas também se buscavam outras ferramentas alternativas,

para os testes não só da aplicação a que se propõe este trabalho, mas para as outras aplicações

em que a equipe de testes aplica a auditoria.

Como resultado da pesquisa feita por parte dos integrantes da equipe de auditoria, foi

contratada uma consultoria especializada para delimitar o escopo mais amplo para a aplicação

de testes a todos os aplicativos produzidos em nossa empresa, e que durante o 2° Seminário

Catarinense de Qualidade e Teste de Software ocorrido entre os dias 10 a 12 de Setembro de

2009, da qual fomos participantes, culminou na escolha por parte da empresa de uma das

ferramentas citadas em nosso trabalho, chamada TestComplete da empresa AutomatedQA, e

na qual a equipe de testes e auditoria será treinada para o uso.

Como trabalho futuro propõe-se o estudo de aplicabilidade da ferramenta elegida pela

equipe de auditoria e testes da empresa ao novo produto de software CRM, proposto pelo

contratante, com a ferramenta escolhida pela empresa para os testes.

4.1 Considerações Finais

Por fim, este trabalho possibilitou um aprendizado abrangente em diversos aspectos

referentes a SOA, web service e testes de software, possibilitando que os conhecimentos

adquiridos fossem repassados para a equipe da empresa onde este foi realizado.

Foi possível verificar que testes em componentes SOA que não tiveram sua

documentação devidamente gerada durante os processos de análise e desenvolvimento, geram

enormes dificuldades para a área de testes, consumindo o mais importante e escasso de todos

os recursos: tempo.

A importância de que a ferramenta de testes e métodos de testes que serão aplicados ao

produto final sejam definidos já no início do processo de desenvolvimento foi confirmada.

Isto sendo realizado, ganha-se tempo e maior assertividade em todas as etapas de construção

de um software.

REFERÊNCIAS

AREVOLO, W. Business Process Management Scenario: The Future of BPM Suites. São Paulo: Gartner, 2006. BASS, CLEMENTS, KAZMAN. Software Architecture in Practice (2nd edition). EUA: Addison-Wesley, 2003. BEIZER, B. “Software testing techniques.” 2nd ed. New York: Van Nostrand Reinhold Company, 1990. BENEDETE Junior, Antonio Carlos. Roteiro para a definição de uma arquitetura SOA utilizando BPM. - Monografia (MBA em Tecnologia da Informação) - Escola Politécnica da Universidade de São Paulo - São Paulo, 2007. BIEBERSTEIN, N. et al. Service Oriented Architecture (SOA) Compass. NJ, EUA: IBM, 2006. CHANG, J.: RICHARDSON, D. J. “Structural Specification-Based Testing: Automated Support and Experimental Evaluation”. France: Proceedings of the 7th European Software Engineering Conference(ESEC/FSE’99), 1999. GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999. GIL, Antonio Carlos. Como elaborar projetos de pesquisa. São Paulo: Atlas, 2002. HURWITZ, J. et al. Service Oriented Architecture for Dummies. EUA: Wiley, 2007. LAKATOS, E. M. e MARCONI, M. A. Fundamentos da Metodologia Científica. 5a. ed. São Paulo: Atlas, 2003. LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo / Craig Larman; tradução Rosana Vaccare Braga ... [et al.] – 3ª. ed. – Porto Alegre : Bookman, 2007 LINNENKUGEL, U.; MÜLLERBURG, M. “Test data selection criteria ofr (software) integration testing”. In: First Integrational Conference on System Integration, Morristown, NJ, 1990, p. 709-717. MYERS, G. “The Art of Software Testing.”. New York: John Willey & Sons, 1979. 170 p. NATIS, Y. Predicts 2007: SOA Advances. EUA: Gartner, id: G00144445, Novembro de 2006. NIELSEN, J. “ Usability Engineering”. AP Professional, Mountain View EUA, 1993. 362 p. NEMETZ, F.; Winckler M. A. A.; de Lima, J. V. “Evaluating Evaluation Methods for Hypermedia Applications”. Short Paper publicado na seção Poster no Proceedings em CD-ROM do ED-MEDIA & ED-TELECOM. Calgary, CA, 1997.

PERES, R.; NOGUEIRA, A. R. - Estudo Comparativo de Ferramentas para Automação de Testes de Software - Monografia de Pós-graduação em Engenharia de Software – UNIFIL, 2004. PRESSMAN, ROGER. S. “Engenharia de Software”. São Paulo: Makron Books, 1995. PRESSMAN, ROGER S. - “Engenharia de Software”, - Software Engineering – A Practitioner’s Approach – 6th edition. - Tradução Rosangela Delloso Penteado, revisão técnica Fernão Stella R. Germano, José Carlos Maldonato, Paulo César Masiero. 6.ed. – São Paulo : McGraw-Hill, 2006. ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. (Ed.). Qualidade de software: teoria e prática. São Paulo: Prentice-Hall, 2001. 303 p. SILVA, A. M. R.; VIDEIRA C. A. E. UML, Metodologias e Ferramentas CASE - Linguagem de Modelação UML, Metodologias e Ferramentas CASE na Concepção e Desenvolvimento de Software - Edições Centro Atlântico - Porto Lisboa – Portugal, 2001 SITES: GOOGLE. “Google SOAP Search API”, Disponivel em: http://code.google.com/intl/pt-BR/apis/soapsearch/api_faq.html, Acessado em: Julho (2009). IEEE. IEEE 829- 1998 e IEEE 730-1998, Disponível em: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=741968&isnumber=16010 Acessado em: Setembro (2009) FLICKR. Serviços do Flickr – Documentação API, Disponivel em: http://www.flickr.com/services/api/, Acessado em: Julho (2009). MANES, Anne Thomas. “SOA is dead; Log life Services” - Burton Group Disponível em: http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html, Acessado em: Setembro (2009)

NEXTG. NEXT GENERATION CENTER “SOA – Service Oriented Architecture”,

Disponivel em: http://www.nextg.com.br, Acessado em: Julho (2009).

NETBEANS. NETBEANS COMMUNITY “Guias de aprendizado para aplicativos SOA e

modelagem UML”, Disponível em: http://www.netbeans.org/kb/trails/soa_pt_BR.html,

Acessado em: Julho (2009).

SOA-RM. “SOA-RM v1.0 OASIS Standard Portuguese (Brazil)”; Escola Politécnica da

Universidade de São Paulo — Brazil - http://www.pcs.usp.br/%7Epcs5002/oasis/soa-rm-

csbr.pdf, acessado em Setembro (2009).

ZACHMAN. Zachman Institute for Framework Advancement (ZIFA), Disponível em: http://www.zifa.com/, acessado em Agosto (2008).

APÊNDICES

APÊNDICE I

PLANO DE TESTES

Plano de Testes

Cliente: Interno

Fornecedor: Interno

Projeto: CRM – Aplicação de Testes a camada SOA

Histórico de Alterações

Data Versão Descrição Autor

07/2009 1.0 Criação de Documento Israel/ Rodrigo

Conteúdo

1 Introdução .............................................................................................................................59 2 Estratégia de Testes ..............................................................................................................60

2.1 < ESCOPO – EX.: IPP XXX >......................................................................................60 3 Gestão de Testes ...................................................................................................................67

3.1 REGISTRO DE RESULTADOS ..................................................................................67 3.2 MODELOS DE AUDITORIA ......................................................................................67 3.3 REGISTROS DE DEFEITOS .....................ERRO! INDICADOR NÃO DEFINIDO.

4 Software – Ferramentas de Testes.......................................................................................68 4.1 FERRAMENTAS..........................................................................................................68

5 Cronograma...........................................................................................................................68 6 Referências............................................................................................................................68

Introdução

Este documento define o Plano de Testes do projeto CRM – Aplicação de Testes a camada

SOA, com o objetivo de registrar a estratégia de testes a ser adotada. Isto possibilitará uma bem-sucedida coordenação e condução de testes no projeto.

Estratégia de Testes

Fluxo de Auditoria O fluxo básico de auditoria a ser seguido nos desenvolvimentos esta ilustrado abaixo, e importante destacar que este fluxo é o padrão de desenvolvimento, porém, de acordo com os riscos particulares de cada projeto, tanto novos processos podem ser inseridos no fluxo como alguns processos podem ser retirados conforme exceções que estiver descritas neste Plano de Testes.

Processo de Auditoria de Fontes/Arquitetura – Nível 1

Esta auditoria deverá apenas iniciar quando os testes de programação foram realizados pelo programador e, a atividade foi liberada para a auditoria anexada dos seguintes documentos e registros específicos deste serviço:

- Números dos pacotes da atividade gerados pelo Sistema Compilador em todos os ambientes disponíveis.

- Check-list de construção preenchido.

- Listagem resultante da execução de uma ferramenta de testes de caixa branca.

Caso os documentos necessários descritos acima para o serviço de construção não estiverem anexados, a auditoria deverá ser reprovada pelo auditor de fontes. O tipo de erro a ser

registrado para este erro com origem “construção” deverá ser “DoctInad” = Documentação Inadequada. Caso os documentos necessários estiverem anexados ao serviço, o auditor de fonte deverá primeiramente avaliar nestes anexos: - Se o check-list de construção foi preenchido de acordo com a necessidade do

desenvolvimento em questão. - Se a listagem de ferramenta de caixa branca não apresenta erros pertinentes ao

desenvolvimento realizado. - Verificar se o pacote da atividade foi gerado pelo Sistema Compilador, confirmando que

não houve erros de compilação nos programas alterados. Caso estes anexos não estiverem de acordo, o auditor de fontes deverá reprovar a auditoria registrando os erros encontrados. Caso os anexos estiverem de acordo, o auditor deverá: - Analisar os códigos alterados e desenvolvidos verificando se as melhores técnicas de

programação foram seguidas; - Verificar se o código está de acordo com o solicitado no desenvolvimento, respeitando

principalmente as releases solicitadas para o desenvolvimento; - Verificar se os padrões dos templates foram seguidos conforme manuais de padrões de

programação (códigos e interfaces); - Analisar a arquitetura dos principais objetos desenvolvidos ou alterados para analisar:

� Se a estrutura de código é de fácil manutenção; � Se o mesmo código (regra) não foi duplicado em mais de um local do sistema; � Se a alteração do código respeitou a integração do mesmo com outros dados externos

(objetos, módulos, aplicativos); � Se a alteração realizada respeita as limitações dos bancos de dados Oracle e SQL; � Se métodos desnecessários foram inclusos; � Se problemas específicos foram resolvidos em soluções genéricas; � Se houve evoluções em API´s, será verificado se a evolução é necessária e, caso for,

será analisado se os procedimentos padrões foram aplicados; � Se foi desenvolvido o programa de conversão ou acerto na base de dados; � Se as alterações realizadas não causaram impacto negativo na performance das rotinas

envolvidas; � Se nos desenvolvimentos realizados foram utilizadas as melhores técnicas de

programação para melhor performance: acesso a registros, utilização de índices,... Em caso de não OK (quantidade de falhas impacta na qualidade do teste ou existe algum erro que impede a continuação do teste), a atividade retornará para o programador para ajustes. O auditor de fontes deverá registrar os erros antes da reprovação da atividade observando a classificação dos erros encontrados conforme descrito mais abaixo neste documento, no tópico “Registro das Falhas” Os erros básicos deverão ser registrados como um tipo de erro “PRoIncor” = Procedimento Incorreto e, deverão ter como origem o processo de “construção”. Para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros Básicos” neste documento. Uma vez que todas as falhas estiverem solucionadas, o auditor deverá dar o OK da auditoria de fontes.

Em caso de OK, a atividade será transferida para a auditoria de negócio. Fluxo do Processo

Processo de Auditoria de Negócio - Nível 2 Esta auditoria deverá apenas iniciar quando a auditoria de fontes/arquitetura foi realizada e, este nível de auditoria foi aprovado (auditoria OK). A auditoria de negócio consiste na execução de todos os cenários de testes informados no documento engenharia da função em desenvolvimento (vide projeto de testes), além da execução dos testes automatizados caso existentes para as rotinas alteradas. As falhas encontradas por esta auditoria deverão ser registradas observando a classificação dos erros encontrados conforme descrito mais abaixo neste documento, no tópico “Registro das Falhas”. Caso a não-conformidade resultar na necessidade de se parar os testes, seja pela quantidade de erros encontrados que impactam diretamente na qualidade do teste, ou seja, por uma situação que impede que os testes sejam continuados, a atividade deverá ser reprovada para que os ajustes necessários sejam realizados – ver tópico “Processo de Retorno da Atividade para Construção”. É importante salientar que os erros básicos deverão ser registrados como um tipo de erro “PRoIncor” = Procedimento Incorreto e, deverão ter como origem o processo de “construção”. Para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros Básicos” neste documento. Uma vez ajustados os erros (retorno da atividade para o auditor), fica a cargo do auditor executar novamente todos os testes necessários, e em caso de problema não corrigido devolver a atividade para a construção. Uma vez que não foram mais encontradas falhas, o auditor deverá dar o OK da auditoria de negócio. Quando dado OK na auditoria de negócio a atividade deverá ser transferida para a auditoria de validação. Fluxo deste processo

Processo de Validação do Artefato - Nível 3 Esta auditoria deverá apenas iniciar quando a auditoria de negócio foi realizada e, este nível de auditoria foi aprovado. A validação, realizada pelo analista responsável pelo desenvolvimento, consiste na execução de testes genéricos aleatórios (testes exploratórios) considerados como importantes por este auditor. Estes testes são voltados à análise da funcionalidade para verificar se os requisitos funcionais do desenvolvimento estão de acordo com o que foi solicitado pelo cliente (usuário final ou gerente de produto responsável). O validador também deverá atualizar a planilha de testes com os erros encontrados por este nível de auditoria. As falhas deverão ser registradas observando a classificação dos erros encontrados conforme descrito mais abaixo neste documento, no tópico “Registro das Falhas”. É importante salientar que os erros básicos deverão ser registrados como um tipo de erro “PRoIncor” = Procedimento Incorreto e, deverão ter como origem o processo de “construção”. Para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros Básicos” neste documento. Uma vez que não foram mais encontradas falhas, o auditor deverá dar o OK da auditoria de validação. Quando dado OK na auditoria de validação, a atividade será encerrada e transferida para a auditoria de quality. Fluxo deste processo

Processo de Quality - Nível 4 Esta auditoria, que será realizada pela Equipe de Testes, e ocorrerá apenas na liberação do ambiente de Quality da OS, onde o desenvolvimento (atividade) foi vinculado. Esta auditoria possui como objetivo executar os testes automatizados caso existentes com o intuito de executar testes regressivos por pacote.

Caso a auditoria esteja OK, o auditor registrará este OK, caso contrário, os erros encontrados deverão ser registrados e, esta auditoria será reprovada, sendo então esta atividade replanejada para outra OS.

Fluxo deste processo

Conceito: Erros Básicos

Caracteriza-se como erro básico todo aquele que pode ser identificado nos testes do programador, não sendo necessário o conhecimento das regras de negócio envolvidas.

Consideram-se erros básicos: • Erros de compilação: independente do ambiente – utilizar sistema compilador; • Erros apresentados na interface (ambiente solicitado para teste no tópico “Cenários

de Testes” da engenharia): erros na execução do programa e, erros encontrados através da execução do check-list de programação, tópico “Verificações de Interface”;

• Erros de programação, como por exemplo, situações onde a engenharia solicitava gravar em um determinado campo e o programa grava em outro;

• Erros encontrados através da utilização das ferramentas de caixa branca, desde que estes erros forem ocasionados pelo desenvolvimento em questão.

4.1.1.1 Fase: Construção

Caracteriza-se como erro com origem na construção: - Erros básicos: para verificar o conceito de erro básico, consultar o tópico “Conceito: Erros

Básicos” neste documento. - Erros identificados a partir da execução dos cenários de testes descritos no projeto de

testes: • Erros detectados pela simples utilização dos cenários de testes; • Erros de resultado, quando previsto na regra de negócio e no diagrama de ação da

engenharia; • Erros de programação, quando identificados a partir da verificação de um cálculo ou

regra de negócio específica. • Problemas de performance identificados pela forma que o programa foi desenvolvido. • Erros de menu, desde que disponibilizadas na engenharia as alterações a serem

realizadas. • Erros de arquitetura: analisar checagens realizadas pela auditoria de arquitetura

descritas acima neste documento.

4.1.1.2 Fase: Especificação

Caracteriza-se como erro com origem na especificação, todo aquele que é identificado a partir de testes extras não previstos nos cenários de testes e, que a engenharia não previu em seu desenvolvimento (regras de negócio e diagrama de ação) porém, estava dentro do escopo da função. É importante destacar que alguns erros podem possuir as mesmas características (tipos) que outros porém, foram originados por fases diferentes do processo. Seguem exemplos de erros com origem na fase de especificação:

� Erros de resultado, quando utilizada a troca de parâmetros de módulos ou programas;

� Erros de resultado em outro módulo ou programa; � Situações identificadas em outras partes do produto ocasionadas pelos resultados

gerados pela implementação. � Sugestões de melhorias do programa ou função, como também de usabilidade do

programa. � Problemas de performance identificados pela forma que o dicionário foi definido

na engenharia. � Erros de menu, desde que não disponibilizadas na engenharia as alterações a serem

realizadas.

4.1.1.3 Fase: Requisitos

Caracteriza-se como erro com origem em requisitos, todo aquele que é identificado a partir de testes extras não previstos nos cenários de testes e, que a engenharia não previu em seu desenvolvimento (regras de negócio e diagrama de ação) e, o escopo do projeto também não previu. É importante destacar que alguns erros podem possuir as mesmas características (tipos) que outros porém, foram originados por fases diferentes do processo. Seguem exemplos de erros com origem na fase de especificação:

� Erros de resultado, quando utilizada a troca de parâmetros de módulos ou programas;


gerados pela implementação.

4.1.1.4 Fase:Testes

Caracteriza-se como erro com origem em testes, todo aquele que é identificado a partir de testes extras não previstos nos cenários de testes porém, a engenharia prevê esta alteração em seu desenvolvimento (regras de negócio e diagrama de ação). É importante destacar que alguns erros podem possuir as mesmas características (tipos) que outros porém, foram originados por fases diferentes do processo. Seguem exemplos de erros com origem na fase de testes:

� Erros de resultado, quando utilizada a troca de parâmetros de módulos ou programas ou releases;


gerados pela implementação.

Fluxo dos Retrabalhos

O líder do projeto, ao receber o retorno da atividade deverá reportar as falhas através de e-

mail para os responsáveis conforme abaixo: � Programadores envolvidos (Erros com origem na construção); � Engenheiro responsável (Erros com origem em requisitos e especificação); � Engenheiro de teste responsável (Erros com origem em testes).

Cada responsável, após análise das falhas com origem em sua fase, deverá reportar para o líder do projeto o que deverá ser realizado para resolver a falha em questão. O líder do projeto encaminhará o ajuste conforme solicitado pelos responsáveis para os programadores para que as alterações necessárias sejam realizadas. Durante as correções, deverão ser executados todos os processos novamente do desenvolvimento Após ajuste dos erros encontrados, a atividade deverá ser retornada para a auditoria informando, para cada falha, o parecer do ajuste realizado.

Fluxo deste processo

IPP – Oportunidades O escopo de teste engloba todas as funções do produto padrão previstas no projeto

Nível Teste Tipo de Testes Execução Release Ambiente ( x ) Unidade ( x) Estrutural / Caixa Branca

( ) Interface ( x) Manual ( ) Automático

2.7

( x ) Integração ( x ) Funcional / Caixa Preta ( ) Regressão

( x ) Manual ( ) Automático

( ) Sistema (Quality)

( ) Regressão ( ) Manual ( ) Automático

( ) Sistema (Alfa)

( ) Estresse/Carga ( ) Recuperação de Falhas ( ) Smoke Test ( ) Segurança/Controle Acesso ( ) Configuração/Instalação ( ) Performance ( ) Integridade de Dados ( ) Funcional ( ) Conversão (Alterar Guia)

( ) Manual ( ) Automático

( ) Aceitação (Beta)

( ) Funcional / Caixa Preta ( ) Manual

Windows XP MS SQL Server 2000 JBoss 4.04 Java 1.5 SDK MS SoapToolkit V3

Requisitos Funcionais/Não Funcionais

CRM - Oportunidade Critérios de Conclusão

1) A etapa de teste de sistema só pode iniciar quando 95% dos casos de teste tiverem sido executados e obtiverem exito 2) Os testes serão concluídos quanto todos os requisitos foram testados e os defeitos de criticidade alta e média foram corrigidos.

Gestão de Testes

Registro de Resultados

Os resultados dos testes serão armazenados na mesma planilha que contém seus valores de entrada. Esta planilha é um arquivo Excel (.xls) cujo nome segue o modelo abaixo: ‘PlanilhaTestes[NivelTeste][CódigoDoRequisito][NomeDoProjeto][NúmeroDoBuild].xls’.

Modelos de Auditoria Conforme definido na estratégia de testes.

A medição de qualidade dos testes será realizada através dos indicadores: densidade de falha e eficácia de testes, no decorrer do projeto.

Software – Ferramentas de Testes

Ferramentas Casos de Teste e Planilhas de Teste. SoapUi – para o teste caixa branca na arquitetura SOA

Cronograma

O cronograma detalhado do projeto está disponível em <deve ser inserido um link para o arquivo de cronograma>.

Referências

Documento de Processos de Auditoria de Desenvolvimento

APÊNDICE II

PROJETO DE TESTES

Detalhamento

Execução

de Testes

Cliente: Interno

Fornecedor: Interno

Projeto: CRM – Aplicação de Testes a camada SOA

Histórico de Alterações

Data Versão Descrição Autor

07/2009 1.0 Criação de Documento Israel / Rodrigo

72

Conteúdo

1 Introdução .............................................................................................................................72 2 Orientações ...........................................................................................................................72

2.1 VALIDAÇÃO ...............................................................................................................73 3 Requisitos de Testes .............................................................................................................73

3.1 REQUISITO DE TESTE REUSÁVEL.........................................................................73 3.2 REQUISITO DE TESTE ESPECÍFICOS DO PROJETOERRO! INDICADOR NÃO DEFINIDO.

Introdução

Este documento descreve os requisitos e os procedimentos de teste a serem executados para o projeto CRM – Aplicação de Testes a camada SOA, com o objetivo de definir como os testes especificados no Plano de Testes serão realizados.

Orientações

As orientações de validação e ambiente devem ser atendidas na execução dos requisitos de testes do projeto, conforme descrito a seguir:

73

Validação

Check-list de Testes, Planilha de Testes

� Deverão ser informados, em cada campo disponível nos casos de testes, dados com o tamanho máximo e mínimo permitidos para análise das telas (tamanho dos campos).

� Haver quantidade de registros suficientes nos Grids para análise do funcionamento da paginação.

� Para os casos de testes que referenciam teste utilizando a função de pesquisa (zoom), estes deverão ocorrer somente após esta funcionalidade estar implementada.

� Verificar a existência de testes automáticos no momento da realização do teste de negócio e assim garantir o teste de regressão.

� Deverão ser realizados os testes de usabilidade pelo auditor de negócio, conforme solicitado no Plano de Testes deste projeto, para cada caso de teste de tela (não reutilizável) disponibilizado abaixo. Como resultado esperado, além do que foi descrito nestes, a tela deve possuir o design e a ergonomia de acordo com o que foi descrito na Interface Concreta.

� Todos os campos na tela deverão ter acesso através da tecla TAB, a ordem da navegação deve ter uma seqüência. Objetos que não podem ser alcançados por TAB devem ter uma tecla de atalho.

� As informações apresentadas nos GRID’s devem possibilitar sua seleção utilizando o mouse, ou o teclado.

� Todos os portlets ou telas que possuam acesso via menu deverão ser testados por este intermédio.

� Para os campos que possibilitem pesquisa pelo (zoom) o procedimento deverá ser executado novamente utilizando esta funcionalidade.

� Para os browsers que apresentarem barra de rolagem vertical ou horizontal, utilizar as barras e navegar até o primeiro/ultimo registro do browser, caso seja rolagem vertical, ou navegar até a primeira/última coluna do brwoser, caso seja rolagem horizontal.

� Em todas as telas, utilizar a tecla TAB para verificar se a navegações dos campos está sendo feita corretamente.

Requisitos de Testes

Requisito de teste Reusável

Requisito de testes: Testar a verificação acesso de um time a uma oportunidade de cliente via webservices

Procedimentos: 1 a 7

Teste Executado pelo Programador: ( x ) Sim () Não

Automatizar?: () Sim (x) Não

74

Recomendações: <Informe particularidades de devem ser consideradas neste requisito de testes>

75

ANEXOS

ANEXO I

FRAMEWORK DE ZACHMAN

PARA ARQUITETURA CORPORATIVA

Framework Zachman para Arquitetura Corporativa – Tradução Livre Ordem Camada O Que

(Dados) Como (Função)

Onde (Rede) Quem (Pessoas)

Quando (Tempo)

Porque (Motivação)

1 Limite de Contexto do Escopo

• Planejador

Lista de coisas importantes para o negócio

Lista de processos que o negócio realiza

Lista de locais onde o negócio opera

Lista de organizações importantes para o negócio

Lista de eventos significantes para o negócio

Lista de objetivos/estratégias do negócio

2 Conceitos de Modelo de Negócio

• Dono

Modelo Semântico ou Entidade-relacionamento

Modelo de Processos de Negócio (BPM)

Sistema Logístico do Negócio

Modelo de Fluxo

Cronograma Mestre

Plano de Negócio

3 Modelo de Sistema Lógico

• Projetista

Modelo de Dados Lógico

Arquitetura da Aplicação

Arquitetura de Sistema Distribuído

Arquitetura de Interface Humana

Estrutura de Processamento

Modelo de Regras de Negócio

4 Modelo Tecnológico Físico

• Construtor

Modelo de Dados Físico

Desenho do Sistema

Arquitetura Tecnológica

Arquitetura de Apresentação

Estrutura de Controle

Desenho de Regras

5 Configuração de Componentes

• Implementador

Definição de Dados

Programa Arquitetura de Rede

Arquitetura de Segurança

Definição de Prazos

Especificação de Regras

6 Corporação Funcional

• Trabalhador

Dados Funções Rede Organização Cronograma

Estratégia

76

ANEXO II

PADROES PARA WEBSERVICES

Web

Ser

vice

sSta

ndard

sO

verv

iew

innoQ

Deuts

chla

nd G

mbH

innoQ

Sch

weiz

Gm

bH

Hal

skes

traß

e17

Gew

erbes

tras

se11

D-4

0880 R

atin

gen

CH

-6330 C

ham

Ph

on

e+

49 2

102

77

162

-100

Ph

on

e+

41

41743

0111

info

@in

noq.c

om

·w

ww

.innoq.c

om

This poster is not to be reproduced or transmitted in any form or for any purpose without the express permission of innoQ Deutschland GmbH.·Copyright ©innoQ Deutschland GmbH. All Rights Reserved. The poster may also contain references to other company, organisation, brand and product names. These company, organisation, brand and product names are used herein for identification purposes only and may be the trademarks of their respective owners.

Inte

roper

abilit

yIs

sues

Met

adata

Spec

ific

ati

ons

Rel

iabilit

y Spec

ific

ati

ons

Sec

uri

ty S

pec

ific

ati

ons

Transa

ctio

nSpec

ific

ati

ons

Mes

sagin

g S

pec

ific

ati

ons

SO

AP

Managem

ent

Spec

ific

ati

ons

Pre

senta

tion

Spec

ific

ati

ons

Mess

agin

g S

pecif

icati

ons

WS-N

oti

fica

tion

SO

AP

Mes

sage

Tran

smis

sion O

pti

miz

atio

n M

echan

ism

SO

AP

1.2

SO

AP

1.1

WS-A

ddre

ssin

g –

Core

WS-A

ddre

ssin

g –

WSD

L Bin

din

g

WS-A

ddre

ssin

g –

SO

AP B

indin

g

WS-T

opic

s

WS-B

roke

redN

oti

fica

tion

WS-E

venti

ng

WS-E

num

erat

ion

WS-B

aseN

oti

fica

tion

Metadata

Security

Resource

Meta

data

Specif

icati

ons

WS-P

olicy

WS-D

isco

very

WS-P

olicy

Att

achm

ent

WS-M

etad

ataE

xchan

ge

Univ

ersa

l D

escr

ipti

on, D

isco

very

and Inte

gra

tion

Web

Ser

vice

Des

crip

tion L

anguag

e 1.1

Web

Ser

vice

Des

crip

tion L

anguag

e 2.0

Core

Web

Ser

vice

Des

crip

tion L

anguag

e 2.0

SO

AP B

indin

g

Messaging

Security

WS-S

ecuri

ty

WS-S

ecuri

ty: SO

AP M

essa

ge

Sec

uri

ty

WS-S

ecuri

ty: Ker

ber

os

Bin

din

g

WS-S

ecuri

ty: SA

ML

Toke

n P

rofi

le

WS-S

ecuri

ty: X.5

09 C

erti

fica

te T

oke

n P

rofi

le

WS-S

ecuri

ty: U

sern

ame

Toke

n P

rofi

le

WS-S

ecuri

tyPo

licy

WS-T

rust

WS-F

eder

atio

n

WS-S

ecure

Conve

rsat

ion

Securi

ty S

pecif

icati

ons

Metadata

Messaging

Reliability

Dep

en

den

cie

s

Basi

c Pro

file

1.1

WS-I

Final

Spec

ific

atio

n

�Basi

c Pro

file

– T

he

Bas

ic P

rofi

le 1

.1 p

rovi

des

imple

men

tati

on g

uid

elin

es f

or

how

rel

ated

set

of

non-

pro

pri

etar

y W

eb S

ervi

ce s

pec

ific

atio

ns

should

be

use

dto

get

her

for

bes

t in

tero

per

abili

ty.

Basi

c Pro

file

1.2

WS-I

Work

ing G

roup D

raft

�Basi

c Pro

file

– T

he

Bas

ic P

rofi

le 1

.2 b

uild

s on B

asic

Pro

file

1.1

by

inco

rpora

ting B

asic

Pro

file

1.1

err

ata,

req

uir

emen

tsfr

om

Sim

ple

SO

AP B

indin

g P

rofi

le 1

.0, a

nd a

ddin

g s

upport

for

WS-

Addre

ssin

g a

nd M

TOM

.

Basi

c Pro

file

2.0

WS-I

Work

ing G

roup D

raft

�Basi

c Pro

file

– T

he

Bas

ic P

rofi

le 2

.0 is

an u

pdat

e of

WS-

IB

P t

hat

incl

udes

a p

rofi

le o

f SO

AP 1

.2.

Basi

c Sec

uri

ty P

rofi

le1.

0W

S-I

Boar

d A

ppro

val D

raft

�Basi

c Sec

uri

ty P

rofi

ledef

ines

the

WS-

I B

asic

Sec

uri

tyPro

file

1.0

, bas

ed o

n a

set

of

non-p

ropri

etar

y W

eb s

ervi

ces

spec

ific

atio

ns,

alo

ng w

ith c

lari

fica

tions

and a

men

dm

ents

to t

hose

spec

ific

atio

ns

whic

h p

rom

ote

inte

roper

abili

ty.

REL

Token

Pro

file

1.0

WS-I

Work

ing G

roup D

raft

�REL

Token

Pro

file

is

bas

ed o

n a

non-p

ropri

etar

y W

eb s

ervi

ces

spec

ific

atio

n, a

long w

ith c

lari

fica

tions

and

amen

dm

ents

to t

hat

spec

ific

atio

n w

hic

h p

rom

ote

inte

roper

abili

ty.

SA

ML

Token

Pro

file

1.0

WS-I

Work

ing G

roup D

raft

�SA

ML

Token

Pro

file

is

bas

ed o

n a

non-p

ropri

etar

y W

eb s

ervi

ces

spec

ific

atio

n, a

long w

ith c

lari

fica

tions

and

amen

dm

ents

to t

hat

spec

ific

atio

n w

hic

h p

rom

ote

inte

roper

abili

ty.

Confo

rmance

Cla

imA

ttach

men

t M

echanis

m (

CCA

M)

1.0

WS-I

Final

Spec

ific

atio

n

�Confo

rmance

Cla

im A

ttach

men

t M

echan

ism

(CCA

M)

cata

logues

mec

han

ism

sth

at c

an b

e use

d t

o a

ttac

h W

S-I

Prof

ile C

onfo

rman

ce C

laim

s to

Web

ser

vice

sar

tefa

cts

(e.g

., W

SDL

des

crip

tions,

UD

DI re

gis

trie

s).

Rel

iable

Asy

nch

ronous

Mes

sagin

g P

rofi

le(R

AM

P)

1.0

WS-I

Work

ing D

raft

�Rel

iable

Asy

nch

ronous

Mes

sagin

g P

rofi

le (

RA

MP)

is a

pro

file

, in t

he

fash

ion o

f th

e W

S-I pro

file

s, t

hat

enab

les,

among o

ther

thin

gs,

bas

ic B

2B

inte

gra

tion s

cenar

ios

usi

ng

Web

ser

vice

s te

chnolo

gie

s.

�XM

L – E

xten

sibl

e M

arku

pLa

ngu

age

is a

par

ed-d

own

vers

ion o

f SG

ML,

des

igned

espe

cial

ly f

or W

ebdo

cum

ents

. It

allo

ws

one

tocr

eate

ow

n c

ust

omiz

ed t

ags,

enab

ling

the

defi

nit

ion,

tran

smis

sion

, val

idat

ion, a

nd

inte

rpre

tati

on o

f da

tabe

twee

n a

pplic

atio

ns

and

betw

een o

rgan

izat

ions.

�XM

L – E

xten

sible

Mar

kup

Languag

e is

a p

ared

-dow

nve

rsio

n o

f SG

ML,

des

igned

espec

ially

for

Web

docu

men

ts. I

t al

low

s one

tocr

eate

ow

n c

ust

om

ized

tag

s,en

ablin

g th

e de

finit

ion,

tran

smis

sion

, val

idat

ion, a

nd

inte

rpre

tati

on o

f dat

abet

wee

n a

pplic

atio

ns

and

bet

wee

n o

rgan

izat

ions.

�N

am

espace

s in

XM

Lpro

vides

a s

imple

met

hod

for

qual

ifyi

ng e

lem

ent

and

attr

ibute

nam

es u

sed in

XM

Ldocu

men

ts b

y as

soci

atin

gth

em w

ith n

ames

pac

esid

enti

fied

by

IRI re

fere

nce

s.

�XM

L In

form

ati

on S

et i

san

abst

ract

dat

a se

t to

pro

vide

a co

nsi

sten

t se

t of

defi

nit

ions

for

use

in o

ther

spec

ific

atio

ns

that

nee

dto

refe

r to

the

info

rmat

ion

in a

wel

l-fo

rmed

XM

Ldocu

men

t.

�XM

L Sch

ema –

XM

LSc

hem

a D

efin

itio

n L

anguag

eis

an X

ML

languag

e fo

rdes

crib

ing a

nd c

onst

rain

ing

the

conte

nt

of

XM

Ldocu

men

ts.

�XM

L bin

ary

Opti

miz

edPack

agin

g (

XO

P)

is a

n X

ML

languag

e fo

r des

crib

ing a

nd

const

rain

ing t

he

conte

nt

of

XM

L docu

men

ts.

WS-S

ecuri

ty1.

1O

ASIS

OA

SIS

-Sta

ndar

d

WS-S

ecuri

ty:

Use

rnam

eTo

ken

Pro

file

1.1

OA

SIS

Public

Rev

iew

Dra

ft

�W

S-S

ecuri

tyis

a c

om

munic

atio

ns

pro

toco

l pro

vidin

g a

mea

ns

for

apply

ing s

ecuri

ty t

o W

eb S

ervi

ces.

WS-S

ecuri

ty:

SO

AP M

essa

ge

Sec

uri

ty1.

1O

ASIS

Public

Rev

iew

Dra

ft

�W

S-S

ecuri

ty:

SO

AP M

essa

ge

Sec

uri

ty d

escr

ibes

enhan

cem

ents

to S

OA

P m

essa

gin

g t

o p

rovi

de

mes

sage

inte

gri

ty a

nd c

onfi

den

tial

ity.

Spec

ific

ally

, this

spec

ific

atio

npro

vides

support

for

mult

iple

sec

uri

ty t

oke

n f

orm

ats,

tru

stdom

ains,

sig

nat

ure

form

ats

and e

ncr

ypti

on t

echnolo

gie

s.Th

e to

ken f

orm

ats

and s

eman

tics

for

usi

ng t

hes

e ar

edef

ined

in t

he

asso

ciat

ed p

rofi

le d

ocu

men

ts.

WS-S

ecuri

ty:

Ker

ber

os

Bin

din

g1.

0M

icro

soft

, IB

M, O

ASIS

Work

ing D

raft

WS-S

ecuri

ty:

X.5

09

Cer

tifi

cate

Toke

nPro

file

1.1

OA

SIS

Public

Rev

iew

Dra

ft

�W

S-S

ecuri

ty:

X.5

09 C

erti

fica

te T

oken

Pro

file

des

crib

esth

e use

of

the

X.5

09 a

uth

enti

cati

on f

ram

ework

wit

h t

he

WS-

Secu

rity

: SO

AP M

essa

ge

Secu

rity

spec

ific

atio

n.

�W

S-S

ecuri

ty: U

sern

am

e To

ken

Pro

file

des

crib

es h

ow

a

Web

Ser

vice

consu

mer

can

supply

a U

sern

ame

Toke

n a

s a

mea

ns

of

iden

tify

ing t

he

reques

tor

by

use

rnam

e, a

nd

opti

onal

ly u

sing

a pa

ssw

ord

(or

shar

ed s

ecre

t, e

tc.)

toau

then

tica

te t

hat

iden

tity

to t

he

Web

Ser

vice

pro

duce

r.

WS-S

ecuri

tyPolicy

1.1

IBM

, M

icro

soft

, RSA

Sec

uri

ty, Ver

iSig

nPublic

Dra

ft

�W

S-S

ecuri

tyPo

licy

def

ines

how

to

desc

ribe

pol

icie

sre

late

d

to v

ario

us

feat

ure

s de

fined

in t

he

WS-

Secu

rity

spe

cifi

cati

on.

WS-T

rust

BEA

Sys

tem

s, C

om

pute

r A

ssoci

ates

, IB

M, La

yer

7Te

chnolo

gie

s, M

icro

soft

, N

eteg

rity

, O

blix,

Open

Net

work

, Pin

g Iden

tity

Corp

ora

tion,

Rea

ctiv

ity,

RSA

Sec

uri

ty, Ver

iSig

n a

nd W

estb

ridge

Tech

nolo

gy

· In

itia

l D

raft

WS-S

ecuri

ty:

SA

ML

Token

Pro

file

1.1

OA

SIS

Public

Rev

iew

Dra

ft

�W

S-S

ecuri

ty: SA

ML

Toke

n P

rofi

le d

efin

es t

he

use

ofSe

curi

ty A

sser

tion

Mar

kup

Langu

age

(SA

ML)

v1.

1as

sert

ions

in t

he

conte

xt o

f W

SS: SO

AP M

essa

ge

Secu

rity

incl

udin

gfo

r th

e purp

ose

of

secu

ring S

OA

P m

essa

ges

and S

OA

Pm

essa

ge

exch

anges

.

WS-F

eder

ati

on

1.0

IBM

, M

icro

soft

, BEA

Sys

tem

s,

RSA

Sec

uri

ty, an

d V

eriS

ign

Init

ial D

raft

�W

S-F

eder

ati

on d

escr

ibes

how

to m

anag

e an

d b

roke

r th

etr

ust

rel

atio

nsh

ips

in a

het

erogen

eous

feder

ated

envi

ronm

ent

incl

udin

g s

upport

for

feder

ated

iden

titi

es.

WS-S

ecure

Conve

rsati

on

BEA

Sys

tem

s, C

om

pute

r A

ssoci

ates

, IB

M,

Laye

r 7 T

echnolo

gie

s, M

icro

soft

, N

eteg

rity

,O

blix,

Open

Net

work

, Pin

g Iden

tity

Corp

ora

tion, Rea

ctiv

ity,

RSA

Sec

uri

ty, Ver

iSig

n a

nd W

estb

ridge

Tech

nolo

gy

·Public

Dra

ft

�W

S-S

ecure

Conve

rsat

ion s

peci

fies

how

to

man

age

and

auth

enti

cate

mes

sage

exc

han

ges

betw

een p

arti

es in

cludi

ng

secu

rity

con

text

exc

han

ge a

nd

esta

blis

hin

g an

d de

rivi

ng

sess

ion k

eys.

WS-P

olicy

Ass

erti

ons

1.1

BEA

Sys

tem

s,

IBM

, M

icro

soft

, SA

PPublic

Dra

ft

WS-P

olicy

1.5

W3C

Work

ing D

raft

WS-P

olicy

Att

ach

men

t1.

2W

3C

W3C M

ember

Subm

issi

on

WS-D

isco

very

Mic

roso

ft, BEA

Sys

tem

s, C

anon,

Inte

l an

d w

ebM

ethods

Dra

ft

WS-M

etadata

Exc

hange

1.1

BEA

Sys

tem

s, C

om

pute

r A

ssoci

ates

, IB

M, M

icro

soft

, SA

P, S

un M

icro

syst

ems

and

web

Met

hods

Public

Dra

ft

�W

S-P

olicy

des

crib

es t

he

capab

iliti

es a

nd c

onst

rain

ts o

f th

e polic

ies

on inte

rmed

iari

es a

nd e

ndpoin

ts (

e.g. b

usi

nes

sru

les,

req

uir

ed s

ecuri

ty t

oke

ns,

support

ed e

ncr

ypti

on

algori

thm

s, p

riva

cy r

ule

s).

�W

S-P

olicy

Ass

erti

ons

pro

vides

an init

ial se

t of

asse

rtio

ns

to a

ddre

ss s

om

e co

mm

on n

eeds

of

Web

Ser

vice

sap

plic

atio

ns.

�W

S-P

olicy

Att

ach

men

tdef

ines

two

gen

eral

-purp

ose

mec

han

ism

sfo

r as

soci

atin

g p

olic

ies

wit

h t

he

subje

cts

tow

hic

h t

hey

apply

; th

e polic

ies

may

be

def

ined

as

par

t of

exis

ting m

etad

ata

about

the

subje

ct o

r th

e polic

ies

may

be

def

ined

indep

enden

tly

and a

ssoci

ated

thro

ugh a

n

exte

rnal

bin

din

g t

o t

he

subje

ct.

�W

S-D

isco

very

def

ines

a m

ult

icas

t dis

cove

ry p

roto

col fo

rdyn

amic

dis

cove

ry o

f se

rvic

es o

n a

d-h

oc

and m

anag

ednet

work

s.

�W

S-M

etadata

Exc

hange

enab

les

a se

rvic

e to

pro

vide

met

adat

a to

oth

ers

thro

ugh a

Web

ser

vice

s in

terf

ace.

Giv

enon

ly a

ref

eren

ce t

o a

Web

ser

vice

, a u

ser

can a

cces

s a

set

of

WSD

L/S

OA

P oper

atio

ns

to r

etri

eve

the

met

adat

ath

atde

scri

bes

the

serv

ice.

Univ

ersa

l D

escr

ipti

on,

Dis

cove

ryan

dIn

tegra

tion

(UD

DI)

3.0

.2O

ASIS

OA

SIS

-Sta

ndar

d

�U

niv

ersa

l D

escr

ipti

on, D

isco

very

and Inte

gra

tion (

UD

DI)

def

ines

a s

et o

f se

rvic

es s

upport

ing t

he

des

crip

tion

and d

isco

very

of

busi

nes

ses,

org

aniz

atio

ns,

and o

ther

Web

serv

ices

pro

vider

s, t

he

Web

ser

vice

s th

ey m

ake

avai

lable

,an

d t

he

tech

nic

al inte

rfac

es w

hic

h m

ay b

e use

d t

o a

cces

sth

ose

ser

vice

s.

Managem

ent

Of

Web

Ser

vice

s(W

SD

M-M

OW

S)

1.0

OA

SIS

OA

SIS

-Sta

ndar

d

WS-M

anagem

ent

AM

D, D

ell,

Inte

l, M

icro

soft

and S

un

Mic

rosy

stem

sPublish

ed S

pec

ific

atio

n

Managem

ent

Usi

ng W

ebSer

vice

s(W

SD

M-M

UW

S)

1.0

OA

SIS

OA

SIS

-Sta

ndar

dW

eb S

ervi

ces

for

Rem

ote

Port

lets

(W

SRP)

2.0

OA

SIS

Com

mit

tee

Dra

ft

�W

eb S

ervi

ce D

istr

ibute

d M

anagem

ent:

Man

agem

ent

Of

Web

Ser

vice

s (W

SDM

-MO

WS)

addre

sses

man

agem

ent

of

the

com

ponen

ts t

hat

form

the

net

work

, the

Web

ser

vice

sen

dpoin

ts, u

sing W

eb s

ervi

ces

pro

toco

ls.

�W

S-M

anagem

ent

des

crib

esa

gen

eral

SO

AP-b

ased

pro

toco

l fo

r m

anag

ing s

yste

ms

such

as

PC

s, s

erve

rs,

dev

ices

, Web

ser

vice

s an

d o

ther

applic

atio

ns,

and o

ther

man

agea

ble

enti

ties

.

Ser

vice

Model

ing L

anguage

IBM

, BEA

, BM

C, Cis

co, D

ell,

HP,

Inte

l,M

icro

soft

, Sun

Dra

ft S

pec

ific

atio

n

�Ser

vcie

Model

ing L

anguage

(SM

L) is

use

d t

o m

odel

com

ple

x IT

ser

vice

s an

d s

yste

ms,

incl

udin

g t

hei

r st

ruct

ure

,co

nst

rain

ts, p

olic

ies,

and b

est

pra

ctic

es.

�W

eb S

ervi

ce D

istr

ibute

d M

anagem

ent:

Man

agem

ent

Usi

ng

Web

Ser

vice

s (W

SDM

-MU

WS)

def

ines

how

an IT

reso

urc

eco

nnec

ted t

o a

net

work

pro

vides

man

agea

bili

ty inte

rfac

essu

ch t

hat

the

IT r

esourc

e ca

n b

e m

anag

ed loca

lly a

nd f

rom

rem

ote

loca

tions

usi

ng W

eb s

ervi

ces

tech

nolo

gie

s.�

Web

Ser

vice

s fo

r Rem

ote

Port

lets

(WSR

P)

def

ines

a

set

of

inte

rfac

es a

nd r

elat

ed s

eman

tics

whic

h s

tandar

diz

ein

tera

ctio

ns

wit

h c

om

ponen

ts p

rovi

din

g u

ser-

faci

ng

mar

kup, i

ncl

udin

g t

he

pro

cess

ing o

f use

r in

tera

ctio

ns

wit

hth

at m

arku

p.

Web

Ser

vice

Des

crip

tion

Language

2.0

Core

2.0

W3C

Can

did

ate

Rec

om

men

dat

ion

Web

Ser

vice

Des

crip

tion

Language

1.1

1.1

W3C

Note

Web

Ser

vice

Des

crip

tion

Language

2.0

SO

AP B

indin

g2.0

W3C · W

ork

ing D

raft

�W

S-B

usi

nes

s A

ctiv

ity

prov

ides

the

defi

nit

ion o

f th

e bu

sines

s ac

tivi

tyco

ordi

nat

ion t

ype

that

is t

o be

use

d w

ith t

he

exte

nsi

ble

coor

dinat

ion

fram

ewor

k de

scri

bed

in t

he

WS-

Coo

rdin

atio

n s

peci

fica

tion

.

WS-C

oord

inati

on

1.1

OA

SIS

Work

ing D

raft

�W

S-A

tom

ic T

ransa

ctio

n d

efin

es p

roto

cols

that

enab

le e

xist

ing

tran

sact

ion p

roce

ssin

g sy

stem

s to

wra

p th

eir

prop

riet

ary

prot

ocol

san

d in

tero

pera

te a

cros

s di

ffer

ent

har

dwar

e an

d so

ftw

are

vendo

rs.

�W

S-C

oord

inat

ion d

escr

ibes

an e

xten

sibl

e fr

amew

ork

for

prov

idin

gpr

otoc

ols

that

coo

rdin

ate

the

acti

ons

of d

istr

ibute

d ap

plic

atio

ns.

WS-C

om

posi

te A

pplica

tion

Fram

ework

(W

S-C

AF)

1.0

· A

rjuna

Tech

nolo

gie

s, F

ujits

u, IO

NA

,O

racl

e an

d S

un M

icro

syst

ems

Com

mit

tee

Spec

ific

atio

n

�W

S-C

om

posi

te A

pplica

tion F

ram

ework

(WS-

CA

F)is

aco

llect

ion

of t

hre

e sp

ecif

icat

ions

aim

ed a

t so

lvin

g pr

oble

ms

that

ari

se w

hen

mult

iple

Web

Serv

ices

are

use

d in

com

bina-

tion

. It

prop

oses

sta

nda

rd, i

nte

rope

rabl

e m

echan

ism

s fo

rm

anag

ing

shar

edco

nte

xtan

den

suri

ng

busi

nes

s pr

oces

ses

achie

ve p

redi

ctab

le r

esult

s an

d re

cove

ry f

rom

fai

lure

.

WS-C

onte

xt(W

S-C

TX)

1.0

Arj

una

Tech

nolo

gie

s, F

ujits

u, IO

NA

, O

racl

ean

d S

un M

icro

syst

ems

Com

mit

tee

Dra

ft

�W

S-C

onte

xt (

WS-

CTX

) is

inte

nded

as

a lig

htw

eight

mec

han

ism

for

allo

win

g m

ult

iple

Web

Ser

vice

s to

shar

e a

com

mon c

onte

xt.

WS-C

oord

inati

on

Fram

ework

(W

S-C

F)1.

0 ·

Arj

una

Tech

nolo

gie

s, F

ujits

u, IO

NA

,O

racl

e an

d S

un M

icro

syst

ems

Com

mit

tee

Dra

ft

�W

S-C

oord

inati

on F

ram

ework

(W

S-C

F) a

llow

s th

e m

anag

emen

t an

d c

oord

inat

ion in a

Web

Ser

vice

s in

tera

ctio

nof

a num

ber

of

acti

viti

es r

elat

ed t

o a

n o

vera

ll ap

plic

atio

n.

WS-T

ransa

ctio

n

Managem

ent

(WS-T

XM

)1.

0 · A

rjuna

Tech

nolo

gie

s, F

ujits

u, IO

NA

,O

racl

e an

d S

un M

icro

syst

ems

Com

mit

tee

Dra

ft

�W

S-T

ransa

ctio

n M

anag

emen

t (W

S-TX

M) de

fines

a c

ore

infr

astr

uct

ure

serv

ice

consi

stin

g of

a T

ransa

ctio

n S

ervi

ce f

or W

eb S

ervi

ces.

WS-B

usi

nes

s A

ctiv

ity

1.1

OA

SIS

Work

ing D

raft

WS-A

tom

icTr

ansa

ctio

n1.

1O

ASIS

Com

mit

tee

Dra

ft

Res

ourc

eSpec

ific

ati

ons

SO

AP M

essa

ge

Transm

issi

on O

pti

miz

ati

on

Mec

hanis

m(M

TOM

)1.

0 · W

3C

Rec

om

men

dat

ion

SO

AP

1.2

W3C

Rec

om

men

dat

ion

SO

AP

1.1

W3C

Note

XM

L 1.1

1.1

W3C

Rec

om

men

dat

ion

XM

L 1.0

1.0

W3C

Rec

om

men

dat

ion

Nam

espace

s in

XM

L1.

1W

3C

Rec

om

men

dat

ion

XM

L In

form

ati

on S

et1.

0W

3C

Rec

om

men

dat

ion

XM

L Sch

ema

1.1

W3C

Work

ing D

raft

XM

L bin

ary

Opti

miz

edPack

agin

g(X

OP)

1.0

W3C

Rec

om

men

dat

ion

�D

escr

ibin

g M

edia

Conte

nt

of

Bin

ary

Data

in X

ML

(DM

CBD

X)

spec

ifie

s how

to

indic

ate

the

conte

nt-

type

asso

ciat

ed w

ith b

inar

yel

emen

t co

nte

nt

in a

n X

ML

docu

men

t an

d t

o s

pec

ify,

in

XM

L Sc

hem

a, t

he

expec

ted

conte

nt-

type(

s) a

ssoci

ated

wit

h b

inar

y el

emen

tco

nte

nt.

Des

crib

ing M

edia

Conte

nt

of

Bin

ary

Data

in X

ML

(DM

CBD

X)

W3C

Note

XM

L Spec

ific

ati

ons

�W

S-T

rust

des

crib

es a

fra

mew

ork

for

trust

mod

els

that

enab

les

Web

Ser

vice

s to

sec

ure

ly in

tero

pera

te. I

tuse

s W

S-Se

curi

ty b

ase

mec

han

ism

san

d de

fines

add

itio

nal

pri

mit

ives

and

exte

nsi

ons

for

secu

rity

tok

en e

xchan

ge t

o en

able

the

issu

ance

and

diss

emin

atio

n o

f cr

eden

tial

s w

ithin

dif

fere

nt

trust

dom

ains.

�W

S-S

ecuri

ty:

Ker

ber

os

Bin

din

g d

efin

es h

ow

to e

nco

de

Ker

ber

os

tick

ets

and a

ttac

h t

hem

to S

OA

P m

essa

ges.

As

wel

l, it

spe

cifi

es h

ow t

o ad

d si

gnat

ure

san

d en

cryp

tion

to

the

SOA

P m

essa

ge, i

n a

ccor

dance

wit

h W

S-Se

curi

ty, w

hic

h

use

s an

d r

efer

ence

s th

e Ker

ber

os

toke

ns.

WS-A

ddre

ssin

g –

Core

1.0

W3C

Rec

om

men

dat

ion

WS-E

venti

ng

W3C

Public

Dra

ft

�W

S-A

ddre

ssin

g –

Core

pro

vides

tra

nsp

ort

-neu

tral

mec

han

ism

s to

addre

ssW

eb s

ervi

ces

and m

essa

ges

.Th

is s

pec

ific

atio

n d

efin

esXM

L el

emen

ts t

o iden

tify

Web

ser

vice

endpoin

ts a

nd

to s

ecure

end-t

o-e

nd

endpoin

t id

enti

fica

tion in

mes

sages

.

WS-A

ddre

ssin

g –

WSD

LBin

din

g1.

0W

3C

Can

did

ate

Rec

om

men

dat

ion

�W

S-A

ddre

ssin

g –

WSD

LBin

din

gdef

ines

how

the

abst

ract

pro

per

ties

def

ined

in W

eb S

ervi

ces

Addre

ssin

g– C

ore

are

des

crib

ed u

sing

WSD

L.

WS-A

ddre

ssin

g –

SO

AP

Bin

din

g1.

0W

3C

Rec

om

men

dat

ion

�W

S-A

ddre

ssin

g –

SO

AP

Bin

din

gpro

vides

tra

nsp

ort

-neu

tral

mec

han

ism

s to

addre

ss W

eb s

ervi

ces

and

mes

sages

.

�W

S-B

ase

Noti

fica

tion

stan

dard

izes

the

term

inol

ogy,

conce

pts

, oper

atio

ns,

WSD

Lan

d X

ML

nee

ded

to e

xpre

ssth

e bas

ic r

ole

s in

volv

ed in

Web

ser

vice

s publis

h a

nd

subsc

ribe

for

noti

fica

tion

mes

sage

exch

ange.

WS-E

num

erati

on

Sys

tinet

, M

icro

soft

, Sonic

Soft

war

e, B

EASys

tem

s an

d

Com

pute

r A

ssoci

ates

Public

Dra

ft

�W

S-E

num

erat

ion d

escr

ibes

a gen

eral

SO

AP-b

ased

pro

toco

l fo

r en

um

erat

ing

a se

quen

ce o

f XM

Lel

emen

ts t

hat

is

suit

able

for

trav

ersi

ng logs,

mes

sage

queu

es, o

r oth

er lin

ear

info

rmat

ion m

odel

s.

WS-N

oti

fica

tion

1.3

OA

SIS

OA

SIS

-Sta

ndar

d

�W

S-N

oti

fica

tion

is a

fam

ilyof

rela

ted w

hit

epap

ers

and s

pec

ific

atio

ns

that

def

ine

a st

andar

d

Web

ser

vice

s ap

pro

ach t

onoti

fica

tion u

sing a

topic

-bas

ed p

ublis

h/s

ubsc

ribe

pat

tern

.

WS-B

ase

Noti

fica

tion

1.3

OA

SIS

OA

SIS

-Sta

ndar

d

�W

S-E

venti

ng

def

ines

abas

elin

e se

t of

oper

atio

ns

that

allo

w W

eb s

ervi

ces

topro

vide

asyn

chro

nous

noti

fica

tions

to inte

rest

edpar

ties

.

WS-T

opic

s1.

3O

ASIS

OA

SIS

-Sta

ndar

d

�W

S-T

opic

s def

ines

thre

eto

pic

expre

ssio

n d

iale

cts

that

can

be

use

d a

s su

b-

scri

pti

on e

xpre

ssio

ns

insu

bsc

ribe

reques

t m

essa

ges

and o

ther

par

ts o

f th

e W

S-N

oti

fica

tion s

yste

m.

WS-B

roker

edN

oti

fica

tion

1.3

OA

SIS

OA

SIS

-Sta

ndar

d

�W

S-B

roker

edN

oti

fica

tion

def

ines

the

inte

rfac

efo

rth

e N

oti

fica

tionB

roke

r. A

Noti

fica

tionB

roke

r is

an

inte

rmed

iary

, whic

h, a

mong

oth

er t

hin

gs,

allo

ws

public

atio

n o

f m

essa

ges

from

enti

ties

that

are

not

them

selv

es s

ervi

ce

pro

vider

s.

�SO

AP M

essa

ge

Tran

smis

sion

Opti

miz

atio

nM

echan

ism

des

crib

es a

nab

stra

ct f

eatu

re f

or

opti

miz

ing t

he

tran

smis

sion a

nd

/or

wir

e fo

rmat

of

aSO

AP m

essa

ge.

�SO

AP

is a

ligh

twei

ght,

XM

L-ba

sed

prot

ocol

for

exch

ange

of

info

rmat

ion

in a

dec

entr

aliz

ed,

dist

ribu

ted

envi

ronm

ent.

WS-P

olicy

Ass

erti

ons

Version 3.0 · February 2007

Reli

abil

ity S

pecif

icati

ons

WS-R

elia

ble

Mes

sagin

g

WS-R

elia

bilit

y

WS-R

elia

ble

Mes

sagin

g P

olicy

Ass

erti

on

Transaction

Reso

urc

e S

pecif

icati

ons

Web

Ser

vice

Res

ourc

e Fr

amew

ork

WS-B

aseF

ault

s

WS-R

esourc

eLif

etim

e

WS-T

ransf

er

Res

ourc

e Rep

rese

nta

tion S

OA

P H

eader

Blo

ck (

RRSH

B)

WS-S

ervi

ceG

roup

Messaging

Security

Transaction

WS-R

esourc

ePro

per

ties

Metadata

Security

BasicProfile

Pre

senta

tion S

pecif

icati

ons

Web

Ser

vice

s fo

r Rem

ote

Port

lets

Mess.

Secur.

Reliab.

Messaging

Security

Managem

ent

Specif

icati

ons

ResourceMeta

WS-M

anag

emen

t

Man

agem

ent

Of

Web

Ser

vice

s

Man

agem

ent

Usi

ng W

eb S

ervi

ces

Ser

vice

Model

ing L

anguag

e

Busi

ness

Pro

cess

Specif

icati

ons

WS-C

hore

ogra

phy

Model

Ove

rvie

w

Web

Ser

vice

Chore

ogra

phy

Des

crip

tion L

anguag

e

Web

Ser

vice

Chore

ogra

phy

Inte

rfac

e

Busi

nes

s Pro

cess

Man

agem

ent

Languag

e

Busi

nes

s Pro

cess

Exe

cuti

on

Languag

efo

rW

ebSer

v.2.0

XM

LPro

cess

Def

init

ion L

anguag

e

Busi

nes

s Pro

cess

Exe

cuti

on L

anguag

e fo

r W

eb S

ervi

ces

Messaging

Transaction

Security

Reliability

Tra

nsa

cti

on S

pecif

icati

ons

Messaging

Security

Reliability

Metadata

WS-C

om

posi

te A

pplica

tion F

ram

ework

WS-T

ransa

ctio

n M

anag

emen

t

WS-C

onte

xt

WS-C

oord

inat

ion F

ram

ework

WS-B

usi

nes

s A

ctiv

ity

WS-A

tom

ic T

ransa

ctio

n

WS-C

oord

inat

ion

Sta

nd

ard

s B

od

ies

The

Org

aniz

atio

n for th

e A

dva

nce

men

t of Str

uct

ure

d In

form

atio

n

Sta

ndard

s (O

ASIS

)is

a n

ot-

for-

pro

fit,

inte

rnat

ional

conso

rtiu

mth

at

dri

ves

the

dev

elopm

ent,

co

nve

rgen

ce,

and

adopti

on

of

e-busi

nes

s st

andar

ds.

Th

eco

nso

rtiu

m p

roduce

s m

ore

Web

ser

vice

s st

andar

ds

than

any

oth

er o

rgan

izat

ion a

long w

ith s

tan-

dar

ds

for

secu

rity

, e-b

usi

nes

s, a

nd s

tandar

diz

atio

n e

ffort

s in

the

public

sec

tor

and f

or

applic

a-ti

on-s

pec

ific

mar

kets

. Fo

unded

in

1993,

OA

SIS

has

more

than

4,0

00 p

arti

cipan

ts r

epre

senti

ng

ove

r 600 o

rgan

izat

ions

and in

div

idual

mem

ber

s in

100 c

ountr

ies.

The

Worl

d W

ide

Web

Conso

rtiu

m (W

3C)

was

cre

ated

in O

ctob

er 1

994 t

o le

ad t

he

Wor

ld W

ide

Web

to

its

full

pote

nti

al b

y de

velo

ping

com

mon

pro

toco

ls t

hat

pro

mot

eit

s ev

olu

tion a

nd e

nsu

re it

s in

tero

per

abili

ty. W

3C

has

ove

r 350 M

ember

org

aniz

a-ti

ons

from

all

over

the

wor

ld a

nd

has

ear

ned

inte

rnat

ional

rec

ognit

ion f

or it

s co

ntr

ibuti

ons

to t

he

grow

th o

f th

e W

eb. W

3C is

des

ignin

g th

e in

fras

truct

ure

, and

defi

nin

g th

e ar

chit

ectu

re a

nd

the

core

tech

nol

ogie

s fo

r W

eb s

ervi

ces.

In S

epte

mbe

r 20

00, W

3C s

tart

ed t

he

XM

L Pr

otoc

ol A

ctiv

ity

to a

ddre

ssth

e nee

d fo

r an

XM

L-ba

sed

prot

ocol

for

app

licat

ion-t

o-ap

plic

atio

n m

essa

ging.

In J

anuar

y 20

02, t

he

Web

Ser

vice

s A

ctiv

ity

was

launch

ed, s

ubs

um

ing

the

XM

L Pr

otoc

ol A

ctiv

ity

and

exte

ndi

ng

its

scop

e.

The

Web

Ser

vice

s In

tero

per

abili

ty O

rgan

izat

ion (

WS-I

) is

an o

pen i

ndu

stry

or

ganiz

atio

n c

har

tere

d to

pro

mot

e W

eb s

ervi

ces

inte

rope

rabi

lity

acro

ss p

latf

orm

s,op

erat

ing

syst

ems

and

prog

ram

min

g la

ngu

ages

. Th

e or

ganiz

atio

n’s

div

erse

com

munit

y of

Web

serv

ices

lea

ders

hel

ps c

ust

omer

s to

dev

elop

inte

rope

rabl

e W

eb s

ervi

ces

by p

rovi

ding

guid

ance

,re

com

men

ded

prac

tice

s an

d su

ppor

ting

reso

urc

es.

Spec

ific

ally

, W

S-I

crea

tes,

pr

omot

es an

dsu

ppor

ts g

ener

ic p

roto

cols

for

the

inte

rope

rabl

e ex

chan

ge o

f m

essa

ges

betw

een W

eb s

ervi

ces.

The

Inte

rnet

Engin

eeri

ng T

ask

Forc

e (IETF

) is

a la

rge

open

inte

rnat

ional

co

mm

unit

y of

net

wor

k de

sign

ers,

ope

rato

rs,

vendo

rs,

and

rese

arch

ers

conce

rned

wit

h t

he

evol

uti

on o

f th

e In

tern

et a

rchit

ectu

re a

nd

the

smoo

th

oper

atio

n o

f th

e In

tern

et.

Att

ach

men

ts P

rofi

le1.

0W

S-I

Final

Spec

ific

atio

n

�A

ttach

men

ts P

rofi

le –

The

Att

achm

ent

Pro

file

1.0

com

ple

men

ts t

he

Bas

ic P

rofi

le 1

.1 t

o a

dd s

upport

fo

r in

tero

per

able

SO

AP M

essa

ges

wit

h a

ttac

hm

ents

-bas

edW

eb S

ervi

ces.

Sim

ple

SO

AP

Bin

din

g P

rofi

le1.

0W

S-I

Final

Spec

ific

atio

n

�Sim

ple

SO

AP B

indin

g P

rofi

le –

The

Sim

ple

SO

AP B

indin

gPro

file

consi

sts

of

those

Bas

ic P

rofi

le 1

.0 r

equir

emen

tsre

late

d t

o t

he

seri

aliz

atio

n o

f th

e en

velo

pe

and its

repre

senta

tion in t

he

mes

sage.

Busi

nes

s Pro

cess

Exe

cuti

on

Language

for

Web

Ser

vice

s1.1

(BPEL

4W

S)

· 1.

1 · B

EA S

yste

ms,

IBM

,M

icro

soft

, SA

P,

Sie

bel

Sys

tem

s · O

ASIS

-Sta

ndar

d

�W

S-C

hore

ogra

phy

Model

Ove

rvie

w d

efin

es t

he

form

atan

d s

truct

ure

of

the

(SO

AP)

mes

sages

that

are

exc

han

ged

,an

d t

he

sequen

ce a

nd c

ondit

ions

in w

hic

h t

he

mes

sages

are

exch

anged

.

�Busi

nes

s Pro

cess

Exe

cuti

on L

anguage

for

Web

Ser

vice

s1.1

(BPEL

4W

S) p

rovi

des

a lan

guag

e fo

r th

e fo

rmal

spec

ific

atio

n o

f busi

nes

s pro

cess

es a

nd b

usi

nes

s in

tera

ctio

npro

toco

ls u

sing W

eb S

ervi

ces.

�W

eb S

ervi

ce C

hore

ogra

phy

Inte

rface

(W

SCI)

des

crib

eshow

Web

Ser

vice

oper

atio

ns

can b

e ch

ore

ogra

phed

in t

he

conte

xt o

f a

mes

sage

exch

ange

in w

hic

h t

he

Web

Ser

vice

par

tici

pat

es.

WS-C

hore

ogra

phy

Model

Ove

rvie

w1.

0 · W

3C

Work

ing D

raft

Web

Ser

vice

Chore

ogra

phy

Inte

rface

(WSCI)

· 1

.0 · W

3C

Sun M

icro

syst

ems,

SA

P, B

EA S

yste

ms

and Inta

lio · N

ote

Busi

nes

s Pro

cess

Spec

ific

ati

ons

Busi

nes

s Pro

cess

Exe

cuti

on

Language

for

Web

Ser

vice

s2.0

(BPEL

4W

S)

· 2.0

OA

SIS

, BEA

Sys

tem

s, IBM

, M

icro

soft

, SA

P,

Sie

bel

Sys

tem

s · Com

mit

tee

Dra

ft

�Busi

nes

s Pro

cess

Exe

cuti

on L

anguage

for

Web

Ser

vice

s2.0

(BPEL

4W

S) p

rovi

des

a lan

guag

e fo

r th

e fo

rmal

spec

ific

atio

n o

f busi

nes

s pro

cess

es a

nd b

usi

nes

s in

tera

ctio

npro

toco

ls u

sing W

eb S

ervi

ces.

�Busi

nes

s Pro

cess

Managem

ent

Language

(BPM

L)pro

vides

a m

eta-

languag

e fo

r ex

pre

ssin

g b

usi

nes

spro

cess

es a

nd s

upport

ing e

nti

ties

.

Busi

nes

s Pro

cess

Managem

ent

Language

(BPM

L)1.

1BPM

I.org

Final

Dra

ft

�W

eb S

ervi

ce C

hore

ogra

phy

Des

crip

tion L

anguage

(CD

L4W

S) is

to s

pec

ify

a dec

lara

tive

, XM

L bas

ed lan

guag

eth

at d

efin

es f

rom

a g

lobal

vie

wpoin

t th

e co

mm

on a

nd

com

ple

men

tary

obse

rvab

lebe

hav

iour,

wher

em

essa

geex

chan

ges

occ

ur,

and w

hen

the

join

tly

agre

ed o

rder

ing

rule

s ar

e sa

tisf

ied.

Web

Ser

vice

Chore

ogra

phy

Des

crip

tion L

anguage

(CD

L4W

S)

· 1.

0 · W

3C

Can

did

ate

Rec

om

men

dat

ion

�XM

LPro

cess

Def

init

ion L

anguage

(XPD

L) p

rovi

des

an

XM

Lfi

le f

orm

at t

hat

can

be

use

d t

o inte

rchan

ge

pro

cess

model

s bet

wee

n t

ools

.

XM

L Pro

cess

Def

init

ion

Language

(XPD

L)2.0

Final

WS-R

elia

ble

Mes

sagin

g1.

1O

ASIS

Com

mit

tee

Dra

ft

�W

S-R

elia

ble

Mes

sagin

gdes

crib

es a

pro

toco

l th

at a

llow

sW

eb s

ervi

ces

to c

om

munic

ate

relia

ble

in t

he

pre

sence

of

soft

war

e co

mponen

t, s

yste

m, o

r net

work

fai

lure

s. It

def

ines

a SO

AP

bindi

ng

that

is r

equir

ed f

or in

tero

pera

bilit

y.

WS-R

elia

bilit

y1.

1O

ASIS

OA

SIS

-Sta

ndar

d

�W

S-R

elia

bilit

yis

a S

OA

P-b

ased

pro

toco

l fo

r ex

chan

gin

gSO

AP m

essa

ges

wit

h g

uar

ante

ed d

eliv

ery,

no d

uplic

ates

,an

d g

uar

ante

ed m

essa

ge

ord

erin

g. W

S-R

elia

bili

ty is

def

ined

as

SOA

P h

eader

ext

ensi

ons

and is

indep

enden

t of

the

under

lyin

g p

roto

col.

This

spec

ific

atio

n c

onta

ins

abin

din

g t

o H

TTP.

WS-R

elia

ble

Mes

sagin

g

Policy

Ass

erti

on (

WS-R

M P

olicy

)1.

1O

ASIS

Com

mit

tee

Dra

ft

�W

eb S

ervi

ces

Rel

iable

Mes

sagin

g P

olicy

Ass

erti

on

(WS-

RM

Polic

y) d

escr

ibes

a d

om

ain-s

pec

ific

polic

y as

sert

ion

for

WS-

Rel

iable

Mes

sagin

g t

hat

that

can

be

spec

ifie

d w

ithin

a polic

y al

tern

ativ

e as

def

ined

in W

S-Po

licy

Fram

ework

.

�W

eb S

ervi

ce D

escr

ipti

on L

anguage

2.0

Core

is

an X

ML-

bas

ed lan

guag

e fo

r des

crib

ing W

eb s

ervi

ces

and h

ow

to

acce

ss t

hem

. It

spec

ifie

s th

e lo

cati

on o

f th

e se

rvic

e an

d t

he

oper

atio

ns

(or

met

hods)

the

serv

ice

expose

s.

�W

eb S

ervi

ce D

escr

ipti

on L

anguage

1.1

is

an X

ML-

bas

edla

nguag

e fo

r des

crib

ing W

eb s

ervi

ces

and h

ow

to a

cces

sth

em. I

t sp

ecif

ies

the

loca

tion o

f th

e se

rvic

e an

d t

he

oper

atio

ns

(or

met

hods)

the

serv

ice

expose

s.

�W

eb S

ervi

ce D

escr

ipti

on L

anguage

SO

AP

Bin

din

gdes

crib

es t

he

concr

ete

det

ails

for

usi

ng W

SDL

2.0

in

conju

nct

ion w

ith S

OA

P 1

.1 p

roto

col.

WS-B

ase

Fault

s(W

SRF)

1.2

OA

SIS

Work

ing D

raft

Web

Ser

vice

s Res

ourc

e Fr

am

ework

(W

SRF)

1.2

OA

SIS

OA

SIS

-Sta

ndar

d

WS-S

ervi

ceG

roup

(WSRF)

1.2

OA

SIS

Work

ing D

raft

�W

S-B

ase

Fault

s(W

SRF)

def

ines

a b

ase

set

of

info

rmat

ion

that

may

appea

r in

fau

lt m

essa

ges

. WS-

Bas

eFau

lts

def

ines

an

XM

L sc

hem

a ty

pe

for

bas

e fa

ult

s, a

long w

ith r

ule

s fo

r how

this

bas

e fa

ult

typ

e is

use

d a

nd e

xten

ded

by

Web

Ser

vice

s.

�W

eb S

ervi

ces

Res

ourc

e Fr

amew

ork

(W

SRF)

def

ines

a f

amily

of

spec

ific

atio

ns

for

acce

ssin

g st

atef

ul r

esou

rces

usi

ng

Web

Ser

vice

s.

�W

S-S

ervi

ceG

roup (

WSR

F) d

efin

es a

mea

ns

by

whic

h W

ebSe

rvic

es a

nd W

S-R

esourc

es c

an b

e ag

gre

gat

ed o

r gro

uped

toget

her

for

a dom

ain s

pec

ific

purp

ose

.

WS-R

esourc

ePro

per

ties

1.2

OA

SIS

Work

ing D

raft

�W

S-R

esourc

ePro

per

ties

spec

ifie

sth

e m

eans

by w

hic

h t

he

defi

nit

ion o

f th

e pr

oper

ties

of

a W

S-R

esou

rce

may

be

decl

ared

as p

art

of t

he

Web

Serv

ice

inte

rfac

e. T

he

dec

lara

tion o

f th

eW

S-R

esourc

e pro

per

ties

rep

rese

nts

a p

roje

ctio

n o

f or

a vi

ewon t

he

WS-

Res

ourc

e st

ate.

�W

S-R

esourc

eLif

etim

e is

to s

tandar

diz

e th

e te

rmin

olo

gy,

conce

pts

, mes

sage

exch

anges

, WSD

L an

d X

ML

nee

ded

to

monit

or

the

lifet

ime

of,

and d

estr

oy

WS-

Res

ourc

es.

Add

itio

nal

ly, i

t de

fines

res

ourc

e pr

oper

ties

that

may

be

use

dto

insp

ect

and m

onit

or

the

lifet

ime

of

a W

S-R

esourc

e.

�W

S-T

ransf

er d

escr

ibes

a g

ener

al S

OA

P-b

ased

pro

toco

l fo

rac

cess

ing

XM

L re

pres

enta

tion

s of

Web

ser

vice

-bas

ed r

esou

rces

.

WS-R

esourc

eLif

etim

e1.

2O

ASIS

Work

ing D

raft

WS-T

ransf

erW

3C

W3C M

ember

Subm

issi

on

Res

ourc

e Rep

rese

nta

tion

SO

AP H

eader

Blo

ck (

RRSH

B)

W3C

Rec

om

men

dat

ion

�Res

ourc

e Rep

rese

nta

tion S

OA

P H

eader

Blo

ck(R

RSH

B)

com

ple

men

ts M

TOM

by

def

inin

g m

echan

ism

s fo

rde

scri

bing

and

conve

ying

non

-XM

L re

sourc

e re

pres

enta

tion

sin

a S

OA

P 1

.2 m

essa

ge.

Documents

APLICAÇÃO DE TESTES DE SOFTWARE UTILIZANDO A ARQUITETURA ORIENTADA A SERVIÇOS (SOA)