Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Think Large, Act Small: An Approach to Web
Services for Embedded Systems Based on
the OSGi Framework

   Roman Roelofsen  ...
And now something different
                

     Let‘s get a bit technical
      Beware – Some code included
Agenda
    Background, Scenarios, Requirements

    Adding ESB / Web services based
     Distribution Capabilities to OS...
Background

Project Setup
    Cross country research (Germany, Estonia) /
     Industry (Ireland, USA) cooperation includ...
Background

SOA, ESB, Web Services
    Service Oriented Architecture is a
     distributed system architecture concept

...
Background

Embedded Systems
    Smaller memory footprint
    ‘Typical’ processors
         ARM: 32 Bit, low power cons...
Scenarios

Why Embedded Web Services?
    Web services usually used in
     large distributed systems.

    Two example ...
Requirements

Requirements Driven by Scenarios
    R1: Exposing Information for External Consumers
         Car tracking...
Requirements

Requirements Driven by Scenarios
    R3: Enable Simultaneous Use of Technologies
          Depending on th...
Agenda
    Background, Scenarios, Requirements

    Adding ESB / Web services based
     Distribution Capabilities to OS...
Implementation

Design Issues: Embedded Web Services
    Independent transport protocol
          Scenarios have highly ...
Implementation

Used Technology: OSGi
    Standardized, small
     footprint ‘in memory
     SOA’ for Java
    OSGi core...
Implementation

Used Technology: OSGi
    OSGi was selected for several reasons, including (but not limited to)
        ...
Implementation
Used Technology: Apache CXF
    Free, open source
    Small footprint, multiple protocol ESB
    Fits we...
Implementation

Independent Bundles
    ‘CXF’ and ‘Web service’ are provided as
     2 independent OSGi bundles, thus
   ...
Implementation

Whiteboard pattern
    Originally alternative to listener/observer pattern

    ‘Kind of’ internal adver...
Implementation

Configuration approaches
    3 options provided         ExampleService service = new ExampleServiceImpl()...
Implementation

Remote access design
    Req. from 2nd scenario:
     Remote Access

    Two options examined
         ...
Implementation

Remote access from OSGi




                          19
Implementation
Adopting CXF for embedded Java
Platforms                                           Adoption results

    J...
Conclusion & Outlook
    Core contributions
         Evaluation, if OSGi/CXF can meet the requirements of
          exam...
Questions ?                  Questions !



Irina Astrova                      Arne Koschel

Tallinn University of Technol...
Upcoming SlideShare
Loading in …5
×

Vii 2 Z Final Slides Os Gi Iess 2010

624 views

Published on

Think Large, Act Small: An Approach to Web Services for Embedded Systems Based on the OSGi Framework
Irina Astrova, Arne Koschel, Roman Roelofsen, David Bosschaert, and Volker Ahlers

Published in: Education
  • Be the first to comment

  • Be the first to like this

Vii 2 Z Final Slides Os Gi Iess 2010

  1. 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. 2. And now something different  Let‘s get a bit technical Beware – Some code included
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Implementation Used Technology: OSGi   Standardized, small footprint ‘in memory SOA’ for Java   OSGi core   Bundles and services for modularization and encapsulation 12
  13. 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. 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. 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. 16. Implementation Whiteboard pattern   Originally alternative to listener/observer pattern   ‘Kind of’ internal advertisement service   Frequently used for OSGi applications 16
  17. 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. 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. 19. Implementation Remote access from OSGi 19
  20. 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. 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. 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

×