UNIVERSIDAD YACAMBU ANÁLISIS Y DISEÑO DE SISTEMAS C.I:
6.504.212 Trabajo No. 2
ESPECIALIZACION EN GERENCIA
MENCION SISTEMAS DE INFORMACION
Prof.: Yaros Pérez
Autor: Manuel
Alvarez
1. JSP
¿Qué es JSP?
Java Server Pages (JSP) es una tecnología que permite mezclar HTML estático con HTML
generado dinámicamente. JSP permite crear por una parte el HTML estático, que comparten
todas las páginas que se vayan a crear, y por otro lado se mete el código Java que generará la
parte dinámica de la página.
¿Cómo funciona?
La página JSP pasa por tres etapas en la evolución de su código, administradas por el
contenedor de JSP:
Código fuente JSP: lo escribe el desarrollador, se encuentra en un archivo de extensión
.jsp en el que se mezcla HTML y código Java, con el fin de generar una página Web
para dar servicio a una petición de usuario.
Código fuente Java: el contenedor de JSP traduce el código fuente JSP a código fuente
de un Servlet Java equivalente.
Clase Java compilada: Como cualquier otra clase Java compilada el código Servlet se
compila en una clase Java que se guarda en un fichero .class preparado para ser cargado
y ejecutado.
En caso que se modifique el código fuente JSP el contenedor vuelve a hacer todo el
proceso de recompilado automáticamente basándose en la situación temporal del archivo. De
esta forma aunque es muy costoso crear el Servlet cuando se hace la primera petición, las
posteriores peticiones no provocan volver a pasar por todos los pasos, por lo que es una buena
práctica que el desarrollador visite la página por primera vez, para que cuando llegue el primer
cliente obtenga una respuesta rápida.
Elementos de JSP
Además del HTML normal, hay tres tipos de construcciones JSP que se embeberán en una
página: elementos de script, directivas y acciones. Aquí se ven de forma breve, si se quiere una
mayor profundización en ellos se aconseja dirigirse a [1].
Elementos de Script: Los elementos de script permiten insertar código Java dentro del
Servlet, que se generará desde la página JSP actual, de tres formas diferentes:
o Expresiones: Los elementos de script permiten insertar dentro del HTML,
como si se hubiese hecho un printl() en un Servlet, el valor de vuelto por una
sección de código Java. El único requisito es que estas expresiones puedan ser
evaluadas como un java.util.String (una cadena o un valor).
Son de la forma: <%= expresión java %>
o Scriptlets: Conjunto de instrucciones en Java de cualquier tipo. Todo lo que se
quiera incluir en el código HTML ha de imprimirse mediante el objeto implícito
out.
Forma: <% instrucción;[instrucción;...] %>
o Declaraciones: Permite definir métodos o campos que serán insertados dentro
del cuerpo principal de la clase Servlet (fuera del método service que procesa la
petición) y que compartirán todos los clientes.
Tienen la siguiente forma: <%! código java %>
Directivas: Son instrucciones dirigidas al contenedor de JSP que describen el código
que se debe generar, con lo que afectan a la estructura general de la clase Servlet. La
especificación JSP 1.1 describe 3 directivas estándar disponibles en todos los entornos
compatibles con JSP. Estas son:
o page: Se emplea para especificar una serie de atributos para toda la página JSP
en su conjunto. Los atributos que se pueden especificar están recogidos en [1].
Ej.: <%@ page [atributo = “valor” atributo = “valor” ...]%>
o include: Fusiona en el momento de la traducción el contenido del fichero
referenciado con el conjunto de la entrada del código fuente JSP. Como hace la
directiva del preprocesador de C #include.
Ej: <%@ include file = “ruta fichero” %>
o taglib: Hace que las acciones personalizadas estén disponibles en la página
actual mediante el uso de una biblioteca de etiquetas.
Ej: <% @ taglib uri = “taglibrary uri” prefix = “tagprefix” %>
Acciones: Son elementos de alto nivel de JSP que usan construcciones de sintaxis XML
para controlar el comportamiento del motor de Servlets, es decir, permiten crear,
modificar o utilizar otros objetos.
Sintaxis: < nombre_etiqueta [atr = “valor” atr = “valor” ...]> ... </nombre_etiqueta>
o
< nombre_etiqueta [atr = “valor” atr = “valor” ...] />
Ejemplo: La forma más sencilla de usar un Bean es usar:
<jsp:useBean
id="name" class="package.class"
/>
Además de estos elementos, JSP proporciona una serie de facilidades adicionales mediante
los siguientes elementos:
Extensiones de etiquetas: Refuerzan la arquitectura JSP posibilitando la ampliación
del entorno de creación de páginas, permitiendo crear etiquetas propias.
Objetos implícitos: Para simplificar el código en expresiones y scriplets JSP, tenemos
ocho variables definidas automáticamente, que completan el entorno en el que operar.
Se pueden utilizar en cualquier página nada más que poniendo su nombre:
o request: Este es el HttpServletRequest asociado con la petición, y permite mirar
los parámetros de la petición.
o response: Este es el HttpServletResponse asociado con la respuesta al cliente.
o pageContext: Medio de obtener acceso a la página, a la respuesta, a la sesión o
a los atributos de la aplicación.
o session: Este es el objeto HttpSession asociado con la petición. Gracias al cual
JSP permite el uso de sesiones, recordemos que HTTP es un protocolo “sin
estado” y había que ingeniárselas para seguir la sesión mediante el uso de
cookies, rescribiendo
o application: Este es el ServletContext obtenido mediante
getServletConfig().getContext() .
o out: el objeto de flujo de salida de la respuesta JspWriter.
o config: el objeto de configuración del Servlet.
o page: Esto es sólo un sinónimo de this, y no es muy útil en Java. Fue creado
como situación para el día que los lenguajes de script puedan incluir otros
lenguajes distintos de Java.
o exception: Es una excepción sin capturar válida solo en páginas de error.
¿Qué es JDBC?
Primero cabe aclarar el significado de sus siglas. Se relaciona muy a menudo con el acrónimo
ODBC por lo que se suele expresar como Java Database Connectivity pero oficialmente, según
Javasoft, JDBC no significa nada ni es acrónimo de nada.
JDBC es una interfaz de programación de aplicaciones (API de inglés Aplication Program
Interface) entre los programas Java y sistemas RDBMS (Relational Database Management
System) independiente de la plataforma y del gestor de bases de datos utilizado.
Es una interfaz al nivel de llamada. Esto significa que un programa emplea llamadas a
funciones o métodos para tener acceso a las características del sistema gestor de bases de datos,
en oposición a las instrucciones SQL incrustadas, traducidas por el precompilador. Esto permite
tener una, mayor flexibilidad a la hora de realizar peticiones, ya que no hace falta tener
precompiladas todas y cada una de las posibles consultas en SQL que vayamos a usar.
Arquitectura
La interacción típica con una base de datos consta de los siguientes cuatro pasos básicos:
Abrir la conexión a la base de datos
Ejecutar consultas contra la base de datos
Procesar los resultados
Cerrar la conexión a la base de datos
Pero JDBC abstrae al desarrolador del Sistema Gestor que tenga nuestra base de datos por
lo que tendremos que cargar inicialmente el controlador que lleve a cabo dicha función,
introduciendo así un nuevo paso anterior a todos los demás
Cargar la clase del controlador JDBC
Conclusiones
Tecnologías como JSP han supuesto un cambio importante en la gestión de los negocios, ya que
facilitan de sobremanera el ofertar a clientes de todos los rincones del mundo sus productos o
servicios a través de la red de redes (Internet) sin necesidad de programas clientes específicos en el ordenador del cliente.
La ventaja principal que aporta JSP al mundo empresarial ha sido poder encargar a profesionales de páginas Web la apariencia de su página y el funcionamiento a expertos java sin problemas engorrosos de ningún tipo.
Se debe admitir que es una tecnología muy nueva, por lo que todavía falta mucho camino por andar antes que compita en términos reales contra otras aplicaciones que están más maduras como SSI, PHP del grupo PHP, ASP de Microsoft o Cold Fusión de Allaire, pero su promesa es muy interesante (como se publicó en el año 2002 en http://www.mexicoextremo.com.mx).
Por otro lado debemos considerar que casi todas las aplicaciones JSP necesitan acceder a bases de datos. JDBC es el API estándar que proporciona Java para este propósito. Permite acceder a casi cualquier base de datos trabajando sobre ella mediante una programación orientada a objetos con la misma capacidad que se hiciese directamente en SQL.
Además al existir pocos objetos clave es fácil de aprender. El objeto Connection crea un vínculo con la base de datos, el Statement hace posible ejecutar instrucciones SQL y recuperar un ResultSet donde está el conjunto de resultados.
Así JDBC es el complemento ideal para tanto Servlets, como JSP ya que les añade una característica indispensable, que es el acceso a datos. Además no es una tecnología estancada sin que está en evolucionando constantemente y cada versión proporciona características mejoradas, siendo así la tecnología dominante para acceso a datos desde Java.
A la vista de lo expuesto, programar en JSP ayudándose de JDBC es una opción muy interesante a considerar para el desarrollo de aplicaciones Web. Además es de especial interés para la gente familiarizada con Java, pues no necesitan aprender otro lenguaje.
1.2 Acceso a Datos Relacionales Bajo un Entorno XML
Abstract.
En nuestros días y especialmente con la explosión de Internet, las
organizaciones tienen que manejar multitud de datos y además datos de fuentes
heterogéneas, como por ejemplo datos procedentes de las tradicionales bases de
datos relacionales y otros procedentes de nuevas tipos de datos aparecidos con
Introducción
Internet esta provocando grandes
cambios en las organizaciones y su gestión. Toda organización tiene que acabar
migrando a
Los nuevos entornos de trabajo
han hecho aparecer nuevos tipos y formatos de datos, como los utilizados para
la publicación de información en
En conclusión, en la organización se tiene que trabajar al mismo tiempo con datos procedentes de fuentes heterogéneas más o menos estructuradas, y por tanto será necesario en muchos casos, algún método intermedio que sirva como mediador y que permita integrar estos datos con diferentes formatos para trabajar de forma conjunta con ellos.
En cuanto a los nuevos tipos de
datos creados como respuesta a las necesidades de
El mundo de las bases de datos también se ha visto afectado por los nuevos cambios. Por un lado, las tradicionales bases de datos relacionales siguen almacenando la mayor parte de información de la organización, pero en las últimas versiones de los sistemas de gestión de base de datos, se han visto obligados también a adaptarse a las nuevas necesidades, por ejemplo permitiendo también tratar y almacenar información en formato XML, aunque el tema del almacenamiento de información XML en bases de datos relacionales quede fuera del ámbito de este trabajo.
También en relación con las bases de datos han aparecido nuevos tipos como los data warehouse, que se han convertido en sistemas de almacenamiento de datos de fuentes heterogéneas, desde los que luego se analizan esos datos para convertirlos en información y conocimiento y así ayudar a la toma de decisiones de la organización. En estos nuevos sistemas se harán también necesarios métodos para permitir integrar estos datos como paso previo a su análisis.
En nuestro trabajo, demostrada la
importancia de XML en el medio Web por un lado, y la gran cantidad de
información que continua siendo almacenada en las bases de datos relacionales,
estudiaremos como podemos tratar de forma conjunta datos procedentes de ambos
entornos. Si los datos procedentes de uno u otro entorno pudiesen estar en el
mismo formato común, XML al ser éste el lenguaje de
El objeto de nuestra investigación será precisamente, proporcionar un entorno de acceso común para datos en formato XML y relacionales al que hemos denominado XBD (acceso a Bases de Datos con XML) . Para el usuario resultará un sistema transparente en cuanto a que accederá a datos XML y relacionales de una forma muy similar, con lo que para él es como si toda la información estuviera en formato XML y sólo estuviese consultando datos de este tipo. Se trata por tanto de acceder a datos relacionales bajo un sistema con apariencia de consulta a datos XML. El resultado obtenido tras las consultas a la base de datos relacional, también sería XML.
Según lo expuesto, una vez vistas en esta introducción las necesidades que las nuevas tecnologías plantean a las organizaciones, queda con ello justificado la utilidad del nuevo entorno de consulta a bases de datos relacionales que proponemos.
En el siguiente apartado se tratará de hacer un estudio de la situación actual de otros sistemas que también tienen relación con el tema de las bases de datos y XML, permitiendo obtener datos XML de fuentes relacionales. A continuación, y una vez analizados las limitaciones de los sistemas estudiados con relación a nuestros objetivos, ya se pasaría por fin a describir en detalle las características de nuestro nuevo sistema de consulta XBD que hemos diseñado como respuesta a las nuevas necesidades de gestión de datos heterogéneos. La descripción del sistema incluirá su arquitectura, el modelo de adaptación que se propone para que cualquier base de datos relacional pueda ser consultada en el entorno XBD, los lenguajes de consulta que en él se utilizan y el procesamiento en general de las consultas en este sistema. Finalmente se demostrarán sus ventajas y las pruebas que con él se han realizado y por último se expondrían las nuevas líneas de investigación en las que estamos ya trabajando y que siguen relacionadas con el área de la integración entre datos relacionales y XML, pero tratada desde una nueva perspectiva.
Obtención de datos XML de Fuentes Relacionales
El propósito de nuestra investigación es ayudar a integrar bases de datos relacionales con datos XML, obteniendo datos XML a partir de información almacenada en base de datos relacionales. Una vez logrado que tanto la información procedente de fuentes XML como de fuentes relacionales esté en el mismo formato, en nuestro caso XML, resultará más fácil trabajar de forma conjunta con ella, tal como se hace necesario en muchos sistemas actuales.
Las últimas versiones de los Sistemas de Gestión de Base de Datos (SGBD) más utilizados como Oracle [6][7], Microsoft SQL Server [5] o IBM DB2 [4], han tenido que adaptarse a los nuevos tipos de información permitiendo trabajar de una forma más o menos directa con datos XML.
En consecuencia, estos SGBD ya permiten almacenar datos XML junto a sus tradicionales datos relacionales, definiendo nuevos tipos de datos como XMLType en Oracle y SQL Server, o XML Column y XML Collection en DB2. Una vez almacenada la información XML en la base de datos habrá que disponer también de herramientas para acceder a ella. Si la información en XML almacenada en la base de datos tiene una estructura más o menos fija (documento XML centrado en los datos) y reconocida por la base de datos a través de una especie de esquema, conocido por ejemplo como DAD (Definición de Acceso a Datos) en IBM DB2, se podrá acceder en detalle a la información XML almacenada. Esto se consigue en la mayor parte de los SGBD ampliando el lenguaje de consulta estándar SQL con construcciones de XPath embebidas en dichas consultas SQL y dirigidas a los datos XML. Si no hay una estructura reconocida de la información XML almacenada, es decir, se trata de documentos XML centrados en el documento sin una estructura prefijada, no en los datos, los SGBD permitirán acceder a todo el documento XML en su conjunto, al documento XML completo, no a una parte en particular del mismo.
Sin embargo, todos los aspectos de las nuevas versiones de los SGBD que acabamos de comentar en relación a XML se refieren al almacenamiento de este tipo de información en las bases de datos relacionales y nosotros estamos más interesados
no en el almacenamiento, sino en la obtención de datos en formato XML generados a partir de información que no está en este formato. En este sentido también los SGBD están proporcionando nuevas herramientas que permiten realizar consultas a las bases de datos en el tradicional lenguaje de consultas de datos relacionales SQL, y obtiene los resultados de la consulta en XML.
Los mismos resultados que con estas últimas herramientas se pueden conseguir con las páginas activas como las JSP (Java Server Pages), ASP (Active Server Pages) o PHP. En todas ellas es posible incluir consultas a base de datos en SQL y obtener los resultados de dichas consultas en XML. Estos resultados se añadirán al resto del contenido de la página Web a la hora de mostrar su información final.
En los dos casos anteriores, tanto los de la herramientas de los SGBD que retornan los resultados en XML como en las páginas activas, la consulta se realiza utilizando un lenguaje propio del entorno de base de datos como SQL. Sin embargo, nuestro objetivo es que para facilitar la integración de datos relacionales con datos XML y que el usuario no tenga que preocuparse ni del formato, ni del tipo de fuente al que accede, y ni siquiera del lenguaje de consulta, sino que para él es como si todo lo que consulta fuese información en XML, por esta razón el lenguaje de consulta también debería estar basado en XML, no ser un lenguaje del entorno de base de datos. Esto por tanto representa una desventaja de las herramientas anteriores si tenemos en cuenta nuestras metas.
En este sentido, existen ya algunos sistemas que permiten la consulta a bases de datos relacionales obteniendo los resultados en XML, pero además usando lenguajes de consulta propios del entorno XMLm y sin que los datos originales de la base de datos tengan que sufrir ningún tipo de transformación ni traducción a ningún formato. Dentro de estos sistemas destacan SilkRoute [1] y XTABLES [2].
En ambos trabajos se propone la creación de una vista virtual en XML de los datos de la base de datos y sobre esta vista se realizan las consultas. La vista se considera virtual porque en realidad los datos de la base de datos no se transforman a XML, se le presentan al usuario con apariencia XML, pero en realidad ni se traducen, ni se almacenan en XML. En los dos sistemas se realiza una consulta inicial a partir de la cual se genera esa vista virtual XML, que contendrá a los datos de la base de datos afectados por la consulta y el resto de consultas tendrán que hacerse sobre los datos de esa vista virtual y en un lenguaje de consulta basado en XML, es decir, se condiciona al resto de consultas a los resultados obtenidos en esa consulta inicial.
En XML la vista XML virtual recibe el nombre de “default view” y como único lenguaje de consulta, tanto para la consulta inicial como para el resto, se utiliza XQuery. En SilkRoute la vista virtual obtenida tras la primera consulta recibe el nombre de “query view” y para obtenerla se utiliza un lenguaje propio de este sistema denominado RXL. El resto de consultas se realizarán sobre los datos de la vista virtual pero utilizando otro lenguaje de consulta denominado XML-QL.
El fin último de estos dos sistemas coinciden con el nuestro, se consulta una base de datos relacional obteniendo los resultados de la consulta en formato XML y además utilizando también lenguajes basados en XML para hacer las consultas y sin necesidad de realizar ninguna transformación de los datos a consultar. El inconveniente sin embargo de estos dos sistemas, es que en ambos existe una consulta inicial que condiciona al resto de consultas, tal que sólo podrán ser consultados los datos afectados por esta primera consulta. En el sistema que nosotros proponemos se
consiguen los mismos resultados, consultar datos relacionales con lenguajes de consulta basados en XML y obtener también los resultados en XML, pero de forma que en cualquier momento se pueda consultar cualquier parte o dato de la base de datos, no existirá una consulta inicial que condicione el resto de consultas, y esta es otra de sus ventajas. Como luego veremos en este nuevo sistema al que denominamos XBD ya no existe ninguna vista virtual porque el proceso de adaptación y consulta de cualquier base de datos relacional bajo este entorno es distinto a la idea de la “vista virtual XML”, en su lugar se crea el “Esquema XML De Base de Datos” que es un documento XML con un significado distinto al de la vista virtual.
Analizadas las características de estos sistemas que permiten obtener datos XML de fuentes relacionales y expuestas sus limitaciones e inconvenientes de acuerdo a nuestros objetivos, a continuación exponemos las características del nuevo sistema que nosotros proponemos denominado XBD, y después demostraremos sus ventajas y bondades con relación a los sistemas analizados y a nuestras metas.
El nuevo Sistema de Consulta XBD
La idea fundamental del nuevo sistema XBD (XML para Bases de Datos) que nosotros proponemos, y del que podemos encontrar un estudio más detallado en [1], trata de solventar los principales problemas de los sistemas analizados en relación con el tratamiento de datos relacionales y XML en el entorno Web.
En nuestro sistema será posible consultar datos relacionales bajo un entorno con apariencia XML, de hecho, para el usuario la apariencia es prácticamente igual a la consulta a datos XML incluido el lenguaje de consulta, como luego veremos, y los resultados obtenidos, que también serán XML.
Para poder hacer efectivas estas consultas además, la gran ventaja es que no se necesita hacer ninguna conversión de información. No es necesario traducir los datos relacionales a XML, y ni siquiera será necesario mostrar estos datos como una vista XML.
Para conseguir estos objetivos hay que afrontar dos aspectos fundamentales, por una parte, cómo se van a consultar los datos relacionales, con qué lenguaje, y en segundo lugar, cuál debe ser la arquitectura interna del sistema que permita que hechas las consultas a la base de datos en el lenguaje del sistema, los resultados obtenidos en formato ya XML, sean los correctos.
Para permitir consultar una base de datos desde el entorno XBD serán necesarios dos procesos básicos. El primero permitirá adaptar la base de datos de modo que esta sea consultada en nuestro sistema. Para ello, ahora no se obtendrá una vista virtual en XML como en los casos anteriores, sino que se propondrá otra solución distinta de modo que como resultado del proceso se obtendrá el documento en formato XML que denominamos “Esquema XML de BD” cuyo significado explicaremos luego. Una vez adaptada la base de datos, el siguiente proceso ya nos permitirá que sea consultada. Para ello será necesario especificar por un lado, las características del lenguaje de consulta y por otro, el proceso interno que permita que estas consultas se ejecuten sobre la base de datos y se obtengan sus resultados en XML. De esta forma,
internamente XBD estará organizado en dos subsistemas principales que luego detallaremos al describir su arquitectura, el subsistema de adaptación y el de consulta.
En primer lugar analizaremos el tema del lenguaje a utilizar para realizar las consultas a la base de datos y luego ya el de la arquitectura del sistema con los dos subsistemas que lo forman.
4. Lenguajes de Consulta en el Sistema XBD
Si se desea que todo el sistema de consulta, incluido el lenguaje que se utiliza para dichas consultas, tenga una apariencia XML, tenemos dos alternativas: o crear un nuevo lenguaje de consulta basado en XML o reutilizar alguno de los ya existentes adaptándolo a nuestras necesidades.
Como deseamos que para el usuario resulte un sistema transparente y que de hecho para él es como si consultase información XML, la primera solución quedaría descartada porque se trataría de que el usuario no tuviese que emplear apenas tiempo de aprendizaje utilizando algún lenguaje que ya conozca del entorno XML.
En cuanto a lenguajes de consulta del entorno XML, el lenguaje de consulta por excelencia es XQuery [12], sin embargo XSL [11], aunque realmente es un lenguaje más de presentación que de consulta, indirectamente también nos va a permitir consultar información. En definitiva, en nuestro sistema se van a utilizar estos dos lenguajes, previa adaptación de los mismos a la consulta de base de datos, lo que implicará añadir alguna modificación, pero muy pequeña, a la sintaxis de las versiones estándar de estos lenguajes.
A los lenguajes obtenidos de esta adaptación, que son los que se van a usar para hacer las consultas en XBD les denominaremos XQuery Adaptado y XSL Adaptado. Su sintaxis es muy semejante a la de los lenguajes XQuery y XSL estándar, la diferencia fundamental radica en el significado que ahora toman las construcciones de estos lenguajes al utilizarlas para la consulta a base de datos. Cambia la semántica, pero la sintaxis es prácticamente la misma.
A continuación explicamos las características fundamentales de ambos lenguajes.
4.1 XSL Adaptado
Para adaptar el lenguaje XSL a nuestro sistema XBD sólo necesitamos algunas de la construcciones del lenguaje XSL estándar: stylesheet, apply-templates, template, value-of, if, for-each, when y short. A todas estas construcciones se les añade el prefijo “xsl_adapt” para señalar que forman parte de este nuevo lenguaje y que tienen un significado especial respecto a la versión estándar.
En relación con la consulta a
bases de datos y teniendo en cuenta que al final, como resultado de la consulta
en XSL adaptado, se obtiene una sentencia SELECT de SQL de consulta a base de
datos, la equivalencia o significado de las construcciones en XSL para obtener
- xsl_adapt:stylesheet:
Contiene información acerca del fichero que contiene el esquema XML de base de datos, que es un documento XML obtenido a partir del proceso de adaptación de la base de datos al sistema XBD. Este fichero contiene información acerca de la estructura de la base de datos: sus entidades, atributos y relaciones. El nombre de este fichero resultado del proceso de adaptación, aparece como valor del atributo “Schema_db” de esta construcción.
Además esta construcción también contiene información sobre como conectarse a la base de datos a la que se refiere la consulta.
- xsl:adapt:apply-template
/ xsl_adapt:template
Cada template equivale a una sentencia SELECT de SQL. Ambas construcciones actúan de forma combinada. En el apply-template determinamos la tabla principal de la consulta y dentro del template asociado aparecerá el resto del contenido de la sentencia SELECT.
- xsl_adapt:value-of
Muestra los campos consultados de la base de datos. Estos campos aparecerán en la sentencia SELECT cuando la consulta se traduce a SQL.
- xsl_adapt:if
Añade una condición a la consulta. Esta construcción se traducirá a una cláusula WHERE en la sentencia SELECT de SQL asociada.
- xsl_adapt:for-each
Permite agrupar los resultados de
la consulta. Se traduce a la cláusula GROUP-BY de
- xsl_adapt:when
Añade una condición a la cláusula GROUP-BY de agrupamiento. Equivale a la cláusula HAVING de SQL.
- xsl_adapt:sort
Permite clasificar la consulta. Equivale a la cláusula ORDER BY de SQL.
Todas estas construcciones tienen diferentes atributos: select, match, test, …, en los que pueden aparecer expresiones de camino que utilizan la sintaxis de XPath [9], a través de las cuales referenciaremos a tablas y campos de la base de datos.
Además será posible anidar sentencias SELECT, definiendo un “template” dentro de otro, es decir, insertando una sentencia “template” dentro de un “apply-template”, pues cada “template” equivale a una sentencia SELECT.
A la hora de traducir las consultas anidadas a la correspondiente sentencia de consulta en SQL se pueden dar dos posibilidades. Si el “apply-template ” aparece aislado, se traducirá a una sentencia SELECT anidada en la cláusula FROM de la sentencia SELECT inicial, es decir, como una subconsulta de SQL. Si la construcción “apply-template” tuviera a su vez anidada una construcción “value-of”, entonces la anidación se traduciría a un “CURSOR” dentro de la sentencia SELECT equivalente. A los resultados asociados a este cursor habría que darles un nombre en el resultado de la consulta en XML para identificarlos. Este nombre estará formado por la unión del nombre de la tabla principal de la consulta anidada y la tabla principal de la sentencia SELECT inicial.
Para entender mejor el modelo de traducción descrito de cualquier consulta a base de datos en el lenguaje XSL Adaptado, a su equivalente sentencia SELECT de
consulta en SQL, a continuación detallamos el Data Type Definiyion (DTD) que contendrá implícitas las reglas de este proceso de traducción.
<!ELEMENT xsl_adapt:if
( (xsl_adapt:value-of)+, (xsl_adapt:apply-templates)?)>
<!ATTLIST xsl_adapt:if
test CDATA #REQUIRED>
<!ELEMENT xsl_adapt:apply-templates
(xsl_adapt:value-of)*>
<!ATTLIST xsl_adapt:apply-templates
select CDATA #REQUIRED>
<!ELEMENT xsl_adapt:value-of
EMPTY>
<!ATTLIST xsl_adapt:value-of
select CDATA #REQUIRED>
<!ELEMENT xsl_adapt:for-each
((xsl_adapt:when)?)>
<!ATTLIST xsl_adapt:for-each
select CDATA #REQUIRED>
<!ELEMENT xsl_adapt:when
EMPTY>
<!ATTLIST xsl_adapt:when
test CDATA #REQUIRED>
<!ELEMENT xsl_adapt:sort
EMPTY>
<!ATTLIST xsl_adapt:sort
select CDATA #REQUIRED>
Según este DTD y deduciendo a partir de él las reglas de traducción del lenguaje XSL Adaptado a SQL, por ejemplo la sentencia SQL: “SELECT nom_prod FROM producto”, en XSL adaptado equivaldría a la siguiente:
<?xml versión=”1.”>
<!DOCTYPE xsl_adapt:stylesheet
system “xsl_adapt.dtd”>
<xsl_adapt:stylesheet
version = “
schema_db= “schema_db_produc.xml”>
<xsl_adapt:template match=/”>
<xsl_adapt:apply_template
select=”Producto”>
</xsl_adapt:template>
<xsl_adapt:template
match=//Producto”>
<xsl_adapt:value_of
select=”nom_prod”>
</xsl_adapt:template>
</xsl:stylesheet>
4.2 XQuery Adaptado
Para adaptar el lenguaje XQuery a la consulta a base de datos, sólo se necesitan las sentencias FOR-LET-WHERE-RETURN (FLWR) de este lenguaje. La equivalencia con las cláusulas de la sentencia SELECT de SQL sería la siguiente:
- FROM: determina las tablas de la base de datos a consultar.
- RETURN: especifica los atributos del resultado de la consulta
- WHERE: añade una condición, cláusula WHERE, a la consulta.
- LET: permite agrupar los resultados de la consulta. Equivale al GROUP-BY de SQL.
Las expresiones de camino con XPath que aparecen en las sentencias FLWR, van a determinar las tablas y campos de la consulta.
Según esto, la sentencia del ejemplo anterior “SELECT nom_prod FROM producto”, en XQuery Adaptado, tendría la siguiente sintaxis.
FOR $p IN document(“schema_db_produc.xml”)
RETURN Producto/nom_prod
5. Arquitectura Sistema XBD
El sistema XBD implementa dos tareas principales. La primera permitirá adaptar la base de datos a consultar, para que de hecho pueda ser consultada en el sistema XBD. La segunda, una vez adaptada la base de datos, permitirá consultarla utilizando cualquiera de los lenguajes del apartado anterior.
Según esto la arquitectura del
sistema tendría dos componentes principales, el de adaptación y el de consulta.
Esta arquitectura se representa en
Adaptación de una base de datos relacional a XBD
Esta tarea permite que cualquier base de datos relacional sea consultada en el sistema XBD. Para conseguirlo es necesario obtener un documento XML especial denominado Esquema XML de Base de Datos (Esquema XML de BD) que contendrá información acerca de la estructura de la base de datos: tablas, relaciones y campos. Este documento se utilizará como entrada del siguiente componente de XBD, el que se encarga de hacer las consultas.
La apariencia del “Esquema XML de BD” es similar a la de un Schema XML clásico [10].
En XML hay dos tipos de esquemas principales, el formato XSD del W3C que es el más utilizado, y el formato XDR de Microsoft que fue el primero. En el sistema XBD se podrá optar por utilizar un formato similar a uno u otro, para crear el documento resultado del proceso de adaptación, el Esquema XML de BD.
Los elementos de estos documentos dependen del formato utilizado. En XDR los principales elementos son “element” y “ElementType”. En XSD, “SimpleType”, “element”, “ComplexType” y “sequence”. Estos elementos contendrán información acerca de la base de datos: tablas, relaciones con otras tablas y cardinalidad, campos de cada tabla con sus tipos de datos y si dichos campos son o no clave.
Si usamos el formato XSD, con SimpleType definimos cada campo o columna de la base de datos junto al tipo de datos, a través de los atributos “name” y “type”, de estos campos. Cada tabla se describe con un elemento ComplexType. Dentro de cada Complextype existirá un elemento “sequence” a través del que definiremos la relación y cardinalidad de la tabla con el resto de tablas del sistema con las que esta
Consulta XML
Sistema ADAPTACIÓN
Sistema CONSULTA
BD Relacional
Resultados XML
Esquema XML BD
relacionado, y varios elementos “element” anidados dentro de “sequence” para definir cada uno de los campos que forman la tabla, junto a información sobre si ese campo es clave primaria de dicha tabla, clave secundaria cuando sirve para relacionar a la tabla con otra, o ninguna de las anteriores.
En el formato XDR, con element se define cada campo de cada tabla y con ElementType se define cada tabla. Anidado dentro de cada ElementType, se define el contenido de cada tabla, campos que lo forman y otras tablas con las que se relaciona junto a su cardinalidad.
Para entender mejor la estructura de cualquier Esquema XML de Base de Datos en formato XSD y reflejar lo que acabamos de comentar sobre cómo este esquema describe internamente la estructura de la base de datos, a continuación exponemos el DTD que deberían seguir los documentos de este tipo.
<!ELEMENT Schema_bd
(conexion, (SimpleType)+, (ComplexType)+)>
<!ELEMENT conexion
EMPTY>
<!ATTLIST conexion
type (basedatos|docxml)
"basedatos"
owner CDATA #REQUIRED
cad_conex CDATA #REQUIRED>
<!ELEMENT SimpleType
EMPTY>
<!ATTLIST SimpleType
name CDATA #REQUIRED
type CDATA #REQUIRED>
<!ELEMENT ComplexType
((sequence)+)>
<!ATTLIST ComplexType
name CDATA #REQUIRED>
<!ELEMENT sequence ((element)+)>
<!ATTLIST sequence
minOccurs CDATA #IMPLIED
maxOccurs (1|unbounded)
"unbounded">
<!ELEMENT element
EMPTY>
<!ATTLIST element
type CDATA #REQUIRED
pk CDATA #IMPLIED
fk CDATA #IMPLIED
ref CDATA #IMPLIED>
De la misma forma exponemos también el DTD que se debería seguir si se utiliza el formato de Esquema XML de Base de Datos más parecido al XDR de Microsoft.
<!ELEMENT Schema_bd
(conexion, (ElementType)+)>
<!ELEMENT conexion
EMPTY>
<!ATTLIST conexion
type (basedatos|docxml)
"basedatos"
owner CDATA #REQUIRED
cad_conex CDATA #REQUIRED>
<!ELEMENT ElementType
(element)*>
<!ATTLIST ElementType
name CDATA #REQUIRED
content (columna|tabla) "columna"
type CDATA #IMPLIED>
<!ELEMENT element
EMPTY>
<!ATTLIST element
type CDATA #REQUIRED
minOccurs CDATA #IMPLIED
maxOccurs (1|*) “*”
pk CDATA #IMPLIED
fk CDATA #IMPLIED
ref CDATA #IMPLIED >
Finalmente, y para visualizar la
utilización de los Esquemas XML de Base de Datos, como ejemplo se da a
continuación la definición de las tablas de PRODUCTOS y PEDIDOS. Además se sabe
que la tabla de PRODUCTOS guarda una relación de
PRODUCTOS (cod_prod, nom_prod, stock_prod)
PEDIDOS (cod_ped, fecha_ped, cod_prod, cant_ped)
<SympleType name=”cod_prod” type=”NUMBER”>
<SympleType name=”nom_prod” type=”VARCHAR2”>
<SympleType name=”stock_prod” type=”NUMBER”>
<ComplexType
name=”PRODUCT0S”>
<sequence minOccurs=”
maxoccurs=”1”>
<element type= ”cod_prod”
pk=”true”>
<element type= ”nom_prod>
<element type= ”stock_prod>
</sequence>
<sequence maxoccurs=”unbounded”>
<element type=”PEDIDOS”>
</sequence>
</ComplexType>
5.2 Consulta a una base de datos relacional en XBD
Esta tarea permite consultar la base de datos, previamente adaptada con la tarea anterior y gracias a la utilización del documento Esquema XML de BD obtenido en el proceso anterior.
Las consultas se podrán realizar en cualquiera de los lenguajes de consulta del sistema XBD: XSL o XQuery Adaptado.
Además, el componente que implementa esta tarea tiene una apariencia muy semejante a la consulta a un documento XML, en cuanto a que el interfaz de consulta presenta la información de la base de datos, su estructura, en un formato arborescente similar al árbol DOM de un documento XML.
En esta estructura arborescente cada tabla se representa como un nodo que parte del nodo raíz. Cada rama asociada a cada nodo a su vez contendrá a los campos que forman la tabla y otras tablas con las que se relaciona. Junto a esta estructura
arborescente, el interfaz también suministra ayuda para editar la consulta, con información sobre la sintaxis de los lenguajes de consulta a utilizar.
Por último, además de la opción de edición de las consultas, el componente de consulta también suministra otras dos opciones, las de validación y ejecución de la consulta.
La validación permitirá comprobar si la consulta es correcta tanto desde el punto de vista de los datos consultados en la base de datos: tablas, campos y relaciones, como de la sintaxis de la consulta en relación a los lenguajes de consulta del sistema XBD.
Finalmente, la opción de ejecución nos permitirá ejecutar la consulta sobre la base de datos. Esto supone traducir internamente la consulta a una única sentencia SELECT de SQL, siguiendo las reglas o semántica de las construcciones del lenguaje de consulta, con relación a la equivalencia con las cláusulas de la sentencia SELECT de SQL vistas en el apartado 4 de este trabajo. La consulta SQL obtenida como resultado del proceso de traducción, se ejecutará sobre la base de datos y el propio DBMS que contiene a la base de datos ya dispone de herramientas para convertir los resultados de la base de datos obtenidos de la consulta, a XML. De esta forma, tal como pretendíamos, tanto el lenguaje de consulta como el formato del resultado será XML.
En la figura 2 se muestra la apariencia del interfaz de consulta. En él, tal como hemos comentado, podemos observar ala izquierda el árbol que muestra la estructura de la base de datos, y a la derecha la pantalla en la que editamos la consulta. En la parte inferior podemos utilizar la ayuda que se nos ofrece para la edición de la sintaxis de las construcciones de la consulta, y también podemos observar la ruta seleccionada en el árbol. Esta ruta utiliza la sintaxis de XPath y podemos utilizarla para añadirla como valor de alguno de los atributos de las construcciones de la consulta que se esta editando.
Conclusiones y Líneas Futuras
Se demuestra, una vez descritas las características de nuestro sistema, que se consiguen los objetivos que nos habíamos propuesto. XBD permitirá consultas a base de datos con un formato y lenguajes semejantes a la consulta a documentos XML, para que al usuario le resulte un sistema transparente y considere que está consultando únicamente datos XML, tal como si estuviera en un entorno Web.
Para conseguir este efecto, no se necesita transformar la información de la base de datos a ningún formato, como ocurría en otros sistemas. Además se podrá consultar en cualquier momento cualquier campo de la base de datos, por que en otros sistemas esta consulta estaba restringida a la parte de la base de datos afectada por una consulta inicial.
Por último, el sistema resulta muy eficiente porque quien realiza la consulta final en SQL sobre la base de datos, obtenida tras el proceso de traducción de la consulta.
1.3- Acceso a Datos Relacionales Bajo un Entorno ASP
El acceso a bases de datos es uno de los recursos más utilizados en las páginas ASP, la facilidad con la que puede crear un sitio web dinámico queda patente en este taller en el que aprenderá los conceptos básicos sobre conexión a bases de datos.
Las páginas ASP con acceso a datos permiten interactuar con la información de una base de datos ya sea para obtener información y mostrarla al usuario o bien para actualizar su contenido.
Son muchas las aplicaciones de este concepto en los sistemas de información actuales por ejemplo, una empresa que vende sus artículos por Internet debe disponer de páginas en las que se visualicen los datos de sus productos, disponibilidad, precio, etc. y almacenar los pedidos de sus clientes. Al tratarse de información en continua actualización la presencia de una base de datos y su consulta dinámica se hacen indispensables.
Para conectarse a una base de datos, las páginas ASP
utilizan la tecnología ADO (ActiveX Data Objects) y pueden accederse a sistemas de gestión de
bases de datos comatibles con ODBC (entre otras SQL
Server, Access, Informix o
Oracle.)
Pueden utilizarse dos sistemas de conexión a Base de Datos:
DSN
Este sistema consiste en definir un identificador de la conexión mediante el driver ODBC accesible desde el Panel de Control. Posteriormente, desde las páginas ASP, se practica el acceso mediante un string de conexión que incluye el identificador antes mencionado.
Para crear un DSN en Windows, haz clic en el botón Inicio selecciona la opción Panel de Control del menú Configuración. En la ventana del Panel de Control selecciona Fuentes de Datos ODBC y accede a la pestaña DSN de Sistema. Selecciona la base de datos que quieres añadir y define un nombre a la conexión y la localización física de la base de datos
Sin DSN
Este sistema requiere almacenar directamente el archivo de
Estos son los 3 pasos para realizar la conexión
Instrucciones de conexión a una base de datos
<%
Dim objConn
'Creación del objeto que realiza la conexión a la base de datos
Set objConn = Server.CreateObject("ADODB.Connection")
'Proporcionar al objeto la información correspondiente a la conexión ODBC a utilizar
'Mediante DNS
objConn.ConnectionString = "DSN=bdProgramacion"
'Sin DNS
objConn.ConnectionString = "DBQ=C:\mis documentos\program.mdb;DRIVER={MS
Access (*.mdb)}"
'Abrir la conexión
objConn.Open
%>
Mediante el lenguaje SQL (Structured Query Language) puedes interactuar con los motores de base de datos relacionales para obtener y modificar la información almacenada en la base de datos.
La información en una base de datos se almacena en tablas que a su vez se componen de columnas o campos. Para realizar una consulta a una tabla deberá utilizar la instrucción SELECT. En una consulta básica en la clasula SELECT se indican las columnas a visualizar, en la claúsula FROM, la tabla de la cual obtener los datos por último en la claúsula WHERE se indican las restricciones a aplicar.
Instrucciones SQL de CONSULTA
SELECT * FROM clientes WHERE poblacion="Sevilla"
SELECT nombre FROM Productos WHERE precio > 2000
Las operaciones de insertar, actualizar y borrar información de la base de datos también se realizan mediante instrucciones SQL concretamente utilizaremos INSERT, UPDATE y DELETE respectivamente.
Por ejemplo, la sentencia UPDATE se compone de la clausula SET para indicar el nuevo valor de los campos y WHERE para indicar los registros sobre los que se desea practicar la actualización.
Instrucciones SQL de MODIFICACIÓN: INSERT
INSERT INTO Productos (nombre, precio, distribuidor)
VALUES ("Auriculares", 1730, "batech")
Instrucciones SQL de MODIFICACIÓN: UPDATE
UPDATE Productos
SET precio = precio + (0,02 * precio)
WHERE distribuidor="ACME"
Instrucciones SQL de MODIFICACIÓN: DELETE
DELETE FROM Productos
WHERE distribuidor="ACME"
A continuación, practicará las instrucciones para que desde la página ASP pueda acceder a la información de la base de datos y mostrarla en la ventana del navegador del usuario
Suponga que tiene una tabla de Productos con las siguientes columnas: nombre, precio y distribuidor.
En la página ASP a crear visualizará aquellos productos cuyo precio sea inferior a los 30 Euros y para realizar esta consulta utilizará el objeto ADODB.Recordset
Instrucciones de acceso a los datos
<%
Dim objConn
Dim objRS
Dim strSQL
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.ConnectionString = "DSN=gestion"
'Inicialización
del objeto Recordset
Set objRS
= Server.CreateObject("ADODB.Recordset")
' Construcción de la consulta mediante SQL
strSQL = "SELECT nombre, precio FROM productos WHERE precio < 30"
' ejecución de la consulta
objRS.Open strSQL, objConn
%>
Como resulta de la anterior ejecución, el servidor obtiene un conjunto de registros procedentes de la base de datos y posiciona el cursor en el primero de ellos. El objeto recordset proporciona mecanismos para acceder a los diferentes campos y mover el cursor entre los diferentes registros. Puede conocer cómo mediante el siguiente código:
Visualización de datos
<table>
<tr><td>NOMBRE</td><td>PRECIO</td></tr>
<%
'Bucle hasta encontrar EOF (final del cursor)
Do Until objRS.EOF = True
Response.Write "<tr>"
'objRS("nombre") y objRS("precio") contienen los valores
'de los campos nombre y precio de
Response.Write "<td>Nombre= " & objRS("nombre") & "</td>"
Response.Write "<td>Precio = " & objRS("precio") & "</td>"
Response.Write "</td></tr>"
'Mover el cursor al siguiente registro.
'Cuando ya esté en el último registro EOF valdrá cierto.
objRS.MoveNext
Loop
%>
</table>
Es una práctica recomendable cerrar y borrar los objetos recordset y de conexión creados en la página ASP. Para ello se utiliza el código indicado a continuación:
Cerrar conexión
<%
'Cerraar el objeto Recordset
objRS.Close
'Eliminar el objeto Recordset
Set objRS = Nothing
'Cerrar el objeto de la conexión
objConn.Close
'Eliminar el objeto de la conexión
Set objConn = Nothing
%>
ADOVBS.INC es un archivo que se incluye con el servidor Internet Information Server y en el que se definen todas aquellas constantes utilizadas con objetos del ADO.
La inclusión de archivos es muy aconsejable para realizar código legible y rehutilizable dos características imprescindibles en páginas de acceso a datos. Para ello se utiliza la instrucción include virtual que pertenece al juego de instrucciones del protocolo HTTP y cuya sintaxis es la siguiente:
<%
<!-- #include virtual="/adovbs.inc" -->
%>
En este caso deberá tener almacenado el archivo ADOVBS.INC en la raiz del directorio de su aplicación.
1.4- Acceso a Datos Relacionales Bajo un Entorno PHP
PHP (siglas que originalmente significaban Personal Home Page) fue primero escrito por Rasmus Lerdorf como un simple conjunto de scripts de Perl para guiar a los usuarios en sus páginas. Luego para satisfacer inquietudes del mismo tipo por parte de otra gente lo reescribe, pero esta vez como un lenguaje de script agregándole entre otras características soporte para formularios. Al ver como la popularidad del lenguaje aumenta, un grupo de desarrolladores crea para él un API, convirtiéndose así en el PHP3. Fue en ese momento cuando el parser de scripts PHP es completamente reescrito (el Zend Engine) dando vida al PHP4 mucho mas rápido, tal y como lo conocemos en la actualidad.
PHP actualmente significa Hypertext Preprocessor y esta listo para su mejor momento...
Cosas
para tener en cuenta en un lenguaje de scripts
Las cuatro grandes características: Velocidad, estabilidad, seguridad y simplicidad.
Bueno otra característica a tener en cuenta seria la conectividad. PHP dispone de una amplia gama de librerías, y agregarle extensiones es muy fácil. Esto le permite al PHP ser utilizado en muchas áreas diferentes, tales como encriptado, gráficos, XML y otras.
Entre las ventajas podemos citar:
·
Muy
sencillo de aprender.
·
Similar
en sintaxis a C y a PERL
·
Soporta
en cierta medida la orientación a objeto. Clases y herencia.
·
El
análisis léxico para recoger las variables que se pasan en la dirección lo hace
PHP de forma automática. Librándose el usuario de tener que separar las
variables y sus valores.
·
Se
puede incrustar código PHP con etiquetas HTML.
·
Excelente
soporte de acceso a base de datos.
·
La
comprobación de que los parámetros son validos se hace en el servidor y no en
el cliente ( como se hace con javascript
) de forma que se puede evitar que chequear que no se reciban solicitudes
adulteradas. Ademas PHP viene equivado
con un conjunto de funciones de seguridad que previenen la insercción
de ordenes dentro de una solicitud de datos.
·
Se
puede hacer de todo lo que se pueda transmitir por vía HTTP.
Y las desventajas:
·
Todo
el trabajo lo realiza el servidor y no delega al cliente. Por tanto puede ser
más ineficiente a medida que las solicitudes aumenten de número.
·
La
legibilidad del código puede verse afectada al mezclar sentencias HTML y php.
·
La
orientación a objetos es aún muy deficiente para aplicaciones grandes.
·
PHP
no soporta directamente punteros, como el C, de forma que no existen los
problemas de depuración provocados por estos.
·
Se
pueden hacer grandes cosas con pocas línes de código.
Lo que hace que merezca la pena aprenderlo.
·
El
código PHP es mucho más legible que el de PERL , todo
el que haya programado PERL podrá corroborar esta afirmación.
·
Viene
acompañado por una excelente biblioteca de funciones que permite realizar
cualquier labor ( acceso a base de datos, encriptación, envió de correo,
gestión de un e-commerce, xml,
creación de PDF ... )
·
Al
poderse encapsular dentro de código html se puede
recoger el trabajo del diseñador gráfico e incrustar el código php posteriormente.
·
Esta
siendo utilizado con éxito en varios millones de sitios web.
·
Hay
multitud de aplicaciones php para resolver problemas
concretos ( weblogs, tiendas
virtuales , periódicos , ... ) listas para usar.
·
Es
multiplataforma, funciona en todas las plataformas que soporten apache.
·
Es
software libre. Se puede obtener en la web y su
código esta disponible bajo la licencia GPL.
Anteriormente hemos visto la evolución de la
creación de paginas HTML dinámicas a lo largo de la historia. Inicialmente se
uso programas C o shell-scripts
que devolvían información en hipertexto por su salida estándar. Posteriormente
se descubrió que el lenguaje interpretado PERL era excelente para la labor de
interpretación necesaria para la programación dinámica. Perl
sigue siendo el "pegamento de la red" , pero
la aparición de soluciones más adecuadas y sencillas hacen que PHP se convierta
en la mejor opción actual para multitud de necesidades. Perl,
desde mi punto de vista, ha llegado a su máximo y entra en fase retroceso. ¿ Cuanto durará PHP en ser una buena opción ? Nadie lo sabe,
pero actualmente es uno de los paquetes para programación de internet más utilizados.
2.-
Para tener éxito en Internet... tendrá que enfocar
sus
esfuerzos principalmente en
4 aspectos.
1. Desarrollar un excelente
producto (o servicio) y comercializarlo a precios competitivos.
2. Diseñar y construir un
sitio web comercialmente efectivo, es decir, vendedor.
3. Atraer tráfico calificado a su sitio web.
4. Gestionar eficazmente sus comunicaciones, en especial, utilizando el poder del correo electrónico (email marketing, autorrespondedores, boletines de correo electrónico por suscripción voluntaria, etc.)
Sin embargo, para poder tener éxito comercial todos deben funcionar armónicamente como un engranaje. Si uno falla, los demás fallan, por lo tanto le estará haciendo el 'quite' al éxito.
Si analiza de cerca los 4 puntos, verá un denominador común: todos están directamente bajo su control. Si trabaja sobre estos aspectos necesariamente tendrá que tener éxito, pues no hay variables externas que controlar. Todos, léase bien: TODOS los puntos están bajo su control.
Hay
tres diferentes formas de vender un producto o servicio en el Internet.
1)
Vender un producto o servicio propio
2)
Afiliarse a un negocio ya establecido y vender los productos o servicios en
calidad de afiliado o promotor.
3)
Adquirir y vender un producto o servicio con derechos de reventa.
Si usted tiene su propio producto tiene la ventaja de poder ganar
el 100% sobre la venta. Si el producto o servicio es de otra persona, entonces
usted se convierte en un afiliado o promotor y recibe un porcentaje de la venta
en forma de una comisión.
Propio producto y/o
servicio
Lo
mejor y más ventajoso es tener un propio producto y/o servicio. Las ventajas
son diversas. Por ejemplo tiene el control total sobre su producto.
Esto
significa que puede variar el precio, cambiar la imagen, la carta de venta,
ofrecer descuentos, bonos etc. Las posibilidades son ilimitadas.
Si
ya tiene un producto o un servicio para vender fenomenal!
Entonces debe crear una página Web exitosa para vender su producto. Y si ya
tiene una página Web que ofrece su producto entonces debe crear un flujo
continuo y automatizado de visitas interesadas hacia su
página.
Productos tangibles v/s
productos digitales
En
el Internet se puede comprar y vender prácticamente TODO. Desde libros hasta
bienes inmuebles, desde viajes turísticos hasta obras de arte... Es un enorme
mercado global interrelacionado por miles y millones de enlaces (links).
Existen
dos tipos de productos. Los tangibles y los digitales. Los tangibles son
productos que, como indica su nombre, se los puede tocar, oler, o comer.
Los
productos digitales son productos o servicios que se puede comprar y descargar
como archivos a la computadora. Por ejemplo: software, libros electrónicos (e-books), artículos, manuales, música (mp3)...
Pero
en este campo están también los servicios como compra de nombres de dominio,
espacios de hospedaje para su sitio Web (hostings),
accesos a áreas exclusivos de subscripción en
diversos sitios Web, etc. ...
La
ventaja de los productos o servicios digitales es que no necesita un almacén,
ni un envío físico por correo o curier, y que el
proceso de venta y distribución puede ser completamente automatizado.
Es
decir un producto o servicio digital se puede vender y entregar automáticamente
de día y de noche, los 365 días del año, sin ningún esfuerzo adicional, en
cuanto el sistema esté armado.
Productos y/o servicios de
otra persona
Hay
miles de personas y empresas en el Internet que tienen algún producto o
servicio a la venta. Muchos de ellos ofrecen derechos de reventa sobre su
producto o un sistema de afiliados para comercializar
su producto.
Si
usted no tiene un producto o servicio propio entonces esta es la forma más
eficaz de comenzar a ganar dinero en el Internet.
Para
un nuevo emprendedor en los negocios por Internet es recomendable comenzar su
experiencia como afiliado, vendiendo el producto o
servicio ya establecido de alguna persona o empresa.
De
esta manera comenzará a aprender y entender las diferentes facetas de los
negocios virtuales sin ningún riesgo. Y en cuanto entienda y domine todos los
aspectos de los negocios por Internet puede lanzarse a crear y comercializar su
propio producto o servicio en la red mundial (www).
Programas de afiliados
Es
fácil registrarse en un programa de afiliados. Cualquier persona lo puede
hacer. Después de la registración el afiliado tiene
generalmente acceso a un área personal donde tiene diversas herramientas para
promocionar el producto o servicio del programa afiliado
3.1- Bibliografías:
Phil Hanna. “JSP Manual de Referencia”. McGraw-Hill Osborne Media 2002
Juan Antonio Palos (Ozito). “Servlets y Java Server Pages (JSP)
Fermoso, A, Berjón, R. Acceso a datos relacionales en entornos web. Un caso Práctico. Ed. Universidad Pontificia de Salamanca (2004)
Fernández, M., Kadiyska,
Y., Morishima, A., Suciu,
D., Tan., W.C., SilkRoute: a
framework for publishing relational data in XML. ACM
Transactions on Database Systems (TODS), Vol. 27, Nª 4, December (2002) pp.
438-493.
Funderburk, J. E., Kiernan, G., Shanmugasundaram, J. , Shekita, E., Wei, C., XTABLES:
Bridging relational technology and XML. IBM Systems Journal, Vol. 41 , Nª 4 (2002)
IBM. IBM DB2 Universal Database. XML Extender Administration and Programming. Version 8.
IBM Corporation. (2002)
Microsoft, SQL Server 2000. XML and Internet
Support. Microsoft Corp. (2002)
Oracle, Oracle 9i Release 2. Database
Concepts. Oracle Corp., March. (2002)
Oracle, Oracle 9i Release 2. XML Database Developers's Guide-Oracle XML DB. Oracle Corp.,
October 2002.
3.2- Infografías:
http://www.programacion.com/asp/articulo/basededatos_asp/
http://www.programacion.com/php/articulo/porquephp/
http://www.programacion.com/java/servlets_jsp
http://www.javahispano.com/tutoriales/servlets.html
http://wwwetsi2.
ugr.es/depar/ccia/mabd/material/practicas/transparencias/AccesoBDJava.pdf
http://www.walc2000.unam.mx/material/track2/JDBCBL1.pdf
http://www.autoingresos.com/productos.htm