Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] JWT and orchestration / web services / databinding 
Hi Florian

As a follow-up to "web service" mail :

Here at Open Wide we want to allow JWT to handle the orchestration paradigm.
This is required to support orchestration languages like BPEL as an export language (in addition to the JWT2BPEL transformation).
You can look at business processes using two opposite but complementary point of views : workflow and orchestration. When using a workflow processes, there is a state (current task and properties) that you might want to inquire, change, or be noticed of its changes, all this using well defined APIs (services). On the other side, a service orchestration process will do successive, explicit calls to user-defined / custom / business / domain specific services.
Being able to call any kind of service, having only its definition (typically WSDL in the WS case), is therefore critical to orchestration. In the WS case, this implies to be able to fill XML / WS messages using process data / properties / variables - in JWT, mapping JWT-typed Data to the parameters of a future WebServiceApplication. This is the databinding problematic, and we at Open Wide want to address it.
Note that if databinding is available with Java or WS, we can additionnally use SCA technology and SCOrWare software to be able to do orchestration with any kind of service (Java, RMI, EJB, REST / json, JBI / ESB...).
Mickael and I have started working on this generic databinding issue, and our goals are * to have the principles of a generic databinding solution between the JWT metamodel and WS or Java services. Ideas : using XML databinding, or XSD - Ecore - Java databinding. * including features that help the user (ex. dataMapping, why not using an expression language) * and how transformation to executable process formats may handle it (the simpler the better, some will work out of the box, ex. ATL with EMF compatible databinding, or XSL with XML databinding) * to be sure it is generic enough to support the main formats (BPEL with WS, XPDL in the specific cases of WS and Java code). Without this it is worthless. * to have technical specs of a working solution at runtime (i.e. be able to call a given WS using JWT-defined data), including the business service part (especially using the CXF WS engine, and the PVM BP engine) 

I'd very much like all of us to work in good sync ! So :
* please find a phone to call me ^^ (not this monday or tuesday, SCOrWare meeting) * what are you currently doing about WS in JWT (especially metamodel), what is doing Christian Saad (as you said) ? * what environment are you working with, where are the touching points we should standardize on ? (ex. should be able to work with jBPM, should ) * what about datamapping using a "generic" expression language ? NB. I think full scripting would be too much engine-specific, but why not... 

Regards,
Marc

Florian Lautenbacher a écrit :

Hi all,

sorry, I try to answer most of the current threads in one email - I guess
that makes it easier for everybody to follow the discussion.

Concerning the CVS directories layout and future components it would be good
to have a discussion on the phone. But, as you've already heard I moved to a
new office in the last week, so it will take few more days till I got a new
phone - I'll contact you asap (hopefully already on Friday).

Concerning applications with Web Services and data binding / data mapping
issues:
this is one part which didn't receive much attention in the JWT metamodel
till now. There, in the JWT metamodel [1], Figure 11 you can see that there
already exists the concept of DataMapping. At the beginning we thought that
not the data as a whole will be described, but in parts. So one data
consists of several parameters and these parameters can then be bound to the
parameters that an application needs. Alas, it is not used as we thought
about it at the beginning: applications are defined without parameters as
well as data, so the data mapping is now quite difficult. Maybe this should
be a point, where the metamodel should be changed in order to reflect the
current usage of the models: there can be several data, but only one
application (with several parameters) and the data needs to be bound to the
parameters of the application.
A Web Service is simply a subclass of an application - having other
properties than the normal application (here the metamodel is probably going
to be changed, too, thanks to the work Chris Saad is doing at the moment).

About your description of AgilPro: yes, thank you, everything was right.
Additionally, it is not necessary to use the Simulator, but one can use the
AgilPro Executor instead (but this one is sadly not open-source) in order to
execute the process model which was generated to a web service orchestration
and to invoke web services instead. This is part of the AgilPro Integration
framework, which has been developed by our partner eMundo. Maybe Claus can
give some further explanation here?

Concerning the Action extension: I gave a rather short explanation on bug
225704, much more text was exchanged between Annette (who is working on that
issue) and myself via eMail (but in German, sorry). If you have some further
ideas (I guess so, since you are now much more familiar than I am with
Dynamic EMF), please feel free to extend the explanations given there or
modify them. Or simply let us know via mail, Annette is probably following
our discussion on the newsgroup, too :) Probably we'll integrate the
ExtensibleAction in the metamodel, too, and make this class an Extension
Point for other plugins.

Best regards,

Florian

[1] http://wiki.eclipse.org/images/2/2f/AgilPro_MetamodelDescription.pdf


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: 23 April 2008 14:37
An: Java Workflow Toolbox
Betreff: Re: AW: [jwt-dev] Extending the JWT Editor with Extension Points?

I think we're getting somewhere at the end ^^


See below, inlined in the text.

Ralph Soika/IMIXS a écrit :

Hi Marc,
yes I agree with you in the point of the idea with ExtensibleAction model object:
* A solution would be to add an ExtensibleAction model object that would have one (or more ?) untyped subnode. In this case, it would be very close to Ralph's embedded XML extension idea - actually, if we define the extension using XSD to ecore, it would even be the same.
And I agree also to you to allow more then one untyped subnodes. As different vendors can support different extensions for one Action or ActivityNode. 
I agree
So which ones - Florian, you and your JWT metamodel specialists are highly welcome ! 
  * Action obviously,
  * but why not Application instead,
  * and what about ActivityNode ?
  * DataType ?
* I'm still not sure there are no "out of the box" extensible ones, maybe DataType is ? 
  * others ?

In this question I would propose Action and also ActivityNode.
What did you mean with "Application". An extension mechanism for application specific or workflow engine specific data would be helpfull in some cases. So the Imixs IX Modeler holds informations like the WebService Endpoint from the Engine. This is configuration stuff. But why not allow a vendor to extend such data. 
If you take a look at following picture you can understand what I mean:
http://www.imixs.org/websites/imixs-org.nsf/vResourcesNameLookup/Workf
lowModeler.ScreenShots/$FILE/image_small_01.gif

In the JWT model, an Action is a single process step that provides its
parameters to a globally defined Application to perform some work. Note that
an Action is not required to be linked to an Application, in which case it
is a "manual" Action (i.e. that must be explicitly started and terminated by
a user or administrator at runtime).

Applications are for now mainly used by AgilPro's jBPM-based Simulator to
perform tasks using applications like Word, Excel, web pages within a
browser. That's why for now creating its own application means coding it in
java first.

We're currently working on applications defining the call of a WebService
and of an SCA service. This also requires to handle well databinding /
datamapping issues.
The main editor is implemented as a multipage editor and a Vendor can extend the editor with an additional pages (like the JBoss page in the picture). This page holds application or engine specific data. 

Is this compatible with your approach Marc?

best regards
Ralph




I think it is, and with Florian's !

Regards
Marc
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

Back to the top