JWT Databinding

Aim

The aim of databinding is to provide to JWT the ability to:

• Deal with orchestration
• Deal with complex types
• Deal with type checking
• To be continued

Thoughts

• Is a workflow action equivalent to a (mathematical) function? That means, is it a component that takes some input, and computes some output?
• We need to be able to know the context (with different scopes?) for any entry of action to make the binding.
• We need to be able to introspect the action to get input and output types. It is easy with WSDL and Java.
• We need a structured databinding to deal with complex types (classes, records, ...). What we specially require is the ability to browse the context and the variables
  • XPath
  • Expression Language
  • OCL (for EMF models)
  • Anything else?
• We don't need to be able to evaluate complex (mathematical) expressions. Smart dereferencing is what we are looking for. However, it could be interesting to statically evaluate the type of guard conditions. (check whether a comparison is valid...). It could also facilitate the transformation of boolean expressions.
• We wouldn't like to use BPEL, however we need something that can easily ve transformed into BPEL.
• It could be good to be able to do static type checking one a binding.
  • May be difficult since the same data type is not the same programmatic type (eg: String for Java, xs:string for XML...)
  • XPath may not be very helpful for this task
• Iterations may be problematic to define a context. Should we be only able to bind on the latest result of an iterated action, or should we be able to bind with the result of a specific iteration?
• Is there a bijection between databindings? If yes, it reduces the risk of making a choice.
• It could be cool to integrate a Talend-like UI for binding:
  • see http://www.talend.com/img/Talend-Open-Studio-v1/tmap.gif
  • Where Left column would be the context, containing all available variables for the current action
  • Database rows would be fields, according to variables' types.
  • Right column would be the set of arguments of the action.
• Should action results automatically global variables, or should they stay "under" the action?

Concrete issues, remarks

Here is the list of remarks that we got when trying to write some code related to web services databinding.

• Should we really generate a SOAP Request from a WSDL, or just introspect the WSDL enough to know types
• Where should appear the SOAP Request => Web Service Action in JWT or generated from a transformation from JWT to ...
• javax.xml.soap and java.wsdl are not really fun to use
• Could we use an ecore model for WSDL and SOAP?
• How to make something that works with SOAP, but whom architecture would also fit to REST

What do we need to call a WS ?

M1 : Identify problems

What is necessary to call a web service?

• WSDL location
• operation name
• arguments << this is databinding

From here, we can get the endpoint and the name and types of operation arguments by introspecting the WSDL (not easy). Then we are able to create the request message.

We currently have a SAAJ implementation that is only able to build a SOAP request from a WSDL describing a "WorkflowService", for the method listUserActivities (or any method that arguments are called arg0 arg1 or arg2).

Main improvement would be to introspect the WSDL file to check the signature of an operation and to generate a request that match the name and the number of the arguments.

How to pass the arguments ?

• method 1 (current): pass an array containing all the arguments. This way, we create the message, and each time we have to put an argument, we put the next item from the list.

The problem is that currently, we are only able to pass "simple" types, but not structured ones. This is not easy to solve since a WSDL can contains sone xsd:schema & co, that are not easy to manipulate with Java.

This method also implies that there is no real type checking, since everything is passed as strings.

Web service action

JWT contains a "Web service Application", that represents a call to a web service. This item inherits from application, that is not an abstract application, but a kind of "Java Agilpro Application". Thus, it would be useful to create an Abstract Application, that would be used to define any concrete application (Java, WS, BPEL, SCA, Human...)