Fair enough, I was trying to confirm my assumptions.
+1 to the camel handler :)

On Wed, Aug 1, 2012 at 9:50 AM, Maciej Swiderski <mswiders@redhat.com> wrote:
More comments inline :)


On 31.07.2012 21:04, Mauricio Salatino wrote:
Comments inline:

On Tue, Jul 31, 2012 at 7:52 PM, Maciej Swiderski <mswiders@redhat.com> wrote:
Thanks Mauricio, comments inline

Maciej


On 31.07.2012 19:45, Mauricio Salatino wrote:
Hi Maciej,
Kudos for the post! It's a really nice example. 
I have a couple of questions about parameters to the invocation and how we can process the results for the invocation.
What are the limitations for such constructs?
First limitation, in general is that WSDL is stored in process definition which makes moving between environments (dev, test, qa, prod) bit difficult but from the other hand it alows tooling to build up interface and operation definitions. Comments welcome here :)

Fair enough, I know that is a common limitation, everything will be generated dynamically and that's how the interaction will work. We should look on how to integrate the CXF endpoint provided by camel to the current handler implementation. Using camel you can build your transformation routes.
I think that we should introduce new handler for camel integration as camel can do much more than just web services. This handler is simple service task that can invoke soap operations.

Most of the solutions out there provide XPATH for mapping different pieces of information, and that's definitely something that will be required if the user wants to integrate against legacy web services.
Difference here is that for invocation handler expect that it has correct message to be sent out. What you had in mind could be probably covered by assign/transformation on data association level in bpmn2 model. But if you think that is not enough we could elaborate bit more to see what are the use cases.

I would love to avoid adding information to the process model about more complex data mappings or external services.  
A simple use case for this would be, we have 3 process variables inside our process scope, we want to call a service sending a variable of type Car and a variable called Person to an external service, can those two variables be mapped to an external service which receives both parameters? the same for the results. We get a type, but we need a way to map to our process variables.
With service task you can have only single parameter - message - so operations should be single (document based) services. But of course you could grab those two variables from process and assign them third one (the message) using data inputs and data association. In general it is work item handler so it accepts parameters and will do whatever is needed with them.
 
What about async executions? is that being handled by CXF?
Yes, this is handled by CXF, when invoking the operation you could provide callback to get result once they are ready.


Nice! we need a generic way for that :)
Cheers

On Tue, Jul 31, 2012 at 4:38 PM, Maciej Swiderski <mswiders@redhat.com> wrote:
Hi guys,

as promised some time ago here comes a link to a post about web services
support for service task in jbpm5:
http://mswiderski.blogspot.com/2012/07/service-task-with-web-service.html

If you have some time to read it through and maybe even give it a try I
would be more than happy. And all your comments are valuable.

Maciej
_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev



--
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar
 
 - Salatino "Salaboy" Mauricio -





--
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar
 
 - Salatino "Salaboy" Mauricio -





--
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar
 
 - Salatino "Salaboy" Mauricio -