Design discussion for meeting on July 18

A reuniao com DocMagic (DM) esta marcada para sexta-feira, julho 18.

Assuntos na agenda:

1.       Modelo do banco – desenho completo das tabelas.

Feito. Publiquei os arquivos no xplanner (um arquivo do MS-Visio e um JPG). Também atualizei a task 15140. É importante ficar claro que durante a implementação ainda surgirão ajustes no modelo de banco, como a parte de armazenamento de documentos, por exemplo (sei que os documentos não serão gravados no BD, mas temos que guardar referências para eles).

2.       Plano para enforce integridade do banco (constraints?, …)

Seguinte:

a)      O modelo já contém foreign keys e identities (automáticos) para garantir parte da integridade dos dados.

b)      Outro mecanismo que será usado (em tempo de implementação) são as check-constraints, para garantir que dados inseridos ou atualizados nas tabelas não fujam às regras de negócio. Por exemplo, um e-mail válido tem que ter pelo menos um “@” e dois tokens depois desse arroba, separados por um “.” (isso é só um exemplo; a regra final pode não ser essa).

c)       Ainda utilizaremos triggers nas tabelas como forma de garantir integridade onde as check-constraints não resolverem.

Acabei de atualizar novamente o modelo, mas o sono não permite uma revisão criteriosa. Fernanda, conto com seu olhar crítico. Sua ajuda na madrugada foi muito importante e ainda é necessária.

3.       Lista de campos necessarios na criacao automatica de pacotes.

Os campos necessários para a criação automática de um pacote são:

-          Os itens obrigatórios da tabela de propriedades adquiridas

o   LoanNumber

o   PropertyAddress

o   PropertyCity

o   PropertyState

o   PropertyZipCode

o   ReleaseToEscrow

o   ReleaseToBorrower

-          Os campos obrigatórios da tabela de mutuários (Borrowers)

o   BorrowerLastName

o   BorrowerFirstName

o   BorrowerEmail

o   Last4Social

o   Address

o   City

o   Sate

o   ZipCode

-          Os campos obrigatório para a tabela de documentos

o   LegalDocument

o   NeedsNotarization

-          Um campo com valor único para o Branch User

o   Branch user login (desse campo encontramos o registro)

- Dados de Company

- Dados de Branch

- Dados de Escrow

4.       Numero total de horas (precisamos comecar a discutir isso o quanto antes, pois as horas listadas no xplanner precisam ser ajustadas considerando o Finance).

Alessandro fará uma revisão e reorganização dos itens dispostos no XPlanner durante a manhã. O combinado com ele é que no início da tarde ele terá uma nova proposta de número de horas. O trabalho dele é refinar as tasks que estão cadastradas no XPlanner e dessa forma conseguir estimar melhor os prazos, pelo menos na questão da programação. Ele levará em consideração o que pode ser aproveitado do finance e também tem como preocupação colocar carga horária de um programador mortal e não de um Alessandro.

Ou seja, teremos esse item 4 resolvido durante o dia (depois do almoço).

Estarei na empresa pela manhã mas ficarei on-line. Apesar de estar oficialmente de férias, na prática ainda estou devendo a entrega de um job na empresa e pretendo concluí-lo antes do almoço.

5.       Discutir web services

A idéia é fornecer os serviços do eClosing no nível de RPC por causa de compatibilidade com os sistemas da DM, mas também forneceremos interfaceamento em SOAP com XML e/ou HTML, conforme necessidade das entidades externas (ex.: eVaulting, Recorder, etc.)

6.       Discutir como estamos planejando liberar o produto para DM pra teste e consideracoes.

Conforme conversamos ontem, a idéia é implementarmos as partes de Administração, criação de pacotes, gerência de pacotes e Web Services. Aí liberamos a primeira fase de testes para a DM, pois eles só poderão testar quando tivermos o Web Service por causa da automação deles.

7.       Discutir criptografia dos dados e documentos.

Sugiro utilizarmos o algoritmo BlowFish para criptografar os dados críticos, incluindo os documentos. Todos os documentos serão armazenados fora do banco de dados, mas serão guardados criptografados. Esse algoritmo (blowfish) é reversível, rápido e seguro para esse uso. Acho que devemos utilizar um outro algoritmo (irreversível) para as senhas. Isso é mais indicado para o caso de senhas e passa para o nosso big boss a idéia de segurança adequada. Com o algoritmo irreversível não é possível ver senha de ninguém no banco de dados. Se alguém perder a senha, terá que gerar outra porque será impossível recuperá-la.

8.       Discutir ideias de escalabilidade.

Da forma como está pensada, a solução não terá problemas em tratar um pacote ou um milhão de pacotes. A modelagem do banco de dados já prevê o possível uso de MUITOS registros.  Basicamente os pontos de observação sobre a escalabilidade são o banco de dados, os servidores de hospedagem e o storage.

Sobre o banco de dados: o SGBD escolhido (MySQL) suporta grande volume de informações e de transações concorrentes. Não tenho medo dessa escolha e ainda temos a possibilidade de, migrarmos o SGBD para um SQL-Server sem grandes traumas por causa do uso do Hybernate. Então, caso o MySQL seja alvo de questionamentos, podemos mudar para o SQL-Server e isso, certamente, dará tranqüilidade quanto à escalabilidade.

Quanto aos servidores: é importante que haja um sistema de load balance tanto nos servidores web quanto nos servidores de banco de dados. Isso deve ser feito no ambiente de hosting e há várias formas de fazer. Há ferramentas pagas e há também algumas gratuitas para load balance. O pessoal de infra-estrutura de hosting certamente conhece algumas. Esse ambiente terá que crescer à medida em que a quantidade de usuários e acessos simultâneos ao sistema for crescendo. Em outras palavras: é importante termos um cluster de banco de dados e um de web-server. Esse cluster ganhará novos “nodes” conforme a carga for aumentando.

Sobre o storage: a base de dados (do MySQL ou SQL-Server) deve estar armazenada em um storage com espaço suficiente para crescer sem riscos para o sistema. Isso também é missão do serviço de hosting.

Com esses cuidados teremos escalabilidade suciente para grande quantidade de clientes, sem medo.

9.       Discutir ambiente para deployment e estrutura do que iremos entregar (1 war, varios; isso, na verdade, ja foi questao da DocMagic, quando discutindo seguranca, mas foge ao meu  conhecimento).

Vou consultar Alessandro, mas a idéia inicial é publicarmos sempre 1 war e deixar o tomcat se virar com o resto. A área de trabalho do tomcat deve estar protegida no servidor para que somente os usuários do próprio tomcat e o root possam acessá-lo. O serviço de deployment do tomcat também deve estar protegido com senha forte e o acesso deve ser feito por VPN.

                Acabei não conversando isso com Alessandro. É importante ouvir a opinião dele ainda.

10.   Outros (sei que irao surgir mais detalhes a serem discutidos).

Sem comentários agora.

Notei que offline signing estava em um lugar nao esperado http://70.114.222.3:8080/xplanner/do/view/userstory?oid=15132. Acho que esta funcionalidade (que sera uma aplicacao completa por si so), precisa ser melhor detalhada a nivel de ideias .

Algumas outras funcionalidades ainda nao listadas no xplanner sao comunicacoes com eVaulting, Recorder, Investor, MERS.  

Fernanda, você consegue nos ajudar a preencher esse buracos? Tenório, você se candidata?

Tenório está cuidando disso neste momento.

Respondo que foram criadas atividades para cada uma das comunicações esperadas. Todas possuem prioridade 2 por poderem e deverem ser estudadas a partir de agora, pois temos um caminho desconhecido até a definição do que deverá ser desenvolvido para cada caso de integração, que poderá ser visto a partir de então, junto às empresas detentoras da informação que precisamos. Por isso, nenhuma das atividades possui estimativa de tempo.