DBA > Articles

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

By: Clemens Utschig-Utschig and Simone Geib
To read more DBA articles, visit http://dba.fyicenter.com/article/

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 as tech preview in SOA Suite 11g PS1 and will be officially available in 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.

<!--
spring bean inside a context, declaring a name, the class it's implemented
with and the scope (singleton or new instance on each BeanFactory.getBean())
-->
<bean id="InternalPartnerSupplierMediator"
class="com.otn.sample.fod.soa.internalsupplier.InternalSupplierMediator"
scope="prototype">
</bean>
d) Create an <sca:service> that exposes a bean as a service. A component must have a service declared, in order to be usable by other components' references.
<!--
exposed bean 'InternalPartnerSupplierMediator'.
Note the type, which represents the java interface
-->
<sca:service name="IInternalPartnerSupplier"
target="InternalPartnerSupplierMediator"
type="com.otn.sample.fod.soa.internalsupplier.IInternalPartnerSupplier"/>

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);

}

Full article...


Other Related Articles

... to read more DBA articles, visit http://dba.fyicenter.com/article/