I am cc'ing tunscay-users since this seems to be interesting to users and they may not be on the dev list.
Thanks Mike. On 5/17/08, Mike Edwards <[EMAIL PROTECTED]> wrote: > > Folks, > > I've just committed some changes to the implementation-bpel and > implementatio-bpel-ode code in trunk which fix some issues relating to > exposing BPEL processes using Web services (and other remote protocols). > > These changes have an impact on the content of the deploy.xml file that is > associated with your BPEL applications. In order to work correctly, you > will need to ensure that your deploy.xml file corresponds to the following > pattern: > > > <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"; > xmlns:tns="http://helloworld"; > xmlns:helloworld="http://helloworld"; > xmlns:greetings="http://greetings"; > xmlns:tus="http://tuscany.apache.org";> > > > <process name="tns:HelloWorld"> > <active>true</active> > <provide partnerLink="helloPartnerLink"> > <service name="tus:helloPartnerLink" > port="HelloWorld"/> > </provide> > <invoke partnerLink="greetingsPartnerLink"> > <service name="tus:greetingsPartnerLink" > port="Greetings"/> > </invoke> > </process> > </deploy> > > > You must ensure: > > a) Each partner link in your BPEL process is declared using either a > <provide.../> (for a service) or using a <invoke.../> for a reference. > > b) Each <provide/> and <invoke/> must use the partnerLink name, as declared > in your BPEL process. > > c) The <provide/> and <invoke/> elements each have a single child > <service/> element. The <service/> elements have name and port attributes. > The NAME attribute MUST be set to the same name as the partnerLink and MUST > be prefixed by a prefix which references the namespace " > http://tuscany.apache.org"; ("tus" in the example above). The port > attribute can be set to any name (it must be present but it is not actually > used for anything significant). > > > Sorry for forcing this change on you all, but the previous version of the > code had a mixup over the name of the services and references as used by the > ODE BPEL engine - this change fixes that problem. > > > In the next week, we shall aim to remove the need for the deploy.xml file > entirely. All the information in the file is already known to the Tuscany > code - either we shall generate the file dynamically, or - ODE willing - we > shall pass the information to ODE in-memory, avoiding the need for a file at > all. > > > You will find that the BPEL Sample applications and the BPEL iTests have > been adjusted to use this new format for the deploy.xml file. > > > Yours, Mike. >
