Por que eu devo ler este artigo:O presente artigo toma como foco o Enterprise Mobility Services, ou simplesmente EMS, que tem a finalidade de trazer a mobilidade de serviços em uma nuvem de forma simples aos projetos Delphi.

Diante disso, aqui serão explicitados os principais conceitos técnicos relacionados ao tema, passando pelos detalhes de sua arquitetura, seus propósitos e, principalmente, as nuances que envolvem sua utilização na prática.

A partir disso, o desenvolvedor estará apto a tomar decisões sobre a eventual adoção do framework em seu cotidiano construtivo e, eventualmente, sua implementação em ambientes reais de produção.

Ainda seguindo por esta linha, este artigo servirá como fundação e ponto de partida para outros desenvolvimentos futuros sobre o assunto, dada a abertura e complexidade do tema.

O Enterprise Mobility Services (EMS) é uma das grandes novidades trazidas pelo recente Delphi XE7 e representa um framework de desenvolvimento com capacidades REST (BOX 1), cuja finalidade principal é prover a devida mobilidade de serviços centralizados na nuvem. Em outros termos, o cenário estabelecido pelo EMS fundamenta um ambiente muito próximo ao fornecido por um servidor DataSnap REST.

Assim, toda sua fundamentação se baseia num aspecto cliente/servidor, onde os serviços, dados e pontualidades de negócio se concentram no servidor, ficando devidamente expostos e disponíveis a clientes nativos Delphi e de outras tecnologias como Java, .NET, PHP, etc.

A fim de pré-visualizar todo este novo cenário que se apresenta, a Figura 1 mostra uma panorâmica geral de toda a solução proposta pelo contexto EMS.

BOX 1. REST

No cenário mais atual do desenvolvimento de software, REST é uma sigla bastante comum no meio Mobile e Web, e vem a resumir o termo em inglês Representational State Transfer que, numa tradução mais popular para o português seria algo como Transferência de Estado Representacional.

Para fácil entendimento, REST pode ser definido como sendo um estilo de projetar aplicativos para internet, cuja estrutura deve se fundamentar em alguns aspectos relevantes, tais como: ser composta de elementos intercambiáveis e fracamente acoplados, prover recursos naturalmente nomeados e acessíveis diretamente através de uma URI (Identificador Uniforme de Recursos) própria.

Figura 1. Enterprise Mobility Services – Visão geral do contexto

EMS Server

Perante a composição do Enterprise Mobility Services, seu componente denominado EMS Server representa o lado servidor da arquitetura do framework, atuando como o canal direto de provimento das funções e serviços às aplicações clientes.

Além disso, ainda neste contexto, outra atribuição importante atrelada ao Server diz respeito à sua atuação no gerenciamento do banco de dados nativo da solução, tratado como EMS Database, visto em detalhes mais adiante. A seguir são então elencadas de forma explícita as três funções essenciais do EMS Server neste cenário:

· Possibilita o registro de novos recursos, o que garante a extensibilidade do próprio servidor;

· Provê o acesso devido às informações do servidor a partir de uma aplicação cliente, por meio de uma API REST proprietária;

· Disponibiliza, também por meio de sua API REST, acesso às informações armazenadas na base de dados do EMS (EMS Database), tais como dados de usuário, grupos e dispositivos.

O servidor dispõe de uma API REST pré-construída, também tratada como Built-in API REST, que é devidamente exposta aos clientes, possibilitando o acesso a alguns de seus principais recursos e funcionalidades. Dentre essas, estão atividades relacionadas a dispositivos, usuários e toda a parte analítica elaborada e disponibilizada pelo próprio framework. Em complemento a esta pontualidade está a Custom REST API, que diz respeito aos novos recursos desenvolvidos para serem adicionados ao contexto do EMS Server existente. Aqui, tais recursos ganham o nome EMS Resources, sendo incorporados ao servidor por meio de pacotes específicos denominados EMS Packages.

EMS Database

De forma padrão, a arquitetura do EMS prevê a presença invariável de um banco de dados nativo da solução, aqui tratado como EMS Database. Logo, é nele onde estarão armazenados os principais dados condizentes ao contexto, essenciais ao funcionamento linear do framework, tais como as informações de usuários e grupos de usuários de acesso ao servidor. Nesta etapa inicial de sua promissora trajetória, o Enterprise Mobility Services acaba por estabelecer o InterBase como sendo o principal e único SGBD adequado a essas pretensões. Isso se justifica pelo fato de ambos os produtos, EMS e InterBase, serem provenientes da mesma fabricante, a Embarcadero, o que dá margens para uma melhor integração neste seu momento primário de utilização. Obviamente, num futuro próximo, o leque de opções neste quesito deve ser expandido aos principais bancos de dados disponíveis no mercado. Por enquanto, na prática, ao tentar se configurar um ambiente EMS sem a presença de uma instância do InterBase instalada e operante, uma mensagem de erro é exibida, tal como mostra a Figura 2. Através de seus dizeres, fica nítida também a presença e utilização do FireDAC na constituição interna do framework.

Figura 2. Mensagem de erro EMS – Servidor InterBase indisponível

Do ponto de vista deste cenário atual que é estabelecido, a barreira imposta pelo uso de um SGBD pago pode ser plenamente derrubada pela aquisição de sua versão gratuita. Disponibilizada como Developer Edition, a distribuição free do InterBase é um tanto quanto desconhecida por grande parte dos desenvolvedores da comunidade, muito em razão de seu ofuscamento pela massiva notoriedade do Firebird, enquanto SGBD gratuito. Um contraponto muito presente nesta questão se dá pela confusão em torno da versão free do InterBase com sua versão trial, uma vez que ambas podem ser obtidas de forma gratuita através do site oficial do produto (ver seção Links ao final do artigo). É importante então ressaltar que Trial caracteriza a distribuição de avaliação da versão ...

Quer ler esse conteúdo completo? Tenha acesso completo