Oracle WebLogic Integration's Custom Control and SOA Suite Spring Component

(From http://www.oracle.com/technetwork/topics/soa/wli-custom-control-spring-component-091819.html)


Introduction

Custom Java code is an essential part of every Oracle WebLogic Integration (WLI) business process (JPD). Although most components of Oracle SOA Suite are XML-centric, Oracle is adding support for Spring components to give the developer full Java support and a powerful IOC container. The Spring components are available since SOA Suite 11g PS2.
This article explains how a Spring component in SOA Suite provides the same functionality as a Custom control in WLI. It uses the example of a logger component to describe step-by-step how the Spring component is implemented and deployed.
This article is intended for WLI developers and architects who want to get started with SOA Suite 11g.

Custom Control in WLI

WLI uses a custom control to encapsulate Java code (e.g. access to a resource or application functionality) which can then be used in a WLI process (JPD) by dragging-and-dropping the control method into the process.
Users can build their own custom controls that are based on the same framework on which system controls are based. A user designs a custom control from the ground up, designing its interface and implementation, and adding other controls as needed.

Spring Component in SOA Suite

Oracle SOA Suite uses its Spring Java component to implement specific business logic in Java, without ever worrying about XML.
Spring (see SpringSource) is an IOC container (Inversion of Control; see Inversion of Control Containers and the Dependency Injection by Martin Fowler) that allows dependency injection via configuration. So while it presents a little overhead when exposing one JavaBean without any dependencies, the more external components are needed, the easier it becomes to use.
While the main components of Oracle SOA Suite are based on XML as data-exchange format, the goal of this component is to allow seamless Java integration and hence the reuse of Java components and skills. Once a component is implemented, it can be subsequently exposed as service, and invoked from other components such as BPEL.
Using Java classes in a composite can be easily achieved through following a few steps.
a) Create a Java interface, and expose the methods that should be publicly available.

public interface IInternalPartnerSupplier
{
    /**
     * Get a price for a list of orderItems
     * @param pOrderItems the list of orderitems
     * @return the price
     */
    public double getPriceForOrderItemList(List pOrderItems)
        throws InternalSupplierException;
}

b) Create an implementation of this interface.

public class InternalSupplierMediator implements IInternalPartnerSupplier
{
    /**
     * Get the price for a list of orderItems and write the quote via
     * injected reference
     * @param pOrderItems the list of orderItems
     * @return the price for the list of orderItems
     */
    @Override
    public double getPriceForOrderItemList(List pOrderItems)
        throws InternalSupplierException
    {
        // just return a default price - or do something else ..
        return 0.0;
    }
}

c) Create a spring component, which also gives you a spring context, and create a bean, which describes the class created in Step b). Give it a name (so it can be referenced) and declare the class.

d) Create an that exposes a bean as a service. A component must have a service declared, in order to be usable by other components' references.

Once a spring component, including a service, is created, it can be wired to any other component, as illustrated in Figure 1, below.

Figure 1

Use case example: a simple logging component

A very common example of a WLI Custom Control is a custom logger which is used at certain points in a process. In this case, we will log the name of the process, the instance ID and a log message.

Implementing the use case in WLI

This use case is not described in great detail as it is assumed that the audience knows how to create and use custom controls in WLI. The focus area is the Spring component in SOA Suite.
The logger control in WLI consists of two java files:
The interface class LoggerControl.java

package sample.oracle.otn.soaessentials.javainteg.controls;
/**
 * Simple logger interface
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
import org.apache.beehive.controls.api.bean.ControlInterface;

@ControlInterface
public interface LoggerControl {

    /**
     * Implementation of the log method
     * @param pProcessName the name of the originating process
     * @param pInstanceId the instanceID
     * @param pMessage the message to be logged to std.out
     * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent#log
     */
    public void log (String pProcessName, String pInstanceId, String pMessage);

}

The implementation LoggerControlImpl.java

package sample.oracle.otn.soaessentials.javainteg.controls;
import org.apache.beehive.controls.api.bean.ControlImplementation;
import java.io.Serializable;
/**
 * Implementation of a simple logger component
 * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
@ControlImplementation
public class LoggerControlImpl implements LoggerControl, Serializable {
 private static final long serialVersionUID = 1L;
 
    /**
     * Implementation of the log method
     * @param pProcessName the name of the originating process
     * @param pInstanceId the instanceID
     * @param pMessage the message to be logged to std.out
     * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent#log
     */
    public void log(String pProcessName, String pInstanceId, String pMessage)
    {  
       StringBuffer logBuffer = new StringBuffer ();
       logBuffer.append("[").append(pProcessName).append("] [Instance: ").
        append(pInstanceId).append("] ").append(pMessage);
 
       System.out.println(logBuffer.toString());
    }
}

Figure 2 shows the logging control in a JPD Data Palette.

Figure 2

Figure 3 shows the use of the logging control in a JPD

Figure 3

Implementing the use case in SOA Suite

In this section, we will create a simple logging component that can be used from other components, such as BPEL Process Manager or Mediator, to log messages, including the originating instance ID, to standard out.

Creating the Spring Component

To get started, create a new Application in JDeveloper, name it " SOASuiteWLIEssentials"...

Figure 4

And create a new Project named " JavaIntegration".

Figure 5

Click " Finish."
Create a new Java Package " sample.oracle.otn.soaessentials.javainteg" (this requires several steps).

Figure 6

Create a new Java Interface, named " ILoggerComponent" in the " sample.oracle.otn.soaessentials.javainteg" package.

Figure 7

Figure 8

Add a new method to the interface, named " log", with parameters for the originating component, the instance ID, and the message.

package sample.oracle.otn.soaessentials.javainteg;

/**
 * Simple logger interface
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
public interface ILoggerComponent
{
   
    /**
     * Log a message, including the originating component, its instance id and
     * a message.
     * @param pComponentName the name of the component that sends this log msg
     * @param pInstanceId the instanceId of the component instance
     * @param pMessage the message to be logged
     */
    public void log (String pComponentName,
                     String pInstanceId, String pMessage);
}

Figure 9

Create a Java class (" LoggerComponentImpl") from the interface " ILoggerComponent".

Figure 10

Name the class and click on the plus sign to find the interface on which to base the class.

Figure 11

Figure 12

Figure 13

This is the implementation of the logging component:

package sample.oracle.otn.soaessentials.javainteg.impl;

import sample.oracle.otn.soaessentials.javainteg.ILoggerComponent;

package sample.oracle.otn.soaessentials.javainteg.impl;

import sample.oracle.otn.soaessentials.javainteg.ILoggerComponent;

/**
 * Implementation of a simple logger component
 * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
public class LoggerComponentImpl implements ILoggerComponent
{

    /**
     * Implementation of the log method
     * @param pComponentName the name of the orginating component
     * @param pInstanceId the instanceid
     * @param pMessage the message to be logged to std.out
     * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent#log
     */
    @Override
    public void log(String pComponentName, String pInstanceId,
                    String pMessage)
    {
        StringBuffer logBuffer = new StringBuffer ();
        logBuffer.append("[").append(pComponentName).append("] [Instance: ").
            append(pInstanceId).append("] ").append(pMessage);
        
        System.out.println(logBuffer.toString());
    }
}

In the next few steps, we will create a new Spring context ("logger-context.xml"), define a Spring bean ("logger"), and expose the bean as a service ("logService").

Figure 14

Figure 15

Next, drag a bean from the Component Palette...

Figure 16

Onto the the spring context canvas.

Figure 17

Name it "logger" and declare a class attribute pointing to the implementation.

Figure 18

Now the bean can be exposed as an SCA service.
To do so, change the drop-down in the component palette to " Spring 2.5 SCA" and drag a " service" onto the canvas.

Figure 19

Give the service the name " logService". Its target will be the " logger" bean.

Figure 20

Finally, pick the type, which is the interface of the LoggerComponent class (" sample.oracle.otn.soaessentials.javainteg.ILoggerComponent").

Figure 21

Figure 22

The completed spring context looks like this:

<?xml version="1.0" encoding="windows-1252" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:jee="http://www.springframework.org/schema/jee"
       xmlns:lang="http://www.springframework.org/schema/lang"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca">
  <!-- expose the logger bean as service -->
  <sca:service name="logService" target="logger"
               type="sample.oracle.otn.soaessentials.javainteg.ILoggerComponent"/>
  <!-- declaration of the logger bean -->
  <bean name="logger"
    class="sample.oracle.otn.soaessentials.javainteg.impl.LoggerComponentImpl"/>
</beans>

Create a new composite and name it " JavaIntegration".

Figure 23

Use the "create with BPEL Process" option and name the process " BPELProcessWithLogger". Leave the rest with default settings.

Figure 24

Figure 25

Figure 26, below, shows the newly created BPEL process with a receive and a callback activity.

Figure 26

Switch back to the composite view, and drag a " Spring Context" onto the composite canvas. Name it " logger-context" and pick the spring context you created earlier.

Figure 27

Figure 28

Compile the Java classes so you can create a valid WSDL definition that can be used from within a BPEL process.

Figure 29

Drag the service of the spring component over to the BPEL process. This will create a wsdl and a partnerlink in the process.

Figure 30

Figure 31

Next, drag an invoke activity from the component palette onto the BPEL canvas. This will be used to invoke the log() method on the log service created earlier.

Figure 32

Wire invoke to the partnerlink for the logger service.

Figure 33

Create input and output variables. They will be used later to assign the values for component name, component instance id and a log message.

Figure 34

With the finished invoke activity, the process should resemble Figure 35, below.

Figure 35

In order to populate the created variables, drag an assign activity from the palette onto the BPEL process.

Figure 36

In the next three steps you will create the necessary copy rules to populate the input variable.
Double-click the assign activity and add a copy operation to assign the component name to the first parameter.

Figure 37

Add another copy operation to assign the process instance id to the second parameter.

Figure 38

Add a third copy operation to assign a message to the third parameter.

Figure 39

Make sure the assign activity contains all three copy rules.

Figure 40

Once all the copy rules have been built, the process should resemble Figure 41, below, with an initial receive, the assign for the log message values, followed by an invoke of the log service's log method, and finally, a callback, implemented via invoke.

Figure 41

Deploying the SOA Composite

The next step is to deploy the composite with Oracle JDeveloper. Please make sure that your SOA server is running.
Please check Section 43 in Deploying SOA Composite Applications to learn how to deploy SOA composite applications with Oracle JDeveloper and scripting tools and create configuration plans that enable you to move SOA composite applications to and from development, test, and production environments.
Please check Section 5 in Deploying SOA Composite Applications to learn how to deploy, redeploy, and undeploy a SOA composite application from Oracle Enterprise Manager Fusion Middleware Control Console.
When deploying the composite from within JDeveloper, the log should look similar to the one below:

[06:15:55 AM] ----  Deployment started.  ----
[06:15:55 AM] Target platform is  (Weblogic 10.3).
[06:15:55 AM] Running dependency analysis...
[06:15:55 AM] Building...
[06:16:11 AM] Deploying profile...
[06:16:11 AM] Updating revision id for the SOA Project 'JavaIntegration.jpr' to '1.0'..
[06:16:12 AM] Wrote Archive Module to C:\JDeveloper\mywork\SDOStuff\JavaIntegration\
              deploy\sca_JavaIntegration_rev1.0.jar
[06:16:12 AM] Deploying sca_JavaIntegration_rev1.0.jar to soa_server1 
              [sta00251.us.oracle.com:8001] 
[06:16:12 AM] Processing sar=/C:/JDeveloper/mywork/SDOStuff/JavaIntegration/deploy/
              sca_JavaIntegration_rev1.0.jar
[06:16:12 AM] Adding sar file - C:\JDeveloper\mywork\SDOStuff\JavaIntegration\deploy\
              sca_JavaIntegration_rev1.0.jar
[06:16:12 AM] Preparing to send HTTP request for deployment
[06:16:12 AM] Creating HTTP connection to host:sta00251.us.oracle.com, port:8001
[06:16:13 AM] Sending internal deployment descriptor
[06:16:13 AM] Sending archive - sca_JavaIntegration_rev1.0.jar
[06:16:41 AM] Received HTTP response from the server, response code=200
[06:16:41 AM] Successfully deployed archive sca_JavaIntegration_rev1.0.jar to 
              soa_server1 [sta00251.us.oracle.com:8001] 
[06:16:41 AM] Elapsed time for deployment:  46 seconds
[06:16:41 AM] ----  Deployment finished.  ----

Testing the BPEL Process

After successful deployment, you can initiate the composite service through Oracle Enterprise Manager Fusion Middleware Control Console (Enterprise Manager).
To log in to Enterprise Manager, use Internet Explorer 7, Mozilla Firefox 2.0.0.2, or Firefox 3.0.x to access the following URL: http://host_name:port/em. (Where host_name is the name of the host on which Enterprise Manager is installed and port is a number that is dynamically set during installation.)
Enter weblogic/password and click Login.
Please check Getting Started with Administering Oracle SOA Suite for more information.

Figure 42

Locate the JavaIntegration composite on the EM dashboard and click on it. This will get you to the composite homepage:

Figure 43

Once on the page, you can test a composite service.

Figure 44

Fill in " clemens" as input and click " Test Web Service"

Figure 45

Once the instance is created, you can click on the Launch Message Flow Trace which will get you to the composite instance:

Figure 46

You can check the BPEL instance flow as well, which will show you the actual message that was passed to the spring component:

Figure 47

Check the standard output of the server, that hosts the soa suite. It should show an entry similar to the one below:

==> CubeEngine deploy BPELProcessWithLogger took 4 seconds
INFO: DeploymentEventPublisher.invoke Publishing deploy event for 
default/JavaIntegration!1.0*c39dc7a2-5031-424e-9ae0-aeec949769b3
[BPELProcessWithLogger] [Instance: 20009] Got input: clemens

Download the complete project

A zip file contiaining the complete project, including the java sources and the composite, is available for download: wli-soaessentials-JavaIntegration-source.zip. To open it in JDeveloper, create a new Application, and then open the project file (JavaIntegration.jpr)

Key Takeaways and Recommendations

• Java can be seamlessly embedded into the composite / xml based world.
• Multiple Java beans can be easily exposed as services, or get external references injected - just by declaring, and later wiring them.
• No need to code around XML, inside the Spring component - it's POJOs.

In order to create reusable entities and beans, a spring context can be packaged and deployed itself, without composite, into the WebLogic Server, and beans can be exposed as EJBs / webservices.
This makes it very easy to create reusable Java components that can be used from within a BPEL process or a Mediator component in the same way as a WLI JPD uses custom controls.

Clustered Caching with Tangosol Coherence

(From http://mdavey.wordpress.com/2007/01/16/clustered-caching-with-tangosol-coherence/)
 Below, in no particular order are a few items worth noting about Tangosol:

• When installing Tangosol, make sure all the nodes are running the same version
• Don’t use any classes in the component.net packages – Coherence was build with its own development environment, compiler etc. component.net contains these internal components.
• BetFair a few years ago had 80 nodes running Tangosol Coherence. The largest installation today is around 1000 nodes.
• Coherence uses TCMP (UDP based) protocol for data movement
• From an installation perspective, 5 machines is probably the minimum requirement. Lots of RAM for each machine, installed across different racks to reduce the risk. The more machines the Coherence cluster contains, the lower the risk.
• All machines in the cluster should be configured with identical config files, network settings, NIC’s (full/half duplex) etc.
• Multi-cast disconnect issues can be as simple as a miss-configured router.
• Production checklist
• Near Topology (near-*)
• During development set TTL=0 and changing the group address and port.
• Client that come/go from the Coherence cluster should set local storage=false, while cluster servers should set local storage=true
• NamedCache.putAll is far more efficient that put since it can reduce network hops.
• Prior to cluster usage, run the multicast test for 24 hours.
• Use Ethereal or similar to monitor the network to help identify unreliable sockets and NIC configuration issues.
• Java serialization can be a performance bottleneck, consider using Coherence’s ExternalizableLite and its helper, ExternalizableHelper. Externalizable offers reduced GC and ~6x speed improvement.
• High ticking volumns can cause problems for any application. In the case of Tangosol, and caching ticks, one possible solution is to queue the incoming ticks, and use a thread pool to insert the ticks into the cache.

Tangosol Coherence as its simplest:

import java.io.IOException;

import java.util.Date;
import com.tangosol.net.CacheFactory;
import com.tangosol.net.Cluster;
import com.tangosol.net.NamedCache;


public class firstExample {
  public static void main(String[] args) throws IOException {
    try {
      Cluster cluster = CacheFactory.ensureCluster();
      System.out.println(cluster);
     
      NamedCache myCache = CacheFactory.getCache(“test”);
      Object existingVale = myCache.put(“message”, “someMesasge “ + new Date());

      System.out.println(“Existing Val :” + existingVale);

      Object val = myCache.get(“message”);
      System.out.println(“Val :” + val);
      System.out.println(“Press any key”);
      System.in.read();
    }finally {
      CacheFactory.shutdown();
    }
  }
}

Getting started with Tangosol Coherence

(From http://www.javalobby.org/java/forums/t78008.html)

This tip will get you started with Coherence so you can see how easy it is to begin to use in your applications for caching data within a cluster.

Grab a download of Coherence and unzip it, say into a directory called tangosol

Run the cache-server.cmd located in the tangosol/bin directory (replace the .cmd with .sh if you're running on *NIX). This starts a cache server which is storage enabled - the storage enabled bit simply means that this member within the cluster will store data.

Compile and run the below little program, it puts a couple of entries into a cache. It then gets their values out, along with a couple entries which don't currently exist in the cache.

The only JARs you need to reference are tangosol.jar and coherence.jar in the tangosol/lib directory.

import com.tangosol.net.CacheFactory;
import com.tangosol.net.NamedCache;


public class Tip1 {
  public static void main(String[] args) {
    NamedCache cache = CacheFactory.getCache("people");


    String key1 = "dave";
    cache.put(key1, new Long(36));
    String key2 = "jenny";
    cache.put(key2, new Long(25));


    String key3 = "stan";
    String key4 = "jane";


    System.out.println(key1 + "=" + cache.get(key1));
    System.out.println(key2 + "=" + cache.get(key2));
    System.out.println(key3 + "=" + cache.get(key3));
    System.out.println(key4 + "=" + cache.get(key4));
  }
}

Next run coherence.cmd in the tangosol/bin . This starts a nice little command-line application which allows you to explore some of Coherence's functionality without writing any programs.

At the Coherence command-line application's prompt type cache people - this just tells the command-line application that we want to manipulate the people cache. Some XML should have been displayed for the default distributed cache. The distributed cache is nowadays referred to as a 'partitioned cache' to better describe what it is actually doing with the data within the cluster.

Type get dave and press enter, you should see the value for Dave.
Next type put stan 55 and press enter, then put jane 40 . This will put two new entries into the cache using the Coherence command-line application.
Run the Tip1 application again and you should now see values for Stan and Jane.
From the Coherence command-line application, type remove stan .
Running the Tip1 application will show that Stan no longer has an entry.

To remove an entry using Java code simply use cache.remove(key) . As you might have noticed by now, it all seems very Map like - it is, because Coherence's NamedCache interface extends from interfaces which extend from java.util.Map.

For a bit of fun, start another cache-server.cmd and from Coherence command-line application type: get jane . You'll see no difference from before, the value will be displayed.

Now, kill the first instance of the cache-server.cmd and from the Coherence command-line application type get jane . Yep - still no difference, Coherence has automatically failed over without any loss of data. The data had been partitioned (split) across the two cache servers, when one of them was killed, the other simply promoted the 'backups' it was storing to be the primary copies ensuring all of the data was still accessible. If you start the first instance again, then Coherence will seamlessly 'fail back'.

Hope this gets you going with Coherence. If you want to explore the Coherence command-line application a little more then type help to see the valid commands and their syntax. The following link has descriptions for many of the commands: http://forums.tangosol.com/thread.jspa?threadID=51&tstart=0

Don't forget to check out the Wiki as well: http://wiki.tangosol.com

Using Shared Object in Soa Suite 11g with MDS

(From http://biemond.blogspot.com/search/label/MDS)

Inspired by Eric Elzinga , who was wondering how MDS can work in Soa Suite 11g , I made some screenshots how you can use a XSD from a central MDS repository in your composite application. Clemens already blogged about re-using common metadata and he made a great ant utility to import or delete MDS files. For 11G R1 PS1 or higher use this instead of the Clemens utility


First I make a local MDS repository. If you install the Soa plugin you already have a seed folder in the integration folder. Under this folder create an new folder called apps. ( this have has to be apps else you will get a permission denied error ) . Under this apps folder we can create our own definitions.

To use my local SOA-MDS repository I create a new MDS File Connection

I want to re-use these common objects in every Soa project so I choose for the resource palette option

select the seed folder in the integration folder

Here we can see our common application objects.

Open the application resources window and open the adf-config.xml

Here we define a new metadata namespace with apps as path. And use the integration folder as metadata-path value.

We are ready to use these common objects in a mediator.. Here I will use a schema from the local MDS as input parameter for the mediator.

Import a new schema

Select the resource browser and here we can select our schema from the local MDS

I uncheck the Copy to project option, because this XSD already exists in the MDS

Our Project is ready but If we want to deploy this Soa project, we will receive a error, it can't find the schema. So we need to export the local MDS files to the SOA Suite database MDS.

To do this we have 2 options , the first option is to create a MAR deployment ( Application properties ) or do this with Ant.

I stripped the Clemens ant project so this ant build file has only two tasks , add and delete. It uses the adf-config.xml ( config folder) for the location of the target MDS and I use the local MDS as source.

Here is the target adf-config.xml which is located in the config folder

Change the build.properties so it matches your environment

This will import your local MDS object to the remote MDS. After this you can deploy your Soa Suite project.

Here you can download my ant project. Thanks to Clemens.

Active the installed adapters in Oracle SOA suite.

Recently, I installed the latest version of Oracle SOA Suite, but I found there are some adapters' status is not active, such as SocketApdater and OracleAppsAdapter. Googled on the internet and found somebody said these adapters weren't deployed to a target server. I checked the setting of these adapters on targets tab and it is true. By selecting the target server, the adapter becomes active and then the configuration works.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let's examine mine used for fusion order demo

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

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

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


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

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

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

Using the shared artifacts:

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

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

Oracle SOA 11g MDS

(From http://markchensblog.blogspot.com/2011/08/oracle-soa-mds.html)

A metadata repository is the centralized store for the metadata used for the applications in Oracle SOA. It is very useful since most organizations and companies have their own common data models defined as XML schema and WSDL files. These files are organized in some hierarchies and there are dependencies among them. Obviously it is not wise to have local copies of these files for each SOA application. The metadata repository: MDS – Metadata Store in Oracle SOA provides to share these common metadata among the various SOA applications.

In Oracle SOA there are two types of MDS: file-based and database-based. File-based MDS uses the file system to store all these metadata and database-based uses the database. File-based MDS is only used for the development purpose. If the application is deployed on sever the database-based MDS must be used.

File-based MDS

Normally when you do the SOA application development using JDeveloper you usually uses file-based MDS. It is much easier to use file-based MDS for the development purpose. For each application there is one adf-config.xml located in YourAppFolder/.adf/META-INF folder.

In the adf-config.xml the element defines the metadata-namespace and metadata-store-usage from which we know where the shared artefacts. In this example the wsdl and schema files are located in the folder:

D:\Oracle\Middleware\jdeveloper\integration\seed\apps\SOInterfaces-2.3.9.8

where D:\Oracle\Middleware\jdeveloper\integration is the metadata-path and seed is partition-name and apps\SOInterfaces-2.3.9.8 is the namespace-path. 

After the artefacts are put into the right file folder specified in adf-config.xml you can create one MDS connection in JDeveloper to view all the wsdl and schema files in the MDS.

From JDeveloper right click on Applic ation Resources->Connections and then select SOA-MDS from New Connection menu item. Then in the popup window: Create SOA-MDS Connection type in the Connection Name and choose File Based MDS as the Connection Type and type in the MDS Root Folder as: D:\Oracle\Middleware\jdeveloper\integration\seed. You can test the connection by clicking on Test Connection button. If the test is su ccessful click on OK button.

After the MDS connection is created you can see it from IDE Connections in JDeveloper.

Once the MDS is created you use it in your development. For example in your BPEL application you can choose one WSDL from MDS as the service interface of the BPEL process.

In the application one artefact such as wsdl or xsd is referenced it will be referred using oramds protocol. The below is one example from a wrapper wsdl.

location="oramds:/apps/SOInterfaces-2.3.9.8/BSC/OrderAndActivation/Activation/ServiceProvisioning-v1.wsdl"

The relation of BPM and SOA

I have quite a bit of confusion on the position of BPM and SOA suite before seeing the follow picture coming from a slide of Oracle. 

Tricky thing in EclipseLink/TopLink

Recently, I got problem when I used a DB adapter in SOA suite to insert a record into DB with a sequence. I always got the follow exception.
Exception Description: The sequence named [AVS_REQUEST_SEQ] is setup incorrectly. Its increment does not match its pre-allocation size.


Searched by google and found somebody wrote the follow.
Use 100 as a start value will resolve the problem: by default the start value is 1, when Eclipselink attempts to use the first allocated sequence value it's negative 1 - 100 + 1, that causes the exception.
(Reference: http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg03461.html)

The above setting solved the issue, but I got a sequence number is 52 instead of 1. I keep to search and found another answer.
You must change the DBAdapter properties in WebLogic deployments console, make the preallocationSize same as the one used for the sequence.
<config-property name="sequencePreallocationSize" value="1"/>


I checked my connection setting in DBAdapter, the value is really 50 and that is why I got a sequence from 52 (101-50+1).

The follow step is the way to change the preI've found it. It is in the dbAdapter connection pool's configuration of sequencePreallocationSize.


In the Weblogic's console:
1) Deployments->dbAdapter
2) Configuration's Tab
3) Click on
4) Click on your ConnectionPoolFactory
5) Properties' Tab
6) Change 'sequencePreallocationSize' property's value to 1. Press ENTER to actually change it.
7) Click Save button.
8) Go to Deployments
9) Check dbAdapter and click Update
10) Click Finish

This is really a tricky thing.

Hibernate Cache

Hibernate is a well-know persistence framework in the  Java world, it comes with a wonderful API to ease application communication with the database. Caching is a mechanism that stores data so that future requests for that data can be served faster. It’s a good point for performance when there are a lot of requests for the same stuff . 


Hibernate comes with 3 caching mechanisms to resolve this issue.

First Level Cache

A hibernate session is a unit of work that’s corresponding to a DB transaction. When doing operations on entities, these latters are not stored immediately in DB but wait until the session commits. The hibernate session is hence representing the first level cache and it’s enabled by default.

Second Level Cache

A hibernate SessionFactory aims to create sessions, initializes JDBC connections and pool them. The second level cache lives in the SessionFactory level so all session can share it. This is why it’s called a process scoped cache.

The second level cache is not enabled by default. One has to configure the cache strategy for hibernate entities and the cache provider that will be a third party caching API like EHCache.

Query Cache

This is related to second level cache and is used for caching queries with parameters. It has to be configured like the second level cache.

To know if the application is hitting the cache, you can configure it in the session factory configuration file and begin your unit tests to get an idea of performance.

Oracle SOA 11g domain issue in R1 PS2

Many weeks ago, I installed a virtual machine of Oracle SOA Suite 11g R1 PS2. Recently, I got time to try it and I got many suprises in the starting of SOA domain.

1. The domain cannot be started and an error message was got : Could not locate enough heap memory.
Searched using google and somebody said the SUN JDK has issue to support large memory. I am not sure whether it is right or not totally as I never got such issue before as BEA WebLogic domain never reserve too much memory. I modified the PermMaxSize and it really solved the starting issue.

2. Got error message in the console after the server was started : Servlet container could not initialized.
Searched on the internet with Google and found it came from the application of Oracle and nothing wrong for the domain.

3. Got SQLException int the console
Searched again with Google and found it is related with the connection testing of datasource and will not affect anything.

SOA - Changing Network Configurations for Oracle SOA Suite

Loopback adapter is needed for SOA installation in the follow scenarios.

1. You are installing on a DHCP computer.
2. You are installing on a non-networked computer and plan to connect the computer to a network after installation.
3. You are installing on a computer with multiple aliases.
4. You are installing on a networked computer (with static IP or DHCP), but you want to be able to run Oracle Application Server when you take the computer off the network.

Steps to change Network configuration (IP, Hostname, domainname)
See Oracle doc for more detail http://docs.oracle.com/cd/E12839_01/core.1111/e10105/host.htm#CHDHAEFE

In Fusion Middleware 11g, Java Components (SOA Suite and WebCenter Suite) are deployed on WebLogic Server. When you change the host name, domain name, or IP address of Oracle WebLogic Server, you also automatically change the information for SOA Suite and WebCenter Suite.

Change Hostname, IP or domainname on WebLogic Managed Server:
http://docs.oracle.com/cd/E12839_01/core.1111/e10105/host.htm#CHDGEDCF

Change Hostname, IP or domainname for System Components (HTTP server, WebCache) , you use chipshost.sh|bat. See more information:
http://docs.oracle.com/cd/E12839_01/core.1111/e10105/host.htm#CHDIFIEF

Change Metadata Repository (Fusion Middleware Schema’s in Database) network configuration:
http://docs.oracle.com/cd/E12839_01/core.1111/e10105/host.htm#CHDBBIAH

Just clarify the pass by value of Java

Remember long time ago, I ever saw a post talking about the refrence of Java. But with the passing of time, almost forget it compeltely. Recently, I looked at another post on the server side agruing the pass by reference. I have to reread it and make it much deeper in my mind. The follow artcile is a good one for pass by reference - http://javadude.com/articles/passbyvalue.htm.

Primitives are passed by value
Objects are passed reference by value (call by sharing)