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 
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? 
Em Cabo Frio, só se for para vender sanduíche natural na praia ou camarão na beira da estrada! 
[]'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:
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 
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:
Para quem estiver interessado em ler mais sobre SOA, encontrei um material muito interessante que acabei de estudar: