Programacin Orientada a Ojetos

1
Programación Orientada a Ojetos

• M.C. Juan Carlos Olivares Rojas

jolivares_at_uvaq.edu.mx http//antares.itmorelia.edu
.mx/jcolivar Noviembre, 2009
2
Programación Orientada a Objetos

• Cuál es la diferencia entre una estructura y una
  clase si las dos son ADT (Tipos de Datos
  Abstractos)?
• La encapsulación
• La encapsulación permite colocar datos
  lógicamente relacionados como constantes,
  variables, funciones en una sola entidad.
  Ejemplos son los paquetes y clases.

3
POO

• La visibilidad y el ocultamiento de la
  información es sumamente importante.
• Este paradigma basa su funcionamiento en la
  creación de objetos que se dan a través de moldes
  predeterminados llamado clases.
• No es reinventar la rueda, simplemente es
  estructurar de mejor forma el paradigma
  imperativo.

4
POO

• La reutilización de componentes como son los
  mecanismos de herencia y polimorfismo hacen que
  la construcción de código sea más simple.
• El primer lenguaje basado en este paradigma fue
  Smalltalk. Lenguajes como Java son considerado
  lenguajes orientados a objetos no puros, ya que
  tienen componentes de programación estructurada.

5
POO

• En esta unidad se verán conceptos avanzados del
  paradigma orientado a objetos así como mejores
  prácticas de desarrollo.
• Se seguirá una dinámica parecida a la de la
  unidad pasada.

6
Refactorización

• La refactorización es el proceso que consiste en
  cambiar la estructura interna de un programa sin
  modificar su comportamiento externo.
• La refactorización es parte importante del
  proceso de reingeniería y puede enfocarse a la
  reestructuración de códigos

7
Refactorización

• Las herramientas actuales permiten más que
  simplemente buscar una cadena de texto y
  sustituirla por otra.
• Al hacer uso de la refactorización permiten una
  reestructuración más simple y menos propensa a
  errores.
• NetBeans desde su versión 5.0 soporta
  refactorización.

8
Refactorización

• Las principales herramientas con las que se
  cuenta son
• Renombrado para cambiar de manera segura el
  nombre (si no se aplica a esto, un comando de
  sustituir todo puede ser perjudicial), mover,
  copiar, borrar, cambiar parámetros de los
  métodos, encapsular campos de una clase (crear
  métodos get/set).

9
Refactorización

• Se pueden extraer elementos para crear
  interfaces, se pueden introducir variables,
  constantes, métodos, atributos.
• En algunos casos es más tardado usar la
  herramienta que realizar la reestructuración de
  código a mano.
• En NetBeans y algunos otros IDEs se cuentan con
  herramientas para manipular el código fuente.

10
Refactorización

• Para dar formato (si es que el código no se creo
  en un IDE), eliminar espacios en blanco
  innecesarios, identar a la izquierda y a la
  derecha, subir, bajar líneas, duplicar líneas,
  completar, insertar código, etc.
• Estas herramientas pueden utilizarse para generar
  patrones repetitivos de código en funciones.

11
Refactorización

• Para la reestructuración de códigos se pueden
  seguir convenciones ya definidas las más
  importantes son la notación húngara y la notación
  de camello.
• La notación húngara fue creada por Charles
  Simonyi de Microsoft, el cual es húngaro y por
  eso recibió ese nombre.

12
Notación Húngara

• Es un método ampliamente usado sobre todo para
  convención de nombres de variables.
• Consiste en tener variables autodocumentadas
  agregando un prefijo de tres caracteres o menos
  para indicar su tipo.
• Las abreviaturas de los tipos de datos puede
  variar dependiendo del lenguaje de programación.

13
Notación Húngara
14
Notación húngara

• int nTest
• long lTemp
• char szString "Prueba"
• struct Rect srRect
• int nMiVariableEjemplo
• char szEjemploString
• int NNOMBREINVALIDO
• int nNombre_Incorrecto

15
Notación Húngara

• Las funciones o subrutinas no se les agrega
  abreviaciones, se recomiendan tengan un nombre
  descriptivo.
• Los nombres de las clases van en mayúsculas.
• Se pueden tener nuevos tipos de datos sólo se
  deben de poner las nuevas nomenclaturas.

16
Notación de Camello

• Es la utilizada por Java y herramientas afines.
  Su uso está creciendo en popularidad mientras que
  la notación húngara va en desuso.
• Su principal característica consiste en que no
  separa nombres de identificadores (variables,
  métodos, objetos) con _ para palabras
  compuestas.

17
Notación de Camello

• Los identificadores tienen la forma de la joroba
  de un camello. No se indican tipos de datos.
  Sigue respetando mucho de la Notación C.
• Los métodos inician en minúsculas y si hay una
  palabra compuesta esta inicia con mayúscula dando
  la apariencia de una joroba.

18
Notación Camello

• Las clases inician con mayúscula siguiendo el
  mismo método.
• Los métodos para acceder a atributos de las
  clases no públicos deben llamarse por convención
  set y get.

19
Reutilización

• El reuso es una de las técnicas de resolución de
  problemas que más utilizamos los humanos. De
  hecho es lo primero que verifica nuestro cerebro.
• El reuso en software nos ayuda a mejorar la
  producción y calidad del software al no
  reinventar la rueda.

20
Reuso

• El reuso nos permite afrontar los grandes
  proyectos de software sin mayores complicaciones.
  Desafortunadamente no todo se puede reutilizar.
• La reutilización es la propiedad de utilizar
  conocimiento, procesos, metodologías o
  componentes de software ya existente para
  adaptarlo a una nueva necesidad, incrementando
  significativamente la calidad y productividad del
  desarrollo.

21
Reutilización

• La reutilización puede ser composicional,
  generativa y adapativa.
• Es composicional cuando se orienta al reuso del
  producto. Puede ser de caja blanca (si nos
  interesa modificar el comportamiento), caja negra
  (cuando no se puede modificar el comportamiento)
  y adaptativo cuando es una mezcla de ambos.

22
Reutilización

• La reutilización por generación se da cuando se
  utilizan esfuerzos previos del desarrollo de
  software.
• Para que un objeto pueda ser reusable se necesita
  de un alto nivel de abstracción. Entre mayor es
  su nivel de abstracción, mayor es su nivel de
  reuso.

23
Reuso

• Tipos de reuso
• Código reciclado utilizar parte del código
  definido en otros proyectos.
• Componentes de código consiste en utilizar
  módulos, clases, APIs, etc.
• Esquemas DFD, Diagramas UML.

24
Reuso

• Frameworks Solución integrada para la resolución
  de problemas en un contexto particular. Se pueden
  utilizar patrones de diseño. Un ejemplo de
  Framework es .NET
• Las etapas del proceso de reuso son
• Adquisición del requerimiento.

25
Reuso

• Búsqueda y Recuperación
• Recuperación por Palabras Claves
• Recuperación Basada en la Estructura
• Recuperación Enumerada
• Identificación
• Adecuación

26
Reingeniería del Software

• Sucede que si una aplicación necesita ser
  modificada constantemente y no tiene una
  metodología de seguimiento del desarrollo del
  proyecto, la modificación del software se vuelve
  sumamente complicada.
• El mantenimiento de software en algunos casos
  puede llegar a ser del 60 del total de costos
  del proyecto.

27
Reingeniería del Software

• Aún cuando un software se haya desarrollado con
  la mejor metodología de software tendrá que ser
  modificado en un futuro por algún motivo, debido
  a que lo único constante es el cambio.
• Los tipos de mantenimiento de Software son
  correctivo, adaptativo, mejoras o mantenimiento
  de perfeccionamiento, mantenimiento preventivo o
  reingeniería.

28
Reingeniería del Software

• El 80 del tiempo del desarrollo del software se
  ocupa en la adaptación del software a su ambiente
  externo.
• La reingeniería de software es costosa y
  consumidora de tiempo.
• La reingeniería es una actividad de
  reconstrucción, preferible de realizar antes de
  que se derrumbe la obra.

29
Reingeniería de Software

• Antes de derribar una casa, quizás se necesita
  corroborar que está mal.
• La reingeniería es un proceso que altera los
  elementos internos de toda obra, no es una sola
  remodelación de la fallada.
• Generalmente se siguen los siguientes pasos para
  aplicar reingeniería

30
Reingeniería de Software

• Análisis de Inventario
• Reestructuración de Documentos
• INGENIERÍA INVERSA
• Reestructuración de Códigos
• Reestructuración de Datos
• Ingeniería directa

31
Ingeniería Inversa

• Se aplica para obtener un modelo detallado de
  análisis, ingeniería de requerimientos, diseño y
  en algunos casos implementación teniendo una
  solución, la cual es una actividad consumidora de
  tiempo.
• Tanto la Ingeniería Inversa como la Reingeniería
  en la mayoría de las licencias de Software se
  encuentran penadas por la ley.

32
Javadoc

• Es el estándar para crear documentación para los
  proyectos en Java.
• Es una herramienta estándar del JDK de Sun
  Microsystem. Crea documentación en HTML y casi
  cualquier IDE lo hace.
• Se deben utilizar los comentarios especiales /
  ../ con algunas palabras clave para determinar
  la documentación.

33
Javadoc

• Las palabras clave inician con una arroba.
• Se puede incrustar cualquier etiqueta de HTML
  para hacer más visible la documentación.
• _at_author nombre_desarrollador
• _at_deprecated descripción //indica un método que no
  se utiliza su uso

34
Javadoc

• _at_param nombre descripción
• _at_return descripción //no se debe utilizar con
  métodos void.
• _at_see referencia //asocia con otro elemento el
  cual puede ser método() clasemétodo()
  paquetemétodo() paquete.clasemétodo().
• _at_throws clase descripcion
• _at_version versión

35
Javadoc

• La documentación se crea de la siguiente forma
  javadoc archivo.java
• En NetBeans se puede encontrar la opción en el
  menú Build en la opción Generate JavaDoc for
• Se recomienda realizar tanto el código como las
  clases en inglés.

36
Javadoc

• /
• Thrown to indicate that the application has
  attempted to convert
• a string to one of the numeric types, but that
  the string does not
• have the appropriate format.
• _at_author unascribed
• _at_version 1.16, 02/02/00
• _at_see java.lang.IntegertoString()

37
Javadoc

• _at_since JDK1.0
• /
• public class NumberFormatException extends
  IllegalArgumentException
• /
• Constructs a ltcodegt NumberFormatException
  lt/codegt with no detail message.
• /
• public NumberFormatException () super()

38
Javadoc

• /
• Constructs a ltcodegt NumberFormatException
  lt/codegt with the
• specified detail message.
• _at_param s the detail message.
• /
• public NumberFormatException (String s) super
  (s)

39
Ofuscación

• La ofuscación es una técnica avanzada de
  refactorización que permite a un código
  mantenerle obscuro (es decir no muy legible) con
  diversos propósitos de optimización.
• Para que se hace ofuscación?
• No viola esto el principio de claridad en la
  implantación?

40
Ofuscación

• La ofuscación se realiza en muchas casos para
  hacer un código ilegible, también en muchos casos
  se puede reducir el tamaño del código fuente y
  del código binario realizado.
• Al realizar cualquier tipo de programa se puede
  aplicar técnicas de reingeniería como la
  ingeniería inversa para de un código binario
  tratar de obtener su código fuente.

41
Ofuscación

• En mucho tipos de aplicaciones como las
  aplicaciones móviles se ofusca el código objeto
  generado para obtener un código más pequeño.
• Un programa puede ser fácilmente decompilable,
  por este motivo se ofusca con la premisa de que
  si esto llegará ocurrir, el que lo hiciera le
  costaría mucho trabajo entender el programa y
  modificarlo.

42
Ofuscación

• En el caso de programas ejecutables (.exe) es
  mucho más difícil obtener un código en lenguaje
  de alto nivel, dado que el proceso de
  decompilación deja sus resultados en ensamblador
  y por lo tanto es necesario saber como el
  compilador ensambla cada línea de código. Por
  este motivo muchas empresas grandes del sector
  informático realizan sus proyectos en sus propios
  compiladores.

43
Ofuscación

• Actualmente la ofuscación se emplea más en la
  ofuscación de código dinámico, dado que aquí es
  muy importante tanto el tamaño del código como la
  legibilidad de este, tal es el caso de HTML.
• La ofuscación si bien es cierto viola principios
  de buena prácticas de Ing. de Software, se
  realiza con un propósito específico hasta el
  final del proceso.

44
Ofuscación

• En algunos casos la ofuscación se logra
  simplemente refactorizando el nombre de las
  variables pero en muchos casos esto no sirve.
• Para lograr la ofuscación se deberá modificar el
  flujo del programa de tal forma que menos
  instrucciones o en algunos casos más
  instrucciones deben de realizar el mismo programa.

45
Ofuscación

• En algunos casos resulta que ofuscar el código
  puede ser que el tamaño del código fuente y del
  programa aumente, debido a que es común que las
  variables tengan nombres muy grandes o bien se
  incluyan instrucciones extras, se descompongan
  ciclos, se cambien y mapeen estructuras, etc.
• Existen concursos de ofuscación de código

46
Ofuscación
47
Sockets Java

• Java es un lenguaje multiplataforma que al igual
  que otros lenguajes de programación tiene APIs
  para la comunicación de procesos remotos.
• La ventaja de utilizar sockets en Java con
  respecto a su contraparte en C, radica en que
  Java enmascara la complejidad de los procesos en
  clases más simples.

48
Sockets Java

• Para utilizar sockets y clases similares se
  necesita utilizar el paquete java.net.
• Se pueden utilizar clases específicas para
  conectarse a servicios de red determinados como
  http, ftp, entre otros.
• //Servidor usando sockets stream
• ServerSocket ss new ServerSocket(5000, 100)

49
Servidor Stream

• Socket con ss.accept()
• OutputStream sal con.getOutputStream()
• String s new String(ITMorelia\n)
• for(int i0 i lt s.length() i)
• sal.write((int) s.charAt(i))
• Conection.close()

50
Cliente stream

• Socket c new Socket(InetAddress.getLocalHost(),
  5000)
• InputStream entrada c.getInputStream()
• char c
• while((c (char) entrada.read()) ! \n)
• System.out.println(String.valueOf(c))

51
Servidor datagramas

• try
• DatagramSocket sS new DatagramSocket()
• DatagramSocket rS new DatagramSocket( 5000)
• catch(SocketException SE)
• SE.printStackTrace()
• System.exit(1)

52
Servidor datagramas

• byte a new byte 100
• DatagramPacket rP new DatagramPacket( a,
  a.length)
• rS.receive(rP)
• System.out.println(Dirección rP.getAddress()
  Puerto rP.getPort longitud
  rP.getLength())

53
Servidor datagramas

• byte d rP.getData()
• sP new DatagramPacket(d, d.length,
  rP.getAddress(), 5001)
• sS.send(sendPacket)
• InetAddress comp InetAddress.getByName(www.itc.
  edu.mx)

54
Sockets Java

• Otras excepciones que se pueden capturar
• UnknownHostException
• EOFException
• ConnectException

55
Sockets en Java

• Se recomienda la utilización en las nuevas
  versiones de Java de los flujos ObjectInputStream
  y ObjectOutputStream, los cuales son
  serializables.
• El cierre de los flujos debe hacerse en orden
  inverso de cómo se crearon.
• Se pueden cambiar algunas opciones de
  configuración como s.setSoTimeout(5000) //Tiempo
  de interrupción de lectura.

56
Sockets Java

• También se recomienda el uso de un objeto
  PrintWriter para manejar de mejor forma la
  escritura a través de un socket.
• PrintWriter escritor new PrintWriter(socket.getO
  utputSream())
• escritor.println(Mensaje mensaje)
• escritor.flush()

57
Sockets Java

• También se puede utilizar un objeto Scanner para
  leer desde un socket.
• Socket s new Socket(time-A.timefreq.bldrdoc.gov
  , 13)
• InputStream e s.getInputStream()
• Scanner in new Scanner(e)
• while(in.hasNextLine())
• String l in.nextLine() System.out.println(l)

58
2.1.2 RPC

• Las llamadas a procedimientos remotos (RPC) fue
  el primer intento por obtener un middleware para
  la construcción de sistemas distribuidos.
• Su funcionamiento se basa en la arquitectura
  cliente/servidor siendo totalmente transparente
  para el usuario.

59
RPC

• El problema del manejo de procesos distribuidos
  con sockets radica en que se basa en el flujo de
  E/S, haciendo los programas más difíciles de
  estructurar.
• En 1984 Birelly y Nelson idearon el modelo de RPC
  a semejanza del llamado de procedimientos locales
  (LPC).

60
RPC

• El nivel de transparencia en RPC es muy alto ya
  que el usuario no tiene que ver con detalles de
  conexión.
• La simplicidad de toda esta heterogeneidad en el
  llamado a un procedimiento remoto es realizado
  por los stubs (resguardos) tanto en el cliente
  como en el servidor.

61
RPC

• Para la transferencia de datos entre los stubs,
  se necesita de un proceso de empacar desempacar
  los parámetros y resultados. Dicho proceso recibe
  el nombre de marshalling.
• Los stubs se comunican con los núcleos de cada
  proceso logrando una transparencia muy alta.

62
RPC

• La secuencia de mensajes RPC es la siguiente
• El procedimiento cliente llama al stub del
  cliente de la manera usual.
• El stub del cliente construye un mensaje y hace
  un señalamiento al núcleo.
• El núcleo envía el mensaje al núcleo remoto.

63
RPC

• El núcleo remoto proporciona el mensaje al stub
  del servidor.
• El stub del servidor desempaca los parámetros y
  llama al servidor.
• El servidor realiza el trabajo y regresa el
  resultado al stub.
• El stub del servidor empaca el resultado en un
  mensaje y hace un señalamiento al núcleo.

64
RPC

• El núcleo remoto envía el mensaje al núcleo del
  cliente.
• El núcleo del cliente da el mensaje al stub del
  cliente.
• El stub desempaca el resultado y lo regresa al
  cliente.
• El manejo de los datos se hace a través de XDR
  (eXternal Data Representation).

65
RPC

• Para el envío de datos se utiliza la siguiente
  forma canónica Complemento a 2 los enteros,
  ASCII caracteres, 0 (falso) y 1 verdadero,
  formato IEEE decimales, todo guardado como little
  endian.
• En la práctica RPC no es lo mismo que un
  procedimiento local a la hora de revisar los
  mecanismos de fallas.

66
RPC

• La semántica de fallas de RPC es la siguiente
• El cliente no puede localizar al servidor.
• Se pierde el mensaje de solicitud del cliente al
  servidor
• Se pierde el mensaje de respuestas del servidor
  al cliente.
• El servidor falla antes de recibir una solicitud.

67
RPC

• El cliente falla después de enviar una solicitud.
• En general existen diversas implementaciones de
  RPC, siendo las más extendidas sobre TCP/IP, la
  cual tiene los siguientes puntos a favor
• El protocolo ya ha sido diseñado, lo que ahorra
  trabajo considerable.

68
RPC

• Se dispone de muchas implementaciones.
• Esta disponible en casi cualquier sistema Unix.
• Tanto TCP como UDP están soportados por muchas
  redes.
• Las implementaciones más evolucionadas de RPC
  incluye la de Sun ONC (Open Network Computing) y
  DCE (Distributed Computing Environmet).

69
RPC

• RPC está desarrollado en C, pero algunas
  versiones permiten programar en otros lenguajes
  como Fortran. Las implementaciones más actuales
  trabajan sobre XML formando los XML-RPC.
• Para la conexión entre un cliente y un servidor
  utilizando RPC se siguen dos pasos localizar la
  máquina servidor, y localizar el proceso en esa
  máquina.

70
RPC

• Para encontrar dichos servicios se necesita de un
  demonio RPC que se encuentre monitoreando todos
  los procesos remotos, dicho proceso se llama
  portmap , el cual escucha en el puerto 111.
• Muchos servicios de red utilizan RPC para
  funcionar, entre ellos NFS, el cual es un sistema
  de archivos distribuidos.

71
RPC

• Un programa en RPC se crea a través de un
  lenguaje de definición de interfaces (IDL por sus
  siglas en Inglés). Tiene la extension .X
• program RAND_PROG
• version RAND_VER
• void INICIALIZA_RANDOM(long) 1
• doble OBTEN_SIG_RANDOM(void) 2
• 1 /No. de version/
• 0x31111111 /No. de programa/

72
RPC

• rpcgen -c -a rand.x
• rand_server.c servidor
• rand_svc.c stub del servidor (no se modifica)
• rand.h cabeceras
• rand_clnt.c stub del cliente (no se modifica)
• rand_client.c cliente
• rand_xdr.c manejo de estructuras

73
RPC

• 00000000-1FFFFFFF Definidos por sun
• 20000000-3FFFFFFF Definidos por el usuario
• 40000000-5FFFFFFF Transitorios
• 60000000-FFFFFFFF Reservados para usos futuros
• rpcinfo -s
• portmap

74
RPC

• const MAX 100
• typedef int Longitud
• struct argumentos
• float salario
• Longitud tam
• Sólo se puede recibir y enviar un parámetro.

75
RPC

• Existen nuevas propuestas para mejorar el
  desempeño de RPC como RPC2 que maneja UDP.
  También se han diseñado mecanismos como MultiRPC
  para el manejo de RPCs en paralelos. Existen
  otras alternativas como LRPC (RPC ligeros) que se
  basan en optimizaciones de la copia de datos y de
  la planificación de los hilos.
• RPC está definido en el RFC 1831.

76
RMI

• La invocación de métodos remotos es la versión
  orientada a objetos de la filosofía RPC.
• Los programas realizados en Java deben heredar de
  la clase remote.
• A la hora de ejecutar se deben indicar las
  políticas de seguridad. Esto se hace a través del
  parámetro -D de java

77
RMI

• java -Djava.security.policypolitica prg
• Los archivos de stub se generan con el comando
  rmic -d . Prg
• El primer paso consiste en inicializar el
  rmiregistry (similar al portmapper en RPC)

78
RMI

• Al proxy en el lado cliente se le llama stub,
  mientrás que en el servidor se le llama skeleton.
• Se cuenta con la primitiva invoke(objeto, método,
  param_entrada, param_salida)
• Se necesita de un proceso enlazador (binder) que
  una a un cliente con el objeto remoto.

79
RMI

• import java.rmi.
• import java.util.Vector
• public interface Forma extends Remote
• int dameVersion() throws RemoteException
• GraphicObject dameTodoEstado() throws
  RemoteException

80
RMI

• public interface ListaForma extends Remote
• Forma nuevaForma(GraphicObject g) throws
  RemoteException
• Vector todasFormas() throws RemoteException
• int dameVersion() throws ReomteException

81
RMI

• //Sirviente ListaForm
• import java.rmi.
• import java.rmi.server.UnicastRemoteObject
• import java.util.Vector
• public class SirvienteListaForma extends
  UnicastRemoteObject implements ListaForma
• private Vector laLista
• private int version

82
RMI

• public SirvienteListaForma() thorws
  RemoteException
• public Forma nuevaForma(GraphicObject g) thorws
  RemoteException
• version
• Forma s new SirvienteForma(g, version)
• laLista.addElement(s)
• return s //implementar los demás métodos

83
RMI

• Para acceder al enlazador (RMIRegistry) se
  utilizan métodos de la clase Naming, utilizando
  las siguiente URI
• rmi//nombrecompupuerto/nombreObjeto
• Los clientes deben hacer consultas (lookup) a
  computadoras concretas. Otros métodos son
  rebind(), bind(), unbind() y list().

84
RMI

• //Programa servidor
• public class ServidorListaForma
• public void main(String args)
• System.setSecurityManager(new
  RMISecurityManager())
• try
• ListaForma unaListaForma new
  SirvienteListaForma()

85
RMI

• Naming.rebind(Lista Forma, unaListaForma)
• System.out.println(Servidor de ListaForm
  Listo)
• catch (Exception e)
• System.out.println(Error
  e.getMessage())

86
RMI

• //Cliente
• import java.rmi.
• import java.rmi.server.
• import java.util.Vector
• public class ClienteListaForma
• public static void main(String args)
• System.setSecurityManager(new
  RMISecurityManager())
• ListaForma unaListaForma null

87
RMI

• try
• unaListaForma (ListaForma)
  Naming.lookup(//jcolivares.ListaForma)
• Vector sLista unaListaForma.todasFormas()
  
• catch(RemoteException e)
  System.out.println(e.getMessage())
• catch (Exception e)

88
RMI

• El marshalling se hace en formato Big-endian.
• Jerarquía de clases en RMI
• Object --gt RemoteObject (Remote) --gt RemoteStub,
  RemoteServer (UnicastRemoteObject)
• El puerto por el cual escucha el RMI es el 1099
  (rmi//localhost1099/Objeto)

89
RMI

• Ejemplo de archivo de política de seguridad
• grant
• permission java.net.SocketPermission
• 1024-65535, connect
• permission java.io.FilePermission
• directorio, read
• permission java.security.AllPermission

90
CORBA

• Common Object Request Broker Architecture
• Es un middleware para la construcción de sistemas
  distribuidos utilizando el paradigma de
  programación orientada a objetos.
• Una de las principales ventajas de CORBA es que
  cada uno de los componentes de CORBA se pueden
  implementar en una gran variedad de lenguajes.

91
CORBA

• //Ejemplo de IDL en CORBA
• struct Persona
• string nombre
• long año
• interface ListaPersonas
• void añadePersona(in Persona p)
• long damePersona(in string nombre, out Persona
  p)

92
CORBA

• CORBA maneja un modelo asíncrono de comunicación,
  aunque también se puede manejar un esquema de
  polling.
• CORBA utiliza muchas tecnologías estandarizadas
  como IOR (Interoperable Object Reference),
  IIOP(Internet Inter ORB Protocol), ORB (Object
  Request Broker Architecture), entre otras.

93
CORBA

• CORBA es una arquitectura genérica, de tal forma
  que otras tecnologías de objetos como RMI se
  pueden ejecutar a través de IIOP.
• CORBA está basado en una arquitectura de cuatro
  capas con proxys en el lado cliente y servidor.

94
CORBA

• Para realizar objetos remotos en Java se utiliza
  el Java IDL, el cual está incluido en las
  diferentes versiones de JDK.
• Las interfaces de los objetos remotos se hacen a
  través del IDL de CORBA.
• interface Produto
• string getDescripcion()

95
CORBA

• El compilador de IDL a Java se llama idlj o
  idltojava en versiones antiguas
• idlj Producto.idl
• public interface Producto extends
  org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEn
  tity

96
CORBA

• Los parámetros de los métodos pueden ser in, out,
  inout. Los parámetros in son por valor, out
  referencia, inout referencia con valor inicial.
• En Java no existen las referencias por lo que se
  simulan (clases holder).
• IDL no soporta sobrecarga de métodos.

97
CORBA

• La palabra clave atrribute de IDL hace referencia
  a métodos set y get
• module Aplicación
• interface producto
• attribute string isbn
• interface Almacen

98
CORBA

• Al ejecutar idlj Producto.idl se crean
• Producto.java //definición interfaz
• ProductoHolder.java //clase contenedor parametros
  out
• ProductHelper.java // Clase auxiliar
• _ProductStub.java //Stub con el ORB

99
CORBA

• El mismo ILDL se puede compilar en C haciendo
  uso de la herramienta omniORB, el cual se
  ejecuta omniidl bcxx Producto.idl
• El cual genera
• Producto.hh Producto, Producto_Helper, y
  POA_Producto
• ProductoSK.cc implementación

100
CORBA

• Para ejecutar el servicio de nombres se corre el
  programa tnameserv (depreciado) o el orbd con el
  parámetro ORBInitialPort 2809
• import org.omg. CosNaming.
• import org.omg.CORBA.
• public class EntCliente
• public static void main(String args)
• try

101
CORBA

• ORB orb ORB.init(args, null)
• org.omg.CORBA.Object n orb.resolve_initial_re
  ferences(NameService)
• NamingContext contexto NamingContextHelper.narro
  w(n)
• NameComponent ruta new NameComponent(princi
  pal, Context), new NameComponent(Objeto,
  Object)

102
CORBA

• org.omg.CORBA.Object obj
  contexto.resolve(ruta)
• Obj o ObjHelper.narrow(obj)
• System.out.println(o.getenv(PATH))
• catch (Exception e)
• e.printStackTrace()

103
CORBA

• Para implementar servidor CORBA en java se debe
  ejecutar idlj fall archivo.idl
• import org.omg.CosNaming.
• import org.omg.CORBA.
• import org.omg.PortableServer.
• public class SysPropImpl extends SysPropPOA
• public String getProperty(String clave)

104
CORBA

• return System.getProperty(clave)
• public class ServidorPropSis
• public static void main(String args)
• try
• ORB orb ORB.init(args, null)
• POA poaraiz (POA) orb.resolve_initial_refe
  rences(RootPOA)

105
CORBA

• poaraiz.the_POAManager().activate()
• SysPropImpl impl new SysPropImpl()
• org.omg.CORBA.Object ref poa.raiz.servant_to_r
  eference(impl)
• org.omg.CORBA.Object objContDenom
  orb.resolve_initial_references(NameService)
• NamingContext contexto NamingContextHelper.narro
  w(objContDenom)

106
CORBA

• NameComponent ruta new
  NameComponent(SysProp, Object)
• Contexto.rebind(ruta, ref)
• orb.run()
• catch (Exception e)
• e.printStackTrace(System.out)

107
Modelo de servicios Web
Dispositivos móviles
Browsers estándar
Clientes ricos
Otros servicios
Servicios Web
Formularios Web
Lógica aplicación
Servicios SO
108
Servicios Web

• Los servicios Web van de la mano de las
  tecnologías XML.
• XML nos sirve para estandarizar el marshalling de
  los datos.
• Utilizar la Web nos permite tener un puerto no
  bloqueando por Firewall

109
Servicios Web

• Son la invocación de código remoto utilizando
  protocolos estandarizados.
• En conclusión, realizan la misma función que los
  sockets, RPC, RMI, Corba y demás tecnologías
  distribuidas.
• Se puede ver a los servicios Web como una
  analogía de un procedimiento almacenado en una
  base de datos.

110
Qué son los Servicios Web?

• "A Web service is a software system designed to
  support interoperable machine-to-machine
  interaction over a network. It has an interface
  described in a machine-processable format
  (specifically WSDL). Other systems interact with
  the Web service in a manner prescribed by its
  description using SOAP-messages, typically
  conveyed using HTTP with an XML serialization in
  conjunction with other Web-related standards."

111
Definición de SW

• La aplicación que actúa como cliente debe
  conocer
• La URL del servidor remoto que ofrece el
  servicio,
• El nombre del servicio que se solicita, y
• Los parámetros que se deben enviar junto con la
  llamada al servicio.
• Estos datos se enviarán mediante HTTP

112
Definición de SW

• El servidor que ofrece el servicio web leerá los
  parámetros que se le han enviado, llamará a un
  componente o programa encargado de implementar el
  servicio, y los resultados que se obtengan de su
  ejecución serán devueltos al servidor que
  solicitó la ejecución del servicio.

113
Servicios Web

• Un servicio Web no es un XML RPC como tal, se
  diferencia en la forma en que trabajan.
• Los servicios Web forman la base de la
  arquitectura orientada a servicios (SOA)
• Los servicio Web utilizan generalmente el método
  POST de HTTP para enviar los datos de la
  invocación del servicio.

114
SOA (Arquitectura Orientada a Servicios)

Proveedor de Servicios
Servicio
Conectar
Publicar
Solicitante de Servicio
Registro de Servicios
Encontrar
Descripción
Cliente
115
Servicios Web

• Los datos viajan envueltos en un protocolo
  llamado SOAP (Simple Object Access Protcol) que
  hace el marshalling de los datos.
• Una de las principales características que tienen
  los servicios Web radica en su ubicuidad, ya que
  pueden ser accedidos desde cualquier sitio,
  utilizando inclusive cualquier otro protocolo de
  transporte SMTP, FTP, etc.

116
SOAP

• Indica cómo se deben codificar los mensajes que
  circularán entre las dos aplicaciones.
• SOAP define dos modelos de mensajes
• Un mensaje de solicitud.
• Un mensaje de respuesta.

117
Mensaje de solicitud

• lt?xml version"1.0" encoding"UTF-8" ?gt
• ltSOAP-ENVEnvelope xmlnsSOAP-ENVhttp//schemas.
  xmlsoap.org/soap/encoding/"gt
• ltSOAP-ENVHeadergt
• lt/SOAP-ENVHeadergt
• ltSOAP-ENVBodygt
• ltcatalogobuscaIsbn xmlnscatalogo"http//catal
  ogo.org/cat"gt
• ltcatalogoisbngt
• 84-4553-3334-2X
• lt/catalogoisbngt
• lt/catalogobuscaIsbngt
• lt/SOAP-ENVBodygt
• lt/SOAP-ENVEnvelopegt

118
Mensaje de respuesta

• lt?xml version"1.0" encoding"UTF-8" ?gt
• ltSOAP-ENVEnvelope xmlnsSOAP-ENVhttp//schemas.
  xmlsoap.org/soap/encoding/"gt
• ltSOAP-ENVHeadergt
• lt/SOAP-ENVHeadergt
• ltSOAP-ENVBodygt
• ltcatalogobuscaIsbnResponse xmlnscatalogo"http
  //catalogo.org/cat"gt
• ltcatalogotitulogt
• Catalogar materiales especiales
• lt/catalogotitulogt
• ltcatalogoautorgtMarta de Juaneslt/catalogoautorgt
  
• lt/catalogobuscaIsbnResponsegt
• lt/SOAP-ENVBodygt
• lt/SOAP-ENVEnvelopegt

119
Servicios Web

• Los servicios Web necesitan ser descritos (saber
  que parámetros reciben, devuelven) para poderlos
  utilizar en diversos clientes. Esta descripción
  se realiza a través de WSDL (Web Service
  Definition Language).
• Generalmente esas descripciones los clientes las
  conocen o bien, puede descubrirlas haciendo uso
  de UDDI (Universal Description, Discovery and
  Integration).

120
Servicios Web

• La UDDI no es otra cosa que un repositorio en
  donde se almacenan servicios Web que pueden ser
  invocados por diversos clientes.
• Muchas empresas ofrecen servicios Web como
  amazon, google, http//www.xmethods.com

121
Por qué utilizar Servicios Web?

• Múltiples tecnologías para hacer lo mismo
• No interoperables entre sí.
• Ligados a una plataforma.

DCOM
CORBA
Java RMI
RPC
IIOP
Protocolo
IIOP or JRMP
NDR
CDR
Formato del mensaje
Java Ser. Format
IDL
OMG IDL
Descripción
Java
Windows Registry
Naming Service
Descubrimiento
RMI Registry or JNDI
122
Pila de protocolos de SW

• Redefinición de toda la pila de comunicaciones
• Basado en tecnologías estándares

Servicio web
HTTP
Protocolo
SOAP
Formato del mensaje
WSDL
Descripción
UDDI
Descubrimiento
123
Ventajas de los Servicios Web

• Basados en estándares.
• Fácil integración.
• Desarrollo de actividades modularizadas.
• Independencia de plataforma.
• Puede ser usado tanto en clientes ligeros como
  pesados (clientes heterogéneos).

124
Desventajas de los Servicios Web

• Es que no son seguros...
• Es que no tienen estado...
• Es que no son transaccionales...
• Los servicios Web no hacen más que reinventar la
  rueda, pero esta vez usando XML.

125
Protocolos Servicios Web
Publicar, buscar servicios UDDI
Descripción de servicios WSDL
Interacción de servicios SOAP
Formato de datos universal XML
Comunicaciones ubicuas Internet
126
Creando Servicios Web

• Los servicios Web XML se exponen en el Framework
  .NET como archivos con una extensión .asmx.
• Los servicios se pueden consumir a través de
  páginas Web, clientes ligeros en una PC o
  clientes inteligentes en dispositivos móviles.

127
Hola mundo!!!

• lt_at_ WebService Language"C class"Helloweb" gt
• using System.Web.Services
• WebService (Namespace"http//sybex.com/webservic
  es")
• public class Helloweb WebService
• WebMethod
• public string HelloWebService()
• return "Holla Mundo!"

128
Otro servicio Web

• lt_at_ WebService Language"C" class"Fibonacci" gt
• using System.Web.Services
• public class Fibonacci WebService
• WebMethod
• public int GetSeqNumber(int fibIndex)
• if (fibIndex lt 2)
• return fibIndex
• int FibArray 0,1
• for (int i 1 ilt fibIndex i)
• FibArray1 FibArray0 FibArray1
• FibArray0 FibArray1 - FibArray0
• return FibArray1

129
Cliente del servicio

• using System
• class ClienteFecha
• public static void Main()
• ServicioFecha s new ServicioFecha()
• Console.WriteLine(Fecha actual 0,
  s.Fecha(false))
• Console.WriteLine(Fecha actual detallada
  0, s.Fecha(true))

130
Cliente de servicio Web Windows C .NET
131
Agregar referencia Web
132
Cliente de servicio Web en una Pocket PC
133
Página Web del Servicio HelloWorld
134
Respuesta del servicio Web par
135
Página Web del Servicio 1
136
WSDL del servicio Web 1
137
Ejecución del servicio Web suma
138
Ejecución del servicio Web par
139
Crear proxy del servicio Web
140
Servicios Web

• Ejemplo de archivo WSDL de amazon
• ltoperation nameAuthorSearchRequest/gt
• ltinput messagetypensAuthorSearchRequest/gt
• ltoutput messagetypensAuthorSearchResponsegt
• lt/operationgt .

141
Servicios Web

• Los tipos de datos se definen en otra parte
• ltxsdcomplexType nameAuthorRequestgt
• ltxsdallgt
• ltxsdelement nameautor typexsdstring/gt
  
• ltxsdelement namesort typexsdstring
  minOccurs0/gt
• lt/xsdallgt
• lt/xsdcomplexTypegt

142
Servicios Web

• Cuando se traduce a Java queda
• public class AuthorRequest
• public AuthorRequest(String author, String page,
  String mode, String tag, String sort, String
  locale, String word, String price)
• public String getAuthor()
• public String getPage() .

143
Servicios Web

• Para ejecutar el servicio se utiliza
• AmazonSearchPort puerto (AmazonSearchPort) (new
  AmazonSearchService_Impl().getAmazonSearchPort())
  
• AuthorRequest solicitud new AuthorRequest(name,
  1, books, , lite, , token, , , )
• ProductInfo res puerto.autorSearchRequest(solicit
  ud)

144
Servicios Web

• Se ocupa en las versiones viejas el JWSDP (Java
  Web Service Developer Pack)
• Se necesita un archivo config.xml
• lt?xml version1.0 encodingUTF-8?gt
• ltconfiguration xmlnshttp//java.sun.com/xml/ns/ja
  x-rpc/ri/configgt

145
Servicios Web

• ltwsdl locationhttp//soap.amazon.com/schemas3/
  AmazonWebServices.wsdl packageNamecom.amazon
  /gt
• lt/configurationgt
• wscompile import config.xml
• wscompile gen keep config.xml

146
Referencias

• Liberty, Jesse, Horvarth, David (200).
  Aprendiendo C para Linux en 21 Días. México,
  Prentice Hall.
• Márquez, Francisco (1994). Unix Programación
  Avanzada. Estados Unidos, Addison-Wesley.

147
Referencias

• Colouris, George, Dollimore, Jean, Kindberg, Tim
  (2001). Sistemas Distribuidos Conceptos y Diseño.
  3a. Edición. España, Pearson Addison-Wesley.
• Horstmann, Cay, Cornell, Gary (2006). Core Java 2
  Volumen II Carácterísticas Avanzadas. España,
  Perason Prentice Hall.

148
Referencias

• Deitel, Harvey, Deitel, Paul (2004). Java Como
  Programar. Quinta Edición. México, Pearson
  Prentice Hall.
• Márquez, Francisco (2004). UNIX Programación
  Avanzada. Tercera edición, México, Alfaomega
  Ra-Ma.

149
Referencias

• Froufe, Agustín, Jorge, Patricia (2004). J2ME
  Java 2 Micro Edition Manual de usuario y
  tutorial. México, Alfaomega.
• Firtman, Maximiliano (2004). Programación de
  celulares con Java. Argentina, MP Ediciones.
• Ruíz, Diego (2005). C La guía total del
  programador. Argentina, MP Ediciones.

150
Referencias

• Tanenbaum, Andrew (2002). Redes de computadoras.
  Cuarta edición. México, Pearson.
• Wigley, Andy, Wheelwright, Stephen (2003).
  Microsoft .NET Compact Framework. Estados Unidos,
  Microsoft Press.
• Ferreira, R. (2009), Material del Curso de
  Sistemas Distribuidos I, Instituto Tecnológico de
  Morelia, México.

151
Referencias

• Makofsky, Steve (2004). Pocket PC Network
  Programming. Estados Unidos, Addison-Wesley.
• Wall, Kurt (2000). Programación en Linux. Perú,
  Prentice Hall.
• Gregory, Kate (1999). Microsoft Visual C 6.
  España, Prentice-Hall Que.

152
Referencias

• Tanenbaum, Andrew (1996). Sistemas Operativos
  Distribuidos. México, Prentice Hall.
• Tanenbaum, Andrew, Van Steen, Maarten (2006).
  Distributed Systems Principles and Paradigms.
  Estados Unidos, Pearson Prentice Hall.
• Morales, F. (2009), Material del Curso de
  Sistemas Distribuidos II, ITM, México.

153
Referencias

• Vázquez, Adolfo (2002). XML. México, Alfaomega
  Ra-Ma.
• R. Pressman, Ingeniería del Software, 5ª.
  Edición, McGraw-Hiil, España, 2002.
• R. Johnsonbaug, Matemáticas Discretas, 4a.
  Edición, Prentice Hall, México, 1999, ISBN
  970-17-0253-0.

154
Referencias

• R. Orfali, et al., Cliente/servidor y objetos.
  Guía de supervivencia, tercera edición, Oxford
  University Press, México, 2002, ISBN
  970-613-597-9.
• W. Inmor, Developing Client/Sever Applications,
  Wiley, Estados Unidos, 2003, ISBN 0-471-56906-2.

155
Referencias

• D. Dewire, Client/Server Computing,
  McGraw-Hill, Estados Unidos, 1993, ISBN
  0-07-016732-X.
• W. Marion, Client/Server Strategies,
  McGraw-Hill, Estados Unidos, 1994, ISBN
  0-07-040539-5.

156
Referencias

• P. Renaud, Introduction to Client/Server
  Systems, Wiley, Estados Unidos, 1993, ISBN
  0-471-57773-1.
• P. Kimmel, Manual de UML. Guía de aprendizaje,
  McGraw-Hill, México, 2006, ISBN 0-07-226182-X.

157
Referencias

• J. Senn, Análisis y Diseño de Sistemas de
  Información, 2da. Edición, McGraw-Hill, México,
  1992, ISBN 968-422-991-7.
• A. Tanenbaum, et al., Sistemas Operativos.
  Diseño e implementación, 2da. Edición, Prentice
  Hall, México, 1998, ISBN 970-17-0165-8.

158
Preguntas, dudas y comentarios?