I tend to think of the operations defined in a WSDL as just another type of building block from which to create workflows/action. Yes, some additional intelligence is required, but no more so than is already required to piece together actions or cli calls, or whatever other building blocks are required to construct a workflow.
I guess there is a slightly grey area of responsibility between the plugin developer and the VMO admin who is creating workflows. I can certainly see a plugin developer using SOAP internally within a plugin to build higher level constructs to expose to VMO. But on the otherhand, I can also see a WSDL that already defines high level operations that can be exposed directly in VMO without the need of a "higher" level interface. Does that make sense?
I can imagine a plugin that just exposes a SOAP interface would need the following
- An interface through which soap operations can be called
- Classes for the schema elements/types used by the operations
Obviously, with a Java soap toolkit like Axis or CXF, you can generate get these for Java automatically.
But, to expose them in VMO, you have to somehow provide a vso.xml that defines the types. I can imagine that a plugin developer would try to generate this vso.xml file automatically (from either the WSDL, or the toolkit generated bindings). It seems like this logic would be common to any plugin trying to expose a WSDL directly, and could therefore be implemented in a common fashion by VMO itself.
