Login Registre-se

Home > Artigos > Engenharia de Software >

SOA - Uma visão geral

Publicado por daltoncamargo em 17/08/2009 - 6.734 visualizações



comentários: 0

SOA: Uma visão geral

João Sávio Ceregatti Longo
Sun Campus Ambassador
http://www.joaosavio.com

I.Motivação

- Reutilização de sistemas já prontos
- Padronização da comunicação entre os sistemas possibilitando uma integração

0


II.SOA

Definição: paradigma para a realização e a manutenção dos processos corporativos que se encontram em grandes sistemas distribuídos. Mas também podemos pensar em SOA como sendo uma camada que oferece um nível maior de abstração partindo do paradigma Orientado a Objetos (OO). Tem como palavras-chave: interoperabilidade, acoplamento fraco e serviços.

Interoperabilidade
A interoperabilidade é alcançada através de um barramento corporativo de serviços (ESB) que podemos ver na representação abaixo:

0

O ESB seria essa camada de abstração maior que tem várias responsabilidades, tais como:

- Prover conectividade
- Transformação de dados
- Roteamento (inteligente)
- Lidar com segurança
- Lidar com confiabilidade
- Gerenciamento de serviços
- Monitoramento e logging

A idéa é que todos os sistemas se integrem através desse barramento corporativo de serviços. Por exemplo, se você tem um sistema feito em PHP, mas atualmente sua empresa utiliza Java, não é necessário modificar totalmente o antigo, mas sim prover uma integração dos dois através de um ESB por exemplo.

Acoplamento Fraco
Por sua vez, o acoplamento fraco tem haver com a redução das dependências do sistema, minimizando os efeitos das modificações e falhas. Podemos exemplificar isso na própria programação Orientada a Objetos com uma classe com alto acoplamento e outra com baixo:

Na primeira classe reparem que tendo um objeto, basta fazer nomeDoObjeto.nome = “qualquer coisa” que mudaremos o valor da variável. Na segunda classe, o acesso à variável “nome” só pode ser feito através dos métodos setNome e getNome. E isso é bom! Pode parecer bobo nestes pequenos exemplos, mas imagine se você tivesse uma API gigante que tivesse regras para modificar os valores das variáveis. Se esta API estivesse altamente acoplada, haveria uma dependência muito grande entre as classes dela e aquelas que a estivessem usando, pois qualquer um poderia modificar as variáveis de qualquer jeito e isso poderia interferir completamente nos resultados.
Mas, voltando ao nosso mundo de SOA, é possível usar o acoplamento fraco em várias situações:

- Comunicação Assíncrona -> isso quer dizer que o remetente e o destinatário não estão sincronizados. Isso é bom porque os sistemas que estão trocando mensagens não precisam estar online ao mesmo tempo.

- Padrões de Iteração -> apenas strings são suportados ou outros tipos de dados também? Estruturas? Arrays? Enumerações? Objetos? Herança e polimorfismo? Bem, quanto mais complexo for o tipo de dados, mais altamente acoplado estará seu sistema. Por exemplo, se você utilizar objetos para troca de mensagens, somente linguagens Orientadas a Objetos poderão participar da integração. A orientação é utilizar até estruturas e arrays, pois colocar tipos de dados mais complexos poderá prejudicar muito a integração entre os sistemas.

- Compensação -> tem haver com a segurança na transação. Se você tem que atualizar dois backends, como lidar com os problemas se apenas uma atualização for bem sucedida? Usualmente é feito um commit de 2 fases, ou seja, os backends são atualizados ao mesmo tempo. Mas, a maneira mais fracamente acoplada e que assegura a consistência geral é modificar os backends separadamente. Se apenas uma atualização for bem sucedida, você poderá revertê-la para a situação consistente anterior e enviar uma mensagem de erro, por exemplo.

- Controle da Lógica do Processo -> se você tiver um controlador central, a falha de um componente vai parar todo o processo. Por outro lado, diminuindo o acoplamento, isto é, fazendo um controle descentralizado, você elimina este problema.

Percebam que só foi citado vantagens do acoplamento fraco. Mas nem tudo são flores, pois quanto mais fracamente acoplado estiver um sistema, mais complexo ele será. Por isso, cabe a você decidir o quanto você está disposto a pagar por isso.

Serviços
A terceira palavra-chave é "serviços", que pode ser definido como um pedaço de uma funcionalidade corporativa independente. Existem três tipos:

- Serviços Básicos -> são serviços básicos de dados e lógica. Por exemplo: criar um novo usuário, alterar um usuário, retornar a idade de uma pessoa cadastrada, dizer se um ano é bissexto ou não, etc. Pertencem a apenas um tipo de backend.

- Serviços Compostos -> são serviços compostos por outros serviços, tendo geralmente múltiplos backends. Em SOA, compor novos serviços partindo dos já existentes é chamado de orquestração. Como em uma orquestra, você combina “instrumentos” diferentes para realizar tarefas mais complexas do que as possíveis com somente um. Serviços compostos ainda são considerados sem estado e com execução rápida.

- Serviços de Processos -> estes são os chamados Workflows. Este tipo de serviços contém estados e às vezes precisa se utilizar de múltiplas sessões. Usando um carrinho de compras como exemplo, teremos um para cada cliente, ou seja, uma sessão do serviço para cada um. E teremos muitos estados possíveis, visto que o serviço tem que guardar os pedidos caso o cliente esteja buscando por mais produtos, finalizar a compra quando a confirmação for efetuada, esperar a confirmação do pagamento e finalizar o pedido apenas quando o produto for entregue.


III.Conclusão

Neste artigo, definimos e falamos sobre o básico de SOA, sendo isso fundamental para o entendimento de Web Services e de outros tipos de modelagens práticas.


IV.Referências

- JOSUTTIS, N. M. SOA na Prática – A Arte da Modelagem de Sistemas Distribuídos. 2008. Ed. Alta Books.


Download:  imagem1.JPG
Size:  36 KB

Download:  imagem2.JPG
Size:  10 KB



comentários: 0