Java Reflection API

In programming terms, reflection is a feature that allows you to see the internal composition of a program—everything from its variables to its method declarations. As its name indicates, the Java Reflection API enables this functionality in Java.

The Java Reflection API provides insight into the classes, interfaces, and objects in a given Java Virtual Machine (JVM). Developers commonly use the API to accomplish the following tasks, which explains why it is so often used to develop tools such as debuggers and Integrated Development Environments (IDEs):

  • Determine the class of an object.
  • Get information about a class’s modifiers, fields, methods, constructors, etc.
  • Get information about an interface’s constants and method declarations.
  • Create an instance of a class whose name is not known until runtime, but rather available at design time or provided as a runtime parameter.
  • Get and set the value of an object’s field, even if the field name is unknown to your program until runtime.
  • Invoke a method on an object, even if the method is not known until runtime.

One tangible use of reflection is in JavaBeans, where you can manipulate software components visually via a builder tool. The tool uses reflection to obtain the properties of Java components (classes) as they are dynamically loaded.

http://www.developer.com/java/article.php/3819961

Etiquetas: ,

Anuncios

My developerWorks: 6 ways to build your technical skills and your professional network

How to connect and collaborate with the My developerWorks community

Summary:
  With the debut of My developerWorks®, two little characters (“My”) make a big difference: They take developerWorks from “just” the place where you find award-winning how-to content for developers and IT professionals to the place where you and your peers congregate to connect, share, and collaborate. Great content is just the beginning, and now it’s time for you to take the next step: Create your professional profile and your custom home page on My developerWorks. Then find and connect with like-minded peers, start tagging and bookmarking, and invite your peers into your My developerWorks network to share expertise and build groups for further interaction and collaboration.

My developerWorks community

Etiquetas: ,

Java Reflection

What’s Going On in There? Java Reflection for Program Insight

By Sridhar M S

Go to page: 1  2 3 Next

In programming terms, reflection is a feature that allows you to see the internal composition of a program—everything from its variables to its method declarations. As its name indicates, the Java Reflection API enables this functionality in Java.

The Java Reflection API provides insight into the classes, interfaces, and objects in a given Java Virtual Machine (JVM). Developers commonly use the API to accomplish the following tasks, which explains why it is so often used to develop tools such as debuggers and Integrated Development Environments (IDEs):

  • Determine the class of an object.
  • Get information about a class’s modifiers, fields, methods, constructors, etc.
  • Get information about an interface’s constants and method declarations.
  • Create an instance of a class whose name is not known until runtime, but rather available at design time or provided as a runtime parameter.
  • Get and set the value of an object’s field, even if the field name is unknown to your program until runtime.
  • Invoke a method on an object, even if the method is not known until runtime.

http://www.developer.com/java/article.php/3819961

Etiquetas: , ,

JBoss Tools 3 Developer Guide

JBoss Tools 3 Developer Guide

By Anghel Leonard

Go to page: 1  2 3 4 5 Next

JBoss Tools consist of the best Java frameworks and technologies placed together under the same “roof.” Discovering JBoss Tools is like exploring a cave; at first everything seems unknown and complicated, but once you become familiar with the main features of the tools, you will start to feel at home.

Throughout this article, you will follow the “learning by example” technique, and you will develop a completely functional JSF application that will represent a JSF registration form as you can see in Figure 1. These kinds of forms can be seen on many sites, so it will be very useful to know how to develop them with JSF Tools.

http://www.developer.com/java/ent/article.php/3823376

Etiquetas: , , ,

Diferecias y Similitudes entre Java y C++

Si no eres programador C++, puedes saltarte esta sección, porque no te dirá nada; al contrario, probablemente contribuya a confundirte más que a aclararte cosas, al introducir conceptos muy familiares que entiende muy bien el que conoce C++, pero que a un profano lo dejan indiferente. Además, muchas de las cosas que se citan no se utilizan en Java, sino que se enumeran para que los programadores que aterrizan en Java desde C++ las tengan en cuenta. Por todo esto, el embrollo que se puede formar un profano puede ser mayúsculo.

Si conoces C++, esta sección te servirá para tener como referencia respecto a los cambios que representa Java sobre C++, y donde debes cambiar el concepto de las cosas. Fundamentalmente, porque hay características que siguen utilizándose en Java heredadas de C++, pero el sentido con que se aplican es ligeramente diferente, lo que muchas veces lleva a los programadores C++ que atacan Java, a confusiones innecesarias. Por ello, aunque un poco denso y latoso, es una sección de lectura obligada para que tengas en cuenta las cosas que debes alterar en tu forma de concebir la programación cuando ataques proyectos en Java.

Entramos en materia. Java no soporta typedefs, defines o comandos de preprocesador. Al no existir un preprocesador, no está prevista la inclusión de ficheros de cabecera, tampoco tiene cabida el concepto de macro o constante. Sin embargo, sí se permite cierto uso de constantes enumeradas a través de la utilización de la palabra clave final. Java tampoco soporta enums, aunque soporte constantes enumeradas, como acabo de decir.

Java soporta clases, pero no soporta estructuras o uniones.

Todas las aplicaciones C++ necesitan una función de entrada llamada main() y puede haber multitud de otras funciones, tanto funciones miembros de una clase como funciones independientes. En Java no hay funciones independientes, absolutamente todas las funciones han de ser miembros de alguna clase (métodos). Funciones globales y datos globales en Java no están permitidos.

En C++ se pueden crear árboles de herencia de clases independientes unos de otros. En Java esto no es posible, en última instancia hay una clase Object, de la que hereda todo lo que el programador cree.

Todas las funciones o definiciones de métodos en Java deben estar contenidos dentro de la definición de la clase. Para un programador C++ puede parecerle que esto es semejante a las funciones inline, pero no es así. Java no permite, al menos directamente, que el programador pueda declarar funciones inline.

Tanto Java como C++ soportan funciones o métodos (estáticos) de clases, que pueden ser invocados sin necesidad de tener que instanciar ningún objeto de la clase.

En Java se introduce el concepto de interface, que no existe en C++. Una interface se utiliza para crear una clase base abstracta que contenga solamente las constantes y las declaraciones de los métodos de la clase. No se permite que haya variables miembro ni definiciones de métodos. Además, en Java también se pueden crear verdaderas clases abstractas.

Java no soporta herencia múltiple, aunque se pueden utilizar las posibilidades que ofrece el uso de interfaces para emplear las ventajas que ofrece la herencia múltiple, evitando los inconvenientes que se derivan de su uso. La herencia simple es similar en Java y en C++, aunque la forma en que se implementa es bastante diferente, especialmente en lo que respecta a la utilización de los constructores en la cadena de herencia.

Java no soporta la sentencia goto, aunque sea una palabra reservada. Sin embargo, soporta las sentencias break y continue con etiquetas, que no están soportadas por C++. Bajo ciertas circunstancias, estas sentencias etiquetadas se pueden utilizar como un goto encubierto.

Java no soporta la sobrecarga de operadores, aunque la utilice internamente, pero no está disponible para el programador. Tampoco soporta la conversión automática de tipos, excepto en las conversiones seguras.

Al contrario que C++, Java dispone de un tipo String y los objetos de este tipo no pueden modificarse. La cadenas que se encuentren definidas entre comillas dobles son convertidas automáticamente a objetos String. Java también dispone del tipo StringBuffer, cuyos objetos sí se pueden modificar, y además se proporcionan una serie de métodos para permitir la manipulación de cadenas de este tipo.

Al contrario que C++, Java trata a los arrays como objetos reales. Disponen de un miembro, length, que indica la longitud del array. Se genera una excepción cuando se intenta sobrepasar el límite indicado por esta longitud. Todos los arrays son instanciados en memoria dinámica y se permite la asignación de un array a otro; sin embargo, cuando se realiza una asignación, simplemente tenemos dos referencias a un mismo array, no hay dos copias del array, por lo que si se altera un elemento de un array, también se alterará en el otro. A diferencia de C++, el tener dos “punteros” o referencias a un mismo objeto en memoria dinámica no representa necesariamente un problema (aunque sí puede provocar resultados imprevistos). En Java, la memoria dinámica es liberada automáticamente, pero esta liberación no se lleva a cabo hasta que todas las referencias a esa memoria son NULL o dejan de existir. Por tanto, a diferencia de C++, una zona de memoria dinámica nunca puede ser inválida mientras esté siendo referenciada por alguna variable.

Java no soporta punteros, al menos en el sentido que atribuye C++, es decir, no permite modificar el contenido de una zona de memoria apuntada por un puntero, o realizar operaciones aritméticas con punteros. La mayor necesidad de uso de punteros deriva de la utilización de cadenas y arrays, y esto se evita al ser objetos de primera clase en Java. Por ejemplo, la declaración imprescindible en C++, char *puntero, para referenciar al primer elemento de una cadena no se necesita en Java, al ser la cadena un objeto String.

La definición de clase es semejante en Java y C++, aunque en Java no es necesario el punto y coma (;) final. El operador de ámbito (::) necesario en C++ no se usa en Java, sino que se utiliza el punto (.) para construir referencias. Y, como no hay soporte de punteros, el operador flecha (->) tampoco está soportado en Java. En C++, las funciones y datos miembros se invocan utilizando el nombre de la clase y el nombre del miembro estático conectados por el operador de ámbito. En Java, se utiliza el punto (.) para conseguir el mismo propósito.

Al igual que C++, Java dispone de tipos primitivos como int, float, etc. Pero, al contrario de C++, los tamaños de estos tipos son iguales independientemente de la plataforma en que se estén utilizando. No hay tipos sin signo en Java, y la comprobación de tipos es mucho más restrictiva en Java que en C++. Java dispone de un tipo boolean verdadero.

Las expresiones condicionales en Java se evalúan a booleano en vez de a entero como en el caso de C++. Es decir, en Java no se permiten sentencias del tipo if( x+y ), porque la expresión que va dentro del paréntesis no se evalúa a booleano.

El tipo char en C++ es un tipo de 8 bits que mapea el conjunto completo de caracteres ASCII. En Java, el tipo char es de 16 bits y utiliza el set de caracteres Unicode (los caracteres del 0 al 127 del set Unicode, coinciden con el set ASCII).

Al contrario que en C++, el operador desplazamiento (>>) es un operador con signo, insertando el bit de signo en la posición vacía. Por ello, Java incorpora el operador >>>, que inserta ceros en las posiciones que van quedando vacías tras el desplazamiento.

C++ permite la instanciación de variables u objetos de cualquier tipo en tiempo de compilación sobre memoria estática o, en tiempo de ejecución, sobre memoria dinámica. Sin embargo, Java requiere que todas las variables de tipos primitivos sean instanciadas en tiempo de compilación, y todos los objetos sean instanciados en memoria dinámica en tiempo de ejecución. Java proporciona clases de envoltura para todos los tipos primitivos, excepto para byte y short, que permiten que estos tipos primitivos puedan ser instanciados en memoria dinámica como objetos en tiempo de ejecución, si fuese necesario.

C++ requiere que las clases y funciones estén declaradas antes de utilizarlas por primera vez. Esto no es necesario en Java. C++ también requiere que los miembros estáticos de una clase se redeclaren fuera de la clase. Esto tampoco es necesario en Java.

En C++, si no se indican valores de inicialización para las variables de tipos primitivos, pueden contener basura. Aunque las variables locales de tipos primitivos se pueden inicializar en la declaración, los datos miembros de tipo primitivo de una clase no se pueden inicializar en la definición de la clase. En Java, se pueden inicializar estos datos miembros de tipo primitivo en la declaración de la clase. También se pueden inicializar en el constructor. Si la inicialización no se realiza explícitamente, o falla por lo que sea, los datos son inicializados a cero (o su equivalente) automáticamente.

Al igual que ocurre en C++, Java también soporta constructores que pueden ser sobrecargados. Y, del mismo modo que sucede en C++, si no se proporciona un constructor explícitamente, el sistema proporciona un constructor por defecto.

En Java todos los objetos se pasar por referencia, eliminando la necesidad del constructor copia utilizado en C++.

No hay destructores en Java. La memoria que no se utiliza es devuelta al Sistema a través del reciclador de memoria, que se ejecuta en un thread diferente al del programa principal. Esta es una de las diferencias extremadamente importantes entre C++ y Java.

Como C++, Java también soporta la sobrecarga de funciones. Sin embargo, el uso de argumentos por defecto no está soportado en Java. Al contrario que C++, Java no soporta templates, por lo que no existen funciones o clases genéricas.

El multithreading, o multihilo, es algo característico de Java, que se proporciona por defecto.

Aunque Java utiliza las mismas palabras clave que C++ para indicar el control de acceso: private, public y protected, la interpretación es significativamente diferente entre C++ y Java.

La implementación del manejo de excepciones en Java es más completo y bastante diferente al empleado en C++.

Al contrario que C++, Java no soporta la sobrecarga de operadores. No obstante, los operadores + y += son sobrecargados automáticamente para concatenar cadenas, o para convertir otros tipos a cadenas.

Como en C++, las aplicaciones Java pueden hacer llamadas a funciones escritas en otros lenguajes, llamadas métodos nativos. No obstante, los applets no pueden hacer llamadas a métodos nativos.

A diferencia de C++, Java dispone de un sistema interno de generación de documentación. Si se utilizan comentarios escritos de determinada forma, se puede utilizar la herramienta javadoc para generar la documentación de la aplicación Java, e incluso se pueden programar doclets para generar tipos específicos de documentación.

Etiquetas: ,

Java y Flex

Java and Flex Integration Bible

Open in new window

# Paperback: 552 pages
# Publisher: Wiley (March 3, 2009)
# Language: English
# ISBN-10: 0470400749
# ISBN-13: 978-0470400746

Etiquetas: ,

Web services

INTRODUCCIÓN A LOS SERVICIOS WEB
Por azuluaga

En este artículo veremos qué es un servicio Web, por qué se destacan entre otras tecnologías y las características de su funcionamiento.
Antes de empezar de lleno con el tema, es necesario que veamos algunos conceptos un tanto simples para algunos, pero definitivamente necesarios.
Esos temas se refieren a RPC, sistemas distribuidos, XML, entre otros. Si consideras que ya conoces sobre el tema, puedes pasarlo por alto y empezar en por qué los servicios web.

1.LOS SISTEMAS DISTRIBUIDOS
Más o menos generalizando un sistema distribuido es aquel donde existen varios computadores cada uno con su procesador independiente de los demás, los cuales se comunican utilizando mensajes por la red.
En palabras más claras, un sistema distribuido nos permite tener varias máquinas para ejecutar el mismo proceso o ejecutar varios con el mismo fin y así entregar resultados mucho más rápido o permitir a una máquina concentrarse en las peticiones y dejar a otras el “trabajo pesado”. Pero esta definición puede ser bastante incompleta. Si se quiere saber más sobre sistemas distribuidos es mejor buscar en textos especializados o en la red. Quizá me anime y haga un artículo completo sobre el tema.

Veamos algunas de las características de un sistema distribuido:
Existen por lo menos dos computadores con procesadores independientes capaces de realizar procesos enfocados hacia el mismo objetivo.
La comunicación se hace por medio de una red (puede ser privada o por Internet) utilizando protocolos estándar o propietarios (claro, funcionando bajo los propios protocolos de la red).
Un sistema distribuido puede utilizar diferentes programas creados en el mismo o en diferentes lenguajes (es ahí donde nos detendremos).
La comunicación entre las máquinas puede ser sincrónica o asíncrona.
Los sistemas distribuidos se pueden usar para aprovechar el procesamiento en paralelo o las utilidades desarrolladas en diferentes lenguajes, plataformas, sistemas operativos, etc.
La idea es que no se necesita una máquina que funcione como servidor, sino que se puedan comunicar entre ellas sin tener que pasar por un sitio común.
Bueno, espero que quede más o menos claro lo que es un sistema distribuido; sino, no te preocupes que apenas estamos comenzando y esto es tan solo un acercamiento.

Existen muchas formas de hacer computación distribuida, muchas empresas tienen sus propias implementaciones, también hay grupos que se han preocupado por crear un modelo estándar que permita la comunicación entre esas diferentes tecnologías. Veamos algunas de ellas.

DCOM (Distributed Component Object Model)
La tecnología de Microsoft para comunicar aplicaciones hechas en sus lenguajes, tiene la gran ventaja de los productos Microsoft: es supremamente sencillo de usar, el programador no necesita profundizar en temas de protocolos para utilizarlo y el equipo Microsoft se esforzó por hacer transparente al cliente la ubicación de los objetos con que trabaja.

RMI (Remote Method Invocation)
Esta es la tecnología que utiliza java para comunicar aplicaciones entre sí. Es una tecnología de SUN Microsystems para invocar métodos y transportar objetos java.
A diferencia de otras tecnologías, RMI solo sirve para comunicar aplicaciones hechas en java. Esto hace que sea mucho más fácil de usar y que los programadores puedan crear sus propios protocolos con todas las ventajas que esto conlleva.
Su desventaja obviamente es que las aplicaciones hechas en otros lenguajes deberán traducirse a Java para que se puedan comunicar.

CORBA (Common Object Request Broker Architecture)
Esta es una propuesta hecha por un gran consorcio de importantes instituciones llamado OMG (Object Management Group). Es un intento por crear una tecnología mucho más abierta que DCOM y RMI, mediante la cual se puedan comunicar programas hechos en diferentes lenguajes (lo de diferentes sistemas operativos está resuelto con los protocolos de red).
CORBA es un avance con respecto a RMI y DCOM puesto que permite comunicar diferentes lenguajes usando el protocolo estándar IIOP (Internet Inter-ORB Protocol) también definido por OMG.
Se puede decir que CORBA es tan abierto como los servicios web pero no puedo ni debo afirmar lo uno ni lo otro, solamente diré que son dos tecnologías diferentes y quizá más adelante me anime a dar una apreciación subjetiva del panorama. Es necesario recordar dos características de CORBA que nos serán muy importantes a la hora de compararla con un servicio Web (claro hay muchas más, pero por ahora utilizaré estas dos):
1.CORBA utiliza el protocolo IIOP, especificado también por OMG.
2.Los datos son transportados en formato binario.

2. ¿POR QUÉ LOS SERVICIOS WEB?

Hasta ahora vimos las tres tecnologías que habían dominado la computación distribuida (siguen siendo muy utilizadas pero se ve una clara tendencia hacia los servicios Web).
DCOM y RMI son rápidos y permiten modelar estructuras complejas para ser transportadas, pero son tecnologías propietarias; por tanto no es posible mezclar DCOM y RMI a menos que realicemos implementaciones propias, por ejemplo sockets; pero esta no es una muy buena idea y habría que hacer una implementación para cada caso, dependiendo del lenguaje, protocolo, etc.
CORBA obviamente permite la comunicación entre muchos lenguajes siempre y cuando estos implementen el protocolo IIOP y permitan crear un IDL (Interface Definition Languaje, el lenguaje para definir interfaces CORBA) compatible con CORBA. De hecho hasta hace muy poco se consideraba el estándar para comunicaciones entre diferentes lenguajes.
Pero CORBA presenta dos grandes inconvenientes:
a)El protocolo IIOP no necesariamente está soportado por una red. A veces es necesario hacer configuraciones especiales a los cortafuegos para que permita usarlo, lo cual hace que no todos los lenguajes o redes puedan transportar objetos con este protocolo.
b)Dado que los datos son transportados en formato binario, es necesario que los lenguajes hagan implementaciones especiales para leer estos datos y convertirlos a sus propios tipos.

3.QUE SON Y COMO FUNCIONAN LOS SERVICIOS WEB
a)¿Qué son?
Los servicios Web nacen como una opción para la llamada de métodos remotos, esta vez superando las dos principales inconvenientes de CORBA: el protocolo y el formato de datos.
Para superar la incompatibilidad de protocolos, los servicios web son accedidos generalmente sobre el omnipresente http, el mismo protocolo para navegar a través de las páginas Web; como es obvio, este protocolo es comprendido por cualquier PC que pueda conectarse a Internet y tiene la ventaja de ser un protocolo sin estado, esto significa que no es necesario mantener una conexión permanente entre el cliente y el servidor. Dado que http es el protocolo más común para navegar en Internet, la gran mayoría de los lenguajes tiene implementaciones para soportarlo. Cabe anotar que http no es el único protocolo bajo el cual funcionan los servicios Web, si bien es el más utilizado, no hay motivos para no utilizarlos en un escenario diferente.
Otro de lo obstáculos que presenta CORBA es el formato de datos, pues aunque el trabajar con datos binarios permite modelar estructuras complejas y es rápido, exige un esfuerzo adicional al lenguaje o al programador para realizar una implementación de IIOP que pueda interpretar estos datos. Esta situación se solucionó utilizando el también omnipresente (especialmente en estos días de programación Web) lenguaje XML que puede utilizar caracteres (US-ASCCI, UTF-8 y UTF-16) comprensibles por cualquier editor de texto, o al menos por la gran mayoría.
Nos podríamos preguntar por que usar XML (que no tiene un tratamiento tan simple) en vez de texto normal quizá separado por comas o algo similar. Pues bien, la complejidad de XML fue lo que inclinó a muchas empresas a usarlo, dada su capacidad para modelar complejas estructuras de datos. Un archivo plano está bastante bien para enviar una cantidad de datos con el mismo significado como podría ser los precios de una serie de libros; pero no estaría tan bien para transportar datos acerca de varios libros, así como el autor, el género, precio, entre otros. ¿Y qué tal si tiene varios autores? Ya ves la utilidad del XML.

b) ¿Cómo funcionan?
Para utilizar un servicio web es necesario conocer su ubicación, que debe estár descrita por la dirección IP o dominio y el puerto por que está habilitado. A partir de esta información, podemos conocer los parámetros de entrada, salida y el nombre de los procedimientos que se ofrecen.

Ubicar el servicio: Conseguir su descripcion.
Si utilizamos servicios web desarrollados dentro de nuestra organización, pues bastará con pedirle la información a la persona que lo ha creado o quizá exista un directorio donde se almacenen todos los datos acerca de los servicios a los que tenemos acceso.
Existen también muchos servicios Web disponibles al público, los cuales tienen sus datos publicados generalmente en la página web de la organización o persona que lo ofrece. Por ejemplo google (www.google.com) ofrece servicios web que reciben un criterio de búsqueda y devuelven una lista de urls que cumplen con ese criterio, similar a como funciona su página web; amazon.com (www.amazon.com) nos permite conocer el precio de un libro dado su código. Así como estos existen muchos más por el estilo, puedes encontrar una lista interesante de servicios en la página http://www.xmethods.com.
Por último existe un servicio similar a las consultas en directorios: UDDI (Universal Description, Discovery, and Integration), el cuál es un estándar para describir y localizar los servicios web que provee una compañía o persona. UDDI es definido por varias empresas (entre ellas Sun Microsystems, Microsoft e IBM) en donde especifican esquemas para inscribir servicios web. Para usar UDDI es necesario publicar servicios web usando el protocolo SOAP que veremos más adelante, de este modo se pueden realizar búsquedas por palabras clave, empresas, funcionalidad e incluso existen directorios de páginas blancas, amarillas y verdes. Cualquier organización o persona puede registrarse y ofrecer sus servicios mediante UDDI (www.uddi.org), de esta manera cuando realizamos una búsqueda obtenemos los datos para invocar el servicio; estos datos son el nombre del procedimiento y los parámetros tanto de entrada como de salida.
Podemos también realizar una implementación interna de UDDI para nuestra organización, recordemos que es tan solo un estándar e incluso ellos mismo (uddi.org) nos proveen soluciones para realizarlo (uddi.org/solutions.html).

Leer la descripción del servicio: Ver su ubicación, nombre y parámetros.
Un servicio web se ubica por medio de una dirección IP (su nombre) y un puerto, por ejemplo: “www.miservicio.org:8080/servicio1” y para usarlo necesitamos también los nombres con los que debemos llamar los procedimientos y los parámetros que debemos enviar y vamos a recibir.
En general los servicios web trabajan sobre dos formatos: SOAP (Simple Object Access Protocol) y XML-RPC (XML – Remote Procedure Call), ambos basados en XML y diseñados específicamente para describir servicios web. XML-RPC es más sencillo de usar y SOAP más potente, por ejemplo con SOAP se puede elegir el tipo de caracteres que se van a transportar lo que puede resultar importante cuando se transmitan palabras con tilde o la eñe. Tanto SOAP como XML-RPC son definiciones del consorcio W3C (www.w3c.org).
Actualmente el protocolo más utilizado es SOAP, por su acogida entre las grandes empresas y su minuciosidad para transportar los datos; los servicios que ofrecen google y amazon son basados completamente en este protocolo, los lenguajes orientados a la web tienen implementaciones propias para “codificar” y “decodificar” documentos SOAP. Así que como veráz, no tendremos que matarnos creando utilidades para leer estos archivos ni realizar tareas complejas para invocar los servicios, por tanto es el protocolo al que nos referiremos de aquí en adelante.
El consorcio w3c define también un archivo llamado WSDL (Web Service Description Languaje) el cual nos describe el servicio que se ofrece, en un formato XML fácilmente comprensible por el programador, que además permite conocer en una única estructura la dirección del servicio, los nombres de los métodos, los parámetros de entrada/salida y la descripción de los tipos de datos que pueden ser primitivos (int, float, string), complejos (al estilo java beans) o listas (al estilo Collection). Conciendo todos estos valores podemos crear el cliente del servicio y definir los tipos de datos necesarios para almacenar los valores de entrada y/o salida.

Invocar el servicio y recibir los resultados.
Para invocar el servicio no es necesario programar utilidades para XML, HTTP y viajes por la red; puedes hacerlo si quieres (por curiosidad está bien), pero la verdad es que existen implentaciones completas para publicar e invocar servicios web. Con uno de estos paquetes es sólo cuestion de datos, incluso ni siquiera es necesario crear los tipos complejos por que las utilidades tienen la capacidad de almacenar estas estructuras en clases propias y ocultan toda la complejidad del parseo (conversión de los datos XML), el uso de protocolos y la comunicación remota.
SOAP define una estructura para el viaje de los datos en formato XML, esta es llamada mensaje SOAP y consta de dos partes:
El SOAP Envelope (Algo así como el sobre), define la estructura general de un mensaje SOAP, las partes del documento que nos deben interesar y además el protocolo de enlace (como ya dije, generalmente http).
La estructura particular del mensaje.
Posee un encabezado opcional (header) donde pueden viajar los datos que no tienen que ver con el negocio en sí, sino más bien estructuras adicionales de control o datos para la autenticación, etc. Cosas que necesitemos usar, pero no hacen parte de los datos solicitados.
El cuerpo del mensaje. Es la parte obligatoria y aquí van los datos que hemos solicitado en una estructura definida, con tipos de datos como los mencionados anteriormente; es la parte más importante del mensaje y son nuestro objetivo final al invocar el servicio.

Para finalizar
Ahora que tenemos los datos es cuestión de la lógica de nuestro negocio lo que debamos hacer con ellos, que puede ir desde una simple presentación en consola o realizar un proceso para invocar otro servicio web y finalmente tomar una decisión o alegrarnos por que la prueba funcionó.
Espero haber dejado claro el concepto de servicio web. No espero que tengas mucha idea de la parte técnica (para ello puedes dirigirte a nuestro laboratorio), sino que sepas bajo que escenarios sirve, cuando es mejor usar otras tecnologías, el por que de su estructura (XML – HTTP) y el proceso que se sigue para descubrirlo y ejecutarlo. Quizá en artículos posteriores analizemos con detalle Mensajes SOAP o archivos WSDL, pero esto es todo por ahora.

REFERENCIAS
CORBA vs Web Services
UDDI
Artículo completísimo (Quizá demasiado)
webservices.org
xmethods.com
w3c


Java Colombia. Programación con J2EE, Struts, JSP, EJB a la manera Colombiana

Etiquetas: , , ,