Boa noite amigos!
Vamos ver hoje a terceira parte de tradução de “Scarce Objects”. No versículo anterior vimos a segunda.
O Provedor é responsável por realmente manter o objeto, que pode conter um estado exclusivo. Ele publica uma descrição assinada de seu método de objeto escasso, descrevendo um tipo particular de direito genérico (por exemplo, na forma de pré e pós-condições de projeto por contrato). O emissor e o agente de transferência criam placas e se preparam para emitir tickets para o método.
Qualquer um ou todos desses servidores componentes podem ser distribuídos, usando métodos descritos aqui [link quebrado] e aqui. Uma assinatura distribuída é usada para emitir tickets (M de N devem assinar usando uma chave privada distribuída para que uma assinatura verificável seja produzida). Essa distribuição reduz bastante a exposição à quebra de confiança e, portanto, reduz os custos mentais de transação do rastreamento de reputação.
Para implementar transferências exclusivas, o TA mantém uma lista de números de tickets cancelados. Um ticket é cancelado sempre que é transferido ou usado. O Provedor instrui o AT quando um ticket foi usado ou, alternativamente, os dois gravam em uma lista compartilhada de tickets compensados.
O AT e o emissor veem apenas classes de objetos fungíveis. O provedor e os usuários veem instâncias específicas com um estado exclusivo. No exemplo acima, de um direito genérico de banco de dados, o Provedor vê um banco de dados preenchido com informações exclusivas, enquanto o TA e o Emissor veem apenas a descrição genérica dos métodos de chamada de objeto de banco de dados.
Em contraste com os servidores, o usuário remoto de um objeto escasso agrupa seu stub de chamada de objeto com chamadas que trocam por tickets necessários (novamente usando um tradutor de mercado), envia os tickets conforme necessário com invocações de método aos Provedores desses métodos. Em alguns casos (esperançosamente muitos) casos, serviços genéricos suficientemente idênticos serão fornecidos pelos concorrentes. Onde isso ocorre, um “cliente de ticket” também pode “comprar” no sentido de que, se as condições pré ou pós da chamada do método falharem, ou se a invocação for detectada como defeituosa, o cliente do ticket tentará novamente chamando o método do concorrente.
O servidor do provedor é quase apenas outro cliente de ticket para o TA, que, como outros clientes, pode transferir ou receber tickets. Sua função especial é informar o AT quando os tickets tiverem sido usados, portanto, devem ser cancelados (ou, ainda, escrever o número do ticket cancelado diretamente em uma lista de números de tickets cancelados que ele compartilha com o TA). Somente o emissor pode criar tickets e somente o provedor pode consumi-los.
No centro do Provedor está o próprio objeto bruto, o conjunto de métodos que fornecem os serviços definidos para clientes de objetos escassos. O provedor é o invólucro em torno deste objeto. Além das funções de controle, verificação e consumo de tickets, o Fornecedor pode acompanhar e informar o Emissor sobre o uso de recursos.
O Emissor, por sua vez, é a interface para as funções de micro-mercados, especialmente o tradutor de mercado descrito abaixo. O Emissor pode, por exemplo, através de um tradutor de mercado, que incorpore as preferências da pessoa que opera o Provedor, negociar acordos de permuta nos quais determinados bilhetes são emitidos e trocados por outros tickets que dão direito de invocar os métodos de objetos escassos da contraparte ou de uma terceira parte. As negociações podem também ser multipartidárias, ou seja, leilões e exchanges [corretoras/trocas] secundários por direitos genéricos também podem ser desenvolvidos para tickets de objetos escassos. Por sua vez, o tradutor de mercado, para emitir operações de troca automatizadas (baixo custos mentais de transação), depende da existência de exchanges de direitos genéricos de objetos escassos.
O TA gera fornecimento de tickets somente a pedido do Emissor e o destrói somente a pedido do Fornecedor. Todas as suas próprias transferências preservam o fornecimento de um direito genérico em específico. O Fornecedor também é responsável pela entrega do serviço ao cliente que satisfaz a descrição do serviço (contrato, por exemplo, condições pré e pós), momento em que o Fornecedor “deposita”os tickets genéricos, ou seja, os adiciona à lista cancelada.
O Provedor emite junto com o ticket inicial de direitos genéricos um certificado assinado, legível por máquina ou humano, descrevendo aspectos do objeto que podem ser não exclusivos e únicos, juntamente com o número do ticket dessa instância e a(s) chave(s) pública(s) do direito genérico para o qual é válido. Por exemplo, pode dizer “um banco de dados contendo cotações dessas duas dúzias de ações listadas a partir das 12:22 da noite de segunda-feira”, sem realmente conter essas cotações. Geralmente, essa descrição vale mais quando combinada com direitos exclusivos genéricos, como o direito a um tempo de resposta rápido. Os direitos específicos podem ser elaborados de maneira única sobre os direitos genéricos, desde que essas elaborações não sejam tomadas para definir direitos exclusivos. Os direitos genéricos permitem que os TAs ofereçam exclusividade aos usuários e conservação de recursos aos Provedores, enquanto os direitos específicos descrevem o estado único em qualquer grau de elaboração desejado. O Provedor deve estar preparado para atender a qualquer promessa específica que tenha sido emitida, desde que acompanhado pelos tickets genéricos conservados adequados.
Vista a terceira, no próximo versículo a quarta parte. E por fim, e não menos importante, feliz dia das mães à todas, especialmente a minha <3.
