SOA x OOP

Alo Pessoal,

primeiro eu li:

What is Service-Oriented Architecture?
http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html

Onde o autor diz:

Depois eu li:

SOA does not replace OOP
http://theagiledeveloper.com/archive/2005/03/02/SOAandOOP.aspx

E agora estou confuso! :shock:

Não que o texto sobre SOA me dê a idéia de “replacement”, mas parece que as duas abordagens são no mínimo um pouco conflitantes.

E vocês, o que acham?

[]'s
Marco Campêlo

Que tal essa parte?

Mas o que eu entendi é que se eu uso a abordagem de SOA, eu teria uma classe CD e uma classe CDPlayer, especializada no serviço de tocar CDs.

No caso do DomainModel (OOP), minha classe CD já não deveria ser responsável por tocar também?

Mesmo considerando que SOA é arquitetura e OOP design, se a resposta para a pergunta acima for afirmativa, me leva a concluir que essa arquitetura é incompatível com o design.

Não seria isso?

[]'s
Marco Campêlo

Depende.

Não existe uma regra fixa. o Domain Model como descrito pelo Fowler (que é a bibliografia mais conhecida, creio) diz:

Criar Domain Models não é o único jeito de lidar com objetos, de qualquer forma, mas é o mais usual (teoricamente, na prática é bem diferente…)

Você pdoeria ter sim, no seu domínio, uma classe CdPlayer, se ela tivesse representação na sua lógica. O objetivo é modelar os participantes o mais próximo conveniente da realidade. Ninguém nunca pode te dizer que o seu CD deve se tocar sozinho ou deve precisar de um CdPlayer, a escolha é de quem projeta, não existe certo e errado, mesmo porque depende do contexto. O que se pdoe avaliar é que um CD tocando sozinho pode implicar em dependência X, acoplamento Y… e de repente você consegue um efeito melhor delegando a responsabilidade à outra classe. Tudo é subjetivo.

Esse trecho:

Mostra que o tal Dr. Hao ou não entendeu muito bem o que é OOD ou descobriu a verdade absoluta que todos devem seguir…

Nem a resposta é totalmente afirmativa ou negativa, nem os paradigmas são incompatíveis.

A primeira coisa a lembrar é que conceitos variam de acordo com autores ou escolas de pensamento.

Um objeto é um componente de baixo nível, mas ele oferece serviços. Empacote os objetos e você pode ter um componente de alto nível. Faça este componente implementar uma interface publicada e você tem um serviço oferecido por um componente, que pdoe ser substituído por qualquer outro desde que sia o contrato da Interface.

SOA é focada em serviços, Objetos também, o que os objetos oferecem são serviços rpestados através de suas relações com outros objetos, serviços estes expostos em sua API :wink:

O que me fica dificil entrar na cabeca é que no Domain Model os dados e as operações ficam juntas.
Posso ter o seguinte
ex:


class Funcionario
{
   public Funcionario[] consultarFuncionariosEmDestaque()
   {
      
   }
}

Funcionario f = new Funcionario();
Funcionario[] fs = f.consultarFuncionariosEmDestaque()

eu preciso de uma instancia para consultar um conjunto de instancias.
Fica dificil entender isso.

jprogrammer (alias, de pois de tantos posts, tu tem nome? :D),

Você não rpecisa disso. Você pdoeria ter, por exemplo:

class Filial{

Collection funcionarios = ...

public Collection funcionariosEmDestaque(){
...
}

class RedeDeLojas{

Collection filiais = ....

public Collection funcionariosEmDestaque(){

 Collection todos=...

 for(Iterator i = filiais.iterator();i.hasNext())
  todos.add(it.next().funcionariosEmDestaque();
  
 return todos;
 }

}

}



}

Sou como o Mister M. Minha identidade é secreta, pois meu chefe não pode ver que fico o dia inteiro no forum (rsrsrsrsr).

Mas a classe Filial precisaria ter acesso ao repositório (DAO) de funcionarios.
Não seria interessante que só a classe de funcionario soubesse como buscar funcionarios ?

Dois "misters m"s ?Trabalha na Summa tb? :mrgreen:

Seria? por que? Por que não seria? Depende do caso, sempre (e é esse meu ponto contra o que escreveu o Dr. Who).

Note que persistir é uma limitação do ambiente (pouca memória, blablabla), não do seu modelo. Existem centenas (milhares?) de implementações possíveis ( AOP, proxies, DAOs, acesso direto…) que resolveriam esse problema, todas têm vantagens e desvantagens.

Mas isso seria uma das “vantagens” do SOA ?
O serviço ficaria responsavel por também persistir.
Há a desvantagem do serviço ter que conhecer dados que geralmente não precisariam ser conhecidos.
ex:

class Estoque
{
    public void estocar(Material material)
    {
        // posso persistir, pois a acao de estocar implicitamente persiste um material.
   
       // para validar tenho que conhecer alguns atributos
       if (material.getDescricao() == "") //

       MaterialDAO.salvar(material);  
       // ou MaterialRespositorio.salvar(material);
    }
}

ou


class Material
{
    public void estocar()
   {
      // acesso metodos internos, não preciso expo-los;

      MaterialDAO.salvar(this);
   }
}

Alias, convenhamos, esse exemplo do CD foi bem fajuto hein? Se tao tentando vender SOA, precisam arrumar um exemplo melhorzinho. Pq, como o shoes mencionou, eh perfeitamente valido ter cdPlayer.play(cd) em OO.

O que eu vejo de interessante na SOA, no entanto, eh bolar uma maneira inteligente pra integrar diversos sistemas diferentes colocando o foco nos servicos, e nao nos dados ou protocolos.

O philippi tá bom de trampo aí no Rio ?
Tô pensando em mudar para Cabo Frio.

Curto muito lá.

[quote=jprogrammer]O philippi tá bom de trampo aí no Rio ?
Tô pensando em mudar para Cabo Frio.

Curto muito lá.
[/quote]

Você pretende trabalhar com Java em Cabo Frio? :smiley:

Em Cabo Frio, só se for para vender sanduíche natural na praia ou camarão na beira da estrada! :stuck_out_tongue:

[]'s
Marco Campêlo

Eu não ganho grana de lviraria (ainda… ) mas me deixem sugerir um lviro que não tem é sobre SOA em si, mas sobre componentes:

UML Components

Baratinho, prático (demais até… :roll: ) e bem simples, mostra o que é desenvolver pensando em interfaces. Não esperem mais que uma breve introdução, entretanto. Aqui no rio tem na Ciência e Cultura (7 de Setembro, no Centro, na Tijuca também, provavelmente),e tem um curso de extensão na PUC-RIO baseado nele (Projeto de Software Orientado a Componentes com UM, com professor Rodrigues, no Centro, muito bom!).

Mas depois do momento Polishop, por que eu falei isso?

Porque numa arquitetura SOA você vai enxergar o mundo além das fronteiras do seu (sub)sistema como um bando de vendedores. Você quer comrpar uma laranja. Existem 15 vendedores de laranja. Qual o contrato básico?

Eu te dou uma quantidade de dinheiro, você me dá uma laranja que esteja em condições de consumo.

Como o cara guarda a laranja dele? Não me improta pelo cotnrato básico. Se eu quiser um diferencial para escolher o melhor vendedor, eu posso até pergutnar para eles (se quiserem/puderem falar), mas basicamente eu dou o dinheiro e pego a laranja, não importa de quem. Se o vendedor A falir, eu posso comrpar do B cumprindo o mesmo contrato, pagando com dinheiro e recebendo laranjas.

As vantagens do SOA não tem a ver coma implementação,porque SOA não diz sobre implementação. Ele diz que componentes fornecem serviços segundo contratos.

O livro do Cheesman ensina você a pensar em Interfaces (em demasia, até).

É lógico que eu não me refiro a trabalhar com Java.
Em Cabo Frio pretendo virar hippie, oras !

O rgand eproblema do Rio hoje é…falta de mão de obra :frowning:

Bom ponto, Shoes.

O artigo http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html é de Setembro, 2003. Acho que o autor ainda não estava com algumas idéias muito bem consolidadas.

Vou procurar algo mais atual para ler.

Abraços,
Marco Campêlo

Mas a programação baseada em contratos é uma enorme vantagem.
ex:

estocar(material) para quem chama este método sempre vai desejar estocar um material, não importa como.
Para mim isto é uma enorme vantagem, pois qualquer funcionalidade extra no processo de estocar pode ser implementado sem problemas.

Opa, opa, há controvérsias. Primeiro que pelo menos 80% das informações da minha profissional estão na minha assinatura (ou linkadas a partir dela :-P) e depois que eu só leio o GUJ entre os builds da aplicação (que são muitos :-P).

Eu não sei apra onde essa discussão está indo :roll:

  • SOA não compete com POO, são coisas com funcionalidades distintas
  • SOA é baseado em contratos, OO também
  • SOA é baseado em componentes, OO também

Para quem estiver interessado em ler mais sobre SOA, encontrei um material muito interessante que acabei de estudar:

http://java.sun.com/developer/Books/j2ee/jwsa/JWSA_CH02.pdf