Pagamentos remotos confiável inter-corporativos

Transcrição

1 Money-Link: Pagamentos remotos confiável inter-corporativos Relatório de projeto Apresentado em Objetos Distribuídos'98, Curitiba, 3-Dez-98 Hernán Astudillo 1 Ciência de Computação, Universidade de São Paulo ha@ime.usp.br, hernan@acm.org 1 Identificação 2 2 Descrição 2 3 Situação 2 4 Dimensão 2 5 Ambiente operacional 3 6 Características técnicas da solução 3 7 Auto-avaliação 5 8 Anexo: Derivação da arquitetura do sistema 5 9 Anexo: Informações para contato 5 1 Dr. Astudillo is professor of Ciência de Computacão, MAC-IME, Universidade de São Paulo, Rua do Matãao, 1010, CEP , São Paulo, SP. He was until recently Lead Architect of the Object Practice of MCI Systemhouse, a large-systems integrator.

2 1 Identificação Money-Link: Sistema distribuido confiável de pagamentos inter-corporativos. 2 Descrição Este relatório descreve um sistema recentemente desenhado (projetado) para automatizar os pagamentos feitos por clientes (bancos e empresas) a uma larga corporação sediada nos Estados Unidos. A corporação tem um grande número de instituições sob ela, e elas recebem pagamentos substanciais diariamente. No modelo operacional prévio, os pagamentos eram feitos geográficamente, tendo um banco receptor para cada região do país; cada banco leva suas próprias contas para a corporação. Ainda que o sistema de contabilidade corporativo é centralizado, não havia maneira de conhecer a situação global instantânea (o que impede estimativas de cash e futuros, entre outras coisas); e tampouco existia um mecanismo centralizado de reconciliação de contas. O projeto resolveu estes problemas criando um sistema lógicamente centralizado, mas físicamente descentralizado. Isto permite descentralizar pagamentos por meio da rama corporativa que corresponda, e a notificação imediata à tesouraria corporativa, para análises históricos como estimativas e predições. A arquitetura de Money-Link é distribuída, consistente num mediador de pagamentos de alta disponibilidade (OLTP, distribuído, replicado, e "load-balancing"), e um centro de análise de alta capacidade (centralizado, replicado, e "fault-tolerant"). 3 Situação O projeto já completou as fases iniciais de especificação de requisitos, análise, e definição da arquitetura global. A fase atual é de projeto (design) detalhado e implantação de protótipos. 4 Dimensão Para satisfazer simultâneamente as duas prioridades do projeto (a saber, acelerar pagamentos, e manter uma imagem global atualizada), o sistema consiste de dois "hemisférios": centro de análise, e mediadores de pagamento. 1. O centro de análise mantêm uma "imagem" do mundo, incluindo pagadores, instituições e bancos, e tem fortes requisitos de segurança e integridade. Por tanto, ele foi replicado tanto geográficamente (duas cidades) quanto internamente (cada hemisfério tem redundância interna, com dois sítios por lóbulo).

3 2. O mediador de pago só processa os pagamentos, enviando aos bancos receptores e permitindo "tracking" inicial (ou seja, pre-envio), e tem requisitos de disponibilidade e segurança 2. Por tanto, ele foi duplicado geográficamente (pelo menos um nodo para cada região geográfica) mas não internamente (o estado interno inclui só o estado dos pagamentos ainda não processados). Uma métrica de dimensão mais interessante: o custo do hardware e software offthe-shelf do projeto são inicialmente estimado em uns 5 milhiões de US$. O custo do software ad-hoc é muito maior. 5 Ambiente operacional O software operacional do sistema difere nos dois hemisférios: 1. O centro de análise consiste principalmente duma instalação de Oracle 8 Parallel Server (banco de dados distribuído). O sítio primário tem uma plataforma de Sun Clusters com 800 GB RAID, e o backup tem só 200 GB. 2. O mediador de pago (que será replicado 38 vezes, segundo nossas previsões) consiste principalmente duma instalação de Oracle 8 comum, numa plataforma Sun Application Server. Além destes dois tipos de sítio, o sistema inclui clientes operando nos desktops dos usuários finais. Para minimizar impacto neles e maximizar nossa flexibilidade, a plataforma destes clientes é a Web mesma, a saber, Java applets. A comunicação entre as peças do sistemas tem dois aspectos: 1. Entre os dois hemisférios, as transações coletadas pelos mediadores de pago são: 1. submitidas aos bancos receptores, usando protocolos bancários (como ACH e EDT) 2. informadas ao centro de análise, usando middleware orientado-a-mensagem, MQ Series. 2. Entre os usuários e os dois hemisférios (ou seja, pagamentos e tracking nos mediadores de pago, e acesso corporativo no centro de análise): 1. a comunicação é feita com CORBA, usando clientes e ORB da Visigenic. Os serviços fundamentais da aplicação (segurança, monitoramento, cadastramento de usuários, certificados, etc.) são implementados com serviços CORBA. 6 Características técnicas da solução É difícil descrever simplesmente um projeto tão complexo, cuja arquitetura conceitual (sem detalhes técnicos) precisou de 124 página para ser descrito. 2 Ou seja, é prioritario que os clientes possam iniciar um pagamento em qualquer momento, e claramente tem que ser seguro.

4 Porém, alguns fatos podem ser mencionados que ajudem a avaliar o interesse deste projeto para OD'98. Processo de Desenvolvimento: O desenvolvimento é iterativo e incremental, começando com uma arquitetura conceitual e um protótipo, e entregando resultados intermédios como peças maiores e funcionalmente completas. A fase inicial consistiu em duas partes: primeiro, um "First Strike Team" aplicou uma metodologia baseada em eventos e casos de uso (própria da MCI Systemhouse) para descrever os requisitos; de aí, os arquitetos aplicaram a metodologia neca 3 para produzir uma arquitetura conceitual. Linguagem de Modelagem: O análise foi descrito usando eventos e casos de uso, com uma extensão proprietária de MCI Systemhouse. A arquitetura foi descrita usando camadas para mostrar a derivação; as camadas são hemisférios, componentes, módulos, e serviços. Design Patterns e Frameworks: Em geral, padrões e frameworks não são adequados para descrever e razoar sobre as camadas superiores da arquitetura (o enfase destas idéias é sobre peças pequenas e discretas, não componentes e "quality of service").razoar Por tanto, eles foram usados só para razoar sobre os módulos de software; uma ferramenta muito útil é o Pattern Applicator, da Blueprint Technologies. Ferramentas CASE: As camadas mais baixas da arquitetura (módulos de software) foram descritos com Rational Rose. Partes do protótipo foram geradas com a mesma ferramenta, em Java. As camadas superiores da arquitetura foram ilustradas com ferramentas ad-hoc. Linguagens de Programação: Java, JavaScript e HTML para clientes dos usuários; SQL e Oracle para processamento de dados; varias linguagens para ferramentas ad-hoc (por exemplo, o reporting engine). ORBs: VisiBroker. Alguns dos serviços CORBA usados são: Event, Alert, Persistence, Location, Naming, Translation, Transaction, Queue and Notification. Os últimos são implementações internas da corporação; o Persistence é (obviamente) reimplementado; os outros são os padrão. Transações Distribuídas: dado que transações distribuídas de larga escala são problemáticas de implementar e de manter, nossa arquitetura dividiou a transação tipo (desde começo de pagamento a verificação e registro) em três partes, todas distribuídas e atômicas: o pagamento mesmo (ocorre no mediador de pagamento), a notificação ao centro (atômico pelo mecanismo de message queuing da Oracle), e a transação já no centro (atômica pelo Oracle intra- e inter-site). Por tanto, uma falha dum pagamento pode ser percebida pelo usuário, sem que o sistema central mantena informação sobre ela. 3 Ainda seendo desenvolvida pelo autor deste relatório, quem for o Arquiteto Chefe do projeto na época.

5 Message Queuing: foi usado para implementar a comunicação entre os mediadores de pagamento e os nodos centrais. 7 Auto-avaliação O projeto Money-Link contribui a automatizar dois "business processes": arrecadação de fundos, sem importar locação ou tempo; e análise histórico do ingresso de fundos (p.ex. predição e "position management"). A distinção destas duas funções permitiu oferecer uma arquitetura completamente distribuída, com lugar para incrementos futuros na base de usuários, na confiabilidade ou na disponibilidade. Nosso projeto maximiza o uso de tecnologias padrão (serviços CORBA, SQL standard, plataforma Web) para minimizar a dependência de provedores específicos e para minimiza a dirupção aos usuários finais, um aspecto chave na aceitabilidade dele. Porém que ainda não existem metodologias claras para derivar arquiteturas de larga escala dos requisitos, o projeto desta complexidade é uma escola para formar futuros arquitetos. 8 Anexo: Derivação da arquitetura do sistema A derivação da arquitetura está documentada (em inglês) num documento auxiliar enviado separadamente. Esse documento contem informação da identidade verdadeira do cliente e do sistema sob construção, e por tanto não posso fazer ele muito divulgado (na forma atual). Porém, eu envio para vocês usar na avaliação do projeto, se precisar, e talvez como fonte de idéias. 9 Anexo: Informações para contato Este relatório foi preparado por Hernán Astudillo, quem é atualmente Professor- Doutor no Departamento de Ciência de Computação da Universidade de São Paulo. Até recentemente ele foi o Lead Architect da Object Practice de MCI Systemhouse, um integrador de sistemas sediado nos Estados Unidos. Nessa capacidade, ele projetou (designed) e/ou supervisou a construção de vários projetos de larga escala, incluindo o aqui descrito. Atualmente ela está condensando essas experiencias numa metodologia de derivação de arquitetura. Seus interesses profissionais são tecnologia de objetos, engenharia de software, e sistemas distribuídos; e especialmente a interseção delas, a arquitetura de sistemas de objetos distribuídos. Contato: Hernán Astudillo Ciência de Computação/Universidade de São Paulo MAC-IME, Rua do Matão, 1010, São Paulo, SP, Brasil fone: fax: ha@ime.usp.br URL: