In this recipe, we will show how we can create Mediator using an interface definition from a WSDL held in MDS. This approach enables us to separate the implementation of a service (a composite) from the definition of its contract (WSDL).
Make sure you have created a file-based MDS repository for JDeveloper, as described in the first recipe. Create an SOA application with a project containing an empty composite.
This will create Mediator based on the specified WSDL within our composite.
When we import the WSDL in this fashion, JDeveloper doesn't actually make a copy of the schema; rather within the componentType file, it sets the wsdlLocation attribute to reference the location of the WSDL in MDS (as highlighted in the following screenshot).
.
For WSDLs in MDS, the wsdlLocation
attribute uses the following format:
oramds:/apps/<wsdl name>
Where oramds
indicates that it is located in MDS, apps
indicates that it is in the application namespace and <wsdl name>
is the full pathname of the WSDL in MDS.
The wsdlLocation
doesn't specify the physical location of the WSDL; rather it is relative to MDS, which is specific to the environment in which the composite is deployed.
This means that when the composite is open in JDeveloper, it will reference the WSDL in the file-based MDS, and when deployed to the SOA infrastructure, it will reference the WSDL deployed to the MDS database repository, which is installed as part of the SOA infrastructure.
This method can be used equally well to create a BPEL process based on the WSDL from within the Create BPEL Process wizard; for Template select Base on a WSDL and follow the same steps.
This approach works well with Contract First Design as it enables the contract for a composite to be designed first, and when ready for implementation, be checked into Subversion.
The SOA developer can then perform a Subversion update on their file-based MDS repository, and then use the WSDL to implement the composite.