| AW: [jwt-dev] Data binding & co |
Hi Mickael, >>And I now think that Application should be more abstract to fit with SOA principles. Yes, I agree. Application contains now a lot of properties that do not fit with all kind of applications (e.g. JAR-archive is not applicable for web services). We like to restructure that, but this means as a consequence that the whole converter as we have it now, needs to be restructured. We always want to be able to load older models and to be downward compatible. Until now we only added parts to the metamodel but we never removed parts. So, this requires a new handling in the converter to cope with non-existent parameters or classes during the load process. >> Is there a wey to define complex types with JWT? I took a look at the doc about AgilPro models, I didn't understand well whether it is possible (There is a link between data and parameters that makes me think something is possible, but I an not sure of my interpretation). Complex types like what? Like they are defined in WSDL? E.g. having an adress that consists of a street:String, town:String and country code:integer? Yes, that would be possible with data and parameters (having adress as a data and street, town and country as paramters). However, if you'd like to have a complex data in another one (person consists of name, first name and adress and adress as described above) then currently JWT can't cope with that anymore. Here, a change to the metamodel might be necessary again. However, we assumed that the WSDL file fully existed when generating the BPEL code, so the problem described above does not appear. So, you can describe a web service as an application that needs parameters (input and output parameters). Additionally, you have some complex data with parameters, too (those are not visible in the graphical editor) and then you can bind one to the other. See a simple sample attached: Here we have two actions. At the first one WebService1 is invoked which has 3 output parameters: town, country code and street. This is written to the data "Adress" which has itself three parameters: city, country code and street. Through the data binding it is specified how town maps to city. Have especially a look in the outline view where all the parameters can be seen and the data binding (which is currently not visible in the graphical model!) is specified. Hopefully that helps a little bit. Currently this is somehow complicated to create - any ideas on improvement are welcome! >> Do you have some informations about the JWT2BPEL transformation? Do you deal with types that are not "JWT-native"? Do you have some samples? Attached please find also a sample BPEL-file which has been created using one of the samples of JWT/AgilPro. You can see that the BPEL-generation is customized to the needs of the integration framework and the underlying jBPM-engine: every data and every application results in an own <invoke> in BPEL, first specifying which data exists and which application shall be invoked and after everything has been initialized the application is finally executed. Afterwards all output data are gathered (again via <invoke>s) and the next action is initialized. Hope that helps in the first place. Best regards, Florian
Attachment:
DataBindingExample.workflow
Description: Binary data
Attachment:
Standardpalette.bpel
Description: Binary data