-
1. Re: BPEL deployment
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 descriptorbpel-application.xml
that specifies the association between partner links in A and the services and ports in D.
H. The descriptorjaxrpc-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 descriptorweb.xml
that lists the service implementation beans to be published as servlets.
G. The descriptorwebservices.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
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.