OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Considering WSDL generation

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]