...

...

http://{host}:{port}/{context}/rest/autodoc/{operationversion}/{versionoperation}

• {host} e {port} definem onde a aplicacao esta rodando
• {context} é o Servlet Context da aplicacao. Por exemplo, no confluence normalmente é /confluence
• {operation} é a operação a ser executada
• {version} é a versao da API. Para utilizar a ultima versao da API eh possivel utilizar como valor /latest

...

Servicos Externos

Os servicos externos que acessam o EMapping poderao fazer isso atraves do padrao REST, podendo realizar leitura e escrita de informacoes desde que autenticados e conforme o nivel de permissao atribuido.

Os servidos REST disponiveis no EMapping sao implementados unica e exclusivamenete pelos EJB de fachada.

O formato padrao de dados REST no EMapping eh, primeiro XML, e opcionalmente JSON.

Detalhes e exemplos sobre essa parte serao disponibilizados quando necessarioGoogle Translate

A lingua padrao para descricoes de Validators, Conditions e Post Functions eh Ingles. Sabendo disso a API pode enviar requisicoes para servicos online de traducao (como Google Translate) para realizar as traducoes da forma que seja possivel disponibilizar a documentacao em diferentes linguas. 

Se esta feature for implementada utilizando este tipo de abordagem o plugin desenvolvido necessariamente deve ter acesso a web.

Funcionamento

Os quatro vertices (Logico, Fisico, Processamento e Implantacao) da arquietetura sao dados pelo Diagrama 4+1 abaixo:

Logico

Para o usuario final, o plugin realiza a tarefa de documentar as mudanças feitas nos workflows cadastrados no JIRA de forma automatica. No momento da mudança o plugin ira perceber esta mudança e alterar a documentacao disponivel no Confluence. Esta documentacao eh uma pagina que ate o presente momento (em proximas versoes poderemos ter novas features) tem um layout estatico por padrao. Classificamos por estatico porque o usuario nao ira alterar o layout do documento em si.

Segue abaixo um diagrama de sequencia para ilustrar esta funcionalidade.

Fisico

Processamento

O Diagrama de Atividades mostra o ciclo completo de processamento de negocio de um acao de usuario no sistema:

...

Onde:

• Cores:
  • Azul: Em suma eh o navegador web, que executa no computador cliente. Captura as acoes do usuario e converte em requisicoes http/s. Tambem captura os retornos do sistema e exibe-os em uma interface html rica (web 2.0).
  • Verde: As actions sao componentes da aplicacao escritos em codigo java. Recebem as requisicoes do browser e realizam validacoes simples (que nao exigem acesso ao sistema). Quando uma acao necessita o processamento de uma regra de negocio, ela aciona um EJB de Fachada.
  • Laranja: Sao EJBs. Eles dividem-sem em "Fachada" (pelo sufixo Facade) e Servicos (pelo sufixo Service). EJBs de fachada encapsulam todas as operacoes de um modulo do sistema. Em outras palavras, um modulo nao deve ser acessado de outra forma que nao pelo seu EJB de Fachada. EJBs de fachada nao contem regras de negocio, eles apenas delegam a execucao das opeeracoes para os EJBs de servico. EJBs de fachada sao sem estado por natureza (@Stateles), e elegiveis para oferecer servicos REST. Todos metodos nos EJBs de Fachada sao transacionais por natureza. Ja os EJBs de servico sao os responsaveis pela implementacao das regras de negocio do sistema. Eles somente podem ser acessados por EJBs de fachada (qualquer EJB de fachada) ou entao por outros EJBs de servico dentro do mesmo modulo. EJBs de servico podem acessar a camada de persistencia ou invocar operacoes em classes utilitarias ou sistemas externos. EJBs de servico nao devem realizar acesso direto ao banco de dados, exceto metodos marcados explicitamente pelos arquitetos da aplicacao. EJBs de servico sao por natureza sem estado (@Stateles). Todos os componentes Laranja executam dentro do servidor de aplicacao, e contam com recursos implicitos para log, persistencia, transacionamento, seguranca e escalabilidade.
  • Amarelo: Classes utilitarias da aplicacao, criadas para o proprio sistema ou utilizadas de frameworks e bibliotecas de terceiros. Deve-se evitar ao maximo a utilizacao de metodos estaticos em classes utiliarias. Quando isso for desejado, entao deve-ser utilizar o padrao Singleton.
  • Lilas: Sistema externo eh todo e qualquer componente, ferramenta ou aplicativo avesso ao Sistema EMapping que deve ser acessado para leitura ou escrita de informacoes. Somente EJBs de Servico ou entao Classes Utilitarias (Util) podem acessar um sistema externo, e nunca uma Action ou Facade.
  • Marrom: Persistencia, representada pelo JPA (JSR-317) pela implmentacao do Hibernate, oferece metodos para escrita e leitura de dados no banco de dados. Todas as operacoes realizadas sobre a camada de persistencia operam sobre o modelo de objetos da aplicacao, e nunca deve fazer acesso direto as tabelas do banco de dados. Em outras palavras, comandos SQL nao deve ser executados sobre a camada de persistencia, mas sim comandos da EJB-QL. A camada de persistencia eh livre para realizar cache de objetos conforme indicacoes da equipe de arquitetura
  • Vermelho: Eh o banco de dados do sistema, representado por um SGBD relacional Oraclel ou Postres, e contem os objetos persistentes da aplicao, salvos em tabelas atraves do framework JPA da persistencia. Nenhum acesso direto da apliacao (codigo de programador) deve ocorrer nessa camada, exceto explicitamente demarcado pela equipe de arquitetura.

...