bpel domain model for wsdl and schema

[tom.baeyens]

The bpel process will have to contain wsdl and schema data structures.

We'll use wsdl4j to parse the wsdl's. But to store them as part of the bpel process definition, we'll have to make this data persistable. Either by making the wsdl4j objects persistable (with JPA?) or by creating our own persistable version of the wsdl information.

For schema's, i know they can be used indirectly by the parsers. Afaik, such a model is not available in the JVM. But i don't know of a good open source implementation is available. If you know one do you also know, if is it persistable with JPA ? Also here, the alternative is to build our own model for that.

How did you guys handle that in your previous bpel implementations ?

[csouillard]

In the previous release, we made the choice to manipulate variables in java. So we were using Java Bean representing schema types. We did'nt had a validation activity.

[tom.baeyens]

"csouillard" wrote:
In the previous release, we made the choice to manipulate variables in java. So we were using Java Bean representing schema types. We did'nt had a validation activity.

does that mean that you had your own object model to represent the WSDL information ?

how was that persisted and related to the bpel process definition ?

what about the schema information ?

[tom.baeyens]

i just checked alejandro's code and if i read it correctly, he extends the wsdl4j to make it persistable with hibernate mappings.

i'll see if i can find the schema things as well in there to see what approach we took there.

[aguizar]

We'll use wsdl4j to parse the wsdl's. But to store them as part of the bpel process definition, we'll have to make this data persistable. Either by making the wsdl4j objects persistable (with JPA?) or by creating our own persistable version of the wsdl information.

We used mapping documents to persist the relevant properties of JWSDL interfaces. For associations, the code uses JWSDL interfaces yet the mapping documents reference WSDL4J implementation classes.

Earlier versions extended WSDL4J classes to add an id field. Only recently I became aware of Hibernate's ability to manipulate objects without identity properties. The latest version actually maps WSDL4J objects directly.

For schema's, i know they can be used indirectly by the parsers. Afaik, such a model is not available in the JVM. But i don't know of a good open source implementation is available.

Currently we do neither static analysis nor runtime validation of XML Schema definitions.

Jason Greene of the WS team pointed me to XSOM, the XML Schema model used by the JAXB RI. Making XSOM objects persistable should be similar to the approach we took with WSDL4J.

Note that XSOM is only useful for static analysis. Runtime validation is the job of the JAXP validation APIs.

[aguizar]

"csouillard" wrote:
In the previous release, we made the choice to manipulate variables in java. So we were using Java Bean representing schema types.

How did you implement XPath expressions? Apache JXPath?

Further, how do you persist variables? Do you require users to provide O/R mapping metadata?

We did'nt had a validation activity.

This brings up the question of what should be the representation of variables in the new release in order to support validation.

One possibility is represent them as xml fragments and let the user provide JAXB-annotated classes. Java binding is performed only when the object value of a variable is needed, e.g. when invoking an EJB-based partner service.

Another possibility is dual xml/java representation, performing conversions internally as needed.

[csouillard]

"How did you implement XPath expressions? Apache JXPath? "
JXPath + Jaxen

"Further, how do you persist variables? Do you require users to provide O/R mapping metadata? "
Variables bean were set in an EJB field.

"Another possibility is dual xml/java representation, performing conversions internally as needed."

I think the best way is to manipulate xml everyWhere. There are more open source tools to manipulate xml and there less bugs in them than in java/xml mapping tools...
We had a very bad experience using such conversions... Then you need to manage java primitive types and a lot of other problems !