[jeffdelong]

I think the second options buys the user not having to name his Interface the same as the SY Service Name, which would need to be documented.

On the other hand it limits the user's flexibility by restricting them to having only a single service implement the same Java interface.

[rcernich]

I agree, but I think using the type name is a bad way to go.  If you prefer not to modify the interface name, then I think the user needs to modify the implementation ref to match the service name, which is how things are today.  Honestly, I don't think the way things work currently is that bad, other than the fact that we default everything to the simple type name, which lines up better with the name.  If you're walking through the tools for the first time, this presents a rough edge.  In reality, it's probably more likely that users will change the default name, at least in some instances, requiring them to change the name referenced in their process (assuming they used the import interface functionality).

All of this said, at some point we will have validation logic that will notify the user of any problems (e.g. Service reference "org.example.SomeService" not defined...).

[objectiser]

I prefer the second approach, as Jeff has pointed out it is more in keeping with the spirit of the spec.

In terms of the restriction, if the service (BPM) component carries it's context through to the ServiceTask, then the only restriction is that a single service reference for that component should implement the interface.

[rcernich]

Hey Gary,

I thought interfaceImplementationRef was specific to the implementation type, which is ##SwitchYard in this case, which means it should be the QName of the reference on the BPM component (e.g. {urn:some:target:namespace:1.0}MyReference), for which if you omit the namespace, the application namespace is added.  This is why I said the "right" solution is to specify the SwitchYard service name in the implementation ref.  The problem is that it's also slightly less user friendly based on how the rest of the tools default things.

Prior to being able it import an interface into a bpmn diagram, the user would have had to manually create the interface.  This was regardless of whether or not SwitchYard was being used.  There was existing support for adding interfaces based on WSDL imports, but jBPM does not support adding WSDL imports, so that functionality is unavailable (meaning if you want to reference a service implementing a WSDL interface, you still have to manually define the interface).  Basically, we improved the bpmn editor to make defining interfaces for jBPM processes simpler and now there is an opportunity to make things simpler still.

Best,

Rob

[dward]

FYI everybody, I am keeping up on this thread.  Honestly I'm okay with whatever you all decide is best.  Jeff knows what is good for the end-user, and Rob knows what is possible in the IDE.  So, that's why I'm leaving it up to you guys.  Once you both make a decision together, I'll implement it in the runtime.

[objectiser]

Hi Rob

I guess if implementation is ##SwitchYard then you are right - the QName can be whatever switchyard wishes to use - and if the tooling around it can validate/resolve the correct values, it should provide a good user experience.

However if using the generic ServiceTask, then we could be more generic, and support ##Interface as the implementation - and reference a Java interface. So the process could be independent of switchyard. However when used within a switchyard app, it wires up the ServiceTask invocation based on the service reference associated with the identified interface.

This second approach would require less environment specific customisation of the BPMN2 editor.

Regards

Gary

[rcernich]

Hey Gary,

That sounds like an interesting alternative.  David would have to answer on the feasibility of doing this (whether we can support it in the BPM component and whether jBPM allows us to override any default behavior for ##Interface).  That said, I think this would be an enhancement to the existing BPM component.

Best,

Rob