1 Reply Latest reply on Dec 15, 2005 3:36 AM by Alejandro Guizar

    Question about BPEL process's XML

    Roy Forever Newbie

      Excuse me,
      Since I cannot success deploy my own BPEL process into jBPM,
      even it is valid and executing in other Workflow engine.
      I would like to know the what kind of XML will the BPEL process have.

      1. Cound the WSDL use type for message?

      <types>
       <xsd:schema targetNamespace="http://jbpm.org/examples/hello">
       <xsd:element name="GreetingMessage">
       <xsd:complexType>
       <xsd:sequence>
       <xsd:element name="value" type="xsd:string"/>
       </xsd:sequence>
       </xsd:complexType>
       </xsd:element>
       </xsd:schema>
      </types>
      <message name="Message">
       <part element="my:GreetingMessage" name="part"/>
      </message>
      


      2. Is the WSDL MUST NOT contain any binding or service?
      <binding name="GreetingBIND" type="my:Greeting">
       <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
       <operation name="operation">
       <soap:operation/>
       <input>
       <soap:body use="literal"/>
       </input>
       <output>
       <soap:body use="literal"/>
       </output>
       </operation>
      </binding>
      <service name="GreetingService">
       <port binding="my:GreetingBIND" name="GreetingPort">
       <soap:address location="http://localhost:8080/GreetingService"/>
       </port>
      </service>
      


      3. If the WSDL is possible to have binding, is the binding style MUST be document?
      <binding name="GreetingBIND" type="my:Greeting">
       <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
       <operation name="operation">
       <soap:operation/>
       <input>
       <soap:body use="literal"/>
       </input>
       <output>
       <soap:body use="literal"/>
       </output>
       </operation>
      </binding>
      


      In addition, is the BPEL XML allow using prefix (e.g. bpws:variables)?
      <bpws:variables>
       <bpws:variable messageType="my:Message" name="myVariable"/>
      </bpws:variables>
      


      Thank you very much...

        • 1. Re: Question about BPEL process's XML
          Alejandro Guizar Master

          1. Yes, the problem is that you are using an anonymous complex type. jBPM BPEL itself has no problem with that. The problem is that it relies on the WS4EE runtime. In JBoss 4.0.x, the runtime (JBossWS) uses Apache Axis. Anonymous complex types are one of its known limitations. See this post in the JBossWS forum.

          2. WSDL documents that describe the interface of the services being produced SHOULD NOT contain binding or service elements because they depend on the implementation. From section 3 of the BPEL specification (v2):

          BPEL does not make any assumptions about the WSDL binding. Constraints, ambiguities, provided or missing capabilities of WSDL bindings are out of scope of this specification.

          A WS-BPEL process is a reusable definition that can be deployed in different ways and in different scenarios, while maintaining a uniform application-level behavior across all of them. Note that the description of the deployment of a WS-BPEL process is out of scope for this specification.

          If I understand correctly, the implementation is free to choose the bindings/services exposed and its deployment model.

          This doesn't mean you can't use your own documents to customize the namespace of the binding/service elements, the SOAP actions or the namespace of the RPC operation wrapper element. Just make sure to meet these requirements:
          RPC/literal bindings; document/literal binding support will be available in beta 1
          a single service; this corresponds to the entire process
          one port for each partner link with a myRole attribute; it must implement the port type associated with that role

          Regarding WSDL documents that describe the consumed services, it's completely a matter of style. Consider that they are OPTIONAL during deployment of the process definition to the database, whereas they are REQUIRED upon deploying the web application to the app server.

          3. For produced services, the opposite is true. The style MUST be RPC (for now - see above). Consumed services can use either the document or the RPC style, but MUST NOT make use of encodings.

          Last question: see the other topic. you created.