As I said during the F2F meeting today that I would write up a
discussion of WSDL generation, here it is:
Since I'm doing this late at night, I expect that I'm not going to be
crystal clear on all points, so I expect that we have to discuss this
further to make sense of the following.
First question: What are the potential use cases for a generated WSDL?
- Design-time - allow the generation of concrete "binding" elements.
Since this is at design-time, it does not make sense to generate "port"
elements since the concrete details are not known, and it follows that
it does not make sense to generate "service" elements. With this
generated artifact, only the binding.ws/@wsdlElement #wsdl.binding
variant makes sense. This is potentially a convenient way to capture
binding details.
- Runtime - Here a fully concrete WSDL can be generated. In this
case, the WSDL is being generated for consumption by a WSDL via a
concrete reference, most likely to a port or endpoint.
- Same domain, different deployment - WSDL generated for the
convenience of monitoring and management tools, and deployment process.
- Same-vendor cross-domains - Vendors can use whatever WSDL
generation they choose, and whatever extensions they choose.
- Cross-vendor cross-domains - For this case, vendors will likely
stick to known conventions/standards, such as WS-I Basic Profile. We
could possibly add some additional "signals" in the generated WSDL to
facilitate using SCA concepts between different vendors.
Second question: By standardizing WSDL generation, what benefits do we
accrue to any of the above use cases?
Not going to try to answer that question yet - wanted to get the
question out there.
Third question: What makes WSDL generation so hard?
Perhaps cheating by not spelling out the issues, but a bullet list:
- WSDL 1.1 vs. WSDL 2.0?
- Conform to WS-I BasicProfile? What about SecurityProfile
- Where does WS-Policy information go?
- Are schemas inlined? Or do they get put in separate files?
- Declare SOAP w/attachments or MTOM with the resulting WSDL, or do
you punt on binary data optimizations?
- Which version of SOAP?
- What if the interface for the service is specified in WSDL 1.1
and WSDL 2.0 needs to be generated, or vice-versa?
- What if it isn't possible to convert from one form to the other
(or at least not obviously, easily, or unambiguously)?
- How many WSDL constructs do you put in the same document, and
why? Only one service per WSDL - why that limitation?
- Assuming that the interface is specified with interface.wsdl,
does a concrete WSDL document reference or inline that interface WSDL?
- And what if it cannot, because that interface is in a different
namespace?
- More generally, do we want to separately generate and reuse files
for abstract and concrete parts of WSDL?
- What sort of SOAP messages do you want - doc literal, or other?
Of course, the current text attempts to handle some of these issues.
Circling back to the second question, picking apart the identified use
cases:
- Design-time - as near as I can tell, generating bindings is
probably useful. However, as this is likely at design-time within a
single vendor's tools, I'm not sure what value standardization brings.
Further, if an implementation can always generate this data in the same
way based on specified intents, existing conventions (WS-I BP) and
available data about an SCA service, then clever tooling on the part of
the vendor can make this a fully automated step.
- Same domain deployment - WSDL ideally fully invisible to the
customer.
- Runtime - Cross-vendor - others have already generated reams of
paper aiming for interoperability here. I think it is out of scope for
the bindings TC to attempt to refine what can be done here. One
exception - if we think we can "signal" to an external domain about SCA
specific features. However, I think that can be accomplished by
narrowly specifying those specific extensions to WSDL that we think we
need to document, not by full-fledged WSDL generation.
- Runtime - Same-vendor - no value. Possibly harmful, as we could
make assumptions that a vendor then needs to work around.
My conclusion: For consistency across vendors, and as an aid at
design-time, at most it may be useful to have an exemplary discussion
of how to generate WSDL bindings, and discuss the complexities
mentioned above.
-Eric.
|