• Nenhum resultado encontrado

4.5 Implementação

4.5.6 Categorias das Aplicações

No contexto do desenvolvimento da arquitetura WSARCH e de qualquer outra arquitetura ori- entada a serviços, as aplicações podem ser de naturezas distintas, cada uma delas com suas partic- ularidades, as quais podem degradar o desempenho de um sistema caso não sejam consideradas na política de roteamento/escalonamento de mensagens. As requisições enviadas por diferentes cate- gorias de aplicações e a resposta advinda dos provedores dos serviços possuem forte relação com a característica das aplicações. Por exemplo, o resultado de uma simples requisição SOAP para uma aplicação que acessa uma base de dados, pode retornar uma mensagem SOAP de resposta muito grande, dependendo do que foi solicitado na requisição, e degradar o tempo de resposta do ponto de vista do cliente, uma vez que a interação cliente e provedor envolve não somente a execução de um dado, mas também o encapsulamento/desencapsulamento das mensagens SOAP. As aplicações

70 4.5. IMPLEMENTAÇÃO podem utilizar com mais frequência determinados recursos e se comportar de modos diferentes quando estão em processo de execução. Devido a tais diferenças, as tarefas são agrupadas em classes, e isso deve ser levado em consideração pelos algoritimos de roteamento/escalonamento de mensagens presente em um Broker de serviços. O objetivo é sempre melhorar o desempenho do sistema, uma vez que alguns recursos podem sofrer sobrecarga enquanto outros permanecem ociosos. A Figura 4.7 apresenta uma visão geral para a classificação de aplicações.

Interativas

3 Batchs

CPU-Bound Memory

Intensive I/O-Bound Network-Bound

Figura 4.7: Classificação das Aplicações (Branco, 2004)

De acordo com (Saphir et al., 1995) as aplicações podem ser classificadas em função do método de execução em:

• Interativas: Possui como característica principal a interação da aplicação com o usuário. A interatividade (mais ou menos interativa) vai depender da frequência com que essa interação ocorre. Nessa categoria de aplicações um dos fatores mais importantes é o tempo de resposta, o qual deve ser priorizado no momento do roteamento/escalonamento das mensagens SOAP; • Batchs: Aplicações que são submetidas em lote, em que não há interação com o usuário. O fator primordial é o tempo de execução para essa classe. As políticas de roteamento de mensagens direcionadas a essa classe podem ser mais flexíveis e considerar mais fatores para realizar o roteamento, uma vez que não possuem usuários on-line.

Ao considerar a intensidade de utilização dos recursos, as aplicações podem ser classificadas em (Voorsluys, 2006):

• CPU-bound: As aplicações desta categoria realizam processamento a maior parte do tempo, mantendo o processador ocupado desde o momento em que elas são escalonadas para exe- cução. Exemplos típicos são: aplicações baseadas em métodos matemáticos. Para este tipo de aplicação costuma se utilizar o termo computation-intensive.

CAPÍTULO 4. A ARQUITETURA WSARCH 71 • Memory-Intensive: Esta categoria de aplicações caracteriza-se pela necessidade de grande quantidade de memória principal. As tarefas que passam um tempo considerável escrevendo e lendo na memória, ou que armazena grande quantidade de dados, podem ser categorizadas como memory-intensive. Frequentemente, as aplicações memory-intensive também são con- sideradas CPU-bound, já que juntamente com o armazenamento de grandes quantidades de dados, deve haver o processamento dos mesmos. Estas aplicações também são conheci- das como memory-bound, porém esta denominação é menos utilizada. Como exemplos destacam-se: programas de data mining, modelos climáticos, reconhecimento de voz buscas em grandes bases de dados, processamento de vídeo, entre outros.

• I/O-bound: Aplicações que necessitam armazenar, ou ler, muitas informações de disposi- tivos de armazenamento secundário (por exemplo, rede ou disco), passando a maior parte do tempo realizando operações de I/O. Elas também podem ser denominadas I/O-intensive. • Network-bound: Aplicações que realizam a comunicação em rede de maneira intensa. Po-

dem também ser denominadas communication-intensive ou ainda communication-bound. Destaque para aplicações que executam na Internet e em plataformas paralelas distribuídas. O que é interessante destacar é que as aplicações podem pertencer a uma ou mais classes, uma vez que elas não são mutuamente exclusivas. Portanto, é possível que uma aplicação seja

CPU-bound e memory-intensive ao mesmo tempo. Outra possibilidade é que as tarefas alterem

sua classificação durante a execução. Deste modo, uma aplicação pode ser classificada como

network-bound no momento de sua submissão e mudar seu comportamento durante a execução,

sendo classificada como I/O-bound, por exemplo (Voorsluys, 2006). Implementação das Aplicações

Para o propósito do teste inicial da WSARCH foi considerada uma aplicação inteiramente CPU-Bound, incluindo operações matemáticas simples dentro de alguns laços aninhados na or-

dem de O(n4). Aplicações mais robustas considerando várias categorias foram implementadas

e testadas em um trabalho de mestrado associado a este projeto de doutorado. Uma das apli- cações implementadas no projeto de mestrado citado anteriormente refere-se à transferência de dados anexados em mensagens SOAP na WSARCH, utilizando as técnicas MTOM e SwA já previ- amente explicadas. Para permitir que anexo de dados fosse utilizado na WSARCH, foi necessária implantar uma nova funcionalidade na arquitetura que contemplasse a correta transferência das informações entre provedor, Broker e aplicação cliente. Com base nesta aplicação de transfer- ência de dados anexados, uma aplicação mais completa foi implementada, considerando também

CPU-Bound e IO-Bound, nos quais representam, respectivamente, a funcionalidade da aplicação

CPU-Bounddefinida anteriormente e escrita de arquivos de texto no disco do provedor. Tais oper-

72 4.5. IMPLEMENTAÇÃO mente, seguida da operação de IO-Bound. Por fim um arquivo binário é transferido do provedor selecionado para o cliente efetuando uma operação de download.