Desenvolvimento-SAAS E Java Com ZK

(1)

Converta seu aplicativo da Web para uma

solução SaaS de múltiplos arrendatários

Uma lista de verificação de considerações e etapas para rapidamente transformar seu aplicativo da Web em um aplicativo em nuvem

Resumo: Você construiu um aplicativo com base na Web, mas precisa torná-lo compatível e eficiente em um ambiente em nuvem. Quais etapas é preciso seguir para converter o aplicativo em um aplicativo SaaS maduro, de múltiplos arrendatários e pronto para nuvem? O autor utiliza um aplicativo da Web de amostra, discute as considerações e alterações necessárias para torná-lo um sucesso na nuvem e mostra as etapas necessárias para colocá-lo lá. Então, como um bônus, demonstra o software que sua empresa desenvolveu para fornecer uma abordagem de "plug-in" a múltiplos arrendatários.

Imagine que você tem um aplicativo que está vendendo no mercado. Você vê o aviso e percebe que Software as a Service (SaaS) em uma infraestrutura em nuvem é a maneira como o setor está orientado. Você sabe que precisa dele e seus próprios clientes podem já estar pressionando para oferecer uma versão SaaS do seu produto.

O desafio é fazer a conversão para SaaS rapidamente, de maneira eficiente e mantendo ou melhorando a lucratividade.

Há muitas diferenças que precisam ser consideradas para um aplicativo SaaS versus um aplicativo da Web regular. Algumas delas são técnicas e outras estão relacionadas à mudança no modelo de negócios ao qual uma empresa precisa se adaptar ao entregar SaaS.

Aplicativo da Web típico vs. SaaS

O SaaS tem suas características de definição centrais na habilidade de os clientes usarem um aplicativo de software em uma base de assinatura de pagamento por uso. Não precisam adquirir as licenças para o software e providenciar sua instalação, hospedagem e gerenciamento. Esses aspectos operacionais são de responsabilidade da organização que fornece o aplicativo SaaS.

Múltiplos arrendatários é a chave para SaaS de sucesso

Embora a habilidade de assinar um aplicativo seja minimamente suficiente para satisfazer os critérios básicos de SaaS, em termos práticos, não é o bastante. Na prática, um aplicativo SaaS precisa também ser um aplicativo de múltiplos arrendatários.

Isso está muito relacionado com fatores que se resumem a ser simplesmente econômico. Os CEOs de importantes empresas de SaaS concordam, não é possível ampliar um negócio SaaS sem múltiplos arrendatários. (Veja Acordo: SaaS precisa de múltiplos arrendatários .)

Acordo: SaaS precisa de múltiplos arrendatários

Múltiplo arrendatário é um requisito para um fornecedor de SaaS ser bem-sucedido. — Marc Benioff, CEO, Equipe de Vendas

(2)

— Treb Ryan, CEO, OpSource

Alcançamos um custo incrivelmente efetivo (baixo) de seat para computação... temos o menor custo no segmento de mercado de SaaS (como resultado de múltiplos arrendatários). — Lars Dalgaard, CEO,

SuccessFactors

Hoje, ASP é um retorno tentador. Entretanto, a abordagem de

datacenter na nuvem ainda segrega clientes usando um modelo de um único arrendatário, o que significa que ainda é muito dispendiosa para operar e, portanto, para comprar. — Zach Neson, CEO,

NetSuite — Nossa margem bruta foi acima de 70% (devido a

múltiplos arrendatários).

Múltiplos arrendatários para nós é realmente importante... cria um modelo muito mais eficiente — Tim Wallace, CEO, iPipeline Múltiplos arrendatários é o que limita o ganho no jogo do SaaS —

Henry Olson, ex-CEO, Edge Dynamics

Múltiplos arrendatários possibilita que todo um modelo de assinatura funcione... — Jeff Kaplan, CEO, THINKStrategies

Múltiplos arrendatários é o nível de eficiência para SaaS

A principal alavanca para eficiência vem de múltiplos clientes, a habilidade de acomodar diferentes usuários do aplicativo enquanto se faz com que pareça para cada um que possuem o aplicativo todo para si próprio. Estamos acostumados com esse conceito, uma vez que se aplica a usuários

individuais em um sistema, mas é ligeiramente diferente para um ambiente SaaS. Em um aplicativo SaaS de uma empresa típico, os usuários são grupos de funcionários de uma organização em particular e essa organização é conhecida como arrendatário. Isso é similar ao que se encontraria em um aplicativo da Web simples se a organização comprasse o aplicativo; haveria um grupo de funcionários que seriam os usuários do aplicativo e a organização seria o proprietário. Em um modelo SaaS, a organização é um arrendatário, não um proprietário, mas os grupos de funcionários ainda são usuários. Cada usuário tem uma associação com um arrendatário em particular

(organização) e o SaaS fornece a cada arrendatário a experiência de possuir sua própria cópia do aplicativo, que seus usuários podem utilizar.

Virtualização na nuvem aproveita SaaS

A diferença entre um aplicativo da Web simples e um aplicativo SaaS ativado para nuvem envolve dois dos maiores recursos de utilização de capacidade em TI hoje:

• Múltiplos arrendatários (que foi apresentado anteriormente). • Virtualização de hardware.

Embora a maior fonte de eficiência de aplicativo venha de múltiplos arrendatários da arquitetura do aplicativo, a alavanca secundária para eficiência vem da virtualização de hardware. Uma nuvem faz um trabalho melhor de aproveitar o valor aumentando as percentagens de utilização de uma dada quantidade de hardware empregando tecnologia de virtualização para reduzir a capacidade não utilizada que resulta quando uma abordagem de máquina física de datacenter comum é usada. Além disso, a nuvem oferece o potencial para realocar o hardware dinamicamente para o aplicativo com base em sua necessidade de recursos. Essa elasticidade, que pode ser no curto prazo (minutos) ou longo prazo (meses), ajuda a desvincular as decisões sobre hardware de um único aplicativo e

(3)

distribuí-las sobre um grande número de aplicativos,suavizando as variações e tornando o investimento e hardware mais previsível e gerenciável.

Agora vamos ver as etapas gerais para converter um aplicativo da Web mais tradicional em um aplicativo ativado para SaaS.

Convertendo aplicativos da Web para SaaS

Para converter seu aplicativo para um aplicativo SaaS, é preciso fazer sete ações: 1. O aplicativo deve dar suporte a múltiplos arrendatários.

2. O aplicativo deve ter algum nível de inscrição por autoatendimento. 3. Deve haver um mecanismo de assinatura/faturamento estabelecido. 4. O aplicativo deve pode ser escalado com eficiência.

5. Deve haver funções estabelecidas para monitorar, configurar e gerenciar o aplicativo e os arrendatários.

6. Deve haver um mecanismo estabelecido para dar suporte a identificação e autenticação exclusivas de usuário.

7. Deve haver um mecanismo estabelecido para dar suporte a algum nível de customização para cada arrendatário.

Vamos observar cada um com mais detalhes.

Suporte a múltiplos arrendatários

Múltiplos arrendatários é a chave para determinar a eficiência de SaaS. Normalmente, um aplicativo dá suporte a múltiplos usuários, mas com a suposição de que todos os usuários são de uma

organização. Este modelo é bom para o mundo pré-SaaS, em que uma organização comprava um aplicativo de software para uso por seus membros. Mas no mundo do SaaS e da nuvem, muitas organizações usarão o aplicativo: elas devem poder todas permitir que todos os seus usuários o acessem, mas o aplicativo deve permitir que somente os membros da própria organização acessem os dados para a organização.

Esse recurso de ter múltiplas organizações (chamado de múltiplos arrendatários na nomenclatura do SaaS), coexiste no mesmo aplicativo sem comprometer a segurança de dados para essas

organizações define o aplicativo como sendo de múltiplos arrendatários.

Há diversos níveis de múltiplos arrendatários (como visto na figura após a lista): 1. Virtualização simples na nuvem em que apenas o hardware é compartilhado. 2. Aplicativo único com bancos de dados separados por arrendatário.

3. Aplicativo único e banco de dados compartilhado (maior eficiência, verdadeiramente com múltiplos arrendatários).

(4)

Pode-se argumentar que o primeiro modelo não é realmente de múltiplos de arrendatários, mas é frequentemente usado em uma nuvem com servidores de virtualização e promovido como uma forma de múltiplos arrendatários. Na realidade, ele é insuficiente e possui apenas vantagens marginais sobre o antigo modelo ASP com hardware dedicado.

O nível mais eficiente é aquele no qual os aplicativos de fato compartilham um banco de dados e a lógica de negócios do aplicativo. Alcançar isso pode ser um processo oneroso que requer alterações ao esquema de banco de dados para adicionar um identificador de arrendatário para toda tabela e visualização, bem como reescrever todo acesso SQL para adicionar os critérios de arrendatários aos filtros. Faltando um local no código onde precisa ocorrer que compromete a segurança de dados do aplicativo.

Além das instâncias de acesso de dados que ocorrem no aplicativo, pode haver outros aplicativos, como gravadores de relatório ou aplicativos de utilitário que também devem ser modificados para incluir a filtragem de arrendatário necessária para manter os dados de arrendatários individuais acessíveis apenas àqueles arrendatários em particular. O tipo de acesso que não é diretamente do aplicativo em si apresenta problemas que devem ser controlados. Se qualquer usuário autorizado puder gravar um relatório, ele deve ser impedido de acessar os dados que não pertençam ao arrendatário do qual eles fazem parte.

Inscrição de autoatendimento

Seu aplicativo deve estar disponível com algum nível de inscrição de autoatendimento, mesmo se for simplesmente um mecanismo de solicitação que resulte em um processo de negócios para adicionar um arrendatário ao aplicativo.

Assinatura e faturamento

Você deve fornecer um mecanismo de assinatura e faturamento. Uma vez que os aplicativos SaaS por design envolvem uma série de pagamentos com base em fatores como número de usuários por arrendatário, opções de aplicativo e talvez duração de uso, deve haver uma maneira de rastrear e gerenciar informações de faturamento que estejam acessíveis aos administradores do arrendatário.

Escalando e gerenciando o aplicativo

Você deve poder escalar conforme as assinaturas aumentam. A infraestrutura de nuvem é uma maneira lógica de fazer isso, uma vez que incorpora muitos recursos que serão precisos para uma escalada eficaz e eficiente.

Ainda, você deve fornecer funcionalidade de administração e gerenciamento de aplicativo para monitorar, configurar e gerenciar o aplicativo e todos os arrendatários.

ID do usuário e autenticação

Você precisa fornecer um mecanismo de suporte à identificação do usuário e autenticação que permita a identificação exclusiva dos usuários. Porque múltiplos arrendatários permite que todos os usuários que se conectam ao sistema sejam identificados para determinar a qual arrendatário

pertencem, deve haver um relacionamento definitivo que permita que os usuários sejam identificados como pertencendo a um arrendatário em particular. Esse relacionamento usuário-arrendatário são as informações chave usadas para restringir os dados que podem ser acessados pelo usuário.

Os endereços de e-mail são uma maneira típica de fazer isso de modo que a singularidade seja garantida e os indivíduos possam ser reconhecidos e identificados como pertencendo a um arrendatário em particular.

(5)

Há muitos mecanismos de identificação e métodos de integração com eles, então um mecanismo flexível para permitir que um usuário seja identificado é essencial. Frequentemente é necessário que um arrendatário em particular possa utilizar seu LDAP existente ou outro serviço de diretório ou mecanismo de autenticação para dar suporte a conexão única ao aplicativo SaaS. Embora esse tipo de autenticação externa do usuário seja importante, é responsabilidade do aplicativo SaaS

estabelecer que o usuário identificado seja um membro do arrendatário alegado.

Personalização por arrendatário

É preciso fornecer um mecanismo para dar suporte a um nível de personalização básica para cada arrendatário, de modo que tenha um URL único, uma página inicial, logotipos, esquemas de cores, fontes e talvez inclusive um idioma.

Esse nível básico de configuração por arrendatário é esperado, mas para verdadeiramente satisfazer as necessidades de múltiplos arrendatários, inevitavelmente haverá uma necessidade de

customização por arrendatário que vai além do básico.

Customizações típicas requeridas são similares ao tipo de customizações que seriam feitas por um arrendatário com uma versão interna do aplicativo. Eles podem envolver a adição de campos ou mesmo tabelas, configurando uma lógica de negócios especial ou integração com outro aplicativo. Poder fazer esses tipos de customizações por arrendatário sem precisar estabelecer uma instância separada que comprometa a eficiência de um design de múltiplos arrendatários é o marco da arquitetura SaaS de alta capacidade.

Questões de desempenho a considerar

Questões de desempenho para aplicativos de múltiplos arrendatários SaaS são tipicamente os mesmos que seriam encontrados para qualquer aplicativo da Web acomodando o mesmo número de usuários com o mesmo nível de atividade. Pode haver melhores práticas para lidar com demandas de capacidade crescentes em aplicativos da Web; em geral, são todas aplicáveis a aplicativos SaaS de múltiplos arrendatários também. Essas técnicas tipicamente envolvem escala horizontal e vertical e balanceamento de carga através de um conjunto de servidores.

Escala horizontal/vertical

Recursos de infraestrutura em nuvem oferecem muitas oportunidades para fazer esse tipo de escalabilidade acontecer dinamicamente e de maneira automatizada, para fornecer os recursos quando necessário e escalar de volta os recursos quando os acordos de nível de serviço (SLAs) de desempenho puderem ser cumpridos com menos recursos. Esse recurso elástico é algo que deve ser ajustado para responder precisamente da maneira necessária para fornecer o serviço sem fornecer recursos que serão subutilizados:

• A escala horizontal normalmente é empregada para a camada do serviço de aplicativos. • A escala vertical normalmente é empregada para a camada do banco de dados.

Armazenamento em cluster do banco de dados

Com aplicativos SaaS, o número total de usuários pode ser muito alto para um produto

bem-sucedido; em algum ponto a escala vertical do banco de dados pode não ser a solução ideal. Muitas tecnologias de banco de dados têm a habilidade de fornecer um modelo de banco de dados em cluster que permite que mais capacidade seja fornecida com relação ao mesmo banco de dados. O DB2® tem diversas opções que funcionam bem com esse modelo e podem ser usadas para criar um cluster de banco de dados.

(6)

Geografia, particionamento e sincronização

Entretanto, há outras técnicas que podem ser mais adequadas, dependendo do aplicativo SaaS e da sua população de usuários. Uma vez que o SaaS é inerentemente acessível de qualquer lugar no mundo, a população de usuários pode estar distante; essa distância pode causar prejuízo de desempenho devido às longas topologias de rede.

Nesses casos, pode ser vantajoso usar nuvens que estejam em regiões diferentes e particionem os dados ou usem sincronização para manter a consistência. Qual dessas opções é adequada dependerá da natureza do aplicativo em particular. Algumas não serão receptivas a sincronizações de longa distância.

Bancos de dados separados

É claro que o método mais radical (para aplicativo SaaS, pelo menos) para usar quando a capacidade do banco de dados não puder atingir as demandas é estabelecer um banco de dados separado. Qualquer um que deseje um aplicativo SaaS de múltiplos arrendatários precisa considerar que essa opção pode levar à situação insustentável de dar suporte a um banco de dados por

arrendatário, o que leva diretamente ao tipo de ineficiências que os múltiplos arrendatários busca evitar.

E se os servidores do aplicativo precisarem ser divididos para atender apenas um banco de dados, então as ineficiências de múltiplos arrendatários serão ainda mais pioradas. Em um mercado competitivo, essas eficiências de múltiplos arrendatários são fatores de sucesso cruciais para empresas SaaS.

Design resgata o poder do balanceamento de carga

Uma maneira de reter tanta eficiência quanto possível mesmo quando, por qualquer motivo, bancos de dados separados precisam ser usados, é ter um design de múltiplos arrendatários que possa permitir que qualquer um dos servidores de aplicativo no cluster de carga balanceada acesse o apropriado quando houver múltiplos bancos de dados. Desta maneira, a eficiência do cluster de carga balanceada pode ser mantida com todos os servidores de aplicativo podendo conectar-se a qualquer banco de dados para as sessões de usuário a que estão dando suporte. Isso mantém o maior nível de eficiência dentro da restrição de múltiplos bancos de dados.

Capacidade não é a única exigência

Pode haver motivos legítimos para ter múltiplos bancos de dados além de simplesmente a capacidade, como a demanda por uma versão criptografada do banco de dados para certos

arrendatários de alta segurança. A capacidade pode não ser o problema, então é importante ter um design que maximize as eficiências quando possível, mesmo quando um modelo inerentemente menos eficiente for necessário.

Questões de segurança a considerar

Em uma pesquisa de opinião após a outra, a segurança costuma ser listada como a principal preocupação para os assinantes de aplicativos SaaS ou pelo menos uma das principais. Nenhum provedor de SaaS pode ignorar a segurança. Mas frequentemente o conceito de segurança de dados é considerado apenas dentro do contexto do aplicativo SaaS em si.

A maioria das arquiteturas de aplicativo SaaS assume medidas de segurança de dados que evitam que um arrendatário veja os dados de outro arrendatário como um requisito da linha de base.Mas:

(7)

outros aplicativos.

• Alguns desses outros aplicativos podem estar fora dos aplicativos (não controlado pelo provedor do SaaS).

• Nem todas as arquiteturas SaaS são projetadas com acessibilidade com aplicativos externos em mente.

Esses outros aplicativos poderiam ser aplicativos desenvolvidos pela própria empresa que precisem acessar ou compartilhar dados; poderiam ser ferramentas analíticas e de gravação de relatório que minam os dados para tendências. Mesmo ferramentas utilitárias usadas pelos administradores de bancos de dados podem ser preocupações de segurança se os arrendatários puderem usá-las para acessar, ou, pior ainda, manipular dados que não pertencem a eles.

Uma arquitetura de melhor prática para SaaS deve considerar que nem todo o acesso a dados pode estar sob controle do aplicativo; deve haver mecanismos estabelecidos para permitir que os dados sejam protegidos para cada arrendatário, não importa se o acesso é através do aplicativo SaaS ou de algum aplicativo externo.

Selecione sua pilha de tecnologia

Sempre há trocas quando se tomam decisões sobre pilhas de tecnologia: em um aplicativo SaaS, isso é especialmente verdadeiro porque as decisões são tomadas para todos os arrendatários. Vamos examinar algumas dessas considerações.

Considerações sobre o sistema operacional

O sistema operacional em um aplicativo da Web é provavelmente o menos relevante para os usuários porque sua interação é através do navegador. Entretanto, há considerações financeiras e técnicas que podem entrar em jogo.

• Se houver dependência de um código em particular que seja dependente do sistema operacional, então as escolhas são restringidas.

• Também pode haver uma restrição se houver uma necessidade comum de integração com aplicativos externos que seja mais bem realizada em um sistema operacional que em outro. A economia implacável da nuvem sempre empurra a escolha em direção ao sistema operacional com as menores tarifas de licenciamento e bom desempenho. Os principais meios de escalar aplicativos da Web envolvem escala horizontal; isso significa que conforme o aplicativo SaaS cresce, o número total de instâncias de servidor de aplicativo da Web aumentará, e isso é um custo direto de operações.

Considerações do banco de dados

O banco de dados em aplicativos da Web provavelmente não é uma preocupação crucial dos usuários finais, porque suas interações sejam através do navegador e desde que o aplicativo possa armazenar e recuperar seus dados, isso é amplamente irrelevante para eles.

Novamente, considerações financeiras e técnicas entram em jogo para o desenvolvedor de

aplicativos. Se houver dependência de aplicativo para recursos em particular do banco de dados, as escolhas são restringidas.

A escolha de um banco de dados pode ser importante por diversos motivos de design de aplicativo, e também pode ser afetada pelas demandas em particular do ambiente SaaS.

As demandas sobre um banco de dados são maiores em um aplicativo SaaS simplesmente devido ao número de usuários que por fim estará integrado. Então escalabilidade de banco de dados é muito importante. A escalabilidade do banco de dados normalmente é feita em uma única instância com servidores de banco de dados cada vez mais potentes usados para um aplicativo cada vez mais

(8)

exigente. Mas a escalabilidade necessária de aplicativos SaaS tem o potencial de superar as

habilidades da escala vertical, então a próxima etapa em escalabilidade de banco de dados envolve ter um recurso de armazenamento em cluster.

A habilidade de fazer esse tipo de armazenamento em cluster no ambiente em nuvem pode influenciar na escolha do banco de dados. Por exemplo, o DB2 pode ser selecionado por sua habilidade de executar em uma variedade de sistemas operacionais que fornecem escala vertical e por sua flexibilidade de escolhas para escalabilidade através de múltiplas instâncias de

armazenamento em cluster e redundância. Por exemplo, um cluster DB2 HADR (High Availability Disaster Recovery) pode ser configurado na nuvem.

Considerações do servidor de aplicativos

A escolha do servidor de aplicativos, como as outras decisões sobre a pilha de tecnologia, também é principalmente uma decisão do desenvolvedor de aplicativo SaaS, uma vez que as interações do usuário final são apenas através do navegador. Mas pode haver diferenças importantes por diversos motivos de design de aplicativo, e também podem afetadas em função de demandas em particular do ambiente SaaS.

Aplicativos que tiram vantagem de recursos especiais ou componentes complementares de

servidores de aplicativos, como o WebSphere® , precisarão usar o servidor do aplicativo na nuvem. Os raciocínios para escolher um servidor de aplicativos normalmente são feitos em um ponto precoce no ciclo de vida do aplicativo porque o aplicativo pode se beneficiar de alguns recursos em particular ou há complementos de terceiros ou recursos de integração que são importantes ao aplicativo. Às vezes é simplesmente porque os padrões internos e o conhecimento da organização determinam o uso de componentes em particular da pilha de tecnologia.

Os pontos de decisão na seleção e configuração da pilha de tecnologia para usar em um ambiente em nuvem/SaaS envolvem equilibrar as forças técnica e econômica para obter um bom resultado. Flexibilidade é a chave para a evolução da tecnologia

Ter a capacidade de tomar decisões e fazer trocas com relação à pilha de tecnologia a usar e

capacidade de rever essas decisões mais tarde é um recurso valioso na arquitetura SaaS. Conforme a tecnologia muda, os principais provedores em nuvem incorporarão novos aplicativos e recursos de middleware e é uma vantagem poder adotá-los para seu aplicativo SaaS.

As arquiteturas de aplicativo SaaS que o forçam a tomar decisões que o trancam em uma pilha de tecnologia em particular comprometerão a habilidade de um aplicativo SaaS evoluir e se adaptar. Os conceitos chave de uma arquitetura orientada a serviços são idealmente adequados para fornecer a agilidade e a flexibilidade necessárias para aplicativos SaaS. Loose coupling fornece flexibilidade, e a flexibilidade possibilita evolução estratégica e tática.

No restante deste artigo, usarei o Servidor Multi-Tenant da Corent ™ para fornecer um exemplo de como converter um ™ aplicativo da Web de faturamento de software livre Java em uma versão SaaS de múltiplos arrendatários com mínimo esforço.

Automaticamente transformar em SaaS aplicativos com o Servidor Multi-Tenant da Corent Os provedores de nuvem oferecem uma ampla variedade de recursos e podem acomodar quase qualquer aplicativo da Web. Transformar um aplicativo em um aplicativo totalmente SaaS de múltiplos usuários exige amplas mudanças ao código do aplicativo e reprojeto e reconfiguração do banco de dados.

O Servidor Multi-Tenant da Corent possibilita que ISVs assumam uma abordagem diferente, usando uma camada de middleware para fornecer os múltiplos arrendatários críticos (preservando, portanto, o investimento no código existente). Descreverei as quatro etapas necessárias para converter jBilling, um aplicativo da Web Java popular de software livre representativo de um

(9)

aplicativo de múltiplos arrendatários típico, em uma versão SaaS de múltiplos arrendatários. Etapa 1. Transformar o esquema de banco de da dos em um modelo abstrato

A pilha típica para um aplicativo da Web é semelhante à Figura 1; um aplicativo comunica-se com um banco de dados, frequentemente através de uma camada de persistência de dados como

Hibernate.

Figura 1. Pilha de aplicativo da Web típico na nuvem

Para transformar um aplicativo em um aplicativo de múltiplos arrendatários , o banco de dados precisa ser reprojetado para ter campos adicionais para gerenciar os dados de identificação do arrendatário que serão precisos para permitir que os dados sejam filtrados pelo arrendatário. O aplicativo SaaS-Factory™ é usado para ler o esquema do banco de dados de aplicativo existente Ele então cria um modelo desse banco de dados, que subsequentemente é usado para gerar um novo banco de dado no MySQL que tem o campo adicional TenantID nas tabelas. Neste momento, diversas tabelas adicionais, incluindo uma para informações do arrendatário , que são usadas pelo Servidor Multi-Tenant, são criadas.

Figura 2. Criando o esquema do banco de dados MetaModel

(10)

cm as mesmas tabelas e campos, o aplicativo original pode continuar a interagir com o Banco de dados MetaModel exatamente da mesma maneira que fazia com o banco de dados MySQL, O banco de dados real subjacente ao modelo pode ser gerado com o campo adicional TenantID necessário para um aplicativo de múltiplos arrendatários.

O Banco de dados MetaModel é uma abstração apenas e não detém de fato nenhum dado: é um simples modelo. Consequentemente, quando o banco de dados real é gerado, não há motivo para que não possa ser gerado em qualquer Relational Database Management System (RDBMS) suportado. Isso pode ser útil para casos em que o ISV deseja alterar a pilha de tecnologia

escolhendo um RDBMS diferente, talvez DB2 para tirar vantagem de alguns recursos ou melhorar o desempenho para o aplicativo.

Etapa 2. Estender o processo de autenticação do usuário

Qualquer aplicativo SaaS de múltiplos arrendatários deve ter a habilidade de gerenciar as

informações de sessão necessárias para usuários autenticados, de modo que o arrendatário ao qual pertencem possa ser estabelecido. Há muitos métodos de autenticação para aplicativos;

consequentemente, qualquer aplicativo sendo convertido deve ser analisado e seus métodos e autenticação, entendidos.

A Etapa 1 mostrou como estabelecer uma tabela de arrendatário e adicionar uma tabela de usuário de modo que esse relacionamento possa ser mantido nos dados do aplicativo. A meta é implementar um método que estenda o processo de autenticação de usuário do aplicativo, de modo que, depois de um usuário ter efetuado logon, ele também é combinado com seu arrendatário correspondente e esse TenantID torna-se parte das informações da sessão.

Há muitas maneiras de fazer isso. Depende da implementação do aplicativo. Se for usado Tomcat como o contêiner do servlet do aplicativo, a autenticação gerenciada por contêiner pode ser aproveitada para iniciar uma regra de negócios que execute o Servidor Multi-Tenant para realizar uma busca do TenantID. do usuário associado. Alternativamente, um filtro do servlet pode ser empregado par detectar e então definir a variável local do encadeamento TenantID. Para este exemplo com jBilling, o aplicativo trata da autenticação diretamente validando com relação às suas tabelas de usuário. Portanto, o método usado para fornecer a autenticação aprimorada envolveu algumas mudanças simples ao código de autenticação para adicionar os processos para consultar as informações de arrendatário do usuário armazenadas nas novas tabelas.

Tendo um usuário autenticado e conhecendo o TenantID ao qual ele pertence, há informações suficientes para pode filtrar os dados de modo que apenas dados que pertencem àquele arrendatário possam ser acessados.

Etapa 3. Configurar a conexão do banco de dados

O Servidor Multi-Tenant da Corent é construído em uma arquitetura orientada a serviços que usa um Banco de dados MetaModel (descrito na Etapa 1). Esse MetaModel é usado como uma camada de abstração para modelar o banco de dados original do aplicativo e as comunicações do banco de dados do aplicativo são redirecionadas para a abstração do MetaModel, em vez de para a

implementação do banco de dados real. Isso é feito simplesmente reconfigurando a conexão JDBC do jBilling para um Banco de Dados MetaModel, em vez do banco de dados MySQL real. Para aplicativos que usam Hibernate, o dialeto Corent de Hibernate é configurado.

Como um resultado dessas alterações, as chamadas do banco de dados do aplicativo agora são direcionadas para o Banco de Dados MetaModel. Esses eventos SQL são interceptados pelo Corent Agile Controller™ e então passados para o ADBC™ (Agile DataBase Connector) da Corent. O ADBC pega a instrução SQL como foi enviada pelo aplicativo para o Banco de dados MetaModel e analisa-a, então adiciona os critérios de filtro para o TenantID do usuário cuja sessão enviou o SQL (por exemplo, onde TenantID = <myTenantID>). Isso garante que a segurança dos dados no

(11)

banco de dados compartilhado seja sempre estritamente mantida. Mesmo quando um aplicativo externo, como o ReportWriter conecta-se, os dados que ele pode ver ainda são restringidos àqueles adequados para o arrendatário em questão. Porque sabemos quem efetuou o login, não importa de qual aplicativo, sabemos qual arrendatário ele pertence e os filtros adequados são aplicados. Porque a manipulação das instruções SQL é feita após terem sido enviadas para o Banco de dados MetaModel e o arrendatário do usuário é conhecido, o Corent Agile Controller pode interceptar e realizar operações mais sofisticadas, incluindo procurar processos e configurações específicos do arrendatário. É, portanto, possível realizar ações específicas por arrendatário, mesmo substituindo uma conexão de banco de dados diferente, de modo que um arrendatário poderia usar um banco de dados DB2 embora todos os outros estejam usando um banco de dados MySQL. Ou um

arrendatário poderia ter manipulação de SQL adicional para restringir os dados que poderia recuperar aos registros inseridos não mais que 90 dias antes. Todas essas personalizações por arrendatário podem ser feitas através do Agile Rules Engine™ integrado no Servidor Multi-Tenant sem quaisquer alterações ao código do aplicativo original.

Servidor Multi-Tenant da Corent

O Servidor Multi-Tenant da Corent possibilita que nossos clientes transformem rapidamente aplicativos da Web de um único arrendatário existentes em soluções SaaS totalmente com múltiplos arrendatários compatíveis com nuvem sem reescrever o aplicativo. A Corent oferece a abordagem mais eficiente e com custo reduzido para múltiplos arrendatários. Essa solução de middleware de plug-in a múltiplos arrendatários fornece uma solução segura e escalável que reduz drasticamente o custo da entrega de serviços.

Você tem a flexibilidade de escolher sua pilha de tecnologia preferida, permitindo o uso do sistema operacional, banco de dados e servidor de aplicativo preferido. Com a arquitetura flexível do Servidor de Múltiplos Usuários, é possível escolher como implementar seu aplicativo, internamente ou em qualquer tipo de nuvem. Isso possibilita a implementação de aplicativos SaaS como serviços públicos ou Private SaaS™ que fornece serviços a um público limitado, como uma grande empresa com divisões que se tornam arrendatários.

O Servidor Multi-Tenant vem com um SaaS-Cockpit™ para possibilitar o fornecimento, gerenciamento e monitoramento dos clientes SaaS, e com SaaS-Factory™ para possibilitar customizações por arrendatário e aumento do seu aplicativo SaaS. Com o conjunto de soluções da Corent, a transformação SaaS para aplicativos pode ser drasticamente acelerada.

Corent e IBM® estão oferecendo no momento a um número limitado de candidatos qualificados uma transformação sem custos de Prova de Conceito, que converterá um aplicativo da Web do ISV em uma solução SaaS de

múltiplos arrendatários operando na Nuvem SBDT da IBM, e permitem que o ISV faça um test drive da solução SaaS resultante.

(12)

Figura 3. A estrutura de personalizações por arrendatário

Toda a conversão do aplicativo jBilling foi realizada com apenas algumas pequenas alterações ao aplicativo, principalmente relacionadas a aprimorar a autenticação para incluir informações do arrendatário nas informações da sessão e para alterar a conexão do banco de dados para apontar para o servidor de Múltiplos Arrendatários. É possível ver o resumo de alterações do jBilling em um dos seguintes:

• Aplicativo original

• Número de arquivos de origem: 897 (Java e jsp) • Total de linhas de código: 76.621

• Aplicativo convertido

• Número de arquivos de origem adicionados: 2 (modelo padrão) • Linhas de código modificadas: menos de 100

• Alterações da lógica de negócios do aplicativo: zero

A conversão do jBilling levou menos de uma semana, incluindo toda a análise e preparação para determinar onde o código precisava ser modificado. Muitas das alterações foram simples alterações de uma linha repetitivas em uma série de código Java para acesso do JDBC, o que é desnecessário se uma camada de persistência de banco de dados como Hibernate for usada.

Etapa 4. Implementar o novo aplicativo SaaS de múltiplos arrendatários para a nuvem

O SaaS-Factory agora pode ser usado para implementar um aplicativo SaaS para um servidor designado, incluindo servidores na nuvem.

Depois de selecionar um servidor para o aplicativo e o banco de dados, o banco de dados de destino é gerado (como um banco de dados MySQL em um servidor Windows® para nosso aplicativo jBilling) e o aplicativo do Servidor Multi-Tenant totalmente configurado é implementado como um conjunto de arquivos .WAR para o servidor de aplicativos selecionado. O Servidor Multi-Tenant funciona com qualquer contêiner J2EE moderno e foi certificado para o WebSphere Application

(13)

Server.

O aplicativo implementado agora é capaz de lidar com múltiplos arrendatários. Entretanto, o aplicativo original não terá uma interface de administração e gerenciamento para gerenciar arrendatários ou monitorar um aplicativo de múltiplos arrendatários.

O SaaS-Factory também pode gerar e instalar um aplicativo parceiro chamado SaaS-Cockpit™ que fornece esses serviços de múltiplos arrendatários básicos. Tem acesso ao mesmo MetaModel Database que um aplicativo principal e tem telas de administração para fornecer arrendatários, atribuindo contas de Administradores de Arrendatários e configurando os parâmetros básicos das diversas configurações de aplicativo por arrendatário que estão disponíveis. Há também instalações de administração para monitorar e relatar arrendatários e seus usuários. Uma vez que uma das características comuns de aplicativos SaaS é a necessidade de rastrear assinaturas e faturamento de arrendatários, estão disponíveis instalações para fazer faturamento ou integração com sistemas de faturamento externos.

Figura 4. A estrutura para implementar seu novo aplicativo SaaS para a nuvem

Esse nível de implementação é bastante básico no que concerne implementações SaaS. As características dos aplicativos permanecem intactas após tipos padrão de cenários de

implementação e conversão, incluindo o uso de ferramentas de gerenciamento na nuvem para criar modelos e propagar instâncias do aplicativo, podem ser usadas para implementar uma arquitetura operacional que atenda as necessidades do aplicativo para escalabilidade, elasticidade, resiliência e redundância.

Um aplicativo SaaS típico pode ter um conjunto de servidores de aplicativos acessados através de um balanceador de carga e conectados a um servidor de banco de dados. O servidor do banco de dados em si pode ser implementado como um cluster com os servidores de banco de dados múltiplos fornecendo redundância e escalabilidade.

O IBM DB2 oferece diversas tecnologias e configurações que podem ser usadas para obter resiliência e tempos de recuperação garantidos, bem como permitindo que a carga no banco de dados seja distribuída.

(14)

• As configurações do DB2 HADR (High Availability Disaster Recovery) podem fornecer tanto resiliência de disponibilidade quanto algum balanceamento de carga através do uso do modo secundário como um banco de dados somente leitura.

• A tecnologia IBM pureScale e o Tivoli System Automation (TSA) permite um ambiente de banco de dados em cluster com múltiplos nós que compartilham a carga de processamento, mas esses têm mais restrições sobre as configurações do sistema operacional e hardware. A tendência na disponibilidade de banco de dados e failover está se tornando mais sofisticada para aplicativos SaaS porque o número de clientes/arrendatários afetados por quaisquer indisponibilidade é maior que aquele no software no local do cliente tradicional (Figura 5).

(15)

A tendência é para recursos que possibilitem que o aplicativo execute continuamente mesmo através de reorganizações offline de dados, evoluções de esquema, atualizações de versão e variações de carga pesada. A tecnologia pureScale da IBM está migrando do mundo do z System para AIX® e Linux® e possibilitando o tipo de manipulação de capacidade e tempo de atividade anteriormente reservados para ambientes de mainframe dedicados.

Conclusão

A evolução do segmento de mercado da tecnologia informação para SaaS está a caminho e como você pode ter suposto, já está começando a causar algumas mudanças importantes na paisagem. A computação em nuvem está crescendo a taxas acima de qualquer outra onda de TI e SaaS é o condutor para esse crescimento. Essa transição está forçando as empresas a repensar a organização de negócios e desenvolver novas maneiras de pensar sobre a entrega de serviços em um mundo de TI centrado em nuvem. Para fornecedores de software, há uma urgência crescente de entender, preparar-se para e realizar a transição para que não sejam deixados para trás no rastro de poeira digital da história.

O modelo SaaS-on-a-cloud diferencia-se do modelo tradicional de fornecedores de software tanto em considerações técnicas quanto de negócios. Essas diferenças fazem a transição para SaaS um empreendimento de maior risco para ISVs. Para reduzir o risco e acelerar o tempo para

(16)

comercializar, os ISVs podem tirar vantagem de tecnologias, produtos e parceiros comprovados para auxiliar na transição.

Agradecimentos

Contribuições, ideias e sugestões e revisões para este artigo foram generosamente fornecidas por Mike Oliver, Rob Brown, Mark Joncich, Kaiser Saeed e Feyzi Fatehi; e assistência de edição de Aimee Dean. Muito obrigado.

Sobre o autor

Com um histórico do desenvolvimento de software, arquitetura, operações globais e gerenciamento para empresas na lista da Fortune 500 Scott Chate da Corent Technology está experimentando o outro lado do setor de TI em uma organização empreendedora com tecnologia inovadora. Através de desenvolvimento de produto e consultoria em gerenciamento na Oracle, TransCanada PipeLines, IBM e Mercer, ele criou e implementou soluções inovadoras usando tecnologias emergentes para entregar eficiência, gerenciar riscos e possibilitar oportunidades.

(17)

Aplicativos de Internet rica que usam o ZK

Uma estrutura Ajax de software livre

Resumo: ZK, uma estrutura de software livre de Asynchronous JavaScript + XML (Ajax) escrita em código Java™, permite criar um aplicativo de Internet rica habilitado para Web 2.0, sem que seja necessário escrever uma única linha de código JavaScript. As estruturas típicas de Ajax, como Dojo, têm bibliotecas JavaScript que expõem determinadas APIs para a realização de chamadas baseadas em Ajax. ZK, por outro lado, usa um definição meta baseada em XML para definir a interface do usuário. A tradução para o código HTML ocorre então quando essa página é solicitada pelo cliente. Este artigo apresenta você ao ZK e fornece um exemplo real do seu uso sendo

executado em Apache Tomcat e conectado a um banco de dados MySQL.

Introdução

É possível pensar no ZK como sendo análogo ao Ajax, mas sem JavaScript. Ele é composto por um mecanismo baseado em Ajax e acionado por eventos, um rico conjunto de componentes XHTML e XUL e uma linguagem de marcação chamada ZUML, que é usada para criar interfaces do usuário ricas em recursos. A lógica de negócios pode ser escrita por meio de código Java diretamente integrado em seu aplicativo, e que é acionado com base em eventos ou componentes. A recurso mais poderoso do ZK é seu rico conjunto de bibliotecas de controle para o desenvolvimento de interfaces do usuário. Parece interessante?

Primeiro, deixe-me descrever os itens anteriores com um pouco mais de detalhes:

• XHTML: Extensible Hypertext markup language, ou XHTML, é um combinação de HTML e XML. O XHTML acrescenta a capacidade e a flexibilidade do HTML à extensibilidade do XML. A Listagem 1 fornece um exemplo de código XHTML.

Listagem 1. Código de exemplo XHTML

<?xml version="1.0" encoding="iso-8859-1"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">

<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Hello ZK</title> </head> <body> <h1>Introducing XHTML</h1> </body> </html>

• XUL: XML User Interface language, ou XUL, (pronuncia-se "Zul") é uma linguagem de marcação desenvolvida pelo Mozilla, e um aplicativo XML usado para descrever interfaces gráficas do usuário. O XUL tem a capacidade de criar elementos como controles de entrada, barras de ferramentas, menus, árvores, atalhos de teclado e assim por diante. A Listagem 2 mostra um exemplo de código XUL.

(18)

Listagem 2. Código de exemplo XUL

<?xml version="1.0"?>

<?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <window id="main" title="My App" width="300" height="300"

xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <caption label="Hello World"/> </window>

• ZUML: ZK User Interface Markup Language, ou ZUML, é usado para definir a interface do usuário rica. Como é baseado em XML, cada elemento descreve o componente e o atributo descreve o valor do componente. A Listagem 3 dá um exemplo de código ZUML.

Listagem 3. Código de exemplo ZUML

<window title="Hello ZUML" border="normal"> Hello World! </window>

Obtendo o ZK

É bastante fácil obter e instalar o ZK. A documentação sobre as bibliotecas e sobre a configuração da estrutura de pastas foi muito bem definida no site de documentação do ZK. (Consulte Recursos

para encontrar um link.) Então, obter o ZK, incluindo executar o aplicativo hello world, deveria ser simples.

Por que ZK?

ZK é uma implementação direta do Ajax — ou, em outras palavras, um modelo centralizado no servidor. É diferente de outras estruturas que o expõem aos complexos detalhes das realizações de chamadas Ajax. Além disso, as chamadas Ajax exigem amplo uso e conhecimento de JavaScript para a manipulação de Document Object Model (DOM) no navegador (cliente) e para a

sincronização de dados durante a comunicação cliente/servidor. Com o ZK, você fica protegido dessas complexidades e pode se concentrar na lógica de negócios. Dentre outros benefícios do ZK estão:

• Rico conjunto de interfaces do usuário • Acesso ao serviço da Web

• Ligação de dados do componente

• Linguagem de marcação simples mas poderosa, o ZUML

• Alta capacidade de manutenção e extensão porque não há código do cliente • Alta usabilidade

• Maior produtividade para o desenvolvedor ZK em ação

Para compreender como o ZK funciona, vamos ver um exemplo real. Este exemplo é o aplicativo Manage Customer, por meio do qual o usuário pode executar várias operações como adicionar um novo cliente, editar dados do cliente e exclusões recuperáveis de entradas do cliente no banco de dados. Mas, antes de começar com o código, explicarei algumas telas da interface do usuário que foram geradas usando o ZK. Após tratar das telas, descreverei a arquitetura do ZK, que é um mecanismo subjacente para a geração dessa notável interface do usuário. Por fim, descreverei os detalhes do nível de código e os parâmetros de configuração usados para este aplicativo.

(19)

Figura 1. Página de índice do aplicativo Manage Customer

A Figura 1 mostra a lista de clientes registrados no aplicativo. A lista é mostrada como uma grade, com colunas para um ID, o nome do cliente, a data ativa e o sinalizador de exclusão. Os dados na grade pode ser classificados (em ordem crescente ou decrescente) clicando no botão ao lado dos nomes das colunas. A classificação é ativada para as colunas ID (int), Name (String) e Active Date (Data). Posteriormente neste artigo, explicarei como customizar a classificação usando um objeto Comparator. A paginação também é ativada para este aplicativo, como mostrado na parte inferior da tela. A página está habilitada para mostrar 5 registros por vez, junto com a capacidade de mover-se para a próxima página ou diretamente para uma página específica.

Figura 2. Barra de menus na parte superior

A Figura 2 mostra a barra superior do aplicativo Manage Customer. Isso é implementado usando o widget de barra de menus do ZK. Ele inclui a opção de registrar um novo cliente e sair do

aplicativo.

Agora que você viu alguns fluxos do usuário do aplicativo de exemplo, vamos passar aos detalhes da arquitetura do ZK.

Aspectos internos do ZK

Um aplicativo do ZK comporta-se de forma semelhante a um aplicativo desktop pelo fato de as atividades do usuário automaticamente dispararem eventos no servidor por meio do Client Engine. Em contrapartida, os componentes em execução no servidor atualizam a visualização para que haja correspondência com o cliente. O cliente (navegador), age simplesmente como uma visualização, enquanto o aplicativo é executado no servidor e tem total acesso a recursos como banco de dados, serviços da Web etc. Consequentemente, as preocupações com segurança são mínimas.

(20)

Há três componentes principais em uma estrutura ZK. Como mostrado na Figura 3, esses componentes são o ZK Client Engine, ZK Loader, e o ZK Update Engine.

• ZK Client Engine: Este é o lado do cliente do ZK, que envia solicitações ao servidor para obter respostas correspondentes do ZK. Essas respostas, por sua vez, são usadas pelo mecanismo para atualizar o DOM no navegador.

• ZK Loader: Este componente gera uma página HTML com base em um URL que é solicitado pelo cliente.

• ZK Update Engine: Também conhecido como Asynchronous Update (AU) Engine. Este componente é responsável por receber a solicitação Ajax e atualizar os atributos

correspondentes no componente ZK para que o Client Engine possa atualizar a visualização no navegador.

Figura 3. A arquitetura do ZK

Mecanismo do fluxo, conforme descrito na Figura 3:

• O ZK Loader serve o HTML, incluindo o CSS, o JavaScript e assim por diante, com base no URL solicitado pelo cliente. Isso inclui o ZK Client Engine, que é responsável por monitorar eventos do lado do cliente e por enviar e receber as Solicitações ZK e as Respostas ZK para o servidor.

• O Client Engine aciona eventos com base nas ações do usuário, como onChange, onClick etc.

• Esses eventos chamam o ZK Update Engine, que atualiza as propriedades dos componentes ZK e responde ao Client Engine.

• Após receber esta resposta, o Client Engine atualiza a árvore DOM no navegador para que o usuário possa obter a visualização atualizada.

Aplicativo Manage Customer usando o ZK

Em seguida, passarei a descrever os detalhes da criação de um aplicativo de exemplo para gerenciar clientes. Uso o IDE Eclipse para demonstrar a criação do aplicativo, mas qualquer IDE que você escolher deverá funcionar.

A ideia básica é criar um projeto de aplicativo da Web dinâmico e apontá-lo para o tempo de execução do servidor do aplicativo que, neste caso, é o tempo de execução do Apache Tomcat. Após a configuração do novo projeto e do tempo de execução, replique a estrutura de pastas conforme mostrado na Figura 4.

(21)

Figura 4. A estrutura do diretório

A estrutura do diretório do aplicativo Manage Customer segue a mesma estrutura de diretório padrão descrita na Figura 4.

Observe que o núcleo dos arquivos para este aplicativo está contido na pasta WebContent. Na pasta WebContent temos os seguintes subdiretórios:

• META-INF – Este contém as informações credenciais do banco de dados para conexão com o banco de dados MySQL.

• WEB-INF – Este inclui a pasta da biblioteca que contém os arquivos JAR ZK necessários para a execução do aplicativo. O diretório também inclui o arquivo web.xml, que descreve a origem de dados.

• Além disso, todos os arquivos zul e HTML associados estão contidos dentro da pasta

WebContent. Esses arquivos atuam como a parte de visualização do aplicativo, fornecendo o conteúdo dinâmico e estático ao aplicativo da Web.

O arquivo de exemplo zkManageCustomer.zip (consulte a seção Download) contém a versão compactada do aplicativo. Também estão incluídos os arquivos de metadados exigidos pelo Eclipse para que seja possível a importação direta para o IDE.

A perspectiva da plataforma Java 2, Enterprise Edition (J2EE) no Eclipse tem uma guia do servidor que, quando clicada com o botão direito do mouse, mostra ao usuário a opção de criar um novo servidor. Esse servidor pode ser usado para gerenciar o servidor de aplicativos a partir do IDE do Eclipse.

Após a configuração do novo servidor, os recursos recentemente criados precisam ser configurados no servidor. A configuração desse servidor implementa os recursos que são criados durante o curso do desenvolvimento.

Configuração do Tomcat e do MySQL

(22)

não deve encontrar problemas ao executá-lo em outro servidor de aplicativos Java, incluindo o WebSphere. Uma vez que o exemplo usa JDBC, deve funcionar com qualquer banco de dados SQL suportado, como o DB2 Express-C, com apenas pequenas mudanças no código de conexão.

Para conectar o Tomcat ao banco de dados MySQL, é necessário definir uma referência de recurso. Este elemento especifica o nome da referência de conexão fábrica de um gerenciador de recursos. Nesse caso, seria a conexão do banco de dados especificada por jdbc/mysql, que é do tipo

javax.sql.DataSource.

Listagem 4. Conexão fábrica do gerenciador de recursos no web.xml

. . . <resource-ref> <description>DB Connection</description> <res-ref-name>jdbc/mysql</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> . . .

Também é preciso definir um recurso de conexão no arquivo context.xml da pasta

WebContent/META-INF. Esse arquivo contém propriedades como nome do driver, nome da jndi, nome do usuário, senha, tipo de dados e o URL.

Listagem 5. Definição do contexto em context.xml

. . . <Context>

<Resource driverClassName="com.mysql.jdbc.Driver"

maxActive="4" maxIdle="2" maxWait="5000" auth="Container" name="jdbc/mysql" password="" type="javax.sql.DataSource" url="jdbc:mysql://localhost:3306/customer" username="root"/> </Context>

. . .

O banco de dados do cliente tem uma única tabela que pode ser criada executando o script mostrado na Listagem 6.

Listagem 6. Script para criar o banco de dados

use customer;

CREATE TABLE `customer` (

`ID` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `date` date DEFAULT NULL,

`deleted` tinyint(1) DEFAULT '0', PRIMARY KEY (`ID`)

);

Ajustando o aplicativo para funcionar com o DB2

Para conectar o Tomcat a um banco de dados DB2-Express C ou a outro banco de dados da variante DB2, a configuração é muito semelhante àquela descrita para o MySQL. Aqui está um exemplo mostrando a configuração da conexão fábrica de um gerenciador de recursos em web.xml: . . .

(23)

Listagem 7. Conexão fábrica do gerenciador de recursos em web.xml . . . DB Connection jdbc/db2db javax.sql.DataSource Container . . .

Para a definição do contexto, veja um típico exemplo: . . . Listagem 8. Definição do contexto

. . .

maxActive="4" maxIdle="2" maxWait="5000" auth="Container" name="jdbc/db2db" password="" type="javax.sql.DataSource"

url="jdbc:db2://localhost:(port)/customer" username="db2admin"/> . . .

Resumo do aplicativo

Uma breve descrição do aplicativo foi apresentada anteriormente neste artigo. O aplicativo Manage Customer oferece as funções de:

• Página do console que permite operações do usuário, incluindo uma visualização de todos os clientes

• Adição de novos clientes • Edição dos clientes existentes

• Possibilidade de exclusão de clientes (exclusão recuperável)

A Figura 5 mostra a página de console do aplicativo. A visualização padrão mostra a lista de clientes no banco de dados.

Figura 5. A tela do console

A tela do console mostra uma lista de todos os clientes registrados. Além da lista de clientes, o usuário também tem a possibilidade de classificar os dados com base no ID ou no Nome. O arquivo index.zul tem vários atributos, como borderlayout, menubar, menu e

(24)

menupopup, sendo que todos definem a aparência e os recursos do aplicativo. Listagem 9. Arquivo index.zul

<menuitem label="Register New Customer"> <attribute name="onClick"><![CDATA[

Window win = (Window) Executions.createComponents("addCustomer.zul", null, null); win.doModal();

win.setTitle("Enter Customer Data"); win.setClosable(true);

win.setMaximizable(true); ]]></attribute>

</menuitem> <menuseparator />

</menu>

</menubar>

Conforme mostrado na Listagem 9, menubar é definido com o rótulo do menu para o registro de novos clientes. Quando este menu é clicado, (onClick) o objeto Window é instanciado por meio do objeto Executions usando outro zul chamado addCustomer. Também é definido o atributo para fazer a caixa de diálogo modal, closable e assim por diante. Além disso, é incluído um menu de saída que fecha o aplicativo. O menubar, juntamente com os atributos definidos, fornece a este aplicativo a aparência e os recursos de um aplicativo rich client.

A Listagem 10 mostra como a tabela é preenchida usando um elemento listbox, onde é definido um modelo no qual o elemento da tabela é preenchido.

Listagem 10. Elemento da caixa de listagem de exemplo definindo a tabela

</listhead>

A função de paginação pode ser ativada usando o atributo mold de listbox. Além disso, a classificação baseada nos cabeçalhos das colunas pode ser definida ativando auto no atributo de classificação de listheader. O objeto myList é uma lista de objetos Customer, que são compostos por atributos como id,name, date e o deleted flag do Cliente. O serviço retorna esta lista que, em seguida, é iterada pelo ZK usando "each =myList". Os rótulos listcell

(25)

mostram então cada atributo do objeto customer na listbox.

Além disso, para habilitar a função de edição, é anexado um método showEdit ao evento onClick.

A caixa de diálogo de registro do cliente é implementada como uma grade com valores obrigatórios para o Nome do cliente e os Dados.

Listagem 11. Código da grade da caixa de diálogo do cliente.

<row>

<row>

<row>

</rows>

</grid>

As restrições obrigatórias para a caixa de diálogo são especificadas usando "no empty" como atributo da restrição. O ZK também oferece a capacidade de definir restrições customizadas. Quando o botão Save é clicado, é anexado um método Java chamado submit() a este evento. Este método submit() recebe o nome e o valor de data fornecidos pelo usuário e os define em um objeto customer recentemente criado. Este objeto é então passado ao serviço para adição ao banco de dados. A Listagem 12 mostra este código.

Listagem 12. Código Java para o botão Save

void submit() throws Exception { Customer cust = new Customer();

cust.setName(customerName.getValue()); java.util.Date utilDate = date.getValue();

java.sql.Date sqlDate = new java.sql.Date(utilDate.getTime()); cust.setDate(sqlDate);

com.test.services.CustomerService custSvc = new com.test.services.CustomerService(); custSvc.addCustomer(cust);

Executions.getCurrent().sendRedirect("index.zul"); addCustomerWin.detach();

(26)

Figura 6. Registrar cliente

A Figura 7 mostra uma tela para editar o nome ou a data do cliente, junto com a opção de exclusão recuperável.

Figura 7. Tela Editar/Excluir

O mecanismo de edição é muito semelhante à definição do código de registro do cliente. Informe novos valores de nome, data e o sinalizador de exclusão para que o serviço de atualização atualize o registro no banco de dados. Se desejar configurar ajuda adicional, é possível usar o código na Listagem 11 para criar um elemento pop-up.

Listagem 13. Código para o elemento pop-up

<row>

</hbox>

<html>Checking this box will enable soft delete of the record.</html> </popup>

</row>

Ferramentas de desenvolvimento para ZK

Os maiores benefícios do ZK são suas ferramentas. Um exemplo é o ZK-Studio (um plug-in do Eclipse), que é usado como um ambiente de desenvolvimento integrado. Ele inclui recursos como ZUL Editor, ZUL Visual Editor, ZK Style Designer e o DB Form Builder. A Figura 8 mostra o ZUL

(27)

Visual Editor, que foi usado para a criação deste exemplo de projeto. Figura 8. ZUL Visual Editor

Resumo

Este artigo descreveu os recursos do ZK, uma estrutura Ajax de software livre escrita em código Java. O artigo usou um simples exemplo real executado em Apache Tomcat e conectado a um banco de dados MySQL. A estrutura ZK tem um rico conjunto de componentes, linguagem de marcação, poderosas ferramentas de desenvolvimento e uma excelente documentação, além de ser um

software livre e uma estrutura Ajax acionada por eventos. Devido a tudo isso, o ZK está se tornando uma opção popular para o desenvolvimento de aplicativos de Internet rica de baixo custo.

Download da Aplicação : http://www.ibm.com/developerworks/apps/download/index.jsp? contentid=469637&filename=zkManageCustomers.zip&method=http&locale=pt_BR

Explore o modelo de programação CDI no ZK

Implemente um aplicativo simples

Resumo: Java™ Specification Request (JSR) 299: Contextos e Injeção de Dependência (CDI) para a plataforma Java EE definem um conjunto poderoso de serviços. Os serviços incluem injeção de dependência de tipo seguro de componentes Java EE e um modelo de notificação de eventos para permitir a interação entre os componentes, o que simplifica o acesso aos serviços do Java EE a partir da camada da Web Java EE. Essencialmente, qualquer estrutura de terceiros usada na camada da Web Java EE pode aproveitar os serviços de CDI usando um mecanismo de extensão portátil de CDI. Este artigo estende um aplicativo de amostra do artigo "Aplicativos de Internet rica que usam o ZK" e explica como modificar um exemplo real usando a estrutura ZK e sua integração com serviços poderosos de CDI.

ZK, uma estrutura de JavaScript assíncrono e XML (Ajax) escrita em código Java, permite a composição de aplicativos de internet ricos, preparados para Web 2.0 sem a composição de uma única linha de código JavaScript.

(28)

Introdução

O ZK é análogo ao Ajax sem JavaScript. É uma estrutura poderosa composta de um mecanismo acionado por eventos baseado em Ajax, um conjunto rico de componentes XHTML e XUL e a linguagem de marcação ZUML para criação de interfaces com o usuário repletas de recursos. Neste artigo, aprenda sobre Contextos e Injeção de Dependência (CDI) para o modelo de programação da plataforma Java EE em relação à estrutura ZK. Este artigo é desenvolvido com base no aplicativo de exemplo em Aplicativos de Internet rica que usam o ZK: Uma estrutura Ajax de software livre", um artigo que explora o poder do ZK. Usando ZK e CDI, é possível estender o aplicativo de exemplo real e detalhado para o gerenciamento de clientes.

É possível fazer o download do código de origem do aplicativo neste artigo. JSR-299 e CDI

Java Specification Request (JSR) 299, ou CDI Java, é um padrão Java para gerenciamento de ciclo de vida de injeção de dependência e contextual. Através do padrão, um conjunto de serviços que facilitam e limpam o desenvolvimento de aplicativos é definido. Os serviços fornecem:

• Interação dos objetos através de um mecanismo de notificação de eventos • Injeção de dependência de tipo seguro

• Métodos de ciclo de vida para objetos stateful ligados aos contextos • Um interceptor "decorator" para conectar o interceptor aos objetos

• Uma interface com o provedor de serviço (SPI) para desenvolver extensões móveis

Como o CDI enfatiza o loose coupling e uma linguagem fortemente tipada, o bean não precisa estar ciente de certos aspectos como implementação, modelo de encadeamento ou ciclo de vida. Esses aspectos podem variar com base na implementação, sem afetar o cliente de forma alguma. O loose coupling facilita a manutenção do código e o torna extensível.

ZK e CDI

O CDI do ZK, fornecido pela estrutura ZK, fornece integração contínua com o CDI para expor serviços de CDI na estrutura ZK. Ele permite aos desenvolvedores corporativos a integração de aplicativos dirigidos por CDI, com um frontend Ajax abrangente e poderoso fornecido pelo ZK. O uso conjunto do CDI e do ZK facilmente preenche a lacuna entre a camada da Web do Java EE e o Java EE.

A extensão de CDI do ZK permite o uso contínuo dos recursos de CDI no modelo de programação ZK. Além dos recursos de CDI integrados, as extensões de CDI do ZK fornecem os seguintes recursos para facilitar o desenvolvimento.

Resolvedor de variável customizada/resolvedor EL

Resolve beans gerenciados por CDI dentro da tag <zscript />, uma expressão EL ( $ {...}) e uma expressão de ligação de dados com anotações de ZK (@{…}) por seu nome EL.

Escopos customizados de ZK

Além dos escopos de CDI integrados (Session, Request, Application e Conversation), essa extensão fornece mais cinco escopos de ZK: Desktop, Page, Execution, IdSpace e

Component.

Componentes de ZK como beans gerenciados

Permitem a injeção de componentes de ZK em beans gerenciados, como criadores ZK. Manipuladores de evento de UI usando anotação customizada de ZK e modelo de notificação de eventos fornecido por CDI

Permitem a anotação de qualquer método com anotação customizada de ZK e a transformação para um método de manipulador de eventos

(29)

A extensão de CDI do ZK é baseada no Weld, que é uma implementação de referência da

especificação JSR-299 que define CDI (consulte a seção Recursos para obter mais informações).

Usando ZK com CDI

O exemplo simples a seguir mostra como acessar um bean gerenciado por CDI a partir de um arquivo ZUL. (A extensão do arquivo .zul é para arquivo de interfaces com o usuário do ZK.) No contexto do CDI, um bean gerenciado, ou simplesmente bean, é um componente Java EE que pode ser injetado em outros componentes, associados com um contexto, ou acessado através de

expressões EL.

O exemplo simples de HelloWorld na Listagem 1 mostra como um bean gerenciado é acessado através da expressão EL em um arquivo ZUL. Primeiro, defina a classe HelloWorld com um único campo de cadeia de caractere chamado text e o método getter getText(). De acordo com a especificação do CDI, a presença de um construtor padrão no-arg torna a classe elegível para ser um bean gerenciado. Para fazer referência ao bean gerenciado HelloWorld através de uma

expressão unificada EL, ele precisa ser anotado com o qualificador @javax.inject.Named. Qualquer nome EL pode ser dado ao bean gerenciado fornecendo um membro de valor do

qualificador @Named . Se não for especificado, o nome EL será definido como padrão para o nome de classe não qualificado da classe de bean após a conversão do primeiro caractere para minúscula. No exemplo, o HelloWorld é definido como padrão para EL helloWorld.

Listagem 1. Acesse um bean gerenciado

@Named

@SessionScoped

public class HelloWorld implements Serializable { private String text = "HelloWorld";

public String getText() { return text; }

}

O código ZUL na Listagem 2 acessa o bean HelloWorld usando seu nome EL padronizado, helloWorld.

Listagem 2. Nome EL padrão

<?variable-resolver class="org.zkoss.zkplus.cdi.DelegatingVariableResolver"?> <window title="ZK + CDI: Hello World" width="300px" border="normal">

My CDI-injected bean says: ${helloWorld.text} </window>

O ZK fornece uma diretiva de resolvedor de variável <?variable-resolver ?> . É possível usá-la para especificar uma classe de resolvedor a ser usada pelo avaliador EL do ZK (${...}), o componente de ligação anotado do ZK (@{...}) e o interpretador <zscript> para resolver variáveis desconhecidas.

Um recurso da extensão de CDI do ZK é um resolvedor EL customizado chamado