Hi,
Thanks a lot for your answer. So, OK, JBI Normalized Message is supposed to
transport WSDL.
So, let's say I find a way to bind my java objects to WSDL 1.1 (does JAXB allow
this ?). I get something like :
<AllOrders xmlns="uri:com.bptest.types">
<Order>
<OrderId>$sequence$</OrderId>
<OrderType>BookOrder</OrderType>
<OrderDetails>
<BookOrder>
...
Once I have it, I attach this as the NM's payload, right ?
And what you said is that is does not work with the current version yet,
but it will in the future one, right ?
So if I do something the "standard" way, it will work in the future, but not
now, and if I do it the broken way, it will work now, but not in the future ?
Is there a way to make it work now AND in the future ?
Thanks,
Sami Dalouche
Selon Maciej Szefler <[EMAIL PROTECTED]>:
> 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
> >
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
