WADL: The REST Answer to WSDL

WADL: The REST Answer to WSDL
Daniel Rubio, TechTarget

Web service developers were stirred a few months ago in the technical
media over the SOAP vs. REST debate, a now familiar theme which seems
to come up every so often and one discussion which will surely never
be completely settled given that each approach has its own technical
merits on which to stand. But appropriate as each technique is for
certain circumstances, until recently, there was one obvious part
missing in RESTful approaches that was ever present in SOAP: the
concept of a descriptor. Web Application Description Language (WADL)
aims to provide descriptors for RESTful services. For SOAP Web services,
descriptors based on Web Services Description Language (WSDL) form a
fundamental piece of their actual design, mainly on account of the
underlying complexity present in the actual service. In these scenarios,
a descriptor not only serves the purpose of formally describing all
the business logic it can fulfill, but it also aides in the creation
of helper classes (often called stubs) used to build service clients.
While the mechanics of using [WADL's] approach (automated code
generation) have caused criticism among early WADL analysts, stating
that its not only unnecessary, but that it will start REST down the
same path as SOAP and other distributed technologies like CORBA, which
depend on intermediate languages/descriptors, from a practical point
of view one cannot deny that using such a contract to obtain stub
classes is an even quicker way to get started with REST-based Web
services clients. While WADL is still in its early phases and tools
are currently available only for Java environments -- contrary to
WSDL, which is more ubiquitous -- WADL's appearance is a vote of
confidence in favor of the REST approach to building Web services
and will in all likelihood become a tight knit companion when
undertaking REST designs in the enterprise, just like WSDL has been
one for SOAP.

http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1265367,00.html
See also the WADL Project web site: https://wadl.dev.java.net/

De windows a Ubuntu

Muchas tareas a las que estamos acostumbrados en entornos windows se realizan de forma diferente en Ubuntu. Aquí va una pequeña lista para ayudar en el proceso de adaptación:

• para copiar y pegar texto. Al pulsar el botón central del ratón se pega aquello que se tenga seleccionado en otra ventana. No funciona exactamente igual que el ctrl-C ctrl-V de windows. De todos modos, Glipper es una opción si quieres tener un histórico de todo lo que vas copiando y luego quieres seleccionar qué pegar. Un buen asistente para tener acceso al histórico del portapapeles es Desktop Data Manager, que además permite gestionar descargas y capturas de pantalla
  
• con alt+F2 aparaece un lanzador de aplicaciones tipo launchy en windows
• la instalación de aplicaciones cambia radicalmente. Ver la pregunta "¿Cómo se instalan programas?" en esta FAQ
  
• Una lista de aplicaciones equivalentes a las que conoces en windows
  

Me paso a Ubuntu!

Por fin he dado el paso que llevaba tiempo rumiando y me he pasado a Ubuntu. Si bien es cierto que mantengo una pata en windows porque el portátil lo he dejado con XP...
Como los resultados son totalmente satisfactorios, resumo aquí los pasos que he seguido para configurar con Ubuntu mi ordenador de sobremesa, por si a alguien le son de utilidad:

• He salvado a un disco externo los datos que quería conservar
  
• Tras bajarlo de la web (http://www.ubuntu.com) y quemar un cd, instalo ubuntu 7.04 (feisty fawn) desde cd (pulsar F12 en arranque para elegirlo).
  
• Nada de particiones, he usado todo el disco duro y he dejado que el disco de instalación lo haga todo (partición swap, etc).
  
• He dejado inglés como idioma por defecto
  
• Juego un poco con system-preferences y system-administration para configurar red, resolución, etc
• Recupero los datos salvador en el disco duro externo y los copio dentro de mi directorio home
• mi tarjeta gráfica es una ATI radeon x600 y he instalado los drivers siguiendo: http://wiki.cchtml.com/index.php/Ubuntu_Feisty_Installation_Guide Parece ser que fglrx (el driver empleado) no soporta modo composite para ubuntu feisty, y beryl (compiz) lo necesita, por esa razón, de momento no funciona beryl. Quizá más adelante...
  
• Firefox es la plataforma donde se ejecuta el 80% de mi trabajo diario. Por eso instalo rápidamente mis addons imprescindibles: all-in-one sidebar, better gmail, clipmarks, delicious, diccionario español, euskera e inglés, downthemall, euskalbar, fireftp, faviconize, google desktop, google notebook, greasemonkey, gtranslate, loop, scribefire, session manager, menu editor, dragdropupload
  
• automatix (http://www.getautomatix.com/) sirve para instalar de forma sencilla aplicaciones que no están incluidas en los repositorios oficiales de Ubuntu (otra opción es http://easyubuntu.freecontrib.org/). Seguir los pasos de instalación de la web y listo. De entre el listado ofrecido por automatix, he seleccionado los siguientes paquetes:
• codecs: casi todos
• commercial sw: crossover office professional (para instalar windows office en ubuntu)
  
• file sharing: amule (como emule), deluge (cliente bit-torrent)
  
• media player: vlc, democracy (miro)
• office: adobe reader, google desktop, earth, picasa, openoffice clipart
• Utilizando Synaptic (system-admin) he instalado: Beryl, k3b (el nero de linux), amarok (el iTunes de linux), synergy (KM)
• Algunos codecs de video no incluidos por defecto en Ubuntu (por ser de uso restringido), los he instalado siguiendo estas instrucciones: https://help.ubuntu.com/community/RestrictedFormats/
  
• Red local.
  
• Red local windows xp-linux. Para compartir carpetas entre ordenadores con diferentes sistemas operativos he seguido (más o menos) ésto.
• Compartir acceso a internet. Tengo el ordenador de sobremesa conectado a la red con una tarjeta (eth0), y a un switch con una segunda tarjeta (eth1). Colgando de este switch tengo el portátil y un disco duro externo (más adelante impresora en red,...). Para configurar el acceso a internet desde el portátil (winXP):
• he asignado al portátil la ip 192.168.0.4 y puerta de enlace 192.168.0.1.
  
• he asignado la ip 192.168.0.1 a eth1 del pc sobremesa (ubuntu) usando ifconfig
• he usado este script: http://www.ubuntu-es.org/index.php?q=node/10513 
• 1.- Creamos un nuevo archivo que vamos a editar:
  
  
  $ sudo gedit /etc/init.d/iptablesconf
  
  2.- Ahora copiamos y pegamos el siguiente script en el editor de texto, sólo tenemos que modificar las 5 cadenas que están en negrita, donde pone eth1 y eth0 lo revisaremos para ver si efectivamente eth1 y eth0 son nuestros dispositivos de red conectados a internet y a la red local respectivamente.
  Lo siguiente es por si queremos redigir cierto puerto a un ordenador de la red (que llamaremos pc2) local para que pueda por ejemplo usar el emule o tener activo un servidor ftp, etc.. , se supone que en el ejemplo redirigiremos en puerto 7778 tcp y 7779 udp al pc con la ip 192.168.0.2
  Si no estamos interesados en redirigir puertos podemos borrar/comentar esas 3 variables.
  
  #### SCRIPT DE CONFIGURACION DE IPTABLES ####
  #!/bin/bash
  # Dispositivo de red de internet
  EXIF="eth1"
  # Dispositivo de red local
  INIF="eth0"
  # Puertos tcp que se desean redirigir (separados por espacios)
  puertosTCP="7778"
  # Puertos udp que se desean redirigir (separados por espacios)
  puertosUDP="7779"
  # ip a la que se le redirigen los puertos
  pc2="192.168.0.2"
  fail=0
  [ -f /etc/default/rcS ] && . /etc/default/rcS
  . /lib/lsb/init-functions
  log_begin_msg "Aplicando Reglas de Firewall..."
  ## Borrado de reglas anteriores
  iptables -F || fail=1
  iptables -X || fail=1
  iptables -Z || fail=1
  iptables -t nat -F || fail=1
  ## Establecemos politica por defecto
  iptables -P INPUT ACCEPT || fail=1
  iptables -P OUTPUT ACCEPT || fail=1
  iptables -P FORWARD DROP || fail=1
  iptables -t nat -P PREROUTING ACCEPT || fail=1
  iptables -t nat -P POSTROUTING ACCEPT || fail=1
  # Marcar paquetes salientes con su ip de origen
  iptables -t nat -A POSTROUTING -o $EXIF -j MASQUERADE || fail=1
  # Reenvio de IP
  echo 1 > /proc/sys/net/ipv4/ip_forward || fail=1
  # Aceptar paquetes para reenviar procedentes de la red local
  iptables -A FORWARD -i $INIF -o $EXIF -j ACCEPT || fail=1
  # Aceptar paquetes para reenviar procedentes de internet de conexiones ya establecidas
  iptables -A FORWARD -i $EXIF -o $INIF -m state --state RELATED,ESTABLISHED -j ACCEPT || fail=1
  ##Se redirigen los puertos configurados arriba
  for puerto in $puertosTCP
  do
  iptables -A FORWARD -i $EXIF -o $INIF -p tcp --dport $puerto -j ACCEPT || fail=1
  iptables -t nat -A PREROUTING -i $EXIF -p tcp --dport $puerto -j DNAT --to $pc2:$puerto || fail=1
  done
  for puerto in $puertosUDP
  do
  iptables -A FORWARD -i $EXIF -o $INIF -p udp --dport $puerto -j ACCEPT || fail=1
  iptables -t nat -A PREROUTING -i $EXIF -p udp --dport $puerto -j DNAT --to $pc2:$puerto || fail=1
  done
  # Se muestran los resultados
  log_end_msg $fail
  if [ $fail -eq 0 ]
  then
  log_success_msg "Verifique que lo que se aplica con: iptables -L -n."
  else
  log_warning_msg "Se ha producido un error al aplicar alguna de las reglas"
  fi
  #### FIN SCRIPT DE CONFIGURACION DE IPTABLES ####
  
  3.- Guardamos los cambios y le damos permisos de ejecucion:
  
  
  $ sudo chmod -v 755 /etc/init.d/iptablesconf
  
  el modo de «iptablesconf» cambia a 0755 (rwxr-xr-x)
  Lo ejecutamos:
  
  
  $ sudo /etc/init.d/iptablesconf
  
  
  si todo ha ido bien veremos este mensaje:
  * Aplicando Reglas de Firewall... [ ok ]
  * Verifique la reglas: iptables -L -n.
  Ahora utilizamos el siguiente comando para que script se cargue cada vez que arranque el sistema:
  
  
  $ sudo update-rc.d iptablesconf start 20 2 .
  
  
  #### ATENCIÓN AL PUNTO DEL FINAL, HAY QUE PONERLO ####
  
  
  
  

  Adding system startup for /etc/init.d/iptablesconf ...
  /etc/rc2.d/S20iptablesconf -> ../init.d/iptablesconf

  4.- Ahora podemos probar si todo funciona, nos vamos a los otros PCs y configuramos la red con ips estaticas (por ej 192.168.0.2 , 192.168.0.3 , etc..) y su correspondiente mascara de subred (255.255.255.0 para el ejemplo) utilizamos como puerta de enlace el pc que comparte la conexión (192.168.0.1 en el ejemplo) y como servidores dns utilizamos los mismos que tenga configurados el pc que da acceso a internet, que podemos verlos utilizando
  
  
  

  $ cat /etc/resolv.conf

  
  Ahora si todo ha ido bien debería funcionar internet en los otros PCs una vez configurados.
• Synergy (http://synergy2.sourceforge.net/) es un KM (KVM sin Video), es decir, permite usar el mismo teclado y ratón para 2 cpus diferentes, aunque tengan diferente sistema operativo. He configurado el cliente en windows poniendo la ip local del servidor ubuntu (192.168.0.1) y el servidor en ubuntu siguiendo las instrucciones de la web (editar un fichero de configuración, probarlo y luego añadirlo al arranque con system-admin-sessions). A
  
• Impresoras. Se ha instalado sin problemas una HP 1200 y he encontrado los drivers para una NRG en http://www.linux-foundation.org/en/OpenPrinting
  

A lo largo de este proceso he consultado, entre otros, los siguientes enlaces que recomiendo:
http://www.ubuntu-es.org
http://www.ubuntu-es.org/index.php?q=Preguntas_Frecuentes

La UPV/EHU ofrece documentación y soporte para la instalación de Ubuntu

Cursos Universidad Barcelona en SL

El Instituto de Formación Continua (IL3) de la Universidad de Barcelona (UB) se convertirá a partir del próximo mes de julio en un centro universitario pionero en cuanto al uso de las nuevos tecnologías, ya que impartirá cursos a través del mundo virtual de Second Life, que representa un nueva manera de relacionarse a través de la Red en la que cada vez más empresas e instituciones han decidido invertir.

Esta iniciativa pretende, gracias a un programa que ha sido bautizado como "Second Life y nuevas tendencias en aprendizaje", utilizar este espacio virtual en tres dimensiones como "herramienta de formación". Los alumnos podrán de esta manera asistir a clases virtuales, simulaciones de situaciones con riesgo para el ser humano o visualizar conceptos complejos mediante simulaciones en 3D, además de "conocer y explorar las posibilidades y funcionamiento del nuevo entorno".

Ha sido el departamento del IL3 Serious Games Lab, dedicado a adaptar metodologías de formación a las nuevas generaciones, el que ha desarrollado este curso. Para ello se ha basado en la idea de que las personas sólo recuerdan un 10% de lo que leen, mientras que este porcentaje llega al 90% de lo que hacen. 

REST vs. SOAP war is over

REST vs. WS-*: War is Over (If You Want It)
David Chappell, Blog

To anybody who's paying attention and who's not a hopeless partisan,
the war between REST and WS-* is over. The war ended in a truce rather
than crushing victory for one side -- it's Korea, not World War II.
The now-obvious truth is that both technologies have value, and both
will be used going forward. If you doubt this, take a look at
Microsoft's forthcoming support for creating RESTful applications in
the next release of Windows Communication Foundation (WCF). The official
Java world is also on board, with the impending creation of JAX-RS.
Since both worlds also have good support for the WS-* approach,
developers will be able to choose the approach that's best for a
particular application. Two big questions remain. The first is, What
exactly is REST? By far the best and clearest definition I've seen is
provided by RESTful Web Services, a wonderful book by Leonard Richardson
and Sam Ruby. If everybody can buy into the measures of RESTfulness
this book provides, we can all avoid lots of future arguments. As a
side benefit, it will let most of us get by without reading Roy
Fielding's PhD thesis, the canonical text on REST. The second question
is, When should each approach be used? Whatever partisans may claim,
neither technology is right for every situation. While hammering out
a true understanding of this will likely take some time, the basic
outlines are clear. A RESTful approach is a natural for data-oriented
applications that focus on create/read/update/delete scenarios. Lots
and lots of apps fit this model, especially on the public Internet. A
solution based on WS-* makes more sense for service/method-oriented
applications, especially those that need more advanced behaviors such
as transactions and more-than-basic security.

http://www.davidchappell.com/blog/2007/06/rest-vs-ws-war-is-over-if-you-want-it.html
See also JAX-RS, the Java API for RESTful Web Services: http://jcp.org/en/jsr/detail?id=311

XML Proc: XML pipeline language

New Working Draft for XProc: An XML Pipeline Language
Norman Walsh and Alex Milowski (eds), W3C Technical Report

W3C Staff announced the publication of a new Working Draft for the
XML Pipeline specification, produced by members of the W3C XML
Processing Model Working Group. "XProc: An XML Pipeline Language"
describes the syntax and semantics of a language for describing
operations to be performed on XML documents. An XML Pipeline specifies
a sequence of operations to be performed on a collection of XML input
documents. Pipelines take zero or more XML documents as their input
and produce zero or more XML documents as their output. A pipeline
consists of steps. Like pipelines, steps take zero or more XML documents
as their input and produce zero or more XML documents as their output.
The inputs to a step come from the web, from the pipeline document,
from the inputs to the pipeline itself, or from the outputs of other
steps in the pipeline. The outputs from a step are consumed by other
steps, are outputs of the pipeline as a whole, or are discarded. There
are two kinds of steps: atomic steps and compound steps. Atomic steps
carry out single operations and have no substructure as far as the
pipeline is concerned, whereas compound steps include a subpipeline of
steps within themselves.  The XProc specification defines a standard
library of steps in Appendix A (Standard Step Library). Pipeline
implementations may support additional types of steps as well. Norm
Walsh reports in the associated Blog: "... think our latest draft,
published today, is getting pretty close. This draft resolves (finally,
I hope) the question of how to deal with parameters. I don't think
we've quite dotted the I's and crossed the T's on how the new parameter
story interfaces with the outside world, but I'm confident that we'll
get there. We've also introduced a new defaulting story; I expect this
will generate feedback, both positive and negative... I hope the next
draft is our Last Call draft and I hope it comes out in July [2007]..."

http://www.w3.org/TR/2007/WD-xproc-20070706/
See also Norm Walsh's blog: http://norman.walsh.name/2007/07/06/xproc