Oracle: Using the Metadata Service to Share XML Artifacts

Exclusive offer: get 50% off this eBook here
Oracle SOA Suite 11g Developer's Cookbook

Oracle SOA Suite 11g Developer's Cookbook — Save 50%

Over 65 high-level recipes for extending your Oracle SOA applications and enhancing your skills with expert tips and tricks for developers with this book and ebook.

$35.99    $18.00
by Matt Wright | January 2013 | Cookbooks Enterprise Articles Oracle

Service Oriented Architecture (SOA) provides the architectural framework needed to integrate diverse systems together and create new composite applications. Oracle SOA Suite 11gR1 provides the tools needed to turn an SOA architecture into a working solution.

In this article by Matt Wright, co-author of Oracle SOA Suite 11g Developer's Cookbook, we will cover:

  • Creating a file-based MDS repository for JDeveloper

  • Creating Mediator using a WSDL in MDS

  • Creating Mediator that subscribes to EDL in MDS

  • Creating an external reference using a WSDL in MDS

  • Referencing Schematron in MDS for validation

  • Referencing a fault policy deployed to MDS

  • Deploying MDS artifacts to the SOA infrastructure

  • Exporting an MDS partition to the filesystem

  • Deleting XML artifacts from SOA infra MDS

(For more resources related to this topic, see here.)

The WSDL of a web service is made up of the following XML artifacts:

  • WSDL Definition: It defines the various operations that constitute a service, their input and output parameters, and the protocols (bindings) they support.

  • XML Schema Definition (XSD): It is either embedded within the WSDL definition or referenced as a standalone component; this defines the XML elements and types that constitute the input and output parameters.

To better facilitate the exchange of data between services, as well as achieve better interoperability and re-usability, it is good practice to de?ne a common set of XML Schemas, often referred to as the canonical data model, which can be referenced by multiple services (or WSDL De?nitions).

This means, we will need to share the same XML schema across multiple composites. While typically a service (or WSDL) will only be implemented by a single composite, it will often be invoked by multiple composites; so the corresponding WSDL will be shared across multiple composites.

Within JDeveloper, the default behavior, when referencing a predefined schema or WSDL, is for it to add a copy of the file to our SOA project.

However, if we have several composites, each referencing their own local copy of the same WSDL or XML schema, then every time that we need to change either the schema or WSDL, we will be required to update every copy.

This can be a time-consuming and error-prone approach; a better approach is to have a single copy of each WSDL and schema that is referenced by all composites.

The SOA infrastructure incorporates a Metadata Service (MDS), which allows us to create a library of XML artifacts that we can share across SOA composites. MDS supports two types of repositories:

  • File-based repository: This is quicker and easier to set up, and so is typically used as the design-time MDS by JDeveloper.

  • Database repository: It is installed as part of the SOA infrastructure. This is used at runtime by the SOA infrastructure.

As you move projects from one environment to another (for example, from test to production), you must typically modify several environment-specific values embedded within your composites, such as the location of a schema or the endpoint of a referenced web service. By placing all this information within the XML artifacts deployed to MDS, you can make your composites completely agnostic of the environment they are to be deployed to.

The other advantage of placing all your referenced artifacts in MDS is that it removes any direct dependencies between composites, which means that they can be deployed and started in any order (once you have deployed the artifacts to MDS).

In addition, an SOA composite leverages many other XML artifacts, such as fault policies, XSLT Transformations, EDLs for event EDN event definitions, and Schematrons for validation, each of which may need to be shared across multiple composites. These can also be shared between composites by placing them in MDS.

Defining a project structure

Before placing all our XML artifacts into MDS, we need to define a standard file structure for our XML library. This allows us to ensure that if any XML artifact within our XML library needs to reference another XML artifact (for example a WSDL importing a schema), it can do so via a relative reference; in other words, the XML artifact doesn't include any reference to MDS and is portable. This has a number of benefits, including:

  • OSB compatibility; the same schemas and WSDLs can be deployed to the Oracle Service Bus without modification

  • Third-party tool compatibility; often we will use a variety of tools that have no knowledge of MDS to create/edit XML schemas, WSDLs, and so on (for example XML Spy, Oxygen)

In this article, we will assume that we have defined the following directory structure under our <src> directory.

Under the xmllib folder, we have defined multiple <solution> directories, where a solution (or project) is made up of one or more related composite applications. This allows each solution to maintain its XML artifacts independently.

However, it is also likely that there will be a number of XML artifacts that need to be shared between different solutions (for example, the canonical data model for the organization), which in this example would go under <core>.

Where we have XML artifacts shared between multiple solutions, appropriate governance is required to manage the changes to these artifacts.

For the purpose of this article, the directory structure is over simpli?ed. In reality, a more comprehensive structure should be de?ned as part of the naming and deployment standards for your SOA Reference Architecture.

The other consideration here is versioning; over time it is likely that multiple versions of the same schema, WSDL and so on, will require to be deployed side by side. To support this, we typically recommend appending the version number to the filename.

We would also recommend that you place this under some form of version control, as it makes it far simpler to ensure that everyone is using an up-to-date version of the XML library. For the purpose of this article, we will assume that you are using Subversion.

Creating a file-based MDS repository for JDeveloper

Before we can reference this with JDeveloper, we need to define a connection to the file-based MDS.

Getting ready

By default, a file-based repository is installed with JDeveloper and sits under the directory structure:

<JDeveloper Home>/jdeveloper/integration/seed

This already contains the subdirectory soa, which is reserved for, and contains, artifacts used by the SOA infrastructure

For artifacts that we wish to share across our applications in JDeveloper, we should create the subdirectory apps (under the seed directory); this is critical, as when we deploy the artifacts to the SOA infrastructure, they will be placed in the apps namespace

We need to ensure that the content of the apps directory always contains the latest version of our XML library; as these are stored under Subversion, we simply need to check out the right portion of the Subversion project structure.

How to do it...

  1. First, we need to create and populate our file-based repository. Navigate to the seed directory, and right-click and select SVN Checkout..., this will launch the Subversion Checkout window.

    • For URL of repository, ensure that you specify the path to the apps subdirectory.

    • For Checkout directory, specify the full pathname of the seed directory and append /apps at the end. Leave the other default values, as shown in the following screenshot, and then click on OK:

    Subversion will check out a working copy of the apps subfolder within Subversion into the seed directory.

  2. Before we can reference our XML library with JDeveloper, we need to define a connection to the file-based MDS.

    Within JDeveloper, from the File menu select New to launch the Gallery, and under Categories select General | Connections | SOA-MDS Connection from the Items list.

    This will launch the MDS Connection Wizard.

  3. Enter File Based MDS for Connection Name and select a Connection Type of File Based MDS.

    We then need to specify the MDS root folder on our local filesystem; this will be the directory that contains the apps directory, namely:

    <JDeveloper Home>\jdeveloper\integration\seed

    Click on Test Connection; the Status box should be updated to Success!. Click on OK. This will create a file-based MDS connection in JDeveloper.

  4. Browse the File Based MDS connection in JDeveloper.

    Within JDeveloper, open the Resource Palette and expand SOA-MDS. This should contain the File Based MDS connection that we just created.

  5. Expand all the nodes down to the xsd directory, as shown in the following screenshot:

    If you double-click on one of the schema files, it will open in JDeveloper (in read-only mode).

There's more...

Once the apps directory has been checked out, it will contain a snapshot of the MDS artifacts at the point in time that you created the checkpoint. Over time, the artifacts in MDS will be modified or new ones will be created. It is important that you ensure that your local version of MDS is updated with the current version.

To do this, navigate to the seed directory, right-click on apps, and select SVN Update.

Creating Mediator using a WSDL in MDS

In this recipe, we will show how we can create Mediator using an interface definition from a WSDL held in MDS. This approach enables us to separate the implementation of a service (a composite) from the definition of its contract (WSDL).

Getting ready

Make sure you have created a file-based MDS repository for JDeveloper, as described in the first recipe. Create an SOA application with a project containing an empty composite.

How to do it...

  1. Drag Mediator from SOA Component Palette onto your composite. This will launch the Create Mediator wizard; specify an appropriate name (EmployeeOnBoarding in the following example), and for the Template select Interface Definition from WSDL

  2. Click on the Find Existing WSDLs icon (circled in the previous screenshot); this will launch the SOA Resource Browser. Select Resource Palette from the drop-down list (circled in the following screenshot).

  3. Select the WSDL that you wish to import and click on OK. This will return you to the Create Mediator wizard window; ensure that the Port Type is populated and click on OK.

    This will create Mediator based on the specified WSDL within our composite.

How it works...

When we import the WSDL in this fashion, JDeveloper doesn't actually make a copy of the schema; rather within the componentType file, it sets the wsdlLocation attribute to reference the location of the WSDL in MDS (as highlighted in the following screenshot).

For WSDLs in MDS, the wsdlLocation attribute uses the following format:

oramds:/apps/<wsdl name>

Where oramds indicates that it is located in MDS, apps indicates that it is in the application namespace and <wsdl name> is the full pathname of the WSDL in MDS.

The wsdlLocation doesn't specify the physical location of the WSDL; rather it is relative to MDS, which is specific to the environment in which the composite is deployed.

This means that when the composite is open in JDeveloper, it will reference the WSDL in the file-based MDS, and when deployed to the SOA infrastructure, it will reference the WSDL deployed to the MDS database repository, which is installed as part of the SOA infrastructure.

There's more...

This method can be used equally well to create a BPEL process based on the WSDL from within the Create BPEL Process wizard; for Template select Base on a WSDL and follow the same steps.

This approach works well with Contract First Design as it enables the contract for a composite to be designed first, and when ready for implementation, be checked into Subversion.

The SOA developer can then perform a Subversion update on their file-based MDS repository, and then use the WSDL to implement the composite

Creating Mediator that subscribes to EDL in MDS

In this recipe, we will show how we can create Mediator that subscribes to an EDN event whose EDL is defined in MDS. This approach enables us to separate the definition of an event from the implementation of a composite that either subscribes to, or publishes, the event.

Getting ready

Make sure you have created a file-based MDS repository for JDeveloper, as described in the initial recipe.

Create an SOA application with a project containing an empty composite.

How to do it...

  1. Drag Mediator from SOA Component Palette onto your composite. This will launch the Create Mediator wizard; specify an appropriate name for it (UserRegistration in the following example), and for the Template select Subscribe to Events.

  2. Click on the Subscribe to new event icon (circled in the previous screenshot); this will launch the Event Chooser window.

  3. Click on the Browse for Event Definition (edl) files icon (circled in the previous screenshot); this will launch SOA Resource Browser. Select Resource Palette from the drop-down list.

  4. Select the EDL that you wish to import and click on OK. This will return you to the Event Chooser window; ensure that the required event is selected and click on OK.

    This will return you to the Create Mediator window; ensure that the required event is configured as needed, and click on OK.

    This will create an event subscription based on the EDL specified within our composite.

How it works...

When we reference an EDL in MDS, JDeveloper doesn't actually make a copy of the EDL; rather within the composite.xml file, it creates an import statement to reference the location of the EDL in MDS.

There's more...

This approach can be used equally well to subscribe to an event within a BPEL process or publish an event using either Mediator or BPEL.

Oracle SOA Suite 11g Developer's Cookbook Over 65 high-level recipes for extending your Oracle SOA applications and enhancing your skills with expert tips and tricks for developers with this book and ebook.
Published: December 2012
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:

Creating an external reference using a WSDL in MDS

In this recipe, we will show how we can create an external reference using an interface definition from a WSDL held in MDS.

Getting ready

Make sure you have created a file-based MDS repository for JDeveloper, as described in the initial recipe. Then open the SOA project in which you want to create the external reference.

How to do it...

  1. Drag a Web Service from the Service Adapters section of the SOA Component Palette onto your composite. This will launch the Create Web Service wizard; specify an appropriate name for it (Employee in the following example), and for Template select Interface Definition from WSDL.

  2. Click on the Find Existing WSDLs icon (as we did in the previous recipe); this will launch SOA Resource Browser. Select Resource Palette from the drop-down list.

  3. Select the WSDL that you wish to import and click on OK. This will return you to the Create Web Service Wizard window; ensure that the Port Type is populated and click on OK.

This will create an external reference based on the specified WSDL within our composite.

How it works...

When we import a WSDL in this fashion, JDeveloper doesn't actually make a copy of the schema; rather within the composite.xml file, it sets the wsdlLocation attribute for the external service reference to point to the location of the WSDL in MDS.

There's more...

As you move composites from one environment to another (for example, from test to pre-prod to prod), you typically need to modify the WSDL to any external web service, to point it to the correct endpoint.

This should be done using a configuration plan; however using this approach enables all your endpoints to be configured separately in MDS, enabling your composites to be completely agnostic of the environment in which they are deployed.

If your composite makes use of adapters, such as the file or database adapter, then it will still contain environment specific values. This can be avoided by using only the adapters within Oracle Service Bus.

Referencing Schematron in MDS for validation

In this recipe, we will show you how to reference Schematron defined in MDS to validate an incoming message within Mediator. This approach enables us to separate the validation rules for the actual composite, allowing us to change our validation rules without having to redeploy a composite.

Getting ready

Make sure you have created a file-based MDS repository for JDeveloper, as described at the start of this article, and that it contains a valid Schematron file.

Create an SOA application with a project containing Mediator (see the Create a Mediator using a WSDL in MDS recipe in this article).

How to do it...

  1. Schematron validation of incoming messages within Mediator is specified at the routing rule level for an operation. Within JDeveloper, open the Mediator that you wish to apply the validation to. Click on the Schematron icon, circled in the following screenshot:

    This will bring up the Validations window where you can specify one or more Schematron files for the routing rule.

  2. To add Schematron, click on the plus sign; this will bring up the Add Validation window shown here:

    For Part, select the part of the SOAP message to which you want to apply the validation.

  3. Next click ,on the search icon (circled in the previous screenshot). This will launch the standard SOA Resource Browser window; select Resource Palette from the drop-down list.

  4. Select the Schematron that you wish to use and click on OK. This will return you to the Add Validation window.

  5. Click on OK; this will return you to the Validation window, which will now list our newly created validation. Click on OK, and this will return you to the Mediator editor.

How it works...

When we reference Schematron in this way, JDeveloper doesn't add a copy of Schematron to the composite; rather within the Mediator plan, it sets the schematron element to reference the location of Schematron in MDS.

At runtime, when the composite references Schematron, it will use the one deployed to the SOA infrastructure, MDS Database repository.

There's more...

This has a number of distinct advantages. Firstly, you can ensure that all your composites use the same version of a particular Schematron.

Secondly, if you need to modify your validation rules, you simply need to update a single copy of your Schematron and redeploy it to MDS. Any composite that references that Schematron will automatically pick up the modified version, without the need to be re-deployed.

Referencing a fault policy deployed to MDS

Rather than creating the fault-policies.xml and fault-binding.xml files in your composite project, which then get deployed with the composite into the runtime environment, you can actually reference the fault policies deployed to MDS.

Getting ready

Make sure you have created a file-based MDS repository for JDeveloper, as described at the start of this article, and that it contains valid fault-policies.xml and faultbinding.xml files.

Then, open the SOA project in which you want to reference the external fault policy.

How to do it...

  1. To reference the policies deployed on MDS, we need to add the properties oracle. composite.faultPolicyFile and oracle.composite.faultBindingFile to the composite.xml file.

  2. These should be added directly following the service elements and reference the location of your policy and binding files in MDS, as shown in the following code screenshot:

How it works...

By default, at runtime the SOA infrastructure will look in the same directory, as composite. xml for the fault-policies.xml and fault-binding.xml files.

Specifying these properties overrides this default behavior, causing the SOA infrastructure to reference the specified location within MDS.

There's more...

This has a number of distinct advantages. Firstly, you can share fault policies across multiple composites. Secondly, if you need to modify your fault policies, you simply need to update a single copy of your fault policy and re-deploy it to MDS.

When deploying an updated version of the fault policy, it will not be automatically picked up by any composite that uses it. Rather, you need to either re-deploy the composite or restart the server.

Oracle SOA Suite 11g Developer's Cookbook Over 65 high-level recipes for extending your Oracle SOA applications and enhancing your skills with expert tips and tricks for developers with this book and ebook.
Published: December 2012
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:

Deploying MDS artifacts to the SOA infrastructure

Before we can deploy a composite that references the artifacts held in MDS, we must deploy those artifacts to MDS on the SOA infrastructure. To do this, we need to create a JAR file containing the shared artifacts and then deploy it as part of an SOA bundle.

In this recipe, we will show you how to do this via JDeveloper, though in practice we would recommend the use of deployment scripts used in conjunction with tools, such as Maven and Hudson.

Getting ready

Make sure you have created an XML library containing your XML artifacts (as described at the beginning of this article).

How to do it...

  1. Within JDeveloper, create a Generic Application (for example, mdslib), and when prompted to, create a project and give it an appropriate name (for example, xmllib). In the application navigator, right-click on the xmllib project and select Project Properties.

    This will launch the Project Properties window; select Deployment from the navigational tree, as shown in the following screenshot:

  2. Click on New; this will launch the Create Deployment Profile dialog. Specify an archive type of JAR File and specify an appropriate name for it (for example, xmllib), and click on OK. This will launch the Edit JAR Deployment Profile Properties window where we can specify what goes in the JAR file.

  3. Even though we are creating a JAR file, it's basically a ZIP file and not a real JAR file, so we need to remove the JAR file specific content; so deselect Include Manifest File.

    Then select File Groups | Project Output | Contributors from the navigational tree and deselect Project Output Directory and Project Dependencies.

  4. Next, specify the actual XML artifacts that we wish to add to the JAR file. Click on Add; this will launch the Add Contributor window.

  5. Click on the magnifying glass and browse to the apps directory for your XML artifacts (this should be the one in your source repository — see the method to create the XML library given at the start of this article), and click on OK.

  6. Next, select File Groups | Project Output | Filters and check that only the files we want are included within the JAR file.

  7. Click on OK to confirm the content of the JAR file, and then click on OK one more time to complete the deployment profile; finally, from the main menu select Save All.

  8. The next step is to create an SOA bundle. From Application Menu, select Application Properties. This will launch the Application Properties window; from the navigational tree, select Deployment and then click on New. This will launch the Create Deployment Profile window, as shown in the following screenshot:

  9. Specify an archive type and appropriate name for the SOA bundle, and click on OK. This will launch the SOA Bundle Deployment Profile Properties window, creating the XML library.

  10. Select Dependencies from the navigational tree and ensure that xmllib is selected.

  11. Click on OK twice and then select Save All from the toolbar.

  12. We are now ready to deploy our XML schemas to the metadata repository. To do this, in Application Menu select Deploy | SOA Bundle Name; this will launch the Deployment Action dialog. Select Deploy to Application Server and follow the standard steps to deploy it to your target SOA infrastructure server(s).

How it works...

In order to deploy our JAR file to the metadata repository, we need to place it within an SOA bundle and deploy that to our SOA infrastructure.

The schemas will then be made available to the SOA composites deployed on the same SOA infrastructure.

There's more...

When you deploy an SOA bundle to MDS, it's a cumulative operation, in that new artifacts are added to MDS and artifacts that already exist in MDS are replaced by a new version. But if I don't deploy an artifact, then the previous one remains.

For example, if I deploy an SOA bundle containing A.xsd and B.xsd to MDS, and then deploy a new version of the SOA bundle containing A.xsd (an updated version) and C.xsd to MDS, I will have A.xsd (new version), B.xsd, and C.xsd deployed to MDS.

Exporting an MDS partition to the filesystem

Occasionally, we may want to validate the current content of all the XML artifacts deployed to the MDS repository on our SOA infrastructure. In this recipe, we will show how to export the content of MDS to the filesystem.

Getting ready

Make sure you have deployed some XML artifacts to the MDS repository running on the SOA infrastructure.

How to do it...

  1. Log in to Enterprise Manager, and with the navigation tree expand the SOA node and right-click on soa-infra. Select Administration | MDS Configuration, as shown in the following screenshot:

  2. This will open the MDS Configuration page in Enterprise Manager, as shown in the following screenshot:

  3. Select Export metadata documents to an archive on the machine where this web browser is running. and click on the Export button.

  4. In the browser pop-up window, choose the path and filename and then click on the Save button.

This will download the current content of the MDS repository in a ZIP file to your local filesystem.

There's more...

The content of the MDS repository can also be exported using the WSLT command exportMetadata. This gives you more fine-grained control over what is exported, for example the following command:

wls:/lab_domain/serverConfig> exportMetadata(application='soainfra', server='soa_server1',toLocation='D:/MDSExport', docs='/apps/ core/**')

This will export just the content of the MDS repository under /apps/core

Deleting XML artifacts from SOA infra MDS

When we deploy XML artifacts to MDS, it's a cumulative operation, in that new artifacts are added to MDS and artifacts that already exist in MDS are replaced by a new version. But, if I don't deploy an artifact, then the previous one remains.

For example, if I deploy an SOA bundle containing A.xsd and B.xsd to MDS, and then deploy a new version of the SOA bundle containing A.xsd (an updated version) and C.xsd to MDS, I will have A.xsd (new version), B.xsd, and C.xsd deployed to MDS

In addition, every time we deploy a new SOA bundle, MDS retains the previous version of the SOA bundle.

Because of this, we often need to clean up and remove unnecessary and unwanted files from the MDS repository.

Getting ready

Make sure you have deployed some XML artifacts to the MDS repository running on the SOA infrastructure.

How to do it...

  1. To do this we need to launch the WebLogic Server Administration Scripting Shell; go to the directory MIDDLEWARE_HOME/Oracle_SOA1/common/bin.

  2. On Windows run the command wlst.cmd, and on Unix run the command wslt.sh.

    This will open the WebLogic Server Administration Scripting Shell (WLST) in offline mode, as shown in the following screenshot:

  3. On the WLST command prompt, execute the following code:

    connect('adminuser', 'adminpassword', 't3://hostname:port')

    For example:

    connect('weblogic', 'welcome1', 't3://localhost:7001')

    The WLST should confirm that you have connected successfully with the text, similar to:

    Connecting to t3://localhost:7001 with userid weblogic ... Successfully connected to Admin Server 'AdminServer' that belongs to domain 'soa_domain'. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead.

  4. Use the deleteMetadata command to remove the XML artifacts from MDS, for example:

    deleteMetadata(application='soa-infra',server='soa_ server1',docs='/apps/core/**')

    This will delete all the content under the /apps/core location in MDS.

There's more...

The WLST command purgeMetadata can be used to remove all but the latest version (referred to as tip) of all the artifacts deployed to MDS.

Summary

This article explained how we can use MDS to share XML artifacts, such as XML schemas, WSDL's fault policies, XSLT Transformations, EDLs for event EDN event definitions and Schematrons between multiple composites.

Resources for Article :


Further resources on this subject:


About the Author :


Matt Wright

Matt Wright is a director at Rubicon Red an independent consulting firm helping customer’s enable enterprise agility and operational excellence through the adoption of emerging technologies such as Service-Oriented Architecture (SOA), Business Process Management (BPM) and Cloud Computing.

With over 20 years experience in building enterprise scale distributed systems, Matt first became involved with SOA shortly after the initial submission of SOAP 1.1 to the W3C in 2000, and has worked with some of the early adopters of BPEL since its initial release in 2002. Since then, he has been engaged in some of the earliest SOA-based implementations across EMEA and APAC.

Prior to Rubicon Red Matt held various senior roles within Oracle, most recently as Director of Product Management for Oracle Fusion Middleware in APAC, where he was responsible for working with organizations to educate and enable them in realizing the full business benefits of SOA in solving complex business problems.

As a recognized authority on SOA, Matt is a regular speaker and instructor at private and public events. He also enjoys writing and publishes his own blog (http://blog.rubiconred.com). Matt holds a B.Sc. (Eng) in Computer Science from Imperial College, University of London.

He has worked on Oracle SOA Suite Developer's Guide, Packt Publishing and Oracle SOA Suite 11g R1 Developer's Guide, Packt Publishing.

Books From Packt


 WS-BPEL 2.0 for SOA Composite Applications with Oracle SOA Suite 11g
WS-BPEL 2.0 for SOA Composite Applications with Oracle SOA Suite 11g

 Getting Started With Oracle SOA Suite 11g R1 – A Hands-On Tutorial
Getting Started With Oracle SOA Suite 11g R1 – A Hands-On Tutorial

 Getting Started with Oracle BPM Suite 11gR1 – A Hands-On Tutorial
Getting Started with Oracle BPM Suite 11gR1 – A Hands-On Tutorial

 Oracle Fusion Middleware Patterns
Oracle Fusion Middleware Patterns

 Oracle SOA Infrastructure Implementation Certification Handbook (1Z0-451)
Oracle SOA Infrastructure Implementation Certification Handbook (1Z0-451)

 Oracle SOA Suite 11g Administrator's Handbook
Oracle SOA Suite 11g Administrator's Handbook

 Oracle SOA Suite Developer's Guide
Oracle SOA Suite Developer's Guide

 Oracle Information Integration, Migration, and Consolidation
Oracle Information Integration, Migration, and Consolidation


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
v
S
N
Z
B
r
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software