This document proposes an approach to adding web services and distribution capabilities to embedded systems based on the OSGi framework. It discusses challenges with embedded web services and how OSGi and Apache CXF can address these. The approach was evaluated based on requirements from example scenarios of car tracking and advertising services in vehicles. It describes implementing independent bundles, using the whiteboard pattern for loose coupling, and various configuration approaches. It also discusses adopting CXF for embedded Java platforms like Java SEE and JamVM to meet memory restrictions of embedded systems.
Kisan Call Centre - To harness potential of ICT in Agriculture by answer farm...
Vii 2 Z Final Slides Os Gi Iess 2010
1. Think Large, Act Small: An Approach to Web
Services for Embedded Systems Based on
the OSGi Framework
Roman Roelofsen David Bosschaert Volker Ahlers
Prosyst Progress University of Applied
Köln Dublin Sciences and Arts,
Germany Ireland Hannover, Germany
Arne Koschel Irina Astrova
University of Applied Institute of Cybernetics
Sciences and Arts, Univ. Tallinn
Hannover, Germany Estonia
2. And now something different
Let‘s get a bit technical
Beware – Some code included
3. Agenda
Background, Scenarios, Requirements
Adding ESB / Web services based
Distribution Capabilities to OSGi
Challenges with embedded Web Services
OSGi & Apache CXF
Implementation details
Adoption to smaller devices: Java VM choices
Conclusion
3
4. Background
Project Setup
Cross country research (Germany, Estonia) /
Industry (Ireland, USA) cooperation including
‘on-site’ development in Ireland
Software vendor (espec. middleware)
Enhancements for IT services standards
specification
(including OSGi / Web services) ‘in mind’
4
5. Background
SOA, ESB, Web Services
Service Oriented Architecture is a
distributed system architecture concept
Services with well described interface(s)
Service / Messaging Backbone
Often: Logical / Technical
“Enterprise Service Bus (ESB)”
Integration of components often based on
productive systems
Different communication paradigms
Request-Response; Oneway; …
Implementation possible with different
technologies, e.g.
CORBA, Web Services, Java EE, .Net, . . .
Web Services w.WSDL, SOAP typical
5
6. Background
Embedded Systems
Smaller memory footprint
‘Typical’ processors
ARM: 32 Bit, low power consumption,
typical for mobiles, PDAs
some Power PC (e.g. PlayStation)
some Intel X86
‘Passing by’ service providers typical
if used ‘in movement’
6
7. Scenarios
Why Embedded Web Services?
Web services usually used in
large distributed systems.
Two example scenarios from
in-car embedded devices
Car tracking
Advertising
Attributes of both
Inside car communication
with ‘outside world’ servers,
e.g. via UMTS network.
Web services usage, thus
dynamic service offerings
will occur.
7
8. Requirements
Requirements Driven by Scenarios
R1: Exposing Information for External Consumers
Car tracking service should
be independent of a specific car manufacturer;
respect existing standards like SOAP to enable third-party integration;
expose the (same) information using different technologies at the same
time (to broaden the number of perspective users)
ease technical consumption of information, so no new proprietary
protocols and semantics should be introduced.
R2: Accessing External Information
Advertising service
needs to access external information using existing standards like
SOAP (car tracking service exposes them);
should abstract from underlying technologies to ease consumption of
external information.
8
9. Requirements
Requirements Driven by Scenarios
R3: Enable Simultaneous Use of Technologies
Depending on the services offered to or by the in-car embedded device,
different technologies will be used. However, the use of one technology
should not prevent the in-car embedded device from using another
technology. Since the technologies may evolve independently from each
other, the in-car embedded device should be able to replace the
technologies. On the other hand, different technologies may be used at the
same time. However, a simultaneous use of technologies should not lead to
an inconsistent environment.
R4: Facilitate Loose Coupling between Services and Technologies
The term loose coupling usually refers to the coupling between services and
consumers, especially over a network. Here, the coupling between services
and technologies is getting observed.
Services may use different technologies at the same time. However, they
may not know in advance, which of the technologies will be used.
Therefore, a loose coupling between services and technologies is required.
9
10. Agenda
Background, Scenarios, Requirements
Adding ESB / Web services based
Distribution Capabilities to OSGi
Challenges with embedded Web Services
OSGi & Apache CXF
Implementation details
Adoption to smaller devices: Java VM choices
Conclusion
10
11. Implementation
Design Issues: Embedded Web Services
Independent transport protocol
Scenarios have highly independent parties, so multiple
independent Web services transports are required (e.g., not
only HTTP)
Highly dynamic service offerings
A full WS stack would help, but embedded devices might be
too small wrt their resources
Nonetheless: WS standard required
Flexible, standardized technology combination useful
Here: OSGi & ESB (Apache CXF) + ‘Java Embedding’
11
12. Implementation
Used Technology: OSGi
Standardized, small
footprint ‘in memory
SOA’ for Java
OSGi core
Bundles and
services for
modularization and
encapsulation
12
13. Implementation
Used Technology: OSGi
OSGi was selected for several reasons, including (but not limited to)
its dynamic service capabilities – suitable for ‘in movement scenes’
Bundles and service ‘come and go’ in different, independent versions at
runtime
Local OSGi service registry (SR)
Deployable on all kind of devices ‘from sensor nodes to mainframes’
Bundle concept increases the isolation between different modules
As long as the metatdata is properly defined, OSGi provides a
notion of execution environments to select bundles/capabilities
based on the current hardware or environment; thus, a fair bit of
hardware independency
Java based
Java Community Process (JCP) standard
Missing in OSGi at that time though
distribution features
13
14. Implementation
Used Technology: Apache CXF
Free, open source
Small footprint, multiple protocol ESB
Fits well to requirements
Info exposure
Read OSGi service registry for service properties
External information access
ESB abstracts from local / remote view
Simultaneous use of technologies
ESB abstracts transparently from multiple technologies
Loose coupling between services and technologies
Bundles use different configurations
No knowledge about technologies required that process the specified properties
to create an endpoint.
Scenarios have quite heterogeneous distributed environment where different
networks or services may need different technologies.
CXF allows these independent parties to use the needed technologies while
participating in other networks or with other services provided that a common set
of technologies exists.
14
15. Implementation
Independent Bundles
‘CXF’ and ‘Web service’ are provided as
2 independent OSGi bundles, thus
CXF bundle can be installed after the
Web service bundle and removed after a
certain time.
To enforce a loose coupling between the
two but still enable the use of each other,
the Whiteboard pattern was applied
15
16. Implementation
Whiteboard pattern
Originally alternative to listener/observer pattern
‘Kind of’ internal advertisement service
Frequently used for OSGi applications
16
18. Implementation
Remote access design
Req. from 2nd scenario:
Remote Access
Two options examined
Creating a remote API.
Creating a proxy (which
we followed
prototypically)
18
20. Implementation
Adopting CXF for embedded Java
Platforms Adoption results
Java Standard Edition Embedded (Java Adoption easy for Java SEE and JamVM
SEE). Java 5 code runs just fine
Almost full Java 5 spec. JamVM required some class additions. A
Only 30MB memory footprint compared to few changes for java.io and java.xml
60MB java SE required.
Several processors
Java ME CDC
JamVM Java 1.4 based, but can run Java 5 byte
Java 5 based also code
Compared to Java SEE: very small For new language constructs (annotations)
footprint and runs on ARM processors. we used the Harmony tool for byte code
weaving
Annotatiosn simulated using reflection
Java Micro Edition (Java ME) Thus some CXF modifications required
ARM processors, PowerPC and Intel x86
processors.
Java ME CDC is viable for low end
devices with memory footprint starting
from 2 MB.
20
21. Conclusion & Outlook
Core contributions
Evaluation, if OSGi/CXF can meet the requirements of
example scenarios.
Adoption of OSGi/CXF to Java embedded platforms in order
to meet the memory restrictions of embedded systems.
Our properties based approach influenced the OSGi
standard
It was presented to OSGi expert group and in similar form
later used by the distributed OSGi specification.
Outlook: Current research work
Asynchronous, distributed event-based messaging for OSGi
21
22. Questions ? Questions !
Irina Astrova Arne Koschel
Tallinn University of Technology University of Applied Sciences, Faculty IV,
Institute of Cybernetics, Department for Computer Science
Tallinn, Estonia Hannover, Germany
irinaastrova@yahoo.com akoschel@acm.org
www.fakultaet4.fh-hannover.de
http://www.koschel-edv.de/arne_koschel_publications
22