Skip to main content
Jump to: navigation, search

Difference between revisions of "Tutorial: Building your first OSGi Remote Service"

(Define a Service Interface)
(Define a Service Interface)
Line 24: Line 24:
 
The purpose of this service is to provide the current time...in the form of a long value specifying the number of milliseconds since 1970.  Of course, declarations of much more complex services (and remote services) are possible, with multiple methods, multiple arguments for each method, and complex types as arguments and return values.  In essence, any semantics that can be represented as a java interface can be used as the service interface.
 
The purpose of this service is to provide the current time...in the form of a long value specifying the number of milliseconds since 1970.  Of course, declarations of much more complex services (and remote services) are possible, with multiple methods, multiple arguments for each method, and complex types as arguments and return values.  In essence, any semantics that can be represented as a java interface can be used as the service interface.
  
With OSGi Services Interfaces (and Remote Services) it's a best practice to put the service interface (and any referred to by the service interface) in a distinct bundle.  This creates a clear, modular separation between the service interface API and both the service implementation and any code that uses the service.  For Remote Services this separation is particularly important, since the client/consumer of the remote service only needs to reference the service interface.
+
With OSGi Services Interfaces (and Remote Services) it's a best practice to put the service interface (and any referred to by the service interface) in a distinct bundle.  This creates a clear, modular separation between the service interface API and both the service implementation and any code that uses the service.  For Remote Services this separation is particularly important, since the client/consumer of the remote service only references the service interface...the implementation doesn't even need to be present in the framework.
 +
 
 +
[http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice Here] is a complete bundle with only the ITimeService class declared.  Note that the package containing this class is exported via the [http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice/META-INF/MANIFEST.MF manifest]:
 +
 
 +
<source lang="manifest">
 +
...
 +
Export-Package: com.mycorp.examples.timeservice;version="1.0.0"
 +
</source>
 +
 
 +
Note also the version information associated with the package.

Revision as of 00:01, 6 December 2013

Introduction

The OSGi Framework provides a very simple model to expose services within a local runtime. Also available, however, is a specification of Remote Services...services that are exported by a distribution provider to allow remote access. The ECF project implements a specification-compliant distribution provider.

This tutorial will show how to

  1. define and implement a simple OSGi service
  2. expose that service for remote access via ECF's implementation of the OSGi Remote Services standard

Define a Service Interface

The key to building a system with low coupling and high cohesion is to create clear and coherent boundaries between different parts of your system. Central to this is defining simple, clear interfaces between subsystems...to allow to interact, but only in clearly defined ways.

For example, here's a simple time service:

public interface ITimeService {
 
	public Long getCurrentTime();
 
}

The purpose of this service is to provide the current time...in the form of a long value specifying the number of milliseconds since 1970. Of course, declarations of much more complex services (and remote services) are possible, with multiple methods, multiple arguments for each method, and complex types as arguments and return values. In essence, any semantics that can be represented as a java interface can be used as the service interface.

With OSGi Services Interfaces (and Remote Services) it's a best practice to put the service interface (and any referred to by the service interface) in a distinct bundle. This creates a clear, modular separation between the service interface API and both the service implementation and any code that uses the service. For Remote Services this separation is particularly important, since the client/consumer of the remote service only references the service interface...the implementation doesn't even need to be present in the framework.

Here is a complete bundle with only the ITimeService class declared. Note that the package containing this class is exported via the manifest:

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, arm, asm, asp, asymptote, autoconf, autohotkey, autoit, avisynth, awk, bascomavr, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_loadrunner, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, coffeescript, cpp, cpp-qt, csharp, css, cuesheet, d, dcl, dcpu16, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, epc, erlang, euphoria, f1, falcon, fo, fortran, freebasic, freeswitch, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, haxe, hicest, hq9plus, html4strict, html5, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, ldif, lisp, llvm, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, nagios, netrexx, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, octave, oobas, oorexx, oracle11, oracle8, otj, oxygene, oz, parasail, parigp, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, pli, plsql, postgresql, povray, powerbuilder, powershell, proftpd, progress, prolog, properties, providex, purebasic, pycon, pys60, python, q, qbasic, rails, rebol, reg, rexx, robots, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, spark, sparql, sql, stonescript, systemverilog, tcl, teraterm, text, thinbasic, tsql, typoscript, unicon, upc, urbi, uscript, vala, vb, vbnet, vedit, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, yaml, z80, zxbasic


...
Export-Package: com.mycorp.examples.timeservice;version="1.0.0"

Note also the version information associated with the package.

Back to the top