3.4 Arquitetura Interna
3.4.6 Tratamento de Exce¸c˜ oes
Em um ambiente distribu´ıdo, plataformas de middleware s˜ao respons´aveis por trans-mitir exce¸c˜oes ativadas em servidores para aplica¸c˜oes cliente. A seguir, descreve-se como essas exce¸c˜oes s˜ao tratadas nas plataformas Java IDL e Java RMI.
Tratamento de Exce¸c˜oes em Java IDL: Em Java IDL, as exce¸c˜oes ativadas por um m´etodo devem ser especificadas na defini¸c˜ao de interfaces IDL. A partir dessa defini¸c˜ao, a ferramenta idlj produz classes espec´ıficas para serializa¸c˜ao dessas exce¸c˜oes. Na Se¸c˜ao 3.4.1 podemos observar que o m´etodogetStock, da interface remota StockMarketOpera-tions, ativa uma exce¸c˜ao do tipoStockNotFoundException, produzida por idlj. Essas classes de exce¸c˜oes estendem uma classe espec´ıfica da plataforma Java IDL, chamada org.omg.CORBA.UserException. Como afirmado anteriormente, e conforme ilustrado pela classe StockNotFoundException, as exce¸c˜oes de neg´ocio estendem uma classe es-pec´ıfica de Java, assim n˜ao ´e poss´ıvel fazer com que a exce¸c˜ao de neg´ocio estenda a exce¸c˜ao remota, uma vez que Java n˜ao possui heran¸ca m´ultipla.
1: public class StockNotFoundException extends Exception { 2: public StockNotFoundException(String dsc) {
3: super(dsc);
4: } 5: }
A solu¸c˜ao proposta por DAJ para contornar as restri¸c˜oes descritas anteriormente, consiste em criar um aspecto que capture a ocorrˆencia de uma exce¸c˜ao, e que realize a transforma¸c˜ao da exce¸c˜ao ativada numa exce¸c˜ao suportada pelo ambiente na qual ser´a transmitida. Ou seja, se uma exce¸c˜ao de neg´ocio for ativada no servidor, ela dever´a ser transformada em uma exce¸c˜ao remota, a qual ´e serializ´avel, para que esta possa ser enviada at´e o lado da aplica¸c˜ao cliente. Ao chegar no lado do cliente, a exce¸c˜ao remota dever´a ser, novamente, transformada em uma exce¸c˜ao de neg´ocio, a qual ser´a repassada
`
a aplica¸c˜ao cliente.
Exemplo: Mostra-se a seguir o aspecto ExceptionHandler StockNotFoundException, o qual ´e respons´avel por transformar exce¸c˜oes remotas em exce¸c˜oes de neg´ocio e vice-versa, em Java IDL.
1: public privileged aspect ExceptionHandler_StockNotFoundException { 2: before(stockMarket.exceptions.StockNotFoundException e)
3: throws daj.javaidl.api.stockMarket.exceptions.StockNotFoundException:
4: handler(stockMarket.exceptions.StockNotFoundException)
5: && args(e)
Define-se o aspecto como privilegiado para permitir visibilidade integral da estrutura das classes associadas (linha 1). Nesse aspecto, existem dois advicesdo tipo before que capturam exce¸c˜oes ativadas no lado do servidor (linhas 2 a 12) e exce¸c˜oes ativadas no lado do cliente (linhas 14 a 23). Al´em disso, esses advices ativam exce¸c˜oes compat´ıveis com o contexto em que s˜ao capturadas, ou seja, no lado do servidor s˜ao ativadas exce¸c˜oes remotas (linha 3), j´a que elas ser˜ao enviadas para o cliente, e no lado do cliente s˜ao ativadas exce¸c˜oes de neg´ocio (linha 15), que ser˜ao enviadas para o invocador do m´etodo remoto. O processo de transforma¸c˜ao consiste, em ambos os casos, em capturar a exce¸c˜ao e transferir os valores de seus atributos para uma exce¸c˜ao equivalente. Assim, no lado do servidor (primeiro advice), o construtor handler captura o bloco catch da exce¸c˜ao ativada (linha 4). J´a o construtorargs captura a exce¸c˜ao lan¸cada (linha 5) e o joinpoint da linha 6 especifica os pontos de jun¸c˜ao onde essa intercepta¸c˜ao deve ocorrer, ou seja, em todos os m´etodos de classes de neg´ocio em que foram introduzidos m´etodos para redirecionamento de chamadas remotas para seus respectivos m´etodos de neg´ocio. Ap´os a captura da exce¸c˜ao, ela ser´a transformada em uma exce¸c˜ao de tipo compat´ıvel com o ambiente em que ser´a lan¸cada, nesse caso, uma exce¸c˜ao serializ´avel (linhas 7 a 10) e, por fim, ser´a ativada. No lado do cliente ser´a realizado um processo semelhante ao utilizado no lado do servidor.
Tratamento de Exce¸c˜oes em Java RMI: Em Java RMI, inexistem as complexidades descritas para Java IDL, pois Java RMI se aproveita do fato de utilizar o mesmo sistema de tipos da linguagem Java. Assim, em Java RMI, ao contr´ario do ocorre em Java IDL, n˜ao h´a a necessidade de realizar qualquer interven¸c˜ao em rela¸c˜ao `as exce¸c˜oes ativadas pelos m´etodos da interface de neg´ocio, uma vez que essas exce¸c˜oes j´a s˜ao serializ´aveis.
Apesar disso, Java RMI utiliza uma exce¸c˜ao verific´avel pr´opria para tratamento de erros de comunica¸c˜ao, adicionada na interface remota mostrada na Se¸c˜ao 3.4.1. Essa exce¸c˜ao, chamada java.rmi.RemoteException, deve ser tratada pela aplica¸c˜ao cliente.
Como o cliente n˜ao introduz o c´odigo de tratamento dessa exce¸c˜ao no n´ucleo da aplica¸c˜ao, a abordagem proposta por DAJ consiste em transformar essa exce¸c˜ao verific´avel em uma exce¸c˜ao n˜ao-verific´avel, isentando assim o tratamento expl´ıcito desse tipo de exce¸c˜ao por parte da aplica¸c˜ao cliente.
Exemplo: Mostra-se a seguir os aspectos respons´aveis por transformar a exce¸c˜ao Remote-Exception de verific´avel para n˜ao-verific´avel.
1: public aspect StockMarketProxy_Exception { 2: declare soft: java.rmi.RemoteException :
3: withincode(* daj.javarmi.api.stockMarket.StockMarketProxy.*(..));
4: } 5:
6: public aspect StockListenerAdapter_Exception { 7: declare soft: java.rmi.RemoteException :
8: withincode(* daj.javarmi.api.stockMarket.StockListenerAdapter.*(..));
9: }
O primeiro aspecto, chamadoStockMarketProxy Exception, captura as exce¸c˜oes ati-vadas na classeproxyutilizada pelo cliente. O construtordeclare soft´e respons´avel por suavizar a exce¸c˜ao definida na linha 2, quando a mesma for ativada nos pontos de jun¸c˜ao definidos pelo conjunto de jun¸c˜ao especificado na linha 3. Ou seja, todas as exce¸c˜oes do tipo java.rmi.RemoteException que forem ativadas no interior de qualquer m´etodo da classe StockMarketProxyser˜ao transformadas em exce¸c˜oes n˜ao-verific´aveis.
De forma similar, o segundo aspecto tamb´em realiza essa transforma¸c˜ao. No entanto ela ocorre no lado do servidor, no interior dos adaptadores que encapsulam os parˆametros transmitidos com semˆantica de referˆencia remota.