1. bases de datos y programación:
una perspectiva a futuro en la sociedad de la información
Javier González Sánchez, MCs.
Tecnológico de Monterrey, campus Guadalajara
javiergs@itesm.org
2. 0001. ¿dónde estamos?
bases de datos y programación:
una perspectiva a futuro en la sociedad de la información
6. CiberEspacio: la alucinación de la conciencia
Ciberespacio:
• 1984, William Gibson
… alucinación consensual experimentada diariamente
por billones de usuario de Internet, en todas las
naciones, conformado por una representación
monolítica del conjunto de información abstraída de
todas los computadoras, de complejidad inimaginable.
Líneas de luz clasificadas en el no-espacio de la mente,
conglomerados y constelaciones de información. Como
las luces de una ciudad que se aleja …
javiergs@acm.org
• un universo paralelo
7. CiberEspacio: el mundo detrás del espejo
Sociedad y comunidad
Trabajo y negocios
Auto realización
A temporal
Omni - presencialista
javiergs@acm.org
9. WWW: de regreso a realidad
Bases de datos
Minería de datos: dataware house
Programación: búsquedas o consultas
Programación: procesamiento de información
javiergs@acm.org
Obrero Arquitecto
Operativo Modelo
Básico Complejo
10. WWW: de regreso a realidad
http://maps.google.es http://amazon.com
javiergs@acm.org
11. WWW: de regreso a realidad
la red el ciberespacio
javiergs@acm.org
Obrero Arquitecto
Operativo Modelo
Básico Complejo
14. 2 historia de Java
agenda[ ]=“ ”;
Diciembre 1990:
Green Project, Oak, Duke …
http://today.java.net/jag/old/green/
Octubre 2004:
Portafolio de productos basados en la red y con la filosofía de que el mismo
software debe ser ejecutable en diferentes dispositivos y/o sistemas.
J2SE = base de la tecnología Java
J2EE = entorno empresarial, redes, acceso a datos
J2ME = entornos limitados
javiergs@acm.org
16. ingeniería de software: La vida real
objetos | relaciones
Capa 3
Deploy
Web / GUI
ser
Capa 2
Entity
Data link usar
Capa 1
Base de datos
tener
javiergs@acm.org
2
17. 3 programación
agenda[ ]=“ ”;
Variables, Tipos de dato, Operadores
Clases, Objetos
Atributos, Métodos
Paquetes, APIs
Herencia, Sobrecarga, Sobreescritura
Estructuras de control
Excepciones
javiergs@acm.org
Estructuras de Datos: arreglos
18. 3 modelar el mundo real ”;
agenda[ ]=“
Clase = molde Objeto = cosa Son hijos de
herencia se usar se usan
se tienen
atributos tienen
metodos atributos
metodos
javiergs@acm.org
19. 3]=“ a trabajar … ”;
agenda[
class Coche {
int velocidad;
void acelerar( int nuevaVelocidad) {
velocidad = nuevaVelocidad;
}
void frenar() {
velocidad = 0;
}
}
class Mundo {
public static void main (String [] arg) {
Coche miCoche = new Coche();
miCoche.acelerar(100);
miCoche.frenar();
}
javiergs@acm.org
}
20. 3]=“ y se puede complicar … ”;
agenda[
class Coche extends Bicicleta{
int velocidad;
void acelerar( int nuevaVelocidad) {
velocidad = nuevaVelocidad;
}
void frenar() {
velocidad = 0;
}
}
class Mundo {
public static void main (String [] arg) {
Coche miCoche = new Coche();
miCoche.acelerar(100);
miCoche.frenar();
javiergs@acm.org
}
}
22. 0010. datos
bases de datos y programación:
una perspectiva a futuro en la sociedad de la información
23. Historia
1945 cintas y búsqueda lineal
1959 acceso aleatorio a datos en almacenamiento
electrónico
1960 modelo jerárquico, en red y multiusuario
1970 Ted Codd presenta el modelo relacional
1976 Chen presenta el modelo entidad relación
1976 Lenguajes de consulta: SQL, QBE, QUEL
1980 DBMS para PC (Dbase, Paradox)
1983 DBMS comerciales: Oracle, Sybase, Informix
1985 SQL estandar preliminar
1990 Incorporación de capacidades y
actividades deductivas, espaciales,
temporales y multimedia.
1990 Paralelismo
javiergs@acm.org
24. Modelo ER
Datos persistentes programación
problema
Reglas del negocio
transacciones requerimientos
análisis
ALTO NINEL: UML
Diseño conceptual Diagrama de flujo
Schemas diseño Etc.
Tipos, relaciones,
constraint
implementación
Lenguaje de
DBMS Programación
javiergs@acm.org
Modelo de +
Implementación
+
Compilación
Modelo Físico
25. Modelo de Datos
Conceptual: alto nivel
MODELO ER - Entidad, atributo, relación
Representativo:
Clases, registros
MODELO RELACIONAL, RED, JERARQUICO, OOP
javiergs@acm.org
FISICO: nivel bajo
Rutas (paths)
Almacenamiento físico
26. SQL
Comando de SQL.
Recuperación de Datos:
SELECT.
Manipulación de Datos: (DML)
INSERT
DELETE
UPDATE
Definición de Datos (DDL)
CREATE
ALTER
DROP
Seguridad de los Datos:
GRANT
REVOKE
javiergs@acm.org
Confirmación
COMMIT
ROLLBACK
27. SQL -DDL
CREATE TABLE PROVEEDORES (
S# CHAR(5) NOT NULL,
SNOMBRE CHAR(20) NOT NULL,
SITUACION SMALLINT NOT NULL,
CIUDAD CHAR(15) NOT NULL,
PRIMARY KEY ( S# ) ) ;
CREATE TABLE PARTES (
P# CHAR(6) NOT NULL,
PNOMBRE CHAR(20) NOT NULL,
COLOR CHAR(6) NOT NULL,
PESO SMALLINT NOT NULL,
CIUDAD CHAR(15) NOT NULL,
PRIMARY KEY ( P# ) );
CREATE TABLE ENVIOS (
S# CHAR(5) NOT NULL,
javiergs@acm.org
P# CHAR(6) NOT NULL,
CANT INTEGER NOT NULL,
PRIMARY KEY ( S# , P# ),
FOREIGN KEY ( S# ) REFERENCES PROVEEDORES,
FOREIGN KEY ( P# ) REFERENCES PARTES ) ;
28. SQL-DML
SELECT S#, SITUACION SELECT SELECT *
FROM PROVEEDORES DISTINCT P# FROM
WHERE CIUDAD = ‘París’; FROM ENVIOS; PROVEEDORES;
SELECT PROVEEDORES.S#,PROVEEDORES.SITUACION
FROM PROVEEDORES
WHERE PROVEEDORES.CIUDAD = ‘París’;
SELECT PARTES.P#, ‘Peso en gramos =‘, PARTES.PESO *454
FROM PARTES;
SELECT S# , SITUACION SELECT PROVEEDORES.* ,
FROM PROVEEDOR PARTES.*
javiergs@acm.org
WHERE CIUDAD=‘París’ FROM PROVEEDORES, PARTES
ORDER BY SITUACION WHERE PROVEEDORES.CIUDAD =
DESC; PARTES.CIUDAD;
29. 0011. las piezas juntas (puente)
bases de datos y programación:
una perspectiva a futuro en la sociedad de la información
31. código
Class.forName("com.mysql.jdbc.Driver");
String url = "jdbc:mysql://localhost:3306/mysql";
Connection con = DriverManager.getConnection
( url, "myLogin","myPassword");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery ("SELECT a, b, c FROM Table1");
while (rs.next()) {
int x = rs.getInt("a");
javiergs@acm.org
String s = rs.getString("b");
float f = rs.getFloat("c");
}
32. 0100. el futuro (unificar)
bases de datos y programación:
una perspectiva a futuro en la sociedad de la información
33. RDBMS
Solo soporta pequeñas colecciones de datos de tipo simple (enteros, flotantes, fechas,
cadenas)
No se permiten conjuntos como tipo de atributos
No considera el concepto de herencia
No se consideran tipos complejos salvo BLOB (binary large object) y CLOB (character
large object)
Dificultad para interactuar entre el lenguaje de acceso a datos (SQL –declarativo-) y
el lenguaje de construccion de aplicaciones (procedural C o Java).
Soluciones ….
Inconvenientes….
javiergs@acm.org
34. ODBMS
Una base de datos Orientada a Objetos es un gestor de almacenamiento persistente
para objetos… y los objetos se pueden TAMBIEN crear en un lenguaje de
programación Orientado a Objetos
Sistemas de base de datos con Objetos:
Object-Oriented Database Systems:
alternative to relational systems
Object-Relational Database Systems:
Extension to relational systems
Ventas: RDBMS ( $8 billion), OODMS ($30 million) world-wide*
javiergs@acm.org
*2003, Zaiane O, Canadá
36. Agenda
Object-Oriented Database Systems
Object-Relational Database Systems
javiergs@acm.org
37. OODBMS
Punto de vista centrado en objetos
Localización ocasional de información en un repositorio de objetos
No cuenta con un DML optimizado en la practica
javiergs@acm.org
38. ODL en OODBMS
Soporta tipos atomicos asi como set, list, array and struct type
Interface defines a class
interface Movie (key movieName)
{
attribute date start;
attribute date end;
attribute string movieName;
relashionship Set<Theater> ShownAt inverse Theater::nowShowing;
}
interface Theater (key theaterName)
{ attribute string theaterName;
attribute string address;
attribute integer ticketPrice;
relationship Set <Movie> nowShowing inverse Movie::shownAt;
javiergs@acm.org
float numshowing() raises(errorCountingMovies);
}
39. OML en OODBMS
Similar a SQL: se define como una extension de SQL
Find the movies and theaters such that the theaters show more than one
movie.
SELECT mname: M.movieName, tname: T.theaterName
FROM Movies M, M.shownAt T
WHERE T.numshowing() >1
Find the different ticket prices and the average number of movies shown at
Theaters with that ticket price.
SELECT T.ticketPrice,
avgNum:AVG( SELECT P.T.numshowing() FROM partition P )
FROM Theaters T
javiergs@acm.org
GROUP BY T.ticketPrice
40. Agenda
Object-Oriented Database Systems
Object-Relational Database Systems
javiergs@acm.org
41. ORDBMS
Cual es la novedad? (SQL 1999)
soporte de almacenamiento y manipulación de tipos de dato largos (BLOB y
CLOB)
Mecanismos para extender la base de datos con tipos específicos y métodos:
– User defined types
– User defined procedures
– Operators for structured types
– Operators for reference types
-- Support for inheritance
javiergs@acm.org
42. Características OOR (oracle)
Tablas de objetos
CREATE TYPE person AS OBJECT (
name VARCHAR2(30),
phone VARCHAR2(20) );
CREATE TABLE person_table OF person;
INSERT INTO person_table VALUES
person("John Smith", "1-800-555-1212");
SELECT VALUE(p) FROM person_table p
javiergs@acm.org
WHERE p.name = "John Smith";
43. Características OOR (oracle)
Metodos
CREATE TYPE Rectangle_typ AS OBJECT (
len NUMBER,
wid NUMBER,
MEMBER FUNCTION area RETURN NUMBER
);
CREATE TYPE BODY Rectangle_typ AS
MEMBER FUNCTION area RETURN NUMBER IS
BEGIN
RETURN len * wid;
javiergs@acm.org
END area;
END;
44. Características OOR (oracle)
Referencias
CREATE TABLE people (
id NUMBER(4)
name_obj name_objtyp,
address_ref REF address_objtyp SCOPE IS address_objtab);
juan.deref(address_ref).street
SELECT REF(po) FROM purchase_order_table po
WHERE po.id = 1000376;
javiergs@acm.org
45. Características OOR (oracle)
Colección: Tablas anidadas
CREATE TYPE PointType AS OBJECT (
x NUMBER,
y NUMBER);
CREATE TYPE PolygonType AS TABLE OF PointType;
CREATE TABLE Polygons (
name VARCHAR2(20),
points PolygonType)
javiergs@acm.org
NESTED TABLE points STORE AS PointsTable;
46. Características OOR (oracle)
Colección: VARRAY
Define una colección de máximo N elementos
del mismo tipo
Definir el tipo obviamente no consume espacio
(no genera instancias o campos por si mismo)
CREATE TYPE prices
AS VARRAY(10) OF NUMBER(12,2);
javiergs@acm.org
47. Características OOR (oracle)
Herencia de Tipos ó creacion de subtipos:
CREATE TYPE Person_t AS OBJECT
( ssn NUMBER,
name VARCHAR2(30),
address VARCHAR2(100)) NOT FINAL;
CREATE TYPE Student_t UNDER Person_t
( deptid NUMBER, major VARCHAR2(30)) NOT FINAL;
CREATE TYPE Employee_typ UNDER Person_t
( empid NUMBER, mgr VARCHAR2(30));
javiergs@acm.org
CREATE TYPE PartTimeStud_t UNDER Student_t
( numhours NUMBER);
48. Características OOR (oracle)
Sobrecarga y Sobre escritura
CREATE TYPE MyType_typ AS OBJECT (...,
MEMBER PROCEDURE Print(),
MEMBER PROCEDURE foo(x NUMBER), ...)
NOT FINAL;
CREATE TYPE MySubType_typ UNDER MyType_typ
(...,
OVERRIDING MEMBER PROCEDURE Print(),
MEMBER PROCEDURE foo(x DATE), ...);
javiergs@acm.org
49. alto … ERA necesario poner orden
A
A
A A
A A
cliente
javiergs@acm.org
4
50. y lo mejor esta por llegar…
¡gracias!
javiergs@itesm.mx
http://www.javiergs.com
javiergs@acm.org
53. arquitectura cero
Web Client GET /index.html HTTP/1.1
Host: www.miweb.com
http HTML
[request]
Web Server
http URL
[response]
DNS Server
1. DNS Lookup
HTTP/1.1 200 OK
HTTP
Date: Tue, 09 Jan 2001 10:49:14 GMT
Server: Apache/1.3.14 (Unix) Web client
Last-Modified: Tue, 09 Jan 2001 01:11:02 GMT
ETag: "131e-a074-3a5a6526" Web server
Accept-Ranges: bytes
Content-Length: 41076 estático
Content-Type: text/html simple
<html>
javiergs@acm.org
…
</html>
1
54. evolución
1990 - 1995 1995 – 200x 200x –
CGI
Script - Cliente
Script – server
RDBMS
XML
Objetos
javiergs@acm.org
estático Spaghetti code Servicios Web
1
55. web CGI
Para añadir dinamismo requerimos de:
un mecanismo que permita la introducción de datos : formularios HTML.
Transmitir esos datos: extensiones a la URL y al protocolo HTTP
Un mecanismo que permita al Servidor Web generar dinámicamente
páginas HTML: CGI, Common Gateway Interface.
Limitaciones importantes:
dinámico
Mantenimiento de Estado ( sesiones )
simple
Rendimiento.
javiergs@acm.org
Desarrollar aplicaciones completas es complicado.
1
56. arquitectura CGI
Web Client GET /index.html HTTP/1.1
Host: www.miweb.com
http
[request]
#include <iostream>
main() {
DNS Server cout << "Content - type: text/htmlnn";
1. DNS Lookup
cout << "<html>" ;
cout << "<body>" ;
cout << "<h1> Hola Mundo <h1>"; programa
for (i=0; i < 10; i+= 2) { que
genera
}
... HTML
cout << "</html>" ;
}
javiergs@acm.org
Web Server
http
[response]
1
57. web script en el cliente
El Navegador es un buen cliente universal, pero tiene ciertas limitaciones :
El HTML original es estático.
La funcionalidad dada es inferior a la de un cliente nativo: validaciones
Existen muchos tipos de datos que no están en HTML: PDF, Ofimática, Gráficos, javaScript
Multimedia.
VBScript
Opciones de mejora:
Flash
Lenguajes de scripting: Javascript, VBScript.
Se integran al navegador pequeñas aplicaciones como visualizadores, Plug-Ins, etc…
Applets, ActiveX, etc.
Esto hace un cliente más potente, pero plantea algunos problemas:
javiergs@acm.org
Incompatibilidades entre los navegadores
dependencia de Plug – Ins
entre otros.
1
58. web script en el servidor
simplificación del modelo CGI.
Se mezcla HTML con lenguajes sencillos para generar páginas Web
PHP
Ventajas importantes: Perl
Sencillez conceptual.
ASP
Alta Velocidad de Desarrollo.
JSP
Problemas significativos: Tcl
Mezcla de presentación y negocio.
Código “ espaguetti ”
javiergs@acm.org
Y por ende bajo rendimiento, re-uso pobre
1
59. arquitectura script
Web Client GET /index.html HTTP/1.1
http Host: www.miweb.com
[request] DNS Server
1. DNS Lookup
PHP
</TABLE>
<?
Perl
$result = mysql_query($query)
or die ("DB SELECT ERROR");
<script language="JavaScript"> ASP
alert (“ Hello World “ ); while( $row = mysql_fetch_array($result))
{
</script> $lname = $row ['lname'];
$fname = $row ['fname']; JSP
$email = $row ['email'];
?>
// Spaghetti code starts.... Tcl
<TR bgColor=white>
<TD><?=$fname?></TD>
<TD><?=$lname?></TD>
<TD><?=$email?><TD>
</TR>
javiergs@acm.org
Web Server </TABLE>
http
[response]
1
60. alto … es necesario poner orden
Capas
diseño
reglas de negocio
datos
javascript presentación
gestión del proceso
dba
software HTML
división
de
responsabilidades
CSS
hardware cliente
javiergs@acm.org
1
61. agenda
1. arquitecturas Web: pre - historia
2. arquitecturas Web: situación actual.
3. factores del cambio: el mundo se complica
4. arquitecturas Web: los nuevos modelos.
5. arquitecturas Web: el Futuro
javiergs@acm.org
6. conclusiones
62. servidor Web: mayo 2004
http://news.netcraft.com/archives/web_server_survey.html
javiergs@acm.org
2
63. ingeniería de software: ¿donde comenzar?
(1) Requerimientos: (EL CLIENTE) :
Comunicación / Entrevistas Visualizar el Contexto Punto de
Validación Herramientas: IEEE SRS, Contexto, UML y otras...
(2) Análisis y Diseño (LA CALIDAD) :
¿metodologías? Y ¿herramientas?
Lo indispensable, lo necesario y el extra (si el tiempo lo permite)...
(3) Implementación (LOS LENGUAJES) :
programar ¿ con OBJETOS ?
• Microsoft .net
• Java 2 Enterprise Edition.
javiergs@acm.org
• LAMP (Linux-Apache-MySQL-Perl-PHP-Python)
(4) Pruebas :
2
64. ingeniería de software: bueno, bonito y barato
Y todo debe ser hecho con CALIDAD ¿Que es CALIDAD?
Sin descuidar:
seguridad, flexibilidad, robustez, portabilidad, reusabilidad, escalabilidad,
confiabilidad, interfaz amigable, ergonomía y documentación ...
Además de (en algunos casos):
concurrente, distribuido y ligado a una o más bases de datos.
Algunos servicios transversales
Portales, Personalización, Gestión de contenidos, Búsquedas,
Estadísticas (Business Intelligence)., Entornos colaborativos, Publicidad,
javiergs@acm.org
y Lo “bonito” tambien importa …
2
65. ingeniería de software: reporte de daños
Soporte muy complejo de dispositivos que no sean el ordenador.
Modelo centrado en el interfaz de usuario (capa de presentación),
no en el intercambio de datos o la invocación de funcionalidad.
Código “espaguetti” es habitual en aplicaciones en lenguajes de
scripting.
Varias “capas” a nivel de desarrollo: scripting de cliente, scripting
de servidor, componentes, acceso a datos.
Ciclos de desarrollo muy cortos, generan poca estructuración.
No es realmente una arquitectura de computación distribuida.
javiergs@acm.org
No satisface plenamente las necesidades
2
66. agenda
1. arquitecturas Web: pre - historia
2. arquitecturas Web: situación actual.
3. factores del cambio: el mundo se complica
4. arquitecturas Web: los nuevos modelos.
javiergs@acm.org
5. arquitecturas Web: el Futuro
6. conclusiones
67. factores de cambio
Los sistemas a nivel global requieren integrarse unos con otros Integración
de una manera natural y transparente.
Dispositivos
El acceso desde múltiples dispositivos (celular, iTV, PDA) no se Múltiples
adapta al modelo basado en HTML.
Complejidad de
interfaces más complejos. Interfases
El modelo web tradicional se adapta bastante bien para ciertos Acceso
modelos de negocio: B2C, pero para otros modelos, como los abstracto
orientados al B2B, resulta limitado, por estar orientado a la capa
de presentación (HTML).
javiergs@acm.org
Es necesario un acceso abstracto a los datos y servicios entre
los participantes, manteniendo la transparencia y sencillez del
modelo web.
3
68. integración
El valor de los sistemas de negocio se incrementan si son Integración
capaces de comunicarse entre si fácilmente.
Y sobre todo, con sistemas ajenos que suelen ser soporte Dispositivos
Múltiples
fundamental del negocio
Las tecnologías de componentes prometían esto, pero tenían
dependencias ocultas: plataforma, lenguaje, entorno... Complejidad de
Interfases
Se busca el modelo desacoplado y transparente del web,
pero en las capas de negocio y de datos.
Acceso
abstracto
Las tecnologías web (HTTP, lenguajes de marcas) han
adquirido una universalidad que los convierten en un
mecanismo posible de integración.
javiergs@acm.org
3
69. dispositivos e interfases: abstracción
El navegador web basado en HTML es una promesa (parcialmente Integración
cumplida) de cliente universal ya que esta ligado de manera inevitable al
ordenador.
Dispositivos
Múltiples
Cada vez toman mayor importancia el acceso al Web desde otros
dispositivos: Teléfonos móviles. PDAs, Televisión Interactiva, Aplicaciones
Multimedia (Flash, Streaming), etc.
Complejidad de
Se requiere el acceso a estos dispositivos aprovechando al máximo la Interfases
infraestructura web existente.
Además, se requieren interfaces más complejas, que no pueden Acceso
satisfacer plenamente con un navegador. abstracto
javiergs@acm.org
3
70. agenda
1. arquitecturas Web: pre - historia
2. arquitecturas Web: situación actual.
3. factores del cambio: el mundo se complica
4. arquitecturas Web: los nuevos modelos.
5. arquitecturas Web: el Futuro
javiergs@acm.org
6. conclusiones
71. objetivo
pasar del modelo de presentación de documentos dinámicos del Web que
conocemos ahora, a un auténtico entorno de computación distribuida
basada en Protocolos Web.
XML
Permite la invocación de servicios de distintos sistemas, de manera
similar a la invocación de una función en un lenguaje tradicional.
Emplea como base la misma infraestructura que el web actual (red IP,
Web
HTTP, Servidores Web...).
services
La capa de presentación HTML se mantiene, pero ya no tiene un
acoplamiento tan estrecho.
El objetivo es una interoperabilidad generalizada.
Toman un peso fundamental dos nuevas bases:
javiergs@acm.org
XML y Servicios Web (Web Services)
4
72. XML
XML es un lenguaje de marcas para documentos
que contienen información estructurada.
xml
Representa tanto la información como el rol que Adressen
juega dicha información (meta datos).
Adresse
Es un meta-lenguaje, con el que se definen otros
lenguajes de marcas específicos (extensibilidad).
Pretende ser la “lengua franca” sobre la que se Name
sustenten las transacciones Internet. Mustermann
PLZ
Sus líneas directoras básicas son:
22087
Adaptado a la tecnología Internet. id
Adresse 1234
Adaptable a distintos esquemas de
aplicación.
Legible por seres humanos.
javiergs@acm.org
Formalizado y validable.
Desarrollo simple.
4
73. XML: ¿ como se ve?
<?xml version="1.0"?>
<cliente> xml
Adressen
<nombre>Pedro</nombre>
<apellidos>Domingo de Dios</apellidos> Adresse
<alias ambito="familiar">Pedrito</alias>
<alias ambito="trabajo">Pesado</alias> Name
<direccion tipo=“Facturas"> Mustermann
<calle>Los Castros 143</calle>
<ciudad>Santander</ciudad> PLZ
<codigopostal>39012</codigopostal> 22087
<privado/> id
</direccion> Adresse 1234
<direccion tipo="Entregas">
<calle>General Mola 13</calle>
<ciudad>Santander</ciudad>
javiergs@acm.org
<telefono>942 318500</telefono>
</direccion>
</cliente>
4
74. XML y sus amigos
Compañeros de Trabajo Familiares
Aparte de la definición formal del lenguaje,
XML incluye una serie de tecnologías de base:
Definición de esquemas: DTDs, XML
Schemas.
Enlaces entre documentos: Xlink,
XPointer.
Parsers: DOM, SAX
Consultas: Xpath, XQuery
Transformaciones: XSLT, XSL-FO, CSS
Algunos de ellos están construidos sobre
XML
javiergs@acm.org
Estas tecnologías están controladas por el
W3C.
4
75. XML ¿para que?
Lenguaje general y neutro, XML puede tener aplicación a todos los niveles
de una arquitectura web:
En la capa de presentación,
Mediante esquemas de transformación XSLT.
Usando lenguajes de marcas derivados de XML: XHTML, WML.
Browser, dispositivo movil, skins de aplicaciones
En la capa de negocio:
Representación de componentes y servicios: formato único de
intercambio
Representación de reglas de negocio.
Configuración de aplicaciones
En la capa de datos:
Persistencia de objetos y almacenamiento de documentos estructurados.
Representación de Meta datos.
Integrado a BDMS
javiergs@acm.org
En la integración de aplicaciones (EAI):
Como formato neutro de intercambio usando esquemas de
transformación basados en XSLT
4
76. servicios web
funcionalidad distribuida a gran escala.
aplicación modular, autocontenida y
autodescriptiva, que puede ser publicada,
localizada e invocada de manera funcional usando
el Web.
Puede ser usada por aplicaciones (no
necesariamente Web) o por otros Servicios Web
(Orquestación).
javiergs@acm.org
invocación de funcionalidad con esquemas
neutros basados en XML, sobre HTTP.
4
77. servicios Web arquitectura
Base tecnológica
HTTP: transporte.
XML: representación de datos.
MIME: codificación.
Servicios básicos de plataforma
SOAP: invocación remota.
UDDI: directorio. (DNS)
WDSL: descripción de
características.
Servicios avanzados (por definir)
XLANG/XAML: soporte
javiergs@acm.org
transaccional.
seguridad
4
78. alto … ERA necesario poner orden
A
A
A A
A A
cliente
javiergs@acm.org
4
79. agenda
1. Arquitecturas Web: pre - historia
2. arquitecturas Web: situación actual.
3. factores del cambio: el mundo se complica
4. arquitecturas Web: los nuevos modelos.
5. arquitecturas Web: el Futuro
javiergs@acm.org
6. conclusiones
81. El web semántico: el web inteligente
http://www.w3.org/2001/sw/
o Marco común para compartir y reutilizar datos entre aplicaciones, empresas,
comunidades: base de datos globalmente relacionada
o El Web Semántico pretende dotar al Web actual de estructura y contenidos con
significado (semántica), categorizados mediante meta datos específicos (ontologías):
RDF – resource description framework
o XML es la base de la representación del significado.
o Mediante la asociación de significado a los contenidos se puede dotar al Web de
funcionalidad siguiendo esquemas de agentes.
o Los servicios web facilitan la invocación de funcionalidad por parte de los agentes
autónomos. (entre comillas inteligencia artificial )
javiergs@acm.org
Palabras clave:
XML (1), servicios Web (2), centrado en los datos (3)
5
82. B2B: el verdadero e-business
http://www.b2business.net/
El web “tradicional” ofrecer una “ventana” hacia los contenidos ofrecido por una
empresa a sus socios externos e internos. (B2C)
Las arquitecturas orientadas a servicios ofrecen “puertas” que permiten un control
más estrecho de los intercambios, y de una manera transparente, segura y
generalizada.
arquitectura sólida y uniforme para el establecimiento de soluciones e-Business para
distintos modelos de negocio, principalmente los “invisibles”
Acciones facilitadotas del comercio: interacción entre empresas y entre las áreas
internas a una empresa: marketing, finanzas, manufactura, ventas y negociación
javiergs@acm.org
Palabras clave:
XML (1), servicios Web (2), centrado en negocio (3)
5
83. agenda
1. Arquitecturas Web: pre - historia
2. arquitecturas Web: situación actual.
3. factores del cambio: el mundo se complica
4. arquitecturas Web: los nuevos modelos.
5. arquitecturas Web: el Futuro
javiergs@acm.org
6. conclusiones