+

Search Tips   |   Advanced Search

Services and the Blueprint Container

In the Blueprint programming model, we use a service element to define the registration of a service in the OSGi service registry. We use the ref attribute to reference the bean that provides the service object. We use the interface attribute to specify the interfaces under which the service is registered.

The service registration mechanism described in this topic is not required to define an EJB as a service. Instead, specify the EJB class name in the Export-EJB header in the bundle manifest file.

See the following partial Java class and Blueprint XML example code.

public class AccountImpl implements Account {      
   public AccountImpl() {
      ...
   }
}

<service id="serviceOne" ref="account" 
   interface="org.apache.aries.simple.Account" />

<bean id="account" class="org.apache.aries.simple.AccountImpl" />

We can specify the bean that provides the service object using an inline declaration in the service element, as shown in the following Blueprint XML example code.

<service id="serviceTwo" interface="org.apache.aries.simple.Account">
   <bean class="org.apache.aries.simple.AccountImpl" />
</service>

Use the auto-export attribute to set the interfaces under which a service is registered. The following Blueprint XML example code registers the service under all the interfaces of the bean.

<service id="serviceOne" ref="account" auto-export="interfaces" />

<bean id="account" class="org.apache.aries.simple.AccountImpl" />

The default value for the auto-export attribute is disabled. Other values are class-hierarchy and all-classes.

Service properties

We can register a service with a set of properties using the service-properties element. The service-properties element contains multiple entry elements that represent the individual properties. You specify the property key using a key attribute. You specify the property value as a value attribute, or in inline declaration in the element. Service property values can be different types, but must be only OSGi service property types, that is, one of the following types:

  • primitive
  • primitive wrapper class
  • collection
  • array of primitive types

The following Blueprint XML example code shows a service registration with two service properties. The active service property has type of java.lang.Boolean. The mode property is of the default type, String.

<service id="serviceFour" ref="account" autoExport="all-classes">
   <service-properties>
      <entry key="active">
         <value type="java.lang.Boolean">true</value>
      </entry>
      <entry key="mode" value="shared"/>
   </service-properties>
</service>

Service ranking

Use service ranking to control the choice of service when there are multiple matches. If there are two services, the higher ranked service is returned before the lower ranked one. The default ranking value is 0. The following Blueprint XML example code shows how to specify service ranking using the ranking attribute. 
<service id="serviceFive" ref="account" auto-export="all-classes" ranking="3" />


Related:

  • Blueprint bundles
  • Blueprint XML
  • Beans and the Blueprint Container
  • References and the Blueprint Container
  • Scopes and the Blueprint Container
  • Object values and the Blueprint Container
  • Object life cycles and the Blueprint Container
  • Resource references and the Blueprint Container
  • Dynamism and the Blueprint Container
  • Type converters and the Blueprint Container
  • JNDI lookup for blueprint components
  • Developing an OSGi application
  • Create a service bundle
  • OSGi Service Platform Release 4 Version 4.2 Enterprise Specification
  • Building OSGi applications with the Blueprint Container specification




    File name: was318.html

    prettyPrint();