Aplicaciones Distribuidas 3

Capas
INTRODUCCION:
Las aplicaciones han pasado por un proceso evolutivo enorme. Desde su
inicio con las aplicaciones monolticas donde en una aplicacin todo estaba
ligado o mezclado por decirlo de alguna manera. Es decir, la interfaces de
usuario, la lgica de cmo funcionaba la empresa y el manejo de la
informacin almacenada y recuperada estaban juntas.
Luego la industria ha implementado un nuevo modelo de aplicaciones, las
aplicaciones distribuidas cliente/servidor, que se convirti en el estndar por
un tiempo. Pero con la llegada de las aplicaciones web se hacia necesario
un nuevo estndar para la operaciones de los sistemas, y es por esto que
se ha propuesto el modelo de las aplicaciones en n-capas.
Este modelo por lo general esta basado en un esquema de tres partes:
Acceso, Lgica de negocios e interfaces de usuario. Aunque es posible
continuar sub dividiendo este modelo en sub capas para una mayor
flexibilidad en la distribucin en el equipo de desarrollo y durante el
mantenimiento. Veamos en que consiste.

Arquitectura de aplicaciones con tres capas

Arquitectura de Aplicaciones en n-capas Se ha convertido en el estndar
para el software empresarial. Se caracteriza por la descomposicin de las
aplicaciones.
Proporciona una escalabilidad, capacidad de administracin y
utilizacin de recursos mejorados.
Cada capa es un grupo de componentes que realiza una funcin
especfica.
Se puede actualizar una capa sin recompilar otras capas.
Por regla general, La capa de la presentacin es una interfaz grfica que
muestra los datos a los usuarios.
La capa de la lgica de negocios es responsable de procesar los datos
recuperados y enviarlos a la capa de presentacin.
La capa de datos almacena los datos de la aplicacin en un almacn
persistente, tal como una base de datos relacional o archivos XML.
Se pueden alojar todas las capas en el mismo servidor, pero tambin es
posible alojar cada capa en varios servidores.
Para Ilustrar un poco el concepto de las aplicaciones distribuidas, vamos a
crear un pequeo proyecto de 3 capas de venta de pelculas. En dicha
aplicacin crearemos:

1- un servicio web como capa de acceso (asumiendo que este sera el

modelo utilizado por cada compaa).
2- un servicio web para la lgica de negocios, que en realidad
constar de dos, el primero para buscar la informacin brindada por
los proveedores como director, actores, duracin, etc. Y otro para
conseguir las crticas de algn sitio dedicado a esos fines.
3- Un cliente que compre pelculas tomando en consideracin la
informacin que le brindamos al respecto.
Y para hacerlo ms interesante vamos a extender un poco el artculo de
nuestro colega Andrs Faya de escribir aplicaciones en distintos lenguajes,
para implementar nuestros Web service de igual forma, uno en C# y otro
en J# y Nuestra capa de acceso y el cliente van a funcionar bajo el lenguaje
de Visual Basic.Net.
Nota: Las aplicaciones distribuidas no necesariamente tienen que estar
construidas en base a los web service, estos se utilizan cuando se requiere
que la informacin sea compatible entre plataformas. En caso en que est
no sea la prioridad entonces es opcional utilizarla o implementar la
distribucin de la aplicacin por medio de Remoting.Net.
La primera capa que vamos a desarrollar es la capa de acceso a datos. De
esta capa cabe mencionar que es recomendable utilizar los Store Procedure
en vez de ejecutar las sentencias directas desde el programa.
Se preguntaran por qu? Simple cuando ejecutas las sentencias directas
contra la base de datos, toda la informacin referente a la sentencia viaja a
travs de la red, consumiendo mas ancho de banda y dejando a merced de
algn sniffer la seguridad de nuestra base de datospiensen como!!!.
La principal ventaja adems de reducir los riesgos antes mencionados, es
que los procedure son precompilados y funcionan de forma tipados, es
decir, que solo reciben los parmetros que tienen preestablecidos y de los
tipos especficos para cada caso, sumndole que se ejecutan mucho mas
rpido que ejecutando sentencias desde el programa y le dejamos al
servidor de base de datos procesar la informacin creando un mayor
balance en la carga de trabajo en nuestra red.
Antes de mostrar el cdigo de la capa de acceso me parece necesario, hacer
mencin de los mecanismos que nos permiten utilizar los web service que
son la base de nuestro ejemplo.
Lo primero es que necesitamos conocer son UDDI y DISCO que
permite a los clientes de los servicios acceder a la funcionalidad que
expone un servicio web dndole la ubicacin del servicio remoto.
Luego de conocer la ubicacin, los clientes necesitan tener
informacin de cmo interactuar con dichos servicios.
El formato de los mensajes que intercambiarn el cliente y los
servicios web como fundamento de comunicacin debe tener un
mecanismo de codificacin y decodificacin.
Para estos fines es indiscutible que el lenguaje a utilizar es el XML que se ha
convertido en el estndar de intercambio de informacin, por permitir la
interoperatividad entre plataformas y por usar un sistema de tipo comn.
Una vez conocidas estas reglas entonces procedemos a codificar.

Cdigo de capa de acceso:

Cabe destacar el uso de la clase Microsoft.ApplicationBlocks.Data versin 1 que nos
permite acceso a datos de forma eficaz y rpida...aunque ya existe una segunda
versin para los interesados.
Imports System.Data
Imports System.Data.SqlClient
Imports System.Data.OleDb
Imports System.Security
Imports System.Configuration
Imports Microsoft.ApplicationBlocks.Data
Imports System.Web.Services
<System.Web.Services.WebService(Namespace:="http:"//tempuri.org/Capa
Acceso/Service1")> _
Public Class CapaAcceso
Inherits System.Web.Services.WebService
#Region " Web Services Designer Generated Code "
Public Sub New()
MyBase.New()
'This call is required by the Web Services Designer.
InitializeComponent()
'Add your own initialization code after the
InitializeComponent() call
End Sub
'Required by the Web Services Designer
Private components As System.ComponentModel.IContainer
'NOTE: The following procedure is required by the Web Services
Designer
'It can be modified using the Web Services Designer.
'Do not modify it using the code editor.
<System.Diagnostics.DebuggerStepThrough()> Private Sub
InitializeComponent()
components = New System.ComponentModel.Container

End Sub
Protected Overloads Overrides Sub Dispose(ByVal disposing As
Boolean)
'CODEGEN: This procedure is required by the Web Services

Designer

'Do not modify it using the code editor.

If disposing Then
If Not (components Is Nothing) Then
components.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
#End Region
Private sqlconn As String =
("server=(local);database=Peliculas;uid=sql;pwd=mar45245wqek")
Private ds As New DataSet
Private i As Integer
'Lo primero que debemos saber es que para hacer que una funcin
o procedimiento
'Sea interpretado como un mtodo que puede ser consumido por un
cliente web es
'necesario, declararlo con esta finalidad, es decir declararlo
como un mtodo web
'Para ello,utilizamos la palabra reservada WebMetohd entre los
simbolos de "<>"
'Por lo que quedara as "< WebMethod() >"

'Lo segundo que debos saber es que para sobre cargar los
WebMethod utilizamos
'la propiedad llamada MessageName para que el servicio web
distinga estre estas
'funciones o procedimiento.
'Esto no quiere decir que, para llamar dichas funciones usemos
el nombre designado
'en el MessageName, se invocan igual que un mtodo sobre cargado
en una clase normal.

'Lo siguiente a tomar en cuenta es el nivel de acceso. Pues al

igual que en un clase
'cualquiera los niveles de private, public tienen los mismo
efectos. Es decir, si desea
'que un mtodo solo sea accesible desde esta clase entonces lo
declaras private, pero si
'desea utilizarlo como un servicio web, entonces debe ser public
para poder ser accesible
'desde las instancias.

'Sobre cargo la funcin Query para los diversos caso que pueda
necesitar.

'La funcin del query es para los procedure que retornar

valores( Select).
<WebMethod(MessageName:="cero")> Public Function Query(ByVal
procedure As String) As DataSet
ds = SqlHelper.ExecuteDataset(sqlconn,
CommandType.StoredProcedure, procedure)
Return ds
End Function
<WebMethod(MessageName:="primero")> Public Function Query(ByVal
conexion As String, ByVal procedure As String) As DataSet
ds = SqlHelper.ExecuteDataset(conexion,
CommandType.StoredProcedure, procedure)
Return ds
End Function
<WebMethod(MessageName:="segundo")> Public Function Query(ByVal
conexion As String, ByVal procedure As String, ByVal parametros() As
Object) As DataSet
ds = SqlHelper.ExecuteDataset(conexion,
CommandType.StoredProcedure, procedure, parametros)
Return ds
End Function
<WebMethod(MessageName:="tercero")> Public Function Query(ByVal
procedure As String, ByVal parametros() As SqlParameter) As DataSet
Try
ds = SqlHelper.ExecuteDataset(sqlconn,
CommandType.StoredProcedure, procedure, parametros)

Return ds
Catch ex As SqlException
ex.Message)

MsgBox(ex.Procedure & ", " & ex.LineNumber & ", " &

End Try
End Function
'sobre cargo QueryInteger por si necesito que el procesudre me
retorne por ejemplo un id.
<WebMethod(MessageName:="primer")> Public Function
QueryInteger(ByVal procedure As String) As Int32
Try
i = SqlHelper.ExecuteScalar(sqlconn,
CommandType.StoredProcedure, procedure)
Return i
Catch ex As Exception
Trace.Write(ex.Message)
End Try
End Function
<WebMethod(MessageName:="second")> Public Function
QueryInteger(ByVal procedure As String, ByVal parametros() As
SqlParameter) As Integer
Try
i = SqlHelper.ExecuteScalar(sqlconn,
CommandType.StoredProcedure, procedure, parametros)
Return i
Catch ex As Exception
Trace.Write(ex.Message)
End Try
End Function
'Sobre cargo la funcin NoQuery para los procedure con
delete, update)

(Insert,

<WebMethod(MessageName:="1")> Public Function NoQuery(ByVal

procedure As String, ByVal parametros() As SqlParameter)
Try
SqlHelper.ExecuteNonQuery(sqlconn,
CommandType.StoredProcedure, procedure, parametros)
Catch ex As Exception
Trace.Write(ex.Message)
End Try
End Function
<WebMethod(MessageName:="2")> Public Function NoQuery(ByVal
conexion As String, ByVal procedure As String, ByVal parametros() As
Object) As Integer

Try
i = SqlHelper.ExecuteNonQuery(conexion,
CommandType.StoredProcedure, procedure, parametros)
Return i
Catch ex As Exception
Trace.Write(ex.Message)
End Try
End Function
<WebMethod(MessageName:="3")> Public Function NoQuery(ByVal
conexion As String, ByVal procedure As String) As Integer
Try
i = SqlHelper.ExecuteNonQuery(conexion,
CommandType.StoredProcedure, procedure)
Return i
Catch ex As Exception
Trace.Write(ex.Message)
End Try
End Function
End Class

Aplicaciones En Capas - Presentation Transcript

1.

Fausto Loja Mora

2.
El modelo de aplicaciones en capas, permite que las aplicaciones puedan ser
distribuidas en sus componentes

o
3.

Desarrollos paralelos (en cada capa)

Aplicaciones ms robustas debido al encapsulamiento

o
Mantenimiento y soporte ms sencillo (es ms sencillo cambiar un componente que
modificar una aplicacin monoltica)

o
o

Mayor flexibilidad (se pueden aadir nuevos mdulos para dotar al sistema de nueva

funcionalidad)

o
Alta escalabilidad. La principal ventaja de una aplicacin distribuida bien diseada es
su buen escalado, es decir, que puede manejar muchas peticiones con el mismo rendimiento
simplemente aadiendo ms hardware. El crecimiento es casi lineal y no es necesario aadir ms
cdigo para conseguir esta escalabilidad.

4.
Acceso a bases de datos (BD)

Normalmente con BD relacionales

Escalables

Deberan poder soportar ms carga de trabajo sin necesidad de

modificar el software (slo aadir ms mquinas)
Disponibilidad

Idealmente no deben dejar de prestar servicio

5.
Seguras

No todos los usuarios pueden acceder a la misma funcionalidad

Integracin

Es preciso integrar aplicaciones construidas con distintas tecnologas

Tipo de interfaz

De entorno de ventanas (clientes desktop): normalmente slo tiene

sentido en intranets.

Web: En Internet y en intranets.

6.

Separacin clara entre la interfaz grfica y la Capa de componentes

Capa de componentes: encapsulan la lgica de negocio.

Ejemplo => aplicacin bancaria

Capa de componentes: conjunto de clases que nos permiten:

crear cuentas, destruirlas, encontrarlas por distintos criterios, hacer transferencias
bancarias, etc.
La capa de componentes debera ser reusable con distintas interfaces

grficas

En el ejemplo de la aplicacin bancaria podra haber dos clientes: uno

Web y otro desktop.

7.

Transaccionales

Propiedades ACID (Atomicity-Consistency-Isolation-Durability)

Operaciones atmicas (Atomicity) son operaciones que se completan en

su totalidad o no se completan en absoluto. As, en el ejemplo anterior de la transferencia
tanto el crdito como el dbito deben haber sido exitosos para que el estado de
transformacin sea exitoso (para que haga efectos), de otro modo el estado de la
transformacin falla, y el sistema es regresado a su ltimo estado conocido.

Transformaciones consistentes (Consistency) preservan la integridad

interna de los recursos involucrados. Por ejemplo, el borrar registros de una tabla primaria
viola la integridad referencial de la base de datos si hay registros relacionados que
concuerden.

Transformaciones aisladas (Isolation) parecen ocurrir serialmente, una

detrs de otra, creando la ilusin de que ninguna transformacin est siendo ejecutada al
mismo tiempo.

La durabilidad (Durability) se refiere a la habilidad para almacenar los

resultados de una transformacin de estado, usualmente en un disco, de tal modo que los
resultados de una transformacin puedan ser recuperados en caso de una falla del sistema.

8.
9.
10.
11.
La capa de servicios de presentacin es responsable de:

Obtener informacin del usuario.

Enviar la informacin del usuario a los servicios de negocios para su

procesamiento.

Recibir los resultados del procesamiento de los servicios de negocios.

Presentar estos resultados al usuario.

12.
El nivel de servicios de negocios es responsable de:

Recibir la entrada del nivel de presentacin.

Interactuar con los servicios de datos para ejecutar las operaciones de

negocios para los que la aplicacin fue diseada a automatizar (por ejemplo, la preparacin
de impuestos por ingresos, el procesamiento de ordenes y as sucesivamente).

Enviar el resultado procesado al nivel de presentacin.

13.

El nivel de servicios de datos es responsable de:

Almacenar los datos.

Recuperar los datos.

Mantener los datos.

La integridad de los datos.

14.
15.
16.
17.
UI Components

Muestran informacin al usuario, generalmente se usan en ventanas o

pginas (user components, server components)

UI Process Components

Implementan procesos de UI

Se pueden reutilizar desde distindos UI components y distintas capas de

presentacin

18.
Model View Controller

View Controller Model User

19.
Model View Controller

Tiene algunos problemas en su implementacin:

Concepto de Proceso

Responsabilidad de navegacin

Hace falta intercambiar ms informacin entre el Controller y

la View
20.
21.
22.
Service Interface

Solo una capa de acceso a la lgica de negocio

Expuesta generalmente con WebServices o Remoting

Se pueden usar otras formas de acceso: BizTalk, Message Queue, etc.

Al ser el punto de acceso a toda la capa de negocio, por lo tanto se
utiliza para implementar todos los servicios globales:

Transacciones, Seguridad, Monitoreo, Caching, etc.

23.

Demo de Service Interface

MBI es una implementacin de Service Interface

Usando Remoting

24.

Business Entities

Son objetos solo con propiedades para mantener una instancia en

memoria.

Deben soportar la distincin entre una instancia y un conjunto de

instancias.

Pueden mapearse con las tablas de la base de datos, si la base est

bien modelada.

El assembly en el que se definen se encuentra en Business Layer y

Presentation Layer

Hay varias formas de implementar esto:

Datasets, Typed Datasets o Custom Objects

Discusin sobre este tema en Designing Data Tier

Components and Passing Data Through Tiers

25.
Business Components

Son objetos que definen solo mtodos que se ejecutan en el contexto de

un Business Entity.

FacturaBO.AplicarDescuento( factura, descuento )

ClienteBO.ValidarCredito( cliente, monto, plazo )

Alunos mtodos requieren acceder a la base de datos.

Porque estn separados?

Separacin de assemblies. Porque las entidades se usan en

Business Layer y Presentation Layer, mientras que los Business Components solo estn
en Business Layer.

Es la nica forma si se usan DataSets.

Evitar la propagacin de la lgica de negocio.

26.
Business Workflow

Hay mtodos que no pertenecen a ningn objeto. :S

Facturar( Vendedor, Cliente, Items[] )

Estos mtodos se pueden agrupar en objetos o tener un objeto por

mtodo.
Idealmente

Hay un mtodo de Service Interface por cada Business

Workflow, pero hay mtodos de la Service Interface que usar directamente los Business
Object
Aunque

Si la Service Interface tiene hardcoded un mtodo de

Business Workflow un cambio, tiene impactos no deseados.

27.
Y donde programo ?

Validaciones

Locales

Globales

Formateo

Valores calculados (ej: Edad, Factura.Total)

28.
Data Access Logic Components

Objetos sin comportamiento que solo saben guardar un Business Entity

en la base de datos.

Generalmente son clases con mtodos estticos.

Utilizan alguna forma de acceso a datos simplificado como Data Access

Application Block.

Debe ser una nica clase que sea llamada por el Business Component
de forma que no se tenga en cuenta el origen de los datos.

Realiza todas las conversiones y validaciones necesarias que estn

relacionadas con el modelo de base de datos.

29.

View Controller Model User

30.
Data Access Logic Components

DALC Business Component Business Entity Database

31.
Se puede implementar:

Escribiendo cdigo ADO.NET para cda mtodo de cada objeto: Create,

Open, Update, Delete, Find.

Usando SqlDataAdapter, si se usan DataSets como Business Entities.

Alguna herramienta de Object Relational Mapping.

Demo

32.
33.
Data Access Application Block

Versin 1.0

Una sola clase con con todos mtodos estticos que soporta
los siguientes features: ExecuteReader, ExecuteDataSet, ExecuteNonQuery,
ExecuteXmlReader, cache de parmetros y discovery.
Versin 3.0

Una clase abstracta con los siguientes mtodos: v1.0 ms,

FillDataSet, UpdateDataset. Execute_____TypeParams.

Todos los mtodos estn programados usando las interfaces

de ADO.NET. Se usan proveedores muy simples para devolver las clases propias de
cada driver ADO.NET.

34.
Data Sources

Representan los origenes de datos OLTP

Solo son accedidos por la capa DALC

Service Agents

Conectores para acceso a una fuente de datos externa

Generalmente son asincrnicos realizan una fuerte conversin de datos

External Services

Sistemas externos generalmente Batch que se acceden en forma

sincrnica o asincrnica.

La conectividad puede estar apoyada por alguna tecnologa de Store-

and-Forward.
35.

Demo de Service Agent

o
36.

Son servicios para las aplicaciones

Dado que no pertenecen a ninguna capa, se definen por fuera aunque en algunos
casos se implementen o usen en alguna capa.

Son los siguientes:

Seguridad

AuthZ, AuthN, Comunicacin segura, Aditora, Manejo de

Perfiles.

Operaciones

Manejo de excepciones, Monitoreo, Execucin asincrnica,

Metadatos, Configuracin.

Comunicaciones

Formato, Protocolo, Asincronismo.

37.
Autenticacin.

Generalmente se utiliza el soporte de la plataforma, en Windows:

SSPI(Kerberos, NTLM), Passport, etc.

Para aplicaciones Web se usa el soporte de IIS

Aunque se puede implementar un soporte liviano basado en Forms y

cookies.
Ver

Improving Web Application Security: Threats and

Countermeasures

Authentication in ASP.NET: .NET Security Guidance

Building Secure ASP.NET Applications.

Autorizacin

Dado que basarse en el soporte de la plataforma es muy complicado, se

desarrolla este soporte para la aplicacin.

Ver Designing Application-Managed Authorization

38.
Comunicacin segura

En .NET la comunicacin est basada en Remoting, WebServices o

algn tipo de comunicacin propietaria.

Nuevamente se puede utilizar el soporte de base, sea SSL

(WebServices), o algn canal seguro de Remoting (NamedPipes).
Es un problema de la capa de Service Interface

Aditora

Registro de las operaciones realizadas:

Tecnico

Lgico
Manejo de Perfiles

Concepto de usuario de la aplicacin que contiene configuracin.

Todas las capas colaboran, soportada en conjunto con la Autorizacin .

39.
Manejo de excepciones

Registro de todas las excepciones

Dos tipos de excepciones (idea de MBI)

Tecnicas

Funcionales

Usar la InnerException

Usando Exception Management Application Block (EMAB) o Log4Net

Ver Exception Management in .NET

Responsabilidad de la capa Service Interface

40.
41.
Monitoreo

Control de la aplicacin mientras est en ejecucin

Performance Counters

WMI

Responsabilidad de la capa Service Interface

Ver Monitoring in .NET Distributed Applications Design

Execucin asincrnica

Soportado internamente (Remoting Asincrnica) o externamente

(MSMQ).

Se puede desarrollar un soporte genrico

Ver Asynchronous Invocation Application Block

42.
Metadatos

Informacin sobre la informacin o la estructura del software

Se puede usar en
Tiempo de diseo: generacin de cdigo

Tiempo de ejecucin: aspectos estticos (deployment,

configuracin, seguridad, etc)

Integracin. Si se usan DataSets se pueden publicar los XSD de forma

que el modelo de datos sea pblico. (Idea de MBI)

43.

Configuracin

Configuracin disponible en toda la aplicacin.

Generalmente hay dos tipos

Capa de presentacin

Ubicacin de la capa de lgica (Remoting,

WebService), propiedades de seguridad de Web o Windows, etc.
Capa de lgica y de datos.

Conecin a la base de datos, exposicin de

servicios, parmetros de seguridad, etc
Se puede implementar como un Singleton, con una clase aprovechando

XmlSerialization.

Ver Configuration Management Application Block

44.

Demo Configuration Management Application Block

45.

Muy basado en las opciones de Remoting y WebServices

Puntos que se pueden configurar

Formato

Binario, SOAP, Custom Xml, Custom Binary.

Protocolo

HTTP, TCP, BiDirectional TCP, NamedPipes, SMTP, Jabber,

IM, etc
46.

Intra-aplicacin

Inter-aplicacin

47.
Caching

Puede ser necesario en todas las capas

Presentacin

Lgica

Datos
Soluciones

ASP.NET. Caching ASP.NET

Caching Application Block

Warnings

Sincronizacin en ambientes distribuidos

Soluciones: TTL o Metadatos

Mantenimiento

Flush, Disable, Failover

48.
Balanceo de Carga / Alta disponibilidad

Network Load Balancer.

Con WebServices 100% soportado

Con Remoting solo SingleCall

Basado en el servidor

Balanceo estadstico genrico

Custom ClientChannelSink

Que soporte un balanceo desde el cliente, itera por un listado

de servidores cambiando el URI.

Puede ser un balanceo inteligente

49.
Concurrencia

Buscar una opcin para mantener la concurrencia de datos

Dado que hay un ambiente distribuido sin estado en el servidor, hay que
relajar la concurrencia de los datos = optimista.

Se puede usar

SqlDataAdapter

Un Object Relational Mapping tool

50.

Persistencia

Transacciones Distribuidas

Performance

Sesin

Reportes

51.
Persistencia

Programar los DALC puede ser bastante largo y repetitivo

Se pueden usar herramientas ORM

Generacin de cdigo usando CodeSmith, XSLT, etc.

Transacciones Distribuidas

No es un atributo del componente sino del contexto de ejecucin

Implementar soporte transaccional en la capa de Service Interface

52.
Performance

Optimizacin del acceso a la base de datos

Atencin al tamao de los objetos para serializar

Paginacin inteligente obligatoria

Sesin

Modelo totalmente state-less

La sesin se mantiene del Service Interface hacia adelante

En WinForms no hay demasiados problemas

En ASP.NET hay distintas opciones cada una con su costo asociado.

53.

Reportes

QUE PROBLEMA !!!

Depende de la herramienta que se use.

Si bien es un problema de Capa de Presentacin algunas herramientas

necesitan acceso directo a la base de datos.
Otras usan DataSets lo cual se complica si hay sets de datos muy

grandes.

Recomendacin: Sentido comn.

Foglight for .NET

Entrega, Gestin y Control de Aplicaciones .NET
Foglight for .NET le permite a las organizaciones de IT
entregar, administrar y controlar aplicaciones .NET para
incrementar sustancialmente los niveles de servicio y
optimizar los procesos de soporte de las aplicaciones.
La carencia de una adecuada solucin de gestin de
aplicaciones .NET puede tener consecuencias como:

Brochure del Producto

Eventos

Prdida de rdito y productividad de los empleados

debido al tiempo muerto de las aplicaciones crticas
del negocio.

Incapacidad para determinar si las aplicaciones

FOGLIGHT .NET DEMOS

estn cumpliendo sus Service Level Agreements

(SLAs).

Incapacidad para prevenir proactivamente fallas y

degradaciones en el desempeo de las aplicaciones.

Incremento del tiempo, a travs de la organizacin

de TI, requerido para establecer claramente la raz
de la causa de fallas y degradaciones en el
desempeo de las aplicaciones.

Uso ineficiente de los recursos dado que los

desarrolladores gastan mucho tiempo en el soporte
de las aplicaciones existentes.

Quest Application and Services Management

Foglight Transaction
Recorder - Recorrido de
una Aplicacin .NET
Ver demostracin
Foglight - Integracin
con Foglight for .NET
Ver demostracin

Foglight es la nica Solucin de Administracin de Aplicaciones y Servicios que conecta los servicios del
negocio con la infraestructura, a los usuarios finales con las base de datos y produccin con desarrollo,
para unificar TI y el negocio.
Como parte integral de Quests Service Management, Foglight for .NET le permite a las organizaciones
gestionar los niveles de servicio de las aplicaciones .NET a travs de un monitoreo proactivo y
diagnsticos en tiempo real.

Foglight for .NET Consola Web

Foglight for .NET brinda la habilidad de
monitorear continuamente Aplicaciones .NET y
advertir a los administradores sobre problemas
de desempeo, seguridad, conectividad, entre
otros.

Haga Clic aqui para ver el video...

Caractersticas & Beneficios

Beneficios Claves:

 Optimizar el desempeo de las transacciones de las aplicaciones y servicios web.

Validar el desempeo y disponibilidad de las aplicaciones y servicios web.
Detectar, diagnosticar y resolver excepciones complejas y problemas de desempeo de las
aplicaciones y servicios web.

Rpidamente asociar los aspectos de una excepcin con la lnea de cdigo a travs de la
integracin con Visual Studio.

Optimizar el tiempo de los desarrolladores para que la escritura de cdigo agregue valor al
negocio, mientras disminuye el tiempo requerido para el soporte de las aplicaciones.

Maximizar la visibilidad de la aplicacin desde la perspectiva del usuario final hasta la base de
datos cuando Foglight for .NET es usado con Quest's Application Advantage Solution.

Permite realizar el diagnstico, detecccin e identificacin del flujo de llamados, de los

incidentes y de los mdulos .NET de cualquier tipo sin necesidad de incluir o mantener cdigo
adicional en sus aplicaciones. Basta con instalar un agente de Foglight .NET en su Web Server
y su Application Server.

Recoleccin de Datos de Bajo Impacto

Foglight for .NET monitorea aplicaciones con muy bajo overhead, recolectando informacin de
diagnstico solo de aquellas transacciones que se desempean pobremente. Si se da una excesiva
cantidad de fallas o una excesiva ejecucin de eventos, hace ms lento el proceso (throttling) y de esta
forma minimiza el impacto para la aplicacin.

Informar a la Organizacin de TI sobre el Desempeo, Eventos, Fallas y Tendencias de

una Aplicacin
Foglight for .NET tiene la capacidad de monitorear degradaciones en el desempeo y excepciones que
pueden afectar en forma adversa la experiencia del usuario final. Recolectando estos eventos y
comunicndolos al equipo de TI apropiado.

Consola Web de Foglight .NET

Reporte y Anlisis de Tendencias de puntos lgidos en las Aplicaciones

Foglight for .NET informa a los desarrolladores sobre las reas ms problemticas de las aplicaciones y
valida la disponibilidad y confiabilidad con anlisis de tendencias y reportes.

Monitoreo del Desempeo y Disponibilidad

de las Aplicaciones y Servicios Web
Foglight for .NET puede monitorear transacciones en tiempo real y determinar cuando el tiempo de
respuesta de una aplicacin se degrada. Adems detecta problemas antes de que estos afecten al
usuario final o impacten los SLAs, y rastrea las transacciones ms lentas para identificar la causa - raz
de las fallas y problemas de desempeo de las aplicaciones.

Reporte de la Tendecia de los Eventos

Diagnostico en Tiempo Real de la Causa - Raz

Debido a que las aplicaciones de hoy en da tienen una naturaleza altamente distribuida, los problemas
de desempeo pueden ser difciles de identificar y aislar para un componente particular en la
arquitectura de la aplicacin.
Foglight for .NET descubre problemas de desempeo en el ambiente de la aplicacin y asla la causa
raz de esos problemas a un componente en particular. Foglight for .NET gua rpidamente al usuario al
componente problemtico al destacar el nodo en rojo.

Aislamiento de un Cuello de Botella en el Desempeo

Una ves que el cuello de botella es identificado en la aplicacin, el usuario puede hacer un drill-down
dentro de ese componente para observar los detalles del evento que identifiquen el cuello de botella en
el cdigo.

Para ganar el contexto completo de un problema de desempeo, el usuario puede hacer drill-down
sobre las peticiones SQL para observar no solo el SQL en s, sino los parmetros de ese SQL tambin.
Conociendo el contexto completo del problema, el SQL puede ser optimizado apropiadamente con
productos como el SQL Optimizer for Visual Studio o las caractersticas de optimizacin de Toad o
Spotlight.

Contexto Completo de un SQL de Bajo Desempeo

Integracin con Visual Studio

Foglight for .NET viaja directo desde el evento de excepcin hasta la lnea de cdigo a travs de su
Integracin con Visual Studio para agilizar el diagnstico y resolucin.
Conectando Produccin con Desarrollo

Ambiente de Operacin de Aplicaciones .NET

Las Aplicaciones ASP.NET y los Servicios Web funcionan en un ambiente de capas (layered enviroment)
con muchas dependencias. En un servidor particular que este albergando una aplicacin .NET, el
ASP.NET se ejecuta dentro de una instancia del Common Language Runtime (CLR), el cul se hospeda
en un Internet Information Services (IIS) worker process. IIS es una aplicacin que se comunica
directamente con el sistema operativo y es responsable por la interaccin con el Servidor de Hardware y
los Service Application Requests.

Dada la naturaleza de las aplicaciones .Net distribuidas de hoy, que impulsan tecnologas como .NET
Remoting ASP.NET Web Services, la complejidad de las aplicaciones se incrementa
considerablemente. Las aplicaciones confan en otras infraestructuras como bases de datos o Servicios
Web de terceras partes. Incluso el escenario ms bsico puede involucrar servidores web, lgica de
negocio o niveles de servicio as como servidores de base de datos.