sexta-feira, 29 de agosto de 2008

ADF BC: Configurando Application Modules para Performance e Escalabilidade: Parte 1

Oi pessoal!

Hoje a dica é sobre Application Module Configuration. Como vocês sabem, toda a camada de fachada do ADF BC é baseada nos Application Modules. Eles são responsáveis por controlar os acessos aos Data Sources, manter o controle transacional, instanciar os View Objects (e por consequência, os Entity Objects e suas queries) e controlar o fluxo da aplicação como um todo. Portanto, a correta configuração dos parâmetros dos AMs é fundamental para o bom desempenho e estabilidade da aplicação ADF como um todo.
Podemos acessar as configurações dos application modules clicando com o botão direito sobre eles no JDeveloper e selecionando o item "Configurations". Podemos por exemplo criar mais de um configuration, um Local (para uso com o Connection JDBC local) e um Remoto (Para uso dentro do App Server usando um Data Source).
Vamos hoje tratar portanto de um dos principais aspectos do ajuste de configurações: Pooling.
Assim como os Data Sources no Servidor J2EE são responsáveis por manter um pool de conexões de banco para melhorar a performance do acesso a dados, o chamado Connection Pooling, os Application Modules no ADF Runtime são responsáveis por manter um pool de AMs para servir mais rapidamente as aplicações ADF, chamado de AM Pooling. E da mesma maneira que os pools de conexão, podemos "tunar" a performance diminuindo o tempo que o runtime mantém uma instância do Application Module no ar ou aumentando o número de AM instances em memória para aguentar uma maior carga de usuários.
Para fazê-lo, selecionamos a configuração desejada dentro das Configurations e clicamos em "Edit", navegando para a aba "Pooling and Scalability". Nesta aba, temos a seção "Application Pool", onde podemos definir:
1) Initial Pool Size: Qual o tamanho inicial do meu pool de instâncias AM. Se colocarmos um valor muito baixo, cada usuário que se conectar demandará a instanciação de um AM, e por consequência, uma solicitação de conexão ao Data Source. Porém, se for muito alto, podemos estar esbanjando memória do servidor.
2) Maximum Pool Size: Qual o maior tamanho possível do pool. Segue a mesma lógica do Initial Pool Size, mas tem o efeito reverso.
3) Minimum Available Size: Número mínimo de instâncias que devem estar DISPONÍVEIS para uso.

Como o processo de instanciação é bem intensivo em uso de recursos, devemos planejar estes parâmetros levando em consideração o número de usuários logados ao mesmo tempo na aplicação. Para uma aplicação que, por exemplo, tenha no mínimo 2 usuários conectados a qualquer momento, seria interessante colocar o parâmetro Initial Pool Size como 2. O estudo destes parâmetros pode fazer a diferença na experiência do usuário.

Abraços!

sexta-feira, 15 de agosto de 2008

Criando Templates com Oracle Bpel

A nossa dica de hoje, é referente ao Oracle Bpel.

É muito comum criarmos templates para criação de diversas aplicações, no Oracle Bpel não é diferente.
Como o desenvolvimento do Oracle Bpel pode ser um pouco complexo, principalmente na criação de (Logs, emails e validações), temos a opção de criação de diversos templates, veja como:

Abra o Jdeveloper e crie uma nova aplicação Bpel, adicionando os componentes que deverão servir como Template.



Após a definição dos padrões, salve a aplicação e clique com o botão direito no Objeto . Abrirá a opção de "Mark as Template".




Feito isso, o template foi criado com sucesso.

Para testar crie um novo projeto "Bpel" que irá aparecer o template criado acima, conforme imagem.




Selecione o template "OracleTechTips Templates" e o novo projeto estará com os componentes definidos acima.

(Obs.: É possível criar o número de templates necessários).

Abraços e até a próxima.