<?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>Comentarios en: OSGi, un Futuro para SOA?</title>
	<atom:link href="http://www.espaciosoa.net/2008/02/11/osgi-un-futuro-para-soa/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.espaciosoa.net/2008/02/11/osgi-un-futuro-para-soa/</link>
	<description>Un Espacio para el Mundo SOA y BPM</description>
	<lastBuildDate>Thu, 22 Jul 2010 20:27:58 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Por: Manuel</title>
		<link>http://www.espaciosoa.net/2008/02/11/osgi-un-futuro-para-soa/comment-page-1/#comment-70</link>
		<dc:creator>Manuel</dc:creator>
		<pubDate>Fri, 22 Feb 2008 09:53:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.espaciosoa.net/2008/02/11/osgi-un-futuro-para-soa/#comment-70</guid>
		<description>La realidad es que OSGi está siendo adoptado no solo para el middleware de servidor, sino como plataforma de ejecución en plataformas cliente, como nuestros windows, linux, etc. llegando incluso hasta plataformas móviles como Windows Mobile, etc.

Esta evolución permite la creación de cosas, como, por ejemplo, un solo modelo de programación (J2EE) en entornos servidor, ordenador personal y PDA, haciendo que los servlets y jsps corran en estos entornos.

Además el esquema de OSGi, permite una interacción entre distintas aplicaciones hasta ahora no experimentada. Para muestra echad un vistazo al RCP de Eclipse.

Gente como IBM ya empieza a comercializar su Lotus Notes 8 y Sametime, Sinphony (basado en el openOffice), etc con la plataforma RCP por debajo.</description>
		<content:encoded><![CDATA[<p>La realidad es que OSGi está siendo adoptado no solo para el middleware de servidor, sino como plataforma de ejecución en plataformas cliente, como nuestros windows, linux, etc. llegando incluso hasta plataformas móviles como Windows Mobile, etc.</p>
<p>Esta evolución permite la creación de cosas, como, por ejemplo, un solo modelo de programación (J2EE) en entornos servidor, ordenador personal y PDA, haciendo que los servlets y jsps corran en estos entornos.</p>
<p>Además el esquema de OSGi, permite una interacción entre distintas aplicaciones hasta ahora no experimentada. Para muestra echad un vistazo al RCP de Eclipse.</p>
<p>Gente como IBM ya empieza a comercializar su Lotus Notes 8 y Sametime, Sinphony (basado en el openOffice), etc con la plataforma RCP por debajo.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: lacayo</title>
		<link>http://www.espaciosoa.net/2008/02/11/osgi-un-futuro-para-soa/comment-page-1/#comment-69</link>
		<dc:creator>lacayo</dc:creator>
		<pubDate>Tue, 12 Feb 2008 10:31:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.espaciosoa.net/2008/02/11/osgi-un-futuro-para-soa/#comment-69</guid>
		<description>Está claro que el empaquetado y versionado de librerías mediante simples jar, a pesar de haber sido útil todos estos años, ha puesto también de manifiesto muchas carencias.
OSGi da solución a estos problemas, además de ofrecer más funcionalidades, como la carga dinámica de paquetes, etc. Además, lleva ya bastante tiempo en el mercado y es por tanto una especificación madura que, según veo yo, va camino de convertirse en un estándar de facto.
Por otro lado, Sun ha definido una especificación alternativa, Java Module System (JSR 277), prevista para ser lanzada en Java 7. ¿Hasta qué punto tiene eso sentido, cuando OSGi ofrece ya solución a esos problemas? Hay quien espera que al final Sun aproveche lo que ya hay (OSGi) en lugar de crear un nuevo estándar compitiendo absurdamente con una especificación que ha demostrado su solvencia.</description>
		<content:encoded><![CDATA[<p>Está claro que el empaquetado y versionado de librerías mediante simples jar, a pesar de haber sido útil todos estos años, ha puesto también de manifiesto muchas carencias.<br />
OSGi da solución a estos problemas, además de ofrecer más funcionalidades, como la carga dinámica de paquetes, etc. Además, lleva ya bastante tiempo en el mercado y es por tanto una especificación madura que, según veo yo, va camino de convertirse en un estándar de facto.<br />
Por otro lado, Sun ha definido una especificación alternativa, Java Module System (JSR 277), prevista para ser lanzada en Java 7. ¿Hasta qué punto tiene eso sentido, cuando OSGi ofrece ya solución a esos problemas? Hay quien espera que al final Sun aproveche lo que ya hay (OSGi) en lugar de crear un nuevo estándar compitiendo absurdamente con una especificación que ha demostrado su solvencia.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
