Translate
viernes, 13 de diciembre de 2019
Introducción a Jakarta NoSQL
EE4J no se detiene y ha aprobado el proyecto Jakarta NoSQL es una especificación en Jakarta EE para ayudar a los desarrolladores a crear aplicaciones de nivel empresarial utilizando tecnologías Java y NoSQL. JNoSQL es la implementación de referencia de Jakarta NoSQL, que proporciona un conjunto de APIs y una implementación estándar para una serie de bases de datos NoSQL, como Cassandra, MongoDB, Neo4J, CouchDB y OrientDB, entre otras.
Jakarta NoSQL consiste en una capa de comunicación (Diana), que extrae un conjunto de APIs diseñadas para definir la comunicación con las bases de datos NoSQL. Contiene cuatro módulos de acuerdo con cada tipo de base de datos NoSQL: clave-valor, familia de columnas, documento y grafo; y una capa de mapeo (Artemis), que proporciona una serie de APIs para ayudar a los desarrolladores a integrar aplicaciones Java con bases de datos NoSQL. La capa de mapeo se basa en anotaciones y utiliza tecnologías como CDI y Bean Validation, lo que facilita el uso de los desarrolladores. Es posible comparar la capa de mapeo con JPA / Hibernate en el mundo tradicional RDBMS.
La definición de una entidad es relativamente similar a JPA. Básicamente usa @Entity, @Id, @Column y así sucesivamente:
@Entity
public class Person {
@Id
private long id;
@Column
private String name;
@Column
private List phones;
}
Los repositorios se parecen a los repositorios de Spring Data, donde se extiende un Repositorio <T, ID>:
public interface PersonRepository extends Repository {
List<Person> findByName(String name);
Stream<Person> findByPhones(String phone);
}
Sin embargo, a partir de este momento, las cosas cambian, ya que las dependencias de Maven cambian de acuerdo con el tipo de base de datos NoSQL que se usa, así como la configuración y cómo inyectamos el repositorio en nuestros servicios.
Veamos 2 ejemplos, uno utilizando una base orientada a columna y otra documental. Importamos librerías :
<dependency>
<groupId>org.jnosql.artemis</groupId>
<artifactId>artemis-column</artifactId>
<version>0.0.9</version>
</dependency>
<dependency>
<groupId>org.jnosql.diana</groupId>
<artifactId>cassandra-driver</artifactId>
<version>0.0.9</version>
</dependency>
Veamos el manager de nuestra base orientada a columna :
@ApplicationScoped
public class ColumnFamilyManagerProducer {
private static final String KEY_SPACE = "developers";
private ColumnConfiguration<> cassandraConfiguration;
private ColumnFamilyManagerFactory managerFactory;
@PostConstruct
public void init() {
cassandraConfiguration = new CassandraConfiguration();
managerFactory = cassandraConfiguration.get();
}
@Produces
public ColumnFamilyManager getManagerCassandra() {
return managerFactory.get(KEY_SPACE);
}
}
Y finalmente, un ejemplo de cómo ejecutar algunas inserciones / consultas:
Person person = Person.builder()
.withPhones(Arrays.asList("234", "432"))
.withName("Name")
.withId(id)
.build();
//using ColumnTemplate
ColumnTemplate columnTemplate = container.select(CassandraTemplate.class).get();
Person saved = columnTemplate.insert(PERSON);
System.out.println("Person saved" + saved);
ColumnQuery query = select().from("Person").where(eq(Column.of("id", 1L))).build();
Optional<Person> person = columnTemplate.singleResult(query);
System.out.println("Entity found: " + person);
//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class).select(ofColumn()).get();
Person saved = repository.save(PERSON);
System.out.println("Person saved" + saved);
Optional<Person> person = repository.findById(1L);
System.out.println("Entity found: " + person);
Veamos un ejemplo con una base documental, primero las dependencias:
<dependency>
<groupId>org.jnosql.artemis</groupId>
<artifactId>artemis-document</artifactId>
<version>0.0.9</version>
</dependency>
<dependency>
<groupId>org.jnosql.diana</groupId>
<artifactId>mongodb-driver</artifactId>
<version>0.0.9</version>
</dependency>
Luego el manager :
@ApplicationScoped
public class DocumentCollectionManagerProducer {
private static final String COLLECTION = "developers";
private DocumentConfiguration configuration;
private DocumentCollectionManagerFactory managerFactory;
@PostConstruct
public void init() {
configuration = new MongoDBDocumentConfiguration();
Map<String, Object> settings = Collections.singletonMap("mongodb-server-host-1", "localhost:27017");
managerFactory = configuration.get(Settings.of(settings));
}
@Produces
public DocumentCollectionManager getManager() {
return managerFactory.get(COLLECTION);
}
}
y usamos el manager :
Person person = Person.builder()
.withPhones(Arrays.asList("234", "432"))
.withName("Name")
.withId(id)
.build();
//using DocumentTemplate
DocumentTemplate documentTemplate = container.select(DocumentTemplate.class).get();
Person saved = documentTemplate.insert(person);
System.out.println("Person saved" + saved);
DocumentQuery query = select().from("Person")
.where(eq(Document.of("_id", id))).build();
Optional<Person> personOptional = documentTemplate.singleResult(query);
System.out.println("Entity found: " + personOptional);
//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class)
.select(ofDocument()).get();
repository.save(person);
List<Person> people = repository.findByName("Name");
System.out.println("Entity found: " + people);
repository.findByPhones("234").forEach(System.out::println);
Y listo!
Ustedes pensaran que feo tener diferentes modos de guardar y recuperar datos de nuestros almacenes de datos sql pero tengamos en cuenta que es el único camino para aprovechar al máximo sus particularidades y normalmente elegimos estas bases por sus particularidades.
Dejo link: https://github.com/eclipse-ee4j/nosql
jueves, 8 de marzo de 2018
Java EE se transforma en Jakarta EE
Me hago eco de esta noticia (medio tarde)
Dado que oracle quiere soltar Java EE pero no quiere soltar el nombre Java por lo tanto ahora se va a llamar Jakarta EE.
Y varios proyectos han cambiado nombres dado este cambio. Ahora que Java EE es Jakarta EE, Glassfish pasa a ser Eclipse Glassfish, Java Community Process (JCP) pasa a llamarse Eclipse EE.next Working Group (EE.next), y Oracle development management ahora es Eclipse Enterprise for Java (EE4J) y Project Management Committee (PMC).
Y eso es toda la noticia, bien no se como estirar más ...
Dejo link:
miércoles, 13 de septiembre de 2017
Java EE se mueve a la organización eclipse
Como habíamos dicho en otro post: https://emanuelpeg.blogspot.com.ar/2017/08/java-ee-bajo-una-organizacion-open.html
Según lo que han publicado en el blog de la empresa Oracle, se quiere que el proceso de desarrollo de la especificación Java enterprise edition sea más ágil y responsivo. Por lo tanto se sugiere que sea parte de un fundación open source.
Bueno la Fundación Eclipse resultó seleccionada para albergar el proyecto y plataforma Java EE. La verdad que es una buenisima noticia.
Java EE en las manos de eclipse no creo que gane mayor agilidad pero sin duda va ser más abierto y comunitario.
Github de Java EE : https://github.com/javaee
Dejo link: https://blogs.oracle.com/theaquarium/opening-up-ee-update
http://middlewareblog.redhat.com/2017/09/12/java-ee-moves-to-eclipse/
https://mmilinkov.wordpress.com/2017/09/12/java-ee-moves-to-the-eclipse-foundation/
viernes, 18 de agosto de 2017
Java EE bajo una organización open source??
Bueno, yo pensé que Java EE de Oracle iba a ser totalmente de Oracle pero me equivoque...
Al parecer Oracle no le puede sacar dinero a Java EE y por lo tanto quiere donarlo, jeje... Digo yo.
Según lo que han publicado en el blog de la empresa, se quiere que el proceso sea más ágil y responsivo. Por lo tanto se sugiere que sea parte de un fundación open source.
Para dar un resumen concreto, luego de el desarrollo de Java EE 8, vendrá un licenciamiento más flexible y si la papa quema que la agarre el que quiera.
Dejo link: http://www.zdnet.com/article/oracle-considers-moving-java-ee-to-an-open-source-foundation/
jueves, 4 de agosto de 2016
Modern Java EE Design Patterns By O'Reilly, Gratis !!!
| ||||
| ||||
|
viernes, 8 de noviembre de 2013
GlassFish Commercial Edition ha muerto
Si bien no me afecta mucho la noticia porque nunca he usado Glassfish edición empresarial. Si me da miedo, Oracle no tiene ningun problema en matar un producto si no le va bien. De todas formas no se cuanta participación en la comunidad tiene Oracle.
De igual forma afecta bastante al producto dado que en USA por ejemplo, son de comprar el soporte comercial. Tambien recordemos que Oracle compro la empresa BEA que era dueña del servidor WebLogic y esto se veía venir. Oracle no iba a mantener 3 productos compitiendo entre ellos en el mercado.
La verdad que creo que es un primer paso a la destrucción de un gran producto. Espero que me equivoque.
jueves, 13 de diciembre de 2012
No estamos grande para jugar a la lucha Spring vs JEE??
A raíz de un articulo de InfoQ me quede pensando, cuanto cuesta que spring respete el estándar JEE? Recordemos que Spring nació como un framework que proveía un montón de características para no utilizar JEE. Spring se ha popularizado en la comunidad de programadores en Java al ser considerado como una alternativa y sustituto del modelo de Enterprise JavaBeans. Por su diseño el framework ofrece mucha libertad a los desarrolladores y soluciones muy bien documentadas y fáciles de usar para las prácticas comunes en la industria.
Pero JEE aprendió de sus desaciertos fue acercándose a un modelo más flexible. Y yo veo que con el tiempo se fue springizando. EL GAP que existía entre Spring y JEE es cada vez más pequeño. Cuesta mucho hacerlo nulo? O optar por hacer Spring JEE y otro no JEE?
Si, ya se la respuesta es: "A mi me gusta solo usar tomcat o jety y no quiero usar JBoss o Glashfish". Creo que se puede modularizar y en los servidores solo cargar lo que usamos. Por ejemplo si solo necesito servicios web, jetty. Si necesito servicios web y un servicio como JMS uso jetty + modulo de ActiveQ o el que sea. Hoy en día es como que no existe punto medio o jetty o tomcat o JBoss o otro servidor JEE. Algo super liviano o algo pesado. Por esto también aplaudo a soluciones como TomEE que implementa Java EE 6 Web Profile.
Que opinan matamos a JEE como un estándar cerrado y lo rompemos en cajitas modulares? Hacemos que spring respete ese orden y cumpla el estándar? No estamos grande para jugar a la lucha Spring vs JEE?
miércoles, 14 de noviembre de 2012
Oracle quiere saber tu opinión sobre qué hacer con Java EE 7
Leyendo javahispano y también en infoQ me entere sobre la encuesta que realiza Oracle sobre JEE 7 Me parece un paso importante de Oracle para motivar a la comunidad, dejo el link de la encuesta y las noticias:
https://www.surveymonkey.com/s/javaee7
http://www.infoq.com/news/2012/11/ee7-early-draft-review
http://www.javahispano.org/portada/2012/11/14/oracle-quiere-saber-tu-opinion-sobre-que-hacer-con-java-ee-7.html
martes, 13 de diciembre de 2011
@EJB
domingo, 17 de abril de 2011
Seguridad con JEE
JEE y EJB proveen un conjunto de servicios que los desarrolladores pueden integrar de forma declarativa o programática. Estos servicios incluyen autorización y autenticación.
Autenticación e identificación
La autenticación es comprobar que el usuario sea quien dice ser. En un sistema EJB un usuario es asociado con una identidad segurizada, esta esta lista para ser usada por los EJB. Cuando un cliente invoca un método de un EJB, el servidor pasa la identidad del cliente con la invocación del método. Cuando el contenedor de EJB recibe la invocación valida la identidad del usuario y si este puede invocar el método invocado.
La especificación EJB no indica como se autentica. Aunque esta definido como la seguridad se propaga del cliente al servidor, no esta definido como el cliente obtiene la identidad y la credencial con una invocación EJB, tampoco define como el servidor guarda y obtiene las autenticaciones.
Cuando accedemos a un EJB muchas aplicaciones utilizan la JNDI API, por ejemplo podemos autenticar el acceso a un EJB de este modo:
properties.put(Context.SECURITY_PRINCIPAL, "username");
properties.put(Context.SECURITY_CREDENTIALS, "password");
Context ctx = new InitialContext(properties);
Object ref = jndiContext.lookup("SecureBean/remote");
SecureRemoteBusiness remote = (SecureRemoteBusiness)ref;
En el ejemplo, el usuario es autenticado con la conexión a el “JNDI InitialContext”
Autorización.
Como sabemos en las aplicaciones no todos somos iguales, cada usuario tiene un rol ante una aplicación por ejemplo “administrador”, “empleado”, etc. y cada rol puede hacer o no determinadas acciones, es decir tiene o no tiene permiso para.
En EJB existen diferentes tipos de granularidad de permisos, puede ser por usuario o por rol. Esto permite que la autenticación sea un proceso separado de la autorización.
Los roles son definidos de forma logica y pueden representar roles, grupos de usuarios, o cualquier otro sistema de identificación. Los roles del los EJB son mapeados a los usuarios y grupos reales cuando el bean es deployado.
La autorización esta bien definida en la especificación EJB. Se declaran los roles de forma programática y luego se indican los permisos a los beans por medio de anotaciones o declararlos en ejb-jar.xml
Vimos de forma teoría la seguridad en EJB, en un próximo post vamos a hace algo más práctico.
Por que no EJB 3?
Soy un promovedor del uso de Spring pero por X motivo estoy estudiando un poco JEE 5 y la verdad estoy sorprendido por su simpleza, cambio mucho. Lo único que critico es que el tiempo de levantar jboss o glassfish o otro servidor JEE es mayor que usar solo tomcat o jetty (obviamente).
La especificación EJB 3 deja atrás el mal sabor que tenían las anteriores versiones de EJB a la hora de desarrollar. El paso más importante ahora los EJB son pojos, que por medio de anotaciones se infiere el comportamiento. No es necesario heredar de ningún objeto, ni hacer interfaces (gracias a Dios).
Veamos los tipos de beans que existen:
Session EJB: Son los beans que tienen las acciones; son los que tienen la lógica del negocio. Este tipo de bean viene en 2 sabores Stateless (no mantiene el estado en el servidor) o Statefull (mantiene el estado en el servidor). Además se agrego un Sigleton Beans, para cuando necesitamos solo una instancia de nuestro objeto de negocio.
Message-Driven Beans: La mensajería asíncrona es un paradigma en el cual dos o más aplicaciones se se comunican mediante un mensaje que describe un evento de negocio. Estos beans pueden generar mensajes asíncronos y consumirlos.
Entity Beans: Son objetos que modelan nuestros datos (Pojos) y son persistidos por medio del javax.persistence.EntityManager. Usando JPA (descripto en JSR-317) podemos persistir nuestros entity beans como si usáramos un ORM común.
Este es un pequeño resumen de la que nos brinda EJB 3. En próximos post ampliaremos!!
jueves, 3 de febrero de 2011
JBoss Seam
JBoss Seam es un framework que integra y unifica los distintos standars de la plataforma Java EE 5.0, pudiendo trabajar con todos ellos siguiendo el mismo modelo de programación.
Ha sido diseñado intentado simplificar al máximo el desarrollo de aplicaciones, basando el diseño en Plain Old Java Objects (POJOs) con anotaciones. Estos componentes se usan desde la capa de persistencia hasta la de presentación, poniendo todas las capas en comunicación directa.
El núcleo principal de Seam está formado por las especificaciones Enterprise JavaBeans 3 (EJB3) y JavaServer Faces (JSF).
A grandes rasgos podemos definir EJB3 como una arquitectura para un sistema transaccional (como bases de datos) de objetos distribuidos basado en componentes que permite construir aplicaciones portables, reusables y escalables.
JSF es un framework de la capa de presentación que define componentes para el interfaz gráfico y "managed beans" para la lógica de la aplicación que interactúan a travé de un sistema de eventos.
Sin embargo, estos frameworks tienen algunas limitaciones y no han sido concebidos para trabajar juntos (esto pretende resolverse con la futura especificación web beans ); tienen distinto tipo de configuraciones (JSF usa archivos XML mientras que EJB3 usa anotaciones), distinto ciclo de vida y no pueden comunicarse directamente a nivel de framework.
Para hacerlos cooperar necesitaríamos escribir "clases fachada" y multitud de código de relleno que se encargase de pasar las llamadas de una capa de la aplicación a otra. Ahí es donde entra en juego Seam.
Seam elimina la barrera existente entre estas tecnologías, permitiendo usar EJBs directamente como "backing beans" de JSF y lanzar o escuchar eventos web.
jueves, 20 de enero de 2011
Tutorial básico de Java EE
domingo, 10 de enero de 2010
Java EE 6
Si bien esta noticia no es novedad, con el cambio de año y vacaciones se hizo difícil escribir.
A fines del año pasado el Java Community Process aprobó la especificación de Java EE 6. Algunas de las características nuevas de la plataforma son:
- Perfiles: Java EE 6 introduce el concepto de perfiles: distintas configuraciones específicas de la plataforma para distintos fines. El primero en ser introducido en esta versión es el Web Profile, un perfil más liviano que usa únicamente lo necesario para desarrollos web.
- Productividad del desarrollo: apuntando las configuraciones a más anotaciones y menos configuración XML.
- Nuevas especificaciones: EJB 3.1, Java API for RESTful Web Services (JAX-RS), Contextos e inyección de dependencias (CDI), JPA 2, y más.
Con esta especificación final, Sun anunció la disponibilidad de GlassFish V3. GlassFish es su servidor de aplicaciones que implementa las tecnologías de Java EE. En esta versión, es el primer servidor en aplicar completamente la especificación Java EE 6. Sun anunció también a su vez, NetBeans 6.8, con soporte completo para Java EE 6.
Con motivo de estos nuevos lanzamientos, el equipo de software de Sun realizó una serie de conferencias virtuales. En éstas se hizo una presentación de las nuevas características de Java EE 6 y GlassFish V3. Los videos y diapositivas están disponibles para la descarga:
Para descargar los videos:
http://www.sun.com/events/javaee6glassfishv3/virtualconference/
Las diapositivas de las presentaciones:
http://www.sun.com/offers/details/java_ee6_slides.xml
Si les interesa empezar a aprender ya lo nuevo, en el sitio JavaPassion han organizado un codecamp online de Java EE 6. Tiene una duración de una semana (inicialmente 24 horas) para aprender las nuevas tecnologías escribiendo código. Pueden inscribirse si tienen una cuenta en Google. El codecamp comienza el 12 de enero, hasta el 20 de enero de 2010.
JBoss de RedHat es otro de los servidores de aplicaciones que viene trabajando en la implementación de la nueva especificación. Si bien habían implementado parte de la especificación en JBoss 5, ya están trabajando en JBoss AS 6. Recientemente se anunció la disponibilidad de JBoss Application Server 6.0.0.M1, un primer milestone que lo acerca más a implementar Java EE 6 (ya disponible para la descarga).
Las tres principales características del estándar que implementa son: JSF 2, Bean Validation y CDI.
Además este lanzamiento incluye soporte para mod_cluster, una solución de balance de carga que se integra con Apache y soporte para EmbeddedAS, un prototipo para una API nueva para la creación, configuración, ciclo de vida, operaciones de despliegue del servidor de aplicaciones JBoss. Pueden enterarse más en esta entrevista a Jason Greene, líder del equipo de desarrollo.
Hay muchas cosas nuevas para aprender este año. Todo esto predice un buen año para Java empresarial.
lunes, 13 de julio de 2009
Que es ORM ?
avanzados que intentan hacer esta tarea mas fácil .
Entre estas tecnologías están los Entity Beans 2.x , TopLink , Hibernate , JDO , y también JDBC con DAO. Con muchas alternativas incompatibles , el grupo Java EE experto toma inspiración de estos frameworks
populares y creo el api de persistencia de Java (JPA) , el cual se puede usar desde aplicaciones Java EE o SE.
En pocas palabras JPA , usa el modelo de programación POJO para la persistencia. A pesar de que este modelo esta incluido en la especificación EJB 3 , JPA puede ser usado fuera de un contenedor
EJB , y esta es la forma que será usada en este articulo . “Plain Old Java Objects” ( POJO ) ejecutándose en una aplicación Java SE.
Como trabaja JPA ?
Inspirado en los frameworks como Hibernate , JPA usa anotaciones para mapear objetos a la base de datos relacional. Estos objetos , usualmente llamados entidades, no tienen nada en común con los Entity Beans 2.x . Las entidades JPA son clases
POJOs, no extienden de ninguna clase y no implementan ninguna interface.
Usted no necesita archivos descriptores XML para hacer los mapeos . Si uno se fija en el API ( java doc ) uno observara que esta compuesto de pocas clases e interfaces.
La mayoría del contenido de el paquete javax.persitence son anotaciones. Con esto explicado , veremos el siguiente ejemplo de código:
@Entity
public class Customer {
@Id
private Long id;
private String firstname;
private String lastname;
private String telephone;
private String email;
private Integer age;
// constuctors, getters,
setters
}