200611 Developing Java web applications

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

0001. ¿dónde estamos?


contexto: presente, pasado y futuro
1980 2000 2010
javiergs@acm.org

Internet: la realidad tangible

Electrónica

Telecomunicaciones
javiergs@acm.org

software

CiberEspacio: la alucinación de la conciencia

software
javiergs@acm.org

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

CiberEspacio: el mundo detrás del espejo

Sociedad y comunidad

Trabajo y negocios

Auto realización

A temporal

Omni - presencialista
javiergs@acm.org

Video: googlezon
javiergs@acm.org

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

http://maps.google.es http://amazon.com
javiergs@acm.org


la red el ciberespacio
javiergs@acm.org

Obrero Arquitecto
Operativo Modelo
Básico Complejo

0010. ¿qué necesitamos?


0010. programación


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

2 Java2.inicio()
agenda[ ]= ”);

MIDlets Applets Servlet

Aplicación gráfica JSP

Aplicación texto Java Beans
javiergs@acm.org

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

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

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

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

}

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

}
}

3] =“ compilar y ejecutar … ”;
agenda[

archivo.java archivo.class
javiergs@acm.org

0010. datos


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

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

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

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

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 ) ;

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;

0011. las piezas juntas (puente)


javiergs@acm.org

JDBC

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");
}

0100. el futuro (unificar)


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

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á

DBMS clasificación
javiergs@acm.org

Agenda

 Object-Oriented Database Systems

 Object-Relational Database Systems
javiergs@acm.org

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

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);
  }

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

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

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";

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;

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

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;

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

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);

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

alto … ERA necesario poner orden

A

A

A A

A A

cliente
javiergs@acm.org

4

y lo mejor esta por llegar…

¡gracias!

javiergs@itesm.mx

http://www.javiergs.com
javiergs@acm.org

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

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

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

arquitectura CGI

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

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

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

arquitectura script
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

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

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

servidor Web: mayo 2004
http://news.netcraft.com/archives/web_server_survey.html
javiergs@acm.org

2

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

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

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

agenda

1.  arquitecturas Web: pre - historia



javiergs@acm.org


6.  conclusiones

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

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

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

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

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

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

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

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

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

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

agenda

1.  Arquitecturas Web: pre - historia




javiergs@acm.org

6.  conclusiones

X-internet: una federación de web services
javiergs@acm.org

5

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

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

javiergs@acm.org

6
conclusiones

200611 Developing Java web applications

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (17)

Similar a 200611 Developing Java web applications

Similar a 200611 Developing Java web applications (20)

Más de Javier Gonzalez-Sanchez

Más de Javier Gonzalez-Sanchez (20)

Último

Último (19)

200611 Developing Java web applications