sexta-feira, 29 de novembro de 2013

Buffer Cache Hit Ratio Oracle Tuning Performance

Buffer Cache Hit Ratio

https://www.simple-talk.com/sql/database-administration/great-sql-server-debates-buffer-cache-hit-ratio/


http://www.dbspecialists.com/files/presentations/buffercache.html

http://www.fadalti.com/oracle/database/how_to_statspack.htm

http://victor-dba.blogspot.com.br/2012/02/scripts-monitores-de-performance.html

Oracle® Database Performance Tuning Guide

Oracle® Database Performance Tuning Guide
http://docs.oracle.com/cd/B19306_01/server.102/b14211/toc.htm

pHmetro Caseiro

Medidor de pH “caseiro”
Um indicador de pH alternativo é o sumo da couve-roxa (ou o caldo onde foi cozida). Segue abaixo, os passos para o teste.
Material básico necessário:
- Folhas de repolho roxo
- Recipientes para armazenamento
- Peneira
- Líquido a ser avaliado
Procedimento:
- Separe e pique algumas folhas de repolho roxo dentro de um recipiente que possa ser levado ao fogo, adicione um pouco de água e ferva por 10 minutos para a infusão. Deixe esfriar, coe e reserve. Então, este será o líquido indicador.
- Coloque o líquido, como por exemplo, água (seja de rio, lago, poço ou chuva), em um recipiente e jogue o líquido indicador. Observe a cor, em seguida, utilize a escala abaixo para classificação.
Escala de pH – “Indicador de Couve-Roxa”
escala-do-ph-couve-roxa
Imagem 1 – Escala de pH – “Indicador de Couve-Roxa”
Alguns valores comuns de pH
tabela_1

JAVASCRIPT - Uso AJAX e JSON

Uso em Ajax


                                                      


AJAX (Asynchronous Javascript and XML1.,  "Javascript Assíncrono e XML") é um grupo de técnicas de desenvolvimento web interligadas usado no lado do cliente para criar aplicações web assíncronas.

Com Ajax, aplicações web podem enviar e recuperar dados de um servidor de forma assíncrona (em segundo plano), sem interferir com a exibição e comportamento da página. Os dados podem ser recuperados usando o objeto XMLHttpRequest2.

Apesar do nome, não é necessário o uso de XML (JSON é frequentemente usado em seu lugar) e as requisições não precisam ser assíncronas.

Ajax não é uma tecnologia única, mas um grupo de tecnologias. HTML e CSS podem ser usados em combinação para marcação de hipertexto e informações de estilo. 

O DOM3 é acessado com JavaScript para exibir de forma dinâmica, e permitir que o usuário interaja com a informação apresentada. 

JavaScript e o objeto XMLHttpRequest fornecer um método para troca de dados de forma assíncrona entre o navegador e o servidor para evitar recargas de página inteira.

JSON é frequentemente usado em técnicas de Ajax. Ajax é um termo para a capacidade de uma página na internet para solicitar novos dados depois de ter carregado no navegador da web, geralmente em resposta a ações do usuário na página exibida. 

Como parte do modelo Ajax, os novos dados são geralmente incorporados no ecrã interface de usuário dinâmica que ele chega de volta a partir do servidor .

 Um exemplo disso na prática pode ser que enquanto o usuário está digitando em uma caixa de pesquisa , o código do lado do cliente envia o que escreveu até agora a um servidor que responde com uma lista de possíveis termos de busca completo de seu banco de dados.

Estes podem ser exibidas em uma lista drop-down abaixo da pesquisa, de modo que o usuário pode parar de digitar e selecionar uma seqüência de pesquisa completa e comumente usado diretamente. 

Quando foi originalmente descrita em meados dos anos 2000 , o Ajax comumente usado XML como formato de intercâmbio de dados, mas muitos desenvolvedores também têm usado JSON para passar atualizações Ajax entre o servidor eo cliente.

O código JavaScript a seguir é um exemplo de um cliente usando XMLHttpRequest para solicitar dados em formato JSON de um servidor . ( A programação do lado do servidor é omitida, e deve ser configurada para responder a solicitações de URL com uma string JSON-formatada. )


var my_JSON_object;
var http_request = new XMLHttpRequest();
http_request.open("GET", url, true);
http_request.onreadystatechange = function () {
    var done = 4, ok = 200;
    if (http_request.readyState == done && http_request.status == ok) {
        my_JSON_object = JSON.parse('''http_request.responseText''');
    }
};
http_request.send(null);


JavaScript eval ()

Porque a maioria de texto JSON formatado também é código sintático JavaScript, uma maneira fácil para um programa JavaScript para analisar dados de JSON- formatado é usar a função built-in JavaScript eval (), que foi desenvolvida para avaliar expressões JavaScript .Ao invés de usar um analisador específico do JSON, o interpretador JavaScript em si é usado para executar os dados JSON produzindo objetos JavaScript nativas.

Há, no entanto , alguns caracteres Unicode que são válidos em strings JSON mas inválido em JavaScript, usar 'escape sequence4' adicional pode ser necessária em alguns casos.


A menos que sejam tomadas precauções para validar os dados em primeiro lugar, a técnica eval está sujeito a vulnerabilidades de segurança quando os dados e todo o ambiente JavaScript não estão sob o controle de uma única fonte confiável.

Por exemplo, se os dados em si não é confiável, ele está sujeito a ataques de injeção de código malicioso JavaScript. Essas quebras de confiança também pode criar vulnerabilidades para roubo de dados, autenticação de falsificação, e outro mau uso potencial de dados e recursos. As expressões regulares podem ser usados ​​para validar os dados antes de chamar eval (). A RFC que define JSON (RFC 4627) sugere a utilização do seguinte código para validar JSON antes de validá-lo (a variável 'texto' é a entrada JSON):

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
    text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');

Uma nova função, JSON.parse (), foi, assim, desenvolveu-se como uma alternativa mais segura para eval. Ele destina-se especificamente para processar dados JSON e não JavaScript. Ele foi originalmente planejado para inclusão na quarta edição do padrão ECMAScript, [25] mas isso não ocorreu. Foi adicionado primeiro à quinta edição, [26] e agora é suportado pelos principais navegadores listados abaixo. Para os mais velhos, uma biblioteca JavaScript compatível está disponível em JSON.org.


XML (eXtensible Markup Language)é usado para gerar linguagens de marcação para necessidades especiais.
                                                                 Ficheiro:XML-pt.svg

XML tem sido usada para descrever dados estruturados e para serializar objetos. Existem vários protocolos baseados em XML para representar o mesmo tipo de estrutura de dados como JSON para o mesmo tipo de efeitos de intercâmbio de dados. 
Quando os dados são codificados em XML, o resultado é tipicamente maior do que uma codificação equivalente em JSON, principalmente por causa das marcas de fechamento de XML. No entanto, se os dados são compactados usando um algoritmo como gzip, há pouca diferença porque a compressão é boa em economia de espaço quando um padrão se repete.

Quando usado sem um esquema XML, valores XML não tem um tipo de dados específico.

XMLHttpRequest (XHR)2.  É uma API disponível para linguagens de script do navegador da Web, usada para enviar solicitações HTTP ou HTTPS para um servidor web e carregar os dados de resposta do servidor de volta para o script. Os dados são também comumente recebido como JSON, HTML ou como texto simples.

Dados da resposta pode ser utilizada para alterar o documento actual na janela de navegador sem carregar uma nova página.

 Os dados de resposta também pode ser avaliada pelo script do lado do cliente. Por exemplo, se ele foi formatado como JSON pelo servidor web, ele pode ser convertido em um objeto de dados do lado do cliente para uso posterior.

XMLHttpRequest tem um papel importante na técnica de desenvolvimento web Ajax. Atualmente é usado por muitos sites para implementar aplicações web ágeis e dinâmicas.

XMLHttpRequest está sujeito à política de mesma-origem do navegador: por razões de segurança, os pedidos só terão sucesso se forem feitas para o mesmo servidor que serviu a página web de origem.

/*
   Provide the XMLHttpRequest constructor for Internet Explorer 5.x-6.x:
   Other browsers (including Internet Explorer 7.x-9.x) do not redefine
   XMLHttpRequest if it already exists.
 
   This example is based on findings at:
   http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx
*/
if (typeof XMLHttpRequest === "undefined") {
  XMLHttpRequest = function () {
    try { return new ActiveXObject("Msxml2.XMLHTTP.6.0"); }
    catch (e) {}
    try { return new ActiveXObject("Msxml2.XMLHTTP.3.0"); }
    catch (e) {}
    try { return new ActiveXObject("Microsoft.XMLHTTP"); }
    catch (e) {}
    throw new Error("This browser does not support XMLHttpRequest.");
  };
}

O Document Object Model (DOM) 3é uma convenção multi-plataforma e independente de linguagem para representar e interagir com objetos em HTML, XHTML e documentos XML.  Objetos na árvore DOM podem ser dirigidos e manipulados usando métodos nos objetos . A interface pública de um DOM é especificado em sua interface de programação de aplicativos (API).

Escape sequence4  seqüência de escape é uma série de caracteres utilizados para alterar o estado de computadores e seus dispositivos periféricos conectados. Estes são também conhecidos como as sequências de controle, que refletem a sua utilização no controle do dispositivo. 

Algumas seqüências de controle são caracteres especiais que sempre têm o mesmo significado. Seqüências de escape usar um caractere de escape para mudar o significado dos caracteres que o seguem, o que significa que os caracteres podem ser interpretados como um comando a ser executado ao invés de dados.

Seqüências de escape são comumente usados ​​quando um computador e um periférico têm apenas um único canal através do qual se envia e retorna informações. Se o dispositivo em questão é "burro" e só pode fazer uma coisa com a informação a ser enviada a ele (por exemplo, imprimi-lo), então não há necessidade de uma seqüência de escape. No entanto a maioria dos dispositivos têm mais de um recurso, e, portanto, precisa de alguma forma de distinguir a informação que está a ser tratada como dados de informação que está a ser tratado como comandos.


quinta-feira, 28 de novembro de 2013

JAVASCRIPT OBJECT NOTATION (JSON) - JSON.org

Sites Oficiais JSON e JSON-RPC


http://www.apps.ietf.org/rfc/rfc4627.html

http://www.apps.ietf.org/rfc/rfc4627.html

JAVASCRIPT OBJECT NOTATION - JSON-RPC

JAVASCRIPT OBJECT NOTATION - JSON

                                     

RPC 

Uma Chamada de Procedimento Remoto (RPC) é uma comunicação entre processos que permite a um programa de computador executar uma sub-rotina ou procedimento em outro endereço (geralmente em outro computador em uma rede compartilhada) sem que o programador tenha codificado explicitamente os detalhes sobre a interação remota.

Isto é, o programador escreve essencialmente o mesmo código quer a sub-rotina seja para execução local do programa, ou para execução remota.

 Quando o software em questão utiliza princípios de orientação a objetos, RPC é chamado de invocação remota ou invocação de método remoto.

Envio de Mensagens


Uma RPC é iniciada pelo cliente, que envia uma mensagem de requisição para um servidor remoto conhecido para executar um procedimento especificado com parâmetros fornecidos.

 O servidor remoto envia uma resposta para o cliente, e o aplicativo continua o seu processo.

 Enquanto o servidor está processando a chamada, o cliente é bloqueado (ele espera até que o servidor tenha terminado o processamento antes de retomar a execução), a não ser que o cliente envie uma solicitação assíncrona para o servidor, como uma chamada XHTTP.

 Há muitas variações e subtilezas em várias implementações, resultando numa variedade de diferentes (incompatíveis) protocolos RPC.

Uma diferença importante entre chamadas de procedimento remoto e chamadas locais é que as chamadas remotas podem falhar por causa de problemas imprevisíveis de rede.

 Além disso, os chamadores geralmente tem que lidar com essas falhas sem saber se o procedimento remoto foi aceito, ou se teve a requisição compilada.

 Procedimentos idempotentes (aqueles que não têm efeitos adicionais se for chamado mais de uma vez) são facilmente manipulados, mas muitas dificuldades permanecem onde o código para chamar procedimentos remotos é muitas vezes confinado um a escrita cuidadosa em subsistemas de baixo nível.

                          

Seqüência de eventos durante uma RPC

  1. O cliente chama o stub (um trecho do código usado para conversão de parâmetros passados durante uma RPC) do cliente. A chamada é um de procedimento de chamada local, com parâmetros colocados em pilha de uma forma normal.
  2. O stub do cliente empacota os parâmetros em uma mensagem e faz uma chamada para o sistema enviar a mensagem. Empacotar dos parâmetros é chamado de  marshalling ( serialização - processo de conversão de dados ou objetos em um fluxo de bytes ).
  3. Sistema operacional local do cliente envia a mensagem a partir da máquina do cliente para a máquina do servidor.
  4. O sistema operacional na máquina do servidor repassa os pacotes da entrada para o stub do servidor.
  5. O stub do servidor desempacota os parâmetros da mensagem. Desempacotando os parâmetros é chamado unmarshalling (deserialização - processo inverso de conversão de um fluxo de bytes de volta a seus dados ou objetos originais).
  6. Finalmente, o stub do servidor chama o procedimento servidor do sistema operacional. A resposta segue os mesmos passos na direção inversa.

Padronização dos Mecanismos de Contato

Para permitir que diferentes clientes acessem os servidores, foram criadas uma série de sistemas RPC padronizados. 
A maioria deles usa uma Linguagem de Descrição da interface (IDL) para permitir que várias plataformas possam chamar o RPC.
 Os arquivos IDL pode então ser utilizado para gerar o código de interface entre o cliente e o servidor.

JSON_RPC


É um protocolo RPC (Remote Procedural Call) construído em JSON, como um substituto para o XML-RPC e SOAP, sendo um simples protocolo que define somente alguns tipos de dados e comandos. 
Em contraste ao XML-RPC ou ao SOAP, ele permite comunicação bidirecional entre o serviço e o cliente, como uma espécie de peer-to-peer, onde cada uma das pontas pode chamar a outra ou enviar notificações(informações enviadas ao servidor que não requerem uma resposta). Ele também permite o envio de múltiplas chamadas de uma ponta a outra que podem ser respondidas fora de ordem.
Uma comunicação JSON pode ser feita em uma requisição HTTP onde o conteúdo é do tipo application/json.1 Além de usar o HTTP para transporte, podem ser usados sockets TCP/IP. Usando sockets, podem ser criadas aplicações web mais responsivas com o JSON-RPC, em comparação com um simples tráfego de um serviço JSON-RPC sobre HTTP.

Abaixo há um exemplo de um JSON-RPC 2.0 com pedido e resposta usando parâmetros posicionais.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

Utilização do JSON-RPC

JSON-RPC funciona através do envio de uma solicitação para um servidor de aplicação que implemente este protocolo. O cliente neste caso é tipicamente o software com a intenção de chamar um único método de um sistema remoto.

Múltiplos parâmetros de entrada podem ser passados ​​para o método remoto como um array ou objeto, ao passo que o próprio método pode também retornar múltiplos dados de saída (Isso depende da versão implementada)


Um método remoto é invocado pelo envio de uma requisição a um serviço remoto usando HTTP ou um soquete TCP/IP. Ao usar o HTTP, o tipo de conteúdo pode ser definido como application/json.

Todos os tipos de transferência são objetos individuais, serializados (convertidos em um fluxo de bytes) usando JSON.

Requisição é uma chamada enviada um método específico disponível em um sistema remoto. Deve conter três certas propriedades :

  1. Método - Uma String com o nome do método a ser invocado.
  2. parâmetros - Um Array de objetos a serem passados ​​como parâmetros para um determinado método.
  3. id - Um valor de algum tipo, que é usado para comparar a resposta com a requisição que foi executada.

O receptor do pedido deve responder com uma resposta válida a todos os pedidos recebidos. A resposta deve conter as propriedades mencionadas abaixo:

  1. resultado - Os dados retornados pelo método invocado. Se ocorreu um erro ao chamar o método, esse valor deve ser nulo.
  2. erro - Um código de erro especificado se houver um erro de chamar do método , caso contrário, nulo.
  3. id - O ID da requisição que está sendo respondida.



Uma vez que há situações em a resposta não é necessária ou mesmo indesejadas, notificações foram introduzidas.

Uma notificação é semelhante a uma requisição exceto pelo id, que não é necessário porque nenhuma resposta será retornada. Neste caso a propriedade id deve ser omitida ou ser nula.

Exemplos para JSON-RPC Versão 2.0

Nestes exemplos, --> indica os dados enviados a um serviço (requisição), enquanto <-- indica os dados de resposta provenientes de um serviço. (Embora <-- muitas vezes é chamado de resposta em computação cliente-servidor, dependendo da versão JSON-RPC não implica, necessariamente, resposta a um pedido).

Chamada de procedimento com parâmetros de posição: 

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}
--> {"jsonrpc": "2.0", "method": "subtract", "params": [23, 42], "id": 2}
<-- {"jsonrpc": "2.0", "result": -19, "id": 2}

Chamada de procedimento com parâmetros nomeados: 

--> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23, "minuend": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}
--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 4}
<-- {"jsonrpc": "2.0", "result": 19, "id": 4}

Exemplo de Notificação: 

--> {"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5]}
--> {"jsonrpc": "2.0", "method": "foobar"}

Exemplo de Chamada de Procedimento de um Procedimento Não-Existente:

--> {"jsonrpc": "2.0", "method": "foobar", "id": 10}
<-- {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Procedure not found."}, "id": 10}

Chamada de Procedimento com JSON inválido: 

--> {"jsonrpc": "2.0", "method": "foobar", "params": "bar", "baz"]
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}

Chamada de Procedimento com JSON-RPC inválido: 

--> [1,2,3]
<-- [
  {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
  {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
  {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}
]
--> {"jsonrpc": "2.0", "method": 1, "params": "bar"}
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}





JAVASCRIPT OBJECT NOTATION - JSON

                                   

JavaScript Object Notation, é um formato padrão aberto que usa texto legível para transmitir objetos de dados que consistem em pares de valores de atributo.

 É utilizado principalmente para transmitir dados entre um servidor e aplicação da web, como uma alternativa para XML.

Embora originalmente derivada da linguagem de script JavaScript, JSON é um formato de dados independente de linguagem, e codifica para analisar e gerar dados JSON está prontamente disponível em uma grande variedade de linguagens de programação.

 A extensão do arquivo JSON é. Json.

Tipos de Dados


Tipos básicos de JSON são:
  • Number (dupla precisão formato de ponto flutuante )
  • String (entre aspas Unicode, com barras de escape)
  • Boolean (true ou false)
  • Array (, uma seqüência separada por vírgula ordenada de valores entre colchetes; os valores não precisam ser do mesmo tipo)
  • Object (uma coleção não-ordenada, separada por vírgulas de chaves)
  • null (vazio)

Espaço em branco não significativos podem ser adicionados livremente em torno dos "caracteres estruturais" (ou seja, chaves, colchetes "{} []", dois pontos ":" e vírgulas ",").

O exemplo a seguir mostra a representação JSON de um objeto que descreve uma pessoa. O objeto tem campos string para o primeiro nome e sobrenome, um campo de número para a idade, um objeto que representa o endereço da pessoa e uma array de objetos telefone.

{
    "primeiroNome": "João",
    "ultimoNome": "Ferreiro",
    "idade": 25,
    "endereco": {
        "rua": "rua Austero Penteado 115",
        "cidade": "Campinas",
        "estado": "SP",
        "codigoPostal": 13020 320
    },
    "telefoneNumeros": [
        {
            "tipo": "casa",
            "numero": "19 3239-0751"
        },
        {
            "tipo": "fax",
            "numero": "19 3239-0751"
        }
    ]
}


Uma armadilha potencial da natureza de forma livre de JSON vem da capacidade de escrever números tanto como números literais quanto strings citadas.

 Por exemplo, os CEP no nordeste dos EUA começam com zeros (por exemplo, 07728 para Freehold, Nova Jersey). Se escrito como strings por um programador, mas não por outro, o zero poderia ser descartado quando a string fosse trocada entre sistemas, quando procurada dentro do mesmo sistema, ou quando impressa.

 Além disso, os códigos postais em os EUA são números, mas em outros países usam letras também. Este é um tipo de problema que o uso de um esquema JSON (ver em baixo) destina-se a reduzir.

Uma biblioteca parser JSON ou suporte JSON nativo do Javascript deve ser usado para leitura e escrita JSON. Um analisador JSON corretamente implementado aceita apenas JSON válido, impedindo códigos potencialmente maliciosos sejam executados de forma inadvertida.

var p = JSON.parse(contact);

Os navegadores da Web, desde 2010, incluiram suporte para analisar JSON. Como suporte ao navegador nativo é mais eficiente e seguro do que o eval (), suporte nativo a JSON está incluído na edição 5 do padrão ECMAScript.
A biblioteca jQuery envolve um objeto JSON em um construtor de função e executa-o imediatamente se JSON.parse não está presente. Isto evita o uso de eval no código.

 var p = new Function('return ' + contact + ';')();

Tipos de Dados Nativos Não Suportados


JavaScript sintaxe define vários tipos de dados nativos que não estão incluídos no padrão JSON :  Datas, erros, expressão regular, e função.

Estes tipos de dados JavaScript devem ser representados como algum outro formato de dados, com os programas em ambas as extremidades concordando sobre como fazer a converção entre os tipos.

Desde 2011, existem alguns padrões de eventos, por exemplo conversão entre Datas e Strings, mas nenhum universalmente reconhecida.

Outras linguagens podem ter diferentes conjuntos de tipos nativos, que devem ser serializados com cuidado para lidar com este tipo de conversão.

Esquemas e Metadados


Características do Esquema JSON:

Especifica um formato baseado em JSON para definir a estrutura de dados JSON para validação, documentação e controle de interação. 

Fornece um contrato para os dados JSON exigidos por uma determinada aplicação, e como esses dados podem ser alterados.

Embora baseando-se nos conceitos de esquemas XML, é um fundamento JSON próprio,  de modo que os dados JSON sob a forma de um esquema pode ser utilizado para validar dados JSON, as mesmas ferramentas de serialização/desserialização podem ser utilizadas para o esquema e dados, e é auto-descritivo .

Exemplo de Esquema JSON:

{
    "name": "Product",
    "properties": {
        "id": {
            "type": "number",
            "description": "Product identifier",
            "required": true
        },
        "name": {
            "type": "string",
            "description": "Name of the product",
            "required": true
        },
        "price": {
            "type": "number",
            "minimum": 0,
            "required": true
        },
        "tags": {
            "type": "array",
            "items": {
                "type": "string"
            }
        },
        "stock": {
            "type": "object",
            "properties": {
                "warehouse": {
                    "type": "number"
                },
                "retail": {
                    "type": "number"
                }
            }
        }
    }
}


O esquema JSON abaixo pode ser usado para teste de validação do código acima:
{
    "id": 1,
    "name": "Foo",
    "price": 123,
    "tags": [ "Bar", "Eek" ],
    "stock": {
        "warehouse": 300,
        "retail": 20
    }
}

RPC 

Uma Chamada de Procedimento Remoto (RPC) é uma comunicação entre processos que permite a um programa de computador executar uma sub-rotina ou procedimento em outro endereço (geralmente em outro computador em uma rede compartilhada) sem que o programador tenha codificado explicitamente os detalhes sobre a interação remota.

Isto é, o programador escreve essencialmente o mesmo código quer a sub-rotina seja para execução local do programa, ou para execução remota.

 Quando o software em questão utiliza princípios de orientação a objetos, RPC é chamado de invocação remota ou invocação de método remoto.

Envio de Mensagens


Uma RPC é iniciada pelo cliente, que envia uma mensagem de requisição para um servidor remoto conhecido para executar um procedimento especificado com parâmetros fornecidos.

 O servidor remoto envia uma resposta para o cliente, e o aplicativo continua o seu processo.

 Enquanto o servidor está processando a chamada, o cliente é bloqueado (ele espera até que o servidor tenha terminado o processamento antes de retomar a execução), a não ser que o cliente envie uma solicitação assíncrona para o servidor, como uma chamada XHTTP.

 Há muitas variações e subtilezas em várias implementações, resultando numa variedade de diferentes (incompatíveis) protocolos RPC.

Uma diferença importante entre chamadas de procedimento remoto e chamadas locais é que as chamadas remotas podem falhar por causa de problemas imprevisíveis de rede.

 Além disso, os chamadores geralmente tem que lidar com essas falhas sem saber se o procedimento remoto foi aceito, ou se teve a requisição compilada.

 Procedimentos idempotentes (aqueles que não têm efeitos adicionais se for chamado mais de uma vez) são facilmente manipulados, mas muitas dificuldades permanecem onde o código para chamar procedimentos remotos é muitas vezes confinado um a escrita cuidadosa em subsistemas de baixo nível.

Seqüência de eventos durante uma RPC

  1. O cliente chama o stub (um trecho do código usado para conversão de parâmetros passados durante uma RPC) do cliente. A chamada é um de procedimento de chamada local, com parâmetros colocados em pilha de uma forma normal.
  2. O stub do cliente empacota os parâmetros em uma mensagem e faz uma chamada para o sistema enviar a mensagem. Empacotar dos parâmetros é chamado de  marshalling ( serialização - processo de conversão de dados ou objetos em um fluxo de bytes ).
  3. Sistema operacional local do cliente envia a mensagem a partir da máquina do cliente para a máquina do servidor.
  4. O sistema operacional na máquina do servidor repassa os pacotes da entrada para o stub do servidor.
  5. O stub do servidor desempacota os parâmetros da mensagem. Desempacotando os parâmetros é chamado unmarshalling (deserialização - processo inverso de conversão de um fluxo de bytes de volta a seus dados ou objetos originais).
  6. Finalmente, o stub do servidor chama o procedimento servidor do sistema operacional. A resposta segue os mesmos passos na direção inversa.

Padronização dos Mecanismos de Contato

Para permitir que diferentes clientes acessem os servidores, foram criadas uma série de sistemas RPC padronizados. 
A maioria deles usa uma Linguagem de Descrição da interface (IDL) para permitir que várias plataformas possam chamar o RPC.
 Os arquivos IDL pode então ser utilizado para gerar o código de interface entre o cliente e o servidor.

JSON_RPC


É um protocolo RPC (Remote Procedural Call) construído em JSON, como um substituto para o XML-RPC e SOAP, sendo um simples protocolo que define somente alguns tipos de dados e comandos. 
Em contraste ao XML-RPC ou ao SOAP, ele permite comunicação bidirecional entre o serviço e o cliente, como uma espécie de peer-to-peer, onde cada uma das pontas pode chamar a outra ou enviar notificações(informações enviadas ao servidor que não requerem uma resposta). Ele também permite o envio de múltiplas chamadas de uma ponta a outra que podem ser respondidas fora de ordem.
Uma comunicação JSON pode ser feita em uma requisição HTTP onde o conteúdo é do tipo application/json.1 Além de usar o HTTP para transporte, podem ser usados sockets TCP/IP. Usando sockets, podem ser criadas aplicações web mais responsivas com o JSON-RPC, em comparação com um simples tráfego de um serviço JSON-RPC sobre HTTP.

Abaixo há um exemplo de um JSON-RPC 2.0 com pedido e resposta usando parâmetros posicionais.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}