WSO2 BRS y WSO2 Developer Studio para el desarrollo de servicios de reglas de negocio

Los desarrolladores de software siempre estamos buscando como volver más ágiles nuestras aplicaciones, ya sea bien por un deseo propio o por los constantes cambios en el negocio. Tener la facilidad de modificar las reglas del negocio sin tener que sacar la aplicación de producción es el deseo de todo arquitecto.

Lo mismo pasa con los desarrolladores BPM que desean que sus procesos utilicen servicios de reglas, en vez de tener que implementarlas dentro del proceso.

Existe una necesidad de externalizar ese desarrollo de las reglas de negocio en sistemas que sean capaces de desplegarlas y ejecutarlas, y es ahí donde interviene WSO2 y su herramienta Business Rule Services o BRS, como la llamaremos a partir de ahora.

Esta herramienta permite desde su UI la implementación de servicios de reglas de negocio pero en esta ocasión quiero mostrarles las potencialidades del Developer Studio de WSO2 para la creación de reglas de negocio.

Precondiciones:

• Tener eclipse JUNO instalado. Si tiene la versión más actual del STS mejor.

• Tener el plugin Developer Studio 3.2.0 instalado en el IDE.

Paso 1:

Crear un proyecto “Business Rules Servic Project” usando el Developer Studio Dashboard.

Aquí los pasos son muy sencillos:

• Le dan a la primera opción para crea un servicio de reglas.

• Luego definen un nombre para el proyecto y un nombre para el servicio.

• Y luego Next  y Finish.

En mi caso tengo el siguiente proyecto creado:

Por defecto se les abre el fichero Service.rsl y bueno ya le he puesto algunas cosas así que me luce así. Veremos cada una ahora.

Paso 2:

He añadido una regla que se ve de la siguiente manera:

O sea le he puesto una descripción a la regla y en la opción inline he copiado el siguiente texto:

import aplicacion.rrhh.Empleado; 

      

    rule "Programador" salience 11 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 8 ) 

        then 

               $empleado.setCargo("Programador"); 

               $empleado.setSalario(500); 

    end 

      

    rule "Lider de Proyecto" salience 10 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 6, promedioConocimientos <= 7) 

        then 

               $empleado.setCargo("Lider de Proyecto"); 

               $empleado.setSalario(1000); 

    end 

      

    rule "Analista" salience 9 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 3, promedioConocimientos <= 5) 

        then 

              $empleado.setCargo("Analista"); 

              $empleado.setSalario(2000); 

    end  

      

    rule "Gerente" salience 8 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 0, promedioConocimientos <= 2) 

        then 

            $empleado.setCargo("Gerente"); 

            $empleado.setSalario(3000); 

    end

Veamos la traducción de este texto para aquellos que no dominan el leguaje de Drools:

Supongamos que tenemos una empresa X que quiere automatizar la forma en que le asigna el salario y el cargo a sus trabajadores en dependencia de su nivel de conocimientos. Esta es la forma en que lo hace:

El nivel de conocimientos va desde 0 y hasta más de 8. Mientras más conocimiento más alto el valor.

• Si el trabajador tiene 8 o más de conocimientos entonces es programador y su salario es de 500.
• Si el trabajador tiene 6 o 7 de conocimientos entonces es Líder de proyecto y su salario es de 1000.
• Si el trabajador tiene 3 o hasta 5 de conocimientos entonces es Analista y su salario es de 2000.
• Si el trabajador tiene 0 o hasta 2 de conocimientos entonces es Gerente y su salario es de 3000.

El servicio debe automatizarnos la asignación del rol y el salario al trabajador cuando le especificamos su nivel de conocimiento. Y eso es lo que aparece en el texto anterior, que se puede leer bastante fácil una vez que se tiene una comprensión de estas reglas para asignar rol y salario.

Ej.:  Esta regla:

    rule "Gerente" salience 8 dialect "mvel" no-loop true 

        when 

            $empleado : Empleado (promedioConocimientos >= 0, promedioConocimientos <= 2) 

        then 

            $empleado.setCargo("Gerente"); 

            $empleado.setSalario(3000); 

    end

Me dice que cuando un empleado tenga el nivel de conocimientos mayor o igual que cero y menos o igual que 2 tendrá el cargo de gerente y su salario será de  3000. Lo mismo se aplica para el resto de las reglas.

Seguimos.!!!!

Paso 3:

Vamos a crear ahora la clase que nos representa a un empleado. Para eso vamos a src/main/java dentro del proyecto, clic derecho y creamos una clase nueva:

Como ven es una clase muy sencilla, con los métodos get/set para cada uno de sus atributos.

Paso 4:

Volvemos al fichero  Service.rsl, a su pestaña de diseño y agregamos una operación nueva:

Para eso dan clic en el botón Add y luego la dejan de esta manera:

En mi caso la entrada es un objeto Empleado y la salida es el mismo objeto actualizado, por eso es que tanto la entrada como la salida se representan con la misma clase.

Y hasta aquí la implementación del servicio, porque ya está implementado. :-D

Ahora debemos desplegarlo en un BRS. En mi caso estaré usando uno local así que me aprovecharé de otras de las funcionalidades del WSO2 Developer Studio y crearé un servidor de WSO2 que me apunte al BRS que tengo.

Paso 5:

Para eso buscan la pestaña de Servers en el Eclipse y crear uno nuevo de la  siguiente manera:

En mi caso ya tenía  uno creado, si ustedes no lo tienen le dan a “Add”

Y ahí deben seleccionar usando el botón Browser la carpeta raíz de su BRS y listo.

El problema ahora es que el proyecto como lo tenemos no se puede desplegar en el BRS, para hacerlo debemos crear una Aplicación CARBON que nos empaquete este proyecto, y lo que desplegamos en el BRS es esta aplicación CARBON, que se encarga a su vez de desplegar el servicio de reglas.

Paso 6:

Para hacer esto volvemos al dashboard del Developer Studio y seleccionamos Carbon Application  Project.

Cuando lo hagan verán como nos lista todos los proyecto de WSO2 que tenemos en el workspace, y debemos seleccionar el de reglas de negocio. en mi caso luce así.

Le asignan un nombre y listo.

Luego es cosa de como cualquier aplicación web en java adicionarla al servidor CARBON que creamos antes y ejecutar el servidor.

Paso 7:

Cuando el servidor se inicie verán unos logs similares a estos:

[2013-07-02 23:33:19,741]  INFO - ApplicationManager Deploying Carbon Application : DespliegueReglaNegocio_1.0.0.car...

[2013-07-02 23:33:20,807]  INFO - ApplicationManager Successfully Deployed Carbon Application : DespliegueReglaNegocio {super-tenant}

[2013-07-02 23:33:36,890]  INFO - DeploymentInterceptor Deploying Axis2 service: SalaryRuleService {super-tenant}

[2013-07-02 23:33:36,949]  INFO - DeploymentEngine Deploying Web service: SalaryRuleService-1.0.0.aar -

[2013-07-02 23:33:42,927]  INFO - CarbonAuthenticationUtil 'admin@carbon.super [-1234]' logged in at [2013-07-02 23:33:42,927-0400]

Como ven nos ha desplegado la aplicación DespliegueReglaNegocio y esta a su vez nos ha desplegado el servicio SalaryRuleService-1.0.0.aar

Paso 8:

Abrimos la consola de administración, buscamos el servicio creado.

Y le damos “Try this Service”

Aquí tienen un pantallazo de la ejecución:

Y así en pocos pasos podemos tener creado un servicio web de reglas de negocio usando Drool y al cual podemos incorporarle todas las potencialidades de la suite de wso2 como son:

• Múltiples niveles de seguridad para la autenticación y autorización.

• Cacheo de la información.

• Filtrado por IP.

• Clusterización.

• Transparencia de ubicación.

• ……

Espero les resulte de utilidad y dejen su comentario.

Read More [...]

Posted in BRS, developer studio, Drools, reglas de negocio, WSO2

Consumiendo un servicio seguro con UserNameToken desde JAVA usando WSO2.

En esta entrada implementaremos el siguiente escenario.

Si al servicio que implementamos, desplegamos y consumimos en las entradas anteriores quisiéramos consumirlo nuevamente pero de forma segura deberíamos de hacer algunos cambios en su diseño.

Esto no lo hicimos desde el inicio para dar pie a esta entrada :-D pero la idea es que de los bindings del servicio que ya tenemos que son el HTTP, SOAP11 y SOAP12 pues tengamos 2 puertos por cada uno de ellos. Uno seguro y el otro inseguro. Ya tenemos los inseguros así que debemos crear los seguros.

Vean que cuando se usa el estándar SOAP versión 1.2 se usa el namespace referenciado por soap12 y que al inicio del WSDL podrán encontrar xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

Una vez hecha la modificación la imagen gráfica del WSDL visto con el eclipse tendría esta forma.

El código en la vista XML del WSDL de uno de estos puertos sería algo como esto:

    <wsdl:port name="HolamundoHttpsSoap12Endpoint"
                binding="ns:HolamundoSoap12Binding">
                <soap12:address location="https://www.example.org/" />
    </wsdl:port>

Lo importante es que el nombre del puerto lleva una s detrás del http para indicar que se usará un canal encriptado https. Y lo otro es que la dirección usa https en vez de http.

Si vuelven a revisar el WSDL que muestra el Application Server verán lo siguiente:

A partir de aquí deberíamos volver a redesplegar el servicio y probarlo a consumir de forma insegura como ya expliqué en otras entradas.

Una vez que comprueben que los cambios introducidos no han afectado el consumo inseguro pues implementaremos los siguientes pasos:

Paso 1:  iremos al dashboard del servicio y le asignaremos el menor nivel de seguridad. En el caso de la suite de wso2 es el uso del UserNameToken. O sea encriptar el canal de comunicación y usar HTTPS y enviar un token que contenga el usuario y la contraseña, ambos en texto plano, de quien desee consumir el servicio. Este usuario debe ser uno de los que están en alguno de los almacenes de usuario que tiene configurada la herramienta.

Paso 2:  usando la funcionalidad del “Try it” consumiremos el servicio seguro especificando el usuario/contraseña del admin del Application Server, que es el único usuario que tenemos hasta el momento en la herramienta.

Paso 3: implementaremos un cliente de este servicio en JAVA usando para ello el Developer Studio de WSO2.

Así que manos a la obra.

Para implementar el paso 1 nos vamos al dashboard de servicio que luce como sigue en la parte de “Quality of Service Configuration”:

Damos clic en Security y  se nos mostrará la interrogante de si habilitamos la seguridad, y seleccionamos Yes. Automáticamente se despliega el listado de posibles escenarios de seguridad. Solo les mostraré los básicos pero son 16.

Como ven marcamos el de UsernameToken y vamos al final de la página para darle al botón Next.

Luego de dar Next se nos pide especificar los grupos que tendrán permiso de acceso al servicio. Una autenticación básica para poder validar el usuario y la contraseña que se introduzcan.

Y por último damos Finish.

Y eso es todo, ya tenemos un servicio seguro sin tocar su implementación.

Cuando volvemos al Dashboard del servicio vemos que ahora solo el servicio está exponiendo un único endpoint, el seguro.

Ahora vamos a realizar el paso 2.

Le damos clic a “Try it” y veremos lo que nos sale.

En mi caso el firefox me dice que la conexión está cifrada pero no verificada, es que no confía en el certificado auto firmado que viene por defecto con la herramienta.

Luego de dar en que entendemos los riesgos y añadir la excepción vemos lo siguiente:

Como ven ya el Try it detectó la seguridad y nos da la opción de que podamos añadir el usuario y la contraseña. Introducimos admin y admin que son los valores por defecto y asignamos un nombre y un apellido y la respuesta no se hace esperar.

Ahora funciona, pero realmente funciona? Una manera de comprobarlo es ver los mensajes que se intercambian. Aquellos que sepan usar el TCPMon los invito a hacerlo pero al estar el canal encriptado poco podrán hacer a no ser que realicen una configuración y usando el par de llaves asimétricas del servidor puedan ver dentro del canal cifrado, pero a aquellos que quieran ver la estructura de los mensajes sin complicarse tanto los invito entonces a usar otra funcionalidad de la suite de WSO2 y de su framework CARBON y por lo tanto incluida en todas  las herramientas: el SOAP TRACER.

Para usarlo nos vamos a la pestaña Monitor del menú:

Y pinchamos en SOAP Tracer.

Se nos pregunta si queremos habilitar el soap tracer y le damos que YES. Veremos lo siguiente:

Ahora volvemos al  try it y consumimos de nuevo el servicio. Y cuando regresamos al soap tracer tendremos lo siguiente:

O sea el soap tracer ha capturado los mensajes, nos muestra la hora de consumo del servicio y los mensajes tanto de entrada como de salida. Es imposible mostrarlos completamente pero en el mensaje request vean como se ha añadido un encabezado “Security” y dentro del mismo un timestamp para evitar que el mensaje sea usado, reenviado, fuera de ese rango de tiempo como una medida de proteccion. También verán que hay un token Username que tiene el usuario y el password introducidos por el usuario. Cada uno de los mensajes pueden visualizarlo a pantalla completa si lo desean y ver su contenido adecuadamente.

Para finalizar esta entrada que ya se ha extendido vamos al paso 3. Consumiremos el servicio asegurado con usernametoken.

Los invito a probar el cliente creado en la otra entrada, les resultará imposible porque el endpoint que usábamos ya no existe. Si lo cambian por  el que existe ahora recibirán varios errores relacionados con el certificado que deberían tener y que no tienen. Aun.

Creamos un proyecto siguiendo los mismos pasos que vimos en la otra entrada para generar las clases del stub.

Luego de implementar el cliente y añadir las dependencias tal y como hicimos para el consumo del servicio inseguro nos sigue dando un error y está claro porque no hemos hecho nada con la seguridad.

Hasta  el momento mi implementación luce así:

package org.blogs.ejemplos.serviciosaxis2;

import java.rmi.RemoteException;
import org.apache.axis2.AxisFault;
import org.blogs.ejemplos.serviciosaxis2.HolamundoWSDLStub.Holaati;
import org.blogs.ejemplos.serviciosaxis2.HolamundoWSDLStub.HolaatiResponse;
import org.blogs.ejemplos.serviciosaxis2.HolamundoWSDLStub.Persona;

public class Cliente {

                /**

                * @param args

                */
                public static void main(String[] args) {

                               try {
                                               HolamundoWSDLStub stub = new HolamundoWSDLStub();

                                               Holaati holaati = new Holaati();
                                               Persona param = new Persona();
                                               param.setNombre("nombre1");
                                               param.setApellidos("apellido1");
                                               holaati.setPersona(param);

                                               HolaatiResponse respuesta = stub.holaati(holaati);
                                               System.out.println("La respuesta es:   " 
              + respuesta.get_return().getSaludo());

                               } catch (AxisFault e) {
                                               e.printStackTrace();
                               } catch (RemoteException e) {
                                               e.printStackTrace();
                               }
                }
}

Luego de realizar los cambios necesarios en el código nos queda la siguiente implementación con los comentario de las cosas nuevas incluidos. Pruébenlo y me dicen.

import java.rmi.RemoteException;

import org.apache.axiom.om.impl.builder.StAXOMBuilder;
import org.apache.axis2.AxisFault;
import org.apache.axis2.client.Options;
import org.apache.neethi.Policy;
import org.apache.neethi.PolicyEngine;
import org.apache.rampart.RampartMessageData;
import org.blogs.ejemplos.serviciosaxis2.HolamundoWSDLStub.Holaati;
import org.blogs.ejemplos.serviciosaxis2.HolamundoWSDLStub.HolaatiResponse;
import org.blogs.ejemplos.serviciosaxis2.HolamundoWSDLStub.Persona;

public class Cliente {

 private static Policy loadPolicy(String xmlPath) throws Exception {
  StAXOMBuilder builder = new StAXOMBuilder(xmlPath);
  return PolicyEngine.getPolicy(builder.getDocumentElement());
 }

 /**
  * @param args
  */
 public static void main(String[] args) {
  try {

   String trustStore = null;

   // ubicación del almace de llaves que contiene el certificado del
   // servidor AS
   trustStore = "c:\\keys\\cliente.jks";

   // ubicacción de la política que usa el servicio para la seguridad.
   String policyFilePath = "d:\\UTOverTransport.xml";
   // se definen las propiedades para encriptar el canal de comuncación
   // especificando el almacen de certificados de donde se extraerá el
   // certificado correspondiente al servidor
   System.setProperty("javax.net.ssl.trustStore", trustStore);
   System.setProperty("javax.net.ssl.trustStorePassword", "cliente");

   // aqui especificamos el endpoint seguro
   HolamundoWSDLStub stub = new HolamundoWSDLStub(
     "https://192.168.0.224:9445/services/HolamundoWSDL/");

   // optenemos las opciones del servicio
   Options options = stub._getServiceClient().getOptions();
   // enganchamos el modulo de rampart para la seguridad en el flujo de
   // los mensajes.
   stub._getServiceClient().engageModule("rampart");

   // pasamos el usuario y la contraseña
   options.setUserName("admin");
   options.setPassword("admin");
   // asignamos la política de servicio a las opciones del stub.
   options.setProperty(RampartMessageData.KEY_RAMPART_POLICY,
     loadPolicy(policyFilePath));
   stub._getServiceClient().setOptions(options);

   Holaati holaati = new Holaati();
   Persona param = new Persona();
   param.setNombre("nombre1");
   param.setApellidos("apellido1");
   holaati.setPersona(param);

   HolaatiResponse respuesta = stub.holaati(holaati);

   System.out.println("La respuesta es:   "
     + respuesta.get_return().getSaludo());

  } catch (AxisFault e) {
   e.printStackTrace();
  } catch (RemoteException e) {
   e.printStackTrace();
  } catch (Exception e) {
   e.printStackTrace();
  }
 }
}

Las librerías que usé fueron las siguientes(tengan en cuenta que las versiones pueden variar):

axiom-1.2.11.wso2v1.jar

axis2-1.6.1.wso2v1.jar

commons-codec-1.3.0.wso2v1.jar

commons-httpclient-3.1.0.wso2v1.jar

commons-io-2.0.0.wso2v1.jar

geronimo-stax-api_1.0_spec-1.0.1.wso2v1.jar

httpcore-4.1.0.wso2v1.jar

neethi-2.0.4.wso2v3.jar

opensaml2-2.0.0.alpha1-wso2v1.jar

org.wso2.carbon.addressing-3.2.0.jar

org.wso2.carbon.logging-3.2.0.jar

org.wso2.securevault-1.0.0.jar

rampart-core-1.6.1.wso2v1.jar

rampart-policy-1.6.1.wso2v1.jar

rampart-trust-1.6.1.wso2v1.jar

woden-1.0.0.M8-wso2v1.jar

wsdl4j-1.6.2.wso2v2.jar

wss4j-1.5.11.wso2v1.jar

XmlSchema-1.4.7.wso2v1.jar

Luego de implementar un ciclo sencillo para consumir varias veces el servicio pueden ver las siguientes estadísticas en su dashboard.

En otras entradas estaremos viendo cómo usar el SOAPUI para consumir un servicio y hacer pruebas de carga y estrés.

Read More [...]

Posted in axis2, developer studio, seguridad, servicios web, UserName Token, WSO2

Creando un cliente de un servicio web usando el Developer Studio de WSO2.

Supongamos que tenemos que consumir un servicio desplegado en el Application Server de WSO2.

El WSDL del servicio es el siguiente:

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:ns1="http://org.apache.axis2/xsd" xmlns:ns="http://serviciosaxis2.ejemplos.blogs.org" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" targetNamespace="http://serviciosaxis2.ejemplos.blogs.org">

  <wsdl:types>

    <xs:schema xmlns:ax24="http://serviciosaxis2.ejemplos.blogs.org/xsd" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://serviciosaxis2.ejemplos.blogs.org">

         <xs:element name="holaati">

            <xs:complexType>

               <xs:sequence>

                  <xs:element minOccurs="0" name="persona" nillable="true" type="ns:Persona"/>

               </xs:sequence>

            </xs:complexType>

         </xs:element>

         <xs:element name="holaatiResponse">

            <xs:complexType>

               <xs:sequence>

                  <xs:element minOccurs="0" name="return" nillable="true" type="ns:PersonaRespuesta"/>

               </xs:sequence>

            </xs:complexType>

         </xs:element>

                  <xs:complexType name="Persona">

            <xs:sequence>

               <xs:element minOccurs="0" name="apellidos" nillable="true" type="xs:string"/>

               <xs:element minOccurs="0" name="nombre" nillable="true" type="xs:string"/>

            </xs:sequence>

         </xs:complexType>

         <xs:complexType name="PersonaRespuesta">

            <xs:sequence>

               <xs:element minOccurs="0" name="saludo" nillable="true" type="xs:string"/>

            </xs:sequence>

         </xs:complexType>

      </xs:schema>

  </wsdl:types>

  <wsdl:message name="holaatiResponse">

    <wsdl:part name="parameters" element="ns:holaatiResponse">

    </wsdl:part>

  </wsdl:message>

  <wsdl:message name="holaatiRequest">

    <wsdl:part name="parameters" element="ns:holaati">

    </wsdl:part>

  </wsdl:message>

  <wsdl:portType name="HolamundoPortType">

    <wsdl:operation name="holaati">

      <wsdl:input message="ns:holaatiRequest" wsaw:Action="urn:holaati">

    </wsdl:input>

      <wsdl:output message="ns:holaatiResponse" wsaw:Action="urn:holaatiResponse">

    </wsdl:output>

    </wsdl:operation>

  </wsdl:portType>

  <wsdl:binding name="HolamundoSoap11Binding" type="ns:HolamundoPortType">

    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

    <wsdl:operation name="holaati">

      <soap:operation soapAction="urn:holaati" style="document"/>

      <wsdl:input>

        <soap:body use="literal"/>

      </wsdl:input>

      <wsdl:output>

        <soap:body use="literal"/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

  <wsdl:binding name="HolamundoHttpBinding" type="ns:HolamundoPortType">

    <http:binding verb="POST"/>

    <wsdl:operation name="holaati">

      <http:operation location="holaati"/>

      <wsdl:input>

        <mime:content part="parameters" type="text/xml"/>

      </wsdl:input>

      <wsdl:output>

        <mime:content part="parameters" type="text/xml"/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

  <wsdl:binding name="HolamundoSoap12Binding" type="ns:HolamundoPortType">

    <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

    <wsdl:operation name="holaati">

      <soap12:operation soapAction="urn:holaati" style="document"/>

      <wsdl:input>

        <soap12:body use="literal"/>

      </wsdl:input>

      <wsdl:output>

        <soap12:body use="literal"/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

  <wsdl:service name="HolamundoWSDL">

    <wsdl:port name="HolamundoHttpEndpoint" binding="ns:HolamundoHttpBinding">

      <http:address location="http://192.168.0.37:9765/services/HolamundoWSDL.HolamundoHttpEndpoint/"/>

    </wsdl:port>

    <wsdl:port name="HolamundoHttpSoap11Endpoint" binding="ns:HolamundoSoap11Binding">

      <soap:address location="http://192.168.0.37:9765/services/HolamundoWSDL.HolamundoHttpSoap11Endpoint/"/>

    </wsdl:port>

    <wsdl:port name="HolamundoHttpSoap12Endpoint" binding="ns:HolamundoSoap12Binding">

      <soap12:address location="http://192.168.0.37:9765/services/HolamundoWSDL.HolamundoHttpSoap12Endpoint/"/>

    </wsdl:port>

  </wsdl:service>

</wsdl:definitions>

Abrimos el eclipse y vamos al dashboard del Developer Studio y seleccionamos la opción “Generate Axis2 Web Service Client”

En dependencia de donde tengamos nuestro servicio será la opción que marcaremos y cargaremos el fichero. En mi caso usaré esta URL: http://192.168.0.37:9765/services/HolamundoWSDL?wsdl que se corresponde con el último servicio que desplegamos en la otra entrada.

Ahí nos pedirá que creemos  un proyecto si no tenemos uno aun.

Creamos el proyecto y damos Finish.

Ahora se nos muestra esta pantalla y damos Finish igual.

Así ya hemos creado el proyecto completo del cliente del servicio como pueden ver a continuación.

Crearemos una clase que será la que consumirá el servicio. La clase que ven que se creó automáticamente contiene la funcionalidad para interactuar con el servicio web.

Esta clase quedará de la siguiente manera:

Si la prueban ahora les dará un error porque faltan algunas dependencias. En esto nos ayuda el Developer Studio.

Damos clic derecho en el proyecto y nos vamos a configurar el Build Path.

Seleccionamos Add Library y luego damos en WSO2 ClassPath Libraries.

Damos en Next y marcamos todas las de Axis2.

Y en la pestaña del IS marcamos lo siguiente:

Por ultimo nos falta agregar una librería que fue introducida recientemente en el framework carbon y que no viene en la versión del Developer Studio que estoy empleando, por lo que tengo que buscarle en:

[AS]\repository\components\plugins\ org.wso2.securevault_1.0.0.wso2v2.jar la agregamos y listo. Ya podemos ejecutar nuestro cliente.

Cuando ejecutamos nuestra clase vemos la siguiente respuesta:

Lo que nos indica que obtuvimos la respuesta del servicio web que esperábamos.

Luego de ejecutar el cliente varias veces podemos ir al dashboard del servicio y ver la estadísticas de su uso.

Y bueno eso es todo hasta el momento.

Read More [...]

Posted in axis2, cliente, developer studio, servicios web, WSO2

Creando un Servicio Axis2 en Eclipse usando el Developer Studio de WSO2.

Para crear un servicio de axis2 usando el Developer Studio se pueden usar 2 variantes:

1. Si ya tienes el código implementado puedes generar el servicio a partir del mismo.
2. Si tienes el WSDL, diseño del servicio, lo puedes usar para generar el esqueleto de la implementación del servicio y de ahí su implementación final.

Veremos las 2 variantes.

Variante 1.

En el Dashboard, la imagen que ven al inicio, damos clic en Axis2 Service Project y verán lo siguiente:

Usaremos la primera opción ya que la segunda es para la variante 2.

Damos siguiente y nos lleva a esta pantalla. Ahí definimos un nombre para el proyecto, el nombre del paquete y el nombre que tendrá la clase donde implementaremos el servicio. En mi caso lo pongo como sigue:

Damos siguiente y veremos una pantalla con algunos valores referentes a Maven, porque el proyecto que se crea es un proyecto de Maven, eso yo lo dejo así  y doy Finish.

Ya aquí se nos crea el proyecto y lo pueden ver en la siguiente imagen:

Es sobre esta clase donde debemos implementar los métodos que queramos sean expuestos a través del servicio web. Es importante que tanto los parámetros de entrada y de salida sean clases para que macheen con el estilo document/literal que es la buena práctica recomendada por el WS-I, estándar para la interoperabilidad entre servicios web.

Luego de realizar una implementación sencilla tendríamos lo siguiente:

Donde las clases que estamos usando las he creado y son las siguientes:

Como se ve es una implementación muy sencilla pero que se ajusta a nuestro propósito.

Si queremos que se genere el WSDL de este servicio le damos clic derecho al proyecto y seleccionamos la opción “Generate WSDL” tal y como muestra la siguiente imagen.

Cuando hacemos esto se nos muestra la siguiente ventana.

Y vean que yo le digo que me guarde el WSDL dentro de la carpeta META-INF. Luego le damos OK.

Una vez hecho esto verán el WSDL del servicio.

Lo otro que nos queda es desplegar el servicio como un fichero .aar, para hacerlo  podemos dar clic derecho en el proyecto y seleccionar la opción “Export Project as Deployable Archive”.

Ahí ponemos donde queremos guardar el servicio y listo. Ya tendremos el fichero en la ubicación seleccionada.

Variante 2.

Ahora supongamos que ya teníamos el WSDL del Servicio. Usaremos este WSDL.

Realizaríamos el primer paso de la variante 1 pero en este caso seleccionamos la opción que pueden ver en esta imagen.

Ahora seleccionamos donde tenemos el WSDL y le damos un nombre al proyecto.

Eso nos crea el proyecto como pueden ver en la siguiente imagen.

La  clase donde debemos implementar es HolamundoSkeleton.java si cambian la clase o desean implementar en otra tengan en cuenta que deben ir al fichero marcado en la siguiente imagen:

Y modificar el nombre de la clase poniendo la clase que realmente contiene la implementación. Esta es la estructura de ese fichero:

Otra cosa que hago es mover el WSDL del servicio para dentro de la carpeta META-INF, eso es importante porque si no después les da un error.

Al inicio la clase que implementa el servicio tiene esta forma:

Luego de implementar la funcionalidad que queremos la clase queda como sigue:

Para crear el .aar seguimos los mismos pasos que en la variante anterior.

En otra entrada veremos como lo podemos desplegar en el Application Server de WSO2.

Read More [...]

Posted in axis2, developer studio, servicios web, WSO2