Web ou Desktop ou mista para um sistema?

Programação Arquitetura
#1

Galera,

A pergunta “Web ou Desktop” muitas vezes vem para trazer um flood de respostas e, algumas vezes, brigas.
Já adianto que não é essa a intenção e gostaria que respeitassem.

A situação é que temos sistemas legados na empresa (DOS) extremamente estáveis.
Depois de uma longa avaliação estratégica e com clientes e clientes em potencial descobrimos que apenas criar uma interface nova (web por exemplo) para os sistemas legados não é uma solução. O problema é que os sistemas, ao longo do tempo, se tornaram repletos de código inútil, com falhas de conceito, difíceis de manter e com altíssima complexidade, fora a ausência de muitos aspectos importantes que precisaríamos para os sistemas na atualidade.

Sendo assim, enfrentamos a pergunta básica: Web ou Desktop?
Depois de muito filtro, estudo e testes, escolhemos o que usar para desktop e o que usar para web mas ainda não escolhemos qual caminho seguir.
Então resolvi perguntar com que os desenvolvedores por aí afora estão trabalhando e qual a percepção do mercado.

A seguir temos uma lista do que vai existir no sistema:

  • Relatórios extremamente grandes com muitas imagens em frente e verso. Diversos cenários apresentam cerca de 80 a 160 mil páginas de imagens (imagens, códigos de barra, linhas e texto) em um relatório já existente atualmente.
  • Gráficos financeiros e de acompanhamento.
  • BI com possibilidade de escrita e armazenamento para uso posterior de query, bem como criação e armazenamento dos relatórios para uso posterior.
  • Integração com componentes periféricos como balanças (tanto as pequenas, de supermercado, quanto as grandes, de caminhão), catracas, impressoras matriciais (precisa de impressão diretamente matricial), leitura de cartão/token de assinatura digital e outros.
  • Extrema usabilidade e amigabilidade do sistema. Simples posto, o usuário precisa “ter um botão mágico que faz tudo”. Claro que isso não existe, mas acho que com essa frase eu passo a idéia de quanto “stupid-proof” o sistema precisa ser.
  • Controle de segurança. Diversos dados confidenciais (histórico financeiro, nome completo e endereço, dados pessoais e de familiares) estarão em trânsito. Claro que não tem como garantir 100% de segurança nunca, mas preciso de algo melhor do que simplesmente um básico login/senha na tela/página inicial do sistema.
  • Excelente performance. O sistema precisa ter performance até a última gota. Sim, isso conflita com o item imediatamente anterior (segurança) mas preciso de um sistema que tenha uma performance realmente boa. Isso é um requisito imprescindível.
  • O sistema precisa atender a demandas diferentes. Preciso de um sistema que atenda a uma demanda de um cliente com 10 usuários com a mesma sensação de performance, confiabilidade, segurança e estabilidade de um outro cliente com 700 usuários simultâneos. Escalabilidade é necessário.
  • O cliente não pode investir muito em infraestrutura. Boa parte dos clientes já possuem uma infra bem elaborada e mantida. Não posso exigir uma completa substituição para, por exemplo, links com fibra e tudo mais. Preciso de algo que cause o menor impacto na infra possível. Não há problema, no entanto, em realizar algumas (não muitas) modificações no servidor e/ou nas estações.
  • Os clientes possuem infra variada. Em sua maioria são clientes com estações e servidor Windows XP (quando muito, Windows 2003 no servidor). Mas existem alguns clientes-chave (que não podem ser descartados) com Linux na infra inteira. Browsers, no entanto, variam muito. Mesmo. Em um mesmo cliente já detectamos 3 versões distintas do Internet Explorer e 2 do Firefox.
  • Não temos experiência vasta nem com java desktop nem com java web (ou seja, qualquer um dos mundos teríamos uma curva de aprendizagem). No entanto eu já trabalhei com java web e com java desktop em projetos pequenos e protótipos e tenho conhecimento de frameworks do java. O ponto é que não temos uma famosa “cultura anterior” para tentar seguir adiante. É, sim, uma mudança completa.

São muitos pontos, sim.
Não peço que respondam todos (se puderem, agradeço muito).

Quero opiniões.
Consultei alguns posts anteriores, até alguns bem velhos aqui no fórum, para tentar refletir sobre uma possível saída.
Como não existe uma demanda pronta do tipo “tem que ser desktop” ou “tem que ser web”, ficamos na dúvida.
Nossos clientes no geral não saberiam dizer. Isso foi uma grande maioria na pesquisa. Os que responderam ficaram basicamente empatados (houve uma tendência muito leve para web mas acredito eu, muito motivada por “ah, é web, vai ser bacaninha”).
O detalhe é que todos aqui são maduros o suficiente para saber que um sistema não é feito para ser “bacaninha”.
Então, fica a questão.

Por favor, opiniões?

Obrigado.

#2

Ao que me parece, muitos dos seus requisitos apontam para um sistema desktop, entre eles, alto volume de dados (1° item), necessidade de segurança, escalabilidade e performance, e poucas alterações na infra.

Eu, particularmente, faria ele desktop. Não tenho muita experiência (na verdade, tenho puquíssima experiência) mas essa é minha opinião.

#3

Eu diria para pensar uma abordagem diferente,

criar um modulo que contenha todas as regras de negocio, um EJB quem sabe. e instala-lo num servidor, operações com dados, validações, tudo nesse EJB (Pode ser um VRaptor com RESTFull também).

Apartir dai é interface, vc cria uma interface desktop para acessar o EJB e uma WEB, vc tem 2 soluções para um mesmo produto e pode atender a mais clientes,se for o caso.

Lembrando que a camada web/desktop é so interface e iteração com o usuário. todo o backend ficaria no EJB.

#4

[quote=Felagund]Eu diria para pensar uma abordagem diferente,

criar um modulo que contenha todas as regras de negocio, um EJB quem sabe. e instala-lo num servidor, operações com dados, validações, tudo nesse EJB (Pode ser um VRaptor com RESTFull também).

Apartir dai é interface, vc cria uma interface desktop para acessar o EJB e uma WEB, vc tem 2 soluções para um mesmo produto e pode atender a mais clientes,se for o caso.

Lembrando que a camada web/desktop é so interface e iteração com o usuário. todo o backend ficaria no EJB.

[/quote]

Tirou as palavras da minha boca! Eu ia sugerir isso abraços, AS.

#5

Tambem concordo com o Felagund , ou seja uma arquitetura híbrida.

Só alertaria para dois detalhes:

  1. Ejbs lhe concede vários recursos, porem como tudo isto também tem prêço; considere utilizar o Spring junto com algum web server.

  2. Como vc disse que existem muitas diferenças nas versões dos browsers dos clientes tome bastante cuidado com a escolha do framework para interface web, vc poderá ter sérios problemas de compatibilidade com o código gerado por eles. As vêzes é melhor fazer uma coisa simples e até com um pouco de dificuldade mas com certeza de execução na maioria dos ambientes.

flws

#6

[quote=Felagund]Eu diria para pensar uma abordagem diferente,

criar um modulo que contenha todas as regras de negocio, um EJB quem sabe. e instala-lo num servidor, operações com dados, validações, tudo nesse EJB (Pode ser um VRaptor com RESTFull também).

Apartir dai é interface, vc cria uma interface desktop para acessar o EJB e uma WEB, vc tem 2 soluções para um mesmo produto e pode atender a mais clientes,se for o caso.

Lembrando que a camada web/desktop é so interface e iteração com o usuário. todo o backend ficaria no EJB.[/quote]

Então, havíamos pensado sobre algo do tipo por aqui…
Criar um servidor de aplicação com a camada de domínio e, a partir daí, desenvolver uma aplicação desacoplada, na qual, como foi bem colocado, seriam apenas duas “cascas” (interfaces), já que o restante estaria integralmente pronto e reutilizável.

[quote=fantomas]Tambem concordo com o Felagund , ou seja uma arquitetura híbrida.

Só alertaria para dois detalhes:

  1. Ejbs lhe concede vários recursos, porem como tudo isto também tem prêço; considere utilizar o Spring junto com algum web server.[/quote]

Sim, isso seria considerado.
Precisamos de desacoplamento e o Spring vai ajudar nisso.
Hibernate também, em outros aspectos.
Fora isso, já mapeamos um framework-base para interfaces comuns e de integração, permitindo que nosso sistema opere com outros sistemas de mercado (e vice-versa) e permitindo também que nossos sistemas legados possam se comunicar com nossos sistemas novos (e vice-versa).
Além disso o nosso framework-base também cria um isolamento tal que, se necessário, posso substituir um módulo da aplicação por um sistema de terceiros (claro, existem restrições, mas a idéia é poder, por exemplo, substituir um módulo CRM nosso por um SugarCRM ou outro, sem quebrar o funcionamento do sistema).

[quote=fantomas]2) Como vc disse que existem muitas diferenças nas versões dos browsers dos clientes tome bastante cuidado com a escolha do framework para interface web, vc poderá ter sérios problemas de compatibilidade com o código gerado por eles. As vêzes é melhor fazer uma coisa simples e até com um pouco de dificuldade mas com certeza de execução na maioria dos ambientes.

flws [/quote]

Também temos este problema.
GWT é uma opção bem interessante mas ao mesmo tempo, é uma faca de dois gumes.
O uso intensivo de JavaScript pode causar problemas de performance em ambientes com muitos usuários simultâneos e com infra restrita.
Aparentemente nossa melhor opção será mesmo criar a interface do zero, assim como você comentou: “uma coisa simples e até com um pouco de dificuldade mas com certeza de execução na maioria dos ambientes”.
Criar CSS e JavaScript e outros para funcionar em múltiplos browsers não é fácil mas talvez seja melhor que usar um framework inteiro.

De qualquer forma, este é outra discussão, que ainda será levada em pauta.
O importante agora é tentar mapear uma arquitetura de base (web ou desktop ou mista) para o sistema.

A saída pelo servidor de aplicação parece ser a melhor.

Obrigado pelas respostas.

#7

Cara, já tive experiência em projetos web e desktop.

Pensando em produtividade, complexidade e java, EU faria algo web com vraptor 3. E SE realmente precisasse de algo desktop, o client desktop poderia consultar o servidor web via rest.

Pontos interessantes a se pensar:

  • Acho que a principal diferença entre usar um client desktop ou um client web (browser) é que se for web vc não precisa se preocupar com atualização. Basta alterar no servidor web e já foi.
  • Acho que as tecnologias para desenv. para web estão mais maduras do que pra desktop;
  • Creio que os usuários hoje em dia já estão muito mais acostumados a usar algo web do que desktop, e isso é um grande diferencial. O usuário tem que gostar de usar o produto;
  • Pense na possibilidade de usar Spring no lugar de EJB;
  • Quanto a clientes com diversos browsers, para o javascript, um framework estilo jquery já elimina boa parte destas preocupaçõe. Em relação ao CSS, se vcs não tiverem um webdesigner, tenta comprar um layout já pronto. Hoje em dia é baratinho e existem diversos sites que vendem.

Enfim, são apenas sugestões! Espero ter ajudado!!

#8

[quote=bacofrb]Cara, já tive experiência em projetos web e desktop.

Pensando em produtividade, complexidade e java, EU faria algo web com vraptor 3. E SE realmente precisasse de algo desktop, o client desktop poderia consultar o servidor web via rest.

Pontos interessantes a se pensar:

  • Acho que a principal diferença entre usar um client desktop ou um client web (browser) é que se for web vc não precisa se preocupar com atualização. Basta alterar no servidor web e já foi.[/quote]

Sim, este é um ponto-chave a ser considerado. Diversos cenários não vão causar qualquer diferença mas em alguns clientes pode ser necessário criar toda uma política para atualizar o sistema, caso ele seja desktop. Isso gera mais demora, mais complicação, mais responsabilidade do nosso lado e, claro, mais dor de cabeça no geral.
Sem considerar que o que ocorre se eu atualizar o SGBD e esquecer uma determinada estação?
Ou vice versa?
Enfim…

Neste ponto eu não concordo nem discordo. Eu realmente não sei palpitar muito sobre a maturidade mas considerando milhões de aplicações tanto em desktop quanto em web, acho que em nível de maturidade as duas tecnologias é muito alto.
Compete muito a nós, como arquitetos, desenvolvedores e analistas, estruturar bem o sistema e como ele será construído. Fora isso, sobra apenas puro código, que é igual em ambos os casos.

Então, isso também é complicado.
Essa é uma das nossas questões, em parte.

Porque existem itens que se beneficiam muito sendo desktop ao invés de web, e outros se beneficiam em web.
Os clientes estão habituados a trabalhar. E querem trabalhar bem.
Tirando o modismo de lado, o que resta é o sistema, e é isso que preciso definir de forma concreta.
O visual desktop também não precisa ser esse visual tradicional old-style que todos estamos acostumados. O problema que já tivemos com web são dois:
[list]Barras de menu consomem muito da janela do usuário e isso atrapalha o sistema, além de causar problemas de estabilidade no browser que podem inclusive afetar a estabilidade e segurança do sistema.[/list][list]O desenvolvimento web tem que ter uma resolução de “destino”. Claro que você altera uma série de tópicos para tentar dinamizar isso e melhorar o funcionamento em outras resoluções mas não consegue o mesmo efeito do desktop.[/list]
Estas duas questões estão pesando bastante, principalmente em itens do sistema que requerem cuidados especiais com visual e apresentação.
Outro problema dos browsers é a maldita pop-up e os bloqueadores existentes. Ou seja: ou eu uso intenso javascript para mostrar janelas (e que já vi sendo bloqueado em inúmeros browsers) ou eu uso applet, que requer instalação e autorização do usuário (que nem sempre vê a barra de applet).

Eu estava pensando em ambos na verdade.
Cada um com seus pontos fortes.
=)
Mas sim, usar o Spring no lugar do EJB também funciona muito bem. Já vi soluções muito bacanas assim e já pude “brincar” com elas também… xD

Totalmente fora de cogitação.
Não temos um designer, infelizmente (3 funcionários na empresa com uma vasta cartela de clientes), mas não vamos contratar designer (pelo menos não em um primeiro momento, embora o sistema será desenvolvido com css e tendo sempre em mente uma presença de designer posterior) nem adquirir templates.
No entanto, criamos algo como um esqueleto ou master-page que já tem os itens posicionados e já tem as definições padronizadas de layout para uso no restante do sistema.
=)

Sim sim, bastante na verdade.
É exatamente o que eu estava querendo. Sugestões. Opiniões.
Ter uma noção do que está rolando fora da empresa aqui antes de tomar qualquer decisão.

Muito obrigado =)

#9

Quanto aos pop-ups, você poderia tentar usar um modal (ex: http://www.tidbits.com.br/click-modal-plugin-de-jquery-para-fazer-modal-lightbox) como alternativa.

#10

Por favor, releia:

Plugin jQuery nada mais é que um mega javascript pronto que você usa na sua aplicação.
Os principais problemas com Javascript são:
[list]Tráfego do arquivo javascript (consumo de rede)[/list][list]Problemas de leak (memória) e falhas de código com dificuldade de debug[/list][list]Não funcionam se o browser estiver com scripts desabilitados[/list]
As principais vantagens são:
[list]Já existe uma extensa biblioteca JS na internet[/list][list]Eu posso utilizar bibliotecas como GWT ou outros para interface baseado em classes (mais fácil de montar)[/list][list]Tenho melhor usabilidade e interação com usuário[/list]

Mas obrigado pelo comentário…

Acho que o jeito mesmo vai ser pelo servidor de aplicação com a camada de domínio isolada, e acessar isso por interfaces diferentes.
Assim eu tiro o melhor proveito de cada tecnologia…

#11

Questão do banco de dados e estrutura de OS dos servidores vocês já tem definição?
Os browsers mais novos em testes, tendem a diminuir o problema com layout de CSS,
já o javascript depende muito das configurações do navegador, não sei até onde vai o trabalho de vocês e até
onde é trabalho da TI do cliente.
O designer no grupo acho essencial, pra evitar muita quebra de cabeça dos desenvolvedores.

Há alguns outros pontos:

Aplicações web tendem a exigir menos máquina do cliente. Pois o processamento está do lado do servidor.
Javascript processa do lado do cliente, o que se pode fazer um balanceamento de carga, entre o que será responsabilidade do cliente,
e o que será do servidor.

Se o sistema for hospedado por vocês, poderiam criar um CPD parrudo.

Se o sistema for do lado do cliente, e eles tiverem uma boa infra, o sistema web pode rodar na intranet, melhorando questões de segurança.

Ou ainda utilizar VPN.

Bom esta é minha contribuição.

#12

Suas perguntas:

1 - O acesso a qualquer tipo de recurso é estritamente interno? não há (nem haverá a curto/médio) prazo a necessidade de uso remoto? outros prédios/filiais, pessoas em viagem que precisem de acesso.

Eu acho que hoje a tecnologia web evolui muito mais rápida que desktop, eu num primeiro momento iria com certeza de desenvolvimento web, com VRaptor ou Rails.

Se for pra fazer uma arquitetura baseada toda em EJBs (que eu particularmente não gosto), não vejo porque não ter acesso web ao invés de desktop, vc teria uma arquitetura web pronta e teria que fazer acesso desktop que é mais complicado de desenvolver, manter e atualizar nos clientes.

Meu voto vai para desenvolvomento web.

2 - Quem é que vai ler um relatório com 80 a 160 mil páginas de imagens??? rs

[]s

#13

[quote=lordtiago]Questão do banco de dados e estrutura de OS dos servidores vocês já tem definição?
Os browsers mais novos em testes, tendem a diminuir o problema com layout de CSS,
já o javascript depende muito das configurações do navegador, não sei até onde vai o trabalho de vocês e até
onde é trabalho da TI do cliente.
O designer no grupo acho essencial, pra evitar muita quebra de cabeça dos desenvolvedores.

Há alguns outros pontos:

Aplicações web tendem a exigir menos máquina do cliente. Pois o processamento está do lado do servidor.
Javascript processa do lado do cliente, o que se pode fazer um balanceamento de carga, entre o que será responsabilidade do cliente,
e o que será do servidor.

Se o sistema for hospedado por vocês, poderiam criar um CPD parrudo.

Se o sistema for do lado do cliente, e eles tiverem uma boa infra, o sistema web pode rodar na intranet, melhorando questões de segurança.

Ou ainda utilizar VPN.

Bom esta é minha contribuição.[/quote]

Então…

Questão de OS dos servidores é conforme eu comentei inicialmente.
A maior parte dos clientes possui um Windows XP em uma máquina mais robusta e “isso” é o servidor deles.
Alguns possuem Windows Server 2000 ou 2003.
Eu não posso nem vou exigir do cliente que ele migre para uma ou outra tecnologia, ou que modifique sua infra a menos que seja realmente necessário.

Quanto àquela famosa sugestão “então porque não coloca Linux?”, bom, eu não coloco isso em hipótese alguma. Esta é uma decisão do cliente. Ele tem que tomar esta decisão por conta própria. Quando muito eu faço o comentário oralmente, e apenas. Imagine ele investindo em mudança do servidor para Linux e depois descobrir que X ou Y não é compatível? A culpa é dele, sim, mas a imagem que queima é a nossa.

Browsers mais novos tendem a funcionar com relativa semelhança.
Embora eu ainda fique com um post no StackOverflow que comentava como “… os browsers parecem determinados ou até se sentem incentivados a NÃO seguirem os padrões propostos pela W3C …” e isso se reflete com outro comentário no mesmo post e que já temos conhecimento de que vai acontecer: “… a renderização das páginas e do CSS muda entre os browsers e em um mesmo browser, entre suas versões …”.

Por outro lado, temos problemas com hardware em sistemas desktop.
Por isso que, conversando com um amigo que é consultor de arquitetura de sistemas, chegamos à conclusão de que na verdade é uma troca. Você troca os problemas de hardware local por problemas de compatibilidade entre browsers ou vice-versa.

A responsabilidade da TI no cliente varia muito e nosso público alvo (que abrange de micro empresas até empresas de grande porte) é muito diversificado para termos uma resposta direta.
Realizamos algumas pesquisas e percebemos, por exemplo, que em um dos nossos clientes a infra já está inteiramente montada e estruturada, existe um servidor 2003 constante atualizado com presença de um técnico especializado 24h. Sofrem auditoria constante e já possuem uma estrutura que requer que eu utilize SQL Server como banco de dados.
Por outro lado, um outro cliente pontuou que sua infra está pronta e que possuem 3 sistemas operacionais diferentes (linux, windows e mac), abrangendo setores diferentes da empresa. O servidor deles está mantido por uma empresa da área, é um HP com RH Linux.
Ainda na mesma balança, clientes pequenos mas que estão conosco há décadas e que são, também, parte fundamental da nossa cartela possuem de uma a 2 máquinas, geralmente com Windows XP pirata e desatualizado. Um deles ainda está com IE 6 (sim, pasmem).

A delegação da infra muda muito de um para o outro.
Em clientes maiores temos a liberdade de repassar as necessidades para a TI da empresa e “está tudo resolvido”. Em clientes pequenos, infelizmente, não funciona bem assim. Qualquer alteração é de responsabilidade nossa, temos que intervir diretamente na máquina do cliente, resolver problemas que nem sempre são relacionados aos nossos sistemas (mas que acabam afetando o uso dos nossos sistemas) e por aí vai…

Infelizmente esse é um problema com nossa cartela.
Claro que manter essa relação pode gerar problemas para ambos os lados mas para isso mantemos sempre um plano de modificações e uma mini gestão de serviços (entenda como se fosse uma tentativa “natural” de chegar ao ITIL, sem sequer saber dele ou estudar ele).
No final das contas temos algo que funciona e que nos mantém no mercado há mais de 2 décadas e que, por isso mesmo, não podemos simplesmente abrir mão e mudar do nada.

Mas temos que melhorar ou estaremos fora do mercado. =)

Uma opção que o sistema inteiro web oferece para nós e para nossos clientes é SaaS.
Sem impacto algum na infra do cliente temos a prestação de serviços com qualidade e mais: garantindo acesso de qualquer lugar, já que não, não vamos colocar na nossa empresa o host, até porque temos parceiros como Datacenters que oferecem serviço muito melhor com custo/benefício muito melhor do que poderíamos oferecer aqui.

Obrigado pela posição.

[quote=Luiz Aguiar]Suas perguntas:

1 - O acesso a qualquer tipo de recurso é estritamente interno? não há (nem haverá a curto/médio) prazo a necessidade de uso remoto? outros prédios/filiais, pessoas em viagem que precisem de acesso.

Eu acho que hoje a tecnologia web evolui muito mais rápida que desktop, eu num primeiro momento iria com certeza de desenvolvimento web, com VRaptor ou Rails.

Se for pra fazer uma arquitetura baseada toda em EJBs (que eu particularmente não gosto), não vejo porque não ter acesso web ao invés de desktop, vc teria uma arquitetura web pronta e teria que fazer acesso desktop que é mais complicado de desenvolver, manter e atualizar nos clientes.

Meu voto vai para desenvolvomento web. [/quote]

Rails nem pensar.
Todos os testes que fizemos tivemos problemas graves de performance que quando escalados seriam um horror. Não vamos correr este risco nem vamos repassar um risco deste para bancos e mineradoras. Sem a menor chance. Mesmo.
VRaptor pode, por outro lado, ser uma saída realmente bacana, mas tenho que conferir.
A idéia que vi hoje sobre ele (VRaptor) foi bacana, vou analisar ele no mercado…

São boletos bancários que consistem de imagens internas e externas, tabelas, desenhos, texto, linhas e código de barras, e que apresentam fundo tanto fora (para envelopamento) quanto dentro.
Os boletos são impressos inteiramente nas empresas ao invés de repassado para o banco e/ou empresa de impressão, e nosso sistema precisa gerar os boletos em arquivo PDF para impressão posterior.

Em outro ponto, relatório de razão contábil em um de nossos clientes possui cerca de 8 mil páginas matriciais 132 colunas compactadas.
Agora transcreve isso para papel A4 com uso de fonte Courrier New e tamanho médio 12…
A propósito, sim, precisa ser esta fonte.
Foi requisitado que os relatórios fossem com esta fonte, pelo menos para este cliente em questão (o que me leva a pensar em ter que especificar a fonte de uma forma diferenciada para cada cliente, quase como uma personalização do sistema).

Fora isso temos relatórios bancários e extratos extensos que não dizem respeito unicamente a uma pessoa mas a um grupo de contas e pessoas e que precisa ser impresso inteiro para envio para os gerentes das contas.

Ainda temos relatórios de outros livros fiscais que também são bem gordinhos.

Mas de longe o mais pesado é o de boletos bancários que é emitido em 2 grupos:
1 grupo anual, com cerca de 160 a 180 mil boletos na média. Existe uma federação em nível nacional que emite em média 300 mil boletos GRCSU/ano.
1 grupo mensal, com cerca de 30 mil boletos bancários.
E, como comentei, os boletos são compostos por imagens, logotipos, fotos, desenhos, tabelas de comparação de valor, linhas e texto, código de barra, imagens de fundo e tudo mais.

Pensamos em uma forma de enviar diretamente do servidor para a impressora, assim evitando o tráfego extra para receber no cliente e depois enviar para o spool.
O problema é que assim que cogitamos isso e pesquisamos no cliente nos deparamos com a situação de que nem todas as impressoras são em rede e, feliz ou infelizmente, essa que faz os boletos não é habilitada em rede.

Eu posso solicitar que ele conecte, então, diretamente no servidor e faça a aquisição de outra impressora.
Mas a idéia aqui é analisar o cenário e ver as opiniões.

#14