WS-Policy [25]: Gram´atica XML para expressar pol´ıticas para sistemas baseados em servi¸cos Web, de acordo com o modelo abstrato de pol´ıticas adotada pela especi- fica¸c˜ao (Policy Model ). Pol´ıticas para servi¸cos Web podem expressar funcionalida- des, requisitos ou caracter´ısticas gerais. Por exemplo, pol´ıticas podem especificar sele¸c˜ao de modos de opera¸c˜ao de um servi¸co, ou declarar caracter´ısticas de QoS re- queridos pelo usu´ario, entre outros cen´arios. Contudo, a especifica¸c˜ao n˜ao restringe como pol´ıticas s˜ao comunicadas entre o provedor e o solicitante dos servi¸cos. De acordo com o modelo abstrato, uma pol´ıtica ´e declarada mediante uma express˜ao wsp:Policy. Uma express˜ao cont´em cole¸c˜oes de assertivas, que definem assertivas alternativas (wsp:ExactlyOne) e conjuntivas (wsp:All ). E por fim, uma assertiva corresponde a um requisito requerido, e s˜ao declarados de acordo com o dom´ınio espec´ıfico atrav´es de namespaces.
WS-Addressing [23]: Servi¸cos Web devem ser interoper´aveis mesmo operando so- bre diferentes protocolos de transporte. Cada protocolo de transporte aplica uma solu¸c˜ao pr´opria para endere¸car servi¸cos, recursos, ou pontos de rede. Desta ma- neira, a especifica¸c˜ao WS-Addressing preenche essa lacuna, definindo um mecanismo padr˜ao para identifica¸c˜ao de servi¸cos Web e troca de mensagens entre m´ultiplos destinos (end points). WS-Addressing define elementos XML para identificar re- ferˆencias a servi¸cos Web e garantir a identifica¸c˜ao ponto-a-ponto em cada mensa- gem. A referˆencia de destino (endpoint reference), denotado pela express˜ao wsa: EndpointReference, tem como principais atributos o endere¸co URI (wsa:Address) e a porta do servi¸co (wsa:PortType), de forma a permitir que um servi¸co em um WSDL seja uma entidade referenci´avel independentemente da referˆencia concreta do protocolo de transporte. Para as mensagens SOAP, ´e acrescentado no cabe¸calho, dentre outras informa¸c˜oes, o campo wsa:To, onde o conte´udo ´e literalmente o en- dere¸co atribu´ıdo ao servi¸co de destino da mensagem.
Outros exemplos de especifica¸c˜oes s˜ao o WS-Security, WS-Coordination, WS-Atomic Transaction, dentre outros.
2.3
Dependabilidade em Arquitetura Orientada a Ser-
vi¸cos Web
A proposta deste trabalho tem foco especial em dependabilidade de sistemas cuja arqui- tetura ´e orientada a servi¸cos Web. Devido `a n˜ao-confiabilidade inerente desta arquitetura (i.e. autonomia da infra-estrutura de comunica¸c˜ao e dos servi¸cos publicados), ´e impor- tante levantar e salientar quais atributos, amea¸cas e meios s˜ao relevantes considerando
2.3. Dependabilidade em Arquitetura Orientada a Servi¸cos Web 23
dependabilidade para servi¸cos Web.
Em uma proposta de uma metodologia para constru¸c˜ao de aplica¸c˜oes de servi¸cos Web com alta dependabilidade a partir de servi¸cos com baixa ou nenhuma dependabilidade, Gorbenko et al. fazem um estudo preliminar de atributos de dependabilidade e falhas em servi¸cos Web [39]. Desempenho e responsividade s˜ao atributos importantes e facil- mente obtidos usando solu¸c˜ao de computa¸c˜ao paralela. Por´em confiabilidade e seguran¸ca s˜ao atributos mais desafiadores. Este trabalho tamb´em define uma taxonomia de falhas aplic´avel a servi¸cos Web a partir de taxonomias existentes.
Tartanoglu et al. [60] exploram os requisitos para a aplica¸c˜ao de t´ecnicas de tolerˆancia a falhas para servi¸cos Web compostos que leva em conta a natureza n˜ao confi´avel do am- biente operacional (Internet e servi¸cos de terceiros). As poss´ıveis falhas que os servi¸cos tem que lidar em composi¸c˜oes v˜ao desde falhas em n´ıvel de servi¸cos Web, notificados com mensagens de erro, como tamb´em falhas em n´ıvel de plataforma e falhas durante atua- liza¸c˜oes on-line de servi¸cos e suas interfaces. J´a as t´ecnicas de recupera¸c˜ao de erros podem se situar entre duas grandes classes: recupera¸c˜ao por retrocesso (backward recovery, e.g. tentativas seguidas de chamar um servi¸co, cancelamento, compensa¸c˜ao) ou recupera¸c˜ao por avan¸co (forward recovery, e.g. tratamento de exce¸c˜oes em n´ıvel de aplica¸c˜ao).
A referˆencia mais importante dessa disserta¸c˜ao ´e a tese de Y. Chen, que apresenta os requisitos e implementa¸c˜ao de um mediador de servi¸cos Web chamado WS-Mediator [16] (estudo detalhado do WS-Mediator ser´a feito na se¸c˜ao 2.4.1). Dentro do contexto de dependabilidade, esta pesquisa define quais aspectos foram relevantes para a con- cep¸c˜ao da solu¸c˜ao computacional para media¸c˜ao e quais manifesta¸c˜oes s˜ao mais comuns em aplica¸c˜oes baseadas em servi¸cos Web. Adicionalmente `as proposi¸c˜oes da se¸c˜ao 2.1 serem aplic´aveis para se obter tolerˆancia a falhas em SOA, os t´opicos detec¸c˜ao de erros e tratamento de falhas foram abordados com maior profundidade.
Y. Chen oferece em sua implementa¸c˜ao duas solu¸c˜oes de tolerˆancia a falhas: blocos de recupera¸c˜ao (recovery blocks), e programa¸c˜ao N-vers˜oes (N-version programming), ambas no ˆambito de estrat´egia de recupera¸c˜ao de falhas por retrocesso (backward recovery). Blocos de recupera¸c˜ao visam manter a continuidade do servi¸co diante de presen¸ca de falhas. Se erros ocorrerem durante a transa¸c˜ao, o sistema retrocede para um estado anterior correto, e procedimentos de tentativa ou reconfigura¸c˜ao para servi¸cos redundantes ´e operado. J´a programa¸c˜ao N-vers˜oes ´e comumente aplicada em aplica¸c˜oes com criticidade elevada, onde falhas de projeto e de implementa¸c˜ao devem ser toleradas. Esta t´ecnica de compensa¸c˜ao requer m´ultiplas vers˜oes dos componentes de software ou desenvolvidas de forma independente, mas com especifica¸c˜ao funcional idˆenticas.
Por fim, considerando composi¸c˜ao de servi¸cos em SOA e padr˜oes de web services, Zalewski [65] levanta alguns riscos cr´ıticos, j´a que SOA introduz novas tecnologias, levando `