Arquitetura de múltiplas camadas
É uma arquitetura cliente-servidor em que as funções de apresentação, processamento de aplicativos e gerenciamento de dados estão logicamente separadas. Por exemplo, um aplicativo que usa middleware para solicitações de dados de serviço entre um usuário e um banco de dados emprega arquitetura multi-tier. O uso mais comum de arquitetura multi-tier é a arquitetura de três camadas Arquitetura de três camadas é uma arquitetura cliente-servidor em que a interface de usuário, lógica do processo funcional ("regras de negócio"), o armazenamento de dados de computador e acesso a dados são desenvolvidos e mantidos como independentes módulos, na maioria das vezes em separadas plataformas. Foi desenvolvido por John J. Donovan em Open Environment Corporation (OEC), empresa chave que ele fundou em Cambridge, Massachusetts. O modelo de três camadas é uma arquitetura padrão de software. Para além das vantagens habituais de modular o software com interfaces bem definidas, a arquitetura de três camadas se destina a permitir que qualquer um dos três níveis podem ser atualizados ou substituídos de forma independente, em resposta as mudanças nos requisitos ou tecnologia. Por exemplo, uma mudança de sistema operacional na camada de apresentação afetaria apenas o código de interface do usuário. Normalmente, a interface do usuário é executado em um desktop PC ou estação de trabalho e usa um padrão de interface gráfica do usuário, lógica do processo funcional, que pode consistir em um ou mais módulos separados que funcionam em uma estação de trabalho ou servidor de aplicativos e um SGBD em um servidor de banco de dados ou de mainframe que contém a lógica de armazenamento dos dados de computador. Os três níveis:
Camada de apresentação
Este é o nível mais alto da aplicação. A camada de apresentação exibe informações relacionadas com serviços como navegação mercadoria, compra e carrinho de compras. Ele se comunica com outros níveis, pelo qual, põe para fora os resultados para a camada de browser/cliente e todas as outras camadas da rede. (Em termos simples, é uma camada que os usuários podem acessar diretamente como uma página web, ou um GUI sistemas operacionais) Camada de aplicativo (lógica de negócio , camada de lógica, camada de acesso a dados, ou camada intermediária)
Camada lógica
É puxado para fora da camada de apresentação, como sua própria camada, controla a funcionalidade de uma aplicação através da realização de processamento detalhado.
Camada de dados
Essa camada é composta por servidores de banco de dados. Aqui a informação é armazenada e recuperada. Essa camada mantém os dados neutros e independentes de servidores de aplicativos ou lógica de negócios. Dando dados a sua própria camada também melhora a escalabilidade e desempenho
Servidor OpenERP
OpenERP fornece um servidor de aplicativos no qual aplicações de negócio específicas podem ser construídas. Também é um framework de desenvolvimento completo, oferecendo uma gama de recursos para escrever essas aplicações. Entre essas características, o OpenERP ORM fornece funcionalidades e uma interface em cima do servidor PostgreSQL. O servidor OpenERP também possui uma camada específica projetado para se comunicar com o cliente baseado no navegador web. Esta camada se conecta usuários que utilizam navegadores padrão para o servidor.
Do ponto de vista do desenvolvedor, o servidor atua tanto como uma biblioteca que traz os benefícios acima ao esconder os detalhes de baixo nível, e como uma maneira simples de instalar, configurar e executar os aplicativos escritos. O servidor também contém outros serviços, tais como os modelos de dados e extensíveis vista, motor de workflow ou relatórios motor. No entanto, esses são serviços OpenERP não especificamente relacionados com a segurança, e portanto não são discutidos em detalhes neste documento.
Servidor - ORM
O Objeto camada Relational Mapping ORM é uma das principais características do OpenERP Server. Ele fornece funcionalidades adicionais e essenciais no topo do servidor PostgreSQL. Modelos de dados são descritos em Python e OpenERP cria as tabelas do banco de dados subjacente usando este ORM. Todos os benefícios de SGBD, tais como restrições de unicidade, integridade relacional ou consulta eficiente são usados e concluído pela flexibilidade Python. Por exemplo, constrangimentos arbitrárias escritos em Python pode ser adicionado a qualquer modelo. Diferentes mecanismos de extensibilidade modulares também são oferecidas pelo OpenERP.
É importante entender a responsabilidade ORM antes de tentar contornar isso e para acessar diretamente o banco de dados subjacente através de consultas SQL crus. Ao usar o ORM, OpenERP pode ter certeza que os dados permanecem livre de qualquer corrupção. Por exemplo, um módulo pode reagir a criação de dados de uma tabela especial. Esse comportamento pode ocorrer apenas se as consultas passar pelo ORM.
Os serviços concedidos pelo ORM são entre outras:
validação de consistência por verificações de validade poderosos, fornecendo uma interface em objetos (métodos, referências, ...) que permite desenhar e implementar módulos eficientes, segurança em nível de linha por usuário e grupo, mais detalhes sobre os usuários e grupos de usuários são dadas na seção Users e User Roles, ações complexas sobre um grupo de recursos, serviço e herança permitindo modelagem multa de novos recursos
Servidor - Web
A camada web oferece uma interface para se comunicar com navegadores padrão. Esta camada web é uma aplicação WSGI-compatível com base em werkzeug. Ele lida com consultas regulares HTTP para arquivo estático servidor ou conteúdo dinâmico e consultas JSON-RPC para a RPC feita a partir do browser.
Módulos
Por si só, o servidor OpenERP é um núcleo. Para qualquer empresa, o valor do OpenERP está em seus diferentes módulos. O papel dos módulos é a implementação de qualquer requisito de negócio. O servidor é o único componente necessário adicionar módulos. Qualquer lançamento oficial OpenERP inclui uma série de módulos, e centenas de módulos estão disponíveis graças à comunidade. Exemplos de tais módulos são Conta, CRM, RH, Marketing, MRP, venda, etc.
Clientes
Como a lógica do aplicativo está contido principalmente do lado do servidor, o cliente é conceitualmente simples. Ele emite uma solicitação ao servidor, obtém dados de volta e exibir o resultado (por exemplo, uma lista de clientes) em diferentes formas (como formulários, listas, calendários, ...). Após as ações do usuário, envia consultas para modificar os dados para o servidor.
O cliente padrão do OpenERP é uma aplicação JavaScript em execução no navegador que se comunica com o servidor usando JSON-RPC.
Comunicação
OpenERP é um servidor web HTTP e também pode ser implementado como uma aplicação WSGI-compliant.
Os clientes podem se comunicar com OpenERP usando sessionless XML-RPC, a maneira recomendada para interoperar com OpenERP. Clientes baseados na Web se comunica usando a sessão ciente JSON-RPC.
Tudo no OpenERP, e objetos métodos em particular, estão expostos através da rede e uma camada de segurança. O acesso ao modelo de dados é na verdade um "serviço" e é possível para expor novos serviços. Por exemplo, um serviço de WebDAV e um serviço de FTP estão disponíveis.
Os serviços podem fazer uso do WSGI pilha. WSGI é uma solução padrão no ecossistema Python para escrever servidores HTTP, aplicativos e middleware que pode ser usado de uma forma mix-and-match. Usando WSGI, é possível executar OpenERP em qualquer servidor compatível com WSGI. Também é possível usar o OpenERP para hospedar um aplicativo WSGI.
Um exemplo flagrante desta possibilidade é a camada Web OpenERP que é a parte contrária do lado do servidor para os clientes na web. Ele fornece os dados solicitados para o navegador e gerencia sessões web. É uma aplicação WSGI-compliant. Como tal, ele pode ser executado como um servidor HTTP autônomo ou incorporado dentro OpenERP.
Os namespaces HTTP / openerp / / objeto / / common / são reservados para a camada XML-RPC, cada módulo é restringir namespace HTTP / <name_of_the_module> /