0 
0 Before I talk about the advantages en methods of using the MDS, I want to introduce myself, because this is my first public post on the AMIS technology blog. My name is Robert van Mölken and I’m 26 years old. I’m now actively working, as a SOA Consultant / Developer, for nearly 5 years. My main toolstack is SOA Suite (3,5 years 10gR3 and 1,5 years 11gR1), but also have experience with opensource BPEL / ESB alternatives from Apache.
In many big SOA application all the composites use the same canonical1 data model (message definitions) for their service contracts. Many entities and elements (complex- and simple types) are reused. Therefor it is not a good choice to use a local copy for the service contracts (WSDLs) and message definition files (XSDs) in each SOA composite project.
If you do so and a mayor (common) part of the message definitions changes then you need to update all the SOA composite projects, where these files are used, with the new version of the files. Oracle created the MDS to solve this issue. MDS stands for MetaData Services. The MDS holds all kind of xml-based files, like WSDLs, XSDs, Domain Values Maps but can also hold fault policies and event definitions (for Event Delivery Network).
There are two versions of the MDS; a file-based and a database version. The file-based version is being used as a local MDS for development and can be saved in a subversion repository, which every developer then can use with their own working copy of the repository.
The database version is being used as a remote MDS. A SOA server instance, running on Weblogic server, uses its own database MDS and can’t use a local MDS. So for every successful implementation of the MDS we need to create both a local as a remote MDS.
Local directory structure for MDS
The first step is to create a local directory structure where we can place our message definitions. The base structure needs to implement an apps folder on the highest level of the MDS seed folder. A seed folder is the name that Oracle uses for saying root folder. I will give an example of a directory structure I use in general. Sources of example are at end of article2.
 | Create a directory mds-store in the root of you’re working copy (preferred a part of a SVN of GIT repository).Create two directories within the mds-store folder, build and soa-infra.build folder contains build en configuration files to deploy a local MDS to a remote MDS. The soa-infra folder is the seed folder and will contain the main structure where the xml-based files resides in.In the seed folder there always needs to be a apps directory. Within this apps folder create one application folder of each mayor application that uses the same definition. |
| How the internal structure of an individual app looks like is up to the person that designs the service contracts, but for use the upcoming example I will show you the structure that was used on my last project.Per BO there is a subfolder with the name of the BO. Per version there is another subfolder. A new version begins if the structure is really different and not compliant with previous version. The filename of the XSD is the same as the BO.The Core folder has three subfolders; Common and CommonBO and Faults.In the Common folder XSDs reside that holds common types and elements and metadata XSD for the service header and status types.In the CommonBO folder you will find BO that are used by others XSDs and are thereby reusable. The Faults folder holds a XSD which described the available SOAP Faults. The WSDL folder holds the webservice contracts for all the services. A WSDL will import the corresponding Message XSD and the Faults XSD. The Messages folder holds the XSD definition files where the request and response messages are defined in. |  |
Create resource connection to local MDS
Before the resources from our mds-store resource directory can be used the first step is to configure the connection to the local MDS directory.
Open JDeveloper, in the Resource Palette click on the 
button for creating new connections and select the item New Connection a SOA-MDS. A dialog “Create SOA-MDS Connection” will open. Click on the radiobutton IDE Connections if it is not choosen on default. Enter as Connection Name Local{Project}MDS where {Project} holds the name of the project you’re working on.
Select under Connection Type a File Based MDS for creating a connection to a local MDS and browse to the root of the MDS on your filesystem. The root of the MDS is the directory called mds-store and click on the seed soa-infra.
Why not mds-store? Because a MDS connection is always to a seed directory. Our seed is a reference to the soa-infra partition of the DB based MDS.
Back in the connection window click on the 
button  to the if the directory is accessible. If correct the test connection gives a success message. Click OK to save connection.
Create resource connection to remote MDS
If you want to be clear if your local MDS is fully sync with the remote MDS of the SOA server also create a resource connection to the remote MDS. A remote MDS is a special database schema that holds the same data as a local MDS, but the files are not saved in a binary way.
In the Resource Palette click on the button for creating new connections and select the item New Connection -> SOA-MDS. A dialog “Create SOA-MDS Connection” will open. Click on the radiobutton IDE Connections if it is not choosen on default. Enter as Connection Name Remote{Project}MDS where {Project} holds the name of the project you’re working on.
Select under Connection Type a DB Based MDS for creating a connection to a remote MDS. In the connection dropdown a list of database connections is presented. If you never created a connection to the remote MDS of your environment you won’t find the correct connection in the list. If so you need to create a new database connection to the MDS schema of your environment.
Click on the 
icon at the right side of the dropdown to add a new connection. A dialog “Create Database Connection” will open. Click on the radiobutton IDE Connections if it is not choosen on default. Enter as Connection Name {Project}SOAMDS.
Select the correct Connection Type for the database you are using. At AMIS we generaly use Oracle (JDBC). Specify the username with the name of the MDS schema (e.g. dev_mds)and the correct password. At last we need to change the setting of the JDBC URL. Specify the Host Name, SID and JDBC Port of the database instance where the SOA repository is present.
Click on to check if the settings are correct. After success click OK.
Back at the “Create SOA-MDS Connection” dialog it will be refreshed and the database connection we just created is selected. Also the list of MDS partitions is refreshed and contains some options.
In the Select MDS partition list select the option soa-infra.
Click on to check if the settings are correct. After success click OK.
Both MDS connections are now configured and displayed in the Resource Palette under SOA-MDS. If you expand to the Local{Project}MDS and Remote{Project}MDS, you will that the have both different folders. The local MDS has two apps defined, but the remote MDS has an empty apps folder.
To browse, open and edit the file in de local MDS, create a SOA application and project MDSLocalStore and use the mds-store folder as the base directory, so that both JWS as JPR file are placed in the same folder.
Synchronize local with remote MDS / deploy to MDS
Before you can deploy a SOA composite that uses WSDLs and XSDs from the MDS you need to synchronize the new files in the local MDS to the remote MDS of the server. To do this simple and quick it is better to use ANT build scripts to successfully deploy the correct resources.
Open the application file MDSLocalStore.jws, that resides in the mds-store directory, that you just created. You can open this file by select File -> Open and browse to the mds-store folder and selecting the file. The application looks something like this if you opened it:
There are three files in the resources folder. build.properties holds the global properties like build directory, environment settings and which applications to deploy that resides in the local MDS.
The last property defines to which server environment we will deploy to and which env file is used.
Then you have the env.{env}.properties file. This file contains the server settings of the specific server environment. The build file uses the one that represents the deployment.env value.
We’re now ready to deploy to our remote MDS. Right-click on the build.xml file and select the option: Run Ant Target -> deployMDS. This file can also be run on the command line or by a build server.
If everything is setup right the resources are deployed to the remote MDS.
In part 2 i’m going to describe how to use the MDS in SOA composites.
References
1 Basic, canonic, canonical: reduced to the simplest and most significant form possible without loss of generality, e.g., “a basic story line”; “a canonical syllable pattern.”
2 Download the sources here, including deploy scripts. It is based on deployment script of Edwin Biemond and part of Emiel Paasschens
Related posts:
(2/2) Using the MetaData Services (MDS) in a SOA environment 
Proces email with the new UMS adapter of SOA Suite PS5 
Kom kennismaken met AMIS en doe mee met uitdagende projecten 
Using Oracle’s Edition-Based Redefinition to support multiple SOA Suite revisions with the database adapter 
SOA Suite 12c: Deploying shared artifacts to Run Time MDS – the official approach and the quick short-cut
It was deleted after the move. Put up a different version as an example.
Hi,
nice post!
Sadly the sources are no more downloadable could you update the link.
Tnx in advance!
Very well explained Robert. Very useful. Thanks for the effort. Good luck on part 2 (and beyond).
Lucas
Great work in sharing your Knowledge.
I see that your using my mds scripts and that you add some extra code which changes the endpoints in the wsdl’s
Beware aware that you also need to do this for acceptance and production.
A better approach is remove this endpoint code keep the generated sar files, deploy these to acceptance etc and use deployment plans on the composites , to override the endpoints .
Then you know for sure that the same code exists on acceptance and production.
thanks Edwin
Â
Â