WTP WSDL WIzard by default provides support for the Binding types SOAP 1.1 and HTTP.
Now what if users need to provide support for a new binding type.
For example, there is a new soap model (SOAP 1.2) to provide support for new soap operations as defined in wsdl11soap12.xsd
step 1: User needs to create the emf model and generate source inside a fragment project so that this models’s SOAP12OperationImpl can be loaded and called to reconcile the new operation from DOM to EMF Model.
step 2: After ceating the new soap model artifacts, user needs to contibute an ExtensibilityFactory say SOAP12ExtensibilityElementFactory.
It is a -WSDL Extensibility Element Factory- which is registered as a factory for creating custom SOAP extensibility elements. WSDL API will be able to bind SOAP 1.2 Artifacts.
WSDLFactoryImpl creates ExtensibilityElementFactory
step 3: Also the new soap schema needs to be contributed to wst xml contribution so that the xsd doms are loaded in the model dynamically emf models are created from them.
name=”SOAP1.2 Schema Contrbution”
We can create a fragment to add functionalities to its host: org.eclipse.wst.wsdl.ui
At runtime, contributions from fragments are merged into a single manifest and a single namespace of libraries and resources.
We need to create a fragment project to capture the new model features as extension to wsdl.
First we contrbute the new Binding Model Extension.
We need to contribute a Contentgenerator to org.eclipse.wst.wsdl.contentGenerators for the same model namespace “http://schemas.xmlsoap.org/wsdl/soap12/”
Next contribution is org.eclipse.wst.wsdl.ui.contentGeneratorUI to create the UI for the new binding say soap1.2
Either we can refer to existing classes or extend them.
Also need to contribute a nodeCustomization to org.eclipse.wst.xsd.ui.extensibilityNodeCustomizations.
We can use the same org.eclipse.wst.wsdl.ui.internal.soap.customizations.SOAPNodeEditorProvider for the new model or we can extend this class.