Saber hacer compras es importante. Es casi inimaginable que alguien le pregunte a su vecino "Me haces la lista de compras?" porque obviamente los gustos varian o pueden haber consideraciones médicas o de otra indole que hacen que la comida de uno no sea la adecuada para otros. Definitivamente se aprecia cuando nos sugieren algo nuevo, pero al final termina uno decidiendo.
Sin embargo, con el desarrollo pasa algo diferente: Todo el mundo espera que los demás le digan que hacer y con que hacerlo, aunque al final (y repetidamente) nos cause "indigestión". El problema es un poco complicado porque la técnologia es complicada. Aunque se aprecien las recomendaciones, debemos saber hacer la "lista de compras". Para ello, es bueno hacer las siguientes preguntas, divididas entre los distintos componentes principales de una aplicación multi-nivel:
Base de datos
Dividamos en los grupos las bases de datos:
Sin embargo, con el desarrollo pasa algo diferente: Todo el mundo espera que los demás le digan que hacer y con que hacerlo, aunque al final (y repetidamente) nos cause "indigestión". El problema es un poco complicado porque la técnologia es complicada. Aunque se aprecien las recomendaciones, debemos saber hacer la "lista de compras". Para ello, es bueno hacer las siguientes preguntas, divididas entre los distintos componentes principales de una aplicación multi-nivel:
Base de datos
Dividamos en los grupos las bases de datos:
- Motores Sql
Son aquellas que tienen un componente servidor, se accesan por un protocolo de Red, y usan principalmente Sql (el lenguaje). Se instalan independientemente de la aplicación y se accesan comúnmente por más de una aplicación.
Ejemplos: Sql Server, MSDE, Oracle, Interbase/Firebird, MySql, Postgree, nexusDB.
Ejemplos: Sql Server, MSDE, Oracle, Interbase/Firebird, MySql, Postgree, nexusDB.
- Embeidas o incrustradas
Aquellas que tienen la capacidad de almacenar localmente datos, no requieren administración y estan intimamente ligadas a la aplicación y por lo general son útiles solo a ella.
Ejemplos: Firebird Embebed, NexusDB, MySql?, Acces, Paradox.
Tradicionalmente, la mayoría de los programadores de Delphi conocen por primera vez Paradox. Igualmente si vienen de programar en Visual Basic entonces Acces. Aunque esas bases de datos sean aceptables, para aplicaciones Multi-Nivel es mejor NO usarlas. Para elegir una base de datos se debe considerar:
Ejemplos: Firebird Embebed, NexusDB, MySql?, Acces, Paradox.
Tradicionalmente, la mayoría de los programadores de Delphi conocen por primera vez Paradox. Igualmente si vienen de programar en Visual Basic entonces Acces. Aunque esas bases de datos sean aceptables, para aplicaciones Multi-Nivel es mejor NO usarlas. Para elegir una base de datos se debe considerar:
- Mercado objetivo:
¿Nuestros posibles clientes ya invirtieron en una plataforma de base de datos, compraron o tienen Sql Server, Oracle, DB2, MySql, etc...? Igualmente ¿Cual plataforma estarían más dispuesto a aceptar? ¿Disponen de un administrador que se encarge de parchar, configurar, asegurar e integrar la base de datos, o es poco probable?
Digamos que el mercado se divide en "Empresarial" y "lo demás". Un mercado empresarial responde mejor si nos integramos con lo que ya tienen, lo cual implica el combo 3: Sql Server, Oracle, DB2. Si el cliente esta sobre Linux, lo más probable es que el combo sea MySql, Oracle, DB2 o Postgree.
Nos haremos un favor si aceptamos que el cliente ha adquirido una plataforma y esta deseoso de poder aprovecharla al máximo. Sin embargo en "lo demás" incluyamos todo caso en donde a)No hay quien administre la BD b)Se requiere una aplicación compacta, con costos muy bajos o nulos de administración c)Utilidades o aplicaciones que almacenan información pero que sobreviven por fuera del entorno empresarial o se integran por otros medios (por ejemplo, si hacemos una aplicación como un cliente de correo, es poco probable que justifique almacenar los correos en una BD empresarial)
Si hacemos una aplicación que puda ser desplegada en un hosting externo, recordemos que las opciones más obvias son Sql Server, Acces, MySql.
Digamos que el mercado se divide en "Empresarial" y "lo demás". Un mercado empresarial responde mejor si nos integramos con lo que ya tienen, lo cual implica el combo 3: Sql Server, Oracle, DB2. Si el cliente esta sobre Linux, lo más probable es que el combo sea MySql, Oracle, DB2 o Postgree.
Nos haremos un favor si aceptamos que el cliente ha adquirido una plataforma y esta deseoso de poder aprovecharla al máximo. Sin embargo en "lo demás" incluyamos todo caso en donde a)No hay quien administre la BD b)Se requiere una aplicación compacta, con costos muy bajos o nulos de administración c)Utilidades o aplicaciones que almacenan información pero que sobreviven por fuera del entorno empresarial o se integran por otros medios (por ejemplo, si hacemos una aplicación como un cliente de correo, es poco probable que justifique almacenar los correos en una BD empresarial)
Si hacemos una aplicación que puda ser desplegada en un hosting externo, recordemos que las opciones más obvias son Sql Server, Acces, MySql.
- Portabilidad, Administración
¿Necesitamos que funcione en varias plataformas (De Win95 a Win2003 o Windows/Linux?) ¿El cliente obtiene más valor si administra la BD o si no lo hace?
La segunda pregunta es MUY importante. Si un cliente PIDE algo como Sql Server lo más probable es que el mayor valor lo obtenga en administrar su BD, o reusar la plataforma (por ejemplo: otras aplicaciones que compro usan Sql Server). Sin embargo, si tenemos como clientes a Pequeñas y Medianas empresas, o usuarios finales, el mayor valor está en NO tener que preocuparse por la base de datos (lo máximo será hacer copias). En este caso, una base de datos embeida es mucho mejor.
La segunda pregunta es MUY importante. Si un cliente PIDE algo como Sql Server lo más probable es que el mayor valor lo obtenga en administrar su BD, o reusar la plataforma (por ejemplo: otras aplicaciones que compro usan Sql Server). Sin embargo, si tenemos como clientes a Pequeñas y Medianas empresas, o usuarios finales, el mayor valor está en NO tener que preocuparse por la base de datos (lo máximo será hacer copias). En este caso, una base de datos embeida es mucho mejor.
- Estabilidad, Seguridad
Una base de datos es algo serio. No importa si almacena tarjetas de crédito o simplimente la lista de amigos: a nadie le gusta que se corrompan o pierdan los datos. Es por eso que motores como Paradox o FoxPro (el viejo) no tienen caso: no son estables ni seguros. Acces casi cae en esta categoría pero el uso común que tiene puede obligar su uso. El punto es que una base de datos, sea cual sea el uso que se le de, debe ser estable o proveer minimamente acceso seguro por contraseñas. Todas las que menciono cumplen con estas características a mayor o menor grado.
Un punto meritorio es que una base de datos para un sistema multi-nivel recibirá una carga de trabajo característica: Multiples clientes o threads (hilos) enviarán constatemente peticiones de datos. Es por eso que una base de datos que sea un motor sql (sea o no embeido) es la elección mas sabia. Una base de datos de archivos como Acces, Paradox, FoxPro NO esta hecha para esa carga de trabajo.
Un punto meritorio es que una base de datos para un sistema multi-nivel recibirá una carga de trabajo característica: Multiples clientes o threads (hilos) enviarán constatemente peticiones de datos. Es por eso que una base de datos que sea un motor sql (sea o no embeido) es la elección mas sabia. Una base de datos de archivos como Acces, Paradox, FoxPro NO esta hecha para esa carga de trabajo.
- Precio
Aunque de último, también es importante. Como regla general, los clientes empresariales DESEAN un motor comercial, asi que está bien usar uno. Sin embargo, a un cliente "pequeño" o usuario final lo puede perturbar que le cobren adicional por tener un motor de datos (que porque no lo va a reusar ni integrar no tiene justificación para costar de más) y se espera que el productor del programa se encarge de esto. Una base de datos embeida o gratis (como Firebird que cumple ambas) sería mucha mejor elección. Sea cual sea, el fabricante debería de incluir cualquier costo de la plataforma de datos dentro del programa.
Comunicación
Básicamente tenemos a nuestra disposición como desarrolladores de Delphi (marco como incluido a aquellas cosas que podemos usar en Delphi sin adquirir nada más):
Comunicación
Básicamente tenemos a nuestra disposición como desarrolladores de Delphi (marco como incluido a aquellas cosas que podemos usar en Delphi sin adquirir nada más):
- DCOM/COM+ (incluido: Viene en Windows)
- TCP/IP, UDP, HTTP (incluido: Indy y disponible con otros)
- SOAP/Servicios Web (incluido y disponible con terceros)
- .NET Remoting (incluido Delphi 8)
- MsgConnect (producto de terceros)
- RemObjects (producto de terceros)
- Kbmw (producto de terceros)
- Asta (producto de terceros)
Y otros que no listo aquí por ser menos populares.
Estas preguntas nos ayudarán a enteder que sistema de comunicación usar:
Estas preguntas nos ayudarán a enteder que sistema de comunicación usar:
- Esfuerzo
Como en todo, existe programación de "bajo" nivel y de "alto" nivel. O como me gusta decir, de alto esfuerzo y de bajo esfuerzo ;)
Una aplicación multi-nivel TIENE que lidiar con algunos o todos de estos requerimientos:
Una aplicación multi-nivel TIENE que lidiar con algunos o todos de estos requerimientos:
- Seguridad: Autenticar usuarios? cifrar conexión? Usar certificados? Abierta al mundo, en internet o dentro de una intranet?
- Rendimiento: Comprimir datos? Respuesta en tiempo real? Debe permitir comunicación en las dos vias - del servidor al cliente tambien, como en un chat-?
- Empaquetado: En forma binaria? XML?
- Estabilidad: Debe tener balanceo de carga? Fail-over?
- Manejo de sesión: Donde se almacena la sesión del usuario?
- Compatibilidad/Interoperabilidad: Debe soportar múltiples plataformas?
- Despliegue: Requiere un administrador de red para poder ser usado? Pasará sin complicaciones a travez de un firewall? Requiere alterar la máquina del cliente con componentes adicionales?
Esto implica que la parte de la comunicación se puede complicar bastante. Esfuerzo implica que si nos bajamos mucho de nivel (por ejemplo, TCP/IP) tendremos que implementar más servicios que si elegimos, o compramos, una solución más adecuada. Despues de haber trabajado en por lo menos 3 desarrollos importantes de tipo multi-nivel no hay que subestimar los altos costos en tiempo y esfuerzo que demanda la parte de la comunicación. NO quiero decir que este mál usar TCP/IP, sino que el protocolo es solo UNA PARTE de la solución completa.
Si vamos a hacer aplicaciones tipo servidor y clientes tradicionales de Internet (como un servidor FTP), o de alto rendimiento entonces es probable que nos vamos por los protocolos básicos. De lo contrario si hacemos aplicaciones de negocios (como una contabilidad) es MUCHO mejor ir con un framework prediseñado (como DataSnap, RemObject o ASTA). Les garantizó: les ahorrará muchos dolores de cabeza.
Si vamos a hacer aplicaciones tipo servidor y clientes tradicionales de Internet (como un servidor FTP), o de alto rendimiento entonces es probable que nos vamos por los protocolos básicos. De lo contrario si hacemos aplicaciones de negocios (como una contabilidad) es MUCHO mejor ir con un framework prediseñado (como DataSnap, RemObject o ASTA). Les garantizó: les ahorrará muchos dolores de cabeza.
- Enfoque
El enfoque se refiere al tipo de comunicación que por lo general se usará en el sistema.
- Archivos (como un sistema FTP)
Lo clave aquí es poder hacer comunicación binaria, posiblemente asincronica. Un framework como MsgConnect, RemObject, los componentes de Indy o .NET remoting son candidatos.
- Peer-to-peer: mensajería tipo chat
Es fundamental la comunicación en tiempo real, con comunicación en dos vías: Indy, MsgConnect, RemObjects.
- Aplicaciones de negocios y bases de datos
Requieren el espectro completo de la comunicación (seguridad, rendimiento, empaquetado, interoperabilidad, etc...) lo que implica que es MALA idea irse muy bajo. Si nos vamos con indy o TCP/IP plano nos cargaremos un trabajo que requiere una serie de habilidades diferentes al manejo de bases de datos. Es mucho mejor irse con DataSnap, RemObjects (y tal vez junto a DataAbstract), ASTA, Kbmw. Este es el area de los frameworks completos, sin duda.
El enfoque tambien está en el "estilo" del API de comunicación. Asta y DataSnap es orientado a DataSets. RemObjects/COM+ es a objetos. MsgConnect/SOAP a mensajes. Indy comandos.
El enfoque tambien está en el "estilo" del API de comunicación. Asta y DataSnap es orientado a DataSets. RemObjects/COM+ es a objetos. MsgConnect/SOAP a mensajes. Indy comandos.
- Interoperabilidad, despliegue
Depende enormemente en el uso de los formatos de intercambio de datos y la manera de conectarse. El despliegue implica si el ambiente es intranet o extranet.
En estos casos, la clave es usar protocolos estandar: Http/Https, SOAP, XML. Lo cual reduce las opciones a servicios web.
NO es buena idea intentar forzar un formato propietario porque al final, nadie querrá conversar con nuestro sistema ;)
Sin embargo, el uso de XML y SOAP / Http significa perdida de rendimiento y capacidad (sencilla) de comunicación tiempo real y en dos vias (que es el dominio de TCP/IP y UDP). Si deseamos AMBAS cosas debemos buscar un producto hibrido (como RemObject, ASTA y .NET Remoting) que permite intercambiar libremente protocolos y formatos (por ejemplo, RemObject permite usar a la vez Binario y XML, Http y TCP/IP sin alterar el código).
El despliegue impacta que tan fácil es la administración. Usando http y Soap (sea formato binario o XML) tendremos los menores problemas por causa de Firewalls. Usar DCOM/COM+ requiere un esfuerzo de administración mayor, especialmente si nuestra aplicación se distribuye masivamente y a clientes inferiores a Windows 2000. Igualmente .NET remoting requiere el despliegue de los prerequisitos y el runtime .NET.
En estos casos, la clave es usar protocolos estandar: Http/Https, SOAP, XML. Lo cual reduce las opciones a servicios web.
NO es buena idea intentar forzar un formato propietario porque al final, nadie querrá conversar con nuestro sistema ;)
Sin embargo, el uso de XML y SOAP / Http significa perdida de rendimiento y capacidad (sencilla) de comunicación tiempo real y en dos vias (que es el dominio de TCP/IP y UDP). Si deseamos AMBAS cosas debemos buscar un producto hibrido (como RemObject, ASTA y .NET Remoting) que permite intercambiar libremente protocolos y formatos (por ejemplo, RemObject permite usar a la vez Binario y XML, Http y TCP/IP sin alterar el código).
El despliegue impacta que tan fácil es la administración. Usando http y Soap (sea formato binario o XML) tendremos los menores problemas por causa de Firewalls. Usar DCOM/COM+ requiere un esfuerzo de administración mayor, especialmente si nuestra aplicación se distribuye masivamente y a clientes inferiores a Windows 2000. Igualmente .NET remoting requiere el despliegue de los prerequisitos y el runtime .NET.
- Seguridad, Desempeño, Escalabilidad
Tradicionalmente, DCOM/COM+ tienen por defecto lo mejor de estos 3. El hecho que se integre con la seguridad de Windows y sea aceptado en el ambiente empresarial es un punto fuerte. Sus capacidades de desempeño son muy buenas, y es muy fácil de usar con Delphi. En un ambiente Intranet/Windows para clientes corporativos seria una buena opción. Por otro lado, RemObjects, Asta proveen capacidades equiparables. DataSnap, Indy, .NET remoting requiere más esfuerzo en esta area.
El combo Base de Datos/Librería de comunicación es el núcleo del éxito en una aplicación n-tier y significa la diferencia entre una aplicación exitosa y una que no cumple con las expectativas. Es bueno tomarse el tiempo de analizar las alternativas ANTES de comprometerse a una en particular, porque una vez realizado es practicamente seguro que hay que depender de ella, con todos los problemas y dificultades, no solo durante el desarrollo sino a travez de la vida de la aplicación (que puede ser años!).
Espero que estas consideraciones sean útiles. Para la próxima ahora si algo más practico!
El combo Base de Datos/Librería de comunicación es el núcleo del éxito en una aplicación n-tier y significa la diferencia entre una aplicación exitosa y una que no cumple con las expectativas. Es bueno tomarse el tiempo de analizar las alternativas ANTES de comprometerse a una en particular, porque una vez realizado es practicamente seguro que hay que depender de ella, con todos los problemas y dificultades, no solo durante el desarrollo sino a travez de la vida de la aplicación (que puede ser años!).
Espero que estas consideraciones sean útiles. Para la próxima ahora si algo más practico!
Etiquetas: Mejorar como programador