O documento discute a arquitetura SOFEA (Service Oriented Front End Architecture), que propõe a separação da lógica da interface do usuário da lógica de negócios e banco de dados através de serviços. Apresenta os benefícios dessa abordagem como escalabilidade, melhor experiência do usuário e integração facilitada.
A nova geração da arquitetura web para a era da nuvem
1.
2. QUAL PÚBLICO É INDICADO ESTA PALESTRA?
• Qualquer pessoa interessada em tecnologia web que tenha uma
compreensão básica de aplicações web e Arquitetura Orientada a Serviço
(SOA)
3.
4. Anos 90
Páginas HTML Estáticas
CGI Servlets
Frameworks MVC
Motores de Templates Web
AJAX
SOFEA
Web 1.0
Web 2.0
Mobile
Hoje
5. MOTORES DE TEMPLATES WEB
• Código incorporado dentro de elementos HTML estáticos
• Mistura de HTML estático e dinâmico
• Arquitetura de primeira geração
• Exemplos:
• Java Server Pages (JSP)
• PHP
• Active Server Pages (ASP)
6.
7. FRAMEWORKS MVC
• Padrão Model View Controller
• Frameworks no lado servidor (Server- Side)
• Arquitetura de Segunda Geração
• Exemplos:
• ASP.NET MVC Framework (.Net)
• Struts, Spring MVC (Java)
• Ruby on Rails (Ruby)
• Django (Phyton)
• Grails (Groovy)
8.
9. AJAX
• Asynchronous JavaScript And XML
• Alterações de conteúdo dinâmico sem recarregar a página inteira
• Aplicativos interativos e dinâmicos da web se aproximando da experiência
de interação rica na parte client-side (Instrumentação para o RIA – Rich
Internet Application)
• HTML/CSS + DOM + XmlHttpRequest Object + JavaScript + JSON/XML
10. PROCESSOS DE APLICAÇÕES WEB
• Download da Aplicação
• Código (JavaScript, HTML, Applets, Flash) a ser baixado no cliente (web
browser)
• Fluxo de Apresentação
• Processamento visual dinâmico da UI (mudança de telas, novas telas, etc)
em resposta à entrada do usuário e alterações de estado de dados
• Interação de Dados
• A troca de dados entre dois componentes de software ou camadas. (busca,
atualizações, recuperação, etc)
15. SOFEA
• Service Oriented Front End Architecture
• Como construir aplicações Front-End em um mundo orientado à serviços.
• Quem definiu isso aí?
• Ganesh Prasad, Rajat Taneja, Vikrant Todankar
• Estilo Arquitetural
• Não uma implementação
• Prasad propôs que a revolução SOA será estar atrás em aplicações
front-end/UI’s.
16. Viável porque...
• Maturidade do paradigma
SOA em teoria e prática.
• Avanços em tecnologias
de cliente com base em
navegador, especialmente
mecanismos de
navegadores com suporte
à JavaScript e AJAX
toolkits
Necessários porque...
• SOA é o mecanismo de
entrega de fato para
serviços baseados em
nuvem (Cloud e SOA são
tecnologias
complementares)
• Diversidade de plataformas
de cliente
• Dominação crescente de clientes
móveis
SOFEA É AGORA...
17. ARQUITETURA EMPRESARIAL WEB LEGADA
Arquitetura típica de aplicações empresariais web
Navegador
Web
Lógica de
Negócios e
Persistência
Construção
Lógica da
Página Web
(JSP, PHP,
ASP, etc.)
Cliente Servidor
20. PRINCÍPIOS DE SOFEA
• Donwload da Aplicação, Comunicação de dados (Data Interchange) e
Fluxo de Apresentação deve ser desacoplado.
• Nenhuma parte do cliente deve ser chamado, gerado ou modelado a partir
do lado do servidor.
• O Fluxo de Apresentação é apenas uma preocupação do lado cliente.
• Toda a comunicação do aplicativo com o servidor deverá estar usando
serviços (REST, SOAP, etc).
• O padrão MVC pertence ao cliente, não ao servidor.
21. • Escalabilidade
• O servidor tem menos trabalho a fazer; não
realiza mais a geração da camada de
apresentação, basta fornecer um serviço.
• Melhor resposta do
usuário
• Baixa Latência – Usuários finais felizes :D
• Após o download do aplicativo, nenhuma
apresentação é transportado sobre a rede,
apenas os dados de negócios
• Alto ROI
• Expandido o espaço de oportunidades,
devido à natureza reutilizável inerente de
SOA
• Ajuste natural em
abmientes SOA e para a
Nuvem
• Modelo de programação
organizada
• Desenvolvedores Client-side se
concentram na UI.
• Desenvolvedores Server-side se
concentram nos serviços.
• Aplicações Offline
• Quando houver falhas de rede, o cliente é
desacoplado e pode mudar
dinamicamente sua escolha sobre os
objetos de modelo, podendo usar uma
base local ou quando a rede voltar
poderá comunicar com os serviços.
• Interoperabilidade
• Integração mais fácil com menor
sobrecarga de múltiplas plataformas.
• Os clientes não se importam se os
serviços são Java, C #, Python, Cobol ou
uma mistura heterogênea
BENEFÍCIOS DE SOFEA
23. PONTOS À SEREM OBSERVADOS
• O App Cliente é a Prioridade número um na definição da arquitetura, não
deve ser pensado nisto depois.
• Usar ferramendas maduras no desenvolvimento client-side.
• Ex: AngularJS, KnockoutJS, jQuery, etc...
• O RESTful é o modelo natural para comunicação em sistemas SOFEA
• Arquitetos e Desenvolvedores devem definir uma comunicação de forma
assíncrona entre o servidor e a camada de cliente.
• Aproveitar ao máximo as tecnologias mais recentes se for apropriado
• HTML5, Webh Workers e WebSockets.
• Comece os testes de compatibilidade cross-browser no início do ciclo de
desenvolvimento
• SOFEA é uma excelente escolha para ambientes que tenham largura de
banda restrita ou consumo limitado de banda.
24. CONTATO
• Git: clovesmjunior
• E-mail: squaresystemsbr@gmail.com
• Sites :
• www.squaresystems.com.br
• www.squaress.com.br
• www.squaress.com
• Agradecimentos: Ao Designer José Mário pela nova identidade visual
da SquareSystems. Link: http://josemarioramos.com.br/
IaaS – Infrastructure as a Service (Infraestrutura como Serviço):De maneira análoga a anterior, neste modelo você contrata sua infraestrutura como serviço, com uma vantagem muito interessante ao modelo tradicional, que é a contratação de servidores virtuais (e outros dispositivos de infraestrutura) ao invés de comprar servidores, roteadores, racks e outras “caixas” de hardware. Aqui você é tarifado por alguns fatores, como o número de servidores virtuais, quantidade de dados trafegados, dados armazenados e outros itens, dependendo de como e com quem (fornecedor IaaS) você trabalha. Neste caso, creio que Amazon EC2 e a IBM sejam bons exemplos para quem queira pesquisar mais sobre o assunto. No IaaS, obviamente também é utilizado o modelo pay-per-use, onde a cobrança é baseada no serviço e não em produto, ou seja, se você precisa de 10 servidores para o próximo mês, você contrata a utilização destes servidores por este período determinado e depois, simplesmente cancela a utilização, exatamente como a compra de um serviço de TV a cabo ou um plano de serviço de dados para seu celular.
PaaS – Platform as a Service (Plataforma como Serviço):Aqui temos um modelo que fica entre o SaaS e IaaS, proporcionando uma plataforma mais robusta e flexível para a utilização de muitos recursos de tecnologia, onde é possível a utilização de softwares de maneira mais flexível, sendo possível desenvolver suas próprias aplicações baseadas em alguma tecnologia (framework, linguagem etc.) e utilizar a infraestrutura necessária, e o mais importante, adequada a aplicação desenvolvida. Pense em uma solução onde você necessite de um software, porém, por alguma limitação de um fornecedor do modelo SaaS, você não conseguirá implementar um determinado recurso personalizado que é fundamental para seu negócio. É aqui que o modelo PaaS é interessante, pois, você pode utilizar a mesma estrutura que você teria “em casa”, porém, utilizando o modelo “as a service”, livrando-se da aquisição de hardware, licenças de software etc. e utilizando esta mesma estrutura como serviço. Para entender este modelo é muito interessante pesquisar sobre o Microsoft Azure. Aliás, o Azure é bem flexível e lhe permite utilizar, além do PaaS, também os modelos SaaS e IaaS.
ROI -> ROI é a sigla em inglês para Return on Investment, que em português significa “Retorno sobre Investimento”. ROI é a relação entre o dinheiro ganho ou perdido através de um investimento, e o montante de dinheiro investido, Este é um termo muito usado em publicidade online.
A especificação Web Workers (link em inglês) define uma API para geração de scripts de segundo plano no seu aplicativo da web. O Web Workers permite executar tarefas como disparar scripts de longa duração para executar tarefas muito dispendiosas, mas sem bloquear a interface de usuário ou outros scripts para manipular interações com o usuário. Isso poderá ser o fim daquele diálogo de "script não responde“.