sábado, 13 de junio de 2015





                                                      Patrones de Integración Empresarial


En esta ocasión haremos referencia a dos patrones de intregracion los cuales son importantes y a manera de profundizar el conocimientos de ambos :

- Message Router

- Publish Subscribe Channel

Message Router iniciaremos indicando como este proporciona enrutamiento y la intermediación de la información, estos se clasifican deacuerdo a si estos realizan combinaciones o no de Message Router para ello los dividimos en 3 :

- Routers Simples -> Variantes del Message Router consiste en enrutar mensajes de un canal de entrada a uno a mas canales de salida

- Routers Compuestas -> Combinan múltiples routers simples para crear más complejos flujos de mensajes.

- Patrones Arquitectónicos -> Dscriben estilos arquitectónicos basado en Messages Router


Routers simples

El Router inspecciona el contenido de un mensaje y rutas a otro canal basado en el contenido del mensaje. El uso de un router tal permite al productor de mensajes para enviar mensajes a un solo canal y deja que el Content-Based Router inspeccione los mensajes y encaminarlos hacia el destino adecuado. Esto alivia la aplicación de envío de esta tarea y evita el acoplamiento del productor de mensajes a los canales de destino específico.

Un filtro de mensajes es una forma especial de un Content-Based Router . Examinar el contenido del mensaje y pasa el mensaje a otro canal si el contenido del mensaje coincide con ciertos criterios.De lo contrario, se descarta el mensaje. Message Filters se puede utilizar con un canal para encaminar un mensaje a todos los destinatarios posibles y permitir a los destinatarios para filtrar mensajes irrelevantes. Un Message Filters lleva a cabo una función que es muy similar a la de un consumidor selectivo con la diferencia clave es que un Message Filters es parte del sistema de mensajería, los mensajes de enrutamiento de calificación pasan por otro canal, mientras que un consumidor selectivo se construye en un Message Endpoint.

Un router basada en contenido y un filtro de mensajes realmente pueden resolver un problema similar. Un contenido basado en router rutas un mensaje al destino correcto basado en los criterios codificados en el Content-Based Router . Comportamiento equivalente se puede lograr mediante el uso de una publicación-suscripción de canales y una matriz de Message Filters, uno para cada posible receptor. Cada filtro de mensajes elimina los mensajes que no coincidan con los criterios para el destino específico. Los contenidos basado en router o rutas predictiva a un solo canal y por lo tanto tiene el control total, sino que también depende de la lista de todos los posibles canales de destino. El mensaje Filtrar gama filtra de forma reactiva, la difusión de la lógica de enrutamiento a través de muchosMessage Filters pero evitando un solo componente que depende de todos los posibles destinos. El equilibrio entre estas soluciones se describe con más detalle en el mensaje Filtro patrón.

Un básico Message Router utiliza reglas fijas para determinar el destino de un mensaje entrante. Cuando necesitamos más flexibilidad, un router dinámico puede ser muy útil. Este router permite la lógica de enrutamiento a modificar mediante el envío de mensajes de control a un puerto de control designado. La naturaleza dinámica del router dinámico se puede combinar con la mayoría de las formas del Message Router


Routers Compuesto

Una ventaja clave de la Tubos y Filtros arquitectura es el hecho de que podemos componer varios filtros en una solución más amplia. Procesador Mensaje Compuesto o un Scatter-Gather combinar múltiples Router Mensaje variantes para crear soluciones más integrales. Ambos patrones nos permiten recuperar información de múltiples fuentes y recombinar en un solo mensaje. Mientras que elprocesador de mensajes Compuesto mantiene el control sobre las posibles fuentes de la Dispersión-Reunir utiliza una publicación-suscripción de canal para que cualquier componente interesada puede participar en el proceso.


Tanto el procesador de mensajes Compuesta y la Dispersión-Reunir enrutar un único mensaje a un número de participantes al mismo tiempo y volver a montar las respuestas en un solo mensaje.Podemos decir que estos patrones de administrar el enrutamiento en paralelo de un mensaje. Dos patrones más gestionar el encaminamiento secuencial de un mensaje, es decir, encaminar un mensaje a través de una secuencia de pasos individuales. Si queremos controlar el camino de un mensaje desde un punto central se puede utilizar una hoja de enrutamiento para especificar la ruta del mensaje debe tomar. Este modelo funciona igual que la lista de distribución adjunta a los documentos de oficina para pasar secuencialmente por un número de destinatarios. Alternativamente, se puede utilizar unadministrador de procesos que nos da más flexibilidad, pero requiere que el mensaje para volver a un componente central después de cada función.
Patrones de arquitectura


Message Router s nos permiten arquitecto una solución de integración mediante un centro de Message Broker . En oposición a los diferentes mensajes de enrutamiento patrones de diseño, este patrón describe un-y-habló hub estilo arquitectónico.
El router adecuado para el propósito correcto


Este capítulo contiene 10 patrones. ¿Cómo podemos hacer que sea fácil encontrar el patrón adecuado para el propósito correcto? El siguiente diagrama de decisiones ayuda a encontrar el patrón adecuado para el propósito correcto por cuestión de simples sí / no decisiones. Por ejemplo, si usted está buscando un patrón de enrutamiento simple que consume un mensaje a la vez, pero publica varios mensajes en orden secuencial, se debe utilizar un divisor . El diagrama también ayuda ilustran cuán estrechamente se relacionan los patrones individuales. Por ejemplo, una hoja de enrutamiento yProcess Manager resolver problemas similares, mientras que un filtro de mensajes hace algo bastante diferente.







                                                                
Publish Subscribe Channel 

¿Cómo puede el remitente transmitir un evento para todos los receptores interesados?













Enviar un evento en un Publish Susbcribe Channel este entrega una copia en particular a cada receptor y funciona de la siguiente manera : 

Este tiene un canal de entrada que se divide en varios canales de salida , uno para cada subscriptor, cuando un evento se publica en el canal de publicacion-subscripcion este entrega una copia del mensaje a cada uno de  los canales de salida. Cada canal de salida tiene solamente un subscriptor ya que solo se le permitió consumir o recibir un mensaje a la vez, de esta manera cada subscriptor solo recibe el mensaje una vez para que sean consumidas y desaparecer de sus canales.

                                                     La aplicacion Publish Subscribe 

Ff649664.despublishsubscribe_f01 (es-es, PandP.10) .gif
La figura  muestra una solución de integración que consta de cuatro aplicaciones. El remitente (también llamado un editor ) utiliza un enfoque basado en el tema para publicar mensajes al Tema A y al Tema B. Tres receptores (también llamados suscriptores ) suscribirse a estos temas; un receptor se suscribe al tema A, un receptor se suscribe al Tema B, y un receptor se suscribe a tanto tópico A y al Tema B. Las flechas muestran los mensajes que fluyen de la editorial a cada suscriptor de acuerdo con estas suscripciones.
 La implementación de Publish/Subscribe afecta generalmente a los mensajes, las aplicaciones integradas, y la infraestructura de comunicación.

En primer lugar, debe identificar los temas o el contenido de interés para las aplicaciones receptoras. Esto se traduce en la partición del conjunto de tipos de mensajes en diferentes subgrupos. Por ejemplo, considere los tipos de mensajes que se envían por un sistema de comercio. Algunas aplicaciones comerciales seguimiento de las transacciones de compra, algunas transacciones de venta de la pista, y otras aplicaciones de seguimiento de ambos tipos de transacción. Separar el mensaje mediante la creación de un tema de compra y una venta particiones tema de los mensajes del sistema de comercio en subconjuntos destinados a estas aplicaciones.
A continuación, debe añadir información a los mensajes que indican el tema o que identifica la información de contenido específico. A veces se puede almacenar la información relacionados con el tema en un campo de mensaje sin usar. Alternativamente, usted puede ser capaz de añadir un nuevo campo para el tema. Por ejemplo, usted puede ser capaz de insertar un nuevo elemento en un encabezado SOAP. Si usted puede utilizar ni un campo existente ni añadir una nueva, usted debe encontrar otras formas de codificar el tema en el mensaje, o usted debe utilizar un enfoque basado en el contenido en lugar.
A continuación, debe ampliar la infraestructura de comunicación para que se entrega mensajes de acuerdo a la suscripción de cada suscriptor. El enfoque que se utiliza depende de la topología de la solución de integración. Por ejemplo, considere los tres topologías comunes. Para la integración de autobús, puede implementar el mecanismo de suscripción en la interfaz de bus. Para la integración broker, puede implementar el mecanismo a través de listas de suscripción al corredor. Para la integración punto a punto, puede implementar el mecanismo a través de listas de suscripción en el editor.
Por último, debe modificar las aplicaciones integradas. El editor debe agregar la información relacionados con el tema de cada mensaje que publica. Por ejemplo, si el tema se codifica como un elemento de cabecera, el editor debe insertar la información relacionados con el tema en el elemento apropiado. Del mismo modo, el suscriptor debe especificar los temas de interés.
Las suscripciones pueden ser fijos o dinámicos. Con suscripciones fijas, el arquitecto de integración establece los temas que la solicitud se haya suscrito. Aplicaciones no tienen control sobre sus suscripciones. Por lo general, las suscripciones se especifican cuando se añade cada aplicación a la solución de integración. La Figura 2 muestra una suscripción fija a Tema A.
Ff649664.despublishsubscribe_f02 (es-es, PandP.10) .gif

Publish/Subscribe con Subscripción Fija 
En contraste, las suscripciones dinámicas permiten que las aplicaciones para el control de sus propias suscripciones a través de un conjunto de mensajes de control. Las aplicaciones pueden eliminar las suscripciones existentes mediante el envío de mensajes a la infraestructura de comunicación que retire la aplicación de la lista de suscripción. Las aplicaciones pueden agregar nuevas suscripciones mediante el envío de mensajes a la infraestructura de comunicación que agregar la aplicación a una lista de suscripción. La mayoría de las infraestructuras de comunicación que tienen de Publish/Susbcribe capacidades proporcionan esta característica. Sin embargo, el apoyo suscripciones dinámicas no es un requisito.

Ff649664.despublishsubscribe_f03 (es-es, PandP.10) .gif

Publish/Subscribe con subscripciones dinamicas
Muestra el grafico de arriba cómo funciona  dinámica las  suscripciones. La parte superior de la Figura de arriba muestra la suscripción inicial al tema A. La aplicación envía un mensaje de que la quita de la lista de suscripción de tema A. La aplicación envía dos mensajes que suscriban la solicitud al Tema B y C. El tema de fondo parte de la Figura 3 muestra la suscripción final después se envían estos mensajes de control.















                  Acceso a Servicios Web REST en Android

                                          (PARTE 2)


Actualizar un cliente existente
La URL utilizada para la actualización de clientes será la misma que la anterior:
http://10.0.2.2:2731/Api/Clientes/Cliente
Pero en este caso, el objeto JSON a enviar como entrada deberá contener no sólo los nuevos valores de nombre y teléfono sino también el ID del cliente a actualizar, por lo que tendría una estructura análoga a la siguiente:
{Id:123, Nombre:”cccc”, Telefono:12345678}
Para actualizar el cliente procederemos de una forma muy similar a la ya comentada para la inserción, con las únicas diferencias de que en este caso la acción HTTP utilizada será PUT (objeto HttpPut) y que el objeto JSON de entrada tendrá el campo ID adicional.
HttpClient httpClient = new DefaultHttpClient();
HttpPut put = new HttpPut("http://10.0.2.2:2731/Api/Clientes/Cliente");
put.setHeader("content-type", "application/json");
try
{
    //Construimos el objeto cliente en formato JSON
    JSONObject dato = new JSONObject();
    dato.put("Id", Integer.parseInt(txtId.getText().toString()));
    dato.put("Nombre", txtNombre.getText().toString());
    dato.put("Telefono", Integer.parseInt(txtTelefono.getText().toString()));
    StringEntity entity = new StringEntity(dato.toString());
    put.setEntity(entity);
        HttpResponse resp = httpClient.execute(put);
        String respStr = EntityUtils.toString(resp.getEntity());
        if(respStr.equals("true"))
            lblResultado.setText("Actualizado OK.");
}
catch(Exception ex)
{
        Log.e("ServicioRest","Error!", ex);
}


Eliminación de un cliente
La eliminación de un cliente la realizaremos a través de la URL siguiente:
http://10.0.2.2:2731/Api/Clientes/Cliente/id_cliente
donde id_cliente será el ID del cliente a eliminar. Además, utilizaremos la acción http DELETE (objetoHttpDelete) para identificar la operación que queremos realizar. En este caso no será necesario pasar ningún objeto de entrada junto con la petición, por lo que el código quedará aún más sencillo que los dos casos anteriores.

HttpClient httpClient = new DefaultHttpClient();
String id = txtId.getText().toString();
HttpDelete del =
    new HttpDelete("http://10.0.2.2:2731/Api/Clientes/Cliente/" + id);
del.setHeader("content-type", "application/json");
try
{
        HttpResponse resp = httpClient.execute(del);
        String respStr = EntityUtils.toString(resp.getEntity());
        if(respStr.equals("true"))
            lblResultado.setText("Eliminado OK.");
}
catch(Exception ex)
{
        Log.e("ServicioRest","Error!", ex);
}

Como podéis ver, al principio del método obtenemos el ID del cliente desde la interfaz de la aplicación y lo concatenamos con la URL base para formar la URL completa de llamada al servicio.


Obtener un cliente
Esta operación es un poco distinta a las anteriores, ya que en este caso el resultado devuelto por el servicio será un objeto JSON y no un valor simple como en los casos anteriores. Al igual que en el caso de eliminación de clientes, la URL a utilizar será del tipo:
http://10.0.2.2:2731/Api/Clientes/Cliente/id_cliente
En este caso utilizaremos un tipo de petición http GET (objeto HttpGet) y la forma de realizar la llamada será análoga a las anteriores. Donde aparecerán las diferencias será a la hora de tratar el resultado devuelto por el servicio tras llamar al método getEntity(). Lo que haremos será crear un nuevo objetoJSONObject a partir del resultado textual de getEntity(). Hecho esto, podremos acceder a los atributos del objeto utilizando para ello los métodos get() correspondientes, según el tipo de cada atributo (getInt()getString(), etc). Tras esto mostraremos los datos del cliente recuperado en la etiqueta de resultados de la interfaz (lblResultados).

HttpClient httpClient = new DefaultHttpClient();
String id = txtId.getText().toString();
HttpGet del =
    new HttpGet("http://10.0.2.2:2731/Api/Clientes/Cliente/" + id);
del.setHeader("content-type", "application/json");
try
{
        HttpResponse resp = httpClient.execute(del);
        String respStr = EntityUtils.toString(resp.getEntity());
        JSONObject respJSON = new JSONObject(respStr);
        int idCli = respJSON.getInt("Id");
        String nombCli = respJSON.getString("Nombre");
        int telefCli = respJSON.getInt("Telefono");
        lblResultado.setText("" + idCli + "-" + nombCli + "-" + telefCli);
}
catch(Exception ex)
{
        Log.e("ServicioRest","Error!", ex);
}


Una vez más como podéis comprobar el código es muy similar al ya visto para el resto de operaciones.
Obtener listado completo de clientes
Por último vamos a ver cómo podemos obtener el listado completo de clientes. El interés de esta operación está en que el resultado recuperado de la llamada al servicio será un array de objetos de tipo cliente, por supuesto en formato JSON. La acción http utilizada será una vez más la acción GET, y la URL para recuperar el listado de clientes será:
http://10.0.2.2:2731/Api/Clientes
De nuevo, la forma de llamar al servicio será análoga a las anteriores hasta la llamada a getEntity()para recuperar los resultados. En esta ocasión, dado que recibimos un array de elementos, convertiremos este resultado a un objeto JSONArray, y hecho esto podremos acceder a cada uno de los elementos del array mediante una llamada a getJSONObject(), al que iremos pasando el índice de cada elemento. Para saber cuántos elementos contiene el array podremos utilizar el método length() del objeto JSONArray. Por último, el acceso a los atributos de cada elemento del array lo realizamos exactamente igual como ya lo hicimos en la operación anterior de obtención de cliente por ID.

HttpClient httpClient = new DefaultHttpClient();
HttpGet del =
    new HttpGet("http://10.0.2.2:2731/Api/Clientes");
del.setHeader("content-type", "application/json");
try
{
        HttpResponse resp = httpClient.execute(del);
        String respStr = EntityUtils.toString(resp.getEntity());
        JSONArray respJSON = new JSONArray(respStr);
        String[] clientes = new String[respJSON.length()];
        for(int i=0; i<respJSON.length(); i++)
        {
            JSONObject obj = respJSON.getJSONObject(i);
            int idCli = obj.getInt("Id");
            String nombCli = obj.getString("Nombre");
            int telefCli = obj.getInt("Telefono");
            clientes[i] = "" + idCli + "-" + nombCli + "-" + telefCli;
        }
        //Rellenamos la lista con los resultados
        ArrayAdapter<String> adaptador =
                new ArrayAdapter<String>(ServicioWebRest.this,
                android.R.layout.simple_list_item_1, clientes);
    lstClientes.setAdapter(adaptador);
}
catch(Exception ex)
{
        Log.e("ServicioRest","Error!", ex);
}


Tras obtener nuestro array de clientes, para mostrar los resultados hemos añadido a la interfas de nuestra aplicación de ejemplo un control tipo ListView (llamado lstClientes) que hemos rellenado a través de su adaptador con los datos de los clientes recuperados.
A modo de ejemplo, en la siguiente imagen puede verse el resultado de ejecutar la operación de listado completo de clientes:
demo-android-rest
PROYECTOS EN GIT HUB al respecto : LINK 

https://github.com/sgolivernet/curso-android-src/tree/master/android-ws-rest
https://github.com/sgolivernet/curso-android-src/tree/master/android-ws-rest