REST Web Services

Representational State Transfer(REST) define um conjunto de princípios de arquitetura para sistemas distribuídos, com os quais podemos desenhar serviços web com foco nos recursos de um sistema, incluindo a forma com os recursos são organizados e transferidos através de HTTP para vários clientes em diferentes linguagens. [Rod08]

REST foi apresentado pela primeira vez no ano 2000, por Roy Fielding na Universidade de Califórnia na sua dissertação com o titulo "Architectural Styles and the Design of Network-based Software Architectures"[Rod08], na qual eram analisados vários princípios de arquitetura de soft- ware para plataformas web utilizando sistemas distribuídos. Passados alguns anos após a sua introdução, várias frameworks para REST começaram a aparecer e ainda continuam a evoluir.

O número de web services que usam REST aumentou ao longo dos anos e neste momento é o modelo predominante. REST teve um enorme impacto na web por ser consideravelmente mais fácil de utilizar comparativamente a outras arquiteturas como SOAP ou WSDL (ambas baseadas em XML).

”REST’s client–server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and incre- ases the scalability of pure server components.” - Fielding 2000 [Fie00]

Uma implementação REST segue quatro princípios principais: 1. Usa métodos HTTP explicitamente

Com REST são usados métodos HTTP do tipo GET, POST, PUT e DELETE. • GET para operações de leitura;

• POST para operações de escrita. Permite criar novos objetos no sistema; • PUT permite atualizar ou criar um novo objeto ou recurso;

• DELETE permite apagar um objeto do sistema. 2. Não tem estado

Um web service REST precisa de escalar para conseguir suportar um número elevado de pedidos sem comprometer a performance. Imaginando um cenário em que o utilizador (cliente) faz um pedido HTTP GET para consultar os 25 primeiros itens de uma lista de contactos, num próximo pedido pode pretender consultar os 25 próximos contactos dessa lista. Num web service "sem estado"não são guardadas variáveis que permitam ao servidor saber qual a informação a enviar no próximo pedido. Neste caso, é necessário o servidor criar links para os próximos recursos para o qual o cliente vai aceder e a aplicação cliente utiliza essa informação no próximo pedido que pretenda efetuar (ver figura2.11).

3. Expõem o URI com uma estrutura do tipo diretório

Estado da Arte

Figura 2.11: Web Service REST sem estado

interpretação. Para conseguir esta simplicidade é utilizada uma estrutura do tipo diretório, onde é mapeado para o URI a estrutura em que as várias entidades se encontram organiza- das. Por exemplo, num fórum de discussão podemos utilizar um endereço com a seguinte estrutura:

http://www.webservice.com/discussion/topics/{topic}

4. Transfere XML, JSON ou ambos

As aplicações clientes têm a possibilidade de especificar o formato de output que melhor se adequa às suas necessidades. Para tal, apenas é necessário que no cabeçalho do pe- dido HTTP a aplicação indique o formato desejado. Estão disponíveis os formato XML (XML/XHTML) ou JSON. Os objetos no modelo de dados geralmente encontram-se re- lacionados e essas relações também devem ser preservadas no momento em que é criada uma representação desses mesmos objetos (recursos) para um dos formatos de output. Uma representação dos objetos apresenta o seu estado atual e os seus atributos no momento em que o pedido é enviado pela aplicação cliente.

2.3.3.1 WCF Data Service

WCF Data Service é uma plataforma que permite a criação e leitura de dados através da web utilizando o protocolo OData. Como foi referido, este protocolo permite expor os vários recursos de dados recorrendo a um URI. O acesso e alteração (criar, atualizar e apagar) da informação é efetuado através de pedidos HTTP, onde são usados os métodos GET, PUT, POST e DELETE. Uma vez que os WCF Data Service utilizam o protocolo OData, todas as funcionalidades e carac- terísticas presentes neste protocolo são preservadas. Uma das características é a possibilidade de acesso e manipulação dos dados independentemente da plataforma e da linguagem de programa- ção utilizada.

Um WCF Data Service conta também com outras facilidades para operações como autentica- ção e caching. Para isso, os WCF Data Services integram-se com outros serviços e aplicações já existentes como ASP.NET, Windows Communication Foundation (WCF), e Internet Information Services(IIS).

Estado da Arte

Apesar dos dados serem baseados no Modelo Entidade Relação (ERM), um WCF Data Ser- vices expõem o resultado independentemente da fonte de dados subjacente. Depois de um WCF Data Service receber um pedido HTTP, esse pedido é processado e passada uma representação para o WCF Data Service provider. Esse provider traduz o pedido no formato específico da fonte de dados e executa esse mesmo pedido[Mic10b]. Os WFC Data Services conseguem assim garan- tir uma independência da fonte de dados, separando o modelo conceptual dos recursos pedidos, usando OData, do modelo da fonte de dados subjacente.

Os WCF Data Services têm integração com várias tecnologias já existentes, como a ADO.NET Entity Framework, que permite criar um serviço de dados que expõem dados relacionais, tal como acontece com dados armazenados numa base de dados relacional. Desta forma, podemos usar as ferramentas do modelo Entity Data Model (EDM) para criar um modelo que contêm as referências entre este modelo e as tabelas da base de dados. Existem ainda bibliotecas para aplicações base- adas na Framework .NET assim como em Silverlight. Estas bibliotecas permitem interagir com os serviços de dados usando objetos da Framework .NET, assim como também é possível fazer consultas utilizando LINQ.

Arquitetura de um WCF Data Service

Estado da Arte

Como pode ser visto na figura2.12, existem várias bibliotecas que podem ser utilizadas por aplicações cliente para facilitar a manipulação da informação recebida utilizando o protocolo OData. Tal como foi referido no ponto2.3.2.2, estão contempladas bibliotecas para várias lin- guagens de programação, incluindo C#, JAVA, PHP, entre muitas outras.

A comunicação é efetuada através de pedidos HTTP, sendo que a resposta desses pedidos encontra-se no formato Atom(XML) ou JSON (potocolo OData). Tal como pode ser visto na mesma figura, a informação pode estar armazenada numa base de dados relacional ou noutra fonte de dados.

2.3.3.2 SharePoint Web Services

SharePoint fornece um conjunto de Web Services que permitem a aplicações cliente traba- lharem remotamente sobre uma aplicação desenvolvida sobre o mesmo. A interface REST do SharePoint é um WCF Data Service que permite a consulta de informação armazenada em listas e bibliotecas de SharePoint através de pedidos HTTP. Tal como todas os RESTful Web services, a interface REST do SharePoint permite operações HTTP do tipo GET, PUT, POST e DELETE. São também suportadas as opções de filtragem e de consulta apresentadas na tabela2.1, uma vez que este web service também utiliza o protocolo OData. Como os WCF Data Services são inde- pendentes da fonte de dados subjacente, pode ser utilizada uma base de dados relacional assim como outras fontes de dados.

Estado da Arte

Como pode ser visto na figura 2.13, a aplicação cliente começa por enviar uma expressão LINQ para o proxy do serviço WCF. Esse mesmo proxy converte a expressão LINQ para um URL que será enviado para a interface REST no servidor. A aplicação cliente também pode enviar o URI diretamente para a interface REST do SharePoint.

De seguida, a interface REST converte o pedido REST recebido para uma expressão LINQ do SharePoint, sendo que o processo de conversão efetuado é transparente para os programado- res. Posteriormente, essas expressões são executadas numa lista de SharePoint onde os dados se encontram armazenados. É importante notar que as expressões LINQ submetidas pela aplicação cliente para o proxy são independentes das expressões LINQ que o SharePoint executa sobre uma lista. Após a execução do pedido, a interface REST retorna os resultados para o proxy no formato Atom(XML) ou JSON, usando o protocolo OData. A figura2.14mostra a representação de alto nível da arquitetura da interface REST do SharePoint.

Figura 2.14: Arquitetura REST do SharePoint[Mic12c]

• Acesso a Documentos

Tal como tem vindo a ser referido ao longo desta dissertação, é possível efetuar operações do tipo CRUD (create, read, update e delete) através da interface REST fornecido pelo SharePoint. Uma vantagem de utilizar a interface REST do SharePoint é que desta forma não é necessário adicionar referências para a aplicação SharePoint às aplicações cliente para conseguir aceder às suas entidades e listas[Mic12b]. Para aceder às entidades e listas de uma aplicação SharePoint é necessário construir um pedido HTTP, utilizando o padrões do protocolo OData. É possível efetuar os pedidos HTTP em qualquer linguagem de programação, incluindo mas não limitando JAVA e C#.

Para ler informação de uma biblioteca SharePoint, devemos conhecer o URI para essa biblio- teca e a representação OData de forma a a aplicar os filtros necessários às nossas necessidades (ver tabela2.1). Por exemplo, para ler todos os documentos presentes na pasta WorkOrders devemos fazer o seguinte pedido:

http://ws2k8r2x64/GesMan/_vti_bin/ListData.svc/WorkOrders

Estado da Arte

http://ws2k8r2x64/sites/GesMan: Corresponde ao endereço da aplicação SharePoint _vti_bin/ListData.svc/ : Devolve o conjunto de dados relativos ao site

/WorkOrders: Nome da biblioteca que se pretende aceder, neste caso, "WorkOrders"

A representação OData pode ser obtida no formato XML e JSON, sendo que a pré-definida é a linguagem de anotação XML. Para obtermos essa representação em JSON, devemos enviar no cabeçalho do pedido HTTP o par "Accept", "application/json;odata=verbose". De seguida podemos ver um excerto de um pedido efetuado na linguagem de programação JAVA, assim como um pequeno excerto da resposta recebida.

1 URL urlRequest = new URL(urlStr);

2 HttpURLConnection conn = (HttpURLConnection) urlRequest.openConnection();

3 conn.setRequestMethod("GET");

4 conn.setRequestProperty("Accept", "application/json;odata=verbose");

5 conn.setRequestProperty("charset", "utf-8");

Code 2.1: Envio de um pedido HTTP GET

A resposta recebida inclui todas as informações relativas ao documento, tal como a sua meta- datae as várias informações relativas ao ficheiro (nome, diretório onde está armazenado, o tipo de ficheiro, data de modificação, entre muitos outros). A partir desta informação é possível fazer o download do ficheiro pretendido.

1 { 2 "__metadata":{ 3 "uri":"http://ws2k8r2x64/GesMan/_vti_bin/ListData.svc/WorkOrders (88)", 4 "media_src":"http://ws2k8r2x64/GesMan/WorkOrders/Emails/teste. docx" 5 }, 6 "Id":88, 7 "ContentType":"Document", 8 "Path":"/GesMan/WorkOrdes/Emails", 9 "Name":"teste.docx",

10 "Title":"Documento de teste" 11 }

Code 2.2: Resposta em JSON a um pedido HTTP GET

Para fazer o upload de um novo documento para o servidor, é necessário também conhecer o nome da biblioteca SharePoint e o URI onde o documento vai ser armazenado.

Estado da Arte

http://ws2k8r2x64/sites/GesMan/_vti_bin/ListData.svc/WorkOrders

No exemplo de código2.3é possível ver um excerto de um pedido HTTP do tipo POST, que permite a criação de um documento no servidor. Ao cabeçalho do pedido efetuado é necessário adicionar a informação relativa ao diretório para onde o ficheiro vai ser armazenado, assim como o seu nome. Essa informação é adicionada no cabeçalho "Slug". A resposta deste pedido será a informação relativa ao ficheiro criado ou, em caso de falha, o erro devolvido pelo servidor.

1 HttpURLConnection conn = (HttpURLConnection)

2 ((new URL(urlStr).openConnection()));

3 conn.setRequestProperty("Content-Type", "application/json");

4 conn.setRequestProperty("Accept", "application/json");

5 conn.setRequestProperty("Slug", "http://ws2k8r2x64/GesMan/WorkOrders/" + "documento .docx");

6 conn.setRequestMethod("POST");

Code 2.3: Upload de um documento para o servidor

Para enviar o ficheiro para o servidor através de um pedido HTTP POST, primeiro é necessário ler a informação binária do ficheiro para um array de bytes utilizando um FileInputStream. De seguida, esse array de bytes é escrito para o OutputStream, tal como pode ser visto no excerto de código2.4.

1 File file = new File("C:\\documento.docx");

2 byte[] fileData = new byte[(int) file.length()];

3 FileInputStream inn = new FileInputStream(file);

4 inn.read(fileData); 5 6 OutputStream os = conn.getOutputStream(); 7 os.write(fileData); 8 os.close(); 9 inn.close();

Code 2.4: Escrita de um documento através de um pedido HTTP POST

• Acesso a Dados

O acesso a dados a partir de uma aplicação SharePoint pode ser efetuado de duas formas dis- tintas, dependendo da localização onde os dados se encontram armazenados. Desta forma, podem existir dados armazenados numa lista SharePoint, assim como numa base de dados relacional. Dados são recursos de informação que podem ser ou não relacionados entre si.

Na primeira situação, o acesso e manipulação de dados que se encontram armazenados numa lista SharePoint é em tudo semelhante ao acesso e manipulação de documentos, como foi visto no ponto anterior.

Estado da Arte

No caso de pretendermos fazer o acesso a dados armazenados numa base de dados relacional, é necessário criar um novo WCF Data Service. De seguida é necessário criar as chamadas necessá- rias, sendo que estas podem ser do tipo GET, PUT, POST e DELETE. Tal como já foi referido, um WCF Data Service utiliza o protocolo OData e todas as suas caraterísticas encontram-se presentes. Podemos ainda utilizar as capacidades da linguagem de consulta LINQ, utilizando a linguagem de programação C# ou Visual Basic. Conseguimos assim efetuar as operações necessárias com os dados armazenados armazenados nas tabelas presentes em base de dados.

2.3.3.3 Limitações dos SharePoint Web Services

Um web service geralmente é mais lento a efetuar determinadas operações, comparativamente aos mecanismos de comunicação binários (nativos). Da mesma forma, no caso SharePoint também é mais lenta a manipulação de dados através de web services comparativamente aos mecanismos geralmente utilizados, como é o caso de .NET [Dam10].

Este atraso nas respostas recebidas pode ser explicado, no caso da resposta recebida utilizar a linguagem de anotação XML, pelo facto desta linguagem ser muito ”verbosa”. São enviados vários dados repetidos, como é o caso das várias tags existentes de forma a respeitar a boa formatação da linguagem. De forma a melhorar esta situação, podemos usar JSON que é significativamente mais rápido devido à sua simplicidade em comparação com a XML.

Outra situação que atrasa as respostas de um SharePoint Web Service é o facto de não existir o conceito de sessão e todos os pedidos efetuados terem de ser autenticados através de um username e password.

Outra das limitações está relacionada com o upload de ficheiros para o servidor. Esta limitação prende-se com o facto de apenas ser utilizado um único buffer para receber todo o conteúdo do ficheiro. No SharePoint, o tamanho máximo pré-definido para o tamanho do ficheiro que queremos enviar é de 50MB, embora possa ser configurado e o limite máximo para a ser de 2GB[Dam10].

Capítulo 3

Mecanismos de integração

desenvolvidos

Neste capítulo será apresentado e descrito o sistema de integração desenvolvido para a aplica- ção buildONE. Serão apresentadas as tecnologias e ferramentas de integração desenvolvidas, com especial destaque para o Add-in desenvolvido para o MS Outlook e a aplicação de sincronização desenvolvida para MS Explorer.

3.1

Objetivos

Tal como foi referido no capítulo1, o objetivo desta dissertação passou pelo desenvolvimento de mecanismos de integração que permitissem a aplicações cliente executadas em diferentes pla- taformas o acesso a recursos de informação disponíveis em aplicações servidor corporativas. No caso das aplicações cliente, são salientadas as ferramentas de produtividade pessoal como é o caso do MS Outlook e o MS Explorer. Pretendeu-se integrar estas ferramentas com um módulo da apli- cação buildONE, mais concretamente o módulo de Gestão de Ordens de Trabalho. Este módulo desenvolvido será analisado com mais detalhe no capítulo4e no capítulo5.

Quando se fala em recursos, estes podem ser de natureza diferente. Podem ser dados ar- mazenados em sistemas de gestão de bases de dados, documentos ou mensagens de email com os respetivos documentos em anexo, que em ambos os casos são arquivados em sistemas de ficheiros, entre outros tipos de ficheiros. O capítulo2faz referência à analise e desenvolvimento de vários mecanismos de integração que permitem o acesso e a manipulação destes recursos recorrendo a Web ServicesREST.

De forma a integrar os recursos da plataforma buildONE com a ferramenta de produtividade pessoal MS Outlook, foi desenvolvido um Add-in que permite a integração desses mesmos recur- sos com esta ferramenta. Com esta extensão é possível executar várias tarefas, como a criação de compromissos ou o arquivo de emails de um projeto para o servidor, diretamente a partir da aplicação Outlook sem a necessidade de recorrer à aplicação web como geralmente acontece com outro tipo de soluções.

Mecanismos de integração desenvolvidos

Para estender estas funcionalidades para o Windows Explorer do utilizador, foi criada uma aplicação que permite de forma simples a organização de documentos alojados no computador pessoal para pastas de documentos armazenadas em servidor. Esta aplicação mapeia numa pasta do computador do utilizador, a estrutura de pastas e documentos de uma biblioteca de documentos de uma aplicação SharePoint, neste caso do módulo de Gestão de ordens de trabalho da aplicação buildONE.

Em ambos os casos foram utilizados os Web Services REST analisados e desenvolvidos de forma a utilizar os recursos da aplicação buildONE nestas ferramentas de produtividade. Estes recursos podem ser dados relacionais ou documentos provenientes de uma biblioteca de ficheiros SharePoint.

Com estas aplicações o utilizador consegue a criação e manipulação de conteúdos armazena- dos em aplicações corporativas através de aplicações e ambientes que já lhe são familiares no seu quotidiano, aumentando desta forma a facilidade com que esta interação é feita.

Na figura3.1pode ser vista a arquitetura simplificada da aplicação, onde pode ser observada uma aplicação onde todos os recursos são armazenados de forma a manter a informação centra- lizada e atualizada entre as várias plataformas. Esses recursos (dados e documentos) podem ser acedidos e manipulados diretamente através da aplicação web bem como através do Outlook, de uma aplicação smartphone ou mesmo através de uma aplicação PC-Desktop.

Mecanismos de integração desenvolvidos