Me llegó la invitación para el evento MVP Open Day en Chile. En este evento los manager del programa MVP vienen a Santiago de Chile a conocer las comunidades locales, recibir feedback y compartir experiencias.
Esta es la invitación, será una excelente oportunidad de intercambiar ideas. Todo lo interesante que no sea NDA lo compartiré en este BLOG.
Estoy es una muy buena noticia. Microsoft va a entregar los códigos fuentes del Framework 3.5 para que los developer puedan hacer debug de manera integrada con sus programas y además usarlo de referencia de implementación.
La segunda utilización me parece mucho más útil que la primera, pero eso puede ser porque no hago tanto código como me gustaría.
Les dejo el Link donde pueden encontrar la información de primera fuente.
Salu2,
En mi trabajo estamos buscando un jefe de proyectos, por lo que tuvimos que redactar alguna descripción del perfil de este Rol. En ese trabajo me mandaron la siguiente tabla de habilidades que debería tener un jefe de proyecto.
Me pareció muy completa y precisa por lo que la comparto en este POST. No tengo clara la fuente, por eso no la cito.
El Project Manager por el alcance de sus funciones, del equipo y recursos que administra, y por las variables y escenarios que se presentan, debería tener en mayor o menor grado algunas de las siguientes habilidades:
|
Skill |
Breve descripción |
|
Coping |
Capacidad de tener una actitud madura ante conflictos y al resolver problemas. |
|
Tolerance of ambiguity |
Capacidad de tomar decisiones sin tener suficiente información. Usualmente son |
|
Decisiveness |
Capacidad para tomar decisiones y aceptar compromisos. Los compromisos siempre son |
|
Spoken Communication |
Capacidad para hablar en público y presentar información, tanto en escenarios |
|
Assertiveness |
Capacidad de expresar opiniones ya sean a favor o en contra a una posición, siempre |
|
Energizing |
Capacidad de crear un buen ambiente y transmitir energía positiva. |
|
Policy & Procedures |
Capacidad de adaptarse fácilmente a los procedimientos y política de la empresa. |
|
Alertness |
Capacidad de estar alerta ante los entornos externos, y cómo este afectan al trabajo del |
|
Analytical Problem Solving |
Capacidad de razonamiento y uso de un proceso lógico analítico para resolver un |
|
Goal Setting |
Capacidad para establecer metas realistas, objetivos y su definición. |
|
Written Communication |
Capacidad para comunicarse de forma correcta a través de la escritura. Permite |
|
Commitment to Risk |
Capacidad de compromiso ante un objetivo, asignación o meta, manteniendo una actitud |
|
Organization & Planning |
Capacidad para organizar tareas, personas en un calendario y realizar el |
|
Creativity |
Capacidad para buscar soluciones creativas e innovadoras a problemas que se presenten |
|
Interaction |
Capacidad de comunicación cálida, transmitiendo seguridad y motivación al equipo de |
|
Perceptivity |
Capacidad para interpretar la comunicación verbal y no verbal de las otras personas. De |
|
Versatility |
Capacidad “camaleónica” de poder cambiar opiniones, ideas, para poder |
|
Reading the system |
Capacidad para entender el funcionamiento interno de una organización, de tal forma que |
|
Team Building |
Capacidad para trabajar y formentar equipos de trabajo, creando entornos apropiados con el fin de conseguir un objetivo en común. |
|
Decision Making & Problem Solving |
Capacidad de tomar decisiones con razonamiento, dejando de un lado el aspecto emocional. |
|
Leadership |
Capacidad de influencia y hacer que las otras personas te sigan hacia un fin en común. |
Como les conté hace un tiempo (en este POST) viene por fin Andrés Calamaro a Chile el 6 de diciembre. La última vez que vino fue el año 1997, hace 10 años!!! , a presentar su disco "Alta Suciedad" en la sala SCD.
Ahora, presentará su nuevo disco "La lengua Popular" que tiene 12 temas.
Está vez vendrá con una banda telonera llamada Fito y Fitipaldis, que es española pero yo no la conozco.
Salu2
En los 2 POST anteriores he tratado el tema del motor de reglas de Windows Workflow Foundation. El primero es una introducción que permite entender el concepto de RuleSet y cómo usarlo en un Workflow. El segundo explica cómo funciona el tema de las dependencias de las reglas y la manera de administrar las re evaluaciones por cambios de las condiciones de validación.
Ahora voy a mostrar algo que es muy potente. Hasta ahora, las reglas de negocio se encuentran compiladas dentro del Assembly del Workflow. La consecuencia de esto es que es necesario para cambiar las reglas volver a compilar. Esto es un contra sentido, porque la idea de desacoplar las reglas de código de programación es poder tener una separación clara de el código del Wrokflow de las reglas.
En este Post voy a tratar de explicar cómo usar una pieza de software de terceros que permite poner el RuleSet de negocio en una base de datos y así cambiar las reglas sin volver a compilar.
Lo primero que debo presisar es que voy a utilizar un software de terceros llamado “External RuleSet Toolkit”[1]. Este código es de ejemplo y demuestra como almacenar en SQL el RuleSet. Además trae una interfaz Windows Forms para modificar las reglas en la DB y así los Workflow no son alterados por cambios en las reglas de negocio.
Lo primero que hay que entender es la arquitectura de esta solución. El siguiente diagrama muestra un WorkflowRuntime que tiene 3 instancias de Workflow corriendo. Cada una de esas instancias tiene una Custom Activity llamada “Custom Policy Activity”, que se encarga de obtener el RuleSet desde la base de datos a través del servicio “RuleSet Services”. Este Servicio debe ser agregado al WorkflowRuntime para que esta actividad de Políticas cutomizada pueda comunicarse con el RuleSet Repository que esta en la base de datos.
Imagen 1.
Además de los componentes para el Workflow este ejemplo de código trae el RuleSet Designer que es una interfaz gráfica para administrar los elementos del RuleSet Repository. Esta interfaz se muestra en la imagen 2.
Imagen 2.
Para poder usar el componente se deben cumplir con el proceso de instalación. Estos no los voy a explicar porque están perfectamente detallados en el manual de instalación de este ejemplo de código.
Para usar este componente vamos a importar el RuleSet que usamos en el primer ejemplo del primer post de esta serie. Como sabemos las reglas de guardan en un archivo de extensión .rule. Usando la aplicación RuleSet Designer vamos a importar el archivo wfReglasEjemplo_1.rule que está en este ejemplo de código [2]. Una vez importado grabamos el RuleSet para que así quede persistente en la base de datos.
Ahora, creamos un Workflow secuencial y le agregamos la actividad customizada PolicyFromService que es la que enlaza con las reglas de la base de datos a través del Servicio. El workflow se ve como la siguiente imagen.
Imagen 3.
Las propiedades de la actividad PolicyFromService son:
1.- RuleSet Name: nombre del juego de reglas a usar.
2.- Major Version: numero de verison.
3.- Menor Version: número de sub versión.
EL RuleSet de nuestro ejemplo se llama Rule Set1. LA versión es la por defecto 1.0.
Ahora para que esto funcione debemos incluir el servicio de comunicaciones con el repositorio de la reglas en la base de datos. Para eso al runtime del Workflow agregamos el Servicio RuleSet Services. Para esto agregamos el siguiente código.
|
workflowRuntime.AddService(new RuleSetService()); |
Código 1.
Con esto tenemos listo nuestro ejemplo. Si lo ejecutamos obtenemos el resultado A=15, B=5, C=5, D=2 y E=7. Las reglas para hacer los cambios de los valores los leyó desde la base de datos!!!!!.
Ahora, vamos a cambiar los valores para comprobar que descaplamos las reglas del Assembly. Para ello usamos la herramienta RuleSet Designer. Lo que haremos es mantener dos versiones de las reglas, así dependiendo de un valor usaremos una u otra regla.
Primero creamos una copia de las reglas, para eso usamos la función copy. Al hacer eso, nos aparece una nueva versión que por defecto es la versión 2.0. Usando la opción de Edit Rule, nos aparece el mismo formulario usamos antes para cambiar las reglas de Rule Set.
Si cambiamos las reglas y las grabamos en la base de datos el workflow inmediatamente comenzará a evaluar con el nuevo set de Reglas. Los valores de las reglas del segundo ejemplo son:
|
Código 3: Reglas Ejemplo II
Las Reglas versión 2.0 se muestran en la siguiente imagen.
Imagen: Reglas Versión 2.0
Los resultados obtenidos al usar las reglas 2.0 son A=15, B=5, C=5, D=2 y E=7000, y para esto no tuvimos que compilar.
Buenos eso es, espero lo encuentren de tanta utilidad como yo!.
El ejemplo de este POST pueden descargarlo desde aquí.
Salu2
[1] External RuleSet Toolkit, http://wf.netfx3.com/files/folders/rules_samples/entry309.aspx
[2] Ejemplo de código de Reglas, http://desarrollo.datco.cl/materialpublico/Test2_Reglas.zip
Siguiendo con esta secuencia de POST orientados a tratar de explicar cómo funciona el motor de Reglas de Windows Workflow Foundation. En el primer POST tenemos se explica cómo funcionan la evaluación de reglas de un RulesSet y cómo se re evalúan por defecto.
En este pequeño POST trataré de explicar cómo se puede controlar la ejecución de reglas atómicas del RuleSet sin dependencia entre ellas. La idea es que en algunos escenarios complejos, quien escribe las reglas necesita tener mayor control sobre el comportamiento de las re evaluaciones, específicamente limitar la cantidad de reevaluaciones. Con esto se busca evitar loops infinitos, resultados erróneos por iteraciones de las reglas y algo no menor, mejorar el desempeño.
En nivel de control que permite Windows Workflow Foundation se puede configurar en dos puntos:
Esta propiedad actua a nivel de RuleSet, y tiene las siguientes tres posibilidades:
1. Full Chaining: este es el comportamiento por defecto que está descrito en el primero post de esta serie. Pueden verlo aquí.
2. Explicit Update Only: está opción deshabilita las dependencias implícitas y por atributos, dejando la posibilidad solo a las explicitas declaradas usando Update.
Un ejemplo sería con el RuleSet del código 1 y los métodos del código 2 utilizando Chaining Behavior con el valor por defecto Full Chaining el valor de salida de las variables A, B, C, D y E son 15, 5, 5, 2 y 7 respectivamente.
Ahora si se cambia la propiedad Chaining Behavior a Explicit Update Only, el resultado cambia a 15, 0, 5, 2, 0. Esto ocurre porque en este modo de se ignoran las dependencias declaradas como atributos.
|
Código 1
|
private int A = 0; private int B = 0; private int C = 5; private int D = 2; private int E = 0; //Omitido el resto del código….Ver el proyecto de ejemplo [RuleWrite("B")] private void CambiarB(int valor) { this.B = valor; } [RuleWrite("A")] private void CambiarA(int valor) { this.A = valor; } [RuleWrite("E")] private void CambiarE(int valor) { this.E = valor; } |
Código 2
Para poder obtener el mismo comportamiento que en la primera prueba tenemos que cambiar el RueSet a lo mostrado en el código 3.
|
Código 3
Al poner la dependencia de forma explícita entonces el motor de reglas cuando evalúa la regla 2, re evalúa a regla 4. El resultado obtenido es 15, 5, 5, 2 y 7 respectivamente.
3. Sequiencial: esta es la opción final y lo que hace es forzar a que el motor realice las evaluaciones en un orden línea estricto, es decir no re evalúa las dependencias.
Si al ejemplo anterior, le cambiamos el valor a Secuencial, entonces obtenemos el resultado 15, 0 ,5, 2 y 0 porque no hay re evaluación de la Regla 4
Está propiedad se aplica a nivel de Reglas y permite la re evaluación o no de la regla. Los valore posibles son:
En el ejemplo anterior, si la Regla 4 es marcada con Never entonces los valores de salida con 15, 0, 5, 2 y 0 porque la Regla 4 no se re evaluó.
Está función es muy interesante porque permite controlar la ejecución de dependencias entre reglas relacionadas. Al incluir Halt en la acción THEN o ELSE, entonces el RuleSet retorna de manera inmediata el control al código que lo invocó.
Con lo expuesto en este POST más el primer POST de RULE ENGINE ya se puede echar a volar la imaginación y buscar las aplicaciones prácticas de está tecnología. Yo ya la uso en proyectos Reales.
Espero seguir con otro Post (esto solo es una expresión de deseo) que muestra otros aspectos de Rules Engine de Windows Workflow Foundation.
EL código fuente del ejemplo mostrado se puede descargar desde aquí.
Salu2
La tecnología DotNet Framework 3.0 tiene un componente para implementar Workflow’s[0] llamado Windows Workflow Foundation [1]. Este no es un producto de Workflow sino un motor de workflow más herramientas para los desarrolladores para que construyan sus propias soluciones de Workflow.
Dentro de las cosas más interesantes que veo en WF se encuentra su motor de Reglas de negocio (Rule Engine)[2].
Rules Engine permite hacer desde evaluación de condiciones lógicas hasta la definición y evaluación de complejas reglas que conforman políticas. En este post voy a tratar de explicar cómo se implementan esas políticas y cómo podemos usarlas en nuestros Worklows.
Lo primero que hay que entender es que las políticas son definidas por un conjunto de reglas semánticas llamado RuleSet. Estas reglas son del estilo If/Then/Else. Para poder invocar desde un Workflow la evaluación de un RuleSet se usa la actividad Policy[3].
Las Reglas que componen un RuleSet tienen una propiedad llamada Priority, que permite asignarle una prioridad a cada regla. El procedimiento de Evaluación del RuleSet es el siguiente:
Veamos el siguiente ejemplo. Tenemos un Workflow sencillo de 3 Actividades, el que se muestra en la imagen 1. La primera actividad muestra los valores de las variables A, B, C, D, E en la consola. La segunda actividad es una Política que tiene 4 reglas que están priorizadas y la última muestra los valores después de aplicar el RuleSet de reglas.
Imagen 1: Workflow de Ejemplo y RuleSet.
El RuleSet se ve en la imagen 1. Las reglas se ejecutan desde la mayor prioridad (4) hasta la menor (1). El proceso en que se ejecutan las reglas es el siguiente:
Quedando cuando se ejecutan los valores mostrados en la imagen 2 en color Rojo.
Imagen 2: resultados.
Las dependencias entre las reglas son identificadas de tres maneras por el Rules Engine:
Este tipo de dependencia es la que vimos en el ejemplo 1, donde las acciones cambian valores que se usan en otras reglas.
La dependencia por atributos es usado en reglas que llaman a métodos en el Workflow. Como llama a un método no tiene como deducir implícitamente que reglas debe ReEvaluar. Para usar este tipo de dependencia se debe usar uno de estos tres atributos en el método:
Veamos un ejemplo para que sea más simple de entender. Tenemos un Workflow igual al anterior pero con el RuleSet mostrado en la imagen 3. Las reglas son las mismas que antes, pero en vez de cambiar los valores de las propiedades A,B, C, D y E directamente en la acción de la regla se invoca a un método.
El código de cada uno de los métodos invocados desde el RuleSet se muestra en el código 1.
Pueden ver en la imagen 4 que el resultado de la evaluación es el mismo que en ejemplo de reglas implícitas porque se hacen los mismos cambios de valores pero en métodos decorados con los atributos que le dan al motor de regla la información necesaria para actuar.
Imagen 3
|
[RuleWrite("B")] private void CambiarB(int valor) { this.B = valor; } [RuleWrite("A")] private void CambiarA(int valor) { this.A = valor; } [RuleWrite("E")] private void CambiarE(int valor) { this.E = valor; } |
Código 1.
La dependencia explicita se basa e declarar uno mismo los cambios que ocurren al ejecutar una acción. Para ello se usa la instrucción Update de esta forma Update("this/A") por ejemplo para indicarle al motor que el valor de la propiedad A cambio.
La única ventaja que he encontrado en la dependencia explicita es que se puede hacer por ejemplo esto Update("this/OrdenCompra/*") que le indica al motor que todos los atributos de la orden de compra cambian con esa acción. Esto es notable!!.
El próximo ejemplo se muestra en la imagen 4. Las reglas contienen ahora en la acción la directiva Update. El código de los métodos ya no tiene la directiva RuleWrite, por lo que el motor se entera del cambio de manera explícita. El código de los métodos de cambio, sin el atributo, se muestra en el código 2.
Por último el resultado sigue siendo el mismo!!! Y se muestra en la imagen 4.
Imagen 4.
|
private void CambiarB(int valor) { this.B = valor; } private void CambiarA(int valor) { this.A = valor; } private void CambiarE(int valor) { this.E = valor; } |
Código 2.
Imagen 4
El motor de reglas es mucho más potente de lo que se muestra en este POST, espero seguir explicando cómo funciona en una serie de post que quiero hacer sobre Windows Forkflow Foundation Rules Engine.
El código fuente de los ejemplos pueden descargarlos dese este Link
Salu2
[0] Sistemas de Workflow, http://es.wikipedia.org/wiki/Sistemas_de_workflow
[1] Windows Workflow Foundation, http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx
[2] Introduction to the Windows Workflow Foundation Rules Engine, http://msdn2.microsoft.com/en-us/library/aa480193.aspx
[3] Introducing Microsoft Windows Workflow Foundation: An Early Look , http://msdn2.microsoft.com/en-us/library/aa480215.aspx
Hoy 4 de septiembre hicimos con Luis y Mauricio una conferencia de procesos de negocio soportados por Windows Workflow Foundation y Windows Comunication Foundation.
En esta presentación mostré ejemplos básicos de WF que pueden descargar desde aquí.
Además al final mostramos una demo de una seguradora de autos que el proceso de venta es llevado adelante en WF. Este ejemplo pueden bajarlo desde acá (Parte WF).
Como siempre es un gusto participar de estos eventos, además quedo contento por la cantidad de preguntas que mi hicieron. Se nota que hay interés en la materia.
Por último la PPT (parte WF) pueden bajarla desde aquí.
Salu2
Hola,
Me llegó la siguiente pregunta, muy interesante por eso la subo aquí a la sección de Q&A del Blog.
Una empresa quiere desarrollar una aplicación móvil en Windows Mobile que funcione desconectada con datos extraídos de SAP en la mañana (usando la cuna) y por la tarde poniéndolos en el móvil en la cuna subir los datos nuevamente. Para ello utiliza un Web Service que expone el módulo Business Connector.
¿Cómo hacer eso? ¿Usar Active Sync?
En este caso se me ocurren dos soluciones, la primera 100% implementada en Service-Oriented y la segunda una combinación de Data-Centric y Service-Oriented. Para los que no estén familiarizados con estos conceptos, pueden ver este POST.
Que la aplicación móvil consuma los servicios Web de descarga de datos directamente (cuando está en la cuna) e inserte los valores en la DB. Luego la aplicación trabaja desconectada para al final del día cuando sea puesta en la cuna subir los datos a través de un Servicio Web de Update y solución de conflictos.
En esta solución se utilizaría una base de datos intermedia (MSSQL2005) la cual utilizando SSIS cargaría los datos desde SAP a través del Web Services. Luego, utilizando replicación con la PDA transfiere los datos necesarios para móvil. Luego al final del día se sincronizan los datos utilizando las facilidades de MSSQL y su motor de resolución de conflictos. Por último, SSIS pasa los datos ya consolidados desde MSSQL a SAP a través del Web Services de Upload.
Los Pro y contras de cada solución.
|
Aspecto |
Service-Oriented |
Mixta |
|
Esfuerzo de programación. |
Alto, la resolución de conflictos no es simple |
Si MSSQL resuelve los conflictos es trivial. |
|
Costos Licenciamiento |
Sin costos adicionales. |
Licencia de MSSQL 2005 |
|
Rapidez de descarga |
Está es más rápida, no tiene SSIS intermediando ni el servicio de replicación de MSSQL. |
Tiene una pieza intermedia extra. |
|
Efectividad en resolución de conflictos en datos |
Puede ser 100% efectiva, todo depende de la lógica programada. |
Tiene las limitaciones del motor de resolución de conflictos de MSSQL, que no es malo pero tiene sus limitaciones. |
|
Administración |
Solo se requiere instalar la aplicación. |
Además de instalar la aplicación hay que configurar en cada equipo la replicación. |
|
Conocimientos del equipo |
Web Services. Aplicaciones Móviles. TSQL |
Web Services Aplicaciones móviles SSIS y TSQL |
En mi opinión yo tomaría la opción 1 si tengo un equipo de desarrollo con experiencia. Si no es así me iría por la opción mixta, para no tener que programar la resolución de conflictos.
Salu2
Los desarrolladores de aplicaciones móviles independiente de la tecnología que utilicen manejan el concepto de computación ocasionalmente conectada (OCC).
Las aplicaciones OCC tienen que tomar una decisión de arquitectura muy importante para enfrentar este problema: Data-Centric y Service-Oriented.
Las aplicaciones que utilizan la estrategia de Data-Centric tienen una base de datos relacional (RDBMS) en el cliente. Las capacidades de esta base de datos son utilizadas para propagar los cambios en los datos locales al servidor, administrando el proceso de sincronización, detectando y resolviendo los conflictos de datos.
La segunda aproximación es utilizar Service-Oriented, que almacena los datos locales en mensajes que son puestos en colas cuando el cliente está fuera de línea. Después que se restablece la conexión esos mensajes son enviados al servidor para ser procesados.
A continuación se desarrollan ambas aproximaciones.
Cuando se usa está aproximación, el servidor publica los datos a ser utilizados y los clientes se suscriben a los datos que necesitan, entonces obtienen una copia de los datos que necesitan antes de desconectarse.
Mientras la aplicación esta fuera de línea, los cambios son hechos sobre los datos locales mediante la interacción de la aplicación con sus datos locales.
Cuando el dispositivo vuelve a conectarse, la base de datos local propaga los cambios realizados a los datos locales. También, los cambios hechos en el servidor central son propagados hacia el cliente.
Cualquier conflicto ocurrido durante la fase de unión de los datos es manejado por el motor de resolución de conflictos, en base a reglas. Estas reglas son implementadas tanto en el servidor como en el cliente, de acuerdo a las propias reglas de negocio de la aplicación.
El proceso de fusión (Merge) de los cambios en los datos es conocido cómo Merge Replication. Los cambios pueden ocurrir de manera autónoma tanto el servidor como en el cliente, por esto no se utilizan transacciones ACID. En vez de una transacción, cuando se realiza el merge, todos los suscriptores recibirán el dato cambiado en el publicador.
La principal ventaja de usar esta aproximación es que todo el seguimiento de los cambios está contenido dentro de las funcionalidades de la base de datos. Generalmente, la base de datos incluye código para detectar conflictos de datos a nivel de filas y columnas a nivel de base de datos, códigos de validación y restricciones del dato. En este sentido el único trabajo que se debe hacer es armar el esquema de replicación para la aplicación móvil que optimice la resolución de conflictos y actualización de datos.
En este modelo, la sincronización de los datos es responsabilidad del motor de datos, por lo tanto, no es necesario codificar funcionalidades para ello. Se define que tablas son las que necesitan ser sincronizadas y el motor de datos se encarga de llevar el rastro de los datos, sincronizarlos y resolver conflictos. En este punto, la resolución de conflictos, si los criterios que vienen no son suficientes, pueden extenderse utilizando código.
Por otra parte, al existir una base de datos central, después que los clientes sincronizan los datos, se puede asegurar la convergencia de los datos es completa.
Las desventajas que aparecen al usar este modelo son las siguientes:
Los escenarios recomendados para usar esta aproximación son:
Ø Se puede sincronizar utilizando HPPTS, VPN o la LAN.
Con esta aproximación, los clientes interactúan con el servidor central consumiendo servicios a través de mensajes definidos. Pueden tener o no un cache de datos local. La ventaja es que no se necesita una base de datos local instalada en el cliente. Esto significa que está aproximación puede ser aplicada a muchos tipos de dispositivos sin las restricciones del uso de un motor de base de datos local.
El uso de está aproximación de servicios es particularmente apropiada cuando las aplicaciones deben operar en ambientes como Internet y Extranet. Esto porque es posible habilitar en el firewall la entrada de las peticiones de los clientes, por ejemplo Web Service.
El uso de servicios permite mantener bajo acoplamiento, lo que significa que puede interactuar con diferentes esquemas de base de datos.
La principal desventaja de está aproximación es que es responsabilidad del constructor del sistema codificar toda la funcionalidad que guarda relación con el modelo transaccional de Store and Forware de mensajes, como también implementar la contención de transacciones cuando el cliente está fuera de línea.
El uso de una aproximación de servicios se desempeña mejor en escenarios en los que la aplicación necesita interactuar con muchos servicios diferentes, provistos por diferentes servidores. Se comporta muy bien con múltiples trasportes, ya que es independiente el mensaje al trasporte usado. Por ejemplo un trasporte es Web Services.
Los escenarios recomendados para usar esta aproximación son:
Si se quiere desarrollar aplicaciones OCC utilizando una orientación de servicios se deben considerar los siguientes puntos principales:
..:: Liarjo of Locksley ::.. 