Introduction to the OSGi Blueprint

It is possible define and register all OSGi services programmatically, but a better way is to use the OSGi Blueprint.

In addition to defining services, you can use Blueprint to dynamically wire together the disparate components of an OSGi application.

Here’s an example of an existing service in MDM as defined using the Blueprint XML:

<service id="Controller.ITCRMCorePartyTxn"  
 interface="com.dwl.tcrm.coreParty.interfaces.ITCRMCorePartyTxn">    
 <service-properties> 
  <entry key="osgi.jndi.service.name"> 
   <list> 
    <value>collapsePartiesWithRules</value>   
    <value>addAddress</value>   
    <value>addPartyAddressPrivacyPreference</value>   
    <value>collapseParties</value>   
    ... 
     
</service-properties> 
 <bean class="com.dwl.tcrm.coreParty.controller.TCRMCorePartyTxnBean"/> 
</service>

This is the new way that the Party Controller is registered and mapped to the transactions it supports in InfoSphere® MDM. Examine the XML more closely, starting with the service definition for the Party Controller service:

<service id="Controller.ITCRMCorePartyTxn"  
 interface="com.dwl.tcrm.coreParty.interfaces.ITCRMCorePartyTxn">

This represents the service definition. The ID is optional and is a way to give a name to the service. The actual service definition as it’s recognized in the OSGi and Blueprint containers is the interface name itself:

interface=”com.dwl.tcrm.coreParty.interfaces.ITCRMCorePartyTxn”

Any bundle wanting to consume this service only needs access to the interface, but it does not need to know anything about the location or details of the implementation of this service.

Next, consider the service properties:

<service-properties> 
  <entry key="osgi.jndi.service.name"> 
   <list> 
    <value>collapsePartiesWithRules</value>   
    <value>addAddress</value>   
    <value>addPartyAddressPrivacyPreference</value>   
    <value>collapseParties</value>   
    ... 
     
</service-properties>

These are the service properties for the Party Controller service. The service properties are what distinguish this controller (the transaction it supports) from the other controller services. Every property must have a key or a name that can be used to distinguish it from other properties. In this case, the property key is osgi.jndi.service.name. This is a special property that allows a client to look up the service using values in this property.

Finally, here is the service implementation -- the bean that implements the Party Control Service:

<bean class="com.dwl.tcrm.coreParty.controller.TCRMCorePartyTxnBean"/>