WS-AtomicTransaction

WS-AtomicTransaction (WS-AT) es un protocolo de transacción interoperable. Permite el flujo de transacciones distribuidas mediante el uso de mensajes de servicios web y coordina de una manera interoperable entre infraestructuras de transacción heterogéneas. WS-AT utiliza el protocolo de ejecución en dos fases para crear un resultado atómico entre aplicaciones distribuidas, administradores de transacciones y administradores de recursos.

La implementación proporcionada de WS-AT en Windows Communication Foundation (WCF) incluye un servicio de protocolo incorporado en el administrador de transacciones del Coordinador de transacciones distribuidas de Microsoft (MSDTC). Las aplicaciones WCF pueden tener flujos de transacciones a otras aplicaciones mediante WS-AT, incluyendo servicios Web interoperables creados utilizando la tecnología de terceros. 

Cuando circula una transacción entre una aplicación cliente y una aplicación de servidor, el protocolo de transacción utilizado es determinado por el binding que expone el servidor en el endpoint del cliente seleccionado. Algunos Binding proporcionados para WCF por defecto especifican el protocolo OleTransactions como el formato de propagación de transacción, mientras que otros por defecto la especificación WS-AT. También mediante programación puede modificar la elección del Protocolo de transacción dentro de un binding determinado.

La elección del protocolo influencia en:

  • El formato de los encabezados de mensaje utilizados para el flujo de la transacción del cliente al servidor.
  • El protocolo de red utilizado para ejecutar el protocolo de ejecución en dos fases entre el administrador de transacciones del cliente y la transacción del servidor, con el fin de resolver el resultado de la transacción. 

Si el servidor y el cliente son escritos utilizando WCF, no se necesita utilizar WS-AT. Por el contrario, se puede utilizar la configuración predeterminada de NetTcpBinding con el atributo TransactionFlow activado, la cual utilizará el protocolo OleTransactions en su lugar.

Esta especificación define los siguientes protocolos para transacciones atómicas.

Completion: El protocolo de terminación inicia proceso el de compromiso. Basado en los participantes inscritos de cada protocolo, el Coordinador inicia con 2PC volátil luego procede a través de 2PC Durable. El resultado final es señalado al iniciador.

Two-Phase Commit (2PC): El protocolo 2PC coordina participantes registrados para alcanzar una decision de commit o abort, y asegura qur todos los participantes sean informados del resultado final. El protocolo 2PC tiene 2 variantes:

  • Volatile 2PC: los participantes gestionan recursos volátiles tales como una memoria caché debe registrarse para este protocolo.
  • Durable 2PC: los participantes gestionar recursos durables tales como una base de datos debe registrarse para este protocolo.

 Un participante puede inscribirse en más de uno de estos protocolos enviando múltiples mensajes de registro.

Posted in Uncategorized | Leave a comment

Introducción A servicios RESTful con WCF

Antes que nada los servicios RESTFUL sigue un estilo de arquitectura, conocido como Representational estado transferencia (REST). Un estilo de arquitectura es un conjunto de restricciones que se pueden aplicar al crear algo. Y un estilo de arquitectura de software es algo que se describen las características que pueden utilizarse para guiar la implementación de un sistema de software. REST es un estilo de arquitectura que se puede utilizar para crear software en el que los clientes (agentes de usuario) pueden efectuar peticiones de servicios (extremos). REST es una forma implementar un estilo de arquitectura de cliente /servidor, de hecho, REST explícitamente se basa en el estilo de arquitectura de cliente/ servidor.

 Un hombre denominado Roy Thomas Fielding acuñó primero el término REST como un concepto en su (de disertación PhD “Estilos de arquitectura y el diseño de arquitecturas de software en función de red “). Era uno de las personas que trabajaron en la especificación que conduce la mayor parte de Internet de hoy: Protocolo de transferencia de hipertexto (HTTP).Normalmente el fondo de las personas que describen un estilo de arquitectura no es relevante para una explicación del estilo, pero aquí CREO que es importante porque CREO que una de las mejores maneras de obtener una comprensión básica de REST consiste en pensar en el Web y cómo funciona.

WCF y REST

WCF es el marco de Microsoft para crear aplicaciones que se comunican a través de una red, con independencia del protocolo o estilo. El concepto de WCF consistía en crear un marco que estaba extensibles y conectables para obtener información acerca de un modelo de programación y de configuración, para que los desarrolladores puedan aplicar esos conocimientos a diversos tipos diferentes de sistemas distribuidos.
Aunque es verdad que gran parte de WCF está orientado a RPC (mediante SOAP), realmente ha tenido la posibilidad de exponer y consumir servicios REST ya que en primer lugar se lanzó como parte de .NET Framework 3.0. Con el assembly System.ServiceModel.Web del .NET Framework 3.5  se ha agregado un modelo de programación y tambien algunas piezas de infraestructura que fueron construidos para trabajar con el estilo REST. Y el .NET Framework 3.5 SP1 agrega unas pequeñas mejoras para hacer mas fácil el uso de REST.
El modelo de programación centra alrededor de dos nuevos atributos, WebGetAttribute y WebInvokeAttribute y un mecanismo de plantilla de identificador URI que permite declarar el identificador URI y el verbo a la que cada método va a responder. La infraestructura se incluye en forma de un enlace (WebHttpBinding) y un comportamiento (WebHttp­Behavior) que proporcionan la pila de red correcta para utilizar REST. Además, hay alguna ayuda de infraestructura de alojamiento de un Service­Host personalizado (WebServiceHost) y un ServiceHostFactory (WebServiceHostFactory).
Posted in Uncategorized | Tagged , | Leave a comment

Metodologías para el Desarrollo de Servicios en la Web

Coulouris definió los sistemas distribuidos como “sistemas en los que los componentes hardware y/o software existentes en una red de computadoras, se comunican y coordinan sus acciones mediante el intercambio de mensajes”.

Este concepto se ha popularizado durante los últimos años, debido a varios factores. El primer factor que impulsó el desarrollo de sistemas distribuidos fue la aparición de redes locales de alta velocidad. Otro factor importante ha sido el avance tecnológico en las prestaciones de los ordenadores personales y el desarrollo de software para soportar aplicaciones distribuidas. Los sistemas distribuidos se ligan con el concepto de Web e Internet. Con la evolución de la Web, y la aparición de nuevas áreas, interacciones, necesidades y aplicaciones, surge el concepto de Web 2.0. Este término fue acuñado por Tim O’Reilly en 2004 para referirse a una segunda generación en la historia de la Web basada en comunidades de usuarios y una gama especial de servicios, como las redes sociales, los blogs, los wikis o las folcsonomías, que fomentan la colaboración y el intercambio ágil de información entre los usuarios.

Las primeras arquitecturas que pueden considerarse orientadas a servicio (SOA) se basaban en CORBA (Common Object Request Broker Architecture), que actuaba como una capa de abstracción para interconectar los distintos elementos de la arquitectura y construir los servicios. Otras tecnologías anteriores fueron DCOM (Distributed Component Object Model) o RPC (Remote Procedure Protocol). Con la necesidad de diseñar e implementar sistemas distribuidos en la Web de forma eficiente, surgen diversos desafíos, algunos centrados en el propio desarrollo (rendimiento, experiencia de usuario, etc.) y otros complementarios, basados en la reusabilidad y compatibilidad de los servicios. Sobre estas necesidades aparecen los Servicios Web, proporcionando mecanismos estándar para interconectar a los distintos usuarios con los servidores de información.

ARQUITECTURAS ORIENTADA A SERVICIOS

Según  SOA (Service‐Oriented Architecture) son arquitecturas de software que definen el uso de servicios como soporte a los requisitos del negocio, cuyo objetivo es alcanzar el mínimo acoplamiento posible entre agentes software. Un servicio es una unidad de trabajo realizada por un proveedor de servicios para alcanzar un resultado final deseado por un consumidor del servicio. Tanto el proveedor como el consumidor del servicio son roles realizados por agentes software en lugar de sus propietarios. En un sentido general, una arquitectura orientada a servicios es una solución software que pretende permitir a la empresa organizar y hacer uso de múltiples procesos. Con SOA, las aplicaciones software ya no son enormes bloques de funciones y procesos. En cambios, estas aplicaciones se componen de servicios modulares ensamblados. Recordemos que un servicio es una función software simple (como por ejemplo, cancelar la reproducción de un CD). Puede ser ejecutada bajo demanda por cualquier sistema, sin tener en cuenta el sistema operativo, plataforma, lenguaje de programación o posición geográfica.

Lo que es revolucionario acerca de SOA no es el concepto en sí mismo, el cual ha estado presente desde hace tiempo, sino el hecho de que se puede implementar a través de la WWW (World Wide Web). De la misma forma que las páginas web se cargan en cualquier plataforma, los servicios web trabajan de forma similar, sin tener en cuenta la plataforma, ya que se construyen utilizando
estándares universales.

ImageLa idea de SOA parte directamente de la programación orientada a objetos, la cual sugiere una relación entre los datos y su procesamiento. Así, definen los servicios formalmente a través de interfaces independientes de la plataforma subyacente y del lenguaje de programación. Estas interfaces ocultan las particularidades de su implementación, lo que las hace independientes del desarrollador y del lenguaje de programación. A través de estas arquitecturas se consiguen diseñar e implementar sistemas altamente escalables que reflejan la lógica de negocio y a la vez facilitan la interacción entre distintos sistemas propietarios o de terceros. La razón por la cual queremos que alguien haga el trabajo por nosotros es porque es experto. Utilizar un servicio es generalmente más barato y efectivo que hacerlo por nosotros mismos. Así, la mayoría de nosotros comprendemos que no podemos ser expertos en todo. La misma regla se puede aplicar a la construcción de sistemas software.

Las interfaces son tremendamente importantes, si éstas no han sido bien definidas o no funcionan, el sistema no funciona. Integrar más interfaces es caro, y además incrementa la posibilidad de errores en aplicaciones distribuidas. Las interfaces remotas son la parte más lenta de la mayoría de las aplicaciones distribuidas. Con todo esto, en lugar de construir nuevas interfaces para cada aplicación, tiene más sentido reutilizar unas genéricas para todas las aplicaciones.

Así, ya que sólo disponemos de unas pocas interfaces genéricas disponibles, debemos incluir dentro de los mensajes semántica específica sobre las aplicaciones. Podemos enviar cualquier tipo de mensaje sobre nuestras interfaces, pero hay unas pocas reglas a seguir para poder decir que una arquitectura es orientada a servicio. 

‐ Primero, los mensajes deben ser descriptivos, más que instructivos, porque el proveedor del servicio es responsable de resolver el problema. Por ejemplo, sería similar a la situación de ir a un restaurante y decir al camarero lo que te gustaría tomar y tus preferencias, pero no deberíamos explicar al cocinero cómo cocinar tus platos, paso por paso. 

‐ Segundo, los proveedores de servicio no serán capaces de entender tu petición si tus mensajes no están escritos en un formato, estructura y vocabulario comprensible por todos los involucrados. Así, limitar el vocabulario y la estructura de los mensajes es una
necesidad para lograr una comunicación eficiente. Cuanto más restringido sea el mensaje, más sencillo es entenderlo.

‐ Tercero, la posibilidad de extensiones es de vital importancia. El mundo es un sitio cambiante en todo momento, y de forma similar es el entorno en el que vive el software. Estos cambios demandan cambios correspondientes en el sistema software, consumidores de servicios, proveedores, y los mensajes que intercambian. Si los mensajes no son extensibles, los consumidores y proveedores estarán bloqueados en una versión concreta del servicio. Restricción y extensibilidad están profundamente relacionadas, se necesitan ambas, e incrementar una supone una reducción de la otra. Lo ideal es lograr un correcto balance.

‐ Cuarto, una SOA debe poseer un mecanismo que permita al consumidor descubrir un proveedor de servicios bajo el contexto de un servicio buscado por el consumidor. El mecanismo debe ser flexible, y no debería ser un registro centralizado.

‐ Quinto, Servicio stateless (sin estados): Cada mensaje que envía un consumidor a un proveedor debe contener toda la información necesaria para que el proveedor la procese. Esta restricción hace más escalable a un proveedor de servicio puesto que el proveedor no tiene que almacenar información de estado entre peticiones. Esto se puede denominar “servicio de producción en masa” ya que cada petición puede ser tratada de manera genérica. Esta restricción además provee de más visibilidad, ya que cualquier software de monitorización puede inspeccionar una petición independiente y extraer su intención. Esto permite además la recuperación de forma sencilla de fallos parciales, puesto que no hay estados intermedios, haciendo el servicio más fiable.

‐ Sexto, Peticiones idempotentes (que no realizan ningún cambio): Las peticiones duplicadas recibidas por un agente software tienen el mismo efecto que una petición única. Este requisito permite que los proveedores y consumidores incrementen la fiabilidad total del servicio, simplemente repitiendo la petición si ha habido algún fallo.

Podemos decir entonces, que SOA no es una herramienta, sino un conjunto de patrones de construcción de nuevas aplicaciones más dinámicas y menos dependientes. SOA facilita el acceso a la lógica de negocios y la información entre diversos servicios de una manera sistemática, pudiendo además orquestar diversos servicios remotos para componer uno único. La mayoría de las definiciones identifican la utilización de Servicios Web, los cuales veremos en el siguiente  capítulo, en la implementación de una arquitectura orientada a servicios. No obstante, se puede implementar utilizando cualquier otra tecnología basada en servicios.

Posted in Uncategorized | Tagged , , | Leave a comment

Metodología para la identificación de inputs y outputs de procesos de negocio en un entorno colaborativo

La identificación de inputs y outputs es un aspecto de vital importancia en el modelado de procesos de negocio, estando además muy ligado a la definición del sistema de información que soporta la ejecución de los procesos.

Se propone una Metodología para la identificación y modelado de inputs y outputs de Procesos de Negocio en un Entorno Colaborativo.

Las inputs y outputs de procesos de negocio, se han abordado desde diferentes disciplinas de trabajo: Gestión de Procesos de Negocio, Arquitecturas de modelado empresarial o la  Ingeniería de Requisitos Software. En un entorno colaborativo los procesos de negocio tienen una serie de diferencias respecto a los procesos de negocio tradicionales. Por una parte

la ejecución de las actividades del proceso son responsabilidad de dos o más entidades (empresas, cadenas de suministro o redes), y con ello la problemática del sistema que da soporte a los procesos y el sistema de información asociado, por otra parte las relaciones colaborativas transforman el modo de compartir información entre entidades.

                                              

En el ámbito de la Gestión de Procesos de Negocio se proporcionan técnicas y herramientas que consideran inputs y outputs de los procesos. Algunas de estas técnicas son (Aguilar-Saven, 2004): Flow chart, Diagramas de flujo de datos (Data Flow Diagrams-DFD), Diagramas de actividades y roles (Role Activity Diagrams-RAD, Diagramas de interacción de roles (Role Interactions Diagrams-RID), Diagramas de Gantt, IDEF (Integrated Definition for Function Modelling), Redes de Petri coloreadas (Couloured Petri-net-CPN), Métodos orientados a objetos (Object Orientation-OO) o Técnicas de Workflow. Las arquitecturas de modelado empresarial se acercan al modelado de procesos de negocio utilizando para ello distintas vistas de modelado. Cada vista focaliza y trabaja en una par te específica del modelo de empresa integrado (Toh, 1999).

 

Cada arquitectura de modelado propone sus propias vistas de modelado, por ejemplo: AIMOSA (Vistas de Organización, Recursos, Información y Función), GRAI-GIM (Vistas del

Sistema Físico, Decisional, de Información y Funcional), PERA (Arquitectura de Organización y RR.HH., del Sistema de Información y del Equipo de Producción), GERAM (Vistas de Organización, Recursos, Información y Función), ARIS (Vistas de Función, Datos,

Organización y Control). Las inputs y outputs de los procesos se han abordado principalmente desde la vista funcional y la vista de información (Melao y Pidd, 2000). Por último, la Ingeniería de Requisitos software permite identificar los elementos que necesitan ser representados en los modelos cuya finalidad sea el diseño de un sistema de información, y que por tanto, consideran explícitamente la relación de los procesos de negocio con los sistemas informáticos.

 

La Ingeniería de Requisitos trata de comprender las necesidades exactas de los usuarios del sistema software, para traducir tales necesidades en instrucciones precisas y no ambiguas las cuales podrían ser posteriormente utilizadas en el desarrollo del sistema.

 

Las distintas disciplinas de trabajo, proporcionan diferentes herramientas de modelado e incorporan, en muchos casos, sus propias metodologías (Cuenca et al., 2006). Las metodologías de modelado de proceso son dependientes del modelo a desarrollar. Desde una perspectiva global, la información relevante para documentar un proceso contiene la definición del objetivo, alcance, términos y definiciones, responsabilidad y autoridad, actividades que se llevan a cabo, inputs y outputs, indicadores, recursos, infraestructura e interrelaciones con otros procesos (Arrascaeta, 2005, y Athena, 2004). Lin y Polenske (1998) presentan un modelo de inputs y outputs del proceso de producción. Este modelo proporciona una descripción matemática de las inputs y outputs existentes en el proceso de producción con el fin de proporcionar información para la toma de decisiones, donde la actividad productiva de una empresa es considerada como un conjunto de procesos de producción que combinan diferentes factores para producir resultados. Sin embargo, este enfoque no tiene en cuenta las relaciones entre el proceso y sus clientes y proveedores.

 

Cheng-Leong et al. (1999) diferencia dos tipos de inputs y outputs: de información y de material. En un contexto de cadena de suministro el modelo SCOR (Supply Chain Operational

Reference Model) se utiliza para mejorar la comunicación entre las empresas de la cadena de suministro y sus sistemas de información (Athena, 2004).Albino et al. (2002) proponen un enfoque basado en inputs y outputs de procesos de producción, utilizado para desarrollar modelos específicos que investiguen los flujos entre procesos de producción, ya sea de una cadena de suministro global o de una parte de la cadena. Hernández et al. (2008) distinguen entre flujos de producto (inputs y outputs a los procesos de transformación), flujos de información (inputs y outputs a los procesos de transformación de la información) y flujos de decisión (procesos de decisión y sus relaciones).

 

La identificación de inputs y outputs de un proceso es un requerimiento a cumplir en el modelado de procesos de negocio, sin embargo las propuestas analizadas no detallan cómo se debe realizar. Esto justifica la necesidad de una metodología que ayude a la identificación y análisis de inputs y outputs de procesos de negocio.

Metodología propuesta para la identificación y modelado de Inputs y Outputs de procesos de negocio en entorno colaborativo

 

Mediante la metodología se identificarán inputs y outputs de proceso desde el punto de vista del flujo de la actividad que se desarrolla. En este sentido, las inputs son transformadas o utilizadas durante la actividad para producir una salida u output. La metodología propuesta sigue una aproximación a los procesos de arriba abajo (Top-Dow) de forma que se identifiquen, en este orden, los inputs y outputs de los procesos, de los subprocesos y de las actividades.

 

Los pasos a seguir para cada proceso, subproceso o actividad son:

 

1. Identificar el proceso, subproceso o actividad: es preciso identificar inequívocamente el  proceso, subproceso o actividad sobre el que se realizarán los siguientes pasos de la metodología.

2. Identificación de outputs (resultados): se deben diferenciar las outputs del proceso que proporcionan valor al cliente, de otras outputs del proceso consecuencia de la actividad de transformación de las inputs en las outputs de valor:

 

a) ¿Qué outputs (resultados) de valor para el cliente proporciona el proceso?

b) ¿Qué otras outputs genera el proceso como consecuencia de la trasformación de las inputs?

 

Para cada output:

 

2.1. ¿Se trata de una output de información o material?: los procesos pueden proporcionar outputs de información o de objetos materiales. En la metodología se entiende que pueden aparecer:

 

— Output de datos o información: datos o información que son producidos por la actividad o proceso.

— Output de objetos (o materiales): objetos que son producidos por la actividad o proceso.

 

2.2. ¿Quién es el cliente o destinatario?: La output del proceso está justificada al proporcionar valor a un determinado cliente (2a).

 

En el caso de otras outputs como consecuencia del proceso de transformación (2b) es posible hablar de destinatario de la output.

 

2.3. Especificación de la output: es necesario especificar la output con el objetivo de identificarla claramente según su propia naturaleza, y desde la perspectiva del destinatario de dicha output. Esto último condiciona el hecho de que la output tenga o no el valor esperado por el cliente:

 

2.3.1. ¿Cuál es la especificación de la output desde la perspectiva del cliente o destinatario?

2.3.2. ¿Cuál es la especificación correspondiente a su propia naturaleza según se trate de  información u objeto?

 

3. Identificación de las inputs: Las inputs al proceso pueden ser de diferentes tipos. IDEF0 incluye en su modelo de proceso los siguientes elementos básicos que pueden ser entendidos como inputs al proceso: autoridad (descripción, especificación o justificación de un proceso), control (condiciones que activan el proceso), inputs (objeto que entra al proceso), y  mecanismos (recursos que utiliza el proceso).

 

En la metodología propuesta se identifican únicamente las inputs que entran en el proceso para ser transformadas o utilizadas con el fin de producir una output.

 

Para cada input:

 

3.1. ¿Se trata de una input de información o material?: en la metodología se entiende que pueden aparecer 2 tipos de inputs:

 

— Input de datos o información: Datos o información que son transformados o utilizados por la actividad o proceso para producir una output.

 

— Input de objetos (o materiales): Objetos que son transformados o utilizados por la actividad o proceso para producir una output.

 

3.2. ¿Quién es el proveedor u origen?: una información necesaria en la identificación de las inputs es el proveedor u origen que proporciona la input, en el caso de que se tengan establecidas o se desee establecer algún tipo de relación.

 

3.3. Especificación de la input: es necesario especificar la input con el objetivo de identificarla claramente según su propia naturaleza, y desde la perspectiva de la actividad que transforma o utiliza dicha input, ya que, esto último condiciona el hecho de que la input cumpla los  requerimientos necesarios en la actividad para transformarse en una output:

 

3.3.1. ¿Cuál es la especificación de la input desde la perspectiva de la actividad?

3.3.2. ¿Cuál es la especificación correspondiente a su propia naturaleza según se trate de información u objeto?

Posted in Uncategorized | Tagged , , , | Leave a comment

Segmentos de autos

La mecánica de los autos no es la única que ha evolucionado, la carrocería en cuanto a su diseño también lo ha hecho para responder a todos los gustos, estilos y necesidades de los usuarios. 

En el mundo existe una gran gama de marcas, modelos, diseños y colores de autos que se clasifican de acuerdo a un segmento, es decir, características tales como el tamaño, distribución del espacio interior y diseño exterior. El lenguaje de las carrocerías no es del dominio popular, prueba de ello es que en los concesionarios resulta frecuente preguntar; ¿Qué es un monovolumen?, ¿Cuál es la diferencia entre una SUV y un crossover?, ¿Por qué existe la versiónsedan y hatchback del mismo auto?, por mencionar algunas.

A continuación te explicamos cada uno de los segmentos que existen en el mercado con un ejemplo para que te sea más fácil identificarlos:

1. Coupé; son autos de dos puertas con el interior reducido, generalmente tienen dos plazas aunque pueden tener asientos traseros. Están armados sobre la plataforma de algunos sedanes o berlinas y a pesar de tener dos puertas suelen ser largos de tamaño. Su diseño es deportivo y la cabina permite un viaje placentero para 1 o 2 personas. Los autos coupé surgieron con la idea de crear vehículos con motores muy avanzados para la época, de 6 cilindros o más en línea o en V, lo que otorgaba mayor potencia con máquinas de 3.0 L a 6.0 L y con un sonido robusto debido a la poca compresión que estos producían. Ejemplos de ellos son el vHemiCamaroCorvette, el Accord Coupe, el Civic Coupe. Con el paso del tiempo su tamaño y peso fueron reduciendo, requiriendo de motores más livianos sin dejar de tener el mismo performance deportivo.

2. Hatchback; son autos del segmento mediano o compacto que tienen lacajuela integrada a la cabina. También se los conoce como autos 3 puertas y ofrecen un mejor aprovechamiento del espacio. En algunos modelos el asiento trasero es abatible, lo que permite agrandar el espacio trasero. Su uso es urbano debido a que ocupan poco espacio. Los hatchbacks surgieron con la idea de crear un automóvil económico, con el paso del tiempo fueron evolucionando creándose así nuevos modelos de distintas marcas como: Peugeot 307Renault clío,Volkswagen PointerFord Fiesta o Ford KaToyota Yaris y Honda Fit, entre otros. Estos autos se convirtieron rápidamente en los favoritos de los jóvenes y mujeres. Los motores fueron cambiando de acuerdo a las normas de contaminación y se fueron ajustando al menor consumo, como sucedió con el cambio del carburador a la inyección indirecta. Algunos modelos fueron evolucionando sus versiones más deportivas como el famoso Volkswagen GTI, un auto pequeño con motor de altas prestaciones ideal para los que buscan emociones fuertes.

3. Cabriolet o convertible; son automóviles con techo retráctil que deja el habitáculo al aire libre. El material con el que está fabricada la capota es de lona flexible, vinilo, plástico, aluminio o algún metal para construir diseños plegables. Los cabriolet son vehículos limitados, buscados por personas que disfrutan del aire libre y están pensados para un viaje confortable de 1 a 2 personas. Generalmente estos autos poseen dos puertas y un diseño muy deportivo. Se los suele clasificar con letras como CC (Coupé Cabrio). Algunos ejemplos de estos autos son el Mazda MX-5BMW Z3 o BMW Z4Pontiac Solstice y Mitsubishi Eclipse, entre otros.

4. Sedan; son vehículos de cuatro puertas con capacidad para cuatro o más personas. Se diferencian del hatchback en que la cajuela está separada de la cabina, es por esto que poseen mayor volumen y en consecuencia son más largos. Son autos generalmente elegidos por familias pequeñas o medianas, algunos modelos poseen motores potentes como el Mazda 3, Honda Civic y Volkswagen Bora. Existen versiones más deportivas con motores de mucha potencia pensando en aquellas personas que disfrutan de la velocidad, como por ejemplo el Alfa Romeo 155Subaru Impreza con motor Boxer y elMitsubishi Lancer Evolution, entre otros. Si bien estos autos no conservan el concepto de un Sedan 4 puertas con respecto al consumo económico, no son más que la línea limitada y exclusiva de las marcas.

5. Berlina; es el término italiano que hace referencia a un vehículo sedan, posen las mismas características técnicas y de equipamiento. Se han creado berlinas deportivas, autos de aspecto muy agresivo con llantas de gran tamaño (de 17¿¿ a 20¿¿) y suspensiones mas bajas que le quitan parte de buen andar en ciudad, pero proporcionan más seguridad en las rutas. Ejemplos del segmento son el Ford Mondeo TS220 con 140 caballos de potencia y el VW Passat V6 con 250 caballos de potencia, entre otros.

6. Familiarmediano o grande; se le conoce de distintas formas a este segmento dependiendo el país donde se vende, como bien lo dice el nombre del segmento, es el preferido de las familias gracias a su espacio y comodidad. Son autos que ofrecen un precio razonable en relación al confort que brindan. Su tamaño es más amplio que un sedan compacto. Adicionalmente pueden abatirse los asientos traseros para hacer más amplio el espacio de carga. Ejemplos de este segmento son; Toyota CamryHonda AccordNissan AltimaChevrolet MalibuChevrolet VectraFord FusionMazda 6 yVolkswagen Passat, por mencionar algunos.

7. SUV (Sport Utility Vehicle); vehículo de utilidad deportivo, estas camionetas dan al usuario la sensación de manejo de una 4X4, están dotadas de una carrocería resistente y poseen una imagen agresiva. Su capacidad de carga no es muy amplia para las SUV ligeras como la Nissan X-TrailToyota RAV-4Honda CR-VSuzuki Grand VitaraMitsubishi Outlander, ya que están ensambladas a partir de las plataformas de los modelos compactos de su misma marca como; Nissan SentraToyota CorollaHonda CivicSuzuki AeroMitubishi Lancer. Este segmento es reciente y constituye una combinación entre un todo terreno y un automóvil cómodo de ciudad. Las SUV tradicionales son las que tienen una construcción de carrocería sobre chasis, poseen un área de carga muy grande debido a que el largo del vehículo supera los 5 metros. La suspensión es muy rígida, resistente y tolera pesos que van desde 1.5 a 2 toneladas. Las más emblemáticas del segmento son; Ford ExplorerFord ExpeditionChevrolet SuburbanToyota Sequoia yToyota 4Runner.

8. 4×4; estos vehículos son muy utilizados en el off road, tienen todas las especificaciones técnicas necesarias para transitar por este tipo de caminos. También se les conoce como tracción a cuatro ruedas o doble tracción por su capacidad de vadear ríos, subir pendientes rocosas, atravesar empedrados y terraceria. El centro de gravedad se encuentra desplazado hacia abajo, por lo que estos vehículos pueden inclinarse hacia los lados hasta un determinado ángulo. Poseen cajas de velocidades muy avanzadas, como la ¿baja¿, un cambio con mucha fuerza para utilizar a baja velocidad que se usa en situaciones en las que se requiere toda la potencia al motor. Ejemplos de estos autos son la gama de Jeep y Hummer.

9. Pick Up; es un tipo de automóvil que tiene en su parte trasera una zona de carga descubierta denominada batea, caja o palangana, en la cual se pueden colocar objetos grandes. Esta clase de vehículos son utilizados para el transporte de objetos de un tamaño mediano, como en el campo. Su motor es pesado, con un área de carga posterior denominada caja, y una cabina con capacidad para 2 o 4 personas. Tienen una suspensión muy fuerte y elevada para soportar grandes cargas. La estructura suele ser muy similar a la de una 4×4, así como los neumáticos que permiten una mayor carga gracias a su alto perfil. Ejemplos de este segmento son; Pick Up pequeña; Chevrolet Montana,Ford Courier. Pick Up mediana; Ford RangerNissan FrontierToyota Tacoma. Pick Up grande; Chevrolet Avalanche o Silverado, GMC Sierra,Toyota TundraNissan TitanFord F-Series y Dodge RAM.

10. Monovolúmen; son vehículos en los que todo está comprendido dentro del espacio del habitáculo; motor, pasajeros y cajuela. Generalmente se diferencian porque en muchos el motor va metido dentro de la parte delantera de la cabina para dar más amplitud. Han ido adquiriendo mayor popularidad, sobre todo entre las familias medianas, ya que cuentan con una capacidad para siete u ocho pasajeros. Como ejemplos de este segmento encontramos; Mitsubishi GrandisMazda 5Chevrolet ZafiraToyota Matrix.

11. Minivan; son los preferidos de las familias numerosas gracias a su gran amplitud y configuración interna. Por lo general tienen 3 hileras de asientos para acomodar a 7 pasajeros, utilizan sólo 1 o 2 puertas corredizas para el ingreso de los pasajeros. En este segmento encontramos; Honda Odyssey,Toyota SiennaNissan QuestChrysler Voyager.

12. Station Wagon o Guayin; vehículo tipo camioneta construido a partir de un sedán con un compartimiento alargado para la cajuela. También es conocida como break o guayin. Como ejemplo del segmento está laVolkswagen Sportwagen.

Posted in Uncategorized | Leave a comment

What’s New in PerformancePoint Dashboards

The latest release of PerformancePoint Services in Microsoft SharePoint Server 2010 provides you with several new and improved features to help you monitor and analyze performance in your organization. You can use dashboards that include more sophisticated key performance indicators (KPIs) in scorecards. You can use new reports, such as a KPI Details report. And, you can open a Decomposition Tree from a value in an analytic report or a scorecard. You can also apply value filters, such as a “Top 10” filter, to view more specific information in some kinds of scorecards and reports.

http://office.microsoft.com/en-us/redir/va101828511.aspx

Enhancements in KPIs and scorecards

PerformancePoint scorecards new include more sophisticated KPIs and other advanced functionality to make it easier to monitor and analyze organizational performance. For example, you can use Drill Down and Drill Up to view lower or higher levels of detail in your scorecards. And, you can use scorecards that have KPIs on columns. You can also use more advanced scorecards that use Time Intelligence, calculated metrics, and multiple actuals to measure performance.

SCORECARDS THAT HAVE DRILL DOWN AND DRILL UP CAPABILITIES

Depending on how your scorecard is configured, you can expand or collapse rows in your scorecard to see lower or higher levels of detail.

For example, if you have a scorecard that measures product sales profitability across different products in a retail organization, your scorecard might resemble the following image:

If you want to see the next level of detail for a particular category, such as GAMES & TOYS you can click the plus sign (+) next to that category and the scorecard will automatically expand to show the next level of detail. Then, your scorecard might resemble the following image:

You can continue expanding the scorecard until you get to the lowest level of detail. The following image shows the Download Games subcategory expanded to list individual products, which is the lowest level of detail for this particular scorecard.

In the preceding example, the categories, subcategories, and individual products are dynamically populated. That is, as the data changes, the scorecard remains up to date to show the current data.

In addition to clicking the plus sign (+) or minus sign () next to an item in the scorecard, you can also use Drill Down and Drill Up commands, as shown in the following image:

To use the Drill Up or Drill Down commands, right-click an item, and then click Drill Up or Drill Down.

Use Drill Up to view a higher level of detail.

Use Drill Down to view a lower level of detail.

SCORECARDS THAT HAVE KPIS ON COLUMNS

You can now have scorecards that include multiple KPIs on columns, enabling you to view more than one set of metrics for each row in your scorecard. A scorecard with KPIs on columns might resemble the following image:

In the preceding example, the scorecard contains two KPIs on columns: Sales Performance and Sales Margins.

SCORECARDS THAT HAVE MORE SOPHISTICATED KPIS

You can now use scorecards that contain more advanced KPIs. For example, you might have KPIs that use formulas and calculations to measure performance (such KPIs are said to use calculated metrics). Or, you might have KPIs that compare multiple values to an overall target (such KPIs are said to use multiple actuals). You can even have KPIs that use special formulas to show information for dynamic time periods, such as “Last Six Months” or “Year to Date” (such KPIs are said to use Time Intelligence). And, you can now have KPIs that show how far off performance is from a goal (such KPIs are said to display Variance).

Although you can have advanced KPIs in your scorecards, your scorecards can remain simple and easy to use. For example, a scorecard that includes such sophisticated KPIs might resemble the following image:

Calculated Metrics

In the following image, the Sales Margins KPI is highlighted. This KPI uses calculated metrics to determine whether performance is on or off target.

When calculated metrics are used in KPIs, SharePoint Server applies one or more formulas to the data as it is retrieved from the underlying database(s). This capability also enables the use of multiple data sources in a single KPI.

New report types and views

You can now use three new PerformancePoint view types in your dashboards: the KPI Details report, analytic pie charts, and the Decomposition Tree.

KPI DETAILS REPORT

You can use a KPI Details report in your dashboard to view additional information about scorecard KPIs. For example, you can view the following information in a KPI Details report:

  • The kinds of metrics that are used for KPIs
  • How performance scores are calculated and what the thresholds are for individual scores
  • Comments that were posted by other scorecard users

A KPI Details report might resemble the following image:

A KPI Details report is always accompanied by a scorecard in a dashboard page. This is because all the information that you view in the KPI Details report is determined by what you click in the scorecard. To view information in a KPI Details report, you click any value in a scorecard. To see how scores are calculated in a scorecard, click a cell in a Target value column.

ANALYTIC PIE CHARTS

You can now use analytic pie charts in your dashboards. Similar to an analytic line or bar chart, you can use an analytic pie chart to view higher or lower levels of detail. You can also drill into the data to view a different dimension in the underlying SQL Server Analysis Services data cube.

An analytic pie chart might resemble the following image:

DECOMPOSITION TREE

You can open a Decomposition Tree to explore data in some kinds of scorecards and reports. The Decomposition Tree is available as an action that you can apply to PerformancePoint analytic reports and scorecards that use Analysis Services data.

You would typically use a Decomposition Tree to see how an individual value in a report or a scorecard can be broken down into its contributing members. The Decomposition Tree automatically sorts results and applies an inline Pareto chart to the data, so you can quickly see the highest contributors to a particular report value. You can also see trends across individual members that contribute to an overall value.

 NOTE    In order to open and use the Decomposition Tree, you must have Microsoft Silverlight 2 or Silverlight 3 installed on your computer. In addition, depending on how a scorecard or an analytic view is configured, you might not be able to open the Decomposition Tree.

To open the Decomposition Tree, right-click an individual value, such as a point in a line chart, a bar in a bar chart, a wedge in a pie chart, or a cell in a grid or a scorecard. Then, you can select Decomposition Tree. The Decomposition Tree opens in a new window, where you can either drill down to the next level of detail, or drill into the data to view a different dimension in the data cube.

A Decomposition Tree might resemble the following image:

Using the Decomposition Tree, you can also view member properties for a particular dimension member, as shown in the following image:

Posted in Business Intelligence | Leave a comment

Design Logic Implementation

Implementation Approach Philosophies

Waterfall Approach

The waterfall approach to implementing an application requires that a designer confer with one or more representatives of the end user organization and write down all the specifications of the application. Usually, the specifications come in a set of functional documents or use cases, written so that the end user can easily read and understand the documents. The end user signs off on these documents, and the documents are then picked up by the technical design team that designs the application, creating a number of artifacts such as class model diagrams, state diagrams, activity diagrams, and data models. The aim of this phase is to write everything down in such detail that a developer will have no problem creating the necessary code. There is a formal handover of the design to both the development team and the test team. After handover, the development team starts coding, and the test team uses the technical design in combination with the use cases to create test cases and test scenarios. Once the development team is finished coding, the code is delivered to the test team. The test team performs the tests they designed based on requirements and detailed design. Any problems will be fixed by the development team. Once the process of testing and fixing is completed, the application is given to the end user for an acceptance test. The end user performs a final check to see whether the application conforms to the initial requirements. If approved, he or she signs off on the finished product, and the project is done.

A project can have more or fewer phases when using the waterfall approach, but the main characteristic is a very formal start and end of every phase, with very formal deliverables.

The advantage of the waterfall approach is that accountability of the team responsible for each phase is higher. It is clear what they need to deliver, when they need to deliver, and to whom they must deliver. Often, the development team will not need to interact with the user. This can be very useful when outsourcing development to a different country.

The main disadvantage to the waterfall approach is that in an environment in which everything is organized in a quite formal manner, flexibility in responding to change is decreased. Even change needs to be organized. Very few companies seem to do this effectively, often resulting in a significant increase in overhead cost. To manage the costs of a project, some companies even go as far as to delay any change in requirements until after initial delivery of the application, effectively delivering an application that does not match end user needs.

Agile Development

Many long-running software development projects have run over their budgets and do not deliver the product on time. The premise of the agile software development philosophy is to minimize risk by developing software in short time boxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own and includes all of the tasks necessary to release the increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. Although an iteration might not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team re-evaluates project priorities.

The goal of agile software development is to achieve customer satisfaction by rapid, continuous delivery of useful software; always aiming to build what the customer needs; welcome, rather than oppose, late changes in requirements; regularly adapt to changing circumstances; have close, daily cooperation between business people and developers, in which face-to-face conversation is the best form of communication.

The main advantage of agile software development is flexibility in dealing with change, always aiming to deliver according to business needs. The drawback, of course, is an increase in complexity in managing scope, planning, and budget. Another common risk is limited attention to (technical) documentation.

Incremental Development

Incremental software development is a mix of agile and waterfall development. An application is designed, implemented, and tested incrementally so that each increment can be delivered to the end user. The project is not finished until the last increment is finished. It aims to shorten the waterfall by defining intermediate increments and by using some of the advantages of agile development. Based on feedback received on a previous increment, adjustments can be made when delivering the next increment. The next increment can then consist of new code as well as modifications of code delivered earlier.

The advantage is that the formalities remain in place, but change management becomes easier. The cost of testing and deploying an application a number of times will be higher than doing this just once.

Program Flow Control

Choosing an approach for program flow control is very much an architectural task. The aim is to create a blueprint of your application in which, once you start adding functionality and code, everything just seems to have its own place. If you’ve ever reviewed or written a highquality piece of code, you understand this principle

Organizing Code

The first step in designing your program flow is to organize the code, laying down a set of rules to help create a blueprint, or outline, of the application. Maintenance, debugging, and fixing errors will go more smoothly because code is located in a logical place. After doing the groundwork, you can choose an approach for implementing your application logic.

Design patterns should play an important part in designing your program flow control. Over the years, a lot of code has been written and a lot of solutions have been designed for what turn out to be repeating problems. These solutions are laid down in design patterns. Applying a design pattern to a common software design issue will help you create solutions that are easily recognizable and can be implemented by your peers. Unique problems will still require unique solutions, but you can use design patterns to guide you in solving them.

Creating the Blueprint

Layers

The first step is to consider logical layers. Note that layers are not the same as tiers, often confused or even assumed to be the same.

Layers versus tiers

Layers concern creating boundaries in your code. The top layer might have references to code in lower layers, but a layer can never have a reference to code in a higher layer. Tiers concern physically distributing layers across multiple computers. For example, in a three-tier application, the user interface is designed to run on a desktop computer, the application logic is designed to run on an application server, and the database runs on a dedicated database server, and the code on each tier can consist of multiple layers.

Figure 8-1: Basic three-layer organization

Layering refers to levels of abstraction. The layering shown in Figure 8-1 is true for most applications. These levels are also referred to as the three principal layers and might go by various other names. As a rule, code in the presentation layer might call on services in the application logic layer, but the application logic layer should not be calling method in the presentation layer. The presentation layer should never call on the data access layer directly because doing so would bypass the responsibilities implemented by the application logic layer. The data access layer should never call the application logic layer.

Layers are just an abstraction, and probably the easiest way to implement the layering is to create folders in your project and add code to the appropriate folder. A more useful approach would be to place each layer in a separate project, thus creating separate assemblies. The advantage of placing the application logic in a library assembly is that this will enable you to create unit tests, using Microsoft Visual Studio or NUnit, to test the logic. It also creates flexibility in choosing where to deploy each layer.

Physical Layers

In an enterprise application, you should expect to have multiple clients for the same logic. In fact, the very thing that makes an application an enterprise application is that it will be deployed to three tiers: client, application server, and database server. The Microsoft Office Access application created by the sales department in your enterprise, although very important to the sales department, does not constitute an enterprise application.

Note that the application logic and data access layers are usually deployed together to the application server. Part of drawing up the blueprint is choosing whether to access the application server by using .NET remoting or Web services. Regardless of choice, you will be adding some code to access easily the remote services in the presentation layer. If you’re using Web services to access the services on your application server, Visual Studio .NET will do the work for you and generate proxy code, automatically providing an implementation of the remote proxy pattern.

Adding Patterns to Layers

The three basic layers provide a high-level overview. Let’s add a couple of structural patterns to create a robust enterprise architecture. The result is shown in Figure 8-2.

Focus on the application logic layer. Figure 8-2 shows that access to the application logic is using the façade pattern. A façade is an object that provides a simplified interface to a larger body of code, such as a class library. A façade can reduce dependencies of outside code on the inner workings of a library because most code uses the façade, thus allowing more flexibility in developing the system. To do so, the façade will provide a coarse-grained interface to a collection of fine-grained objects.

Decision Flow

Program flow control, also referred to as decision flow, concerns how you design the services on your application logic layer or, as you’ve seen in the previous paragraph, how you design the methods on your façade.

There are two approaches to organizing your services:

  • Action-driven
  • State-driven

Action-Driven Approach

When organizing services based on the actions of the user, you will be implementing application logic by offering services, each of which handles a specific request from the presentation layer. This is also known as the transaction script pattern. This approach is popular because it is simple and feels very natural. Examples of methods that follow this approach are BookStoreService.AddNewOrder(Order order) and BookStoreService.CancelOrder(int orderId).

The logic needed to perform the action is implemented quite sequentially within the method, making it very readable but also harder to reuse the code. Using additional design patterns such as the table module pattern can help increase reusability.

State-Driven Approach

It is also possible to implement the decision flow of the application in a much more state-driven fashion. The services offered by the application server are more generic in nature, for example, BookStoreService.SaveOrder(Order order). This method will look at the state of the order and decide whether to add a new order or cancel an existing order.

Data Structure Designs

You must make a number of choices while designing your data structures. The first choice is the data storage mechanism, the second is the intended use of the data, and the third is the versioning requirements. There are three ways of looking at data structure designs:

  • Services offer data; data is a reflection of the relational database.
  • Data should be mapped to objects, and services offer access to objects.
  • Data offered by services should be schema based.

Choosing one of the three as the basis for your data flow structure should be done in an early stage of the design process. A lot of companies have a company guideline that forces one of the three choices on all projects, but when possible, you should re-evaluate the options for each project, choosing the optimal approach for the project at hand.

Choosing a Data Storage Mechanism

When designing your application, you will undoubtedly have to design some sort of data store. The following stores and forms of data storage are available:

  • Registry
  • app.config file
  • XML files
  • Plaintext files
  • Database
  • Message Queuing

Each store has its own unique characteristics and might be suitable to specific requirements.

Designing the Data Flow

Data Flow Using ADO.NET

When implementing data-centric services in the application logic layer, you’ll design your data flow by using ADO.NET. The .NET Framework Class Library offers an extensive application programming interface (API) for handling data in managed code. Referred to as ADO.NET, the API can be found in the System.Data namespace. The complete separation of data carriers and data stores is an important design feature of ADO.NET. Classes such as the DataSet, DataTable, and DataRow are designed to hold data but retain no knowledge of where the data came from. They are considered data-source agnostic. A separate set of classes such as SqlConnection, SqlDataAdapter, and SqlCommand take care of connecting to a data source, retrieving data, and populating the DataSet, DataTable, and DataRow. These classes are located in sub-namespaces such as System.Data.Sql, System.Data.OleDB, System.Data.Oracle, and so on. Depending on what data source you wish to connect to, you can use the classes in the correct namespace and, depending on the completeness of the product you’re using, you’ll find that these classes offer more or less functionality.

Because the DataSet is not connected to the data source, it can be quite successfully used for managing the data flow in an application. Figure 8-5 shows the flow of data when doing so.

Let’s do a walkthrough of this design and imagine that someone has logged on to your bookstore and has ordered three books. The presentation layer has managed the state of the shopping cart. The customer is ready to order and has provided all necessary data. He chooses submit order. The Web page transforms all data into a DataSet holding two DataTables, one for the order and one for orderliness; inserts one DataRow for the order; and inserts three DataRows for the order lines. The Web page then displays this data back to the user one more time, data binding controls against the DataSet, and asks Are you sure? The user confirms the order, and it is submitted to the application logic layer. The application logic layer checks DataSet to see that all mandatory fields have a value and performs a check to see whether the user has more than $1,000.00 in outstanding bills. If all is okay, the DataSet is passed on to the data access layer, which connects to the database and generates insert statements from the information in the DataSet.

Using the DataSet in this manner is a fast and efficient way of building an application and using the power of the Framework Class Library and the ability of ASP.NET to data bind various controls such as the GridView against a DataSet. Instead of using plain DataSet objects, you can use Typed DataSet objects and improve the coding experience when implementing code in both the presentation layer as well as in the application logic layer. The advantage of this approach is also the disadvantage of the approach. Small changes in the data model do not necessarily lead to a lot of methods having to change their signatures. So in terms of maintenance, this works quite well. If you remember the presentation layer is not necessarily a user interface, it can just as well be a Web service. And if you modify the definition of the DataSet, perhaps because you’re renaming a field in the database, then you’re modifying the contract that underwrites the Web service. As you can imagine, this can lead to some significant problems. This scenario works well if the presentation layer is just a user interface, but for interfaces to external systems or components, you will want to hide the inner workings of your application and transform data into something other than a direct clone of your data model, and you will want to create Data Transfer Objects (DTOs).

Data Flow Using Object Relational Mapping

Data flow using ADO.NET is a very data-centric approach to managing the data flow. Data and logic are discrete. The other side of the spectrum is to take a more object-oriented approach. Here, classes are created to bundle data and behavior. The aim is to define classes that mimic data and behavior found in the business domain that the application is created for. The result is often referred to as a business object. The collection of business objects that make up the application is called the domain model. Some developers claim that a rich domain model is better for designing more-complex logic. It’s hard to prove or disprove any such claim. Just know that you have a choice, and it is up to you to make it.

Figure 8-6 shows a data flow similar to Figure 8-5 except that now you’ve added the object relational mapping layer and substituted the DataSet objects for different data carriers.

Now do the same walkthrough as you did before; imagine that someone has logged on to your bookstore and has ordered three books. The presentation layer has managed the state of the shopping cart. The customer is ready to order and has provided all necessary data. He chooses submit order. The Web page transforms all data into a DTO, holding data for one order and with three order lines, creating the objects as needed. The Web page then displays this data back to the user one more time, data binding controls against the DTO using the ObjectDataSource in ASP.NET 2.0, and asks Are you sure? The user confirms the choice, and the DTO is submitted to the application logic layer. The application logic layer transforms the DTO into a business object of type Order having a property for holding three OrderLine objects. The method Order.Validate() is called to validate the order and check that all mandatory fields have a value, and a check is performed to identify whether the user has more than $1,000.00 in outstanding bills. To do this, the order will call Order.Customer.GetOutstandingBills(). If all is well, the Order.Save() method is called. The order will submit itself to the object relational mapping layer, where the order and order lines are mapped to a DataTable in a DataSet, and the DataSet is passed to the data access layer, which connects to the database and generates insert statements from the information in the DataSet. There are, of course, many ways in which object relational mapping can take place, but not all will include transformation to a DataSet. Some will create the insert statements directly but still use the data access layer to execute that statement.

As you can see, quite a few transformations take place. The use of DTOs is needed because a business object implements behavior, and behavior is subject to change. To minimize the impact of these changes on the presentation layer, you need to transform the data, take it out of the business object and put it in a data transfer object. In Java, the data transfer object is normally referred to as a value object.

A big advantage of working with business objects is that it really helps organize your code. If you look back at a piece of complex logic, it is usually very readable because there is very little plumbing code. The disadvantage is that the majority of data stores are still relational, and the mapping of business objects to relational data can become quite complex.

Schema-Based Services

You have just seen two opposites when it comes to managing the data flow. Many variations are possible. A common one is the variant in which a dataset is used as the basic data carrier from user interface to data store, but separate schemas (DTOs) are used for Web services that are called from other systems. The application layer transforms the relational data to a predefined schema. The main advantage of this is that any application that references the service is not depending on any kind of internal implementation of the component. This allows more flexibility in versioning, backward compatibility of interfaces, and the ability to change the implementation of the component while not changing the interface of the service.

Of course, you can use business objects in the Web application and skip the DTO transformation, but this usually works well only if the application logic is deployed together with the Web application. Remember that to call Order.Save(), you’ll need a database connection. Whether this is desirable is up to you as well as, probably, to your chief security officer.

Posted in Uncategorized | 1 Comment