2 Replies Latest reply on Sep 6, 2007 5:22 PM by Alejandro Guizar

    BPEL deployment

    Tom Baeyens Master

      Alejandro,

      Could you explain http://jira.jboss.com/jira/browse/BPEL-275 a bit more for me, please ?

      What artifacts are deployed in what manner to the server ? What is done on the client (= eclipse plugin ?) and what is done on the server ?

      regards, tom.

        • 1. Re: BPEL deployment
          Alejandro Guizar Master

          BPEL-275 is about deploying a WAR file to the server in a portable manner.

          The user must provide the following artifacts:
          A. The BPEL process
          B. WSDL definitions containing the messages, port types, partner link types, properties and property aliases referenced in A.
          C. XML schemas containing the elements and types referenced in A and B.

          The following artifacts are eligible for automatic generation. The user may still want to provide them for finer control of the resulting J2EE port components.

          D. WSDL definitions containing the bindings, services and ports for the port types in B.
          E. The descriptor

          bpel-application.xml
          that specifies the association between partner links in A and the services and ports in D.
          H. The descriptor
          jaxrpc-mapping.xml
          that maps the bindings in D and the port types in B to service endpoint interfaces, plus the elements and types in C to to Java value classes.
          F. The descriptor
          web.xml
          that lists the service implementation beans to be published as servlets.
          G. The descriptor
          webservices.xml
          that links the ports in D to the servlets in F and the service endpoint interfaces in H.

          In the former model A-C were packaged in a process archive on the client and deployed to the jBPM database on the server. E-G were provided by the user. D and H were generated on the client. B-G were packaged in a WAR on the client and deployed to the server.

          The new model is yet to be defined. Now that E-G can be generated, how to provide custom artifacts becomes an issue. I have two approaches in mind:

          1. The client packages A, B and C and any overrides for E-G in a process archive and submits it to the server. The server generates any missing artifacts, builds the WAR and deploys it internally. Upon restart, the server is able to rebuild the WAR because the overrides are stored with the process definition.

          2. The client packages A, B and C in a process archive and submits it to the server. The client generates any missing artifacts, builds the WAR and deploys it to the server. Upon server restart, the server is not able to rebuild the WAR, hence it must not be deleted.

          My current preference is 1, although I have not figured out the file system access issues on the server.

          • 2. Re: BPEL deployment
            Alejandro Guizar Master

            I submitted before previewing... here is the intended post.

            BPEL-275 is about deploying a WAR file to the server in a portable manner.

            The user must provide the following artifacts:
            A. The BPEL process
            B. WSDL interfaces: define the messages, port types, partner link types, properties and property aliases referenced in A.
            C. XML schemas: define the elements and types referenced in A and B.

            The following artifacts are eligible for automatic generation. The user may still want to provide them for finer control of the resulting J2EE port components.

            D. WSDL endpoints: define the bindings, services and ports for the port types in B.
            E. bpel-application.xml: specifies the association between partner links in A and the services and ports in D.
            H. jaxrpc-mapping.xml: maps the bindings in D and the port types in B to service endpoint interfaces, plus the elements and types in C to to Java value classes.
            F. web.xml: lists the service implementation beans to be published as servlets.
            G. webservices.xml: links the ports in D to the servlets in F and the service endpoint interfaces in H.

            In the former model A-C were packaged in a process archive on the client and deployed to the jBPM database on the server. E-G were provided by the user. D and H were generated on the client. B-G were packaged in a WAR on the client and deployed to the server.

            The new model is yet to be defined. Now that E-G can be generated, how to provide custom artifacts becomes an issue. I have two approaches in mind:
            The client packages A, B and C and any overrides for E-G in a process archive and submits it to the server. The server generates any missing artifacts, builds the WAR and deploys it internally. Upon restart, the server is able to rebuild the WAR because the overrides are stored with the process definition.
            The client packages A, B and C in a process archive and submits it to the server. The client generates any missing artifacts, builds the WAR and deploys it to the server. Upon server restart, the server is not able to rebuild the WAR, hence it must not be deleted.
            My current preference is 1, although I have not figured out the file system access issues on the server.