Your SlideShare is downloading. ×
200611 Developing Java web applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

200611 Developing Java web applications

1,151
views

Published on

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,151
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 3. contexto: presente, pasado y futuro 1980 2000 2010 javiergs@acm.org
  • 4. Internet: la realidad tangible Electrónica Telecomunicaciones javiergs@acm.org software
  • 5. CiberEspacio: la alucinación de la conciencia software javiergs@acm.org
  • 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
  • 8. Video: googlezon 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
  • 12. 0010. ¿qué necesitamos? bases de datos y programación: una perspectiva a futuro en la sociedad de la información
  • 13. 0010. programación bases de datos y programación: una perspectiva a futuro en la sociedad de la información
  • 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
  • 15. 2 Java2.inicio() agenda[ ]= ”); MIDlets Applets Servlet Aplicación gráfica JSP Aplicación texto Java Beans 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 } }
  • 21. 3] =“ compilar y ejecutar … ”; agenda[ archivo.java archivo.class 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
  • 30. javiergs@acm.org JDBC
  • 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á
  • 35. DBMS clasificación javiergs@acm.org
  • 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
  • 51. javiergs@acm.org
  • 52. 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
  • 80. X-internet: una federación de web services javiergs@acm.org 5
  • 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
  • 84. javiergs@acm.org 6 conclusiones
  • 85. y lo mejor esta por llegar… ¡gracias! javiergs@itesm.mx http://www.javiergs.com javiergs@acm.org