Plataforma Digital do Poder Judiciário (PDPJ-Br)

O que é a PDPJ-Br?

A PDPJ-Br é, ao mesmo tempo, um lugar, uma arquitetura, e um conjunto de padrões. Trata-se da nuvem pública nacional do Poder Judiciário brasileiro para a hospedagem dos novos sistemas, módulos e serviços de interesse e uso geral dos atores envolvidos com a Administração da Justiça. A PDPJ-Br também define uma arquitetura, um modo pelo qual os mencionados sistemas, módulos e serviços devem ser desenvolvidos e se comunicarem, bem como estipula padrões a serem seguidos para realizar a arquitetura proposta.

Fundamento Normativo

Em setembro de 2020, o CNJ publicou a Resolução nº 335 que institui a política pública para a governança e a gestão de processo judicial eletrônico e a integração dos tribunais do país com a criação da Plataforma Digital do Poder Judiciário Brasileiro – PDPJ-Br.

Com a política, os múltiplos sistemas de processo judicial atualmente em produção e utilização nos Tribunais passam a serem tratados todos como aplicações legadas – aplicações com tecnologia antiga não suscetíveis de evolução futura – devendo progressivamente serem diminuídas e modularizadas para a criação de serviços nacionais – serviços independentes que se comunicam usando APIs bem definidas – permitindo, assim, em médio prazo, a convergência para um mesmo conjunto de soluções nacionais.

A disponibilização dos sistemas na PDPJ também implica que os futuros módulos e serviços sejam construídos de forma colaborativa, mediante tecnologia e metodologia fixadas pelo CNJ, desincentivando a repetição de iniciativas para atender às mesmas demandas. Assim, a Plataforma Digital do Poder Judiciário Brasileiro incentiva a cooperação entre os tribunais, preservando os sistemas públicos em produção.

Saiba mais sobre a PDPJ-Br e o Programa Justiça 4.0 no Portal CNJ.

Conceitos Básicos

Assista ao webinário abaixo que oferece uma visão geral técnica da PDPJ-Br:

RESTful API

O acrônimo REST significa Representational state transfer, e diz respeito a um conjunto de restrições de arquitetura de serviços disponíveis na web, com ênfase na utilização, pelos serviços, dos conceitos e estruturas preexistentes relativos ao protocolo HTTP.

Uma API (Application Programming Interface), por sua vez, é o meio pelo qual uma aplicação de informática se comunica com outras aplicações.

Assim, um API REST é uma forma particular de aplicações baseadas em tecnologias web se comunicarem entre si.

Os desenvolvedores de API podem implementar a arquitetura REST de maneiras variadas.

Quando um cliente faz uma solicitação usando uma API RESTful, essa API transfere uma representação do estado do recurso ao solicitante ou endpoint. Essa informação (ou representação) é entregue via HTTP utilizando um dos vários formatos possíveis, sendo o mais comum o Javascript Object Notation (JSON).

Para que uma API seja considerada do tipo RESTful, ela precisa está em conformidade com os seguintes critérios:

• Ter uma arquitetura cliente/servidor formada por clientes, servidores e recursos, com solicitações gerenciadas por meio de HTTP;
• Estabelecer uma comunicação stateless entre cliente e servidor. Isso significa que nenhuma informação do cliente é armazenada entre solicitações GET e toda as solicitações são separadas e desconectadas;
• Armazenar dados em cache para otimizar as interações entre cliente e servidor;
• Ter uma interface uniforme entre os componentes para que as informações sejam transferidas em um formato padronizado. Para tanto, é necessário que:
  • os recursos solicitados sejam identificáveis e estejam separados das representações enviadas ao cliente;
  • os recursos possam ser manipulados pelo cliente por meio da representação recebida com informações suficientes para tais ações;
  • as mensagens auto descritivas retornadas ao cliente contenham informações suficientes para descrever como processá-las;
  • hipertexto e hipermídia estão disponíveis. Isso significa que após acessar um recurso, o cliente pode usar hiperlinks para encontrar todas as demais ações disponíveis para ele no momento.
• Ter um sistema em camadas que organiza os tipos de servidores (responsáveis pela segurança, pelo carregamento de carga e assim por diante) envolvidos na recuperação das informações solicitadas em hierarquias que o cliente não pode ver.
• Possibilitar código sob demanda (opcional): a capacidade de enviar um código executável do servidor para o cliente quando solicitado para ampliar a funcionalidade disponível ao cliente.

Embora uma API REST precise estar em conformidade com os critérios acima, ela é considerada mais fácil de usar do que o Protocolo Simples de Acesso a Objetos (SOAP). Esse tipo de protocolo tem requisitos específicos, como a comunicação por meio de troca de arquivos XML, o que o torna mais lento e pesado.

Em comparação, a arquitetura REST é composta de um conjunto de diretrizes que podem ser implementadas conforme necessário. Isso faz com que as APIs REST sejam mais rápidas, leves e escaláveis.

Na PDPJ-Br, os serviços, módulos e sistemas, tanto quanto possível, devem expor fachadas de API REST para o seu backend, a fim de facilitar um desacoplamento maior entre o backend e o frontend de cada solução, bem como para facilitar a integração entre sistemas, por meio de comunicação direta entre backends diversos.

Autenticação via SSO

A autenticação na PDPJ-Br se dá por meio de uma solução de Single Sign On baseada no Keycloak, que é um aplicativo open source de gestão de identidade e acessos. O protocolo adotado é o OAuth2 (vide RFC 6749).

Veja mais informações sobre o SSO da PDPJ-Br e como utilizá-lo na documentação do SSO.

Discovery e Gateway API

A PDPJ-Br também possui um serviço de descoberta (discovery), que permite que APIs registradas sejam acessíveis por meio do Gateway API.

Mais informações

Veja mais informações sobre o Gateway e o Discovery da PDPJ-Br, bem como utilizar ambas as ferramentas, na documentação desses serviços.

Marketplace

A PDPJ-Br dispõe de uma interface web na qual são disponibilizados os serviços da Plataforma que possuem interface para utilização pelos usuários.

Mais informações

Veja mais detalhes e como utilizá-la na documentação da Marketplace.

Mensageria e Webhooks

Mensageria

Além do serviço de SSO (Login Único), do uso extensivo de RESTful APIs, e do Marketplace, os outros dois conceitos fundamentais para a compreensão do funcionamento da PDPJ são mensageria e webhooks.

Como é cediço, cada um dos sistemas, módulos e serviços hospedados na PDPJ deve expor uma fachada REST API para o mundo externo, de tal maneira que os sistemas de processo judicial eletrônico dos Tribunais possam se valer dessa fachada/barramento para chamar os métodos dos serviços, módulos e sistemas em questão.

Contudo, internamente à PDPJ, é encorajado que os serviços se comuniquem entre si por meio de troca de mensagens, fazendo uso de um Message Broker. No caso da PDPJ, utiliza-se para tanto a solução open source RabbitMQ.

Esse mecanismo de comunicação agrega uma maior robustez à arquitetura, uma vez que as mensagens são enfileiradas em filas (queues) definidas por cada aplicação, as quais podem consumir as mensagens a seu tempo e modo, ou seja, de forma assíncrona e conforme sua capacidade de processamento.

Mais informações

Para mais detalhes sobre o funcionamento do serviço de mensageria, consulte a sua página de documentação.

Eventos Negociais

Além das mensagens "ordinárias" trocadas entre os serviços, módulos e sistemas hospedados na PDPJ, algumas mensagens podem representar uma evento negocial relevante para outro sistema, em especial para os sistemas de processo judicial eletrônico dos Tribunais. Esses eventos negociais serão comunicados, de forma assíncrona, aos sistemas ou pessoas que se inscreveram para ouvi-los, via chamadas de webhook pelo sistema de notificações da PDPJ, como explicado melhor na seção seguinte.

Importante frisar que, a despeito de se tratarem, ou não, de eventos negociais de maior relevância, todos as aplicações hospedadas na PDPJ que lançarem ou consumirem mensagens devem, em sua documentação técnica, expressamente listar tais mensagens, a fim de auxiliar as demais equipes de desenvolvimento da comunidade.

Webhooks

Lançadas as mensagens pelas aplicações hospedadas na PDPJ, elas serão consumidas por outras aplicações (internas à PDPJ) que configurarem as respectivas filas no servidor do RabbitMQ.

Contudo, para o "mundo externo", que se comunica com a PDPJ via chamadas diretas de REST APIs, a comunicação a respeito de eventos disparados pelos serviços, sistemas ou módulos da PDPJ será feito via webhooks, ou seja, por meio da indicação ao serviço de notificações da PDPJ de endpoints dos sistemas processuais dos Tribunais que serão acionados quando os referidos eventos ocorrerem.

Uma característica importante das notificações encaminhadas por este serviço é que elas são transmitidas instantaneamente e no formato definido pelo usuário no momento da sua inscrição (por ora, raw, documento ou alerta).

Os webhooks também são conhecidos como APIs reversas, já que o servidor é quem chama a API do cliente.

Mais informações

Para maiores detalhes do funcionamento do serviço de notificações, consulte sua página de documentação.

Arquitetura

A Plataforma Digital do Poder Judiciário utiliza o conceito da arquitetura distribuída de microsserviços, projetados para serem executados em ambiente de nuvem, de maneira que todos os sistemas operam em modo de alto desempenho.

O uso desse modelo arquitetural promove facilidades em diversos aspectos da implementação e operacionalização da PDPJ, entre elas estão o rápido desenvolvimento, manutenção e testes dos serviços, a robustez na segurança do sistema, o uso eficiente de recursos computacionais, a alta disponibilidade e escalabilidade, o monitoramento da saúde do sistema e a rápida atuação na mitigação de problemas.

Exemplo de tecnologias utilizadas para proporcionar esses benefícios: cluster, containers, gateways e serviços de descoberta.

O desenvolvimento dos sistemas é baseado em microsserviço, de modo que as aplicações sejam modulares e a implementação de cada serviço esteja focada em um contexto negocial específico.

O diagrama abaixo ilustra a arquitetura utilizada na implementação dos microsserviços da PDPJ:

Na arquitetura distribuída, os microsserviços são disponibilizados de forma dinâmica, de modo que seus recursos computacionais sejam alocados conforme demanda.

Cada serviço, ao ser iniciado, se registra no “Discovery” informando que está disponível para aceitar as requisições. O Discovery também se encarrega de realizar load balancing entre os serviços registrados, desta maneira, se temos cinco instâncias de Pessoas, o serviço Discovery irá distribuir as requisições, de modo a não carregar uma mais que as outras.

Cada microsserviço possui seu próprio domínio e é responsável por resolver um problema em contexto bem definido. O acesso é feito pela fachada REST, na qual estarão disponíveis as funcionalidades do serviço. A imagem abaixo ilustra as camadas básicas que compõem o serviço e um exemplo de uso de recursos do framework Spring pra implementar o serviço.

Pilha de Tecnologia

Microsserviços

Os microsserviços da PDPJ são desenvolvidos com tecnologias de código aberto, sendo o Java a principal linguagem de programação e são implementados com o uso do framework Spring, que é um conjunto de bibliotecas e ferramentas que facilita o desenvolvimento de software.

O conjunto de tecnologias utilizadas para o desenvolvimento dos microsserviços está representado na figura abaixo:

Tecnologias Empregadas

Spring Framework

• SpringCloud: Conjunto de ferramentas que possibilita um desenvolvimento rápido dos principais padrões de computação distribuída. O SpringCloud se integra aos serviços SpringBoot para prover um ambiente distribuído interligado utilizando suas bibliotecas para descoberta de serviços, roteamento, circuit-breakers, e etc. Entre as bibliotecas disponibilizadas estão as que dão suporte à suite Netflix para computação em nuvem.
• Eureka: Serviço REST utilizado como service register. Cada serviço ao ser iniciado se registra no Eureka Server que será responsável por manter um catálogo de serviços ativos. Através deste catálogo é possível atribuir outros comportamentos ao sistema, como load balancing e circuit break.
• Zuul: Serviço de borda, que tem como principal função ser um ponto único de entrada, distribuindo as requisições entre as diversas instâncias de serviços que estão registrados em sua nuvem.
• Hystrix: Faz o papel de monitorador dos serviços mantendo um conjunto de dados com informações a respeito da execução dos serviços. É seu papel também operar o circuit break.
• Data Envers: Envers é um módulo Hibernate que adiciona funcionalidades de auditoria às entities JPA.
• SpringBoot: Solução criada pela Pivotal para entregar uma aplicação Spring de maneira rápida e que esteja pronta para produção, sem que haja necessidade de um monte de configurações como acontece muito em aplicações java para WEB. Com um simples java -jar, por exemplo, é possível iniciar uma aplicação java web com um tomcat embarcado, sem necessidade de executar deploy de um arquivo war. Esse tipo de solução colabora na escalabilidade horizontal e na entrega contínua.

Recursos incializados pelo Spring Boot

• Actuator: Funcionalidades adicionais que permitem o monitoramento e gerenciamento de aplicações em produção com o uso de endpoints HTTP ou JMX.
• Micrometer: Biblioteca de instrumentação de métricas para aplicativos java. Coleta as informações da aplicação em tempo de execução e expõe em um endpoint.
• Prometheus: Banco de dados de série temporal dimensional. Extrai métricas de instâncias de aplicativos periodicamente com base na descoberta de serviço. Prometheus endpoint disponibiliza as métricas fornecidas pelo Micrometer.
• AMQP: Conjunto de ferramentas para o desenvolvimento de soluções de mensageria baseadas no protocolo AMQP (Advanced Message Queuing Protocol). Fornece um “template” como uma abstração de alto nível para envio e recebimento de mensagens.
• AOP: Paradigma de programação que visa aumentar a modularidade, permitindo a separação de interações transversais no código. Ele faz isso inserindo comportamento adicional ao código existente sem modificação do próprio código. Em vez disso, podemos declarar esse novo código e esses novos comportamentos separadamente.
• Configuration-Processor: Processador de anotação que gera metadados sobre classes em seu aplicativo que são anotadas com @ConfigurationProperties. Esses metadados são usados pelo seu IDE (Eclipse, IntelliJ ou NetBeans) para fornecer autocompletar e documentação para as propriedades ao editar os arquivos application.properties e application.yaml.
• Data JPA: Fornece suporte avançado para camada de acesso à dados baseadas em JPA.
• Data Redis: Redis é um banco de dados em memória que pode ser utilizado em formato chave-valor, cache ou agente de mensagens. Nos projetos do pdpj é utilizado como cache.
• Netflix Eureka Client: Fornece os recursos de cliente para o serviço de descoberta Eureka.
• Security: Recursos de segurança do Spring Framework. Na PDPJ, a segurança da aplicação é integrada com o software Keycloak.

Recursos e Frameworks Adicionais

• Flyway: Ferramenta para organização de scripts SQL que são executados no banco de dados, funcionando como um controle de versão do mesmo. Com ele é possível sincronizar o banco de dados com a versão da aplicação, saber quais scripts SQL foram executados ou não, automatizar a execução de scripts e criar um banco de dados do zero.
• Hibernate Envers: Biblioteca que permite auditar classes persistentes através do controle de versões em mapeamentos de objetos relacionais feitos através do Hibernate. Para cada entidade mapeada auditada, uma tabela versionada é criada no banco de dados, contendo todo o histórico das alterações efetuadas sobre aquela entidade.
• H2 Database: Banco de dados (Java puro).
• Keycloak: Solução de código aberto para o gerenciamento de identidade e acesso. Fornece funcionalidades como Single-Sign-On (SSO), entre outras.
• MapStruct: Gerador de código para a implementação de mapeamento entre tipos de beans java. No projeto é utilizado para converter DTOs em entities e vice-versa.
• PostgreSQL: Sistema gerenciador de banco de dados.
• Swagger: Linguagem de descrição de interface para descrever APIs RESTful expressas usando JSON. O Swagger é usado junto com um conjunto de ferramentas de software de código aberto para projetar, construir, documentar e usar serviços da Web RESTful.

Serviços Estruturantes

Para além da arquitetura descrita acima, alguns serviços foram desenvolvidos para facilitar a comunicação fluída entre os módulos e sistemas da PDPJ. Esses serviços foram chamados de "estruturantes", por serem a fundação sob a qual outras aplicações poderão ser desenvolvidas para a PDPJ.

Existem dois grupos de Serviços Estruturantes:

1. Serviços de integração: garantem a entrada, o processamento e a transmissão de informações entre os serviços negociais da PDPJ-Br e os sistemas processuais. Nesta categoria se encontram o Serviço de Autenticação (SSO), o Serviço de Notificações, o Marketplace da PDPJ e a plataforma Codex.

2. Serviços de padronização e enriquecimento de dados: visam garantir a higienização de dados de processos em tramitação nas plataformas processuais com o objetivo de trazer melhor fluidez no recebimento e na transmissão de dados, que serão realizados por meio dos serviços estruturantes de integração. Nesta categoria se encontram os serviços de Consulta às Tabelas Processuais Unificadas, Cabeçalho Processual, Pessoas, Endereços e Organizacional.

Webinários

O CNJ organizou uma série de webinários com instruções técnicas sobre a PDPJ-Br.

note

Acesse aqui a lista de vídeos disponíveis.

Dúvidas e Apoio à Integração com a PDPJ-Br

Suporte

Para suporte e apoio na utilização e integração com a PDPJ-Br, entre em contato com integracaopdpj@cnj.jus.br.

Contato

Para assuntos gerenciais e estratégicos em relação à PDPJ-Br, o contato é o gerenciaexecutivapdpj@cnj.jus.br.