SOA e BPM no brasil engatinham vagarosamente ainda

Assuntos Gerais
#21

[quote=adriano_si]Esse livro é muito ruim para um zerado na tecnologia ???

http://www.submarino.com.br/produto/1/21576487/arquitetura+orientada+a+servicos+:+soa+para+leigos

Kenobi, se montar uma turma é possível receber as aulas pela On-line ??

Fico no aguardo…

Abs [][/quote]

Bom… nunca lí esse, mas dei uma conferida no material e parece ser bom para entender o que é, mas não como fazer. Ou seja, grandes chances de você entender o que é, etc., mas acabar precisando comprar outro livro pra aprender a fazer, de fato. Vai do quanto você achar que tem necessidade, por agora.

[]´s

#22

[quote=asaudate][quote=adriano_si]Esse livro é muito ruim para um zerado na tecnologia ???

http://www.submarino.com.br/produto/1/21576487/arquitetura+orientada+a+servicos+:+soa+para+leigos

Kenobi, se montar uma turma é possível receber as aulas pela On-line ??

Fico no aguardo…

Abs [][/quote]

Bom… nunca lí esse, mas dei uma conferida no material e parece ser bom para entender o que é, mas não como fazer. Ou seja, grandes chances de você entender o que é, etc., mas acabar precisando comprar outro livro pra aprender a fazer, de fato. Vai do quanto você achar que tem necessidade, por agora.

[]´s[/quote]

A idéia é saber o que é mesmo… já comecei a estudar as coisas logo pelo COMO FAZER e até hoje me arrependo… Desde então procuro começar do começo mesmo…

Abs []

#23

[quote=adriano_si]Esse livro é muito ruim para um zerado na tecnologia ???

http://www.submarino.com.br/produto/1/21576487/arquitetura+orientada+a+servicos+:+soa+para+leigos

Kenobi, se montar uma turma é possível receber as aulas pela On-line ??

Fico no aguardo…

Abs [][/quote]

Quanto ao livro, acho que ele pode te dar uma visão inicial, embora muita coisa tenha mudado. O livro de Rest do Leonard Richardson e Sam Ruby é excelente, assim como o Rest in Pratice do Jim Webber e cia.

Os livros do Thomas Erl, trazem a visão clássica, do conceito mais tradicional e também são excelentes para você aprender toda a base histórica. Sem história, não há evolução.

Quanto as turmas, são presenciais com laboratório super equipado, pois aqui na soa|expert, power point é só pra ilustrar conceito :slight_smile: , depois é mão na massa e quando entramos em produtos, os computadores são bem parrudos. Todos Core i5 com 8gb de memória e monitor wide de 19. Essa estrutura é muito importante para seu bom aprendizado :-).

E para quem está em SP, dia 29 vamos fazer um minicurso de SOA gratuíto em parceria com a Globalcode - http://www.globalcode.com.br/gratuitos/minicursos/minicurso-introducao-a-soa. Acho que vale à pena o pessoal que está interessado no tema :-).

Ah, notinha que saiu no InfoQ sobre SOA: http://www.infoq.com/br/news/2010/11/SOARising

E o jabazinho básico da nossa formação :slight_smile: - http://www.soaexpert.com.br/cursos/fsoa

PS: Em janeiro, vamos começar a turma intensiva de férias para as pessoas de outras regiões, fazerem a formação durante período integral, encurtando o tempoda formação. !!

#24

[quote=Kenobi][quote=adriano_si]Esse livro é muito ruim para um zerado na tecnologia ???

http://www.submarino.com.br/produto/1/21576487/arquitetura+orientada+a+servicos+:+soa+para+leigos

Kenobi, se montar uma turma é possível receber as aulas pela On-line ??

Fico no aguardo…

Abs [][/quote]

Quanto ao livro, acho que ele pode te dar uma visão inicial, embora muita coisa tenha mudado. O livro de Rest do Leonard Richardson e Sam Ruby é excelente, assim como o Rest in Pratice do Jim Webber e cia.

Os livros do Thomas Erl, trazem a visão clássica, do conceito mais tradicional e também são excelentes para você aprender toda a base histórica. Sem história, não há evolução.

Quanto as turmas, são presenciais com laboratório super equipado, pois aqui na soa|expert, power point é só pra ilustrar conceito :slight_smile: , depois é mão na massa e quando entramos em produtos, os computadores são bem parrudos. Todos Core i5 com 8gb de memória e monitor wide de 19. Essa estrutura é muito importante para seu bom aprendizado :-).

E para quem está em SP, dia 29 vamos fazer um minicurso de SOA gratuíto em parceria com a Globalcode - http://www.globalcode.com.br/gratuitos/minicursos/minicurso-introducao-a-soa. Acho que vale à pena o pessoal que está interessado no tema :-).

Ah, notinha que saiu no InfoQ sobre SOA: http://www.infoq.com/br/news/2010/11/SOARising

E o jabazinho básico da nossa formação :slight_smile: - http://www.soaexpert.com.br/cursos/fsoa

PS: Em janeiro, vamos começar a turma intensiva de férias para as pessoas de outras regiões, fazerem a formação durante período integral, encurtando o tempoda formação. !!

[/quote]

Percebo que você insiste no uso de REST, pura e simplesmente… Qual o motivo ?? mais comercial ??

Quanto ao curso, infelizmente ainda é inviável… quem sabe no decorrer de 2011…

Abs[]

#25

Só um porém: alguém mencionou o Apache Camel como sendo um ESB. Não acho que seja. É uma plataforma de integração que pode ser usada dentro de um ESB, como o ServiceMix.

PS: somente minha opinião, YMMV, IMHO, take with a ton of salt, ignore please

#26

Quanto ao tópico, é verdade… SOA e BPM engatinham no Brasil.

Vc encontra:

  1. empresas com áreas de Governança que possuem funcionários despreparados (longe de saber o que significam conceitos como Arquitetura Corporativa, Arquitetura de Referência e Modelo Canônico).

  2. empresas que dizem implementar SOA só pq estão integrando sistema X com sistema Y através de um barramento.

  3. empresas que não estão dispostas a pagar por um ESB ou por um BPM, mas que acabam contruindo um substituto meia-boca e depois chegam à conclusão que SOA não presta para nada.

  4. fornecedores despreparados para ensinar o caminho das pedras na adoção de SOA.

Só uma observação: é verdade que dá pra implementar SOA sem ferramentas (BPM, BPEL, ESB, etc), mas é bem mais difícil e custoso. É algo como construir um prédio com pá, martelo e talhadeira.

#27

[quote=adriano_si]
Percebo que você insiste no uso de REST, pura e simplesmente… Qual o motivo ?? mais comercial ??

Quanto ao curso, infelizmente ainda é inviável… quem sabe no decorrer de 2011…

Abs[][/quote]

O Kenobi insiste porque ele adoooora REST =P

Você esperaria algo diferente de um entusiasta Ruby ???

[]´s!!

#28

[quote=andre_salvati]Quanto ao tópico, é verdade… SOA e BPM engatinham no Brasil.

Vc encontra:

  1. empresas com áreas de Governança que possuem funcionários despreparados (longe de saber o que significam conceitos como Arquitetura Corporativa, Arquitetura de Referência e Modelo Canônico).

  2. empresas que dizem implementar SOA só pq estão integrando sistema X com sistema Y através de um barramento.

  3. empresas que não estão dispostas a pagar por um ESB ou por um BPM, mas que acabam contruindo um substituto meia-boca e depois chegam à conclusão que SOA não presta para nada.

  4. fornecedores despreparados para ensinar o caminho das pedras na adoção de SOA.

Só uma observação: é verdade que dá pra implementar SOA sem ferramentas (BPM, BPEL, ESB, etc), mas é bem mais difícil e custoso. É algo como construir um prédio com pá, martelo e talhadeira.

[/quote]

Esqueceu de citar um:

  1. Fornecedores que sabem que o cliente não tem conhecimento de SOA e, portanto, enfiam goela abaixo tudo que aparecer de mais caro no meio do caminho.

[]´s

#29

Por favor veja: www.soasymposium.com

Abraço,

#30

Fui eu que te falou usso né? :slight_smile:

Não sei se esse problema acontece apenas no Brasil.

Kenobi, o meu problema com SOA nunca foi o conceito em si e sim como “ferramentas SOA corporativas” e como geralmente é vendido. Google Maps, Facebook, Twitter, etc, são alguns dos exemplos de APIs a serem utilizadas por plataformas heterogêneas ou APIs que usam recursos de outras plataformas. Quantos desses caras usam ESB e BPEL para fazer integração? Tenho quase certeza que nenhum.

Acho que você não precisa de nenhum produto SOA para implementar “APIs para ser utilizadas por plataformas heterogêneas”. Acho também que o mais difícil é definir como vai funcionar a troca de mensagens entre os sistemas (principalmente como vai ser as interfaces), a granularidade dos serviços e qual sistema deve possuir quais serviços. Se você conseguir fazer bem essas três coisas, você terá um ambiente em que as aplicações tem APIs bem definidas, que conversam entre si, resultando em reaproveitamento de funcionalidades entre os sistemas. E esse é um trabalho que nenhum produto pode fazer por você.

IMHO, os produtos podem teoricamente ajudar você a implementar a forma de comunicação entre os sistemas. Mas essa não é a parte mais difícil (nem mais crítica para o sucesso).

#31

Já falei…

não é pq meu projetinho faz uma integração com Google Maps que eu estou usando SOA CORPORATIVAMENTE.

Vamos deixar de pensar isoladamente e começar a pensar no todo. Que tal um ERP com 250 integrações com sistemas legados para começar?

É por isso que SOA tem sido um fracasso. Não existe estratégia de adoção em nível corporativo. Para uns SOA é a tromba do elefonte, para outros SOA é a perna do elefante e para outros SOA é bunda do elefante.

É ingenuidade querer controlar um ambiente corporativo com 1000, 2000, 3000 serviços sem ferramentas.

#32

[quote=Claynor]Por favor veja: www.soasymposium.com

Abraço,[/quote]

Estive lá!

[]´s

#33

[quote=Rubem Azenha][quote=asaudate]
(aliás, já fui obrigado a engolir, de uma pessoa que teve péssima experiência com a arquitetura, que SOA nada mais é do que um engodo feito para vender produtos, quando não podia estar mais longe da intenção)
[/quote]
Fui eu que te falou usso né? :slight_smile:
[/quote]

Por acaso!

Tenho certeza que não, mas acho que aqui isso acontece com mais frequencia, simplesmente porque nossa cultura é assim.

[quote=Rubem Azenha]

Kenobi, o meu problema com SOA nunca foi o conceito em si e sim como “ferramentas SOA corporativas” e como geralmente é vendido. Google Maps, Facebook, Twitter, etc, são alguns dos exemplos de APIs a serem utilizadas por plataformas heterogêneas ou APIs que usam recursos de outras plataformas. Quantos desses caras usam ESB e BPEL para fazer integração? Tenho quase certeza que nenhum.

Acho que você não precisa de nenhum produto SOA para implementar “APIs para ser utilizadas por plataformas heterogêneas”. Acho também que o mais difícil é definir como vai funcionar a troca de mensagens entre os sistemas (principalmente como vai ser as interfaces), a granularidade dos serviços e qual sistema deve possuir quais serviços. Se você conseguir fazer bem essas três coisas, você terá um ambiente em que as aplicações tem APIs bem definidas, que conversam entre si, resultando em reaproveitamento de funcionalidades entre os sistemas. E esse é um trabalho que nenhum produto pode fazer por você.

IMHO, os produtos podem teoricamente ajudar você a implementar a forma de comunicação entre os sistemas. Mas essa não é a parte mais difícil (nem mais crítica para o sucesso).[/quote]

Aeeee!! ESSA é a idéia! Existem patterns em SOA, assim como em qualquer outro tipo de ambiente. O caso é que, como em qualquer tipo de ambiente, algumas pessoas não enxergam patterns como conselhos, e sim, como regras. Moral da história: alguma coisa sai problemática no processo.

[]´s

#34

[quote=andre_salvati]Já falei…

não é pq meu projetinho faz uma integração com Google Maps que eu estou usando SOA CORPORATIVAMENTE.

Vamos deixar de pensar isoladamente e começar a pensar no todo. Que tal um ERP com 250 integrações com sistemas legados para começar?

É por isso que SOA tem sido um fracasso. Não existe estratégia de adoção em nível corporativo. Para uns SOA é a tromba do elefonte, para outros SOA é a perna do elefante e para outros SOA é bunda do elefante.

É ingenuidade querer controlar um ambiente corporativo com 1000, 2000, 3000 serviços sem ferramentas.
[/quote]

Concordo plenamente!!

[]´s

#35

[quote=Rubem Azenha][quote=asaudate]
(aliás, já fui obrigado a engolir, de uma pessoa que teve péssima experiência com a arquitetura, que SOA nada mais é do que um engodo feito para vender produtos, quando não podia estar mais longe da intenção)
[/quote]
Fui eu que te falou usso né? :slight_smile:

Não sei se esse problema acontece apenas no Brasil.

Kenobi, o meu problema com SOA nunca foi o conceito em si e sim como “ferramentas SOA corporativas” e como geralmente é vendido. Google Maps, Facebook, Twitter, etc, são alguns dos exemplos de APIs a serem utilizadas por plataformas heterogêneas ou APIs que usam recursos de outras plataformas. Quantos desses caras usam ESB e BPEL para fazer integração? Tenho quase certeza que nenhum.

Acho que você não precisa de nenhum produto SOA para implementar “APIs para ser utilizadas por plataformas heterogêneas”. Acho também que o mais difícil é definir como vai funcionar a troca de mensagens entre os sistemas (principalmente como vai ser as interfaces), a granularidade dos serviços e qual sistema deve possuir quais serviços. Se você conseguir fazer bem essas três coisas, você terá um ambiente em que as aplicações tem APIs bem definidas, que conversam entre si, resultando em reaproveitamento de funcionalidades entre os sistemas. E esse é um trabalho que nenhum produto pode fazer por você.

IMHO, os produtos podem teoricamente ajudar você a implementar a forma de comunicação entre os sistemas. Mas essa não é a parte mais difícil (nem mais crítica para o sucesso).[/quote]

Onde e em qual momento, citei ESB ou BPEL ? Acompanhe a discussão aqui e no Tectura e entenderá minha posição e quando utilizar tais - http://www.tectura.com.br/topics/rest_vs_soap_para_plataformas_baseadas_em_servicos

Exatamente o que eu disse o tempo todo aqui. Você não precisa de produtos pra fazer SOA e eu não recomendo a utilização de nenhum, à menos que tenha fortes motivações.

Falei exatamente em fazer uma API bem feita, usar técnicas como BDD e DDD e se tiver em Http, Restful e ainda citei os frameworks Restfulie e Vraptor. Logo, acho que sua visão pré-concebida ao meu respeito ou ao SOA, não o fez ler todas as minhas colocações e convicções.

#36

Bom, vou responder agora todos que passaram por aqui. Desculpem-me de não responder em tempo, mas realmente não ando tendo tempo livre.

[quote]adriano_si

Percebo que você insiste no uso de REST, pura e simplesmente… Qual o motivo ?? mais comercial ??

Quanto ao curso, infelizmente ainda é inviável… quem sabe no decorrer de 2011…

Abs[][/quote]

Eu insisto no uso do Rest pelo simples motivo de qualquer design de software deve começar pelo mais simples e eficiente. Rest além de ser mais simples que a Stack WS-*, é muitíssimo mais eficiente para cenários de integração e composição.

Aliás o WS-I fechou as portas, http://www.infoq.com/news/2010/11/wsi-closes.

Está rolando uma discussão de excelente nível técnico no Tectura - http://www.tectura.com.br/topics/rest_vs_soap_para_plataformas_baseadas_em_servicos e seria muito interessante lerem todas as réplicas e tréplicas para entenderem as motivações.

[quote]
esmiralha
Só um porém: alguém mencionou o Apache Camel como sendo um ESB. Não acho que seja. É uma plataforma de integração que pode ser usada dentro de um ESB, como o ServiceMix.

PS: somente minha opinião, YMMV, IMHO, take with a ton of salt, ignore please[/quote]

Sim o Apache Camel é um ESB, pois o fundamento de um “ESB” é a composição de diversos Bus, técnica nasceu à partir do hub and spoke.

Um ESB na verdade, se trata da implementação do conjunto de patterns de integração http://camel.apache.org/enterprise-integration-patterns.html e se você pegar todos os produtos, até o mais parrudo do mercado - Oracle Service Bus (antigo ALSB-BEA) vai reparar que trabalham exatamente da mesma forma.

As diferenças estão nos itens gerenciais, que não são cobertos diretamente pelo Apache Camel, como Throttling ou monitoria de SLA dos serviços, por isso os ESB de segunda geração levam o “E” de enterprise e o Camel seria um Light ESB e se vocês quiserem uma explicação oficial dos próprios fundadores do projeto: http://camel.apache.org/is-camel-an-esb.html

Particularmente eu o considero o Kernel de um ESB e muito mais interessante que muitos produtos, por conta da sua DSL-Fluent API - http://camel.apache.org/dsl.html.

Só um comentário, ministro treinamento de ESB e conheço diversos produtos e até desenvolvi adaptadores, tenho uma visão muito clara sobre o produto e na soaexpert, estamos tentando fazer uma nova versão de um “caninho”, com conceitos de Web para patterns de integração, como RestMS - http://www.restms.org, Salmon, OAuth entre outros :slight_smile:

PS: “Caninho” como os ESBs são apresentados em Slides, e não chamaremos de ESB, pois é muito enterprisey. Será um framework de integração orientado a web.

#37

[quote]andre_salvati Quanto ao tópico, é verdade… SOA e BPM engatinham no Brasil.

Vc encontra:

  1. empresas com áreas de Governança que possuem funcionários despreparados (longe de saber o que significam conceitos como Arquitetura Corporativa, Arquitetura de Referência e Modelo Canônico).

  2. empresas que dizem implementar SOA só pq estão integrando sistema X com sistema Y através de um barramento.

  3. empresas que não estão dispostas a pagar por um ESB ou por um BPM, mas que acabam contruindo um substituto meia-boca e depois chegam à conclusão que SOA não presta para nada.

  4. fornecedores despreparados para ensinar o caminho das pedras na adoção de SOA.

Só uma observação: é verdade que dá pra implementar SOA sem ferramentas (BPM, BPEL, ESB, etc), mas é bem mais difícil e custoso. É algo como construir um prédio com pá, martelo e talhadeira.
[/quote]

1- Pior que isso, os desenvolvedores não sabem modelar software, fato. Logo, o buraco é mais embaixo e confesso, que DDD junto à BDD me auxiliaram muito nesse último ano, pois também sofri com o problema. Estudei muito modelagem no último ano, pois percebi que conhecer tecnicamente as soluções não adiantava nada se você não souber modelar corretamente.

  1. Integração != de SOA, outra confusão. Você pode utilizar um ESB somente para esse fim, mas tem que ficar claro o que está fazendo.

  2. As empresas não precisam comprar nenhum dos produtos citados sem que tenham realmente necessidade para isso. Como disse anteriormente, ninguém implementa um pattern sem motivação. BPM é ferramenta de engenharia de software, auxiliará a equipe de Domian Experts à extrairem um melhor modelo, mas não serve para implementação Top-Down, esse é um dos grandes erros de pseudo-experts em SOA.

  3. Completamente de acordo. SOA exige muito estudo, muitas bibliografias diferentes. O mundo do SOA hoje está dividido em :

  • Quem ouviu falar e não sabe nada, macacos treinados de produtos
  • Pessoas que leram 1 ou 2 livros do Thomas Erl ou blogs e se acham especialistas e vão pelo design “clássico”
  • Restafarians que possuem aversão à WS-*, Thomas Erl e afins, e não abrem a mente para analisar outras possibilidades ou ao menos ensinamentos de modelagem, que podem ser úteis no ambiente Rest, como: EntityServices , TaskServices, Document Style etc.

E o que estamos fazendo na soaexpert, é dar a base sólida teórica, modelagem e ferramental, caso seja necessária a utilização e à partir daí, as melhores práticas com tais.

Por fim, é mais simples e infinitamente menos custoso implementar SOA sem ferramental (pesado), desde que você não precise delas. Se não tiver integrações com outros protocolos como SNA (mainframe), por exemplo.

Se o projeto for inteiro novo, faça-o inteiro em cima de http e utilizem técnicas modernas. Não escrevam novos legados :-). Aliás, todos os ESBs modernos, respondem ao menos na escala 2 do Leornad Richardson, basta saber usar.

Aliás, quem quiser ver um vídeo de um talk que fiz no GuruSP sobre em que cenários se utilizaria WS-(*), o oposto do que estou dizendo aqui, basta acessar / http://blip.tv/file/4164217. São só 10 minutos, não vai doer :slight_smile:

#38

[quote=Kenobi][quote]andre_salvati Quanto ao tópico, é verdade… SOA e BPM engatinham no Brasil.

Vc encontra:

  1. empresas com áreas de Governança que possuem funcionários despreparados (longe de saber o que significam conceitos como Arquitetura Corporativa, Arquitetura de Referência e Modelo Canônico).

  2. empresas que dizem implementar SOA só pq estão integrando sistema X com sistema Y através de um barramento.

  3. empresas que não estão dispostas a pagar por um ESB ou por um BPM, mas que acabam contruindo um substituto meia-boca e depois chegam à conclusão que SOA não presta para nada.

  4. fornecedores despreparados para ensinar o caminho das pedras na adoção de SOA.

Só uma observação: é verdade que dá pra implementar SOA sem ferramentas (BPM, BPEL, ESB, etc), mas é bem mais difícil e custoso. É algo como construir um prédio com pá, martelo e talhadeira.
[/quote]

1- Pior que isso, os desenvolvedores não sabem modelar software, fato. Logo, o buraco é mais embaixo e confesso, que DDD junto à BDD me auxiliaram muito nesse último ano, pois também sofri com o problema. Estudei muito modelagem no último ano, pois percebi que conhecer tecnicamente as soluções não adiantava nada se você não souber modelar corretamente.

  1. Integração != de SOA, outra confusão. Você pode utilizar um ESB somente para esse fim, mas tem que ficar claro o que está fazendo.

  2. As empresas não precisam comprar nenhum dos produtos citados sem que tenham realmente necessidade para isso. Como disse anteriormente, ninguém implementa um pattern sem motivação. BPM é ferramenta de engenharia de software, auxiliará a equipe de Domian Experts à extrairem um melhor modelo, mas não serve para implementação Top-Down, esse é um dos grandes erros de pseudo-experts em SOA.

  3. Completamente de acordo. SOA exige muito estudo, muitas bibliografias diferentes. O mundo do SOA hoje está dividido em :

  • Quem ouviu falar e não sabe nada, macacos treinados de produtos
  • Pessoas que leram 1 ou 2 livros do Thomas Erl ou blogs e se acham especialistas e vão pelo design “clássico”
  • Restafarians que possuem aversão à WS-*, Thomas Erl e afins, e não abrem a mente para analisar outras possibilidades ou ao menos ensinamentos de modelagem, que podem ser úteis no ambiente Rest, como: EntityServices , TaskServices, Document Style etc.

E o que estamos fazendo na soaexpert, é dar a base sólida teórica, modelagem e ferramental, caso seja necessária a utilização e à partir daí, as melhores práticas com tais.

Por fim, é mais simples e infinitamente menos custoso implementar SOA sem ferramental (pesado), desde que você não precise delas. Se não tiver integrações com outros protocolos como SNA (mainframe), por exemplo.

Se o projeto for inteiro novo, faça-o inteiro em cima de http e utilizem técnicas modernas. Não escrevam novos legados :-). Aliás, todos os ESBs modernos, respondem ao menos na escala 2 do Leornad Richardson, basta saber usar.

Aliás, quem quiser ver um vídeo de um talk que fiz no GuruSP sobre em que cenários se utilizaria WS-(*), o oposto do que estou dizendo aqui, basta acessar / http://blip.tv/file/4164217. São só 10 minutos, não vai doer :slight_smile: [/quote]

Para aqueles que, assim como eu , estavam perdidos em relação a essa escala que o Kenobi cita, abaixo segue uma figura que ilustra:

Quanto aos tipos de ESB… IMHO, não existem Light ESB´s ou Enterprise ESB (nossa, que coisa redundante!). Apenas ESB´s com mais ou menos features a mais, que não impactam na definição da ferramenta como ESB.

[]´s

#39

Se vc estiver fazendo integração ponto-a-ponto realmente não é necessário ferramental. Se vc estiver implementando SOA de verdade, ou seja um ARQUITETURA ORIENTADA A SERVIÇOS EM NÍVEL CORPORATIVO, as ferramentas são essenciais.

Eu concordo e até adoto a filosofia da Agilidade segundo a qual só se implementa quando precisa. Só que a questão aqui não é de implementação, a questão é de uso. As ferramentas estão lá e se uma grande empresa está querendo organizar a bagunça, vc simplesmente escolhe a ferramenta correta e usa.

Não existem projetos novos em SOA. Os legados estão lá integrados da forma que estão (mainframe, PL/SQL, JMS, HTTP, etc). SOA se propõe a organizar a bagunça. Tem que trocar o motor com o avião no ar.

#40

[quote=andre_salvati][quote=Kenobi]
Por fim, é mais simples e infinitamente menos custoso implementar SOA sem ferramental (pesado), desde que você não precise delas. Se não tiver integrações com outros protocolos como SNA (mainframe), por exemplo.

[/quote]

Se vc estiver fazendo integração ponto-a-ponto realmente não é necessário ferramental. Se vc estiver implementando SOA de verdade, ou seja um ARQUITETURA ORIENTADA A SERVIÇOS EM NÍVEL CORPORATIVO, as ferramentas são essenciais.

Eu concordo e até adoto a filosofia da Agilidade segundo a qual só se implementa quando precisa. Só que a questão aqui não é de implementação, a questão é de uso. As ferramentas estão lá e se uma grande empresa está querendo organizar a bagunça, vc simplesmente escolhe a ferramenta correta e usa.

Não existem projetos novos em SOA. Os legados estão lá integrados da forma que estão (mainframe, PL/SQL, JMS, HTTP, etc). SOA se propõe a organizar a bagunça. Tem que trocar o motor com o avião no ar.
[/quote]

Podem existir, sim, projetos novos em SOA. É só questão de saber dar nome aos bois, ou seja, é SOA ou SOA-Ready ???

Quanto à colocação do Kenobi, eu só tenho uma ressalva: na época que os legados foram escritos, alguns deles usavam técnicas modernas em suas épocas, também. Ou seja, não dá pra dizer que a técnica que você usa hoje vai se manter sempre atualizada :wink:

[]´s!