INTEGRATING ASYNCHRONOUS COMMUNICATION
INTO THE OSGI SERVICE PLATFORM
Marc Schaaf, Volker Ahlers, Arne Koschel
Faculty IV, Department of Computer Science, University of Applied Sciences and Arts
120 Ricklinger Stadtweg, 30459 Hannover, Germany
Irina Astrova, Ahto Kalja
Institute of Cybernetics, Tallinn University of Technology, 21 Akadeemia tee, 12618 Tallinn, Estonia
David Bosschaert
Progress Software, 158 Shelbourne Road, Ballsbridge 4, Dublin, Ireland
Roman Roelofsen
Weigle Wilczek GmbH, 42-44 Martinstraße, 73728 Esslingen a., Neckar, Germany
Keywords: Asynchronous communication, Remote services, OSGi service platform, Event admin service (EAS),
Message-oriented middleware (MoM).
Abstract: OSGi is a popular Java-based platform that was originally intended for embedded systems. But today OSGi
is used more and more in enterprise systems. To fit this new application area, OSGi is continuously
extended by the OSGi Enterprise Expert Group (EEG). For example, recently, support for remote services
has been added to OSGi. But this support implies only synchronous communication of remote services, thus
limiting the application of OSGi in the area of enterprise systems, as enterprise systems typically embody
both synchronous and asynchronous communication. To fill this gap, we propose a novel approach to
integrating asynchronous communication into OSGi.
1 INTRODUCTION
Due to the manifold requirements of real-world
examples, enterprise systems typically embody both
synchronous and asynchronous communication
(Krafzig, Banke, and Slama, 2005). Synchronous
communication is characterized by that a service
sends a request to another service and keeps waiting
until it receives a response. Asynchronous
communication is less stringent. A service sends a
request to another service but it does not wait for a
response. Rather, it continues working. The response
can be received at any later time.
Recently, support for distribution has been
introduced into OSGi. This support is based on
synchronous invocations of methods for accessing
remote services. However, OSGi does not specify
any methods for asynchronous accessing remote
services yet; this is an area of future standardization.
Therefore, we propose a novel approach to
integrating asynchronous communication into OSGi.
2 OSGI
The OSGi Service Platform (OSGi Alliance, 2009)
is a popular Java-based platform that has arisen in
the context of embedded systems. OSGi is freely
available and continuously extended by the OSGi
Enterprise Expert Group (EEG).
There are a number of commercial and open
source implementations of OSGi, including Eclipse
165
Schaaf M., Ahlers V., Koschel A., Astrova I., Kalja A., Bosschaert D. and Roelofsen R..
INTEGRATING ASYNCHRONOUS COMMUNICATION INTO THE OSGI SERVICE PLATFORM .
DOI: 10.5220/0003401601650168
In Proceedings of the 7th International Conference on Web Information Systems and Technologies (WEBIST-2011), pages 165-168
ISBN: 978-989-8425-51-5
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
Equinox, Apache Felix, Knopflerfish and ProSyst’s
mBedded server. Well-known applications that are
based on OSGi include the Eclipse IDE and Apache
Service Mix.
The core of OSGi is the OSGi Framework. This
framework simplifies the development and
deployment of extensible applications also called
bundles, by decoupling the bundle’s specification
from its implementation. This means that a bundle is
accessed by the framework through an interface,
which is by definition separate from the bundle’s
implementation. This separation enables changing
the bundle’s implementation without changing the
environment and other bundles.
The OSGi Framework makes it possible to run
multiple applications simultaneously within a single
Java Virtual Machine (JVM), by dividing
applications into bundles that can be loaded at
runtime and also removed. For communication
within the JVM, the framework provides a service
registry to register services, so that services can be
found and used by other bundles.
3 OUR APPROACH
Figure 1 provides an overview of our approach. Our
approach aims at integrating asynchronous
communication into OSGi with little or no impact on
OSGi itself. Therefore, our approach is leveraging
the OSGi Event Admin Service (EAS), which
provides asynchronous communication. This
communication is based on the publish-and-
subscribe mechanism, where an event sending
bundle (“producer”) can publish the event to a topic,
whereas an event receiving bundle (“consumer”) can
subscribe to that topic. For subscription, an event
receiving bundle registers an event handler service
with the appropriate service properties. These
properties specify the topic the event handler service
is listening for and an optional filter expression. An
event handler service can be registered by any
bundle that wants to receive the event.
However, leveraging the EAS is more difficult
than it originally appears. This is because the EAS
provides facilities only for receiving events from
bundles and delivering them to all (registered) event
handler services. Concepts like distribution and
guaranteed delivery are not part of the EAS itself.
Next we’ll show how our approach addresses these
issues.
3.1 Distribution
The EAS provides asynchronous communication.
But this communication is limited to a (local) OSGi
container. We solved this problem by using
message-oriented middleware (MoM) for
distribution (see Figure 1).
But herein lies another problem. The
communication mechanism of the MoM is based on
messages, whereas the communication mechanism
of the EAS is based on events. We solved this
problem by introducing a mediation component
called Event Distribution System (EDS) (see Figure
1). The EDS receives events from the EAS and
forwards them as messages to the MoM. In the other
direction, the EDS receives messages from the MoM
and forwards them as events to the EAS. Thereby
the EDS is used to enable the communication
between the MoM and the EAS.
Figure 1: Our approach is leveraging the OSGi Event Admin Service, while leaving the core OSGi relatively untouched.
WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies
166
Figure 2 illustrates this communication when a
bundle sends an event to the MoM. At first, this
event is sent to the EAS. The EAS fulfils its normal
duty by delivering the event to all (registered) event
handler services. One of those services is registered
by the EDS, which thereby receives the event. The
EDS creates a message from the contents of the
event and forwards it to the MoM. Thus, the event
sending bundle communicates with the EAS only; it
has no direct knowledge of the EDS and the MoM.
Figure 2: Asynchronous event delivery. The event sending
bundle has no possibility to determine if the event was
received by the EDS and delivered to the MoM as a
message.
Figure 3 illustrates the communication between
the MoM, the EDS and the EAS when a bundle
receives a message from the MoM. At first, this
message is sent to the EDS. The EDS creates an
event from the contents of the message and forwards
it to the EAS. The EAS delivers the event to all
(registered) event handler services that are listening
for this event. One of those services is registered by
the bundle, which wants to receive the event. Thus,
the event receiving bundle also communicates with
the EAS only; it has no direct knowledge of the EDS
and the MoM.
Figure 3: Asynchronous event reception. The EDS has no
information if the delivery of the event to the destination
was successful. But it needs to acknowledge the successful
reception and processing of the message.
3.2 Guaranteed Delivery
The EDS mediates between the MoM and the EAS.
It receives messages from the MoM and forwards
them as events to the EAS for further delivery to the
(registered) event handler services (see Figure 3). As
soon as, the EDS forwards an event to the EAS, it
cannot know if the event reaches its destination and
if the event is processed successfully. We solved this
problem by connecting the EDS to the event handler
services so that the EDS can forward the event to
them directly (see Figure 1). This way the EDS can
inform the MoM about a successful or failed
delivery.
The EAS completely decouples the event
sending bundle from the EDS and the MoM (see
Figure 2). It only guarantees the delivery of an event
to all (registered) event handler services that are
available at the very moment of this delivery. Since
the event sending bundle cannot know which of the
event handler services are available, it has no
information if the event was successfully delivered
to the EDS. We solved this problem by connecting
the event sending bundle to the EDS (see Figure 1).
Now the event sending bundle knows that the
event was successfully delivered to the EDS as it
sends the event to the EDS directly. However, the
EDS still has no way to inform the event sending
bundle about a failed delivery of the event. This is
because the EAS API does not allow the EDS to
throw an exception from the call of a
postEvent
method.
public interface EventAdmin{
void postEvent(Event event);
...
}
As a result, the event sending bundle has to send the
event blindly without any chance to get information
on the success or failure of the delivery. We solved
this problem by extending the EAS API. In
particular, we defined a new method
postEventReliable, which waits (blocks) until
the event is successfully delivered. In the case of a
failure, it throws an exception. Thereby the event
sending bundle is informed about the failure and can
react appropriately.
public interface ExtendedEventAdmin{
void postEventReliable(Event e) \
throws MessagingException;
...
}
But herein lies another problem. Our previous
solution breaks the compatibility with legacy
bundles. We solved this problem as follows. The
right side of Figure 1 shows that bundles will use the
extended EAS API to guarantee the delivery. The
left side of Figure 1 shows that legacy bundles will
not be aware of the extended EAS API. Rather, they
INTEGRATING ASYNCHRONOUS COMMUNICATION INTO THE OSGI SERVICE PLATFORM
167
will continue to use the EAS API. The centre of
Figure 1 shows an event handler service. It is a
registered service that is listening for events to be
distributed to both legacy bundles and bundles that
are aware of the extended EAS API.
4 RELATED WORK
The work that most closely comes to ours is the ECF
Distributed EAS (Eclipse Foundation, 2009). The
Distributed EAS is implemented based on the
Eclipse Communication Framework (ECF). Thus,
this implementation can be used with a variety of
protocols like ActiveMQ and XMMP. The
implementation replaces the “standard” EAS with
the custom-built EAS, which is capable of sending
events between other remote EASs. The Distributed
EAS also uses the MoM (viz. ActiveMQ Broker) for
distribution. However, by contrast to our approach,
guaranteed delivery is not part of the Distributed
EAS.
5 CONCLUSIONS
Currently, OSGi does not support asynchronous
communication of remote services yet. This is a
severe hindrance for OSGi to be used widely,
especially in distributed environments. As an
attempt to fill this gap, we have proposed a novel
approach to integrating asynchronous
communication into OSGi. Our approach is
leveraging the OSGi EAS, while leaving the core
OSGi relatively untouched. The EAS provides
asynchronous communication. But this
communication is between local services only. We
have solved this problem by using the MoM for
distribution (i.e. remote services). Another problem
with leveraging the EAS was that the EAS does not
guarantee the delivery of events. We have solved
this problem by extending the EAS API.
ACKNOWLEDGEMENTS
Irina Astrova’s and Ahto Kalja’s work was
supported by the Estonian Centre of Excellence in
Computer Science (EXCS) funded mainly by the
European Regional Development Fund (ERDF).
REFERENCES
Eclipse Foundation, 2009. Distributed Event Admin
Service. http://wiki.eclipse.org/Distributed_Event
Admin_Service.
Krafzig, D., Banke, K., Slama, D., 2005. Enterprise SOA:
service-oriented architecture best practices. Pearson
Education, Inc.
OSGi Alliance, 2009. OSGi Service Platform Service.
Compendium – Release 4, version 4.2.
http://www.osgi.org/Release4/.
Rellermeyer, J., Alonso, G., Roscoe, T., 2007. R-OSGi:
Distributed applications through software
modularization. In Middleware’07, vol. 4834.
Springer.
WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies
168