aplicaÇÃo de testes de software utilizando a arquitetura orientada a serviÇos (soa)
DESCRIPTION
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. SENAI / SC FLORIANÓPOLIS - 2009TRANSCRIPT
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
Israel Kraisch – Rodrigo Tomaselli
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
Israel Kraisch – Rodrigo Tomaselli
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">
<!--Zero or more repetitions:-->
<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:xsd="http://www.w3.org/2001/XMLSchema"
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:xsd="http://www.w3.org/2001/XMLSchema"
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">
<item xsi:type="x-:mapItem">
<!-- Parametro Codigo do usuario-->
<key xsi:type="xsd:string">resourceId</key>
<!-- Codigo do Usuario-->
<value xsi:type="xsd:int">1</value>
</item>
<item xsi:type="x-:mapItem">
<!-- Grupo do usuario -->
<key xsi:type="xsd:string">resourceType</key>
<!-- Codigo do Grupo de Usuario-->
<value xsi:type="xsd:string">1</value>
</item>
<item xsi:type="x-:mapItem">
<!-- Verificacao de Idioma -->
<key xsi:type="xsd:string">locale</key>
<!-- Codigo do Usuario-->
<value xsi:type="xsd:string">"pt"</value>
</item>
</Map>
</in0>
<!--Tipo de Acesso e Codigo do Cliente-->
<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:xsd="http://www.w3.org/2001/XMLSchema"
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;
� Erros de resultado em outro módulo ou programa; � Situações identificadas em outras partes do produto ocasionadas pelos resultados
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;
� Erros de resultado em outro módulo ou programa; � Situações identificadas em outras partes do produto ocasionadas pelos resultados
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.