Treinamento sobre ESB?

esse treinamento seria só pra você ou seria para empresa?

para a equipe da emrpesa.

A Oracle University tem

(Eu quase ministrei um curso assim…)

Pode informar o contato deles?

Entra no http://www.oracle.com/global/br/education/maps/index.html e seleciona tua cidade… você tem que falar direto com o training center.

[]´s

Olá Rafael, estou com um curso específico de ESB que inclusive ministrei à vários clientes - CVC Turismo, Intermédica, C&A, Porto de Santos entre outras companhias.

Sobre minha empresa :

A SOAExpert é uma empresa de treinamento recém formada por
especialistas em arquitetura e design de software, com forte ênfase em
produtos de integração, processos e componentização em serviços;
formando profissionais com uma visão clara e pragmática sobre como se
construir software com qualidade para os problemas do cotidiano
corporativo.

O curso será ministrado pelo instrutor Felipe Oliveira (Kenobi) ,
profissional com bastante vivência mercado SOA e experiência em TI
próxima a 16 anos. Foi IT Manager da VAD da Sun Microsystems,
arquiteto chefe da américa latina do banco francês BNP Paribas,
arquiteto da General Eletric, experiência internacional em diferentes
projetos e empresas e hoje é um dos instrutores da SOAExpert,
palestrando em diversos eventos sobre SOA - mais informações acesse : www.linkedin.com/in/soaexpert.

Módulos contidos no curso:

• Introdução ao SOA
• ESB - Primeira geração, conceitos e evolução.
• Instalando e configurando o Aqualogic Service Bus, Apache ServiceMix e Mule
• HelloWorld, criando o primeiro Business Service.
• Modelagem de serviços, contratos - WSDL.
• Canonical Data Model vs DDD - Domain Driven Design - Eric
  Evans.
• Integration patterns e sua realação com Aqualogic Service Bus
• Arquitura e Conceitos.
• Processamento de Mensagens, bindings e camadas de
  transporte, EJB Transporte à fundo
• EJB para clientes externos
• Orquestração vs Coreografia - Flows e tópicos avançados sobre
  Messaging.
• Composição de seviços, Testes, registros e versionamento.
• Modelos de Segurança.
• Overview sobre administração e operação.
• • Custom Transports - Overview de e exemplo simples de como
    se criar um transporte otimizado
    para o produto.

O curso ainda vai abranger 3 produtos - OSB (antigo AquaLogic Service Bus BEA) e 2 OpenSources lídres de mercado - Apache ServiceMix que é a base para muitos outros produtos ESB e Mule.

As turmas se iniciam dia 22 de fev e maiores informações estarão no site da empresa que entra no ar dia 26 de fev desse mês.

PS: Estou na correria aqui pra deixar tudo pronto, mas se quiser, posso levar o material para conhecerem, todo em português e desenvolvido com base em muito material de estudo e exercícios.

Kenobi, vc teria como fazer voltado para o ESB da JBoss?

Acredito que pelo menos a parte teorica sobre ESB seja a mesma
o que mudaria seria a parte pratica.

rafaelmeireles:

Kenobi, vc teria como fazer voltado para o ESB da JBoss?

Acredito que pelo menos a parte teorica sobre ESB seja a mesma
o que mudaria seria a parte pratica.

Tem certeza que você gostaria de aprender o ESB da JBoss? O produto da Oracle é muito, mas muito MESMO, mais maduro (pelo menos até o presente momento).

[]´s

rafaelmeireles:

Kenobi, vc teria como fazer voltado para o ESB da JBoss?

Acredito que pelo menos a parte teorica sobre ESB seja a mesma
o que mudaria seria a parte pratica.

Rafael se for corporativo podemos conversar sim, mas em outra data até pode ser antes do dia 22 de fev. Agora nesta data está fechada a grade, pois vai ser uma promoção inicial que vou lançar ao mercado que será o curso de introdução à soa + formação especialista de integração + engenheiro de processos (BPA- Overview, BPEL-BPM). Será um pacote de mais de 100 horas de curso

Entendo que a companhia queira optar por um produto, mas seria interessante uma análise de características em detrenimento do tipo de projeto que vão desenvolver e talvez nem haja a necessidade do produto no projeto.

Caso haja mesmo a necessidade, aí se deve levar em conta uma série de fatores.

Se quiser conversar sobre o assunto, mande um mail : [email removido]

PS: Como o Alexandre mencionou, o produto da Oracle é realmente fantástico e de longe o melhor da categoria.

Rafael, o próprio time da JBoss / Red Hat aqui do Brasil ministra o treinamento oficial JB453- JBoss ESB.
O outline do treinamento é este:

https://www.redhat.com/courses/jb453_jboss_esb/details/

Você pode entrar em contato com a Red Hat no telefone +55 ([telefone removido] ou pelo e-mail em [email removido].

Em relação a ser “maduro”, “melhor”, “mais acessível” ou “tecnologia correta” para o seu negócio é muito relativo ao que VOCÊ precisa. Se a companhia que você trabalha quiser uma apresentação sem compromisso do que é o “JBoss ESB”, entre em contato com a Red Hat Brasil.

[]s

Respeito sua opinião, mas existem fatores que fazem com que você posicione a solução da Oracle (alias são tantas: OracleESB, AcquaLogicESB) como mais madura?

Este é um daqueles tipos de debates do tipo: “Eu gosto mais de manga que laranja”, ou seja, sem embasamento para uma afirmação como esta, apenas posso dizer que é apenas uma opinião, e como você mesmo diz em sua assinatura: “Talvez não a verdade pura”

ESB’s ou ferramentas de Integração já passaram a ser soluções “odiadas” no mercado, devido ao fato das pessoas sempre tentarem empurrar um produto X, Y, Z que geralmente custa muito dinheiro, ao invés de se preocupar com a solução e o que irá trazer de retorno para o cliente.

Quanto a maturidade, o JBoss ESB tem seu codebase sobre o Rosetta ESB, que foi adquirido em 2006 pela JBoss[1], o Rosetta por sua vez teve seu primeiro deployment em 2003, então acredito que de lá pra cá, alguns produtos nasceram, outros morreram, e a solução opensource JBoss ESB continua em franca evolução, sem a preocupação e confusão de adquirir empresas e ter que descontinuar produto, ou ainda pior: Mesclar produtos (Oracle+BEA+Sun)!

Outro fator interessante, em 2008 o JBoss ESB foi agraciado com o prêmio BOSSIE Award from InfoWorld [2] como ?Best Enterprise Service Bus (ESB)? na categoria ?Best of Open Source Platforms and Middleware?.

Particularmente respeito todas as soluções do mercado de integração, várias empresas utilizam dos mais variados critérios para escolher a sua solução, umas optam pela “Tradição do Fornecedor”, outras pelo “Arrojo, Customizável e Baixo Custo de Implementação”… etc, e nesta esfera há várias soluções, entre elas o próprio BizTalk da Microsoft, é uma fantástica solução, mas eu ainda destaco a solução da Tibco, da SoftwareAG e o Mule da MuleSource, no final das contas, todas essas soluções são muito próximas, tanto em funcionalidades, quanto até mesmo em maturidade, afinal de contas, maturidade não é só tempo no mercado, acredito que estabilidade é um outro grande fator importante para uma empresa adotar ou não uma solução.

Ah, e de fato eu não cortei meus pulsos não , eu acredito que um debate educado e embasado só venha agregar mais esta vibrante comunidade que é o GUJ.

[1] http://www.theserverside.com/news/thread.tss?thread_id=40966
[2] http://press.redhat.com/2008/08/07/jboss-esb-and-jboss-drools-projects-win-infoworld-bossie-awards/

Rafael,

Além da opção que o Lazarotti lhe passou, se servir como fonte de estudo, você e seus colegas da sua equipe podem utilizar os slides de um Workshop que ministrei em Fortaleza em 2008. De lá pra cá o JBoss ESB evoluiu bastante, entretanto este material ainda serve como uma grande base com certeza.

http://edgarsilva.com.br/2008/10/29/material-do-workshop-soa-jboss-esb-versao-11/

A Red Hat possui o treinamento oficial, a grande vantagem é que você realiza treinamentos com profissionais com grande experiência em projetos de Integração , SOA, BPM etc.

Um dos grades cases do JBoss ESB no Brasil está no STF - Supremo Tribunal Federal, não quero aqui ficar fazendo propaganda, este canal não serve para isto, mas é que muitas vezes aqui ficam muito a opinião das pessoas, e acredito que muito mais que influenciar pessoas, devemos fornecer os fatos para que elas tomem suas próprias decisões, então segue um texto extraído de uma matéria de uma revista sobre o caso do STF:

No pêndulo da lei

Engana-se quem acha que apenas grandes empresas ou multinacionais investem em SOA, empresas de porte médio ou até mesmo o Governo tem seus exemplos (veja mais no Box: Investimento de mil faces). Um deles está no Supremo Tribunal Federal, que por meio de seu gabinete de tecnologia buscou uma solução de software livre. “Chegar ao SOA foi um processo de maturação que demorou por volta de 2 anos. Temos um legado bem heterogêneo e uma experiência prévia com a plataforma da Red Hat, além do padrão aberto ser o mais interessante dentre os que foram levados em consideração”, garante Alberto Magno Muniz Soares, analista judiciário do Supremo Tribunal de Justiça (STF).

A escolha da plataforma JBoss, da Red Hat, obedeceu ainda a um estudo de mercado que analisou desde o custo/benefício com custo visto como uma prioridade até os recursos proporcionados pelas mais diversas abordagens SOA. “Realizamos uma prova de conceito e vimos a oportunidade de mudar o enfoque de componentização do desenvolvimento para serviços. A integração de sistemas era feita no banco de dados o que trazia algumas deformações e perda de agilidade, agora tudo mudou”, admite Soares.

Além disto, no CONIP (Evento de Tecnologias do Governo), o pessoal de lá falou da experiência deles com SOA, recomendo você conferir os slides deles aqui:
http://www.conip.com.br/twiki/pub/Judiciario2009/ProgramaTemario/AlbertoMagnoMunizSoares.pdf

Em resumo, Rafael e amigos, agora acredito que vocês podem tomar suas decisões, não pela minha visão e sim pelos fatos aqui apresentados.

Eu sei que vários aqui podem aqui várias vezes tentar bater nos produtos JBoss, ou que a Red Hat é um vilão por ter o modelo de suporte e serviços sobre opensource, e na verdade, o que estamos fazendo é trabalhando muito para que a prática de opensource sobreviva, e que esse modelo de negócios seja encarado como algo de sucesso, e não apenas “Marketing de bonzinhos”. Certos ou não, mas contratamos um grande número de profissionais nos ultimos anos, nosso time em 2009 cresceu tanto na Red Hat, que o número de profissionais técnicos da divisão JBoss já é maior que os de Red Hat Linux, isto demonstra o crescimento que tivemos com trabalho e não manchando produto de ninguém. Toda vez que aparece algo falando mal de JBoss no GUJ, tentamos nos reservar ao direito do silêncio, porém é direito das pessoas terem suas opiniões, , mas nos confortamos nos esforçando para continuarmos provando que não queremos dominar o mundo, e sim, apenas ser uma alternativa ao modelo proprietário e caro, que não necessariamente significa ser: “O melhor” !

Forte abraço

Bom com relação à Oracle, oficialmente o produto antigo foi descartado e o que veio da BEA é o OSB padrão, portanto, existe somente 1 e foi o qual me referi.

Não estou julgando as ferramentas, tenho certeza que a JBoss possui uma equipe excelente e o produto está evoluindo rápido. Com relação à features, como gestão de SLA, Throttling,Definição de Rotas por configuração com editor plugin (Eclipse) ou via Web; são muitas as características que me fazem preferir a solução Oracle-BEA. Claro que há também questões como ROI entre outras, estou me atendo somente à detalhes técnicos aqui.

Rafael, não conheço o treinamento da JBoss, posso te falar da Oracle-BEA, pois eu já os ministrei e o problema que enxergo é que ficam muito focados no produto e passo-a-passo, com pouco ou nenhum grau de teoria.

Edgar,

Eu sou meio suspeito pra falar de algumas coisas
Eu sou autor de um artigo na Java Magazine falando sobre jBPM. Não sou nenhum tipo de evangelista da Oracle pra dizer “ah, esse produto é melhor do que aquele porque esse produto é da empresa X”. Mas é fato que eu conheço os dois produtos e sei que o JBoss ESB tem alguns problemas de estabilidade (fato é que praticamente toda solução enterprise tem algum problema, mas o JBoss ESB tem mais). Além disso, não sei de nenhuma ferramenta (até o presente momento) que facilite o desenvolvimento de soluções para o JBoss ESB (da última vez que olhei, ainda era o “escrever XML na mão”). Isso me leva a crer que o Oracle Service Bus (antigo Aqualogic, que já era uma ferramenta bastante prestigiada) é uma ferramenta “melhor”, do ponto de vista de desenvolvimento.

Por favor, esclareça se em algum desses pontos eu estou errado. Acredito, sim, que um debate saudável é a chave para que cheguemos num consenso. Francamente, espero estar errado a respeito destes detalhes sobre o JBoss ESB (como eu disse antes, sou autor de um artigo sobre jBPM e , sinceramente, acho uma ferramenta fantástica. Gostaria que o JBoss ESB fosse tão fantástico quanto!).

[]´s

Quando você falou “Gestão de SLA”, você se referia a aba “SLA Alert Rules” dos proxy services ou aos gráficos que o BAM gera?

Pessoal,

Estava procurando por algum gráfico, ou comparação (tipo do Gartner) para embasar meu posicionamento, quando me deparei com este link: http://www.guors.com.br/documentos_2007/ApresentacaoSOA_GUORS.pdf

Este PDF foi elaborado pelo Grupo de Usuário Oracle do RS (GUORS).

Trata-se de uma explicação de qual é a estratégia SOA. Até aí, tudo bem… até chegar na penúltima página, onde ele mostra a Red Hat como cliente do ORACLE SOA. Achei, no mínimo, estranho!!

(Acho que todos aqui sabem que a Red Hat comprou a JBoss, que tem sua própria plataforma SOA).

Alguém aí sabe dizer se é verídico, se a Red Hat realmente é cliente da Oracle neste sentido?

asaudate:

Tem certeza que você gostaria de aprender o ESB da JBoss? O produto da Oracle é muito, mas muito MESMO, mais maduro (pelo menos até o presente momento).

Eu sou meio suspeito pra falar de algumas coisas
Eu sou autor de um artigo na Java Magazine falando sobre jBPM. Não sou nenhum tipo de evangelista da Oracle pra dizer “ah, esse produto é melhor do que aquele porque esse produto é da empresa X”. Mas é fato que eu conheço os dois produtos e sei que o JBoss ESB tem alguns problemas de estabilidade (fato é que praticamente toda solução enterprise tem algum problema, mas o JBoss ESB tem mais). Além disso, não sei de nenhuma ferramenta (até o presente momento) que facilite o desenvolvimento de soluções para o JBoss ESB (da última vez que olhei, ainda era o “escrever XML na mão”). Isso me leva a crer que o Oracle Service Bus (antigo Aqualogic, que já era uma ferramenta bastante prestigiada) é uma ferramenta “melhor”, do ponto de vista de desenvolvimento.

Por favor, esclareça se em algum desses pontos eu estou errado. Acredito, sim, que um debate saudável é a chave para que cheguemos num consenso. Francamente, espero estar errado a respeito destes detalhes sobre o JBoss ESB (como eu disse antes, sou autor de um artigo sobre jBPM e , sinceramente, acho uma ferramenta fantástica. Gostaria que o JBoss ESB fosse tão fantástico quanto!).

[]´s

@ asaudate

Quanto aos problemas de estabilidade, numa das respostas eu publiquei um dos casos no Brasil, um de vários mesmo, acredito que aqui não é lugar de ficar fazendo propaganda, mas você deve atentar alguns pontos:

• Quais problemas você teve?
• Você pediu ajuda, se sim pra quem?
• Você debugou a ponto de ver que o erro era algo do codebase ?

Algumas pessoas reclamam as vezes de questões sem embasamento, ontem mesmo um colega nosso (Ricardo Ferreira), comentou que um cliente dizia que quando o JBoss subia ele derrubava o SQL Server, ele só não disse que a SQL de teste se a conexao do SQL estava válida e estava no ar era uma SQL que lia todas as tabelas de sistemas do MS SQL Server o que era para ser uma especie de select from dual simples, como é executado várias vezes para validar o pool, fazia com que o SQL travasse claro . Consegue perceber que estabilidade é algo extremamente relativa?

Quanto a edição de XMLs, o JBoss ESB através dos plugins do JBoss Tools oferece de forma visual as facilidades para criar as Actions, e declarar listeners etc, para isto veja isto aqui:

http://docs.jboss.org/tools/3.1.0.CR1/en/esb_ref_guide/html_single/index.html

E ai, você usa o XML se quiser, eu até gosto, já que tem codecompletion

No JBoss ESB 4.7 (futuro release do JBoss SOA Platform 5.0), você também tem total suporte de transformações através do framework Smooks:

• http://docs.jboss.org/tools/3.1.0.CR1/en/jboss_smooks_plugin_ref_guide/html_single/index.html
• http://www.screencast.com/users/tfennelly/folders/Camtasia/media/4b184ca6-9a6d-4817-b15d-aac8576d36bb

E ainda, o JBoss ESB 4.7 pode ser instalado o RiftSaw, que é o motor BPEL JBoss baseado no Apache ODE, e ai você pode ter por ex um WSDL que representam seu BPEL e este pode invocar outros N WSDLs, classes Java, ou até mecanismos REST (esta extensão foi feita pelo time no Brasil)

http://docs.jboss.org/tools/3.1.0.CR1/en/bpel_user_guide/html_single/index.html

E como você é um usuário do JBPM, um outro mecanismo visual de Orquestração de Serviços do JBoss ESB é você através do JBPM utilizar o ESBNode, o qual por sua vez interage totalmente com a máquina de processos BPM do JBPM que reside também no JBoss ESB server quando em execução, então você pode ter um JPDL que visualmente irá lhe dizer em que passo está a execução de alguma chamada de Serviço. Ou melhor, você pode ter um listener de FTP que ao chegar um arquivo este evento automaticamente inicialize um processo do JBPM.

Além disto, recentemente foi fundado pelo mesmo cara que desenvolve o Smooks (Tom Fenelly) e outras pessoas, um projeto que visa trazer ainda mais contribuidores pro JBoss ESB, que é o breakingwoods (http://code.google.com/p/breakingwoods/ )

Se você gosta do JBPM, que eu posso dizer que conheço razoavelmente, se você começar a imergir nas coisas novas do JBoss ESB, e de preferência buscando ajuda se necessário, eu tenho certeza que você irá mudar sua perspectiva deste projeto.

Vale lembrar, que temos uma comunidade de debate e pesquisa de JBoss em pt_BR que é o http://jbossbrasil.ning.com/

Se ficou faltando algum ponto ainda, por favor, só falar, eu nao quis ficar aqui lotando de informação ok?

[]s

Eu não pretendo, obviamente, ficar fazendo propaganda (como já disse antes, sou agnóstico). E faz algum tempo, também, que não lido com o JBoss ESB (provavelmente estou desatualizado).

Vamos fazer o seguinte… segunda-feira é feriado em São Paulo. Vou ver se tiro o fds pra elaborar alguns pontos a serem validados em ambos os Service Bus e posto aqui os resultados dos testes que fizer , OK?

Se eu tiver alguma dúvida, entro em contato com você , tudo bem?

[]´s

Bom com relação à Oracle, oficialmente o produto antigo foi descartado e o que veio da BEA é o OSB padrão, portanto, existe somente 1 e foi o qual me referi.

Não estou julgando as ferramentas, tenho certeza que a JBoss possui uma equipe excelente e o produto está evoluindo rápido. Com relação à features, como gestão de SLA, Throttling,Definição de Rotas por configuração com editor plugin (Eclipse) ou via Web; são muitas as características que me fazem preferir a solução Oracle-BEA. Claro que há também questões como ROI entre outras, estou me atendo somente à detalhes técnicos aqui.

Continua sendo uma opiniao!

Então posso emitir a minha: Esta estratégia “boil the ocean”(ferver a água do oceano) que algumas empresas trazem e esses jargões bonitos e pomposos muitas vezes são comprados por alguns gestores que nada entendem de negócio e muitas vezes de Tecnologia mesmo, e na hora de implementação, percebem que nada disso substitui “A simples prática”. Eu achava que essa fase de SOA tinha ido embora, essa que as pessoas ficam falando termos assustadores para embasar uma solução melhor que a outra, e no final, o que toda a empresa apenas sonha é: “Gastar menos e ganhar mais”, “Fazer mais com menos”.

Não estou desmerecendo o conhecimento, seja técnico e as vezes até academico da coisa, pelo contrário, mas temos que ser mais pragmáticos, afinal estamos na era de Ruby, Scala, Groovy até JavaScript … Vale a pena pensar no simples, mas no final de tudo, a única coisa que vão perguntar é: “Está pronto ?”

Outro fator importante, vivemos uma época de crise, ninguém tem dinheiro sobrando, eu atentaria em embasar minhas soluções em algo que me gerasse economia, então ROI pode ser mais importante que fatores técnicos. Além disto, se você está começando uma empresa, eu tenho certeza que vale a pena você seguir até mesmo o exemplo de sucesso da Caelum e oferecer soluções para o mercado que sejam acessíveis por ele depois, neste caso você está certíssimo em falar de ServiceMix, Mule (adoro estes projetos tb), adicionaria o Apache Camel, mas usando um item de Administração: “Pesquisa de Mercado”, acredito que valeria pena você abordar o JBoss ESB no futuro… E esta dica é de quem já teve empresa também

Já pensou… Esses termos bonitos + a simplicidade e pragmatismo do JBoss ESB : Seria muito bom.

asaudate:

ankiewsky:

…

Eu não pretendo, obviamente, ficar fazendo propaganda (como já disse antes, sou agnóstico). E faz algum tempo, também, que não lido com o JBoss ESB (provavelmente estou desatualizado).

Vamos fazer o seguinte… segunda-feira é feriado em São Paulo. Vou ver se tiro o fds pra elaborar alguns pontos a serem validados em ambos os Service Bus e posto aqui os resultados dos testes que fizer , OK?

Se eu tiver alguma dúvida, entro em contato com você , tudo bem?

[]´s

Pára asaudate, vai pra praia , deve fazer Sol este final de semana em SP …

Brincadeiras a parte estou a disposição, só não sou dos maiores fans de ficarmos fazendo benchmarks pq isto dá um mega trabalho.

Meu email é: edgar (vocesabequesimboloparaevitarspam *quebra ####)[)])) R& *) redhat.com

Abraços e obrigado pela oportunidade de falar do projeto opensource JBoss ESB .

Alessandro, aqui temos o suporte completo da JBoss, já fizemos alguns treinamentos
mais não gostamos da metodologia utilizada, fica so ali passando os slides e aqueles
labs tudo prontinho já, não gostei muito do formato do curso não, agora se puderem mudar
um pouco a forma do treinamento pelo menos para nossa turma ai pode ser.

ankiewsky:

asaudate:

ankiewsky:

…

Eu não pretendo, obviamente, ficar fazendo propaganda (como já disse antes, sou agnóstico). E faz algum tempo, também, que não lido com o JBoss ESB (provavelmente estou desatualizado).

Vamos fazer o seguinte… segunda-feira é feriado em São Paulo. Vou ver se tiro o fds pra elaborar alguns pontos a serem validados em ambos os Service Bus e posto aqui os resultados dos testes que fizer , OK?

Se eu tiver alguma dúvida, entro em contato com você , tudo bem?

[]´s

Pára asaudate, vai pra praia , deve fazer Sol este final de semana em SP …

Brincadeiras a parte estou a disposição, só não sou dos maiores fans de ficarmos fazendo benchmarks pq isto dá um mega trabalho.

Meu email é: edgar (vocesabequesimboloparaevitarspam *quebra ####)[)])) R& *) redhat.com

Abraços e obrigado pela oportunidade de falar do projeto opensource JBoss ESB .

A previsão é de chuva

Edgar, eu também acredito muito na simplicidade e realmente pra qual cenário o produto se destina.

O ESB primeiramente não é um produto para a base do SOA como os players vendem (minha opinião). Ele serve para muitos pontos importantes de integração como CICS, SAP ou centralização de políticas de segurança entre diversos sistemas em plataformas diferentes e por aí vai.

Agora se o desenvolvimento é novo, um projeto inteiro Web, existem outras abordagens como Restful, uso de RelaxNG, Hypermedia - ATOM, frameworks como o do pessoal da Caelum, Restfulie e por aí vai.

ESB é pra quem realmente precisa e quando vamos integrar por exemplo um protocolo financeiro complexo como SWIFT, aí você precisa além de tempo de tempo de desenvolvimento, como uma linguagen dinâmica Groovy em cima do ESB (JBoss), confiabilidade, escalonamento da solução como processamento SEDA (Mule) - http://www.eecs.harvard.edu/~mdw/proj/seda, ferramentas de transformação como MFL Format, XQuery Engine ( 6x mais rápido que o XPath tradicional), XMLBeans - framework interno OXM de alto desempenho e por aí vai.

Tenho certeza que o JBossESB está à altura da competição e vou incluí-lo no meu portfólio de treinamentos caso haja interesse do mercado pela solução :-).

Agora Teiid, Drools, são produtos de primeira classe que dão banho em muitos produtos pagos do mercado e são minha primeira opção tanto em cursos quanto consultoria :-).

Rubem Azenha:

Kenobi:

Não estou julgando as ferramentas, tenho certeza que a JBoss possui uma equipe excelente e o produto está evoluindo rápido. Com relação à features, como gestão de SLA, Throttling,Definição de Rotas por configuração com editor plugin (Eclipse) ou via Web; são muitas as características que me fazem preferir a solução Oracle-BEA. Claro que há também questões como ROI entre outras, estou me atendo somente à detalhes técnicos aqui.

Quando você falou “Gestão de SLA”, você se referia a aba “SLA Alert Rules” dos proxy services ou aos gráficos que o BAM gera?

Só para o pessoal conseguir acompanhar seu post, no OSB você tem basicamente 2 estruturas: BusinessServices e ProxyServices. Os business encapsulam internamente um serviço enquanto os proxies são encarregados de exporem para fora, agregarem fluxos-orquestrações. Por tal motivo os pontos de controle de nível de serviço se aplicam diretamente nos Proxies.

Imagine um cenário de emissão de nota fiscal eletrônica, onde o cliente precisa fazer uma chamada síncrona de status da nota fiscal, e o fluxo como um todo não pode exceder 5 segundos.

Para saber onde são os pontos de controle, quais serviços estão impactando seu desempenho, o produto tem a possibilidade de configurar uma série de alertas, desde tempo médio de resposta à erros entre muitos outros - http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/consolehelp/monitoring.html#wp1029033

A BEA, não tinha nenhum produto de Business Activity Monitoring como o BAM da Oracle, por isso ela incorporou os DashBoards ao produto, onde é possível monitorar e extrair relatórios, por isso chamei de gestão de SLA, pq na prática você consegue tomar decisão sobre o desempenho da sua solução.

rafaelmeireles:

Alessandro, aqui temos o suporte completo da JBoss, já fizemos alguns treinamentos
mais não gostamos da metodologia utilizada, fica so ali passando os slides e aqueles
labs tudo prontinho já, não gostei muito do formato do curso não, agora se puderem mudar
um pouco a forma do treinamento pelo menos para nossa turma ai pode ser.

Para o JBoss ESB e alguns outros projetos da linha de SOA, os Instrutores certificados a ministrarem este treinamento são pouquissimos, entre eles:

• Ricardo Ferreira (Colunista da Mundo Java - SOA) - http://architecture-journal.blogspot.com
• Alessandro Lazarotti
• Leandro Abite
• João Paulo Viragine (Red Hat/ JBoss, Brasilia)
• Rafael Liu (Red Hat/ JBoss, Brasilia)

Os treinamentos desta linha são tratados de forma particular, mas eu vou levar este feedback do treinamento para a Gerente Responsável.

Se for turma fechada, eu posso pedir para o Instrutor deixar o “by the book” e ir mais profundo nos assuntos, recentemente o Lazarotti fez isto num treinamento, no qual ele chegou a mostrar algumas coisas de JEE6+ Weld etc… Num treinamento que por padrão nao aborda tais tópicos.

Contacte-nos em off: edgar —arroba---- redhat.com

[]s

asaudate:

Pessoal,

Estava procurando por algum gráfico, ou comparação (tipo do Gartner) para embasar meu posicionamento, quando me deparei com este link: http://www.guors.com.br/documentos_2007/ApresentacaoSOA_GUORS.pdf

Este PDF foi elaborado pelo Grupo de Usuário Oracle do RS (GUORS).

Trata-se de uma explicação de qual é a estratégia SOA. Até aí, tudo bem… até chegar na penúltima página, onde ele mostra a Red Hat como cliente do ORACLE SOA. Achei, no mínimo, estranho!!

(Acho que todos aqui sabem que a Red Hat comprou a JBoss, que tem sua própria plataforma SOA).

Alguém aí sabe dizer se é verídico, se a Red Hat realmente é cliente da Oracle neste sentido?

Sim, usava, não sei se posso ficar falando o que a empresa usa, mas nós usamos o SalesForce como ERP, que é fantástico, e usamos algumas coisas de Oracle Business Suite (RH e outros modulos) que há muitos anos foram “doadas” para a Red Hat, muito antes de eles pensarem em comprar a JBoss, não acho isso errado. Eu não acho que um cara que tem licença pagas do Banco de Dados oracle por mais 3 anos, fique tentando trocar pelo PostgreSQL, só pq o PG é opensource, afinal, ele já pagou, já se estrepou mesmo pagando uma bica de licença, ele tem mais é que usar, e qdo a licença expirar, ele se planeja para trocar para uma solução melhor.

Se a SAP tivesse doado, seria melhor, mas…

Fazem 2 anos que algumas coisas foram migradas, entre elas os TomCats por JBoss, o Oracle ESB por JBoss SOA-P e outros sistemas novos vieram, entre eles IssueTracker etc…

Saiu um report do Gartner deste ano, o JBoss ESB foi bem avaliado.

[]s
E

Não esquenta Edgar… principalmente em TI, em casa de ferreiro, o espeto é de pau

Pois é … Paciência …

Eu mesmo preferia usar Macintosh, mas a empresa nos dá thinkpads que ai pelo menos usamos ou Red Hat Linux ou Fedora :), seguimos um pedido de nosso Country Manager

asaudate,

Esta questão de “estabilidade” é algo muito relativo. Eu tinha um professor de estruturas de dados na faculdade que dizia a seguinte frase: “Se não está funcionando, é porque você não está fazendo direito!” - Na época, eu ficava irritado com a frase, mais hoje, vejo que é a mais pura verdade. Vou te dar um exemplo (até oportuno) do que estou falando …

Eu trabalhei dando consultoria e liderança técnica por quase dois anos na Oi, que possui sua base técnica de middleware totalmente voltada a produtos Oracle por razões muito mais comerciais do que técnicas. Em trẽs dos projetos que participei com eles, usei o AquaLogic Service Bus e o AquaLogic Data Services como plataformas de EAI e EII para os projetos que hoje representam 80% da recem criada área de VAS (Value-Added Services) da Oi. Um destes projetos (chamado na época de projeto BroadCast) era totalmente baseado no AquaLogic ESB. Criei vários Proxy Services nele baseados tanto em JMS, SOAP quanto em T3 (Protocolo do AquaLogic DSP) e estes proxies eram front-ends de diversos Business Services que usavam a genial (porém questionável) implementação de Custom Transport e Flow Control do ESB para mediação de serviços.

A moral da história é que o projeto, pouco antes de ser entregue, estava com sérios problemas de performance devido ao intenso uso de XSLT nas transformações do AquaLogic, mecanismo esse que, baseia 100% daquele editor “bonitinho” web onde você cria pipelines de forma visual. O uso de XML no CPU estava sempre em 100% com uma taxa de somente 500 requisições simultâneas (Dois sevidores em Cluster). Na época, me relutei e acreditar que um super ESB daquele porte (que já estava sendo introduzido na Oi pela Oracle devido a descontinuação do WLI [WebLogic Integrator]) tinha problemas tão básicos. Acionamos o suporte da BEA na época, e os consultores recomendaram que, se performance era crucial, que evitassemos criar mediações intensas usando XSLT (opção default quando você cria as coisas “visualmente”) que criássemos o que o AquaLogic chama de “Java Callouts”, que é na prática, criar uma classe Java estática que recebe uma mensagem como parâmetro e você a processa usando código Java. Achei uma solução bem “tosca” mas no final das contas, fez com que entregássemos o projeto com os devidos SLA’s de performance, apesar de criarmos uma série de outros problemas no cluster, uma vez que as classes eram estáticas, ou seja, carregadas numa dada JVM. Por sorte, o jRockit (JVM da BEA) possibilitou criar um classLoader distribuído destas classes, mecanismo esse que foi a solução final dos problemas.

Que conclusões podemos tirar desta pequena história:

1. Estabilidade muitas das vezes está relacionado a fazer as coisas da forma correta, e não da forma mais fácil;
2. As features mais interessantes de qualquer produto na maioria das vezes, se aplica somente a cenários simples;
3. As vezes, você julga que o que um consultor ou fabricante lhe fala é errado, mas na maioria das vezes é algo que você NÃO quer ouvir
4. O uso de uma solução visual atraente trás consigo, a necessidade de se fazer uso de diversas outras “abordagens” técnicas alternativas;

Numa situação análoga, hoje, atuando na Red Hat do Brasil, já presenciei diversos projetos onde pessoas com dificuldades com o JBoss ESB reclamavam de sua “estabilidade”, “performance” ou “aparência”, e, depois de algumas horas de conversa e tunnings, eles vêem em concordam que o JBoss ESB aguenta o tranco tal como qualquer outro ESB do mercado que respeito (dentre eles, o próprio Oracle Service Bus) e que a questão da usabilidade é, em ultima análise, um ponto nem tão importante assim uma vez que você cria seus métodos de desenvolvimento próprios. Nós da Red Hat reconhecemos que, o JBoss ESB ainda precisa evoluir muito na questão de ferramentas visuais, e se vocês acompanharem os últimos releases do JBoss Tools verão que a coisa está mudando e que muito esforço está sendo feito para sanar isso. Mas como sempre digo, prefiro priorizar a criação de um software que mesmo “feio” dá conta do recado, do que softwares que são bonitos, mas que para que funcionem adequadamente precisam de vários outros produtos coadjuvantes e complementares, o que aumenta ainda mais no investimento em ferramentas.

A recomendação que faço sobre este tema é, seja qual for o curso que será investido, lembre-se sempre que na hora de colocar a solução de ESB em produção no seu cliente, este terá que arcar com os custos da mesma se ela for baseada no modelo de licenças. Se você é uma fabrica de software ou software house, é bom ter cuidado para não criar soluções que dependem de plataformas proprietárias. Cerca vez criei um projeto baseado no BizTalk da Microsoft (outro excelente ESB) e na hora de fazer as primeiras entregas, o cliente se assustou um pouco com o fato de que a plataforma era mais cara que o projeto em si, quase comprometendo o nosso investimento. Convencemos as duras penas ele a comprar (leia-se: Empurramos o BizTalk pra ele) e conseguimos nos livrar dessa. Depois disso, todos nossos projetos eram baseados no JBoss ESB, não porque ele seja melhor ou pior que o BizTalk (ou outros) mas porque a conta pode ser cara demais para os clientes finais

Recomendo fortemente o uso de soluções open-source, não só o JBoss ESB, mas o Mule, ServiceMix ou outros, porque isso garante menor vendor lock-in nos clientes. Investir um treinamento em Oracle ESB é algo bom? Claro que sim, desde que o cliente final que você deseja colocar suas soluções tenha licenças pra ele, ou esteja ciente e preparado para adquiri-las. Neste caso, o investimento em capacitação que farão hoje, irá ditar seus próximos passos no futuro. E, tecnicamente falando, conhecer um ESB te dá a oportunidade de conhecer outros com maior facilidade, pois vários aspectos técnicos destas soluções são baseados em padrões de desenho de integração. Consulte EAI Patterns e veja como eles baseiam diversas das plataformas que hoje existem.

Cordialmente,

Ricardo Ferreira
architecture-journal.blogspot.com

Ricardo Ferreira:

asaudate,

Esta questão de “estabilidade” é algo muito relativo. Eu tinha um professor de estruturas de dados na faculdade que dizia a seguinte frase: “Se não está funcionando, é porque você não está fazendo direito!” - Na época, eu ficava irritado com a frase, mais hoje, vejo que é a mais pura verdade. Vou te dar um exemplo (até oportuno) do que estou falando …

Eu trabalhei dando consultoria e liderança técnica por quase dois anos na Oi, que possui sua base técnica de middleware totalmente voltada a produtos Oracle por razões muito mais comerciais do que técnicas. Em trẽs dos projetos que participei com eles, usei o AquaLogic Service Bus e o AquaLogic Data Services como plataformas de EAI e EII para os projetos que hoje representam 80% da recem criada área de VAS (Value-Added Services) da Oi. Um destes projetos (chamado na época de projeto BroadCast) era totalmente baseado no AquaLogic ESB. Criei vários Proxy Services nele baseados tanto em JMS, SOAP quanto em T3 (Protocolo do AquaLogic DSP) e estes proxies eram front-ends de diversos Business Services que usavam a genial (porém questionável) implementação de Custom Transport e Flow Control do ESB para mediação de serviços.

A moral da história é que o projeto, pouco antes de ser entregue, estava com sérios problemas de performance devido ao intenso uso de XSLT nas transformações do AquaLogic, mecanismo esse que, baseia 100% daquele editor “bonitinho” web onde você cria pipelines de forma visual. O uso de XML no CPU estava sempre em 100% com uma taxa de somente 500 requisições simultâneas (Dois sevidores em Cluster). Na época, me relutei e acreditar que um super ESB daquele porte (que já estava sendo introduzido na Oi pela Oracle devido a descontinuação do WLI [WebLogic Integrator]) tinha problemas tão básicos. Acionamos o suporte da BEA na época, e os consultores recomendaram que, se performance era crucial, que evitassemos criar mediações intensas usando XSLT (opção default quando você cria as coisas “visualmente”) que criássemos o que o AquaLogic chama de “Java Callouts”, que é na prática, criar uma classe Java estática que recebe uma mensagem como parâmetro e você a processa usando código Java. Achei uma solução bem “tosca” mas no final das contas, fez com que entregássemos o projeto com os devidos SLA’s de performance, apesar de criarmos uma série de outros problemas no cluster, uma vez que as classes eram estáticas, ou seja, carregadas numa dada JVM. Por sorte, o jRockit (JVM da BEA) possibilitou criar um classLoader distribuído destas classes, mecanismo esse que foi a solução final dos problemas.

Que conclusões podemos tirar desta pequena história:

1. Estabilidade muitas das vezes está relacionado a fazer as coisas da forma correta, e não da forma mais fácil;
2. As features mais interessantes de qualquer produto na maioria das vezes, se aplica somente a cenários simples;
3. As vezes, você julga que o que um consultor ou fabricante lhe fala é errado, mas na maioria das vezes é algo que você NÃO quer ouvir
4. O uso de uma solução visual atraente trás consigo, a necessidade de se fazer uso de diversas outras “abordagens” técnicas alternativas;

Numa situação análoga, hoje, atuando na Red Hat do Brasil, já presenciei diversos projetos onde pessoas com dificuldades com o JBoss ESB reclamavam de sua “estabilidade”, “performance” ou “aparência”, e, depois de algumas horas de conversa e tunnings, eles vêem em concordam que o JBoss ESB aguenta o tranco tal como qualquer outro ESB do mercado que respeito (dentre eles, o próprio Oracle Service Bus) e que a questão da usabilidade é, em ultima análise, um ponto nem tão importante assim uma vez que você cria seus métodos de desenvolvimento próprios. Nós da Red Hat reconhecemos que, o JBoss ESB ainda precisa evoluir muito na questão de ferramentas visuais, e se vocês acompanharem os últimos releases do JBoss Tools verão que a coisa está mudando e que muito esforço está sendo feito para sanar isso. Mas como sempre digo, prefiro priorizar a criação de um software que mesmo “feio” dá conta do recado, do que softwares que são bonitos, mas que para que funcionem adequadamente precisam de vários outros produtos coadjuvantes e complementares, o que aumenta ainda mais no investimento em ferramentas.

A recomendação que faço sobre este tema é, seja qual for o curso que será investido, lembre-se sempre que na hora de colocar a solução de ESB em produção no seu cliente, este terá que arcar com os custos da mesma se ela for baseada no modelo de licenças. Se você é uma fabrica de software ou software house, é bom ter cuidado para não criar soluções que dependem de plataformas proprietárias. Cerca vez criei um projeto baseado no BizTalk da Microsoft (outro excelente ESB) e na hora de fazer as primeiras entregas, o cliente se assustou um pouco com o fato de que a plataforma era mais cara que o projeto em si, quase comprometendo o nosso investimento. Convencemos as duras penas ele a comprar (leia-se: Empurramos o BizTalk pra ele) e conseguimos nos livrar dessa. Depois disso, todos nossos projetos eram baseados no JBoss ESB, não porque ele seja melhor ou pior que o BizTalk (ou outros) mas porque a conta pode ser cara demais para os clientes finais

Recomendo fortemente o uso de soluções open-source, não só o JBoss ESB, mas o Mule, ServiceMix ou outros, porque isso garante menor vendor lock-in nos clientes. Investir um treinamento em Oracle ESB é algo bom? Claro que sim, desde que o cliente final que você deseja colocar suas soluções tenha licenças pra ele, ou esteja ciente e preparado para adquiri-las. Neste caso, o investimento em capacitação que farão hoje, irá ditar seus próximos passos no futuro. E, tecnicamente falando, conhecer um ESB te dá a oportunidade de conhecer outros com maior facilidade, pois vários aspectos técnicos destas soluções são baseados em padrões de desenho de integração. Consulte EAI Patterns e veja como eles baseiam diversas das plataformas que hoje existem.

Cordialmente,

Ricardo Ferreira
architecture-journal.blogspot.com

Ricardo,

Acredito que, de fato, cada cliente tem seu nicho. Alguns podem preferir o JBoss ESB, outros podem preferir o Oracle Service Bus. Quanto às características técnicas, já citei neste fórum que pretendo conduzir, neste final de semana, uma comparação técnica entre os dois produtos de maneira que o usuário do fórum poderá decidir qual o melhor produto. A saber, esta comparação deverá levar em conta os seguintes tópicos:

Ferramentas de desenvolvimento disponíveis;

Conectores;

Performance;

Estabilidade;

Integração com outras ferramentas;

Features;

Protocolos suportados;

Database;

Application Servers / compatibilidade;

Segurança;

Event Handling;

Frameworks de web services;

Suporte a hypermedia;

Suporte a WS-Specs;

Linguagens;

Formatos e transformações de dados;

Documentação;

Patterns implementados.

Pretendo conduzir esta análise e postar neste fórum, detalhadamente, quais foram os testes e as conclusões obtidas. Desta maneira, acredito que pode-se obter uma análise imparcial a respeito dos produtos.

Quanto ao fato da licença do Oracle, minha opinião pessoal é de que as empresas que utilizam SOA podem pagar pelo produto. O valor do SOA Suite, que eu acabo de verificar no site da Oracle, varia entre 240 e 57.500 dólares (de acordo com o número de usuários). Acredito eu que empresas desse porte têm condições de pagar pelo produto (é mais barato do que o Windows =) ).

[]´s

<blockquote>Ferramentas de desenvolvimento disponíveis;

Conectores;

Performance;

Estabilidade;

Integração com outras ferramentas;

Features;

Protocolos suportados;

Database;

Application Servers / compatibilidade;

Segurança;

Event Handling;

Frameworks de web services;

Suporte a hypermedia;

Suporte a WS-Specs;

Linguagens;

Formatos e transformações de dados;

Documentação;

Patterns implementados.

Pretendo conduzir esta análise e postar neste fórum, detalhadamente, quais foram os testes e as conclusões obtidas. Desta maneira, acredito que pode-se obter uma análise imparcial a respeito dos produtos.

Quanto ao fato da licença do Oracle, minha opinião pessoal é de que as empresas que utilizam SOA podem pagar pelo produto. O valor do SOA Suite, que eu acabo de verificar no site da Oracle, varia entre 240 e 57.500 dólares (de acordo com o número de usuários). Acredito eu que empresas desse porte têm condições de pagar pelo produto (é mais barato do que o Windows =) ).

[]´s

Só tem que tomar cuidado para isso nao parecer aquele programa do Discovery que 2 caras vao a vários lugares do mundo aprender as artes marciais locais, e eles treinam por 1 semana, e no final, quase sempre apanham que nem criança, provando que a experiência em alguns casos, vale mais que a simples vontade de superar.

Não precisa levar 3 dias, se você quiser fazer algo assim, faça um artigo, alguma coisa mais trabalhada…

Outro detalhe, o licenciamento do Oracle Suite é feito da seguinte forma:

=> Se você tiver o model “Usuário Nomeado”, que é um modelo da Oracle de licenciamento que significa o “usuario que acessa o recurso”, somente assim você pode pagar por usuário, se não você paga por processador, entao se vc tem aplicativos Web que acessam seus serviços tem que ser por processador.

=> Então mais uma vez, é melhor ter mais atenção o levantamento das informações, então vamos a continha de padaria [1]:

Oracle SOA Suite[1]: 57.500 Licença + 12.650 de Suporte == $ 70.150 Isto por 1 ou disse uma 1 e misera CPU!

Se você tiver 1 Ambiente com minimo de 2 máquinas para ter alta-disponibilidade, com 2 CPUs vc paga 140.300.

Sem falar que a Oracle cobra os Núcleos também, que nem vou mencionar, acho que já deu para as pessoas terem uma idéia dos custos envolvidos.

Perceba que hoje qualquer servidorzinho pé de boi, vem com 2 CPUs quadricore, então seu custo inicial vai para 2 servidores com 2 CPUs cada 280.600 DOLARES, se você calcular um dolar bonzinho de R$1.88 isso chega a mais de R$500.000 - MEIO MILHÃO DE REAIS. É uma boa bagatela não é?

[1] https://shop.oracle.com/pls/ostore/f?p=ostore:product:3186357635435959::NO:RP,3:P3_LPI,P3_PROD_HIER_ID:4509693291561805719977%2C4510005237031805720017

Outra coisa, não existe isso de uma empresa que usa SOA pode pagar por SOA, SOA não é um produto, isto não é a mesma coisa do cara poder usar um Terno Armani ou ter uma Ferrari, SOA é apenas um modelo de Arquitetura que preve reuso e foco no negócio em resumo.

Mais uma vez, aproveite seu feriado, descanse, vá ao parque… Faça algo de legal para você, você vai ganhar muito mais

…

Olá Ricardo, primeiramente queria parabenizá-lo pelo post, excelente.

Bom, como é muito grande, vamos por partes:

Criei vários Proxy Services nele baseados tanto em JMS, SOAP quanto em T3 (Protocolo do AquaLogic DSP) e estes proxies eram front-ends de diversos Business Services que usavam a genial (porém questionável) implementação de Custom Transport e Flow Control do ESB para mediação de serviços.

Custom Transport pra mim é uma coisa bem bacana que o produto possui. É uma SDK que permite à empresa estendê-lo à sua necessidade para integrá-lo com seu software legado, escrevendo um protocolo totalmente novo. Aqui eu poderia escrever um protocolo pra conversar com SAP e à partir desse momento, para minha equipe de desenvolvimento, isso fica encapsulado num wizzard. IMHO - Acho o recurso bacana não sei o porque tiveram que usar uma implementação de Custom, mas seria legal detalhar os problemas que teve, até para base de experiência :-).

Flow Control é a orquestração-coreografia, e não entendi o pq questionável, já que é um dos melhores recursos da ferramenta.

Quanto a probelmas com o produto e sua experiência relatada na OI, eu passei por um problema de estouro de memória com o mesmo na versão 2.6, pelo simples fato de na época o produto não trabalhar com streaming. Na época até conversei com um dos engenheiros do produto, já que internamente usavam a API Sax mas não haviam exposto a feature stream da mesma. Logo em seguida liberam um patch com a feature.

PS: Aqui descobri mediante à ferramenta de profiler e decompilei algumas classes do produto por curiosidade.

Aqui vou discordar de você, pois usabilidade é o que faz a produtividade de uma equipe ser completamente diferente. Como mencionei. Como você conhece o produto, posso citar sobre o MFL Builder por exemplo, para construção de um layout TXT para sua posterior conversão em XML e ferramenta XQuery que o produto possui, pois de forma gráfica isso se torna simples.

Mesmo com toda essa facilidade, o tempo de desenvolvimento da solução de extrato das faturas do Grupo STP, só nessa parte do mapeamento levou quase 1 semana. Fico imaginando sem tais facilidades e isso representa custo também ao cliente.

Quando falamos em implementação de alguns EAI patterns como - Message Translator, Normalizer, Claim Check, Content Enricher (esse último com componente de dados) de forma simples, o desenvolvedor consegue fazê-lo à partir de uma IDE com apoio de Tools com até controle da expressão, isso se torna um ganho.

Na versão 3 inclusive já vem outros patterns como SplitJoin pré-prontos para serem apenas aplicados.

Aqui quero enfatizar que a BEA sempre esteve à frente da Sun e da própria Oracle em concorrências onde tive oportunidade de participar, exatamente porque possui essa facilidade ao desenvolvedor.

Aqui vou discordar, pois lock-in todas essas soluções possuem. Se você desenvolver para o Mule e quiser o usar o FuseESB (outro excelente), terá que refazer a implementação.

Para algumas empresas de grande porte este é o ponto que as fazem optar por “bandeiras” como RedHat, Oracle, IBM; pois sabem quem está por trás do produto, sua evolução e garantias.

Então o desenvolvedor vai escolher a quem quer ficar “amarrado”, não tem jeito. :roll:

Edgar, o custo é altíssimo mesmo. O que os CIOS argumentam é : "Quanto custa minha operação parada ? " Se a operação de uma corretora de valores para 1 dia, qual o tamanho do prejuízo ? Por isso a decisão se torna muitas vezes política, pois eles podem subir e ir à Oracle, IBM e tratar disso num outro patamar e resolver a questão.

Já vi clientes terem contratos pesados com o player e o mesmo deslocar um batalhão de gente para sanar o problema…

Não estou advogando em causa de players, só estou fazendo o papel do advogado do diabo aqui para ponderarmos os porquês de algumas decisões que não concordamos, mas não sou esquerdista. Acredito que o software que resolve uma questão de grande importância, pode ser sim cobrado, afinal é uma das maneiras de vermos melhorias constante.

Acho que não tem melhor exemplo que o grandioso Adobe Photoshop que hoje na versão CS4 é imbátivel - Tentando terminar o site aqui e fiz o layout com o mesmo …bão pra cacete, vale cada centavo !!

asaudate:

Pessoal,

Estava procurando por algum gráfico, ou comparação (tipo do Gartner) para embasar meu posicionamento, quando me deparei com este link: http://www.guors.com.br/documentos_2007/ApresentacaoSOA_GUORS.pdf

Este PDF foi elaborado pelo Grupo de Usuário Oracle do RS (GUORS).

Trata-se de uma explicação de qual é a estratégia SOA. Até aí, tudo bem… até chegar na penúltima página, onde ele mostra a Red Hat como cliente do ORACLE SOA. Achei, no mínimo, estranho!!

(Acho que todos aqui sabem que a Red Hat comprou a JBoss, que tem sua própria plataforma SOA).

Alguém aí sabe dizer se é verídico, se a Red Hat realmente é cliente da Oracle neste sentido?

Esse pdf esta escrito que SOA é um tema em evidência, documento bem velhinho esse ne?

Outra fase interessante sugere um papel para SOA no ano de 2015!

“Até 2015, SOA transformará o software de fator inibidor para a condição de agente de transformação nos processos de negócios. A SOA levará as vendas de pacotes aplicativos a se transformarem em subscrição de serviços. Transformará, ainda, as suites monolíticas em aplicações compostas. - Gartner”

Bom, nem é preciso dizer que SOA como promessa não chegou nem a 2010, quanto mais 2015. A previsão do gartner é praticamente certa, só errou na tecnologia utilizada. Não é SOA que vai transformar os processos de negócios, e sim a web + cloud computing.

O post anterior não tem nada a ver com o topico, afinal o autor la no inicio queria treinamento pra ESB né mesmo, mas como o tópico virou briga entre fornecedores achei que não iam se importar.

Só cuidado com a Oracle, se deixar ela te leva até as cuecas!

Kenobi,

Primeiro vou responder suas perguntas … depois passo para a exploração dos pontos de vista discordados

“Acho o recurso bacana não sei o porque tiveram que usar uma implementação de Custom, mas seria legal detalhar os problemas que teve, até para base de experiência”

Na época, parte do processo de negócio requeria que algumas informações do Siebel fossem recuperadas durante o processamento da mensagem, pois esta deveria ser “enriquecida” com detalhes sobre o cliente que iriam sustentar decisões na cadeia de processamento adiante. Tentamos utilizar o conector do Siebel que a própria Oracle fornece, mas algumas questões de desempenho foram relevantes, o servidor Siebel não estava aguentando as requisições enviadas a ele (a partir do conector próprio) pois o número de requisições planejadas para o servidor do Siebel eram inferiores as chamadas enviadas pelo AquaLogic ESB. Ai tivemos que criar um Custom Transport para fazer esse “Message Enrichment”. Quanto a esse ponto, tudo ocorreu bem até, o SDK é muito simples de usar e funciona bem quando você adota as recomendações da BEA.

“Flow Control é a orquestração-coreografia, e não entendi o pq questionável, já que é um dos melhores recursos da ferramenta”

Você sabe o que são trade-offs? Quando você projeta um software, a sua maior preocupação como projetista / arquiteto de software é mensurar, avaliar e acomodar o maior número possível de requisitos não funcionais da solução. Você deve conhecer os RNF mais clássicos portanto não vou citá-los aqui (na duvida consulta a ISO 9126), e deve saber também que, em qualquer projeto de software médio ou grande, RNF conflitam. Performance muitas das vezes conflita (em termos de peso e aderência) com interoperabilidade assim como facilidade no desenvolvimento (em tempo de projeto) conflita com escalabilidade da aplicação em tempo de execução. Dito isso, qual meu ponto ao afirmar sobre ser questionável o recurso de orquestração da ferramenta?

Como disse no cenário, ao originalmente optarmos por adotar esse “poderoso” recurso do AquaLogic em pró de estimular maior produtividade no desenvolvimento (que concordo com você, é bem produtivo), acabamos nos adentrando num problema de desempenho que, para ser solucionado, tivemos que abrir mão da produtividade em pró da performance, criando uma série de Java Callouts para os estágios (você conhece este termo né ;-)) mais complexos. Como projetistas, temos sempre que fazer bom uso dos RNF dos usuários, mas devemos saber quando abrir mão de certos RNF em pró de outros. Na época, a dosagem de peso se deu em maior quantidade para a performance, e nem tanto para a produtividade. Produtividade é importante? Claro que sim! Se você é uma fábrica de software por exemplo, fazer software mais rápido significa faturar mais horas do que as negociadas com o cliente, e isso é bom com certeza. Mas as decisões arquiteturais devem balizar muito mais a qualidade da aplicação do que a qualidade do desenvolvimento da aplicação. Quando ambos são possíveis, ÓTIMO! Mas quando não são, temos que sacrificar um pelo outro.

Como dica, recomendo fortemente a leitura do livro “Evaluating Softwares Architectures”, criado pela equipe do SEI, que explica, entre outras coisas, um método de avaliação de RNF chamado de ATAM, sigla de “Architecture Trade-Off Method Analisys”. Na época, meu caro Kenobi, usei o bom senso praticado pelo ATAM para decidir sacrificar o recurso. E como consequência da experiência em questão, criei esta opnião sobre o recurso visual da ferramenta: Ela é muito legal e trás produtividade, mas ela trás consigo uma série de problemas técnicos que devem ser corretamente avaliados. XSLT é um recurso poderoso, mas é caro em termos de processamento. E infelizmente é a estratégica técnica que está por trás do editor visual. Hoje, na versão 3.0 do Oracle Service Bus, existe a forma de lidar com esta limitação técnica, que é usar implementações alternativas de XML parsing baseadas em SAX e não em DOM, assim como compreensão de XML baseado em Stax. Em suma, quando eu avalio uma ferramenta, eu não tenho comigo somente a impressão inicial que me vem aos olhos, eu avalio também as consequências da aplicação de uma dada tecnologia. Com base nisso, crio minhas opniões. Ou seja, concordo com você quanto a produtividade do recurso, mas quando ponderado com demais RNF, não tenho tanta certeza quanto a importância do mesmo

“Aqui vou discordar de você, pois usabilidade é o que faz a produtividade de uma equipe ser completamente diferente”

Como mencionei antes, produtividade é sim algo muito importante, mas quando temos outras prioridades a serem avaliadas, eu coloco a produtividade como o item de menor prioridade pois me concentro nos detalhes da aplicação. Salvo que eu esteja num projeto com prazo curto e um gerente de projetos na minha cola me ligando num sábado as 17:30 pra saber como estão os testes unitários da entrega da próxima iteração, eu não considero tempo de desenvolvimento e produtividade como algo mais importante que os demais RNF clássicos. Mas assim cara, eu respeito a sua opnião se quiser discordar, de boa

“Aqui quero enfatizar que a BEA sempre esteve à frente da Sun e da própria Oracle em concorrências onde tive oportunidade de participar, exatamente porque possui essa facilidade ao desenvolvedor.”

Concordo em gênero, número e grau. A BEA é (era) sem dúvida uma empresa de middleware respeitável

“Aqui vou discordar, pois lock-in todas essas soluções possuem. Se você desenvolver para o Mule e quiser o usar o FuseESB (outro excelente), terá que refazer a implementação.”

Você está analisando e assumindo vendor lock-in apenas pelo prisma da tecnologia

Concordo que se você começar a desenvolver um projeto no JBoss ESB … depois que quiser trocar de ESB (por alguma razão plausível) será um duro parto migrar para outro ESB. Em minha experiência isso é quase impossível. Fatalmente você terá que reescrever a solução toda, devido a features intrínsicas de cada produto. Isso é um cenário perceptível mesmo no mundo dos Application Servers, onde a premissa do JEE “garante” interoperabilidade entre os fornecedores, mas sabemos que na prática, não é bem assim. No mundo dos ESBs, isso se torna mais verdade ainda. Concordo com você, sob este prisma técnico

Mas meu caro Kenobi, vendor lock-in deve ser medido também pelo prisma de investimento. O modelo baseado em licenças lhe priva do direito de optar por uma versão do produto que não seja baseada em licenças. Se você inicia um projeto usando Oracle Service Bus e por algum motivo você não poderá mais continuar pagando suas licenças (que como o Edgar citou, são caras de fato) sua única opção é REESCREVER a solução em outro ESB. E isso significa PERDA de investimento. E olha que todo CEO quer ter ROI, ou seja, o retorno do mesmo ou mais que o investimento. Imagina ele não ter isso e pior, efetivamente perder o investimento feito. Os custos de mão de obra investidos (os salários dos programadores) e as licenças compradas vão por água abaixo.

Agora se você adota uma iniciativa baseada em open-source, digamos por exemplo, investindo no Mule (vou até esquecer por hora o JBoss ESB para isso não virar de fato uma discussão sobre fabricantes), e na hora de colocar o projeto em produção, por algum motivo, você não pode | não quer investir no suporte enterprise, você AINDA têm a chance de manter o investimento usando a tecnologia oriunda da comunidade. As horas dos programadores serão justificadas ainda, e nenhum custo com licença teve que ser perdido. E acima de tudo, a expectativa do CEO que investiu no projeto ainda poderá ser suprida, ainda terá chances dele recuperar no mínimo o investimento feito, ou, como muitos CEOs querem, recuperar bem mais que o investimento feito.

E esta é a beleza do mundo open-source, a possibilidade de você ter possibilidades A opção a tecnologia e ao conhecimento é um direito de todos, e a filosofia open-source estimula isso, e é sustentada por iniciativas e investimentos por todo globo, desde pessoas altruístas que gostas de compartilhar o conhecimento, assim como empresas que fomentam e investem no open-source como Apache, IBM, Ericsson, Red Hat entre outros.

Caramba, este thread está ficando bem legal mesmo, mas está se distanciando um pouco do seu título. Será que dá pra mudar o título do thread ou criar outro? GUJMasters?

Cordialmente,

Ricardo Ferreira
http://architecture-journal.blogspot.com

Kenobi:

Edgar, o custo é altíssimo mesmo. O que os CIOS argumentam é : "Quanto custa minha operação parada ? " Se a operação de uma corretora de valores para 1 dia, qual o tamanho do prejuízo ? Por isso a decisão se torna muitas vezes política, pois eles podem subir e ir à Oracle, IBM e tratar disso num outro patamar e resolver a questão.

Já vi clientes terem contratos pesados com o player e o mesmo deslocar um batalhão de gente para sanar o problema…

Não estou advogando em causa de players, só estou fazendo o papel do advogado do diabo aqui para ponderarmos os porquês de algumas decisões que não concordamos, mas não sou esquerdista. Acredito que o software que resolve uma questão de grande importância, pode ser sim cobrado, afinal é uma das maneiras de vermos melhorias constante.

Acho que não tem melhor exemplo que o grandioso Adobe Photoshop que hoje na versão CS4 é imbátivel - Tentando terminar o site aqui e fiz o layout com o mesmo …bão pra cacete, vale cada centavo !!

Você está corretíssimo, e é por isso que a Red Hat oferece a possibilidade de cobrar pelo suporte, para que ela seja vista como um player de mercado, e não como um bando de amadores tentando ser Che Guevaras do Software. Quando a Red Hat cobra pelo suporte, todo e qualquer cliente tem exatamente esta possibilidade: “De escalar o suporte não só para uma empresa que tem um time preparado para atender, mas também até de se valer de seus direitos previstos em CONTRATO”.

Muito obrigado pela resposta, ela só embasa o modelo de negócios que praticamos que é: “Não vendemos licença apenas suporte”, a diferença é que essas empresas que você citou, nós já substituimos no ano de 2009 um grande número de cliente frustrado com os tais “big players”, e que hoje estão satisfeitíssimos em obter os benefícios de não pagar licenças, afinal nosso software não tem custo de aquisição e só suporte para aqueles que querem, e é exatamente esta pergunta que nosso time faz em clinete: “Você usa as versões .ORG, mas assim você não terá garantia… Quanto custa cada hora do seu ambiente parado?”. Todo o software pára, proprietário ou aberto.

Nosso valor de solução, que é o suporte representa uma economia de 70 a 80% de economia de aquisição, isto faz com que qualquer cliente gere uma economia, e com esse montante salvo, por exemplo, possa contratar empresas como a sua (SOAExpert), para adquirir conhecimento e educação, isso não é legal?

Então é por isso que eu continuo insistindo, não é porque o Software é caro que ele é bom, isso é uma forma retrograda de pensar. Nós queremos é que em nosso mercado, nós possamos fazer com que empresas reduzam seu custo sim, e que as pessoas possam ter sua vida melhorada, com maior educação, com melhores salários, com melhores ambientes, ao invés de ter que pagar uma fortuna por um software que com certeza poderia ter uma alternativa de custo mais acessível e estratégico.

Obrigado pela sua colocação,

mochuara:

asaudate:

Pessoal,

Estava procurando por algum gráfico, ou comparação (tipo do Gartner) para embasar meu posicionamento, quando me deparei com este link: http://www.guors.com.br/documentos_2007/ApresentacaoSOA_GUORS.pdf

Este PDF foi elaborado pelo Grupo de Usuário Oracle do RS (GUORS).

Trata-se de uma explicação de qual é a estratégia SOA. Até aí, tudo bem… até chegar na penúltima página, onde ele mostra a Red Hat como cliente do ORACLE SOA. Achei, no mínimo, estranho!!

(Acho que todos aqui sabem que a Red Hat comprou a JBoss, que tem sua própria plataforma SOA).

Alguém aí sabe dizer se é verídico, se a Red Hat realmente é cliente da Oracle neste sentido?

Esse pdf esta escrito que SOA é um tema em evidência, documento bem velhinho esse ne?

Outra fase interessante sugere um papel para SOA no ano de 2015!

“Até 2015, SOA transformará o software de fator inibidor para a condição de agente de transformação nos processos de negócios. A SOA levará as vendas de pacotes aplicativos a se transformarem em subscrição de serviços. Transformará, ainda, as suites monolíticas em aplicações compostas. - Gartner”

Bom, nem é preciso dizer que SOA como promessa não chegou nem a 2010, quanto mais 2015. A previsão do gartner é praticamente certa, só errou na tecnologia utilizada. Não é SOA que vai transformar os processos de negócios, e sim a web + cloud computing.

Mas foi dito aqui sim, que no passado, antes da compra da JBoss a Red Hat usava algumas coisas para integração da Oracle, bem como algumas coisas de ERPs que foram “DOADOS”, afinal por mais que muitos pensem que não, a Red Hat é uma empresa normal, presente em cerca 35 países, e só este fato já faz com que sejamos sérios candidatos a integração, já que temos operação de vendas, contabilidade, pessoas etc… E cada país com seu detalhe…Ou vc acha que é simples explicar pros americanos que todo o ano os salários CLT aumentam de acordo com o dissídio do sindicato :).

Mais uma vez, SOA não é produto, o modelo arquitetural de SOA, eu já vi numa Telco, que tem isso desde 1996, e foi implementado com Sockets e C++.

Esse tema não deveria gerar polemica, até porque o que falamos aqui, nos embasamos em fatos, e não em achometros, acredito que ele já ultrapassou a expectativa de resposta da pessoa que começou o tópico.

Infelizmente, sempre que algo que venha aqui que possa gerar confusão na cabeça das pessoas, é nosso papel tentar ajudar com fatos, e não com apenas com opiniões sem base.

Quer dar o nome de WOA ? Web Orientend Architecture como o Anne Thomas - Burton Group, OK ! O Acrônimo muda, mas o conceito é exatamente o mesmo. SOA não está atrelado à SOAP + WSDL como o Edgar mencionou no seu exemplo. REST é SOA também, acredite se quiser

Edgar e Ricardo, pra fechar a questão de players, eu acredito que a RedHat-JBoss vem fazendo um excelente trabalho, estando em algumas áreas até em nível superior como os produtos que citei, pricipalmente o BRMS que espanca o da Oracle, e a IBM esperta, foi e comprou a iLOG

Concordo com o ponto de vista de vendor lock-in também está inerente aos negócios, mas acho que o principal medo dos CIOS é investir numa solução de uma companhia completamente desconhecida, que não se sabe como é o nível do suporte e nem se ela vai estar de pé daqui a um ano, caso da MuleSoft por exemplo.

Infelizmente nós técnicos podemos somente opiniar sobre qual ferramenta gera melhor resultado, ou possui mais features interessantes, mas quem bate o martelo tem a responsabilidade sobre o dinheiro investido, mesmo que isso não esteja atrelado à licenças, mas refazer uma aplicação ou “PARAR” o ambiente enquanto o refactoring fica pronto pode custar o cargo dele no mínimo.

A RedHat é uma empresa que está num outro nível, por isso eu argumentei com o Ricardo sobre OpenSource. Manter aquele código internamente para muitas companhias é impossível, até por questões técnicas dos profissionais, sem know-how para tal, por isso não generalizo à aderência à OpenSource.

Um exemplo bem bacana disso é o Spring e a SpringSource, que com a VMWare por trás, acaba ganhando muita confiabilidade para o mercado e principalmente, junto aos executivos.

PS: Pra mim seria infinitamente melhor se a empresa escolhesse um OpenSource, pois players normalmente já vêem com pacotes prontos e curso pra eles sempre é commodity :? Normalmente preciso brigar muito para provar o valor do meu treinamento, coisa que nem sempre é fácil quando se tem um sem custo em mãos.

PS2: Fazia tempo que não participava de uma Thread tão bacana aqui no GUJ, fiquei bastante feliz com o nível da discussão aqui

Quer dar o nome de WOA ? Web Orientend Architecture como o Anne Thomas - Burton Group, OK ! O Acrônimo muda, mas o conceito é exatamente o mesmo. SOA não está atrelado à SOAP + WSDL como o Edgar mencionou no seu exemplo. REST é SOA também, acredite se quiser

Não. WOA é apenas mais um acrônimo que não significa nada de fato, assim como SOA, serve apenas para enfeitar o vocabulario daqueles que só sabem falar ao invés de produzir. Deixe isso para os blogueiros desse tal de Buton Group.

Pode ser que SOA não esteja atrelado a SOAP + WSDL na teoria (na prática, em 100% das vezes, é sim!). Mesmo assim, isso não é argumento pra dizer que SOA seja igual a REST que eu saiba… (e se SOA = REST qual o sentido da existência de WOA?)

Alias, nem falei em REST, e sim, simplesmente sistemas baseados na web. Só falta falar que SOA é baseado na web tb ne?

Esse tópico já deu pra mim, não quero ficar falando de quem já morreu.

É por essas e outras que não dá mais pra entrar no GUJ. Eu juro que estou perdendo a vontade de escrever por aqui, assim como outros tantos que nunca mais vimos e que agregavam muitíssimo às discussões.

Quer dar o nome de WOA ? Web Orientend Architecture como o Anne Thomas - Burton Group, OK ! O Acrônimo muda, mas o conceito é exatamente o mesmo. SOA não está atrelado à SOAP + WSDL como o Edgar mencionou no seu exemplo. REST é SOA também, acredite se quiser

Não. WOA é apenas mais um acrônimo que não significa nada de fato, assim como SOA, serve apenas para enfeitar o vocabulario daqueles que só sabem falar ao invés de produzir. Deixe isso para os blogueiros desse tal de Buton Group.

Pode ser que SOA não esteja atrelado a SOAP + WSDL na teoria (na prática, em 100% das vezes, é sim!). Mesmo assim, isso não é argumento pra dizer que SOA seja igual a REST que eu saiba… (e se SOA = REST qual o sentido da existência de WOA?)

Alias, nem falei em REST, e sim, simplesmente sistemas baseados na web. Só falta falar que SOA é baseado na web tb ne?

Esse tópico já deu pra mim, não quero ficar falando de quem já morreu.

O Kenobi não disse que SOA é igual a REST, ele disse que SOA também é REST. Na verdade, um grande conjunto de conceitos entra como SOA, e acho que nem vale a pena discutir isso nesta thread. Mas, sim, SOA também pode ser baseado na web.

Agora, quanto à “morte” de SOA… sua opinião. Acho que se SOA estivesse morto, não haveria eu, o Kenobi, o Edgar Silva, o Ricardo Ferreira, além de tantos outros, defendendo essa tecnologia.

[]´s

mochuara:

Outra fase interessante sugere um papel para SOA no ano de 2015!

“Até 2015, SOA transformará o software de fator inibidor para a condição de agente de transformação nos processos de negócios. A SOA levará as vendas de pacotes aplicativos a se transformarem em subscrição de serviços. Transformará, ainda, as suites monolíticas em aplicações compostas. - Gartner”

Bom, nem é preciso dizer que SOA como promessa não chegou nem a 2010, quanto mais 2015. A previsão do gartner é praticamente certa, só errou na tecnologia utilizada. Não é SOA que vai transformar os processos de negócios, e sim a web + cloud computing.

Cloud Computing e SaaS são apenas mais dois dos motivos para se aplicar SOA, dessa vez corretamente.

Ou enxerga uma melhor solução para, por exemplo, implementação de NF-e?

Quem viver verá…

Falar nisso…

http://www.infoq.com/articles/cloud-soa-enterprise-linthicum;jsessionid=A6F327F02301C27FD31A210FC5A87F0A

Pessoal,

Boa tarde!

Estou fazendo um projeto para um cliente, onde iremos orientar a implementação de um ESB para que seja feita a integração dos sistemas legados com o SAP e seus processos.

Eles estão indo para o lado do TIBCO e queremos apresentar o SAP PI para que eles possam escolher o que mais atende eles.

O que eu estou precisando no momento, é algum tipo de material ou comparativo entre ambos, onde eu possa ver as vantagens de os prós de cada um deles. E se possível, qual o tipo de arquivos suportados na integração.

Agradeço muito a ajuda de vocês.

Abs e obrigado.