SOA e BPM no brasil engatinham vagarosamente ainda

121 respostas
S

Eu não tenho dados oficiais pois não sei se existem pesquisas no nosso país sérias sobre tecnologia. O Gartner Group sequer deve nos considerar dignos de sua atenção mas minha visão do mercado SOA no país é que este ainda engatinha vagarosamente. Pouca gente sequer conhece sobre SOA e a maioria dos que vejo ou converso por ai tem noções equivocadas sobre serviços.
Muita gente acha que SOA é um ESB plugado com muitos webservices e mais nada, sendo que nem um nem outro é imprescindivel para SOA. No mercado de trabalho vejo muita proposta para vagas em Java, JSP, Struts, JSF e banco oracle alem de noções de orientação a objeto. O que obviamente já demonstra que não se está investindo na construção de serviços e sim na manutenção e construçaõ de sistemas monoliticos sem visão de negócio, escopo limitadissimo e funcionalidades que dificilmente serão reaproveitadas.

O que podemos fazer para mudar esse quadro? Começarmos antes de mais nada a estudar, literatura conceituada de fornecedores e mesmo independentes como Thomas Erl e companhia que alias tem um belo catalogo de design patterns que fariam passar vergonha qualquer ‘entendidinho’ em SOA. Com base nesse arcabouço teórico estimular o uso dos principios e sua aplicação, sem isso não iremos sair dessa inércia e a continuar com os mesmos problemas de sempre nesses sistemas intermináveis e que agregam pouco valor ao negócio. Não importa quantos design patterns java ee voce implemente, se eles não agregam valor ao negócio eles não servem para nada, jogue-os fora e comece do zero.

Estou postando aqui pois é em Java que temos as melhores ferramentas SOA BPM existentes e vejo pouca coisa de movimentação da comunidade em busca da orientação a serviços atualmente no Brasil.

121 Respostas

A

SOA foi a moda que mais me interessou até agora… Calma, antes de me bater, deixa eu te explicar porque chamo de moda…

Sempre que vejo alguma letrinha na TI e vejo muita gente falando nela, fico meio que assustado por achar que estou anos luz atrás de outros profissionais em Tecnologia, com SOA não foi diferente… SOA moda pelo simples motivo que você falou… tem um monte de gente dizendo que sabe SOA e no máximo sabe ESB ou fazer WS e jura que manja de SOA…

Um dia, muito aturdido quanto ao assunto e botando a cabeça pra funcionar de verdade me esforcei pra ler um material de SOA em inglês… Como meu inglês é bem básico demorei um tempinho pra absorver a idéia central do material e percebi que o que você falou é uma realidade, metade das pessoas que dizem que sabem SOA, não sabem nem metade do que SOA significa…

A Carência de materiais de estudos e profissionais qualificados na área, de fato desacelera o processo de adoção de uma determinada tecnologia… Mas vai ser assim em qualquer lugar cara, infelizmente não posso largar o que to fazendo agora :frowning: pra estudar algo que dificilmente colocarei em prática tão cedo em minha região… Outro dia conversando com um gerente, tava tentando explicar TDD pra ele, ele disse na minha cara que isso era “perda de tempo”… Enfim :frowning:

A

Sparcx86:
Eu não tenho dados oficiais pois não sei se existem pesquisas no nosso país sérias sobre tecnologia. O Gartner Group sequer deve nos considerar dignos de sua atenção mas minha visão do mercado SOA no país é que este ainda engatinha vagarosamente. Pouca gente sequer conhece sobre SOA e a maioria dos que vejo ou converso por ai tem noções equivocadas sobre serviços.
Muita gente acha que SOA é um ESB plugado com muitos webservices e mais nada, sendo que nem um nem outro é imprescindivel para SOA. No mercado de trabalho vejo muita proposta para vagas em Java, JSP, Struts, JSF e banco oracle alem de noções de orientação a objeto. O que obviamente já demonstra que não se está investindo na construção de serviços e sim na manutenção e construçaõ de sistemas monoliticos sem visão de negócio, escopo limitadissimo e funcionalidades que dificilmente serão reaproveitadas.

O que podemos fazer para mudar esse quadro? Começarmos antes de mais nada a estudar, literatura conceituada de fornecedores e mesmo independentes como Thomas Erl e companhia que alias tem um belo catalogo de design patterns que fariam passar vergonha qualquer ‘entendidinho’ em SOA. Com base nesse arcabouço teórico estimular o uso dos principios e sua aplicação, sem isso não iremos sair dessa inércia e a continuar com os mesmos problemas de sempre nesses sistemas intermináveis e que agregam pouco valor ao negócio. Não importa quantos design patterns java ee voce implemente, se eles não agregam valor ao negócio eles não servem para nada, jogue-os fora e comece do zero.

Estou postando aqui pois é em Java que temos as melhores ferramentas SOA BPM existentes e vejo pouca coisa de movimentação da comunidade em busca da orientação a serviços atualmente no Brasil.

Pois é, a coisa anda meio complicada, mesmo. Como alguns aqui do fórum devem saber, eu sou consultor SOA, e a sua visão do mercado não é nem um pouco equivocada, ao contrário…

No entanto, a falha da adoção de SOA no mercado brasileiro está nas próprias pessoas responsáveis pela implementação, já que, como você mesmo disse, muitos pensam que SOA é composto de ESB´s e web services (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).

Alguns vendors, aqui no Brasil, fazem questão de promover SOA para vender seus produtos. Eu mesmo tive uma péssima experiência com uma consultoria parceira da Oracle (obviamente, não vou revelar o nome dessa consultoria aqui), onde o próprio vendedor se encarregou de “empurrar” os produtos pela goela do cliente. Não tínhamos necessidade de NENHUM desses produtos, aliás, o uso dos mesmos, por ser empurrado, acabou prejudicando a arquitetura, atrasando o projeto e me forçando a pedir demissão da consultoria, pois não aceitava mais a situação como um todo.

Hoje, trabalho em uma empresa que trabalha estas questões com mais responsabilidade, e nos esforçamos ao máximo para promover o reuso dos serviços, além de promover a governança SOA com nossos clientes. É direito do cliente usar uma tecnologia para seu benefício, não para fazer com que ele gaste rios de dinheiro com ferramentas que não vão trazer o ROI esperado.

No entanto, a impressão que tenho tido, até agora, é que praticamente todas as empresas que vendem SOA (especialmente aquelas gigantes de três letrinhas) não têm essa responsabilidade, o que acaba atrasando a adoção da tecnologia.

O outro lado da moeda é que não vejo essa situação somente no Brasil. Já trabalhei com este tipo de arquitetura em projetos fora do Brasil e devo dizer que as implementações de serviços e SOA são iguais às daqui. Tendo a pensar que, dada a complexidade da tecnologia, as pessoas tendem a não conseguir implementar de maneira ideal SOA. Aliás, SOA é tão complicado que mesmo as pessoas que parecem que conhecem muito bem a arquitetura, no final das contas, parecem nunca ter implementado uma de fato. Recentemente, assistí a uma palestra da Anne Thomas, do Gartner Group, em Berlin (no SOA Symposium, pra ser específico). A impressão que ela me deixou é de que faz, pelo menos, alguns anos que ela não senta na frente de um computador para escrever uma única linha de código. O que ela disse, na palestra, está beeem distante de ser uma realidade.

Assim, só para concluir… SOA é uma fria? Não, não é. Só que deve ser adotada com seriedade, porque muita gente aproveitou o hype para embarcar na onda. Muitos clientes são ignorantes do fato de que (como o próprio Thomas Erl disse) uma implementação inicial de SOA costuma levar 30% a mais do que uma implementação de arquitetura convencional. O ROI prometido por SOA é dado a longo prazo; quem tiver paciência, verá.

[]´s

F

Eu idem!

Desisti de estudar sobre o assunto por perceber rapidamente que o mercado não estava entendendo realmente o conceito. Logo a adoção seria difícil de acontecer. A gota d’àgua foi quando participei de uma entrevista e puxaram o assunto sobre SOA. Não era pré-requisito para a vaga mas como o assunto apareceu comecei a explorar o entendimento que havia no local. A conclusão foi exatamente esta que vcs descreveram.

flws

A

Aí o buraco é ainda mais embaixo… Já é quase um divisor de águas então, tamanha as mudanças de filosofia aplicadas…

Abs []

A

adriano_si:

A Carência de materiais de estudos e profissionais qualificados na área, de fato desacelera o processo de adoção de uma determinada tecnologia… Mas vai ser assim em qualquer lugar cara, infelizmente não posso largar o que to fazendo agora :frowning: pra estudar algo que dificilmente colocarei em prática tão cedo em minha região… Outro dia conversando com um gerente, tava tentando explicar TDD pra ele, ele disse na minha cara que isso era “perda de tempo”… Enfim :frowning:

Aparentemente, algumas pessoas também pensam que SOA é só pra grandes empresas - no que estão erradas.

[]´s

A

Aí o buraco é ainda mais embaixo… Já é quase um divisor de águas então, tamanha as mudanças de filosofia aplicadas…

Abs []

Não acho que se trata de mudanças de filosofia; seria mais o caso de dizer que SOA deveria ter sempre a tutela de pessoas que não são nem gerentes nem peões de fábrica, ou seja, um nível mais tático da coisa. O irônico é que a governança SOA serve pra, justamente, dizer como a coisa deve ser feita, mas nunca ví uma única empresa sequer disposta a implementar SOA com governança.

[]´s

A

fala asaudte…

realmente não sei nem por onde começar… mas não é o fato de serem pequenas empresas… o fato é conseguir vender a idéia ao empresariado aqui…

Talvez somente umas de nossas redes de supermercados grandes… e quando digo talvez, é talvez mesmo, porque até isso acho inviável… temos que suar pra vender Sistemas WEB convencionais, imagina então aplicar uma nova “Forma” de Disponibilizar e compartilhar informações…

A menos que me digas que posso implantar sem problemas SOA em meus projetos pessoais para criação de Sistemas de Escolas e Eventos… se for possível, vou começar a pensar com carinho no estudo da mesma já pra 2011…

Abs []

K

Bom amigos, como muitos sabem, fudei uma startup de treinamento de SOA - SOA|EXPERT e anunciei aos amigos aqui no GUJ, pelo simples motivo que não faz sentido criarmos mais softwares de forma monolítica.

O que é SOA ? Simplesmente é uma maneira de você escrever sua API para ser utilizada por plataformas heterogêneas ou sua API usar “recursos”, de outras plataformas.

Tão simples quanto isso e o maior Case de SOA hoje é : Google Maps. :slight_smile: Quantas aplicações fazem uso dessa API, de diversas plataformas ?

Projetar sua API para outras plataformas consumirem, exige um pouco de planejamento e algumas técnicas.

Estamos discutindo de forma mais aprofundada aqui algumas diferenças em cima de Request-Driven, lembrando que ainda existe Event-Driven: http://www.tectura.com.br/topics/rest_vs_soap_para_plataformas_baseadas_em_servicos ( fórum dos samurais )

Quanto aos produtos, eles são a implementação de Patterns. Qual é a regra para adoção de um pattern mesmo ?
Resposta: - MOTIVAÇÃO !

Sem motivação, não existe a necessidade.

Infelizmente as empresas primeiro adquirem os patterns e depois tentam encaixar seus problemas. Foi o que aconteceu no projeto que o Alê citou, o player faz a venda e obriga o partner a aderir uma arquitetura “pré-moldada”, que visa a utilização e compra de novos produtos.

Quem tiver curiosidade e for acessar nossa Formação Consultor SOA - http://www.soaexpert.com.br/cursos/fsoa - Verá que citei algumas motivações para utilização dos produtos, como tradução de protocolos para um ESB.

Lembrando que sempre começamos do mais simples, para o mais complexo, logo devemos optar sempre que possível, por uma arquitetura mais simples como Restful.

Fazendo um jabazinho aqui, no curso o pessoal aprende Restfulie, Jersey, Coreweb que é pra forçar bem o design em cima de http puramente, usando técnicas de DDD e BDD para design :slight_smile:

K

adriano_si:
fala asaudte…

realmente não sei nem por onde começar… mas não é o fato de serem pequenas empresas… o fato é conseguir vender a idéia ao empresariado aqui…

Talvez somente umas de nossas redes de supermercados grandes… e quando digo talvez, é talvez mesmo, porque até isso acho inviável… temos que suar pra vender Sistemas WEB convencionais, imagina então aplicar uma nova “Forma” de Disponibilizar e compartilhar informações…

A menos que me digas que posso implantar sem problemas SOA em meus projetos pessoais para criação de Sistemas de Escolas e Eventos… se for possível, vou começar a pensar com carinho no estudo da mesma já pra 2011…

Abs []

Adriano, vc pode fazer com o VRaptor em java da caelum, bastando modelar em cima do estilo arquitetural Rest, você estará fazendo SOA :slight_smile: Simples não ?

K

Aí o buraco é ainda mais embaixo… Já é quase um divisor de águas então, tamanha as mudanças de filosofia aplicadas…

Abs []

Não acho que se trata de mudanças de filosofia; seria mais o caso de dizer que SOA deveria ter sempre a tutela de pessoas que não são nem gerentes nem peões de fábrica, ou seja, um nível mais tático da coisa. O irônico é que a governança SOA serve pra, justamente, dizer como a coisa deve ser feita, mas nunca ví uma única empresa sequer disposta a implementar SOA com governança.

[]´s

Só uma coisa Alê, ouvi do Jim Webber pessoalmente sobre governança: Se você tem demais, então seu design está errado !! Parei pra refletir e o cara está certo. Se pensarmos muito em modelagem prévia, estamos fazendo o BDUF-Waterfall. As chances de sucesso em qualquer cenário SOA ou não, todos já conhecem.

Acredito que a melhor maneira de fazer um design hoje é usando técnicas como DDD e BDD que irão orientar o design do seu recurso/serviço e aqui vale algumas regras também como evitar o Anemic Services Domain.

Esse é um erro bem comum e eu já incorri neste assim como outros arquitetos que utilizam as cartilhas de players ou Thomas Erl. Se olharmos um pouco mais da dica que o Jim Webber dá e o modelo do Eric Evans, dá pra imaginar uma camada de EntityServices rica.

Tentar separar a linha entre TaskServices e EntityServices. Modelar de forma coerente não é fácil, acho que essa é a parte que exige bastante literatura e aprendizado. Passei o último ano somente estudando esses assuntos, pois muitos acreditam que é o tecnês que pega num projeto SOA e como bem sabemos a modelagem, faz toda a diferença.

A

adriano_si:
fala asaudte…

realmente não sei nem por onde começar… mas não é o fato de serem pequenas empresas… o fato é conseguir vender a idéia ao empresariado aqui…

Talvez somente umas de nossas redes de supermercados grandes… e quando digo talvez, é talvez mesmo, porque até isso acho inviável… temos que suar pra vender Sistemas WEB convencionais, imagina então aplicar uma nova “Forma” de Disponibilizar e compartilhar informações…

A menos que me digas que posso implantar sem problemas SOA em meus projetos pessoais para criação de Sistemas de Escolas e Eventos… se for possível, vou começar a pensar com carinho no estudo da mesma já pra 2011…

Abs []

Opa!

Adriano, já ouviu falar de sistemas SOA-Ready ? Um sistema SOA-Ready é aquele que ainda não é SOA, mas todas as suas funcionalidades são, ou podem ser, expostas como serviços. Isso é um grande passo para influenciar na adoção de SOA. Você usa EJB´s em seus sistemas? Use a anotação @WebService neles e seja feliz (desde que, é lógico, esses EJB´s tenham nível de granularidade adequado, pra não haver, mais tarde, nenhuma lógica redundante). Uma vez expostos como serviços, estes componentes vão estar expostos pra outras linguagens, e moral da história que, no dia em que as empresas cansarem de Java, elas podem continuar aproveitando a lógica desenvolvida em Java em outras linguagens. Daí pra chegar no que é chamado de SOA, mesmo, é um passo.

[]´s

K

Bom respeito muito sua opinião, mas usar a annotation @WebServices é a pior coisa que o caboclo pode fazer. Primeiro que se o projeto está todo em cima de http, ele não precisa usar SOAP e o WS-Death Dead :-). O WS-I fechou as portas e SOAP deverá ser utilizado somente em cenários de integração.

Tentem modelar olhando para um design mais Restful das coisas e sejam felizes :slight_smile: Lembrando que o Jersey é RI da spec , apesar de não ter no nível 3 de maturidade da escala Richardson.

Aliás podem utilizar o VRaptor que é bem melhor e melhor ainda seria usar o Restfulie em cima do Rails, coisa fina :-).

Outra coisa, se sua empresa é pequena, provavelmente você não tem integração, logo não justifica um ESB. Se tiver poucas integrações, pode usar um light ESB como Apache Camel, recomendado inclusive pela Thought Works e olha que os caras detestam ESB por lá.

ESB é tão somente para projetos com uma certa criticidade, como fazer Throttling, diversos roteamentos, integração entre múltiplos protocolos, como SNA Mainframe, SAP e por aí vai…

A

Aí o buraco é ainda mais embaixo… Já é quase um divisor de águas então, tamanha as mudanças de filosofia aplicadas…

Abs []

Não acho que se trata de mudanças de filosofia; seria mais o caso de dizer que SOA deveria ter sempre a tutela de pessoas que não são nem gerentes nem peões de fábrica, ou seja, um nível mais tático da coisa. O irônico é que a governança SOA serve pra, justamente, dizer como a coisa deve ser feita, mas nunca ví uma única empresa sequer disposta a implementar SOA com governança.

[]´s

Só uma coisa Alê, ouvi do Jim Webber pessoalmente sobre governança: Se você tem demais, então seu design está errado !! Parei pra refletir e o cara está certo. Se pensarmos muito em modelagem prévia, estamos fazendo o BDUF-Waterfall. As chances de sucesso em qualquer cenário SOA ou não, todos já conhecem.

Acredito que a melhor maneira de fazer um design hoje é usando técnicas como DDD e BDD que irão orientar o design do seu recurso/serviço e aqui vale algumas regras também como evitar o Anemic Services Domain.

Esse é um erro bem comum e eu já incorri neste assim como outros arquitetos que utilizam as cartilhas de players ou Thomas Erl. Se olharmos um pouco mais da dica que o Jim Webber dá e o modelo do Eric Evans, dá pra imaginar uma camada de EntityServices rica.

Tentar separar a linha entre TaskServices e EntityServices. Modelar de forma coerente não é fácil, acho que essa é a parte que exige bastante literatura e aprendizado. Passei o último ano somente estudando esses assuntos, pois muitos acreditam que é o tecnês que pega num projeto SOA e como bem sabemos a modelagem, faz toda a diferença.

Fala, sumido ! ^^

Então… também acho que governança demais é sintoma de problemas, mas governança de menos também dá problemas. Não precisa ir muito longe, é só pensar em algum caso de empresa grande querendo aplicar SOA (trabalhei em uma assim). É regra: alguma parte da lógica de negócios vai acabar duplicada.

Não estou dizendo que precisamos de modelagem prévia, apenas que precisamos pensar a respeito da granularidade das coisas. E isso não é tão difícil assim de fazer, acaba sendo uma habilidade adquirida. Um desenvolvedor comum (tipo eu =P ) consegue pensar na granularidade dos serviços no dia-a-dia, mas pra isso precisa de prática. Adivinha quem vai guiar o aprendizado desse desenvolvedor?

Acho que DDD, BDD e outras técnicas podem ser aproveitadas junto com SOA, sim, mas na verdade não é disso que SOA se trata, mas sim, de reaproveitar lógica de negócios, e isso dá pra usar até em linguagens procedurais, que não dão suporte a DDD (o Luca deve conhecer algumas dessas ^^). Acredito eu que quem tentar desenvolver em Java com um certo nível de componentização terá surpresas agradáveis com SOA =) .

EDIT: quanto ao (eterno) embate SOAP x REST , vai minha opinião: cada um tem seu propósito, e coisas que fazem de melhor. Nenhum deles exclui SOA :wink:

[]´s

A

Opa… meio que entendí os 2… Me resumiram a questão respondendo que é possível… enfim, tá valendo investir meus estudos na Tecnologia…

Sim, eu uso EJBs… Quanto a discursão de vocês, já ultrapassou meu nível de conhecimento… quem sabe ano que vem eu não volte aqui pra contestar os 2… heueheueheueheueheuehueuhe

Agora uma pergunta que ficou meio no ar pra mim, afinal ainda não sei quem são os personagens Gurus da Tecnologia e ainda não conheço os Processos, onde posso encontrar algum material do tipo, “Oi eu soua SOA” pra começar ???

Abs[]

A

adriano_si:
Opa… meio que entendí os 2… Me resumiram a questão respondendo que é possível… enfim, tá valendo investir meus estudos na Tecnologia…

Sim, eu uso EJBs… Quanto a discursão de vocês, já ultrapassou meu nível de conhecimento… quem sabe ano que vem eu não volte aqui pra contestar os 2… heueheueheueheueheuehueuhe

Agora uma pergunta que ficou meio no ar pra mim, afinal ainda não sei quem são os personagens Gurus da Tecnologia e ainda não conheço os Processos, onde posso encontrar algum material do tipo, “Oi eu soua SOA” pra começar ???

Abs[]

Acredito eu que o material do Thomas Erl é muito bom nesse sentido, apesar de ser meio extenso. Tente dar uma olhada (rápida) nos livros dele e veja o que acha! E, claro, existe também a SOA|Expert, do nosso amigo Kenobi.

[]´s

K

O que eu quis dizer sobre DDD é que se você tem uma API bem modelada, o seu problema de reutilização será resolvido. O problema é tentar achar os serviços na bagunça de um problema de negócio, sentença, por isso comecei a adotar o design BDD. Facilitou e enxugou muita coisa, consegui complitude :slight_smile:

Aliás, vamos marcar uma gelada um dia desses !!

PS: Valews por mencionar a SOA|EXPERT :stuck_out_tongue:

A

Kenobi:
O que eu quis dizer sobre DDD é que se você tem uma API bem modelada, o seu problema de reutilização será resolvido. O problema é tentar achar os serviços na bagunça de um problema de negócio, sentença, por isso comecei a adotar o design BDD. Facilitou e enxugou muita coisa, consegui complitude :slight_smile:

Aliás, vamos marcar uma gelada um dia desses !!

PS: Valews por mencionar a SOA|EXPERT :stuck_out_tongue:

Acho que o “Problema” quanto a SOA|Expert é só a distância… Ou os cursos são On-line ???

Quanto ao material, irei dar uma estudada…

Abs []

A

adriano_si:
Kenobi:
O que eu quis dizer sobre DDD é que se você tem uma API bem modelada, o seu problema de reutilização será resolvido. O problema é tentar achar os serviços na bagunça de um problema de negócio, sentença, por isso comecei a adotar o design BDD. Facilitou e enxugou muita coisa, consegui complitude :slight_smile:

Aliás, vamos marcar uma gelada um dia desses !!

PS: Valews por mencionar a SOA|EXPERT :stuck_out_tongue:

Acho que o “Problema” quanto a SOA|Expert é só a distância… Ou os cursos são On-line ???

Quanto ao material, irei dar uma estudada…

Abs []

Que eu saiba, com demanda suficiente, tudo é possível :wink:

[]´s

A

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 []

A

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 []

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

A

asaudate:
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 []

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

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 []

K

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 []

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. !!

A

Kenobi:
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 []

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. !!

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[]

E

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

A

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.

A

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[]

O Kenobi insiste porque ele adoooora REST =P

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

[]´s!!

A

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.

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

C

Por favor veja: www.soasymposium.com

Abraço,

R

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).

A

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.

A

Claynor:
Por favor veja: www.soasymposium.com

Abraço,

Estive lá!

[]´s

A

Rubem Azenha:
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)

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

Por acaso!

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

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).

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

A

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.

Concordo plenamente!!

[]´s

K

Rubem Azenha:
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)

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).

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.

K

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.

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[]

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.


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

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.

K

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.

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:

A

Kenobi:
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.

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:

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

A

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.

A

andre_salvati:
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.

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.

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!

A

Muito genérico, elabore, exemplifique.

A

andre_salvati:
asaudate:

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

Muito genérico, elabore, exemplifique.

Ué! É razoavelmente simples: você está fazendo um projeto novo. Ele é orientado a serviços? Aliás, ele tem serviços publicados num repositório de serviços, inteiramente federado? Se você responde sim para a primeira pergunta e não para a segunda, você tem um projeto SOA-Ready, ou seja, ele não é 100% SOA, já que ele não é completamente aderente ao que SOA deve ser, mas ele está pronto para ser, já que, tecnicamente falando, ele é orientado a serviços.

Se encaixam no SOA-Ready praticamente todos os sistemas novos sob SOA, que ainda estão engatinhando nisso e, portanto, não usam um repositório integrado (muitos desses projetos, aliás, ainda são a primeira tentativa das empresas de usarem SOA). Mas, assim que a empresa passar para um próximo passo, de usar repositórios federados e integração entre sistemas, o SOA-Ready passa para SOA, capisce?

[]´s!

A

asaudate:
andre_salvati:
asaudate:

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

Muito genérico, elabore, exemplifique.

Ué! É razoavelmente simples: você está fazendo um projeto novo. Ele é orientado a serviços? Aliás, ele tem serviços publicados num repositório de serviços, inteiramente federado? Se você responde sim para a primeira pergunta e não para a segunda, você tem um projeto SOA-Ready, ou seja, ele não é 100% SOA, já que ele não é completamente aderente ao que SOA deve ser, mas ele está pronto para ser, já que, tecnicamente falando, ele é orientado a serviços.

Se encaixam no SOA-Ready praticamente todos os sistemas novos sob SOA, que ainda estão engatinhando nisso e, portanto, não usam um repositório integrado (muitos desses projetos, aliás, ainda são a primeira tentativa das empresas de usarem SOA). Mas, assim que a empresa passar para um próximo passo, de usar repositórios federados e integração entre sistemas, o SOA-Ready passa para SOA, capisce?
[]´s!

Confuso isso, mas entendi o que vc quis dizer.

Não há dúvidas de que vc pode ir colocando seus novos projetos sob as diretrizes de SOA definidas para sua empresa, mas isso não elimina o fato de que

  1. SOA é um projeto CORPORATIVO e, portanto, bem maior

  2. o objetivo de SOA é organizar a bagunça dos serviços dispersos nos vários sistemas legados. E nesse caso não importa se são novos ou não, são apenas legados.

  3. vc NÃO PRECISA e NÃO DEVE reescrever todo seu legado para adequação a SOA.

São dois projetos separados:

1 - O projeto de SOA corporativo que define ferramentas, padrões, diretrizes, modelo canônico, etc

2 - O seu projeto que deve ser SOA-enabled e estar de acordo com os padrões definidos no anterior.

Repito: muitas empresas confundem um projeto simples que envolve algumas integrações com SOA. “They are different beasts”.

B

Aí vocês estão tentando desvirtuar o significado de SOA com SOA-Ready, SOA “de verdade”, SOA Corporativo, 100% SOA…

SOA é literalmente um arquitetura desenhada com paradigma de orientação a serviços, assim como existe a orientação a objetos, componentes, procedimentos, funções, etc (um não exclui o outro, e uma aplicação pode usar vários desses paradigmas ao mesmo tempo).

Se você tem mais requisitos fortes para gerenciar centenas de aplicações desenvolvidas ou adaptadas para esse paradigma, e precisa de ferramental pesado pra organizar isso, outras soluções mais simples não deixam de ser menos SOA que a sua. Aliás quantificar de SOA não faz nem sentido.

A

Bruno Laturner:
Aí vocês estão tentando desvirtuar o significado de SOA com SOA-Ready, SOA “de verdade”, SOA Corporativo, 100% SOA…

SOA é literalmente um arquitetura desenhada com paradigma de orientação a serviços, assim como existe a orientação a objetos, componentes, procedimentos, funções, etc (um não exclui o outro, e uma aplicação pode usar vários desses paradigmas ao mesmo tempo).

Se você tem mais requisitos fortes para gerenciar centenas de aplicações desenvolvidas ou adaptadas para esse paradigma, e precisa de ferramental pesado pra organizar isso, outras soluções mais simples não deixam de ser menos SOA que a sua. Aliás quantificar de SOA não faz nem sentido.

Não, a idéia não é “quantificar” a coisa. É só distinguir aquelas que são, nas palavras do André, “corporativas”, e aquelas que são orientadas a serviço mas não adotadas pela empresa toda (ou seja, a empresa ainda vai migrar pra SOA, talvez).

Se ficar um pouco mais claro o que estou querendo dizer, dêem uma lida aqui.

[]´s

M

esqueceu de falar do SOA “google maps”, pelo visto SOA esta evoluindo para tornar compativel com tudo, inclusive o que não é SOA, como REST. :?

E

Nao confunda rifle de caçar rolinha com bife de cacarolinha…

SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…

A

esmiralha:
Nao confunda rifle de caçar rolinha com bife de cacarolinha…

SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…

Concordo. Só não digo que é possível tornar compatível com tudo, é possível tornar SOA compatível com serviços. E o que é um serviço? É uma peça de lógica de negócios composta de uma implementação e um contrato. Ou seja, se o serviço REST tem contrato (o que é perfeitamente possível de se fazer com um WSDL), então, REST é compatível com SOA.

[]´s

A

esqueceu de falar do SOA “google maps”, pelo visto SOA esta evoluindo para tornar compativel com tudo, inclusive o que não é SOA, como REST. :?

Falar que REST não é SOA é como falar que orientação a objetos não é Java, meu caro.

Esse discurso lembra bastante alguns xiitas REST que já vi por aí que acham que REST é uma bala de prata por, (dentre tantos motivos que eles tiram da cartola), e também porque não é SOA. Acontece que SOA não é feito (só) de SOAP, nem o contrário!

E

Em qual grupo você se encaixa?

K

esmiralha:
Kenobi:

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.

Em qual grupo você se encaixa?

1- Não me incluo, pois conheço bastante teoria e não somente produtos.
2- Li a bibliografia completa do Thomas Erl, além de outros excelentes autores, como Sam Ruby, Ian Robson e Jim Webber, Cesare Pautass, logo tenho entendimento dos dois mundos, clássico e restful.
3- Não sou Restafarian, isso vc pode deduzir pelos cursos que ministramos, ementas e vídeos onde deixo isso bem claro, ou até na discussão do Tectura citada - Felipe Oliveira.

Logo, acredito que estou praticando as 10 mil horas de treino intensivo em cima de algo. Não que eu seja melhor que muitos, apenas tenho mais horas de dedicação e estudos, já que a soa|expert me proporciona isso e faz parte do meu trabalho parar todo dia 3-4h somente para estudar conceitos e testar coisas.

M

esmiralha:
Nao confunda rifle de caçar rolinha com bife de cacarolinha…

SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…

Amplo? Mas tem propriedades arquiteturais conhecidas pela comunidade ou na literatura?

Usar SOA pra implementar “serviços REST” vai resultar em algo que é SOA, não REST. Se quer as propriedades arquiteturais do REST vc usa REST. Não tem porque complicar quanto a isso.

K

Olá todos, mais uma vez, falta de tempo, bom vamos lá:

mochuara
esqueceu de falar do SOA “google maps”, pelo visto SOA esta evoluindo para tornar compativel com tudo, inclusive o que não é SOA, como REST.

Sim, Restful é SOA e pelo simples fato de SOA não ser aquela encrenca toda que os players pregam, ferramental, COE e tudo mais. SOA é simplesmente e tão simplesmente, fazer uma API que possa expor as funcionalidades à outras plataformas.

esmiralha
Nao confunda rifle de caçar rolinha com bife de cacarolinha…

SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…

Não é tão amplo, é simples: Você vai expor sua API à outra plataforma, simples. Não poderia fazer com Servlets, pois está preso à sua plataforma (Java) a não ser que você retorne algo que desconecte, como um xml ou json.

Atualmente temos 3 estilos arquiteturais: Corba ( pois permite o desenvolvimento em muitas plataformas, interoperabilidade), WS-* e Rest.

Quando você vai usar um em detrenimento do outro ? Vale ver o debate no Tectura, não vou ficar replicando aqui.

alesaudate
Ou seja, se o serviço REST tem contrato (o que é perfeitamente possível de se fazer com um WSDL), então, REST é compatível com SOA.

Na verdade você não precisa do WSDL e nem da porcaria que tentaram trazer WADL, pois o Http já possui o contrato implícito - Uniform Interface :slight_smile: - Sim, tem contrato, mas você não o vê e é padronizado.

Usar SOA pra implementar “serviços REST” vai resultar em algo que é SOA, não REST. Se quer as propriedades arquiteturais do REST vc usa REST. Não tem porque complicar quanto a isso.

É quase isso e até mencionei no tectura a modelagem horrível do projeto Bonita BPM - http://www.bonitasoft.org/docs/javadoc/rest/5.3/API/identityAPI/index.html

Isso concordo, não é Rest. O que acontece é que a MODELAGEM muda de um estilo pro outro e o desenvolvedor precisa aprender a pensar de forma diferente, pois está expondo dados/conjuntos com operações implícitas através de vértices e não algorítimos.

A

Kenobi:
alesaudate
Ou seja, se o serviço REST tem contrato (o que é perfeitamente possível de se fazer com um WSDL), então, REST é compatível com SOA.

Na verdade você não precisa do WSDL e nem da porcaria que tentaram trazer WADL, pois o Http já possui o contrato implícito - Uniform Interface :slight_smile: - Sim, tem contrato, mas você não o vê e é padronizado.

Na verdade, mencionei o WSDL pela facilidade de uso em ferramentas que já existem e só aceitam WSDL (porque, no final das contas, você não consegue fazer Oracle BPEL entender REST sem um WSDL). Veja que eu não disse que somente é possível fazer com WSDL :wink:

[]´s!

A

<IRONIA>

É isso mesmo.

SOA é simples. Qualquer projeto de SOA é trivial. Afinal, SOA não implica em mudanças culturais!!

Quanto aos “players”, como Oracle e IBM, eles só fazem ferramentas para ganhar dinheiro mesmo!!

Quanto aos profissionais que participam de consórcios como OASIS e W3C, eles só fazem isso por autopromoção!!!
Afinal eles nunca gastaram 10000 horas lendo livros, então eles não possuem conhecimento nem EXPERIÊNCIA.

Para que modelar processos de negócios? Para que organizar a bagunça das estruturas de dados e dos serviços?
TI precisa continuar tendo desculpas para a falta de produtividade em projetos.

Vamos continuar usando martelo e talhadeira, vamos fazer integrações ponto-a-ponto com arquivos TXT blocados, do mesmo jeito que se fazia (e ainda se faz) em mainframes.

Pq não descobrimos uma maneira de integrar os ábacos com REST. Seria um grande avanço, não?

Só REST presta. Só REST resta. O resto é lixo tecnológico.

</IRONIA>

A

andre_salvati:
Kenobi:

Sim, Restful é SOA e pelo simples fato de SOA não ser aquela encrenca toda que os players pregam, ferramental, COE e tudo mais. SOA é simplesmente e tão simplesmente, fazer uma API que possa expor as funcionalidades à outras plataformas.

<IRONIA>

É isso mesmo.

SOA é simples. Qualquer projeto de SOA é trivial. Afinal, SOA não implica em mudanças culturais!!

Quanto aos “players”, como Oracle e IBM, eles só fazem ferramentas para ganhar dinheiro mesmo!!

Quanto aos profissionais que participam de consórcios como OASIS e W3C, eles só fazem isso por autopromoção mesmo!!!
Afinal eles nunca gastaram 10000 horas lendo livros de SOA. Eles nem possuem conhecimento nem EXPERIÊNCIA.

Para que modelar processos de negócios? Para que organizar a bagunça das estruturas de dados e dos serviços?
TI precisa continuar tendo desculpas para a lentidão dos projetos.

Vamos continuar usando martelo e talhadeira, vamos fazer integrações ponto-a-ponto com arquivos TXT blocados, do mesmo jeito que se fazia (e ainda se faz) em mainframes.

Só REST presta. Só REST resta. O resto é lixo tecnológico.

</IRONIA>

Também não vamos exagerar.

Em SOA (aliás, em TI) temos que analisar tudo com muita, mas muita parcimônia. Não adianta partir pra um extremo e dizer “vamos usar REST em tudo”, mas também não adianta partir pro lado “as ferramentas estão aí pra serem usadas, então, vamos usar sempre”.

Cada projeto é um projeto. Alguns grandes, outros pequenos, alguns com meia dúzia de serviços, outros com centenas ou até milhares. A probabilidade de um projeto com meia dúzia de serviços precisar usar uma ferramenta estabelecida é bem menor do que a probabilidade do que aquele que usa centenas de serviços.

Precisamos de ferramental para controlar os casos? Precisamos, sempre que houver SOA, é preciso usar governança, sem dúvida. No entanto, esse princípio também deve ser tomado com bastaaaante parcimônia!

[]´s

A

Isso é óbvio, para um projeto com meia dúzia de serviços eu também NÃO usaria repositório, ESB, modelo canônico, BPM, BPEL…

Só que um projeto com meia dúzia de serviços não é um projeto SOA, é somente mais um projeto que envolve algumas integrações.

10 projetos com meia dúzia de serviços podem ser um bom começo para uma Arquitetura Orientada a Serviços.

M

Estão batendo em cachorro morto. SOA já era. Que papo é esse que da pra fazer SOA com REST. As pessoas querem fugir de SOA, isso sim!

Uma dica pra quem se interessa por SOA. Desiste.

Procura outra area. Cloud computing por exemplo deve substituir SOA como plataforma para servicos em escala da internet. Mas sinto lhes informar, não tem nada de SOA em cloud computing, é algo completamente diferente, é REST.

Mas é apenas uma sugestão. Ninguém tem nada com a tecnologia que vc usa, nem como prefere gastar seu dinheiro.

M

Puxa, eu achei que eles poderiam estar relacionados. Será que viajei grandão?

M

andre_salvati:
asaudate:

Cada projeto é um projeto. Alguns grandes, outros pequenos, alguns com meia dúzia de serviços, outros com centenas ou até milhares. A probabilidade de um projeto com meia dúzia de serviços precisar usar uma ferramenta estabelecida é bem menor do que a probabilidade do que aquele que usa centenas de serviços.

Isso é óbvio, para um projeto com meia dúzia de serviços eu também NÃO usaria repositório, ESB, modelo canônico, BPM, BPEL…

Só que um projeto com meia dúzia de serviços não é um projeto SOA, é somente mais um projeto que envolve algumas integrações.

10 projetos com meia dúzia de serviços podem ser um bom começo para uma Arquitetura Orientada a Serviços.

a web parece estar indo muito bem com URI + HTTP + HTML.

A

Puxa, eu achei que eles poderiam estar relacionados. Será que viajei grandão?

Vc está certa,

SOA tem tudo a ver com Cloud e, na verdade, SOA contém muitos dos fundamentos que estão possibilitando Cloud.

Só quem não sabe do que está falando não enxerga isso.

Na realidade esta conversa de que “SOA morreu” já está até passada. O que existe é uma tendência do hype de SOA diminuir e de os produtos serem reempacotados pelos fornecedores, só que agora sob o hype de Cloud.

Ignore os trolls.

“You can’t do true cloud computing without architecture. Leveraging best practices to build loosely coupled abstractions: That’s a SOA best practice,” said Bloomberg. “You won’t be able to succeed in the cloud without SOA best practices.”

E

Não é tão amplo, é simples: Você vai expor sua API à outra plataforma, simples. Não poderia fazer com Servlets, pois está preso à sua plataforma (Java) a não ser que você retorne algo que desconecte, como um xml ou json.

SOA é simples, mas exige 10 mil de horas de treinamento intensivo para entender. Deve ser um poema zen… Vou embora antes que voce me bote pra pintar uma cerca…

M

Cloud computing é baseado em REST pelo simples motivo que a web é baseado na arquitetura REST, e a nuvem é a propria web. Crie sua propria nuvem para competir com a web, chame seus amigos, e use SOA pra isso se quiser. A relação com SOA é o que pouco me interessa. Sem um caso de sucesso a relação entre ela e qualquer outra coisa só interessa aos arqueólogos da TI, encarregados de contar a historia dos maiores fracassos da indústria.

“Leveraging best practices to build loosely coupled abstractions”

É uma afirmação linda, mas na prática não quer dizer nada. Empresas de internet lidam com milhoes de usuários na web todos os dias e estão cagando pra SOA. Só quem promove SOA são consultores querendo faturar uma graninha com ferramentas milagrosas e pra isso vendem a ideia que no ambiente corporativo a natureza do software desenvolvido é especial. Não é. Felizmente o mercado esta começando a criar anticorpos contra essas promessas que não são entregues.

A

Mochuara,

sinto dizer-lhe, mas sua guerra é contra SOAP e não contra SOA … kkkk

O pior é que ainda assim vc está errado.

Por exemplo, pegue essa empresinha chamada Amazon que não sabe nada de Internet e de E-commerce…

Ela está cagando e andando para SOAP… kkkk

http://docs.amazonwebservices.com/AWSECommerceService/2009-10-01/DG/index.html?CHAP_IntroducingECommerceandWebServices.html

M

andre_salvati:
Mochuara,

sinto dizer-lhe, mas sua guerra é contra SOAP e não contra SOA … kkkk

O pior é que ainda assim vc está errado.

Por exemplo, pegue essa empresinha chamada Amazon que não sabe nada de Internet e de E-commerce…

Ela está cagando e andando para SOAP… kkkk

http://docs.amazonwebservices.com/AWSECommerceService/2009-10-01/DG/index.html?CHAP_IntroducingECommerceandWebServices.html

Não. Estou falando de SOA como todo. Um dos maiores fracassos da nossa industria. Vc essta falando de SOAP só pra poder citar a API da amazon que de fato é SOAP. Mas e ai? A menos que vc esteja dizendo que a API SOAP é mais usada que a API HTTP não entendi qual seu ponto. O proprio fundador da amazon ja disse que a API HTTP é muito mais usada.

A

Não, vc não sabe do que está falando.

Estude SOA, pratique SOA e depois volte aqui para contribuir.

Desculpe estar sendo repetitivo.

A

andre_salvati:
mochuara:

Não. Estou falando de SOA como todo. Um dos maiores fracassos da nossa industria.

Não, vc não sabe do que está falando.

Estude SOA, pratique SOA e depois volte aqui para contribuir.

Desculpe estar sendo repetitivo.

++

M

andre_salvati:

Desculpe estar sendo repetitivo.

O problema não é a repetição, mas a falta de argumentos.

Voces estão simplesmente convencidos que SOA é importante, sem saber qual beneficio exatamente ele promove.

A

mochuara:
andre_salvati:

Desculpe estar sendo repetitivo.

O problema não é a repetição, mas a falta de argumentos.

Voces estão simplesmente convencidos que SOA é importante, sem saber qual beneficio exatamente ele promove.

Sabemos exatamente quais os benefícios. Não teríamos tantos cases de integração no currículo se não soubéssemos para que serve. E, como eu disse no começo do tópico, o discurso que você tem é o de quem teve um primeiro contato ruim e, por conta disso, não quer mais se envolver com a tecnologia. Tudo bem, é um ponto de vista, a vida é sua. Mas não venha generalizar, falar que todo mundo que trabalha com isso está tentando vender ferramentas e que a tecnologia não serve pra nada.

M

asaudate:

Sabemos exatamente quais os benefícios. Não teríamos tantos cases de integração no currículo se não soubéssemos para que serve. E, como eu disse no começo do tópico, o discurso que você tem é o de quem teve um primeiro contato ruim e, por conta disso, não quer mais se envolver com a tecnologia. Tudo bem, é um ponto de vista, a vida é sua. Mas não venha generalizar, falar que todo mundo que trabalha com isso está tentando vender ferramentas e que a tecnologia não serve pra nada.

Tudo gira em torno das ferramentas no SOA. Se vc não é um vendor querendo trancar o cliente no seu produto proprietario então é um comprador prestes a receber a visita de um.

K

Porra, alguém se deu ao trabalho de assistir o meu Talk ou ver a discussão no Tectura ?

Por isso o GUJ às vezes me brocha e fico meses se escrever. Muito troll, achômetro e pouca discussão concreta madura.

SOA não é ferramental, isso é fato. O ferramental ajudará caso tenha motivações, sempre disse isso e dou aula das ferramentas. Logo, vivo disso e não teria sentido algum eu ministrar treinamento de algo que não acredito.#ficaadica.

O que eu disse é que vc não precisa delas pra criar SOA em muitos cenários. Se há motivação de integração com outros protocolos, como SNA-Mainframe, claro que você vai usar um ESB.

Se você necessitar de uma máquina de estados, vai usar uma DSL como BPEL e sua engine.

Até o exemplo que citei sobre o maps distorceram. Eu não disse que fazer uma aplicação se integrar com Maps está fazendo SOA, ela está pura e simplesmente fazendo integração. O que eu disse foi que o Google Maps é SOA, coisa completamente diferente.

Eu percebo que tem muita gente bitolada em ferramental, deve trabalhar em partners e sei como isso funciona, pois já passei por essa fase.

E por fim, sim SOA exige muuuita literatura para percerber uma coisa: É muito simples, basta saber como fazer direito :).

Aliás, o Jim Webber fala pra jogar todos os livros fora, não sou tão radical mas confesso, que muitos são uma merda e instruem as pessoas a fazerem design pobre como Access layer, Business Shared Services, Business Private Services, Portal - E eles te empurram isso, vc acha que está fazendo SOA, mas está fazendo uma meleca e é isso que o Mochura diz que morreu e não sabe se expressar :-).

Denovo, não escrevo mais aqui até antes, todos lerem o tópico do Tectura, verem o talk e depois voltem e façam críticas, caso contrário, vou ficar no fórum de adultos 8)

A

Oras,

para mim a discussão estava e está interessante.

Fica chato uma evasiva dessas, mas tudo bem, pelo menos agora tem gente convencida de que as ferramentas são importantes :wink:

K

andre_salvati:
Oras,

para mim a discussão estava e está interessante.

Fica chato uma evasiva dessas, mas tudo bem, pelo menos agora tem gente convencida de que as ferramentas são importantes ;)

Eu nunca diria o ao contrário, até porque como eu disse, vivo delas e o carro chefe da soa|expert é a Formção Consultor SOA - http://www.soaexpert.com.br/cursos/fsoa / FSOA.

Analise friamente, o que são essas ferramentas ? Implementação de patterns. Quando um pattern é utilizado ? resposta: Quando há motivações.

Se não há motivação, não tem o porquê utilizar uma ferramenta, e na maioria dos novos projetos, não tem o porque, ao menos não as atuais.

O BPEL vai necessitar ser estendido, outras ferramentas que suportem Atom, PubSubHubPub, RestMS, Salmon, OAuth e etc;ou seja, a maior parte já está obsoleta em sua forma atual.

Claro que os players não ficarão parados e novas versões dos produtos devem surgir ou serão comidos pelo tempo, por novas ferramentas de startups.

Aliás, dia 29, farei um Mini Curso de SOA junto com a Globalcode. Esse é na faixa e tem duração aproximada de 3h, onde dá pra ver muita coisa. Quem quiser aparecer lá e bater papo ao vivo, ficarei honrado :slight_smile: - http://www.globalcode.com.br:80/gratuitos/minicursos/minicurso-introducao-a-soa

E

Alguém sabe dizer qual o percentual de grana do mercado que essa maioria de novos projetos que não necessitam de ferramentas representa?

A

Não sei te dizer qual o percentual. Sei que sou consultor SOA e trabalho com ferramentas open source.

P.S: Caso o mochuara venha a falar algo sobre isso, eu faço questão de implementar SOA de acordo com padrões abertos e, portanto, se o cliente quiser mudar de vendor, ele sempre se sente à vontade para fazer isso.

K

Por acaso, asssisti uma apresentação do Gartner hoje, falando sobre pequenas e médias empresas também.

Uma pequena empresa, provavelmente não tem grande legado e talvez esteja escrevendo sua primeira plataforma. Pra esse cenário, talvez endereçar com ferramental mas simples, como Restful - Restfulie + RestMS + OAuth + Hypermedia.

Repare que há um stack, não deixa de ser um novo, orientado às novas práticas.

Já empresas médias e principalmente, grandes empresas, a maior parte precisará, pois os cenários exigirão integração com softwares legados, ou soluções empresariais como SAP, Siebel, Cobol e por aí vai.

Acredito que hoje, 80% das empresas necessitem de ferramental e a tendência é baixar, pois as pequenas e médias empresas deverão também implementar SOA.

Quando vc olha pra Telecom, Bancos, Corretoras, Grandes Seguradoras…é praticamente impossível não adotarem ferramental, como Grid, Complex Events, ESB e BPEL, até evoluirem para processos - BPM, pois precisam otimizar a gestão do negócio.

É para esse tipo de cenário acima, profissionais que queiram trabalhar forte em integração e disponibilização de recursos, que criamos a FSOA: http://www.soaexpert.com.br/cursos/fsoa #jabazinhomoments :slight_smile:

A

As pequenas e médias empresas vão utilizar SaaS. A implementação de SOA fica para o fornecedor de SaaS… :wink:

A

andre_salvati:
Kenobi:

… pois as pequenas e médias empresas deverão também implementar SOA.

As pequenas e médias empresas vão utilizar SaaS. A implementação de SOA fica para o fornecedor de SaaS… ;)

Quer dizer, SE e somente SE houver software (SaaS) que as atenda. Caso contrário…

[]´s

A

asaudate:

Quer dizer, SE e somente SE houver software (SaaS) que as atenda. Caso contrário…

[]´s

Caso contrário não faz… PMEs não têm dinheiro nem para pagar por projetos de ERP customizados, quanto mais por projetos SOA.

A

andre_salvati:
asaudate:
andre_salvati:
Kenobi:

… pois as pequenas e médias empresas deverão também implementar SOA.

As pequenas e médias empresas vão utilizar SaaS. A implementação de SOA fica para o fornecedor de SaaS… ;)

Quer dizer, SE e somente SE houver software (SaaS) que as atenda. Caso contrário…

[]´s

Caso contrário não faz… PMEs não têm dinheiro nem para pagar por projetos de ERP customizados, quanto mais por projetos SOA.

E SOA precisa custar caro?

(Desconfio que vamos voltar ao ponto inicial da discussão… ferramental x não-ferramental. Espero q possamos discutir isso dum ponto em que “corporativo” não signifique “imenso”!)

[]´s

A

asaudate:

E SOA precisa custar caro?

(Desconfio que vamos voltar ao ponto inicial da discussão… ferramental x não-ferramental. Espero q possamos discutir isso dum ponto em que “corporativo” não signifique “imenso”!)

[]´s

Vamos colocar assim: integrações não precisam custar caro.

E ainda assim eu nunca fui acionado por uma PME para um projeto de integração, mesmo apesar de trabalhar com PMEs…

SOA é um projeto caro por natureza.

A

andre_salvati:
asaudate:
andre_salvati:
asaudate:
andre_salvati:
Kenobi:

… pois as pequenas e médias empresas deverão também implementar SOA.

As pequenas e médias empresas vão utilizar SaaS. A implementação de SOA fica para o fornecedor de SaaS… ;)

Quer dizer, SE e somente SE houver software (SaaS) que as atenda. Caso contrário…

[]´s

Caso contrário não faz… PMEs não têm dinheiro nem para pagar por projetos de ERP customizados, quanto mais por projetos SOA.

E SOA precisa custar caro?

(Desconfio que vamos voltar ao ponto inicial da discussão… ferramental x não-ferramental. Espero q possamos discutir isso dum ponto em que “corporativo” não signifique “imenso”!)

[]´s

Vamos colocar assim: integrações não precisam custar caro.

E ainda assim eu nunca fui acionado por uma PME para um projeto de integração, mesmo apesar de trabalhar com PMEs…

SOA é um projeto caro por natureza.

PMEs não acionam consultorias para desenvolver SOA porque consultorias (ou a maioria delas) pregam que SOA custa caro - quando não precisa custar. E, no meu entender, taí o nome do tópico pra descrever a consequencia.

[]´s

A

asaudate:

PMEs não acionam consultorias para desenvolver SOA porque consultorias (ou a maioria delas) pregam que SOA custa caro - quando não precisa custar. E, no meu entender, taí o nome do tópico pra descrever a consequencia.

[]´s

Aí é que vc se engana. PMEs não te procuram para implementar um projeto SOA. PMEs estão longe de saber o que é SOA. PMEs te procuram para resolver um problema de negócio da maneira mais barata possível.

A

andre_salvati:
asaudate:

PMEs não acionam consultorias para desenvolver SOA porque consultorias (ou a maioria delas) pregam que SOA custa caro - quando não precisa custar. E, no meu entender, taí o nome do tópico pra descrever a consequencia.

[]´s

Aí é que vc se engana. PMEs não te procuram para implementar um projeto SOA. PMEs estão longe de saber o que é SOA. PMEs te procuram para resolver um problema de negócio da maneira mais barata possível.

Na realidade, conforme conversamos, me toquei que eu nunca ví uma PME encomendando um projeto de integração - o que, na realidade, faz sentido, dado que dificilmente elas têm sistemas que precisam ser integrados. Não porque custam grana, mas porque não há necessidade.

[]´s

A

Nem por necessidade. É por grana mesmo.

Pense em duas aplicações muito comuns em PMEs: um ERP e um aplicativo para controle eletrônico de ponto (imposição legal)

Eu nunca vi uma PME disposta a pagar um tostão que fosse para injetar os dados de ponto no ERP, mesmo apesar de isso se fazer necessário em alguns cenários.

A

andre_salvati:
asaudate:

Na realidade, conforme conversamos, me toquei que eu nunca ví uma PME encomendando um projeto de integração - o que, na realidade, faz sentido, dado que dificilmente elas têm sistemas que precisam ser integrados. Não porque custam grana, mas porque não há necessidade.

Nem por necessidade. É por grana mesmo.

Pense em duas aplicações muito comuns em PMEs: um ERP e um aplicativo para controle eletrônico de ponto (imposição legal)

Eu nunca vi uma PME disposta a pagar um tostão que fosse para injetar os dados de ponto no ERP, mesmo apesar de isso se fazer necessário em alguns cenários.

Tem toda razão. Mas isso aconteceria de qualquer maneira - com projeto simples ou SOA ou …

P

Na minha opinião, SOA não passa de mais uma onda entre tantas outras criadas pela indústria de consultoria de TI, que aliás, até por uma questão de subsistência, é uma das indústrias mais pródigas na aplicação de um mantra do marketing que prega a criação de necessidades para os consumidores. MOA - Marketing Oriented Architecture. Ou: repita tantas vezes que um produto é importante que os consumidores vão acabar acreditando e comprando, mesmo que não precisem. É claro que do ponto de vista da geração de negócios e de empregos para a área de TI, estas ondas ou ciclos até que são bem-vindos…

K

Olá amigo, respeito sua opinião. Então você acredita que devemos continuar a fazer software monolítico, preso numa caixinha ? Como faço para explor aquela funcionalidade ? Voltamos à troca TXT ?
:twisted:

A

Amigo, só uma sugestão…

Antes de sair distribuindo sua opinião, leia o restante do tópico, para saber o que talvez outros achem da sua mesma opinião, OK?

Grato.

A

Amigo, só uma sugestão…

Antes de sair distribuindo sua opinião, leia o restante do tópico, para saber o que talvez outros achem da sua mesma opinião, OK?

Grato.

Relaxa, ele ainda é pinto. Talvez, quando virar frango, ele comece a entender SOA. :lol:

M

Olá amigo, respeito sua opinião. Então você acredita que devemos continuar a fazer software monolítico, preso numa caixinha ? Como faço para explor aquela funcionalidade ? Voltamos à troca TXT ?
:twisted:

É impressão minha ou vc viajou na maionese aqui? Pinto fez uma critica válida ao modelo SOA, não disse nada sobre como criar sistemas ou o que trocar entre eles.

Mas já que falou, as pessoas não vão voltar porque elas nunca deixaram de trocar textos em primeiros lugar, se trata de um caso de uso legítimo para qualquer sistema de rede e não há qualquer indicação de que isso venha a diminuir. Na verdade o que resulta em sistemas monoliticos não é trocar HTML, JSON e Atom, todos textos, e sim XMLs opacos gerados por ferramentas SOA proprietárias.

L

E vai me dizer que isto não é bom pra ganhar $$$ ?

A

Olá amigo, respeito sua opinião. Então você acredita que devemos continuar a fazer software monolítico, preso numa caixinha ? Como faço para explor aquela funcionalidade ? Voltamos à troca TXT ?
:twisted:

É impressão minha ou vc viajou na maionese aqui? Pinto fez uma critica válida ao modelo SOA, não disse nada sobre como criar sistemas ou o que trocar entre eles.

Mas já que falou, as pessoas não vão voltar porque elas nunca deixaram de trocar textos em primeiros lugar, se trata de um caso de uso legítimo para qualquer sistema de rede e não há qualquer indicação de que isso venha a diminuir. Na verdade o que resulta em sistemas monoliticos não é trocar HTML, JSON e Atom, todos textos, e sim XMLs opacos gerados por ferramentas SOA proprietárias.

Em primeiro lugar, se são gerados “XMLs opacos por ferramentas SOA proprietárias”, azar de quem escolheu. Existem ferramentas que geram, sim, contratos e XSD´s reutilizáveis por qualquer ferramenta / linguagem, e a maior parte dessas nem proprietária é. Aqui, como em tudo que envolve TI, requer discernimento, bom senso, parcimônia, etc.

M

asaudate:

Em primeiro lugar, se são gerados “XMLs opacos por ferramentas SOA proprietárias”, azar de quem escolheu. Existem ferramentas que geram, sim, contratos e XSD´s reutilizáveis por qualquer ferramenta / linguagem, e a maior parte dessas nem proprietária é. Aqui, como em tudo que envolve TI, requer discernimento, bom senso, parcimônia, etc.

Não importa se sua ferramenta é proprietária ou não. O XML gerado continua sendo opaco porque só é entendido por quem segue as diversas especificações da plataforma.

P

asaudate:
Amigo, só uma sugestão…
Antes de sair distribuindo sua opinião, leia o restante do tópico, para saber o que talvez outros achem da sua mesma opinião, OK?
Grato.

Eu li todo o tópico, como sempre faço,
Sinceramente não entendi a sua colocação, e não entendi o que há de errado em expor (ou “distribuir”, como vc diz) a minha opinião, mesmo que seja semelhante a outras.
O que me parece é que, ante uma simples opinião contrária à sua, vc teve uma reação tão irônica e raivosa que prejudicou até a sua capacidade de escrever uma frase inteligível.

Uma das vantagens de ser pinto é que ainda posso evitar desenvolver uma soberba igual à sua, que me tacha como ignorante só porque não concordo com a sua opinião.
E certamente vc tem muito mais conhecimento do que eu sobre SOA, afinal vc tem que ter muitos argumentos para tentar vender aos seus clientes uma solução que, como já foi dito aqui até pelos seus defensores, é cara, apresenta resultados a longo prazo e sobre a qual (agora é a minha opinião) não se sabe exatamente o que se está comprando nem o que vai ser entregue.

A

pinto:
asaudate:
Amigo, só uma sugestão…
Antes de sair distribuindo sua opinião, leia o restante do tópico, para saber o que talvez outros achem da sua mesma opinião, OK?
Grato.

Eu li todo o tópico, como sempre faço,
Sinceramente não entendi a sua colocação, e não entendi o que há de errado em expor (ou “distribuir”, como vc diz) a minha opinião, mesmo que seja semelhante a outras.
O que me parece é que, ante uma simples opinião contrária à sua, vc teve uma reação tão irônica e raivosa que prejudicou até a sua capacidade de escrever uma frase inteligível.

O que eu quis dizer foi que, logo no começo do tópico, eu me manifestei a respeito.

Quem trabalha com isso SABE que existem muitas e muitas empresas que apenas tentam vender produtos. No entanto, tem gente séria por aí tentando fazer um bom trabalho, mas que acaba sendo prejudicada por essa visão - que nada tem a ver com SOA em si, poderia ser qualquer outra tecnologia.

Desculpe se pareceu uma reação “irônica e raivosa”, não foi a intenção. Espero que agora o argumento esteja parecendo um pouco mais claro.

A

mochuara:
asaudate:

Em primeiro lugar, se são gerados “XMLs opacos por ferramentas SOA proprietárias”, azar de quem escolheu. Existem ferramentas que geram, sim, contratos e XSD´s reutilizáveis por qualquer ferramenta / linguagem, e a maior parte dessas nem proprietária é. Aqui, como em tudo que envolve TI, requer discernimento, bom senso, parcimônia, etc.

Não importa se sua ferramenta é proprietária ou não. O XML gerado continua sendo opaco porque só é entendido por quem segue as diversas especificações da plataforma.

Sim, claro, muito melhor desenvolver uma coisa sem contrato. Tudo bem que alguém corre sério risco de acabar com uma aplicação “crasheada” nas mãos, do nada, sem nem entender porque, mas o importante é entregar funcionando. Se quebrar, depois… paciência!

K

Caros,

Não existe integração sem contrato, o próprio http implementa de forma implícita.

A troca que me referi de arquivos foi layout, como fazíamos nos tempos de integração Mainframe com EDI, onde não há possibilidade de cenários Online síncronos por exemplo.

Uma integração exige muitas vezes, tradução de protocolos, de http pra SNA, por exemplo. Pauta que estamos discutindo no Tectura e vale à pena entender a discussão.

Disse milhões de vezes aqui no fórum que SOA não é ferramental.

Vi que o Mochura, gosta de separar Restful de SOA e acho que o problema está no erro conceitual disso.

Utilizar ou não ferramental, vai depender das necessidades de cada cliente. Todo preconceito é burro ou estúpido, sem conhecer à fundo as soluções, julgar apenas com achômetro é uma baita ignorância.

Eu me retiro da discussão, pois não há argumentações técnicas aqui neste fórum. Olhem o Tectura, por exemplo. Estamos discutindo SOAP x Rest, mas em outro nível e prefiro ficar por lá.

Quem quiser continuar a acompanhar o tópico e ver minhas explicações, sugiro que migrem para a outra discussão.

The end.

P

Kenobi, infelizmente não sei qual é a solução para esta Torre de Babel, e se soubesse estaria a caminho de enriquecer :lol:
Tambem não acredito no aparecimento de uma utópica camada mágica que faça com que os sistemas conversem entre si mais facilmente.
Mas acredito menos ainda na idéia de que todos os sistemas tenham que ser, um a um, moldados a ferro e fogo para que sejam acessíveis entre si.
Apesar do meu ceticismo, eu respeito o trabalho de vocês, que pelo menos estão tentando fazer algo para resolver o problema, e se conseguirem merecerão todos os aplausos.
Enquanto isso, vamos fazendo os sistemas conversarem via texto mesmo, porque o mundo não pode parar.

A

Kenobi, infelizmente não sei qual é a solução para esta Torre de Babel, e se soubesse estaria a caminho de enriquecer :lol:
Tambem não acredito no aparecimento de uma utópica camada mágica que faça com que os sistemas conversem entre si mais facilmente.
Mas acredito menos ainda na idéia de que todos os sistemas tenham que ser, um a um, moldados a ferro e fogo para que sejam acessíveis entre si.
Apesar do meu ceticismo, eu respeito o trabalho de vocês, que pelo menos estão tentando fazer algo para resolver o problema, e se conseguirem merecerão todos os aplausos.
Enquanto isso, vamos fazendo os sistemas conversarem via texto mesmo, porque o mundo não pode parar.

Quer saber um segredo? Até os ESB´s mais leves do mercado conseguem fazer leitura de texto.

[]´s

P

Kenobi, infelizmente não sei qual é a solução para esta Torre de Babel, e se soubesse estaria a caminho de enriquecer :lol:
Tambem não acredito no aparecimento de uma utópica camada mágica que faça com que os sistemas conversem entre si mais facilmente.
Mas acredito menos ainda na idéia de que todos os sistemas tenham que ser, um a um, moldados a ferro e fogo para que sejam acessíveis entre si.
Apesar do meu ceticismo, eu respeito o trabalho de vocês, que pelo menos estão tentando fazer algo para resolver o problema, e se conseguirem merecerão todos os aplausos.
Enquanto isso, vamos fazendo os sistemas conversarem via texto mesmo, porque o mundo não pode parar.

Quer saber um segredo? Até os ESB´s mais leves do mercado conseguem fazer leitura de texto.
[]´s
Poxa cara, estou me sentindo discriminado porque comigo vc não usa as suas tags de ironia…
Mas não se preocupe, não vou contar este seu segredo pra ninguem, porque se a notícia se espalha vc não vai conseguir vender nem pra quem ainda integra por EAI via file transfer…

M

asaudate:

Sim, claro, muito melhor desenvolver uma coisa sem contrato. Tudo bem que alguém corre sério risco de acabar com uma aplicação “crasheada” nas mãos, do nada, sem nem entender porque, mas o importante é entregar funcionando. Se quebrar, depois… paciência!

Voce devia pesquisar sobre REST que extingue a necessidade de contratos pre-definidos. Sem falar que é uma arquitetura provada que funciona, inclusive para integração de sistemas heterogeneos, ao contrário de SOA.

A

Não Pinto, não leve pelo lado errado. Primeiro entenda os recursos e os benefícios de SOA para depois fazer críticas e generalizações, senão vai parecer que vc está seguindo os passos do Mochuara.

Se vc parar para pensar, QUALQUER solução de software é “cara, apresenta resultados a longo prazo e (o cliente) não sabe exatamente o que se está comprando nem o que vai ser entregue”. Sabe pq? A natureza de sotware é abstrata. Vc vai perceber isso com o tempo. :wink:

Cabe a vc como profissional guiá-lo no caminho dessa descoberta.

M

Kenobi:

Vi que o Mochura, gosta de separar Restful de SOA e acho que o problema está no erro conceitual disso.

Hã? REST e SOA são arquiteturas distintas. Se vc quer unificar as duas provavelmente esta querendo vender alguma coisa. Engenheiros de software não tem porque temer diversidade, eles aplicam o que é melhor pra cada caso.

P

andre_salvati:
Se vc parar para pensar, QUALQUER solução de software é “cara, apresenta resultados a longo prazo e (o cliente) não sabe exatamente o que se está comprando nem o que vai ser entregue”. Sabe pq? [color=red]A natureza de sotware é abstrata[/color]. Vc vai perceber isso com o tempo. :wink:

Cabe a vc como profissional guiá-lo no caminho dessa descoberta.


:shock: :shock: :shock:

A

pinto:
andre_salvati:
Se vc parar para pensar, QUALQUER solução de software é “cara, apresenta resultados a longo prazo e (o cliente) não sabe exatamente o que se está comprando nem o que vai ser entregue”. Sabe pq? [color=red]A natureza de sotware é abstrata[/color]. Vc vai perceber isso com o tempo. :wink:

Cabe a vc como profissional guiá-lo no caminho dessa descoberta.


:shock: :shock: :shock:

É Pinto,

infelizmente vc ainda não tem a maturidade necessária para compreender coisas simples como essas.

Só me resta esperança de que um dia vc vire um frango e, depois, um galo. :stuck_out_tongue:

Desisto de vc tb.

Abraço

A

Kenobi, infelizmente não sei qual é a solução para esta Torre de Babel, e se soubesse estaria a caminho de enriquecer :lol:
Tambem não acredito no aparecimento de uma utópica camada mágica que faça com que os sistemas conversem entre si mais facilmente.
Mas acredito menos ainda na idéia de que todos os sistemas tenham que ser, um a um, moldados a ferro e fogo para que sejam acessíveis entre si.
Apesar do meu ceticismo, eu respeito o trabalho de vocês, que pelo menos estão tentando fazer algo para resolver o problema, e se conseguirem merecerão todos os aplausos.
Enquanto isso, vamos fazendo os sistemas conversarem via texto mesmo, porque o mundo não pode parar.

Quer saber um segredo? Até os ESB´s mais leves do mercado conseguem fazer leitura de texto.
[]´s
Poxa cara, estou me sentindo discriminado porque comigo vc não usa as suas tags de ironia…
Mas não se preocupe, não vou contar este seu segredo pra ninguem, porque se a notícia se espalha vc não vai conseguir vender nem pra quem ainda integra por EAI via file transfer…

Não uso as tags de ironia com você porque não estou sendo irônico, oras. Estou dizendo como se fosse um segredo porque algumas pessoas esquecem (parece que convenientemente) que SOA consegue se adaptar, também, ao legado - quando as transferências por CSV, TXT ou coisa que o valha eram usadas.

Agora, sendo irônico mesmo: você notou que, se as pessoas soubessem que os ESB´s tivessem essa capacidade, aí sim que elas iriam MESMO querer essas ferramentas??

[]´s!

A

mochuara:
Kenobi:

Vi que o Mochura, gosta de separar Restful de SOA e acho que o problema está no erro conceitual disso.

Hã? REST e SOA são arquiteturas distintas. Se vc quer unificar as duas provavelmente esta querendo vender alguma coisa. Engenheiros de software não tem porque temer diversidade, eles aplicam o que é melhor pra cada caso.

Não são arquiteturas distintas. Na verdade, REST nem ao menos é uma arquitetura: você pode construir algo baseando-se na tecnologia, mas ela não deixa de ser uma tecnologia. É como se eu dissesse que possuo uma arquitetura Spring.

Já SOA é uma arquitetura. Que pode usar REST, assim como WS-*, JMS, file transfer…

K

mochuara:
Kenobi:

Vi que o Mochura, gosta de separar Restful de SOA e acho que o problema está no erro conceitual disso.

Hã? REST e SOA são arquiteturas distintas. Se vc quer unificar as duas provavelmente esta querendo vender alguma coisa. Engenheiros de software não tem porque temer diversidade, eles aplicam o que é melhor pra cada caso.

O que é distinto é Corba x WS* x Restful. O conceito, permanece.

Todas são implementações do conceito. EJB não se aplica, apesar de ser contrato e tudo mais, pois é preso à plataforma e não permite que plataformas heterogênas consumam recursos.

Mas não precisa acreditar em mim, um mero brasileiro tentando firmar meus pensamentos:

http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm - Simon Phipps.
http://www.infoq.com/presentations/Resurrecting-SOA - Palestra da Anne sobre o ressurgimento do SOA.

Uma excelente definição sobre o que é SOA - http://www.infoq.com/news/2010/11/SimpleIT

Explicação (mais ou menos) da IBM - http://www.ibm.com/developerworks/library/x-restfulsoa/

E claro, a melhor de todas que eu já vi e mais concisa: http://www.slideshare.net/cesare.pautasso/soa2010-soa-with-rest - Prof. Cesare Pautasso.

Entendo sua afirmação, pois logo quando Rest surgiu, a comunidade queria diferenciá-lo de tudo que ali estava, como produtos e a especificação dos WS-*. Entretanto o conceito do SOA nunca pregou tecnologia X ou Y, isso era coisa de vendor e alguns evangelizadores, como nós que estamos tentando fazer um trabalho, começaram a refutar essa idéia e lembrar que SOA é conceito e não implementação.

Espero que tenha clarificado :slight_smile:

M

asaudate:

Não são arquiteturas distintas. Na verdade, REST nem ao menos é uma arquitetura

Parei de ler aqui. rs

A

mochuara:
asaudate:

Não são arquiteturas distintas. Na verdade, REST nem ao menos é uma arquitetura

Parei de ler aqui. rs

Realmente, dá pra ver que você não lê bastante coisa. Se você fosse um pouco menos teimoso (ou seria arrogante?), talvez você entendesse o que eu, o Kenobi, e o andre_salvati estávamos tentando te explicar. É uma pena, a arrogância cega mesmo as pessoas.

Eu parei por aqui com você.

A

Para quem quer entender mais sobre como começar com SOA dentro de uma organização segue um post bem interessante.

http://www.oracle.com/technetwork/articles/soa/chiang-soa-governance-083965.html

Reparem que ele só fala sobre ferramentas (REST ou WS) no final … :wink:

M

andre_salvati:
Para quem quer entender mais sobre como começar com SOA dentro de uma organização segue um post bem interessante.

http://www.oracle.com/technetwork/articles/soa/chiang-soa-governance-083965.html

Reparem que ele só fala sobre ferramentas (REST ou WS) no final … ;)

Aonde que fala de REST?

A

Hmmm…

Blog da Oracle falando por onde se começa com SOA. Será que é com tecnologia e ferramentas?

http://blogs.oracle.com/governance/2011/01/soa_governance_starts_with_peo.html

R

asaudate:
mochuara:
asaudate:

Não são arquiteturas distintas. Na verdade, REST nem ao menos é uma arquitetura

Parei de ler aqui. rs

Realmente, dá pra ver que você não lê bastante coisa. Se você fosse um pouco menos teimoso (ou seria arrogante?), talvez você entendesse o que eu, o Kenobi, e o andre_salvati estávamos tentando te explicar. É uma pena, a arrogância cega mesmo as pessoas.

Eu parei por aqui com você.

O mesmo pode ser dito aos 3, só preciso ter a opinião diferente de vocês

M

RafaFloripa:
asaudate:
mochuara:
asaudate:

Não são arquiteturas distintas. Na verdade, REST nem ao menos é uma arquitetura

Parei de ler aqui. rs

Realmente, dá pra ver que você não lê bastante coisa. Se você fosse um pouco menos teimoso (ou seria arrogante?), talvez você entendesse o que eu, o Kenobi, e o andre_salvati estávamos tentando te explicar. É uma pena, a arrogância cega mesmo as pessoas.

Eu parei por aqui com você.

O mesmo pode ser dito aos 3, só preciso ter a opinião diferente de vocês

Eu só queria saber porque proponentes da SOA estao agora afirmando que sao PRO-o contrario de SOA. Porque é isto que Rest representa. Será que vou ter que fazer um curso na SOAExperts pra saber?

A

Eu gostaria muitíssimo de entender porque alguém aparece, meses depois da conversa estar morta, pra soltar uma mensagem que não agrega nada ao tópico. Isso é vontade de ser troll ou o que?

H

Eu sei la mas tenho uma visão diferente de vcs nesse aspecto.

Concordo que é bom desenvolver aplicações utilizando patterns e que possam ser reutilizadas.

Mas, isso não resolve NADA.

Só resolve os problemas criados por nós mesmos, desenvolvedores.

É a discussão infinita de como melhorar o que o cliente não percebe.

Uma ferramenta tem que atender a requisitos de negócio, se atender gera lucro, se tiver lucro, q se dane se ta bem feita ou não, com o lucro se refaz a ferramenta.

Eu to cansado de ver cara focado em programação que sabe 198 patterns diferentes e que não sabe entender como ajudar o cliente a faturar mais.

Essas discussões de arquitetura são importantes, mas, o bemfeitinho já resolve com sobra esses pepinos.

Os erros que eu mais vejo pegar são os relacionados a falta de entendimento do negocio e de como utilizar sistemas para alavanca-los.

Ou seja, linkando com o tópico, “É tão importante assim que SOA e BPM andem mais rápido?”, “Não tem um zé querendo que vc reaprenda algo pra te vender certificação?”.

A

heroijapa:
Eu sei la mas tenho uma visão diferente de vcs nesse aspecto.

Concordo que é bom desenvolver aplicações utilizando patterns e que possam ser reutilizadas.

Mas, isso não resolve NADA.

Só resolve os problemas criados por nós mesmos, desenvolvedores.

É a discussão infinita de como melhorar o que o cliente não percebe.

Uma ferramenta tem que atender a requisitos de negócio, se atender gera lucro, se tiver lucro, q se dane se ta bem feita ou não, com o lucro se refaz a ferramenta.

Eu to cansado de ver cara focado em programação que sabe 198 patterns diferentes e que não sabe entender como ajudar o cliente a faturar mais.

Essas discussões de arquitetura são importantes, mas, o bemfeitinho já resolve com sobra esses pepinos.

Os erros que eu mais vejo pegar são os relacionados a falta de entendimento do negocio e de como utilizar sistemas para alavanca-los.

Ou seja, linkando com o tópico, “É tão importante assim que SOA e BPM andem mais rápido?”, “Não tem um zé querendo que vc reaprenda algo pra te vender certificação?”.

Até certo ponto, concordo com vc… Acho válido sua colocação pra sistemas pequenos, e, realmente, não tem porque ficar complicando mesmo. Mas, em geral, SOA é aplicado em contextos onde o software para o cliente não para nunca de ser desenvolvido, tipo aqueles sistemas internos de empresa, que precisam de manutenção constante. Aí, não tem jeito, algo precisa ser (bem) feito desde o começo, senão acaba chegando o ponto onde o sistema tem que ser jogado fora e ser refeito, porque manutenção se torna difícil ou impossível (e repare que eu não citei SOA nesta frase).

[]´s

H

Legal o que vc disse, esperava até uma certa retaliação hehehe

Sim, o meu problema com a discussão é que acredito que isso de ser bem feito (a ponto de não ser reescrito um dia) nunca vai acontecer, pq arquitetura boa hoje, vira o legado de amanha que tera fatalmente de ser reescrito.

Acho que fazendo uma referencia a contabilidade o software deprecia e vai ter de ser jogado fora um dia, assim como computador.

Eu vejo livros antigos, caras falando que banco de dados relacional era o maximo da inovação, que eles seriam o centralizador da empresa…

Hoje vejo voces dizendo a mesma coisa com a mesma paixão do SOA (que é o centralizador, tudo passa ali e tals).

Ok, juro que acho bom, mas confesso que acho um pouco “inocente” esse amor.

Então pensando macro a nivel de PDI o diretor de TI deveria investir em software, pensando que em X anos (meu chute é 7, talvez se usar o estado da arte em tecnologia pode ser 10) ele terá de reinvestir.

Seria correto isso? Algum cliente pagaria nossos projetos se soubesse que tem vida limitada? A gente conta isso? hehehehe

A

heroijapa:
Legal o que vc disse, esperava até uma certa retaliação hehehe

Sim, o meu problema com a discussão é que acredito que isso de ser bem feito (a ponto de não ser reescrito um dia) nunca vai acontecer, pq arquitetura boa hoje, vira o legado de amanha que tera fatalmente de ser reescrito.

Acho que fazendo uma referencia a contabilidade o software deprecia e vai ter de ser jogado fora um dia, assim como computador.

Eu vejo livros antigos, caras falando que banco de dados relacional era o maximo da inovação, que eles seriam o centralizador da empresa…

Hoje vejo voces dizendo a mesma coisa com a mesma paixão do SOA (que é o centralizador, tudo passa ali e tals).

Ok, juro que acho bom, mas confesso que acho um pouco “inocente” esse amor.

Então pensando macro a nivel de PDI o diretor de TI deveria investir em software, pensando que em X anos (meu chute é 7, talvez se usar o estado da arte em tecnologia pode ser 10) ele terá de reinvestir.

Seria correto isso? Algum cliente pagaria nossos projetos se soubesse que tem vida limitada? A gente conta isso? hehehehe

Confesso que nunca pensei muito a respeito do assunto, mas acho que os clientes sabem disso, sim. Alguns gerentes de TI estão no mercado desde a época do CORBA, e provavelmente eles ouviam que isso seria o futuro, que CORBA era o futuro da programação distribuída, etc., etc. Por isso, alguns clientes sabem bem que isso nem sempre é uma verdade (e, sim, talvez SOA também não seja a resposta pro problema).

Contudo, o que todos sabem é que nós, que trabalhamos com TI, fazemos o possível pra minimizar nosso próprio trabalho e pra fornecer soluções que são entregues mais rapidamente pro cliente, o que acaba barateando o software. Acho que, no final das contas, mesmo que o software acabe depreciado, compensa fazer o investimento, desde que ele “sobreviva” o suficiente pra ter ROI. Essa é a idéia de SOA, prolongar a vida útil do software tempo suficiente pra que ele consiga se pagar e, quem sabe, até dar uma margenzinha de tempo antes que precise ser refeito.

Quanto à paixão por SOA, você tem toda razão!!! Alguns são xiitas, alguns nem tanto, mas acabamos, mesmo, sendo todos muito apaixonados por isso, por uma série de fatores. Pra mim, por exemplo, SOA é uma paixão porque foi a tecnologia que impulsionou minha carreira, foi a grande responsável por um crescimento muito rápido (em três anos, eu passei de desenvolvedor trainee para arquiteto). Obviamente, não foi fácil, mas com (bastante) esforço, acabei chegando na posição que queria.

D

Os banco de dados relacionais , Cobol e outras antiguidades estão ai firmes e fortes.

Aplicações distribuidas são o futuro na minha opinião.
Porém não podemos colocar as paixões na frente da razão.

Não acredito que SOA destrone as outras arquiteturas, mas com o avanço da internet e a necessidade de manter funcionalidades online e de maneira totalmente reutilizavel, SOA poderá se tornar um padrão.
Se vc ler SOA for Dummies verá o quão apaixonado alguns autores são (sempre falando em nova ordem mundial da TI xD).

Não sou um expert do assunto, mas estudo e programo webservices e wcf (aplicativos orientados a serviço da .net) acho bastante interressante , pois é um estilo totalmente diferente de programação.

O que falta é o entendimento do problema do negócio,
alguns casos é so mais alguem querendo implementar uma “nova moda”

Criado 18 de novembro de 2010
Ultima resposta 17 de jan. de 2011
Respostas 121
Participantes 17