WS-I is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. Its main purpose is to narrow the originally wide and sometimes vague range of Web service standards in order to achieve instant interoperability of cross-vendor SOA applications.
Currently, WSO2 SOA Enablement Server for Java fully implements the WS-I Basic Profile and the WS-I Attachments Profile.
The WS-I Basic Profile defines an interoperable subset of the core Web services specifications, including XML Schema, SOAP 1.1, WSDL 1.1, and UDDI 2.0. It defines rules on the behavior of contracts in design time and business transactions in runtime.
To ensure WS-I BP compliant applications, the following conditions must hold in the development environment:
There must be a joint effort by application designers and the Web services framework to achieve WS-I BP compliance for Web service applications.
Developers must design their contracts to follow the WS-I BP rules.
The WS framework must let the developers design these contracts the correct way; i.e., it must not place restrictions in their way that would prohibit achieving WS-I BP compliance. The WS framework must also ensure the correct runtime behavior.
WSO2 SOA Enablement Server for Java Framework assists application developers with WS-I BP compliance WSO2 SOA Enablement Server for Java lets developers set up its environment (tools, generators) to produce WS-I BP compliant contracts by default, without any extra effort on the developer side. This can be set at installation by selecting WS-I Compliant (see Figure 2). The defaults can be changed after installation, or the options can be set per instance, as follows:
Wrapped/Literal SOAP Binding/Encoding style Can be set as default during installation or after installation by modifying serverconf.xml and clientconf.xml. For reasons of backward compatibility, you may not want this as the default binding/encoding (see WS-I Compliance). You can set the binding/encoding style for each WSDL you generate by using the Java2WSDL --soap-binding-style and --soap-encoding-style command line parameters (see Table 16, “Basic Java2WSDL Command Options” and also SOAP Binding and Encoding Styles).
SOAP 1.1 protocol Only this protocol is WS-I compliant. This can be set as the default at installation, or you can use the --protocol soap11 parameter with the Java2WSDL tool (see Table 16, “Basic Java2WSDL Command Options”).
MIME attachments Set at the time of installation, MIME should be the default attachment type. If not, you can use the --attachment-type mime parameter with Java2WSDL (see Table 17, “Advanced Java2WSDL Command Options” and also Choosing Between MIME And DIME.
WSO2 SOA Enablement Server for Java executes WS-I BP compliance WSO2 SOA Enablement Server for Java transparently provides runtime compliance, provided the contracts are designed according to the WS-I compliance criteria above.
If you use WSO2 Developer for Eclipse, it offers explicit validation checks of both contracts and runtime behavior. These can be set to check for WS-I BP compliance.
By using certain entities, you lose WS-I BP compliance.
If you use rpc/encoded or document/literal SOAP binding/encoding style, you lose WS-I compliance for backward compatibility.
WSO2 SOA Enablement Server for Java's WSDL for stateful services received with ?allheaders should not be used in runtime, but only in design time.
WS-I BP compliance cannot always be achieved; e.g. when you already have a WSDL defined, etc. This is why WSO2 SOA Enablement Server for Java offers the flexibility to configure its behaviour to support a wide range of application scenarios. However, if you have a non-WS-I compliant solution, please consider migrating it to a compliant version if at all practicable.