XET (Xml Entity Technology)

Suena bien y lo podemos inventar... Lo único que necesitamos es clonar jee5... y listo!

No es tal fácil como suena, pero sería posible.
Digamos: en vez de tener un ejb-jar.xml hacemos la definición de las entidades con schema (XSD) y creamos una persistence-unit con el descriptor.
Por ejemplo, usando un servicio xpcom: EntityManagerFactory.buildEntityManager(name, descriptor) : EntityManager;
De este modo ya tendríamos centralizada la cuestion, y cuando queramos nuevamente el entity manager en cualquier pantalla haríamos: Components.classes["org.xet/entity-manager;1?unit=name"]
.getService(Components.interfaces.xetIEntityManager);
habría que implementar em.persist(); em.createXQuery(); em.merge(); em.remove().... etc.. como decía antes clonar EntityManager.

Habría que responder más cuestiones:

1. Donde estaría la declaración de la clase EJB. Para esto tendríamos dos opciones:

a. Hacemos como el viejo método de j2ee y creamos proxies. A estos los obtendriamos por el entity manager (por un find o un query)

b. Hacemos como el nuevo método de jee5 y dejamos que sean JavaScriptObjects (JSO) simple (el equivalente a un POJO). Lo malo es que nos faltaría el enlace que nos dan los annotations, que JavaScript no tiene. Podríamos permitir que exista un prefijo para los metada y miramos (si existe, porque sería opcional) un __field : donde field es el nombre del campo, que contenga información adicional.

c. Hacemos un mixtura entre j2ee y jee5. Como en sí hay que conocer la estructura, podríamos usar un descriptor xsd, pero no crear el proxy y sí crear ciertos campos con __field, or __className o cosas así, para que el entityManager pueda reconocer a qué entidad tiene que mapear.

2. La transacción no sería fácil ya que en j2ee está dada por el contexto (al ser las entidades proxies, se conocen y se pueden manejar los puntos de entrada y salida). En jee5 está dada por la mecánica de injection, a la que JavaScript ni aspira (quizás ahora con la donación de macromedia, podría ser). En una primera instancia podríamos no implementarla.

Quizás haya que caminar el camino de j2ee desde el comienzo y ver que pasa en el futuro.

persistencia con storage en mozilla

Ahora existe la posibilidad de construir un motor tipo ejb con mozilla. Una utilidad es que esto permitiría que mozilla se convierta en un verdadero cliente de un AS.

Las unidades de persistencia (las podríamos llamar storageunits) deberían ser de dos tipos: de la aplicación y del perfil.

Todo debería arrancar con un servicio, cuando se crea por primera vez el servicio se leen las declaraciones de las entidades. El motor podría usar E4X.

Podríamos usar a modo de jndi el motor de preferencias del mozilla.

Los problemas:

• Anotaciones: no existen, pero podríamos hacer algo del ese tipo con e4x
• Contexto: habría que construir un motor transaccional (basado en servicios)
• Proxy: en ejb2 se usan proxies de las entidades para capturar los sets y gets...
• Interceptors: podemos hacer esto usando watch y unwatch de las propiedades de los objetos.

problemas futuro: si realmente queremos que esto se integre en forma remota a un AS, entonces hay que resolver el problema de los webservices. Con E4X se puede reimplementar el motor de mozilla.

Estamos en proceso con ARCpy y el software de la vaquita.
Su grupo: arcpy@googlegroups.com

Único y maravilloso... total y completamente nuevo... soy yo ¡El de siempre!
He llegado. Y veremos que va surgiendo con este blog.
En nuestra primera entrada me mando un saludo.