BPM a nivel técnico: tres clases de artefactos

27 Oct 2011 en Management

 Antes de entrar en el tópico, cabe aclarar que estos artículos que hoy les presentamos se basan en material elaborado por la firma investigadora Ovum, del grupo Datamonitor. De hecho, el enfoque adhiere a lo que se conoce como Artifact-centric Business Process Model. Este modelo operacional de procesos implica que los cambios en los datos del negocio o sus entidades, son consideradas como los mayores descriptores de la ejecución de procesos.

Antes de entrar en el tópico, cabe aclarar que estos artículos que hoy les presentamos se basan en material elaborado por la firma investigadora Ovum, del grupo Datamonitor. De hecho, el enfoque adhiere a lo que se conoce como Artifact-centric Business Process Model. Este modelo operacional de procesos implica que los cambios en los datos del negocio o sus entidades, son consideradas como los mayores descriptores de la ejecución de procesos. Este enfoque difiere del modelo conocido como Activity-centric o Process-centric. El modelo de artefactos se centra en describir la forma en que los datos del negocio son modificados o actualizados por una tarea o acción en especial a través de los procesos. A nivel técnico, se pueden crear servicios o elementos funcionales de procesos con alguno de estos tres artefactos: objetos, componentes o Web services. Los componentes y Web services (que son tipos de componente no específicos), son los únicos que permiten la definición de granularidad funcional por parte del usuario final. Los objetos deben encajar en la estructura de herencias por jerarquía de clases que hacen a su naturaleza. Un servicio en forma de objeto se limitará a la definición de su árbol de jerarquías. No se pueden combinar entidades de diferente clase en un objeto sin antes definir un nuevo tipo de entidad y es imposible crear una clase desde múltiples entidades dentro del paradigma de orientación a objetos. Los objetos, componentes y Web services tienen algunas características en común: Todos son estructuras de código que se crean para ejecutar una pieza específica de funcionalidad. Todas pueden ser implantadas dentro de un motor de procesos. La descripción de su funcionalidad se accede mediante sus respectivas interfases. Su propósito es el de ocuparse de una actividad dentro de una estructura mayor de proceso. Son ?dóciles,? ya que esperan a ser invocados desde un cliente antes de completar su función. Aparte de estas similitudes, existen diferencias entre estos tres artefactos: Ubicación- Define la ubicación relativa de los procesos en los que existen el artefacto y el cliente. Entorno- Define el runtime del artefacto y el cliente. La ubicación y el entorno definen si la relación entre artefactos y clientes es de objetos, de componentes o si tiene un requerimiento para Web service. Si el artefacto y el cliente existen dentro de un mismo entorno de proceso, la relación entre objetos. Si el artefacto y el cliente están en diferentes procesos pero en el mismo entorno, la relación es entre componentes y es definida por el entorno. Por ejemplo, desplegando una JavaBean empresarial en el motor de proceso. Si el cliente y artefacto están en diferentes entornos es una relación de Web services. Aquí el entorno es el factor de definición y no es necesario entender la posición artefacto/cliente respecto a los procesos. Una vez que se comprende la relación ubicación/entorno, se puede definir el requerimiento de capacidad transaccional. Existe una diferente jerarquía de eficiencia para estos artefactos: Los objetos son más eficientes que los componentes y éstos más que los Web services. La eficiencia de los objetos es inherente dentro de la estructura ya que los objetos no tienen que abarcar procesos. De esa manera, el mapeado de invoación de métodos al código pueden ser desempeñados usando una búsqueda de tabla optimizada para un entorno discreto. Los componentes requieren un mecanismo de transporte inter-proceso que genera la invocación de la interfaz para traducir el requerimiento de método a un método de resolución usando un proxy. Para el cliente, la invocación de método es vista como una resolución de código nativo, pero el proxy tiene que hacer un trabajo adicional para que esto aparezca así y eso reduce la eficiencia. Los Web services deben cruzar fronteras entre entornos y para ello necesitan protocolos de transporte estandarizados. Esto equivale a SOAP sobre HTTP, pero existen otras opciones que reducen la sobrecarga. Como con otros aspectos de la interconexión, la conectividad no nativa tiene un overhead que impacta en la eficiencia.