Storing SCA Metadata in the Oracle Metadata Services Repository

The concept of code hot deployments in application server world still remained with if's and but's w.r.t service availability of 24/7 requirements. Especially in the arena of EAI service upgrades where one would like to upgrade one or a group of selected service interfaces without disrupting other services in the EAI/ESB umbrella seems to be a more challenging than thought and also a complicated approach to achieve without a server downtime or a proper planning around it during release cycles and this poses lots of concerns on code resusability if we adopt a code redundant architecture approach to solve this which obviously increases the complexity w.r.t maintainability and manageability of code and services in a long run. So, basically, its almost impossible to provide an out of the box feature by any EAI product on proper versioning strategy for services or group of components (SCA), or a logical domain of SCA's to cater all type of requirements but it is us who needs to understand and design components that uses the common artifacts/resources which are typically shared by set of components/SCA's that are part of different service interfaces.

In the current emerging trend, the vendors or designers have started putting common artifacts like wsdl,xsd's,rules,dvms,xsl's,xslt,etc into a common shared repository store and this repository store is exposed as a service or meta data service (MDS) to be used by an deployed components or SCA's in a clustered environment or distributed environments at runtime or a design time. This MDS service is typically deployed as a SOA bundle and components/SCA will be designed to access the common artifacts from the repository via custom protocol or using http url's . These repositories are cached and well managed in distributed environments and they are also deployable with versions incrementally and can also be referenced by components or SCA's using version to leverage the version specific changes during code deployment. This mechanism would definitely addresses most of the problems associated with hot deployment issues where service disruptions are less likely to happen as the older components would continue to use older version of MDS artifacts and newer components would use newer ones. There are purge strategies built around this to manage and purge these MDS soa bundles by versions.

Oracle SOA suite is one such EAI product which has MDS feature but it doesn't provide a feature to access the common artifacts using versions through BPEL or SCA's and I am hoping that in future all EAI products would definitely adopt and glorify this mechanism to better handle service interruptions during service upgrades.

In my opinion accessing common artifacts from the centralized store is bit more complex by design. Container should be good enough to manage the shared artifacts efficiently in all respects.

MDS concept was introduced in 11g to overcome some of key problems of 10G where we used to refer the common artifacts via http URL's in WSDL's or XSDs and this straigh forward and conventional method of accessing resources posed many problems in 10G world like for example: moving code from one environment to next environments was not easy as we had to replace the developer hard coded host names and ports and also during development time JDeveloper IDE used to take more time while JDev performing resource lookup on developer hardcoded host name and ports in the partner links contents.

However, MDS can show some lights on 24/7 requirements as part of HA feature especially during service upgrades. I hope that Oracle will address this in their future releases.

Some Useful information to quickly go through on MDS is here:

The advantages of using the Oracle Metadata Services Repository as a central storage for the metadata.

Introduction

SCA has been available since the release of the Oracle SOA Suite 11g. This technology combines and orchestrates several SOA components inside an SCA composite, making design, development, deployment, and maintenance easier. SCA development is metadata-driven, meaning that metadata artifacts, such as Web Services Description Language (WSDL), XML Schema Definition (XSD), XML, others, define the composite's behavior.

With the increased number of composites and the dependencies among them, it became necessary to manage all the metadata in an adequate way. This article will address the advantages of using the Oracle Metadata Services (MDS) repository as a central storage for the metadata. The MDS repository is a central part of the Oracle Fusion Middleware landscape, managing the metadata for several technologies, such as Oracle Application Development Framework (Oracle ADF), Oracle WebCenter, and the Oracle SOA Suite.

This article is divided into three parts. The first part provides an overview of SCA and MDS. The second part describes some MDS tasks that help in the management of the SCA metadata files inside the repository. The third part shows how to develop SCA composites in combination with an MDS repository.

Concepts

SCA

The SCA standard was introduced by several companies, including Oracle, and is now being maintained by the OASIS group. SCA delivers a software development model for composing applications and integrating systems. Inside an SCA composite, different kinds of components are defined and bound together in order to provide several services to the outside world. The main purpose of an SCA model is to provide complex functionality-for example, a business process-by dividing it into small SOA components that are each responsible for one specific task and orchestrating the components together as a composed service. Figure 1 shows a sample of an SCA composite at development time.

Figure 1: SCA Composite in Oracle JDeveloper

SCA builds upon the SOA standard, providing a framework for composing and integrating these SOA components into a higher-level, central composite. One of the main characteristics of SCA composites is that they are metadata-driven, meaning that the behavior of each one component is not defined in a singular programming language, such as Java, C++, or .Net, but in metadata artifacts, such as XML files. This characteristic makes SCA composites very flexible, allowing them to easily integrate and interchange new components based on their interface definitions.

An SCA composite is divided into three main parts: Components, external references, and exposed services. The component part is the central part of an SCA composite, defining all the components and the communication (wires) among them. In Oracle SOA Suite 11g, five kinds of components may be used inside an SCA composite:

• BPEL Process: Business Process Execution Language (BPEL) is a language that allows the definition of business processes. These processes are defined in XML and their main goal is to orchestrate functional services. These services may be external services to the composite or other components inside the same composite. One of the main features of a BPEL process is the ability to integrate synchronous as well as asynchronous services using correlation IDs. A BPEL process is used inside a composite to define business logic in the form of a process.
• Oracle Business Rules: The Oracle Business Rules component serves as a rules repository inside an SCA composite. Its main propose is to define statements that define business policies in a central place outside the application code. The language implemented to define these rules can be read easily by nontechnical users, and the rules engine allows the rules to be changed at runtime without recompiling or stopping the application. Rules are defined in XML and can adopt the form of sentences or decision tables.
• Human Workflow Task: The Human Workflow Task component allows the interaction of users inside an SCA composite and includes some predefined workflows that facilitate the definition of complex human intervention. Usually, it is used in with BPEL processes to define a set of tasks that have to be done by a user, a group, or a predefined role. Upon authentication, users can access a list of available tasks that are assigned to them by other components or even by other users. These tasks can be viewed using the predefined workflow application or they can be accessed through a custom application that uses the available Java API.
• Mediator: The mediator works as a message dispatcher inside an SCA composite. A mediator helps with the integration of the other components inside the composite by making decisions-based on the incoming message-about which one of the other components the message should be routed to. Apart from this, before routing the different kinds of messages, it can transform them using XSL Transformations (XSLT), decoupling the different components by allowing them to have their own specific input and output messages.
• Spring Contexts: Spring beans may also be included inside an SCA composite, allowing the execution of Java functionality and the re-utilization of previously developed Java components. The Spring context component extends the common Spring configuration file with two new tags: SCA-service and SCA-reference. With the help of these tags, Spring beans can consume the services of other SCA components and expose services that can be consumed by other SCA components.

Oracle Metadata Services

MDS can be described as a central repository inside the Oracle Fusion Middleware landscape. Its main purpose is to provide a centralized store where the Oracle Fusion Middleware components can keep, manage, and access their metadata.

Metadata is often defined as data about data, or in other words, pieces of information that describe and give meaning to other information. Typical examples of metadata used by Oracle Fusion Middleware components are XML files, XSD schema files, XSL transformations, SCA composites, BPEL processes, WSDLs, business rules, Oracle ADF pages, JaveServer Pages (JSP), and Oracle ADF task flows, among others. These resources contain not only configuration parameters or data definitions; they also complex business logic, interface contracts, and business rules. Therefore, it is important to manage them in a special way, so they can be easily updated and shared with the external world.

In common 2-tier or 3-tier applications, such as Oracle Forms applications or Java EE applications, business data is usually stored inside a database, centralizing it for easy management and access. Business components do not have to look everywhere for the needed information, because they know where it is and how to access it. The data can be shared among different applications and any changes to the data will have to be done at only a single point, guaranteeing consistency. MDS applies the same philosophy for the metadata of the Oracle Fusion Middleware components. Instead of having several metadata resources in class paths, inside JAR files, or even inside databases, MDS makes it possible to have the resources centralized in a single place. Figure 2 show how the Oracle Fusion Middleware components interact with MDS.

Figure 2: Oracle Fusion Middleware and MDS

There are many justifications for using a metadata repository. First, metadata such as XML files or XSD schema files is usually shared among different components. Therefore, it is not only necessary that those resources can be accessed easily and referenced by all the components, but it is also important that they remain consistent; a change in the metadata should be reflected in all the components that are referencing it. Having only one copy of each metadata resource avoids unnecessary redundancy and guarantees that the changes are made in only one place.

Second, as with functional data, metadata also has a lifecycle, which means that different versions of the metadata exist through different project phases such as analysis, design, development, testing, and production. All of the versions have to be managed, and it should be possible to interchange them easily, depending on the phase. Changing from one version to another and rolling back to an older version should not jeopardize the component's consistency or behavior.

Third, as with functional data, metadata has to be administered and managed. Among the common needed functionality are abilities for adding, updating, deleting, labeling, caching, and versioning metadata. Maintaining these resources would be very difficult if they were stored in several places instead of one central place.

Fourth, since many components use this metadata, it has to be highly available and performant to avoid bottlenecks and to avoid becoming a single point of failure. Metadata often requires the same special treatment as functional data and concepts such as clustering, replication, and load balancing should also be considered a fundamental part.

Several features of the MDS repository make it a very robust solution for handling metadata. Before examining them, it is necessary to mention first that there are two types of possible repositories-file-based or database based-and most of the following features are possible only if a database based repository is being used. File-based repositories are intended for development environments, whereas database-based repositories are intended for production environments.

• Customized applications: This feature is available for both types of repositories and is commonly used in Oracle ADF applications. Customized applications are built upon a base application and multiple customization layers. The customization layers are stored in the MDS repository and are merged with the base application at runtime.
• Query optimization: Database repositories can rely on database capabilities to optimize the queries done on their content. There are also some preconfigured indexes and purging mechanisms that help with overall performance. Also, metadata that is not changed during runtime can be configured so that it is cached for fast access. MDS can also detect changes in the metadata, which makes it possible to maintain the cached version up to date.
• MDS query API: This API provides the capability to define queries based on metadata attributes, metadata values, the type of metadata, metadata paths, and even text content.
• Transaction support: Database-based MDS repositories can use database transactions to roll back to a previous state in case of a failed import or update of the repository.
• Versioning: Versioning applies only to database-based MDS repositories and allows metadata to be saved with a different version number rather than just overwriting the original version. Versions are stored separately and a version history can also be configured so that the metadata can be viewed as it was at a specific point in time. Each version can also be labeled to facilitate retrieving a specific version.
• Change isolation: Changes to the metadata can be isolated so that they apply only for a specific set of clients, allowing testing to be done before releasing the changes to everyone. This feature applies only for database-based repositories.
• Change detection: As mentioned before, metadata is intended to be shared among different components. This feature allows a component to poll for changes on the metadata (or subscribe to them), so it can detect when the shared resource was modified and use the new version without having to be restarted. This feature works only on database based repositories.
• Shared metadata repository: This feature allows sharing a metadata repository among distinct components. A shared metadata repository can centralize all the metadata and maintain it up to date for each consumer, which facilitates reuse and avoids unnecessary duplicates. A shared metadata repository is required if change detection is going to be used.
• Partitions: In an MDS repository, each component and application has its own partition. Partitions allow deployments to remain independent from each other. In other words, a partition is a logical, independent repository inside the MDS repository that can be associated with one or more applications. This feature applies to file-based and database-based repositories.
• Label: Each partition can have many labels. Each label represents a state (snapshot) of the metadata inside the partition. Figure 3 shows labels inside MDS.

Figure 3: MDS Labels and Partitions

• Namespaces: Namespaces inside the MDS repository define the home path of the metadata inside the repository. At runtime, MDS uses three predefined namespaces: apps, deployed-composites, and soa-shared. Namespaces are used inside theadf-config.xml file to specify the location of the metadata. Custom XML files are usually located inside the apps namespace, whereas composites are stored inside the deployed-composites namespace, and standard SOA artifacts are stored inside thesoa-shared (/soa/shared) namespace.

Managing the MDS Repository

As already mentioned, the MDS repository can be file-based or database based. The idea behind file-based repositories is to allow developers to have a light repository available in their local environment that can be easily adapted for development and tests; a file-based repository relieves developers of having to configure and maintain an external database while providing necessary functionality, such as file referencing and customizations. These kinds of repositories are easily modified and maintained, since they define a directory structure similar to any other directory structure inside an operating system. They can be navigated and altered using common shell commands or any kind of visual file explorer application. The file-based repository is usually located inside the Oracle JDeveloper home (JDEV_HOME/integration) if the default configuration is used, but external directories may also be configured for each application in the adf-config.xml configuration file.

On the other hand, database-based repositories are used in production environments where robustness is needed. These repositories are created using the Repository Creation Utility (RCU) application from Oracle. This utility helps with the creation of a new database schema with its corresponding tables and objects. Repositories can later be registered or deregistered via the Oracle Enterprise Manager Fusion Middleware Control console. Figure 4 shows how repositories are viewed in the console.

Figure 4: MDS Repositories in the Oracle Enterprise Manager Fusion Middleware Control Console

The directory structure can also be navigated and explored with the help of Oracle JDeveloper. Single files can also be viewed in Oracle JDeveloper. Nevertheless, it is important to mention that files and directory structures can be modified only by using WLST commands or by deploying new files; they can't be modified using Oracle JDeveloper.

The next sections expose some basic administrative commands for a database based MDS repository. These commands do not apply for a file-based repository, since it can be directly modified.

Administration

Repository Creation and Registration

As mentioned in the previous section, database-based repositories have to be created using the RCU utility. Since the MDS repository is a prerequisite of some other products, such as Oracle SOA Suite, the repository is automatically created when the schemas for those products are created. Nevertheless, new and independent repositories can be created at any time using RCU. New repositories have to be registered using the Oracle Enterprise Manager Fusion Middleware Control console or WLST commands in order to allow all the managed servers—or only specific ones—to have access to them.

Adding Files

Files can be added or updated in the MDS repository using WLST commands or by deploying JARs (Java Archives) or MARs (Metadata Archives). The WLST script inside the Oracle Common home provides the importMetadata command for adding or updating files to MDS. With this command, it is possible to add one or more files using fully qualified document names and document name patterns. The files are added if they do not exist or they are overwritten if they are already in the repository. Files can be added to a specific label and can be versioned before being uploaded. The SCA and MDS section provides an example of the importMetadata command.

Metadata files can also be deployed to the repository using one of the following options: Ant scripts, Oracle JDeveloper, or WLST commands. The deployment process is similar to the process of deploying an SCA composite; in fact, the Ant scripts that are available are the same. The first step for deploying metadata files is to pack them with the desired structure inside a JAR (or MAR) file. The directory structure in which the files are packed is the same one that is used in the repository. So, if the files have no directory, they will end up directly inside the apps directory in the repository. If the JAR file stores the files inside the MdsApp/schemas directory, the apps/ MdsApp/schemas directory will be generated and the files will be stored inside. It is also important to mention that MAR files are usually used in Oracle ADF applications to store metadata. In the SOA world, the metadata is usually packed in a JAR file.

After the JAR file is created, an SCA bundle has to be generated in order to pack the JAR file in it. This SCA bundle can then be deployed to the MDS repository. Packing the metadata files can be done using the Ant scripts or Oracle JDeveloper. With Ant, the zip target is used to build the JAR file and SCA bundle file. Afterwards, the deploy target from the ant-sca-deploy.xml file has to be referenced to deploy the SCA bundle.

With Oracle JDeveloper, it is necessary to define two deployment profiles. The JAR file is the first deployment profile to be created and it is defined at the project level. The SOA bundle is the second deployment profile that has to be created and this should include the previously generated JAR file. This deployment profile has to be defined at the application level. The SCA bundle (or SOA bundle) can be deployed directly in Oracle JDeveloper using the ant sca deploy.xml file or via the Oracle Enterprise Manager Fusion Middleware Control console. There are also a couple of sample Ant scripts that wrap the Ant tags and define friendlier tags for deploying the MDS files.

Updating Files

Files cannot be directly updated. To change a file, it is necessary to overwrite it by exporting it or by redeploying it. Files can be viewed directly using Oracle JDeveloper but they cannot be edited. One option is to download the files using the exportMetadata command from WLST, change them, and upload them using the importMetadata WLST command.

Deleting and Purging Files

Specific files or whole directory structures can be deleted using the deleteMetadata WLST command. As with exportMetadata andimportMetadata, fully qualified document names or document name patterns can be defined. The application version is optional, meaning that if the version is omitted, the latest version will be deleted.

Documents that are unlabeled can be purged. This is done using a WLST command called purgeMetadata. Document versions that are older than the value specified for this command and that are unlabeled are purged from the database.

The Java API

The Oracle SOA A-Team developed a Java class that can also modify and access the MDS repository, and it is based on the functionality used by Oracle JDeveloper to navigate. This Java class, called MDSUtils.java, can create and delete folders and can also search resources inside the repository. Furthermore, this Java class can be accessed using WLST. More information can be found on the A-Team - SOA Blog.

MDS MBeans

The MDS repository provides two kinds of MBeans (manage beans) that allow the administration of the metadata and the repository itself. Both MBeans are located under the "Application defined MBeans" category inside the oracle.mds.lcm package. TheMDSDomainRuntime MBean provides operations for managing the repository. With this MBean, is possible to list partitions, list repositories, create partitions, create labels, register repositories, and delete partitions, among other functions.

The MDSAppRuntime MBean provides the functionality to alter the metadata files. There is an MDSAppRuntime MBean for each application that uses the MDS repository. So, for example, there is one for soa infra, one for the composer, and one for wsm-pm. Any Oracle ADF application that uses the repository will also get an MBean. On the other hand, SCA composites run inside the soa-infraapplication and, therefore, use the same MBean as the soa-infra application. These MBeans provide operations for deleting metadata, purging metadata, exporting metadata, and importing metadata, among other functions. Figure 5 shows the MDS MBean Browser inside the Oracle Enterprise Manager Fusion Middleware Control console.

Figure 5: MDS MBean Navigator

MDS Inside Oracle JDeveloper

Oracle JDeveloper is the principal IDE (Integrated Development Environment) for developing Oracle Fusion Middleware components and applications. With Oracle JDeveloper, it is possible to reference several MDS repositories where the metadata is stored. Thanks to this functionality, the developed components don't depend on the physical location of their metadata, and they can be easily deployed in different environments without having to reconfigure any of the corresponding metadata references. This also allows developers to have a local development environment that better simulates other environments such as test and production. References to the metadata repositories are defined in the adf-config.xml file.

As mentioned before, it is also possible in Oracle JDeveloper to graphically navigate the different MDS repositories. To access a repository (file based or database-based), it is necessary to define a connection. Afterwards, its tree structure can be explored like a file system. The content of the files in the repository can also be viewed inside Oracle JDeveloper and they can be edited using the options described in the Updating Files section.

Connections

Defining a connection for an MDS repository in Oracle JDeveloper requires one or two steps, depending on the type of repository being accessed. If a connection to a file-based repository is being defined, only the root path of the MDS repository needs to be supplied. This root path is usually located inside the Oracle JDeveloper home path: JDEV_HOME/integration/apps. The first time, the apps directory has to be manually created inside the integration directory. Nevertheless, this path can be configured in the adf-config.xml file.

To create a database-based repository connection, it is necessary to first define the respective database connection that points to themds-schema. Afterwards, the MDS connection can be created based on the database connection. Figure 6 shows the connection wizard in Oracle JDeveloper.

Figure 6: Connection Wizard

The adf-config.xml

The adf-config file is a configuration file that was initially used only in Oracle ADF applications, but it is now also used in other Oracle Fusion Middleware components, such as Oracle SOA Suite and Oracle WebCenter. This file contains several Oracle ADF application-level settings for the following:

• Metadata validation
• Resource bundle caching
• Task-flow settings
• Implicit save points
• Global settings for Oracle ADF Business Components
• Oracle ADF Security
• Seeded customizations
• User customizations
• Change persistence
• MDS repositories

These settings are usually changed at deployment time and at runtime. For more information about these settings, refer to the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

For SCA applications, Oracle JDeveloper also generates an adf-config.xml file inside the .adf/META-INF directory. This adf config.xml file can be used to configure several MDS repositories that can be referenced at development time. Oracle JDeveloper will then use these references to validate and compile the composite. The following sample shows how the repositories are being referenced:

<?xml version="1.0" encoding="windows-1252" ?>
  <adf-config xmlns="http://xmlns.oracle.com/adf/config"
  xmlns:config="http://xmlns.oracle.com/bc4j/configuration"
  xmlns:adf="http://xmlns.oracle.com/adf/config/properties"
  xmlns:sec="http://xmlns.oracle.com/adf/security/config">
     <adf-adfm-config xmlns="http://xmlns.oracle.com/adfm/config">
       <defaults useBindVarsForViewCriteriaLiterals="true"/>
       <startup>
         <amconfig-overrides>
           <config:Database jbo.locking.mode="optimistic"/>
         </amconfig-overrides>
       </startup>
     </adf-adfm-config>
     <adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
       <adf-property name="adfAppUID" value="MdsApp3.demo.wpmds"/>
     </adf:adf-properties-child>
     <sec:adf-security-child xmlns="http://xmlns.oracle.com/adf/security/config">
       <CredentialStoreContext credentialStoreClass="oracle.adf.share.security.providers.jps.CSFCredentialStore"
 credentialStoreLocation="../../src/META-INF/jps-config.xml"/>
     </sec:adf-security-child>
     <adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
       <mds-config xmlns="http://xmlns.oracle.com/mds/config">
         <persistence-config> 
           <metadata-namespaces>
             <namespace metadata-store-usage="mstore-usage_1" path="/soa/shared"/>             
             <namespace metadata-store-usage="mstore-usage_2" path="/apps/WPMDSDemo2"/>    
             <namespace metadata-store-usage="mstore-usage_2" path="/apps/WPMDSDemo3"/>          
           </metadata-namespaces>           
           <metadata-store-usages>            
             <metadata-store-usage id="mstore-usage_1">               
               <metadata-store class-name="oracle.mds.persistence.stores.file.FileMetadataStore"> 
                 <property value="${oracle.home}/integration" name="metadata-path"/>                 
                 <property value="seed" name="partition-name"/>
               </metadata-store>             
             </metadata-store-usage>            
             <metadata-store-usage id="mstore-usage_2">               
               <metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore"> 
                 <property value="DEV1_MDS" name="jdbc-userid"/>
                 <property value="jdbc:oracle:thin:@localhost:1521:XE" name="jdbc-url"/>                 
                 <property value="soa-infra" name="partition-name"/>                     
               </metadata-store>             
             </metadata-store-usage>           
           </metadata-store-usages>         
         </persistence-config>       
       </mds-config>     
     </adf-mds-config>

</adf-config>

The different MDS repositories are defined inside the persistence-config tag. The MDS repository configuration consists of two parts: namespaces and metadata stores.

The namespaces define the home path of the metadata inside the repository. At runtime, the Oracle MDS repository defines the following three preconfigured namespaces:

• apps: Reserved namespace for storing custom artifacts.
• deployed-composites: Namespace for storing the SCA composites.
• /soa/shared: Namespace reserved for the standard Oracle SOA Suite artifacts.

The home path that is defined in the namespace tag will be used by Oracle JDeveloper as a starting point to look for all the referenced metadata. Different parallel metadata home paths can be defined with the same name to allow the composites to reference paths inside the same store.

The second part is the configuration of the repository itself. Repositories are defined inside the metadata-store-usage tag. This tag also contains the reference to the corresponding metadata-store-usage that was previously defined in the namespace tag. The type of the repository is defined in the meta-store tag. File-based repositories should use theoracle.mds.persistence.stores.file.FileMetadataStore class and should also define the metadata-path to indicate where the metadata is physically stored. As mentioned in the Administration section, this path is usually inside the Oracle JDeveloper home directory. A custom directory can also be defined using operating system environment variables. So, instead of having the metadata under ${oracle.home}/integration, the user can define the ${MDS.HOME}/files directory as the root path for the metadata. (MDS.HOME has to be defined as an environment variable for this to work.) Database-based repositories should use theoracle.mds.persistence.stores.db.DBMetadataStore class and they also should define the properties needed to establish a database connection.

In the example shown at the beginning of this section, two repositories were defined. The first one is a file-based repository with${oracle.home}/integration as the root path. It references mstore-usage_1, which defines /soa/shared as home path. In other words, Oracle JDeveloper will look for the metadata in the following path: ${oracle.home}/integration/soa/shared. Using environment variables, as mentioned above, it is also possible to specify a different location from ${oracle.home}, for example,${MDS.HOME}/integration/soa/shared or ${metadata.dir}/integration/soa/shared.

The second one is database repository and references mstore-usage_2. Since mstore-usage_2 is defined twice, Oracle JDeveloper will use both paths (/apps/WPMDSDemo2 and /apps/WPMDSDemo3) as home paths to look for the metadata being referenced in the SCA composites.

SCA and MDS

Having all the previous concepts exposed, it is now possible to explain how to develop SCA composites that reference the metadata from external repositories instead of having the metadata be stored locally. The main reason for using this approach is to follow the development best practice that dictates the component's interface definition is separated from its implementation. Figure 7 shows this approach.

Figure 7: SCA Composites and MDS

Metadata at Development Time

In most cases, it is recommended to use a local file repository when developing the SCA composites. This configuration allows developers to make local changes easily without affecting other developers. Afterwards, the SCA composites and metadata can be deployed to a test environment where a central database-based MDS repository is installed.

In order to separate the SCA composite from its definition, it is recommended to have at least two independent applications in Oracle JDeveloper: one for the metadata and others for the different composites. The starting point should be the metadata application. It is necessary to mention that the metadata application is not obligatory, since the metadata files can also be deployed using the WSLT commands previously described. Nevertheless, it is better to have a metadata project in order to take advantage of additional Oracle JDeveloper functionality such as the XML visual design view and history reviews. The metadata application contains one generic project where the files are stored with the corresponding folder structure. All XSD, XSLT, WSDL, and XML artifacts that are shared among different composites should reside in this project. Figure 8 shows a sample MDS project.

Figure 8: MDS Project

After the project has been created, it can be deployed using WSLT commands or the SCA Ant script or directly in Oracle JDeveloper. These approaches will be explained in detail in the next section.

The SCA composites should be developed using references to the metadata inside the MDS repository. Usually, the composite definition file, mediators, BPEL processes, and other components reference metadata files from the local file system or from a remote server using the corresponding URL. The files inside the MDS repository also have a URL that can be used to access the resources and it looks like this: oramds:/apps/directory1/directory2/someFile.wsld.

The oramds placeholder is used to indicate that the resource is located inside the MDS repository. Oracle JDeveloper will then look for the adf config.xml file to search for the resource in the configured repositories. Oracle SOA Suite will also interpret the oramds key word and will look for the resource in the repositories that are configured in its installation. The standard path where the metadata is stored is apps. The whole metadata structure will be stored inside apps directory if the deployment is done using Oracle JDeveloper or the SCA Ant script. The other directories and files depend on the metadata project itself.

Oracle JDeveloper facilitates the inclusion of the MDS URLs in the SCA composite's artifacts by providing a navigator screen where the resources can be explored and included. This navigator screen is available via the SOA Resource Browser by selecting the MDS connection inside the IDE connections. It is important to mention that an MDS connection should be available to navigate the repository. Figure 9 shows how the MDS navigator screen looks.

Figure 9: MDS Navigator in Oracle JDeveloper

After the resource has been selected, Oracle JDeveloper generates the URL in the form oramds:/apps/...

Including XML, XSLT, and XSD from the MDS repository rather than from the local file system or a remote server should be straightforward since the files remain unaltered. With WSDL files, there is the issue of the endpoint address. WSDL files stored inside the MDS repository should avoid having an endpoint address, since they are a generic resource, whereas the endpoint address is deployment-specific information. An SCA composite that imports a WSDL as a reference may define the endpoint address in thecomposite.xml file, making this property editable through a configuration plan and in runtime via the Oracle Enterprise Manager Fusion Middleware Control console. This can be achieved by defining the endpoint property inside the binding of the reference like this:

<binding.ws port=quot;http://xmlns.oracle.com/bpel/workflow/taskService#wsdl.en
dpoint(TaskService/TaskServicePortSAML)quot;
location=quot;http://localhost:7001/integration/services/TaskService/
TaskServicePortSAML?ORAWSDLquot;
soapVersion=quot;1.1quot;>
<property name=quot;weblogic.wsee.wsat.transaction.flowOptionquot;
type=quot;xs:stringquot; many=quot;falsequot;>WSDLDriven</property>
<property name=quot;endpointURIquot;
type=quot;xs:stringquot; >http://localhost:7001/integration/services/TaskService/
TaskServicePort</property>

</binding.ws>

This property can later be changed at runtime inside Oracle Enterprise Manager Fusion Middleware Control, in the Service/Reference Properties menu. Figure 10 shows the console.

Figure 10: Endpoints in the Oracle Enterprise Manager Fusion Middleware Control Console

SCA and MDS Deployment

The metadata project should be deployed first, since the SCA composites have dependencies to the metadata that may restrain the deployment. As mentioned before, there are three ways to deploy the metadata: use a WSLT command, use an Ant script, or use Oracle JDeveloper.

WLST Commands

There are two different WLST commands for deploying the MDS files: importMetadata and sca_deployComposite. Regardless of which command is used, the command should be executed using the WLST tool from the Oracle SOA Suite installaton which is usually located in SOA_HOME/common/bin. Also, the importMetadata command needs to be executed online, so the first instruction to be executed should be connect().

The importMetadata command can be used to deploy one or more files to the repository using wildcards. This command has three required parameters.

• For the first parameter, the application name (soa-infra) should be used as the corresponding value, since the metadata is going to be deployed and referenced in Oracle SOA Suite.
• The second parameter is the server name and it should be the managed server where Oracle SOA Suite is installed.
• The third parameter is the source directory from which documents will be transferred. This parameter can be used with the docs parameter, which is optional but allows filtering the files that will be transferred. This parameter allows the use of wildcards (* or **) to filter the desired files. It is important to mention that this parameter imports the whole given structure. So ifdocs='/apps/directory1/*.txt' is used, all files ending in txt will be transferred to the /apps/directory1 in the repository.

Here is an example of how to use the importMetadata command:

importMetadata(application='soa-infra', server='AdminServer',fromLocation='D:\mywork\WPMDSDemo\MDSFiles',
docs='/apps/WPMDSDemo3/**')

This command will transfer all files located in D:\mywork\WPMDSDemo\MDSFiles\apps\WPMDSDemo3 to the /apps/WPMDSDemo3directory in the repository. Please refer to Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for more details about this command.

The sca_deployComposite command is actually meant to deploy composites, but it can also be used to deploy metadata files. This command is easier to use because it was developed specifically for SCA composites, whereas the importMetadata is more generic and can be used also for other technologies, such as Oracle ADF. This command doesn't deploy single files, so all the metadata files have to be packed in a JAR file or inside an SOA bundle.

The sca_deployComposite command requires two parameters: the URL of the destination server (managed server where Oracle SOA Suite is installed) and the location of the SOA bundle or JAR file. Here is an example of how the command can be used:

sca_deployComposite("http://localhost:7001","D:\mywork\WPMDSDemo
\MDSFiles\deploy\mds.jar")

Please refer to Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for more details about this command.

Ant Script

Oracle JDeveloper ships several Ant scripts that facilitate the management of SCA composites. The

ant-sca-deploy.xml script allows the deployment of composites and also metadata files. Similar to when using the WLSTsca_deployComposite command, the metadata files have to be previously packed in a JAR file or in an SOA bundle.

Here is an example of how the ant-sca-deploy.xml script can be used to deploy metadata files:

ant -f ant-sca-deploy.xml -DserverURL=http://localhost:7001 
-DsarLocation= D:\mywork\WPMDSDemo\MDSFiles\deploy\mds.jar)

For more information please, refer to Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Oracle JDeveloper

As with other technologies, JDeveloper provides the functionality to deploy the artifacts to a remote server. The deployment of the metadata files consist of two main steps. First the metadata project needs to be deployed to a JAR file. Afterwards a soa-bundle has to be generated at the application level. The soa-bundle deployment profile has to include the previously generated jar file. For further information about how to deploy using JDeveloper, please refer to Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

After the metadata files have been deployed to the MDS repository, the composites can be deployed as usual without any changes.

Conclusion

Metadata is a crucial part of any SCA development. It defines the interfaces, the services being referenced, the data structures, messages, and the transformations of these messages. Some of these metadata files are used inside one SCA composite, but there are some cases, especially with WSDL files, where metadata needs to be shared among composites.

Storing shared metadata files in a central repository provides the following advantages:

• Consistency: All composites reference the same version of the metadata, reducing the inconsistencies that duplicated data may generate.
• Ease of maintenance: The metadata has to be maintained in only one place.
• Ease of change: Changes in the metadata will be reflected in all composites that reference it.
• Reuse of metadata: Having all metadata in one central repository enforces the reuse of previously defined structures.

For the following reasons, the MDS repository is the best option for storing shared metadata files in a central repository:

• It is native to Oracle SOA Suite. In fact, it is used automatically by Oracle SOA Suite to deploy the composites.
• Oracle JDeveloper supports the usage of MDS repositories to develop SCA composites.
• Both file-based and database-based repositories are supported for different environments, such as development and production.
• SCA composites are independent of the kind of repository being used and its location. The deployment process of the composites is the same as if the metadata files were stored locally.
• Additional functionalities, such as partitioning, versioning, and change detection, are provided.
• MDS repositories can be navigated visually in Oracle JDeveloper.
• MDS repositories can be configured easily using the Oracle Enterprise Manager Fusion Middleware Control console.

Using a central metadata repository is a good option for composites that share their metadata. The MDS repository not only addresses this need; it also provides additional functionality that adds robustness to the end solution.

References

• Storing SCA Metadata in the Oracle Metadata Services Repository by Nicolás Fonnegra Martinez and Markus Lohn

• White Paper: Oracle SCA - The Power of the Composite
• Oracle Business Rules User's Guide
• Oracle Fusion Middleware WebLogic Scripting Tool Command Reference
• Metadata Services (MDS) in Fusion Middleware 11g
• Oracle Fusion Middleware Administrator's Guide 11g Release 1
• MDS in a Nutshell – by George Maggessy
• Inside BPM and SOA – Danilo Schmiedel's blog
• Oracle Fusion Middleware A-Team SOA Blog