SOA |
O que é SOA?
Service-Oriented Architecture (SOA) – ou, em português, Arquitetura Orientada a Serviços – é um termo que descreve duas coisas muito diferentes. As duas primeiras palavras expressam uma metodologia para desenvolvimento de software. A terceira palavra é um panorama de todos os ativos de software de uma empresa, assim como uma planta arquitetônica é uma representação de todas as peças que, juntas, formam uma construção. Portanto, “service-oriented architecture” é uma estratégia que proclama a criação de todos os ativos de software de uma empresa via metodologia de programação orientada a serviços.
O conceito de serviço.
Serviços são porções -- ou componentes -- de software construídas de tal modo que possam ser facilmente vinculadas a outros componentes de software. A idéia por trás destes serviços é simples: a tecnologia expressa de forma que o pessoal de negócio possa entender, e não como um aplicativo enigmático.
No centro do conceito de serviços está a idéia de que é possível definir partes dos códigos de software em porções significativas o suficiente para serem compartilhadas e reutilizadas em diversas áreas da empresa. Com isso, algumas tarefas passam a ser automatizadas – por exemplo, enviar uma query para um website de relatório de crédito para descobrir se um cliente se qualifica para um empréstimo. Se os programadores em um banco puderem abstrair
todo este código em um nível mais alto (isto é, pegar todo o código que foi escrito para realizar a verificação de classificação de crédito e reuni-lo em uma única unidade chamada “obter classificação de crédito”), eles poderão reutilizar esta porção da próxima vez que o banco decidir lançar um novo produto de empréstimo que requeira a mesma informação, ao invés de ter que escrever o código a partir do zero.
Para chegar a isto, os desenvolvedores criam um invólucro complexo em torno do código empacotado. Este invólucro é uma interface que descreve o que a porção faz e como conectar a ele. É um conceito antigo, que data dos anos 80, quando a programação orientada a objetos surgiu. A única diferença é a demanda atual por objetos de software muito maiores e mais sofisticados.
Na operadora norte-americana Verizon, por exemplo, o serviço “get CSR” (get customer service record, obter registro de serviço ao cliente) é uma miscelânea complexa de ações de software e extrações de dados que emprega infra-estrutura de integração da empresa para acessar mais de 25 sistemas em quatro data centers ao redor do país. Antes de criar o serviço “get CSR”, desenvolvedores da Verizon que precisavam desta porção crítica de dados tinham que criar links para todos os 25 sistemas — acrescentar seus próprios links sobre a teia complexa de links que já pendiam dos sistemas populares. Porém, com o serviço “get CSR” situado em um repositório central na intranet da Verizon, estes desenvolvedores agora podem usar o simple object access protocol (SOAP) para criar um único link para a interface cuidadosamente elaborada ao redor do serviço.
Estes 25 sistemas entram em fila e marcham imediatamente, enviando informação do cliente para o novo aplicativo e poupando meses, ou mesmo anos, de tempo de desenvolvimento dos desenvolvedores cada vez que eles usam o serviço. Existem muitas maneiras diferentes de conectar serviços, como links de programação customizados ou software de integração de fornecedores, mas, desde 2001, um conjunto de mecanismos de comunicação de software conhecido como web services, criados sobre a onipresente World Wide Web, tornou-se um método cada vez mais popular para integrar componentes de software.
A diferença entre SOA e Webservice.
SOA é a arquitetura abrangente para criar aplicações dentro de uma empresa — pense em um projeto arquitetônico — mas, neste caso, a arquitetura demanda que todos os programas sejam criados com uma metodologia de desenvolvimento de software específica, conhecida como programação orientada a serviço. Web services são um conjunto de mecanismos-padrão de comunicação criados sobre a World Wide Web. Ou seja, os web services são uma metodologia para conectar e comunicar, enquanto SOA é uma estratégia de TI.
Vantagens do SOA
Reutilização do Software
Aumento da produtividade: Com módulos prontos, a equipe de desenvolvimento pode ser concentrar em outras tarefas do sistema
Maior agilidade: O fato de não precisar recriar nada Interoperabilidade: Consiste em trocar informações entre sistemas escritos em linguagens distintas.
Escalabilidade
Desvantagens do SOA
Performance
Segurança: Como os dados trafegam pela rede, eles podem ser interceptados.
Robustez
Disponibilidade
Testabilidade: Os arquivos de logs podem não estar acessíveis, ou o serviço externo não estar disponível.
Usabilidade: Como webservices não funcionam como threads, fica complicado fornecer feedbacks do processo ou cancelar a solicitação.
Service-Oriented Architecture (SOA) – ou, em português, Arquitetura Orientada a Serviços – é um termo que descreve duas coisas muito diferentes. As duas primeiras palavras expressam uma metodologia para desenvolvimento de software. A terceira palavra é um panorama de todos os ativos de software de uma empresa, assim como uma planta arquitetônica é uma representação de todas as peças que, juntas, formam uma construção. Portanto, “service-oriented architecture” é uma estratégia que proclama a criação de todos os ativos de software de uma empresa via metodologia de programação orientada a serviços.
O conceito de serviço.
Serviços são porções -- ou componentes -- de software construídas de tal modo que possam ser facilmente vinculadas a outros componentes de software. A idéia por trás destes serviços é simples: a tecnologia expressa de forma que o pessoal de negócio possa entender, e não como um aplicativo enigmático.
No centro do conceito de serviços está a idéia de que é possível definir partes dos códigos de software em porções significativas o suficiente para serem compartilhadas e reutilizadas em diversas áreas da empresa. Com isso, algumas tarefas passam a ser automatizadas – por exemplo, enviar uma query para um website de relatório de crédito para descobrir se um cliente se qualifica para um empréstimo. Se os programadores em um banco puderem abstrair
todo este código em um nível mais alto (isto é, pegar todo o código que foi escrito para realizar a verificação de classificação de crédito e reuni-lo em uma única unidade chamada “obter classificação de crédito”), eles poderão reutilizar esta porção da próxima vez que o banco decidir lançar um novo produto de empréstimo que requeira a mesma informação, ao invés de ter que escrever o código a partir do zero.
Para chegar a isto, os desenvolvedores criam um invólucro complexo em torno do código empacotado. Este invólucro é uma interface que descreve o que a porção faz e como conectar a ele. É um conceito antigo, que data dos anos 80, quando a programação orientada a objetos surgiu. A única diferença é a demanda atual por objetos de software muito maiores e mais sofisticados.
Na operadora norte-americana Verizon, por exemplo, o serviço “get CSR” (get customer service record, obter registro de serviço ao cliente) é uma miscelânea complexa de ações de software e extrações de dados que emprega infra-estrutura de integração da empresa para acessar mais de 25 sistemas em quatro data centers ao redor do país. Antes de criar o serviço “get CSR”, desenvolvedores da Verizon que precisavam desta porção crítica de dados tinham que criar links para todos os 25 sistemas — acrescentar seus próprios links sobre a teia complexa de links que já pendiam dos sistemas populares. Porém, com o serviço “get CSR” situado em um repositório central na intranet da Verizon, estes desenvolvedores agora podem usar o simple object access protocol (SOAP) para criar um único link para a interface cuidadosamente elaborada ao redor do serviço.
Estes 25 sistemas entram em fila e marcham imediatamente, enviando informação do cliente para o novo aplicativo e poupando meses, ou mesmo anos, de tempo de desenvolvimento dos desenvolvedores cada vez que eles usam o serviço. Existem muitas maneiras diferentes de conectar serviços, como links de programação customizados ou software de integração de fornecedores, mas, desde 2001, um conjunto de mecanismos de comunicação de software conhecido como web services, criados sobre a onipresente World Wide Web, tornou-se um método cada vez mais popular para integrar componentes de software.
A diferença entre SOA e Webservice.
SOA é a arquitetura abrangente para criar aplicações dentro de uma empresa — pense em um projeto arquitetônico — mas, neste caso, a arquitetura demanda que todos os programas sejam criados com uma metodologia de desenvolvimento de software específica, conhecida como programação orientada a serviço. Web services são um conjunto de mecanismos-padrão de comunicação criados sobre a World Wide Web. Ou seja, os web services são uma metodologia para conectar e comunicar, enquanto SOA é uma estratégia de TI.
Vantagens do SOA
Reutilização do Software
Aumento da produtividade: Com módulos prontos, a equipe de desenvolvimento pode ser concentrar em outras tarefas do sistema
Maior agilidade: O fato de não precisar recriar nada Interoperabilidade: Consiste em trocar informações entre sistemas escritos em linguagens distintas.
Escalabilidade
Desvantagens do SOA
Performance
Segurança: Como os dados trafegam pela rede, eles podem ser interceptados.
Robustez
Disponibilidade
Testabilidade: Os arquivos de logs podem não estar acessíveis, ou o serviço externo não estar disponível.
Usabilidade: Como webservices não funcionam como threads, fica complicado fornecer feedbacks do processo ou cancelar a solicitação.
WOA |
WOA - Conceitos
Web Oriented Architecture (Arquitetura Orientada para Web) é um estilo de arquitetura de software que extende SOA para aplicações baseadas na Web. Muitas vezes é considerada uma versão mais leve de SOA.
Também conhecida como RESTfull programing. WOA também é destinada a potencializar o browser e o servidor com interações pelo uso de tecnologias como POX e REST. WOA tem o propósito de fundir SOA e Web 2.0. Os recursos são identificados por uma URI(Universal Resource Identifieer).
Pilares do WOA
Continuidade dos negócios.
Infra-estrutura mais robusta.
Maior integração de sistemas.
Mais inteligência no tratamento das informações para melhor tomada de decisão.
Web Oriented Architecture (Arquitetura Orientada para Web) é um estilo de arquitetura de software que extende SOA para aplicações baseadas na Web. Muitas vezes é considerada uma versão mais leve de SOA.
Também conhecida como RESTfull programing. WOA também é destinada a potencializar o browser e o servidor com interações pelo uso de tecnologias como POX e REST. WOA tem o propósito de fundir SOA e Web 2.0. Os recursos são identificados por uma URI(Universal Resource Identifieer).
Pilares do WOA
Continuidade dos negócios.
Infra-estrutura mais robusta.
Maior integração de sistemas.
Mais inteligência no tratamento das informações para melhor tomada de decisão.
REST |
Representational State Transfer (Transferência de Estado Representacional) a REST é pretendida como uma imagem do design da aplicação se comportará: uma rede de websites (um estado virtual), onde o usuário progride com uma aplicação selecionando as ligações (transições do estado), tendo como resultado a página seguinte (que representa o estado seguinte da aplicação) que está sendo transferida ao usuário e apresentada para seu uso.
Permite a comunicação entre duas aplicações quaisquer, idependentemente de plataforma.
Usa protocolo HTTP para troca de mensagens. REST não é um padrão, é um modelo de arquitetura. URI identifica seus serviços.
Recursos
Um conceito importante em REST é a existência de recursos (elementos de informação), que podem ser usados utilizando um identificador global (um Identificador Uniforme de Recurso) para manipular estes recursos, os componentes da rede (clientes e servidores) se comunicam através de uma interface padrão (HTTP) e trocam representações de recursos (os arquivos ou ficheiros são recebidos e enviados).
Uma aplicação pode interagir com um recurso conhecendo o identificador do recurso e a ação requerida, não necessitando conhecer se existem caches, proxys ou qualquer outra coisa entre ela e o servidor que guarda a informação. A aplicação deve compreender o formato da informação de volta (a representação), que é geralmente um documento em formato HTML ou XML, onde também pode ser uma imagem ou qualquer outro conteúdo.
Princípios
Um protocolo cliente/servidor sem estado : cada mensagem HTTP contém toda a informação necessária para compreender o pedido. Como resultado, nem o cliente e nem o servidor necessitam gravar nenhum estado das comunicações entre mensagens.
Um conjunto de operações bem definidas que se aplicam a todos os recursos de informação: HTTP em si define um pequeno conjunto de operações, as mais importantes são POST, GET, PUT e DELETE Uma sintaxe universal para identificar os recursos.
O uso de hipermídia , tanto para a informação da aplicação como para as transições de estado
da aplicação.
Vantagens
Uso do padrão Web (HTTP) para troca de dados.
Melhor performance devido ao fato dos request/response serem muito menores.
Fácil de usar.
Permite fazer CACHE das requisições / respostas.
Possibilita a utilização de camadas intermediárias (como proxysn e gateways) para aumento de performance e segurança.
Possibilidade de REST sobre HTTPS.
Pode ser utilizada em aplicativos móveis.
Melhor manutenabilidade.
Desvantagens
Não possuir contrato descrevendo as interfaces de seus serviços.
Falta de ferramentas de apoio ao desenvolvimento.
Não perimitir requisições assíncronas.
Permite a comunicação entre duas aplicações quaisquer, idependentemente de plataforma.
Usa protocolo HTTP para troca de mensagens. REST não é um padrão, é um modelo de arquitetura. URI identifica seus serviços.
Recursos
Um conceito importante em REST é a existência de recursos (elementos de informação), que podem ser usados utilizando um identificador global (um Identificador Uniforme de Recurso) para manipular estes recursos, os componentes da rede (clientes e servidores) se comunicam através de uma interface padrão (HTTP) e trocam representações de recursos (os arquivos ou ficheiros são recebidos e enviados).
Uma aplicação pode interagir com um recurso conhecendo o identificador do recurso e a ação requerida, não necessitando conhecer se existem caches, proxys ou qualquer outra coisa entre ela e o servidor que guarda a informação. A aplicação deve compreender o formato da informação de volta (a representação), que é geralmente um documento em formato HTML ou XML, onde também pode ser uma imagem ou qualquer outro conteúdo.
Princípios
Um protocolo cliente/servidor sem estado : cada mensagem HTTP contém toda a informação necessária para compreender o pedido. Como resultado, nem o cliente e nem o servidor necessitam gravar nenhum estado das comunicações entre mensagens.
Um conjunto de operações bem definidas que se aplicam a todos os recursos de informação: HTTP em si define um pequeno conjunto de operações, as mais importantes são POST, GET, PUT e DELETE Uma sintaxe universal para identificar os recursos.
O uso de hipermídia , tanto para a informação da aplicação como para as transições de estado
da aplicação.
Vantagens
Uso do padrão Web (HTTP) para troca de dados.
Melhor performance devido ao fato dos request/response serem muito menores.
Fácil de usar.
Permite fazer CACHE das requisições / respostas.
Possibilita a utilização de camadas intermediárias (como proxysn e gateways) para aumento de performance e segurança.
Possibilidade de REST sobre HTTPS.
Pode ser utilizada em aplicativos móveis.
Melhor manutenabilidade.
Desvantagens
Não possuir contrato descrevendo as interfaces de seus serviços.
Falta de ferramentas de apoio ao desenvolvimento.
Não perimitir requisições assíncronas.
Postagens
2 comentários:
Onde essa tecnologia aparenta ser mais promissora?
REST em ambientes onde tráfego de dados/custo é levado em conta (mobile por exemplo) e SOA em integração de entre softwares já existentes (codigo legado).
Postar um comentário