Think Large, Act Small: An Approach to Web Services for Embedded Systems Based on the OSGi Framework

Roman Roelofsen Prosyst

Köln Germany

David Bosschaert Progress

Dublin Ireland

Volker Ahlers University of Applied Sciences and Arts,

Hannover, Germany

Arne Koschel University of Applied Sciences and Arts,

Hannover, Germany

Irina Astrova Institute of Cybernetics

Univ. Tallinn Estonia

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

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’

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

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’

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.

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.

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.

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

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’

12

Implementation Used Technology: OSGi   Standardized, small

footprint ‘in memory SOA’ for Java

  OSGi core   Bundles and

services for modularization and encapsulation

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

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.

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

16

Implementation

Whiteboard pattern   Originally alternative to listener/observer pattern

  ‘Kind of’ internal advertisement service

  Frequently used for OSGi applications

17

Implementation Configuration approaches   3 options provided

  Java properties

  Declarative Service Spec. (DSS)

  Spring-OSGi (not here)

  . . .

ExampleService service = new ExampleServiceImpl(); Dictionary dict = new Hashtable(); dict.put (“expose.service”, true) ; 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> <property name=“expose.interface”>com.example.ExampleService </property> <property name=“expose.url”>http://localhost:8080/exampleService </property> <service> <provide interface=“com.example.ExampleService”/> </service>

</component>

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)

19

Implementation Remote access from OSGi

20

Implementation Adopting CXF for embedded Java Platforms

  Java Standard Edition Embedded (Java SEE).

  Almost full Java 5 spec.   Only 30MB memory footprint compared to

60MB java SE   Several processors

  JamVM   Java 5 based also   Compared to Java SEE: very small

footprint and runs on ARM processors.

  Java Micro Edition (Java ME)   ARM processors, PowerPC and Intel x86

processors.   Java ME CDC is viable for low end

devices with memory footprint starting from 2 MB.

Adoption results

  Adoption easy for Java SEE and JamVM   Java 5 code runs just fine   JamVM required some class additions. A

few changes for java.io and java.xml required.

  Java ME CDC   Java 1.4 based, but can run Java 5 byte

code   For new language constructs (annotations)

we used the Harmony tool for byte code weaving

  Annotatiosn simulated using reflection   Thus some CXF modifications required

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

22

Questions ? Questions !

Arne Koschel

University of Applied Sciences, Faculty IV, Department for Computer Science Hannover, Germany

akoschel@acm.org www.fakultaet4.fh-hannover.de http://www.koschel-edv.de/arne_koschel_publications

Irina Astrova

Tallinn University of Technology Institute of Cybernetics, Tallinn, Estonia

irinaastrova@yahoo.com