SOA - SOA - Service Oriented Architecture

Introdução

O SOA( Service Oriented Architecture) é um tipo de arquitetura de software que promove a integração, entre clientes e sistemas, e orquestração de processos de uma organização por meio de serviços (componentes abertos/webservices).

Uma arquitetura orientada a serviços é essencialmente uma coleção de serviços interligados que comunicam entre si formando assim um único sistema, porém a localização dos serviços não é importante, estes podem ser internos à empresa ou disponibilizados por outras empresa, pois a comunicação entre os serviços pode envolver apenas simples trocas de dados, ou uma coordenação entre dois ou mais serviços.

Para compreender claramente o que é uma arquitetura orientada a serviços é necessário definir o que é um serviço.

Um serviço é uma função ou funcionalidade que se encontra bem definida, que é estanque (self-contained) e que não depende do contexto ou estado de outros serviços.

Temos então, que o SOA é um estilo de arquitetura na qual aplicações são disponibilizadas em forma de serviços, e esses serviços são disponibilizados em uma interface, que podem ser os Web Services ou alguma outra forma de aplicação.

Best Practices

No desenvolvimento de um software baseado no SOA, deve-se ter em mente algumas respostas para as seguintes perguntas, para que o sistema seja bom e produzido com as melhores praticas para atender o mercado consumidor.

Quais são algumas das vantagens para o cliente de tal prestação de um serviço? Quais são as expectativas e objetivos do cliente?

Quais são os papéis, procedimentos, estruturas e responsabilidades que já estão no local no site do cliente para o planejamento de Tecnologia da Informação, tomada de decisão e direção?

Qual o nível de serviço, a descrição e padronização definição de serviço é adequada?

Como os serviços e prestadores de serviços melhor ser medido e controlado? Quem deve controlar, autorizar e definir mudanças nos serviços que existem atualmente?

Quais são os problemas atuais? Como o cliente pode ser ajudado a resolvê-los?

Deve-se ter em mente também algumas características que seu projeto irá utilizar, algumas citadas a seguir:

• Loose Coupling

Uma das praticas utilizadas no Arquitetura orientada ao serviço é o Loose Coupling entre agentes de Softwares. O Loose Coupling passa pela redução ao mínimo das dependências artificiais, sem que para esse efeito sejam comprometidas as dependências reais. Um exemplo é o serviço de roaming de um aparelho celular.

• Mensagens

São as ligações fundamentais numa arquitetura orientada a serviços, não menos importantes são as mensagens que passam através dessas mesmas ligações.

As mensagens que passam de um serviço a outro tem algumas regras:

- As mensagens têm que ser descritivas e não instrutivas,pois a responsabilidade de resolver o problema é do fornecedor do serviço, o consumidor apenas necessita de explicar o problema. - As mensagem têm que ser perceptíveis para o fornecedor do serviço, ou seja, têm que estar escritas num formato, estrutura e vocabulário que é compreendido por ambas as partes. - Quanto mais restritivo for o vocabulário e a estrutura da mensagem, mais fácil é a sua compreensão, no entanto, desta forma, limita-se a extensibilidade do serviço. - E ainda extensibilidade, que é o aumento do da estrutura e um vocabulario de dados para acompanhar a evolução dos sistemas de softwares.

O problema é que a restrição e a extensibilidade estão intimamente ligadas e é impossível aumentar a uma sem diminuir a outra. O truque está em encontrar o equilíbrio certo entre a duas

• Web Services

Os Web Services são uma implementação do Soa e são aplicativos servidores que disponibilizam 1 ou mais serviços ao cliente. [Cleuto Sampaio, 2003]. Estes permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML. Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efectuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Por outras palavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos pelo Web Service, ou seja, Web Services foram criados para construir aplicações que são serviços na internet.

• Documentos XML

Tendo em conta a importância da extensibilidade nas mensagens trocadas entre os serviços, a escolha lógica parece ser utilização de XML, pois este satisfaz as condições necessárias para a obtenção de Loose Coupling e ainda os documentos XML podem ser restringidos por XML Schemas e, a não ser que as restrições não o permitam, podem ser estendidos.

- Schemas XML

Os Schemas XML exprimem vocabulários e definem as regras sobre as quais pode ser escrito um determinado tipo de documento XML, e permitem também a validação de documentos. Basicamente são um meio para definir a estrutura, os conteúdos e semântica de um documento XML, sendo um meio por excelência para definir os termos do contracto de comunicação entre os sistemas.

Um documento XML contém informação auto-descritiva, e isso pode ser uma das desvantagens de utilizar XML, pois as mensagens tendem a tornar-se muito maiores. Assim sendo existe aqui uma questão de performance. Ao utilizar XML troca-se a performance por flexibilidade, no entanto quanto maior for a largura de banda para comunicação menos se notará este problema.

- Exemplo XML

 <?xml version="1.0"?>
 <xs:schema xmlns:xs="http://exemplo.xml">
 <xs:element name="note">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="to" type="xs:string"/>
      <xs:element name="from" type="xs:string"/>
      <xs:element name="heading" type="xs:string"/>
      <xs:element name="body" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
</xs:schema>

Serviços

Um serviço é um componente que atende a uma função de negocio especifico para seus clientes. Ele recebe requisições e as responde ocultando todo o detalhamento do seu processamento. Um serviço deve executar unidades completas de trabalho, não dependendo do estado de outros componentes externos. Assim, outra conclusão importante é que eles devem ser “Stateless”, ou seja, sem armazenamento de estado de conversação.

Alguns exemplos de serviços:

• Verificar a disponibilidade de vôos para uma determidada cidade.
• Efetuar a venda de um determinado produto.
• Reservar hotel para um cliente.

Um serviço é um componente de granularidade grossa, logo não deve executar funções muito detalhadas.

Alguns exemplos incorretos de serviços:

• Alterar o preço de um produto.
• Fazer baixa de um produto do estoque
• Debitar o valor da conta do cliente.

Estes exemplos são de granularidade muito fina para serem considerados serviços. Por exemplo: “Alterar o preço de um produto” poderia ser uma função de um serviço de gerenciamento de produtos.

Seguindo este principio, podemos criar serviços usando qualquer linguagem, tecnologia ou plataforma.

Web Services

Web Service é uma “encarnação” de SOA, mas não a sua definição. Pela sua natureza, a tecnologia de Web Services favorece muito a criação de componentes SOA usando qualquer outra tecnologia.

O importante é que para ser considerado de arquitetura SOA, um componente deve ser um serviço, o que implica em:

• Granularidade grossa;
• Relevância e alto nível de transação executada;
• Preferencialmente Stateless;
• Baixo acoplamento;
• Interface bem-definida;
• Detalhes de implementação bem encapsulados.

Referências

• SOA e Web Services em Java - Cleuton Sampaio
• Barry, Douglas K. (2003) Web Services and Service-Oriented Architectures
• Lane, Edward (2004). SOA fundamentals and characteristics