Estratégia baseada em web services REST e SOAP

O desenvolvimento das aplicações baseadas em web services REST e SOAP seguiu os preceitos estabelecidos pelas arquiteturas ROA e SOA, respectivamente.

Para a composição dos web services REST foi necessário dividir as tarefas, apresentadas no quadro 1 da sessão 3.2, em recursos. Valendo-se da ideia de que os recursos não são os dados em si, mas sim uma informação abstrata de uma entidade (aqui, um dispositivo de rede), agrupou-se essas tarefas em quatro recursos, sendo eles: configuração,

VLAN, tabela de roteamento estático e interface. A exposição do estado atual ou desejado

desses recursos foi definida através da utilização de representações no formato JSON, ocultando assim aspectos internos da sua implementação. Já as referências a essas representações são realizadas através de URIs que nomeiam esses recursos. O quadro 13

apresenta a transformação dessas tarefas de gerência de configuração em web services REST. As tarefas não listadas nesse quadro são encontradas no APÊNDICE C.

Quadro 13 – Tarefas de gerência de configuração transformadas em web services REST.

ID Recurso URI Método

HTTP

Tipos e nomes de parâmetros da URI

1 CONFIG /{address}/configuration/runnning/ GET Path {address}

2 VLAN /{address}/vlan/all GET Path {address}

4 VLAN /{address}/vlan/{vlanid} PUT

Path {address}

{vlanid}

Query name

status 7 VLAN /{address}/vlan/{vlanid} DELETE Path {address}

{vlanid} 8 TBRE /{address}/routes/static GET Path {address} 11 IFACE /{address}/ports/{port}/ GET Path {address} {port}

12 IFACE /{address}/ports/{port}/ PUT

Path {address} {port} Query interfaceAddress subnetMask MTU description Fonte: Elaborado pelo autor.

Nota: Legenda para a coluna denominada recurso: CONFIG: Configurações do dispositivo de rede; VLAN: Virtual Lans – Rede Local Virtual (VLANs); TBRE: Tabela de Roteamento Estático;

IFACE: Interface de rede.

Legenda para a coluna denominada tipos e nomes de parâmetros da URI:

Path: Parâmetros inseridos diretamente na URI;

Query: Parâmetros adicionais passados explicitamente na URI e inseridos após o sinal de interrogação (?).

O quadro 13, além de demonstrar a estrutura (forma) de aceso aos web services REST, apresenta as condições norteadoras elencadas na seção 2.4.2 para os princípios desse estilo arquitetural. A definição de como as representações são acessadas e as operações básicas realizadas sobre elas é dada pela interface uniforme e apresentada pela coluna denominada método HTTP do quadro 13. Os parâmetros do tipo Path – identificados pela anotação @PathParam nos trechos de códigos dos web services (WS) REST – são inseridos diretamente na URI; já os parâmetros do tipo Query são atributos adicionais – identificados pela anotação @QueryParam – adicionados na query string da URI (contendo os dados do recurso que não são convenientes de serem adicionados a estrutura do seu caminho hierárquico). A separação através desses parâmetros foi necessária para não alongar a URI aos olhos do usuário, possibilitar o seu encadeamento, deixá-la clara, bem definida e tornar a aplicação endereçável. Cabe salientar que os métodos HTTP PUT e DELETE das tarefas 4, 7 e 12, apresentados pela interface uniforme, são tratados de forma idempotente seguindo

também as orientações de REST. Os web services REST foram desenvolvidos de forma a não manter o estado da aplicação; com isso nenhuma informação do lado do servidor é armazenada, fazendo com que todos os dados necessários para que a solicitação seja atendida sejam enviados através da URI ou por meio de parâmetros de cabeçalho.

O trecho de código apresentado no quadro 14 demonstra o mapeamento da tarefa 1 em um WS REST. Para esse WS é utilizado o método GET do HTTP (anotação @GET) com o objetivo de obter as configurações (representação de um recurso no formato JSON através da anotação @Produces("application/json")) em execução no roteador por meio da classe

RouterFunctions e do método getRunningConfigurationRouter disponibilizada pela API CLI

na camada de acesso e disposta no diagrama de classes da figura 9. Os atributos user e

password passados como parâmetro nesses métodos foram anonimizados, através de strings

de mesmo nome, nos códigos que detém essas características.

Quadro 14 – WS REST que retorna as configurações de um dispositivo de rede.

/**

* Método responsável por obter as configurações de um dispositivo de rede * @param address

* @return String - Contendo uma representação no formato JSON com o spool * oriundo do roteador mediante a execução do comando

*/ @GET

@Path("/{address}/configuration/runnning/")

@Produces("application/json")

public String RunningConfiguration(@PathParam("address") String address) {

//Crio um novo objeto do tipo Router passando como parâmetro seu endereço Router router = new Router(address, "user", "password");

//Executo o método da camada de acesso reponsável por obter //a configuração geral do roteador

return RouterFuntions.getRunningConfigurationRouter(router);

}

Fonte: Elaborado pelo autor.

A configuração de uma interface (porta) de rede de um dispositivo é apresentada no quadro 15. Nesse trecho de código é observada a utilização da interface uniforme por meio do método HTTP PUT, que trata da criação/atualização completa de um recurso (porta) oferecida pelo método de aplicação denominado configureInterface e apresentado no quadro 6.

Quadro 15 – WS REST que configura uma interface de rede.

/**

* Método responsável por configurar uma interface (recurso) de rede no * dispositivo de rede * @param address * @param port * @param interfaceAddress * @param subnetMask * @param MTU * @param description

* @return String - Contendo uma representação no formato JSON com o spool * oriundo do roteador mediante a execução do comando

*/ @PUT

@Path("/{address}/ports/{port}/")

@Produces("application/json")

@PathParam("port") String port,

@QueryParam("interfaceAddress") String interfaceAddress,

@QueryParam("subnetMask") String subnetMask,

@QueryParam("MTU") String MTU, @QueryParam("description") String description) {

//Crio um novo objeto do tipo Router passando como parâmetro seu endereço Router router = new Router(address, " user ", "password");

//Executo o método da camada de acesso reponsável por configurar a interface //passando os devidos parâmetros

return RouterFuntions.configureInterface(router, "0/" + port, interfaceAddress, subnetMask, MTU, description);

}

Fonte: Elaborado pelo autor.

O quadro 16 apresenta o método deleteRoute. Através desse método, implementado dentro de um WS REST de mesmo nome e por meio da interface uniforme DELETE, é realizada a exclusão de uma entrada na tabela de roteamento estático no dispositivo de rede.

Quadro 16 – WS REST que exclui uma entrada na tabela de roteamento estático.

/**

* Método responsável por excluir uma entrada da tabela de roteamento * @param address

* @param destination

* @param destinationPrefixMask

* @return String - Contendo uma representação no formato JSON com o spool * oriundo do roteador mediante a execução do comando

*/ @DELETE

@Path("{address}/routes/static/{destination}")

@Produces("application/json")

public String deleteRoute(@PathParam("address") String address,

@PathParam("destination") String destination,

@QueryParam("destinationPrefixMask") String destinationPrefixMask) {

//Crio um novo objeto do tipo Router passando como parâmetro seu endereço Router router = new Router(address, "user", " password");

//Executo o método da camada de acesso reponsável por //excluir uma entrada da tabela de roteamento

return RouterFuntions.deleteRoute(router, destination, destinationPrefixMask);

}

Fonte: Elaborado pelo autor.

Diferente dos WS REST, onde as tarefas foram mapeadas em recursos, os WS SOAP valem-se dessa divisão através de serviços, levando em consideração a transformação de uma funcionalidade de negócio relacionada às tarefas de gerência de configuração.

Os componentes da arquitetura SOA utilizados neste trabalho são o service provider (provedor de serviço) e o service consumer (consumidor de serviço). As especificações de

hardware desses componentes serão definidas na seção 3.4 que trata do cenário de testes. No

contexto desta dissertação a responsabilidade do provedor de serviço é de ser o componente que torna os serviços (tarefas) passíveis de serem executados. Já o consumidor de serviço (cliente) é o componente responsável por consultar a existência de serviços e invocá-las para a execução de uma determinada tarefa de gerência de configuração de redes. Cabe salientar que no cenário montado para este trabalho, o componente service registry (registro de serviço) foi suprimido, logo as interações entre provedores e consumidores são realizadas sem intermediações.

Através dessa arquitetura é abstraída a implementação interna do serviço por parte do provedor, pois o consumidor invoca somente as interfaces fornecendo os parâmetros, quando necessário, para a sua execução. As interações (requisições e respostas) entre os pares são realizadas por meio de web services e definidas pelo protocolo SOAP, que se fundamenta em um modelo de dados XML. Os serviços elencados no quadro 17 executam as tarefas apresentadas no quadro 1 da seção 3.2. As tarefas mapeadas em serviços e não listadas nesse quadro são encontradas no APÊNDICE D.

Quadro 17 – Tarefas de gerência de configuração transformadas em web services SOAP.

ID Métodos Parâmetros de entrada

1 getRunningConfigurationRouter address 2 getAllVLANs address 4 setNewVLAN address VLANid name state 7 deleteVLAN address VLANid 8 getStaticRoutes address 11 getPortConfigurationRouter address port 12 configureInterface address port interfaceAddress subnetMask MTU description 13 noShutdownInterface address port 14 shutdownInterface address port

Fonte: Elaborado pelo autor.

Percebe-se pelo exposto no quadro 17 que as operações em SOA são apresentadas por métodos get e set – quando sua correspondência for clara à execução da tarefa – diferente de ROA, onde as operações são tratadas como substantivos – representações de recursos acessados através das URIs – e os verbos ficam a cargo da interface uniforme. Outro fato que diferencia a utilização de WS baseados em SOAP dos WS que utilizam o estilo arquitetural REST trata basicamente do seu mapeamento individual e do não agrupamento dos serviços. Essa diferença é motivada pelas características oriundas da arquitetura SOA que abordam a granularidade fina e a reutilização. Através dessas duas características foi incorporada uma maior flexibilidade à aplicação fazendo com que cada serviço desempenhe uma funcionalidade clara e passível de ser reutilizada sem a dependência ou agregação de outros serviços (o chamado encadeamento) no caso de WS REST. Essas duas características também possibilitaram aos serviços a qualidade de

isolamento, onde permitiu-se a existência de apenas uma forma de acesso – através de um serviço fino e bem definido – para a execução de determinada tarefa evitando assim o uso de código redundante na aplicação.

O trecho de código apresentado no quadro 18 é semelhante ao demonstrado no quadro 14, onde é exibido um WS REST que retorna as configurações de um dispositivo de rede. Porém, este difere na interface de acesso que se dá através da anotação @WebMethod expondo essa funcionalidade aos consumidores por meio do protocolo SOAP. A passagem de parâmetros quando o acesso acontece por meio de SOAP, para essa aplicação, é definida pela anotação @WebParam. Cabe salientar que da mesma forma definida em REST os web

services SOAP acessam os métodos disponibilizados pela API CLI disposta na camada de

acesso.

Quadro 18 – WS SOAP que retorna as configurações de um dispositivo de rede.

/***

* WebMethod responsável por obter as configurações de um dispositivo de rede * @param address

* @return - String no formato XML com o spool oriundo do roteador mediante a execução * do comando

*/

@WebMethod(operationName = "getRunningConfigurationRouter")

public String getRunningConfigurationRouter(@WebParam(name = "address") String address) {

//Crio um novo objeto do tipo Router passando como parâmetro seu endereço Router router = new Router(address, "user", "password");

//Executo o método da camada de acesso reponsável por obter a configuração //geral do roteador

return RouterFuntions.getRunningConfigurationRouter(router);

}

Fonte: Elaborado pelo autor.

O trecho de código apresentado no quadro 19 se vale das mesmas características expostas pelo quadro 18, diferenciando-se na funcionalidade de negócio que é tratada pela tarefa de configuração de uma interface (porta) no dispositivo de rede.

Quadro 19 – WS SOAP que configura uma interface de rede.

/**

* Método responsável por configurar uma interface (recurso) de rede no * dispositivo de rede * @param address * @param port * @param interfaceAddress * @param subnetMask * @param MTU * @param description

* @return - String no formato XML com o spool oriundo do roteador mediante * a execução do comando

*/

@WebMethod(operationName = "configureInterface")

public String configureInterface(@WebParam(name = "address") String address, @WebParam(name = "port") String port,

@WebParam(name = "interfaceAddress") String interfaceAddress,

@WebParam(name = "subnetMask") String subnetMask,

@WebParam(name = "MTU") String MTU,

@WebParam(name = "description") String description) {

//Crio um novo objeto do tipo Router passando como parâmetro seu endereço Router router = new Router(address, "user", " password ");

//Executo o método da camada de acesso reponsável por obter a configuração //geral do roteador

return RouterFuntions.configureInterface(router, port, interfaceAddress, subnetMask, MTU, description); }

Fonte: Elaborado pelo autor.

O diagrama de sequência apresentado na figura 11 ilustra o processo de execução da tarefa 1 através de WS REST e SOAP. Com o intuito de facilitar a visualização do fluxo as condições de guarda durante a ocorrência de erros, por exemplo, nos procedimentos de conexão ao equipamento ou na execução de uma tarefa, foram omitidas do diagrama de sequência; entretanto, foram tratadas nas APIs e aplicações.

Figura 11 – Diagrama de sequência das aplicações REST e SOAP.

No documento Comparação de estratégias para gerência de configuração de redes (páginas 73-80)