joselynrojas91-blog

[joselynrojas91-blog]

Java Message Service  (JMS)

Definamos JMS, una interfaz de programación de API de Sun Microsystems que permite la comunicación de mensajería, de manera oficial entre computadores en red. El objetivo de Sun Microsystems es que se pueda utilizar sus API en cualquier importante plataforma de sistema operativo. Se conoce que Mensajería es utilizada a menudo para coordinar los programas en los sitemas disímiles o tambien dicho distinto lenguaje de programación.

A través de su mensajería no sólo podrá invocar  a los servicios de mensajería de IBM MQseries sino tambien a otros vendedores de productos de mensajería populares. Un dato también es que JMS recibe mensajes que contengan el lenguaje de etiquetas XML.

Los 2 modelos de esta API son: modelo punto a punto y publish suscribe. En el primero, solo cuenta con 2 clientes, uno que envpia el mensaje y el otro que lo recibe; utiliza la cola tipo FIFO. El segundo, a contrario del anterior, éste si puede tener múltiples clientes. Ambos trabajan de manera síncrona con el método receive y asíncróna a través de un MessageListener.

La implementación es la siguiente, para enviar o recibir mensajes los clientes tienen que conectarse por medio de los objetos administrados, este nombre lo reciben porque son creados por el administrador (j2eeadmin). Estos implementan las interfaces JMS y se sitúan en el espacio de nombres JNDI (Java Naming and Directory Interface) para que así los clientes puedan solicitarlos.

Hay dos tipos de objetos administrados en JMS:

ConnectionFactory: Se usa para crear una conexión al proveedor del sistema de mensajes.

Destination: Son los destinos de los mensajes que se envían y el recipiente de los mensajes que se reciben.

Los mensajes son la base de los JMS, se componen en tres elementos:

1.Header: Es la cabecera del mensaje, le sirve a los clientes y a los proveedores para poder identificarlos. Similar a URI en HTP.

2.Properties: Sirve para personalizar y/o hacer más específico un mensaje.

3.Body: Es el mensaje en sí mismo, hay varios tipos de “cuerpos” que pueden llevar un mensaje:

StreamMessage: Contiene un flujo (stream) de datos que se escriben y leen de manera secuencial.

MapMessage: Contiene pares nombre-valor.

TextMessage: Contiene un String.

ObjectMessage: Contiene un objeto que implemente la interfaz Serializable.

BytesMessage: Contiene un stream de bytes.

Los clientes JMS son aquellos que envíen mensajes, y a su vez  que los reciban. En otras publicaciones a los que envían mensajes son llamados proveedores y los que reciben los llaman consumidores o clientes. Para enviar o recibir mensajes tienen que tener una serie de pasos :

1.Conseguir un destino, mediante el objeto Destination a través de JNDI.

2.Usar ConnectionFactory para conseguir un objeto Connection.

3.Usar Destination para crear un objeto Session.

Referencias:

http://docs.oracle.com/javaee/6/tutorial/doc/bncdq.html http://searchsoa.techtarget.com/definition/Java-Message-Service https://es.wikipedia.org/wiki/Java_Message_Service

[joselynrojas91-blog]

Oh!! Mensajería en cola.

[joselynrojas91-blog]

Crear servicios web RESTful en Java (JAX-RS)

En las clases de laboratorio se han realizado servicios web en .NET pero, ahora complementaremos la clase con este tutorial de creación de servicios web en Java.

API de Java para RESTful Web Services (JAX-RS), es un conjunto de las API a servicio de revelado REST.  JAX-RS es parte del Java EE6, y hace que los desarrolladores puedan crear aplicaciones Web REST fácilmente. Jersey es la implementación de referencia para esta especificación.  Jersey contiene básicamente un servidor y un cliente REST REST.  El cliente núcleo puede comunicarse con el servidor mediante lib jersey.

En el lado del servidor Jersey se utiliza un servlet que escanea clases predefinidas para identificar los recursos REST.  A través del archivo de configuración web.xml de la aplicación web.

La URL base de este servlet es:

 http: // your_domain: puerto / display-name / url-pattern / path_from_rest_class

 Este servlet analiza la petición HTTP entrante y selecciona la clase y método correcto dependiendo de la petición.  Esta selección se basa en las anotaciones previstas en la clase y métodos.

1) Abrir el eclipse.

 2) Crear un nuevo proyecto web dinámico llamado "RESTfulWebServiceExample"

 3) Ahora vaya a la ubicación donde usted tiene descarga Jersey y vaya al maillot-archive-1.17-> lib

 folder.you puede tener todos los frascos, pero por ahora se puede copiar siguientes frascos

 asm-3.1

 maillot-client-1.17

 maillot-core-1.17

 maillot-server-1.17

 maillot-servlet-1.17

 jsr311-api-1.1.1

 Pegue todos los frascos anterior copiados en WebContent-> WEB-INF> lib

 Añadir todos estos frascos a eclipsar ruta de compilación.   Haga clic derecho sobre el proyecto (RESTfulWebServiceExample) -> Propiedades

Haga clic en Java Build Path y luego Añadir frascos como se muestra en el diagrama anterior.

 ir a Proyecto-> WebContent-> WEB-INF> lib y seleccione todos los frascos y luego haga clic en Aceptar.

 Haga clic en frascos ok.Jersey añadido a la ruta de clase.

 4) Crear un nuevo paquete llamado "org.arpit.javapostsforlearning.webservice"

 5) Crear

FeetToInchAndInchToFeetConversionService.java

 org.arpit.javapostsforlearning.webservices paquete; / ** *author Arpit Mandliya * / javax.ws.rs.GET importación; javax.ws.rs.Path importación; javax.ws.rs.PathParam importación; javax.ws.rs.Produces de importación; javax.ws.rs.core.MediaType importación; Path ("ConversionService") public class FeetToInchAndInchToFeetConversionService {      @OBTENER      Path ("/ InchToFeet / {i}")       Produces (MediaType.TEXT_XML)       public String convertInchToFeet (PathParam ("i") int i) {         int pulgada = i;         pies dobles = 0;         pies = (doble) pulgadas / 12;               volver "<InchToFeetService>"         + "<Inch>" + pulgadas + "</ pulgadas>"           + "<Pies>" + pies + "</ Pies>"          + "</ InchToFeetService>";       }       Path ("/ FeetToInch / {f}")       @OBTENER       Produces (MediaType.TEXT_XML)       public String convertFeetToInch (PathParam ("f") int f) {        int pulgada = 0;           int pies = f;           pulgada = 12 * pies;             volver "<FeetToInchService>"             + "<Pies>" + pies + "</ Pies>"             + "<Inch>" + pulgadas + "</ pulgadas>"             + "</ FeetToInchService>";       } }

Path (/ Your_path_at_class_level):

Establece la ruta de URL base + / your_path_at_class_level.  La URL base se basa en el nombre de la aplicación, el servlet y el patrón de URL del archivo de configuración web.xml ".

Path (/ Your_path_at_method_level):

Establece camino hacia la URL base + / your_path_at_class_level + / your_path_at_method_level

Produces (MediaType.TEXT_XML [, más tipos]):Produces

define qué tipo MIME se entrega mediante un método anotado conGET.  En el texto del ejemplo ("text / XML") se produce.

PathParam:

Se utiliza para inyectar valores de la URL en un método parameter.This manera que se inyecte pulgadas en el método convertFeetToInch y convertir que a los pies.

 6) Ahora lo que necesita para crear

web.xml

y ponerlo bajo

/ RESTfulWebserviceExample / WebContent / WEB-INF /

 <? Xml version = "1.0" encoding = "UTF-8"?> <Web-app xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xmlns = "http://java.sun.com/xml/ns/javaee" xmlns: web = "http : "xsi: schemaLocation =" //java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com /xml/ns/javaee/web-app_2_5.xsd "id =" "version =" 2.5 WebApp_ID ">   <Display-name> RESTfulWebServiceExample </ display-name>   <Servlet>     <Servlet-name> Servicio REST Jersey </ servlet-name>     <Servlet-class> com.sun.jersey.spi.container.servlet.ServletContainer </ servlet-class>     <Init-param>       <Param-name> com.sun.jersey.config.property.packages </ param-name>       <Param-value> org.arpit.javapostsforlearning.webservices </ param-value>     </ Init-param>     <Load-on-startup> 1 </ load-on-startup>   </ Servlet>   <Servlet-mapping>     <Servlet-name> Servicio REST Jersey </ servlet-name>     <Url-pattern> / rest / * </ url-pattern>   </ Servlet-mapping> </ Web-app>

 En anterior <param-value>, ponga su paquete de servicios web.

 8)

Proyecto de Ejecución:

haga clic derecho sobre proyecto-> ejecutar como -> ejecutar en el servidor   9) Pruebe su servicio REST en: "http: // localhost: 8080 / RESTfulWebServiceExample / rest / ConversionService / FeetToInch / 2".

  Usted recibirá salida como: 

  Si Usted ve la página de información de servicio web, entonces ya está.

El por qué usar JAX-RS se resumiría en lo siguiente:

El servicio RESTful de desarrollo (Jersey) es una arquitectura, que de todas maneras utiliza servlets.

JAX-RS es compatible con herramientas como Jersey,. que proporciona fácil marhalling-unmarshalling de XML/JSON de datos, esto es de gran ayuda para los desarrolladores.

El DESCANSO nos ayuda a usar GET/PUT/POST/ELIMINAR de una manera que es mucho más eficiente de lo normal servlets.

Referencia:

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.com&sl=en&u=http://www.java2blog.com/2013/04/create-restful-web-servicesjax-rs-using.html&usg=ALkJrhgS8vvwxXPV6P8j3tVz87pn7hHTZQ

http://www.iteramos.com/pregunta/35633/por-qu-utilizar-jax-rs--jersey

[joselynrojas91-blog]

Un meme para amenizar el día. =)

[joselynrojas91-blog]

SOA Insight

Ya sabemos que SOA es una arquitectura orientada a servicios. Pero.. ¿qué es un servicio?

Revisemos más a fondo este concepto. En definición un servicio es la unidad lógica de una solución, donde se aplica el paradigma de la orientación a servicios. Ellos soportan la ejecución de los procesos del negocio. Estos procesos van a ser descompuestos para agruparse, clasificarse y componerse en SERVICIOS.

La descomposición de los procesos se realizarán en diferentes lógicas, con ellas se podrán definir modelos de servicio.

1. Negocio: aquí se expresa las capacidades del negocio.

2. Utilidad: se encuentra a bajo nivel, para realizarlo requiere lógica de utilidad que genere a la lógica del negocio. Soporta a las capacidades del negocio.

3. Agnóstica: es la lógica genérica con alto ppotencial a ser reutilizada.

4. Capacidades del negocio: otros servicios y otros procesos. Unidades de trabajo.

5. No agnóstica: funcionalidad específica.

Entonces, los modelos de servicio se clasifican en: tarea, entidad y utilidad. Siendo la primera, servicios con contextos funcionales de Negocio No Agnóstico y los dos restantes; negocios agnósticos y utilidad agnósticas, respectivamente. Gracias a la lógica se podrá definir las capas de servicio. Tenemos la capa superior, donde estarán los servicios de tarea, luego en la capa 2 los servicios de entidad y por último en la tercera capa, los servicios de utilidad.

Es fundamental que se apoyen en servicios de más bajo nivel como los servicios de entidad o de utilidad. Ya que la reutilización y la composición, es decir cuando un servicio utiliza otros servicios, son dos principios básicos de diseño de servicios. Entonces, una arquitectura que únicamente contenga servicios de tarea, probablemente no sea una SOA.

[joselynrojas91-blog]

Un servicio no es un web service

Héctor Saira

[joselynrojas91-blog]

Para ayudarnos a entender qué es Grid Computing.

[joselynrojas91-blog]

Hoy hablamos de... GRID COMPUTING

GRID, la traducción al español es cuadrícula, red o malla. Y.. ¿qué tiene que ver una cuadrícula con sistemas? Pues tiene que ver en la manera de cómo se conectan las computadoras y servidores, es decir en la infraestructura para tener una mejor comunicación.

Para tener un poco de conocimiento histórico, vamos a remontarnos a los años de los 70, exactamente en Palo Alto, California. En este lugar se levantó el laboratorio dedicado exclusivamente a la innovación e investigación por la empresa XEROX. En este lugar, XEROX PARC, se creó la interfaz Ethernet, el elemento muy importante para la infraestructura entre computadoras; es decir GRID. Pero, realmente donde hubo uso de un GRID fue en un proyecto iniciado por la NASA; en este proyecto se utilizó anónimamente a más de un millón y medio de computadoras de más de 200 países. Por otro lado, Carl Kesselman e Ian Foster, en su libro que publicaron a finales de los 90 “The Grid: The Blueprint for a new computing infrastructure“ plasmaron el concepto de GRID basándose del concepto de una malla eléctrica; ellos querían que la conexión a los nodos (servidores) fuera sencilla. Tanto así como  cuando conectamos nuestro cargador del celular a cualquier tomacorriente, es más, sin fijarnos en el voltaje que este nos brinde. Por cosas del destino puede que sea una toma que sólo brinde 110 V. Bueno, ellos querían que se tuviera la facilidad de acceder a la red de cómputos que contenía la información que el usuario deseara.

Pero definamos mejor y con más claridad. Como se sabe por historia humana todo ha ido evolucionando, también los procesos de información. Por mencionar 2 claros ejemplos, se tiene el campo de la medicina, para las investigaciones de las enfermedades, exactamente los componentes de los elementos químicos o en las Finanzas, para realizar complicados cálculos matemáticos, se ha visto en la necesidad de tener un computador que procese con mayor eficacia mayor cantidad de información o un software pesado. Además, con el Grid Computing se aprovecha al máximo la capacidad de los recursos que pueden ofrecer los computadores.

Una de las principales ventajas de Grid Computing es la alta escalabilidad que se tiene, puesto que cualquier hardware, clúster o base de datos se puede adicionar a esta red sin ningún inconveniente, ellos pueden estar ubicados en distintos lugares distantes, no es necesario que se encuentren en un solo edificio. Esta ventaja claramente nos dará como buen resultado la ausencia de los cuellos de botellas, o sea la falta de recursos, que quizá en otras tecnologías sí. Al tener una alta capacidad de información, es recomendable que se maneje el tema de seguridad con políticas de acceso.

Entonces el funcionamiento del Grid es la comunicación rápida, fiable y transparente de recursos remotos sobre un middleware. Esto ayudará con la interoperabilidad; es decir, imagínese si se desea agregar un aparato como el telescopio o sensores de medida, ya no será tan sencillo que haya comunicación con estos nuevos aparatos que se desee agregar. Entonces hará falta de un “adaptador“ o mejor llamado middleware.

A pesar de tener una excelente ventaja de escalabilidad, aún se tiene inconvenientes con el tema de sincronización de los procesos de todos los equipos.

La arquitectura lo podemos enumerar de la siguiente manera:

1. Capa de aplicación. Relacionado directamente con el usuario.

2. Capa de Middleware. Esta es la más importante. Ya que se ocupa de la supervisión del buen funcionamiento de los procesos.

3. Capa de recursos. Como su nombre indica, los recursos, tenemos las supercomputadoras,  sistemas de almacenamiento, etc.

4. Capa de red. Se encarga de asegurar la conexión.

También tenemos a la Estandarización, quien lo desarrolla es nada más ni nada menos que el OGF (Open Grid Forum). Si se desea Grid basado en servicios web, está OGSA (Open Grid Services Architecture).

Los principales o potenciales clientes para esta tecnología son las organizaciones relacionadas a salud, educación o el gobierno. Ya que ellos comparten un objetivo, normalmente, en común.

https://es.wikipedia.org/wiki/Computaci%C3%B3n_grid https://apuntescomputacion.wordpress.com/2008/08/16/%C2%BFque-es-y-como-funciona-un-grid/ http://es.slideshare.net/poool666/universidad-nacional-federicovillarreal http://www.ramonmillan.com/tutoriales/gridcomputing.php http://blogthinkbig.com/xerox-parc-origen-tecnologias-de-hoy/