Assume you have a collection of XSD's (canonical) need be shared between OSB and SOA.
Oracle recommends placing common artifacts in MDS. However, that syntax "oramds:/..." doesn't work for OSB.
I can think of two solutions:
1. Deploy your XSDs in MDS under "apps/xsd". The trick is make these XSD's accessible from OSB. Assume you have a SOA process "foo" deployed to SOA server, then you can access the above XSD like http://yourhost:8001/soa-infra/services/your-parition/foo/apps/xsd/myschema.xsd
Please note, "foo" can be a process that has nothing to do with your XSD file collections! In other words, you can use any surrogate SOA process to access MDS artifacts. All of the XSDs in MDS can be accessed this way.
2. place XSD's in OSB only, SOA access the XSDs with something like "http://your-host:your-port/sbresource?SCHEMA/your-proj-name/xsd-folder-name/xsd-resource-name". e.g. http://localhost:8011/sbresource?SCHEMA/canonical/xsd/Account
This approach works, keep in mind, the access to the following might be disabled via OSB configuration
http://localhost:8011/sbresource?SCHEMA/...
http://localhost:8011/sbresource?WSDL/...
if "sbresource?SCHEMA" access is disabled, then you may need to create a surrogate proxy that references these XSDs, then expose the XSDs via the proxy WSDL.
Another way to do it (not recommended) is to put the XSD file in both MDS and in OSB, There are many problems with this approach, duplicate files in two places can get out of synch. Additionally,you may run into problems with the following scenario:
You have a BPEL process "foo" uses "oramds:/apps/xsd/myschema.xsd",
and an OSB proxy "bar" uses the same XSD within OSB locally.
SOA "foo" process invokes OSB "bar" proxy.
Now your "foo" process will "see" the "myschema.xsd" twice. Once via "oramds:/...", once via "bar" WSDL from OSB, which reference the same schema using http://localhost/8011/sbresource?SCHEMA/testProj/xsd/myschema.xsd. Jdeveloper will complain about the duplicates and won't compile.
No comments:
Post a Comment