Thursday Oct 01, 2009

Fuji simple service API and springDM

 What is Fuji simple service api?

The simple service provides the capability to invoke/interact with JAVA code outside of  JBI, Simple Service API provides a bridge between code that is hosted outside of a JBI component and service endpoints available on the NMR. The interface below shows what a user need to do in-order to use simple service api while provisioning an osgi service. for details see Fuji Simple Service API

 \* This interface represents a simple service provisioning contract with the
 \* JBI runtime environment.  The invoke method is called when a message
 \* exchange is addressed to this service instance.  Classes implementing this
 \* interface must be registered in the OSGi service registry in order to be
 \* available to consumers in the JBI runtime environment.  Further, the
 \* service registration must contain a property called "org.glassfish.openesb.serviceName" which
 \* contains the name of the service being offered.  Optionally, a property
 \* called "org.glassfish.openesb.endpointName" can also be specified.
public interface ServiceProvider { 
    ServiceMessage invoke(ServiceMessage message) throws Exception;

This blog shows how to integrate Fuji simple service api with spring/springDM  application, We will create a springDM application which instantiates the above provider Implementation , based on spring-config and spring-osgi-config files . In the diagram below the service provider is part of the spring application and the application context is created by the springDM module

Create a new springDM module, The Spring-OSGi project supplies a maven archetype that will create a SpringDM bundle project , example

 mvn archetype:create   -DarchetypeGroupId=org.springframework.osgi  

The structure of the project will look as below

 spring DM project

Change the pom , add dependency of the Fuji api

 go the src root of the application and add the following dependency to the springDM module pom


Write the POJO which implements ServiceProvider , note this POJO is part of the spring application, and can access any bean or the spring applicationContext, In the above diagram , represents the POJO which implements the ServiceProvider Interface. here is a sample code


import org.glassfish.openesb.api.service.ServiceMessage;
import org.glassfish.openesb.api.service.ServiceMessageFactory;
import org.glassfish.openesb.api.service.ServiceProvider;

public class MyProvider implements  ServiceProvider {
    ServiceMessageFactory msgFactory_;
    public ServiceMessage invoke(ServiceMessage message) throws Exception {
        // Print out the content of the message
        String payload = (String)message.getPayload();
        // One way exchange, so there's no need to return anything
        return null;

    public void setMessageFactory(ServiceMessageFactory factory) {
        msgFactory_ = factory;
    public void setAnotherBean (AnotherBeanI bean){
     //make use the bean


Define the spring beans in the spring config file bundle-context.xml 

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""
       <bean name="anotherBean" class="" />
       <bean name="fujiService" class="">
         <property name="anotherBean" ref="anotherBean"/>

Let us define the beans to be exported as OSGI service, Once the bean MyProvider is exported as osgi service,  any JBI component will be able to access this bean by sending a normalized Message see simple service api for more details 

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:beans=""

 <service id="fujiServiceOsgi" ref="fujiService"

   <beans:entry key="org.glassfish.openesb.serviceName" value="abcService" />
   <beans:entry key="org.glassfish.openesb.endpointName" value="endpoint1" />


Based on the osgi service with the ServiceProvider Interface, an jbi  internal interpoint is activated, The activation of the endpoint is based on the osgi service properties as specified in the bean service definition shown above

  • org.glassfish.openesb.serviceName is used for the service name of the activated endpoint

  • org.glassfish.openesb.endpointName is used for the endpoint name of the activated endpoint

Install the springDM bundles into Fuji-Felix

In order to use springDM application one has to install all the required spring DM osgi bundles, see the set of osgi bundles which needs to installed and started, more details

Build and deploy the application

Go to the project folder and execute
  mvn clean build
In the felix console type install and start the springDM bundle just created
  install file:/ 

Invoking JBI-Endpoint from a spring application 

This would require a springDM application to import an osgi service registered by the Fuji/jbi runtime. Note the current Fuji implementation while activating an jbi endpoint , register an osgi service based on the endpoint properties, The endpoint properties are once again based on service name and the endpoint name, Assuming and endpoint had been activated by a JBI component with service-name = xyzService and endpoint-name=xyzEndpoint , how such a endpoint can be accessed from an spring application. In the diagram below the service consumer is part of the spring application .


 1. Import the osgi services, using the spring-osgi-config file, note the filter

<reference id="jbiService"
  filter="(org.glassfish.openesb.serviceName=xyzService)"  />

2. Use dependency injection to set the service reference into a bean

<bean id="someBean" class="" lazy-init="false">
  <property name="serviceReference" ref="jbiService" />
  <property name="service" ref="jbiService" />

3. Define the bean and Invoke

import org.glassfish.openesb.api.service.ServiceConsumer;
import org.glassfish.openesb.api.service.ServiceMessage;
import org.osgi.framework.ServiceReference;

public class BeanWithJbiServiceReference {
  private ServiceReference serviceReference;
  private ServiceConsumer service
  public void setServiceReference(ServiceReference serviceReference) {
   this.serviceReference = serviceReference;
  public void setService(ServiceConsumer service) {
   this.service = service;
  public void invokeJBIService(Object payload) throws Exception{
   ServiceMessage message = service.getServiceMessageFactory().createMessage();

Future Direction Idea is to provide capabilty which will let any spring bean or osgi service to be accessed seamlessly, based on service properties or configuration, Also Fuji going forward will provide native support for spring beans . Read On   

Thursday Feb 12, 2009

Mtom, Soap with Attachment in Composite Applications

Mtom is used to optimize the transmission of soap message over the wire. MTOM uses a  wire format of a SOAP message by selectively encoding portions of the message, whilst still presenting an XML Infoset to the SOAP application. Optimization is available only for element content that is in a canonical lexical representation of the xs:base64Binary data type  

This article talks how to use mtom in glassfish esb, what are the limitation current implementation has , how to overcome the same

[Read More]

Thursday Feb 05, 2009

Soap1.2 in GlassfishESB

This article show how to use soap1.2 in glassfishesb or javacaps or openesb, also talks about some of the point to note in terms of changes or the differences with soap1.1 

[Read More]

Friday Jul 11, 2008

Security in open-esb

Basic Authentication, this can be based on 

1. Glassfish security realm
2. Sun Java Access Manager
3. WssTokenCompare

 The following steps describes the basic authentication process

  • The client sends a request to the Web service, sending the  credentials as part of the http authorization header , base64 encoded.
  • The Web service validates the credentials against the glassfish/access-manager /WssTokenCompare.
  • The Web service returns a response to the client.

 For more information see basic authentication

Basic Authentication and Authorization

1. this support is only available while using Sun Java System Access Manager while doing basic authentication for more detail see

Brokered Authentication  

The brokered authentication has the following steps

  • The client submits an authentication request
  • The authentication broker validate the authentication credentials , The authentication broker responds to the client if authentication is successful and issues a security token. The client can use the security token to authenticate with the service.
  • A request message containing the security token is sent to the service.
  • The service authenticates the request by validating the security token and sent the response

In open-esb this is achieved using wsit , and the most common security mechanism used in this regard are

  •  X509 Security token
  • Security Token Service

Fore more details see the following examples

Monday Apr 09, 2007

Soa Usage Governance and jbi

Soa governance is a very broad topic. This blog focus on the SOA Usage governance and how can we implement Usage governance in open-esb and jbi. see Soa Governance for sun soa governance solution.

When we talk about SOA Usage governance some of the questions that come up are:

  1. Are we using any usage metrics to for our services?
  2. Are we tracking the messages that are flowing through the system?
  3. Who has / can access a particular service (both internal and external)?

The common approach that the software vendors use is the interception or the mediation. The interception mechanism can be used for various purposes like filter, aggregation, content based routing, transformation, QOS and SLA

The strategies used to resolve Usage governance are

  • Lease Management
  • Charge back
  • Access Control
  • Monitoring
  • Message Tracking
  • Prioritization ...etc

In JBI environment we can use either of the following strategy to mediate or intercept message.

a) NMR interceptor: The JBI spec ( possibly this feature will be included in JBI 2.0 ) provide the user with API to implement an interceptor/handler and use that to intercept message for a given JBI component.

b) Aspect Oriented Programming: In this approach the interception or mediation is done using a service engine called Aspect Service Engine.

The diagram above shows a request-response scenario. Both the request message and the response message is intercepted / mediated using a aspect service engine.

The idea is to inject one or more aspect in between a consumer and provider. The Aspect oriented approach is granular than the NMR interceptor approach and hence more powerful in certain cases. Here the user can be selective about applying aspect for specific service endpoint for a given JBI component. To know more about aspect oriented programming see

  1. Aspect Oriented Programming in JBI
  2. Aspect Service Engine

The diagram above shows the flow of message between Service Units of various service engine and Binding Components and the Aspect Service Unit.This basically shows how we can inject a set a aspect between a consumer and provider. Note each of this aspect for given SU are configurable during runtime.




« April 2014