Arquivo Discussoes de Programacao e Tecnologia 
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á.
O philippi tá bom de trampo aí no Rio ?
Tô pensando em mudar para Cabo Frio.Curto muito lá.
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:
Completando a listinha acima:
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.
Concordo que programacao por contratos eh uma boa ideia, mas isso que vc descreveu nao eh programacao por contratos. De uma olhada em Eiffel (FAQ), e nos papers, por exemplo, http://archive.eiffel.com/doc/manuals/technology/contract
E, claro, tem a boa e velha Wikipedia:
A Mundo Java nº 18 traz uma matéria sob o título “Problemas com a adoção de SOA”:
Seguem algumas das críticas que o autor (Glauco Reis) faz:
A Mundo Java nº 18 traz uma matéria sob o título “Problemas com a adoção de SOA”:Seguem algumas das críticas que o autor (Glauco Reis) faz:
- SOA é um novo nome para algo já conhecido e que não teria atingido o grau de aceitação desejado: SOAP.
- Falta de serviço de transações;
- Lentidão e falta de segurança;
- Falta de conivência dos fabricantes.
Dizer que falta serviço de transações para SOA não faz sentido. SOA usa transações compensatórias em vez de transações distribuidas.
Transações compensatórias são uma maneira progamática/braçal de se implementar rollback de transações. A vida fica muito mais simples quando está tudo implícito dentro de uma transação e o BD desfaz (ou não aplica) as alterações em disco. Além disso, SOA não usa transações compensatórias obrigatoriamente. Transações compensatórias também podem ser utilizadas em sistemas sem SOA. Da mesma maneira vc pode ter compenentes de uma sistema SOA que utilizem transações distribuídas para efetuar suas tarefas.
Olá
Na área de transações bancárias e de cartão de crédito há sempre o mecanismo chamado “desfazimento” que acho que pode ser considerado como um mecanismo de transação compensatória.
Existem sistemas baseados em SOA que usam e sei que o BizTalk provê este recurso desde que o desenvolvedor seja responsável por gravar as alterações na base de dados e fazer o “Undo”.
Talvez SOA sem um mecanismo de transação compensatória dê certo em um ambiente em que todos os sistemas estão sob um controle único. Mas não vejo muito sentido nisto com SOA. Acredito que poderiam sobrar eventuais inconsistências na base de dados que precisariam ser acertadas na mão ou por processos de auditoria como nos tempos antigos.
[]s
Luca meio na dúvida porque o que conhece de SOA é pura teoria
Dizer que falta serviço de transações para SOA não faz sentido. SOA usa transações compensatórias em vez de transações distribuidas.
Transações compensatórias são uma maneira progamática/braçal de se implementar rollback de transações. A vida fica muito mais simples quando está tudo implícito dentro de uma transação e o BD desfaz (ou não aplica) as alterações em disco. Além disso, SOA não usa transações compensatórias obrigatoriamente. Transações compensatórias também podem ser utilizadas em sistemas sem SOA. Da mesma maneira vc pode ter compenentes de uma sistema SOA que utilizem transações distribuídas para efetuar suas tarefas.
O problema de transações em um ambiente SOA é que impoem uma exigência muito grande em todos serviços envolvidos, todos tem que ser capazes de conversar com um DTC.
Mesmo com WS-AtomicTransaction quase disponivel em todas pilhas, ainda assim acho que é inviavel, e uma maneira muito ruim de se trabalhar com SOA. Transações distribuidas já não são uma maravilha em um ambiente controlado, com poucos e conhecidos componentes heterogêneos, imagine em um ambiente onde você não tem como saber como é implementado um serviço?
Transações Distribuidas acabam com o loose coupling que SOA promovem, é um retrocesso.
Transações Distribuidas acabam com o loose coupling que SOA promovem, é um retrocesso.
Dois componentes não podem ser considerados fortemente acoplados só pq compartilham os mesmos serviços de transação ou pq são processados numa mesma transação. Transações distribuídas facilitam o desenvolvimento e utilizam menos recursos computacionais do que SOA.
Ola
Talvez me esteja escapando algo. Mas ainda não entendi como se pode fazer transações distribuídas com SOA quando cada parte usa sua própria base de dados, seu próprio servidor de aplicações (ou não usa) e que troca mensagens em um ambiente em que os serviços possam ser interrompidos em algum momento (Internet por exemplo).
[]s
Luca
Talvez nosso amigo louds (SOA’s Defender) possa explicar melhor do que eu.
Olá
Sem polêmicas, não percebi que o Louds era defensor de SOA. Apenas entendi que ele chamou a atenção de que com SOA quase sempre precisamos de transações compensatórias e você disse que bastaria usar transações distribuídas.
Não tenho experiência com SOA mas já trabalhei com aplicações que trocam mensagens com ambientes diferentes e não foi possível centralizar o controle das transações. Daí a minha dúvida sobre como isto poderia ser possível.
Aliás, vou dar um exemplo. Digamos que nós 2 usássemos uma agenda comum. Como você imaginaria que fosse o processo de inclusão de um nome nesta agenda de modo que ambas sempre estivessem iguais?
É claro que excluo a possibilidade de nós 2 usarmos o mesmo banco de dados e o mesmo servidor de aplicações porque senão bastava uma aplicação comum e não precisava de SOA.
[]s
Luca
Imagine que sua agenda esteja dentro de um ERP como SAP e que a minha esteja em uma solução desenvolvida sob medida em um servidor J2EE. O protocolo Two-Phase-Commit (transações distribuídas) possibilita que a transação seja realizada de maneira atômica e que, caso ocorra algum problema, os dois BDs façam o rollback retornando para a última posição consistente. Em Java, vc consegue usar os recursos de Two-Phase-Commit com JTA.
Olá
Há uns 2 anos atrás tentei aprender JTA pelo livro Java Transaction Processing: Design and Implementation e achei um tanto complicado.
Aliás os autores do livro disseram no Java One 2006 em Demystifying Java Transaction Processing:
Using distributed transactions JavaTM application appears easy
but�
Using transactions correctly is a little more difficult!
Já trabalhei com sistemas financeiros, que trocando mensagens com 3 pernas garantem o Two-phase commit com muito mais facilidade.
Até gostaria de ver um sisteminha usando JTA. Alguma coisa bem simples de fazer como por exemplo venda de créditos de cartão telefônico em loja de departamentos com solicitação de autorização na Telco. Sem JTA é bem facinho bolar a arquitetura. Com JTA seria necessário sair atrás de gente com conhecimento específico.
[]s
Luca
Então acho que vc sabia o caminho :roll:
Escolher uma solução paleativa pq não se domina JTA é uma opção. Entretanto, a longo prazo, isto não é viável. É melhor estudar e fazer certo na primeira vez para evitar retrabalho.
Lembre-se: a polêmica é SOA x transações distribuídas. É mais fácil encontrar alguém que conheça SOA?
Olá
Sei o caminho usando transações compensatórias.
O uso correto de Two-phase commit sempre foi um desafio na industria de software. É exatamente por isto que estou insistindo contigo que o Louds tem razão quando disse que deveria ser usado transações compensatórias. Para mim é muito mais fácil desacoplar tudo e trocar mensagens mandando desfazer em caso de erro.
Até hoje o único desenvolvedor que me disse que usou JTA foi o Daniel Quirino. Seria interessante que ele desse um pitaco se achou fácil.
[]s
Luca
Eu já precisei usar transações distribuidas, mas somente no caso simples, um coordenador, múltiplos recursos. Esse é facil, até que funciona bem, e não deixa o sistema em estados de inconsistencia bizarros no caso de falhas.
Nunca vi sistemam que usem múltiplos coordenadores - distribuídas pra valer. Esse é o pior caso, e o mais facil de deixar o sistema naqueles muitos estados “buraco negro” o próprio XA diz existir.
Um fato, XA e two-phase commit não garantem 100% de atomicidade, garantem que em um cenário de falha razoavel seja possivel abortar a transação globalmente de forma consistente. Isso até que funciona, mas apenas quando todos participantes estão disponíveis para fazer recovery ASAP.
Mas falando de SOA, SOA para valer, no qual um sistema fala com outros sistemas completamente aliens. Fazer uma transação distribuida é impraticavel por vários motivos:
:arrow: O protocolo XA existe 1 tonelada de estados intermediários, teu serviço vai ser obrigado a saber da existência deles e permitir sistemas remotos intervirem nisso.
:arrow: A troca de mensagens é grande, o tempo de resposta fica bem compromentido se os sistemas existirem em sites diferentes.
:arrow: Transações distribuidas sofrem do mal do inderminismo no caso de falhas em vários cenários.
:arrow: Pago 1000 reais para quem conseguir me explicar ao vivo todos estados e transições do protocolo XA sem qualquer auxílio.
:arrow: Transações compensatórias eu sei explicar em um guardanapo e até estagiário consegue entender.
:arrow: Encarando a cruel realidade, nenhum ISP testa o serviço de DTC dele com o de outros fornecedores, então intraoperabilidade entre DTCs é lenda urbana.
Caramba, transações distribuidas são um treco muito, muito dificil para fazer funcionar quando temos controle de tudo na nossa mão, falando com 2-3 provedores de serviço distinto vai ser um caos.
Ainda prefiro encarar SOA como opção quando preciso efetuar busca e instalação automática de serviços em diretórios de serviços.
E quanto às outras críticas? Lembrem-se que só entamos falanda da “falta de serviço de transações”.
A Mundo Java nº 18 traz uma matéria sob o título “Problemas com a adoção de SOA”:Seguem algumas das críticas que o autor (Glauco Reis) faz:
- SOA é um novo nome para algo já conhecido e que não teria atingido o grau de aceitação desejado: SOAP.
- Falta de serviço de transações;
- Lentidão e falta de segurança;
- Falta de conivência dos fabricantes.
Ainda prefiro encarar SOA como opção quando preciso efetuar busca e instalação automática de serviços em diretórios de serviços.E quanto às outras críticas? Lembrem-se que só entamos falanda da “falta de serviço de transações”.
As outras três eu concordo ue. Tudo bem que dizer que SOA é apenas um novo nome para SOAP é forçar um pouco a barra, mas vale pela alfinetada. :lol:
Usar 2PC em transações que envolvem processamento assíncrono não gera problemas com locking excessivo? Se demora horas ou dias entre o start e o commit de uma transação e a taxa de TPS é alta, o BD vai acabar todo trancado por causa de lock escalation. Ou tem alguma coisa óbvia que eu não estou enxergando aqui?
Rafael, é exatamente este o ponto de toda literatura que conheço sobre o tema. Um processo de negócios de dias, meses ou anos não podem depender de locks, é só perceber como os negócios funcionam com transaçãoes compensatórias desde sempre.
Usar 2PC em transações que envolvem processamento assíncrono não gera problemas com locking excessivo? Se demora horas ou dias entre o start e o commit de uma transação e a taxa de TPS é alta, o BD vai acabar todo trancado por causa de lock escalation. Ou tem alguma coisa óbvia que eu não estou enxergando aqui?
Depende muito de como esse processamento for implementado e como o banco de dados funciona.
O banco pode implementar multi versionamento e nesse caso somente locks solicitados pela transação são gerados. O ruim é que o transaction log (undo/redo logs do oracle) ficam enormes pois não podem sofrer flush enquanto ocorre uma transação ao risco dela falhar por conta de um “snapshot too old”, quando os logs sofrem flush mesmo com transações pendentes.
O banco pode usar locks explicitos, como o DB2, nesse caso o banco pode sofrer problemas de lock escalation, mas dependendo da implementação, transações paradas ou de longa duração tem seus locks armazenados em disco de maneira semelhante ao tx log. O problema maior mesmo é o excesso de deadlocks que isso constuma gerar ou lock escalation.
um processo de negócios que demore, digamos, seis meses para ser compeltado pode influenciar em milhares (literalmente) de outras transações. Não importa a tecnologia, isso nunca vai ser simples.
isso me lembra algo que li ha muito tempo e nem lembro onde sobre a dificuldade dos bancos de dados atuais em implementar transações de longo prazo, e o texto fazia um paralelo com sistemas de SCM.
Um sistema de SCM trabalha com compensação. Se você modifica um código fonte diveras vezes para implementar um detrminado caso de uso durante um mês vai gerar (num sistema grande, ao menos) um mar de dependências em outros fontes. Em termos tecnológicos é muito simples reverter o arquivo em questão no SCM, mas acertar os estragos nos fontes dependentes deste não é simples nem barato.
Obviamente seria quae que insano utilizar transações para processos invocados de maneira assíncrona, até pq o processamento assíncrono é desacoplado do chamador. O chamador pode efetivar o commit sem que necessariamente o processo assíncrono tenha sido bem sucedido.
Conheço muito pouco de SOA vcs acaham que ler o livro UML Components seria uma boa introdução?