Service Oriented Front-End Architecture
por Cristiano Gomes
Neste post eu quero propor uma discussão sobre Presentation Ar...
de desempenho causados por mal dimensionamento ou má configuração da
infraestrutura responsável por aplicações web. Além d...
Atendem a diversos canais/dispositivos ao desenvolvermos aplicações
utilizando as tecnologias mencionadas previamente (HTM...
Próximos SlideShares
Carregando em…5
×

Service Oriented Front-End Architecture

358 visualizações

Publicada em

Neste post eu quero propor uma discussão sobre Presentation Architecture, mais especificamente sobre front-end web, com processamento client-side (no browser) e consumindo serviços (XML/JSON, SOAP, REST, WebSockets, etc,).

Para que possamos perceber todo o potencial dessa abordagem, devemos entender as vantagens e as implicações (trade-offs) de cada uma de suas três características básicas:
- Web;
- Processamento client-side (browser);
- Consumo de serviços.

Vamos lá!

Publicada em: Software
3 comentários
0 gostaram
Estatísticas
Notas
  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
358
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
0
Comentários
3
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Service Oriented Front-End Architecture

  1. 1. Service Oriented Front-End Architecture por Cristiano Gomes Neste post eu quero propor uma discussão sobre Presentation Architecture, mais especificamente sobre front-end web, com processamento client-side (no browser) e consumindo serviços (XML/JSON, SOAP, REST, WebSockets, etc,). Para que possamos perceber todo o potencial dessa abordagem, devemos entender as vantagens e as implicações (trade-offs) de cada uma de suas três características básicas: § Web; § Processamento client-side (browser); § Consumo de serviços. Vamos lá! Web: As principais tecnologias web - HTML, CSS e JavaScript, são, de modo geral, padronizadas e independentes de fornecedor. De tal sorte que a mesma página construída com tais tecnologias pode ser visualizada da mesma maneira em diferentes browsers e diferentes sistemas operacionais (incluindo o mundo mobile/tablets). A curva de aprendizado para estas tecnologias é tão curta ou menor do que a curva de aprendizado para linguagens de programação populares como C# ou Java, que tipicamente possuem diversos módulos e frameworks. Na minha opinião, uma vantagem importante (talvez a principal) para nós, provedores de soluções para diferentes clientes, é que a mesma base de conhecimento pode ser empregada em diferentes cenários e clientes (o mesmo não é possível com ferramentas de fornecedores, que mudam de versão para versão, por vezes exigindo considerável capacitação adicional). É notável a existência de limitações para aplicações web, com relação ao uso/consumo de recursos locais (na máquina cliente). É verdade que tais restrições podem ser contornadas de diferentes maneiras, porém, utilizando outras tecnologias para tanto. Processamento client-side (browser): Realizar o processamento necessário para apresentar conteúdo ao usuário e tratar suas entradas e eventos, até então era uma tarefa para o servidor de aplicações. Escalar uma infraestrutura de servidores de aplicações é uma tarefa que poucos clientes conseguem realizar de modo apropriado. São inúmeros os casos de problemas
  2. 2. de desempenho causados por mal dimensionamento ou má configuração da infraestrutura responsável por aplicações web. Além do processamento, tais aplicações consomem grande volume de memória para armazenar objetos na sessão do usuário. Distribuir esse processamento e carga de objetos entre os clientes da aplicação desonera consideravelmente a infraestrutura. Ou seja, todo o MVC fica na camada cliente (no browser). Consumo de serviços: As vantagens de expor funcionalidades em forma de serviços estão relacionadas a princípios básicos da construção de softwares, como o encapsulamento e desacoplamento. O tema serviços é bastante amplo, por isso, me limitarei aos aspectos relacionados à exposição de funcionalidades para alimentar aplicações web. Talvez em um outro post possamos falar especificamente sobre SOA, API e afins. Sob este aspecto, os serviços cumprem um papel simples, provendo dados e funcionalidades à camada de apresentação, representando os pontos de acesso aos diferentes processos, sistemas, funcionalidades e dados. A percepção que tenho é de que a união destas três características nos permite entregar aplicações que não dependem da plataforma tecnológica, distribuem a carga de processamento e preservam recursos nos servidores, rapidamente conferem ao usuário um ar de renovação tecnológica e atendem a diversos canais/dispositivos . Eu explico. Aplicações que não dependem da plataforma tecnológica, uma vez que as principais plataformas do mercado, como Java e .NET, estão aptas à construção e entrega de serviços, sejam eles pertencentes a uma arquitetura orientada a serviços tradicional ou mesmo serviços construídos de forma tática, para atender requisitos funcionais específicos e ad-hoc. Distribuem a carga de processamento e preservam recursos nos servidores porque, diferente de tecnologias como JSP, JSF, PHP ou ASP.NET, o conteúdo estático e dinâmico não é preparado no lado servidor, mas sim no cliente (browser). Utilizando JavaScript através de frameworks ou código customizado, todo o conteúdo dinâmico é recuperado, tratado e apresentado através da camada cliente – o browser. Rapidamente conferem ao usuário um ar de renovação tecnológica, pois o desenvolvimento web traz resultados visuais impactantes quando aliado a disciplinas como identidade visual, usabilidade e experiência do usuário.
  3. 3. Atendem a diversos canais/dispositivos ao desenvolvermos aplicações utilizando as tecnologias mencionadas previamente (HTML, CSS e JavaScript) e utilizando o conceito de Responsive Design, ou Design Responsivo, que prevê a adaptação do formato e do conteúdo de uma página às dimensões do dispositivo cliente, podendo ser um desktop, um tablet ou um smartphone.  

×