Which WSDL elements are required (Oracle SOA Suite)

Question

I am trying to understand the .wsdl files generated by JDeveloper in SOA Projects. I noticed that they tend to only contain the types, the portType and the message elements, not however the service or the binding element.

Then I checked the WSDL Schema definition at http://schemas.xmlsoap.org/wsdl/ and noticed that binding and service were both 'key' elements of the wsdl definitions element. Does this mean that service and binding are required elements? If so, how come they are not included in JDeveloper/SOA Suite WSDL files?

[Update]

O.k. I found a partial answer to my question. It turns out when you access the WSDL file via the URL, the binding and the service element are in deed included.

Can anyone provide any more in-depth background information about:

1. How this happens?
2. Why this is done?
3. If (2) is because you want the concrete definitions of your WSDL to be hidden from the developer and handled dynamically by SOA Suite: Concrete examples of how this dynamic binding works and is used in real-world applications... ?

Answer 1

What you see generated is the abstract WSDL which are the minimums required from a functionality perspective. Datatypes, operations, etc. are all in there.

What you are looking for is the concrete WSDL which specifically defines how to access a particular service (Location, protocol, etc.). This is more of configuration/deployment concern from the SOA Suite perspective.

To shortly answer your questions;

1. If a client needs the concrete WSDL, SOA Suite generates the concrete WSDL definition on demand (This is mandated by the WS binding specification). If a client makes a call that is according to this concrete WSDL, SOA Suite knows how to resolve the call to your service.
2. Basically, you only define the functional parts of your service and leave the details concerning access to SOA Suite. After all, these are highly dependent on deployment details. Therefore, your services become a bit more decoupled from the physical details.
3. This is the SCA way of doing things. From a consumer perspective, the experience is not really different. They can look up the concrete WSDL just as any other service.

From the developers perspective, one should remember that we are in the SCA world. Inside the SCA domain, bindings are used for exposing services or referencing them inside the composite. It is only when one wants to expose the service outside the SCA domain, these bindings are translated to conventional WS standards.

For more information you can see the WS binding standard at OASIS. http://docs.oasis-open.org/opencsa/sca-bindings/sca-wsbinding-1.1-spec.pdf