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.

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

17. Implementation
Configuration approaches
 3 options provided ExampleService service = new ExampleServiceImpl();
Dictionary dict = new Hashtable();
dict.put (“expose.service”, true) ;
 Java properties dict.put (“expose.interface”, ExampleService.class);
dict.put (“expose.url”, “http://localhost:8080/exampleService”);
context.registerService (ExampleService.class.getName(),
service, dict);
<?xml version=“1.0” encoding=”UTF−8”?>
<component name=“ExampleService”>
<implementation class=“com.example.ExampleServiceImpl”/>
<property name=“expose.service”>true</property>
 Declarative Service <property
Spec. (DSS) name=“expose.interface”>com.example.ExampleService
</property>
<property name=“expose.url”>http://localhost:8080/
exampleService
</property>
<service>
 Spring-OSGi <provide interface=“com.example.ExampleService”/>
</service>
(not here) </component>
 ...
17

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

19. Implementation
Remote access from OSGi
19

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