Oracle Metadata Services - oramds:/ URIs

Oracle Metadata Services (short: Oracle MDS, or simply MDS) is a proprietary repository delivered as part of Oracle Fusion Middleware BPM Suite, whose purpose is to store the resources (WSDL, XSD, BPMN,...) used in BPM solutions and to make them available to SOA development teams during design time as well as to SOA services at runtime.

The fact that it is proprietary makes the MDS have at least the following caracteristics:

• It is well integrated into the tools suite provided by Oracle: Weblogic, JDeveloper BPM Suite.
• It is absolutely not well (even virtually not at all...) integrated to other technologies (opensource or commercial), so it may become at some point in time a source for vendor locking, making it hard to switch from Oracle SOA solution to any other SOA solution (opensource or commercial).

In my eyes, vendor locking is a risk you have to mitigate when you want to use proprietary software, and concerning the MDS, it is the main risk.
To avoid vendor locking, it is essential to clearly assess your needs in terms of resource repository, development procedures and operations procedure, followed by the evaluation of the tradeoffs you are ready to accept before deciding to use the Oracle MDS.

As with any software technology, what is essential is to understand the interface (as in API, or service contract) of the solution, as your development and operations procedures, tools and files may be impacted by this interface.

So what is part of the Oracle MDS interface? At least the following:

• The interface provided by JDeveloper: this is the integration with JDeveloper, which makes it easy to use the MDS and is the primary interface to the MDS.
• The interface provided by Weblogic (BPM suite): this is the integration with Weblogic.  Multiple MDS services may be configured in Weblogic and may be used by deployments at runtime.
• The files that are shared in the MDS: by default, some file types are modified when stored in the MDS.
• XSD files: these are not modified by the MDS, provided they are stored in the same structure as in your filesystem.  XSD files may import other XSD files.  When you design your XSD files upfront, and store them in a specific filesystem hierarchy, the imports ideally use relative paths.  If you keep the same "directory" structure in the MDS, these imports will not need to be modified.  This is perfectly fine.
• WSDL files: these may import several XSD files.  When you create WSDL files in JDeveloper, and import these into the MDS, the probability is high that JDeveloper has generated the paths to the imported XSD like "oramds:/BusinessObjects/MyObject.xsd".  In my opinion, this is absolutely not acceptable.  Because once the oramds:/ scheme is used in the WSDL, it is almost impossible to reuse the WSDL and XSDs as is with another tool, without modifying them to remove the oramds:/ scheme.
• Eclipse does not understand oramds:/
• Nor does CXF's wsdl2java
• Nor does .Net
• Nor does PHP
• Nor does any other tool
• This looks to me like a very serious source of vendor lock-in.

Nevertheless, there is a simple way to avoid having WSDLs containing the oramds:/ scheme, by adopting a top to bottom approach (WSDL first, contract first):

• Generate your XSDs and WSDLs outside JDeveloper (thus, with Eclipse, XMLSpy, IntelliJ, Notepad++, or any other tool).
• Organize them well in the filesystem folder.
• Copy this filesystem folder inside the "SOA Design Time Repository" MDS instance of JDeveloper.
•  Finally start designing your composites and processes using these WSDLs and XSDs from the MDS.

The WSDLs and XSDs will then be unmodified and will not have any oramds:/ paths.  You'll then be free to reuse the WSDLs and XSDs from any other tool.

For easy sharing between teams, you may also package your resources (WSDL, XSD,...) inside a JAR and distribute it using a common Maven repository.  Developers would then only need to unzip these JARs inside their "SOA Design Time Repository" MDS folder to import them and be ready to use them from JDeveloper.