Avaliando o Desempenho de um Design de Mecanismo de Transação. Richard Drayton, FiS e Arvindra Sehmi, Microsoft EMEA páginas 19 33

Transcrição

1 Escolhendo a Arquitetura da Camada de Apresentação Correta David Hill, Microsoft Corporation páginas Avaliando o Desempenho de um Design de Mecanismo de Transação Richard Drayton, FiS e Arvindra Sehmi, Microsoft EMEA páginas Razorbills Maarten Mullender, Microsoft Corporation páginas Information Bridge Network Ricard Roma i Dalfó, Microsoft Corporation páginas Heurística de Alinhamento da Arquitetura Empresarial Pedro Sousa, Carla Marques Pereira e José Alves Marques, Link Consulting, SA páginas Ferramentas da Próxima Geração para ODD Oren Novotny, Goldman, Sachs & Co páginas JOURNAL 4 JOURNAL4 JORNAL DE ARQUITETOS DA MICROSOFT OUTUBRO DE 2004 A NOVA PUBLICAÇÃO PARA ARQUITETOS DE SOFTWARE Caro Arquiteto Os avanços nos padrões da indústria e tecnologia que permitem a SOA (arquitetura orientada por serviços) estão causando também uma mudança nos padrões na arquitetura do cliente. Particularmente, essas mudanças podem ser consideradas um progresso, porém no todo elas se reúnem para revolucionar a arquitetura do cliente. Historicamente, os aplicativos no cliente estavam fortemente vinculados a um sistema específico de back-end. Mais precisamente, a função principal do aplicativo no cliente era expor a funcionalidade e os dados de um sistema específico de back-end para os usuários. Apesar de ser possível criar clientes que podiam interagir com vários sistemas de back-end, fazer isso era extremamente complexo e raramente efetuado. A SOA mudou tudo isso. Em uma SOA, a funcionalidade e os dados dos sistemas de back-end são expostos como serviços (ou iniciados por serviços de camada intermediária da Web) e esses serviços são consumidos por aplicativos clientes. O aplicativo cliente não está mais vinculado fortemente a um sistema de back-end único. As empresas têm agora a liberdade, e os meios, para radicalmente criar, de forma eficiente, novos aplicativos cliente que realmente otimizam a produtividade do usuário e o fluxo da linha de produção. O design obrigatório dos aplicativos no clientes mudou dos modelos centrais de sistemas de conexão da população de usuários em geral para sistemas específicos, para modelos centrais de usuários que fornecem aos usuários acesso transparente a todos os serviços que necessitam para efetuar os respectivos trabalhos ou tarefas. Se alguém ampliar esse modelo, integrando continuamente esses serviços com os vários recursos dos aplicativos de desktop, poderá alcançar algo que redefine os padrões para excelência operacional. Além disso, ao fornecer tratamento igual aos modelos de sistemas e de usuários em um modelo central de serviço convergente, poderá melhorar significativamente a integração entre eles com interoperação funcional contínua. Nesta edição do JOURNAL, iniciamos a interessante jornada para explorar as perspectivas desses diversos modelos. Aproveite! Chris Capossela Vice-Presidente, Information Worker Business Group, Microsoft Corporation

2 Editorial Por Arvindra Sehmi Caro Arquiteto Bem-vindo à edição de outono do JOURNAL. Passaram-se vários anos desse que o.net alcançou as ruas e criou impulso dentro da visão da Microsoft de conectar pessoas e processos a qualquer momento, em qualquer lugar e de qualquer dispositivo. Essa visão foi criada em implementações de padrões de serviços da Web no.net e na ampla adoção na comunidade técnica. Ambos requisitos prévios foram alcançados, não apenas no.net, mas também em outras ofertas de plataformas de fornecedores. Isso trouxe um melhor entendimento de novas possibilidades de arquiteturas de aplicativos, especificamente a SOA, que, posso afirmar, é a expressão principal desse entendimento. Estamos observando a adoção de idéias de arquiteturas que suportam a SOA em várias áreas da solução de sistemas em geral. Isso não está limitado apenas à camada de aplicativos em virtude da produtividade resultante e dos benefícios comerciais. Por exemplo, a integração, a interoperabilidade, o gerenciamento, as operações, a análise, a segurança, os dados e os aspectos de interface do usuário das soluções de sistemas podem ser visualizados separadamente a partir da perspectiva de orientação dos serviços. Um fenômeno denominado SOC (Convergência Orientada a Serviço) está sendo observado, pelo menos conceitualmente, entre os criadores de arquitetura com os quais estive trabalhando ultimamente. 1 Nesta edição do JOURNAL existem três artigos que acrescentarão algum crédito a essa forma de pensar, especialmente porque ela se refere à função dos consumidores de serviços na SOC e particularmente à função de smart clients e interfaces dos usuários orientadas por tarefas. Começamos esse artigo com David Hill, um membro da equipe da Microsoft Architecture Strategy, que contrasta as abordagens de arquiteturas de thin client e smart client e fornece orientação para escolher entre elas. David nos mostra que smart clients são rich clients aperfeiçoados, aproveitando novas tecnologias e técnicas para evitar os imprevistos dos aplicativos rich clients tradicionais, enquanto alinham-se ordenadamente com os princípios dos modelos do sistema central de serviços convergentes. Ricard Roma i Dalfó da divisão da Microsoft Office discute em seu artigo uma nova abordagem orientada por metadados pra criar consumidores de serviços orientados por tarefas diretamente nos aplicativos Microsoft Office. A IBF (Information Bridge Framework) vai além de um metadado WSDL de serviço, automatizando a construção de interfaces de usuários a partir das descrições de metadados das entidades que constituem os serviços consumidos. Ela faz isso descrevendo as exibições da entidade, suas referências de identidade e relacionamentos, e as operações que podem se executadas nelas. O desempenho é provavelmente uma das métricas menos entendidas e mais citada de maneira incorreta no campo da computação atualmente. Contudo, como uma métrica para avaliação de sistemas, é considerada pela maioria dos usuários como um dos fatores críticos e mais importantes para avaliar a adequação de sistemas. Richard Drayton da FiS e Arvindra Sehmi da equipe da Enterprise Architecture da Microsoft EMEA escrevem um artigo sobre avaliação de desempenho de um mecanismo de transação escalonável que possui uma arquitetura baseada em componentes de processamento de mensagem, sem estado, acoplado livremente, distribuído em uma rede enfileirada. Essa arquitetura provou ser de grande valor a partir de uma perspectiva de avaliação de desempenho, porque é feito um backup da mesma por meio de técnicas matemáticas seguras, que permitem uma avaliação do impacto no desempenho de várias técnicas de realização de implementação, antes de decidir sobre qualquer tecnologia de realização específica. Portanto, as métricas de avaliação de desempenho mensuradas herdam e beneficiamse dessas bases matematicamente confiáveis. Pedro Sousa, Carla Marques Pereira e José Alves Marques, todos da Link Consulting, prosseguem com os respectivos artigos discutindo como, dentro dos contextos de diversas estruturas de arquitetura empresarial, cada uma com seus próprios conceitos, componentes e metodologias, a preocupação mais importante para os arquitetos é o alinhamento. Essa preocupação pode levar a considerar conceitos de arquitetura e metodologias mais simples porque o foco não é a definição de artefatos de desenvolvimento, mas a verificação das respectivas consistências. Em seguida, Maarten Mullender, Arquiteto de Soluções da equipe de Estratégia de Arquitetura da Microsoft, introduz Razorbills, que é uma proposta para descrever o que os serviços executam, aumentando bastante, desse modo, a utilidade do consumo de serviços. Existem 1 O nerd, o terno e o adivinho, Tech-Ed Europe Mantenha-se atualizado com as informações adicionais disponíveis no site JOURNAL4 Editorial 2

3 semelhanças com o segundo artigo sobre IBF, no qual a descrição é feita em termos de entidades, exibições, ações, referências e relacionamentos, mas a ênfase está em ajudar usuários e analistas de negócios a preencherem a lacuna existente entre estruturado e não estruturado, conteúdo formal e informal e processo. Maarten vai mais além para discutir a importância dessa abordagem na agregação de entidade em níveis informativo e funcional, colaboração e interação de usuário. O artigo final é uma pequena parte de Ferramentas da Próxima Geração de autoria de Oren Novotny da Goldman, Sachs & Co. Nesse artigo ele argumenta que as ferramentas de desenvolvimento devem suportar a mudança que os idiomas já efetuaram e suporta totalmente o desenvolvimento orientado por modelo. Ele insiste que os arquivos de códigofonte devem ser eliminados à medida que não mais servirem a uma função útil nesse contexto e o fundamento lógico atual para utilizá-los tornarse irrelevante pelos meios melhores e diferentes dessas ferramentas da próxima geração. Visite para manter-se atualizado sobre o pensamento de arquitetura na Microsoft e para efetuar download, de modo conveniente, dos artigos do JOURNAL. Como de costume, se tiver interesse em escrever para esta publicação, envie-me uma breve descrição do seu tópico e o seu currículo para asehmi@microsoft.com. Desejando-lhe ótimas férias e uma boa leitura! Arvindra Sehmi Arquiteto, D&PE, Microsoft EMEA JOURNAL4 Editorial 3

4 Escolhendo a Arquitetura da Camada de Apresentação Correta Por David Hill, Microsoft Corporation Resumo A camada de apresentação é uma parte de importância vital de um aplicativo uma camada de apresentação arquitetada de forma incorreta pode causar grande complexidade, falta de flexibilidade e uma experiência frustrante e ineficiente para o usuário. Os aplicativos thin clients possuem benefícios bastante conhecidos sobre os aplicativos rich clients tradicionais em termos de implantação e gerenciabilidade e isso os tornou populares nos últimos anos. Contudo, com o surgimento dos smart clients, a escolha da arquitetura de camada de apresentação não é mais automática. Os rich clients evoluíram em smart clients que podem combinar as vantagens de gerenciamento central de thin clients com a flexibilidade, a receptividade e o desempenho de rich clients. Este artigo discute as abordagens de smart client e thin client e fornece orientação sobre a escolha entre eles. A Importância da Camada de Apresentação A camada de apresentação da maioria dos aplicativos é geralmente de grande importância para o sucesso do aplicativo. Afinal, a camada de apresentação representa a interface entre o usuário e o resto do aplicativo. É onde as peças se encaixam, para assim dizer. Se o usuário não puder interagir com o aplicativo de modo que possibilite a execução do seu trabalho de uma forma eficiente e eficaz, o sucesso geral do aplicativo será gravemente prejudicado. Pessoalmente, eu acho que o termo camada de apresentação não corresponde de forma justa à função e à importância dessa camada. Raramente é mais do que a apresentação de informações ao usuário geralmente é mais sobre o fornecimento de acesso interativo ao usuário para o aplicativo. Talvez um nome mais apropriado para essa camada seria camada de interação do usuário. Neste artigo, no entanto, para facilitar, eu utilizarei o nome comumente aceito para essa camada. De qualquer forma, você desejará projetar essa camada para fornecer a experiência certa ao usuário, de modo que ele possa interagir com o aplicativo de forma eficaz e eficiente. Com certeza você também precisa arquitetar e, em seguida, implementar essa camada de uma forma que leve em consideração, adequadamente, o desenvolvimento, a manutenção e as necessidades operacionais da empresa. A escolha certa da arquitetura de camada de apresentação do aplicativo é de vital importância para alcançar esses objetivos. As duas abordagens comumente adotadas para o design e a arquitetura da camada de apresentação são a abordagem de thin client e a abordagem de smart client. Certamente, vários fatores influenciam na decisão sobre qual é a melhor abordagem para um aplicativo específico por exemplo, requisitos de plataforma de cliente, atualização e implantação de aplicativos, experiência do usuário, desempenho, integração no cliente, recursos offline, etc. e cada um herdou pontos fortes e fracos e suporta naturalmente um certo estilo de aplicativo. Você descobrirá, no entanto, que a distinção entre eles pode ficar obscura e isso pode levar facilmente à aplicação da abordagem básica incorreta causando problemas posteriormente. Por exemplo, é possível fornecer uma interface de usuário rica com uma camada de apresentação baseada em navegador, da mesma forma que é possível fornecer uma interface do usuário totalmente dinâmica com um smart client. Nenhuma dessas opções seria muito fácil de alcançar e ambas poderiam resultar muito provavelmente em uma complexidade desnecessária, na falta de flexibilidade e em altos custos de desenvolvimento e de manutenção. Muitas organizações escolhem, por padrão, uma arquitetura de thin client, sem considerar devidamente as alternativas. Enquanto não for apropriada a todos os cenários, uma arquitetura de smart client pode oferecer vantagens significativas sobre uma abordagem de thin client, sem incorrer nos lados inferiores tradicionalmente associados aos rich clients. As organizações devem observar cuidadosamente cada abordagem de forma que adotem a abordagem correta desde o início, minimizando o TCO durante a vida útil do aplicativo. Nas seções a seguir, examinarei as abordagens de thin client e smart client e algumas das tecnologias que as suportam. Para cada uma, descreverei a arquitetura básica e discutirei algumas das opções de design em cada uma. Após isso, falarei sobre os pontos fortes e fracos relativos de cada abordagem em termos de um número de fatores e requisitos comuns que você deve levar em conta ao determinar a abordagem mais apropriada ao seu aplicativo. Uma arquitetura de smart client pode oferecer vantagens significativas sobre uma abordagem de thin client sem incorrer nos lados inferiores tradicionalmente associados aos rich clients. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 4

5 Browser Security Sandbox Dados Navegador Página UI UI Implantação de Página Página Negócios Empresarial no cliente). Ele fornece um mecanismo que permite o armazenamento de pequenos volumes de dados no cliente (através de cookies) e algumas vezes a capacidade de armazenar páginas em cache, mas geralmente esses recursos são de uso limitado, exceto como uma forma de fornecer rastreamento ou gerenciamento de sessão simples e recursos off-line somente leitura rudimentares, respectivamente. Cliente Suporte limitado de dados locais Servidor da Web Figura 1: Visão Geral Esquemática da Arquitetura de Thin Client Server Roundtrip Nenhum suporte off-line O navegador também fornece a infraestrutura de segurança, de modo que aplicativos diferentes (páginas) possam ter mais ou menos permissões atribuídas, possam fazer diferentes coisas sobre o estado (como cookies), possam hospedar componentes e executar scripts. O Internet Explorer implementa esses recursos através de zonas diferentes, sites confiáveis, classificações, etc. O Que é um Thin Client? Muitas tecnologias de thin client referem-se ao lado do servidor e existem muitas molduras e plataformas de servidores da Web (ASP, ASP.NET, JSP e outros) para escolha. Cada uma possui recursos específicos que tentam torná-lo mais fácil para escrever aplicativos thin client, porém todos entregam a interface do usuário a um navegador no cliente por meio de uma série de páginas HTML. Um aplicativo thin client é facilmente definido como aquele que utiliza um navegador para fornecer o ambiente de execução para a interface do usuário (definido por HTML) do aplicativo. Além de processar a interface do usuário e permitir que o usuário interaja com ele, o navegador também fornece segurança genérica, gerenciamento de estado e recursos de gerenciamento de dados, mais o ambiente de execução para qualquer lógica no cliente. Para o último, o navegador fornece geralmente um mecanismo de script e a capacidade de hospedar outros componentes executáveis, como controles.net, Java Applets, ActiveX e assim por diante, (embora a maioria das definições não considerem esses componentes executáveis como tecnologias de thin client ver aplicativos híbridos abaixo). Um aplicativo arquitetado para utilizar uma camada de apresentação de thin client é decomposto em páginas e cada página é implantada para o cliente mediante solicitação. Cada página contém a descrição da interface do usuário e, geralmente, um pequeno volume de lógica de script no cliente e um pequeno volume de estado/dados (estado de exibição, cookies, ilhas de dados em XML, etc.). A figura 1 mostra uma representação esquemática de uma arquitetura da camada de apresentação de thin client. O navegador possui uma capacidade limitada para interagir com o ambiente do cliente (hardware e outros aplicativos de software em execução Em uma tentativa de fornecer uma interface do usuário mais rica e receptiva, alguns aplicativos da Web adotaram DHTML e tecnologias similares para facilitar uma interface de usuário mais rica. Ao passo que essas tecnologias não são padrão, no sentido de que todos os navegadores não as suportam da mesma forma, elas fornecem a capacidade de inclusão de elementos da interface do usuário mais avançados, como menus suspensos, o recurso arrastar e soltar e mais em uma página da Web. Outros aplicativos da Web migraram para componentes de hospedagem complexos dentro da página incluindo componentes Java Applets, ActiveX e.net. Esses componentes fornecem uma interface do usuário mais receptiva ou lógica no cliente que não pode ser implementada em script por motivos de desempenho ou segurança. É aqui onde o thin client começa a ser sobreposto com o smart client, levando aos chamados aplicativos híbridos. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 5

6 CAS Security Sandbox Smart Client Interface do Usuário Lógica Empresarial Implantação Smart Client Serviço da Web Lógica Empresarial Contudo, os aplicativos smart client representam uma abordagem melhor-dos-dois-mundos, adotando as vantagens de gerenciabilidade dos aplicativos thin client e combinandoas com os benefícios dos aplicativos rich client. Os smart clients são rich clients aperfeiçoados, aproveitando novas tecnologias e técnicas para evitar os imprevistos dos aplicativos rich client tradicionais. Cliente Armazenamento em Cache de Dados Locais Figura 2: Visão Geral Esquemática de uma Arquitetura Smart Client Ao passo que é possível utilizar, certamente, tais aplicativos híbridos para aproveitar os pontos fracos e fortes de cada abordagem, definirei, neste documento, o termo thin client como um aplicativo genérico da Web que não depende de tais componentes, mas somente utiliza os recursos básicos fornecidos pelo ambiente do navegador. Como os aplicativos híbridos necessitam confiar em recursos do smart client para evitar problemas de gerenciamento e operacionais, descreverei os aplicativos híbridos em uma seção posterior quando discutir os aplicativos de smart client. O que é um smart client? Os aplicativos smart client não são, provavelmente, fáceis de definir como os aplicativos thin client porque podem adotar diferentes formas e não estão limitados à abordagem um-tamanhoserve-todos dos aplicativos thin client. A diferença essencial entre um smart client e um thin client é que o primeiro não depende de um navegador para fornecer o ambiente da interface do Suporte Off-line Servidor da Web usuário, execução e segurança para sua operação. Além disso, os smart clients, em vez de HTML e Jscript, geralmente envolvem artefatos de código compilados (componentes, montagens, etc.), sendo executados na máquina cliente para fornecer a interface do usuário do aplicativo e a lógica no cliente. Como os smart clients referem-se aos rich clients? Os aplicativos rich client evoluíram para aplicativos smart clients. Os rich clients ofereciam muitas vantagens sobre os aplicativos thin clients, incluindo desempenho aperfeiçoado, receptividade e flexibilidade e a capacidade de trabalhar off-line, porém os rich clients sofreram uma série de problemas operacionais quando foi necessário implantá-los e atualizá-los de uma forma robusta. As soluções de thin clients superam, certamente, na área de implantação e atualização e esse é um dos motivos principais da sua popularidade. Por exemplo, os aplicativos smart client criados na plataforma.net podem obter vantagens de uma série de tecnologias fundamentais que o.net Framework fornece para solucionar muitos dos problemas tradicionalmente associados aos aplicativos rich client. Ao passo que sempre foi possível criar aplicativos rich client que minimizaram ou evitaram inconveniências de segurança e implantação, os recursos fornecidos pelo.net Framework tornaram isso mais fácil de ser feito. O.NET fornece a capacidade de implantar um aplicativo, ou parte de um aplicativo, a partir de um servidor da Web. Essa tecnologia, conhecida como No-Touch Deployment, permite que você distribua aplicativos através de um URL. Isso permite que você libere aplicativos para uma localização central (por exemplo, para um servidor da Web), de modo que os aplicativos possam ser implantados automaticamente para o cliente, mediante solicitação. Todos os clientes podem ser atualizados automaticamente, desde que o aplicativo verifique automaticamente as atualizações cada vez que o aplicativo for executado e cada aplicativo cliente efetuar download do novo código, se necessário. O.NET também fornece a infraestrutura do CAS (Code Access Security). O CAS atribui permissões específicas de código.net de acordo Os smart clients são rich clients aperfeiçoados, aproveitando novas tecnologias e técnicas para evitar os imprevistos dos aplicativos rich client tradicionais. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 6

7 com a evidência apresentada. O CAS tem a mesma função que o navegador possui em um aplicativo thin client, fornecendo um ambiente de sandbox no qual o aplicativo opera. O No-Touch Deployment é integrado com o CAS. Por padrão, os aplicativos implantados utilizando No-Touch Deployment receberão um conjunto limitado de permissões de acordo com a zona do URL da qual foram distribuídos. Os administradores da rede podem modificar permissões usando política de segurança, de modo que possam ser concedidas ou negadas permissões ao aplicativo de acordo com as solicitações. A criação de um aplicativo smart client com o.net Framework fornece aplicativos menos frágeis. Tradicionalmente, a instalação de um aplicativo rich client poderia quebrar outros aplicativos, pois ele substituiu componentes e DLLs importantes compartilhados por outros aplicativos. O.NET permite o isolamento de aplicativos, mantendo todos os artefatos de aplicativos em um diretório local, de modo que todas as montagens sejam mantidas separadas. Além disso, tais aplicativos não exigem nenhum processo de registro quando são implantados, reduzindo, assim, o risco de quebra de outros aplicativos. Adicionalmente, o.net Framework permite a implantação lado a lado de várias versões de uma montagem. Isso garante que na execução de um aplicativo, ele seja executado nas versões exatas das montagens com as quais foi criado e testado. Um aplicativo arquitetado para utilizar um smart client na sua camada de apresentação, fornecerá geralmente um servidor de implantação central, do qual os artefatos de smart client podem ser implantados para os clientes, e uma série de serviços da Web para fornecer acesso aos recursos de negócios de back-end dados e lógica de negócios e que são consumidos pelo smart client. Desde que o smart client esteja executando o código no cliente, é possível separar mais facilmente a interface do usuário da lógica e dados no cliente. Além disso, dependendo das permissões concedidas, ele pode interagir mais livremente com outros recursos no cliente, como hardware local e outro software em execução no cliente. A figura 2 mostra uma visão geral esquemática dessa arquitetura. Qual a aparência de um smart client? Os aplicativos smart client podem adquirir diversas formas e o arquiteto de um aplicativo possui várias opções de design. A primeira decisão a ser tomada é escolher o estilo de aplicativo mais apropriado a forma que o smart client é apresentado ao usuário. Em geral, existem três formas para desenvolver um aplicativo smart client. Aplicativos Windows. Aplicativos de estilo Windows tradicionais, geralmente criados usando Windows Forms ou aplicativos móveis criados no.net Compact Framework. Aplicativos do Office. Programas do Microsoft Office ampliados para incluir recursos de smart client, conectando o usuário à linha de aplicativos comerciais e processos de negócios. Aplicativos híbridos. Aplicativos que utilizam uma combinação de tecnologias de thin client e smart client. Por exemplo, ao hospedar controles do Windows Forms em uma página do navegador ou ao hospedar o navegador em um aplicativo Windows Forms. A escolha do estilo de aplicativo correto é crucial, se você deseja obter todos os benefícios de uma abordagem de smart client. A escolha do estilo do aplicativo de smart client é afetada pela implantação, pela segurança, pelo desenvolvimento e pelos recursos off-line, mas talvez o fator mais importante a ser considerado é a experiência geral do usuário. Cada escolha representa um tipo diferente de experiência do usuário e a escolha correta dará ao usuário a combinação correta de flexibilidade e desempenho que necessita. Aplicativos Windows Os usuários associam aplicativos smart client a aplicativos de estilo Windows porque fornecem funcionalidade de rich client que inclui barras de ferramentas, barras de menus, menus de contexto, suporte para arrastar e soltar, ajuda sensível ao contexto, desfazer/refazer e muito mais. Os desenvolvedores podem criar esses tipos de aplicativos smart client no.net Framework ou no.net Compact Framework utilizando o Windows Forms para fornecer esses recursos da interface do usuário rica. Esses desenvolvedores podem também obter vantagens da funcionalidade de smart client pré-criada, aproveitando os Blocos de Aplicativos fornecidos pelo grupo Microsoft Patterns and Practices. Esses blocos dotam o aplicativo com recursos de smart client comuns, como armazenamento em cache de dados locais, implantação contínua e a capacidade de trabalhar off-line. Os aplicativos Windows Forms fornecem um maior controle sobre a experiência do usuário, permitindo ao desenvolvedor criar a interface do usuário e o modelo de interação do usuário que melhor se adequa às suas necessidades. Para os aplicativos que exigem uma experiência específica do usuário que não pode ser fornecida por qualquer um dos aplicativos do Office, essa abordagem será a melhor opção. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 7

8 Aplicativos de Smart Client do Office 2003 Os programas Microsoft Office fornecem uma plataforma altamente convincente para a criação de soluções de smart client. A ampliação dos aplicativos Office de modo que tomem parte de uma solução distribuída, a conexão deles a fontes de dados remotas e serviços comerciais, não apenas beneficia os usuários, mas oferece também eficiências aos desenvolvedores que escrevem os aplicativos e para aqueles que devem implantá-los e gerenciá-los. Existem muitos usuários que estão familiarizados com o Office e o utilizam diariamente nos respectivos trabalhos. A ampliação dos aplicativos Office, conectando-os a fontes de dados remotas e serviços comercias significa que a solução pode beneficiar-se da familiaridade do usuário, prevenindo ou reduzindo drasticamente a necessidade de treinar o usuário novamente. O usuário beneficiase também, pois pode continuar a usar o aplicativo com o qual está familiarizado. Muitas organizações utilizam bastante o Microsoft Office. Muitos computadores comerciais seu, de seus clientes, de seus provedores de serviços e de seus fornecedores possuem aplicativos Office instalados. A utilização do Office como o cliente de linha de sistemas de negócios pode reduzir a necessidade de instalar e manter aplicativos cliente incrementais para acessar serviços e fontes de dados de back-end. E, freqüentemente, os dados da linha de aplicativos comerciais são copiados em aplicativos Office, como o Word ou Excel para manipulação, edição, análise e apresentação futura. O recurso para copiar e colar consome tempo e aumenta a possibilidade de erros. E acima de tudo, o link para os dados é perdido, de modo que o usuário necessita de atualizações constantes, repetindo o processo de copiar e colar, provocando, possivelmente, problemas de simultaneidade. Os aplicativos Office podem também fornecer diversas funcionalidades necessárias para exibir e manipular dados, permitindo ao usuário interagir com a solução utilizando todos os recursos do Office. Isso pode economizar esforços e um enorme espaço de tempo, permitindo que você desenvolva e lance a solução mais rapidamente. Por exemplo, o Excel fornece recursos potentes para classificar, manipular e exibir dados. A reutilização desses recursos em sua solução de smart client pode ter um alto custo. Certamente, os usuários têm a capacidade de integrar funcionalidade adicional em seus aplicativos Office durante algum tempo. Em alguns casos, isso levou a soluções especiais, porém críticas de negócios, difíceis de gerenciar porque não são desenvolvidas ou mantidas pelo departamento de TI. A criação dessas soluções utilizando tecnologias de smart client permite que sejam mais facilmente implantadas e atualizadas e representa uma forma de reter o valor das soluções, ao passo que soluciona algumas das questões de gerenciabilidade. O Office 2003 fornece suporte para integrar recursos de smart client no aplicativo Office e conectá-los a serviços remotos que fornecem acesso a processos comerciais e dados. Algumas das tecnologias mais importantes que o Office 2003 suporta para criar soluções de smart client incluem: Suporte de XML. O Office 2003 fornece um número de recursos que permite aos desenvolvedores conectarem, mais facilmente, aplicativos Office a fontes de dados remotas e processo comercial através de XML. O Word, Excel e InfoPath podem usar XML para armazenar a estrutura e o conteúdo de um documento em formato XML legível por máquina ou elemento humano. A Microsoft lançou esquemas W3Ccompliant XSD para esses formatos de arquivos e esses esquemas são disponibilizados gratuitamente a todos para utilização em suas próprias soluções. Esses esquemas permitem que documentos em Word e Excel e formulários em InfoPath sejam criados facilmente no servidor e fornecidos ao cliente através de serviços da Web em XML e os usuários podem exibir e editar de imediato esses documentos. Essa tecnologia pode ser também utilizada para fornecer composição de documentos, indexação ou recurso de pesquisa. E, lógico, desde que os documentos sejam em XML, podem ser trocados com qualquer outro sistema ou processo, fornecendo um meio para intercâmbio de dados através de sistemas heterogêneos. Essa tecnologia adapta-se perfeitamente a soluções centrais de documentos. O Word, Excel e InfoPath podem também consumir mensagens ou documentos em XML que ajustamse ao esquema definido pelo usuário ou cliente. Os usuários podem utilizar seus aplicativos Office como serviços de camada de apresentação em soluções centrais de dados, onde os serviços ou processos comerciais já definem o esquema da mensagem. Esse tipo de aplicativo smart client mapeia elementos e atributos na mensagem para áreas específicas do documento, de modo que o aplicativo Office possa exibi-los corretamente e permite ao usuário editar os valores, enquanto verifica se os dados digitados pelo usuário estão em conformidade A ampliação dos aplicativos Office de modo que tomem parte de uma solução distribuída, a conexão deles a fontes de dados remotas e serviços comerciais, não apenas beneficia os usuários, mas oferece também eficiências aos desenvolvedores que escrevem os aplicativos e para aqueles que devem implantá-los e gerenciá-los. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 8

9 com o esquema de base. É possível consultar, definir ou referenciar, programaticamente, valores específicos usando uma instrução de consulta do XPath. Documentos Inteligentes. As soluções de documentos inteligentes ajudam o usuário a interagir com um documento, fornecendo dados adicionais e orientação ao usuário de acordo com a sua localização atual no documento. À medida que o usuário interage com o documento, este pode exibir informações importantes ou orientação para o usuário, utilizando o painel de tarefas, ou preencher automaticamente os dados ausentes de acordo com a tarefa atual. A conexão dessa experiência a serviços remotos para obter dados ao vivo ou para possibilitar a interação com processos comerciais permite a criação de aplicativos potentes e integrados. IBF (Moldura de Ponte de Informações). A IBF é uma solução declarativa que cria tecnologia de documento inteligente para permitir que os documentos sejam conectados aos serviços através de metadados. As marcas inteligentes em um aplicativo Office interagem com a infra-estrutura IBF genérica e os metadados associados aos serviços disponíveis da Web para fornecerem acesso a dados importantes e processos comerciais no documento, de acordo com o conteúdo dos documentos e com a atividade atual do usuário. Por exemplo, se um usuário receber um documento que se refere a um fornecedor específico, a infraestrutura poderá acessar dados sobre aquela empresa e exibi-los no painel de tarefas. É possível também fornecer acesso às opções disponíveis, permitindo que o documento seja conectado para outros processos comerciais. VSTO (Visual Studio Tools for Office). O VSTO fornece acesso aos modelos de objetos para Word e Excel para extensões de código gerenciadas. Os desenvolvedores podem criar soluções complexas e abrangentes de smart client do Office, utilizando VSTO, não somente para fornecer acesso a todos os recursos do Word e Excel, mas também a todos os recursos do.net Framework, como Windows Forms, que permitem a integração fácil das interfaces do usuário receptivas e ricas. O VSTO também fornece uma experiência de desenvolvimento superior, permitindo ao desenvolvedor a criação e a depuração fácil de uma solução. O VSTO fornece essencialmente o código por trás do documento para formar uma solução que aproveita os recursos fornecidos pelo aplicativo host. Aplicativos Híbridos Os aplicativos híbridos smart client combinam as abordagens de smart client e thin client. Podem fornecer uma forma de estender um aplicativo thin client existente com recursos de smart client ou uma forma de integrar um aplicativo com base em navegador em um aplicativo smart client. Por exemplo, um aplicativo smart client pode hospedar uma instância de um navegador, de modo que determinada funcionalidade de aplicativo e conteúdo possa ser fornecida utilizando a abordagem de thin client. Essa arquitetura pode ser muito útil quando o aplicativo precisar integrar um aplicativo thin client existente ou quando necessitar aproveitar um benefício-chave da abordagem de thin client para fornecer conteúdo dinâmico vinculado fornecido por um servidor da Web. Certamente, tal conteúdo e funcionalidade estarão apenas disponíveis quando o usuário estiver on-line, mas a parte de smart client do aplicativo pode ser utilizada para fornecer funcionalidade útil quando estiver off-line e melhora o aplicativo com acesso à funcionalidade de thin client quando estiver on-line. Em alguns casos, a abordagem híbrida pode ser usada para estender um aplicativo thin client existente, hospedando componentes ou controles de smart client em uma página da Web. Esses componentes podem fornecer uma interface do usuário rica e receptiva e funcionalidade específica de aplicativos (por exemplo, processando ou visualizando dados) enquanto o resto do aplicativo é entregue em uma forma de thin client. Contudo, essa arquitetura não é adequada ao fornecimento de suporte off-line, uma vez que a página de hospedagem da Web não estará disponível sem uma conexão, ou para fornecer integração no cliente de software ou hardware, a não ser que as alterações de política de segurança adequadas estejam em vigor. Escolhendo a Arquitetura da Camada de Interação Correta Ambas abordagens, de thin client e smart client, possuem claramente seus espaços. Cada uma possui seus próprios pontos fracos e fortes e a escolha entre elas dependerá dos requisitos de um aplicativo específico ou da necessidade comercial. A abordagem correta fornecerá ao usuário a experiência de usuário correta, de modo que ele possa interagir com o aplicativo de uma forma eficaz e eficiente, enquanto leva em conta, adequadamente, o desenvolvimento, a manutenção e os aspectos operacionais do aplicativo. Algumas organizações têm uma política que dita uma abordagem de thin client para todos os aplicativos. A escolha de uma abordagem de thin client por padrão pode causar problemas técnicos significativos em alguns aplicativos, porque a plataforma do navegador não é capaz de suportar facilmente os requisitos de aplicativos moderadamente complexos. O desenvolvimento de um aplicativo thin client para ter a aparência, a sensação e os recursos de um aplicativo rich client tradicional pode ser extremamente desafiador e muito dispendioso. Por quê? O navegador impõe limitações severas ao desenvolvedor em termos de gerenciamento de estado, lógica no cliente, dados no cliente e a provisão de recursos da interface do usuário rica, como os recursos arrastar e soltar, desfazer/refazer, etc. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 9

10 Inversamente, a escolha de uma abordagem de smart client para todos os aplicativos não é apropriada, uma vez que pode resultar em soluções bastante complexas para aplicativos que somente apresentam dados dinamicamente e exigem os benefícios de uma interface do usuário altamente dinâmica. Além disso, se o seu aplicativo deve suportar sistemas operacionais de clientes diversos, uma abordagem de smart client pode não ser apropriada, devido a limitações de plataforma híbrida. A adoção de uma abordagem única para todos os aplicativos pode, portanto, resultar em custos desnecessários, complexidade, falta de flexibilidade e redução de usabilidade. Ambas as abordagens podem, provavelmente, coexistir dentro do empreendimento de acordo com os requisitos de aplicativos específicos e as necessidades do negócio. A escolha de uma abordagem no lugar da outra deve ser decidida com base no aplicativo, embora em alguns casos ambas possam ser combinadas, integrando adequadamente tecnologias de thin client e smart client ou adotando uma abordagem de canal duplo, na qual alguma classe de usuários pode acessar o aplicativo utilizando um thin client enquanto os usuários com requisitos mais rigorosos utilizam um smart client. Em cada modo, o segredo está em aproveitar a tecnologia apropriada no tempo adequado para atender às expectativas dos usuários e às necessidades gerais do negócio. A abordagem de thin client possui benefícios bastante conhecidos em termos de alcance e facilidade de implantação e operação. Contudo, com o surgimento da tecnologia de smart client, os smart clients estão sendo atualizados e são atualmente uma alternativa viável para thin clients de diversos cenários. Em particular, os smart clients não são atingidos pelos problemas de implantação e gerenciamento que atingem as soluções de rich clients, e as soluções de smart client adicionam benefícios em termos de flexibilidade, receptividade e desempenho. Logo, se a implantação e a gerenciabilidade não são mais os fatores dominantes que influenciam a decisão entre as duas abordagens, como escolher entre elas? Com a redução dos benefícios relativos da abordagem de thin client nessa área, o equilíbrio está mudando e os fatores que devem ser levados em consideração aumentaram. Dependendo da prioridade relativa dos requisitos, uma abordagem será mais adequada do que a outra e a escolha da abordagem correta resultará em um processo de desenvolvimento mais rápido e menos complexo, no aumento da facilidade de uso e na maior satisfação do usuário. Os recursos, as vantagens e desvantagens de cada abordagem são descritas acima, mas como isso se traduz em uma decisão, considerados os requisitos de um aplicativo específico? Alguns dos fatores mais importantes que as empresas devem levar em consideração incluem: Requisitos de plataforma do cliente Requisitos de implantação e atualização Requisitos de experiência do usuário Requisitos de desempenho Requisitos de integração no cliente Requisitos off-line Isso não é uma lista abrangente de fatores e o departamento de TI da sua empresa pode adicionar outros fatores bastante importantes para aplicativos específicos. Particularmente, essa lista de fatores enfoca requisitos operacionais ou funcionais e os fatores de tempo de design e desenvolvimento não foram aqui incluídos. Ainda assim, esses fatores podem ser importantes o suficiente para tirar o equilíbrio entre uma abordagem e a outra. A decisão sobre a abordagem correta é uma decisão conjunta entre os funcionários de TI e os proprietários do negócio. A abordagem adotada deve levar a uma solução na qual ambos os grupos fiquem satisfeitos: a equipe de TI do lado do gerenciamento e os proprietários do negócio do lado da funcionalidade. Plataforma do Cliente A flexibilidade da plataforma do cliente pode ser importante para um cliente ou aplicativos de cobertura de parceiro, nos quais os usuários principais são externos à organização e para os quais uma plataforma de cliente específica não pode ser obrigatória, ou para aplicativos que tenham que ser acessíveis de sistemas operacionais não-windows. Os thin clients oferecem a capacidade de atingir diversas plataformas de clientes, embora isso exija freqüentemente que o aplicativo determine o tipo exato de plataforma de destino, de modo que ela possa alterar sua operação ou comportamento para acomodar as diferenças entre os diversos navegadores, especialmente quando a plataforma de destino deva incluir dispositivos móveis. A própria moldura de thin client pode gerenciar muitas dessas diferenças. Por exemplo, o ASP.NET no servidor pode determinar o tipo de navegador de destino e processar o conteúdo para cada navegador, em conformidade. No entanto, o uso de alguns dos recursos mais avançados do navegador resultará, provavelmente, na necessidade de desenvolver um código específico para gerenciar as diferenças entre os tipos de browser. A abordagem de smart client não oferece esse recurso, embora os aplicativos que visam apenas os sistemas operacionais Windows possam usar o.net Framework e/ou o NET Compact Framework (para A abordagem correta fornecerá ao usuário a experiência de usuário correta, de modo que ele possa interagir com o aplicativo de uma forma eficaz e eficiente, enquanto leva em consideração o desenvolvimento, a manutenção e os aspectos operacionais do aplicativo. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 10

11 aplicativos móveis) para entregar uma solução de smart client em uma ampla gama de dispositivos de cliente, mesmo para usuários externos. Se o seu aplicativo tiver que suportar clientes ou usuários externos que executem sistemas operacionais não-windows, a abordagem de thin client deverá ser levada bastante em consideração. Implantação e Atualização As abordagens de thin client e smart client envolvem a implantação da interface do usuário, lógica de aplicativo e dados para o cliente. Em ambos os casos, esses artefatos são centralizados, gerenciados e implantados para o cliente, mediante demanda. Na abordagem de thin client, esses artefatos não são constantes no cliente e necessitam ser implantados cada vez que o usuário executa o aplicativo. Na abordagem de smart client, o cliente pode manter esses artefatos para habilitar a utilização off-line ou otimizar o processo de implantação e atualização. Como ambas as abordagens permitem que a empresa localize centralmente os artefatos do aplicativo, elas fornecem gerenciamento centralizado no que se refere à autorização do usuário, implantação do aplicativo, atualização, etc. As empresas podem usar o thin client e o smart client para fornecer soluções e garantir que os usuários executem apenas a versão mais recente do aplicativo, embora o smart client permita flexibilidade adicional, como a possibilidade de usuários diferentes executarem versões diferentes do aplicativo (por exemplo, grupos pilotos) ou a execução off-line do aplicativo. Contudo, para obter esses benefícios, a solução pode exigir alterações adicionais da política de segurança e/ou um componente do gerenciador de atualização a ser implantado para o cliente. Se o seu cenário exigir que o aplicativo seja executado off-line, você deve levar em conta a adoção da abordagem de smart client. Por outro lado, se o aplicativo não se beneficiar da continuidade de artefatos no cliente, a abordagem de thin client pode fazer mais sentido. No último caso, os aplicativos que apresentam principalmente dados dinâmicos, ou onde problemas de simultaneidade (com relação a dados ou lógica de aplicativos) podem ser graves, tendem a ser melhor servidos com a utilização de um thin client. Experiência do Usuário Os aplicativos de thin client e smart client são adaptados para estilos específicos de interfaces do usuário. Muitos aplicativos thin client tentam fornecer uma experiência de usuário rica, mas tendem a tornarse insuficientes em determinados aspectos importantes devido às limitações do navegador quando comparados a uma plataforma de smart client. Por exemplo, os recursos básicos de rich client como arrastar/ soltar e desfazer/refazer são muito difíceis de desenvolver em uma solução de thin client. A complexidade associada ao fornecimento desses recursos pode ser considerável e pode reduzir os benefícios da plataforma híbrida da abordagem de thin client. Você deve também levar em conta como o usuário interage com o aplicativo. Alguns aplicativos são bastante lineares porque o usuário interage tipicamente com os mesmos em um modo pré-definido ou semelhante. Outros aplicativos são não-lineares e o usuário pode iniciar uma tarefa apenas para interrompêlos, concluir outra tarefa e, em seguida, voltar à tarefa original. O gerenciamento do estado necessário para fornecer tal funcionalidade pode ser desafiador em uma solução de thin client. Por exemplo, as soluções de thin client terão que ser projetadas para gerenciar a situação se o usuário pressionar o botão Back no meio de uma transação importante. Tal situação é mais fácil de gerenciar em um aplicativo de smart client. Os smart clients podem também obter vantagens dos recursos locais para fornecer classificação, visualização, pesquisa de dados locais e validação no cliente para aumentar a utilidade de um aplicativo e melhorar a experiência do usuário. Tais recursos podem levar a uma melhoria da qualidade dos dados, satisfação do usuário e produtividade. Desempenho Uma diferença significativa entre as duas abordagens é que os aplicativos smart client oferecem um desempenho superior em comparação às suas réplicas thin client. Em um nível básico, um thin client utiliza geralmente script (que deve interpretar às pressas) como o meio para entregar e executar a lógica de aplicativo no cliente. De modo oposto, uma solução de smart client pode entregar código compilado específico ao cliente. Além disso, e talvez o mais importante, a lógica no cliente em um aplicativo smart client possui menos restrições no sentido de que pode interagir com a interface do usuário, o armazenamento local de dados ou com os serviços localizados na rede. Por esses motivos, uma boa arquitetura de smart client permite ao desenvolvedor da solução entregar uma solução de alto desempenho de modo mais fácil. A percepção do usuário sobre o desempenho depende de como ele utiliza o aplicativo e como espera que se comporte. Os aplicativos que não são usados freqüentemente ou com os quais o usuário não interage muito, por exemplo aplicativos que simplesmente obtêm e exibem dados não se beneficiarão do alto desempenho bruto no cliente. Contudo, os aplicativos que são bastante usados, darão a impressão que têm um mau desempenho, caso exista mesmo um pequeno atraso nos recursos freqüentemente usados. Por exemplo, em um aplicativo de call center, um atraso de 4 ou 5 segundos para recuperar detalhes da ordem do cliente pode aumentar facilmente a insatisfação do usuário (e o custo). JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 11

12 Certamente, para a funcionalidade que envia ou recupera dados através da rede, ambas as abordagens exibirão o mesmo desempenho bruto. Contudo, uma solução de smart client bem projetada pode executar sua comunicação da rede em um segmento separado, permitindo que o aplicativo permaneça receptivo ao enviar e receber dados através da rede. Tal trabalho de segundo plano pode ser alcançado proativamente, em resposta a uma chamada recebida de cliente. Além disso, é mais fácil para as soluções de smart client armazenar dados localmente, que podem reduzir o número de chamadas da rede ou reduzir a largura da banda necessária para executar a mesma função. Esses recursos podem ter um grande impacto no desempenho observado pelo usuário de um aplicativo. As soluções de client smart podem fornecer validação mais rigorosa de dados no cliente. Por exemplo, como uma solução de smart client pode armazenar dados e lógica em cache localmente, é possível armazenar, em cache, dados de referência somente leitura que o aplicativo pode usar para fornecer validação de campo e campo cruzado. Os aplicativos que usam tal validação podem fornecer um feedback ao usuário com antecedência, aumentando o desempenho observado do aplicativo, reduzir o número de vezes que os dados são transferidos através da rede e garantir qualidade de dados mais alta. As soluções de thin client podem depender de scripts complexos para fornecer o mesmo nível de funcionalidade e podem não ser capazes de validar dados localmente em relação a outros dados que não são exibidos na página atual. Uma solução de smart client pode também obter muitas vantagens do armazenamento, processamento local e exibir recursos para permitir que o usuário, consulte, classifique e visualize dados do cliente sem a necessidade de fazer uma chamada da rede. Essa capacidade fica especialmente evidenciada ao usar um aplicativo do Office, como o Excel, como o ambiente de host do smart client. Isso pode resultar em uma redução significativa de chamadas da rede para executar a mesma função para um aplicativo thin client. Como a interface do usuário da solução de smart client é fornecida geralmente pelo código específico em execução no cliente, ela pode fornecer uma interface do usuário mais receptiva para o usuário. Os recursos de interface do usuário rich client, como arrastar e soltar, desfazer/refazer, ajuda sensível ao contexto, atalhos do teclado, etc. podem melhorar a experiência do usuário e, com isso, o desempenho observado do aplicativo. Se o desempenho é uma questão importante, você deverá levar em conta uma solução de smart client. Um desempenho observado pelo usuário do aplicativo é normalmente mais importante do que o desempenho real das operações individuais. O objetivo principal de um bom aplicativo é garantir que o usuário possa executar seu trabalho de forma eficaz e eficiente, de modo que a satisfação do usuário seja mantida. Integração no Cliente Normalmente, um aplicativo necessita de acesso aos recursos no cliente, de forma que possam ser integrados em uma solução geral. Algumas vezes os recursos no cliente incluem hardware (uma impressora, telefone, leitora de código de barra, etc.) ou software (integração de outra linha de negócios ou aplicativos de desktop). Certamente, as abordagens de thin client e smart client operam em uma sandbox. No caso do thin client, o navegador fornece uma sandbox, para um smart client, o tempo de execução do.net Framework fornece a sandbox. A integração dos recursos no cliente em um aplicativo thin client exige geralmente a utilização de uma arquitetura de aplicativo híbrida para hospedar um componente em uma página (por exemplo, um controle ActiveX) para estender além da sandbox do navegador. Essa abordagem não é muito flexível e depende geralmente da tomada de decisões de segurança, pelo usuário, sobre o download de componentes para execução no cliente sob a conta de login do usuário. O tempo de execução do.net Framework utiliza uma abordagem mais flexível e concede permissões de código gerenciado com base na evidência que apresenta e a política de segurança local. Por padrão, o código obtido através de download de um servidor da Web não pode interagir com os recursos locais, exceto de formas muito limitadas e específicas. Contudo, sua lógica de aplicativo pode conceder permissões adicionais ao código para acessar recursos específicos, como diretórios específicos no disco, acesso a outros aplicativos, bancos de dados locais, etc. Essa abordagem gerenciada representa um mecanismo mais flexível e palpável para controlar os aspectos de segurança de um aplicativo, permitindo a integração do smart client a outros recursos no cliente sem a possibilidade de riscos para a segurança. Acima de tudo, o administrador da rede utiliza políticas de segurança para tomar decisões de segurança em vez dos usuários individuais, de modo que o código do aplicativo não pode executar ações ou acessar recursos para os quais não tenha permissão. Os aplicativos de smart client geralmente usam segurança de acesso de código para controlar o armazenamento em cache de dados e lógica no cliente. Tal comportamento é essencial para fornecer recursos off-line e, desse modo, esses tipos de aplicativos necessitam geralmente de alterações da política de segurança para conceder permissões específicas. Normalmente, isso envolve a concessão de permissão ao aplicativo para armazenar o código e os dados em cache no disco local. É importante que a abordagem correta seja aplicada desde o início para evitar complexidade, custos, falta de flexibilidade desnecessários e uma experiência do usuário ruim. JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 12

13 Se a solução exigir acesso aos recursos no cliente, como hardware local ou outros aplicativos instalados localmente, a abordagem de smart client fornecerá uma solução segura e flexível. Recursos Off-line As organizações tornaram-se cada vez mais dependentes dos seus sistemas de TI e dos dados e serviços que eles fornecem; a capacidade de trabalhar off-line tornou-se muito importante para os usuários. O fornecimento de suporte para acesso off-line a dados e serviços, utilizando o mesmo aplicativo, estando online ou off-line, permite ao usuário permanecer produtivo constantemente e ajuda a garantir a consistência e a qualidade dos dados. Ao passo que a conectividade da rede está se tornando cada vez mais onipresente, é importante observar que possuir uma conexão de rede não é geralmente suficiente para garantir o acesso a um aplicativo e aos dados e serviços que ele representa. Os aplicativos de linha de negócios dentro do firewall podem não estar acessível aos usuários quando estiverem fora do escritório, a não que a organização invista em uma infra-estrutura VPN. Mesmo nesse caso, forjar uma conexão pode ser dispendioso e demandar muito tempo. O acesso breve ou especial ao aplicativo não é geralmente apropriado ou possível, causando a perda de oportunidades ou inconsistência dos dados. Às vezes, os usuários podem planejar para trabalhar off-line. Por exemplo, você pode ter um profissional de vendas que está fora do escritório por um período específico ou um usuário que trabalha em casa. Às vezes, no entanto, é difícil planejar um cenário off-line. Por exemplo, um usuário em um depósito com um Tablet PC pode ter uma conexão sem fio que é interrompida periodicamente. Outro ponto a ser considerado é a qualidade da conexão do usuário. À David Hill Microsoft Corporation davidhil@microsoft.com medida que as organizações tornaramse cada vez mais distribuídas no mundo, a conectividade da rede pode ter problemas com alta latência ou banda larga baixa. Em cada um desses casos, uma solução de smart client pode fornecer acesso robusto ao aplicativo de modo que o efeito das alterações de conectividade possa ser minimizado ou eliminado. Por meio do armazenamento inteligente de dados e lógica em cache no cliente, e da implantação automática de atualizações a ambos quando solicitada, o aplicativo pode fornecer ao usuário uma experiência contínua, independentemente do seu estado de conexão. Além disso, um smart client pode garantir que todas as chamadas da rede sejam gerenciadas em um segmento de segundo plano, de modo que o aplicativo nunca tenha que esperar pela rede para responder, permitindo que o usuário continue o trabalho independentemente do estado da rede. A consecução desses objetivos com uma solução de thin client é muito difícil de ser alcançada. Algumas soluções tentam solucionar esse problema fornecendo o aplicativo da Web, ou um subconjunto dele, no cliente, usando um servidor local da Web. Tais soluções são de difícil manutenção e exigem uma infraestrutura complexa para garantir que as atualizações do aplicativo e dos respectivos dados sejam gerenciadas adequadamente. Tais soluções reduzem os benefícios de gerenciamento centralizado que são geralmente mencionados como o motivo principal para a adoção de uma solução de thin client, e elas impõem todas as outras inconveniências de uma solução de thin client. Conclusão A escolha da arquitetura da camada de apresentação correta pode ser crítica ao sucesso geral de um aplicativo. A arquitetura correta fornecerá o equilíbrio perfeito entre David Hill é um Arquiteto de Soluções da equipe da Microsoft Architecture Strategy. Nos últimos dois anos, David vem ajudando clientes e arquitetos parceiros a criar soluções de smart client com êxito na plataforma.net. Ele teve uma contribuição-chave para a experiência do usuário, facilidade de desenvolvimento e avaliação e os requisitos operacionais do aplicativo. Os usuários estão cada vez mais exigindo que suas partes dessa equação sejam levadas em conta. As abordagens de thin client e smart client são bastante apropriadas aos estilos particulares de aplicativos. Avanços recentes da tecnologia repararam alguns dos desequilíbrios entre essas abordagens, de modo que elas não precisam ser aplicadas inapropriadamente a situações às quais não são adequadas. É importante que a abordagem correta seja aplicada desde o início para evitar complexidade, custos, falta de flexibilidade desnecessários e uma experiência do usuário ruim. As políticas corporativas genéricas que favorecem uma abordagem sobre a outra são propensas a incorrer nesses problemas. Uma organização deve levar em conta, cuidadosamente, as necessidades gerais do aplicativo e compará-las aos recursos de cada abordagem. Os fatores que podem influenciar essa decisão são diversos e variados e esse artigo abordou apenas alguns dos mais comuns deles. Invariavelmente, a decisão será tomada com base em um compromisso entre os diversos fatores. O entendimento desses fatores, e suas prioridades respectivas, podem ajudar a garantir que a sua organização escolha a arquitetura da camada de apresentação correta. Fontes Manual de Design e Arquitetura do Smart Client Padrões e Práticas Microsoft (Smart Client Architecture and Design Guide Microsoft Patterns and Practices). Visão Geral de Tecnologias do Desenvolvedor do Office 2003 MSDN. Visão Geral das Ferramentas e Programas do Desenvolvedor do Office 2003 MSDN. o Manual de Design e Arquitetura do Smart Client Padrões e Práticas Microsoft (Patterns and Practices Smart Client Architecture and Design Guide) e o Bloco de Aplicativos Offline (Offline Application Block). JOURNAL4 Escolhendo a Arquitetura da Camada de Apresentação Correta 13

14 Moldura de Ponte de Informações Trazendo SOA para a área de trabalho em aplicativos do Office Por Ricard Roma i Dalfó, Microsoft Corporation Introdução Atualmente as empresas estão migrando para a SOA como uma forma de divulgar seus aplicativos e dados para consumo. Ao adotar a SOA, os ativos da empresa como a linha de aplicativos comerciais ou os sistemas de back-end podem ser usados por uma variedade de soluções/aplicativos criados, além dos serviços divulgados por esses ativos. Nesse universo é possível olhar para uma empresa como um conjunto de serviços que divulgam conjuntos de dados ou funcionalidade e engloba a lógica comercial por trás deles. Atualmente, a criação de soluções, além desses serviços, é bastante fácil com o uso das ferramentas de desenvolvimento existentes. Fornecedores diferentes oferecem ferramentas para exposição e desenvolvimento, além desses serviços, utilizando padrões como SOAP ou WSDL. Uma vez que as empresas iniciam o desenvolvimento, alguns desses problemas de soluções começam a surgir. A seguir, alguns dos problemas mais comuns: a) As soluções são utilizadas apenas uma vez. Falam apenas para um ou uma série de serviços predefinidos e a própria solução é difícil de ser reutilizada. As alterações dos serviços exigem uma recriação/ reimplantação da solução. b) O conhecimento sobre o que o serviço expõe está na mente das pessoas muito mais do que na definição do próprio serviço. Os padrões atuais somente abrangem a forma como você obtém esses serviços. c) É difícil reunir serviços diferentes. Não existem mecanismos de agregação predefinidos e não existe definição sobre como um serviço refere-se ao outro (os serviços não têm conhecimento sobre os demais). d) As UI das soluções são difíceis de fazer e geralmente ruins (a não ser que sejam feitos grandes investimentos) pela maioria dos padrões de usuários comuns. É difícil emular UIs de aplicativos em circulação atuais em uma solução utilizada apenas uma vez. e) A maioria dos usuários está bastante familiarizada com aplicativos como o Office Suite (Word, Excel, Outlook, etc.), mas necessita de treinamento se um novo aplicativo/solução for produzido, aumentando os custos de tal implantação. Em virtude do acima exposto, é necessário um mecanismo melhor para a criação de soluções, além dos serviços existentes. A Abordagem de Metadados Atualmente os serviços da Web divulgam muitas informações sobre como os serviços podem ser consumidos, mas oferecem pouca ajuda para entender que tipo de informações ou funcionalidade é oferecido. Os serviços da Web normalmente divulgam WSDL, logo as ferramentas podem descobrir facilmente quais métodos e parâmetros os serviços da Web divulgam, mas oferecem poucas dicas sobre quais entidades comerciais são definidas por trás desses métodos ou mesmo se afetam sistemas de backend (nenhuma forma de dizer se um método atualizará o sistema de backend, por exemplo). Parece que o WSDL não é suficiente para representar o que os serviços atuais divulgam. Nós propomos um novo conjunto de Metadados que esteja associado a um serviço e explique o tipo de coisas que um usuário do serviço (um desenvolvedor de soluções) necessitará saber. Nesses novos Metadados, divulgaremos conceitos como: a) Entidades Negócios abstratos ou definições do usuário que englobarão um conjunto de dados ou funcionalidade. Por exemplo, podemos ter uma entidade Cliente. b) Exibições Um esquema associado com uma entidade que descreve um subconjunto de dados sobre ela. Por exemplo, para a entidade Cliente, podemos ter diversas exibições como Informações sobre Contato do Cliente ou Informações Financeiras do Cliente. Cada exibição cumpre um esquema específico e é uma representação da entidade de um determinado contexto. c) Relacionamentos As Entidades/ Exibições podem ser relacionadas a outras e esses relacionamentos devem ser descritos nesses Metadados. Por exemplo, a entidade Cliente pode ser relacionada a uma entidade Ordens. Os relacionamentos permitem navegações entre as entidades, através da execução da descrição de Metadados. Um relacionamento descreverá, então, como ir de uma entidade para outra. d) Referências Uma referência é uma forma comum para indicar um conjunto de informações. É um esquema e representa o conjunto mínimo de informações necessárias à recuperação de uma parte dos dados, por exemplo Identificação do Cliente para recuperar um Cliente. Existem várias formas de recuperar uma parte das informações, por exemplo, um cliente pode ser recuperado por nome, identificação, SSN, etc. e) Operações São os métodos disponíveis para uma determinada entidade/exibição operar. Você pode ter como exemplo de tais operações as opções GetCustomer, UpdateCustomer ou ReleaseOrder. A descrição de Metadados para os Serviços existentes somente soluciona metade da equação. A outra metade (as soluções desenvolvidas além desses serviços) também necessita de uma descrição de Metadados. É possível criar a maioria das soluções, pensando em termos de Ações executáveis pelo usuário final. Essas Ações são construídas além das Entidades de Serviços/Exibições e fornecem acionabilidade além delas. Uma ação Cliente certamente terá uma ação para exibir seus dados e, possivelmente, Atualmente os serviços da Web divulgam muitas informações sobre como os serviços podem ser consumidos, mas oferecem pouca ajuda para entender que tipo de informações ou funcionalidade é oferecido. JOURNAL4 Moldura de Ponte de Informações 14

15 Cliente Servidor Aplicativos do Office Esquema Anexado Marca Inteligente CRM Informações sobre o Cliente Faturas Ordens Figura 1: Arquitetura de IBF Integração e Processamento de Aplicativos Gerenciador do Painel de Tarefas Integração de Host Processamento Mecanismo da Ponte de Informações SOAP Serviço da Web Compatível com Ponte de Informações SAP outra ação para atualizá-la. A descrição da ação deve vincular os dados recuperados do serviço na UI ou a funcionalidade de solução que a utilizará. Moldura de Ponte de Informações IBF (Moldura de Ponte de Informações) é a resposta da Microsoft à abordagem de Metadados e aos desafios acima. A IBF permite a conexão de LOBs e sistemas de backend a aplicativos Office e a criação de soluções, além de serviços da Web, por meio de uma abordagem de Metadados. Serviços da Web Serviço de Metadados Serviço da Web Compatível com Ponte de Informações Aplicativo Herdado Metadata Designer Metadados Serviço da Web Compatível com Ponte de Informações Serviço de Agregação A IBF executa diversas coisas: Metadados a) Cria descrição de Metadados para serviços b) Cria infra-estrutura de Metadados para criar soluções/aplicativos além de serviços. c) Alto nível de reutilização sobre as soluções d) Fácil manutenção e implantação de soluções e) Alto nível de integração com aplicativos Office f) Curva de aprendizagem muito baixa para os usuários existentes do Office Arquitetura de Ponte de Informações A arquitetura de IBF (como mostra a Figura 1) inclui os seguintes componentes: a) Um serviço da Web compatível com IBF que engloba o sistema de back-end ou LOB. Discutiremos o problema de compatibilidade na próxima seção (projetando e desenvolvendo uma solução IBF). b) Um repositório de Metadados (Serviço de Metadados) que inclui o serviço e os Metadados de Solução. O repositório é exposto como um serviço da Web que fornece acesso aos Metadados. Existe um repositório central no qual todos os Serviços e as Soluções são descritos. Os clientes efetuarão download de subconjuntos desses Metadados com base na necessidade para execução com base nas respectivas permissões. c) Mecanismo de Cliente IBF Essa última parte possui dois componentes distintos: a) O Mecanismo que efetua download de Metadados do Serviço de Metadados, quando necessário, e mantém um cache local dele. Também entende os Metadados e os executa com base no contexto atual. Ele executa todas as operações não relacionadas à UI como chamadas SOAP, transformações, etc. Esse componente é agnóstico da UI. b) O Mecanismo de UI é a parte que entende o aplicativo, onde está sendo hospedado (Word, Excel, etc.), processará a UI e fornecerá serviços específicos para o aplicativo host. Cria uma camada de abstração, além do aplicativo de hospedagem; logo, as Soluções criadas com a IBF não necessitam saber as diferenças entre os aplicativos de hospedagem. d) O Metadata Designer é uma ferramenta baseada no Visual Studio que permite a edição/ importação de Metadados para o Serviço de Metadados. Propomos um novo conjunto de Metadados que esteja associado a um serviço e explique o tipo de coisas que um usuário do serviço (um desenvolvedor de soluções) necessitará saber. JOURNAL4 Moldura de Ponte de Informações 15

16 Projetando e desenvolvendo uma solução de Ponte de Informações Ao projetar uma solução IBF, você deverá separá-la em três blocos distintos (ver Figura 2). De um lado você precisa descrever um serviço da Web compatível com IBF que englobe a funcionalidade do aplicativo de back-end que deseja oferecer aos seus usuários finais. Por outro lado, você precisa projetar a UI e a experiência que deseja oferecer aos usuários da sua solução. A etapa final é vincular o seu Serviço e a solução de UI que você criou usando metadados IBF. Ao separar esses três estágios, você pode alocar recursos diferentes para cada um deles e, em seguida, pode operar de uma maneira independente e concordar somente nas interfaces (ou esquemas comuns) que eles compartilharão. Criando um serviço compatível com IBF A IBF exige Serviços que fornecerão os dados e a interação com os dados necessários à sua solução. A IBF suporta atualmente dois tipos de Serviços: Serviços da Web e Componentes CRL. Os Serviços da Web são a forma mais comum para divulgar dados de back-end, e a maioria dos exemplos de IBF os utiliza para a descrição do Serviço. Se você necessitar trabalhar com os dados off-line ou armazenar em cache (por motivos de desempenho) a implementação de CLR é também possível. Microsoft Office System Developer Soluções de Documentos Configuração de Metadados Vinculações e Controles de UI.NET Developer Metadados de Soluções Desenvolvedor / Analista de Negócios Desenvolvimento de Serviços da Web.NET Web Services Developer Visual Studio.NET Ferramentas de Criação de Páginas em XML Marcas Inteligentes SDK Visual Studio.NET Gerenciador de Autenticação Visual Studio.NET Documento Anexado do Esquema Marcas Inteligentes Embutidas XSL ou Windows Forums Active Directory Plug-in de Desenvolvedor de Metadados Serviço da Web Compatível com Ponte de Informações Serviço da Web Compatível com Ponte de Informações Serviço da Web Compatível com Ponte de Informações Microsoft Office System Microsoft Office System Serviço de Contexto e Ação Biblioteca de Metadados Aplicativo LOB Aplicativo LOB Aplicativo LOB Ao projetar um Serviço para IBF, você deve ter em mente que está criando um Serviço para consumo do usuário; logo, você deseja divulgar dados e métodos significativos para o usuário. Existem também alguns conceitos que você precisa saber, ao criar esses Serviços. Entidades Você pode pensar em uma entidade como um objeto comercial com um significado Figura 2: Os três blocos distintos de uma solução IBF específico para o usuário e que este poderá agir sobre o mesmo. Um exemplo de uma entidade pode ser Cliente, Ordem ou Oportunidade. Todas elas possuem alguns dados associados às mesmas e são acionáveis do ponto de vista do usuário. Por exemplo, a entidade do cliente pode ter dados associados a um cliente específico (nome, endereço, localização, etc.) como também métodos que permitem aos usuários agir na entidade, como UpdateCustomerInforma tion ou Send ToCustomer. Pode também ser um ponto de partida para outras entidades através de relacionamentos A IBF permite a conexão de LOBs e sistemas de back-end com aplicativos Office e a criação de soluções, além de serviços da Web, por meio de uma abordagem de Metadados. JOURNAL4 Moldura de Ponte de Informações 16

17 como CustomerOrders ou CustomerOpportunities. Exibições entidades de partições IBF em exibições diferentes. Uma exibição é um subconjunto de informações referentes à entidade. Para um cliente você deve ter uma exibição Informações sobre Contato do Cliente e uma exibição Finanças do Cliente. Referências Uma referência no universo IBF é uma parte da informação que identifica exclusivamente uma instância de uma entidade/exibição. No exemplo anterior, uma referência poderia ser Identificação do Cliente ou Nome do Cliente, se isso permite que você identifique o cliente exclusivamente. Relacionamentos Algumas das entidades/exibições terão relacionamentos entre elas e os Metadados que criarmos devem descrevê-las. Um exemplo seria Cliente e Ordens, uma vez que você pode referir-se a um Cliente pelas respectivas ordens e a uma Ordem pelo respectivo Cliente. Com base nos conceitos anteriores, ao criar um Serviço, você identificará três tipos de métodos diferentes: Obter O método obter é o que permite que você recupere os dados para uma entidade/exibição, passando por uma Referência. Um exemplo disso seria um método denominado GetCustomerCon tactinformation que aceitaria um parâmetro Referência de Identificação do Cliente. Colocar Esse método permite que você modifique o conteúdo de uma entidade/exibição, atualizando o sistema de back-end. O método aceita duas entradas, a Referência para a entidade/exibição a ser atualizada e os dados a serem atualizados. Agir Esse tipo de método permite fazer coisas que não estão relacionadas à obtenção/atualização de uma entidade/exibição ou através de várias entidades. Ao compreender esses conceitos, você pode criar um Serviço ao redor deles. O serviço divulgará uma coleção de modelos do tipo Obter/Colocar/Agir e ao fazer isso definirá os esquemas das referências e das exibições (retorno de dados pelas operações Obter). Para o serviço ser concluído, ele tem que expor Metadados de IBF que descrevem os conceitos anteriormente descritos. A IBF fornece ferramentas que geram, automaticamente, Metadados de um serviço da Web e, em seguida, você pode incrementar os Metadados anotando os métodos expostos por volta das Entidades/ Exibições e mapeá-los para as Referências corretas. Criando componentes da UI A IBF permite que os seus documentos contenham links ao vivo para dados de back-end. A forma como esses documentos contêm informações sobre quais dados de back-end serão obtidos é através de SmartTags ou possuindo um esquema anexado ao documento. A SmartTag ou nó de elemento no esquema armazenará informações sobre que parte da informação de back-end está indicando. Conforme discutido no tópico anterior, sobre como criar um serviço IBF, essas são Referências. As SmartTags, por exemplo, conterão uma referência para uma parte de informação de back-end. Sua solução terá que definir como deseja que as SmartTags sejam incluídas no documento e a IBF fornece/recomenda várias formas de fazê-lo. Você pode gerar automaticamente um documento com as SmartTags embutidas (isso poderá ser útil se os s/documentos forem gerados dinamicamente por algum processo); é possível usar um identificador de SmartTag para detectar partes do texto com base em uma expressão regular ou efetuando uma pesquisa e inserindo uma SmartTag nelas. Você também pode utilizar o recurso Pesquisar embutido na IBF para o usuário localizar a instância da informação na qual está interessado e permitir que seja colada no documento. As partes da UI restantes são o que será exibido para o usuário. A IBF fornece uma abordagem do Painel do Windows que hospeda regiões totalmente definidas pelo provedor de soluções. A IBF suporta controles.net CLR e regiões HTML (e menus para essas regiões). A criação de uma parte da UI é somente uma questão de criação de um controle e da implementação de uma interface que terá os dados sob controle. O controle não precisa saber como ou de onde os dados são obtidos. O controle somente necessita saber os tipos de dados que serão fornecidos. A IBF iniciará o controle dinamicamente no tempo de execução e transmitirá os dados corretos ao controle. Isso permite separar a exibição dos dados da forma como estes são obtidos. Seguindo o exemplo anterior, seria possível criar um controle que sabe como processar as informações do Cliente (conhece o esquema de um Cliente e possui seu nome, endereço e assim por diante). Criando Metadados de Soluções A etapa final para criar uma solução de IBF é a criação de Metadados que vincularão a descrição dos Serviços aos elementos da UI que foram definidos para eles. A IBF fornece alguns conceitos que permitem a criação fácil dessas soluções com base em Metadados: Ações São as unidades executáveis de um ponto de vista do usuário e podem obter métodos/operações de UI e Serviço. No exemplo anterior, você teria uma ação DisplayInformation que utilizaria a entidade/exibição JOURNAL4 Moldura de Ponte de Informações 17

18 Serviço em CustomerContactInfor mation e a vincularia ao controle do usuário que criamos para exibir as informações sobre o cliente. Transformações Como os dados do Serviço e os dados necessários aos elementos da UI podem não ser os mesmos, a IBF permite que sejam transformados. As transformações XSL, as expressões regulares ou os componentes CLR de chamada são todos modos suportados para transformar dados. Relacionamentos A sua solução pode ter relacionamentos, além dos fornecidos pelo Serviço. Pode também saber sobre os relacionamentos pelos Serviços. Como um exemplo, posso referirme a um Cliente em um dos meus aplicativos herdados com o meu Cliente em meu sistema CRM. Implantação e Segurança É possível pensar na IBF como um repositório central de descrição de Serviços, Metadados e elementos da UI que serão implantados dinamicamente como soluções usadas pelos componentes do cliente IBF. Nenhum código/metadado diferentes do cliente IBF precisa ser instalado em máquinas clientes. O componente do cliente IBF conecta-se ao Serviço de Metadados apropriado para obter todos os elementos de UI e Metadados necessários a um determinado contexto. Depois de possuir a descrição de Metadados e os elementos da UI, ele os executará juntamente com as chamadas de métodos de Serviço e construirá a UI e a experiência do usuário, conforme necessário. Como a IBF utiliza os componentes CLR para processar a UI que cria, além da segurança do.net, todos os componentes são obtidos, dinamicamente, através de download, armazenados em cache localmente e são executados em um ambiente de sandbox, de modo que não possam causar danos à máquina do cliente. Se você desejar que seus controles tenham um nível de controle mais alto, poderá assinar esses controles e aumentar os respectivos privilégios, utilizando Políticas de Segurança do.net padrão. Isso fornece um ambiente gratuito e robusto de implantação para suas soluções empresariais. Conclusão A IBF permite um alto nível de abstração e reutilização dos seus componentes da UI e Serviços, através da separação da camada de Serviços da camada da UI e vinculando-as através de Metadados. Isso fornece uma plataforma muito potente para a especificação de ativos de back-end em um empreendimento e a criação de soluções ao redor desses, que podem ser vinculadas ou combinadas sem codificação. Essa abordagem de Metadados acrescenta muita flexibilidade e permite um maior refinamento de soluções entre os cenários do cliente em uma abordagem dirigida de Metadados. A IBF permite construções de UI potentes para ajudar a criar uma experiência de UI completa e a integração com aplicativos do Office. Fornece também um ambiente gratuito e seguro de implantação de novas soluções, criadas além das tecnologias do.net. Fontes Para obter mais informações sobre IBF, consulte o site: Ricard Roma i Dalfó Microsoft Corporation ricardrd@microsoft.com Ricard Roma i Dalfó é o chefe de desenvolvimento do projeto de Moldura de Ponte de Informações. Está trabalhando em versões futuras de IBF e solucionando problemas de conectividade com aplicativos de Linha de Negócios. Estava anteriormente na equipe do Office e ajudou a lançar o Office 2000, XP e 2003 em várias funções de desenvolvimento. Possui pós-graduação em Ciência da Computação na Polytechnic University of Catalunya. JOURNAL4 Moldura de Ponte de Informações 18

19 Avaliando o Desempenho de um Design de Mecanismo de Transação Por Richard Drayton, FiS e Arvindra Sehmi, Microsoft EMEA O desempenho é provavelmente uma das métricas menos entendidas e mais citada de maneira incorreta no campo da computação atualmente. É uma prática comum entre os tecnólogos e fornecedores de aplicativos, referir-se ao desempenho como uma questão que pode ser, seguramente, deixada para um exercício de sintonia executado ao final de um projeto ou na implementação do sistema. Em contraste, o desempenho, como uma métrica para avaliação de sistemas, é considerado pela maioria dos usuários um dos fatores mais importantes e, certamente, críticos para avaliar a adequação de um sistema para um objetivo específico. Este artigo descreve um exercício de avaliação de desempenho efetuado em outubro de 2002 nos Laboratórios de ISV da Microsoft em Redmond, Washington como parte de projeto conjunto entre a Capco (Capital Markets Company) e a Microsoft. O projeto foi iniciado quando a Capco foi incumbida pela SXG (Singapore Exchange Limited) para fornecer uma avaliação de negócios e desenvolver uma arquitetura técnica para o utilitário de processamento centralizado de transações de intercâmbio. O utilitário deveria fornecer serviços correspondentes para pós-comercialização, interações de preestabelecimento de participantes nas áreas de comercialização de ações e renda fixa do mercado de Cingapura. O design do mecanismo principal de processamento foi efetuado seguindo um processo conhecido como SPE (Software Performance Engineering) [SMITH90, SMWIL02], no qual o exercício de validação e design completo foi modelado sob a perspectiva do desempenho em vez da perspectiva tradicional de design orientada do objeto. Os dois subsistemas foram criados pela Capco, conhecidos respectivamente como STP Bridge (uma infra-estrutura de comunicações e gateway de intercâmbio) e STE (um mecanismo de transações escalonável). Ambos foram usados no exercício de avaliação de desempenho. Figura 1: Modelo de Mecanismo de Processamento Conexão aos Serviços de Fluxo de Trabalho e Gerenciamento de Exceção Externa Processador de Fluxo de Trabalho (Gerenciamento de Exceção) Processador de Mensagens Processador de Mensagens Conexão de Participante (mensagens de chegada VPN) Componente PAM de Front End Componente de Encaminhamento de Chamada Processador de Mensagens Processador de Mensagens Processador de Mensagens Processador de Mensagens Processador de Notificação Conexão para Participantes (mensagens de saída VPN) e Serviços de Acordo Processador de Mensagens Processador de Mensagens Gerenciamento de Banco de Dados Conexão a Serviços de Banco de Dados Externo O desempenho não realizável é uma característica comum das avaliações de desempenho. JOURNAL4 Benchmark de um Projeto de Mecanismo de Transação 19

20 O Modelo de Processamento A arquitetura de STE foi baseada em componentes de processamento de mensagens, sem estado, acoplados livremente e distribuídos em uma rede enfileirada para alta escalabilidade, alto desempenho e taxas de transferência de transações extremamente altas. Para SGX, uma carga de processamento de transações de pior caso, de aproximadamente 600 mensagens por segundo, foi estimada de acordo com a análise do seu histórico de comercialização durante os anos anteriores, que resultou no mais alto nível de processamento exigido durante a crise financeira asiática em 1998, quando as transações de câmbio foram consideradas incomumente altas. Esse valor foi usado como a carga de processamento de linha de base/destino. Um destino de carga ampliada de mensagens por segundo foi definido para garantir a arquitetura; se bem-sucedido, teria espaço livre adequado para lidar com a volatilidade e o crescimento futuro do volume de negociações esperado. A decisão para utilizar componentes acoplados livremente, comunicando-se por meio de filas de mensagens em vez de APIs (interfaces de componentes mais tradicionais) exigem que as informações sejam transmitidas diretamente de componente para componente pelas próprias mensagens (fluxo de mensagens persistente) ou enriquecendo as mensagens à medida que são transmitidas através de diversas etapas de processamento (fluxo de mensagens temporal). Os próprios componentes do processamento são bastante independentes de outros e sem estado. Isso resulta em benefícios, como custo de realização e risco de desenvolvimento de software mais baixos para componentes individuais, juntamente com características de flexibilidade e escalabilidade mais altas do mecanismo de processamento como um todo, quando comparado às abordagens de desenvolvimento de aplicativo monolítico tradicionais. Os designs mais convencionais suportam apenas uma das duas dimensões de escalabilidade possíveis: scale-up potência de processamento aumentada por meio de recursos de processador melhorados (memória, CPU, etc.) ou scale-out potência de processamento aumentada por meio de um número ampliado de nós de processamento. Essa arquitetura suporta ambos tipos de ajuste de escala. A arquitetura global do mecanismo de processamento do STE é mostrada na Figura 1. Isso consiste em um número de componentes de STE com a responsabilidade de processar subáreas das atividades de negócios comerciais de base. O suporte do processo comercial fornecido pelo mecanismo é obtido por meio da quebra do ciclo de vida total de comercialização em um conjunto de mensagens atômicas relacionadas. Cada participante do mercado gera e recebe vários subconjuntos dessas mensagens atômicas durante a execução da comercialização. Uma implicação da arquitetura é que o próprio processo comercial deve ser capaz de ser representado por um conjunto comutativo totalmente assíncrono de operações, ou seja, deve ser capaz de processar mensagens em qualquer ordem. Isso elimina a necessidade de sincronizar o processamento de mensagens e as operações comerciais por meio do mecanismo, um tarefa que pode resultar em um aplicativo complexo e bastante lento. Observe que a sincronização é diferente da correlação de mensagens aplicada no processamento normal. Diversos outros requisitos de computação autônoma são fornecidos no modelo de processamento. Dentre estes estão as noções de sistemas de distrusting, operações de idempotent, gerenciamento de estado, correlação de mensagem, gerenciamento de contexto, operações de tentativa, cancelamento de mensagens e compensação de transações 1. O fluxo de mensagens de nível de negócios por meio do mecanismo de processamento é baseado, em parte, no modelo de execução proposto pela GSTPA (Global Straight Through Processing Association) que propôs um modelo de utilitário centralizado semelhante para acordos comerciais internacionais. O modelo de processamento foi admissível para solicitar links operacionais para outros utilitários centralizados como o GSTPA, de modo que os conjuntos de mensagens usados foram baseados, em parte, naqueles usados pelo GSTPA para fornecer a interoperabilidade no futuro 2. O processo comercial do mercado de Cingapura foi reduzido para um conjunto de quatro tipos de mensagens principais, a saber, NOE (Notice of Execution), ALC (Trade Allocation) NPR (Net Proceeds Allocation) e SET (Settlement Instructions). O processo adjacente desses tipos de mensagens envolveu um número de interações, levando a um conjunto de 35 variantes de mensagens que formou o modelo 1 A obra Autonomous computing: Fiefdoms and Emissaries [PHEL02] de Pat Helland publicada na Web fornece mais detalhes sobre o modelo de computação autônoma. 2 O GSTPA foi extinto, mas esse evento desagradável não tem impacto sobre a essência desse estudo. Além disso a proposta original suportada pelo GSTPA não pôde ser usada diretamente no mercado de Cingapura, logo, foram criados esquemas de processamento específicos para o mecanismo de processamento de SGX. JOURNAL4 Benchmark de um Projeto de Mecanismo de Transação 20