Java Reference
In-Depth Information
We've now introduced how to create OSG i bundles out of existing JAR files using
the module layer and how to make your bundles lifecycle aware so they can use frame-
work functionality. The last example in this section demonstrates the service-oriented
programming approach promoted by OSG i.
1.3.3
Service layer example
If you follow an interfaced-based approach in your development, the OSG i service
approach will feel natural to you. To illustrate, consider the following Greeting
interface:
package org.foo.hello;
public interface Greeting {
void sayHello();
}
For any given implementation of the Greeting interface, when the sayHello()
method is invoked, a greeting will be displayed. In general, a service represents a con-
tract between a provider and prospective clients; the semantics of the contract are typ-
ically described in a separate, human-readable document, like a specification. The
previous service interface represents the syntactic contract of all Greeting implemen-
tations. The notion of a contract is necessary so that clients can be assured of getting
the functionality they expect when using a Greeting service.
The precise details of how any given Greeting implementation performs its task
aren't known to the client. For example, one implementation may print its greeting
textually, whereas another may display its greeting in a GUI dialog box. The following
code depicts a simple text-based implementation.
Listing 1.5 Implementation of the Greeting interface
package org.foo.hello.impl;
import org.foo.hello.Greeting;
public class GreetingImpl implements Greeting {
final String m_name;
GreetingImpl(String name) {
m_name = name;
}
public void sayHello() {
System.out.println("Hello, " + m_name + "!");
}
}
Your may be thinking that nothing in the service inter face or listing 1.5 indicates that
you're defining an OSG i service. You're correct. That's what makes the OSG i's service
approach so natural if you're already following an interface-based approach; your
code will largely stay the same. Your development will be a little different in two
places: how you make a service instance available to the rest of your application, and
how the rest of your application discovers the available service.
 
Search WWH ::




Custom Search