• Nenhum resultado encontrado

2.7 Conclus˜ao

3.1.12 Servi¸co de Localiza¸c˜ ao de Nomes

Plataformas de middleware orientadas por objetos em geral baseiam-se em uma arquitetura orientada por servi¸cos [BHTV03]. Esse tipo de modelo envolve trˆes tipos diferentes de entidades: fornecedores de servi¸cos, clientes e agˆencias de localiza¸c˜ao. Fornecedores de servi¸cos s˜ao entida- des que detˆem alguma funcionalidade que pode ser utilizada pelas partes clientes que comp˜oem o sistema. Com o intuito de permitir que clientes tenham como encontrar os servi¸cos dispon´ıveis, fornecedores precisam publicar uma descri¸c˜ao das funcionalidades que eles disponibilizam, o que ´e feito via agˆencias de localiza¸c˜ao. Tais agˆencias fornecem, basicamente, duas opera¸c˜oes, que no contexto desta se¸c˜ao, s˜ao chamadas publish e find. Uma representa¸c˜ao tradicional deste tipo de arquitetura pode ser vista na Figura 3.20.

O modelo apresentado na Figura 3.20 pode ser implementado de diferentes formas. Por exemplo, em Java RMI o usu´ario tem acesso `a agˆencia de localiza¸c˜ao por meio de uma classe denominada Naming [Mic03]. Esta classe permite que objetos remotos sejam registrados em um diret´orio onde s˜ao identificados por nomes ´unicos. A cada um destes nomes est´a associado um stub. Em Java RMI as opera¸c˜oes publish e find s˜ao chamadas, respectivamente, de lookup e bind. O m´etodo lookup recebe como parˆametro uma URL, que cont´em o endere¸co de um host e o nome do objeto procurado. Caso tal objeto esteja presente no host especificado, esta opera¸c˜ao retorna para a aplica¸c˜ao cliente o stub associado `aquele objeto. O m´etodo bind, por sua vez, recebe dois parˆametros: um stub e o nome ao qual tal componente deve ser associado junto `a agˆencia de localiza¸c˜ao.

´

E poss´ıvel implementar agˆencias de localiza¸c˜ao que forne¸cam para o usu´ario interfaces dife- rentes daquela oferecida por Java RMI. Por exemplo, em vez de objetos remotos serem represen- tados por nomes ´unicos, eles podem ser identificados diretamente pelos servi¸cos que oferecem, isto ´e, por suas interfaces. Neste caso, o m´etodo publish deve associar, junto `a agˆencia de localiza¸c˜ao, cada objeto remoto ao nome da interface implementada por ele. O m´etodo find deve receber como parˆametros o endere¸co de um host e a interface que descreve os servi¸cos procurados. Para tratar tentativas de registro de objetos que implementam interfaces iguais no mesmo diret´orio de nomes, existem diferentes alternativas. Pode-se por exemplo, permitir que tais eventos ocorram e, diante de buscas, qualquer implementa¸c˜ao adequada ´e retornada. Por

package arcademis.concrete; import arcademis.*;

public interface NameBasedNaming { public Remote find(String name) throws NotBoundException, ArcademisException; } package arcademis.concrete.server; import arcademis.*; import arcademis.server.*;

public interface NameBasedNaming { public void publish

(String name, Stub obj) throws AlreadyBoundException, ArcademisException;

}

Figura 3.21: Defini¸c˜ao de agˆencia de localiza¸c˜ao baseada em nomes.

package arcademis.concrete; import arcademis.*; public interface InterfaceBasedNaming {

public Remote find(Class service) throws NotBoundException, ArcademisException; } package arcademis.concrete.server; import arcademis.*; import arcademis.server.*; public interface InterfaceBasedNaming { public void publish(RemoteObject obj) throws AlreadyBoundException, ArcademisException; }

Figura 3.22: Defini¸c˜ao de agˆencia de localiza¸c˜ao baseada em tipo.

outro lado, pode-se restringir o diret´orio de nomes de forma que somente uma implementa¸c˜ao seja registrada por interface.

Devido ao fato de ser poss´ıvel definir o servi¸co de localiza¸c˜ao de nomes de diferentes formas, Arcademis n˜ao predefine nenhuma interface para a agˆencia de localiza¸c˜ao. Assim, tais entidades devem ser implementadas de forma independente pelo desenvolvedor de middleware. Por outro lado, em sua cole¸c˜ao de componentes concretos, Arcademis define duas interfaces diferentes para a agˆencia de localiza¸c˜ao, as quais podem ser vistas nas Figura 3.21 e 3.22. A primeira figura mostra um servi¸co de localiza¸c˜ao semelhante ao que ´e utilizado por Java RMI, sendo os objetos remotos identificados por nomes ´unicos. A Figura 3.22 apresenta um servi¸co de localiza¸c˜ao onde objetos s˜ao pesquisados com base nas interfaces que eles implementam. Em ambos os casos, as opera¸c˜oes publish e find foram declaradas em interfaces diferentes porque dessa forma uma aplica¸c˜ao n˜ao precisa implementar um dos m´etodos se n˜ao for precisar dele. Por exemplo, uma aplica¸c˜ao cliente necessita somente da interface que declara o m´etodo find e, assim, n˜ao precisa implementar a opera¸c˜ao publish. Da mesma forma, um servidor de m´etodos remotos pode n˜ao precisar de utilizar o m´etodo find, e, neste caso, dever´a prover somente uma implementa¸c˜ao para a opera¸c˜ao publish.

Tamb´em fazem parte da semˆantica de um servi¸co de nomes os diferentes tipos de mensagens de erro que podem ser disparadas durante a sua utiliza¸c˜ao. Erros podem ocorrer, por exem- plo, quando determinada consulta n˜ao encontra qualquer resultado v´alido, ou quando ocorrem conflitos devido `a colis˜oes de nomes durante a opera¸c˜ao de registro. Arcademis define trˆes ti- pos de erros, os quais s˜ao representados pelas classes de exce¸c˜ao: AlreadyBoundException, NotBoundException e InvalidAccessException. A primeira exce¸c˜ao caracteriza a tentativa

de utiliza¸c˜ao de um nome que j´a foi usado em um registro anterior. O segundo tipo de erro caracteriza a n˜ao ocorrˆencia de um nome solicitado em uma opera¸c˜ao de busca no diret´orio de nomes. Finalmente, a terceira exce¸c˜ao qualifica o evento em que um cliente tenta localizar um nome, este se encontra registrado, por´em o cliente n˜ao possui permiss˜ao para invocar m´etodos sobre o objeto remoto ao qual o nome se refere.

3.1.13 Tipos de Exce¸c˜oes ´

E poss´ıvel catalogar diversos tipos diferentes de situa¸c˜oes excepcionais que podem ocorrer em uma plataforma de middleware. Situa¸c˜oes deste tipo ocorrem, por exemplo, quando um conector tenta efetuar uma conex˜ao em um ponto no qual n˜ao existe nenhum receptor ativo, ou quando acontece uma tentativa de leitura de uma seq¨uˆencia de bytes que n˜ao descreve corretamente um objeto com base no protocolo de serializa¸c˜ao adotado. A seguir podem ser vistos alguns tipos de exce¸c˜oes previstas por Arcademis. Al´em destas exce¸c˜oes, Arcademis define outros tipos de erros, relacionados ao servi¸co de nomes, conforme apresentado na Se¸c˜ao 3.1.12.

ActivationException Essa exce¸c˜ao deve ser levantada quando o objeto remoto n˜ao pode ser corretamente ativado. Por exemplo, caso um objeto remoto tente criar um receptor de conex˜oes em uma porta que j´a ´e utilizada por outra aplica¸c˜ao, durante a sua ativa¸c˜ao, ent˜ao uma exce¸c˜ao desse tipo deve ser disparada.

MalformedAddressException Esse tipo de exce¸c˜ao deve ser disparada quando o middleware se depara com a especifica¸c˜ao de um endere¸co que n˜ao obedece `a sintaxe adotada. Por exemplo, caso endere¸cos sejam definidos via URIs (Uniform Resource Identifiers), ent˜ao um endere¸co como turmalina.dcc.ufmg.br!8080/obj deveria levantar uma exce¸c˜ao deste tipo, pois o sinal ! n˜ao pertence ao conjunto de s´ımbolos usados na declara¸c˜ao de URIs. MarshalException Esse tipo de exce¸c˜ao ocorre quando n˜ao ´e poss´ıvel serializar um objeto que

implementa Marshalable ou quando n˜ao ´e poss´ıvel reaver um objeto desse tipo a partir de uma cadeia de bytes. Por exemplo, tal exce¸c˜ao deveria ser disparada quando acontecer uma tentativa de ler um inteiro de uma seq¨uˆencia de menos que quatro bytes, uma vez que, na linguagem Java, inteiros possuem 32 bits.

NetworkException Essa exce¸c˜ao ocorre devido `a falhas na camada de transporte, em geral detectadas na implementa¸c˜ao da interface Channel. Por exemplo, ela deveria ser disparada quando acontecer uma tentativa de conex˜ao a um ponto no qual n˜ao exista nenhum receptor ativo.

ProtocolException Esse tipo de erro caracteriza a ocorrˆencia de mensagens inesperadas de acordo com o protocolo de comunica¸c˜ao adotado. Uma falha desse tipo acontece quando uma mensagem com o cabe¸calho inv´alido ´e recebida.