Completando a listinha acima:
[quote=jprogrammer]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.
[/quote]
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:
- 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.
[quote=Taz]
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.[/quote]
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
[quote=Taz][quote=louds]
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.
[/quote]
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.
[/quote]
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.
[quote=louds]
Transações Distribuidas acabam com o loose coupling que SOA promovem, é um retrocesso.[/quote]
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:
[quote=Maron, Pavlik e Little]Using distributed transactions JavaTM application appears easy
but�
Using transactions correctly is a little more difficult![/quote]
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”.
[quote=Taz]
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.[/quote]
[quote=Taz]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.