Hi, Thanks a lot for the tips. It looks like it is getting deployed now ! Waouh.
However, concerning your statement "NMR understands only abstract messages, so not even SOAP is used. ".. In fact, NMR does not deal with SOAP directly, but if you look at the AsyncProcess example bundled with ServiceMix, you will see that a SOAP (file message.soap in bpel example directory) message is actually sent to the Process... the SOAP message is wrapped in a NormalizedMessage and represents the content of the NM message. So, what i understand ( I may be wrong, any correction is welcome) is that in order to talk to the BPEL process, you need to wrap the message as SOAP. James suggested using ActiveSOAP for that, however, the process is still unclear to me. So here's a mini-HOWTO to help anyone who would need to get ServiceMix + PXE to run a BPEL service.. (nothing on communicating with the process, I'll complete that when I understand how to do it ;) Feel free to add it to ServiceMix / PXE's wiki, I think it can help some people : ==================================== How to get a BPEL process running with ServiceMix JBI Container and Fivesight's PXE : === 1) The first step is to create a BPEL process with the corresponding WSDL files. Examples bundled with PXE can serve as a quickstart. 2) Remove any concrete bindings in the WSDL Files ( binding and service XML tags). Indeed, the endpoints are JBI proxies, so the SOAP over HTTP bindings are useless here. PXE and ServiceMix will take care of registering ports as JBI Service endopints. 3) Compile your BPEL process and WSDL files let's say the main WSDL file describing the process is in the MissionPlanningProcess.wsdl (this file must import the other WSDL files that are used : REM add the resources to PXE's Resources Repository MissionPlanning.rr rradd -wsdl file:MissionPlanningProcess.wsdl MissionPlanning.rr REM compile the BPEL bpelc -rr MissionPlanning.rr -wsdl file:MissionPlanningProcess.wsdl file:MissionPlanning.bpel 4) Create a pxe-system.xml file that describes how to bind the BPEL process to actual JBI endpoints. (PXE's deployment descriptor) Let's say that the MissionPlanning process provides 3 portTypes : proc:ProcessPT, proc:CallbackPT, resp:ResponderPT. We want to expose 2 services : ProcessSVC that exposes the proc:processPT and proc:CallbackPT porttypes and ResponderSVC that exposes the resp:ResponderPT portType. (same names as the Async example bundled with PXE) the corresponding pxe-system.xml file would be : <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <system-descriptor name="MissionPlanning" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.fivesight.com/pxe/system-descriptor/ http://www.fivesight.com/pxe/system-descriptor/"; wsdlUri="file:MissionPlanningProcess.wsdl" xmlns="http://www.fivesight.com/pxe/system-descriptor/"; xmlns:proc="uri:concordia.ciise.weather.process" xmlns:resp="uri:concordia.ciise.weather.responder"> <channels> <channel name="inboundChannel" /> <channel name="callbackChannel" /> <channel name="outboundChannel" /> </channels> <services> <service name="ProcessSVC" provider="uri:jbi" > <properties> <property name="namespace" value="uri:concordia.ciise.weather.process" /> </properties> <imports> <!-- The following port will be registered as a JBI service endpoint {uri:fivesight.com/examples/AsyncProcessJBI:ProcessSVC, ProcessPORT} --> <port name="ProcessPORT" type="proc:ProcessPT" channel-ref="inboundChannel"/> <!-- The following port will be registered as a JBI service endpoint {uri:fivesight.com/examples/AsyncProcessJBI:ProcessSVC, CallbackPORT} --> <port name="CallbackPORT" type="resp:CallbackPT" channel-ref="callbackChannel"/> </imports> </service> <service name="ResponderSVC" provider="uri:jbi" > <properties> <property name="namespace" value="uri:concordia.ciise.weather.responder" /> </properties> <exports> <!-- The following port will invoke JBI service endpoint {uri:fivesight.com/examples/AsyncProcessJBI:ResponderSVC, ResponderPORT} --> <port name="ResponderPORT" type="resp:ResponderPT" channel-ref="outboundChannel"/> </exports> </service> <service name="ProcessSync.BpelService" provider="uri:bpel"> <properties> <property name="compiledProcess" value="MissionPlanning.cbp"/> </properties> <imports> <port name="AsyncResponder.Responder" type="resp:ResponderPT" channel-ref="outboundChannel"/> </imports> <exports> <port name="Client.Process" type="proc:ProcessPT" channel-ref="inboundChannel"/> <port name="AsyncResponder.Caller" type="resp:CallbackPT" channel-ref="callbackChannel"/> </exports> </service> </services> </system-descriptor> Pay attention to use the same value for the "name" attribute in the system-descriptor tag, as the name of the BPEL process. (current limitations with PXE, should be fixed in the future) 5) We now have all the necessary artifacts to create a SAR (System Archive) file that is just a container for all these files : sarcreate -common MissionPlanning.rr -sysd pxe-system.xml MissionPlanning.cbp pxe.sar 6) JBI needs deployable components (the SAR in this case) to be contained in a zip file. The zip file is referred later as a Service Unit. (hence the -su) => create the output directory => jar cf output\MissionPlanning-su.zip pxe.sar (or use any tool that can create a .zip) 7) Package this service unit inside a so-called Service Assembly (SA), which is just a set of service units with a jbi.xml For example, create the following output\META-INF\jbi.xml file : <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <jbi version="1" xsi:schemaLocation="http://java.sun.com/xml/ns/jbi ./jbi.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns="http://java.sun.com/xml/ns/jbi";> <service-assembly> <identification> <name>MissionPlanningSA</name> <description>Service Assembly containing just the BPEL deployment.</description> </identification> <service-unit> <identification> <name>MissionPlanning</name> <description>BPEL Service Unit</description> </identification> <target> <artifacts-zip>MissionPlanning-su.zip</artifacts-zip> <component-name>PxeBpelEngine</component-name> </target> </service-unit> </service-assembly> </jbi> and create the jar : cd output echo creating Service Assembly jar cf ..\MissionPlanning-sa.jar * cd .. component-name refers to the name of the BPEL engine deployed in the JBI container. 8) Create a servicemix.xml file that launches a JBI container. An example is bundled with ServiceMix's AsyncDemo example : Pay attention to : <property name="installationDirPath" value="./install"/> and <property name="deploymentDirPath" value="./deploy"/> in the installationDirPath, you will have to drop the PXE's JBI component. (bundled with ServiceMix). If ServiceMix doesn't detect PXE nor install it, then it means there is a problem in your installationDirPath. (For example, if ServiceMix is integrated inside Geronimo, the "." directory refers to GERONIMO_HOME the deploy directory is where you will drop the Service Assembly 9) launch service mix (either standalone, or by sourcing the spring file. If you source the spring file, make sure you use ServiceMix's Spring version. The XML extension mechanism is not yet available from upstream Spring, so Spring won't recognize servicemix's specific spring syntax. 10) Here you go, you can then talk to your BPEL process from other JBI components (more information in another HOWTO) Regards, Sami Dalouche Selon Maciej Szefler <[EMAIL PROTECTED]>: > Sami, > > These are best answered on service mix, but I happen to have some of the > answers: > > On Fri, 2005-09-02 at 16:34 +0200, Sami Dalouche wrote: > > Hi, > > > > I'm posting both to pxe + service mix ML since I'm not really sure where > the > > problem comes from. > > > > My first question is, is the AsyncDemo in ServiceMix the exact same one as > the > > one in PXE ? > > Indeed, I couldn't find the source of the demo (the BPEL + WSDL), and PXE's > > async demo has some concrete SOAP over HTTP endpoints hardcoded : > > like > > <soap:address location="http://localhost:8080/pxe/soap/async/invoke"/> > > > I believe the demo is identical except for the endpoints: in service mix > the endpoints are JBI proxies, so the concrete WSDL would not be used. > > > is this suppsoed to work in ServiceMix's NMR ?? > > > > I thought it was only SOAP in the NMR, not SOAP over HTTP... > > > NMR understands only abstract messages, so not even SOAP is used. > > > same stuff in the BPEL : > > <from > > > expression="'http://localhost:8090/pxe/soap/AsyncProcess/ProcessSVC/CallbackPORT'"/> > > there are concrete endpoints... > > > This bit of code is a historical vestige, it does not actually get used. > > > > > > 2) My second question is a technical problem : > > > > The JBI wrapper has a limitation: the SU name must match the name of the > PXE system. Update your pxe-system.xml so that the "name" attribute on > the system-descriptor element matches the name of the SU. We're working > on fixing this problem. > > > I took the async demo, modified the filenames and namespaces.. that's all I > > changed. > > then I compile and package using a small .bat script : > > > > call rradd -wsdl file:MissionPlanningProcess.wsdl MissionPlanning.rr > > call bpelc -rr MissionPlanning.rr -wsdl file:MissionPlanningProcess.wsdl > > file:MissionPlanning.bpel > > call sarcreate -common MissionPlanning.rr -sysd pxe-system.xml > > MissionPlanning.cbp pxe.sar > > jar cf output\MissionPlanning-su.zip pxe.sar > > cd output > > echo creating Service Assembly > > jar cf ..\MissionPlanning-sa.jar * > > cd .. > > > > I end up having a MissionPlanning-sa.jar, that has : > > - META-INF/jbi.xml > > - MissionPlanning-su.zip > > > > the jbi.xml is the exact same one as the AsyncProces, except with the > filename > > modifications : > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > > <jbi version="1" > > xsi:schemaLocation="http://java.sun.com/xml/ns/jbi ./jbi.xsd" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xmlns="http://java.sun.com/xml/ns/jbi";> > > > > <service-assembly> > > <identification> > > <name>MissionPlanningSA</name> > > <description>Service Assembly containing just the BPEL > > deployment.</description> > > </identification> > > <service-unit> > > <identification> > > <name>MissionPlanning</name> > > <description>BPEL Service Unit</description> > > </identification> > > <target> > > <artifacts-zip>MissionPlanning-su.zip</artifacts-zip> > > <component-name>PxeBpelEngine</component-name> > > </target> > > </service-unit> > > </service-assembly> > > </jbi> > > > > > > so, at this point, given that the BPEL compilation is OK, this should work, > > right ? > > > > Here's the errror I get when I deploy it in serviceMix : (I use the > asyncprocess > > servicemix.xml, my process has the same port names, etc) > > ssionPlanning > > 2005-09-02 10:38:00 com.fs.pxe.jbi.PxeSUManager deploy > > GRAVE: Naming conflict PXE system name must be "MissionPlanning"! > > [WARN] AutoDeploymentService - -Directory: deploy: Automatic install of > .\deploy > > \MissionPlanning-sa.jar failed <javax.jbi.management.DeploymentException: > Invali > > d PXE system name.>javax.jbi.management.DeploymentException: Invalid PXE > system > > name. > > at com.fs.pxe.jbi.PxeSUManager.deploy(PxeSUManager.java:96) > > at > org.servicemix.jbi.framework.DeploymentService.deployServiceUnit(Depl > > oymentService.java:495) > > at > org.servicemix.jbi.framework.DeploymentService.deploy(DeploymentServi > > ce.java:162) > > at > org.servicemix.jbi.framework.DeploymentService.process(DeploymentServ > > ice.java:106) > > at > org.servicemix.jbi.framework.AutoDeploymentService$1.run(AutoDeployme > > ntService.java:164) > > at > org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja > > va:291) > > at > EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown So > > urce) > > at java.lang.Thread.run(Thread.java:595) > > > > [INFO] AutoDeploymentService - -Directory: deploy: Finished installation of > arch > > ive: MissionPlanning-sa.jar > > > > And when I deploy the asyncProcess bundled with serviceMix, there is no > > problem.. > > So if someone could give me an idea of what the error exactly comes from... > > > > Thanks a lot, > > Sami Dalouche > > > > > > > > > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > pxe-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/pxe-user > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > pxe-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pxe-user > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
