Vantagens e Desvantagens de SOA

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (13)  (0)

Veja neste artigo uma apresentação da Arquitetura Orientada a Serviços (SOA), as vantagens e desvantagens em utilizá-la em projetos.

Service Oriented Architecture. Fonte: Information Systems

Figura 1: Service Oriented Architecture. Fonte: Information Systems

RESUMO

Arquitetura Orientada a Serviços (SOA) não é uma tecnologia, não é uma metodologia, não é um serviço, mas é um conceito de arquitetura corporativo que promove a integração entre o negócio e a TI por meio de conjunto de interfaces de serviços acoplados. Este trabalho consiste em apresentar uma revisão bibliográfica sobre vantagens e desvantagens de SOA. Com ele será demonstrado que apesar dessa arquitetura estar em alta no mercado, ainda muitas iniciativas falham, e como boas praticas podem ajudar na implementação.

1. INTRODUÇÃO

Arquitetura Orientada a Serviços é um modelo de planejamento de estratégia da área de tecnologia da informação, alinhando diretamente aos objetivos de negócios de uma organização. Esta ponte permite expor as funcionalidades dos aplicativos em serviços padronizados e interrelacionados (AVELLAREDUARTE, 2012). As empresas precisam responder de forma efetiva e rápida ao mercado, sendo assim, as aplicações tem que ter flexibilidade em executar mudanças rapidamente. Existem inúmeras aplicações dentro dos departamentos que precisam ser integradas com o objetivo de atingir agilidade e simplificar processos de negócio.

Nas corporações é muito comum os processos serem tratados por departamentos, cada área só visualiza as suas tarefas, as pessoas não visualizam que fazem parte de um processo que pode começar em uma área e terminar em outra. Essa arquitetura tem como objetivo integrar as aplicações, disponibilizar maior flexibilidade para mudanças, suportar serviços independentes de plataforma e protocolos.

Serviços são módulos de negócio ou funcionalidades que possuem interfaces expostas que são invocadas via mensagens. Interfaces disponibilizam recursos sem que a implementação do serviço seja conhecida.

SOA trata os requisitos de baixo acoplamento, desenvolvimento baseado em padrões, computação distribuída independente de protocolo, integração de aplicações e sistemas legados.

Um dos componentes mais importante em SOA é o ESB (Barramento de Serviços Corporativos), ele não implementa a arquitetura, mas oferece as funcionalidades para implementá-la. O barramento provê uma camada de abstração acima de um sistema de mensageria que permite a integração entre os aplicativos.

Este trabalho tem como objetivo mostrar as vantagens e desvantagens em uma arquitetura orientada a serviços e como evitar que implementações de projetos falhem. Serão mostrados os pontos importantes que devem ser observados em uma arquitetura orientada a serviços.

Nas próximas seções deste trabalho é apresentado, de maneira mais detalhada, como funciona uma arquitetura orientada a serviços.

2. REVISÃO BIBLIOGRÁFICA


2.1 SERVIÇOS

Um serviço é uma atividade ou conjunto de atividades de natureza intangível que é o relacionamento entre um provedor e um consumidor. A interação acontece em respostas síncronas ou assíncronas (GRONROOS, 2006). Na prestação de serviços, existe um fornecedor que fornece algum tipo de serviço e o consumidor que consome o serviço fornecido. Abaixo se vê a figura de um ambiente de prestação de serviço.

Um exemplo de serviço é a energia elétrica que chega à sua casa. Há a geração, depois tem transmissão e por último tem distribuição. Para o usuário não importa todas essas etapas, o que importa são os benefícios que geram esse serviço. A seguir estão os princípios de design de serviços listador por Thomas ERL(2009):

  • Serviços são reutilizáveis.
  • Serviços compartilham um contrato formal.
  • Serviços possuem um baixo acoplamento.
  • Serviços abstraem a lógica.
  • Serviços são capazes de se comporem.
  • Serviços são autônomos.
  • Serviços evitam alocação de recursos por longos períodos.
  • Serviços são capazes de serem descobertos.

Serviços expõem seus membros através de um contrato de serviço. No contrato são definidas quais operações serão disponibilizadas e nele está presente a interface técnica. Essas interfaces são as ligações entre um serviço e as aplicações que irão consumi-lo, expondo somente as operações desejadas.

2.2 ARQUITETURA DE SOFTWARE

A arquitetura de software consiste em documentar o que um sistema precisa ter em termos de componentes computacionais e os relacionamentos entre eles, os padrões que serão usados e suas restrições (SHAW e GARLAN, 1996).

Para construir um software, precisamos ter uma fundação sólida. A arquitetura de software estuda como deve ser feito o software, definindo todos os componentes que devem ser utilizados, estudando os requisitos funcionais e não funcionais do sistema.

A arquitetura de software procura construir uma relação entre os requisitos de negócio e os requisitos técnicos, entendo o funcionamento e então encontrando maneiras de implementar as funcionalidades do sistema. Uma arquitetura bem planejada reduz os riscos de negócio. Alguns benefícios são listados por MARZULLO (2009):

  • Facilidade na gerência da complexidade.
  • Padronização da linguagem e da comunicação entre desenvolvedores, clientes e gerentes.
  • Possibilidades de reuso e consequente evolução do sistema.
  • Fator determinante de uma boa análise (como consistência, atributos de qualidade, atendimento a estilos arquiteturais).

No desenvolvimento de software é muito importe o papel do arquiteto, podemos dividir em três papeis:

  • Arquiteto de Negócio: Deve conhecer muito bem o negócio da empresa.
  • Arquiteto de Soluções: Deve conhecer o negócio da empresa e conhecer soluções técnicas.
  • Arquiteto Técnico: É o profissional que tem o conhecimento técnico, como Arquiteto de Software, Arquiteto de Rede, Arquiteto de Banco de Dados , etc.

Eis algumas funções do arquiteto de software.

  • Priorizar casos de uso.
  • Análise arquitetural.
  • Construir prova de conceito arquitetural.
  • Estruturar o modelo de implementação.
  • Incorporar elementos de design.
  • Descrever a distribuição.
  • Avaliar viabilidade de prova de conceito.
  • Identificar mecanismos de design.
  • Desenvolver guia de programação.
  • Identificar elementos de design.
  • Descrever a arquitetura em tempo de execução.
  • Desenvolver guia de design.

2.3 SOA

Algumas pessoas dizem que o termo arquitetura orientada a serviços (SOA) foi criado por um analista do Grupo Gartner chamado Alenxander Pasik, em 1994. Outras dizem que os primeiros indícios e discussões foram por volta do ano 2000, de estudos da Microsoft e IBM sobre a tecnologia de Web Service. O que pode ser afirmado é que, atualmente, é visto como uma técnica que cobri melhor as necessidades do mercado. (MARZULLO, 2009).

É uma arquitetura que promove a integração do negócio com a tecnologia da informação com componentes de serviços, esse componente é o principal item dessa arquitetura. Os resultados que SOA traz são: agilidade para atender as novas demandas, flexibilidade nas mudanças, redução de custo e reuso de serviços. (SILVA, 2012).

O foco em SOA é a construção e disponibilização de serviços de negócio, evitar replicação de dados, reuso e facilidade de manutenção de sistemas, integração entre os sistemas, visão e controle do processo de negócio, agilidade nas mudanças.

Podemos dizer que SOA é assunto novo, e algumas pessoas confundem o que realmente é essa arquitetura. Abaixo se vê algumas informações erradas sobre ela.

  • Não é uma tecnologia.
  • Não é um produto.
  • Não é um Web Service.
  • Não é um projeto de TI.
  • Não é um software.
  • Não é um “framework”.
  • Não é uma metodologia.
  • Não é uma solução de negócio.
  • Não é um middleware.
  • Não pode ser comprada.
  • Não é um serviço.
  • Não é uma ferramenta de produtividade.

SOA é um conceito de arquitetura que traz maiores prioridades de inovação, aumentando a capacidade de colaboração entres aplicativos e inovando os modelos de negócio e processos. Dizer que uma empresa precisa inovar seu negócio, é a mesma coisa em dizer que é preciso mudar, não existe uma inovação sem mudança, é essa arquitetura facilita as mudanças.

2.4 WEB SERVICE

Web Service é disponibilização de um serviço pela Internet que pode ser acessado em qualquer lugar. Os clientes enviam requisições com informações bem definidas e recebem respostas que podem ser síncronas ou assíncronas (MARZULLO, 2009).

A disponibilização de um serviço é através de um contrato, que é uma interface que disponibiliza as suas funcionalidades, com uma infraestrutura leve e desacoplada de plataforma que facilita a integração em diferentes tecnologias.

Web Service tem que ser visto por um conjunto de tecnologias, que são citadas por MARZULLO (2009).

  • Protocolo HTTP: Transmissão de dados pela Internet.
  • XML: Formato padrão para troca de informações, os dados são separados por tags.
  • SOAP: Fornece uma estrutura padrão de empacotamento para transporte de documentos XML pela internet.
  • WSDL: Tecnologia XML que descreve de forma padronizada a interface de um Web Service.
  • UDDI: Descreve um registro mundial de serviços e serve com integração, propaganda e descoberta de serviços.

2.5 ESB

Enterprise Service Bus (ESB) é um barramento de serviços corporativos que fornece uma abstração de camadas na implementação de um sistema empresarial de mensagens. Combina uma abordagem orientada a eventos e orientada a serviços, simplificando integrações de negócios e unindo plataformas heterogêneas e ambientes (MARÉCHAUX, 2006)

ESB é um dos mais importantes componentes de SOA, é um software de infraestrutura que torna os serviços de negócios reutilizáveis e amplamente disponíveis para usuários, aplicações, processo e outros serviços.

Para desenvolver as integrações é cada vez mais complicado e não é rápido como o mercado exige, os barramentos de serviços corporativos aceleram e simplificam as integrações nas aplicações. Empresas como Totvs, IBM e Microsoft vendem essa ferramenta. Principais características dessas ferramentas são:

  • Roteamento de mensagens.
  • Conversão de protocolo de transporte.
  • Requisição de serviços.
  • Transformação de mensagens.
  • Distribuição de eventos de negócio.

3. DESENVOLVIMENTO

Estratégica arquitetural não é um simples desenvolvimento de software, é governança de processos, serviços e pessoas, metodologia de desenvolvimento centralizado e o envolvimento de todos que estão envolvidos nos processos. É uma arquitetura que precisa do patrocínio dos executivos do alto escalão, para proporcionar a TI o conhecimento dos processos e conseguindo adesão para o compartilhamento corporativo. (KLEIN, 2012).

3.1 IMPLEMENTAÇÕES DE SOA FALHAM

Falhas em iniciativas SOA não serão publicadas pelos consultores ou fornecedores, o que é vendido é mundo perfeito dessa arquitetura, sendo assim, não expondo alguns cuidados que as empresas deveriam tomar, caso acontece, alguns riscos poderiam ser diminuídos (CARVALHO, 2012).

Alguns erros comuns de SOA são tratar funções de negócio como módulos de softwares técnicos, delegar o projeto para os técnicos, implantar um projeto que não tem valor expressivo para a companhia, decisão de implantação por pessoas que não são da área de estratégia, iniciativas SOA falham por causa das pessoas. São listadas algumas das razões por KAVIS (2008).

  • Não sabem explicar o valor de SOA para o negócio.
  • Subestimam o impacto da mudança organizacional.
  • Não garantem o patrocínio dos executivos ou alta gerência.
  • Tentar implementar uma arquitetura com custo mais baixo.
  • Não existe ajuda externa.
  • Não existe investimento em treinamento.
  • Não existem pessoas com conhecimento e experiência.
  • Não tem um gerenciamento de projetos eficiente.
  • Tratam SOA como um projeto e não como uma arquitetura.
  • Subestimam a complexidade da arquitetura.
  • Não acreditam na importância da governança.
  • Quanto existe ajuda externa, as empresas permitem que elas ditem a arquitetura.

3.2 VANTAGENS DA ARQUITETURA ORIENTADA A SERVIÇOS

O reuso de serviços é grande vantagem dessa arquitetura, aumentando produtividade, alinhamento com negócio, melhorias para corporação e facilidade na gerencia da tecnologia da informação, focando em melhorias continuas e automatizando os processos, disponibilizando qualidade nas informações trafegadas na empresa (SOBRINHO, 2011).

Mudar o negócio e os sistemas das empresas não é uma tarefa fácil, particularmente em um contexto de mudanças constantes, a implantação de SOA não é diferente, sendo assim, porque deve ser utilizada essa arquitetura? Abaixo são listadas algumas vantagens que ela pode trazer para o negócio.

  • Reutilização: O serviço pode ser reutilizado para outras aplicações.
  • Produtividade: Com o reuso, a equipe de desenvolvimento pode reutilizar serviços em outros projetos, diminuindo o tempo de desenvolvimento.
  • Flexibilidade: Isolando a estrutura de um serviço as mudanças são feitas com maior facilidade.
  • Manutenibilidade: Com baixo acoplamento, facilita a manutenção dos serviços.
  • Alinhamento com o negócio: A área de negócio visualiza os processos alinhados com a tecnologia.
  • Interoperabilidade: Disponibilizar serviços independentemente da plataforma e tecnologia.
  • Integração: A integração com outros serviços, aplicativos e sistemas legados.
  • Governança: Gerenciamento nos processamentos de negócio.
  • Padronizado: É baseado no uso de padrões.
  • Abstração: Serviço totalmente abstraído da sua implementação.

3.3 DESVANTAGENS DA ARQUITETURA ORIENTADA A SERVIÇOS

A principal preocupação em implementações dessa arquitetura é a questão da segurança. Em uma pesquisa global patrocinada pela CA, 43% dos executivos classifica a segurança como o ponto mais crítico nas iniciativas SOA. (TI INSIDE ONLINE, 2012).

Todos os tipos de desenvolvimento de software tem suas desvantagens, na arquitetura orientada a serviço não é diferente, ela depende da implementação de normas, não é utilizada em aplicações com grande transferência de dados, alto acoplamento e aplicações que precisam manter estado. A seguir são listadas algumas desvantagens.

  • Complexidade: Uma grande quantidade de serviços precisa ser gerenciada.
  • Performance: A performance depende do servidor onde o serviço está publicado, como também da rede.
  • Robustez: Caso uma exceção acontecer não tem como reverter o processo.
  • Disponibilidade: Uma queda na rede ou no servidor deixa todos os serviços indisponíveis.
  • Testabilidade: O debug no serviço é um problema para os desenvolvedores.
  • Segurança: Os serviços estão disponíveis na rede, qualquer aplicativo pode consumir esse serviço, os dados são trafegados pela rede podendo ser interceptados.

3.4 BOAS PRÁTICAS PARA IMPLATAR SOA

Adotar SOA é conseguir uma solução que assegure uma agilidade comercial e reutilização de funcionalidades. A primeira etapa em adotar essa arquitetura é identificar desafios ou prioridades comerciais importantes à integração. Alguns dos princípios implantados em SOA são escolhidos de modo que atendam as necessidades comercias, ofereçam um bom tempo para concretizar o valor e dando o melhor suporte ao crescimento de longo prazo para as empresas (MICROSOFT, 2012).

O desafio de fornecer aplicações baseadas em SOA está em identificar os problemas que podem acontecer e ter um plano para resolvê-los sem ter impactos na implementação.

Para que uma iniciativa em SOA seja bem sucedida, precisa de arquitetura de referência bem estruturada, uma politica de governança e uma infraestrutura bem planejada.

A adoção de uma estratégia de SOA precisa ter soluções que estejam alinhas com o negócio e os processos dos setores da empresa. Abaixo alguns desafios técnicos e organizacionais para implementação de SOA são listados.

  • Não sabem explicar o valor de SOA para o negócio.
  • Barreiras politicas.
  • Gerência do ciclo de vida de serviços.
  • Cultura organizacional.
  • Estrutura de processos de governança.
  • Imaturidade de competências.
  • Falta de experiência na implementação.
  • Identificar e desenhar serviços.
  • Aplicar governança.
  • Promover o reuso.
  • Eficiência de desenvolvimento.
  • Integração de aplicativos.

Para ter uma implementação bem sucedida, depende da abordagem cuidadosa do planejamento da arquitetura de negócios. A ferramenta mais importante é o conjunto de boas práticas. Aprender com as experiências das empresas que já passaram pelos processos de implantação é um bom começo para ter sucesso na implementação de SOA. (FRONCKOWIAK, 2012).

SOA é considerado como chave para melhorar a eficiência de TI, mas para implementar em um negócio, é preciso ter muito mais do que apenas conhecimento técnico. É essencial aprimorar as habilidades em práticas de gestão, utilizando as melhores práticas em relação a SOA. São listadas algumas boas práticas.

  • Siga os padrões de mercado: WS-I, WS-BPEL, WSDL, UDDI, SOAP.
  • Use ESB (Enterprise Service Bus): É um mecanismo arquitetural para comunicação corporativa que possibilita a integração de sistemas.
  • Siga os princípios de SOA: Fraco acoplamento, contrato de interfaces, serviços reutilizáveis, não manter estado entre chamadas.
  • Use nomes de negócio para os serviços: Os consumidores dos serviços não sabem o que acontece dentro dos serviços, então os nomes dos serviços devem usar terminologias e vocabulário para tornar seu significado intuitivo.
  • Estabeleça padrões de nomeclatura: Facilita na leitura e o significado dos serviços.
  • Seja cético na candidatura de serviços: Nem tudo precisa ser um serviço. Explore sistemas que já existem para procurar candidatos a serviços, verificar o valor para o negócio e não para a TI.
  • Otimize mensagens SOAP: O conteúdo do SOAP é XML. Trafegar grandes informações pode ser um problema, devido à quantidade de tags em torno dos dados. Procure um mecanismo mais eficiente de serialização de XML.
  • Crie serviços que tenham operações atômicas: O serviço não deve se preocupar com dados de outros serviços, serviços devem funcionar sem transação e estornos de dados.
  • Construa seus serviços iterativamente: Não tente criar tudo em um serviço ao mesmo tempo, comece com uma área ou grupo de processos que traga valor agregado no negócio.
  • Contrate uma consultoria: Não tente implatar SOA sem ajuda externa, é um estilo arquitetural difícil de aplicar.

4. CONCLUSÃO

O mercado é baseado em processos de negócio, adotar SOA é essencial para as empresas, alinhando TI com o negócio, agilidade, reuso, facilidade na manutenção, flexibilidade e rapidez nas mudanças de processo.

Os desafios que tem essa arquitetura não são na tecnologia, mas nas pessoas que lideram a abordagem orientada a serviço. Para que essa arquitetura seja um caso de sucesso, tem que ter uma mudança organizacional, a área de estratégia da empresa deve garantir o patrocínio e acreditar que SOA é importante para os negócios.

Esse trabalho mostrou as vantagens que essa arquitetura pode trazer para o negócio, as desvantagens que nos próximos anos serão estudadas para formar uma arquitetura mais eficiente e como boas práticas podem ajudar a iniciativas em SOA. Os próximos desafios em SOA estão diretamente relacionados a fornecer serviços com mais segurança e conscientização das pessoas que estão envolvidas nos processos.

Uma conclusão é que abordagem tradicional de desenvolvimento de software não é mais capaz de trazer vantagens à organização, e que SOA responde de forma efetiva e rápida aos negócios.

6. REFERÊNCIAS

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?