Translate

Mostrando las entradas con la etiqueta JEE. Mostrar todas las entradas
Mostrando las entradas con la etiqueta JEE. Mostrar todas las entradas

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 !!!

Me llego un super mail de infoQ, al parecer esta gente junto con los amigos de red hat regalan un libro y yo lo tengo que compartir con ustedes.

August 2016
 
Sent on behalf of Red Hat to InfoQ Industry Email Notices Subscribers
 
With the ascent of DevOps, microservices, containers, and cloud-based development platforms, the gap between state-of-the-art solutions and the technology that enterprises typically support has greatly increased. But as explained in this O’Reilly report, some enterprises are now looking to bridge that gap by building microservice-based architectures on top of Java EE. 

Download this report to explore best practices for automation, high availability, data separation, and performance while inspecting design patterns such as aggregator, proxy, pipeline, and shared resources to model service interactions.
Download Now

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

martes, 13 de diciembre de 2011

@EJB


En un post anterior hicimos un proyecto con maven y JEE 

Pero en ese caso hicimos un lookup pero podríamos haber usado @EJB de la siguiente manera:


@EJB(mappedName="HolaMundoImpl/remote")
private HolaMundo holaMundo = null;

Y con esto nos ahorrábamos el lookup.

Cuales son los atributos de @EJB y para que se usan?

@EJB indica la dependencia de un ejb tanto local como remoto. Esta anotación tiene diferentes atributos los cuales analizaremos luego de revisar el concepto de ENC. Todos los EJB tienen un ENC (Enterprise Naming Context ) es como un registro interno donde fue deployeada esta aplicación.

Por ejemplo:

@Stateless(name="MyEJB")
public class MyEJBBean implements MyEJBRemoteBusiness, MyEJBLocalBusiness
{
...
}

Si nosotros asumimos que este EJB esta en myejb.jar y dentro de myapp.ear se puede tener una referencia a este bean de la siguiente manera:

javax.naming.Context jndiContext = new InitialContext(); // Assume we have this
// Define the contracted value
final String jndiName = "java:global/myapp/myejb/MyEJB!" +
MyEJBRemoteBusiness.class.getName();
MyEJBRemoteBusiness bean = (MyEJBRemoteBusiness)jndiContext.lookup(jndiName);

Cada bean contiene su JNDI ENC. La registración a JNDI ENC puede ser registrado bajo el contexto java:comp/env comp es porque es un componente. Cuando hacemos el lookup se resuelve la dependencia de diferentes contextos.

@EJB tiene los siguientes atributos:

name: atributo el cual indica conque nombre acedemos a una referencia EJB en JNDI ENC.

BeanName: este es el nombre de una referencia.

MappedName : es especifico del vendor; es una key dentro de la registración global. Es una forma de acceder a la referencia en el JNDI global. Por medio de mappedName varios vendors introducen características particulares. 

Esto fue una reseña general de @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

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.
GlassFishGlassFish

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 ?

Mapeo Objeto Relacional (ORM) ,en otras palabras persistir los objetos Java en una base de datos relacional ha tenido su mayor cambio recientemente, gracias, en parte a la proliferación de métodos
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
}