O documento descreve a palestra de Flávio Gomes da Silva Lisboa sobre o sistema ExpressoV3 do SERPRO. O ExpressoV3 é um software de comunicação e colaboração desenvolvido com código aberto que fornece ferramentas como email e mensagens instantâneas para o setor público. O documento explica a arquitetura modular e baseada em plugins do ExpressoV3 que permite extensões personalizadas sem alterar o código original.
Sistema de Plugins do ExpressoV3. Não espere, faça o seu!
1. Líder em soluções de TI para governo
Palestrante: Flávio Gomes da Silva Lisboa
Coordenação Estratégica de Ações Governamentais (CEAGO)
Sistema de
Plugins do
ExpressoV3
Não espere, faça o seu!
2. Para encaminhar perguntas durante a palestra, enviem
para:
e-mail cisl@serpro.gov.br
diáspora https://diasporabr.com.br/u/cislgovbr
twitter @CISLGovBR
facebook https://www.facebook.com/cislgovbr.
Reveja as palestras técnicas editadas no nosso canal
do youtube https://www.youtube.com/user/CISLGov.
Perguntas
3. Empresa pública vinculada ao
Ministério da Fazenda.
O negócio do Serpro é a prestação de
serviços em Tecnologia da
Informação para o setor público. A
empresa desenvolve soluções que,
além de contribuírem para a
modernização e eficácia da
administração pública, buscam
estreitar a relação entre cidadãos e
Governo.
O SERPRO
4. O SERPRO
Presença Nacional
11 Regionais
Brasília, Belém, Fortaleza, Recife,
Salvador, Belo Horizonte, Rio de
Janeiro, São Paulo, Curitiba,
Florianópolis e Porto Alegre
17 Escritórios
5. Números do SERPRO
● 3 Data Centers: SPO, BSB e RJO
● 2 Serviços - Mainframe (29.095 MIPS)
● Mais de 2.500 servidores de
plataforma baixa (Risc, Cisc e Epic)
entre máquinas físicas e virtuais
● 6 Fitotecas automatizadas com
capacidade de 2 petabytes de
armazenamento
● 1.353 petabytes de armazenamento
(discos) sendo 945TB em SPO, 51TB
no RJO e 357TB em BSB
● 12 bilhões de transações on-line
processadas por ano
● Múltiplos Bancos de Dados (Adabas,
DB2, Oracle, SQL Server, MySQL,
PostgreSQL, Lotus Notes, BRSearch,
MS Access Sybase, INFORMIX,
ZopePlone)
● 64.407 Microcomputadores
Heinz Doofenshmirtz, by Disney
6. Linhas de negócio do SERPRO
Desenvolvimento de Sistemas e Aplicações
Rede de Comunicação
Administração de correio eletrônico
9. O ExpressoV3 é um software de comunicação e
colaboração inteiramente desenvolvido em software
livre.
Seu principal objetivo é fornecer uma ferramenta
economicamente viável que permita que corporações,
dentro e fora do Brasil tenham domínio e
autossuficiência em sua manutenção.
ExpressoV3
10. O ExpressoV3 é baseado na versão Kristina do Tine
2.0, um groupware e CRM livre criado na Alemanha.
ExpressoV3
11. O ExpressoV3 é um software mantido por
uma comunidade com grande experiência
na construção e manutenção de
ferramentas de groupware.
Comunidade
http://comunidadeexpresso.serpro.gov.br
12. As comunidades ExpressoV3 e Tine 2.0 colaboram entre
si, compartilhando um núcleo de código comum por meio
de submissões mútuas de mudanças.
Colaboração e Integração
ExpressoV3 Tine 2.0
Admin
Addressbook
Calendar
Tasks
Tinebase
Setup
Expressomail
Messenger
Webconference
Courses
Crm
Felamimail
Filemanager
HumanResources
Inventory
Phone
Projects
RequestTracker
Sales
Timetracker
Voipmanager
13. Em um projeto de software mantido em comunidade,
sempre existe o conflito entre os interesses gerais e os
interesses particulares.
Os interesses gerais são as funcionalidades do
software que todos irão utilizar e para as quais a
discussão limita-se a como serão implementadas.
Os interesses particulares são funcionalidades usadas
por somente um grupo ou um membro da comunidade
que são importantes para eles, mas não são relevantes
para os demais.
Conflito de interesses
14. Um software que deve atender uma diversidade de
usuários precisa se focar nos interesses gerais dessas
pessoas.
Software em comunidade
Software em comunidade = Interesses gerais
15. “O destino de um é compartilhado por todos”
Mestre dos Magos
Software em comunidade
Dungeons & Dragons, 24th episode. Copyright CBS.
16. A unidade de um projeto de software em comunidade
depende da manutenção dos interesses de seus
membros.
Unidade do software
Interesses
particulares
Interesses
particulares
Interesses
particulares
Interesses
particulares
Interesses
gerais
17. Se os interesses particulares não forem tratados, eles
darão origem a softwares derivado, os forks.
Sectarismo
Fork
Fork
Fork
Fork
Software
original
18. Para permitir que os interesses particulares sejam
atendidos sem deixar que o software exista como uma
implementação dos interesses gerais, é necessário que
cada membro ou grupo seja capaz de adicionar o que
deseja ou alterar o comportamento das funcionalidades
de acordo com sua necessidade específica.
O software em comunidade deve, portanto, ser
extensível e configurável.
Manutenção da unidade
21. Por herança do Tine 2.0, o ExpressoV3 nasceu
extensível por módulos.
Extensibilidade
Módulo Módulo
Módulo
Módulo
Tine 2.0
22. Tine 2.0 tem uma arquitetura modular, que permite
adicionar funcionalidades por meio de módulos que
implementam o padrão de projeto MVC estendido.
Modularidade
Tine 2.0
Admin Addressbook Calendar Courses
Addressbook
Phone
Felamimail Filemanager
Projects RequestTracker
Human
Resources
Inventory
Sales
Crm
Phone
Setup
Tasks Timetracker RequestTracker Voipmanager New Module
23. Todos os módulos seguem o mesmo padrão de
implementação, que inclui suporte a tradução e
configuração de preferências.
Padrão de módulos
24. Usando essa arquitetura, o ExpressoV3 disponibilizou os
módulos Expressomail, Messenger e Webconference.
Módulos do ExpressoV3
ExpressoV3
Admin Addressbook Calendar
Messenger Setup
Expressomail
Tasks Webconference
25. O que os módulos fazem
Módulos adicionam funcionalidades.
Módulos podem consumir serviços de outros módulos.
Os que os módulos não fazem
Módulos não alteram funcionalidades existentes em
outros módulos.
Limites dos módulos
29. O que plugins fazem
Plugins adicionam funcionalidades.
Plugins podem consumir serviços de qualquer módulo.
Plugins podem alterar funcionalidades existentes em
outros módulos.
Plugins são injeções de dependências.
Não estenda, plugue!
30. O ExpressoV3 suporta certificado digital
A implementação de certificado digital criada pelo Serpro
foi feita de acordo com as especificações da ICP-Brasil
(Infraestrutura de Chaves Públicas Brasileira).
Essa implementação é de interesse de organizações do
Brasil, mas não serve para outros países.
Estudo de caso: certificação digital
31. Foi implementada uma rotina de verificação de
certificado no módulo Tinebase.
Estudo de caso: certificação digital
Tinebase
Frontend_Json
public function verifyCertificate($_data)
32. Essa rotina é chamada por uma classe herdeira da
camada de frontend do Tinebase.
Estudo de caso: certificação digital
Tinebase
Frontend_Json
public function verifyCertificate($_data)
Módulo
Classe herdeira
33. A chamada ao método é feita pelo cliente, por requisição
JSON-RPC 2.0.
Estudo de caso: certificação digital
Cliente ExpressoV3
Tinebase.verifyCertificate
34. Essa rotina fazia uso de classes que também foram
adicionadas ao módulo Tinebase.
Estudo de caso: certificação digital
Tinebase
Auth_ModSsql_Certificate_Factory
Auth_ModSsl_Certificate_ICPBrasil
Auth_ModSsl_Certificate_X509
Auth_ModSsql_Exception_Openssl_NotLoaded
Auth_ModSsl_UsernameCallback_Abstract
Auth_ModSsl_UsernameCallback_Interface
Model_DigitalCertificateValidation Auth_ModSsl_UsernameCallback_Serpro
35. O problema é que o Tinebase é o módulo do qual todos
os outros dependem.
Tinebase: a dependência
ExpressoV3
Admin Addressbook Calendar
Messenger Setup
Expressomail
Tasks Webconference
Tinebase
36. Tinebase também é a extensão das dependências do
ExpressoV3.
Tinebase: a extensão
ExpressoV3
Tinebase
Syncroton
37. Tinebase deve ser genérico para todos os módulos, pois
ele contém os interesses gerais dos módulos.
Tinebase: o interesse geral
Módulo Módulo
Módulo
Módulo
Tinebase
38. Tinebase
Por isso devemos evitar alterar o Tinebase, a menos que
a mudança seja genérica.
Tinebase: o intocável
39. A verificação de certificado digital pelo padrão ICP-Brasil
é um interesse geral no Brasil. Por isso ela não pode
ficar dentro um módulo específico, mas no módulo que
provê as funcionalidades essenciais.
No entanto, considerando a comunidade internacional,
essa implementação é específica.
Tinebase: o conflito
40. A implementação de verificação de certificado digital
pelo padrão ICP-Brasil deve ser desacoplada do
módulo Tinebase.
Tinebase: a conclusão
Pepper Potts & Tony Stark. Copyright Marvel.
41. Mas como manter a resposta para a requisição?
Tinebase: o inevitável
Cliente ExpressoV3
Tinebase.verifyCertificate
42. Eu dependo de uma funcionalidade, mas não posso
acoplá-la ao meu software, pois nem todos irão fazer
uso dela, pois não é genérica.
Eu preciso fazer uma chamada a um método que não
pode estar estaticamente definido.
Ou seja, eu preciso fazer uma chamada a algo que deve
estar disponível somente quando eu precisar.
Problema arquitetural
47. Criando um plugin
Para criar um plugin você deve:
Criar uma classe em uma biblioteca que siga o padrão
Zend Framework 1, dentro da pasta library.
Registrar o plugin na camada que deve receber a
funcionalidade, acrescentando uma linha como uma das
seguintes:
Tinebase_Frontend_Abstract::attachPlugin('nomeDoMétodo', 'NomeDaClasse');
Tinebase_Controller_Abstract::attachPlugin('nomeDoMétodo', 'NomeDaClasse');
Tinebase_Backend_Abstract::attachPlugin('nomeDoMétodo', 'NomeDaClasse');
48. Plugin de camada
Um plugin é uma classe cujo método é invocado de forma
indireta por um objeto das camadas de frontend, controller
e backend.
Você pode criar e adicionar quantos plugins forem
necessários usando o método addPlugin() da classe
abstrata da camada.
Todas as suas herdeiras terão acesso aos métodos de
plugins.
49. Assim, a implementação de certificado digital foi movida
para uma biblioteca.
Dependências ficam na pasta library
Serpro
Auth_ModSsql_Certificate_Factory
Auth_ModSsl_Certificate_ICPBrasil
Auth_ModSsl_Certificate_X509
Auth_ModSsql_Exception_Openssl_NotLoaded
Auth_ModSsl_UsernameCallback_Abstract
Auth_ModSsl_UsernameCallback_Interface
Model_DigitalCertificateValidation Auth_ModSsl_UsernameCallback_Cpf
50. Plugins são classes que fazem
parte de bibliotecas, que são
dependências da aplicação.
Se você quer adicionar uma
funcionalidade específica a uma
camada, crie sua própria biblioteca
e dentro dela crie seus plugins.
Dependências ficam na pasta library
51. É possível injetar outras dependências em,
init_plugins.php além das que afetam as camadas.
É possível alterar a regra de validação de
endereçamento IP e a estratégia de armazenamento do
AccessLog.
Isso é tornar o ExpressoV3 configurável.
E não é só isso!
52. Nos próximos releases do ExpressoV3, serão
disponibilizados plugins para:
●Inicialização da aplicação
●Sistema de usuários e grupos
●Filtros de consultas
Mais plugins estão a caminho!
53. Se precisar de alguma customização, não espere que
sua necessidade se torne genérica.
ESCREVA O SEU PLUGIN E USE!
Escreva o seu!
54. Tem ideias para mais pontos de plugins?
Acesse o Fórum do ExpressoV3 e exponha suas
propostas no tópico Desenvolvimento, subtópico
Arquitetura/Frameworks.
http://comunidadeexpresso.serpro.gov.br