<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: À procura de uma maneira produtiva de trabalhar com web services SOAP</title>
	<atom:link href="http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/feed/" rel="self" type="application/rss+xml" />
	<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/</link>
	<description>Open source, Java, web, python, client-side e outros hobbies :)</description>
	<lastBuildDate>Wed, 08 Feb 2012 05:30:54 -0200</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: blpsilva</title>
		<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/comment-page-1/#comment-1514</link>
		<dc:creator>blpsilva</dc:creator>
		<pubDate>Mon, 05 Jan 2009 22:43:24 +0000</pubDate>
		<guid isPermaLink="false">http://brunopereira.org/?p=262#comment-1514</guid>
		<description>Oi Rodrigo, obrigado por compartilhar também esta sua experiência. Eu não tive tempo nas últimas semanas de prosseguir muito nos experimentos, mas pretendo em breve retomar meus testes usando o Glassfish + Metro em conjunto com o Mule e talvez o Service Mix.

O Mule e o Service Mix têm propostas um pouco distintas, e também quero avaliar melhor as características de cada um. Se você tiver observações interessantes sobre os 2, terei todo o interesse em saber.

[]s</description>
		<content:encoded><![CDATA[<p>Oi Rodrigo, obrigado por compartilhar também esta sua experiência. Eu não tive tempo nas últimas semanas de prosseguir muito nos experimentos, mas pretendo em breve retomar meus testes usando o Glassfish + Metro em conjunto com o Mule e talvez o Service Mix.</p>
<p>O Mule e o Service Mix têm propostas um pouco distintas, e também quero avaliar melhor as características de cada um. Se você tiver observações interessantes sobre os 2, terei todo o interesse em saber.</p>
<p>[]s</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rodrigo Carvalho Silva</title>
		<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/comment-page-1/#comment-1508</link>
		<dc:creator>Rodrigo Carvalho Silva</dc:creator>
		<pubDate>Mon, 05 Jan 2009 14:46:41 +0000</pubDate>
		<guid isPermaLink="false">http://brunopereira.org/?p=262#comment-1508</guid>
		<description>Muito bom artigo. Recentemente fiz a mesma pesquisa no trabalho e obtive o mesmo resultado: Netbeans + Metro. O Metro contém o JAX-WS RI internamente e o WSIT, para WS-Secutiry e WS-Coordination. Muito completo e produtivo. Fora esta parte de testes, que você pode tentar usar o soapUI, acho muito melhor do que o BEA Workshop.

Lembrando que tanto o Glassfish quanto o JBoss trabalham com o Metro, ou seja, não é preciso levar nenhuma lib para a aplicação se estiver usando um destes app servers.

Abraço e estou no aguardo da seqüencia deste artigo!</description>
		<content:encoded><![CDATA[<p>Muito bom artigo. Recentemente fiz a mesma pesquisa no trabalho e obtive o mesmo resultado: Netbeans + Metro. O Metro contém o JAX-WS RI internamente e o WSIT, para WS-Secutiry e WS-Coordination. Muito completo e produtivo. Fora esta parte de testes, que você pode tentar usar o soapUI, acho muito melhor do que o BEA Workshop.</p>
<p>Lembrando que tanto o Glassfish quanto o JBoss trabalham com o Metro, ou seja, não é preciso levar nenhuma lib para a aplicação se estiver usando um destes app servers.</p>
<p>Abraço e estou no aguardo da seqüencia deste artigo!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thiago</title>
		<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/comment-page-1/#comment-1448</link>
		<dc:creator>Thiago</dc:creator>
		<pubDate>Tue, 16 Dec 2008 16:53:36 +0000</pubDate>
		<guid isPermaLink="false">http://brunopereira.org/?p=262#comment-1448</guid>
		<description>Exato! O melhor jeito atual eh &quot;escrevendo os schemas e os WSDLs e depois...&quot;. Eh exatamente isso que a gente tava tentando evitar, que voce tenha que se preocupar com XSDs e WSDLs. A ideia era usar EMF no lugar.

Mas concordo que se voce nao precisa modificar o framework, glassfish deve ser suficiente. Mas CXF tem algumas coisas legais tambem, como o Simple Databinding pra fazer prototipos.

[]s</description>
		<content:encoded><![CDATA[<p>Exato! O melhor jeito atual eh &#8220;escrevendo os schemas e os WSDLs e depois&#8230;&#8221;. Eh exatamente isso que a gente tava tentando evitar, que voce tenha que se preocupar com XSDs e WSDLs. A ideia era usar EMF no lugar.</p>
<p>Mas concordo que se voce nao precisa modificar o framework, glassfish deve ser suficiente. Mas CXF tem algumas coisas legais tambem, como o Simple Databinding pra fazer prototipos.</p>
<p>[]s</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blpsilva</title>
		<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/comment-page-1/#comment-1446</link>
		<dc:creator>blpsilva</dc:creator>
		<pubDate>Tue, 16 Dec 2008 01:40:31 +0000</pubDate>
		<guid isPermaLink="false">http://brunopereira.org/?p=262#comment-1446</guid>
		<description>Oi Thiago, obrigado novamente por compartilhar essa sua experiência. Como você falou, também tive a impressão de que a recomendação forte do CXF é o uso do JAXB em vez do Aegis. 

Então se é pra usar JAX-WS com JAXB, prefiro simplesmente usar a implementação de referência que não deixa a desejar em nada em relação ao CXF. Por enquanto continuo achando que a forma mais produtiva de trabalhar com SOAP usando open source é escrevendo os schemas e os WSDLs e depois gerando as classes Java com o JAX-WS/JAXB.</description>
		<content:encoded><![CDATA[<p>Oi Thiago, obrigado novamente por compartilhar essa sua experiência. Como você falou, também tive a impressão de que a recomendação forte do CXF é o uso do JAXB em vez do Aegis. </p>
<p>Então se é pra usar JAX-WS com JAXB, prefiro simplesmente usar a implementação de referência que não deixa a desejar em nada em relação ao CXF. Por enquanto continuo achando que a forma mais produtiva de trabalhar com SOAP usando open source é escrevendo os schemas e os WSDLs e depois gerando as classes Java com o JAX-WS/JAXB.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thiago</title>
		<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/comment-page-1/#comment-1444</link>
		<dc:creator>Thiago</dc:creator>
		<pubDate>Mon, 15 Dec 2008 17:53:05 +0000</pubDate>
		<guid isPermaLink="false">http://brunopereira.org/?p=262#comment-1444</guid>
		<description>Oi,

eu tava usando como implementação de JAX-WS, mas ao invés de usar JAX-B pro binding, tava fazendo serialização em EMF.

Clarificando um pouco. EMF implementa mappings pra XML. Então um modelo Ecore do EMF pode ser visto como um XSD e EMF (de)serializa objetos Java de/para XML. Então, ao invés de encher as suas classes com anotações JAX-B, a idéia era reaproveitar esses mappings do EMF.

Eu cheguei a implementar um proof-of-concept no CXF, criando um novo DataBinding que chamava as classes do EMF pra serializar e de-serializar. Funcionava direitinho, mas eu nunca tive chance de terminar uma implementação robusta.

Quando eu acompanhei a lista cxf-dev, me pareceu que Aegis não era tido como a melhor opção, era somente mantido pra ter compatibilidade para clientes que usavam o Aegis nas implementações antigas. 

[]s</description>
		<content:encoded><![CDATA[<p>Oi,</p>
<p>eu tava usando como implementação de JAX-WS, mas ao invés de usar JAX-B pro binding, tava fazendo serialização em EMF.</p>
<p>Clarificando um pouco. EMF implementa mappings pra XML. Então um modelo Ecore do EMF pode ser visto como um XSD e EMF (de)serializa objetos Java de/para XML. Então, ao invés de encher as suas classes com anotações JAX-B, a idéia era reaproveitar esses mappings do EMF.</p>
<p>Eu cheguei a implementar um proof-of-concept no CXF, criando um novo DataBinding que chamava as classes do EMF pra serializar e de-serializar. Funcionava direitinho, mas eu nunca tive chance de terminar uma implementação robusta.</p>
<p>Quando eu acompanhei a lista cxf-dev, me pareceu que Aegis não era tido como a melhor opção, era somente mantido pra ter compatibilidade para clientes que usavam o Aegis nas implementações antigas. </p>
<p>[]s</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blpsilva</title>
		<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/comment-page-1/#comment-1439</link>
		<dc:creator>blpsilva</dc:creator>
		<pubDate>Sun, 14 Dec 2008 11:00:10 +0000</pubDate>
		<guid isPermaLink="false">http://brunopereira.org/?p=262#comment-1439</guid>
		<description>OI Thiago, obrigado por compartilhar essa sua experiência. Você estava usando o CXF como implementação de JAX-WS ou estava usando ele com o Aegis Databinding?</description>
		<content:encoded><![CDATA[<p>OI Thiago, obrigado por compartilhar essa sua experiência. Você estava usando o CXF como implementação de JAX-WS ou estava usando ele com o Aegis Databinding?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thiago</title>
		<link>http://brunopereira.org/2008/12/08/a-procura-de-uma-maneira-produtiva-de-trabalhar-com-web-services-soap/comment-page-1/#comment-1437</link>
		<dc:creator>Thiago</dc:creator>
		<pubDate>Sat, 13 Dec 2008 20:22:43 +0000</pubDate>
		<guid isPermaLink="false">http://brunopereira.org/?p=262#comment-1437</guid>
		<description>Oi,

eu estive trabalhando um tempo com essas tecnologias e quando tive oportunidade de avaliar, CXF me pareceu a melhor opção (entre glassfish e Axis2), porque o que eu precisava fazer era estender o framework. CXF eh muito melhor documentado e o código eh bem mais modular pra quem quiser criar algo novo.

No meu caso, eu estava trabalhando num projeto chamado Servus, que eh um componente do EMFT no Eclipse ( http://wiki.eclipse.org/Servus ). A idéia era a seguinte. Muita gente que trabalha com Java hoje em dia cria modelos EMF para modelar os dados. EMF gera as classes de dados e tem diversos serviços como reflexão, persistência em arquivos XML, em banco de dados, etc. 

Agora, imagine que você tem esse modelo e gerou as classes, daih você quer expor algum serviço que receba como parâmetro (ou retorne) algum desses tipos. EMF jah tem um mapping pra XSD, então em teoria bastaria você criar um WSDL e apendar o XSD (ou um pedaço dele). Mas os problemas seriam 1) quando você usasse alguma ferramenta JAX-WS pra gerar Java pro seu WSDL, você geraria novas classes pros seus dados (bem parecidas com as que você jah tem), mas nao poderia reusar as que você jah tem 2) você normalmente teria que usar JAX-B bindings, mesmo que EMF jah faca binding de Java pra XML.

Então a idéia era criar um mapping WSDLEMFJava(JAX-WS) em que o código gerado pros client proxies e server skeletons usasse as mesmas classes geradas pelo EMF pra Java, e pudesse aproveitar a serialização do EMF pra fazer o binding. Por isso, eu teria que adicionar um binding pro CXF pra reaproveitar o que o EMF faz. Alem disso, daria pra usar modelos EMF pra modelar os seus serviços.

Infelizmente eu não tive tempo de terminar a implementação do componente, jah que houveram mudanças na IBM que me fizeram ter que mudar de projeto (eles dão funding pro meu doutorado). Toda a estrutura pra ler WSDL, gerar modelos EMF e gerar código esta implementada. Falta somente finalizar as templates pra gerar o código direito. Como disse, não estou podendo trabalhar diretamente nisso, mas se o projeto interessar realmente a alguem, eu posso ajudar a entender o que foi feito, o que ainda tem que ser feito, etc.

Alias, um outro objetivo do projeto era ajudar na migração de serviços baseados em WSDL1.x pra WSDL2, jah que o modelo EMF suportaria ambos.

[]s</description>
		<content:encoded><![CDATA[<p>Oi,</p>
<p>eu estive trabalhando um tempo com essas tecnologias e quando tive oportunidade de avaliar, CXF me pareceu a melhor opção (entre glassfish e Axis2), porque o que eu precisava fazer era estender o framework. CXF eh muito melhor documentado e o código eh bem mais modular pra quem quiser criar algo novo.</p>
<p>No meu caso, eu estava trabalhando num projeto chamado Servus, que eh um componente do EMFT no Eclipse ( <a href="http://wiki.eclipse.org/Servus" rel="nofollow">http://wiki.eclipse.org/Servus</a> ). A idéia era a seguinte. Muita gente que trabalha com Java hoje em dia cria modelos EMF para modelar os dados. EMF gera as classes de dados e tem diversos serviços como reflexão, persistência em arquivos XML, em banco de dados, etc. </p>
<p>Agora, imagine que você tem esse modelo e gerou as classes, daih você quer expor algum serviço que receba como parâmetro (ou retorne) algum desses tipos. EMF jah tem um mapping pra XSD, então em teoria bastaria você criar um WSDL e apendar o XSD (ou um pedaço dele). Mas os problemas seriam 1) quando você usasse alguma ferramenta JAX-WS pra gerar Java pro seu WSDL, você geraria novas classes pros seus dados (bem parecidas com as que você jah tem), mas nao poderia reusar as que você jah tem 2) você normalmente teria que usar JAX-B bindings, mesmo que EMF jah faca binding de Java pra XML.</p>
<p>Então a idéia era criar um mapping WSDLEMFJava(JAX-WS) em que o código gerado pros client proxies e server skeletons usasse as mesmas classes geradas pelo EMF pra Java, e pudesse aproveitar a serialização do EMF pra fazer o binding. Por isso, eu teria que adicionar um binding pro CXF pra reaproveitar o que o EMF faz. Alem disso, daria pra usar modelos EMF pra modelar os seus serviços.</p>
<p>Infelizmente eu não tive tempo de terminar a implementação do componente, jah que houveram mudanças na IBM que me fizeram ter que mudar de projeto (eles dão funding pro meu doutorado). Toda a estrutura pra ler WSDL, gerar modelos EMF e gerar código esta implementada. Falta somente finalizar as templates pra gerar o código direito. Como disse, não estou podendo trabalhar diretamente nisso, mas se o projeto interessar realmente a alguem, eu posso ajudar a entender o que foi feito, o que ainda tem que ser feito, etc.</p>
<p>Alias, um outro objetivo do projeto era ajudar na migração de serviços baseados em WSDL1.x pra WSDL2, jah que o modelo EMF suportaria ambos.</p>
<p>[]s</p>
]]></content:encoded>
	</item>
</channel>
</rss>

