Sami, NMS/NMR should never be used to transport SOAP, however the JBI reference implementation punts on dealing properly with normalization/denormalization of messages. Hence people may have the wrong idea as to how things are supposed to work. In particular the BCs pick up a message and put it on the NMS without change, this is simply not correct if the message is SOAP. The PXE JBI wrapper is intentionally "broken" so as to be compatible with the broken BCs shipped with the JBI RI.
To be JBI compliant the BCs would pick up a message (un-SOAPify it if necessary), construct a normalized JBI WSDL1.1 message document (defined in the JBI spec), and send that to the PXE JBI wrapper. The PXE JBI wrapper would then pick up this properly normalized message and process it (if you look at the PXE JBI wrapper code, this is currently commented out). Right now this happens to "almost" work, because for doc lit soap messages with a single part, there is not much difference between the SOAP format and the normalized format (aside from namespace). I'm not sure on the service mix specifics, but I imagine there are similar issues there. The future version of the JBI Wrapper will expect JBI compliant messages. -Maciej > 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. > > > ------------------------------------------------------- > 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 >
