Los Bpel tiene un punto de acceso. Estos se definen a través de un fichero Wsdl. Para ejecutar un BPEL es tan fácil como enviar un mensaje SOAP. La aplicacion ODE tiene un comando el cual manda el mensaje SOAP a un EPR (end point reference). Para llamalo esta es la sintaxis.
C:\>sendsoap -o D:\apache-ode-war-1.3.3\apache-ode-war-1.3.3\examples
\response.xml http://localhost:8080/ode/processes/HelloWorld D:\apache-ode-war-1.3.3\apache-ode-war-1.3.3\examples\HelloWorld\testRequest.soap
Ten en cuenta que el mensaje SOAP tiene que tener el formato adecuado con su definición en el WSDL.
He encontrado un problema en ODE, a veces da un error al enviar los mensajes. No hay mas que reiniciar el ODE.
Thursday, March 24, 2011
Monday, March 21, 2011
Creacion de un bpel partiendo de un WSDL
Un Bpel es un proceso el cual tiene una entrada, un conjunto de operaciones y una salida. Para editar un bpel tienes el Eclipse Java EE IDE for Web Developers. Y para ejecutar el bpel tienes el motor de ejecucion de Apache ODE.
Los puntos de entrada y de salilda de los bpel se llaman Receive y Reply. Para que un Bpel esté accesible, se tiene que crear un acceso a través de un Wsdl. Es decir, para llamar a un proceso Bpel hay que ejecutar una llamada a un WS. Además cualquier punto de aceso, ya sea para llamar a un WS o para dejar accesible el bpel a través de un WS tienes que crear un PartnerLink. Los Bpel son procesos abstractos, es decir no tiene un punto de acceso defnido, tienes un interfaz . El punto de acceso o implementacion del servicio se vincula en tiempo de despliegue del Bpel. En ODE cuando despliegas un servicio lo vinculas con un EPR (end point reference) con el fichero deploy.xml, en el cual indicas el partnetlink con el binding del Web service. Por todo esto un Partnerlink es una asociacion a un PortType de un Wsdl.
Un proceso básico de un Bpel se prodria definir de la siguiente manera:
Paso 1
Un WS simple con un servicio que tiene operacion que contiene un mensaje de entrada y un mensaje de salida, todo esto esta definido en un portType. La implementacion del servicio esta definido en un ERP.
Paso 2
Para creamos un Bpel e incluimos el PartnerLink al PortType y creamos 3 acciones una de entrada una invocacion y una de salidad, es decir receive invoke reply. creamos otro PartnerLink al portType
<process name="process"
xmlns:tns="urn:process/bpel/process/"
xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
suppressJoinFailure="no"
xmlns:nshotel="http://hotel/reservadehotel/"
xmlns:nsimport="urn:import:service">
<bpel:import namespace="urn:import:service" location="process.wsdl"
importType="http://schemas.xmlsoap.org/wsdl/"/>
<partnerLinks>
<bpel:partnerLink name="hotelPartner"
partnerLinkType="nsimport:hotelPLT"
myRole="hotelRole"
partnerRole="hotelRole" />
<bpel:partnerLink name="hotelPartnerInvoke"
partnerLinkType="nsimport:hotelPLT"
partnerRole="hotelRoleInvoke" />
</partnerLinks>
<variables>
<variable name="input" messageType="nshotel:messageRequest"/>
<variable name="output" messageType="nshotel:messageResponse"/>
</variables>
<sequence name="MainSequence">
<bpel:receive name="receiveInput" partnerLink="hotelPartner"
createInstance="yes" operation="bookRoom" portType="nshotel:hotel" variable="input"/>
<bpel:invoke name="Invoke" partnerLink="hotelPartnerInvoke"
operation="bookRoom" portType="nshotel:hotel"
outputVariable="output" inputVariable="input"></bpel:invoke>
<bpel:reply name="replyOutput" partnerLink="hotelPartner"
operation="bookRoom" portType="nshotel:hotel"
variable="output" />
</sequence>
</process>
Paso 3
Creamos un WSDL con una referencia a ODE importando el WSDL del paso 1, e incluimos los ParnetLink para hacer de interface del BPEL y creamos una implementacion del WS para que nuestro BPEL pueda ser llamado
<plnk:partnerLinkType name="hotelPLT">
<plnk:role name="hotelRole" portType="nshotel:hotel" />
<plnk:role name="hotelRoleInvoke" portType="nshotel:hotel" />
</plnk:partnerLinkType>
<import location="hotel.wsdl" namespace="http://hotel/reservadehotel" />
<wsdl:binding name="HotelSoapBinding" type="nshotel:hotel" >
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="bookRoom">
<soap:operation
soapAction="http://hotel/reservadehotel/bookRoom" />
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="HotelService">
<wsdl:port name="HotelSoapBinding" binding="nsimport:HotelSoapBinding">
<soap:address location="http://localhost:8080/ode/processes/proceso"/>
</wsdl:port>
</wsdl:service>
Paso 4
Creamos con ayuda de eclipse el fichero de Deploy.xml vinculando a cada PartnetLink una implementacion de PortType para que pueda ser ejecutado.
<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
xmlns:nshotel="http://hotel/reservadehotel/"
xmlns:nsimport="urn:import:service">
<process name="proceso">
<active>true</active>
<provide partnerLink="hotelPartner">
<service name="nsimport:HotelService" port="HotelSoapBinding"/>
</provide>
<invoke partnerLink="hotelPartnerInvoke">
<service name="nshotel:hotel" port="hotelSOAP"/>
</invoke>
</process>
</deploy>
Los puntos de entrada y de salilda de los bpel se llaman Receive y Reply. Para que un Bpel esté accesible, se tiene que crear un acceso a través de un Wsdl. Es decir, para llamar a un proceso Bpel hay que ejecutar una llamada a un WS. Además cualquier punto de aceso, ya sea para llamar a un WS o para dejar accesible el bpel a través de un WS tienes que crear un PartnerLink. Los Bpel son procesos abstractos, es decir no tiene un punto de acceso defnido, tienes un interfaz . El punto de acceso o implementacion del servicio se vincula en tiempo de despliegue del Bpel. En ODE cuando despliegas un servicio lo vinculas con un EPR (end point reference) con el fichero deploy.xml, en el cual indicas el partnetlink con el binding del Web service. Por todo esto un Partnerlink es una asociacion a un PortType de un Wsdl.
Un proceso básico de un Bpel se prodria definir de la siguiente manera:
Paso 1
Un WS simple con un servicio que tiene operacion que contiene un mensaje de entrada y un mensaje de salida, todo esto esta definido en un portType. La implementacion del servicio esta definido en un ERP.
Paso 2
Para creamos un Bpel e incluimos el PartnerLink al PortType y creamos 3 acciones una de entrada una invocacion y una de salidad, es decir receive invoke reply. creamos otro PartnerLink al portType
<process name="process"
xmlns:tns="urn:process/bpel/process/"
xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
suppressJoinFailure="no"
xmlns:nshotel="http://hotel/reservadehotel/"
xmlns:nsimport="urn:import:service">
<bpel:import namespace="urn:import:service" location="process.wsdl"
importType="http://schemas.xmlsoap.org/wsdl/"/>
<partnerLinks>
<bpel:partnerLink name="hotelPartner"
partnerLinkType="nsimport:hotelPLT"
myRole="hotelRole"
partnerRole="hotelRole" />
<bpel:partnerLink name="hotelPartnerInvoke"
partnerLinkType="nsimport:hotelPLT"
partnerRole="hotelRoleInvoke" />
</partnerLinks>
<variables>
<variable name="input" messageType="nshotel:messageRequest"/>
<variable name="output" messageType="nshotel:messageResponse"/>
</variables>
<sequence name="MainSequence">
<bpel:receive name="receiveInput" partnerLink="hotelPartner"
createInstance="yes" operation="bookRoom" portType="nshotel:hotel" variable="input"/>
<bpel:invoke name="Invoke" partnerLink="hotelPartnerInvoke"
operation="bookRoom" portType="nshotel:hotel"
outputVariable="output" inputVariable="input"></bpel:invoke>
<bpel:reply name="replyOutput" partnerLink="hotelPartner"
operation="bookRoom" portType="nshotel:hotel"
variable="output" />
</sequence>
</process>
Paso 3
Creamos un WSDL con una referencia a ODE importando el WSDL del paso 1, e incluimos los ParnetLink para hacer de interface del BPEL y creamos una implementacion del WS para que nuestro BPEL pueda ser llamado
<plnk:partnerLinkType name="hotelPLT">
<plnk:role name="hotelRole" portType="nshotel:hotel" />
<plnk:role name="hotelRoleInvoke" portType="nshotel:hotel" />
</plnk:partnerLinkType>
<import location="hotel.wsdl" namespace="http://hotel/reservadehotel" />
<wsdl:binding name="HotelSoapBinding" type="nshotel:hotel" >
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="bookRoom">
<soap:operation
soapAction="http://hotel/reservadehotel/bookRoom" />
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="HotelService">
<wsdl:port name="HotelSoapBinding" binding="nsimport:HotelSoapBinding">
<soap:address location="http://localhost:8080/ode/processes/proceso"/>
</wsdl:port>
</wsdl:service>
Paso 4
Creamos con ayuda de eclipse el fichero de Deploy.xml vinculando a cada PartnetLink una implementacion de PortType para que pueda ser ejecutado.
<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
xmlns:nshotel="http://hotel/reservadehotel/"
xmlns:nsimport="urn:import:service">
<process name="proceso">
<active>true</active>
<provide partnerLink="hotelPartner">
<service name="nsimport:HotelService" port="HotelSoapBinding"/>
</provide>
<invoke partnerLink="hotelPartnerInvoke">
<service name="nshotel:hotel" port="hotelSOAP"/>
</invoke>
</process>
</deploy>
Tuesday, February 22, 2011
Leer un fichero dentro de un Bundle
Cuando se empaqueta un Bundle estes es publicado todo en un jar. Para poder leer, por ejemplo ficheros de congfiguracion dentro del jar hay que hacer lo siguiente:
configurationURI = FileLocator.toFileURL(
FileLocator.find(Activator.getBundleContext().getBundle(), new Path(
"./resources/config.properties"), null)).getPath();
A partir de esta ruta ya puedes abrir el fichero con un new File();
Además que no se te olvide marcar en en fichero build.porperties que publicas el fichero, ya que si no, no te lo incluye en el jar
configurationURI = FileLocator.toFileURL(
FileLocator.find(Activator.getBundleContext().getBundle(), new Path(
"./resources/config.properties"), null)).getPath();
A partir de esta ruta ya puedes abrir el fichero con un new File();
Además que no se te olvide marcar en en fichero build.porperties que publicas el fichero, ya que si no, no te lo incluye en el jar
Monday, February 14, 2011
Como saber la fecha de compilacion de una clase desde GlassFish
Cuando realizas pruebas te interesa saber si estas usando la última versión de tu código compilado. Sobre todo cuando pruebas en un servidor de aplicaciones. Debido a que no se si existe algún método que te lo de, he realizado un pequeño código a partir de lo que he leido por distintos foros.
String classfilename =context.getRealPath("WEB-INF/classes/clasejava.class");
File file = new File(classfilename);
Long lastModified = file.lastModified();
Date date = new Date(lastModified);
context.log("Date compilated :" + date);
Mejoraría si no tuviera que parametrizarlo con el nombre de la clase para mejorarlo.
String classfilename =context.getRealPath("WEB-INF/classes/clasejava.class");
File file = new File(classfilename);
Long lastModified = file.lastModified();
Date date = new Date(lastModified);
context.log("Date compilated :" + date);
Mejoraría si no tuviera que parametrizarlo con el nombre de la clase para mejorarlo.
Thursday, February 3, 2011
Acceder al contexto del servlet desde una implemetacion de web service
¿Como desde una implemetacion de un Web service, puedo leer el contexto de un servlet?
La respuesta a esta pregunta, que a priori es muy sencilla, se vuelve un poco compleja. He estado buscando informacion por la red y he visto que la gente usaba Spring. Pero ¿para que? Así que, he seguido buscando y al final encontré una solucion para el estandar de J2EE 6 .
@webService
public class MiServicio{
@Resource
private WebServiceContext webServiceContext;
ServletContext context;
public boolean damePath(){
if(webServiceContext != null){
context=(ServletContext)webServiceContext.getMessageContext().get(MessageContext.SERVLET_CONTEXT);
return context.getContextPath();
}
}
}
Hay muchos comentarios que al acceder al contexto, devuelve Null. Esto es debido a que cuando llamas a un WS el metodo, no es persistente. Es decir las variables son inicializadas. Así que cada metodo del WS debe aceder a la carga del contexto para que este valor no sea nulo.
La respuesta a esta pregunta, que a priori es muy sencilla, se vuelve un poco compleja. He estado buscando informacion por la red y he visto que la gente usaba Spring. Pero ¿para que? Así que, he seguido buscando y al final encontré una solucion para el estandar de J2EE 6 .
@webService
public class MiServicio{
@Resource
private WebServiceContext webServiceContext;
ServletContext context;
public boolean damePath(){
if(webServiceContext != null){
context=(ServletContext)webServiceContext.getMessageContext().get(MessageContext.SERVLET_CONTEXT);
return context.getContextPath();
}
}
}
Hay muchos comentarios que al acceder al contexto, devuelve Null. Esto es debido a que cuando llamas a un WS el metodo, no es persistente. Es decir las variables son inicializadas. Así que cada metodo del WS debe aceder a la carga del contexto para que este valor no sea nulo.
Thursday, January 13, 2011
Lanzar glassFish en modo debug
En GlassFish he publicado una aplicacion y cada vez que la invoco se cuelga glassfish y me salta una mensaje killed
Para ejecutar GlassFish en modo debug ejecuta desde la consola de comandos o shell
asadmin start-domain --debug [domain-name]
Donde domain-name por defecto es domain1
Una vez realizado este paso puedes obtener la consola de debug ejecutando
desde UNIX systems:
jdb -attach 9009
For Windows:
jdb -connect com.sun.jdi.SocketAttach::hostname=localhost,port=9009
Esta informacion ha sido extraida del documento
http://dlc.sun.com/pdf/821-1752/821-1752.pdf
Para ejecutar GlassFish en modo debug ejecuta desde la consola de comandos o shell
asadmin start-domain --debug [domain-name]
Donde domain-name por defecto es domain1
Una vez realizado este paso puedes obtener la consola de debug ejecutando
desde UNIX systems:
jdb -attach 9009
For Windows:
jdb -connect com.sun.jdi.SocketAttach::hostname=localhost,port=9009
Esta informacion ha sido extraida del documento
http://dlc.sun.com/pdf/821-1752/821-1752.pdf
Creacion de una Feature y un Site, en Eclipse
Una vez que hemos desarrollado unos plugins en Eclipse, si queremos distribuirlos la mejor manera es creando un Site. Pero antes de crear el Site, debemos crear un plugin del tipo Feature. Este plugin Feature, contendrá la lista de todos los plugins necesarios para la correcta ejecucion de nuestros plugins. Para crear un Feature plugins lo que debemos realizar es ir a Eclipse ->proyecto nuevo -> plugins feature el asistente nos mostrará una pantalla en la cual debemos introducir el ID que es el nombre de nuestro plugin feature, el distribuidor la versión. Lo mas importante viene cuando pulsamos siguiente, aparece una pantalla con un boton que "Initialize form a launch configuration" en la cual seleccionaremos nuestro entorno de ejecucion previamente creado.
Una vez acabado, creamos un site en el cual incluimos nuestro bundle feature. pulsamos construir y sincronizar y ya lo tenemos disponible para instalarlo desde el P2 de Eclipse.
Un fallo que me he encontrado ha sido que al probarlo no me encontraba el bundle javax.wsdl [1.4.0 - 1.6.0). Una vez que he mirado en el site tenia el bundle javax.wsdl 1.6.2 ¿como es posible que no lo encuentre? Así que la solución es poner en el fuichero de bundles otra version de bundle. por ejemplo javax.wsdl 1.5.1, y republicamos. Si, pulsas actualizar te borra el cambio realizado.
Otro fallo que te puedes encontrar es que a la hora de publicar una actualizacion en el Site. Eclipse agrupa las acutalizaciones por categoria, si lo tiene así agrupado no te muestra la última actualización. Así que es mejor en en el asistente de P2 quitar la opción de agrupar por categorias.
Una vez acabado, creamos un site en el cual incluimos nuestro bundle feature. pulsamos construir y sincronizar y ya lo tenemos disponible para instalarlo desde el P2 de Eclipse.
Un fallo que me he encontrado ha sido que al probarlo no me encontraba el bundle javax.wsdl [1.4.0 - 1.6.0). Una vez que he mirado en el site tenia el bundle javax.wsdl 1.6.2 ¿como es posible que no lo encuentre? Así que la solución es poner en el fuichero de bundles otra version de bundle. por ejemplo javax.wsdl 1.5.1, y republicamos. Si, pulsas actualizar te borra el cambio realizado.
Otro fallo que te puedes encontrar es que a la hora de publicar una actualizacion en el Site. Eclipse agrupa las acutalizaciones por categoria, si lo tiene así agrupado no te muestra la última actualización. Así que es mejor en en el asistente de P2 quitar la opción de agrupar por categorias.
Subscribe to:
Posts (Atom)