Woden
  1. Woden
  2. WODEN-97

When a interface is not referenced from a binding component the getInterfaceFault() method returns null

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Parser
    • Labels:
      None

      Description

      Hi,

      When I use the WSDL of Message-Test-2G and try to get the interfaceFault for a fault thats in a binding I get a null object. The reason is that the binding does not specify a interface. Should woden resolve the fact that the interface referenced by this binding is specified in the service component and return the correct InterfaceFault.

      In my opinion it would be better is woden returns the correct Interface Fault by resolving the reference from the service component.

      Thanks,
      Keith.

        Activity

        Hide
        John Kaputin added a comment -

        Keith,
        all the bindings in MessageTest-2G refer to interfaces. I assume you mean MessageTest-3G, whose binding named SafeEchoHTTPBinding is interface-less.

        Firstly, I want to make sure I understand your requirement correctly. I think the problem you've hit is that you currently have to use the Woden API differently to determine binding information for faults (or operations) depending on whether or not the interface has an explicit binding, but what you would like is to use the same Woden programming model regardless of whether the interface binding is explicit or derived. In other words, if it's derived you would like Woden to make that transparent and give you a common programming model for the binding information needed to build your concrete messages.

        Currently, if the interface is explicitly bound you can just get the Binding component from the Endpoint then navigate down the component API to the Binding sub-components to retrieve their binding-specific extension properties and their associated Interface sub-components. However, for a Service whose Endpoint refers to a generic (interface-less) binding, you need to get the Interface from the Service to get its faults or operations then get the Binding from the Endpoint to obtain its binding extensions properties and then match the Interface components and binding extension properties yourself to derive the appropriate fault and operation binding information.

        Here a couple of reasons why I think we should not change the existing behaviour of the Binding.getBindingFaults() method.

        A goal of the Woden project is to define an API that faithfully reflects the WSDL Component model as defined by the spec, so the existing getter methods in the component API map directly to the component properties defined by curly braces {} in the spec and behave as described in the spec. For example, Binding.getBindingFaults() represents the

        {binding faults}

        property of the Binding component which according to the spec only contains BindingFaults for <fault> child elements of the <binding> element.

        Also, note what the spec says in Part 1, section 2.7.1:

        "Conversely, a Binding component which omits any operation-specific binding details and any fault binding details MAY omit specifying an interface. Binding components that do not specify an interface MAY be used to specify operation-independent binding details for Service components with different interfaces. That is, such Binding components are reusable across one or more interfaces."

        So even if we did change Binding.getBindingFaults() to accomodate derived fault binding information, the potential one to many mapping from Binding to Interface via Endpoint and Service could make the getBindingFaults() method impractical. Remember that a single Binding instance exists for a <binding> element, even if it is referenced by multiple endpoints.

        I guess the existing Woden programming model conforms to the intention of the WSDL 2.0 spec. That is, it's up to the concrete message builder to access the required information from the appropriate part of the WSDL component model, so this information is supposed to be extracted differently from the WSDL component model for explicit interface binding compared to generic binding.

        If the Woden API was to make this transparent then I don't think accomodating derived binding information within the Binding API is the correct approach. If all you want is easy access to the Interface components then Arthur's suggestion of convenience methods on Endpoint would suffice. If actually you want some transparent mapping of Interface components to binding extension properties, then possibly some derived binding helper class retrieved via Endpoint would be a suitable approach, but that might still not give you a common programming model (e.g. if it is not appropriate for this derived binding to be treated as a subtype of Binding). I need to give this more thought. Any comments are welcome.

        Show
        John Kaputin added a comment - Keith, all the bindings in MessageTest-2G refer to interfaces. I assume you mean MessageTest-3G, whose binding named SafeEchoHTTPBinding is interface-less. Firstly, I want to make sure I understand your requirement correctly. I think the problem you've hit is that you currently have to use the Woden API differently to determine binding information for faults (or operations) depending on whether or not the interface has an explicit binding, but what you would like is to use the same Woden programming model regardless of whether the interface binding is explicit or derived. In other words, if it's derived you would like Woden to make that transparent and give you a common programming model for the binding information needed to build your concrete messages. Currently, if the interface is explicitly bound you can just get the Binding component from the Endpoint then navigate down the component API to the Binding sub-components to retrieve their binding-specific extension properties and their associated Interface sub-components. However, for a Service whose Endpoint refers to a generic (interface-less) binding, you need to get the Interface from the Service to get its faults or operations then get the Binding from the Endpoint to obtain its binding extensions properties and then match the Interface components and binding extension properties yourself to derive the appropriate fault and operation binding information. Here a couple of reasons why I think we should not change the existing behaviour of the Binding.getBindingFaults() method. A goal of the Woden project is to define an API that faithfully reflects the WSDL Component model as defined by the spec, so the existing getter methods in the component API map directly to the component properties defined by curly braces {} in the spec and behave as described in the spec. For example, Binding.getBindingFaults() represents the {binding faults} property of the Binding component which according to the spec only contains BindingFaults for <fault> child elements of the <binding> element. Also, note what the spec says in Part 1, section 2.7.1: "Conversely, a Binding component which omits any operation-specific binding details and any fault binding details MAY omit specifying an interface. Binding components that do not specify an interface MAY be used to specify operation-independent binding details for Service components with different interfaces. That is, such Binding components are reusable across one or more interfaces." So even if we did change Binding.getBindingFaults() to accomodate derived fault binding information, the potential one to many mapping from Binding to Interface via Endpoint and Service could make the getBindingFaults() method impractical. Remember that a single Binding instance exists for a <binding> element, even if it is referenced by multiple endpoints. I guess the existing Woden programming model conforms to the intention of the WSDL 2.0 spec. That is, it's up to the concrete message builder to access the required information from the appropriate part of the WSDL component model, so this information is supposed to be extracted differently from the WSDL component model for explicit interface binding compared to generic binding. If the Woden API was to make this transparent then I don't think accomodating derived binding information within the Binding API is the correct approach. If all you want is easy access to the Interface components then Arthur's suggestion of convenience methods on Endpoint would suffice. If actually you want some transparent mapping of Interface components to binding extension properties, then possibly some derived binding helper class retrieved via Endpoint would be a suitable approach, but that might still not give you a common programming model (e.g. if it is not appropriate for this derived binding to be treated as a subtype of Binding). I need to give this more thought. Any comments are welcome.
        Hide
        Keith Godwin Chapman added a comment -

        Hi Arthur,

        for eg take the following code fragment.

        BindingFault[] bindingFaults = binding.getBindingFaults();
        for (int i = 0; i < bindingFaults.length; i++) {
        BindingFault bindingFault = bindingFaults[i];
        InterfaceFault interfaceFault = bindingFault.getInterfaceFault()

        What I'm trying to do is get the interfaceFault referenced by the binding. True that the binding does not specify a interface in this case, but by default it uses the interface specified in the service component which means the binding really has a interface though its not mentioned specifically. So wouldn't it be good if this fact is resolved by woden rather than having a developer navigate to the service component to retrieve the interface in orger to get the interface fault?.

        Show
        Keith Godwin Chapman added a comment - Hi Arthur, for eg take the following code fragment. BindingFault[] bindingFaults = binding.getBindingFaults(); for (int i = 0; i < bindingFaults.length; i++) { BindingFault bindingFault = bindingFaults [i] ; InterfaceFault interfaceFault = bindingFault.getInterfaceFault() What I'm trying to do is get the interfaceFault referenced by the binding. True that the binding does not specify a interface in this case, but by default it uses the interface specified in the service component which means the binding really has a interface though its not mentioned specifically. So wouldn't it be good if this fact is resolved by woden rather than having a developer navigate to the service component to retrieve the interface in orger to get the interface fault?.
        Hide
        Arthur Ryman added a comment -

        Keith,

        What method are you calling? Clearly it doesn't make sense for an interface-less Binding to return InterfaceFaults. Perhaps you have navigated to the Service component. The Bindings only apply to the Endpoint components.

        Maybe it makes sense to add convenience methods to Endpoint components to retrieve related Interface components. Alternatively, you can find the Interface components via the Service component.

        Show
        Arthur Ryman added a comment - Keith, What method are you calling? Clearly it doesn't make sense for an interface-less Binding to return InterfaceFaults. Perhaps you have navigated to the Service component. The Bindings only apply to the Endpoint components. Maybe it makes sense to add convenience methods to Endpoint components to retrieve related Interface components. Alternatively, you can find the Interface components via the Service component.

          People

          • Assignee:
            Unassigned
            Reporter:
            Keith Godwin Chapman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development