Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

OSGi-Entwicklung
OSGi-Entwicklung
OSGi-Entwicklung
Ebook71 pages1 hour

OSGi-Entwicklung

Rating: 0 out of 5 stars

()

Read preview

About this ebook

OSGi hat sich als führende Modularitätslösung für anspruchsvolle Java-Anwendungen etabliert. Dieser shortcut befasst sich mit aktuellen Innovationen in der OSGi-Anwendungsentwicklung: Das neue Framework OSGi enRoute von Peter Kriens sowie die Neuerungen in der OSGi-Entwicklungsumgebung Bndtools werden vorgestellt. Es wird gezeigt, wie leicht, effektiv und schnell die Entwicklung von Komponenten mit OSGi sein kann und welche Neuerungen das Update der OSGi Http Service Specification mit sich bringt. Abschließend beleuchtet der shortcut den OSGi-Server Karaf, der zahlreiche Funktionen zur Unterstützung der Entwicklung von OSGi-Anwendungen bereithält und das Hinzufügen einiger OSGi-Enterprise-Funktionalitäten ermöglicht.
LanguageDeutsch
Release dateMay 30, 2015
ISBN9783868025460
OSGi-Entwicklung

Related to OSGi-Entwicklung

Titles in the series (100)

View More

Related ebooks

Programming For You

View More

Related articles

Reviews for OSGi-Entwicklung

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    OSGi-Entwicklung - Peter Kriens

    GmbH

    1 Ein neues Framework für OSGi-Anwendungen

    Als wir im Jahr 1998 mit den Arbeiten an den OSGi-Spezifikationen begannen, hatten wir die Gelegenheit, ein Weltklasseframework für kleine Netzwerkgateways zu schaffen – der aktuelle Raspberry Pi ist im Vergleich dazu extrem leistungsfähig. Heute, sechzehn Jahre später, ist OSGi die führende Modularitätslösung für Java-Anwendungen auf dem Markt. Es ist eine Technologie, die wir für unabdingbar für die Entwicklung anspruchsvoller Java-Anwendungen halten. Dennoch zeigen diverse Blogs, dass einige falsche Annahmen über OSGi im Umlauf sind.

    OSGi ist die einzige Lösung auf dem Markt, die die letzten Innovationen unserer IT-Industrie, etwa Objektorientierung und Inversion of Control/Dependency Injection, umfassend mit einschließt und darüber hinaus den nächsten Paradigmenwechsel mit sich bringt: serviceorientierte Programmierung. Dabei geht es nicht darum, auf einer Art Hypewelle mitzureiten – nein, serviceorientierte Programmierung war keineswegs ein nachgelagerter Gedanke bei OSGi. Echte serviceorientierte Systeme (SOS) sind von Beginn an der Kern von OSGi gewesen. Erst nachdem die SOA-Bewegung den Begriff „Service für sich vereinnahmt hatte, begannen wir, unsere Services „Microservices zu nennen. Und mittlerweile verwenden wir den Begriff „μservice, da „Microservice heute immer mehr für das weitaus schwergewichtigere Modell der REST-Services genutzt wird.

    Obwohl das μservice-Modell das wichtigste Feature von OSGi ist, stellt es auch die größte Herausforderung für die Verbreitung von OSGi dar, weil es von Entwicklern fordert, anders zu denken. Java – und insbesondere Java EE – hat einige schlechte Angewohnheiten in Mode gebracht. Zum Beispiel war Class Loading niemals als Extensions-Mechanismus konzipiert. Und Statics in einem API haben dieselben Nachteile wie globale Variablen: Sie erzeugen beide unschöne Kontext- und Singleton-Probleme. Leider gibt es in Java kein mächtigeres Extensions-Modell, das die Entwicklung von Anwendungen aus wiederverwendbaren Modulen heraus erlaubt. OSGi liefert eine solche solide Lösung für Modularität.

    Allerdings hat die Vermeidung der schlechten Angewohnheiten, die Java so antimodular machen, es OSGi erschwert, den Mainstream-Java-Entwickler zu erreichen. Nur wenn diese Entwickler sich so tief im Softwaredickicht verstricken, dass OSGi unvermeidbar wird, verstehen sie endlich die Lösungsansätze von OSGi.

    Das OSGi-μservice-Modell ist ein Paradigmenwechsel

    Das große Problem mit Paradigmenwechseln ist, dass das Publikum oft blind für die Vorteile des neuen Paradigmas ist. Das ist hervorragend im Buch „Flatland" von Edwin A. Abbott nachgezeichnet, in dem es um das Leben in verschiedenen Dimensionen geht. Es wird gezeigt, wie ein Punkt, der in einer Welt von Linien existiert, sich niemals eine Ebene vorstellen kann. Genauso wird sich eine Ebene niemals eine Kugel denken könnte.

    Und auch wir selbst sind verloren, wenn wir über eine vierte oder fünfte Dimension nachdenken. Wir verstehen sie zwar rational und haben keine Probleme damit, mit tausenden von Dimensionen zu rechnen, doch wir werden niemals etwas von einer Sache empfinden, die wir nicht wirklich erfahren haben.

    Ein Beispiel: Im Sun Java Issue Tracker fragte einst jemand nach einer Multimap – eine überraschende Lücke im Java Collections API. Der Issue wurde von Sun aber geschlossen, weil der Autor niemals die Notwendigkeit einer Multimap verspürte – anders als die vielen nicht beachteten Upvoter. In ähnlicher Weise war es für mich als alter Smalltalker interessant, in den letzten Jahren die Diskussionen über die Einführung von Lambda-Ausdrücken in Java zu verfolgen. Viele Entwickler waren skeptisch. Doch werden dieselben Entwickler sich in einigen Jahren eine Welt ohne Lambdas nicht mehr vorstellen können. Die Welt wäre ein ruhiger Ort, wenn wir nur über Technologien reden würden, mit denen wir selbst schmerzvolle Erfahrungen gemacht haben.

    Wir haben bei der OSGi Alliance also diese wundervolle neue Dimension der Softwareentwicklung, doch zeigt es sich, dass sie nur schwer zu vermitteln ist. Nur wer die Vorteile wirklich am eigenen Leib erfahren hat, wird verärgert aufschauen und fragen, warum ihm das niemand

    Enjoying the preview?
    Page 1 of 1