Re-using common metadata (wsdl / xsd / edl) in SOA Suite 11g

(From http://blogs.oracle.com/soabpm/entry/reusing_common_metadata_wsdl_x)

As promised here is the first of a set of tips for the brand new SOA Suite 11g.

Managing dependencies between services at development as well as runtime is a challenging task when people implement Service-Providers and -Consumers.

There are a few approaches that worked well in the past and will continue to work well on 11g - yet there are a few notable differences between the releases that should make dependency mgmt way easier in 11g.

Preface:
In the 10.1.3. BPEL world we used to have one global cache for wsdls and schemas. Hence having twice the same (with possible differences) would get you one that overwrites the other.

In 11g SOA Suite, each composite (and revision) has its own store for artifacts, so they don't clash.

Four approaches are in use today (in 10.1.3.x)

a. not preferred at all) Don't bother much and have copies of concrete wsdls in your consuming artifacts. Well that is not sharing, and if the provider changes you need to redeploy the consumer

b. and still not a good approach) Reference the deployed concrete wsdl of a Service Provider. Problem here: Provider not deployed, consumer can't compile or be deployed

c. and the first step to reuse) Introduce a common directory of abstract wsdls and copy them around from project to project. Use wsdlRuntimeLocation on the partnerlink to point to the concrete implementation. Eventually change that during deployment time with the deployment plan.

d. and the next step to reuse) Store abstract wsdls on a centrally accessible endpoint (that might be a war or just an http server) employ the same approach from (c). Problem here - we cache them, you need to refresh the wsdl cache on the BPEL Server.

In SOA Suite 11g we introduced a set of changes that helps you sharing, notable the biggest being the introduction of MDS (MetaData Service) that backs your application (and hence your composites) at designtime as well as runtime.

Think of MDS like a version management system that is used all accross the platform, that you can use to share common artifacts at design and runtime.

So where is your mds located, and how does an application know which one to take?

The configuration sits in $application_home/.adf/META-INF/adf-config.xml and by default points to your local - JDeveloper file system based mds.

Let's examine mine used for fusion order demo

The first important thing to note is the store type. By default this is file based - described with oracle.mds.persistence.stores.file.FileMetadataStore. Now the base path to your mds is described with the property called metadata-path. From here on you can have multiple partitions, but usually one per application. In our case, the partition is called seed. From here, namespaces are used that map to directory structures. These are defined in the section, and by default you get the one that points to internally shared artifacts for your SOA projects, called /soa/shared.

How is mds used in your SOA project then? For example if you create a business rule (yup and that is one of the new features on the JDeveloper UI side) we create you a bunch of artifacts, but the common ones are imported from mds.

An example is
<xsd:import namespace=http://xmlns.oracle.com/bpel
             schemaLocation="oramds:/soa/shared/rules/BpelProcess.xsd"/>
 
Note the namespace being used. If you follow the directory structure based on your adf-config.xml you find this schema. In my case the BpelProcess.xsd is located in C:\JDeveloper\JDev_11.1.1.0\jdeveloper\integration\seed\soa\shared\rules.


A few thoughts here to consider (and succeed):
a) this default namespace is reserved for soa suite infrastructure, and something you should NOT use

b) if you add stuff to the local mds and use it through oramds:/, you need to transfer those artifacts to the server MDS, so the deployment does work.

c) the namespace you should use, that is known to the soa server as well is called apps. To use it - add another namespace to, as I did above in my adf config that says , and create an apps directory under the seed folder. On the server this directory is already there.

Using the shared artifacts:

If you expand the resource browser, there is a section called soa mds connections. Create one for your local environment by picking file as type and specify $ORACLE_HOME\jdeveloper\integration\seed. Whatever you pick now in the resource browser when you work on your composite will be automatically based on the right urls.

Last but not least - create a mar deployment profile on the application level with those shared artifacts, and deploy them to the server.