¿Sabes PHP?

Con esta frase me saludaba ayer un compañero de trabajo. Detrás de este saludo se escondía una oferta de trabajo, ganarme unos eurillos por unas horas por las tardes.
Mi respuesta fue contundente,No, el día que decida hacer horas extra después del trabajo será para mi propio cliente, empresa y beneficio.
¿Ha llegado el momento?

Modificación cabeceras SOAP

Con todas las herramientas disponibles actualmente es muy fácil desarrollar sistemas complejos. De lo que yo me suelo quejar siempre es de lo difícil que resulta cuando tienes que hacer algo que no está contemplado.

En este caso, invocar un Web Service añadiendo elementos a la cabecera SOAP.

Una vez investigado, no es tan difícil.

El primer paso es crear nuestro cliente con la herramienta que más te guste, y después escribir el código para ejecutar el cliente generado. Puede ser algo así:

MyWebServiceClient webService = new MyWebServiceClient();
MyWebServicePort port= webService.getMyWebServicePortTypeSoap();
port.myMethod ….

Hasta aquí, todo perfecto, pero nosotros necesitamos acceder al SOAPHeader, ¿cómo?

Modificamos el código anterior:

MyWebServiceClient webService = new MyWebServiceClient();
MyWebServicePort port= webService.getMyWebServicePortTypeSoap();
javax.xml.ws.Binding binding = ((BindingProvider) port).getBinding();
List handlerList = binding.getHandlerChain();
handlerList.add(new MyCustomHandler());
binding.setHandlerChain(handlerList);

port.myMethod ….

Lo que acabamos de hacer es incluir una clase nuestra, MyCustomHandler, en la cadena de procesamiento de la invocación, donde podremos manipular el mensaje antes de ser enviado.

Pero, ¿qué es MyCustomHandler?, una clase que implementa javax.xml.ws.handler.soap.SOAPHandler. El método principal es:

public boolean handleMessage(MessageContext context)

Que nos permite acceder a la invocación:

En versión reducida

SOAPMessageContext soapContext = (SOAPMessageContext)context;
 SOAPMessage message = soapContext.getMessage();
 SOAPEnvelope soapEnvelope = soapPart.getEnvelope();

 String targetNameSpace = ….
String serviceName = ….
QName serviceQName = new QName(targetNameSpace, serviceName);
SOAPHeaderElement headerElement = soapEnvelope.addHeader().addHeaderElement (serviceQName);
 headerElement.addChildElement(“eleme1″).setValue(“value1″);
 headerElement.addChildElement(“eleme2″).setValue(“value2″);

Y, milagrosamente, en tu mensaje SOAP, aparecerán  los nuevos valores añadidos a la cabecera.

PL/SQL = JVM

En una nueva incursión en lo desconocido, he vuelto a tropezar con mi odiado PL/SQL. Un lenguaje que supuso en su día un gran avance respecto a lo que se podía hacer dentro de una base de datos.

¿Cuáles han sido las innovaciones introducidas desde entonces ?, básicamente toda nueva funcionalidad pasa por ejecutar Java…

Esto me ha hecho pensar,¿ el futuro de Java pasa por olvidarse de sí mismo, por puro complejo, y ampliarse con otras herramienta/tecnologías más potentes?

Como hacer imposible lo sencillo

Estos días he estado trabajando con web services. Lo más obvio es utilizar las herramientas que tengas a tú alcance,en este caso las incorporadas en  Weblogic 10.3.

Hasta aquí todo perfecto,como debería ser.

Los problemas llegan cuando algo falla y quieres saber qué se esta haciendo debajo de la falda, riete tú de la Odisea de Ulises.

Ninguna solución encontrada en la documentación oficial me ha ayudado.

Señores, muy listo no soy,pero a veces hago bien las cosas.

No hagamos imposible hasta lo más sencillo.

WordPress for Android.

Buenas.
Este post es sólo una prueba de la App de WordPress.
¿Es necesario crear post desde el móvil ?

Código paella

Al contrario de lo que mucha gente puede creer, existe algo peor que el código spaghetti.

Desde aquí quiero reivindicar la capacidad, muy española, de hacer complicado lo sencillo, e imposible lo dificil. De este modo llegamos a nuevas cotas , convirtiendo el código spaghetti en código paella. Me explico.

El código paella es aquel que, una vez pasado el susto/cabreo/descojone incial, te vuelve a sorprender una y otra vez, llevándote a la conclusión de que sólo un perturbado mental, o mono de feria en su defecto, ha podido perpetrar semejante desfachatez.

El nombre de código paella no es algo elegido al azar. No ensalza simplemente ese gran plato de nuestra gastronomía, va un paso más allá. El spaghetti es un ente complicado, una linea curva de infinitos puntos, unidos de principio a fin, extenua seguir sus esquivas curvas y trampas, pero se ha conseguido.

El código paella va  un paso más allá. Es un ente complicado, de infinitos puntos, iconexos, sin orden ni concierto, salteado con ciertos manjares que nos intenta vender algo más de lo que realmente es, un simple y llano plato de arroz.

Javassist y el ataque de los Proxies

Continuando con los miniartículos sobre Javassist, ahora le toca el turno a los proxies.

Según la wikipedia, un proxy es un “patrón que se utiliza como intermediario para acceder a un objeto, permitiendo controlar el acceso a él”.

Javassists nos lo sigue poniendo fácil.
Sólo nos hacen falta un par de clases. Una de ellas es un interfaz, no es obligatorio ningún método,
aunque los puede incluir si los ves necesario, y la clase que proporciona la funcionalidad de proxy, que
ha de implementar el interfaz javassist.util.proxy.MethodHandler

Listado 1. Creación del proxy:

ProxyFactory factory = new ProxyFactory();
//indicamos que nuestro proxy hereda de MyClass
factory.setSuperclass( MyClass.class);
//implementa el interfaz MyProxyInterface
Class []interfaces = {MyProxyInterface.class};
factory.setInterfaces( interfaces );

Class cl = factory.createClass();
final MyProxyInterface proxy = ( MyProxyInterface ) cl.newInstance();
//fijamos la clase que interceptará las llamadas a los métodos
( ( ProxyObject ) proxy ).setHandler( new MyProxy() );
return (MyClass)proxy;

Listado 2. El proxy como tal.

public class MyProxy implements javassist.util.proxy.MethodHandler{

public Object invoke(Object target,
Method thisMethod,
Method proceed,
Object[] args)    throws Throwable {
//simplemente “interceptamos la llamada al método “toString()”
if (“toString”.equals(thisMethod.getName())){
return “Método interceptado Javassist ” + proceed.invoke(target, args);
}

return proceed.invoke(target, args);
}

Diferencias con JDK

1.-JDK te obliga a que tus classes implementen el interfaz utilizado para crear el proxy (MyProxyInterface),
en Javassists esto es transparente.

2.-La diferencia entre MethodHandler de Javassits y el InvocationHandler de la JDK puede parecer poca, pero muy importante.

Javassists
public Object invoke(Object self,
Method thisMethod,
Method proceed,
Object[] args)    throws Throwable

JDK
public Object invoke(Object proxy, Method thisMethod, Object[] args)    throws Throwable

El primer parámetro del método de Javassists es el objeto original sobre le que se invoca el método.
De este modo, para invocar al método original:

proceed.invoke(target, args);

Con la versión de la JDK, debemos guardar una referencia al objeto original en nuestro porxy, para poder realizar la invocación ya   que el primer parámetro de invoke es el propio proxy, no el objeto original.

3.-Javassists permite filtar los métodos que van a pasar por tu proxy.

proxyFactory.setFilter(new MethodFilter() {
public boolean isHandled(Method m) {
//ignoramos los métodos “final”
return !Modifie.isFinal(m.getModifiers());
}
});

¿Hay algo así en la JDK?

En definitiva, ¿con cuál te quedas?