e um protocolo projetado para invocar aplicacoes remotas atraves de RPC (Remote Procedure Calls - Chamadas Remotas de Procedimento) ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programacao. SOAP e, portanto, um padrao normalmente aceito para utilizar-se com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicacao entre diferentes sistemas, atraves da utilizacao de uma linguagem (XML) e mecanismo de transporte (HTTP) padroes. 2.2 CONTROLE DE CONCORRENCIA Ao utilizamos o nosso sistema para locacao de veiculos via web, como podemos ter o controle sobre os bloqueios em nivel de registro? Sabemos que o SQL Server gerencia bloqueios em varios niveis (banco, arquivos, tabelas, indices, paginas, etc) e que alguns objetos como sysprocesses, sp_lock, sys.dm_exec_requests, sys.dm_tran_locks,etc podem ajudar mas servem apenas para monitoramente e nao paracontrole. Imaginemos a seguinte situacao:Nossa aplicacao Web recupera e atualizadados de varios clientes simultaneos. Pode acontecer de dois atendentes (A1 e A2) recuperarem os dados do um Cliente (C1), fazerem atualizacoes divergentes e apenas um deles saira vencedor. Suponhamos que A1 e A2 recuperem os dados e que A1 atualize o estado civil do Cliente C1 de solteiro para casado e que A2 atualize a renda do cliente de R$ 2.000,00 para R$ 3.000,00. Se A1 vencer, C1 sera casado, mas possuira renda de R$ 2.000,00. Se A2 vencer, C1 sera solteiro, mas possuira renda de R$ 3.000,00. Nenhuma das situacoes e a ideal e revelam um problema classico de concorrencia. Se a aplicacao fosse Desktop, enquanto A1 estiver atualizando A2 fica bloqueado. Se A2 chegasse primeiro, A1 ficaria bloqueado. Seria possivel detectar que existe um bloqueio, mas ainda que isso fosse possivel nao teriamos como saber que o bloqueio se deve a um registro especifico (C1) e mesmo que conseguissemos. Em nossa situacao WEB a conexao a banco de dados nao pode ser mantida por muito tempo como uma aplicacao Desktop. Esse impasse e natural ja que bloqueios no banco de dados sao gerenciados pelo proprio SGBD e nao podemos (e nem devemos) a priori influenciar em como o SGBD faz esse controle. O que e necessario nao utilizar o mecanismo de bloqueios do SGBD, mas sim gerenciar bloqueios em nivel de aplicacao. O SQL Server possui duas procedures para tratar isso e que comumente sao ignoradas. Essas procedures conseguem impor um bloqueio em nivel logico podendo ser trabalhado no TSQL mas sem influenciar nos bloqueios impostos nas estruturas fisicas do SQL Server. Elas funcionam como um bit logico popularmente conhecido como flag. Essas procedures sao a sp_getapplock e sp_releaseapplock. Uma outra forma de resolver esse problema e a utilizacao de um tipo de dados que muita gente conhece mas pouca gente sabe pra que serve. O tipo de dados TIMESTAMP e otimo para uma situacao dessas. Esse tipo de dados e criado automaticamente quando o registro e inserido e alterado automaticamente quando o registro e alterado. 2.3 RECUPERACAO Segundo Carvalho (2000, apud BJORK, 1973, p. 12), a recuperacao de uma transacao e considerada uma das tarefas mais importantes no gerenciamento de transacoes. Ela consiste na recuperacao do banco de dados