SSL Concept and How to debug SSL issues with weblogic server

Let's get some good understanding on SSL.

- Two parties wants to exchange data securely over the network.

- So they need uncrackable encryption algorithm support to achieve secure communication between two parties irrespective of platforms.

- Encrypted data is not understandable to the application layers as its needs to be decrypted before data/content could  be used by app layers.

- Hence, top of  application layer, one more layer is introduced and is called Secure Socket Layer or SSL Server.

- In essence, Client ( browser) connects to SSL Layer and SSL Layer in turn communicates with App Layer, typically, Https (ssl) to Http (app layer).

- By requirement, requests from Client Browser to SSL Layer must be secured with the use of some good encryption technique however SSL Layer to App Layer can remain as non secured.

- A Typical example: User logs into ebay website and uses his/her credit card to purchase items  over internet.

- Credit Card Data entered by User cannot be sent in plain text to server due to man in the middle attack problems.

- So, secure communication is achieved using a public-private key encryption mechanism on the data to be exchanged between two parties.

- Private key will be known to SSL Server only.

- Common Public Key will be issued by SSL server to the public who wants to communicate with it.

- One must remember that Client ( public key )  and the SSL Server ( Private Key) doesn't know each other.

- Man in the middle attacker can act as a ebay web site and can steal credit card details. Because the public certificate can also be issued by masqueraded ebay SSL server dynamically on demand to the client.  

- So, In theory, there is nothing called secured communication.

- As solution, both the Client and Server needs to trust some third party vendor (for ex:Govt) who can verify and authorize EBAY type of vendors for their real identity. 

- So, both the user (client) and ebay (SSL server) will have to trust upon third party vendors whose job is to know EBAY company in detail. 

- The third party vendors are the trusted authorities who sells the certificates to ebay type of apps or webapps(to be imported on SSL Layer of web apps) and they are one who issues a unique private (for ebay)  and common public key (client) as part of this certificate they sell.

- One can buy the certificate by submitting CSR information at vendor site. 

- Some of the well re-known vendors in the market are Geo Trust or Verisign.

So, without a TRUST no secured communication can be established. The name trusted keystore is meant on this same context  as well.

Anybody can sell certificates but not all of them can be trusted source. Usually, the browser or server api languages comes installed with trusted root CA certificates. Having these certificates installed on browser or at server means these are the vendors  trusted by borwser or servers. If browser shows the cross or warnings sign then user needs to carefully deal with such sites before making any transactions or giving away valuable information over the net

A look at SSL Handshake using symmetric session key:  

At look at SSL handshake in general:

Let's get some basic understanding on one way SSL communication:

One way SSL is the encryption process that happens from client to server only.

Key points to note down:

The SSL server will have a private key installed as server certificate.

The User or Client (browser) who wants to communicate to SSL Layer would need a public key to encrypt and send the data securely over the network. This public key certificate will be downloaded by client from SSL Server on demand.

The data encrypted by client can only be decrypted by private key at SSL Layer. 

For the reverse communication i.e Server (encrypts the data) to client(decrypts data)  one needs use two way SSL Mechanism. In other words, its also called peer to peer two way SSL communication where both the peers will have the private certificates installed at their ends using their separate private-public key for decryption and encryption mechnanisms.

WLS as Client:

Remote Service as a Server to be accessed over SSL layer:

This is broader picture of SSL.

1. Client (WLS) Initiates the Handshake with the server (Remote Service).
2. Server (Remote Service) will present its remote public certificate to the Client (WLS).
3. Client (WLS) will verify the certificate by looking into the Trust Keystores.
4. This is the reason why we would need to import the remote public Certificate (Remote Service certificate) into WLS Trust Keystore in order to successfully handshake with remote SSL Server.
5. By default DemoTrust.jks keystore is used as a Trusted keystore by WLS and hence the Remote public certificate is imported generally into the DemoTrust.jks file.
6. Then Client will send the list of Ciphers to be used for encryption over the network to the remote SSL server.
7. If the SSL Server supports the ciphers sent by the Client, then first level of handshaking will succeed and then SSL communication will be established between client and SSL server.
8. If there are no common ciphers available between the Client (WLS) and the Server then secure communication will fail.

How to debug:

1. Try testing the Remote Service connectivity with the standalone client to test whether the service is accessible over SSL or not. This way we will be clear enough whether the issue is on remote server or on the client side.
2. Check to see standalone java code is using the same JRE as used by WLS.

The following Java command line system property variables can be used to enable debug log in SSL modules used by weblogic modules.

-Dweblogic.StdoutDebugEnabled=true

-Dssl.debug=true

 If we need to debug any Javax Net API related All/SSL problems then one could use the following debug flags at the java command line:

-Djavax.net.debug=all :                 This is for turning all debugging.

-Djavax.net.debug=ssl :                This is for turning SSL debugging.

Common Errors:

Symptom 1:

Errors:

FINE: Cannot complete the certificate chain: No trusted cert found

FINE: Validating certificate 0 in the chain: Serial number: 1398096
Issuer:C=CZ, CN=I.CA – Standard root certificate, O=Prvni certifikacni autorita a.s.
Subject:C=SK, CN=damas.sepsas.sk, ST=Slovakia, L=Bratislava, O=Slovenska elektrizacna prenosova sustava, a.s., OU=Damas Energy, ?=ICA – 595029
Not Valid Before:Tue Aug 11 12:07:51 CEST 2009
Not Valid After:Wed Aug 11 12:07:51 CEST 2010
Signature Algorithm:SHA1withRSA

FINE: validationCallback: validateErr = 16

Resolution:

We can follow below steps to resolve:
1: If you are running Java code in a standalone command prompt then you could use the following command to run the Java code to make use of SSL resources at client side:
java -Djavax.net.ssl.trustStore=<<JKSTRUSTSTORE.jks>> -Djavax.net.ssl.trustStorePassword=<<TRUSTPASSWORD>> YourJAVAclass

where,
JKSTRUSTSTORE: is the keystore which should have the root certificate from the SSL server hosting the service.
TRUSTPASSWORD: keystore password for the trustStore.

2: If the java code is running on the WLS server then WLS server being the client you should use:
-Djava.protocol.handler.pkgs=weblogic.net
-Dweblogic.security.SSL.trustedCAKeyStore=trustStore

You can set the above envrionment properties using System.setProperty("");

——————————————————————————————————————————————————-

Symptom 2:

Error:

FINE: ……….. Eating Exception ……….
java.security.NoSuchAlgorithmException: Algorithm ECDH not available
+ at javax.crypto.KeyAgreement.getInstance(DashoA13*..)+

Reason:

This is like both the Htps Client and the HttpS Server is not able to negotiate on a common Cipher (Algorithm) and hence the handshake is failing.

Just to give you a brief idea: the Cipher is an encryption algorithm which is typically initialized by the Client end and the same Ciper algorithms should be supported at SSL Sever so as to choose any one of the Ciphers presented to be used to establish a secure communication over SSL layer.
If the Server doesn't support any such Cipher algorithms as with Client then the communication will not succeed.

It is also possible to force the Client (Weblogic) to use the weaker ciphers provided if the Server doesn't have any constraints in using the limited ciphers then connection over SSL could be established.

Resolution:

By default Weblogic Server uses the certicom implementation of SSL. Considered to to be faster than sun.

The above exception is seen because of the certicom implementation of SSL where it is unable find a common cipher during SSL handshaking process between client and server.

We can hint Weblogic server to use the SUN implementation of SSL instead to solve the issue.

In order to use the SUN implementation of SSL the following properties has be to set as a command line parameters in the Weblogic server:

-Djavax.net.ssl.keyStore
-Djavax.net.ssl.keyStoreType
-Djavax.net.ssl.keyStorePassword
-Djavax.net.ssl.trustStore
-Djavax.net.ssl.trustStoreType
-Djavax.net.ssl.trustStorePassword
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol

all the above properties can also be also set programmatically  or can be overidden in the code thats deployed on weblogic server so that the WLS JVM would use these values at runtime rather than using its own implementation.

System.setProperty( “javax.net.ssl.keyStore”, “***” );

System.setProperty( “javax.net.ssl.keyStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.keyStorePassword”, “***” );
System.setProperty( “javax.net.ssl.trustStore”, “***” );
System.setProperty( “javax.net.ssl.trustStoreType”, “JKS” );
System.setProperty( “javax.net.ssl.trustStorePassword”, “***” );
Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider() );
System.setProperty( “java.protocol.handler.pkgs”, “com.sun.net.ssl.internal.www.protocol” );

————————————————————————————————————-

——————————————————————————————————————–

Symptom 3:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

How to debug above Error:

The above error denotes that the URL you are trying to access does not have a Valid Certificate or the Certificate used by the URL provider is not issued by a Trusted Certificate Authority.

in Order to resolve the above error message, there can be two scenarios:

1: When client accesses the SSL URL in a Java Standalone code then it is needed to import the root certificate of the SSL URL into the cacerts file, which can be located @JAVA_HOME/jre/lib/security/ directory.

2: If the Client is the WLS server here, which is trying to access the SSL URL, then we need to determine what is the Trust Store configured at Weblogic Server.

If the Weblogic server is using DemoTrust then we can import the root certificate of the URL in the cacerts file of the JAVA used by the WLS server.

If the Weblogic Server is using Custom Trust then we can import the root certificate of the URL in the Custom Trust keystore used by the weblogic server.

How to get the root certificate of the URL:

1: Copy the URL and paste in the browser address bar , let us say IE and press Enter.

2: Typically, the page show a warning message indicating the certificate is not valid, Click on the view certificate option of the pop-up and then we have to click on the Install certificate.

3: Once installed, then open the IE >>> Internet Options >>> contents >>> certificates >>> Trusted Certificate option.

Find the certificate that was just installed and export that certificate into DER encoded binary format and store it as root_vendorName.cer

To import the new certificate into the cacert file or into any keystore we will have to use the following keytool utility that comes pre-installed in JDK/bin folder :

keytool -importcert -v -alias root_cert -file c:/root.cer -keystore c:/java/jdk/jre/lib/security/cacerts -storepass changeit

-alias: this can be anything .

-file: this is the file needs to be imported.

-keysotore: this is the keystore file where we need to import the certificate.

-storepass: this is the password for the keystore file, which is “changeit” by default for cacerts.

Reference:

http://www.weblogic-tips.com/2010/05/11/how-to-debug-ssl-issues-with-weblogic-server/

The Secure Socket Layer, SSL for short, is a protocol by which many services that communicate over the Internet can do so in a secure fashion. Before we discuss how SSL works and what kinds of security it provides, let us first see what happens without SSL.

Life on the Internet without SSL

Let us compare communications between computers on the Internet and communications between people over the telephone. Without SSL, your computer-to-computer communications suffer from the same security problems from which your telephone communications suffer:

• Who are you talking to? In a phone conversation, how can you be sure that the person who picks up the phone at the other end is really the person you are trying to call (especially if you have never spoken to them before)? What if your phone call was intercepted or re-routed, or what if someone else is answering your call recipient’s phone? There really is no way to be sure you have reached the right person, especially if they are actively trying to fool you.
• Eavesdropping? As you are aware of from watching TV or reading, it is very easy to tap phone lines: the police and spies do this all the time to covertly gather information. It is not easy to detect if your lines are tapped. The same applies with communications over the Internet — how can you be sure that your communications are not being “tapped” and recorded?  This is especially problematic in public wifi hotspots.

This results in two very real security issues for communications over the Internet: 1. knowing for sure that you are connecting to the right servers  (i.e. those at your bank and not those at a hacker’s or phisher’s web site), and 2. knowing that your data is safe from prying eyes during transit to those computers. This is where SSL comes in.

Enter the Secure Socket Layer (SSL)

To solve these problems to a large degree, most Internet services support use of SSL as a mechanism for securing communications. To illustrate how SSL works, let us use another analogy.

Client wants to communicate with a company to send important information back and forth. Client wants to be 100% sure that s/he is communicating with this particular company and that no one can eavesdrop on or intercept the communications. How can s/he do this?

• Client sends a courier to the company’s address.
• The company has envelopes that, when closed, can only be opened by the company. The company and the courier go together to a trusted third party — a notary — which makes the company provide documentation to prove its identity. The notary certifies the company’s secure envelopes and the courier takes these back to the client.
• The client gets the envelopes and, if it trusts the notary’s reputation, can be sure that they are actually from the company indicated.
• The client also has secure envelopes that, once sealed, only the client can open. It puts some of these in one of the company’s secure envelopes and sends them back to the company.
• The company gets the sealed secure envelope. It opens the envelope (as only it can). It now has the client’s secure envelopes.
• The company has another kind of envelope that can be opened and sealed only by using a special combination. The company puts this special envelope with the combination lock, together with the combination, into one of the client’s secure envelopes. The company seals the envelope.
• The company has another type of secure envelope that anyone can open, but which only the company can seal. If you open one of these sealed envelopes, you know for sure that it was sent by the company. The company puts the whole package inside this and sends it to the client.
• When the client gets the secure envelope, it opens it and thus knows that it came from the company. It then opens the next secure envelope inside that can only be opened by the client. Inside it gets out the combination-envelope and the combination itself.
• The client the puts his data in the combination envelope, seals it and sends it to the company.
• The company receives it, opens it, and puts the response in the same secure envelope and sends it back.
• The procedure is repeated as often as necessary for required communications.

SSL relies on the concept of “public key cryptography” to accomplish these tasks. In normal encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate these passwords to people you have not yet met in a way that is itself secure?

In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the user’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe and secure, and private.

If John sends Mary a message encrypted with Mary’s public key, then only Mary can open it, as only she has her private key. This is like an envelope that anyone can seal but which only Mary can open.

If John sends Mary a message encrypted with John’s private key, then anyone can open it, as everyone has access to John’s public key. However, successfully opening the message proves that it was sent by John and no one else, as only John has access to his private key. This is like an envelope that only John can seal, but which anyone can open and thus prove that John sealed it.

SSL in Action

So, let’s see how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:

• A company wishes to secure communications to their server company.com.
• They create a public and private key for company.com (this is also known as as “SSL Certificate“).
• They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a lot of paperwork and paying a hefty fee.
• Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com and that this is verified by Thawte. This certification information is encrypted using Thawte’s private key… we will see why below.

Then, when Client wishes to communicate with the company at company.com,

• Client makes a connection to company.com with its computer. This connection is made to a special “port” (address) on company.com that is set up for SSL communications only.
• When Client connects to company.com on its SSL-secured port, the company sends back its public key (and some other information, like what Ciphers it supports).
• Client gets the public key and decides if it is OK…
  • If the public key has expired, this could be a problem
  • If the public key claims to be for some domain that is not company.com that could be a problem.
  • Client has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, client can decrypt the validation information, prove the validation is from Thawte and verify that the public key is certified by Thawte. If Client trusts Thawte, then Client can trust that he/she is really communicating with Company. If Client doesn’t trust Thawte, or whatever Third Party company is actually being used, then the identity of who is running the computers to which Client is connecting is suspect.
• If client decides to trust the public key, then Client will send to the company the Client’s public key.
• The company will then generate a “password” and encrypt it using both Client’s public key and Company’s private key, in succession, and send it back to the client.
• Client will decrypt the password. This process proves that the company sent the password and that only Client was able to read it.
• If the client doesn’t trust the server, then the communication is terminated.
• If the client has its own SSL certificate installed, it may send that to the server at this point to see if the server trusts the client.  Client-side SSL certificates are not commonly used, but provide a good way for the client to authenticate itself with the server without using a username or password.  In the case where this is used, the server would have to know about the client’s certificate and verify it in a similar way to how the client verified the server.  If this fails, the connection is terminated.  If a client-side certificate is not needed, this step is skipped.
• Once the client is happy with the server (and the server with the client, if needed), then the client choose an SSL Cipher to use from the list of encryption methods provided by the server, and generates a “symmetric key” (password) for use with that Cipher.  The client encrypts this password using the server’s public key and sends it back to the server.  The server (and only the server) can decrypt this message and get this password, which is now shared by both the client and server.
• The client will then start communicating with the company by encrypting all data using this password and the chosen Cipher. Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. These keys were needed to enable the company (and possibly the client) to prove its identity and right to domain.com and to enable the client and server to generate and securely communicate a common password.

So, Are there Limitations to This Process?

This all sounds great — what are the down sides? There are a few.

Key Length: The statement that “only someone with the private key can decrypt something encrypted with the public key” is true so long as the private key cannot be “guessed”. Hackers may try to do this by trying all possible private key combinations. Older “40bit” keys can be broken by trial and error if one has access to vast computer resources and a good amount of time. These days, keys used in SSL are 128bit or better. There are so many possible keys with 128bit that it would take significantly longer than the age of the universe to “guess” one.

Trust: While use of SSL ensures that your communications cannot be spied on, it comes down to trust to ensure that you are actually communicating with your intended company. This is reflected in the validation of company.com and your trust of the third party organization. Some “secure sites” do not bother to get a third party’s approval and have their keys approved by “themselves”. Others use third parties that are almost free and which spend very little effort in validating the company. In these cases, SSL provides you with no real assurance that you are really talking to your intended company and not some hacker trying to forge their identity to communicate with you in a manner in which you think you are safe.

For defensive use of the web, you should pay attention to warnings generated by SSL when you connect to secure sites. Such warnings include “expired certificates”, “domain name mismatches” — where the domain name presented by the company is different than the one to which you are connecting, and “non trusted certificates” — where the public key (certificate) presented by the company was not validated by a third party that your computer trusts. In all of these cases, you should be wary.

Ciphers: SSL uses one of a large variety of possible “ciphers” to perform the symmetric encryption.  Use of a poor/weak cipher can result in fast SSL that is easily compromised.  Currently, it is recommended that one use 128-bit or stronger AES encryption as your cipher.  See: 256-bit AES Encryption for SSL and TLS: Maximal Security.

What Services Can be Protected With SSL?

Almost any Internet service can be protected with SSL. Common ones include WebMail and other secure web sites such as banking sites and corporate sites, POP, IMAP, and SMTP. LuxSci provides SSL services to protect your username, password, and communications over all of these and other services.

Oracle Fusion Middleware 11g Release, Support and upgrade patching concepts

Nice PDF document:

Oracle Fusion Middleware 11g Release 1Support Update: Patchset3 (11.1.1.4)

Oracle Fusion Middleware Roadmap

Middleware 11g: Patching Concepts and Tools



https://docs.google.com/open?id=0B5SGobvptF_wcUZocjdHTG1wdE0

http://download.oracle.com/technology/community/ofm_directors/files/PartnerCouncil-SOA-Suite-11g-roadmap.pdf

MDS-00054: Undeploying SOA Composite when Soa-Infra is Down

Goal

Undeploying SOA Composite while soa-infra is down.

Mainly this task is required when starting soa server, soa-infra application wont come up due to corrupt composite which stops the soa-infra to be in active state.  The solution also applies in the case where the server itself is failing to come up / stay up due to a bad deployment.

Fix

Check the soa logs and determine which composite is causing the problem and then follow the below process to Undeploy SOA composite by editing deployed-composites.xml

1. Download and copy the ShareSoaInfraPartition.ear file to $MIDDLEWARE_HOME/oracle_common/common/bin

2. cd to $MIDDLEWARE_HOME/oracle_common/common/bin

and

run wlst.sh

3.

connect()

provide username, password and server URL

4. run the below command to deploy ShareSoaInfraPartition.ear

deploy('ShareSoaInfraPartition','ShareSoaInfraPartition.ear',upload='true')

5. Now run the below command by changing the "toLocation" ('/fmw11g/fmw1115/Middleware' is some location path on SOA machine)

exportMetadata(application='ShareSoaInfraPartition',server='AdminServer',toLocation='/fmw11g/fmw1115/Middleware',docs='/deployed-composites/deployed-composites.xml')

6. A deployed-composites folder will be created at "toLocation" path with deployed-composites.xml in it

7. Delete the composite which is causing the problem and save the file

For example i am MediatorTest composite like below

<composite-series name="default/MediatorTest" default="default/MediatorTest!1.0">
<composite-revision dn="default/MediatorTest!1.0" state="on" mode="active" location="dc/soa_58b98be8-9ec8-41af-bb83-590f6004d1aa">
<composite dn="default/MediatorTest!1.0*soa_58b98be8-9ec8-41af-bb83-590f6004d1aa" deployedTime="2011-11-17T09:01:54.750+05:30"/>

8. Now run the below command by changing the "fromLocation" (this should be the same location as previous)

importMetadata(application='ShareSoaInfraPartition',server='AdminServer',fromLocation='/fmw11g/fmw1115/Middleware',docs='/deployed-composites/deployed-composites.xml')

9. Now bounce your server and the composite will not be deployed by SOA when it comes up and hence that should bring your soa-infra up.

• ShareSoaInfraPartition.zip(675.9 KB)

Changing Weblogic Configuration to use newer version of JDK

1. Backup the following files

ADMIN SERVER DOMAIN FOLDER:

$WLSDOMAIN/<<DOMAIN NAME>>/bin/setDomainEnv.sh (WHERE THE ORIGINAL OR MASTER COPY OF ADMIN SERVER DOMAIN FOLDER IS LOCATED) - typicall shared storage.

MANAGED SERVER DOMAIN FOLDER:

$MWHOME/admin/<<DOMAIN NAME>>/mserver/<<DOMAIN NAME>>/bin/setDomainEnv.sh (On all nodes viz node1,2,3 & 4)

$WLSHOME/common/bin/commEnv.sh (On  all nodes viz node1,2,3 & 4)

 2. Edit setDomainEnv.sh file

The setDomainEnv script is located in the bin subdirectory of the domain’s root directory.

$WLSDOMAIN/<<DOMAIN NAME>>/bin/setDomainEnv.sh (from any one node)

$MWHOME/admin/<<DOMAIN NAME>>/mserver/<<DOMAIN NAME>>/bin/setDomainEnv.sh (On all nodes viz node1,2,3 & 4)

The first code snippet shows the initial existing settings in bold  for older version of JDK:

SUN_JAVA_HOME="/reuters/oracle/product/soa/11g/fmw/jdk1.6.0_24"

export SUN_JAVA_HOME

if [ "${JAVA_VENDOR}" = "Oracle" ] ; then

                JAVA_HOME="${BEA_JAVA_HOME}"

                export JAVA_HOME

else

                if [ "${JAVA_VENDOR}" = "Sun" ] ; then

                                JAVA_HOME="${SUN_JAVA_HOME}"

                                export JAVA_HOME

                else

                                JAVA_VENDOR="Sun"

                                export JAVA_VENDOR

                                JAVA_HOME="/reuters/oracle/product/soa/11g/fmw/jdk1.6.0_24"

                                export JAVA_HOME

                fi

fi

The second code snippet shows the changes, in bold, made to switch to newer version:

SUN_JAVA_HOME="/reuters/oracle/product/soa/11g/fmw/jdk1.6.0_39"

export SUN_JAVA_HOME

if [ "${JAVA_VENDOR}" = "Oracle" ] ; then

                JAVA_HOME="${BEA_JAVA_HOME}"

                export JAVA_HOME

else

                if [ "${JAVA_VENDOR}" = "Sun" ] ; then

                                JAVA_HOME="${SUN_JAVA_HOME}"

                                export JAVA_HOME

                else

                                JAVA_VENDOR="Sun"

                                export JAVA_VENDOR

                                JAVA_HOME="/reuters/oracle/product/soa/11g/fmw/jdk1.6.0_39"

                                export JAVA_HOME

                fi

fi

3. The following two code snippets show the switching of the default JDK from Older to newer version of JDK in commEnv.sh.

$WLSHOME/common/bin/commEnv.sh (On  all nodes viz node1,2,3 & 4)

The first code snippet shows the initial existing settings of older version of JDK:

# Reset JAVA_HOME, JAVA_VENDOR and PRODUCTION_MODE unless JAVA_HOME

# and JAVA_VENDOR are pre-defined.

if [ -z "${JAVA_HOME}" -o -z "${JAVA_VENDOR}" ]; then

  # Set up JAVA HOME

  JAVA_HOME="/reuters/oracle/product/soa/11g/fmw/jdk1.6.0_24"

  # Set up JAVA VENDOR, possible values are

  #Oracle, HP, IBM, Sun ...

  JAVA_VENDOR=Sun

  # PRODUCTION_MODE, default to the development mode

  PRODUCTION_MODE=""

fi

The second code snippet shows the changes, in bold, made to switch to newer version:

# Reset JAVA_HOME, JAVA_VENDOR and PRODUCTION_MODE unless JAVA_HOME

# and JAVA_VENDOR are pre-defined.

if [ -z "${JAVA_HOME}" -o -z "${JAVA_VENDOR}" ]; then

  # Set up JAVA HOME

  JAVA_HOME="/reuters/oracle/product/soa/11g/fmw/jdk1.6.0_39"

  # Set up JAVA VENDOR, possible values are

  #Oracle, HP, IBM, Sun ...

  JAVA_VENDOR=Sun

  # PRODUCTION_MODE, default to the development mode

  PRODUCTION_MODE=""

fi

4. CHANGE THE JAVA_HOME VALUE TO LATEST ONE IN .PROFILE FILE

5. LOGIN TO PUTTY WITH A NEW SESSION AND VALIDATE IF THE JDK VERSION IS LATEST or not by running java -version command.

cheers

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